14.2 Health Information Exchange, Interoperability & Cures Act Rules

Health Information Exchange, Interoperability & Cures Act Rules

Quick Summary: In modern healthcare delivery, clinical data cannot remain trapped in proprietary software silos. Health Information Exchange (HIE) organizations and advanced interoperability frameworks facilitate the secure, electronic movement of clinical data among disparate healthcare information systems. Enacted by Congress to eliminate anti-competitive vendor lock-in and administrative barriers, the 21st Century Cures Act and the ONC Information Blocking Rule (45 C.F.R. Part 171) fundamentally restructured health IT compliance. Practice managers must master technical data exchange architectures, the evolution from legacy HL7 standards to RESTful FHIR APIs, the expansive definition of Electronic Health Information (EHI), the ten regulatory exceptions to information blocking, and the strict mandate requiring immediate, uninhibited release of clinical notes and diagnostic test results to patient portals.

---

Health Information Exchange (HIE) Architectures & Modalities

A Health Information Exchange (HIE) is both an action (the electronic mobilization of healthcare data across organizations within a region, community, or hospital system) and an entity (an organization that oversees and governs the network exchange of health information according to nationally recognized standards).

                      HEALTH INFORMATION EXCHANGE (HIE) ARCHITECTURES

     CENTRALIZED MODEL                    FEDERATED MODEL                     HYBRID MODEL
  ┌─────────────────────┐              ┌─────────────────────┐             ┌─────────────────────┐
  │ Central Repository  │              │ Central Record      │             │ Central MPI & Core  │
  │ (All clinical data  │              │ Locator Service     │             │ Longitudinal Data   │
  │ aggregated in one   │              │ (Data remains at    │             │ (Full charts stay   │
  │ central database)   │              │ source clinics)     │             │ at local edge nodes)│
  └──────────┬──────────┘              └──────────┬──────────┘             └──────────┬──────────┘
             │                                    │                                   │
    ┌────────┴────────┐                  ┌────────┴────────┐                 ┌────────┴────────┐
    ▼                 ▼                  ▼                 ▼                 ▼                 ▼
[Clinic A]       [Hospital B]       [Clinic A] ◄───► [Hospital B]       [Clinic A] ◄───► [Hospital B]

1. Architectural Models of HIE

2. Direct Secure Messaging (The Direct Protocol)

For targeted, provider-to-provider transitions of care, the healthcare industry relies on Direct Secure Messaging (the Direct standard). Built on secure, encrypted email protocols (SMTP and S/MIME) coupled with public key infrastructure (PKI) certificates, Direct operates like a federally certified, HIPAA-compliant email network.

• Operational Example: A primary care practice refers a patient to an orthopedic surgeon. Rather than faxing paper records or querying a broad regional repository, the medical assistant sends a standardized clinical summary directly to the orthopedic practice's unique Direct Address (e.g., drsmith@direct.orthoclinic.org). The transmission is end-to-end encrypted, verified by a Health Information Service Provider (HISP), and directly ingested into the receiving specialist's EHR workflow.

3. Health Information Organizations, Networks & TEFCA

A health information organization (HIO) is the entity that governs and operates exchange for a region or community—often called a regional health information organization (RHIO) or a state HIE. HIOs sign participation agreements with practices and hospitals, maintain the master patient index and consent rules, and offer services such as query-based exchange, event notifications (for example, an alert when a patient is admitted to an emergency department), and public health reporting.

Nationally, the Trusted Exchange Framework and Common Agreement (TEFCA), created under the 21st Century Cures Act and run by a Recognized Coordinating Entity designated by ASTP/ONC, links networks through designated Qualified Health Information Networks (QHINs). A practice usually joins TEFCA through its EHR vendor or HIO as a participant or subparticipant. TEFCA participation can satisfy the MIPS Promoting Interoperability health information exchange objective, and the TEFCA Manner exception (described below) lets TEFCA participants route requests through TEFCA.

Practice manager checklist: confirm which HIO or network the EHR connects to; review the participation agreement's permitted purposes, fees, and patient opt-out rules; and train clinicians to check HIE results before ordering duplicate tests.

---

Evolution of Interoperability Standards: HL7 v2 to FHIR

Interoperability represents the ability of two or more health IT systems to securely exchange data and interpret that shared data without manual translation.

                    EVOLUTION OF HEALTHCARE DATA STANDARDS

  HL7 Version 2 (v2)           HL7 CDA / C-CDA                 HL7 FHIR Release 4
  ────────────────────         ────────────────────            ────────────────────
  • Pipe-and-hat (| and ^)     • XML Document-based            • Web RESTful APIs
  • Point-to-point interfaces  • Static complete summaries     • Granular JSON resources
  • Event-driven messaging     • Difficult to extract pieces   • Individual data fields
  • Heavy site customization   • Bulky, rigid parsing          • Mobile/App native

