EHR System Development: Custom EHR, Module or Off-the-Shelf (2026)

Your EHR holds the clinical record, and your product supports the workflows around it. This guide shows when to configure the EHR system you run, when to extend it through FHIR and when to build.

Highlights

• For customers using Epic, a module can add your workflow while Epic keeps the record.
• Integrations and certification scope move budget and timeline more than screens do.
• HIPAA safeguards, audit trails and BAAs belong in the architecture before code.

EHR system development is the work of building or extending software that stores, exchanges and acts on patient records. With a working product, you have three paths: configure an existing EHR, add your own module on top, or commission custom EHR development of a full system.

EMR development follows the same scoping process, with complexity set by the clinical workflow and the external systems it must connect to. The question usually comes up when growth outpaces the first setup: workflows stop fitting the vendor's templates, and license costs climb with every new site.

We've built EHR-connected products, including a pre-visit intake module whose data lands in Epic. This guide uses that experience to help you decide where your own EHR system build should end.

If your clinical workflows have outgrown the EHR you run today, the first question is which of the three paths your product needs.

EMR vs. EHR: what the difference changes in your build

An EMR keeps patient records inside one organization, while an EHR also exchanges them with labs, pharmacies, hospitals and patient apps. A custom EMR for one specialty group keeps EMR software development tied to that group's workflow and its own interface list. An EHR system brings external connections, standards and certification questions into scope.

Federal law builds exchange into the definition. Under the qualified EHR definition, a qualified electronic health record must be able to exchange electronic health information with other sources and integrate it.

The table compares two typical scenarios, an EMR for one specialty group and an EHR for a network or a product sold to providers, on the criteria that change scope and budget.

Practice management software, a third category, covers scheduling, registration and billing without clinical charting. It usually runs beside the EHR system, so an EMR development plan should list it as one more integration from the start.

Build, buy or extend: when custom EHR system development makes sense

A ready-made EHR works while workflows are standard. A module fits companies whose customers run Epic or Oracle Health and whose value sits in one workflow. Build your own EHR when your product must own the clinical record and you can carry the integration and maintenance that follow.

The signals tend to look alike. Clinicians fight templates instead of documenting care, lab and pharmacy data need manual re-entry, and specialty reports live in spreadsheet exports.

How the extend path works

Extending works because the large vendors open their platforms to outside developers. Epic's open.epic program lists more than 750 APIs and interfaces. Oracle Health's Millennium Platform APIs let developers use HL7 FHIR (Fast Healthcare Interoperability Resources) in SMART applications.

The piece that ties this together is SMART App Launch, an HL7 specification built on OAuth 2.0. An app launched inside the EHR can receive context such as the current patient when the host grants the requested context. Clinicians stay in one EHR system, and your module handles the specialized work.

What to confirm before you commit to extending

SMART handles authorization and launch context, while the host decides what your app may do. Per the spec's scopes section, granted scopes may differ from requested ones and stay limited by the system's policies and the user's permissions. So discovery confirms three things with the host:

• FHIR resources: which ones the vendor exposes for your use case, and whether each allows write-back or only reads;
• Granted scopes: which scopes the organization will grant your app for patients, users or back-end services;
• App approval: who approves and activates the app inside each customer organization.

If write-back isn't available, the module may have to store data itself, which brings BAAs and possibly certification back into scope.

Which path fits your situation

The table matches common situations to a path and its main risk.

Three questions usually settle the choice:

• Record ownership. Does your product need to own the clinical record, or only control one workflow? Owning the record points to a build; a workflow can live in a module, as Dr. Cho's intake does.
• Existing EHR. Do your customers already run a major EHR system? Then a module launched inside it spares them a replacement project.
• Certification scope. Which functions do your customers' programs require to be certified? Your answer sets how much certification work your path carries.

For a smaller practice with standard needs, our guide to private practice EHR options covers decisions at that scale.

Dmytro Dobrytskyi, CEO at Mind Studios, explains when a host EHR's limits should make a founder reconsider the extend path:

