EHR Software Development: Build, Buy or Build Around It

§ 01 · the short answer

Who should build an EHR, and who should not

Build a certified EHR only if the EHR is your product: a health IT company funded for certification testing now and for the duties that follow every year. Almost every practice and hospital is better served buying one, and nearly all already have. In 2024, 91% of US office-based physicians used a certified EHR, by ASTP/ONC Data Brief 84, and 99.4% of non-federal acute care hospitals had one, by Data Brief 83.

So the useful question for most buyers is narrower: which jobs does the EHR do badly, and can software beside it do them without touching the record? That second kind of software is the work we take on, for the clinics and health companies on our healthcare software page.

What we build beside an EHR

Patient portals for intake and consent forms, documents and secure messages.
Online scheduling across providers and locations, with confirmations and reminders.
Staff workflow modules: rosters, leave approvals, training records, intake queues and admin dashboards.

What we do not build

Certified EHR systems, or modules meant for ONC certification.
EHR integrations, including FHIR apps, FHIR API connections and HL7 interfaces.
Electronic prescribing, including controlled substances.
Claims engines and medical-device software.

Our builds neither read from nor write into your EHR. When a plan needs data to move between the two on its own, that interface belongs with your EHR vendor or an integration specialist, and we say so on the first call rather than after the budget is spent.

§ 02 · terms

EHR, EMR and practice software: four different systems

ONC, the federal office that runs EHR certification, separates the two terms: an EMR is the paper chart of one clinician's office made digital, while an EHR is designed to carry what it holds beyond the practice that collected it, to labs, specialists and hospitals. Vendors still sell under both names. Certification and Medicare's programs use EHR.

Four kinds of system a clinic runs, and which of them holds the chart
System	What it holds	Who uses it	Shares data outside the practice
EMR	One practice's charts: notes, problems, medications	Clinicians in that practice	Little; it was built for one office
EHR	The chart plus orders, prescriptions, results and care summaries	Clinicians, nurses and care teams across settings	Yes; a certified EHR must send care summaries and answer standard API requests
Practice management software	Schedules, registration, insurance and billing	Front desk and billing staff	Through claims and eligibility checks, not the chart
Patient portal	Forms, messages and visit history; results and notes when the EHR vendor runs it	Patients and the staff who answer them	Only what the EHR releases to it

A portal from us covers the part that does not need the chart: intake answers, uploaded documents, messages and appointment history. Clinical notes and lab results remain in the EHR's own portal. The patient portal service lists what one includes.

§ 03 · must-have functions

What a certified EHR has to do, criterion by criterion

Feature lists differ from vendor to vendor, but the federal floor does not. The Base EHR definition in 45 CFR 170.102 names the criteria a product must be certified to before it counts as certified technology in Medicare's programs. Here they are, each with its number in 45 CFR 170.315, so a developer's claim can be checked.

Demographics, (a)(5): Birth date, sex, race, ethnicity and preferred language, coded to the standards the rule names.
Order entry, (a)(1), (2) or (3): Clinicians place medication, laboratory or imaging orders in the system itself.
Implantable devices, (a)(14): A list of each patient's implanted devices, by unique device identifier.
Transitions of care, (b)(1): Sending and receiving a summary of care when a patient moves to another provider.
Decision support, (b)(11): Alerts and predictive tools shown while a clinician works, with source details users can review. Part of the definition since 1 January 2025.
Quality measures, (c)(1): Recording the data each clinical quality measure needs, and exporting it.
App access, (g)(7), (g)(9), (g)(10): Outside apps chosen by patients or providers can find a patient and request that patient's data, or a whole group's, over a FHIR API.
Direct messaging, (h)(1) or (h)(2): Secure transport of health information to other providers.
Prescription benefit, (b)(4): A real-time check of a drug's cost and covered alternatives while prescribing. It joins the definition on 1 January 2028.

Two more sets apply to almost every certified module, per ONC's certification process. The privacy and security criteria in section (d) cover sign-in and access control, tamper-resistant audit logs, automatic time-out, encrypted credentials and multi-factor authentication, among others. And a module that stores health information must export it, criterion (b)(10): one patient's whole record whenever a user chooses, and the whole patient population, in a documented format.

Above that floor sit the parts clinicians notice every day: specialty templates, how fast a note closes, the patient portal, prescribing, billing and reporting. Those are where products differ, and where a buyer should spend demo time.

