Skip to main content

Awell - clinical workflow automation on Medplum

· 3 min read
Nick Hellemans
Head of Product, Awell

Awell is a low-code platform designed to enable your clinical teams to design, operate and continuously improve your care flows with minimal engineering lift.

Awell works seamlessly with Medplum to build and operate careflows. Connecting Medplum to your Awell care flows opens up limitless possibilities for automating, standardizing and coordinating care such as:

  • Patient onboarding
  • Send pre-consultation questionnaire to patient based on consultation date
  • Send an automated charting note to Medplum based on a form filled in by a patient/care team member
  • Send automated chat messages via Medplum to patients based on input in the care flow (e.g. “Your consultation data is scheduled for 9 November at 3:30 PM ET, please don’t forget to list your medication before the consultation using this form)
  • Automated follow-up
  • Task coordination for care team members, and more.


Are your clinical and product experts spending time mapping care flows in Miro or Lucidchart? Writing protocols in Google docs? If so, you’re having challenges with one or both of the following:

  • Some of these flows live on as Google docs, PDFs & Flowchart and are used as such in clinical practice, resulting in operational inefficiencies and potential clinical errors.
  • Some flows are hard-coded in patient and care team apps by the engineering team, resulting in slow time to market and a low ability to iterate.
  • Clinical operations need to quickly build and test operational workflows quickly, in an environment where engineering resources are limited. They need a tool to visualize their workflow as well.

That’s where Awell comes in, to enable clinicians with a no-code tool that’s intuitive but flexible enough to enable even complex care. As we all know clinicians have limited time, and robust and auditable automations can really help them with their workflow.


Awell authoring tool and Medplum record system together allow for a usable and powerful workflow experience with the following features:

  • Start an Awell care flow based on events (FHIR subscriptions) received from Medplum
  • Get data from Medplum into Awell care flows to enrich your flows and use the data in conditional logic, personalized reporting, risk score calculations etc
  • Push data back or perform actions in Medplum triggered by an Awell care flow.
  • Standards compliant FHIR data stored and managed on Medplum, and consumable via API or in the provider application.
  • Highly auditable workflow with change history and audit logging available.


Supporting Stanford Biodesign OpenCareHub

· One min read
Reshma Khilnani
CEO, Medplum

Medplum is a community, and advocacy for standards and open source implementations are core to our mission. I’m writing today to share Medplum’s support for Stanford Biodesign OpenCareHub’s proposal for ARPA-H PARADIGM.

There are three things that make this proposal noteworthy.

  • ARPA-H PARADIGM is a government initiative, whose mission to improve access to healthcare in rural communities
  • OpenCareHub will open source their implementation
  • The initiative is led by an interdisciplinary (clinical/technical) team out of Stanford Biodesign, Dr. Oliver Aalami and Dr. Paul Schmiedmayer

We would like to encourage those in the Medplum community to reach out if you need a letter of support for your engagement with government agencies like ARPA-H, NIH, CMS, FDA and more. Contact us at

We wrote a letter of support for the OpenCareHub team. Good luck!

OpenCareHub Letter

Chamber Cardio - case study

· 6 min read
Andrew Dilling
Head of Product, Chamber Cardio

Chamber Cardio, a technology-enabled cardiology solution, helps enable and empower cardiologists and practices in their transition to value-based care. With our cloud-based technology platform, we offer a suite of tools designed specifically for cardiovascular care. These tools provide real-time insights, analytics and care coordination tools focused on improving outcomes for patients with chronic cardiovascular conditions.

Chamber’s products serve as a compliment to a cardiology practice’s existing Electronic Health Records (EHR) and Practice Management Systems offering many powerful features, such as quality measure and care gap assessment, customizable population-level patient dashboards and hospital encounter notifications, clinical pathway workflows (including guideline-directed medication support), automated risk assessments and care team collaboration through secure messaging and task management.

To reduce engineering lift and accelerate development, the clinical and operational front-end for internal care team management was built using the Retool Enterprise Platform self-hosted in Chamber’s AWS cloud environment integrated directly with Medplum for the backend data storage and web services layer.


