EHR Systems Explained: What They Are, How They Work, and How to Choose the Right One

Most EHR guides begin with comparing feature checklists. That misses the bigger problem. Recent studies show that only 38% of EHR adoption projects hit the mark. The reason doesn’t show up in the feature list. Choosing the right EHR system, or deciding whether to buy, build or extend, comes down to understanding its architecture. Decisions about data models, APIs and the interoperability standards it supports are much bigger factors in deciding whether your system will be useful in 5 years. This guide covers what an EHR system actually is, how they work under the hood, where they fail, and what the next generation looks like.

TL;DR

• An EHR system or Electronic Health Record system is a digital system for capturing, storing and sharing patient data across the people and places involved in care: clinicians, hospitals, labs, pharmacies and the patient themselves.

• EHR systems are cross-provider digital records. EMR systems are single-practice charts. The distinction matters in regulation and procurement, but in practice, the terms are used interchangeably.

• The global EHR market is large and growing. Grand View Research estimates the global EHR market at USD 35 billion in 2025, and projected to reach USD 53 billion by 2033. Other estimates vary, but all agree it is a multi-billion dollar industry.

• According to the 2025 KLAS Arch Collaborative report, only 38% of recent EHR implementations hit the mark. Satisfaction has dropped consistently since 2022.

• Modern EHR architecture separates data from applications using open standards like openEHR for clinical data persistence, FHIR for interoperability, and SNOMED CT for terminology. This combination is aimed at reducing lock-in and improving long-term flexibility.

• Key selection criteria in 2025 include FHIR API support, SMART on FHIR readiness, cloud deployment, clinical decision support, total cost of ownership over 5+ years, and how easy it is to get your data back out

• Medblocks builds on FHIR and openEHR from the ground up, giving teams a vendor-neutral and standards-based path to access and structure the complete patient record across EHRs, payers, HIEs, and more.

What is an EHR system?

An Electronic Health Record system or EHR system is a structured digital platform that captures, stores, and shares clinical and administrative data about a patient across multiple care settings. It is intended to serve as an authoritative source of truth for a patient’s health over time, accessible by any authorized provider involved in their care.

The word “system” matters here. An EHR is not just a database. It is a set of interconnected tools: clinical documentation, order entry, prescribing, lab results, billing, patient portals, and increasingly, analytics and AI-driven decision support. All of these touch the same underlying patient record.

EHR vs EMR: What is the difference?

This is one of the most searched questions in health IT, and the confusion is understandable. Here’s the honest answer: The terms are often used interchangeably and that’s okay. But there is a technical distinction worth knowing, especially if you are buying, building, or working with regulations.

An EMR (Electronic Medical Record) is a digital version of a paper chart inside a single practice or clinic. It records what happens within those four walls. If a patient switches doctors, the EMR data stays behind unless someone manually transfers it.

An EHR (Electronic Health Record) is built to travel with the patient. It shares data across organizations, care settings, and provider types. An EHR connects your primary care physician, cardiologist, radiologist, and pharmacy into one coherent record.

In practice, the line is fuzzier. Many modern systems sold as EHRs do not fully achieve cross-organizational data sharing without significant integration work. And many products that started as EMRs have added interoperability features over time. Vendors market on whichever term sounds better for the audience.

The table below shows the intended distinction between EMRs and EHRs.

Feature	EMR	EHR
Scope	Single practice	Multiple providers and settings
Data sharing	Limited or manual	Designed for cross-org exchange
Patient view	Provider-centric	Patient-centric, longitudinal
Interoperability	Low	High (FHIR, HL7)
Use case	Documentation within one clinic	Care coordination across a network
Regulatory fit	Basic compliance	Full Meaningful Use / ONC certification
Example systems	Standalone clinic systems, dental or optometry practice software	Enterprise systems like Epic, Oracle Health, MEDITECH