§ 04 · care setting

A practice EHR and a hospital EHR do different work

A practice EHR runs scheduled visits: one clinician, one patient, a note, some orders and a bill. A hospital EHR runs around the clock across departments: admissions and transfers, inpatient medication orders, results from in-house labs and imaging, and handoffs between shifts. The certification rule reflects this, marking some requirements ambulatory setting only and others inpatient setting only.

Practice and hospital EHRs in the US: the Medicare program behind each, and who supplies them (2024 data)
Compared on	Practice EHR	Hospital EHR
Daily work	Booked visits, notes, orders, prescriptions, billing	Admissions, inpatient orders and medication, departmental results, shift handoffs
Medicare program requiring certified technology	The MIPS Promoting Interoperability category, under 42 CFR 414.1375	The Medicare Promoting Interoperability Program for eligible hospitals and critical access hospitals
Certified EHR use	91% of office-based physicians; 79.9% of solo physicians	99.4% of non-federal acute care hospitals
Leading developers	Epic 62.8%, Oracle Health 10.5% and athenahealth 7.8% of clinicians reporting to Promoting Interoperability	Epic 50.8%, Oracle Health 20.1% and MEDITECH 15.6% of non-federal acute care hospitals

Sources: Data Briefs 83 and 84 above, and ASTP/ONC Quick-Stat 30 for clinicians; a clinician can report products from more than one developer, so those shares overlap.

The numbers matter to anyone building beside an EHR. In more than four hospitals in five, a hospital tool sits next to one of three products, while clinicians reported certified products from 175 developers. Small practices vary most: only 32% of physicians in solo practice used a top-five EHR, against 90% in practices of more than 50 physicians.

§ 05 · HL7 and FHIR

HL7 Version 2 and FHIR: how EHRs share data

HL7 Version 2 is the older approach: one system sends a message, such as an admission or a lab result, and another receives it. The VA's technical reference model calls it the workhorse of clinical data exchange and says it carries most of the common interfaces in healthcare worldwide.

FHIR, Fast Healthcare Interoperability Resources, is HL7's newer standard. Data is split into resources, such as Patient, Encounter, Observation and MedicationRequest, which an app requests from a web API. It is the standard federal certification requires for the patient and population API, criterion (g)(10).

What the (g)(10) API must support

FHIR Release 4.0.1, shaped by the US Core profiles, with version 6.1.0 as the base.
SMART App Launch 2.0.0 for app registration, sign-in and permissions, with refresh tokens that last at least three months.
FHIR Bulk Data Access 1.0.0, for exporting a whole group of patients at once.
The data classes in USCDI version 3, the certification baseline since 1 January 2026 under the HTI-1 final rule.
TLS 1.2 or higher, and public documentation of the API.

From ONC's (g)(10) test method, last updated 15 May 2026, which also lists newer versions developers may adopt.

What this means for software beside an EHR: a certified EHR offers a FHIR API, but connecting to it is still integration work. The app has to be registered with that EHR's authorization server, tested against its sandbox, and kept working through its upgrades. We do not take that work on; we refer it to your EHR vendor or an integration specialist.

To learn the standard yourself, two free tools help. Epic on FHIR offers a testing sandbox with example data and app registration, and the SMART App Launcher lets a developer test an app with no registration at all.

§ 06 · build and certify

Six steps to build and certify an EHR

If the EHR is your product, building and certifying run together. ONC calls its certification program voluntary, but clinicians and hospitals in Medicare's Promoting Interoperability programs must use certified technology, so a product sold to them has to be certified. ONC does not test products itself: an ONC-Authorized Testing Laboratory (ONC-ATL) tests them, and an ONC-Authorized Certification Body (ONC-ACB) makes the certification decision.

Choose the criteria and the setting. Start from the Base EHR definition, add what your buyers report on, such as electronic prescribing or public health reporting, and decide between ambulatory, inpatient or both.
Model the data and code it. Problems, results and medications are stored in the vocabularies 45 CFR 170.207 names, such as SNOMED CT, LOINC and RxNorm, and shaped to USCDI, so they can be exchanged and exported later.
Build privacy and security in from the first release. The section (d) criteria sit beside the HIPAA Security Rule's technical safeguards in 45 CFR 164.312, and both belong in the first design, not a later release.
Build the exchange layer. The FHIR API under (g)(10), care summaries for transitions of care, Direct messaging, and the health information export under (b)(10).
Test and certify. Register with an ONC-ATL and an ONC-ACB, pass testing against ONC's test procedures, and receive certification, after which the product appears on the Certified Health IT Product List (CHPL).
Keep the certification. Submit a Real World Testing plan by 15 December each year and its results by 15 March, attest to the Conditions of Certification every six months, report Insights measures yearly as they phase in from July 2027, and accept surveillance by the certification body.

