Medblocks vs Medplum
How Medblocks compares to Medplum and the FHIR CDRs, across connectivity, modeling, and deduplication.
Medplum is a FHIR clinical data repository, a server that stores and serves FHIR. A CDR is not an integration product, so it does not appear in the healthcare integration landscape at all. We cover it here because teams still weigh CDRs against integration tools and get the two confused. Other FHIR CDRs include Aidbox, Smile CDR, AWS HealthLake, Azure FHIR, and Google Cloud Healthcare. They are repositories: excellent at holding FHIR, but they do not connect to sources unless you build the integration, and the modeling is yours to bring.
Quick verdict
Choose a FHIR CDR if you need a compliant, scalable FHIR server to hold and serve data. Within that job they are solid, and several are battle-tested at scale.
Choose Medblocks if you need the data to arrive in the first place, connected, deduplicated, and modeled. A CDR is the destination, not the pipeline. In fact this is not an either-or: Medblocks connects and normalizes, then exports clean FHIR straight into the CDR you keep as your system of record.
Side by side
| Medblocks | Medplum | Aidbox | Smile CDR | AWS HealthLake | Azure FHIR | Google Healthcare | |
|---|---|---|---|---|---|---|---|
| Patient access ? | ✓ | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ |
| Your branding ? | ✓ | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ |
| Brokered org access ? | ✗1 | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ |
| Wearable & mobile ? | ✓ | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ |
| SMART EHR embed ? | ✓ | ~2 | ✗ | ✗ | ✗ | ✗ | ✗ |
| CDS Hooks ? | ✓ | ~2 | ✗ | ✗ | ✗ | ✗ | ✗ |
| EHR backend ? | ✓ | ~2 | ✗ | ✗ | ✗ | ✗ | ✗ |
| FHIR bulk ? | ✓ | ~2 | ~3 | ~3 | ~3 | ~3 | ~3 |
| HL7v2 interfacing ? | ~4 | ~2 | ✓ | ✓ | ✗ | ~5 | ~5 |
| Treatment-use HIE ? | ✓ | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ |
| Patient deduplication ? | ✓ | ~6 | ~7 | ~7 | ✗ | ✗ | ✗ |
| Clinical data models ? | ✓ | ~8 | ~8 | ✗ | ✗ | ✗ | ~9 |
| Export to FHIR CDR ? | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
| Export to warehouse ? | ✓ | ✓ | ✓ | ✓ | ~10 | ~10 | ~10 |
| Pricing model ? | Flat subscription | OSS / Subscription | Subscription | Usage based | Usage based | Usage based | Usage based |
| Pricing ? | $60,000/year | $72,000/year11 | $19,000/year12 | Undisclosed | Pay as you go13 | Pay as you go14 | Pay as you go15 |
✓ native · ~ partial · ✗ not supported
- Medblocks brokered access: we provide extensive written guidance and one-to-one support on contracting with an organization and getting your own credentials installed. We don't do it on your behalf with our credentials.
- Medplum integrations: the capabilities marked limited are achievable by building custom integration and mapping with their Bots feature, but take significant glue code, technically similar to Rhapsody. See their integration docs.
- FHIR bulk (CDRs): these servers expose bulk export endpoints, but importing from another source’s bulk endpoint, which is what this row measures, is not native and takes additional software or code.
- Medblocks HL7v2 interfacing: supported over HTTP with SMART Backend authentication, which major EHRs like Epic support natively.
- HL7v2 (Google, Azure): they convert HL7v2 to FHIR and store it directly, but only accept messages sent as special FHIR bundles, with no MLLP or HL7v2 over HTTP. Google also offers a separate HL7v2 store, but it does not integrate directly with the FHIR store.
- Medplum patient deduplication: a framework and reference implementation, not a turnkey EMPI. You design the matching rules and merge workflow yourself and build it with custom code.
- CDR deduplication: FHIR servers expose a $match operation, but you configure and tune the MDM rules yourself. It is not turnkey.
- Clinical data models (Medplum, Aidbox): available through SQL on FHIR, which you define and maintain yourself, not provided out of the box.
- Google clinical data models: offered through a separate open-source data harmonization repo that exports to OMOP, not built into the FHIR store.
- Warehouse export (cloud CDRs): they export to their own cloud analytics only (AWS to Athena, Azure to Fabric, Google to BigQuery), not an external warehouse you choose.
- Medplum pricing: only the $6,000/month Premium plan includes any integrations, so that is the figure shown here.
- Aidbox pricing: the figure shown is the Aidbox Base Yearly plan; other tiers and a free development tier are available.
- AWS HealthLake pricing: metered, billed per GB ingested, per GB stored each month, and per API request and query. See HealthLake pricing.
- Azure FHIR pricing: metered, billed per GB of structured storage and per API request. See Azure Health Data Services pricing.
- Google Cloud Healthcare pricing: metered per GB stored and per API call. See Healthcare API pricing.
See the full capability matrix for every row and the sources behind each rating.
What FHIR CDRs do well
A CDR is excellent at storing and serving FHIR. If you need a compliant, scalable FHIR server, with bulk export and SMART-based access, these are solid choices, and the cloud options (HealthLake, Azure, Google) scale with almost no operational overhead.
They differ mostly in flavor. Medplum and Aidbox lean developer-first with app tooling, Smile CDR is the commercial steward of HAPI FHIR, and the cloud CDRs are managed services inside AWS, Azure, and Google.
Where Medblocks goes further
A CDR is mostly storage, and three gaps follow from that. It does not connect you to sources, so getting data in is your problem. It leaves modeling to you, so the same concept lands in many shapes inside the same repository (tumor size can be an Observation or a Condition). SQL on FHIR helps query it but is one more thing you build, and it is limited: modeling in a warehouse with a tool like dbt is usually more powerful. And while many offer a FHIR $match operation for deduplication, you configure and tune the MDM rules yourself.
Medblocks does the connecting, the deduplication, and the normalizing upstream, and delivers a clean, modeled FHIR record. The CDR holds it; we make it worth holding.
Pricing
CDR pricing varies by model: the cloud services (HealthLake, Azure, Google) are pay-as-you-go on storage and requests, Aidbox is subscription with a free development tier, and Smile CDR is enterprise and quote-based. None of these includes connectivity or modeling, which you fund separately. Medblocks is a flat $60,000 per year for the connect-and-normalize layer that feeds them.
Using them together
This is the natural fit. Keep your CDR as the system of record, and let Medblocks be the pipeline into it. We connect to your sources, deduplicate and normalize the data, then export clean FHIR straight into Medplum, Aidbox, HealthLake, or any FHIR server you run. You get one modeled record in the repository you already chose.
Not sure if this fits you?
Tell us what you're building and we'll show you exactly what you can integrate.