The short version: every EHR contains EMR-like functions, but not every EMR qualifies as an EHR. When procurement teams, developers, and regulators say “EHR systems,” they mean the broader, interoperable class. Whether the product actually delivers that interoperability is a different question, and what we’ll try to answer here.

What data does an EHR system store?

A fully implemented EHR system stores far more than diagnoses. The data layer typically includes:

• Demographics and contact information
• Medical history: past diagnoses, surgeries, family history
• Current and historical medications with dosages and dispensing records
• Allergy lists with severity ratings
• Lab and diagnostic test results
• Radiology images and reports (often via PACS integration)
• Clinical notes: SOAP notes, discharge summaries, operative reports
• Immunization records
• Vital signs and device data recorded over time
• Billing and insurance data
• Care plans and goals
• Patient-reported outcomes (in modern systems)

Some next-generation EHR systems also store information like genomic data, social determinants of health (SDOH), and structured data using openEHR archetypes. When data is structured in this way, it is computable. That is, it can be queried, analyzed, and reused by other applications without manual cleanup. At Medblocks, we build on this approach.

The difference between a departmental and enterprise EHR

A Departmental EHR serves a specific specialty or unit. Think of a radiology information system (RIS), a pharmacy management tool, or a standalone mental health EHR. These are optimized for one workflow but can create data silos if they are not well-integrated.

An Enterprise EHR is meant to cover the full patient journey across an entire health system. Epic, Oracle Health (formerly Cerner), and MEDITECH occupy this space. The trade-off is significant: enterprise EHRs offer breadth but carry enormous implementation complexity, cost, and the risk of being locked into one vendor’s monolithic stack. That trade-off is exactly what the next generation of EHR architecture is trying to solve.

The technical architecture of EHR systems

Under the hood, every EHR system is made of four layers: storage, integration, APIs, and the application itself. The choices vendors make at each layer shape what the system can do, how easily it connects, and how stuck you are if you need to change something later.

Client-server vs. Cloud-based EHR architectures

Legacy EHR systems were built on client-server architectures. The application and database live on servers inside the hospital’s data center. Clinicians access it through thick desktop clients (heavy applications installed on each workstation) over an internal network. This model gives the hospital full control but creates real problems: expensive hardware, difficult updates, limited remote access, and poor scalability.

Cloud-based EHR systems move the application and data to external servers managed by the vendor or, in some cases, on a private cloud managed by the health system. The shift to cloud-based EHR platforms reduces upfront capital expenditure on IT infrastructure and makes updates, remote access and scaling easier. It also comes with trade-offs: data residency concerns, ongoing subscription costs that can outpace one-time hardware spend, and a deeper dependency on the vendor’s uptime and security practices.

Even with the tradeoffs, the market is moving in a clear direction. As per Grand View Research, web and cloud-based EHRs account for over 80% of the US EHR market in 2024.

Where patient data is stored

This is where most vendors differentiate, and where most lock-in happens. Legacy EHR vendors like Epic, Oracle Health and others use proprietary database schemas. The data is theirs in practice, even if it is technically yours in law. Extracting, migrating, or reusing that data outside the vendor’s ecosystem is painful, expensive, and often contractually restricted.

Modern architectures take a different approach. openEHR is an open specification that defines how clinical data can be modelled and stored, using community-defined archetypes for things like blood pressure readings, discharge summaries or medication orders. Because the data model is open and standardized, the data stored in it remains structured, computable and portable between systems.

At the infrastructure level, most cloud EHRs now use relational databases (PostgreSQL, Oracle etc.) with a separate object store for imaging files and time-series storage for vitals and device data.

EHR integration: How EHRs talk to other systems

EHR integration is a deep topic in its own right. For now, the key thing to know is, no EHR exists in isolation. A typical hospital needs its EHR to connect to:

• Laboratory Information Systems (LIS)
• Radiology / Picture Archiving (PACS/RIS)
• Pharmacy Management Systems
• Billing and Revenue Cycle Management platforms
• Patient portals and scheduling tools
• External Health Information Exchanges (HIEs)
• Insurance payers and clearinghouses
• Wearables, remote monitoring devices, and IoT equipment

