EHR Tech Stack

What is an EHR tech stack?

An EHR tech stack is the combination of hosting, clinical data stores, terminology services, integration engines, APIs, identity services and user interfaces that an electronic health record is built on. Each layer has its own standards: FHIR R4 and US Core for APIs, HL7 v2 and X12 for interfaces, and HIPAA Security Rule safeguards wherever ePHI is held.

How an EHR stack differs from a typical SaaS stack

• Coded data: A medication is not a string. It carries an RxNorm code, a dose with a UCUM unit and a status, and the stack must store and return all of it.
• Two generations of interfaces: Labs and hospitals still send HL7 v2 messages over MLLP, while apps and payers call FHIR REST APIs. The stack has to run both at once.
• Access is evidence: Who opened which chart, and when, is a record the organization may need to produce, so audit data is part of the design, not a log file.
• Corrections, not deletes: Clinical data is amended with history. A stack built on hard deletes and overwrites loses the trail clinicians and auditors rely on.

How are the layers of an EHR stack arranged?

An EHR stack has four layers: infrastructure, data, integration and APIs, and applications with their security services. Teams tend to pick the front-end framework first, but the choices that are hardest to undo sit lower down, in the data model and the interface layer.

• Infrastructure: Cloud accounts, networks, keys, backups and the deployment pipeline. Only services covered by the provider's business associate agreement should hold ePHI.
• Data: The clinical store, the terminology service, document and image storage, and a separate audit store.
• Integration and APIs: The HL7 v2 interface engine, a message queue, X12 and e-prescribing connections, and the FHIR R4 API with SMART on FHIR authorization.
• Applications and security: The clinician web app, patient portal and mobile apps, plus single sign-on, role and context checks, encryption and monitoring.

Should the clinical store be relational, FHIR-native or both?

Most EHR teams keep a relational clinical database as the system of record and expose FHIR through a server or facade. A FHIR-native store suits products whose main job is exchange, while a relational core suits products with heavy charting, scheduling and billing logic that FHIR resources do not model well.

• Relational core with a FHIR facade: PostgreSQL or a similar database holds encounters, orders and results in tables designed for the product. A mapping layer turns rows into US Core resources on request. It gives full control of queries, at the cost of maintaining the mapping.
• FHIR-native server: HAPI FHIR, or a managed FHIR service such as AWS HealthLake, the FHIR service in Azure Health Data Services or the Google Cloud Healthcare API, stores resources directly. Exchange is simple, but reporting queries and product-specific workflows can get awkward.
• Both, with a clear owner: Some stacks write to the relational core and sync to a FHIR store for APIs and Bulk Data. This works only if one side is declared the source of truth and the sync is monitored.

Terminology, documents and images

A terminology service holds SNOMED CT, LOINC, RxNorm and ICD-10-CM and answers the FHIR terminology operations $lookup, $validate-code, $expand and $translate. Store the original local code next to the standard one. Scanned documents and PDFs belong in object storage with metadata in the database, and imaging stays in a PACS or vendor neutral archive that speaks DICOM, with the EHR holding the report and a link.

Which integration tools belong in the stack?

An EHR that talks to labs, hospitals and payers needs an interface engine, a durable queue, and dedicated connections for claims and prescriptions. Point-to-point code written inside the application works for one interface and becomes hard to monitor by the fifth.

• Interface engine: Mirth Connect by NextGen Healthcare, a commercial engine or a cloud integration service receives HL7 v2 ADT, ORM and ORU messages over MLLP, returns ACKs, transforms segments and routes them.
• Queue between engine and app: Kafka, RabbitMQ or a cloud queue absorbs bursts, retries failures and holds a dead-letter queue, so a slow database never makes a lab resend a whole day of results.
• Claims and eligibility: X12 270/271, 837P or 837I and 835 files usually travel through a clearinghouse, which handles payer connections and returns acknowledgments.
• E-prescribing: NCPDP SCRIPT through a certified network. Electronic prescribing of controlled substances adds DEA requirements under 21 CFR Part 1311, including identity proofing and two-factor signing.

The integration-only stack

A product that connects to existing EHRs rather than replacing one needs a smaller EHR integration tech stack: a SMART on FHIR client, an HL7 v2 listener or engine, a mapping and terminology layer, a queue with retries, monitoring for failed and late messages, and encrypted storage for whatever the product keeps. Vendor programs such as open.epic and fhir.epic.com set the scopes and resources each connection can use.

