TL;DR
• Where to actually start if you’re serious about how to create ehr software rather than just exploring the idea.
• The data and interoperability requirements – FHIR R4, USCDI v3 – that belong in your architecture from day one, not added later.
• The full build process from requirements to launch.
• What ONC certification requires, and when you actually need it.
• The mistakes that trip up teams building an EHR from the ground up.
• How Dotcode approaches greenfield EHR builds.
As of January 1, 2026, certified EHR systems in the US are required to support the USCDI v3 dataset. If you’re planning how to build ehr software that meets that bar, the requirement belongs in your architecture from the first sprint, not something you retrofit once the product’s already shipped. Whatever your specific ehr software requirements turn out to be, USCDI v3 is the floor, not a nice-to-have.
ONC certification criterion §170.315(g)(10) requires a standardized API built on HL7 FHIR Release 4, along with US Core profiles and SMART on FHIR, as a condition of base EHR certification, per the ONC’s own resource guide. And under the CMS-0057-F rule, four FHIR-based APIs – Patient Access, Provider Access, Payer-to-Payer, and Prior Authorization – need to be live on HL7 FHIR R4.0.1 by January 1, 2027, which is worth planning for now rather than waiting until the deadline is close.
This guide covers where to start, the steps involved in creating an ehr system from requirements to launch, data architecture and interoperability requirements, certification, and the mistakes that show up most often in ground-up builds. If you’d rather think of it as how to create an electronic health record system or build your own ehr platform, the same process applies either way.
Before You Start: Define Requirements and Scope
- Define your target specialty or facility type – ambulatory practice, inpatient facility, or a narrow specialty focus. This shapes almost everything downstream.
- Decide whether ONC certification is required – it’s mandatory if your clients want to participate in federal incentive programs, optional otherwise.
- Choose your build model: from scratch, or on top of a FHIR-first platform like Medplum, Aidbox, or Healthie. The platform route gets you moving faster; building from scratch gives you full control.
Getting this right up front is most of what separates a smooth ehr system development steps process from one that drags on for an extra six months. Your ehr development requirements document – and really, your full ehr system requirements checklist – should answer all three of the above before a single line of backend code gets written. This is also the honest answer to what you need to build ehr software that doesn’t fall apart at the compliance review stage: clear scope, before architecture.
How to Create EHR Software: Step by Step
Here’s how to build an ehr system, laid out in the order these decisions actually need to happen – the same steps to build ehr software apply whether you’re building an ehr from scratch or extending an existing product:
1. Define requirements and compliance scope. Clinical workflows, HIPAA, and ONC certification if it applies.
2. Design the patient data model. Structured clinical records that map to USCDI v3 from the start.
3. Build the FHIR interoperability layer. FHIR R4 API, US Core profiles, and SMART on FHIR so third-party apps can connect.
4. Implement role-based access and security. RBAC, MFA, encryption, and audit logging.
5. Develop the clinical UI. Patient charts and a dashboard built for physicians, nurses, and admin staff.
6. Test and prepare for certification. Functional and security testing, plus ONC-ACB testing if certification is on the roadmap.
7. Launch and support. Data migration, staff training, and updates as CMS and ONC requirements evolve.
If what you searched for was how to develop an ehr system or how to make ehr software specifically for a single specialty, the sequence above doesn’t change – only the scope of steps two and three does. And if you want to create your own ehr software but aren’t sure you need a full custom build at all, that’s worth a candid conversation before step one, not after step four.
Data Architecture and Interoperability Requirements
This is where most of the real ehr interoperability requirements live, and it’s the section teams most often underestimate:
- Your data model needs to match USCDI v3, the federal minimum dataset now mandatory for certified health IT as of January 2026.
- A FHIR R4 API with US Core profile support is required for base EHR certification under ONC §170.315(g)(10).
- SMART on FHIR is the authorization framework that lets third-party apps connect to your system through OAuth 2.0 – worth building in from the start even if you don’t have third-party integrations planned yet.
Getting the ehr data architecture right the first time is genuinely one of the highest-leverage decisions in the whole project – a data model that already speaks FHIR natively saves months down the line. This section is really the core of any serious ehr system architecture, more than the UI layer most people picture when they think about the build.
ONC Certification: What It Requires
- Base EHR definition – the minimum set of certification criteria needed to access federal incentive programs.
- ONC-ACB (Authorized Certification Body) testing – verifies you meet the criteria, FHIR API included.
- CMS-0057-F requires FHIR R4-based payment APIs to be live by January 1, 2027 – worth building toward now rather than scrambling later.
An ehr software build checklist that doesn’t account for ONC-ACB testing timelines is incomplete – that testing window can add weeks to a launch date if it’s not planned for.
*CTA*
*Ready to start building your own EHR system and want the architecture right from day one? Tell us your requirements – we’ll scope it in 48 hours.*
Common Mistakes When Building EHR Software From Scratch
- Treating interoperability as a “later” problem instead of building the FHIR layer in from day one.
- Underestimating how much work data migration from legacy systems actually is.
- Building a custom HL7 interface instead of moving straight to the FHIR standard.
- Leaving ONC certification testing until the late stages of the project, when fixing gaps costs far more.
Every one of these shows up in our own project post-mortems more than we’d like, which is why they’re worth calling out directly rather than burying in a checklist nobody reads.
How Dotcode Can Help
Dotcode builds FHIR-first from day one on every ground-up EHR project, and we support clients through the ONC certification process rather than leaving them to figure it out alone. We’ve got specific experience migrating clients off legacy HL7 systems, and HIPAA-by-design architecture is the default on every build, in line with HHS’s own requirements. Our EHR integration and healthcare app development pages go deeper into how we structure these projects, and our notes on API integration are useful background if FHIR is new territory for your team. You can see what past clients say about working with us on Clutch.
Final Thoughts
Building an EHR system from scratch means designing interoperability and certification requirements into the architecture from the first day, not adapting the system after the fact. A FHIR-first platform gets you moving faster; building from scratch gives you full control over the data architecture. If you’re still weighing that decision, our broader healthcare industry page and our healthcare data security best practices notes are a reasonable next stop.
FAQ
How do I start creating EHR software?
Define your target specialty or facility type, decide whether ONC certification is required, and choose between building from scratch or on top of a FHIR-first platform. Those three decisions shape everything that follows.
What data standard must EHR software support?
USCDI v3, the federal minimum dataset now required for certified health IT as of January 1, 2026.
Do I need ONC certification to build an EHR system?
Only if your clients want to participate in federal incentive programs. It’s not legally required otherwise, though many buyers expect it as a baseline.
What is the difference between building on a FHIR platform and building from scratch?
A FHIR-first platform like Medplum or Aidbox gets you to market faster with interoperability already handled. Building from scratch takes longer but gives you complete control over the data architecture.
What is SMART on FHIR?
An authorization framework built on OAuth 2.0 that lets third-party applications securely connect to your EHR system through its FHIR API.
What are the most common mistakes when building EHR software?
Treating interoperability as an afterthought, underestimating data migration effort, building a custom HL7 interface instead of using FHIR, and leaving ONC certification testing until too late in the project.