Historically, this integration used HL7 v2 messages, a specification that has been in use since the late 1980s (and is still widely used today). HL7 v2 works but was designed for point-to-point connections, not modern API-first ecosystems. Many v2 interfaces end up being custom builds maintained by expensive interface engines.

FHIR or Fast Healthcare Interoperability Resources takes a different approach. It uses REST APIs, JSON/XML payloads, and standardized resource-based data models. The result is that integration starts to look more like connecting to any modern web service, and less like managing a legacy interface engine. FHIR isn’t fully replacing HL7 v2. Most production EHRs still run a mix, but for new builds and patient-facing access, it’s the standard.

How external apps connect to EHRs

APIs are how EHR systems expose their data and functionality to outside applications. In a modern EHR, APIs serve several functions:

• Read and write patient data (demographics, clinical notes, lab results)
• Launch external applications within the EHR context (SMART on FHIR apps)
• Receive data from external devices and services
• Power patient-facing apps and portals
• Enable analytics pipelines that pull data into data warehouses

A FHIR-native EHR exposes all of this through standardized FHIR R4 (or R4B) endpoints. A legacy EHR may have its own proprietary API layer that requires separate licensing, custom connectors, and significant developer effort. Even among FHIR-supporting EHRs, the depth of support varies: some only allow reads, some don’t support all resource types, and some have rate limits that make certain use cases impractical. “Has FHIR APIs” is a cue to dig deeper.

Why FHIR APIs are now mandatory in certified EHRs

The 21st Century Cures Act (2016), and its implementation rules ONC Cures Act Final Rule with information blocking (2021) require APIs and interoperability among healthcare systems to give patients frictionless access to their own data. ONC-certified EHR systems must expose FHIR R4 APIs, and blocking data access is now a federal violation under the information blocking rules.

The regulatory push has continued with the CMS finalizing the Interoperability and Prior Authorization Final Rule (CMS 0057-F), requiring payers to implement FHIR APIs for patient access, provider access, and payer-payer exchange. Most provisions took effect in January 2026, with API compliance dates extending into 2027.

The direction is clear: FHIR is the floor, not the ceiling. The ceiling is a fully FHIR-native architecture where every data operation, not just patient access, goes through standardized FHIR endpoints.

Types of EHR systems

Before picking an EHR, you need a map of the landscape. The market is large, fragmented, and confusing. Here is a practical taxonomy.

Enterprise EHRs: Epic, Oracle Health/Cerner, MEDITECH

These are the large-scale, hospital-grade systems built for health systems with hundreds of beds, multiple departments, and complex care networks.

Epic Systems is the dominant player in the U.S. hospital market. Epic holds over 40% of the U.S. acute care hospital market share and over 50% of hospital beds (per the KLAS 2024 acute care EHR market share report). Epic’s strength is integration: one vendor, one platform and deep workflow coverage. Its weakness is cost, implementation complexity, and the degree of vendor lock-in it creates.

Oracle Health (formerly Cerner) is the second largest player with 23% of acute care hospitals per the KLAS 2024 report, although that share has been declining since Oracle’s acquisition of Cerner in 2022. Oracle has invested heavily in AI integration and a planned next generation EHR rebuild, but customer retention has been challenging during the transition.

MEDITECH Expanse is a strong third option (with about 14% of US acute care hospitals), particularly common in community and critical access hospitals. It also has growing international adoption across Canada, the UK, Ireland, Australia, and parts of Africa and Asia. HCA Healthcare, with over 180 hospitals, is one of the largest MEDITECH deployments.

These systems work for large organizations with dedicated IT departments, implementation budgets in the millions, and the staffing to manage a multi-year rollout. For everyone else, they can be overkill and unaffordable.

Ambulatory and small practice EHRs: Athenahealth, eClinicalWorks

