Develo has built a full-featured EHR and customer relationship management (CRM) for pediatrics, encompassing core scheduling, clinical, and billing workflows along with family engagement capabilities.
(5 minute demo)
Outpatient pediatrics is uniquely family-centered, longitudinal care-driven, and high volume, with distinct well child check-ups and payor mix that is different from other specialties. Accordingly, the Develo product is beautifully designed with much attention to the nuances that matter to their core independent pediatric practices market.
(A beautiful pediatric growth chart)
Develo has built a full stack solution with key innovations around automating family engagement, reducing administrative tasks, and AI-assisted documentation.
(Intuitive patient intake)
They rapidly release new capabilities and take a comprehensive, end-to-end approach to build a full operating system for pediatrics, rather than just optimizing a narrow set of provider workflows.
(Scheduling orders)
Develo EHR is FHIR native and built on Medplum using the following features:
Self-hosting: Develo hosts Medplum in their own AWS.
Multi-tenant: Develo customers have separate datastores using Medplum projects.
This application is an example of a software company, using Medplum to build a custom EHR that delights pediatricians, patients, and families alike. Some screen shots of the applications are shown below.
(Even the billing experience shows attention to detail)
As we close out 2023, the Medplum team would love to thank our customers and community for joining us on this journey.
We wanted to highlight a few memorable moments and reflect on all that happened during the year. It was a lot of fun, and huge thank you to the team who pushed so hard to make all these things happen.
✅ Added many wonderful customers, and several have written case studies about how they use Medplum.
The Medplum team is pleased to announce that we have certified the (b)(10) ONC Criteria - Electronic Health Information Export.
To see details related to our certification please check out our ONC Certification page.
What does this mean?
It means that a full export of a patient's data can be pulled from Medplum in a machine readable format, in a timely manner. At the time of this writing, the CHPL lists 70 EHRs have certified the (b)(10), out of 708 total. The requirements are summarized as follows:
✅ All data for a specific patient can be exported
✅ Machine readable format
✅ Timely export
✅ Self-service, can be done without contacting support
For those new to EHRs,** it can come as a surprise that it isn't a requirement that a patient's data be exportable in machine readable format**. This criteria is relatively recent, and a result of the 21st Century CURES Act. We believe it is a great benefit to our industry and for patients.
Medplum's implementation is open source and we believe we are the only open source implementation of this criteria so far. For data management certification criteria, the key benefit of open source is composability. Instead of ripping and replacing a huge monolithic system that needs to conform to one or more complex compliance frameworks, you can progressively enhance an implementation to fit the requirements of your specific scenario.
One of the main sources of confusion when starting an implementation is with FHIR system strings.
This field is ubiquitous across FHIR elements, but many developers who are new to healthcare don't understand its purpose or how to set it properly. They are used in even the most basic implementations, and even the sample data we provide for prototyping has many system identifiers.
So today, we're going to delve into system strings to understand what they're for and how to use them!
System strings are commonly found on two distinct element types:
A common occurrence in healthcare is that the same entity (patient, practitioner, device, etc.) is present in many different systems, each assigning their own unique ID. With FHIR, we can neatly keep track of all these unique IDs using the identifier field.
To avert any name collisions, each Identifier has an associated system string, which acts as a namespace for the identifier. This namespace is typically an absolute URL to ensure its global uniqueness.
Let's look at an example. Say we have two patients, Alice and Bob, who have both visited Hospital 1 and Hospital 2. They have the following medical record numbers:
Alice
Bob
Hospital 1
12345
Hospital 2
98760
Hospital 1
98760
Hospital 2
12345
Simply searching for the patient with record number "12345" would cause confusion.
GET [base]/Patient?identifier=12345
The system string is our guiding light here. It allows us to clarify which identifier comes from each hosptial.
Healthcare thrives on codes. Labs, medications, billing - they all have alphanumeric code systems. These standardized codes help healthcare actors communicate, reduce ambiguity, and streamline interoperability. You may have heard of some of these codes, like CPT for "procedure codes" or ICD-10 "diagnosis codes".
In an ideal world, there would be one universal code system for any application. But real-life healthcare is more complicated.
Let's take medications as an example. There are at least four common coding systems used to identify medications (for a deeper dive, check out our guide on medication codes).
This is where CodeableConcepts come in handy. They anticipate that the same concept (e.g. drug) might have different representations (aka codes) in different systems.
The example below shows how Tylenol would be represented in RxNorm and NDC. Here, the system string lets us know which code system we're using.
However, not all CodeableConcepts map to a standard system. For example, assume that you are using the Communcation.category field to organize messages based on product lines. Since product lines are specific to your company, there won't be a standard code system available. In these cases, you will develop in-house, or local , codes.
For Identifiers, the strategy is simple: each system string should correspond 1:1 with the source system. For instance, a patient ID from a particular hospital should have a system string like https://hospitalname.org/patientId.
When it comes to CodeableConcepts, it gets a bit more complex. Whenever possible, you should use standardized code systems to avoid reinventing the wheel and promote good data hygeine. The FHIR community has defined standard system strings for these code systems.
System strings are your go-to tool for successful healthcare data management. By keeping them clean and consistent, you'll save yourself a lot of confusion and time.
EnSage, is an innovator in healthcare management, improves outcomes for elderly populations in value-based care (VBC) organizations. Their service automates the acquisition of patient data from multiple sources and performs data-driven risk-scoring on each patient. The risk scores then aid the care team in scheduling check ups for the highest risk patients first. It also facilitates sharing these risk profiles with their Primary Care Providers, enabling high fidelity care coordination across institutions.
In this project, EnSage utilized two Medplum solutions.
Custom EHR: A health record application specifically tailored for EnSage practitioners. This provides healthcare professionals with vital data at their fingertips.
Provider Portal and FHIR API: An application for referring physicians to access and contribute to the integrated care management, but ensures they only have access (via API or app) to patients under their care.
EnSage overcame significant technical challenges in this project, including the need to aggregate data from a wide array of sources such as claims data, CMS datasets, and more. Additionally, they required a bespoke workflow that incorporated case management across multiple organizations that necessitated sophisticated access controls.
Medplum stood out due to its out-of-the-box auth service that supports cross-organization access. Its ability to build high-fidelity custom integrations quickly also proved invaluable in overcoming the challenges of collecting and synchronizing data from multiple sources.
The FHIR data model also proved valuable, as a well documented data model supported by EHRs aligned stakeholders quickly.
These factors allowed EnSage to focus on what was most important: their risk scoring algorithms and the clinician experience.
EnSage leveraged a suite of Medplum features to create a comprehensive and efficient solution:
Authorization: by leveraging Medplum sophisticated access control system, the EnSage team was able to expose the Medplum FHIR API directly to client applications and external partners, without the need to encapsulate it behind a gateway / proxy.
FHIR Datastore: All data is stored in FHIR format and is accessible via the FHIR API. This provides a standardized approach to storing and accessing health information.
Subscriptions: In this implementation, in response to questionnaires, subscriptions are triggered, setting off automated workflows like notifications, data synchronization and more.
Scheduling: Integration between Acuity and FHIR Schedule provided a robust solution for managing appointments and optimizing healthcare service delivery.
Charting: A system for documenting encounters, including details like CPT and diagnosis codes, was created. This facilitated a comprehensive and precise record-keeping process.
Open source: The development team used Typescript for the entire stack. The Medplum open source code, issue tracking and community features helped streamline development and speed learning.
Below is an architecture diagram showing how the different components fit together.
In conclusion, Medplum was instrumental in providing the tools and support needed to address the complex challenges faced by EnSage. The result is an efficient, patient-centered system that ensures proactive care for elderly populations in value-based care settings.
Ro, and their diagnostics arm Kit.com enable a sophisticated nationwide diagnostics service, that includes touch points across clinical teams, shipping and logistics, laboratory sites and customer success.
The workflow requires tight coordination and real-time synchronization between many systems and applications.
Codex Health enables health systems manage their patient populations with effective remote patient monitoring (RPM) programs for diabetes, cardiovascular diseases and more.
Their offering has a patient facing experience, a provider experience and EHR integrations with Epic, Cerner and others.
They read and write data from EHRs, and collect data from medical devices like CGM, scales and blood pressure monitors.
Historically, services like Codex would have had to connect to EHRs using some combination of system integrators or HL7 V2 over VPN connections which is painful, brittle and costly.
With the roll out of the Standardized API for Patient and Population Services (g)(10) by major EHR platforms like Epic and Cerner they are able to connect to multiple health systems via REST based FHIR APIs, without third party aggregators or VPN Connections.
(Above) The "old" way of connecting an application to an EHR
(Above) The new (g)(10) based way of connecting an application to an EHR
This standardized interface allows Codex to provide RPM programs with no setup cost.
The (g)(10) API is very powerful, as it has build in support for access controls using SMART-on-FHIR oAuth Scopes, enabling:
Provider Access - allowing Codex physicians and staff to access demographic data, diagnostic reports and notes for patients under their care.
Patient Access - patients can auth in the Codex application and read and write their own data to their record, without need for IT approval.
This scalable approach allows the Codex team to focus on their service, and not on integrations.
Codex uses Medplum as part of their software development cycle, because Medplum is an open source implementation of the (g)(10), and so from a developer perspective is the same as Epic, Cerner or others, but with robust tooling and configurable permissions. This streamlines the Codex's teams software development lifecycle and their testing across platforms and products.
This standardized interface driven approach allows them to deliver their two solutions:
Foresight - an analytics and case management web application for clinicians, that helps them view and manage their patients care
Allie - a patient facing application that runs on iOS and Android that allows patients to view their care plans and take action.
Below is a brief interview with the Codex engineering leadership Zane Silver and Yury Staravoitau, about their EHR integrations the transcript is edited for clarity.
Video - 7 mins 51 seconds
Background (Zane): Let me just give you quick refresher of what we're doing here at Codex.
So we're building a remote patient monitoring platform a software solution as well as professional service on top of that. So we sell directly to healthcare providers or DMEs durable medical equipment manufacturers. And they can use our platform to monitor patients remotely if any diseases we connect over Bluetooth.
We have native (iOS, Android) applications, connects over Bluetooth to various blood glucose meters scales, blood pressure monitors. We also do cloud connections for like Dexcom and Freestyle Libre and other CGM devices. A clinician, either at a hospital system or a doctor or technician, might use our platform to be able to monitor or they can out outsource that to us.
We have a licensed disease educators for heart failure, diabetes that we can monitor the patients for them as well. Our internal educators use the same product that we also sell as a platform to the healthcare providers. We integrate directly with EHR systems for those hospital systems, either being able to read or write results back.
So sometimes blood glucose meter results are required in the EHR system, so we do that. We use Medplum as a testing ground and staging ground to make sure that we can properly read and write as well as be able to pull new types of resources records from the healthcare provider themselves.
At this point, a dozen to, well, half a dozen different types of EHR systems: Meditech, Hilo, Epic, Cerner, and others.
We use a multi-tenant system. And so each multi-tenant itself will have its own set of EHRs that's integrated and they're totally isolated across tenants. We are testing connectivity and correctness and being able to pull in those records there.
EHR systems quickly either throttle or crash. So we, we pull in batches and we kind of basically do periodic syncs and then try to do writes in real time.
Question (Reshma): How does it work end to end?
Yury: A patient, selects Medplum as healthcare provider login using the account. And authentication that we put that in the background request EHR system to, to grab some data for this user and update our database, get the refresh token, and on a daily basis, we request some updates using this user by ID for example.
Zane: We integrate with EHR systems, right? Yeah. So we wanna be able to test against EHR systems. And because Medplum is an EHR system with also write access, we can test whether or not we can write records and be able to see that as well as manually write records outside of our application.
Make sure we were able to read those as well. You can't do that unless you're actually doing it on a real EHR system. And we can, but not all of our customers have partnerships where they actually allow us to be able to test on their production systems.
We're remote patient monitoring, so we get (FHIR) Observations (from the customer EHR).
The big part it's missing in terms of the spec is just callbacks and being able to get asynchronous updates.
So moving from an event based versus a pull based system. The pull based system is like much more scalable operationally for us. So we don't have any kind of third party dependencies.
I think for the most part they (providers) prefer it because there's fewer integration points. They turn on the endpoint and give us, our credentials and they're just ready to go. We don't have to, you know, do any back doors connecting directly to their databases or anything like that.
So observations came as from our applications that can be connected to via some devices or, for example, we have dramatic error device that I testing for my blood, blood glucose. Or it can be from EHR system.
I'm happy to talk or, you know, feel free to put us, you know, connect us to anyone you feel like I might be interested in and we're happy to also help out and share any of our learnings and thoughts too.
Question: Can you do a day in the life for me about when you're talking to the provider and you're engaging their IT to get this kind of access, what the process looks like?
Yeah, it's more of a, I would say like a long engaged relationship in terms of actually getting like the direct access to write and read from systems to system.
Obviously, with ONC and data blocking, we can connect with the provider on our own. We don't coordinate with them to do that in terms of just getting patient consent to read their (FHIR) resources. So that's easy if we do that on our own. And then it just takes a little bit of time and talk to the right stakeholders.
The healthcare provider side, find out who the IT team is, get the right people in there and make sure we go through their security reviews. At that point, basically there's, each of the major healthcare providers have their own app portal. So we create an app portal on there. We usually end up giving the healthcare provider what our app ID is, whether it's, you know, app Orchard on Epic.
Cerner has their own developer portal too. Give that to them and then basically they download the app into their system. I don't have any visibility into what that looks like. There says admins do that. And it's usually like a, it takes about 24 hours for that to happen for them to pull it in and then we get their endpoint and it just seems to work for us on that side.
Reshma: So you download their app, but like they're not using the traditional SMART-on-FHIR kind of app machinery. It's more that. You're now eligible to get the credentials that you need to connect server to server?
Zane: That is true. Yeah. We, we can use it in terms of if SMART-on-FHIR to be able to do our launch and they do have to have, you know, download the app there.
But the (Codex) app type is different. So instead of it's a clinician facing app, which is system facing app. So they, the app store kind of on their part, they (provider) have the dropdown that they choose how they want to install it, and it gets installed in their system.
Seems, seems great and it's a lot more scalable in terms of how you can write your application once.
And you don't have to have a custom footprint or like dedicated boxes or instances for each provider.
Our integration costs are very low, so we don't really even, we don't charge in a new integration or onboarding fees or anything like that for a new customer.
Question (Reshma): Are you continuing to roll it out or working on more of the depth scenarios within systems?
I think it's more of just getting more breadth with more provider systems on there. You know, even just this morning we tested Hilo and Meditech, which are two different EHR systems and just getting verified all those seems to work out of the box quite well, which is nice.
Question (Reshma): So anyone with a (g)(10) right? A (g)(10) FHIR implementation?
Zane: Yep.
Reshma: Awesome. It's a great story. It's a great, great story and all the FHIR enthusiasts would be excited.
Medplum Client Typescript SDK can be used to connect to the EHR in multiple modes, such as Patient access, oAuth and Basic Auth.
For example use the MedplumClient to connect to another FHIR server from a Bot or other application that has the Medplum client as follows (client credentials).
// External EHR Url and credentials const externalEhrBaseUrl ='https://ehr.externalprovider.org/FHIRProxy/api/FHIR/DSTU2/'; const externalClientId ='<client_id>'; const externalClientSecret ='<client_secret>'; // Construct client ant authenticate const externalEhrClient =newMedplumClient({ baseUrl: externalEhrBaseUrl, }); await externalEhrClient.startLogin(externalClientId, externalClientSecret); // Work with the client as needed, for example search await externalEhrClient.searchResources('Patient?identifier:contains=999-47-5984');
MITRE Open Health Solutions is a leader in healthcare open source and are the makers of Inferno, Synthea and more - which are tools we use all the time here.
Medplum gave a talk at MITRE last fall, that was recently released, and this post contains an annotated transcript and clips, as well as some updates as the talk was last fall, shortly after Medplum's public launch. Transcript has been lightly edited for clarity.
Welcome to today's OHS Tech Talk. Today we are very lucky to be joined by Reshma Khilnani, who will be giving a talk titled Medplum FHIR Native Web Apps. Reshma is the CEO at Medplum, which is an open source toolkit for building FHIR native web apps. Reshma has an experience as a Visiting Partner at Y Combinator and as a two-time founder in healthcare. She is also an alumna at Meta, Microsoft, Box and BS and MEng course six at MIT. Reshma will cover the opportunity and challenges in developing apps that use FHIR as their data model. She'll also discuss Medplum business model and how they hope to make a living off of open source.
Today's material will include demos and Medplum getting started tutorial.
Reshma Khilnani
So what is Medplum? Medplum is a open source toolkit to build FHIR native web applications. At the highest level, that's what it is. Before we dive two into the details with a little story about our founding team.
So these are our founders. We myself, Cody, and Rahul, notably you'll notice we have a crossover career. I myself have done venture capital, I was early-ish on the team at Facebook. Cody has a career from Microsoft and he was at One Medical as well on the provider side and, Rahul at Palantir and Applied Intuition, these are enterprise and very machine learning centric organizations and so we're bringing that experience with us to this.
And I'm going to run through the following agenda.
First of all, I'll tell a little bit about our story.
Second pain points from our history of building medical applications.
I'll go through Medplum's approach and how we're thinking about solving the problems that we have experienced in our career.
I'll talk about open source and why we decided to make a commercial open source company and how we think about the opportunity on that front.
Then I'll do some, some demos and we can do Q&A.
Like I mentioned with regards to our team, you know, our endeavor in building Medplum is informed by our experience. First of all, in big tech. Microsoft and Meta (Facebook) and getting a sense of professional software engineering in that environment and that type of infrastructure and quality control. Also, the way web applications are developed at that scale was really informed by our careers in big tech.
This same team built another startup. It was called MedXT, which was a RIS/PACS that was our first endeavor. That was a long time ago. That company was founded in 2012 and was acquired by Box. And then we've also had the opportunity, I myself have worked with a lot of startups. In a time working in venture capital and over the course of my career, and had a chance to work with entrepreneurs who are building applications for the first time, many in healthcare.
We have some experiences in enterprise as MedXT was acquired by Box and we worked with large enterprise customers to implement their healthcare and life sciences workflows. And Cody was a senior director of engineering at One Medical, which is a primary care company that was acquired by Amazon and has a lot of they were real leaders in providing this primary care experience that's accessible and friendly. There were a lot of learnings from building the infrastructure for that company. I was a Visiting Group Partner at Y Combinator, and notable in there I had opportunity to work with a lot of commercial open source companies and learn a lot about why they make sense and how they can help in delivering software in a new way by helping people develop their applications. So that's where we're coming from.
Our experience is also informed by building many applications that are in the healthcare context, I'll include a LIS/LIMS, RIS/PACS, custom EHRs, patient portals, all as examples of medical applications.
We experience the following pain points. I think there first we'll call it the terrible choice, so I'll go into this in a bit of detail, but basically while developing your application, you have to make some trade-offs and it's, it's possible to leave with the impression that, you know, you don't have any good choices.
So integrations and workflow in healthcare are very difficult, harder, I believe, than other sectors like FinTech to build and maintain. So this is a common problem. And the regulated environment is part of it. The vendor mix is part of it, but in general, this is just an extremely challenging aspect of developing healthcare.
Third. And I'm very interested to hear from this team in particular on this front is poor data quality is rampant. Duplication issues, you can't compare records that exist in different institutions. There's lots of subtle issues with the data that make it hard to trust and if you're writing an application and you want it to have good quality data, for example, to report HEDIS or something like that, this is often an enormous lift for developers.
So this is a, it's a big problem. And fourth, which I think is related to the first three, is that talent is very scarce. If, you know, it's tempting to think of software engineers as a monolith and there's a labor pool. But really healthcare has its own domain specific nature, and the intersection of those who are software engineers and who are trained in the specifics of the domain is rare.
And in order to build an application, you often have a lot of people who are not trained in healthcare I'm often find myself in the position of telling them to please just use FHIR instead of, create a new patient table create table, patient, patient ID equals X, you know this is a common pattern.
And then the nature of the workforce. Having so many people who are working in the domain who do not have healthcare experience just has a shape to it that's challenging to work with. So those, those are the high level on the pain points. So first let me talk about the terrible choice.
Basically consider, say you're company like One Medical, you're a provider. You have a terrible choice. You can build a great tailored experience, but roll all of your own infrastructure or you can use off the shelf products and fight with experience. So this is a common choice that people have to make and it's easy to be frustrated with this choice.
If you want your great tailored experience, think about how much work you have to do to build up your certifications, interop and workflows. But if you use the off the shelf product, it's very rigid, so you're stuffing data where it's not meant to be, or you're doing unnatural things to get your system to behave the way you want.
This is a common experience that people have been having with developing these apps for years. And what's notable to me is that other domains have made more, let, for example, FinTech or insurance technology have a better story in this regard than I've seen in healthcare. And that is part of the opportunity that they don't have in those other domains the same terrible choice in the same way that we see in healthcare.
Healthcare is harder. Developer productivity and velocity is slower. And sometimes talented engineers choose to work in other sectors. So this is a, this is a pain point and things that we thought about hard when we decided to start Medplum.
So that leads me to the next part, which is our approach, how we've thought about at least chipping away at some of these problems. And I mean, the problems are very hard. I will never want to give people the impression that they will be overcome instantly. But, Medplum is a first step towards addressing some of these problems that we see day to day.
And the approach is simple. The API is the product. Tery headless product that is interop-ready and features that are designed to be programmed.
Here's an overview of the system: the core Medplum application, then this is an open source application, is right here in purple and this is a source code that you can get on. Internet. It has a data store, FHIR data store, and a FHIR Rest API. And so that's a big part of it.
We've invested heavily in the TypeScript SDK. And most of our customers and people who are developing on the platform, they're really here. They're writing a white label application on a custom domain, so it's like my healthcareapp.com, and they're embedding our SDK. Now, what's notable about this developer paradigm is that.
Right here, this gray box that's running their website is a static JavaScript file. This has no backend and it's meant to be very easy for back to our, the discussion on the labor and labor shortage for somebody who is you know, has a light education in healthcare or they're from a different domain, but they know how to develop apps to help them get productive very quickly.
And they don't have to think about the complexities of the data model, and the auth and all that stuff. They can just focus on the experience that they really care about that's important to them. Notably is that integrations are very important to any healthcare application.
And we think of, integrations are the product so that this is crucial. And we have our infrastructure here called bots. You can think of these as like lambdas, you know for example, if you create a new patient, You can invoke one of these lambdas to synchronize that data to a legacy EHR, either via FHIR, HL7.
We support a bunch of data types and we have a streamlined developer kit so that, again one of these developers who don't have a lot of history or training in the domain can be very productive very quickly using this technique. So, and these, we provide the environment, which in which to develop these, and then all the tooling so that you can run them.
So there's really no DevOps from the perspective of the developer. They're just writing their code and hooking it up. And this is a big productivity win. And people bring their own code here. We have some partners who have written their own integrations and we also provide some built-in integrations.
So that's part of the customer experience. We also have access policies and identity, literacy in general on FHIR and SMART-on-FHIR is growing, and we're part of the message there helping people understand how to use these tools and the scopes and the auth part of what we provide as well.
And we just have a built-in implementation as well as allowing people to bring their own auth if that's what they want as a developer. And then subscriptions, you can think of these as webhooks, you know allow event driven applications to be built, and I'll show some examples of those in the demo.
So this is, this is the Medplum overview. And I'll just like compare and contrast that with traditional software healthcare software, which is like a full stack SaaS application that exposes some interfaces. In this model, it's hard to program a system like this. The developer experiences is poor.
Systems that we've built like this tend to be brittle and slow, and introp is an afterthought. So we, want to think about how to do this a bit differently from the traditional way. We believe that, assume we are, go back to this view. Like all of the applications, like a LIS/LIMS or a custom EHR or patient facing apps, EDC can all be built in this simplified way.
And it could be an effective developer model to get more productivity, leverage, better interop, and just reduce the investment overall and have better tooling and story. So that's kind of the thinking. So I'll summarize it here. So our approach, you know, interoperability is the product not an afterthought.
So the, I'll emphasize that. It's very common to have a SaaS app with an API software as a service, by the way, app with an API to support interop. That generally is not the same as having a headless and dev tools centric focus, and we really live that difference. The programability of the system is what we focus on and You'll notice that our ui, they, they look very bare bones because we're really focused on the programability.
And we hope for a lot of attention to detail on the developer experience. We consider testing and test-driven development, CI/CD and documentation as products. And there are things that we deliver and part of our offering and of course our open source. Open source has a lot of interesting characteristics that are unexpected.
I'll put an example here. We see people, our customers searching our repo all the time. How do I search for resources? Oh, here's an example. And they're just searching in the code for examples for how to implement their own applications and workflow. And it's, a way to help people do a complex implementation without having to build the full stack SaaS app and then hand it to them.
So that's, that's the thinking. And we didn't, we didn't make this up like GitLab, Hashicorp, Vercel, Supabase. These are examples of companies who are doing this in other domains. So GitLab does DevOps and Hashicorp also is on, on the infrastructure side, infrastructure as code. And they're, really focusing on the developer as being their advocate and their own audience that they're trying to reach.
So I'll talk a bit about open source and how we think about it. So why open source? That's question. We believe we know that open source enables developer productivity and velocity.
If you are composing complicated systems to implement an application that's very functional, that has to do a lot of things and support lots of features enable to do that effectively. Open source is just a great tool. It's a way for an individual contributor to make a lot of progress without being gummed up with a lot of meetings and compliance and access issues. It's way for devs to also learn about how to do an implementation and a way to build trust.
So once, assuming a developer is our audience and people who we think about as users of the product, we want them to trust it. We want them to think about how to solve their problems, using us as a reference. So that's the thinking. And again, we didn't, make this up, GitLab, Hashicorp, Vercel, Supabase. They, really have a lot of mindshare on this, in other domains.
We are early in our open source life, so I'm really excited for the chance to meet you all and to have your, your thoughts and feedback and engagement as part of this community. But we, you know, we publicly launched in September around 190 GitHub stars, if that's a metric that people care about. We're, just getting started 13 contributors and around 80 in in our discord, and we just released our v1. So we're like you know, in the stage of having, we do have some definitely implementations on the platform and are working to move past the early adopters in this coming year and have some more established players.
Updated stats as of April 14, 2023 - 622 Github Stars, 25 Contributors, 261 in Discord
So, That's where we are so far and our business model. So we're really focused on hosting and we have our hosted product app.medplum.com where you can sign up, start building your application, and it provides that backend that you know is fully working and easy to. And if you're a developer who wants to get started quickly, then it's a great option.
Then, you know, usually what we think of how we think about deployments is that you kind of decouple them into two parts. So one is the developers, Who want to build the app and they, build their applications the mostly front end applications or integrations. And then once they've made a significant amount of progress, the organization that they're a part of can make a decision.
Do we wanna go self-hosted and, install in our own environment or do we want to use the cloud offering? So we have invested in, SOC II Type 2 certification, HIPAA compliance, and ONC certification. So we're going to really show our work on the compliance side as a way to have people think about using the hosted option.
And again, this is a model that is, is modeled after GitLab and their very successful at doing this in the DevOps world.
I'll show our storybook, which is our react components
Demo of our documentation because as I mentioned documentation is a big part of the product.
I think as a developer developing in this space, the number of times I had to contact someone to even get a copy of the docs makes me irritated. So first of all, admin console. So this is our admin console. You can see here it's app.medplum.com, and this is a, developer-centric view of your FHIR data.
We have a list of the resources here on the side and you can just browse your resources. As I'm talking to the folks who work on Synthea, this is largely Synthea Data and. You can add your fields to your list can filter.
And the reason this is potentially interesting is that people are using this in the following way. They are actually learning how to program FHIR This. They go to their work list and they look at their dev tools here and let's see, fetch, they're like copy as curl. So they're learning how to construct their FHIR queries.
And other things this way. It's a great tool for teaching and it's a great way to explore your data. And I'll go into that in a sec. So here's my Synthea data. You can see this is, you know, it's not super beautiful, but it's very functional from a developer perspective. You can see all the linked resources that are linked to this patient.
You can, if you do the same, inspect and copy as curl. You can view the queries to query all the resources related to the patient. Let's see. These are all FHIR objects, so you can, you know, look at 'em, browse 'em, and then this is generated from the FHIR spec. So this is just a very good debugging tool where you can see all the fields.
Great. You can touch them up if you need to. This is common when doing a deployment. Just add your identifiers, for example, or change address. If you don't yet have an app that's fully functioning, you can see the history started by Synthea. And blame. So if you're running a deployment, it's very often that you wanna be, who changed this data. So this is a great tool for that. JSON representation. And then there's this concept of apps basically if you have. Questionnaires that are linked to this, to the patient object, then you can just link them here. They are automatically linked here. So that's a example. So yeah, that this is, this is the admin console.
It's very powerful. It helps. The developer have like an on-ramp into FHIR that you know, for a novice developer it can be pretty intimidating. For this crew, I'll show the batch upload like. I, I think one of the top search items on our website is Synthea. People generate their Synthea, or use Synthea from files from GitHub and just upload them here or paste them as JSON here and then, use that to quick start and prototype their application.
I would invite all of you all who, if you're making demos or you want to have a little environment to share with people, That would be, you know, we would love to have you use the free offering. That would be great. And we'd really like that. We support all of the resources. We just have like some, this account just has these ones configured, but you can change your user profile to have the quick links that you want.
And there's a lot of administrative tools to, to help you get started. One thing I'll note here. Is that there's this concept of bots that we talked about. So if you have a bot, this is basically like it's code, that executes. For example, in this example if a patient fills out a questionnaire and you have a questionnaire response and you want to like compute some in this case, this is the SDOH, I think social determinants of health.
Then you can use, build out your scoring function and if you want to write it as an observation, you can implement a lightweight workflow here. This is just a very common thing and the bots have, you know, different flavors. There's integration bots synchronizing to insurance, you know this is what a lot of the developers on the platform are.
I'll go briefly into the questionnaire as well, because a lot of developers, they are focused on the patient experience or the provider experience, but the, they're setting up their questionnaires and stuff in the admin tool and this is a, Google forms type experience for your FHIR questionnaire.
So here's the builder can, wow, this one's really big add item. You can change, the display can change go through a bunch of different. Editing and it's, this is just, a way to build it. It just ends up being, your FHIR questionnaire object and you have the history and the, and the blame, et cetera, just like the other resources.
And then you can preview what it will look like. And this is not very impressive in and of itself, except that this, you can, you can use. Form and embed it in your application. So that's, the real use case. And people are tagging them with their various ontologies.
I don't have a good one here right now, but like, you know, where, where did this form come from? What ontologies is it tagged with? That's very useful generally for getting your, your workflow to work, right. I. Okay. Let's see. So once you have all of these like resources in place your questionnaires, your integrations, and you can start building a more powerful app.
So I'll show you kind of in context. So this is foomedical.com. All this is also an open source application. If you go to foomedical.com and just look at the footer, you can get to the documentation and stuff and you can log in. It's a sample. It's not a real healthcare practice, but you can have like a very cool patient portal that looks white label.
That's all FHIR native. And these are FHIR resources. I'll show you some examples here. Here's the lab result. Medications. It's a medication object. Vaccinations, vitals, blood pressure. This is based off of Synthea Data by the way, but and kind of body temperature. You can add measurements if you want.
And this is the core data model. All, the data for this is living on app.medplum.com. Foomedical is a static JavaScript site. It's a streamlined developer experience for a novice. Care plans, checklist. There's a lot of discussion in the community on how to, represent care plans and I'm curious on this team's perspective as well, but also get care, you know this is just a FHIR schedule with slots.
Questionnaires, but these are composing all of the things that you've set up in your app, in your admin console into an experience that's sensible for the users. And it has, you know a lot of other, FHIR resources. I think this example uses like 40 or 50 different type of resources in order to get this experience.
But it absolutely can be supported. We have a alpha version of the Foo Medical provider as well, which is like a very simple EHR. I won't go to this in depth, but you can, you can kind of see very similarly. This is the, questionnaire object, which. Is actually comes, you know, that we saw previously here in the admin console.
So, and this is just a FHIR questionnaire object, so this is kind of helps people administer their practice in a more effective way. Let's see. So patient portal, sample custom EHR. I want to save time for questions, so I'm just gonna blitz through the rest of these. But we have our storybook here online, which is just our React components.
These React components. Map generally to FHIR objects or FHIR data types. I'll, I'm showing like the diagnostic report display here because one of our claims to fame is that one of our customers has built a LIS/LIMS, which has been certified by CLIA/CAP, on top of Medplum. And they use this diagnostic report display, which the CAP inspector has looked at, and you can see the code.
This is just a, you know, diagnostic report we have if you search in our, our repos for this, you can see the object. So it's, it's got a lot of tools to help, you know, smooth the onboarding for the, for the users and for the developers. And then finally, the storybook, I think is one of the top things that developers are looking at in order to help build their applications more effectively.
Finally, I'll move on to the documentation. So we invest a lot in our docs and we absolutely, we want feedback. So if anybody is just looks at the docs, they find something they don't. File a GitHub issue. We're happy to talk about it. It's the subject matter for, and the subject matter is very dense.
So like, it's a, it is a tough job to really document it in a way that makes sense for users, but we are working on it. One thing I'll point out here is that we have sophisticated search. As very popular. And so like, oh, how do I invite a user? Okay, great. Or, you know, I want to look at observation.
And documentation is all in GitHub, so if you ever wanted to contribute to, to documentation, write some tutorials we would absolutely welcome that. And this is part of our open source project, so again, can just go there. Great. And I think you know, we have our, our core repo and would have our, our lots of tooling and build associated with it.
Let me see if I can find, okay, so one thing I will note here is we have like a pretty sophisticated build system, which is all publicly available and it has code scanning and actually probably the best way to see it and I'm also interested to talk to this group about is we have our build of course, Which includes a lot of code coverage and, and important things like that, code analysis.
And if there was like testing tools made. By MITRE and other groups that could be incorporated into a build. We think that that would be really high value. For example, like just be able to test your conformance or ontologies or terminology. The, all of those things would be just very helpful and we hope to you know, bend your ear on it or have the opportunity to at some point.
Data privacy, locality, governance and compliance are huge issues in healthcare, and that's why we at Medplum support self-hosting. For those running on AWS, we use Aurora RDS, which supports auto-scaling. A common question we get is - how big is my database going to be?
tip
Medplum offers a hosted offering as well as self-hosted. Instructions to register can be found in our docs.
Say for example, you have 1M active patients annually - how does that translate to database size?
Unfortunately, there is no straightforward answer to that question, but the right way to think about it is to make a FHIR resource count estimate, per patient, annually. Applications with a lot of messaging and observation data are generally more resource intensive, while those that have visit notes and prescriptions are generally less resource intensive.
Here's an example of a resource projection.
Resource Type
Count per Patient
Total Count (M)
Avg. Size / Resource (kb)
Avg. History Length
Total Storage (GB)
Patients
__
1
5
10.0
52.5
Encounters
10
10
2
2.0
42.0
Coverage
1
1
2
2.0
4.2
DiagnosticReport
10
10
2
2.0
42.0
Observation
15
15
2
2.0
62.9
MedicationRequest
10
10
2
2.0
42.0
Media
15
15
2
2.0
62.9
Average History Length (column 5) refers to the number of times the resource is edited, as changes are tracked, historical data will increase storage size.
To calculate the total storage, we use an "overhead factor" (representing metadata, indexes, etc) of 10%. The following formula shows how to estimate column 6 - Total Storage
We are excited to hear about the release of Fast Healthcare Interoperability Resources (FHIR) R5, the latest version of the healthcare data interoperability standard. This new version builds on the previous versions of FHIR and incorporates new features and improvements to further support healthcare data exchange and interoperability.
FHIR R5 includes enhancements to the FHIR specification, including additional resources, improved support for clinical workflows, and improved alignment with other healthcare data standards. The new version also includes updates to the FHIR conformance framework, which helps ensure that FHIR implementations are interoperable with each other.
In the future, we will upgrade our service to support FHIR R5 side by side with R4. This includes ensuring that our solutions comply with the latest FHIR R5 specifications and testing our products for interoperability with other FHIR R5-compliant systems.
We will do this while maintaining our support for FHIR R4 - which most of our customers rely on today. We will use our Bot framework, TypeScript SDK and validation tools to help our customers implement the version of the spec that best suits their business needs.
We are excited about the potential of FHIR R5 to improve interoperability and enable better healthcare outcomes for patients. We continue to closely monitor industry adoption and compliance requirements and will strive to provide our customers with the most up-to-date solutions to meet their interoperability needs.
Thank you for your continued support, and we look forward to sharing more updates with you soon. If you are interested in updates related to FHIR R5, please reach out at hello@medplum.com.
(A beautiful pediatric growth chart)
(Intuitive patient intake)
(Scheduling orders)
(Even the billing experience shows attention to detail)
