Who Runs Your Custom EHR After We Hand It Off? Here’s the Actual Support Model

Why This Question Comes Up Before the Contract Is Even Signed

A founder asked me almost this exact question in an evaluation call last month, before we’d even finished scoping the build: “So when you’re done, what actually happens?” Not hostile. Just direct. And it’s the right question to ask before you sign anything, not after.

I’ve sat through this conversation more times than I can count. It’s not a hypothetical objection somebody made up for a sales deck, it’s a real, current thing digital health founders ask before committing to a build partner. Most proposals answer it with one vague line, something like “ongoing support available,” and move on. Our own partner-evaluation checklist names the exact pattern as the bad answer: “we hand off the code and you maintain it” is, in that piece’s words, a ticking time bomb.

Here’s the part that surprised me when I went looking at what’s actually published on this. Generic dev-shop SLA pages cover tier structures fine, but they have zero healthcare specificity. HIPAA vendor-management content covers access control thoroughly, but it’s written for a compliance audit, not for a founder trying to figure out who to call. Nobody combines an honest support model with the clinical-platform context and the compliance layer in one place. So that’s what this piece tries to do.

Five parts to the real answer. I’ll walk through all of them in order, and I’m not going to skip the parts that are actually inconvenient for us to admit.

If you’re still deciding whether to build on something like Medplum yourself or bring in a partner at all, that decision sits one step upstream of this one and it’s worth working through first. And if you want the fuller version of the evaluation questions this piece answers in depth, our partner-evaluation checklist has “what happens after launch” as question seven of ten. This is the long answer to that question.

What “Hypercare” Actually Means in the First 90 Days

Hypercare is a defined window, not an open-ended “we’re around if you need us.” Industry practice puts it at 30 to 90 days right after go-live, and on a clinical platform I’d push toward the longer end of that range unless the rollout is genuinely small.

Here’s why the window has a hard edge instead of fading out gradually. The same team that built the platform staffs hypercare, not a separate support desk that’s never seen the codebase. That continuity matters most exactly when it’s hardest to arrange, which is the first weeks real patient and clinical volume hits a system that’s only ever seen test data and a UAT script.

I’ve watched this play out enough times to trust the pattern. Clinical-workflow surprises don’t show up during user acceptance testing. They show up in week three, when a front-desk scheduler hits an edge case nobody scripted for, or a specialty workflow behaves differently under real patient volume than it did with twelve test records. UAT tells you the software does what the spec said. Hypercare tells you what the spec missed.

What changes at the end of the window isn’t arbitrary either. It’s a deliberate handoff from the build team’s full attention to a defined tiered-support structure, and the transition point gets set at kickoff, not improvised near the end. If nobody can tell you when hypercare ends and what happens the day after, that’s worth asking about before you sign.

The Support Tiers After Hypercare Ends (and Who’s Actually on Each One)

Once hypercare ends, support has to be severity-based, not one-size-fits-all. A patient-facing charting screen going down and a cosmetic label being off by a pixel are not the same emergency, and a contract that treats them the same is a contract that will fail you exactly when it matters.

The standard shape, adapted for a clinical platform: P1 critical issues, meaning patient-facing charting, scheduling, or clinical documentation is down or corrupting data, get a 1 to 4 hour response with 24/7 coverage. P2 high-severity issues, meaning a workflow is broken but there’s a manual workaround, get same-business-day response. P3 and P4, cosmetic issues and minor enhancements, get a multi-day window, typically 3 to 10 business days.

Here’s the detail that gets missed on a generic app and can’t get missed on a clinical one: what counts as P1 has to be defined explicitly in the contract before launch, not assumed from a generic SaaS template. On a generic app, a broken checkout button might be P2. On a clinical platform, a broken charting screen during a patient encounter is P1, full stop, and if that’s not written down in plain language before go-live, you’ll find out the hard way during an actual incident.

Who’s actually staffed on each tier matters too. Helpdesk-level triage on P3/P4 doesn’t mean the engineers who wrote your integration logic are unreachable, it means they’re not the first line for a typo fix. On P1, the people responding are the same people who understand the architecture, not a generic support queue reading from a script.

Bug Fix or New Feature? The Line That Actually Matters in the Contract

Here’s the most common dispute point in vague maintenance retainers, and I mean the most common one, not a hypothetical: “bug fixes included” without a defined line between a bug and a change request. I’ve seen this exact ambiguity turn a healthy client relationship tense within a single support cycle.

The actual line, and it’s not complicated once you write it down: corrective and adaptive work is maintenance. That means fixing something that doesn’t match its original spec, or adjusting to a changed external environment, an API version bump, a browser update, a payer format change. Expanding functionality, redesigning a workflow, or adding a new integration is new development. Different track, different scope, different conversation.