Extending stays the right call until the host's limits start shaping your product. The warning sign is a roadmap that keeps bending around what the vendor lets you read and write. When that happens, cost the full build against the module. On Dr. Cho the clinic's records already lived in Epic, which is why a module on top fit.

Core modules of an EHR system and the order to build them

For a full system, a first version usually needs the patient record, charting, lab integration, roles and an audit trail, because these touch every visit and every compliance review. A module on top of an existing EHR needs far less. Either way, the workflow you chose sets the order of everything else.

The table is a reference for a full EHR system: the modules most systems carry and when to build each.

Each module also rests on a standard or integration, which shows where the EHR system depends on outside rules and partners. For data and access, those are:

• Patient page and history: USCDI data classes, FHIR resources
• Charting: your clinical templates
• Roles and access: HIPAA access control
• Audit trail: HIPAA audit controls
• Patient portal: FHIR patient access APIs
• Mobile access: same APIs as the web app

For connections to partners and outside programs, they are:

• Lab integration: HL7 v2, FHIR
• E-prescriptions: NCPDP SCRIPT via Surescripts
• Clinical decision support: CDS Hooks; FDA review if interpretive
• Reminders and telehealth: messaging and video vendors under a BAA
• Billing and claims: ASC X12 837 and 835
• Quality reporting: program specifications

In EHR software development, the order matters as much as the list, because reporting and decision support can only be as good as the structured data the first modules capture.

Mind Studios' recommendation: If your workflow centers on documenting visits and reviewing lab results, put charting and lab integration in the first release. Both touch every visit, so the pilot shows whether clinicians can document a visit and review its results with fewer handoffs. Portals and reminders can follow.

Ambient documentation (which drafts the note from the visit conversation) and coding suggestions sit on top of these modules. They inherit the access rules and audit trail of the EHR system and need a clean record to work from.

Our healthcare AI guide covers where they pay off.

How the list shrinks on the extend path

Extending an existing EHR cuts the table down sharply. The host keeps the patient page, history, orders, prescriptions and billing, while your module carries its own workflow screens, the data it stores, role mapping and an audit log for anything it holds.

Interoperability: HL7, FHIR and the integrations that set your timeline

US interoperability rests on three layers: HL7 v2 messages for labs, admissions and results; FHIR R4 APIs profiled by US Core; and USCDI, the baseline data set for certified systems. Every external connection to your EHR system adds build, testing and partner onboarding time, so the integration list sets the timeline more than the feature list does.

The HL7 v2 comparison page calls v2 one of the organization's most widely adopted standards, still common in inpatient care for lab results and admission events. The US Core guide, HL7's rulebook for FHIR in the US, sets minimum constraints on resources and maps them to USCDI (United States Core Data for Interoperability).

The data set keeps changing. Under the HTI-1 rule, the USCDI v3 baseline became the standard of the ONC certification program on January 1, 2026, so a schema designed today should model those data classes from the start.

For message-level detail, see our guides to HL7 integration and Epic integration.

Integration is where EHR software development timelines slip, so check each connection below before anyone commits to a date.

How Dr. Cho's intake module puts patient data into Epic

A US dermatologist and geneticist wanted patients to share their medical history, complaints and symptoms before the appointment. That data had to end up in the Epic EHR system the clinic already relied on.

We built a web app with a pre-visit interactive questionnaire whose dynamic question logic adjusts to earlier answers. An interactive body map lets patients mark areas of discomfort and upload a picture, and a Medical Note Composer turns the answers into a standardized note.

It was our first Epic project, so we brought in an external Epic integration specialist to bridge our development team and the vendor.

Once submitted, all patient-provided medical information is securely stored in Epic's EHR/EMR system. The project was handed over to the client and is in beta testing at a US-based clinic.

For your roadmap, the lesson is that the clinic kept Epic as its system of record and added a specialized workflow on top.

When the integration list runs longer than the feature list, the question to settle before any estimate is which connections your module can reuse from the host EHR.

Compliance you design in from day one: HIPAA, ONC certification and the Cures Act

