One post tagged with "traditional-ehr"

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.