On May 14, 2021, CMS published FAQs addressing questions that have been raised regarding the Interoperability and Patient Access final rule published May 2020.  CMS is careful to note that the FAQs “do not have the force and effect of law and are not meant to bind the public in any way, unless specifically incorporated into a contract, as directed by a program.”  CMS has provided links and other guidance, including regarding technical standards, best practices, and privacy and security resources, and has directly addressed questions raised by trade associations and others.

We summarize some of the key points addressed in the FAQs.  We encourage you to review the full CMS response where questions arise in your implementation.

Patient Access API

  • Conversion of PDFs or scans of faxes: CMS states that regulated payers are not required to manually go through large files that cannot be parsed into data elements efficiently for the purposes of this API and are not required to include these large files as data available via the API. However, CMS encourages payers to make as much data available to patients as possible through the Patient Access API and 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 FHIR resource for access through the Patient Access API.
  • Maintaining Data: CMS does not provide much additional clarification.  The guidance reiterates what CMS stated in the preamble that ‘‘maintain’’ means the impacted payer has access to the data, control over the data, and authority to make the data available through the API (85 FR 25538).  They add that 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, and if they do 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.  While the term “covered patients” was not used in the CMS Interoperability rule, CMS explained that payers “subject to these rules [are required] to send data at the enrollee’s request at any time during enrollment or up to 5 years after enrollment ends” (85 FR 25567).
  • Single point of access for Patient Access API: CMS does not directly answer if a single Patient Access API is required or if a regulated payer can comply with multiple APIs, but we interpret the response to permit multiple APIs. CMS stated that payers “can set up their APIs in a way that works best for their situations,” as long as the API is conformant with the technical, content, and vocabulary standards adopted in the CMS and ONC interoperability rules.
  • CARIN IG and exclusion of dental and vision claims: CMS stated that if an entity is in compliance with the CARIN for Blue Button IG, which excludes certain claims data such as dental and vision, it will be considered technically compliant with the CMS Patient Access API.  CMS does not explicitly state that vision and dental claims are excluded and seems to suggest that as this IG is updated to include additional claim types, payers should make efforts to adopt such updates.

Payer-to-Payer Data Exchange

  • Response to payer requests: CMS states that where the rule requires a patient’s action for payer-to-payer data exchange, the health plan cannot directly request the information as the “personal representative” of the individual.  As such, where the CMS Interoperability and Patient Access rule requires payers to send specific information they maintain to any other payer identified by the current or former enrollee, that is limited to enrollee request.  CMS notes that payers may be able to exchange data without a request from a patient for payment and health care operations purposes.  We note that even if such disclosure is not required under the CMS Interoperability and Patient Access rule, where such disclosure is permissible under HIPAA, it may be required under ONC’s information blocking rule.

Provider Directory API

  • Public facing Provider Directory API: Regulated payers, other than QHP issuers on the FFE[1], are required to offer a public facing Provider Directory API which must include data on a payer’s network of contracted providers, including provider names, addresses, phone numbers, and specialties. Directory information must be available to current and prospective enrollees and the public within 30 calendar days of a payer receiving provider directory information or an update to the provider directory information.  CMS clarifies that in order to be publicly available, the Provider Directory API must exclude the security protocols related to user authentication and authorization and any other protocols that restrict the availability of this information to particular persons or organizations (see 85 FR 25543). With regard to providers managed through contracted network, CMS states that “payers may make appropriate business decisions for ensuring availability of the Provider Directory APIs,” including providing information or links on the payer website to direct interested parties to those APIs.
  • MA-PD plan requirements: MA organizations that offer MA-PD plans must make available, at a minimum, pharmacy directory data and include the pharmacy name, address, phone number, number of pharmacies in the network, and mix (specifically the type of pharmacy, such as “retail pharmacy”).
  • Registration of 3rd party apps:  A payer may not require the developer or the application that accesses the Provider Directory API (or its documentation) to register to use the Provider Directory API because these apps are supposed to be publicly accessible. CMS states that the final rule requires payers make the Provider Directory API accessible via a public-facing digital endpoint on their website to ensure public discovery and access.  However, CMS notes that  under the payer’s obligation to keep its systems secure under other rules, payers may, as they would protect data for any website, put certain information behind an initial firewall in order to protect against a denial of service attack.
  • Compliance and Testing of APIs: CMS clarified that the Interoperability and Patient Access Rule does not require payers to certify their APIs. However, they note that regulated payers are required to conduct routine testing and monitoring, and update their systems as appropriate, to ensure the API functions properly and is compliant with HIPAA privacy and security requirements. CMS recommends that impacted payers use the implementation guides and testing tools developed for use with FHIR APIs and refer to HL7 Da Vinci Implementer website.
  • Compliance with CMS Interoperability and Patient Access Rule: CMS will assess compliance in accordance with the oversight policies of each impacted program. Specifically:
    • Medicare Advantage and Medicaid managed care programs each have programs in place to evaluate compliance of contracted entities. Medicare Advantage plans will be evaluated using annual survey instruments. Similarly, the States will use their contract vehicle to complete assessments.
    • Issuers of QHPs on the FFEs will be evaluated through the annual QHP certification application process. CMS will provide additional guidance to QHP issuers.

[1] Because QHP issuers on the FFEs at 45 CFR 156.221(i) were already required to make provider directory information available in a specified, machine-readable format, CMS did not require that QHP issuers would have to make provider directory information available through an API.