The ambulatory EHR market serves physician offices, outpatient clinics, and small to mid-size practices. Athenahealth, eClinicalWorks, Kareo, NextGen, and DrChrono are common names in this space. The US ambulatory EHR market was valued at about $5 billion in 2024, with the smallest practices (<5 physicians) holding the largest share.

These systems are easier to implement and less expensive upfront, but they vary significantly in interoperability capabilities and FHIR readiness. Practices in specialty-heavy or multi-site workflows often hit the limits of ambulatory EHRs quickly and end up customizing extensively or migrating to something larger.

Open-source EHRs: OpenEMR, OpenMRS, Bahmni, VistA

Open-source EHRs are a legitimate and growing category, particularly in global health, low-resource settings, and organizations that want control over their own systems.

OpenEMR is the most widely deployed open-source EHR in the U.S., with an active developer community and ONC certification. It handles basic ambulatory workflows well and is highly customizable.

OpenMRS is built specifically for global health deployments in low- and middle-income countries. It powers clinical systems across sub-Saharan Africa, Southeast Asia, and parts of Latin America. Its modular architecture and community-driven concept dictionary make it adaptable to local clinical needs.

Bahmni is an integrated hospital system built on OpenMRS, OpenELIS and OpenERP and bundles clinical records, lab management and billing. It is widely used across India and in several global health deployments (clinical and public health initiatives in low- and middle-income countries).

VistA is the U.S. Department of Veterans Affairs’ legacy EHR, which was open-sourced and has influenced much of the modern EHR ecosystem. Though the VA is migrating to Oracle Health, the rollout has paused and restarted multiple times. VistA-derived systems remain in use globally.

The challenge with open-source EHRs is implementation capacity. Organizations that choose them need technical teams capable of configuring, hosting, and maintaining the system.

Specialty-Specific EHRs

Some EHRs are designed for particular clinical domains where generic systems fall short. Common examples include:

• Ophthalmology EHRs: Modernizing Medicine’s EMA, Nextech
• Mental health and behavioral EHRs: Kipu, Valant, SimplePractice
• Oncology EHRs: Flatiron Health, iKnowMed
• Dental EHRs: Dentrix, Eaglesoft

Specialty EHRs win on workflow fit. They come with domain-specific templates, clinical decision support rules, and workflow tools that a general EHR will not have out of the box. The downside is integration with the broader health system due to varying FHIR API support, often requiring custom connectors.

Health data platforms

This is the category that often gets missed in standard EHR comparisons, but it is an important one for organizations building or extending clinical systems today.

A Health Data Platform separates the data layer from the application layer. Instead of buying one large EHR that does everything, organizations use a standards-based data repository (typically openEHR plus FHIR) and build or source applications on top of it. Clinical documentation, order management, analytics, and patient engagement tools become modular services that all read from and write to the same underlying data model. Each can now be swapped, upgraded or replaced independently without touching the data itself.

EHR system features: What to look for in 2026

Key EHR system features to evaluate in 2026 fall into five categories: clinical functionality, interoperability, analytics, patient engagement, and security. The lists below cover what to look for in each, with notes on how to test vendor claims.

Core clinical features

These are the non-negotiables. Any EHR system worth evaluating must handle:

• Computerized Provider Order Entry (CPOE): Clinicians enter orders digitally, triggering automatic alerts for drug interactions, allergies, and duplicate orders.
• Clinical Documentation: Structured note templates, SOAP notes, discharge summaries, operative reports. Look for systems that support structured data capture, not just free text, since free text is nearly impossible to query or analyze later.
• e-Prescribing (eRx): Direct electronic transmission of prescriptions to pharmacies. This should include controlled substance prescribing (EPCS) where required by law.
• Problem and Medication Lists: Maintained dynamically, with clinical coding using SNOMED CT or ICD-10.
• Allergy and Adverse Reaction Tracking
• Lab results encoded with LOINC, SNOMED CT and/or local codes
• Vital Signs and Flowsheets

Interoperability features

This is where most EHRs fail, and it is now the most important feature category for any organization planning to grow or integrate with external systems.

