Every time a patient moves between providers, from a primary care visit to a specialist referral to a hospital admission, clinical data needs to follow. That handoff depends on health information exchange standards: the technical and regulatory frameworks that define how systems share patient records electronically. Without them, healthcare data stays trapped in silos, clinicians make decisions with incomplete information, and patients repeat the same tests and answer the same questions at every stop.

These standards aren't just theoretical. They include specific protocols like HL7v2, C-CDA, and FHIR, along with federal mandates such as the 21st Century Cures Act and ONC's interoperability rules. Together, they dictate the format, transport, security, and governance of clinical data exchange. For anyone building or managing healthcare technology, whether you're a developer, a CTO, or a product leader, understanding how these standards work (and how they interact) is non-negotiable. Getting this wrong means failed integrations, compliance violations, or months of rework.

At SoFaaS, we deal with this complexity daily. Our platform handles SMART on FHIR integration as a managed service, connecting healthcare applications to EHRs like Epic, Cerner, and Allscripts so that teams can build on top of these standards without having to implement every layer themselves. That experience has given us a clear picture of what matters most, and where teams typically get stuck.

This guide breaks down the major health information exchange standards in practical terms. You'll learn what each standard actually does, how federal regulations shape adoption timelines, and where modern approaches like FHIR fit alongside legacy protocols that still run in production across thousands of health systems. Whether you're planning your first EHR integration or evaluating your current architecture, this is the reference you need.

Why health information exchange standards matter

The US healthcare system generates enormous volumes of clinical data every day, but historically that data has stayed locked inside whatever system captured it. A hospital running Epic doesn't automatically share records with a home health agency using a different platform. Health information exchange standards exist to fix that: they give every system a common language so that patient data can move accurately from one place to another, regardless of the vendor or technology stack involved. When these standards work as intended, a physician treating a patient in an emergency room can see medications prescribed by a specialist from a previous visit, even if those records live in a completely different system.

The real cost of fragmented data

When data doesn't flow between systems, the consequences are immediate and measurable. Duplicate testing alone costs the US healthcare system billions of dollars annually, often because a provider can't pull results from a previous visit and orders new labs rather than working from existing data. Patients also face direct harm: medication errors happen frequently at care transitions when one provider doesn't know what another prescribed. According to the Office of the National Coordinator for Health Information Technology (ONC), incomplete data at care transitions is one of the leading contributors to preventable adverse events.

When your application can't access complete patient data, that gap doesn't just slow down your development cycle - it directly affects clinical decisions that impact patient safety.

Fragmented data also creates operational waste at every level of the care delivery process. Providers spend time faxing records, staff manually re-enter information across systems, and patients fill out the same intake forms at every visit. Every one of those workarounds is a failure point where data can be lost, misread, or delayed. If you're building a healthcare application, your product sits in the middle of this ecosystem, and the quality of your data access determines the quality of your product.

How standards reduce integration complexity

Standards do more than ensure data accuracy; they dramatically cut the engineering work required to connect systems. Without a shared standard, every integration becomes a custom project. Your team maps fields from one proprietary format to another, writes transformation logic for edge cases, and maintains that code every time either system updates. Multiply that effort across ten EHR vendors and you have an integration burden that consumes most of your engineering capacity.

When systems agree on a standard, you write integration logic once and it works against any compliant endpoint. A request formatted to the FHIR R4 specification works whether you're pointing at Epic's API or Cerner's. This is precisely why federal regulators pushed hard for standard adoption: reducing per-vendor complexity lowers the barrier for new market entrants and accelerates the development of tools that improve care outcomes.

Why regulatory pressure accelerated adoption

For years, health information exchange standards existed on paper but saw inconsistent adoption because vendors had little financial incentive to make their systems truly interoperable. The 21st Century Cures Act changed that dynamic significantly by making information blocking a federal offense and requiring certified EHR vendors to support FHIR-based APIs by specific ONC-mandated deadlines. If you're building on modern EHR APIs today, you're working in an environment where the major vendors are legally required to support standardized access.