Step six never ends: the duties last as long as the product keeps its certification. ONC lists all seven conditions, from information blocking to Insights, on its Conditions and Maintenance of Certification page, last updated 16 April 2026.

§ 07 · regulatory load

The rules that come with holding the chart

Certification is one layer. A system that holds clinical records answers to these rules as well, and each one changes what the software must do.

HIPAA: The Security Rule's five technical safeguards: access control, audit controls, integrity, authentication and transmission security. Any vendor holding protected health information on your behalf needs a business associate agreement with you.
Information blocking: A developer of certified health IT may not interfere with access to, exchange or use of electronic health information unless an exception applies. The HHS Office of Inspector General says a violation can bring a penalty of up to $1 million.
Controlled substances: An electronic prescribing application needs a third-party audit, or a DEA-approved certification, before it handles controlled substance prescriptions, and again when those functions change or every two years, whichever comes first (21 CFR 1311.300).
Substance use records: Records from federally assisted substance use disorder programs carry their own consent and disclosure rules under 42 CFR Part 2, on top of HIPAA.
Medicare reporting: Clinicians reporting the MIPS Promoting Interoperability category must use certified EHR technology for the performance period, and attest that they cooperate with ONC review of it when asked. For hospitals, CMS ties the same certified technology definition to ONC's criteria.

§ 08 · buy or build

Buy a certified EHR, or build around one

For a practice, a clinic group or a health startup, the choice is rarely build against buy. It is which certified EHR to buy, and what, if anything, to build beside it. These are the five routes, with our part in each stated plainly.

Five ways to get EHR capability, what each leaves you carrying, and where Digital Heroes fits
Route	Fits when	What you carry	Our part
1. Build and certify your own EHR	The EHR is the product you sell, to clinicians or hospitals in Medicare's programs	Certification testing, then Real World Testing, attestations and information blocking duties every year	None. We do not build certified EHRs
2. Build an uncertified clinical record	Nobody using it reports to a program that requires certified technology	HIPAA wherever a covered provider uses it, no certified APIs, and certification work later if your market changes	None. Clinical records are outside our scope
3. Buy a certified EHR and configure it	Your specialty is well served and your workflows fit the product's templates	Subscription fees and the vendor's roadmap	None needed
4. Add the EHR vendor's own tools	The vendor's patient portal or app marketplace already covers the gap	Extensions follow the vendor's rules and release dates	None
5. Build beside a certified EHR	The gap is outside the chart: intake, booking, rosters, approvals, admin reporting	A second system to host and maintain, kept in step with the EHR by your staff	This is the work we do

Our view, from building on the staff and patient side of care: build where your service differs from everyone else's, and leave the chart to certified software. Route five rarely needs the EHR vendor's permission, because it never touches the record. A video visit service is a common case, and our telehealth app developers build it beside the chart.

Signs that route five fits

Staff retype intake answers from paper, email or PDFs before the visit.
Booking runs through phone calls because the EHR's scheduling cannot express your rules.
Rosters, leave and training records live in spreadsheets.
Managers export data every week to answer the same question.

To test the money side, our build vs buy calculator sets five years of a build's cost against subscription fees.

§ 09 · what we build

Portals, scheduling and workflow modules beside your EHR

Each of these is custom software that sits next to the record. It is scoped in writing, built in sprints of one to two weeks, and handed over with its code, which becomes yours once the final invoice is paid, under the terms on our custom software company page.

Patient portals

One sign-in for intake and consent forms, document uploads, secure messages and appointment history, with separate roles for patients, front desk and admins.

Scheduling and reminders

Self-serve booking across providers and locations, with confirmations, reminders by email or text, and reschedule links. What it includes.

Staff workflow modules

Rosters, leave approvals, training records, intake queues and admin dashboards: the operational work an EHR was not designed to run. What it includes.

client build · 2026 · planivo.me

