The CMS Interoperability Vision
Health Data That Truly Flows
The CMS vision makes health data truly flow across the healthcare industry, breaking down the barriers between systems and empowering every patient with their own information.
What is the CMS Interoperability Framework?
The CMS Interoperability Framework is a voluntary, open, standards-based blueprint that invites any health data network to commit to a clear set of data sharing principles and get listed as a CMS-Aligned Network.
The goal is simple but powerful: beneficiaries and providers should be able to access any patient's health data, anywhere it lives, through any app of their choice — without logging into separate portals, filling out clipboardsor waiting for fax machines.
Framework Criteria
The criteria below are visionary goals for the industry. Early adopters collaborate with CMS to establish implementation guidelines for emerging standards.
- 1. Beneficiaries, 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. Beneficiaries can access their claims, explanation of benefits (EOBs), prior authorizationsand clinical data (when applicable) from current or past payers. Beneficiaries 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 accountsor 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 licenseand 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, whenand 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.
- 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 Directoryand 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. Payers, including CMSand 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.
- 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, TIF, 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 beneficiaries 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 appointments 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 that are already live today, they must be committed to supporting and implementing FHIR APIs.
- 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, TIF, JPG) as FHIR attachments as specified in USCDI V3.
- 15. Appointment and encounter notifications will be provided for outpatient, telehealth, EDand 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 beneficiaries, providers and value-based care organizations.
- 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 endpointsand 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.
- 22. All queries must include the purpose for the request (e.g., individual access, treatment, paymentor healthcare operations) to ensure disclosures are lawful.
- 23. Accepts digital credentials for both beneficiaries 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 applicable laws and standards.
For clarity, nothing in this document is intended to contravene, supersedeor preempt federal or state healthcare or privacy laws, such as the Health Insurance Portability and Accountability Act of 1996 Privacy, Securityand 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, HHSand, as applicable, the media, of breaches of unsecured PHI; and ensuring business associate agreements are in place.
USCDI Version 3.1
The United States Core Data for Interoperability defines the standardized data elements all CMS-Aligned Networks must support. Published by ONC, June 2025.