In the early stages of product development, the Chamber team, with limited time and technical resources, sought out creative solutions to help accelerate product delivery without sacrificing the quality or capabilities in scope for our MVP milestones. We initially prioritized the development of our core data integration pipeline (including EHR, ADT feeds, claims, etc.) and a foundation for internal tooling to properly support clinical and operational workflows.

The complexity of internal care coordination and practice management requirements, including integrated clinical guidelines, medication titration support, disease-specific risk assessments, and quality measure reporting, elevated the challenge. We also had to manage and normalize diverse datasets and terminology standards. As a seed-funded startup with just two software engineers, finding the right mix of custom-built and off-the-shelf solutions was critical to building a strong, secure foundation for the product, capable of supporting future growth.


Chamber decided to tackle the challenge of managing key data workflows and operational tooling by leveraging Retool as the backbone for our internal platform. Retool's platform, known for its comprehensive frontend components and ease of data integration, enabled Chamber's team to effortlessly link our FHIR datastore, supported by Medplum, with clinical and scheduling information. This approach allowed for a development of a wide range of care management and operational applications with minimal custom development.

The Retool client, deployed in AWS, connects to Medplum directly, using both API protocols (REST and GraphQL). This configuration provided a flexible and robust environment for Chamber’s internal requirements, and, given the compliance offering (SOC 2, HIPAA, ONC, etc) from Medplum built into the platform, our team could devote more resources to developing a reliable data pipeline and a high-quality user experience for our external clinician-facing products, ensuring the foundation was set for future scale and complexity.

Challenges Faced

Several challenges emerged during the early development process:

  • Normalizing Clinical Terminologies: One of the first obstacles was creating a system to accurately map and normalize clinical terminologies from various data sources into Chamber’s FHIR datastore. The solution was a blend of API integrations for standard coding systems, utilization of public crosswalk datasets, and leveraging Medplum for critical terminology metadata and mapping logic. This multilayered approach ensured a seamless, standardized coding solution.
  • Generating Realistic Synthetic Patient Data: To refine complex workflows, Chamber turned to Synthea™, generating synthetic patient data that mimics real-world medical histories (e.g. hospital encounters, office visits, prescriptions, lab values, etc). This synthetic data allowed our team to simulate scenarios specific to chronic cardiovascular diseases, refining the system’s use of FHIR resources and Medplum integration. The insights gained were pivotal in developing analytics dashboards, risk assessment algorithms, and medication management features.
  • Concept Mapping and Categorization: Effective query support and decision-making required a sophisticated grouping and categorization of clinical concepts. By integrating with leading coding system APIs and the NLM VSAC repository through Retool, Chamber was able to categorize and code clinical concepts efficiently, laying the groundwork for robust data queries and decision support tools.
  • Maximizing Retool Built-in Capabilities: While Retool provided a strong foundation for data integration, Chamber encountered limitations with more complex and nuanced FHIR data use cases. To overcome these, the team incorporated FHIR-based libraries as global functions using BonFHIR, enhancing Retool’s capabilities while adhering to healthcare standards.

Medplum Features

Medplum, offered several key features that were useful in the development of the Chamber Cardio platform:

  • Authentication: Ensuring secure access and access controls for data and system functionality that works well with Retool.
  • Subscriptions: Used to automate critical updates when changes are made to FHIR resources, helping to maintain quality and contingency across all data elements.
  • API and SDK: Offering robust application programming interfaces and software development kit for seamless integration.
  • Compliance: Meeting healthcare regulations and standards, an essential aspect of any medical software solution.

Retool Features

