CMS and ONC Healthcare Regulations 2026: What Every CTO Must Know About Interoperability Compliance

Healthcare interoperability compliance is no longer optional. In 2026, a convergence of federal regulations from the Centers for Medicare & Medicaid Services (CMS) and the Office of the National Coordinator for Health Information Technology (ONC) creates the most demanding compliance environment hospital technology leaders have ever faced. With penalties reaching $1 million per violation for information blocking and mandatory FHIR API deadlines approaching, every CTO, CIO, and compliance officer must understand exactly what is required and when.

This guide provides a comprehensive, regulation-by-regulation breakdown of every major interoperability mandate affecting US healthcare organizations in 2026 and 2027. We cover the legal foundations, technical requirements, deadlines, penalties, implementation strategies, and a step-by-step compliance checklist you can act on immediately. Whether you are a hospital CTO evaluating vendor readiness, a CIO budgeting for compliance projects, or a compliance officer preparing for audits, this resource is designed to be your definitive reference.

The 21st Century Cures Act: The Foundation of Modern Interoperability Law

Every regulation discussed in this guide traces its authority back to the 21st Century Cures Act, signed into law in December 2016. The Cures Act established the legal framework for preventing information blocking, mandating certified health IT, and requiring federal agencies to advance interoperability standards. Understanding this legislative foundation is essential because each downstream regulation—CMS-0057-F, HTI-1, TEFCA—draws its legal authority from specific Cures Act provisions.

Three provisions matter most for 2026 compliance:

• Section 4003 — Condition and Maintenance of Certification: Requires EHR vendors to meet updated ONC certification criteria and publish APIs using standardized formats. Non-compliant vendors face decertification, which in turn affects every provider using their software. This is not a theoretical risk—ONC maintains a public list of certified products, and health systems receiving Medicare/Medicaid payments must use certified technology.
• Section 4004 — Information Blocking: Prohibits healthcare providers, health IT developers, and health information exchanges (HIEs) from practices that interfere with the access, exchange, or use of electronic health information (EHI). This provision fundamentally changed the legal landscape: before the Cures Act, there was no federal prohibition on data hoarding. Now, violations carry civil monetary penalties up to $1 million per violation for health IT developers and HIEs, with healthcare provider penalties administered through CMS program disincentives.
• Section 4003(b) — APIs and Patient Access: Mandates that certified health IT make patient data available through standardized APIs, specifically HL7 FHIR. This provision directly drives the CMS FHIR API mandates taking effect in 2026-2027. The API requirement is what makes interoperability practical—it shifts from document-based exchange (sending C-CDA files) to programmatic, real-time data access.

The Cures Act gave HHS, through CMS and ONC, the authority to issue the specific implementing rules we discuss below. Understanding this hierarchy matters because compliance with any single rule often intersects with obligations under other rules. For example, a health system that fails to maintain an accessible FHIR API may simultaneously violate CMS-0057-F API requirements, ONC certification conditions, and information blocking prohibitions—creating compounding regulatory exposure.

Information Blocking Enforcement: $1 Million Penalties Are Real

Information blocking enforcement represents the highest-stakes compliance risk for healthcare organizations in 2026. After years of building the regulatory infrastructure—defining what constitutes information blocking, establishing exceptions, creating investigation processes—the Department of Health and Human Services (HHS) Office of Inspector General (OIG) now actively investigates and penalizes information blocking violations. The OIG published its final enforcement rule in July 2024, removing any remaining ambiguity about whether penalties would actually be imposed.

Who Is Subject to Information Blocking Rules?

The Cures Act defines three categories of regulated actors, each with different penalty structures:

• Health IT Developers of Certified Health IT: EHR vendors and other developers whose products are ONC-certified. Subject to civil monetary penalties up to $1,000,000 per violation, enforced by HHS OIG. This category captures not just major EHR vendors like Epic, Oracle Health (Cerner), and MEDITECH, but also smaller developers of certified modules, patient portals, and clinical decision support systems. The OIG determines penalty amounts based on the nature and extent of the blocking, the harm caused, the number of individuals affected, and the actor's history of violations.
• Health Information Networks and Health Information Exchanges (HINs/HIEs): Organizations that facilitate the exchange of EHI, including regional HIEs, national networks, and clearinghouses. Also subject to the $1 million per violation penalty. HIEs face particular scrutiny because their entire purpose is facilitating data exchange—any restriction on that exchange faces heightened regulatory attention.
• Healthcare Providers: Hospitals, health systems, physician practices, long-term care facilities, and other providers. Not subject to CMPs directly, but face "appropriate disincentives" through CMS programs including: reduced Medicare payment adjustments of up to -9% under MIPS, lower MIPS composite scores affecting the Promoting Interoperability performance category, removal from Medicare Shared Savings Programs (ACOs), potential termination from Medicare Promoting Interoperability programs, and referral to the OIG for particularly egregious conduct.

