Should You Build Your Custom EHR on Medplum Yourself, or Bring in a Partner?

Why This Question Comes Up Right After You Pick Medplum

I’ve sat across the table from more than one physician-founder who built a working prototype, picked Medplum as the platform, and then hit the exact same fork: keep building it themselves, or bring in help.

It’s not a coincidence, and it’s not a red flag either. It shows up right after a team runs the Medplum vs Healthie vs Canvas vs Oystehr comparison and lands on Medplum specifically, because Medplum is the platform that makes DIY look genuinely plausible. Apache 2.0 core, a FHIR-native data model out of the box, no per-seat licensing wall. Compare that to a closed platform and the “can we just build this ourselves” question barely comes up. On Medplum, it comes up constantly.

Here’s the part that doesn’t help: almost nothing written about this decision is actually neutral. Implementation-partner sites sell the partner path without honestly scoping what DIY takes. Medplum’s own documentation is instructional, not evaluative, it tells you how to install a self-hosted instance, not whether your team should. I went looking for a page that gives the two-sided answer before writing this one. Couldn’t find it. That’s the gap this piece is trying to close.

The honest answer depends on four specific things, and I’ll walk through all four before I tell you what I’d do in your seat. First, though, you need the unvarnished list of what building on Medplum yourself actually requires, because that’s the part everyone glosses over in thirty seconds and it deserves more than that.

What Building on Medplum Yourself Actually Requires

Let’s be direct about this, because vague answers here are how teams end up three months into a build they underscoped.

Real FHIR fluency, not a weekend of reading. Resources, references, search parameters, terminology systems, Bundle handling. If your team hasn’t worked with HL7 FHIR before, this is a genuine learning curve, not a checkbox. I’ve watched engineers who are excellent generalists spend six to eight weeks just building the mental model for how FHIR resources reference each other before they’re productive on a real feature.

Tenant isolation is on you. Medplum doesn’t ship built-in multi-tenant data isolation. Medplum’s own June 2026 post on building with AI coding assistants puts it plainly: a wrong access policy “does not throw an error, it quietly exposes data.” If you’re serving more than one organization, and most custom EHR builds eventually do, that isolation logic is application-layer work you own, and getting it wrong doesn’t fail loudly. It fails silently, which is worse.

HIPAA compliance on a self-hosted deployment is partially DIY. Medplum’s own compliance documentation states it directly: “compliance is a shared responsibility.” The hosted, Medplum-managed environment carries SOC 2 Type 2, HIPAA, and (as of June 2026) HITRUST e1 certification built in. Self-host it yourself, and encryption configuration, audit logging, access controls, and BAA management with your hosting provider move to your side of that shared line.

Medplum’s self-hosting best-practices guide covers infrastructure hygiene well, private subnets, bastion hosts, secrets rotation, centralized logs, but it doesn’t cover HIPAA obligations or encryption standards at all. That gap isn’t an oversight. It’s the boundary of what a platform vendor can own for you.

An infra cost floor that’s real but not scary. Across the self-hosting write-ups I’ve read this year, the consistent range is $200 to $500-plus a month in AWS spend for a self-hosted Medplum instance, on top of the engineering time to set it up and keep it running. That’s not the number that kills a DIY build. The engineering time is.

The ONC certification pathway is real work, even with self-attestation. Medplum itself achieved ONC certification (Unique Certification Number 15.04.04.3147.Medp.05.03.1.251231) at the end of 2025, and its documentation is upfront that self-attested criteria still require a documented Real World Testing Plan with results tracked year over year. Self-attestation means you’re not sitting through a live examiner session for every criterion.

It doesn’t mean there’s no documentation discipline involved. Teams that treat it as a checkbox find out otherwise during their first audit cycle.

The Honest Case for Doing It Yourself

Some of this is going to sound like I’m talking myself out of a job. I’m not.

If your team already has FHIR and backend-healthcare depth, DIY on Medplum genuinely works. That’s not a hedge, that’s the actual case. Medplum is built for exactly this: an Apache 2.0 core, a REST and GraphQL API surface that doesn’t fight you, and a data model that doesn’t require you to reverse-engineer a proprietary schema before you can write your first feature. Teams with the right background ship real clinical software on it.

MVP and early-validation stage also favors DIY, for a reason that has nothing to do with technical difficulty. It’s capital allocation. Rapid prototyping without a big upfront partner spend lets you validate the clinical workflow before you commit real budget to the infrastructure around it. That sequencing matters more than people give it credit for.

In the builds I’ve watched succeed on the DIY path, three traits show up together, almost every time: in-house FHIR experience already in the room (not “we’ll learn it”), a scope small enough to avoid the multi-tenant complexity early (single org, single deployment, at least at first), and enough runway to absorb a real learning curve without the timeline pressure forcing corners to get cut.

If none of those three are true yet for your team, the math changes. That’s not a judgment on the team. It’s just the actual variable that decides whether DIY is the efficient path or the expensive one.

You can also build a substantial amount of real functionality on Medplum’s Apache 2.0 core before you hit the wall where the depth requirements above start to bite. That’s worth knowing going in. The wall exists. It’s just further out than most teams assume on day one.

Where DIY Quietly Turns Into a Partner Problem

Here’s the failure pattern, told plainly, because the vague version of this (“things can get complicated”) is useless.

The timeline creep is the most common thing that shows up around month six. Teams that thought they’d ship clinical workflow in a quarter are still building infrastructure. Not because they’re slow. Because the infrastructure kept surfacing requirements nobody scoped at the start.

