Interoperability Framework

Vision

We’re done waiting. The CMS Interoperability Framework is a call to action for health data networks that want to move faster - to make what should already work, actually work by voluntarily meeting the CMS Interoperability Framework criteria to be listed as a CMS-Aligned Network.

This is a voluntary blueprint for modern health data exchange that puts patients and providers first. It is open, standards-based, and market-friendly, so that the industry can stop theoretical debates and start delivering real results. CMS is offering shared infrastructure and clear criteria, and we’re inviting any network – big or small – that’s ready to lead.

This effort is not intended to create new regulatory burdens. Just alignment, execution, and momentum. Come one, come all.

The Interoperability Framework has two parts: the criteria that define data sharing principles and the different categories of participants, such as networks, EHRs, providers, payers, and digital health products. All participants should understand the framework criteria overall and consult the participant-specific sections for the requirements applicable to their role.

We’re looking for early adopters in the following categories to pledge to collaboratively meet and aim to showcase the objectives in the first quarter of 2026. 

1. CMS Aligned Networks
2. Providers connecting to CMS Aligned Networks
3. EHRs connecting to CMS Aligned Networks
4. Payers connect to CMS Aligned Networks
5. Patient Facing Apps leveraging CMS Aligned Networks
   1. Kill the Clipboard
   2. Conversational AI
   3. Diabetes and Obesity Prevention and Management

Where needed, further technical specifications or implementation guides will be determined by the working group of early adopters.

For clarity, nothing in this document is intended to contravene federal and state healthcare and privacy laws, including HIPAA and the Privacy Act.

Framework Criteria:

The below criteria are meant to be visionary and to illustrate the goals of the initiative. For criteria that are less mature, early adopters will collaborate with CMS to document and publish implementation guidelines.

I. Patient Access & Empowerment

1. Patients, using applications of their choice, can access their electronic medical information anywhere that it lives on the network – including both structured and unstructured data, with certain limited exceptions. Apps can be commercial or non-commercial and will not require any special status to be on the network. They will be able to communicate without special effort.
2. Patients can access their claims, explanation of benefits (EOBs), prior authorizations, and clinical data (when applicable) from current or past payers. Patients can initiate these requests from commercial and non-commercial apps and will not require any special status to be on the network. They will be able to communicate without special effort.
3. No additional login or portal info required: If a patient uses a digital identity credential, through a CMS-approved service for IAL2 or equivalent (e.g., mDLs) and AAL2 (e.g., passkeys), all nodes must return to the patient (or their personal representative) electronic medical information, without requiring knowledge of specific providers, portal accounts, or additional interactions. In addition, implementers should leverage additional credentials, including digital insurance cards, to improve the patient’s identity verification and trust. For clarity, IAL2 is Identity Assurance Level 2, mDL is mobile driver’s license, and AAL2 is Authentication Assurance Level 2.
4. Audit log transparency: The network provides an accounting record of all network-facilitated transactions, including for treatment, (who accessed patient’s data, when, and why) and ensures a timely response for each request.
5. Patient consent preferences, when included in a transaction, must be shared with all involved parties, including for treatment use cases. These preferences must be supported when required by law or policy, including honoring a patient’s right to request restrictions on disclosures of their information for certain purposes. 

II. Provider Access & Delegation

6. Full treatment access: If a provider uses an identity verified credential such as IAL2 or equivalent (eg, mDLs) and AAL2 (eg, passkeys), is validated as an active provider in the CMS National Provider Directory, and attests that the request is for treatment purposes, all nodes must return all information they hold on the patient except where restricted by law.
7. Delegated model supported: Providers may use any application or delegated technology vendor/partner of their choice to execute transactions in the network. When acting on behalf of a provider, such vendors are considered business associates under HIPAA and must have an executed Business Associate Agreement in place. These delegated actions are treated as equivalent to direct provider actions. Delegated vendors/partners are not required to provide reciprocation within the network unless otherwise contractually agreed.
8. Open quality gap queries: Open quality gap queries: Payers, including CMS, and other Value-based care organizations may query for specific quality data elements (e.g., HbA1c, mammograms, colonoscopies, blood pressure, BMI, depression screening) necessary for payment or health care operations.
9. Claims-based encounter access: Payers, including CMS, can query for relevant data tied to a claim submitted in the last 60 days and receive clinical data for that encounter.

