Are impacted payers required to convert large unstructured documents like portable document formats (PDF) to Fast Healthcare Interoperability Resources® (FHIR®) to support the clinical data exchange requirements of the Patient Access API? In other words, are impacted payers required to convert documents to FHIR® to identify clinical data elements that may or may not be present on a PDF or fax?

Impacted payers (i.e., Medicare Advantage [MA] organizations, Medicaid and Children’s Health Insurance Program [CHIP] Fee-for-Service [FFS] programs, Medicaid managed care plans, CHIP managed care entities, and Qualified Health Plan [QHP] issuers on the Federally-Facilitated Exchanges [FFEs]) are required to make claims, encounter and clinical data, including laboratory results ^[1] available through the Patient Access API. CMS encourages impacted payers to make as much data available to patients as possible through the API to ensure patients have access to their data in a way that will be most valuable and meaningful to them. In the final rule, we said that the Patient Access API must meet the technical standards as finalized by the Department of Health and Human Services (HHS) in the ONC 21st Century Cures Act final rule, the content and vocabulary standards adopted at 45 CFR part 162 and 42 CFR § 423.160 and the United States Core Data for Interoperability (USCDI) version 1, also finalized by HHS (see citations below). ^[2]

Large documents, such as PDFs or a scan of a fax may or may not include data elements in the USCDI. CMS encourages payers to follow industry best practices to map data that a payer maintains as part of an enrollee's record as a discrete data element to USCDI data elements or a Fast Healthcare Interoperability Resources® (FHIR) resource and make it available through the Patient Access API. However, CMS does not require payers to manually go through large files that cannot be parsed into data elements efficiently for the purposes of this API. The final rule did not require payers to include these large files as data available via the API.

What is the requirement for impacted payers to maintain their data? Please clarify the intended meaning of the word “maintain."

The Interoperability and Patient Access final rule (CMS-9115-F) defines ‘‘maintain’’ to mean the impacted payer has access to the data, control over the data, and authority to make the data available through the application programming interface (API) (85 FR 25538). Payers are only required to make the data that they maintain in their systems available through the Patient Access API and for exchange with other payers. If a payer does not maintain clinical information for covered patients in its systems, the payer will not have to share clinical information through the Patient Access API or for exchange with other payers. ^[3] As discussed in the final rule at 85 FR 25513, impacted payers must make available, through the Patient Access API, data they maintain with a date of service on or after January 1, 2016 forward for all current enrollees. Impacted payers must follow any other applicable federal or state laws regarding data retention requirements for records.

Are impacted payers required to provide a single point of access for the member through the Patient Access API? May a payer require a patient to use multiple portals to access their data?

In order to meet the requirements finalized for the Patient Access API, impacted payers are required to make all claims/encounter data, and clinical data they maintain available through a Fast Healthcare Interoperability Resource® (FHIR) -based API. ^[4] This FHIR®-based API allows a third-party software application (“app") of enrollees’ choosing to access the data easily. Payers can set up their APIs in a way that works best for their situations, but ultimately, the data must be available through an API that is conformant with the technical, content, and vocabulary standards adopted in the Interoperability and Patient Access final rule (CMS-9115-F) and ONC 21st Century Cures Act final rule (45 CFR 170.213 and 170.215).

CMS has suggested that industry consider using the CARIN for Blue Button Implementation Guide (IG) for the Patient Access API. The current version of the CARIN for Blue Button IG (STU 1 V1.0.0) ^[5] does not enable the inclusion of certain claims data (e.g. dental and vision claims). Will an impacted payer be considered compliant with the Patient Access API provision of the Interoperability and Patient Access final rule if it uses the suggested CARIN for Blue Button IG?

Yes, from a technical perspective, if a payer uses the suggested IGs, and follows the IGs to specification to build their Patient Access API, the payer could be in compliance with the final rule (85 FR 25524). The Interoperability and Patient Access final rule requires that payers must make available adjudicated claims, encounters and clinical data that they maintain. ^[6] The final rule does not preclude vision or dental claims. When an updated version of the suggested Implementation Guide for the Patient Access API (the CARIN for Blue Button IG) is available for use which enables inclusion of additional claim types, impacted payers may use the updated version.

How do impacted payers report Patient Access API metrics to CMS to comply with the reporting requirement? Is there available guidance for format and method for submission of these metrics?

Under the CMS Interoperability and Prior Authorization final rule (CMS-0057-F), beginning January 1, 2026, and annually thereafter, impacted payers must report metrics (89 FR 8779) in the form of aggregated data to CMS on the number of patients who use the Patient Access API. Specifically, this includes: 

1. The total number of unique patients whose data are transferred via the Patient Access API to a health app selected by the patient; and 
2. The total number of unique patients whose data are transferred more than once via the Patient Access API to a health app designated by the patient. 

The format and method for submission of these reports will be communicated in early 2025.

Footnotes

• ^[1] 42 CFR § 422.119; 42 CFR § 431.60; 42 CFR § 438.242(b)(5); 42 CFR § 457.730; 42 CFR § 457.1233(d); and 45 CFR § 156.221
• ^[2] 42 CFR § 422.119(c)(3)(i); 42 CFR § 457.730(c)(3); 45 CFR § 156.221(c)(1); 45 CFR §§ 170.215; 45 CFR §§ 170.213
• ^[3] 42 CFR §§ 422.119(h) and 438.242(b)(5); 45 CFR § 156.221(i)(1).
• ^[4] 42 CFR § 422.119; 42 CFR § 431.60; 42 CFR § 438.242.(b)(5); 42 CFR § 457.730; 42 CFR § 457.1233(d)(2); 45 CFR § 156.221.
• ^[5] http://hl7.org/fhir/us/carin-bb/history.html
• ^[6] 42 CFR § 422.119; 42 CFR § 431.60; 42 CFR § 438.242.(b)(5); 42 CFR §§ 457.730; 42 CFR § 457.1233(d)(2); 45 CFR § 156.221.