Understanding the work
What does an EHR software development company do?
An EHR software development company designs, builds, certifies, and maintains electronic health record software, or builds apps, modules, and integrations that extend an existing EHR. Typical work includes specialty charting, FHIR APIs, certification testing, data migration from legacy systems, clinical decision support, patient access, and the usability and safety work clinicians depend on.
The work splits into two very different businesses. One is building the record system itself, which means owning clinical data models, certification, and decades of retention. The other is building on top of a record system someone else owns, which means mastering its APIs, app review processes, and upgrade cycles. Our software development company guide covers hiring in general; this page covers what is specific to EHRs.
An electronic health record (EHR) is software that stores and manages a patient's clinical record across encounters, including problems, medications, allergies, results, notes, and orders, and shares that information with authorized clinicians, patients, and other systems.
If your project is mainly virtual visits, read our telemedicine software development guide. For patient apps, payer tools, and FDA questions across health software, start with the custom healthcare software development company guide.
Types of EHR software projects
EHR projects range from building a full certified EHR, to building a specialty EHR for a niche such as behavioral health or physical therapy, to building apps, modules, and integrations on an existing platform. Data migration and patient access APIs are common standalone projects. Each type carries very different certification and maintenance obligations.
| Type | Examples | What drives the effort |
|---|---|---|
| Certified EHR product | A full EHR sold to practices or hospitals | Certification criteria, USCDI support, FHIR APIs, real world testing, long-term support |
| Specialty EHR | Behavioral health, dental, therapy, home health, or research clinic records | Specialty workflows and forms, deciding whether certification is needed, interoperability with hospital EHRs |
| Apps on an EHR platform | SMART on FHIR apps listed in vendor marketplaces such as those run by Epic or Oracle Health | Vendor APIs and review processes, launch context, write-back limits |
| Modules and add-ons | Specialty documentation, care plans, scheduling, decision support | Fitting existing workflows, synchronizing data both ways |
| Interoperability and API layers | Patient access APIs, bulk data exports, HIE and TEFCA connections | Standards conformance, identity matching, consent, throughput |
| Data migration and archiving | Moving from a retired EHR, building a read-only legacy archive | Data mapping, code sets, validation with clinicians, retention rules |
Scroll the table sideways to see all columns.
Build, buy, or extend an EHR
Most provider organizations should buy an EHR and extend it with apps and integrations. Building a full EHR makes sense mainly for companies that intend to sell one, or for specialties whose workflows no product supports. Extending through FHIR apps and modules usually delivers differentiated workflows faster, with less regulatory and support burden.
| Option | Good fit when | What you take on |
|---|---|---|
| Buy an EHR | You are a provider and products cover your specialty reasonably well | Configuration, training, and the vendor's roadmap and upgrade schedule |
| Extend an EHR | Your EHR covers the core record but not a key workflow, specialty form, or patient experience | Platform APIs, app review, and testing your app against each EHR upgrade |
| Build a specialty EHR | A niche where products are weak and certification is not required by your customers | Ongoing security, retention, interoperability, and support for every customer |
| Build a certified EHR | You are a health IT company selling to customers who need certified technology | Certification, Conditions and Maintenance of Certification, information blocking duties, and constant rule changes |
Scroll the table sideways to see all columns.
Questions that settle the decision
- Do your customers participate in CMS programs that require certified EHR technology?
- Can your differentiating workflow live in an app that launches from an existing EHR?
- Will you support the product, its security, and its data for a decade or more?
- Does your target EHR platform allow the write-back your workflow needs?
A trustworthy EHR software development company will often recommend extending rather than building. Treat that as a good sign.
Requirements and rules
Certification, HTI rules, and information blocking
EHR developers work under the ASTP/ONC Health IT Certification Program, a series of HTI rules that update its criteria, USCDI data requirements, and information blocking rules backed by real penalties. As of October 2026, USCDI v3 is the required baseline, HTI-4 added e-prescribing and prior authorization criteria, and HTI-5 is still a proposal.
The certification program
The Assistant Secretary for Technology Policy and Office of the National Coordinator for Health IT (ASTP/ONC) runs a voluntary certification program. Products are tested against certification criteria by authorized testing labs, certified by authorized certification bodies, and listed on the Certified Health IT Product List (CHPL). Certification also brings Conditions and Maintenance of Certification, such as API requirements, real world testing, and attestations, that continue after launch.
| Rule | Status | Why it matters |
|---|---|---|
| HTI-1 | Final January 9, 2024 | Made USCDI v3 the baseline, updated decision support and information blocking provisions |
| HTI-2 | Final December 16, 2024 | Further updates to certification and information blocking, including TEFCA-related provisions |
| HTI-4 | Final August 4, 2025 | Added certification criteria for e-prescribing and electronic prior authorization |
| HTI-5 | Proposed December 2025 | Deregulatory proposal that would remove many certification criteria; not final |
| USCDI v3 | Required from January 1, 2026 (enforcement discretion to March 1, 2026) | The data classes and elements certified health IT must support |
Scroll the table sideways to see all columns.
Information blocking
The 21st Century Cures Act prohibits practices likely to interfere with access, exchange, or use of electronic health information, subject to defined exceptions. HHS announced a crackdown on September 3, 2025. Developers of certified health IT, and health information networks and exchanges, face civil money penalties of up to $1 million per violation. For an EHR software development company, that means designing export, API access, and fee practices that will hold up to scrutiny.
This is general information, not legal or regulatory advice; confirm current requirements with counsel and your certification body.
FHIR APIs, SMART, bulk data, and TEFCA
Certified EHRs must expose standardized FHIR R4 APIs using US Core profiles and SMART App Launch for authorization, with bulk data export for population-level access. US Core 6.1.0 aligns with USCDI v3. TEFCA provides a national framework for network exchange. Any EHR software development company should show working conformance, not just familiarity.
- FHIR R4 (4.0.1): R5 is the latest published FHIR release, but US regulations reference R4.
- US Core 6.1.0: the profiles that define how USCDI v3 data appears in FHIR resources.
- SMART App Launch: OAuth 2.0 based authorization and launch context for patient and clinician apps.
- Bulk data (FHIR Bulk Data Access): asynchronous export of data for groups of patients, used for analytics, payers, and population health.
- TEFCA: the Trusted Exchange Framework and Common Agreement, operational since December 2023, for exchange through qualified networks.
- Older interfaces: HL7 v2 feeds for admissions, orders, and results, and C-CDA documents, remain common in real deployments.
When building on a platform such as Epic or Oracle Health, expect each vendor to have its own developer program, API catalog, and review process. Read their current terms directly rather than relying on a partner's summary.
Migrating data from a legacy EHR
EHR data migration means deciding what to convert into the new system as structured data, what to bring over as documents, and what to leave in a read-only archive. It requires mapping code sets, matching patients, validating samples with clinicians, and keeping records for legally required retention periods. Errors can directly affect patient safety.
- InventoryList data types, volumes, code sets, and attachments in the legacy system, and any interfaces feeding it.
- Decide scopeConvert active problems, medications, allergies, and recent results; archive older history in a searchable viewer.
- Map and cleanMap local codes to standard terminologies such as SNOMED CT, LOINC, and RxNorm, and resolve duplicate patients.
- Trial loadsRun repeated test migrations and reconcile counts, then have clinicians review sample charts side by side.
- CutoverFreeze changes, run the final load, verify, and keep the archive available for as long as retention rules require.
Ask any EHR software development company to show reconciliation reports from a past migration. For moving the surrounding infrastructure, see our guide to cloud migration service providers.
Clinical safety and usability
EHR design choices affect patient safety: a confusing medication list, an alert that fires too often, or a default that hides results can cause harm. Good EHR development uses user-centered design, usability testing with clinicians, safety reviews of high-risk workflows, and monitoring after launch. ONC's SAFER Guides and NIST usability work are useful references.
- Test high-risk tasks, such as ordering medications and reviewing results, with clinicians before release.
- Keep alerts specific and actionable to limit alert fatigue, and track override rates.
- Show clear source and date for data received from other systems.
- Give clinicians a fast way to report safety problems, and review those reports regularly.
- Use the SAFER Guides as a self-assessment for EHR configuration and contingency planning.
- Ask an EHR software development company how it handles a reported safety issue from triage to fix.
Decisions
How an EHR development project runs
An EHR software development company adds certification planning, standards conformance testing, clinical safety review, and migration rehearsals to the usual lifecycle. Platform extension projects add vendor onboarding and app review. Clinicians should be involved throughout, and releases need to be coordinated with customer upgrade windows because downtime affects patient care.
- DiscoveryMap clinical workflows, data, existing interfaces, and whether certification or platform onboarding is needed.
- Regulatory and standards planList certification criteria in scope, USCDI v3 and US Core requirements, and information blocking policies.
- Design with cliniciansPrototype and test the highest-risk workflows first.
- Build and conformance testingAutomated tests against FHIR validators and test data, plus security testing.
- Certification or app reviewTesting with an authorized lab and certification body, or the EHR vendor's review process.
- Migration and go-liveRehearsed cutovers, downtime procedures, and on-site or virtual support for clinicians.
- MaintainReal world testing, rule updates, and regular releases aligned with customer upgrade cycles.
What drives the cost of EHR development
EHR cost depends mostly on whether you build a full record system or extend one, whether certification is in scope, how many interfaces and data sources you integrate, how much legacy data you migrate, and the ongoing cost of keeping up with rule changes. Ask any EHR software development company to separate these in its estimate.
| Driver | Why it adds effort |
|---|---|
| Scope of the record | A full EHR needs orders, results, medications, notes, and billing links; an app needs only a slice |
| Certification | Testing, documentation, real world testing plans, and ongoing attestations |
| Interfaces | Labs, pharmacies, imaging, HIEs, and payers, each with its own formats and testing |
| Data migration | Mapping, cleaning, repeated trial loads, clinician validation, and archives |
| Platform dependence | App review and regression testing against each host EHR release |
| Regulatory change | New HTI rules, USCDI versions, and payer requirements arrive regularly |
| Security and hosting | HIPAA-eligible hosting, audit logging, backups, and long retention |
Scroll the table sideways to see all columns.
This guide does not quote prices. See the cost section of our main guide for pricing models.
Contracts, data, and ownership
A contract with an EHR software development company should include a BAA, assign custom code to you, define who holds certification and its ongoing obligations, guarantee full data export in standard formats, cover support during clinical hours, and include source code escrow and transition help if the developer hosts a system you depend on.
- BAA: required whenever the developer or its hosting providers handle protected health information.
- Certification ownership: whose name is on the CHPL listing, and who handles attestations and real world testing.
- Data export: complete exports of the record in standard formats, with no fees or delays that could raise information blocking concerns.
- Escrow and exit: source code escrow for hosted systems, and a transition plan with documented data structures.
- Support: severity levels and response times that match clinical operations.
This is general information, not legal advice; have counsel review your agreements.
How to choose an EHR software development company
Choose an EHR software development company with proven FHIR and HL7 integration work, experience with certification or with your target EHR platform, a clinical safety and usability practice, a real data migration method, and clear terms on data export and ownership. A paid discovery or a small app is the best test before a large build.
Evaluation criteria
- Standards depthWorking FHIR R4, US Core, SMART, bulk data, HL7 v2, and C-CDA implementations.
- Certification or platform experienceProducts they took through certification, or apps live on your EHR platform.
- Clinical involvementClinicians on the team or advising, and usability testing built into delivery.
- Migration methodMapping tools, reconciliation reports, and clinician validation steps.
- Information blocking awarenessThey can explain how their designs support access, exchange, and use of data.
Questions to ask an EHR software development company
- Should we build, buy, or extend, and what would change your answer?
- Which certification criteria or EHR platform programs have you worked through, and what went wrong?
- How will you track HTI-5 and future USCDI versions during our project?
- How do you validate migrated data with clinicians?
- How do you test your apps against host EHR upgrades?
Red flags
- Recommending a full custom EHR without exploring extension.
- Claiming special access to a platform vendor's program that you cannot confirm with the vendor.
- Charging for or restricting data export in ways that could look like information blocking.
- No clinicians involved in design or testing.
See also how to choose a software development company, and for large multi-system programs, our enterprise software development guide. After launch, cloud security managed services can help monitor hosted EHR environments.
Reference
EHR software development company FAQs
Do we need ONC certification for our EHR?
Certification is voluntary for developers, but providers in some CMS programs need certified EHR technology, so many customers will require it. Specialty systems and apps built on a certified platform often do not need their own certification. Confirm based on your customers.
What is USCDI v3 and when is it required?
USCDI is the standard set of data classes and elements for exchange. Version 3 became the required baseline for certified health IT from January 1, 2026, with enforcement discretion until March 1, 2026. US Core 6.1.0 aligns with it.
What are the penalties for information blocking?
Developers of certified health IT and health information networks or exchanges face civil money penalties of up to $1 million per violation. HHS announced a crackdown on information blocking on September 3, 2025.
Is it better to build an EHR or extend Epic or Oracle Health?
For most provider organizations, extending an existing EHR with apps and integrations is faster and carries less regulatory and support burden. Building makes sense mainly for health IT companies selling an EHR or for specialties no product supports well.
Which FHIR version should EHR software use?
US work targets FHIR R4 (4.0.1) because US regulations reference it, with US Core profiles and SMART App Launch. FHIR R5 is the latest published release, but R4 remains the production standard for certified health IT in the US.
What is HTI-5?
HTI-5 is a deregulatory rule ASTP/ONC proposed in December 2025 that would remove many certification criteria. It was still a proposal as of October 2026, so developers should track it but continue to meet current requirements.
How long must migrated EHR data be kept?
Retention periods depend on state law, patient age, and payer and program rules, and can be long. Most organizations keep a read-only archive of the legacy system for that period. Confirm requirements with counsel and your records management team.
Sources and further reading
Regulatory dates and standards in this guide come from the following primary sources.
- ASTP/ONC, HTI rules
- ASTP/ONC, Certification of Health IT
- ASTP/ONC, Conditions and Maintenance of Certification
- ASTP/ONC, Certified Health IT Product List (CHPL)
- ASTP/ONC, United States Core Data for Interoperability (USCDI)
- ASTP/ONC, Information Blocking
- HHS, HHS crackdown on health data blocking
- HHS Office of Inspector General, Information Blocking
- ASTP/ONC, Trusted Exchange Framework and Common Agreement (TEFCA)
- HL7, FHIR specification
- HL7, US Core Implementation Guide
- HL7, SMART App Launch
- HL7, FHIR Bulk Data Access
- ASTP/ONC, SAFER Guides
- NIST, Technical Evaluation, Testing, and Validation of the Usability of Electronic Health Records
About this guide
This guide is published by Crecso as an independent educational resource and is part of our software development guide. It names platforms, standards, and regulations as examples only, is not affiliated with any software vendor, EHR platform, or development firm, and does not describe services offered by Crecso. It is not legal, regulatory, or medical advice.
Last reviewed on . If you spot something that has changed, please let us know through our contact page.