Your investment in understanding and implementing these standards now compounds over time. You build once against a known standard, stay compliant with federal requirements, and avoid the vendor lock-in that trapped earlier generations of health tech products. That compounding return is the core reason these standards matter: they make it possible to build interoperable, compliant healthcare software without starting from scratch at every client deployment.

Core standards you will encounter

Health information exchange standards don't exist as a single unified specification. Instead, you deal with a layered set of standards that each handle a different part of the data exchange problem: structure, transport, terminology, and security. Before you can make smart architecture decisions, you need a clear picture of which standards cover which layer, because choosing the wrong tool for a given problem creates integration failures that are expensive to unwind.

The table below maps the major standards categories to their primary function:

Category	Standards	What it governs
Messaging	HL7 v2, HL7 v3	Real-time clinical event notifications
Documents	C-CDA, CCD	Structured clinical summaries
APIs	HL7 FHIR R4	RESTful data access and exchange
Terminology	SNOMED CT, LOINC, ICD-10, RxNorm	Consistent clinical vocabulary
Imaging	DICOM	Medical imaging data
Transport	Direct Protocol, HTTPS	Secure message delivery
Authorization	OAuth 2.0, SMART on FHIR	Access control and consent

Standards that define data structure and format

Structural standards determine how clinical information gets packaged before it travels between systems. HL7 v2 handles real-time messaging for events like admissions, lab results, and order updates. C-CDA defines how entire clinical documents, such as discharge summaries and referral notes, get formatted for exchange. FHIR takes a different approach entirely, breaking clinical data into discrete, addressable resources that modern APIs can return on demand rather than bundling everything into a single large document.

Understanding which structural standard a given EHR uses for a specific data type is the starting point for any integration project. Getting this wrong at the beginning can cost weeks of rework.

Standards that govern transport and authorization

Once data is packaged correctly, transport standards define how it moves securely between endpoints. The Direct Protocol is commonly used for point-to-point messaging between providers, operating similarly to encrypted email. For modern API-based integrations, HTTPS combined with OAuth 2.0 and the SMART on FHIR framework handles both secure transport and the authorization flow that grants your application access to specific patient records.

These two layers work together. You can't deliver a perfectly structured FHIR resource over an insecure or improperly authorized channel and call the integration complete. Your team needs to account for both simultaneously, which is why many healthcare applications treat transport security and data formatting as a single design problem rather than two separate tasks handled by different people on the team.

HL7 FHIR and SMART on FHIR

HL7 FHIR (Fast Healthcare Interoperability Resources) is the most significant shift in health information exchange standards in the past decade. Where older specifications relied on flat, pipe-delimited message formats, FHIR structures clinical data as discrete, web-native resources that any HTTP client can request and parse. Each resource has a defined URL structure, a standard schema, and a predictable JSON or XML format. That predictability is what makes FHIR practical for development teams without deep healthcare backgrounds.

What FHIR actually does

FHIR organizes clinical information into over 150 resource types, each representing a specific clinical concept. A Patient resource holds demographics. An Encounter resource captures visit details. A DiagnosticReport resource carries lab results. When you query a FHIR server, you're making a standard REST API call with defined parameters, and you get back a structured resource rather than a proprietary blob that requires custom parsing logic.

FHIR R4 is the version required by ONC's interoperability rules, meaning every certified EHR must expose compliant R4 endpoints - if you're starting a new integration today, R4 is the version you target.

The table below lists the most commonly used FHIR resources in production integrations:

Resource	What it contains
Patient	Demographics, identifiers, contact info
Encounter	Visit details, dates, facility
Condition	Diagnoses and problem list entries
Observation	Lab results, vitals, measurements
MedicationRequest	Prescriptions and medication orders
AllergyIntolerance	Patient allergy and intolerance records

SMART on FHIR and authorization

SMART on FHIR sits on top of FHIR's data model and handles the authorization layer. It defines how your application requests access to patient data, how patients or providers grant consent, and how access tokens get issued and scoped. Without SMART, your application could construct a valid FHIR query but have no standard way to prove it has permission to make that request. SMART on FHIR uses OAuth 2.0 as its foundation and adds healthcare-specific scopes that map directly to clinical resource types, so you can request read access to a patient's medications without also requesting access to unrelated records.

