Types of EHR Systems

What are the types of EHR systems?

The types of EHR systems are the categories used to describe electronic health records: ambulatory, inpatient and specialty systems by care setting; on-premises, vendor-hosted and cloud systems by deployment; ONC certified and non-certified systems by regulatory status; and commercial, open source and custom-built systems by origin. Most organizations run a mix, and the type shapes cost, integration and patient access.

By care setting

• Ambulatory EHR: Clinic and practice workflows, scheduling, visits, orders and professional billing.
• Inpatient EHR: Admissions, orders, medication administration, nursing documentation and hospital billing.
• Enterprise EHR: One platform across inpatient, ambulatory and specialty settings, typical of large health systems.
• Specialty EHR or EMR: Templates, orders and devices for one specialty, such as an orthopedic EMR with imaging, implant and outcomes tracking.
• Behavioral health and post-acute systems: Records built around their own documentation, consent and billing rules.

By deployment, certification and origin

• On-premises: Servers the organization owns and runs, with full control and full responsibility.
• Vendor-hosted or cloud: Run by the vendor or a cloud provider under a Business Associate Agreement, with less infrastructure to manage.
• ONC certified: Tested against 45 CFR 170.315 criteria and listed on the Certified Health IT Product List; required for Medicare and Medicaid incentive and reporting programs.
• Non-certified: Common in cash-pay, wellness and some specialty settings where no program requires certification.
• Commercial, open source or custom: Licensed products, open source platforms you host and extend, or systems built for a care model no product fits.

Why do the types of EHR systems matter now?

• Certification is a category: ONC Health IT Certification Program criteria at 45 CFR 170.315 define the capabilities a certified EHR must have, and certification status for every product is public on the Certified Health IT Product List.
• Programs require certified EHRs: Hospitals in the Medicare Promoting Interoperability Program and MIPS clinicians must use certified EHR technology as defined at 42 CFR 495.4.
• APIs come with certification: Under criterion 170.315(g)(10) and the HTI-1 rule, certified EHRs expose a FHIR API supporting USCDI v3, US Core 6.1.0, SMART App Launch 2.0 and Bulk Data Access from January 1, 2026, which non-certified systems may not offer.
• Patients have rights in every type: Under 45 CFR 164.524, covered entities must give patients access to their records as soon as practicable and no later than 30 days after a request, however the system is deployed.
• Cloud needs a BAA: HHS OCR's cloud computing guidance states that a cloud provider storing ePHI is a business associate even if the data is encrypted and the provider has no key.
• Data must move between types: The information blocking rules at 45 CFR Part 171 apply to certified and non-certified systems alike when they hold electronic health information.

How do you choose between the types of EHR systems?

The diagram sets the four classifications side by side and shows the questions that decide each. Answer them in order: setting, certification, deployment, then origin.

• Setting: Which care settings and specialties must the record serve, and do they need one platform or connected systems?
• Certification: Do you bill Medicare or Medicaid under programs that require certified EHR technology, or do customers expect certification?
• Deployment: Do you have the team to run servers, or does a hosted system under a BAA fit better?
• Origin: Does a commercial product fit the care model, can an open source platform be extended, or is the workflow new enough to justify building?
• Integration: Whatever the type, how will it exchange data: FHIR APIs, HL7 v2, C-CDA documents and network participation?

What specialty systems add

The benefits of orthopedic EMR systems, and specialty records in general, come from fitting the specialty's workflow: imaging and implant tracking, procedure templates, outcome scores and device integration for orthopedics; measurement instruments and consent rules for behavioral health. The trade-off is exchange: a specialty record still has to share data with the enterprise EHR, labs, payers and patients through standard interfaces.

Benefits of EHR systems for patients

For patients, a modern EHR means one record across visits, results and notes they can read in a portal, medications reconciled across prescribers, reminders for preventive care and the ability to connect an app of their choice through the certified API. The type matters less to patients than whether the organization has turned those capabilities on.

Open source as a middle path

Open source EHR platforms sit between commercial products and custom builds: you host and extend them, and you carry the operations, security and, where needed, certification work yourself. They suit organizations with engineering capacity and a care model that products do not fit, and they still need the same standard interfaces to exchange data.

Exit terms and data ownership

Whatever the type, the contract decides what happens when you leave: how data is exported, in which format, how long the archive stays readable and what it costs. Under criterion 170.315(b)(10), certified systems must be able to export all electronic health information, which is the floor to insist on.

What are the steps to build an EHR system when none fits?

• 1. Prove no product fits: Write the care model and test it against commercial and open source options first.
• 2. Decide on certification: Which ONC criteria are in scope decides the data model, APIs and security work.
• 3. Design the platform: FHIR data model or facade, terminology services, identity, audit logging and an integration engine.
• 4. Build the chart first: Documentation, problems, medications and allergies before orders, results and billing.
• 5. Connect early: Labs, pharmacy networks, payers and partner EHRs through standard interfaces.
• 6. Test and certify: Conformance, security, accessibility and clinical safety testing as part of the build.
• 7. Pilot and expand: One site, measured, then more.
• 8. Plan upgrades: USCDI versions, code sets and regulations change every year.

What are the best practices when choosing an EHR system type?

• Start from the care model: Setting and specialty first, then everything else.
• Check certification on the CHPL: Not on the vendor's slide.
• Insist on the standard API: FHIR R4 with SMART App Launch and bulk data, whatever the type.
• Match deployment to your team: Hosted systems trade control for less operations work.
• Keep specialty records connected: Standard interfaces to the enterprise record, labs and payers.
• Turn on patient capabilities: Portal, API access and reminders are only benefits when enabled.
• Plan the exit: Data export and archive terms before you sign.

The practices above keep the choice honest. The mistakes below are the ones that show up a year after the contract.

What are the common mistakes with EHR system types?

• Choosing by brand: A system picked for its name rather than the care setting it must serve.
• Assuming certification: A product certified for some criteria and not the ones your program needs.
• Specialty islands: Specialty EMRs that never connect to the enterprise record.
• Cloud without the BAA: Hosted systems adopted before agreements are in place.
• Building too early: A custom EHR started before proving that nothing on the market fits.
• Ignoring exit terms: Data trapped in a system when the contract ends.

What do EHR system types mean for your build plan?

• Settings and specialties: Each adds workflows, templates and integrations.
• Certification scope: Criteria in scope drive data model, API and security work.
• Deployment: Operations team and cost for on-premises versus hosted.
• Integration: FHIR, HL7 v2 and documents between systems of different types.
• Patient capabilities: Portal, API access and reminders to enable and support.
• Custom build: Only after products are ruled out, with a certification and upgrade plan.

For the build path, our EHR development guide covers architecture and certification, and our custom EHR software development guide covers the build or buy decision.

How Agnotic can help

Agnotic Technologies is a software development services company. We work across every type of EHR system: integrating certified ambulatory and inpatient EHRs through FHIR and HL7 v2, extending specialty records, hosting and connecting open source platforms, and building custom EHR modules when the care model needs them, with HIPAA safeguards and certification requirements designed in. You choose the type; we make the systems work together.

Sources

• 45 CFR 170.315: ONC Health IT certification criteria
• ASTP/ONC: Certified Health IT Product List
• 42 CFR 495.4: Definitions, including certified EHR technology
• ASTP/ONC: Standardized API for patient and population services, 170.315(g)(10)
• 45 CFR 164.524: Access of individuals to protected health information
• HHS OCR: Guidance on HIPAA and cloud computing
• 45 CFR Part 171: Information blocking
• ASTP/ONC: HTI-1 final rule