1. HL7 Version 2 (HL7 v2)

Originating in the late 1980s, HL7 v2 remains widely used for legacy point-to-point clinical interfaces. Data is structured as delimited text strings using pipes (|), carets (^), and carriage returns. Common message types include:

• ADT (Admission, Discharge, Transfer): Transmits patient demographic, insurance, and encounter status changes.
• ORM (Order Message): Transmits clinical orders for laboratory, radiology, or cardiology procedures.
• ORU (Observational Result): Returns diagnostic test results and narrative interpretation back to the ordering EHR.
• Limitation: HL7 v2 allows extensive site-specific customization, meaning an interface built for one commercial laboratory rarely works for another without custom programming.

2. Consolidated Clinical Document Architecture (C-CDA)

Developed under HL7 Version 3, C-CDA utilizes Extensible Markup Language (XML) to generate standardized, human-readable and machine-processable clinical documents. The most ubiquitous C-CDA document is the Continuity of Care Document (CCD), which packages a patient's active diagnoses, medications, allergies, and recent procedures into a single document structure.

• Limitation: C-CDA is document-centric and monolithic. If a clinician or patient app merely needs to check a patient's latest potassium lab result, the entire multi-page XML document must be transmitted and parsed.

3. HL7 FHIR (Fast Healthcare Interoperability Resources)

HL7 FHIR represents the modern gold standard for health IT interoperability. Designed around contemporary web standards, FHIR combines the best features of HL7 v2, v3, and modern RESTful web APIs (Representational State Transfer) using lightweight JavaScript Object Notation (JSON) or XML structures.

• Resources as Modular Building Blocks: FHIR breaks medical data down into granular, discrete clinical units called Resources (e.g., Patient, Observation, Condition, MedicationRequest, Encounter, AllergyIntolerance).
• RESTful Operations: Systems interact with FHIR resources using standard HTTP verbs: GET (read/query), POST (create), PUT (update), and DELETE.
• Operational Example: A patient uses a third-party smartphone health app to track blood pressure. Instead of requesting a bulky 50-page PDF or XML document, the smartphone app executes a secure HTTPS GET request: GET /Observation?patient=98765&code=85354-9. The clinic's CEHRT system immediately returns only the blood pressure reading in a clean, structured JSON payload.

---

The 21st Century Cures Act & ONC Information Blocking Rule

Enacted by Congress with overwhelming bipartisan support, Section 4004 of the 21st Century Cures Act added Section 3022 to the Public Health Service Act, establishing sweeping federal prohibitions against Information Blocking. Codified in federal regulations at 45 C.F.R. Part 171, the ONC Information Blocking Rule fundamentally shifts medical practice data management from proprietary ownership toward open, unhindered data exchange.

                     THE INFORMATION BLOCKING STANDARD

                      Is the actor a regulated entity?
          (Healthcare Provider, Health IT Developer, or HIE/HIN)
                                   │
                                   ▼ YES
          Did the actor engage in a practice that is likely to
          interfere with, prevent, or materially discourage
          the access, exchange, or use of EHI?
                                   │
                                   ▼ YES
              Did the actor meet the statutory knowledge standard?
        • Developer/HIE: Knows or SHOULD know
        • Provider: Knows the practice is unreasonable & likely to block
                                   │
                                   ▼ YES
             Does the practice meet all conditions of an ONC Exception?
                                   │
                  ┌────────────────┴────────────────┐
                  ▼ YES                             ▼ NO
          [ FULLY COMPLIANT ]             [ INFORMATION BLOCKING! ]
          (Shielded from liability)       (OIG penalties / MIPS zero)

1. Statutory Definition (45 C.F.R. § 171.103)

Information blocking is defined as a business, operational, or technical practice that is likely to interfere with, prevent, or materially discourage the access, exchange, or use of electronic health information (EHI), provided that:

1. If conducted by a Health IT Developer of Certified Health IT or a Health Information Network (HIN) / Health Information Exchange (HIE), the actor knows, or should know, that such practice is likely to interfere with, prevent, or materially discourage access, exchange, or use of EHI; or
2. If conducted by a Healthcare Provider, the provider knows that such practice is unreasonable and is likely to interfere with, prevent, or materially discourage access, exchange, or use of EHI.

2. Scope of Electronic Health Information (EHI) & USCDI

The scope of data subject to the Information Blocking Rule encompasses all Electronic Health Information (EHI) held in a HIPAA Designated Record Set (medical records, billing records, payment systems, and any records used to make clinical decisions).

