EHR Capabilities

What are EHR capabilities?

EHR capabilities are the clinical, administrative, patient-facing and technical functions an electronic health record system offers: documentation and orders, medication management, decision support, scheduling and billing data, patient portal and API access, quality reporting, public health reporting, exchange with other providers and the security controls around all of it. EMR capabilities are the same functions scoped to one practice, with less emphasis on exchange.

The capability groups

• Clinical: Problem lists, medications, allergies, notes, orders, results and care plans.
• Decision support: Alerts, reminders, order sets and predictive interventions.
• Medication: e-Prescribing, formulary checks, medication reconciliation and controlled substance prescribing.
• Patient access: Portal, view, download and transmit, and API access for patient apps.
• Exchange: Transitions of care documents, direct messaging, query-based exchange and network participation.
• Reporting: Quality measures, public health reporting and operational analytics.
• Platform: APIs, data export, audit logging, authentication and configuration tools.

Why do EHR capabilities matter now?

• Certification defines the baseline: ONC Health IT Certification Program criteria at 45 CFR 170.315 are grouped into clinical (a), care coordination (b), clinical quality measures (c), privacy and security (d), patient engagement (e), public health (f), design and performance (g) and electronic exchange (h).
• 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, and the 2026 objectives cover e-prescribing, health information exchange, provider to patient exchange and public health reporting.
• APIs are standardized: Under criterion 170.315(g)(10), certified EHRs expose a FHIR API with SMART App Launch and, under HTI-1, must support USCDI v3, US Core 6.1.0, SMART App Launch 2.0 and Bulk Data Access from January 1, 2026.
• All data must be exportable: Criterion 170.315(b)(10) requires export of all electronic health information for a single patient or a whole population in a documented, computable format.
• Decision support is transparent: Criterion 170.315(b)(11), decision support interventions, replaced the older clinical decision support criterion from January 1, 2025 and requires source attribute information for predictive interventions.
• Safety is assessed: ONC's SAFER Guides provide self-assessment checklists for EHR safety, and hospitals in the Promoting Interoperability Program attest to an annual assessment.

How does ONC certification organize EHR capabilities?

The diagram maps the eight certification groups at 170.315 to the capabilities buyers and builders actually ask about. Certification status for any product is public on ONC's Certified Health IT Product List.

• (a) Clinical: Order entry, demographics, problem and medication lists, clinical notes and family health history.
• (b) Care coordination: Transitions of care, clinical information reconciliation, e-prescribing, EHI export and decision support interventions.
• (c) Clinical quality measures: Recording, importing, calculating and reporting measures.
• (d) Privacy and security: Authentication, access control, auditable events, audit reports, encryption and multi-factor authentication.
• (e) Patient engagement: View, download and transmit, and secure messaging.
• (f) Public health: Immunization, syndromic surveillance, case and registry reporting.
• (g) Design and performance: Safety-enhanced design, quality management, accessibility and the standardized FHIR API.
• (h) Electronic exchange: Direct messaging and related edge protocols.

Which EHR capabilities should you check before building on an EHR?

When a product will integrate with or extend an EHR, a handful of capabilities decide how hard the work will be. Check them in the vendor's documentation and in a test tenant, not in a sales deck.

• FHIR API coverage: Which resources are readable and writable, which FHIR version, and how far beyond US Core the vendor goes.
• App launch: SMART App Launch support for EHR launch and standalone launch, and the vendor's app program requirements.
• Bulk data: Whether population exports are available to your organization and how fast.
• Events: Subscriptions, webhooks or HL7 v2 feeds for admissions, orders and results.
• Write-back: Which notes, orders, documents and flowsheet data can be written and under what review.
• Identity: Single sign-on, user provisioning and how your app's users map to EHR users.
• Configuration tools: Templates, order sets, rules and reports that can be changed without vendor releases.
• Audit and export: Access logs you can read, and the EHI export when you need everything.

