A Practical Guide to CMS Interoperability Rules in Healthcare

The 21st Century Cures Act and accompanying federal regulations compel health-care institutions to share electronic health information via standardised APIs and to avoid “information blocking.” The HHS/ONC Cures Act Final Rule and the CMS Interoperability and Patient Access Final Rule mandate API access and data exchange by payers and health IT developers, as well as information-blocking bans for providers, HIEs, and developers.

This study summarizes these guidelines and accompanying guidance, including who must comply and when; what data and APIs are required; the relationship with HIPAA privacy/security and state legislation technical standards, implementation details, and enforcement. It provides useful checklists, typical pitfalls, and examples.

Official sources with citations are the primary focus. Tables compare obligations by entity, timelines, and technical standards. Templates outline a compliance checklist and a sample API privacy policy.

Scope and Applicability

The CMS rules apply to health plans/payers that the agency regulates. This includes Medicare Advantage organizations, Medicaid fee-for-service and managed care plans, CHIP FFS and managed plans, and QHP issuers on HealthCare.gov. The ONC rules apply to designated health IT actors: most health care providers, health information networks/exchanges, and certified health IT developers. Providers subject to certain CMS programs must attest to info-blocking compliance; certified IT developers must meet certification criteria.

The rules cover all settings that use electronic health records or data: hospitals, clinics, labs, pharmacies, long-term care, home health, etc. CMS’s Patient Access and Provider Directory API rules focus on payer data, but also intersect with provider directories and hospital ADT notifications. The ONC rules apply nationwide; note that states may impose additional consent/privacy laws. Key regulations by actor:

• Payers/Plans must implement various APIs by specified dates. They must also report the provider directory, digital contact info, and support ADT notifications.
• Health IT Developers must certify to ONC’s Cures-era criteria: e.g., support FHIR R4-based APIs and adopt USCDI data content. They are barred from writing contractual or technical barriers that block users from exchanging data.
• Providers/Clinicians/Hospitals/HIEs must not engage in information blocking under the Cures Act: e.g. they must fulfil EHI requests using available technology. Hospitals must send ADT notifications to community providers within one year of the rule. CMS program participants affirm that they do not have any information-blocking policies.
• State Medicaid and CHIP agencies are specifically mentioned: they must guarantee that FFS and managed programs conform.

Key Requirements

Data Access and API Requirements

Patient Access API

• CMS-regulated payers must implement a standards-based API allowing patients to retrieve their adjudicated claims, encounters, medications, lab results, and insurer-covered drugs. 
• The API must use HL7 FHIR R4.0.1 as the data model and FHIR US Core profiles, patients direct data to apps using SMART on FHIR/OAuth2 authentication. 
• Health plan years beginning Jan 1, 2021. CMS-0057-F later expanded this API to include prior authorization data.

Provider Access API

• Payers must also share similar data with in-network providers’ systems via a FHIR-based API. 
• This “provider API” mirrors the patient API but exchanges data between payers and providers. 
• It also includes prior authorization info by Jan 1, 2027.

Payer-to-Payer API

• When a member switches plans, the new payer must retrieve and incorporate the member’s data from the old payer. 
• The rule requires payers to implement an FHIR-based API to exchange a patient’s USCDI data on enrollee request. 
• All CMS-regulated payers must be compliant by January 1, 2022.
• Data must be exchanged beginning in 2016; Medicaid/CHIP MCOs include the data into enrollee records.

Provider Directory API

• Payers must provide an API endpoint for up-to-date provider directory information so that apps may determine which providers are in the network.
• Updated at least monthly. 
• Required by Jan 1, 2021 for Medicaid/CHIP and Medicare. 
• The IG used is HL7 FHIR Da Vinci PDEX/PlanNet.

ADT Event Notifications

• Under CMS Hospital Conditions of Participation, hospitals must send electronic Admission/Discharge/Transfer notifications to community providers. 
• The Interoperability Rule supports this by mandating capture of digital contact endpoints in NPPES; actual CoP compliance is 12 months after the rule’s publication.

Information Blocking Provisions

• The Cures Act bars actors from practices that “reasonably likely interfere” with access, exchange or use of EHI. It defines EHI broadly and lists eight exceptions. 
• Covered entities must document when exceptions apply. 
• Notably, the rule requires that patients have “immediate” access to all their EHI.

Privacy, Security, and Consent (HIPAA and State Laws)

APIs and data sharing must comply with existing privacy/security laws. 