• United States Core Data for Interoperability (USCDI): Established by the ONC, the USCDI defines a standardized set of health data classes and constituent data elements required for nationwide interoperability. USCDI data classes include:
  • Patient Demographics: Name, date of birth, race, ethnicity, preferred language, gender identity, sexual orientation.
  • Vital Signs: Systolic/diastolic BP, heart rate, respiratory rate, body temperature, BMI, pulse oximetry.
  • Clinical Notes: Consultation notes, discharge summaries, history & physical (H&P), imaging narratives, lab narratives, pathology reports, procedure notes, and progress notes.
  • Medications, Allergies & Problem Lists: Active and resolved conditions, medication orders, and drug allergies.
  • Laboratory & Diagnostic Findings: Numerical tests, reference ranges, specimen sources, and diagnostic interpretations.
  • Assessment and Plan of Treatment: Clinical impressions and planned clinical interventions.

3. The Immediate Portal Release Mandate

A critical operational impact of the Cures Act is the immediate portal release requirement. Ambulatory practices may not institute arbitrary delays or "embargo" policies on clinical data.

• The Legacy Practice: Historically, clinics held laboratory, pathology, and radiology reports for 7 to 14 calendar days to allow the physician to review the results before the patient could view them.
• The Cures Act Rule: Routine, automatic withholding of clinical notes, lab results, or diagnostic imaging reports constitutes illegal information blocking. As soon as a laboratory result, pathology finding, or clinical note is finalized in the EHR, it must be released immediately to the patient's electronic portal. Clinicians cannot delay release simply because results are abnormal, sensitive, or have not yet been discussed in person, unless an explicit exception applies on an individualized basis.

---

The Information Blocking Exceptions

To provide legal certainty and prevent patient harm, ASTP/ONC regulations (45 C.F.R. Part 171, Subparts B–D) define ten exceptions. The original 2020 rule created eight; the 2024 HTI-1 rule renamed "Content and Manner" to Manner and added a TEFCA Manner exception (§ 171.403), and the HTI-2 rule (December 2024) added a Protecting Care Access exception (§ 171.206). If a practice's conduct satisfies every condition of an applicable exception, it is not information blocking. The exceptions fall into three categories:

                 THE TEN INFORMATION BLOCKING EXCEPTIONS
                                    │
         ┌──────────────────────────┴──────────────────────────┐
         ▼                                                     ▼
  CATEGORY 1: NOT FULFILLING REQUESTS (6)       CATEGORY 2: PROCEDURES FOR FULFILLMENT (3)
  ├─ 1. Preventing Harm Exception               ├─ 7. Manner Exception
  ├─ 2. Privacy Exception                       ├─ 8. Fees Exception
  ├─ 3. Security Exception                      └─ 9. Licensing Exception
  ├─ 4. Infeasibility Exception
  ├─ 5. Health IT Performance Exception         CATEGORY 3: TEFCA PARTICIPATION (1)
  └─ 6. Protecting Care Access Exception        └─ 10. TEFCA Manner Exception

Category 1: Exceptions Involving Not Fulfilling Requests for EHI

1. Preventing Harm Exception (45 C.F.R. § 171.201)

Permits withholding EHI if the practice reasonably believes that interfering with access, exchange, or use will substantially reduce the risk of harm to a patient or another natural person.

• Strict Standard: The practice must reasonably believe that withholding will substantially reduce a risk of harm. When a patient requests their own EHI, the risk must be to the life or physical safety of the patient or another person (the same standard HIPAA uses for denying access); a broader "substantial harm" standard applies to some requests by personal representatives. Emotional distress or anxiety alone does not qualify.
• Individualized Determination: The decision must be made on an individualized basis by a licensed healthcare professional who has a current clinician-patient relationship with the patient. A practice can never institute a blanket clinic-wide policy delaying all abnormal biopsy results!

2. Privacy Exception (45 C.F.R. § 171.202)

Permits not fulfilling a request for EHI to protect individual privacy, satisfying at least one of four sub-conditions:

• Unmet Legal Precondition: State or federal privacy laws (e.g., HIPAA or 42 C.F.R. Part 2 governing substance use disorder records) require written patient consent or authorization before disclosure, and valid consent was not provided.
• Health IT Developer Not Covered by HIPAA: Vendor respects individual privacy choices expressed in writing.
• Individual's Request for Restriction: The patient explicitly requested that their data not be shared, and the practice is honoring that legally permissible restriction.
• Adolescent Health Privacy: Withholding minor reproductive or mental health data where state law grants the minor sole confidentiality rights.