• FHIR R4 API support: Mandatory for ONC certification. Ask vendors which FHIR resource types are supported, and whether both read and write operations work
• Health Information Exchange (HIE) connectivity: Can the system query and receive data from state or regional HIEs?
• Direct Messaging: Secure provider-to-provider messaging using the Direct protocol.
• Patient access APIs: Compliance with the 21st Century Cures Act’s patient access requirements.
• FHIR bulk data export for analytics, research and evaluating population health
• SMART on FHIR support: Can third-party apps launch within the EHR context using standardized tokens? This is the foundation of an app marketplace model.

Engagement in interoperable exchange increased by 54% from 2018 to 2023 among U.S. hospitals, which signals real progress. But large or system-affiliated hospitals reported 53% routine engagement in all interoperability domains versus 22% among independent hospitals. The gap remains wide.

Analytics and reporting

EHR data is only useful if you can extract and act on it. Features to evaluate:

• Standard quality measure reporting (HEDIS, CMS eCQMs)
• Population health dashboards for chronic disease management and preventive care gaps
• Custom report builders that do not require IT tickets
• Data export to external analytics platforms (Snowflake, Databricks, Azure Health Data Services)
• Cohort building tool for clinicians and researchers to query patient populations directly

Patient Engagement

• Patient portal: secure messaging, test result access, appointment scheduling, and medication refill requests.
• Telehealth integration: Native video visit capability or deep integration with telehealth platforms
• Patient-reported outcome (PRO) collection
• Mobile app access for patients and clinicians

Most US EHR systems allow patients to access their records electronically, but the differentiator is how usable it is and how much data it exposes.

Security and Compliance

• HIPAA compliance (for U.S. systems): Role-based access control, audit logs, breach notification workflows, Business Associate Agreement (BAA) with the vendor
• GDPR compliance for organizations operating in or serving European patients
• Data residency controls for organizations subject to national localization laws
• Encryption at rest and in transit
• Multi-factor authentication (MFA)
• Penetration testing cadence and SOC 2 Type II certification from the vendor

Cyberattacks on healthcare systems have escalated sharply in recent years. The February 2024 ransomware attack on Change Healthcare disrupted prescriptions, claims processing, and clinical operations across the U.S. for weeks, affecting about 192 million individuals. Security is an ongoing operational commitment. Ask vendors about their incident response history, breach disclosure timelines, and recovery point objectives.

Why do so many EHR implementations fail?