Chamber took advantage of a wide array of Retool’s platform capabilities for both prototyping and developing solutions for internal tools and care coordination workflows:

  • Component Library: comprehensive set of highly customizable, scalable and responsive frontend components
  • Data Source Integration: REST and GraphQL APIs, AWS Lambda, S3 Resources
  • Javascript Transformers: reusable functions and local data storage used to manipulate data returned from queries and access anywhere in the app
  • Event handling: triggering queries and components on successful and failing query responses and manual data refresh control
  • Environments & Version Control: Ease of configuration for multi-environment deployment with dedicated data sources and version-based release support
  • Self-Hosted Deployment: To maintain healthcare compliance, Chamber’s Retool instance is deployed fully within our AWS cloud infrastructure


Chamber Cardio’s initiative underscores the effectiveness of combining cutting-edge technologies—Retool’s frontend versatility, Medplum’s backend strength, and BonFHIR’s supplementary libraries and tooling —to craft a cardiology care platform that stands out for its comprehensive data integration and workflow management offering. This collaboration resulted in a product and technology foundation for enhanced care coordination, streamlined decision-making processes, and a supportive pathway for cardiology practices transitioning to value-based care and exemplifies how strategic tool selection and technology partners can enable meaningful advancements in healthcare innovation and delivery.


Flexpa - sync health history to apps

· 2 min read
Joshua Kelly
Flexpa CTO

Claims data is a uniquely rich source of financial and clinical data important to many healthcare workflows. The EDI 837 Health Care Claim transaction is one of the oldest forms of electronic data exchange, stemming from being defined as a required data transmission specification by HIPAA.

Today, we are showcasing Flexpa which connects applications to claims data via direct patient consent and a modern FHIR API powered by Medplum.

How does it work?

Flexpa aggregates and standardizes Patient Access APIs created by payers as required by CMS-9115-F. First, patients authenticate and consent to a data-sharing request from an application.

Then, Flexpa extracts, transforms, and loads payer responses into a normalized FHIR dataset. Flexpa stores data in a temporary FHIR server cache during the period for which a patient has granted access.

Finally, applications receive a patient-specific authorization response which can be used to retrieve data from a FHIR API provided by Flexpa – powered by Medplum.


What problems does Flexpa solve?

Payer FHIR servers offer an extremely variable API experience and implementing against 200+ of them is painful. Using Medplum as a data cache for their own FHIR API allows for a uniform developer experience on top of the underlying network access. Flexpa allows developers to use claims data to deliver risk factor adjustment scoring to value-based care providers, help patients navigate care, join clinical trials, negotiate bills, and more.

How does Flexpa use Medplum?

Flexpa takes advantage of several important features of Medplum’s FHIR implementation:

Medplum’s open source implementation provides Flexpa with the ability to contribute back to the project when improvements or changes are required. Additionally, Medplum’s technology choices and stack align perfectly with Flexpa’s making working with Medplum easy for Flexpa’s development team.

Develo Pediatric EHR

· 2 min read
Reshma Khilnani
Medplum Core Team

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.