Implementing both layers correctly is where most teams underestimate the effort. The FHIR query logic is relatively straightforward once you understand the resource model. The SMART authorization flow requires handling token lifecycle, refresh logic, patient context, and EHR-specific launch parameters, all of which vary between Epic, Cerner, and other major vendors. Managing that variation across multiple EHR connections is precisely what a managed SMART on FHIR platform is built to handle.

Messaging and documents: HL7 v2 and C-CDA

Before FHIR became the center of attention in health information exchange standards, two older formats handled the majority of clinical data movement across US health systems: HL7 v2 for real-time event messaging and C-CDA for structured clinical documents. Both are still in heavy use today. If your application connects to a hospital system, a lab network, or a care coordination platform, you will almost certainly encounter one or both of them, regardless of how modern your own stack is.

HL7 v2: the messaging standard still running in production

HL7 v2 was introduced in the late 1980s and became the default format for communicating clinical events between systems. When a patient is admitted to a hospital, when a lab result comes back, or when an order gets placed, an HL7 v2 message fires between systems in near real time. The format uses a pipe-delimited, segment-based structure that looks nothing like modern JSON or XML. Each segment starts with a three-letter code, fields are separated by pipe characters, and the message type determines what data each segment is expected to carry.

HL7 v2 has no formal versioning enforcement, so two systems both claiming to support v2.5.1 can still produce incompatible messages because the specification allows significant optional variation.

That flexibility created decades of vendor-specific customization. You'll regularly encounter Z-segments, which are vendor-defined extensions with no standard schema, and fields that are technically optional in the spec but required by the receiving system. Parsing HL7 v2 reliably means accounting for these variations at every new integration, which adds engineering time that teams consistently underestimate before their first hospital connection.

C-CDA: structured documents for care transitions

Consolidated Clinical Document Architecture (C-CDA) addresses a different use case than v2 messaging. Instead of communicating individual events, C-CDA packages a complete clinical summary into a single structured XML document. Common C-CDA document types include the Continuity of Care Document (CCD), discharge summaries, and referral notes, each with defined sections for problems, medications, allergies, and results.

C-CDA documents are what typically travel between providers at transition points: when a patient discharges from a hospital, when a specialist receives a referral, or when a patient requests their records. The ONC mandated C-CDA support as part of meaningful use requirements, which drove broad adoption across certified EHR vendors.

The practical challenge with C-CDA is that the XML schema is large and the document templates have enough flexibility to produce valid documents that are structurally inconsistent between vendors. Your parsing logic needs to handle missing sections, unexpected ordering, and varying levels of coded versus free-text content to extract data reliably across different source systems.

Terminologies and identifiers that keep data consistent

Structuring data correctly and transporting it securely only gets you halfway to a working integration. The third layer that health information exchange standards depend on is shared vocabulary: a consistent set of codes and identifiers that ensure "hypertension" in one system means exactly the same thing as "hypertension" in another. Without that layer, data that looks clean in transit becomes ambiguous or unqueryable the moment a receiving system tries to act on it.

Clinical code systems that standardize meaning

Four code systems cover most of what you'll encounter in production integrations. LOINC (Logical Observation Identifiers Names and Codes) is the standard for lab tests, vital signs, and clinical observations. When a FHIR Observation resource returns a lab result, the code field should carry a LOINC code that precisely identifies what was measured, so any receiving system can interpret the result without guessing from a free-text label.

If a source system returns lab results using local codes instead of LOINC, you'll need a mapping layer before you can reliably aggregate or analyze that data across facilities.

SNOMED CT (Systematized Nomenclature of Medicine Clinical Terms) handles clinical findings, diagnoses, and procedures. You'll see it in Condition resources and clinical documentation. ICD-10 handles diagnostic billing codes and is the format most familiar to anyone working with claims data or administrative records. These two systems overlap in coverage but serve different purposes, and you'll often encounter both in the same patient record.