EHR implementation is hard, and the failure rate has in fact become worse. According to the [2025 KLAS Arch Collaborative report](https://klasresearch.com/archcollaborative/report/ehr-implementations-2025/628) only 38% of organizations say their recent implementation hit the mark. And the number has dropped consistently since 2022.

These are not small projects. EHR implementations take years to deploy and stabilize, with total costs running from millions for community hospitals, to over a billion dollars for large health systems.

Let’s look at why many EHR implementations fail.

Data migration from legacy systems

Moving years or decades of clinical data from one system to another is one of the most technically complex tasks in health IT. Common failure points include:

• Inconsistent data formats and structures across source systems
• Unmapped clinical terminologies (an old system using local codes versus SNOMED CT or LOINC)
• Incomplete migration of historical notes, images, or structured data
• Loss of provenance and audit history during the migration
• Data quality issues that only surface after go-live

A common best-practice approach is a parallel run: keep the old system accessible in read-only mode for at least 12 months post-migration so clinicians can reference historical data without forcing everything through the new system immediately.

Clinical workflow disruption and change management

Technology does not change behavior. People change behavior when technology is designed around how they actually work. EHR implementations that are designed by IT teams without deep clinician input consistently produce systems that slow everyone down. This is one of the most consistently cited drivers of EHR failure.

Involving frontline clinical staff, especially nurses and physicians, early in the planning and decision making is a key differentiator between EHR projects that succeed and ones that struggle.

EHR Integration challenges

Almost no hospital runs a single EHR. There are almost always peripheral systems that need to connect, such as lab analyzers, imaging equipment, pharmacy robots, scheduling tools, and billing platforms. Every point of integration is a potential failure point, especially when relying on legacy HL7 v2 interfaces that require constant maintenance.

Modern, FHIR-native architectures reduce the technical burden, but vendors can still add friction (e.g. charging for API access, limiting integration depth, restricting third-party connections, etc.)

Clinician Burnout and Usability Issues

Clinician burnout is one of the most consistently cited problems with EHR systems. A 2018 Stanford Medicine poll found that 74% of clinicians noted increased work hours after EHR implementation, with 71% attributing burnout to EHRs.

The usability data backs this up. EHRs are among the worst rated systems in usability, receiving an F grade on the System Usability Scale in a 2019 AMA study, the same scale on which Google’s search engine receives an A, and microwave ovens, ATMs, and Amazon’s website receive Bs.

A failing grade on usability is a patient safety problem. Poor usability has been directly linked to low adoption rates, user dissatisfaction, and reduced clinical efficiency.

Cost Overruns and Timeline Delays

Large EHR implementations almost always run over budget and over schedule. The reasons are predictable: underestimated data migration complexity, inadequate change management budgets, unexpected integration work, and the need for extended training.

The future of EHR systems is modular, open, and FHIR-native

The next decade of EHR architecture will look meaningfully different. Open standards, AI, and growing dissatisfaction with monolithic systems are reshaping how clinical software is built, bought, and connected.

From monolithic EHRs to health data platforms

The shift from monolithic to modular EHRs is happening in three ways.

Some hospitals keep their core EHR and build a parallel openEHR or FHIR-based data layer for specific use cases where the existing system falls short, e.g. clinical research, analytics, and specialty workflows. This way, clinical data stays in the EHR, and a structured copy is in the open layer.

Some deploy new specialty modules connected to the main EHR through FHIR APIs. New use cases get built on modern architecture while legacy use cases stay where they are.

Lastly, greenfield deployments skip the monolithic option entirely and start with a modular health data platform approach from day one.

In all three patterns, the data layer is the long-term asset, and applications become replaceable.

SMART on FHIR and the app marketplace model

SMART on FHIR is an open standard for launching third-party applications within an EHR session. A SMART on FHIR app launches with the patient context already loaded, can query FHIR APIs for the data it needs, and write results back to the record, all without requiring a separate login or data export.

Effectively, SMART on FHIR turns the EHR into a platform that other software can build on, rather than a closed system that has to provide every feature itself. Specialty workflows, decision support tools, ambient documentation, research instruments, patient engagement apps, and analytics dashboards can all be built by third parties and dropped into existing EHR workflows.

Epic runs this model at scale with its Showroom marketplace (formerly App Orchard) with hundreds of approved third-party apps, basically an app store for clinical software. The standard itself is open, so any FHIR-native EHR platform can support the same app ecosystem.

AI in EHRs

The most adopted AI use case is ambient documentation: AI listens to the patient-clinician conversation and autogenerates structured notes. Major EHR vendors have started shipping native versions, with Epic launching AI Charting and athenahealth launching athenaAmbient in February 2026.

Clinically valuable AI applications in EHR systems include:

• Ambient clinical documentation: AI listens during visits and generates structured notes from the conversation
• Diagnostic decision support: Surfacing relevant clinical guidelines, drug interaction alerts, and differential diagnoses at the point of care
• Predictive risk scoring: Identifying patients at risk for sepsis, readmission, or deterioration before it happens. Real-world performance has been uneven, Epic’s sepsis prediction model, for example, has faced criticism for high false-positive rates.
• Coding and billing automation: Mapping clinical notes to billing codes

For AI to work well in an EHR, the data needs to be structured and computable, not locked in unstructured free text. This is one of the practical arguments to use openEHR archetypes: they define what data elements mean and make it machine readable.

How openEHR and FHIR work together

openEHR and FHIR are two open standards that solve different problems. openEHR defines how clinical data is modelled and stored using community-defined archetypes. FHIR defines how data is exchanged between systems via REST APIs. Used together, openEHR handles clinical depth and long-term storage; FHIR handles interoperability and app integration.

Real-world adoption is concentrated in greenfield deployments and national or regional health programs, including openEHR-based platforms in Slovenia, Catalonia, Norway, Wales, and parts of India. Many of these expose FHIR APIs for interoperability with other systems. None of these are at the market scale of Epic or Oracle Health, but the trajectory is upward, particularly for new builds.

The Medblocks approach to EHR development

Most EHR vendors lock you into their data model, their integrations, and their pace of change. Medblocks takes a different approach: ingest and structure clinical data on open standards, so the data layer outlasts any single application and remains usable across analytics, integrations, and new builds.

Medblocks platform

Medblocks gives clinical teams and developers access to the complete patient record across EHRs, payers, HIEs, labs, wearables and mobile apps. Data is ingested through FHIR, HL7, TEFCA, and direct connectors. AI handles the heavy lifting (code mapping, structuring PDFs and clinical notes, cross-source deduplication, MDM matching) and every result is human-verified and traceable back to the source.

Once the data is in, teams can query it in plain English or use pre-built templates for HCC, HEDIS, and care gaps. The engine writes deterministic SQL on top of audited data models, so the same question returns the same answer every time. Output can be exported to Snowflake, BigQuery, S3, or a FHIR server, or pushed downstream through CDS Hooks and FHIR Webhooks for real-time decision support.

Medblocks is built on openEHR for clinical data persistence, FHIR for interoperability, and SNOMED CT for terminology. The data layer is open by design. No proprietary schema to extract from, no vendor lock-in.

Medblocks Sprint

Medblocks Sprint is a development-as-a-service offering that brings our team into a project directly. It’s designed for teams that want to move fast on custom EHR or clinical platform development without starting from zero. Our team handles the openEHR modeling, FHIR integration, terminology binding, and infrastructure setup, while the customer’s team focuses on the clinical and product decisions.

Typical use cases include new specialty EHRs, national health data platforms, clinical research data repositories, and modules that extend existing EHR deployments.

What else to consider when evaluating an EHR

What ONC certification actually means

In the U.S., the [Office of the National Coordinator for Health Information Technology (ONC)](https://healthit.gov/certification-health-it/about-onc-health-it-certification-program/) runs a certification program for EHR systems. ONC certification means a system has been tested against specific criteria for functionality, security, and interoperability. This includes baseline FHIR R4 API support, patient access APIs and clinical quality measure reporting. Certification is necessary for providers to qualify for certain Medicare and Medicaid programs.

Certification does not necessarily mean the system is good to use. A certified EHR can still have poor usability, slow performance, and bad implementation support. Certification sets a baseline; don’t read it as a recommendation.

EHR total cost of ownership

The license fee or per-user pricing is almost never the real cost of an EHR. Total cost of ownership (TCO) for an enterprise EHR implementation includes:

• Software licensing: Annual or per-user fees
• Implementation services: Consultants, project managers, configuration work. Often 2 to 3x the software cost
• Hardware and infrastructure: Servers, network upgrades, workstations (for on-premise systems)
• Data migration: Extracting, transforming, and loading data from legacy systems
• Training: Initial training plus ongoing onboarding for new staff
• Integration development: Connecting labs, imaging, billing, and third-party tools
• Ongoing maintenance and support: Annual vendor support contracts
• Productivity loss during transition: Often underestimated, sometimes severe
• Exit costs: Migrating off an EHR years later, including data extraction fees and parallel-run periods

For large hospital systems, the numbers are sobering. The most expensive Epic implementations on record (from Becker’s Hospital Review) include Kaiser Permanente ($4 billion), Mayo Clinic ($1.5 billion), Mass General Brigham and Northwell Health (both $1.2 billion). Mid-size implementations typically run $50 million to $200 million.

Cloud-based and modular platforms reduce the infrastructure and implementation overhead, but TCO analysis should always cover at least a 5-year horizon before any vendor decision is made.

The four levels of interoperability every buyer should understand

Interoperability is one of the most overused and least precisely defined terms in health IT. Before accepting any vendor’s claim about being “interoperable,” ask which level they are actually delivering according to the HIMSS definition:

1. Foundational interoperability: Systems can send and receive data. The receiving system does not need to interpret the data. This is basic connectivity.

2. Structural interoperability: Data is exchanged in standardized formats (HL7, FHIR). The structure is defined, but the meaning might not be fully consistent.

3. Semantic interoperability: Data meaning is consistent across systems because both sides use the same clinical terminology standards (SNOMED CT, LOINC, RxNorm). A diagnosis code in one system means exactly the same thing in another.

4. Organizational interoperability: Policies, governance, and workflows are aligned to enable effective data sharing across organizations, not just technical connectivity.

Most legacy EHRs deliver foundational or structural interoperability. True semantic interoperability requires commitment to clinical terminology standards, which is why openEHR archetypes and SNOMED CT bindings matter at the data layer. Organizational interoperability is harder still: most health systems are nowhere close.

Key Takeaways

• EHR and EMR are often used interchangeably, though the technical distinction (EHR shares data across providers; EMR stays in one practice) matters for regulation and procurement decisions.

• Only 38% of recent EHR implementations hit the mark, per the 2025 KLAS Arch Collaborative report, and satisfaction has dropped consistently since 2022.

• The global EHR market is large and growing, estimated at around USD 35 billion in 2025 and projected to reach over USD 53 billion by 2033, with cloud-based systems dominating new deployments.

• FHIR is mandatory, not optional. ONC certification requires FHIR R4 APIs, and the 21st Century Cures Act makes information blocking a federal violation.

• Clinician burnout is an EHR design problem. A 2018 Stanford / Harris Poll found 71% of physicians said EHRs contribute greatly to burnout, and more recent surveys continue to identify EHR-related documentation burden as a top contributor.

• The architecture of the future separates data from applications. openEHR for clinical data persistence, FHIR for interoperability, and SNOMED CT for terminology give organizations a vendor-neutral foundation.

• You can build your own EHR on open standards. Platforms like Medblocks provide the infrastructure layer so teams don’t start from zero.

• Total cost of ownership matters more than license price. Enterprise EHR implementations regularly cost $50 million to over $1 billion when all costs are included, with major deployments like Kaiser Permanente reaching $4 billion.

• Interoperability has four levels (foundational, structural, semantic, organizational). Most vendor claims stop at structural. Semantic and organizational interoperability require standards commitment, not just a FHIR endpoint.

Conclusion

The best EHR systems in 2026 are not necessarily the biggest or most feature-rich. They are the ones built on architectural foundations that give organizations control over their clinical data, real interoperability with the broader health ecosystem, and the flexibility to evolve without being locked into a single vendor.

The monolithic EHR model had its era. The next model separates data from applications, exposes everything through FHIR APIs, stores clinical data using openEHR archetypes, and lets organizations compose the clinical software they actually need.

Medblocks is built on this model. Whether you need access to the complete patient record, want to extend an existing EHR, or are building a custom clinical platform, book a call to see the platform in action.

Related articles

View all

April 17, 2026

How to Get a Patient's Health Record in 2026

You'd think I'd tell you about APIs or tools. The key is in understanding legal coverage.

January 2, 2026

XDS Explained: Build a Working Document Exchange on Your Laptop

A simple XDS tutorial: understand Registry vs Repository and run the core XDS flow end-to-end with the NIST XDS Toolkit, Docker, and Postman.

December 21, 2025

Catalonia's openEHR CDR for 8 Million People

Catalonia wanted an openEHR Clinical Data Repository for 8 million people. Medblocks worked with IBM and vitagroup to design the sync layer for hospitals.