What Constitutes Information Blocking?

Any practice that is likely to interfere with, prevent, or materially discourage access, exchange, or use of EHI qualifies as information blocking unless an exception applies. The definition is intentionally broad, and the OIG has indicated it will interpret "likely to interfere" expansively. Common violations that organizations should audit for include:

• Restrictive licensing terms that prevent third-party apps from accessing patient data through certified APIs, including terms that require approval of each app connecting to the API or that impose unnecessary onboarding delays
• Excessive fees for data exchange capabilities that should be included in standard product offerings, such as charging separately for FHIR API access or bulk data export functionality that is required for certification
• Technical barriers such as requiring proprietary formats when standard formats (like FHIR) are available, implementing rate limits designed to make API access impractical, or deploying IP whitelisting that blocks legitimate data access
• Delay tactics that slow patient data requests beyond reasonable timeframes, including manual approval processes for automated data flows
• Switching costs designed to lock providers into a single vendor ecosystem, such as charging prohibitive data export fees or providing data in formats that are technically standard-compliant but practically unusable
• Selective data sharing where an organization shares certain EHI categories with some requestors but not others without a legitimate exception basis

The Eight Exceptions

Not every restriction on data sharing constitutes information blocking. The ONC defines eight exceptions that protect legitimate restrictions. However, claiming an exception is not a free pass—each has specific conditions that must be met, and the burden of proof falls on the actor claiming the exception:

1. Preventing Harm: Restricting access when a reasonable belief exists that sharing would endanger a patient's life or physical safety. Must be based on a case-by-case assessment, not blanket policies. The determination must be made by a licensed healthcare professional or be consistent with a determination by such a professional.
2. Privacy: Protecting patient privacy consistent with applicable law (HIPAA, state privacy laws, 42 CFR Part 2 for substance abuse records). Does not permit using privacy as a pretext for restricting access—organizations must demonstrate the specific privacy law that justifies the restriction.
3. Security: Implementing security practices that may limit access but are tailored to specific, identified security risks. Cannot use security as a blanket excuse—the security practice must be proportionate to the risk and consistent with industry standards (NIST Cybersecurity Framework, HITRUST).
4. Infeasibility: When sharing is technically infeasible due to infrastructure limitations beyond the actor's control. This exception has a high bar—organizations must demonstrate they have taken reasonable steps to resolve the infeasibility.
5. Health IT Performance: Temporary restrictions necessary to maintain the performance and integrity of health IT systems. Must be limited in duration, applied consistently, and based on genuine performance concerns (not competitive motives).
6. Content and Manner: Offering data in alternative formats or through alternative means when the requested method is not supported. The organization must still provide the data—just through a different mechanism.
7. Fees: Charging reasonable fees for data access that do not exceed costs and are non-discriminatory. Fee structures must be transparent and based on objectively verifiable cost data.
8. Licensing: Requiring licenses for interoperability elements on reasonable and non-discriminatory (RAND) terms. Licensing terms cannot be structured to discourage access.

Critically, claiming an exception requires contemporaneous documentation. In 2026, organizations must maintain records demonstrating that any data sharing restriction falls within a recognized exception at the time the restriction is imposed. Retrospective justification—going back after an OIG inquiry to create documentation—is insufficient and may itself be viewed as evidence of information blocking.

CMS Interoperability and Prior Authorization Final Rule (CMS-0057-F)

The CMS-0057-F final rule, published January 17, 2024, is the most technically prescriptive interoperability regulation affecting US healthcare payers. It mandates four FHIR-based APIs and fundamentally restructures how prior authorization works. The rule addresses a long-standing pain point in US healthcare: prior authorization processes that delay care, burden providers with manual workflows, and create opacity for patients about their coverage.

