EHR Software Development

What is EHR software development?

EHR software development is the work of designing, building, testing and running electronic health record software, whether that is a full certified EHR, a specialty module, a SMART on FHIR app that extends a vendor EHR, or the integration software around it. The first decision is scope: build the record, buy one, or extend one.

Four kinds of EHR software work

• A full EHR or EMR product: The system of record itself, with charting, orders, results, scheduling and billing hooks. This is the largest scope and usually includes certification.
• A specialty module: Templates, order sets, flowsheets or a workflow for one specialty, built inside or beside an existing record.
• An app that extends the EHR: A SMART on FHIR app that launches in patient context, or a CDS Hooks service that returns cards at points such as order sign.
• EHR integration software: The interfaces and services that move data between the record and labs, imaging, billing, devices and patient apps.

Build, buy or extend: which fits your case?

Buy when your workflows match what certified vendors already support, extend when the record works but one workflow is missing, and build only when the record itself is the product. The checklist below turns that rule into questions a founder or CTO can answer in a workshop.

• Buy if: Your clinicians follow common ambulatory or inpatient workflows, you need certified EHR technology for CMS programs, and the difference you offer is care delivery rather than software.
• Extend if: The organization already runs Epic, Oracle Health (Cerner) or another certified EHR, the gap is one workflow, view or calculation, and the vendor's developer program exposes the data you need.
• Build if: The record is what you sell, no vendor serves the specialty's data model, or you need control of the data structure that configuration cannot give you.
• Warning sign for build: The main reason is a dislike of the current vendor's screens. A SMART on FHIR app or a better template usually solves that for a fraction of the scope.
• Warning sign for extend: The data you need is not available through the vendor's APIs or interfaces. Check open.epic, fhir.epic.com or the relevant vendor documentation before you commit.

Hybrid paths

Many projects mix the three. A specialty group may buy a certified EHR for documentation and billing, extend it with a SMART on FHIR app for a specialty calculation, and build a separate patient-facing app that exchanges data through the vendor's APIs. Write down which system owns each data element, because hybrid designs fail when two systems both believe they hold the true medication list or problem list.

EMR software compared with integration software

EMR software is the record a practice works in every day. Integration software sits between that record and everything else, receiving lab results and admission messages and sending claims and referrals. A founder with a new specialty product may need both. A hospital CTO with an established EHR usually needs only the integration layer and a few apps.

What obligations come with building rather than extending?

Building a certified EHR makes your company a developer of certified health IT, with program conditions that apps built on someone else's record mostly avoid. These are the rules that change scope and calendar.

• Certified EHR technology: CMS requires certified EHR technology for the Medicare Promoting Interoperability Program and the MIPS Promoting Interoperability category, so an EHR sold to US hospitals and clinicians in those programs usually needs certification.
• Certification process: Under the ASTP/ONC Health IT Certification Program, an ONC-Authorized Testing Lab tests the product, an ONC-Authorized Certification Body certifies it, and the result is listed on the Certified Health IT Product List (CHPL).
• HTI-5 changes: The ASTP/ONC HTI-5 final rule, published 28 Oct 2026 and effective 28 Dec 2026 (some provisions 1 Jan 2027), removed 14 certification criteria and revised 7, and developers no longer submit annual real-world testing plans.
• Information blocking: Developers of certified health IT are actors under 45 CFR Part 171, so practices likely to interfere with access, exchange or use of EHI can be information blocking unless an exception applies.
• Risk analysis: The HIPAA Security Rule at 45 CFR 164.308(a)(1) requires an accurate and thorough risk analysis of ePHI, which a covered entity customer will expect your product's design to support.

If the build includes decision support, check device status early. The FDA's final Clinical Decision Support Software guidance, issued in January 2026, explains which software functions fall outside the device definition.

How does an EHR build move from discovery to go-live?

An EHR build moves through discovery, a thin slice, the core build, interoperability, clinical acceptance and go-live. Phases overlap, but each one has an exit test that should be met before the next one takes most of the team.