• HIPAA: Covered entities must still safeguard PHI under HIPAA rules when granting access. Patient-directed data transfers typically fall outside HIPAA after they leave the CE, so CMS advises app developers to have clear privacy policies. Payers must enforce privacy. 
• 42 CFR Part 2: Stricter rules protect substance-use records; these require patient consent, which may limit information blocking. 
• State laws: States can impose additional restrictions. If a state law is more restrictive than federal HIPAA/Cures Act, actors may refuse to share that data under the privacy exception. 

For example, if state law forbids disclosing certain EHI, providers may withhold it; however they should document reliance on the exception. Entities must align policies to handle these conflicts, ideally by obtaining broader consents or limiting state-specific sensitive disclosures in their compliance workflow.

Authentication, Authorization, Consent Workflow

All APIs use SMART on FHIR profile for OAuth2-based patient authorization. Patients log into a third-party app using their insurance credentials and explicitly consent to share data; the app receives an access token for the FHIR API. Consent beyond the API should be handled by policies. 

Providers/payers should build workflows to capture patient requests and trigger data exchanges accordingly. Patient consent must be obtained for data transfer in P2P exchanges. In general, patient-directed data sharing is mandatory; providers cannot opt-out unless a legal exception applies. Adults have HIPAA access rights to their records, minors may need guardian consent depending on state.

Technical Standards and Implementation Details

All required APIs and data formats are standards-based:

Data Model, FHIR Release 4.0.1

The foundational standard is HL7 FHIR R4 for all API resources. Required data elements align with the US Core Implementation Guide. CMS required adoption of ONC’s technical standards at 45 CFR §170.215, which include FHIR R4, US Core, SMART, OpenID Connect, OAuth2, and specific IGs. Entities may use updated IG versions approved via ONC’s SVAP process.

US Core Data for Interoperability

APIs must expose at least the US Core data classes/fields. USCDI v1 includes demographics, allergies, medications, lab results, procedures, etc. CMS’s rule explicitly references USCDI.

SMART on FHIR & OAuth2

Patient and provider authentication uses the SMART App Launch profile. APIs must implement authorization workflows conforming to OAuth2 and OpenID Connect, allowing users to grant third-party apps access using tokens.

Bulk Data Access

CMS and ONC rules require support for FHIR Bulk Data (Flat FHIR) to allow population-level data exports. The ONC Certification rule mandates Bulk Data IG support as a Condition of Certification. See CMS site [21] noting Bulk Data IG among Provider APIs.

FHIR Resources / Implementation Guides

Depending on the API:

• Patient & Provider APIs: use FHIR Patient, Coverage, ExplanationOfBenefit, Claim, MedicationStatement, AllergyIntolerance, Condition, Procedure, Observation, etc., as defined in US Core IG.
• Prior Auth API: using FHIR DeviceRequest, CommunicationRequest, etc., per Da Vinci CRD/DTR/PAS IGs.
• Provider Directory API: uses FHIR Organization, Practitioner, Location, and the Da Vinci PlanNet IG to represent networks.
• Payer-to-Payer API: similar to patient API (using US Core resources) plus Bulk Data for large records.

API Endpoints

Payers must expose public HTTPS endpoints for these APIs. For example, each payer’s website must list the FHIR endpoint URL for Patient Access APIs and Provider Directory API so that apps or directory queries can connect. HIEs or states participating might register endpoints as part of Medicaid enrollment.

Error Handling

APIs should return standard FHIR OperationOutcome responses for errors, using HTTP status codes. ONC’s certification requires specific error code support. If no content, return HTTP 204. The SMART on FHIR spec also covers OAuth error responses for auth flows.

Versioning and Backward Compatibility

Rules currently mandate FHIR R4. Payers may later upgrade to newer FHIR releases if ONC approves. Implementations should include version query and follow the C-CDA2.1/US Core R3+ as recommended. If updated, ensure clients can still access R4 endpoints during transition.

Testing and Certification

• CMS does not require a formal “certification” of each payer’s API, but requires routine testing and validation. Impacted payers must use available FHIR Conformance tools to verify their APIs meet the published IGs. HL7 Da Vinci and CARIN alliances provide implementer tools. Testing should include security and data correctness.
• Health IT modules must pass ONC certification testing against the Cures 2015 criteria, which include Standardized API, requiring all above standards. The ONC Health IT Certification Program requires EHR vendors to provide compatibility for these APIs, OAuth2, and applicable modules.

Compliance Timelines, Enforcement, Penalties, and Reporting

Compliance Dates

Major deadlines are:

• December 2016: The 21st Century Cures Act was enacted, laying the foundation for healthcare interoperability and preventing information blocking.
• May 2020: The Office of the National Coordinator published the Cures Act Final Rule, introducing regulations on information blocking and API standards.
• May 2020: The Centers for Medicare & Medicaid Services released the Interoperability and Patient Access Final Rule to improve patient data access.
• January 2021: CMS required the implementation of: Patient Access API, Provider Directory API. Enforcement was later delayed to July 2021.
• January 2022: CMS mandated the Payer-to-Payer Data Exchange API to enable seamless data sharing between payers.
• April 2022: CMS required daily data exchange for dual-eligible beneficiaries.
• October 2022: ONC enforced full compliance: All Electronic Health Information must be shared. Expanded enforcement of information blocking rules
• Expected / Proposed November 2023: The Office of Inspector General proposed and finalized financial penalties for information blocking violations.
• September 2025: The Department of Health and Human Services announced a stricter enforcement crackdown, including financial penalties.

COVID-19 Adjustments

• CMS delayed enforcement of January 2021 API requirements to July 1, 2021 due to the public health emergency.
• ONC postponed information-blocking enforcement.
• Full compliance was ultimately required by November 2022, with expanded EHI scope effective October 6, 2022. 

Enforcement and Penalties

• HHS has enforcement authority via ONC and the OIG. As of 2025, HHS announced it will actively enforce info-blocking rules. Entities found violating may face: providers under certain CMS programs can incur payment penalties, health IT developers can incur civil monetary penalties up to $1,000,000 per violation. Certified HIT devs may have their certifications revoked. Patients and providers may report suspected blockers to HHS for investigation. To date, no major fines have been levied on providers, but the new enforcement push indicates action is planned.
• CMS evaluates payer compliance through existing oversight. Failure to implement required APIs could result in plan audit findings or loss of program status. For hospitals/providers, non-compliance with info-blocking could trigger CMS program penalties.
• CMS expects payers to monitor and report on their API performance. CMS publishes lists of providers who have not updated digital contact info and may publish information-blocking violators. Payers also are subject to external testing via plan surveys. HIT developers report on certification compliance to ONC, and must attest in their Maintenance of Certification activities that they have not imposed info-blocking.

Attestation and Documentation

• Many regulated parties must attest annually to compliance: Medicare and Medicaid payers attest that APIs are live; healthcare providers attest via Promoting Interoperability or Quality programs that they are not information-blocking. In 2021, CMS required hospitals and clinicians to attest in PI to not having info-blocking policies.
• Covered entities must document their designated record sets and have policies for any info-blocking exception used. Payers must log API request/response issues and ensure error-handling meets specifications. State Medicaid agencies should update contracts to require MCOs to comply.

Practical Implementation Guidance

Implementation Checklist

Implementers should follow a structured approach:

1. Assess Existing Capabilities: Inventory current APIs, data types, and architecture. Identify where member data reside and how to map to FHIR resources. Evaluate identity/auth systems.
2. Data Mapping: Map internal data fields to US Core FHIR elements. Use the official US Core IG as a reference. For encounters/clinical data, map to FHIR Condition/Procedure/Observation using standardized code sets.
3. API Development: Build FHIR server endpoints supporting required resources. Leverage open-source or commercial FHIR servers if possible. Ensure compliance with IG constraints. Implement SMART on FHIR Auth and OpenID Connect for user login. Implement Bulk Data endpoints if needed for aggregate export.
4. Security and Privacy: Implement OAuth2 flows with patient app scopes, TLS encryption, and audit logging. Verify scopes. For provider APIs, secure with mutual-authentication or app tokens for trusted systems. Deploy Identity and Access Management tools.
5. Testing: Use approved tools like ONC’s Inferno and Da Vinci test suites to validate API endpoints and data format. Conduct conformance tests. Perform end-to-end tests with patient apps and provider systems. Validate privacy compliance.
6. Privacy Policy/Consent: Draft clear notices for patients/app users: inform them how data will be used, that once data is downloaded to an app it may not be HIPAA-protected. Obtain patient consent at the app for data sharing. For data beyond minimum necessary, ensure any special consents are captured.
7. Go-Live and Monitoring: Roll out APIs by the compliance date. CMS requires regular monitoring: log API uptime and errors. Prepare to respond to HHS data requests or plan audits. Post API documentation publicly if possible.

Checklist (sample):

• Ensure patient EHI access through portal/APP with SMART on FHIR.
• Implement and test FHIR R4 APIs: Patient Access, Provider Access, Payer-to-Payer, Directory.
• Map data to US Core profiles; populate required fields.
• Publish public endpoints and consent flow.
• Update privacy policies: address de-identification, data resale, and third-party app use.
• Train staff on information-blocking exceptions and documentation.
• Run external testing.

Common Pitfalls