Affected Organizations

CMS-0057-F applies to a broad swath of the payer market:

• Medicare Advantage (MA) organizations — covering over 32 million beneficiaries in 2025
• State Medicaid and CHIP Fee-for-Service (FFS) programs — all 50 states plus territories
• Medicaid managed care plans — approximately 74% of Medicaid beneficiaries are in managed care
• CHIP managed care entities — covering approximately 7 million children
• Qualified Health Plan (QHP) issuers on the Federal Facilitated Exchanges — ACA marketplace plans

Notably, commercial group health plans regulated solely by ERISA (employer-sponsored plans) are not directly subject to CMS-0057-F, though many large insurers are implementing the APIs across all lines of business for operational efficiency.

The Four Mandatory FHIR APIs

1. Patient Access API (Enhanced)

Building on the existing Patient Access API requirement from the 2020 CMS-9115-F rule, CMS-0057-F significantly expands what payers must expose through this API. By January 1, 2027, payers must provide through a FHIR R4-based API:

• Claims and encounter data (including provider remittances and cost-sharing information)
• Prior authorization decisions, including pending, approved, denied, and partially approved statuses with specific reason codes
• All USCDI data elements in the payer's possession, including clinical data received from providers
• Cost-sharing and out-of-pocket expense information when available
• Formulary and drug coverage information for relevant plans

Payers must begin reporting annual Patient Access API usage metrics by January 1, 2026. These metrics include the number of unique users, total API calls, types of data accessed, and denial rates for API access requests.

2. Provider Access API (New)

This entirely new API enables in-network providers to access their attributed patients' data for care coordination—a capability that has been a significant gap in the US healthcare data ecosystem. Providers have long had difficulty obtaining a complete picture of their patients' healthcare interactions. Requirements include:

• Claims and encounter data from all care settings
• USCDI data elements available to the payer
• Prior authorization information (decisions, requirements, documentation, and status)
• Patient attribution processes that clearly define which patients each provider can access data for
• Patient opt-out capability with clear notification processes
• Provider directory integration to verify requesting providers

Implementation deadline: January 1, 2027. The Provider Access API is expected to have the largest operational impact of the four APIs because it creates a new data flow that did not previously exist at scale.

3. Payer-to-Payer API (New)

When a patient changes health plans—a common occurrence, especially for Medicaid beneficiaries and employees changing jobs—the new payer can request the patient's history from the previous payer through this API. This addresses a chronic problem where patients' healthcare data effectively disappears when they switch plans. Key provisions:

• Covers claims, encounter data, and USCDI information
• Limited to data within five years of the request date
• Requires patient opt-in with educational materials explaining what data will be shared and how it will be used
• Must support concurrent enrollment scenarios where a patient is covered by multiple plans
• Must be completed within one business day of receiving a valid request

Implementation deadline: January 1, 2027.

4. Prior Authorization API (New)

The most operationally impactful API for providers. Prior authorization has been cited by the American Medical Association (AMA) as one of the top administrative burdens in healthcare, with physicians spending an average of 14 hours per week on prior authorization activities. Payers must provide a FHIR-based API that:

• Identifies documentation requirements for specific prior authorization requests before submission
• Processes prior authorization requests and returns decisions electronically, eliminating fax-based workflows
• Communicates approvals, denials (with specific reason codes conforming to X12 standards), and requests for additional information
• Supports the Da Vinci Prior Authorization Support (PAS) Implementation Guide
• Integrates with provider EHR systems through standard FHIR interfaces

Implementation deadline: January 1, 2027. CMS estimates this API alone will save the healthcare system approximately $15 billion over 10 years by eliminating manual prior authorization processes.

Prior Authorization Process Reforms

Beyond the API requirements, CMS-0057-F imposes operational changes effective January 1, 2026—ahead of the API implementation deadlines—that immediately affect how payers handle prior authorization:

• Decision timeframes: 72 hours for expedited (urgent) requests; 7 calendar days for standard requests. These timeframes apply regardless of whether the request comes through the API or through traditional channels. This represents a significant compression from current practices, where some payers take weeks to process standard requests.
• Specific denial reasons: Payers must provide specific, actionable reasons for denials using standardized reason codes, regardless of submission method. Vague denials citing "medical necessity" without specific clinical rationale are no longer compliant.
• Public reporting: Annual publication of prior authorization metrics including: total prior authorization requests received, approval rates by category, average decision times, appeal and overturn rates, and the most common denial reasons. This transparency is designed to create market pressure on payers with poor prior authorization practices.
• Gold-carding provisions: CMS encourages (but does not mandate) exempting providers with consistently high approval rates from prior authorization requirements for specific services. Several state laws are making gold-carding mandatory.

FHIR Technical Standards Required

All four APIs must conform to the following technical standards:

• HL7 FHIR Release 4.0.1 as the base specification
• USCDI for standardized data elements (version aligned with current ONC requirements)
• OpenID Connect Core 1.0 for patient-facing authentication (Patient Access API)
• SMART on FHIR for authorization in applicable contexts, supporting both standalone and EHR-launch flows
• Da Vinci Implementation Guides for prior authorization (PAS), payer data exchange (PDex), and other use cases
• Payers may adopt updated ONC-approved FHIR versions without disrupting user access

MIPS Electronic Prior Authorization Measure

Beginning with the 2027 performance year, eligible clinicians and hospitals participating in the Merit-based Incentive Payment System (MIPS) must attest to using electronic Prior Authorization APIs for at least one medical item or service (excluding drugs). This creates a pull-through incentive: even if a provider organization does not directly build APIs, it must adopt workflows that use payer APIs, creating demand for EHR integration.

ONC HTI-1 Rule: Certification, USCDI v3, and AI Transparency

The Health Data, Technology, and Interoperability: Certification Program Updates, Algorithm Transparency, and Information Sharing (HTI-1) final rule represents ONC's most significant update to health IT certification since the 21st Century Cures Act. Published in the Federal Register in January 2024, it reshapes what certified EHR systems must support and introduces groundbreaking requirements for AI transparency in healthcare.

USCDI v3 Adoption

HTI-1 mandates that certified health IT systems support the United States Core Data for Interoperability Version 3 (USCDI v3), which significantly expands the required data classes and elements beyond USCDI v1 and v2:

• Health Insurance Information (new data class): Coverage type, payer identifier, subscriber ID, group number, relationship to subscriber, and coverage period. This enables automated insurance verification and supports the CMS-0057-F Provider Access API.
• Expanded Clinical Notes: Consultation notes, history and physical notes, imaging narratives, laboratory report narratives, pathology report narratives, procedure notes, and progress notes. Each note type has specific LOINC codes for standardized identification.
• Diagnostic Imaging (new data class): Reports and associated metadata for imaging studies, including DICOM study references. This closes a long-standing gap where imaging data was siloed in PACS systems.
• Expanded Patient Demographics: Sex assigned at birth (for clinical purposes distinct from gender identity), date of death, tribal affiliation (supporting Indian Health Service populations), and related person information for care coordination with family members and caregivers.
• Social Determinants of Health (SDOH): Assessment data including food insecurity, housing instability, transportation needs, interpersonal violence screening, and veteran status. SDOH data elements use standardized LOINC codes and value sets from the Gravity Project. This addition reflects the growing recognition that clinical outcomes are heavily influenced by social factors.
• Health Status Assessments: Standardized functional status (e.g., ADL assessments), disability status, and mental/cognitive health assessments using validated screening tools (PHQ-9 for depression, GAD-7 for anxiety, MMSE for cognitive status).
• Specimen Data (new elements): Specimen type, condition, and source for laboratory results. Critical for laboratory information system integration.

The USCDI v3 adoption requirement means EHR vendors must update their data models, FHIR API responses (using US Core 6.1.0 profiles), and C-CDA document templates to include these new elements. For hospital IT teams, this translates to EHR upgrade planning, data migration, workflow reconfiguration, and staff training on new data capture requirements—particularly for SDOH screening, which requires clinical workflow changes.

Decision Support Interventions (DSI) Transparency

HTI-1 introduces the first federal requirements for algorithmic transparency in healthcare, replacing the legacy Clinical Decision Support (CDS) certification criteria with a broader Decision Support Interventions (DSI) framework. This is directly relevant to the rapid adoption of AI and machine learning in clinical settings:

• Source attributes: All DSIs must provide users with information about the intervention's developer, funding source, intended use cases, the data used to develop and validate the algorithm, and the date of last update. This applies to every alert, suggestion, and prediction that a certified EHR presents to clinicians.
• Predictive DSI requirements: Algorithms that make predictions (including AI/ML models for sepsis detection, readmission risk, deterioration alerts, and similar use cases) must additionally disclose: detailed intervention descriptions, output descriptions and interpretation guidance, development methodology (including training data characteristics), performance metrics, known limitations, and ongoing validation and maintenance practices.
• Bias and fairness: Developers must document how algorithmic bias has been assessed and mitigated, including demographic performance data where available. This means testing models across age, sex, race, and ethnicity subgroups and disclosing any disparities in model performance.
• User-facing transparency: Clinicians must be able to access DSI source attribute information directly within the EHR workflow—not buried in a separate document or website. This is a practical workflow requirement, not just a documentation exercise.

Updated Certification Criteria

Key certification updates in HTI-1 include:

• FHIR US Core 6.1.0 profiles for standardized API responses aligned with USCDI v3
• Bulk FHIR export using the FHIR Bulk Data Access specification for population health, quality reporting, and research use cases
• SMART App Launch Framework 2.0 for third-party application authorization with granular scoping and improved security
• C-CDA R2.1 updates aligned with USCDI v3 data elements for document-based exchange
• Standards Version Advancement Process (SVAP): A flexibility pathway allowing developers to adopt newer standards versions before they are formally required through regulation, reducing the multi-year lag between standard publication and regulatory mandate
• Electronic Case Reporting (eCR): Updated criteria for automated public health reporting

HTI-2 (Proposed Rule) — Looking Ahead

ONC has published the HTI-2 proposed rule, which would further advance requirements including USCDI v4 adoption (adding additional data classes like facility information, orders, and functional status details), enhanced patient demographic data with sexual orientation and gender identity (SOGI) standards, expanded AI governance requirements including mandatory adverse event reporting, and real-world testing requirements for predictive algorithms. While not yet finalized as of March 2026, CTOs should track this rule for forward-looking compliance planning and begin early gap assessments.

TEFCA: The Nationwide Health Information Exchange Framework

The Trusted Exchange Framework and Common Agreement (TEFCA) represents the federal government's strategy for enabling nationwide health information exchange without requiring thousands of point-to-point integrations. Rather than every hospital connecting individually to every other hospital, payer, and public health agency, TEFCA creates a network of networks. In January 2025, TEFCA transitioned to self-governance with the release of its Governance SOP, marking a significant maturation from pilot project to production infrastructure.

How TEFCA Works

TEFCA operates through a three-tiered structure that creates scalable data exchange:

• Recognized Coordinating Entity (RCE): The Sequoia Project serves as the RCE, administering the Common Agreement, establishing technical and policy requirements, and onboarding Qualified Health Information Networks. The RCE functions as the "regulatory body" for the TEFCA ecosystem.
• Qualified Health Information Networks (QHINs): Organizations that sign the Common Agreement and facilitate exchange between their participants. Current designated QHINs include eHealth Exchange, Commonwell Health Alliance, KONZA National Network, Epic's Carequality connections, MedAllies, Health Gorilla, and others. QHINs are required to connect with each other, meaning a hospital connected to any single QHIN can theoretically exchange data with every other TEFCA participant.
• Participants and Subparticipants: Hospitals, health plans, EHR vendors, laboratories, pharmacies, public health agencies, and other entities that connect through QHINs to access the national exchange infrastructure.

TEFCA Exchange Purposes

TEFCA defines specific exchange purposes under which data may flow, with each purpose carrying specific consent and data governance requirements:

• Treatment (TPO): Exchanging data for direct patient care, including emergency department queries for patient history
• Payment: Supporting claims adjudication, eligibility verification, coordination of benefits, and payment activities
• Healthcare Operations: Quality assessment, population health management, care coordination, and administrative functions
• Public Health Activities: Mandatory reporting, disease surveillance, immunization registries, and emergency response coordination
• Government Benefits Determination: Supporting eligibility determinations for government healthcare programs
• Individual Access Services (IAS): Enabling patients to gather their own records from multiple sources through authorized third-party applications—similar to the banking model where personal finance apps aggregate account data

TEFCA Governance Transition (January 2025)