What does the API and identity layer need?

The API layer needs a FHIR R4 server that returns US Core profiles, SMART App Launch for user-facing apps, and the Bulk Data $export operation for population extracts. Identity needs single sign-on for clinicians and an authorization model that checks role and patient context, not role alone.

• Authorization server: OAuth 2.0 and OpenID Connect with SMART scopes such as patient/Observation.rs, refresh token rules and a way to revoke an app.
• Backend services: SMART Backend Services authorization with signed JWT client assertions for system-to-system calls, such as a nightly Bulk Data export.
• Bulk Data output: NDJSON files written to storage, with expiring download links and a job status endpoint the client can poll.
• Clinician sign-in: OpenID Connect or SAML federation with the customer's identity provider. Multi-factor authentication is good practice and is part of a proposed HIPAA Security Rule update, not a current requirement.
• Context checks: A nurse can open a patient on her unit, not every patient in the system. Encode care team and location rules in the authorization service rather than in each screen.

Which rules pin down specific layer choices?

A handful of federal rules and standards narrow the options at specific layers. Each one below maps to the layer it constrains.

• API layer: ASTP/ONC certification criterion 45 CFR 170.315(g)(10) defines a standardized read API for patient and population services, using US Core, SMART App Launch and Bulk Data. Writing data into an EHR needs vendor write APIs or an HL7 v2 interface instead.
• Data model: USCDI, published by ASTP/ONC, lists the data classes and elements certified health IT must support, which sets the minimum your schema and FHIR mapping must carry.
• Security layer: The HIPAA Security Rule at 45 CFR 164.312 requires unique user identification, emergency access procedures, audit controls and person or entity authentication. Encryption at rest and in transit and automatic logoff are addressable specifications.
• Infrastructure: HHS guidance on HIPAA and cloud computing says a cloud provider that stores ePHI is a business associate even when it cannot view the encrypted data.
• Front end: The HHS Section 504 rule at 45 CFR 84.84 adopts WCAG 2.1 Level AA for the web content and mobile apps of HHS-funded recipients, with compliance dates moved to 11 May 2027 for recipients with 15 or more employees.

WCAG 2.2 AA is a sensible design target for a new component library, because meeting it also covers WCAG 2.1 AA.

Stack failure points to design out early

• Failure 1, Free-text clinical values: Results stored as display strings without LOINC codes and units cannot feed a US Core Observation without a cleanup project.
• Failure 2, Audit in the app log: Access events mixed into application logs get rotated, sampled or filtered. Keep a separate, append-only audit store with its own retention policy, and consider the FHIR AuditEvent resource as the export shape.
• Failure 3, A service outside the BAA: An email, analytics, error-tracking or AI service that is not covered by a business associate agreement quietly receives PHI in payloads or stack traces.
• Failure 4, Synchronous HL7 handling: Writing each inbound message straight to the database means a slow query stalls the MLLP connection and the sending system queues or resends.
• Failure 5, Real PHI in test: Copying production into development spreads ePHI. Generate test patients with a tool such as Synthea instead.
• Failure 6, FHIR added last: A data model built without standards produces slow, partial US Core output when a customer or certification body asks for the API.

How Agnotic can help

Picking a stack is easier with an engineer who has wired each layer together before. Agnotic Technologies builds EHR platforms and EHR integration stacks for digital health teams and health IT vendors: clinical data models with a FHIR R4 facade or server, terminology services, HL7 v2 engines with queues, SMART on FHIR authorization, Bulk Data export and cloud infrastructure built to HIPAA Security Rule safeguards.

A typical first step is a thin slice, such as a visit note with a lab order and a returned result, built through every layer so the stack is proven before the team scales it.

Sources

• ASTP/ONC: Standardized API for patient and population services, 45 CFR 170.315(g)(10)
• ASTP/ONC: United States Core Data for Interoperability (USCDI)
• 45 CFR 164.312: HIPAA technical safeguards
• HHS: Guidance on HIPAA and Cloud Computing
• Federal Register: Section 504 web and mobile accessibility compliance date extension (11 May 2026)
• HL7: SMART App Launch Implementation Guide
• HL7: FHIR Bulk Data Access Implementation Guide
• eCFR: 21 CFR Part 1311, electronic prescriptions for controlled substances