III. Data Availability & Standards Compliance

10. Chart notes and clinical documents (e.g., radiology reports, scanned/faxed labs, external specialist notes) are returned in machine and human-readable formats (PDF, TIFF, JPG) as specified in United States Core Data for Interoperability, Version 3 (USCDI v3).
11. Queries must have a timely response.  Where legally permissible, queries should be fulfilled automatically and, when feasible, in real-time—including through use of IAL2 credentials to support identity matching. Use of a valid IAL2 credential should enable query responses without requiring patients to register for or log into a separate portal. If additional information is needed to complete verification or authorize disclosure, the response must clearly indicate what is needed and allow resolution without unnecessary burden on the patient.
12. Patient appointment and encounter details (e.g., date, time, provider, location, type) may be shared, in accordance with existing law.  Although networks may initially support non-FHIR standardized formats thatare already live today, they must be committed to supporting and implementing FHIR APIs.

By July 4th, 2026

13. Networks must provide or facilitate access to data using FHIR APIs, that adheres to the US Core FHIR implementation guide, including full FHIR capabilities statement and USCDI V3 (or later) with terminology compliance (e.g., labs in LOINC, meds in RxNorm, conditions in SNOMED). Networks should leverage FHIR Bulk data exchange to reduce stress on existing systems and enable the exchange of full data records.
14. Chart notes and clinical documents (e.g., radiology reports, scanned/faxed labs, external specialist notes) are returned in human-readable formats (PDF, TIFF, JPG) as FHIR attachments as specified in USCDI V3.
15. Appointment and encounter notifications will be provided for outpatient, telehealth, ED, and inpatient encounters using FHIR subscriptions, where such notifications are permitted by existing law.
16. Implement record locator functionality by collaborating with CMS to determine efficient and timely models to reduce query load on the networks and to aid understanding of data completeness. Requests to the record locator service can be initiated by patients, providers and value-based care organizations.

IV. Network Connectivity & Transparency

17. Data networks agree to be displayed as a CMS Aligned Network and to publish membership information, NPI level participants, relevant endpoints and other inter-connected networks in the CMS National Provider Directory, in the format and cadence established by the agency.
18. Update the CMS National Provider Directory as new information is discovered about providers, such as contact details, license information, interoperability endpoints, and insurance plans accepted. This data will be shared in the format and cadence established by the agency.
19. Provide metrics on network queries, as well as usage statistics, including number of successful and unsuccessful replies, to share in the CMS National Provider Directory. CMS may develop scorecards based on the network metrics and user’s feedback.
20. Standards-based inter-network connectivity is supported, including the ability to query/respond across federated networks using widely accepted query formats and protocols.
21. Supports searching network-wide for all records of a patient or only a subset using a targeted query (e.g., records in a certain state or from a specific NPI).

V. Identity, Security & Trust

22. All queries must include the purpose for the request (e.g., individual access, treatment, payment, or healthcare operations) to ensure disclosures are lawful.
23. Accepts digital credentials for both patients and providers using a CMS-approved service for IAL2 or equivalent (e.g., mDLs) and AAL2 (e.g., passkeys).
24. Enforces access control and consent policy appropriate to the data access context.
25. Provides verifiable logs or audit records for identity/auth requests and responses for independent review.
26. Maintain HITRUST certification or equivalent security validation as approved by CMS. Note, HITRUST certification does not replace or supersede the obligation to fully comply with the HIPAA Security Rule.

For clarity, nothing in this document is intended to contravene, supersede, or preempt federal or state healthcare or privacy laws, such as the Health Insurance Portability and Accountability Act of 1996 Privacy, Security, and Breach Notification Rules (HIPAA Rules), and the Privacy Act of 1974. HIPAA covered entities and business associates implementing the CMS Interoperability Framework criteria retain their obligations to fully comply with the HIPAA Rules, including, for example, verifying the identity and authority of protected health information (PHI) requesters; meeting the requirements associated with the purpose of the use or disclosure of PHI; implementing the minimum necessary standard; fulfilling the rights of individuals (including to request restrictions on the use or disclosure of their PHI); notifying affected individuals, HHS, and, as applicable, the media, of breaches of unsecured PHI; and ensuring business associate agreements are in place.