The Governance SOP published January 9, 2025 established three permanent governing bodies, transitioning TEFCA from federal oversight to industry self-governance:

• Governing Council: Strategic oversight and policy direction for the TEFCA ecosystem
• QHIN Caucus: Representing the interests and operational needs of designated QHINs
• Participant and Subparticipant Caucus: Representing the organizations that connect through QHINs

Advisory groups provide feedback on proposed changes to agreements and new exchange purposes. This governance maturation signals that TEFCA is no longer experimental—it is production infrastructure that health systems should plan for in their 2026-2027 IT strategies.

Why CTOs Should Care About TEFCA

While TEFCA participation is technically voluntary as of 2026, several factors make it strategically critical for forward-looking health systems:

• CMS alignment: CMS has signaled that TEFCA participation may become a condition for certain program participation, and the Medicare Promoting Interoperability program already rewards bi-directional health information exchange
• Competitive pressure: As more organizations join TEFCA, non-participants face growing data gaps in care coordination, patient matching, and quality reporting
• Reduced integration burden: A single TEFCA connection through a QHIN replaces dozens or hundreds of bilateral data sharing agreements, reducing both legal complexity and technical maintenance
• Future-proofing: TEFCA represents the direction of federal interoperability policy for the next decade. Organizations that build TEFCA-compatible infrastructure now will avoid costly retrofitting later
• Patient expectations: As Individual Access Services mature, patients will increasingly expect their providers to participate in nationwide exchange networks

CMS Quality Reporting and Interoperability Requirements

CMS continues to strengthen the connection between interoperability compliance and quality-based payment programs. In 2026, several reporting requirements have direct interoperability implications that affect hospital revenue:

Medicare Promoting Interoperability Program

• Electronic prescribing: Must use NCPDP SCRIPT 2023011 or later standard for electronic prescribing, including controlled substances (EPCS) where state law permits
• Health Information Exchange (HIE): Must demonstrate active participation in bi-directional exchange using TEFCA, a regional HIE, or an equivalent network. CMS is increasingly weighting this measure, signaling TEFCA alignment expectations.
• Patient electronic access: Must offer patients API-based access to their health records using certified FHIR endpoints within one business day of data availability
• Public health reporting: Electronic case reporting (eCR) for reportable conditions, syndromic surveillance data submission, immunization registry reporting, and electronic lab reporting. All must use standardized formats.

MIPS and Value-Based Program Implications

Non-compliance with interoperability requirements directly impacts MIPS scores through the Promoting Interoperability performance category, which carries a 25% weight in the overall MIPS composite score. Providers who fail to meet thresholds face negative payment adjustments of up to -9% applied two years later. For hospitals, similar requirements exist under the Hospital Inpatient Quality Reporting (IQR) program, where failure to meet interoperability measures results in a one-quarter reduction in the annual market basket update—a significant financial penalty compounding annually.

State-Level AI and Healthcare Regulations

Beyond federal mandates, state legislatures are increasingly passing laws that affect healthcare AI, data exchange, and algorithmic transparency. CTOs must monitor state-level activity, particularly in states where their organizations operate or serve patients:

Texas: AI Governance in Healthcare (HB 1709)

Texas HB 1709, effective September 2025, is one of the most comprehensive state-level healthcare AI laws. It requires healthcare organizations using AI for clinical decision-making to:

• Disclose AI use to patients when it materially influences treatment decisions, diagnosis, or prognosis
• Maintain human oversight for AI-assisted diagnoses, ensuring a licensed clinician reviews and approves AI-generated recommendations before they are acted upon
• Document and retain AI model validation records, including performance metrics, training data descriptions, and demographic bias assessments
• Report adverse events related to AI-assisted care decisions to the Texas Health and Human Services Commission within 30 days
• Conduct annual AI risk assessments for all clinical AI systems in production use

Arizona: Health Data Exchange Standards (SB 1253)

Arizona SB 1253 establishes state-specific requirements for health information exchange that complement and in some cases exceed federal rules:

• Mandatory participation in the Arizona Health Information Exchange (HIE) for hospitals and health systems receiving state Medicaid funding
• FHIR-based data sharing for behavioral health integration, addressing the historical fragmentation of behavioral and physical health data
• Patient consent management aligned with 42 CFR Part 2 requirements for substance use disorder records, with additional state-specific consent granularity requirements
• Real-time ADT (Admit-Discharge-Transfer) event notification to attributed primary care providers