Beautiful growth chart from develo (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.

Patient intake (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 order (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.

Billing experience (Even the billing experience shows attention to detail)

Medplum Year in Review 2023

· One min read
Reshma Khilnani
Medplum Core Team

2023 in Review

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.

ONC Certified in March

✅ 99.999% uptime

✅ Launched integrations with many popular platforms like Labcorp and Epic

✅ Enhanced our connectivity with on premise systems with the Medplum agent

✅ Released support for FHIRcast

✅ Doubled the size of our team

✅ Added to our Youtube Channel and Discord Community

✅ Enhanced our our Roadmap

Thank you, dear reader, for being part of our community. See you on Discord.

Rad AI Omni Reporting - Case Study

· 3 min read
Reshma Khilnani
Medplum Core Team

Medplum’s Open-Source FHIRcast Hub Enables Rad AI Omni Reporting's Interactive Measurements

Radiology is a bellwether for innovations in Healthcare IT due to the time-sensitive and data-intensive workflow. Naturally, radiology applications lead the way in adopting real-time functionality like FHIRcast, a WebSockets-based protocol that enables development of highly interactive applications.

Today, we are showcasing the Rad AI Omni Reporting platform, with FHIRcast support through Medplum’s open source FHIRcast hub.

How does it work?

Let’s consider an example: a radiologist makes a tumor measurement from a PACS workstation; that measurement can be sent in real-time to the FHIRcast hub as an event. The event is then forwarded to the radiologist’s report editor, where a context-aware description is automatically filled in describing the tumor findings, all without the radiologist ever needing to touch another application or do dictation.

Why open source?

Proprietary notification systems are a walled garden, and make it difficult or impossible to build highly ergonomic applications. An open-source FHIRcast hub is a foundational community asset, as developers and vendors can focus on building integrations rather than the plumbing. Open source provides a lot of flexibility for prototyping, testing and integrations across organizations.


Integration is a thorny problem in healthcare overall, and the adoption of standards has been a key tool in allowing system interoperability. Specifically for FHIRcast, a reference implementation that partners can prototype against and use without restriction will increase quality and speed of integration.

Rad AI interactive reporting enabled by FHIRcast

Rad AI Omni Reporting uses the Integrated Reporting Application (IRA) spec and Medplum’s open source FHIRcast hub to enable the rich, interactive application seen in the video.

Rad AI is excited to use open source FHIRcast for context syncing and data passing with our imaging and worklist partners. Having an open-source, standards-based FHIRcast hub lowers the barrier of entry for products to work together.

John Paulett Director of Engineering, Rad AI

About Rad AI

Rad AI is the fastest-growing radiologist-led AI company. The company was recently listed on the CB Insights’ Digital Health 50 as one of the top privately-owned companies using digital technology to transform healthcare, Digital Health 150 as one of the most innovative digital health startups, and AI 100 as one of the world’s 100 most promising private AI companies. Rad AI won AuntMinnie’s “Best New Radiology Software” in 2023 for Omni Reporting and “Best New Radiology Vendor” in 2021. In 2022, Black Book ranked Rad AI #1 in Mean KPI score on its survey of 50 emerging solutions challenging the healthcare technology status quo.

Founded in 2018 by the youngest radiologist in U.S. history, Rad AI has seen rapid adoption of its AI platform and is already in use at 8 of the ten largest private radiology practices in the U.S. Rad AI uses state-of-the-art machine learning to streamline repetitive tasks for radiologists and automate workflow for health systems, which yields substantial time savings, alleviates burnout, and creates more time to focus on patient care.

Digital Health is an Operations Game

· 6 min read
Rahul Agarwal
Medplum Core Team

Digital health companies are at the forefront of revolutionizing patient experience by combining quality care, at lower costs, and at national scale. Typically, they target a specific healthcare niche, concentrating on top-notch execution. Their ultimate goal? To merge an exceptional patient experience with smooth operations behind the scenes.

When operations are executed right, patients have a seamless experience - everything Just Works TM. At Medplum, we've worked with many excellent digital health implementations, and there are four foundational elements that make their operations truly stand out:

  1. Well-defined Service Menu
  2. Top of License Care
  3. Fifty-state Workflow
  4. Asynchronous / Hybrid Care Models

To implement these elements, companies need IT infrastructure that can be tailored to their service niche.

Traditional EHRs weren't built for this - rather, they were built to serve a broad healthcare domain at a smaller scale, typically within the four walls of a single site.

Well-Defined Service Menu

Successful digital health operations start with a crystal-clear understanding of their clinical service menu. From an IT standpoint, this means defining your codes:

A well-defined scope not only sets the stage for streamlined integration and billing, but also paves the way for a superior clinical experience. Instead of using one-size-fits-all EHRs, developers can build dedicated interfaces for physicians, highlighting only the necessary data for that specific care context.

The result? Reduced data entry, no physician burnout, and easier clinician recruitment. That's why Medplum provides a truly headless platform - to empower developers to create purpose-built physician experiences.

Example: Summer Health

Summer Health had clear understanding of their service menu: non-acute, pediatric care over SMS. They built a provider charting experience from the ground up, with a focus on fast, mobile-first charting.

Some of their design innovations were:

  • Using buttons, not drop-downs, to select from the most common patient complaints reduced data entry mistakes.
  • Integrating an LLM summarization of the SMS exchange between provider / patient exchange significantly reduced typing time.
  • Implementing a paginated workflow for each encounter made efficient use of the mobile screen real estate and reduced physician frustration.

Summer Health

The cumulative effect of these changes was to convert charting from a chore to a delight. Physicians spent more time on patient care, and less time and energy on charting.

Top of License Care

Delivering high quality care at reasonable cost means that everyone is working at the "top of their license". MDs and NPs focus diagnosing, prescribing, and designing care plans; care coordinators handle administrative inquiries.

To implement this model at scale, operations teams need to develop a clear ontology of clinical tasks and roles that mirrors their care model, and manage them in a unified task system. The challenge is ensuring tasks are automatically directed to the professional, while still being able to escalate when needed.

Many traditional EHRs make offer a fixed clinical workflow, or offer limited configurability. Most of them cater to MDs, but don't account for care coordinators, customer success representatives, fulfillment teams, and the host of other roles that make up the digital health care workforce.

Platforms like Medplum offer a layer of programmability on top of the FHIR Task model, which allows developers to implement the precise clinical workflow model. Tasks can be organized into queues and assigned based on credentials and availability. And by integrating these automations (i.e. Bots) into the software development lifecycle, operations teams can test workflow changes before deploying and release with confidence.

For a deeper dive, check out our guide on Task-based workflows.

Fifty-State Workflow

One of the game-changing innovations of digital health was the ability to serve patients across all 50 states. But this evolution brought with it a significant challenge: managing physician licensure and credentials nationwide.

Operations teams need to make sure that enough physicians with the correct licenses are staffed to serve their patient population. They need to account for differing physician specialties, regulatory restrictions, and vacations across service lines.

The key to managing this complexity is having the right data model. How can you manage physician coverage if you don't even know which licenses they have? Traditional EHRs fall short here, as they presume a single-site deployment.

Leveraging the FHIR standard, platforms like Medplum offer the building blocks for tracking physician credentials, specialties, and care teams. For more insights, take a look at our guides on provider organizations, credentials, and payor networks.

Asynchronous Care

The rise of telehealth, catalyzed by the pandemic, was the first step in unlocking the potential of digital care. But digital health is more than just video calls. Not every patient concern needs to be handled face-to-face.

Allowing physicians to deliver care asynchronously allows them to scale themselves more effectively. It also opens up a number of different interaction media for patients: SMS, video message, in-app chat, etc.

While many traditional EHRs have chat functionality, their visit-centric model makes them ill-suited to async-first care. What is considered a "visit" in the age of day-long text chains?

Platforms like Medplum present the tools to craft your care delivery, even if it adopts a partially or completely asynchronous model. Our guide on asynchronous encounters provides an example of how you can build your async care model from FHIR primitives.

The Digital Health Operations Playbook

  1. Define your Service Menu: For each clinical service line, clearly outline the relevant CPT, ICD-10, RxNorm, and LOINC codes. Focus on the essential data entry requirements from patients and physicians and prioritize data-entry efficiency.

  2. Diagram your Operations: Map out the clinical tasks required, identify the roles responsible for each task, and determine data access restrictions for each role. A visual representation, such as a flow-chart, of your end-to-end clinical operations can be immensely beneficial.

  3. Map out your Provider Organization: Have a keen understanding of the availability and qualifications of each provider to ensure availability and access to care.

  4. Define the Encounter Model: In the digital age, redefining the patient encounter is crucial. Understand the mediums, methods, and tools at your disposal and craft a model that best serves your patients and practitioners alike.

Remember, in the rapidly evolving world of digital health, operations are more than just a behind-the-scenes affair. It's the backbone that defines patient experience and sets the stage for a future of healthcare that is efficient, effective, and truly global.

AI Driven Patient Intake and EMPI - Titan Case Study

· 3 min read
Reshma Khilnani
Medplum Core Team

Those who have experienced the wait and shuffle of a specialist referral will appreciate the thoughtful and futuristic approach of the team at Titan Intake.

(5 minute demo)


Continuity of care is broken because practices rely on fax and paper referral workflows to send patients to specialists. It is unrealistic to expect practices to change their systems, but patients need referrals and practices want to process them faster and capture all of the incoming clinical data without manual data entry.


Titan provides a novel solution that leverages large language models (LLMs) to normalize unstructured referral data to FHIR, and gives practitioners and staff a button to synchronize data to their EHR (Cerner and others) via FHIR API. This saves manual work by staff and helps patients track the status of their referral. To lighten provider load, the Titan Intake app automatically synchronizes FHIR data to enable faster and more complete chart prepping.

In addition, as part of the intake process, Titan’s Natural Language Processing (NLP) engine detects and predicts the presence of Hierarchical Classification Codes and Elixhauser Comorbities to help both health systems and payors measure and receive reimbursement for the health of their patient populations. These are added to the FHIR Resources as CodableConcepts.

Medplum Solutions Used

  • Enterprise Master Patient Index (EMPI) - As part of their EMPI implementation Titan checks and deduplicates patients, to prevent the fear of hospital IT - that an integration will introduce duplicates into their system and disturb their reporting and workflow.
  • Interoperability Service - From their web application, Titan triggers data synchronization into many downstream EHRs like Cerner, NextGen and others. This uses the Medplum integration engine a natively multi-tenant system that is very scalable and they serve many providers on the same technical stack.

Here is the full list of Medplum Solutions.

Challenges Faced

  • Extracting data from documents/PDFs and structuring the data as FHIR is a very difficult technical problem. The team employs use of LLMs and modern artificial intelligence techniques to structure and tag the data with code systems.

  • Due to the nature of referrals, with a single patient being sent to many different institutions, duplicate Patient resources immediately become an issue. The team built a FHIR native Enterprise Master Patient Index and deduplication pipeline to support this use case.

  • Synchronizing to many downstream EHRs, like Cerner and Epic on an event driven basis is difficult because each EHR has slightly different conventions and requirements to accept data.

Medplum Features Used

GraphQL vs REST APIs in Medplum

· 6 min read

One of the most frequent questions we get from our users is whether they should use Medplum's REST or GraphQL APIs. Both have a FHIR specification, but they offer different tradeoffs for different use cases.

In this post, we'll discuss these tradeoffs and provide some guidance on how you can choose which API is right for you.


GraphQL has surged in popularity in recent years. You can try out FHIR graphql queries on your medplum project using our graphiql sandbox.

In the context of FHIR, one of GraphQL's strongest features is the ability to quickly retrieve multiple linked resources. While the REST API allows similar functionality using the _include and _revinclude search parameters, GraphQL offers a more natural syntax for querying bundles of resources that reference each other.

Patient(id: "patient-id") {
name {
address {
# Get all DiagnosticReports related to this patient
DiagnosticReportList(_reference: patient) {
performer {
code {
# Get all Observation resources
# referenced by DiagnosticReport.result
result {
resource {
... on Observation {
code {
valueQuantity {

In addition, GraphQL also offers very fine grained control for developers to select the exact fields returned in a query, which can reduce your app's network traffic. Unlike the REST API, GraphQL lets you select specific fields, even in deeply nested elements, and provides additional filtering functionality through FHIR Path list filters. This is helpful in applications where bandwidth is at a premium, such as in mobile applications.

Patient(id: "patient-id") {
name {
address {
# Filter the `telecom` field to only contain phone numbers
telecom(system: "phone") {

As with REST batch requests, GraphQL queries and mutations support the retrieval and modification of multiple resources in a single query, respectively.

# Retrieve all Patients
patients: PatientList(name: "Eve", address_city: "Philadelphia") {
name {
address {
# Retrieve all Medications
medications: MedicationList {
code {

However, GraphQL does have some limitations. The FHIR GraphQL specification is under active development, but some parts have not yet reached maturity. For instance, its search specification isn't as detailed as its REST counterpart, though the _filter search parameter is available in both APIs. And FHIR GraphQL does not yet have a specification for PATCH operations, which limits its ability to make field-level updates to a resource.

Lastly, because shape of a GraphQL query's return value depends on the query itself, it's harder to use typescript type definitions from @medplum/fhirtypes to handle return values. Instead, users must defined custom types that match the shape of their query.


The FHIR REST API is the most common way to interact with FHIR-based systems on the market, and enjoys a broad base of support. While REST is an older technology, the FHIR REST API offers a few advantages.

First off, REST offers a relatively richer search specification out of the box, with support for search modifiers, iterated includes, and search result counts .

Moreover, REST supports HTTP PATCH operations, which allows clients to perform targeted, field-level resource updates. This capability is especially useful in high-concurrency environments, where many clients could be editing different parts of the same field.

// This call assigns the Task to the current user
// IF AND ONLY IF the the task has not been modified on the server
await medplum.patchResource('Task',, [
{ op: 'test', path: '/meta/versionId', value: task.meta?.versionId },
{ op: 'replace', path: '/status', value: 'accepted' },
{ op: 'replace', path: '/owner', value: createReference(currentUser) },

And while GraphQL mutations do allow writing multiple resources at once, using FHIR batch requests via the REST API offers more advanced batch writing functionality. The ifNoneExist element can be used to perform a search before creating a resource to prevent duplicate resource creation. Additionally, you can create collection of linked resources that reference each other using the urn:uuid syntax.

resourceType: 'Bundle',
type: 'batch',
entry: [
fullUrl: 'urn:uuid:42316ff8-2714-4680-9980-f37a6d1a71bc',
request: {
method: 'POST',
url: 'Practitioner',
ifNoneExist: 'identifier=|' + identifier,
resource: {
resourceType: 'Practitioner',
identifier: [{ system: '', value: identifier }],
request: { method: 'POST', url: 'ServiceRequest' },
resource: {
resourceType: 'ServiceRequest',
status: 'active',
intent: 'order',
subject: createReference(patient),
code: { coding: [{ system: '', code: '12345-6' }] },
requester: { reference: 'urn:uuid:42316ff8-2714-4680-9980-f37a6d1a71bc' },

Lastly, there are additional APIs that are only available from REST, such as the resource history API, which returns a Bundle of all historical versions of a resource.

However, while REST has more powerful write and search functionality, it has some limitations on reads. You can use the special _elements search parameter to limit which fields in a resource are returned, but this can only be used to filter top-level fields. You cannot specify filter out nested subfields of a complex element.

Additionally, when requesting linked resources using _include and _revinclude with a FHIR search, the REST API will return a flat Bundle of resources. You will have to implement some additional logic in your client to connect linked resources with their base resource, where as GraphQL nests linked resources within their root resource.

Which One Should I Choose?

So which should you choose? Your choice between REST and GraphQL will largely hinge on your specific use-case. Here are three potential paths to consider:

Both (recommended): For those not committed to a specific toolset, blending the best of both worlds is our recommended strategy. GraphQL is great for reading linked resources, and REST offers advanced write, batch, and history management functionality. Using the Medplum Client makes it easy to shift between these two query modalities, and it's what we used when building the Medplum App.

REST API: Using REST is our recommendation if your tasks involve complex searches or filters. Similarly, if you are performing queries that delve into resource history or necessitate targeted updates using PATCH, REST is the way to go. Lastly, REST is the de-facto standard when interacting with multiple FHIR systems.

GraphQL Only: This route may appeal to you if you have invested in building on top of GraphQL tooling such as Apollo. Additionally, if your operations are predominantly read-heavy and bandwidth is at a premium, GraphQL can give you fine-grained control over what is sent over the network.

The decision between REST and GraphQL isn't black and white, and each API offers its own tradeoffs. Medplum aims to offer developers the widest set of options so that they can hone in on the optimal tool for their needs.