EHR Software Development Company: Build or Integrate?

If you’re shopping for an EHR software development company, start with a question most of them won’t ask you: are you sure you should build a new EHR at all? Almost nobody should. As of 2024, 91% of US office-based physicians had already adopted a certified EHR. Your customers aren’t waiting for a better chart. They’re on Epic, athenahealth, or Oracle Health right now, and the job that actually pays is usually plugging your product into the one they already run, over FHIR R4, not building a rival to it.

We’re gmware, a custom software development firm in Austin, TX with engineering centers in Bangalore and Mohali, India, and EHR-connected builds are part of our healthcare delivery history. This post is the conversation we have before any statement of work exists: build a new EHR or integrate with an existing one, which standards a real build has to speak, what ONC certification actually obligates you to, and where the interoperability rules (info-blocking, TEFCA) sit in your architecture.

One opinion up front, and we’ll defend it. “We’re building an EHR” is one of the most expensive sentences a healthcare founder can say, and nine times out of ten the thing they actually need is an integration wearing an EHR’s clothes.

Should you build a new EHR or integrate with an existing one

Here’s the fork that sets everything else. Building a new EHR means creating the system of record clinicians chart into all day. Integrating means connecting your product (a scheduling tool, a patient app, an AI triage layer, a specialty workflow) to the EHR the clinic already trusts. These are not two sizes of the same project. They’re different projects with different risk, and the second is usually the right one.

The math is unforgiving for the build side. To sell a full EHR that clinics can bill Medicare through, you eventually need to clear the ONC Health IT Certification Program and conform to USCDI, on top of building the software itself. The integration path skips all of that, because the certified EHR you’re connecting to already carries that weight. You reach the same 91% of physicians, at a fraction of the cost and years off the timeline.

There’s a narrow lane where building makes sense: a specialty so underserved that no general EHR fits its workflow, a business model that depends on owning the record, and funding that can survive a multi-year certification program before revenue. That’s a real lane. It’s just a lot narrower than the number of decks that claim to be in it.

What standards EHR software development has to speak

Whichever path you pick, the software has to talk in the healthcare data languages, and there are really two that matter. New work rides on FHIR. Legacy hospital data still moves over HL7 v2. Serious builds speak both, because the systems you need to reach don’t all live in the same decade.

FHIR R4 is the modern one, a REST API with JSON resources your web team already knows how to work with. In the US you don’t just build “to FHIR,” you build to the US Core Implementation Guide, which is built on FHIR Version R4 and defines the minimum constraints (profiles) for US Realm data exchange. US Core is the floor. It maps to USCDI, the government’s required data set, so if a payer or a certification program says “support USCDI,” US Core profiles are how you actually do it in FHIR.

HL7 v2 is the older pipe-delimited messaging standard, and it hasn’t gone anywhere. Hospital ADT feeds, lab results, and billing messages still flow over it. The catch with v2 isn’t parsing (libraries handle that); it’s that every site’s feed is effectively its own dialect, so “we support HL7 v2” really means “we’ll build and maintain a custom mapping per site.” We broke that build-vs-run tradeoff down in detail in our EHR integration cost guide, which carries the per-vendor numbers this post deliberately doesn’t repeat.

The practical rule: default to FHIR R4 and US Core for anything new, and reach for HL7 v2 only when it’s the only door a given hospital system offers. Don’t pick a standard by preference. Pick it by which one the data you need actually travels on.

What ONC certification really obligates you to

This is where build and integrate split hardest, so it’s worth being precise. The ONC Health IT Certification Program is voluntary. That word trips people up. It’s voluntary in the way a driver’s license is voluntary: nothing forces you to get one until you want to do the thing that requires it. For EHRs, that thing is participation in the CMS Promoting Interoperability Programs, where certified products are mandated, which is how a huge share of providers get reimbursed.

So if you’re building the full system of record and your customers will bill Medicare through it, certification stops being optional in any meaningful sense. You’re signing up for standards conformance, testing against adopted criteria, and the CHPL listing, all before a clinic can use your product to get paid. That’s a program, not a sprint.

If you’re building a product that integrates with a certified EHR, the certification burden sits with that EHR, not you. Your app can pull demographics, push a note, or surface a risk flag without ever entering the certification process yourself, because the certified system is the one carrying the conformance. That asymmetry is the single strongest argument for the integrate path, and it’s the one most build pitches quietly skip.

The interoperability rules your architecture has to respect

Two federal rules shape how EHR data moves, and both should be design inputs, not afterthoughts you retrofit.

