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:

• ICD-10 and CPT codes for services
• LOINC codes for diagnostics
• RXNorm codes for medications

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.

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.

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)

Problem​

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.

Solution​

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​

• Bots and Automation - to enable the event driven connections between applications and EHRs
• FHIR Datastore - to store the data and manage the identities and deduplication
• Self Hosting - super admin features, and the ability to to manage tenants enables multi-institution access and connections

Related Reading​

• EMPI Implementation video
• Patient Deduplication Architectures
• Deduplication reference implementation code
• Case Study: Codex and the Power of the (g)(10)
• CodableConcepts in FHIR

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​

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 {
      given
      family
    }
    address {
      line
      city
      state
      postalCode
    }
    # Get all DiagnosticReports related to this patient
    DiagnosticReportList(_reference: patient) {
      performer {
        reference
      }
      code {
        text
      }
      # Get all Observation resources
      # referenced by DiagnosticReport.result
      result {
        resource {
          ... on Observation {
            status
            code {
              text
            }
            valueQuantity {
              value
              unit
            }
          }
        }
      }
    }
  }
}

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 {
      given
      family
    }
    address {
      line
      city
      state
      postalCode
    }
    # Filter the `telecom` field to only contain phone numbers
    telecom(system: "phone") {
      value
    }
  }
}

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") {
    resourceType
    id
    name {
      family
      given
    }
    address {
      line
      city
      state
      postalCode
    }
  }
  # Retrieve all Medications
  medications: MedicationList {
    code {
      text
    }
  }
}

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.