HIPAA applies when your product creates, receives, maintains or transmits protected health information (PHI) for a covered entity such as a clinic. ONC certification is voluntary and applies to the functions a developer certifies, and customers in CMS Promoting Interoperability need certified technology for what they report. Information blocking rules reach providers, certified developers and exchanges.

What each requirement asks of the system

In EHR software development, compliance turns into concrete features. The table pairs each requirement with who it applies to and what to build in; confirm the details with legal and regulatory counsel.

Certification and information blocking

The ONC Health IT Certification Program is a voluntary certification program, and its certification process applies to a Health IT Module and the criteria its developer chooses. If the module stores EHI or causes it to be stored, the EHI export criterion comes into scope.

On the customer side, CMS Promoting Interoperability asks eligible hospitals, critical access hospitals and MIPS clinicians to use certified EHR technology (CEHRT). The Medicaid version of that program ended on December 31, 2021, so it no longer pays EHR incentives.

For the build-or-extend decision, certification follows functions. A module may rely on certified functions that stay in the host EHR, while a full EHR system sold to hospitals usually has to cover the reported functions itself.

The rules keep moving: the HTI-5 final rule removes and revises certification requirements and resets the program around FHIR-based APIs. Under the 21st Century Cures Act, information blocking rules mean a product that makes EHI hard to access or export puts your customers at risk.

BAAs and the flow of ePHI

Under HIPAA, a subcontractor that handles PHI for a business associate becomes a business associate too. So whether your company and its vendors qualify depends on what each does with electronic PHI (ePHI).

Here is one flow, a pre-visit intake form submitted through a module, mapped to the parties and agreements that cover each step:

A cloud BAA covers only the provider's side. Microsoft's Azure HIPAA documentation states that using Azure doesn't automatically make a cloud solution compliant, so configuration, access rules and processes stay your responsibility.

Our guide to HIPAA-compliant software development covers those safeguards in depth.

Your development partner joins this chain whenever its people or environments could touch ePHI, so ask how it keeps real patient data out of test environments. Mind Studios is ISO 27001 certified, so our information security management is independently audited.

See the EHR-connected products we've built on our healthcare software page.

FDA, EU and MENA rules

FDA oversight depends on what each function does. Under 21 U.S.C. 360j(o), a function that serves as electronic patient records falls outside the device definition when all of these hold:

• health care professionals, or people working under their supervision, create, store, transfer or review the records;
• the records are part of certified health IT;
• the function isn't meant to interpret or analyze them for diagnosis or treatment.

Other functions are checked against FDA's device software functions policy.

GDPR Article 9 treats health data as a special category. The EHDS regulation, in force since March 26, 2025, sets security and interoperability criteria for EHR systems, with key parts applying from March 2029.

The Saudi PDPL treats health data as sensitive data, and the UAE's data protection page lists Federal Law No. 2 of 2019 on ICT in health fields next to its Personal Data Protection Law. Local counsel should confirm which law governs each health data flow.

Checklist before the first line of code

Before development starts, check the plan against these actions:

• Map every ePHI flow to the organizations and agreements that cover it
• Decide which functions need ONC certification and which stay in a certified host
• Map the USCDI data elements required by your certification criteria and host interfaces
• Define roles, unique user IDs, emergency access and an audit trail
• Keep ePHI in cloud services your provider's BAA covers
• Plan data export and patient access under information blocking rules
• Flag features that interpret records for FDA review

How to build an EHR system step by step

Seven steps take an EHR system from discovery to daily use: map workflows, draw the regulatory and data map, prototype with clinicians, build one complete workflow, connect integrations, test security and migrate data, then launch with training. These stages are a planning framework for EHR software development, and scope and order depend on the workflow.

1. Map clinical workflows in discovery

Discovery means watching clinicians work, from check-in to the signed note, and listing every handoff, form and system they touch. The business gets a scope based on real work. Interviews with managers alone describe the workflow as designed.

2. Draw the regulatory and data map

This step turns discovery into architecture: ePHI flows and agreements, certification scope, USCDI data classes and the full integration list. The business gets an estimate it can defend to its board. Choosing the stack first risks rework when an integration or certification requirement changes the design.