A workflow module in practice: Planivo

Planivo plans the workforce of clinics and hospitals, and we built the whole platform and its website in 2026. It runs monthly shift rosters, vacation approvals in three levels that warn when two staff of the same speciality would be away together, tasks, training sessions with attendance, reminders before a certification expires, duty display screens and an audit history, across six roles.

It works on staff data, not patient charts, so it runs entirely beside the EHR. Shown with the client's permission; no results figures are published.

Planivo home page presenting workforce planning for clinics and hospitals — The public Planivo site, which we built alongside the signed-in app.

How information reaches the chart

Without an integration, your staff are the bridge. They see each booking, form or message in a dashboard, a notification or an export, and decide what goes into the chart. When that has to happen automatically, the link is an EHR integration project; we will name it on the first call and help you find a specialist for that part.

Portals and modules are usually built on Next.js and React, with PostgreSQL row-level security deciding who sees which record. Our CTO, Divyansh Singh, sets the architecture of each build. Clients rate our work 5.0 on Clutch from 66 verified reviews (checked 13 October 2026).

§ 10 · HIPAA

HIPAA terms we put in writing

A portal or scheduling tool that a provider runs handles protected health information, so the same obligations apply to it as to the EHR beside it.

A BAA from us. Digital Heroes signs a business associate agreement with you before any protected health information reaches our team, whenever our work will involve handling it.
Hosting under the cloud's BAA. Healthcare builds run on AWS, Microsoft Azure or Google Cloud, under that provider's own business associate agreement, and the written scope names which one.
An outside review. Our HIPAA practices have had an outside review by an independent firm.

Inside the software, each technical safeguard maps to a control you can inspect: role-based access enforced in the database, an audit log of who viewed or changed a record, edits limited to the roles allowed to make them, sign-in before any record appears, and encryption in transit and at rest.

No certificate makes software HIPAA compliant, so ask any vendor, an EHR vendor included, for its BAA and its written list of safeguards rather than a badge.

§ 11 · cost and time

What EHR software development costs, by the published ranges

No neutral survey prices a certified EHR build. The figures that exist come from vendors, and three that rank on Google for this search publish ranges that barely agree. ScienceSoft gives $120,000 to over $2,000,000. Itransition gives $50,000 to $500,000, over six months to three years. A&I Solutions starts at $75,000, live in about ten weeks. We read all three on their own sites on 17 October 2026; treat them as sales figures.

Most of the spread is scope. A specialty charting tool with no certification, a certified ambulatory module and a hospital EHR all get called EHR development. Before comparing quotes, ask each vendor which 170.315 criteria are in the price, whether testing and certification fees are included, and who pays for Real World Testing and attestations after launch.

Our price for the software beside the record

A focused first version of custom software costs $40,000 to $150,000; complex enterprise platforms run $250,000 to $500,000 or more. After discovery, an MVP usually takes 8 to 12 weeks and a production platform 16 to 28. The fixed price follows a two-week discovery sprint, priced on its own, which can also end in advice to buy instead.

The custom software cost guide shows what moves a number inside those bands. For healthcare, the usual movers are extra user roles, each vendor that must sign a BAA, and waits on another organization's approval.

§ 12 · checking a vendor

Seven checks for an EHR vendor or integration specialist

Whether you are buying a certified EHR or hiring a team to connect to one, each answer below can be checked rather than taken on trust.

The CHPL listing. Search the Certified Health IT Product List for the product and read which criteria it holds. A claim of certification with no listing is not certification.
Last year's Real World Testing results. Developers report them every year for publication on the CHPL.
The API documentation. Certified API developers must publish it with their terms, fees and service base URLs; open it before you sign.
The export format. The documented format of the health information export tells you how your data leaves if you switch.
The BAA chain. Every party that will hold protected health information signs one, including hosting, messaging and video vendors.
The EPCS audit report, if you prescribe controlled substances. DEA rules require the application provider to make it available to practitioners who use, or are considering, the application.
A data model conversation. Ask the team how they would store a medication list with its reconciliation history in FHIR terms. A team that works in Patient, Encounter, Observation and MedicationRequest every day answers without slides.

These checks are for the EHR vendor or the integration team, which Digital Heroes is not. For the software we would build beside your EHR, the six checks for any custom software quote apply instead.

§ 13 · questions

Questions buyers ask about EHR builds