REST​

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', task.id, [
  { 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=https://example.com|' + identifier,
      },
      resource: {
        resourceType: 'Practitioner',
        identifier: [{ system: 'https://example.com', value: identifier }],
      },
    },
    {
      request: { method: 'POST', url: 'ServiceRequest' },
      resource: {
        resourceType: 'ServiceRequest',
        status: 'active',
        intent: 'order',
        subject: createReference(patient),
        code: { coding: [{ system: 'http://loinc.org', 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.

As a long time YC community member (10+ years) and former Visiting Group Partner, I'm always excited by the great companies that release each Demo Day. For me, it's like the Superbowl 🏈.

Read our coverage on YC S23 Open Source Meetup and Medplum's YC Launch

YC Alumni Demo Day was this Saturday September 2, and I thought the presentations were particularly good. Here's some exciting nuggets we saw in the presentations in the Healthcare and Life Sciences category.

• Mantle Bio - Snowflake for Biotech - enormous data sets, complex algorithms, and a workforce filled with PhDs who have a lot of domain expertise but little exposure to data engineering make this a fertile area. Great to see an MIT team here as well.
• Flex - Stripe for HSA/FSA - accepting payments period in healthcare and HSA/FSA in particular requires so many special agreements and there is a ton of float out there. I could see specialized medical services being built around these balances. A team with strong infra chops and big tech background is great to see here too.
• Decoda - AI medical claims creation. Just Google CPT 99205 (outpatient evaluation and management of new patient) documentation and you'll see why it would be great to have AI do this.
• Shasta Health - AI Platform for physical therapists. Patients need PT before and after surgery and treatment in so many cases for health reasons and for payers. Having an AI guided workflow here seems so useful.
• Ohmic Biosiciences - Genetically engineering plants for alternative to roundup. Clear win to getting this to work! A team out of UCB, and reading their launch brought to mind the movie Interstellar.
• Olio Labs - Therapeutics for tough diseases. There's a lot of great properties of targeting tough diseases. Details are long, but a Startup and FDA article may be of interest.
• Flair health - Shopify for holistic primary care. It's just a matter of time before there is a huge direct-to-consumer health company the likes of the biggest companies in America, that's the opportunity.
• Feanix Biotech - genetic testing for animal (cow) breeding. Clear win getting this to work as well! Launch highlights a team at the intersection of big tech and agriculture.
• Health Harbor - Gen AI to "call insurance" for clinics. The phone, like fax, is a major channel for information exchange. I could see one angle where they payers also put a bot on the other side of the line.
• Obento Health - Patient engagement for private practice. Patient engagement at the right level is a perennial challenge at all levels. If it's cracked it is a big deal.
• Andromeda Surgical - autonomous surgical robots. Love the ambition and it would be a breakthrough as trained surgeons are so scarce. Clearly a team savvy about Startups and the FDA.
• Medisearch - trustworthy medical search. Healthcare is all about trust! Trust is the difference between gold and garbage in this industry. A trusted search engine has immense obvious value. A very technical team working on this.
• Sohar Health - AI driven clearinghouse for behavioral health. Access to behavioral health is a huge issue at the societal level. Godspeed.
• Sensible Biotech - mRNA synthesis for therapeutics and vaccines. We all know how powerful mRNA is. Exciting. Related: FDA Orientation for Startups.
• Wattson Health - Software for managing Rx and automate manual workflow. Healthcare + automation, love it. The quality monitoring benefit seems like a big deal as well. Demo gif tells a good story to those (like us at Medplum) in the industry.
• Healthtech 1 - Automating repetitive healthcare processes. After fighting our way through interop and "standard" interfaces, we at Medplum know how powerful and compelling RPA can be for practitioners. This is a case in point in solving a burning pain point for practitioners.
• Synaptic - AI powered training for doctors Well organized, high quality medical knowledge is a sleeper category. UpToDate is the Craigslist of this category and am excited about the future. Also cool to see an interdisciplinary MD + big tech team at work on this.
• Simbie - AI powered practice in a box for NPs in women's health. I could see myself as a customer of one of their customers.
• Cleancard - cancer screening as easy as pregnancy test. Clearly valuable and loved their launch. We at Medplum serve several at-home test providers as customers and at home diagnostics resonate a ton with patients. Related: How to start a Biotech on a budget,
• Nanograb - AI-generated binders for targeted drug delivery. Nothing close to an expert in this space, but am enthusiastic about the descriptive name of this company, and like that they have a neat domain. 70% of drug trials fail because the "grab" doesn't work (poor targeting).
• MICSI - Higher resolution MRI with faster scan times. MRI (and ultrasound) are really valuable tools, and see many wonderful applications of this technology. MICSI stands for microstructure imaging, and I could see this technology being able to read the mind.
• Certainly Health - Book doctors and avoid surprise bills. How much (and when) are two frequent unknowns in healthcare. Great to see a technocratic approach here from a technical team.
• Stellar Sleep - clinic for chronic insomnia. Great use case for a specialized provider, as insomnia really affects quality of life and the standard advice from GP is to reduce coffee intake, neglecting frequent related issues like anxiety, hormonal issues and more.
• Empirical Health - proactive primary care, scaled with AI. I love the name and the premise. Also, so exciting to see a team with a deep understanding of precision,recall and value based care in this space.
• Eden Care - Digital health insurance for employers in Africa. Not an expert, but we see a good amount of Medplum community activity in Africa, and am bullish about the opportunity in region.

A huge congrats to YC S23 on your Demo Day!

Patient record-keeping systems often have duplicate patient records, which can affect patient care and service delivery. One of the Medplum use cases is the the Enterprise Mater Patient Index (EMPI), database used in healthcare settings to maintain accurate and consistent unique identifiers for patients across various departments and services. A great EMPI implementation will improve patient safety, enhance the quality of care, facilitate data sharing among disparate healthcare systems, AND speed payer contracting.

The Medplum team has had experience with EMPIs across different practices, including telehealth practices, which especially thorny duplication and identity issues as patients may never meet providers in real life.

This video walkthrough summarizes a reference implementation that we have developed based on our experience. It can be used with any identity solutions or matching algorithms.

Our overview of Patient Deduplication Architectures describes the data model and pipelines in detail.

Outline​

The following points are covered in this implementation:

• How to trigger the deduplication pipeline by subscribing to changes on the Patient resource, which reduces the maintenance cost of implementation
• Creating a Task for humans to review high-risk duplicates
• Creating the Risk Assessment - how likely is this to be a duplicate?
• Numeric scoring and qualitative scoring for calculating the probability that a record pair is duplicates
• Workflow for merging two records driven by FHIR Questionnaires
• Showing how duplicates are deactivated, and creation of a bi-directional link between duplicates
• How to mark records as "Do not merge"
• Demonstration of traceability how to audit merges

EMPI Deduplication workflow code

Transcript​

YC invites alumni (like us - Medplum is YC S22) to come speak for the current batch and share our experiences. We were excited when our YC Partners Diana and Nicolas invited Medplum to come and speak to Open Source and devtools companies two weeks ago.

Jorge, Michel, and me at YC (Nicolas at the edge)

However, I had a moment of panic when I realized that the other panelists were Michel from Airbyte, and Jorge from MindsDB. For context, MindsDB and Airbyte have huge communities. They are frequently featured on Hacker News - which is the New York Times of open source.

Standing side-by-side with these founders, I worried, could not be a flattering comparison.

A False Comparison​

Here's one thing that we believe: 10 or 20 years from now, we will find the fact that we grouped open source startups together funny and peculiar. It's like looking at startups from the late 90's when "Internet" was a startup category - how quaint!

Looking back at our 2023 selves, we will have that same thought about "open source" startups - a grouping representative of the time, and not the startup itself.

YC Founders were quick to pick up the fact that we are not all the same. Below are the questions they asked in session. These answers are from the Medplum perspective, these certainly don't apply globally and the answers you get from Michel and Jorge would no doubt be pretty different.

What Founders Asked​

Why did you choose open source?

Healthcare app developers have what we call "the terrible choice", (a) buy an off the shelf health records system and fight with it or (b) invest a ton of time and resources into your medical record system to build your workflow, compliance, certification and integrations.

Minimal/simple medical app implementations are rare, and when they exist - spiral in complexity when the app makes contact with the healthcare establishment (insurance billing, medications ordering, lab integrations etc).

What healthcare devs really need is a composable solution, that enables adding on functionality as needed with great abstractions. Composability is a superpower and is the key attribute of open source.

Open source has some great secondary benefits too. Healthcare devs are very jaded after repeatedly being marketed products that don't really work and/or are largely undocumented black boxes. The ability to test and audit open source in depth has appeal, and helps to build trust.

We actually "learned the open source lesson" a long time ago. The Medplum founding team founded a medical imaging SaaS startup called MedXT (YC W13). MedXT customers were constantly asking for "source code in escrow" or "source access" whenever they would sign a SaaS agreement. We should have put some careful thought as to why they were asking for it. With 20/20 hindsight, we now know that continuity of business and compliance are critical for customers, and open source is a great tool in that regard.

What were some of the most effective tactics for growing your dev mindshare early on?

We have a fundamentally different approach to growing dev mindshare than many other open source startups. We don't do launch week, memes, or advanced Tweeting. (Maybe we should, but that's not top of mind today.)

For us, getting customers to build and run in production was the first step in getting dev mindshare. Electronic Health Records have no "hobbyist" use case, if you are going to use it, it better work in production.

In that way, getting to production really early, before we had 20 stars on our repo, on was our way to establish mindshare. That production usage is something that our customers value, and that in combination with an open source, certified, well documented, compliant offering is novel for the healthcare dev.

Second to running in production, certifications are our second most effective technique to gain developer mindshare. Medplum has common certifications, like SOC 2 and HIPAA as well as some very industry specific ones like ONC and CLIA/CAP. In general devs find certification tasks tedious and un-fun, so a reference implementation appeals.

Citus Data (YC S11) and Posthog (YC W20) have a similar "in production" ethos to Medplum,

Umur (VGP YC, Citus Data S11), Tim (Posthog), James (Posthog), me holding the mic

What are your important metrics?

We track the number of projects and apps created, as well as the number that reach certain maturity milestones in their implementation on our hosted service. These are nothing fancy or sophisticated.

We work hard on our customer success and implementations. We track questions and support requests across all channels Github, Discord, Slack and email. We track how many had documentation/content already published, how many were actual bugs and turnaround times. Troubleshooting, helping others build is our customer obsession, and if their implementation is successful, we'll be successful too.

How did you get your first paid customer?

Our first paid customer used our hosted offering.

Medplum is somewhat unique in that we started with our hosted multi-tenant offering. This is the opposite of many open source companies, who start with a self-hosted single tenant offering.

Our initial customers liked what they saw in the repo, and liked that they could self-host, but decided they would rather have a managed solution. We believe that having a managed solution day 1 was crucial for us, as the time to value and feedback loop are much faster.

Do you do professional services? If so, how much?

We do a small amount of professional services in the form of workshops and pilots for prospective enterprise customers. Engineering leaders often have budget for professional services, and this type of engagement helps devs align stakeholders internally as they make the case to their leadership that they should use Medplum.

How did you decide on your license?

We support customers through many complex compliance audits and certification processes. Our license, Apache 2.0 is a reflection of that, it's well understood to stakeholders. There are code scanners everywhere in an audit.

How was fundraising as an open source company?

I mentioned in the beginning how nerve wracking it is to be compared to the Github star machines like MindsDB and Airbyte. We had to do extra preparation and communicate crisply to investors to tell our story, not a version of someone else's.

For Medplum, open source is our way to build trust. I'll compare and contrast that with some other approaches where open source is a form of marketing, and is primarily for growth.

When it comes to fundraising, the narrative is critical: we are open source to build trust with customers and prospective customers. And companies have trusted us with their data, and use us as their primary health datastore in production. The value customers get from having a trusted partner to manage their data is the basis of our business.

Break a leg on your demo day YC S23!

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.

Related Reading​

• Medplum's Compliance Documentation
• Composability and Standards
• What is ONC Certification

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:

• Identifiers
• CodeableConcepts

Identifiers​

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:

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.

{
  "resourceType": "Patient",
  "name": [{"given": ["Alice"]}],
  "identifier": [
    // MRN - Hospital 1
    {
      "system": "http://hospital-1.org",
      "value": "12345"
    },
    // MRN - Hospital 2
    {
      "system": "http://hospital-2.org",
      "value": "98760"
    }
  ]
}

{
  "resourceType": "Patient",
  "name": [{"given": ["Bob"]}],
  "identifier": [
    // MRN - Hospital 1
    {
      "system": "http://hospital-1.org",
      "value": "98760"
    },
    // MRN - Hospital 2
    {
      "system": "http://hospital-2.org",
      "value": "12345"
    }
  ]
}

Now if we add the system string to our search, we can do a targeted query for Bob.

GET [base]/Patient?identifier=http://hospital-2.org|12345

See our search guide for more information about searching with system strings.

CodeableConcepts​

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.

{
  text: 'Tylenol 325 MG Oral Tablet';
  coding: [
    // RxNorm
    {
      system: 'http://www.nlm.nih.gov/research/umls/rxnorm',
      code: '209387',
    },
    // NDC
    {
      system: 'http://hl7.org/fhir/sid/ndc',
      code: '50580045850',
    },
  ];
}

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.

Best Practices for System Strings​

So now that we understand Identifier and CodeableConcepts better, we can talk about how to write good system strings.

Identifiers​

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.

CodeableConcepts​

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.

Some commonly used code systems:

For local codes, the system string should reflect the degree of consensus you want to enforce across your organization.

A system string like https://my-healthcare-company.org/productLine could indicate a company-wide standard for product lines, while https://my-healthcare-company.org/messaging/productLine could refer to a standard specific only used within the messaging function.

Conclusion​

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.

See Also​

• FHIR Basics
• Medication Codes
• LOINC Codes

Darren Devitt, a respected FHIR expert, has recently released an alpha version of a new tool called Vanya. Similar to how Postman functions for API requests, Vanya is designed specifically for browsing data on FHIR servers.

I've taken some time to test Vanya with Medplum's FHIR server, and I want to share the setup process, some tricks I've found useful, and a brief overview of my experience.

Setting Up Vanya with Medplum's FHIR Server​

If you've decided to give Vanya a try, here's what you need to know to get it running with Medplum's FHIR server:

FHIR Base URL​

You'll need to input the FHIR base URL, not just the server base URL. Remember to include the "fhir/R4" path. For example, when using the Medplum Staging server, I used the full URL "https://api.staging.medplum.com/fhir/R4".

Authentication​

Vanya requires authentication as an HTTP header. For my testing, I used a "Basic" auth header created using the client ID and client secret.

You can use a tool such as DebugBear to generate a Basic auth header from a client ID and client secret.

Or, if you prefer, you can use the OAuth2 client_credentials flow with the client ID and client secret to get an access token. See our guide on Client Credentials for step-by-step instructions.

Once you have a Basic auth token or a Bearer token, add it to the Vanya HTTP headers:

Using Vanya​

Once you've set up these parameters, you can start using Vanya to browse through different types of FHIR data on the Medplum server.

Wrapping Up​

Vanya is still in its alpha stage, and there's a lot to look forward to as it continues to develop. However, even now, it offers a useful tool for browsing FHIR data. I'll be keeping an eye on the tool's progress, and I'll share any important updates here.

Give Vanya a try and let us know about your experience. If you have any questions or need help with the setup, please join our Discord!

NASA's TRISH team (Translational Research Institute for Space Health) recently issued an RFP for a healthcare tech platform designed for monitoring spaceflight participant health metrics during space missions. TRISH is a virtual consortium focused on applied research to ensure astronaut health during space exploration.

As avid space enthusiasts, and NASA Space Camp alumni, we were eager to apply.

Medplum submitted a proposal. We were invited to present to the TRISH team in June!

We're now anxiously awaiting the results.

Adapting to Space Challenges​

A notable challenge in the RFP was the solution's ability to operate in a low power environment. To address this:

Medplum on Raspberry Pi​

We successfully set up the entire Medplum tech stack on a Raspberry Pi 4 (8gb edition). Due to Medplum's open source nature and its reliance only on widely-used open source dependencies, this transition was quite smooth. For those curious, here's the Raspberry Pi 4 model we used.

Raspberry Pi OS Selection​

A necessary adjustment was using the 64-bit edition of the Raspberry Pi OS because 32-bit Postgres isn’t widely supported or available as a Debian package. Following that, the Medplum installation mirrored the process on any other Linux server, as detailed in our Ubuntu installation guide.

Monitoring Power Consumption​

With everything up and running, it became pertinent to gauge the power consumption. Using the SURAIELEC Watt Meter, we observed that when Medplum operates idly, the power consumption hovers around 1-1.5 watts.

UI Development​

Once power constraints were addressed, we used the Medplum React components to assemble a mock dashboard showcasing health metrics of Artemis mission astronauts, monitoring vital signs and other crucial health parameters. We also included the spacecraft's intrinsic metrics, such as cabin temperature, pressure, oxygen levels, CO2 concentrations, and radiation readings.

Conclusion​

This exercise provided a practical demonstration of Medplum’s adaptability and versatility, underscored by the strength of open source tools. We believe the exercise emphasizes Medplum's flexibility and readiness for diverse challenges.