Maryland: AI Oversight in Clinical Settings (Health-AI Accountability Act)

Maryland's Health-AI Accountability Act establishes one of the most prescriptive AI governance frameworks in the country:

• Annual algorithmic impact assessments for all AI systems used in patient care, including readmission prediction, sepsis detection, and utilization management algorithms
• Disparate impact testing across demographic groups with mandatory reporting of performance differentials exceeding 5% between any two groups
• Public reporting of AI-related adverse events through the Maryland Health Care Commission
• Patient notification rights when AI contributes to coverage determinations, including the right to request a human-only review
• Penalties of up to $50,000 per violation for non-compliance

These state laws create additional compliance layers that interact with federal requirements. A multi-state health system must simultaneously comply with CMS-0057-F API mandates, ONC HTI-1 certification requirements, information blocking prohibitions, TEFCA participation considerations, and varying state AI governance laws—a matrix of obligations that requires dedicated compliance infrastructure.

Complete Timeline: Every Deadline Through January 2027

Here is every significant compliance deadline healthcare organizations must track. We recommend adding these to your organization's regulatory compliance calendar with 6-month lead time for preparation:

Penalties for Non-Compliance: A Comprehensive Risk Assessment

The financial and operational consequences of non-compliance are severe and multi-layered. Understanding the full risk profile is essential for CTO conversations with boards and executive leadership:

Direct Financial Penalties

• Information blocking (Developers/HIEs): Up to $1,000,000 per violation, enforced by HHS OIG. Multiple violations can be aggregated, and each instance of blocking access for a single patient can be considered a separate violation.
• Medicare payment reductions: Negative MIPS payment adjustments of up to -9% for failing Promoting Interoperability requirements. For a hospital with $100M in Medicare revenue, this represents a $9M annual impact.
• Hospital IQR penalty: One-quarter reduction in the annual market basket update, compounding annually. A 0.5% reduction on $200M in Medicare payments costs $1M per year.
• Program exclusion: Potential termination from Medicare Shared Savings Programs (ACOs), resulting in loss of shared savings distributions that can exceed $10M annually for large ACOs.
• State-level fines: Varies by jurisdiction; Maryland AI law carries penalties of $50,000 per violation, Texas requires adverse event reporting with associated investigation costs.

Operational and Strategic Risks

• Vendor decertification: If your EHR vendor loses ONC certification, your organization faces an urgent migration requirement—a multi-year, multi-million-dollar project under time pressure. Monitor your vendor's certification status proactively.
• Network exclusion: As TEFCA adoption grows, non-participating organizations face increasing data silos, inability to receive records from referring providers, and gaps in patient longitudinal records.
• Reputational damage: HHS OIG publishes enforcement actions publicly. Information blocking findings become a matter of public record and can affect physician recruitment, patient trust, and payer contract negotiations.
• Care quality impact: Lack of interoperability directly degrades care coordination, leading to duplicate testing (estimated $25B annually in waste), medication errors from incomplete medication histories, and delayed diagnoses from missing clinical context.
• Payer contract leverage: Payers implementing CMS-0057-F APIs will increasingly expect provider organizations to accept data through these channels. Non-participating providers may face contract disadvantages.

Actionable Compliance Checklist for Hospital CTOs

Use this checklist to assess your organization's readiness across all 2026-2027 interoperability requirements. Each item maps to a specific regulatory obligation discussed above:

Technical Infrastructure (Complete by Q2 2026)

• EHR Certification Verification: Verify your EHR vendor's ONC certification status includes HTI-1 compliance, USCDI v3 support, and DSI transparency requirements. Check the ONC Certified Health IT Product List (CHPL) and request your vendor's compliance roadmap in writing.
• FHIR API Validation: Confirm FHIR R4.0.1 API endpoints are operational for patient-facing and provider-facing access. Test endpoints against the US Core 6.1.0 profiles using standard test suites (Inferno).
• Authorization Framework: Implement or verify SMART on FHIR 2.0 authorization framework for third-party app connections with granular scoping.
• Bulk Data Export: Test Bulk FHIR export capability for population health, quality reporting, and payer data exchange use cases.
• USCDI v3 Data Elements: Validate USCDI v3 data elements in API responses, particularly new elements: SDOH assessments, health insurance information, expanded demographics, and diagnostic imaging references.
• C-CDA Compliance: Ensure C-CDA R2.1 document generation includes all USCDI v3 data classes with appropriate LOINC, SNOMED, and ICD-10 coding.