Certified does not mean enabled

A product can be certified for a criterion that the customer never turned on, or turned on with a configuration that limits what your application can do. Bulk data access, event feeds and write-back are the usual cases. Ask the customer's EHR team what is enabled in their tenant, and test it there, before you promise a feature that depends on it.

Reading the audit trail

Every certified EHR records auditable events, and your application's reads and writes appear in that trail under the identity you authenticate with. Design so the trail makes sense to the customer's privacy officer: named service accounts, user context passed through when a clinician acts, and no bulk reads where a single-patient query would do.

How do teams assess EHR capabilities step by step?

• 1. Write the use cases: What your users must do in or alongside the EHR, in plain scenarios.
• 2. Check certification: The product's criteria on the Certified Health IT Product List, including (g)(10) and (b)(10).
• 3. Read the API documentation: Resources, versions, scopes, rate limits and sandbox access.
• 4. Get a test tenant: Run the scenarios against real configuration, not the public sandbox alone.
• 5. Test write-back and events: The two capabilities most often promised and least often complete.
• 6. Review security and audit: Authentication options, access logs and how your app's activity appears in them.
• 7. Price the gaps: Interface fees, app program costs and the custom work the gaps require.
• 8. Decide and document: Which capabilities you rely on, which you build around and what changes when the vendor upgrades.

What are EHR capabilities best practices?

• Use the certified API first: Standard FHIR before proprietary interfaces, because it survives upgrades.
• Configure before you code: Templates, rules and reports the EHR already supports cost less than custom apps.
• Keep one source of truth: Data created elsewhere is written back to the EHR through the API.
• Plan for versions: USCDI, US Core and vendor API versions change on a schedule. Track them.
• Test on real configuration: Every site's EHR is configured differently, so test tenants matter.
• Watch the audit trail: Your app's reads and writes should be visible and explainable.
• Run the SAFER Guides: Especially when adding decision support or changing order workflows.

The practices above keep an integration working through the EHR's own changes. The mistakes below are how integrations break between upgrades.

What are the common mistakes with EHR capabilities?

• Trusting the feature list: Capabilities that are certified but not enabled, or enabled but not configured.
• Assuming write-back: Reading data is common, writing it is often limited or reviewed.
• Sandbox only testing: The public sandbox works, the customer's tenant does not.
• Ignoring the app program: Vendor review requirements discovered after the build.
• Building what configuration could do: Custom apps for problems a template or rule would solve.
• No upgrade plan: Vendor releases change APIs and workflows, and nobody is watching.

What do EHR capabilities mean for your build plan?

• Use cases and sites: Each EHR and each site's configuration is its own work.
• API and events: FHIR coverage, bulk data and event feeds decide the integration design.
• Write-back and review: What your product can change in the record, and how.
• App program and fees: Vendor review, listing and interface costs.
• Security and audit: Authentication, access logs and the evidence you keep.
• Operations: Version tracking, vendor upgrades and test tenants over time.

For the integration patterns themselves, our EHR integrations guide covers methods and costs, and our EHR data analytics guide covers getting the data out for reporting.

How Agnotic can help

Agnotic Technologies is a software development services company. We assess EHR capabilities for your use cases and build what the EHR does not do: SMART on FHIR apps, FHIR and HL7 v2 integrations, event pipelines, write-back with review, and the data platforms that turn EHR data into reports and models, with HIPAA safeguards designed in. Your EHR stays the system of record. We make it do more.

Sources

• 45 CFR 170.315: ONC Health IT certification criteria
• ASTP/ONC: Certification criteria
• ASTP/ONC: Certified Health IT Product List
• 42 CFR 495.4: Definitions, including certified EHR technology
• CMS: Promoting Interoperability Programs
• ASTP/ONC: Standardized API for patient and population services, 170.315(g)(10)
• ASTP/ONC: Electronic health information export, 170.315(b)(10)
• ASTP/ONC: SAFER Guides