For medications, RxNorm provides a normalized naming system that links drug names, strengths, and dose forms to a common identifier, regardless of how the prescribing system or pharmacy platform described the medication internally. Using RxNorm codes in MedicationRequest resources means downstream applications can match prescriptions across systems without custom synonym tables.

Patient and provider identifiers

Code systems standardize what clinical data means, but identifiers standardize who and where that data belongs to. The National Provider Identifier (NPI) is the standard identifier for individual clinicians and healthcare organizations in the United States. Every FHIR Practitioner or Organization resource from a compliant system should include an NPI, which lets you reliably associate clinical records with the provider or facility that created them.

Patient identification is more complicated. There is no national patient identifier in the US, so each facility assigns its own Medical Record Number (MRN). When you integrate across multiple health systems, you'll regularly encounter the same patient under different MRNs. Your application needs a matching strategy, whether rule-based demographic matching or a dedicated master patient index, to link those records reliably without creating duplicate patient profiles.

Security, privacy, and consent requirements

Health information exchange standards cover more than data format and transport. Every integration you build touches protected health information (PHI), which means security, privacy, and consent are not optional add-ons you layer on at the end of a project. They are structural requirements baked into the standards themselves, and regulators actively enforce them. If your application doesn't handle these requirements correctly from the start, you face both compliance liability and the risk of losing access to the EHR APIs you depend on.

HIPAA and the technical safeguards it requires

HIPAA's Security Rule sets the baseline technical requirements for any system that creates, receives, maintains, or transmits ePHI. For your integration, that means implementing access controls, audit logging, encryption in transit, and encryption at rest across every layer of your stack. The rule doesn't prescribe specific technologies, but it requires you to document your choices and demonstrate that they address each addressable and required safeguard category.

Audit logging isn't just a compliance checkbox: it creates the record you need to investigate access anomalies and respond to breach notifications under HIPAA's required 60-day reporting window.

Encryption in transit means TLS 1.2 or higher for all API calls between your application and EHR endpoints. Encryption at rest means any PHI stored in your database, cache, or message queue needs to be encrypted using a current standard such as AES-256. Both requirements apply simultaneously, so a gap in either layer creates a reportable vulnerability.

OAuth 2.0 and token-based access control

The SMART on FHIR authorization framework uses OAuth 2.0 to control which application can access which patient data under which conditions. Your application requests specific scopes during the authorization flow, and the EHR issues an access token scoped to exactly what was granted. This means you can't request broader access than your use case requires, and the EHR can revoke that access independently of your application's internal state.

Token lifecycle management is one of the most common failure points in production integrations. Access tokens expire, refresh tokens have their own expiration windows, and some EHRs impose additional session limits tied to the original patient launch context. Your application needs to handle token refresh proactively rather than waiting for a 401 response to trigger re-authorization.

Patient consent and authorization flows

Consent flows determine who authorizes data access and under what conditions. Standalone SMART launches require explicit patient authorization through the EHR's consent interface. EHR-launched apps inherit the provider's session context and don't require a separate patient consent step, but your application still needs to respect the scope boundaries the EHR enforces. Building your authorization logic around these two launch patterns from day one prevents the re-architecture work that teams face when they try to support both scenarios after the fact.

US rules and frameworks that shape HIE

Federal regulation is the primary force that moved health information exchange standards from voluntary guidance to enforceable requirements. Understanding which rules apply to your integration, and what they actually require, lets you build compliant systems the first time rather than retrofitting compliance after a failed audit or a blocked API request.

The 21st Century Cures Act and information blocking

The 21st Century Cures Act, signed into law in 2016, established information blocking as a federal offense. The law defines information blocking as any practice that is likely to interfere with access, exchange, or use of electronic health information, and it applies to EHR developers, health IT networks, and healthcare providers alike. Violators face significant civil monetary penalties, which gave vendors a concrete reason to open their APIs rather than restrict them.

Information blocking rules don't just protect your access to EHR data: they give you a legal framework to push back when a vendor adds unnecessary barriers to integration without a legitimate exception.