ONC certification timeline creep is a specific version of this. Self-attestation doesn’t remove the internal ownership most early teams underestimate. Someone has to run the Real World Testing Plan, document it, and keep it current. That someone is usually the same engineer who’s also trying to ship the next clinical feature, and one of those two things loses.

Multi-tenant isolation, HIPAA audit logging, and general compliance debt compound quietly. None of them fail loudly in week two. They surface all at once, usually during a security review or funding diligence, which is the worst possible moment to discover three gaps at the same time.

The real tell, if you want one signal to watch for: the roadmap keeps getting reprioritized around infrastructure instead of the clinical workflow that was the actual point of building custom in the first place. When your sprint planning is dominated by “fix the access policy” and “patch the audit log gap” instead of the feature your users are asking for, that’s the signal, not a vague sense that things feel harder than expected.

And the compliance surface isn’t holding still while you catch up. Medplum achieved HITRUST e1 certification for its hosted AWS environment in June 2026, part of what it called “a key commitment on the compliance theme of our 2026 roadmap.

” Separately, CMS-0057-F and HTI-4 require payers and providers to support electronic prior authorization workflows built on FHIR, specifically Coverage Requirements Discovery, Documentation Templates and Rules, and Prior Authorization Support, with enforcement beginning January 2027. If your platform touches prior auth at all, that’s a deadline, not a someday.

What a Partner Actually Buys You (Beyond Just Speed)

It’s not “faster.” That’s the wrong frame, and it undersells what’s actually on the table. What a partner buys you is fewer decisions you don’t know you’re making yet.

Tenant isolation and access-control patterns arrive already solved, not re-invented from scratch on your specific project. That’s the difference between a pattern that’s been through a security review before and one that’s getting its first real test on your production data.

HIPAA-compliant data handling shows up as a layer, not a per-project scramble. This is honestly what PHISecure does at Mindbowser: it’s a compliance layer built to handle PHI de-identification across the data types custom clinical platforms actually touch, DICOM, NIfTI, video, image files, so that HIPAA-safe data sharing for research or downstream AI use isn’t something every team rebuilds from first principles. I’m naming it here because it genuinely fits this specific problem, not because it’s the accelerator on the shelf closest to hand.

ONC certification pathway experience means knowing which criteria to batch and in what order, and knowing what a Real World Testing Plan actually needs to look like before your team learns it live on your own deadline.

And there’s a proof point worth naming honestly: a Seed-stage precision-medicine and longevity platform built on Medplum shipped in under 90 days with a 70% reduction in provider documentation time, using an AI ambient scribe layered on top of the FHIR-native core. That’s not a hypothetical. That’s what “a partner already having the pattern” looks like in a real timeline.

If you bring in a partner, what your contract says about who owns the resulting code matters just as much as the build itself, especially if you’re planning to commercialize what gets built. That’s a separate conversation, but it’s one to have at the same table as this one, not after.

A Decision Framework: Four Questions Before You Decide

Here’s the actionable version, the part you can actually use this week.

Does your team have in-house FHIR and backend-healthcare depth right now, not “can learn it”? Be honest about the difference between “we’ve read the spec” and “we’ve shipped against it.” Those are not the same team.

Will you serve more than one tenant or organization in the next 12 months? If yes, tenant isolation stops being a someday problem and becomes a now problem, because retrofitting isolation into a single-tenant architecture is far more expensive than building it in from the start.

Do you have a funding or diligence timeline that a compliance gap could jeopardize? If an investor’s technical diligence is on your calendar in the next year, a HIPAA or ONC gap discovered mid-process is a worse outcome than the cost of closing it now.

Is your actual differentiation the clinical workflow itself, or the infrastructure underneath it? If it’s the workflow, and for most custom EHR builds it is, the infrastructure shouldn’t be eating the runway that should be going toward the thing that actually makes your product different.

Four questions, and the pattern is usually clear by the time you’ve answered them honestly. Teams answering “yes” to depth and “no” to the multi-tenant timeline tend to land on DIY. Teams answering “no” to depth or “yes” to an imminent diligence event tend to land on a partner, or the blended model I’ll get to next.

You can pull the deeper version of this into a fuller partner-evaluation checklist once you’ve got a directional answer from the four questions above.

Where a Blended Approach Actually Beats Either Extreme

Most real builds I’ve seen aren’t fully DIY or fully outsourced. They’re blended, and the blend usually isn’t an accident; it’s the right call once you actually run the four questions above.

The common pattern: your internal team owns the clinical workflow and the UI layer, the part that’s actually your differentiation, while a partner handles FHIR infrastructure, compliance, and the ONC pathway underneath it. That split isn’t a compromise. It’s literally what Medplum’s own architecture is built for, a headless FHIR backend with your custom application layer sitting on top of it. The platform was designed assuming a separation between the plumbing and the product.

Here’s the honest limit, though, and I want to be direct about it rather than gloss over it: no accelerator, no partner pattern, no amount of infrastructure help shortcuts the actual clinical logic specific to your specialty. If you’re building for functional medicine, or acupuncture, or a niche surgical specialty, someone still has to design that clinical workflow by hand, because it doesn’t exist in a reusable form anywhere else.

Pretending otherwise, that a partner or an accelerator makes the specialty-specific clinical design disappear, would be dishonest, and I’d rather tell you that plainly than sell you a shortcut that doesn’t exist. The architecture guide I wrote on building on Medplum covers the mechanics of that layered approach in more depth if you’re at the point of actually laying it out.