What are the top 3 EHR systems?

It depends on the setting. In US non-federal acute care hospitals in 2024, the top three EHR developers were Epic, Oracle Health and MEDITECH, together about 86.5% of hospitals. Among clinicians reporting the Promoting Interoperability category of Medicare's Quality Payment Program, Epic, Oracle Health and athenahealth led, at 62.8%, 10.5% and 7.8%. Both sets of figures are in the care setting table, with sources.

How much does it cost to build an EHR?

There is no neutral figure. Vendors ranking for this search publish ranges from $50,000 to over $2,000,000, and the spread is scope: which certification criteria, which care setting, how much data must move. Certification adds testing fees and yearly duties on top. Software that sits beside an EHR is a smaller job, and our cost section gives our own bands for it.

How to build your own EHR?

Decide first whether it must be certified: if the clinicians or hospitals using it report to Medicare's Promoting Interoperability programs, it must. Then choose the criteria, model and code the data, build the privacy and security criteria, build the FHIR API and the export, test and certify through an ONC-ATL and an ONC-ACB, and keep the yearly duties. The six steps set each one out.

How do I learn EHR systems?

Clinicians and staff learn the EHR their organization runs, through the training that organization provides. Developers can learn the standards for free: the HL7 FHIR specification is public, Epic on FHIR offers a sandbox with example data, and the SMART App Launcher tests an app without registration. To see what every certified product must do, read the criteria in 45 CFR 170.315, summarized in the functions section.

Is there a difference between EHR and EMR systems?

Yes, in ONC's usage. An EMR is the digital chart of one practice; an EHR is built to share that information with labs, specialists and hospitals, and to follow the patient. Certification, Medicare's programs and federal data all use the term EHR, while many vendors still sell under both names.

Do I need ONC certification for a custom EHR?

Only if the people using it need certified technology. The program is voluntary, but clinicians in the MIPS Promoting Interoperability category and hospitals in Medicare's program must use certified EHR technology. A custom record outside those programs can skip certification, though HIPAA still applies to any covered provider using it, and certifying later means building to the criteria and passing testing at that point.

Should the developer sign a business associate agreement?

Yes, whenever the developer will create, receive, keep or send protected health information for you, and that includes test data copied from real records. Digital Heroes signs one before any of it reaches our team, and our healthcare builds are hosted on AWS, Azure or Google Cloud under that provider's own BAA.

How long does EHR development take?

For a certified EHR, vendor estimates run from about ten weeks to three years, and certification testing sits on top. For the software beside an EHR, our planning bands are a two-week discovery, then 8 to 12 weeks for an MVP or 16 to 28 weeks for a production platform.

Does Digital Heroes build EHR integrations or FHIR apps?

No. FHIR apps, HL7 feeds and other interfaces into an EHR are integration work, and we refer it to your EHR vendor or an integration specialist. We build software that sits beside the EHR without connecting to it: patient portals, booking and reminders, and staff workflow modules. If your plan depends on an interface, we say so on the first call.

Last reviewed 17 October 2026.

§ 14 · next step

Tell us the gap your EHR leaves

Send us the job your EHR does badly and who does it today. Within two days of a 30-minute call you have a written scope and quote; the fixed build price comes after discovery. If the honest answer is an EHR integration or a different EHR, we will tell you that instead. Book a call.

Why work with Digital Heroes

115 people across five studios in New York, Delhi, London, Sydney and Lucknow, shipping ecommerce, web, software and mobile work for founder-led brands. Senior engineers only, no account-manager relay, and the same team from kickoff to launch.

Shopify Select Partner, as listed in the Shopify Partner Directory
Tier 1 registered supplier on the United Nations Global Marketplace, which requires audited company documentation
Top Rated Plus on Upwork, the bracket for the top 3% of talent by client outcomes
397 public five-star-weighted reviews across four Fiverr gigs, from clients in 36 countries
DUNS verified business, No. 650878346, so procurement can check us before signing
Listed by Clutch in Top 1000 Global B2B Companies and Top Web Designers 2024
Verified profiles on GoodFirms, DesignRush, Digital.com, AppFutura and TopDevelopers
2,000+ brands built across 40+ countries, with $50M+ in client revenue scaled

Book a call

More from Divyansh.

Chief Technology Officer · Lucknow · 50 posts on the site

post

EHR Software Development, and What We Build Around It