The Act also directed ONC to define specific exceptions where restricting data access is permissible, such as preventing patient harm or protecting privacy. Your integration architecture needs to account for these exceptions because a vendor that invokes one legitimately is not violating the law, even if the restriction slows your development timeline.

ONC's interoperability rules and USCDI

ONC's 21st Century Cures Act Final Rule, published in 2020, translated the legislation into specific technical requirements. Certified EHR vendors must support FHIR R4-based APIs that expose patient data defined in the United States Core Data for Interoperability, commonly called USCDI. USCDI is a standardized set of data classes and elements that every certified system must be able to share, covering clinical notes, allergies, medications, problems, lab results, and demographics.

The USCDI version in effect for a given certification cycle determines exactly which data elements your FHIR queries can reliably retrieve across compliant systems. ONC updates USCDI periodically, expanding the required data set with each new version, so your integration roadmap needs to track these updates if your application depends on newly added data classes.

CMS rules that extend interoperability requirements

The Centers for Medicare and Medicaid Services (CMS) issued parallel interoperability rules that apply to payers rather than providers. These rules require health plans participating in certain federal programs to expose patient access APIs and provider directory APIs using FHIR R4. If your application connects to payer data in addition to EHR data, CMS rules set the baseline requirements you need to meet on that side of the integration.

How to implement HIE standards in practice

Knowing what health information exchange standards exist is different from knowing how to build against them. The gap between understanding the specifications and shipping a working integration trips up even experienced engineering teams. Your implementation approach determines whether you spend weeks connecting a single EHR or months debugging edge cases across multiple vendors.

Define your data scope before writing any code

Start by listing the specific FHIR resources your application actually needs, not the full USCDI data set. Most teams begin with too broad a scope and discover partway through that certain resource types have inconsistent support across EHR vendors. If your application needs medications, allergies, and problem lists, target those three resource types first and validate them against at least two EHR sandbox environments before expanding.

Narrowing your scope early prevents the situation where your integration technically works against one vendor but breaks against every other because you relied on optional fields that only Epic populates.

Once you know which resources you need, map each one to the terminology codes you'll accept: LOINC for observations, RxNorm for medications, SNOMED CT or ICD-10 for conditions. Document the fallback logic for records that arrive with local codes instead of standard ones, because production systems send local codes more often than the specifications suggest.

Build your authorization layer before your data layer

The SMART on FHIR authorization flow is the part of the integration that breaks most unpredictably, so build it first while your scope is still narrow. Implement both the standalone launch and EHR launch patterns from the start, because retrofitting the second pattern after you've already shipped the first creates token context bugs that are difficult to reproduce in a sandbox.

Your token refresh logic needs to run proactively, not reactively. Set your refresh window to trigger before expiration rather than waiting for a 401 response, and write explicit error handling for revoked tokens so your application degrades gracefully instead of silently dropping requests.

Validate in sandbox environments early and often

Every major EHR vendor maintains a developer sandbox that approximates production behavior. Test your FHIR queries, authorization flows, and error handling against these environments long before your first go-live date. Sandbox responses frequently expose vendor-specific quirks, such as missing sections in C-CDA documents or unexpected pagination behavior on large result sets, that you won't find by reading the specification alone.

Treat each new EHR connection as a fresh validation cycle, not a copy-paste of your previous integration. Even compliant systems diverge enough in practice that assumptions from one vendor will surface as bugs against another.

Final takeaways

Health information exchange standards form the foundation of every EHR integration you'll build. Mastering them means understanding multiple overlapping layers: FHIR R4 for modern API access, HL7 v2 and C-CDA for legacy messaging and documents, shared terminologies like LOINC and RxNorm for consistent meaning, and federal rules that enforce adoption. Getting each layer right from the start saves significant rework later.

Your biggest leverage point is the authorization layer. SMART on FHIR handles the access control that sits between your application and patient data, and it's where most production integrations break first. Build it correctly, test it across multiple vendor sandboxes, and treat each new EHR connection as its own validation cycle rather than a copy of the last one.

If you want to skip the complexity of building and maintaining all these layers yourself, launch your SMART on FHIR app and connect to major EHRs in days instead of months.