EHR Features

Which EHR features does your project actually need?

EHR features a project needs are the ones that complete its core clinical and billing loop for each user role: scheduling, intake, charting, orders and prescribing, results, claims and patient access. Everything else, from analytics to specialty extras, belongs in a later release unless it is the reason the product exists.

Feature groups by user role

Start the feature list from roles, not modules. Each role has a short set of tasks it repeats all day, and those tasks define the features that matter most.

• Front desk: Scheduling by visit type and resource, registration, insurance card capture, X12 270/271 eligibility results, consent forms and copay collection.
• Medical assistant or nurse: Rooming, vitals, medication and allergy reconciliation, questionnaires that file as discrete answers, standing orders and patient messages handled under protocol.
• Clinician: Problem-oriented notes, problem list coded in SNOMED CT and ICD-10-CM, order entry with interaction checks, e-prescribing, results review with trends, and referrals.
• Biller or coder: Charge capture from the signed note, coding edits, X12 837 claims, 835 remittance posting and denial work queues by reason code.
• Patient or caregiver: Booking, forms, results, messages, refill requests and record download, with proxy access for a caregiver where the patient allows it.
• Administrator: User and role management, templates, order sets, reporting and audit log review.

How do you sort features into release tiers?

Sort every candidate feature into one of three tiers, using the same four questions for each. Write the answer next to the feature so the tier can be challenged later.

• Loop test: Does the core loop of schedule, intake, chart, order, result and bill break without it? If yes, it is release one.
• Rule test: Does a regulation, certification criterion or payer rule require it for the users you serve at launch? If yes, it is release one.
• Workaround test: What does the workaround cost each day in staff time or risk? A cheap, safe workaround can move a feature to release two.
• Difference test: Is this the feature that sets your care model apart? If yes, it belongs in release one even when a workaround exists.
• Tier 1, release one: Passes the loop, rule or difference test.
• Tier 2, next release: Useful, with a safe workaround for now.
• Tier 3, not building: Covered by another system, or asked for by one user without a clear task behind it.

Which features do certification criteria define?

For a certified EHR, some features are defined by ONC criteria at 45 CFR 170.315. For a product that is not certified, these criteria still describe what buyers will compare against.

• Standardized API: Criterion 170.315(g)(10) defines a read API for patient and population services: USCDI data through US Core profiles, SMART App Launch and Bulk Data export. It does not cover writing data into the EHR.
• Patient portal: View, download and transmit to a third party is criterion 170.315(e)(1), separate from the (g)(10) API that third-party apps use.
• Data export: Criterion 170.315(b)(10) requires certified developers to support export of all electronic health information for one patient or a whole patient population.
• Decision support: HTI-1 replaced the old clinical decision support criterion (a)(9) with Decision Support Interventions at (b)(11). The HTI-5 final rule then removed the predictive DSI model card and source-attribute requirements.
• Criteria change: The HTI-5 final rule, published in the Federal Register on 28 October 2026, removes 14 criteria and revises 7. The removals include family health history (a)(12) and care plan (b)(9), with effective dates of 28 December 2026 or 1 January 2027 depending on the criterion.

Which security features does HIPAA name?

The HIPAA Security Rule at 45 CFR 164.312 names technical safeguards but stays technology-neutral, so the feature design is yours. Each safeguard is either required or addressable.

• Required: Unique user identification, an emergency access procedure, audit controls that record activity in systems holding ePHI, and person or entity authentication.
• Addressable: Automatic logoff, encryption and decryption of ePHI at rest, an integrity mechanism, and encryption in transmission. Addressable means implement it, or document why an equivalent measure is reasonable.
• Proposed: The January 2025 HHS proposed rule would make multi-factor authentication and encryption required. Until a final rule says so, treat MFA as good practice that buyers and security reviewers may ask for.

In feature terms, that means a role-based access model, a break-glass flow with after-the-fact review, an audit trail of who viewed or changed each chart, session timeouts on shared devices, and encryption settings documented in the risk analysis.

Buy, extend or build: deciding feature by feature

