This article aims to share a bit of our experience developing healthcare solutions using Medplum. It will provide an overview of the platform and cover some technical aspects of building products with it.
** Disclaimer ** Medplum is a client of Vinta; however, the opinions expressed in this article are based on our experience building products for our clients with their product. Vinta does not receive any direct or indirect financial incentives for recommending Medplum.
What is Medplum?
Medplum is an open-source end-to-end framework for building and hosting healthcare applications. Effectively, it can be used as a headless EHR, or as the full-stack health tech platform for patient or provider-facing solutions.
It combines a database designed for healthcare applications, the APIs to store and retrieve data, and a full-featured frontend SDK with not only helper methods to interact with the backend but also React components to render and manage resources.
To fully understand how Medplum works you need to understand what FHIR is. FHIR stands for Fast Healthcare Interoperability Resources and it's a standard for computer systems to exchange healthcare information. It defines an API that enables systems to talk to each other and share data regardless of how it's stored.
Notice how FHIR only defines the communication layer of applications, one of Medplum's advantages is that it expands on that concept by also storing the data in the database using the FHIR format.
Applications built on Medplum are FHIR-native. Every resource you interact with and all API calls you make to your application are shaped according to the FHIR standard.
Building with Medplum
As a developer, the first key benefit of building with Medplum is how easy it is to get started. Healthcare is a highly regulated industry (as it should be) with a lot of specificities and jargon, which can be a big barrier for newcomers. Medplum breaks that barrier by giving you a production-ready backend with all the resources and relationships that kind of application needs.
You don't need to spend months discussing and defining how to model the application. Pretty much everything you can possibly need in a healthcare system is already modeled according to the industry standard and available to use.
Your job is to learn how to properly fit the data of the application you are building into that existing structure. Starting an application with all of that out of the way is a competitive advantage to any team and, as a developer, it's reassuring to know that you are backed by industry experts.
Another benefit of Medplum is that it's built with developers in mind. Starting from the fact that it's open-source so all the code is available at GitHub for you to inspect and understand how it works. They also provide many example applications that can be customized to kick off new projects.
The built-in React library is super useful and it allows building UI components that are common in healthcare applications with very little code. It's also easy to find and reuse components in their library by browsing their storybook page.
Even if you don't want to use their component library, Medplum also provides both a REST and a GraphQL API that will make developing your custom frontend in React or any other tool of choice as smooth as it can be. Their SDK feels modern and using the built-in client to make requests is super easy.
The frontend SDK is built with TypeScript which makes development feel super productive. Because everything is annotated with types, by using any modern code editor it becomes easy to inspect objects and to learn how methods work and what parameters they expect. Working with this kind of state-of-the-art tool reduces the need for consulting docs and constant trips to the browser to search for how to make things work.
And speaking on docs, that's yet another area where Medplum shines. Even if you are not going to use Medplum to build your application, their documentation is still an excellent tool to learn and consult about FHIR resources.
Custom requests and background processing
While it's possible to build a Medplum application just using the frontend SDK, most applications will require some level of processing that needs to happen in the backend.
Things like:
- ensuring changes to multiple resources happen in a single API call;
- triggering batch operations;
- running background tasks;
- or reacting to changes in a certain resource.
To handle these scenarios Medplum uses the concept of Bots. They are a special type of resource that can be programmed using TypeScript. They can be triggered either by an explicit call from the front-end, where you can pass arguments just like in any call to an API, or via a Subscription.
Subscriptions are another special kind of resource that can listen to events such as the creation, edition, or deletion of other resources. Once they are linked to a Bot, every time a certain criteria is met the Subscription will trigger the execution of that Bot passing the appropriate resource that needs to be processed.
Common examples where Bots can be used include:
- processing a questionnaire data, such as an intake form;
- updating the patient's profile accordingly;
- checking doctor's schedule to find available slots to book an appointment.
Bots are similar to AWS Lambda functions in that you can focus on writing the code while the platform handles everything else related to managing and running them. They bridge the gap between the frontend and custom backend code without the need to deploy a separate application just for that.
Deploying a Bot is simple and it's easy to write automated tests for them so you can ensure things are working as expected before making changes to your production environment.
Hosting and compliance
Because Medplum is open-source it allows companies to self-host the application in their infrastructure. While this is desirable in certain situations it has some downsides. Healthcare information is sensitive, especially when compared with applications from other industries, so extra care should be taken on where and how to store user data.
In some jurisdictions, healthcare applications must be certified in order to operate and special data management and storage requirements might be needed to comply with local laws. If you don't have a dedicated team with experience in that kind of environment it can be extremely risky (and costly) for your business to do it in-house.
With that in mind, it's safe to say that for most companies, especially the ones that are still finding market fit, it's better to leverage Medplum's hosting infrastructure. Continuously deploying and maintaining an application can be a time-consuming activity so being able to delegate it to a partner and allowing the development team to focus on building new features and supporting customers is a worthwhile investment.
On top of that, building compliance and getting certified is no easy job and yet another focus and productivity drain. By using Medplum's managed service you get a lot of that out of box included in the package.
Conclusion
Our experience building products with Medplum's platform has been excellent so far. We've been able to reliably deliver features and products fast for our customers without compromising the safety and compliance healthcare applications require.
We can also attest to the productivity gains of having a full-featured FHIR native backend at our disposal with no effort from the development team and the modern tools Medplum provides. We are looking forward to the platform to keep evolving, enabling us to build better healthcare products and unlocking even more productivity for developers.