• Failure to align codes or neglecting demographic linking can break continuity. Always test end-to-end patient matching.
• Incorrect redirect URIs or token scopes cause authentication failures. Use well-tested OAuth libraries and follow SMART on FHIR guides.
• Forgetting that once data leaves the payer/portal, HIPAA no longer applies. CMS recommends requiring apps to have clear privacy policies and even having users acknowledge them. Failure to do so risks user complaints.
• APIs can be queried by many users at once, plan capacity. Also, watch ONC’s Standards Version Advancement Process for updates, use them only if CMS allows.
• Not accounting for stricter state confidentiality laws. If such laws exist, implement logic to restrict data accordingly or obtain additional consent. Document reliance on exceptions.
• Choosing a proprietary API solution not based on open FHIR may make future compliance difficult. Prioritise FHIR standard tools and conformance.

Vendor Selection and Integration

When selecting vendors:

• Prefer those already certified under Cures Edition. Check ONC CHPL for certified modules supporting APIs.
• Ensure vendors support bulk data exports if you need large-scale data access.
• Evaluate integration patterns: many use “API Gateway + FHIR facade”, e.g. deploy a FHIR server in front of legacy claims DB.
• For data aggregation (payer-to-payer), consider an enterprise FHIR service or cloud solutions. The AWS case study at Mary K. Health Network used HealthLake to comply.
• Review how vendors handle error responses and versioning.
• For prior authorization APIs, vendors should support the Da Vinci CRD/DTR/PAS IGs and the planned X12-to-FHIR transformations.

Consent Workflows and Risk Mitigation

• Integrate workflows to capture patient requests for records/APIs. For example, a member portal can let users “connect apps” and authorize data flow.
• Build opt-in controls for family accounts.
• Maintain audit trails of all data disclosures. This helps defend any info-blocking claims or flag potential breaches.
• Implement fallback processes: if the API is down, have a manual method to fulfill urgent requests.

Templates: Checklist and Policy Statement

Compliance Checklist:

• Inventory all data sources. Map to USCDI/US Core.
• Design or update FHIR API endpoints for: Patient Access, Provider Access, Payer-to-Payer, Provider Directory.
• Implement SMART on FHIR for user authentication; configure OpenID Connect if needed.
• Establish error-handling per FHIR spec.
• Ensure HIPAA/42CFR2 compliance: train staff on info-blocking exceptions, document policies.
• Update public-facing API documentation and payer webpages with API URLs and porting instructions.
• Conduct iterative testing: use Inferno/Da Vinci test suites, verify with patient apps and provider queries.
• Verify compliance timelines: Jan 1, 2021, Jan 1, 2022. Plan ahead for later requirements.
• Maintain logs and audit trails of all API transactions.

Sample API Privacy Policy Statement (bulleted):

• Patient Authorization: We only share your health data at your direction. When you connect a third-party app, you will be asked to consent before any data is exchanged.
• Data Shared: We disclose your insurance claims, encounters, lab results, medications, and immunizations via our API. No other personal data will be shared without your explicit approval.
• Data Use: Once the data is in the app you choose, HIPAA no longer applies. We recommend reviewing the app’s privacy policy; we do not control third-party data use.
• Security: Our APIs use secure encryption and your identity is verified before any data is released.
• Stopping Access: You can disconnect any app through your member account or by contacting us, which stops future data sharing.
• No Fees: We do not charge you for using this API, any costs charged by your mobile carrier or device are unrelated.

Such a statement should be conspicuous and, if possible, require a user acknowledgment before the first data transfer.

CMS Interoperability Compliance & Integration Service

Navigating CMS Interoperability and Patient Access rules is not just about compliance, it’s about building a scalable, API-driven healthcare ecosystem that supports secure, real-time data exchange. 

At CapMinds, we deliver end-to-end CMS interoperability services designed to help payers, providers, and health IT organizations align with evolving federal mandates while imprviong operational efficiency and patient data accessibility.

Our approach combines regulatory expertise with deep technical implementation across FHIR, APIs, and healthcare integration frameworks. We ensure your systems are not only compliant but also future-ready for interoperability expansion.

Our CMS Interoperability Services Include:

• FHIR R4 API development and implementation
• Patient Access, Provider Access, and Payer-to-Payer API setup
• HL7, FHIR, and SMART on FHIR integration workflows
• Data mapping to USCDI and US Core profiles
• API security, OAuth2 authentication, and consent management
• Information blocking compliance assessment and remediation
• CMS and ONC rule readiness audits and documentation
• Integration with EHRs, HIEs, and payer systems
• Bulk data export and population-level data access setup
• Ongoing monitoring, testing, and compliance optimization

With CapMinds, you gain a structured interoperability framework that reduces compliance risk, accelerates API deployment, and enables seamless healthcare data exchange, while supporting long-term scalability and regulatory alignment, and more.

Talk to an Interoperability Expert