Prior Authorization Readiness (Complete by Q4 2025)

• Payer Assessment: Identify which payers your organization works with are subject to CMS-0057-F and request their API implementation timelines.
• Workflow Mapping: Map current prior authorization workflows to the electronic FHIR-based model, identifying processes that will change.
• EHR Integration: Prepare EHR integration for consuming payer Prior Authorization API responses and displaying them in clinical workflows.
• Staff Training: Train staff on new 72-hour expedited and 7-day standard decision timeframes and updated denial appeal processes.
• Monitoring Setup: Establish monitoring for prior auth denial reason codes, appeal success rates, and payer response time compliance.

Information Blocking Compliance (Ongoing)

• Risk Assessment: Conduct an information blocking risk assessment across all data sharing workflows, identifying any practice that could be interpreted as blocking.
• Exception Documentation: Document all data sharing restrictions with the applicable exception justification, maintaining contemporaneous records.
• Vendor Contract Review: Review vendor contracts for terms that may constitute information blocking (restrictive licensing, excessive fees, proprietary format requirements).
• Response Process: Establish a process for responding to data access requests within 72 hours with tracking and escalation procedures.
• Staff Education: Train compliance staff on the eight information blocking exceptions and create decision trees for common scenarios.

TEFCA and Network Participation (Complete by Q3 2026)

• QHIN Evaluation: Evaluate QHIN options and assess readiness for TEFCA participation based on your organization's geographic footprint and existing network connections.
• HIE Assessment: Review current HIE memberships for TEFCA alignment and identify any gaps in exchange capabilities.
• Data Governance: Assess data governance policies for compatibility with TEFCA exchange purposes, particularly Individual Access Services.
• Consent Management: Plan patient consent management infrastructure for TEFCA exchange purposes, especially for sensitive data categories (behavioral health, substance use).

AI Governance (If Applicable)

• AI Inventory: Inventory all AI/ML models used in clinical decision-making, including vendor-provided algorithms embedded in the EHR.
• DSI Compliance: Ensure DSI source attributes are accessible to clinicians per HTI-1 within the clinical workflow.
• State Law Assessment: For multi-state operations, assess compliance with each applicable state AI healthcare law (Texas, Arizona, Maryland, and others).
• Bias Testing: Establish algorithmic bias testing and documentation processes for all predictive models in clinical use.
• Adverse Event Reporting: Create an AI adverse event identification, reporting, and remediation workflow.

Governance and Documentation (Ongoing)

• Ownership Assignment: Assign interoperability compliance ownership to a named individual or team with executive accountability.
• Review Cadence: Schedule quarterly compliance reviews against this checklist with documented findings and remediation plans.
• Audit Readiness: Maintain documentation sufficient to demonstrate compliance with each requirement in the event of an HHS OIG inquiry.
• Board Reporting: Brief the board quarterly on regulatory exposure, compliance status, and remediation plans.
• Budget Planning: Budget for implementation costs including: API development, vendor upgrades, staff training, TEFCA participation fees, and compliance monitoring tools. Industry estimates suggest $2-5M for mid-size health systems to achieve full compliance.

How Nirmitee.io Helps You Achieve Compliance

At Nirmitee.io, we specialize in building the healthcare interoperability infrastructure that these regulations require. Our engineering teams have deep experience implementing FHIR R4 APIs, SMART on FHIR authorization frameworks, USCDI-compliant data models, bulk FHIR export pipelines, and prior authorization automation workflows.

Whether you need to stand up a fully compliant FHIR API layer, integrate with TEFCA through a QHIN, build automated prior authorization workflows that meet CMS-0057-F requirements, or implement AI transparency reporting for HTI-1 DSI compliance, we bring the technical expertise and regulatory knowledge to deliver on time and on budget. Our work with health systems across the US means we understand both the technical and operational challenges of interoperability compliance at scale.

Schedule a compliance readiness assessment with our team to identify gaps and build a detailed remediation plan before the 2026 deadlines arrive.