3 posts tagged with "fhir"

Most folks, before encountering Medplum, think of FHIR in one of two ways:

• As a read-mostly interface bolted onto a proprietary EHR. Epic, Oracle Health, and exchange profiles like Da Vinci Payer Exchange all use FHIR only at the boundary between systems. The real data lives in someone's proprietary tables; FHIR is the negotiated contract at the edge.

• As a FHIR repository you publish into. HAPI, Aidbox, HealthLake, and the Azure or Google FHIR stores are often stood up alongside the operational datastore that actually serves the application — a landing zone for exchange, analytics, or compliance, rather than the system of record your app reads and writes on the hot path.

In both models, FHIR sits off to the side, and a separate database is doing the real work of running the application.

So when developers come to Medplum, they usually ask something along these lines:

• "How is the data handled and stored in the DB itself? How does that relate to FHIR?"
• "If I point a SQL explorer at the Postgres database when running Medplum locally, will I be able to see what's happening?"
• "Can I get direct access to the rows in the database when using your hosted service?"

These are all very reasonable questions for developers doing due diligence on Medplum, and part of the beauty of open source is that you can inspect our implementation directly. We also think these questions come from a particular understanding of the relationship between FHIR and an EHR — and this post is about how that relationship is different in Medplum.

After several months of preview as an Alpha product, we are pleased to announce that Medplum's Scheduling API has graduated to Beta.

Medplum's Scheduling API provides an interface for applications to atomically interact with Schedule, Slot, and Appointment resources to safely create and manage bookings without creating scheduling conflicts. Developing a feature like this required the ability to iterate as we learned, and our Alpha period provided exactly that.

There's a piece of conventional wisdom in health tech that won't die: FHIR is fine for interoperability, but too slow and bloated for real-time clinical apps.

The skepticism isn't unreasonable. FHIR resources can be verbose, real charts are messy, and clinical workflows don't forgive much. A physician who opens a chart and watches a spinner for five seconds has already been let down by the architecture.