That line has to be written into the statement of work before launch. Not negotiated in the middle of a dispute, when both sides are already annoyed and the trust that made the original deal easy to close has started to erode.

This is also, plainly, the model our own institutional maintenance and support service runs on. I’m naming that here because it’s the actual mechanism, not a marketing flourish, the same tier logic that governs a general product-maintenance engagement is what governs post-launch support on a custom EHR, just with the clinical-severity layer from the previous section stacked on top.

What We Actually Document Before Anyone Leaves

Architecture documentation, runbooks for operational systems, and a searchable knowledge base are the baseline. Not a nice-to-have, not a deliverable you get if you ask for it, the baseline.

Actually, let me refine that. Documentation is the baseline for a generic software handoff. For a clinical platform it’s necessary but not sufficient on its own, which is the distinction the rest of this section is really about.

For a clinical platform specifically, documentation has to cover the clinical-workflow decisions themselves, not just the code. Why a specialty-specific intake flow was modeled the way it was matters as much as how the API endpoint is structured, because the next engineer who touches that workflow needs to know the reasoning, not just the implementation.

The actual mechanics, and this is where handoffs quietly fail: real knowledge transfer isn’t a single meeting with a slide deck. It’s overlap. Pair-programming sessions before a team transition, where the incoming and outgoing engineers work the same ticket together. A shadow period where the new team handles real tickets with the original team still reachable. One meeting doesn’t transfer three months of context on why a HIPAA edge case was handled the way it was. Overlap does.

What I’d actually tell a founder to check before signing: ask to see a sample runbook or architecture decision record from a past engagement, not a description of the process. If a partner can’t show you a real artifact, that’s the same red flag as the vague “ongoing support available” line from earlier.

The HIPAA Layer Most Support Contracts Skip

Ongoing support on a clinical platform isn’t just uptime. It’s who has access to protected health information during that support, and whether that access is logged and reviewed.

The HHS Security Rule sets specific access-control and audit expectations that most generic software support contracts never touch. Least-privilege access, meaning support staff get exactly the access their current task needs, not a standing admin account. Just-in-time elevation for admin tasks, meaning elevated access is granted for the task and revoked after, not left open. Quarterly access recertification, meaning someone actually reviews who still has access and why, on a schedule, not whenever someone happens to remember.

Audit logging has to capture individual user IDs on every access event, not a shared support-team login where you can’t tell which specific person touched a record. Break-glass controls, meaning emergency access that bypasses normal restrictions in a true incident, require mandatory post-incident review every time they’re used, not just when someone escalates a complaint. And the HHS-published audit log guidance points to a 6-year retention requirement on audit records, which most teams don’t think about until an audit actually asks for them.

Here’s the part that actually breaks this layer in practice, and it’s not malice, it’s turnover. This access model has to survive a support-team roster change. Someone leaves, someone new joins, and if quarterly recertification isn’t a real, scheduled process rather than a line item in a proposal, that’s exactly when a standing account gets forgotten and sits open for months.

Can You Bring This In-House Later? (The Honest Answer)

Yes, genuinely, and I want to give you the real conditions instead of the safe non-answer. It’s not “you’ll always need us.” It’s a real path with real requirements.

The condition that matters most: your internal team’s clinical-data and FHIR depth has to get built during the hypercare window, not asked for after everyone’s already moved on. If your engineers are shadowing real tickets in month one, an in-house transition in month six is realistic. If nobody on your team has touched the codebase until you’re trying to take it over, that’s a much harder six months, not an impossible one, just harder than the pitch decks make it sound.

The actual path looks like this: an overlapping shadow period where your team owns tickets with the original team still reachable, a documentation-completeness test before the transition (can your engineer actually find and understand a runbook without asking us), and gradual ticket-ownership handoff rather than one cutover date on a calendar.

And here’s the honest limit, because I’d rather tell you this plainly than sell you a version that sounds better and isn’t true. No amount of documentation replaces the institutional memory of having actually built the specialty-specific clinical logic firsthand. If your platform handles a niche workflow, a specific intake pattern for a rare specialty, an unusual eligibility rule, someone still had to design that by hand, and reading about it in a runbook is not the same as having lived through the three iterations it took to get right. A clean in-house transition still takes real overlap time. It doesn’t happen over a long weekend, no matter how good the documentation is.

If your contract is silent on code ownership when you bring things in-house, that’s worth resolving before the transition, not during it, and it connects directly to how IP ownership actually gets structured on a custom build.

If you’re weighing this question for a real build and want a second set of eyes on where your specific support gaps might be, request an assessment and we’ll walk through it against your actual team and timeline, not a generic checklist.