3. Security Exception (45 C.F.R. § 171.203)

Permits restricting EHI access or exchange to safeguard the confidentiality, integrity, and availability of health IT systems. The security practice must be tailored to specific, identifiable security risks and must be consistent with the practice's formal, documented HIPAA Security Rule risk assessment and written security policies (e.g., temporarily blocking a compromised IP address or infected third-party application).

4. Infeasibility Exception (45 C.F.R. § 171.204)

Permits not fulfilling a request due to genuine infeasibility under the circumstances, limited to three specific legal scenarios:

• Uncontrollable Events: Natural disasters, public health emergencies, telecommunication blackouts, or severe cyberattacks (e.g., enterprise ransomware) that render the practice incapable of fulfilling the request.
• Segmentation Inability: The practice cannot unambiguously segment the requested EHI from other legally protected data that cannot be disclosed (e.g., psychotherapy notes or another patient's data).
• Infeasibility Under the Circumstances: Fulfilling the request is genuinely impossible after evaluating technical feasibility, resource constraints, and lack of standard interfaces. The practice must provide a detailed written explanation to the requester within 10 business days of the request.

5. Health IT Performance Exception (45 C.F.R. § 171.205)

Permits making health IT temporarily unavailable for maintenance, updates, security patching, or resolving critical performance degradations, provided that system outages are conducted during planned maintenance windows or consistent with agreed-upon service-level agreements (SLAs).

6. Protecting Care Access Exception (45 C.F.R. § 171.206)

Added by the HTI-2 rule, this exception lets an actor limit sharing of EHI in good faith to reduce potential legal exposure for patients, providers, or others who seek, obtain, provide, or facilitate lawful reproductive health care, provided the practice meets the exception's detailed conditions.

Category 2: Exceptions Involving Procedures for Fulfilling Requests

7. Manner Exception (45 C.F.R. § 171.301)

Renamed from "Content and Manner" by HTI-1 (the content condition was retired once EHI came to mean the full designated record set in October 2022). It governs how an actor may fulfill a request:

• Manner Condition: The practice must fulfill the request in the manner requested (e.g., FHIR API, secure portal, or encrypted export). If technically unable to fulfill in the exact manner requested, the practice must offer standardized alternative formats (e.g., C-CDA or secure PDF) without unreasonable delay.

8. Fees Exception (45 C.F.R. § 171.302)

Permits charging reasonable, cost-based fees for certain technical data exchange services (e.g., developing custom interfaces for third-party entities), provided fees are non-discriminatory and based on objective costs.

• Critical Prohibition: Practices and vendors are strictly prohibited from charging fees to individual patients for accessing their own EHI via an electronic portal or standard FHIR API.

9. Licensing Exception (45 C.F.R. § 171.303)

Allows health IT developers and HIEs to license their interoperability elements, software code, and intellectual property on fair, reasonable, and non-discriminatory (FRAND) terms within 10 business days of receiving a request.

Category 3: Exception Involving TEFCA Participation

10. TEFCA Manner Exception (45 C.F.R. § 171.403)

When both the actor and the requestor participate in the Trusted Exchange Framework and Common Agreement (TEFCA), the actor may fulfill the request only through TEFCA, provided any fees and licenses also meet the Fees and Licensing exception conditions.

---

Enforcement, Investigations & Regulatory Penalties

Enforcement of the Information Blocking Rule involves joint jurisdiction between the ONC, the HHS Office of Inspector General (OIG), and the Centers for Medicare & Medicaid Services (CMS).

                   INFORMATION BLOCKING ENFORCEMENT PATHWAY

   [ ONC Public Complaint Portal ] ──► [ ONC Review & Screening ]
                                                    │
                                                    ▼
                                     [ HHS OIG Investigation ]
                                                    │
                   ┌────────────────────────────────┴────────────────────────────────┐
                   ▼                                                                 ▼
  HEALTH IT DEVELOPERS & HIEs/HINs                                     HEALTHCARE PROVIDERS
  ├─ Direct statutory jurisdiction                                     ├─ Appropriate disincentives
  ├─ Civil Monetary Penalties (CMPs)                                   ├─ MIPS Promoting Interoperability: Score = 0%
  └─ Up to $1,000,000 PER VIOLATION                                    ├─ Medicare Shared Savings Program termination
                                                                       └─ Public reporting on CMS website

1. Enforcement Against Health IT Developers & HIEs/HINs

Under direct statutory authority enforced by the HHS OIG, health IT developers and Health Information Networks/HIEs that engage in information blocking face Civil Monetary Penalties (CMPs) of up to $1,000,000 per violation (inflation-adjusted to $1,327,209 in HHS's 2025 adjustment). A single software update that intentionally disables an interface or restricts third-party app connections across multiple client clinics can trigger multi-million-dollar fines.

2. Disincentives Against Healthcare Providers

Under the final rule on Disincentives for Health Care Providers (codified by CMS under 42 C.F.R. Part 414), when the HHS OIG determines that a healthcare provider committed information blocking, the OIG refers the finding to CMS for the imposition of "appropriate disincentives":

• MIPS Promoting Interoperability Disincentive: Eligible clinicians or groups that OIG determines have committed information blocking receive an automatic score of zero (0) in the MIPS Promoting Interoperability performance category for the applicable calendar year. Because PI accounts for 25% of the total composite MIPS score, this zero almost universally drops the provider below the MIPS performance threshold, triggering substantial negative payment penalties (up to negative 9%) across all Medicare Part B reimbursements.
• Medicare Shared Savings Program (MSSP) Disincentive: Accountable Care Organizations (ACOs) or participating group practices may be deemed ineligible to participate in the MSSP for at least one year, forfeiting all shared savings revenues.
• Public Accountability: CMS publicly publishes the names, practice locations, and details of all healthcare providers penalized for information blocking on the official CMS public website.

---

Realistic Management Scenario: Handling Physician Resistance to Immediate Portal Release

The Situation: Following a routine clinical governance meeting, the physician leadership of a six-provider gastroenterology group passes an internal clinical policy: "To protect patients from anxiety and confusion, all outpatient pathology reports (including biopsy results for suspected colon cancer) and clinical endoscopy procedure notes must be locked and held from the patient portal for 14 business days, allowing the ordering physician to review findings and contact the patient directly." Three weeks after implementing the policy, a patient undergoes a screening colonoscopy where a benign polyp was removed. The patient repeatedly requests their biopsy report through the patient portal but sees a message reading: "Results pending physician review and approval." The patient files an online complaint on the ONC Information Blocking Portal.

                  PORTAL EMBARGO CRISIS & INTERVENTION WORKFLOW

   Physician Policy:                 Patient Experience:               Regulatory Outcome:
   [ 14-Day Result Hold ] ──► [ "Results Pending Review" ] ──► [ ONC Blocking Complaint ]
                                                                               │
   ┌───────────────────────────────────────────────────────────────────────────┘
   ▼
   PRACTICE MANAGER ACTION PLAN:
   1. Immediate Policy Repeal: Terminate 14-day hold; unblock pathology & notes.
   2. Preventing Harm Audit: Document that cancer anxiety is NOT physical harm.
   3. EHR Trigger Reconfiguration: Set pathology feeds to auto-release upon finalization.
   4. Patient Communication Strategy: Add educational banner urging patients to await
      provider consultation while preserving immediate data access rights.

The Manager's Action Plan:

1. Immediate Regulatory Education & Policy Repeal: The practice manager calls an emergency executive committee meeting. The manager informs the physicians that their 14-day blanket hold policy directly violates 45 C.F.R. Part 171. The manager explains that the clinic meets the statutory definition of a healthcare provider and that knowingly maintaining an operational policy that delays EHI access constitutes information blocking, exposing the practice to OIG investigation, MIPS PI zeroes, and negative payment adjustments.
2. Evaluating the Preventing Harm Exception: The lead gastroenterologist argues that the hold is protected by the Preventing Harm exception to prevent patient panic over potential malignancy. The manager presents the legal standard: under 45 C.F.R. § 171.201, the Preventing Harm exception requires a reasonable belief of substantial physical harm, determined on an individualized case-by-case basis by a licensed clinician with an active doctor-patient relationship. A generalized blanket policy delaying all pathology results is completely ineligible for this exception.
3. Reconfiguring EHR Technical Workflows: The manager immediately coordinates with the EHR vendor to eliminate the automated 14-day delay filter. The system is reconfigured to automatically push finalized pathology narratives and endoscopy procedure notes to the patient portal within minutes of sign-off.
4. Operational Mitigation & Patient Education: To alleviate physician concerns regarding patient anxiety, the practice adds a prominent, empathetic educational disclaimer at the top of the portal results tab: "Laboratory and pathology results are released immediately upon finalization. Some reports contain complex medical terminology. Your clinical care team is reviewing your results and will contact you directly within 2 business days to discuss next steps. If you have urgent questions, please message your care team through the portal."
5. Audit Trail Documentation: The manager documents the complete remediation process, files a formal response to the ONC inquiry demonstrating policy revocation, and trains all clinical staff on Cures Act compliance.

---

Exam Traps & Regulatory Best Practices