• 1. Discovery: Observe real clinic sessions, list every user role, and inventory each system you exchange data with. Exit test: a written build, buy or extend decision and a list of the certification criteria, if any, in scope.
• 2. Thin slice: Build one visit end to end, such as a note, a lab order and a returned result, through the data model, interface and screens. Exit test: a clinician completes it on real devices.
• 3. Core build: Add charting, problem lists, medications, orders and scheduling in short sprints with a clinician review each sprint. Map each table to US Core resources as it is designed, not afterwards.
• 4. Interoperability: Build HL7 v2 lab and ADT feeds, the FHIR R4 API with SMART App Launch and Bulk Data, X12 transactions and e-prescribing. Test the API with the Inferno test kit and validate resources with the HL7 FHIR validator.
• 5. Clinical acceptance: Run scripted scenarios with clinicians, review alerts, defaults and order sets for safety, and rehearse downtime. Hospitals in CMS Promoting Interoperability attest annually to a SAFER Guides self-assessment, so they will ask how the product behaves when it fails.
• 6. Migration and go-live: Load history from the old system, reconcile it, train super-users and staff the first weeks of live use with engineers who can fix interface issues the same day.

After go-live: the run phase

EHR software is never finished. Plan a release schedule customers can test against, a regression suite that replays recorded interface traffic, a process for adopting new USCDI versions and US Core releases, and support engineers who can read an HL7 v2 message and trace it to the screen that shows it. Budget this phase from the start rather than treating it as maintenance.

Who belongs on an EHR delivery team?

An EHR delivery team needs clinical judgment and interface skill as much as application engineers. Leaving out either one moves the cost to go-live week.

• Product owner: Knows the clinical workflow and owns the build, buy or extend decision and the backlog.
• Clinical informaticist or practising clinician: Reviews every screen, alert and default, and signs off acceptance scenarios.
• Backend and frontend engineers: Build the record, the screens and the authorization rules.
• Integration engineer: Knows HL7 v2 segments, FHIR resources, terminology and the vendor programs you connect to.
• QA engineer: Tests with synthetic patients and keeps a regression suite for interfaces as well as screens.
• Security and compliance lead: Runs the risk analysis, vendor agreements and audit-log design.

For an extension or integration project, the team can shrink to a product owner, one or two engineers, the integration engineer and a part-time clinical reviewer.

Where EHR software projects lose time

• Building a record when an app would do: A full EHR adds certification, migration and support work that a SMART on FHIR app avoids.
• Treating certification as a final step: Each criterion needs test evidence, and some shape the data model and API design from the start.
• Interfaces scheduled after the screens: The lab and ADT feeds decide what data the screens can show, so late interfaces force redesign.
• No clinical reviewer until user acceptance: Extra clicks, unclear alerts and unsafe defaults are cheap to fix in sprint two and expensive in month nine.
• Migration left to the customer: Clinics switching systems need their history, so import, mapping and reconciliation tools are part of the product.
• No plan for rule changes: Certification criteria, USCDI versions and payer rules change, as HTI-5 shows, so leave capacity each quarter for regulatory updates.

How Agnotic can help

The most useful help often comes before any code: a short discovery that settles build, buy or extend with evidence from your workflows and vendor APIs. Agnotic Technologies runs that discovery, then builds what it points to, whether that is a SMART on FHIR app, a CDS Hooks service, a specialty module, integration software or a full EHR product with certification preparation and data migration.

Sources

• ASTP/ONC: HTI-5 Final Rule
• ASTP/ONC: About the ONC Health IT Certification Program
• ASTP/ONC: Certified Health IT Product List (CHPL)
• CMS: Promoting Interoperability Programs
• 45 CFR Part 171: Information blocking
• 45 CFR 164.308: HIPAA administrative safeguards, including risk analysis
• FDA: Clinical Decision Support Software guidance
• ASTP/ONC: SAFER Guides