• Buy or integrate: Commodity networks and content such as pharmacy routing, drug interaction knowledge bases and clearinghouse connections. Rebuilding them adds certification and maintenance work without adding difference.
• Use the EHR's own feature: Standard charting, ordering and billing that the vendor already supports well. Configuration costs less than custom code and stays inside the vendor's upgrades.
• Extend with SMART on FHIR or CDS Hooks: Specialty screens, intake flows, calculators and decision cards that read EHR data and run inside the clinician's workflow without changing the core database.
• Build in a custom platform: Workflows the EHR cannot model at all, such as a care model built around a team task board or a home-based program, where the custom product becomes the system of record for that work.

When a custom feature needs to write data into the EHR, check the vendor's write APIs or plan an HL7 v2 interface before committing to the design.

What belongs in a feature spec?

A feature is ready to build when an engineer and a clinician read the same spec and agree how to test it. Each spec should carry these fields.

• 1. Role and task: Who uses the feature, in which visit type, and what they are trying to finish.
• 2. Trigger: The event that opens the feature, such as check-in, order signing or a result arriving.
• 3. Data elements: Every field, with its terminology binding: SNOMED CT or ICD-10-CM for problems, LOINC for results and vitals, RxNorm for medications, CPT for procedures.
• 4. Exchange mapping: The FHIR R4 resource or HL7 v2 segment each field maps to, so the data can leave the system later.
• 5. Rules: Validation, defaults, alerts and who may override them.
• 6. Audit events: What the system logs when the feature is used, viewed or changed.
• 7. Accessibility: Keyboard use, screen reader labels and contrast. HHS Section 504 rules adopt WCAG 2.1 Level AA, and designing to WCAG 2.2 AA covers it.
• 8. Acceptance tests: Named scenarios with expected results, run with a clinician before release.

A worked example: pre-visit intake for a specialty clinic

Take a pre-visit intake feature for a specialty clinic. The role is the patient, with the medical assistant as reviewer. The trigger is an appointment booked at least two days ahead, which sends a link to the patient. The data elements are the reason for visit, current medications coded to RxNorm, allergies, and a specialty questionnaire whose answers each carry a code.

The exchange mapping stores answers as a FHIR QuestionnaireResponse, with medications and allergies offered to the medical assistant for reconciliation rather than written straight into the chart. The rules say what happens when the patient skips a required question. The audit events record who reviewed and accepted each item. The acceptance tests cover a complete form, a partial form, a caregiver filling it in and a patient on a screen reader.

Written this way, the spec also answers the build decision: if the EHR vendor offers a write API for reconciled medications, the feature can be a SMART on FHIR app; if not, it needs an interface or a reviewer step that keys the data in.

Feature traps that slow clinicians

• Checkbox scoring: A 400-line RFP checklist scores a ten-click prescribing screen the same as a two-click one, so usability problems appear only after launch.
• Free-text fields for data that drives rules: Diagnoses, vitals and screening dates stored only in narrative cannot feed alerts, measures or FHIR queries.
• Every alert switched on: Low-value pop-ups teach users to click through, including the alert that matters.
• One screen for every role: A rooming assistant should not scroll past a surgeon's history tabs to record vitals.
• No provenance: Data carried forward without showing where it came from, such as patient-reported or pharmacy fill, leaves clinicians unsure how far to trust it.
• Custom code inside the vendor database: Changes made outside documented APIs break on the next vendor upgrade.

How Agnotic can help

Feature scoping is where an EHR project's cost and adoption are decided. Agnotic Technologies works through the role map, release tiers and feature specs with the client's clinicians, then builds the features that need building: SMART on FHIR apps, CDS Hooks services, intake flows and HL7 v2 or FHIR R4 interfaces.

Sources

• 45 CFR 170.315: ONC Health IT certification criteria
• ASTP/ONC: Standardized API for patient and population services, 45 CFR 170.315(g)(10)
• ASTP/ONC: Electronic health information export, 45 CFR 170.315(b)(10)
• ASTP/ONC: Decision support interventions, 45 CFR 170.315(b)(11)
• ASTP/ONC: HTI-5 final rule removals or revisions of certification criteria
• 45 CFR 164.312: HIPAA Security Rule technical safeguards
• HHS: HIPAA Security Rule notice of proposed rulemaking (January 2025)
• 45 CFR Part 84 Subpart I: Web, mobile and kiosk accessibility (Section 504)