3. Prototype and test with clinicians

A clickable prototype lets clinicians try the workflow before any code exists, which is the cheapest moment to change it.

Mind Studios' approach: On Dr. Cho, the doctor's students gave the initial feedback on the Figma prototype. Add a session with the clinicians who will chart in your system, since their daily workflow decides whether the screens hold up.

4. Build a first version around one complete workflow

The first version of an EHR system carries one clinical workflow end to end, such as intake to signed note, with the record, roles and audit trail underneath. One complete workflow beats eight features delivered halfway, because a clinician who finishes documentation faster becomes the system's advocate.

5. Connect integrations in the order the workflow needs

The workflow you chose in step 4 decides which interfaces come first. If clinicians need lab results to finish it, that connection belongs in the first release, while billing or patient-app links can follow. Start partner onboarding early: two labs on HL7 v2 can still send different versions and test codes, so each interface needs its own test cases.

6. Test security and migrate data

Security testing covers access rules, audit logs, encryption and penetration tests before real ePHI arrives. Migration moves history, attachments and access rights from the current EHR system, with a trial run and a parallel period. Records moved without permissions leave clinicians locked out or seeing too much.

7. Launch, train and support

Roll out site by site, train super-users who help their peers, and keep support close during the first weeks. Go-live is a date, while adoption is the result, so track whether clinicians actually chart in the system. After launch, EHR development work continues through standards updates, certification changes and new integrations.

Tech stack for an EHR system

Judge an EHR stack on three things: whether it supports the standards you must exchange or certify, whether you can hire for it in your markets, and what it costs to maintain over many years. A typical EHR system setup pairs React or Vue.js with Node.js or Python, PostgreSQL, a FHIR server and a cloud provider that signs a BAA.

The table groups common options by layer, with the reason each choice matters to a founder.

The split between self-hosted and hosted FHIR servers decides who carries server operations, a budget line for the first year and beyond.

On the cloud row, the AWS HIPAA guidance asks customers to process, store and transmit PHI only in the services its BAA defines, and Google Cloud's HIPAA page calls compliance a shared responsibility. So stack choices in EHR software development include deciding which managed services your EHR system may use.

For reference, the Dr. Cho module runs on Vue.js on the frontend and on Ruby on Rails 6.1 with PostgreSQL, Docker and RSpec on the backend. The other rows are market options that suit different teams and codebases.

What drives EHR system development cost and timeline

The heaviest drivers are the number of integrations, the certification scope and data migration. Published price ranges rarely transfer to a specific build, because two EHR systems with similar screens can need very different amounts of integration and compliance work.

Red flag: Several costs arrive after launch: certification and USCDI updates as rules like HTI-5 take effect, interface changes when a partner upgrades, security reviews and support as usage grows. EHR software development budgets that stop at go-live leave these unfunded, so plan for them in the first year.

Each driver below changes the budget, the timeline or both.

Scope and partner drivers

Four come from partners, certification and existing records:

• Integrations. Every lab, hospital feed, e-prescribing link and clearinghouse adds build, testing and onboarding work, and partner queues can set the date.
• Certification scope. Developers certify modules by showing conformance to criteria, and participating developers take on ongoing obligations afterward.
• Data migration. History, attachments and access rights need mapping, cleanup and a trial run.
• Vendor platform terms. On the extend path, app registration, sandbox access and review follow each vendor's program terms.

Product and adoption drivers

The other three depend on the product and adoption:

• Mobile clients. Native iOS and Android apps for the EHR system bring their own design, testing and release cycles.
• AI features. Ambient documentation or coding support adds model costs, evaluation and clinician review.
• Training and adoption. Super-users, site visits and support hours grow with the number of locations.

Anton Baryshevskyi, Head of Business Development and Co-Founder at Mind Studios, explains how he keeps an estimate honest while access to the host EHR is still unconfirmed:

