Rahul Agarwal is COO at Medplum, an open source healthcare developer platform. I asked him specific questions about Medplum’s FHIR servers and I asked him his thoughts on FHIR in general.
1. FHIR adoption in the US is far greater than in other countries, most likely due to regulation. What sort of companies and organizations are using Medplum FHIR servers, and how fast is that use growing?
Most of our customers aren’t coming to us looking for a FHIR-server. Rather, they’re looking for a backend solution for building a custom EHR, clinical workflow, or improved patient experience.
In that way, FHIR is a means to an end. Organizations want a standards-based data schema that will grow with their organization while remaining compliant.
We’ve seen consistent, steady growth amongst three main groups:
- Digital Health Providers who want don’t want to reinvent the wheel, or be locked into a monolithic EHR
- Traditional Health Care Systems looking for non-traditional interop workflows (e.g connectivity to multiple rural clinics)
- Software companies building custom solutions for specific medical specialties, value-based care and more.
Some customers have made videos of their implementations, you can see some videos on our case studies page.
2. Not all FHIR servers implement all features. How does Medplum handle these three features of FHIR: Subscriptions, composite search parameters and Patient $everything?
We’re continually iterating towards full specification compliance, and our approach to feature implementation is community-driven. We prioritize enhancements based on the needs and feedback of our customers and open-source community.
Subscriptions: We offer robust support for Subscriptions using both Webhook and WebSocket protocols.
Composite Search Parameters: Currently, we do not support Composite Search Parameters. However, we recognize the potential value of this feature and are highly receptive to incorporating it based on feedback from our user community.
Patient $everything: We fully support the Patient $everything operation as part of our ONC certification, including pagination.
3. Support for FHIR operations varies by server provider. Talk a little about the operations that Medplum handles and doesn’t handle. For example, ValueSet $expand and the elusive Patient $match operation. And do users have the ability to add operations not supported?
Out of the box, we handle:
- ValueSet $expand: we invested a lot of energy recently into implementing a performant terminology service. Many developers want a fast autocomplete and validation from major code systems
- $graphQL: The popularity of our GraphQL search feature has exceeded our expectations, especially amongst front-end developers
- Group $export
- PlanDefinition $apply
We also offer our Medplum Bots framework, which allows developers to write their own custom operations that we can host on the server.
Because patient matching can have a number of use-case specific edge cases or business logic, we chose to implement as a set of open-source Bots, based on the Patient $match specification, that implementers can clone and modify for their use case.
4. Performance can be an issue for FHIR servers. Some servers do not fully support certain features because of the performance hit they would entail — examples are _include and _revInclude result truncation. How does Medplum handle this and do you see a trade off between speed and the features on offer?
Medplum is unique in that we’re used as a live backend for web and mobile applications, at a scale of over a million patients in some instances, so performance is a key priority for us. We are committed to optimizing query response times for our users to build real-time, responsive applications.
Additionally, Medplum supports multi-tenancy with a robust isolation model through our Project Model, and we need to ensure that one tenant’s workload does not impact the performance experienced by others.
To maintain performance of FHIR features like _include, _revinclude, and chained searches, we do implement some constraints on these features, such as limiting the depth of chaining. Specifically for chained search, we’ve also developed optimizations that reduce join complexity.
We continuously refine our performance strategies based on feedback from our community, as well as from our own alerting and benchmarks.
5. If you were advising a business looking for a FHIR server provider, what three things would you tell them to ask a potential provider about?
- “What is my protection against vendor lock-in?” While FHIR is an open standard, not every platform is an open platform that doesn’t lock you in down the line.
- “What are the server’s extensibility and integration capabilities?” In healthcare, interoperability is crucial. Check if the server provides HL7v2 integration, and connections to external APIs for e-prescribe, RCM, etc.
- “What does your user ecosystem look like?” The FHIR user community can often be the best source of support and best practices. Pick a server that has a strong user community that is solving the same problems as you are.
6. Looking at competing FHIR servers, what do you feel Medplum does better than the competition?
- Open Source & Open Registration: Medplum made the decision early on to make the platform open-source. This has been a great boon to our users, who frequently contribute back to the platform or provide feedback. We also support open registration, so developers can try the platform out before ever talking to a sales person. This open approach has been very successful for us, and sets us apart from other vendors who are much less transparent about their capabilities.
- One-stop-shop: Medplum distinguishes itself as a comprehensive platform for healthcare application development. We provide a one-stop shop that includes not just FHIR storage and search, but also essential tools such as authentication, access controls, audit logging, bots, front-end components, and integration tools—everything necessary for creating a standards-based healthcare application.
- Developer Experience: Our focus on the developer experience sets us apart as the most developer-friendly platform in healthcare. We support developers with CLI tools, unit testing integrations, front-end tooling, and type generation, making development a joy rather than a struggle.
7. When it comes to access control, Smart-on-FHIR can be insufficient for real-world applications. Does Medplum offer extra features to help with this? Examples might be element level access control or anonymization.
In addition to SMART-on-FHIR, Medplum implements our custom access control framework using a custom AccessPolicy resource type. This framework allows precise control over data access at both resource and element levels.
Key features include:
- Resource-Level Controls: Define specific resources as read-only
- Element-Level Controls: Set individual elements within a resource to be read-only or hidden.
- Search Criteria Restrictions: Apply access limitations based on search parameters or compartments
- Write Constraints: Disallow certain modifications to resources, using FHIRPath expressions
- Access Policy Templates: Employ templates that support variable substitution for flexible policy implementation.
- IP Restriction: Create allow/block lists of IP addresses for access
We’ve seen great success with this model in practice. Some example scenarios:
- Family Medicine: Enable parents to access their own and their children’s records.
- Multi-Center Practices: Allows physicians to see patient records only from their assigned centers.
- Care Navigation: Protects sensitive patient health information (PHI) from non-clinicians while allowing access to personally identifiable information (PII) such as contact info.
8. Apps that use FHIR often have a need to store data that does not fit into the FHIR standard. Is there a way to store this ‘extra’ data in Medplum FHIR servers? And if not, do you recommend certain approaches to your users?
This is a nuanced question that comes up a lot, especially with digital health companies that combine e-commerce, CRM, and EHR requirements. As with all FHIR servers, we do support extensions. However, we do not support custom resource types or search parameters.
Our guidance is that FHIR should be used for all data related to the care delivery or administration process, including charting, labs, medication workforce management, care navigation, RCM, etc.
Data that is purely “e-commerce” in nature (such as promotions, discounts, etc.) typically makes sense in a separate system, with links through FHIR identifiers.
9. As a FHIR server provider, what were the most difficult parts of FHIR for your team to implement?
Our team has actually thoroughly enjoyed implementing the FHIR spec. It is well written, detailed, and extremely thorough. One of Medplum’s unique implementation details is that everything is derived from the FHIR spec – type definitions, database tables, access controls, logging, etc. It is a great testament to the brilliance of the FHIR spec authors.
Implementing FHIR search has been an ongoing challenge. It requires understanding the intricacies of FHIR search parameters and FHIRPath, all while balancing the needs of system performance.
Despite those challenges, the advantages have been immense. A clear detailed spec is a huge gift to our customers and partners, because the system behavior is well defined.
10. If you were redesigning FHIR today, which features would you leave out or force a re-think on?
- More JSON-Friendly Structures: Simplifying the structures to be more JSON-friendly (such as key-value pairs instead of lists) would enhance usability and integration with modern web technologies.
- Expanded Modeling/Guidance around transportation and supply chain: Post COVID-19, we’ve seen a dramatic increase in the amount of care happening outside the clinic. Developing more comprehensive modeling for supply chain and logistics of clinical guidance would really help broaden FHIR’s applicability.
- Consolidation of Medication Resources: Reducing the fragmentation among medication-related resources (MedicationKnowledge, Medication, MedicinalProduct) would reduce the FHIR learning curve and make it easier for developers to adopt.
We carefully track the innovations in FHIR R5. It is clear that the FHIR spec authors care deeply about the success of the ecosystem, and they’re making the necessary choices to continuously improve FHIR.
---