The first is information blocking. Under the 21st Century Cures Act, the information blocking rule bars practices that interfere with the access, exchange, or use of electronic health information, and it applies to healthcare providers, developers of certified health IT, and health information networks. There are ten exceptions under 45 CFR Part 171 for legitimate reasons like privacy and preventing harm, but the default posture the rule expects is open, standardized access. HHS OIG investigates, and a final rule sets disincentives for providers. The engineering translation: build the standardized data-access paths in, and don’t design gates that make data hard to get without a documented exception.

The second is TEFCA. The Trusted Exchange Framework and Common Agreement is a nationwide health-information-sharing framework from HHS and ONC, with Qualified Health Information Networks (QHINs) as its backbone; the first QHINs were designated in December 2023. For almost every product, you don’t connect to TEFCA directly. You connect through a QHIN or through an EHR that already participates. Becoming a QHIN yourself is roughly a 12-month designation process, so treat it as a mature-stage move, not a v1 line item. The right early question is simpler: which QHIN or participating EHR is my fastest path to the exchange I actually need?

What PHI and audit actually add to an EHR build

Every path that touches patient data carries a compliance load that sits on top of the feature work, and it’s the load most estimates hide. On healthcare builds, HIPAA engineering (encryption, audit logging, role-based access, BAA management, and penetration testing) typically adds 20% to 30%, or $15K to $40K to the initial build. That’s not a tax you can skip. Every PHI access has to be logged and queryable, every role has to see only its slice, and the whole thing has to survive an audit.

The reason to take that line seriously is on the downside. Healthcare had the highest average data-breach cost of any industry at $7.42 million in IBM’s 2025 report. Against that number, the compliance premium is the cheapest insurance in the project. We run production data systems ourselves (Shield Suite ingests retail intelligence across more than 60,000 beverage-alcohol storefronts), so the access-control and audit discipline in this section isn’t theory we read in a guide. It’s how our own systems have to work.

And the recurring cost doesn’t stop at launch. Interfaces have their own upkeep: plan on $3K to $15K per interface per year, because both ends of the pipe move. EHR vendors version their APIs, health systems upgrade on their own calendars, and a single renamed field can break a mapping at 2am. Budget the maintenance before you sign, not in year two when it arrives uninvited.

When building a new EHR is actually the right call

Here’s the honest verdict, and it’s the one most EHR development pitches skip because it argues against the biggest possible engagement.

For the overwhelming majority of healthcare products, don’t build a new EHR. Integrate. The market already standardized on certified systems, your customers won’t switch, and the certification program you’d take on to sell a full EHR is a multi-year cost with no revenue until it clears. If you need scheduling, a patient portal, an AI layer, or a specialty workflow, that’s an integration project, and it reaches the same clinicians for $15K to $150K+ depending on read-only versus bidirectional scope instead of a ground-up build.

Build a new EHR only when three things are all true. Your specialty is genuinely underserved, so no general EHR’s workflow fits (think a niche with charting no major vendor supports). Your business model depends on owning the record itself, not just touching it. And you’re funded to survive the certification and conformance program before the first billed seat. If any one of those is missing, you’re building a harder, slower version of a product you could have integrated your way into, and we’ll tell you so before you spend the money.

How gmware approaches EHR software development

We run EHR work as fixed-scope engagements out of our healthcare software development practice: Austin-based leads own discovery, the data-flow map, the standards call (FHIR R4 and US Core versus HL7 v2 per source), and the compliance architecture on US hours, while our Bangalore and Mohali teams build. Compliance gets designed into the first sprint, because audit logging and access control retrofitted onto a finished app cost more than designing them in.

The first thing we do is pressure-test build versus integrate, out loud, before there’s a quote. If the answer is integrate (it usually is), we scope the interface tier and the standards, and the per-vendor numbers live in our EHR integration cost breakdown. If your product leans on a model (triage, summarization, coding support) rather than plain data movement, our AI agents and LLM integration practice scopes that layer with evaluation and guardrails built in, not bolted on. And if you’re weighing a full clinical platform, our telemedicine software development guide walks the compliance, video, and budget calls that a broader build sets off.

We’ll also tell you when not to hire us. If a certified EHR’s own marketplace already has an app that does what you need, buy it; integration is a means, not a trophy. And if you’re still validating whether providers will adopt at all, prove that with the smallest integration that works before anyone talks about building a system of record.

Tell us which EHRs you need to reach and whether you’re building or integrating. Reach out and we’ll come back within 48 hours with a straight read on the build-vs-integrate call, the standards, and the scope.