An estimate for a module inside someone else's EHR rests on access we don't control. So we write every open assumption into the estimate, with an owner on the customer's side and a date to close it. On Dr. Cho the vendor bridge needed an external Epic specialist, so we budget access as its own piece of work.

Mistakes that stall EMR development and what to do instead

Five risks can stall EMR development long before rollout, and each leaves a visible sign in the project plan that a founder can spot before the first site goes live on the new EHR system.

Each item below pairs the warning sign with what to do instead:

• Terms before data. Sign: steering notes debate EMR vs. EHR, yet nobody can list the interfaces. Instead: ask for the interface count, with a named owner on each partner's side.
• UI before integrations. Sign: screens are signed off while partner sandboxes and message formats are still unconfirmed. Instead: validate data-dependent screens against representative messages and API responses before approving them.
• Certification "later." Sign: the architecture document has no list of certification criteria and no note saying none apply. Instead: settle certification scope while designing the data model.
• Migration at the end. Sign: the plan shows no trial migration date and no parallel period. Instead: put both on the plan now.
• No training plan. Sign: the budget has a go-live date but no super-users, site visits or support hours. Instead: name super-users at each site before launch.

What to decide before the first line of code

When growth exposes gaps in your current EHR, discovery should settle three decisions before development begins. First, the path: configure, extend with a module, or build. Second, the standards: which HL7 v2 feeds, FHIR APIs and USCDI data classes the EHR system must support.

Third, certification: which functions your customers need certified, and whether your product or the host performs them. Left open, each one tends to return as rework after the first clinic is live, so the estimate, the stack and the compliance plan should follow from them.

If you want those three decisions mapped against your current EHR setup and integration list, that's the discovery work we'd start with.

FAQ

How much does it cost to build an EHR system, and what drives custom EHR development cost?

A custom EHR development cost figure is only as good as its assumptions, so compare estimates by what each one states. Ask every bidder for:

• the assumptions it treats as confirmed and the ones still open;
• an owner for each open item;
• what it excludes, such as first-year upkeep and standards updates.

How long does EHR system development take?

The schedule depends on how many milestones wait on outside calendars: lab, hospital and e-prescribing onboarding, certification testing and migration. A module on a host EHR system has fewer of them, because the host already carries the records and most interfaces.

How to build an EHR system on top of Epic or another vendor's EHR?

The usual route goes through the vendor's developer program and SMART on FHIR:

• register your app in the vendor program, such as open.epic or Oracle Health's Millennium Platform APIs;
• confirm which FHIR R4 resources and operations, including write-back, the vendor exposes;
• build and test in the vendor sandbox;
• launch with SMART App Launch and pass each customer's security and app review.

What are the 8 core functions of an EHR?

The Institute of Medicine's 2003 letter report on key EHR capabilities, in the National Academies reprint, names eight core functions:

• health information and data;
• results management;
• order entry/management;
• decision support;
• electronic communication and connectivity;
• patient support;
• administrative processes;
• reporting and population health management.

Does a custom-built EHR need ONC certification?

Not automatically, because certification is voluntary for developers. It becomes a practical requirement when your customers' programs call for certified technology for the functions your product performs. List what customers report on and which of those functions your product performs, then plan certification around them.

What is the difference between EMR software development and custom EHR software development?

EMR software development builds records for one organization, while custom EHR software development adds exchange with other organizations and the standards behind it. Neither label fixes the scope, since an EMR project may still need several external interfaces. In EHR software development, the interface list drives the estimate more than the label does.

How to create EHR software from scratch: where do you start?

Start discovery on the one clinical path your product will own, such as check-in to signed note. Its first output is a map of that workflow's handoffs and the systems it touches. That map shows whether a lean first version fits or integrations need planning before screens.

What are the top 3 EHR systems in the US?

By hospital use, the three developers reported most often are Epic, Oracle Health and MEDITECH. In ASTP/ONC data for 2024, 1,951 of 4,058 non-federal acute care hospitals in the Medicare Promoting Interoperability Program reported certified health IT from Epic, 999 from Oracle Health and 716 from MEDITECH. The data set covers those hospitals only.

6