Who Owns Your Custom EHR? A Straight Answer on IP Ownership

Why Does “Who Owns This EHR” Even Need Answering?

A founder who came to us to build a patient-owned EHR for alternative-medicine providers stopped mid-negotiation over four words in our contract: “you would license certain parts.” She wasn’t being difficult. She’d spent two years raising money on the premise that the platform itself, not just the practices using it, was the asset. Licensing language meant we’d retain rights to the thing she’d pitched investors on.

That stopped the deal cold for about two weeks.

We’ve had this conversation more than once. Enough that it changed how we write contracts. And here’s the uncomfortable part: most buyers walk into an EHR build assuming ownership works the way it works for a car or a laptop. You pay, you own it. Software doesn’t work that way. Copyright law hands authorship to the creator by default, not the payer, and that single fact surprises founders who’ve otherwise done their diligence on everything else.

It matters more for some buyers than others. A practice buying custom scheduling logic for internal use only can often live with looser terms. A founder building a platform they intend to commercialize, license to other practices, or eventually sell can’t. If the IP isn’t unambiguously theirs, the cap table conversation gets awkward fast, and so does the acquisition conversation three years later.

So we changed our default. Full IP assignment, not licensing, is now the starting position on every custom EHR engagement we scope. More on exactly what that means and why later in this piece. First, the part almost nobody explains clearly: what “ownership” legally means when the product is software.

Request an Assessment for your custom EHR build if you’re already evaluating a custom EHR development partner and IP terms are one of your open questions.

Does Paying for Custom Software Mean You Own It?

No. Not automatically, and not in the way most founders assume.

Under US copyright law, authorship, and with it default ownership, vests in the creator at the moment the work is fixed in a tangible form. That’s the developer or the development firm, not the party paying the invoice. The only exceptions are actual employees creating work within the scope of their employment, or a narrow list of statutory work-for-hire categories, and even those require a signed written agreement to apply. A services engagement with an outside vendor doesn’t automatically qualify.

Here’s the sentence that trips people up: “we paid for it” is not, on its own, a legal argument. Payment establishes a contract exists. It doesn’t establish who owns the code that contract produced. Ownership is a separate clause, and if that clause isn’t written, isn’t specific, or says “license” instead of “assign,” the default legal position is the developer keeps the rights.

We’ve watched sophisticated founders miss this. People who’ve done three rounds of fundraising, who read cap tables for fun, who still assumed a signed SOW meant they walked away owning the platform. It’s an easy assumption to make because it’s true for almost everything else you buy. But software isn’t a car or a laptop, and the gap between that assumption and the legal reality is exactly where the surprise clause lives.

Actually, let me refine that. It’s not that founders are careless. It’s that the ownership question hides inside contract language nobody reads for pleasure, and the vendor rarely brings it up first.

Whether you’re planning to build custom or evaluating an off-the-shelf platform first, this is the question to settle before you sign anything, not after.

Work-for-Hire vs. Licensing vs. Full IP Assignment: What’s the Difference?

Three models, one real distinction: does the contract say “assign,” and does that assignment cover everything you’re paying to build?

• Work-for-hire: Ownership transfers to the commissioning party automatically, but only under narrow statutory conditions (true employment, or specific categories like a contribution to a collective work) and only with signed written terms in place before the work starts. Rarely applies cleanly to an outside development firm.
• Licensing: The developer or agency keeps ownership. You get usage rights, scoped by the license terms: exclusive or non-exclusive, perpetual or term-limited, transferable or not. This is what nearly derailed the engagement we opened with. Usage rights are not ownership, even when the license is generous.
• Full IP assignment: An explicit clause transferring all rights, title, and interest in the work product to the client. This is the model that actually matches what most founders expect when they say “I own what I paid for.”

The difference lives in the contract’s actual word choice, not in the spirit of the relationship. “We’re partners in this” doesn’t override a licensing clause. If the document says “grants a license to use,” that’s what governs, regardless of how the sales conversation went.

How Do We Structure IP Ownership on Custom EHR Builds?

Here’s what our contracts say by default: full IP assignment. The client owns the application layer outright, everything we build specifically for them, including custom workflows, data schemas, and integration logic. That’s the starting clause, not the negotiated concession.

It wasn’t always the default. It became the default after the negotiation we described at the top of this piece. We looked at our standard services agreement afterward and found the licensing language wasn’t malicious or even unusual for a services firm. It was just old, written for a version of Mindbowser that built internal tools and integrations more often than commercializable platforms. It hadn’t caught up to who we actually build for now.

