How to build an EHR system: An electronic health record (EHR) system is one of the hardest products you can build in software. The code is rarely the problem. The difficulty is the mix of clinical workflows, strict regulation, patient safety and integration with systems that were not designed to talk to each other.
This guide explains how to build an EHR system in practice. It covers the decisions to make first, the features that matter, the standards you need to support, and what it costs in time and money. It is written for founders, product owners and health-tech teams who are weighing up a custom build.
Key takeaways:
- A focused EHR MVP takes around 6 to 9 months; a multi-module platform takes 12 to 24 months.
- Ongoing costs typically add 15 to 25 percent of the initial build each year.
- UK GDPR requires certain breaches to be reported within 72 hours.
- HL7 FHIR (R4) is the standard for new EHR builds, alongside HL7 v2, DICOM, SNOMED CT, ICD-10 and LOINC.
- NHS sales typically require DCB0129 clinical safety compliance, the DSPT and the DTAC.
What an EHR system is
An EHR is a digital record of a patient’s health history that can be shared across care settings. It typically holds demographics, diagnoses, medications, allergies, test results, clinical notes, imaging and care plans.
People often use EHR and EMR (electronic medical record) interchangeably. An EMR is usually the digital version of a single practice’s paper chart. An EHR is built to travel with the patient, so it can be shared between GPs, hospitals, labs and pharmacies. If you plan to exchange data with other organisations, you are building an EHR.
Before you build: decide what you are actually making
“EHR” covers a wide range of products. A full hospital system and a specialist tool for a physiotherapy clinic share a name and almost nothing else. Settle these questions early:
- Who is the customer: hospitals, GP practices, specialist clinics, care homes or a digital health startup?
- Is it a full record, or one module (for example e-prescribing or clinical notes) that plugs into existing systems?
- Which market comes first: UK, US, EU or somewhere else? This drives your compliance route.
- Will you sell it as a product to many providers, or build it for one organisation?
How to build an EHR system: a step-by-step guide
A narrow first release almost always beats a broad one. Many EHR projects fail because they try to replace everything on day one. Pick one specialty or one care setting, get it right, and expand from there.
Building an EHR system is less about writing code and more about getting scope, compliance and integration right from the start. The steps below walk through the full process, from mapping clinical workflows and meeting UK and US regulations to choosing your architecture, planning migration and estimating cost.
Step 1: Map users and clinical workflows
Start with the people who will use the system every day: doctors, nurses, receptionists, pharmacists, lab staff, billing teams and patients. Spend real time with them. Sit in on clinics, watch how they record notes, and note where they work around the current system.
Document the workflows end to end. A typical outpatient journey runs from booking, check-in and triage through consultation, orders and prescribing, to follow-up and billing. Each step has its own users, data and rules.
This stage produces the thing most teams skip: a clear list of what clinicians do today and which parts hurt. Features that remove those pain points are the ones that get adopted. Clinicians have little patience for software that adds clicks.
Step 2: Understand the regulatory requirements
Compliance shapes your architecture, so deal with it before design starts, not after launch.
UK
- UK GDPR and the Data Protection Act 2018 apply to all health data, which is special category data.
- NHS England’s clinical safety standards, DCB0129 (for manufacturers) and DCB0160 (for deploying organisations), require a clinical safety case and a named Clinical Safety Officer.
- Selling to NHS organisations usually means completing the Data Security and Protection Toolkit (DSPT) and the Digital Technology Assessment Criteria (DTAC).
- Depending on what the software does, it may count as a medical device under UK MDR rules and need MHRA registration.
- Cyber Essentials Plus and ISO 27001 are commonly asked for in procurement.
US
- HIPAA governs how protected health information is stored, accessed and transmitted.
- ONC certification, and support for the USCDI data set, is often needed to sell to providers who claim federal incentives.
EU
- GDPR applies, along with the European Health Data Space rules as they come into force.
- AI features, such as note summarisation or decision support, may be affected by the EU AI Act, which treats some healthcare uses as high risk.
Rules change, and the details depend on your exact product, so involve a regulatory specialist early. Treat this guidance as a starting point, not legal advice.
Step 3: Define the core features
A useful EHR needs a solid core before any extras. These are the modules most systems start with:
- Patient registration and demographics, including identifiers such as the NHS number in the UK
- Clinical documentation: structured notes, templates, problem lists and history
- Medication management and e-prescribing, with allergy and interaction checks
- Orders and results for labs and imaging
- Appointment scheduling and a patient timeline
- Clinical decision support, such as alerts and care pathways
- Role-based access control and a full audit trail
- Billing, coding and claims where relevant to your market
- A patient portal for records, messages and bookings
- Reporting and analytics for clinical and operational use
Add AI features later, once the foundations are stable. Ambient note-taking, coding suggestions and summarisation are useful, but they need clinician review, clear audit trails and careful handling of patient data. Bolting them on before the core is solid creates risk.
Step 4: Plan for interoperability from day one
An EHR that cannot exchange data is a silo, and hospitals will not buy silos. Interoperability needs to be designed in, not added at the end.
The main standards to know:
- HL7 FHIR (R4) is the modern, API-based standard for exchanging health data and is where most new work happens. In the UK, build against the UK Core FHIR profiles.
- HL7 v2 is older but still everywhere, especially for lab and admission messages.
- DICOM covers medical imaging.
- SNOMED CT for clinical terms, ICD-10 for diagnoses and LOINC for lab observations. In the UK, the dm+d dictionary covers medicines.
- In England, GP Connect and the NHS Spine services provide access to shared records and national services.
Expect to build integrations with laboratory systems, pharmacy systems, imaging platforms, national services and sometimes legacy hospital software. Each one takes longer than planned. Budget extra time for testing against real systems, because test environments rarely behave like production.
A sensible approach is to build your internal data model around FHIR resources, or at least map to them cleanly, so each new integration is a translation job and not a redesign.
Step 5: Choose your architecture and tech stack
There is no single correct stack, but a few principles hold up well.
Architecture: A modular design lets you ship and scale features separately. A well-structured modular monolith is often the right start, with services split out later where load demands it. Going straight to dozens of microservices adds operational cost that early-stage teams struggle to carry.
Backend: Mature, well-supported options include .NET, Java, Node.js and Python. Pick what your team knows well and can hire for.
Database: Clinical data is relational and needs strong consistency, so PostgreSQL or SQL Server are common choices. Some teams add a document store for flexible clinical content, or a FHIR-native data store.
Frontend: React or Angular for web, and Flutter or native iOS and Android if clinicians or patients need mobile access.
Cloud: Azure, AWS and Google Cloud all offer compliant healthcare environments. For UK NHS work, check data residency requirements so patient data stays where it should. Azure is a natural fit if your customers already use Microsoft tooling.
Audit and logging: Every read, write and change to a patient record should be logged with who, what and when. This is a legal and clinical requirement, not a nice-to-have, so design it into the data layer from the start.
Step 6: Build security in, not on
Health records are among the most valuable data sets for attackers. Security has to be part of every layer.
- Encrypt data in transit and at rest.
- Use role-based access control with least privilege, plus a “break glass” process for emergencies that is fully logged.
- Require multi-factor authentication for staff.
- Keep environments separate and never use real patient data in development or testing.
- Run penetration tests before launch and on a regular schedule after.
- Have a tested backup and disaster recovery plan, with clear recovery time targets.
- Prepare an incident response plan, including the legal duty to report certain breaches within 72 hours under UK GDPR.
Step 7: Design for clinicians, not for demos
Poor usability is a patient safety issue. A confusing screen can lead to a wrong dose or a missed allergy.
Good EHR design is quiet and fast. Show the most important information first, such as allergies and current medications. Reduce typing with templates, defaults and structured fields. Keep common tasks to a few clicks. Make errors easy to spot and easy to undo.
Test with real clinicians throughout, not only at the end. Short, frequent sessions with working prototypes will teach you more than any specification document. Also design for accessibility from the start, following WCAG guidance, since staff and patients have a wide range of needs.
Step 8: Test for safety as well as bugs
Standard software testing is not enough here. On top of unit, integration and performance tests, you need:
- Clinical safety testing, where a clinician reviews scenarios and checks that hazards identified in your safety case are controlled
- Integration testing with real partner systems, not just mocks
- Load testing, since clinics hit peak demand at the start of the day
- Data migration testing, which is covered in the next step
- User acceptance testing with the people who will use the system
Keep a hazard log and update it as the product changes. Auditors and NHS buyers will ask to see it.
Step 9: Plan migration, rollout and training
Many EHR projects stumble at the end. Getting the software built is only part of the job. Moving a provider onto it is the other part.
Data migration is often the hardest piece. Old records may be incomplete, inconsistent or stored in formats nobody documents. Plan for cleansing, mapping, trial migrations and a clear reconciliation process so you can prove nothing was lost.
For rollout, a phased approach reduces risk. Start with one clinic or department, learn from it, then expand. Run the old and new systems in parallel for a short, defined period if you can. Provide hands-on training and have support staff on site at go-live. Clinical adoption depends heavily on how the first week feels.
How long does it take and what does it cost?
Every project differs, so treat these as rough planning ranges and not quotes.
- A focused MVP for one specialty or care setting commonly takes around 6 to 9 months.
- A broader platform with several modules and integrations often takes 12 to 24 months.
- Costs for a custom EHR typically run from low six figures (in pounds) for a narrow MVP to well over a million for a full multi-module platform.
The main cost drivers are the number of modules, the number and complexity of integrations, regulatory certification, data migration and the level of security and availability required. Ongoing costs matter too. Plan for hosting, support, security testing, regulatory upkeep and continued development, which often add up to 15 to 25 percent of the initial build each year.
The biggest risks to both budget and schedule are scope creep, underestimated integrations and late-discovered compliance requirements. A discovery phase at the start, before committing to a full build, is the cheapest way to reduce all three.
Indicative EHR development cost breakdown
| Component | Focused MVP | Full multi-module platform |
|---|---|---|
| Discovery and requirements | £10,000 – £25,000 | £30,000 – £60,000 |
| UX and UI design | £15,000 – £35,000 | £50,000 – £120,000 |
| Core development (registration, notes, scheduling, prescribing) | £80,000 – £180,000 | £350,000 – £700,000 |
| Integrations (FHIR APIs, labs, pharmacy, national services) | £20,000 – £60,000 | £100,000 – £300,000 |
| Security and compliance (clinical safety case, DSPT, penetration testing) | £15,000 – £40,000 | £50,000 – £120,000 |
| QA and clinical safety testing | £20,000 – £50,000 | £80,000 – £180,000 |
| Data migration | £10,000 – £30,000 | £50,000 – £150,000 |
| Deployment, training and go-live support | £10,000 – £25,000 | £40,000 – £100,000 |
| Project management | £15,000 – £35,000 | £60,000 – £140,000 |
| Total | £195,000 – £480,000 | £810,000 – £1,870,000 |
| Typical timeline | 6 – 9 months | 12 – 24 months |
| Cost area | Share of initial build per year |
|---|---|
| Hosting and infrastructure | 3% – 5% |
| Support and maintenance | 5% – 8% |
| Security testing and monitoring | 2% – 4% |
| Regulatory and compliance upkeep | 2% – 4% |
| Continued development | 3% – 4% |
| Total | 15% – 25% |
Build or buy?
Building from scratch is not always the right call. Off-the-shelf EHRs such as those from established vendors are mature and certified. They make sense when your needs are standard.
A custom build starts to make sense when you have a specialised workflow that packaged products handle badly, when you are creating a new health-tech product to sell, or when you need tight control over your data model and roadmap.
A middle route is also common: use an existing platform as the core and build custom modules, portals or integrations around it.
Common mistakes to avoid
- Trying to build everything in the first release
- Treating compliance as a final-stage task
- Underestimating integration work
- Designing screens without clinicians in the room
- Ignoring data migration until late in the project
- Skipping a clinical safety case until a buyer asks for it
- Using real patient data in test environments
Frequently asked questions
How much does it cost to build an EHR system?
Answer: A custom EHR typically costs from low six figures (in pounds) for a narrow MVP to well over a million for a full multi-module platform. The main drivers are the number of modules, integrations, regulatory certification and data migration. Ongoing costs add roughly 15 to 25 percent of the initial build each year.
How long does it take to build an EHR system?
Answer: A focused MVP for one specialty or care setting usually takes 6 to 9 months. A broader platform with several modules and integrations often takes 12 to 24 months. Integrations and compliance work are the most common causes of delay.
What features should an EHR system have?
Answer: At minimum patient registration, clinical documentation, medication management and e-prescribing, orders and results, scheduling, role-based access control and a full audit trail. Many systems also add a patient portal, billing and coding, and reporting. AI features are best added once these foundations are stable.
What tech stack is best for an EHR system?
Answer: There is no single right answer. Common choices are .NET, Java, Node.js or Python for the backend, PostgreSQL or SQL Server for the database, and React or Angular for the frontend. Azure, AWS and Google Cloud all offer compliant healthcare environments. Choose a stack your team knows well and can hire for, and design your data model around HL7 FHIR.
What team do I need to build an EHR system?
Answer: You will typically need a product owner, a business analyst, a UX designer, backend and frontend developers, QA engineers and a DevOps engineer. You also need a Clinical Safety Officer (a requirement under the NHS DCB0129 standard in the UK), a security specialist and access to a regulatory adviser. Having practising clinicians available throughout the build is just as important.
Read More: Custom Microservices: What Does That Mean for Software Development?
Planning an EHR or healthcare platform?
Scope, compliance and integration decide whether an EHR project succeeds, and they are much cheaper to get right before development starts than after. Evangelist Software can run a short discovery phase with you to map your workflows, confirm the regulatory route for your market, and give you a realistic view of timelines, risks and cost.
Book a free consultation at evangelistsoftware.com and talk through your project with our team.
Final thoughts
Building an EHR system takes careful scoping, early attention to regulation, and close work with the clinicians who will use it. Teams that start small, design for interoperability and treat patient safety as a core requirement give themselves the best chance of shipping something people trust.
Evangelist Software is a UK-based technology consultancy with experience in mobile and web application development, Azure cloud solutions and AI products. If you are planning a healthcare platform and want a realistic view of scope, risks and timelines before you commit, get in touch via evangelistsoftware.com.