So we rewrote it. Full assignment on the application layer, disclosed and separate treatment for anything we reuse across engagements (our internal accelerators and reusable frameworks, which stay ours and are named upfront, not buried three schedules deep in an appendix).

Proof this doesn’t slow anything down: we shipped an AI-native EHR for a precision-medicine and longevity practice on Medplum, full IP assignment from day one, and still hit a 70% reduction in provider documentation time from the ambient scribe component and a sub-90-day deployment window. And the ownership terms and delivery speed were never in tension. Full ownership didn’t cost the client a week of schedule.

What stays separate, and this is the part vendors sometimes gloss over: our own reusable frameworks and accelerators. If we built a piece of internal tooling before your engagement and reuse it inside your build, that component isn’t automatically your IP just because it touches your codebase. We disclose which pieces those are during scoping, not after delivery. If a vendor can’t name their reusable components when you ask, that’s worth pushing on before you sign.

If you’re scoping a custom EHR build and want to see how we structure this in an actual SOW, request an assessment and we’ll walk the IP clause line by line before anything gets signed.

Does the Platform You Build On Change What You Own?

Ownership of the application you commission is one question. Ownership of the platform underneath it is a different one, and founders conflate the two more than you’d expect.

Medplum’s Apache 2.0 source code is open. The entire platform, self-hostable, no proprietary lock on the underlying FHIR (Fast Healthcare Interoperability Resources, the data standard most modern EHRs exchange clinical records through) layer. If you build on Medplum, the platform itself was never anyone’s to license to you in the first place, it’s already open.

Canvas Medical’s proprietary backend works differently. You’re customizing their platform through an SDK and plugin layer, not owning the underlying EHR engine. Your customizations can be yours by contract. The platform under them stays Canvas’s.

Oystehr’s licensing model sits in between: only the Ottehr frontend is open source, the backend stays proprietary, similar to Canvas in practice if not in branding.

None of that changes what happens at the application layer, the part Mindbowser builds on top, regardless of which platform sits underneath. That’s governed entirely by the services contract, not by the platform’s open-source status. A founder building on Canvas can still walk away with full IP assignment on their custom application layer. They just can’t walk away owning Canvas’s core EHR engine, because nobody ever offered to sell them that.

What About AI-Generated Code? Who Owns That?

This one’s live and genuinely unsettled, worth a short flag rather than a full section.

The US Copyright Office holds that AI-generated output without substantial human authorship isn’t copyrightable at all. Not licensed, not assigned, not owned by anyone. The Supreme Court declined to hear Thaler v. Perlmutter in March 2026, which left that human-authorship requirement standing. Separately, Doe v. GitHub Copilot is now on appeal to the Ninth Circuit, testing how much AI-assisted code generation counts as human-directed work versus machine output.

For an AI-native custom EHR build, ambient scribe components, AI-assisted code generation in our own delivery pipeline, the practical answer lands close to the human-written-code answer: it needs to be substantially human-directed, and it needs to be explicitly assigned in the contract to be defensibly yours. “Our platform used AI” doesn’t answer the ownership question on its own. The contract still has to say who owns the output.

We don’t think this area settles cleanly in the next 18 months. Worth asking any vendor directly how they handle AI-assisted code in their assignment clause, not assuming it’s covered by the same boilerplate that covers human-written code.

What Should You Put in Writing Before You Sign?

Four questions, and one deadline for asking them: before kickoff, not during it.

1. Does the contract say “assignment” or “license”? Read the actual word. Not the pitch deck, not the sales call notes, the document you’re about to sign.

2. When does ownership transfer? On signing, on delivery, or on final acceptance? Timing matters if the relationship ends mid-build. A clause that transfers ownership only on final payment leaves you exposed if the engagement stalls at 80% complete.

3. What does the vendor retain? Reusable frameworks, internal accelerators, anything that predates your engagement. Ask for this in writing, disclosed as a specific list, not a general carve-out clause.

4. Does the platform license affect your exit options? If you’re on a proprietary backend and switch vendors later, what do you actually take with you, versus what stays locked to that platform relationship?

Get all four answered in writing before kickoff. A verbal assurance from a sales call doesn’t survive a dispute. A signed clause does.

Evaluating a custom EHR development partner more broadly? This checklist is one line item in a longer evaluation, and it’s usually the one that gets skipped.