Final

Issued by: Centers for Medicare & Medicaid Services (CMS)

CMS published Frequently Asked Questions (FAQs) on various topics related to the May 2020 Interoperability and Patient Access final rule (CMS-9115-F)(85 FR 25510) for reference by impacted payers and providers. As we note below, you will find the contents of 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. The FAQs are intended only to provide clarity to the public and regulated payers and providers regarding existing requirements under the law, specifically the entities to whom this guidance applies including Medicare Advantage Organizations, Medicaid Fee-for-Service Organizations, Medicaid Managed Care Plans, CHIP Managed Care Entities, Issuers of Qualified Health Plans on the Federally-facilitated Exchanges (FFEs) (referred to in these document as “impacted payers”) and certain providers. 

The information herein addresses certain requirements for impacted payers to build application programming interfaces (APIs), and (for certain impacted payers) to conduct payer-to-payer exchanges; and requirements for certain providers to include digital contact information in the National Provider and Payer Enumeration System (NPPES), and transmit Admission, Discharge and Transfer Notifications (ADT). This communication was printed, published, or produced and disseminated at U.S. taxpayer expense and issued on April 30, 2021.

For the regulatory requirements on impacted payers referenced in this guidance, see 42 CFR part 422 for Medicare Advantage plans; 42 CFR part 431 for state Medicaid fee-for-service programs; 42 CFR part 438 for Medicaid managed care plans, 42 CFR part 457 for CHIP programs, and 45 CFR part 156 for QHP issuers on the FFEs.

For the regulatory requirements related to API standards finalized by Office of the National Coordinator for Health Information Technology (ONC) in the 21st Century Cures Act: Interoperability, Information Blocking, and the ONC Health IT Certification Program final rule (85 FR 25642), see 45 CFR part 170.  

Please see below for the published CMS 9115-F FAQs.  A PDF version of the CMS 9115-F FAQs are also available here (PDF).  

Table of Contents

Patient Access API

Provider Directory API

Compliance and Testing of the Required APIs

Technical

Medical Loss Ratio (MLR) for Medicaid MCOs, MA Plans, and Issuers of QHPs on the Federally-Facilitated Exchanges

Admission, Discharge, and Transfer Patient Event Notification Conditions of Participation (CoP) (42 CFR 482.24(d), 482.61(f), and 485.638(d))

Digital Contact Information: What is it? What is required?

Public Reporting of Missing Digital Contact Information

Provider Types Subject to Providing Digital Contact Information

Bulk Upload, Reviewing and Updating Digital Contact Information in NPPES

Payer-to-Payer Data Exchanges

Proposed Rule on Interoperability and Improving Prior Authorization

---

Patient Access API

1. Question. 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? 

• Response. Impacted payers (i.e., MA organizations, Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs) are required to make claims, encounter and clinical data, including laboratory resultsftn1 title="">[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 HHS in the ONC 21^st 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).ftn2 title="">[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 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.

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

• Response. 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 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.    

3. Question. 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?

• Response. 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 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 21^st Century Cures Act final rule (45 CFR 170.213 and 170.215). 

4. Question. 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 BlueButton IG? 

• Response. 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.     

Back to top

Provider Directory API 

5. Question. Are payers impacted by the Interoperability and Patient Access final rule (CMS-9115-F) required to offer a public facing Provider Directory API? What information are they required to include through the Provider Directory API for in-network providers and contracted networks?

• Response. MA organizations, Medicaid state agencies, Medicaid managed care plans, CHIP state agencies and CHIP managed care entities are required to offer a public facing Provider Directory API which must include data on a payer’s network of contracted providers.[7]
  • 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, we did not require that QHP issuers would have to make provider directory information available through an API.
  • Impacted payers, other than the QHP Issuers on the FFEs, must make certain information accessible through the Provider Directory API, 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[8].  There are additional content requirements for the provider directory under the Medicaid and CHIP managed care program at 438.10(h)(1) and (2).
  • CMS does not specify how payers manage access to APIs for provider directories for providers managed through contracted networks. Therefore, payers may make appropriate business decisions for ensuring availability of the Provider Directory APIs, making them accessible, and providing information or links on the payer website to direct interested parties to those APIs.
  • The Provider Directory API must be publicly available and 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).

6. Question. What are the requirements for the Provider Directory API for Medicare Advantage organizations that offer Medicare Advantage Prescription Drug (MA-PD) plans, with respect to including the mix and number of pharmacies in their network?

• Response. 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”).[9] In the Interoperability and Patient Access final rule (CMS-9115-F), CMS encouraged MA-PD plans to build a Provider Directory API that is conformant to the Health Level Seven International (HL7) PDex Plan-Net Implementation Guide (85 FR 25529).

7. Question. May a payer require the developer of a third-party application or the third-party application itself to register in order to use the Provider Directory API?

• Response. No, 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. The Provider Directory API endpoint must be made publicly accessible and payers subject to the Provider Directory API requirement must make that API publicly accessible. The API technical standards for the Provider Directory API 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.[10] In addition, payers must make sure that the API and its documentation are accessible via a public-facing digital endpoint on the payer's website.[11] Specifically, 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.[12] Given this is generally publicly available information at this time, restrictions are not permitted. However, under the payer’s obligation to keep its systems secure under other rules, payers may put certain information behind an initial firewall in order to protect against a denial of service attack, much as they would currently protect data for any website. Otherwise this must be a truly public and unrestricted digital endpoint.

Back to top

Compliance and Testing of the Required APIs

8. Question. Does CMS require certification to determine if a payer’s APIs comply with the requirements of the Interoperability and Patient Access final rule?

• Response. No, CMS does not require that payers certify their APIs as part of the requirements imposed on MA Organizations, Medicaid Managed Care Plans, State Medicaid Agencies, CHIP Agencies, CHIP Managed Care Entities, and Issuers of Qualified Health Plans on the FFEs. However, these impacted payers are required to conduct routine testing and monitoring, and update their systems as appropriate, to ensure the API functions properly, including conducting assessments to verify that the API is fully and successfully implementing privacy and security features such as those required to comply with HIPAA requirements in 45 CFR parts 160 and 164, 42 CFR parts 2 and 3, and other applicable laws protecting the privacy and security of individually identifiable data.[13]

9. Question. Does CMS require that payers test their APIs? What testing tools should implementers use for the implementation guides suggested in the Interoperability and Patient Access final rule?

• Response. The CMS Interoperability and Patient Access final rule requires impacted payers to conduct routine testing and monitoring of their APIs and to make updates as appropriate, to ensure the API functions properly.[14]
  • CMS recommends that impacted payers use the implementation guides and testing tools developed for use with FHIR APIs.  The authoring organizations of the implementation guides, HL7 Da Vinci and the CARIN Alliance have chosen to use certain testing tools that are available on the HL7 Da Vinci Implementer website. For more information, visit that web page at: https://confluence.hl7.org/display/DVP/Da+Vinci+Implementer+Support
  • There are at least two different levels of testing that can be performed:
    • FHIR API validation: These tests validate that the FHIR APIs conform to the FHIR IGs that specify the API, including terminologies.
    • Rule conformance/certification: These tests evaluate the API and the data content. This can be done with synthetic sample data or with actual data.  

10. Question. How will CMS evaluate compliance with the provisions of the Interoperability and Patient Access final rule?

• Response. Compliance with the provisions of the Interoperability and Patient Access final rule will be assessed in accordance with the oversight policies of each impacted program.  The MA and Medicaid managed care programs each have programs in place to evaluate compliance of contracted entities. Issuers of QHPs on the FFEs will be evaluated through the annual QHP certification application process, and in the final rule we indicated that we would provide additional guidance to QHP issuers on how they would demonstrate compliance (85 FR 25553). Medicare Advantage plans will be evaluated using annual survey instruments. Similarly, the States will use their contract vehicle to complete assessments. Each program will provide information about evaluation mechanisms at a later date.

Back to top

Technical

11. Question. What resources are available for additional assistance with technical questions related to the suggested implementation guides?

• Response. CMS encouraged the use of certain HL7 FHIR Implementation Guides, and provided links to information and resources on our website. There are a number of implementer work groups in which impacted payers and their vendors may be interested in participating to support their project development and implementation plans. Technical questions may be addressed from these resources through the main HL7 Zulip chat stream (https://confluence.hl7.org/display/FHIR/Zulip+Streams) or to one of the HL7 Zulip chat links below based on the relevant IG.
  • Carin BB: https://chat.fhir.org/#narrow/stream/204607-CARIN-IG.20for.20Blue.20Button 
  • PDex: https://chat.fhir.org/#narrow/stream/235286-Da-Vinci.20PDex
  • Formulary:  https://chat.fhir.org/#narrow/stream/197730-Da-Vinci.20PDex.20Drug.20Formulary
  • Plan Net/ Directory: https://chat.fhir.org/#narrow/stream/229922-Da.2BVinci.2BPDex.2BPlan-Net
• To obtain an account, visit the Zulip chat home page at: chat.fhir.org. For additional guidance, refer to the HL7 confluence site at: https://confluence.hl7.org/display/CAR/CMS+Patient+Access+API+%3A+Industry+Questions+and+CMS+Answers.
• For testing questions and support: https://touchstone.aegis.net/touchstone/

Back to top

Medical Loss Ratio (MLR) for Medicaid MCOs, MA Plans, and Issuers of QHPs on the Federally-Facilitated Exchanges   

12. Question. Can implementation costs related to interoperability be ified as Quality Improvement Activity (QIA) expenses rather than administrative costs for purposes of MLR calculation?

• Response. Yes, for QHP issuers on a Federally-Facilitated Exchange, if the criteria described in section 2718(a)(2) of the Public Health Service Act and its implementing regulations at 45 CFR part 158 are met, implementation costs related to interoperability may be ified as QIA expenses rather than administrative costs for purposes of MLR calculation. There are similar standards required for QIA treatment that are applicable to Medicaid Managed Care Plans (MCOs, PIHPs, and PAHPs) under 42 CFR 438.8(e),[15] CHIP managed care entities under 42 CFR 457.1203(f),[16] MA organizations under 42 CFR 422.2430, and Part D sponsors under 42 CFR 423.2430.[17] An entity’s MLR is generally calculated as the proportion of revenue spent on clinical services and QIA. There are specific criteria an expense must meet to qualify as a QIA expense, such as being designed to improve health quality and health outcomes through care coordination.  
  • QHP issuers should work with their Plan Management contacts for additional information and to submit MLR reports. Medicaid managed care plans should work with their state partners to ensure expenses are accurately reflected in their MLR reports in accordance with their contractual requirements. Additional guidance regarding the MLR calculation and reporting requirements for MA organizations and Part D sponsors is available at: https://www.cms.gov/Medicare/Medicare-Advantage/Plan-Payment/MedicalLossRatio.html.

Back to top

Admission, Discharge, and Transfer Patient Event Notification Conditions of Participation (CoP) (42 CFR 482.24(d), 482.61(f), and 485.638(d))

13. Question. What are the CoP requirements for the admission, discharge, and transfer (ADT) patient event notifications within the final rule?

• Response. The patient event notification CoP requirement is limited to those hospitals, psychiatric hospitals, and critical access hospitals (CAH) that utilize electronic medical record systems or other electronic administrative systems that are conformant with the content exchange standard at 45 CFR 170.205(d)(2). However, conformance with this standard is only used to determine whether a facility will be evaluated under the CoP.  Hospitals are not required to use a specific standard or technology to implement the electronic patient event notification required by the CoP. Hospitals subject to this rule may transmit patient event notifications using a range of approaches, including messages based on different versions of HL7 messaging standards, summary care records using the C-CDA standard, or making notification information available via a FHIR-based API (see 85 FR 25596 through 25597). CMS does note that a fax is not considered an electronic method of data exchange in this context. Please see page 25584 of the final rule for full details of the CoP.
  • The applicability date for the patient event notifications requirement is April 30, 2021. Compliance with this requirement will be assessed through established survey and certification procedures.

14. Question. Will CMS provide an extension for hospitals based on hardship for compliance with the patient event notification requirement?

• Response. CMS will not provide hardship extensions for compliance with the patient event notification requirements for hospitals or CAHs. We note that the final rule was published on May 1, 2020.

15. Question. Can CMS elaborate on the intended goal of including the name of the treating practitioner in the minimum information that must be included in the notification pursuant to 482.24(d)(2), 482.61(f)(2), and 485.638(d)(2)?

• Response: The intended goal of including the name of the treating practitioner in the minimum information that must be included in an electronic notification is the facilitation of care coordination. We believe that including the name of the treating practitioner in the notification enables seamless, coordinated patient care. Existing patient event notification systems have demonstrated that a minimal set of information can achieve the desired effect of improving care coordination while imposing minimal burden on providers. 

16. Question. What course of action should hospitals take if a patient has not yet been assigned to a treating physician at the time a patient event notification is required to be generated?

• Response. In these instances (which we expect would only possibly occur upon initial registration in the emergency department [ED]), since the treating physician is not known at the time of issuance, hospitals would not need to include it in the notification.  

17. Question. Is a patient event notification required when a patient is receiving services in the hospital’s emergency department and subsequently has their status changed to observation status?

• Response. No. The preamble language in the final rule notes the following: “The revisions we are finalizing here would require a hospital’s system to send patient event notifications for patients who are registered in the ED, if applicable, and then also for patients admitted as inpatients, regardless if the patient was admitted from the ED, from an observation stay, or as a direct admission from home, from their practitioner’s office, or as a transfer from some other facility.” (85 FR 25592-93). Note that the hospital must send patient event notifications for patients registered in the ED, patients discharged from the ED, patients who are admitted, and patients who are discharged or transferred from the hospital’s inpatient services. Additionally, as noted in the preamble to the final rule, “However, while the requirements do not prohibit a hospital from electing to send a patient event notification when a patient is transferred to one inpatient services unit of the hospital to another, the requirements finalized in this rule are based on a change in the patient's status from outpatient to inpatient, and not necessarily on the physical location of the patient.” (85 FR 25593). To clarify, since a patient in the ED and a patient in observation are both considered to be outpatients (as they have not been admitted to the hospital as inpatients), there is no change in the patient’s status as an outpatient if the patient in the ED is then placed in observation. As per our discussion in the above example of an inpatient transferred from one inpatient services unit to another, the requirements here similarly do not prohibit a hospital from sending a patient event notification if a patient in the ED is subsequently placed in observation; however, such a notification is not required.

18. Question. How will CMS handle scenarios where a hospital can only record a patient’s primary care practitioner because their electronic health record (EHR) vendor has not provided a method to electronically capture any additional provider and/or group types?

• Response. Under the requirements at 482.24(d)(5), 482.61(f)(5), and 485.638(d)(5), a hospital (or CAH) that is compliant with the content exchange standard under 45 C.F.R. 170.205(d)(2) must demonstrate that it has made a reasonable effort to ensure that its system sends the notifications to all applicable post-acute care services providers and suppliers, as well as to any of the following practitioners and entities, which need to receive notification of the patient's status for treatment, care coordination, or quality improvement purposes:
  • The patient's established primary care practitioner; or
  • The patient's established primary care practice group or entity; or
  • Other practitioner, or other practice group or entity, identified by the patient as the practitioner, or practice group or entity, primarily responsible for his or her care.
• A hospital is not required to demonstrate that it has captured information about recipients for notifications in the EHR, but may capture information about recipients in whatever manner is convenient. If a hospital chooses to work with an intermediary to deliver notifications, the intermediary may capture information about recipients.

19. Question. Is there a timeframe that would qualify for compliance with the patient event notification requirements other than “immediate”?  Is it acceptable to produce a single document daily for primary care practitioners that lists the admission, discharge, and transfer information from the previous day to limit the number of notifications that the physician receives and would provide a working report for the office staff so that they can schedule follow-up appointments as necessary? 

• Response. The Interoperability and Patient Access final rule requires at 42 CFR 482.24(d)(3) for hospitals, 482.61(f)(3) for psychiatric hospitals, and 485.638(d)(3) for CAHs, that if such hospital utilizes a compliant electronic medical records system or other electronic administrative system as discussed above, the system should send notifications directly, or through an intermediary that facilitates exchange of health information at the time of: (i) The patient's registration in the hospital's emergency department (if applicable) or (ii) The patient's admission to the hospital's inpatient services (if applicable).  The final rule also requires at 42 CFR 482.24(d)(4), 482.61(f)(4), and 485.638(d)(4), that if a hospital (or CAH) utilizes an electronic medical records system or other electronic administrative system, the system should send notifications directly, or through an intermediary that facilitates exchange of health information, either immediately prior to, or at the time of: (i) The patient’s discharge or transfer from the hospital’s emergency department (if applicable) or (ii) The patient’s discharge or transfer from the hospital’s inpatient services (if applicable).  We interpret “immediately” to be at the time of discharge or transfer and without any intentional delays. Further, at 482.24(d)(5), 482.61(f)(5), and 485.638(d)(5), the rule requires that the hospital (or CAH) make a reasonable effort to ensure that the system sends the notifications to post-acute care services providers and suppliers, as well as to other practitioners and entities, which need to receive notification of the patient’s status for treatment, care coordination, or quality improvement purposes. The intent of this rule is to ensure that health information exchange is used to improve care coordination across settings, especially for patients at discharge, resulting in a reduction in readmissions, improved post-discharge transitions, and a reduction in the likelihood that a patient would face complications from inadequate follow-up care. As a result of this, and the cited regulatory provisions, hospitals are required to send the admission, discharge, and transfer notifications “at the time of” the patient’s admission or registration and “immediately prior to, or at the time of” the patient’s discharge or transfer.   Intentional delays in sending these notifications is not consistent with the regulatory requirement.
  • However, these requirements would not preclude hospitals, working either directly with providers or through an intermediary, from tailoring the delivery of patient notifications in a manner consistent with individual provider preferences. Thus, in accordance with provider preferences, a hospital or intermediary would be permitted to group notifications for daily delivery if preferred.

20. Question. Are hospitals that have not fully adopted the use of an EHR system in all the healthcare services units, and are therefore utilizing a health record system that consists of paper records and electronic records, or hospitals that are currently migrating from one EHR system to another, required to comply with the patient event notification requirements?

• Response. The applicability date for the patient event notifications, as required under the Interoperability and Patient Access final rule, is April 30, 2021. The provisions of this final rule require that a hospital, psychiatric hospital, or a CAH demonstrate compliance with all of the patient event notification requirements contained at 42 CFR 482.24(d), 482.61(f), and 485.638(d), respectively, only if it utilizes an electronic medical records system or other electronic administrative system that is conformant with the content exchange standard at 45 CFR 170.205(d)(2).  If the hospital is not utilizing an electronic medical record system that is not yet conformant with the requirements in the final rule, CMS would not expect the hospital to meet the patient event notification requirements.
  • As we noted in the preamble to the final rule, we limited the applicability of this requirement to only those hospitals (and CAHs) that utilize electronic medical records systems or other electronic administrative systems that are conformant with the content exchange standard at 45 CFR 170.205(d)(2), recognizing that not all Medicare- and Medicaid-participating hospitals and CAHs have been eligible for past programs promoting adoption of EHR systems. Consistent with that is also our recognition, as expressed in the provisional clause regarding conformance with the content exchange standard, since not every hospital or CAH is at the exact same stage in its individual adoption and efficient use of EHR systems, the patient event notification requirements might not be applicable to such a hospital or CAH at this time.

21. Question. Patient privacy and consent—Are hospitals required to obtain patient consent to send a patient event notification? And will hospitals be able to honor a patient's request to opt-out of sharing information with providers in the form of a patient event notification and still be in compliance with the requirements if they do so? How should hospitals implement the required patient event notifications while still complying with other applicable state and federal laws and regulations around the transmission of sensitive data, particularly state laws and requirements on privacy and consent related to individuals treated in mental health facilities?

• Response. Nothing in this rule should be construed to supersede a hospital’s compliance with HIPAA or other state or federal laws and regulations related to the privacy of patient information. We note that hospitals are not required to obtain patient consent for sending a patient event notification for treatment, care coordination, or quality improvement purposes as described in the final rule. However, we also recognize that it is important for hospitals to be able to honor patient preferences to not share their information. While the CoP would require hospitals to demonstrate that their systems can send patient event notifications, as we stated in the final rule, we do not intend to prevent a hospital from recording a patient's request to not share their information with another provider, and, where consistent with other laws, restrict the delivery of notifications as requested by the patient and consistent with the individual right to request restriction of uses and disclosures established in the HIPAA Privacy Rule. Similarly, if a hospital is working with an intermediary to deliver patient event notifications, the intermediary may record information about a patient's preferences for how they prefer their information is shared, and, where consistent with other laws, restrict the delivery of notifications accordingly. Regarding a patient's ability to request that his or her medical information (in the form of a patient event notification) not be shared with other providers and suppliers and/or practitioners, the requirements in the final rule explicitly state that a hospital (or CAH) must demonstrate that its notification system sends notifications, “to the extent permissible under applicable federal and state law and regulations and not inconsistent with the patient's expressed privacy preferences.”
  • Nothing in these requirements should be construed as conflicting with a hospital’s ability to comply with laws and regulations restricting the sharing of sensitive information. While hospitals subject to the CoPs will need to demonstrate that their systems send notifications to appropriate recipients, hospitals would not be expected to share patient information through a notification unless they have obtained any consents necessary to comply with existing laws and regulations.

22. Question. How should hospitals address cases where they cannot confirm the identity of a provider, and/or where sending a patient event notification could risk improper disclosure of protected health information?

• Response. Regarding improper disclosure of health information where a hospital cannot confirm the identity of a receiving provider, we note that under these requirements a hospital would not be under any obligation to send a patient event notification in such cases. Under our final rule, hospitals are required to make a “reasonable effort” to ensure their systems send notifications to the specified recipients. We believe this standard accounts for instances in which a hospital (or its intermediary) cannot identify an appropriate recipient for a patient event notification despite establishing processes for identifying recipients, and thus is unable to send a notification for a given patient.

23. Question. Can a hospital partner with an intermediary such as a health information exchange (HIE) to send notifications and delegate responsibility for identifying recipients to the intermediary?    

• Response. The final rule permits and encourages use of an intermediary such as an HIE that manages care relationships and routes notifications to the appropriate provider. The final rule discusses a variety of methods through which hospitals can identify recipients for patient notifications, including through partnering with intermediaries such as health information exchanges (84 FR 7652). We believe this is an important approach that hospitals are currently using to identify and route notifications to appropriate recipients, and that using an intermediary to complete these tasks may reduce operational burden for hospitals. Thus, hospitals are permitted to delegate responsibility for identifying recipients to an intermediary where applicable.

24. Question. Are hospitals, or an intermediary which a hospital is working with to deliver notifications, permitted to tailor the frequency or quantity of notifications in accordance with provider preferences.

• Response. Yes, as noted in the final rule (85 FR 25598), under the requirement, hospital systems must send patient notifications in accordance with the requirements. However, this would not preclude hospitals, working either directly with providers or through an intermediary, from tailoring the delivery of patient notifications in a manner consistent with individual provider preferences. For instance, if a specific provider prefers only to receive notifications upon discharge, nothing would prevent the hospital from limiting the notifications sent to that provider accordingly. Hospitals are encouraged to coordinate closely with receiving providers to ensure that the process is not burdensome and alerts are sent in a manner prioritizing the communication of clinically significant events and clinically significant data. Similarly, an intermediary may also support the hospital in developing a process that prioritizes communicating clinically significant events and data in a manner that does not disrupt the receiving providers’ workflows.

Back to top

Digital Contact Information: What is it? What is required?

25. Question. What is a digital contact? Where do providers find information on how to enter or update digital contact information associated with their National Provider Identifier (NPI) in the National Plan and Provider Enumeration System (NPPES) and what fields are required to complete their entry for digital contact?

• Response. Digital contact information, also known as endpoints, provide a secure way for health care entities, including providers and hospitals, to send authenticated, encrypted health information directly to known, trusted recipients over the internet.[18] Health care organizations seeking to engage in electronic health information exchange need accurate information about the electronic addresses (for example, Direct address, FHIR server URL, query endpoint, or other digital contact information) of potential exchange partners to facilitate this information exchange. NPPES can now capture information about a wide range of endpoints that providers can use to facilitate secure exchange of health information (85 FR 25581). Providers may find additional information on digital contact information in NPPES on the Health Information Exchange page of the NPPES website at: https://nppes.cms.hhs.gov/webhelp/nppeshelp/HEALTH%20INFORMATION%20EXCHANGE.html.
  • In the CMS Interoperability and Patient Access final rule, CMS finalized the policy to publicly report the names and NPIs of those providers who do not have digital contact information included in the NPPES system beginning in the second half of 2020 (85 FR 25584).
  • Instructions on how to update digital contact information in NPPES and what fields are required can be found in the instructional PowerPoint deck, beginning on slide 29, at: https://nppes.cms.hhs.gov/assets/How_to_apply_for_an_NPI_online.pdf. The required fields, shown on slide 30, are: Endpoint; Endpoint Type; Endpoint Location; Endpoint Affiliation; and the Endpoint Use Terms and Conditions checkbox.

26. Question. Will patients or members of the public be able to contact a provider via a Direct address, since this information will be publicly available in NPPES? 

• Response.  The main purpose of a Direct address is for providers to exchange health information with each other over the internet in a standardized, secure manner. In general, “Direct” is a technical standard for exchanging health information between health care organizations. Direct is similar to email, but different in important ways. For example, Direct messages are authenticated and encrypted in a specific way to ensure that data are sent and received only by authorized parties. Direct is also formatted slightly differently than personal email. There are some providers who use the Direct technology to communicate with their patients through their patient portals; however, the intent of this technology is not to serve as a regular email exchange for members of the public or patients. Direct addresses are available from a variety of sources, including electronic health record (EHR) vendors, State Health Information Exchange entities, regional and local Health Information Exchange entities, as well as private service providers offering Direct exchange capabilities called Health Information Service Providers (HISPs).  

Back to top

Public Reporting of Missing Digital Contact Information

27. Question. What is the deadline for compliance with the requirement that providers (or clinicians) enter their contact information into NPPES?

• Response. In the CMS Interoperability and Patient Access final rule, CMS finalized the policy to publicly report the names and NPIs of those providers (or clinicians) who do not have digital contact information included in the NPPES system beginning in the second half of 2020 (85 FR 25584). CMS also noted that we would engage in public education efforts to ensure providers were aware of the benefits of including digital contact information in NPPES, including FHIR Application Programming Interfaces (API) endpoints, and when and where this information will be posted. Based on stakeholder inquiries, CMS decided to wait to publish the public report until the programming for the bulk upload of provider information was completed to allow larger organizations to complete the process of adding the digital contact information into NPPES in an efficient manner. The Electronic File Interchange (EFI) process now supports bulk upload capability which enables provider organizations to submit data element changes for their providers, including the addition of the digital contact information. CMS plans to publicly report providers with missing digital contact information by the end of 2021, to give all providers additional time to enter their digital contact information in NPPES, either individually or through the bulk upload.  ​​​
  • CMS has been responding to individual inquiries through the Health Informatics and Interoperability mail box or through the enumerator. This document serves as a public education tool for the wider stakeholder community.
  • All EFI documents are available here: https://www.cms.gov/Regulations-and-Guidance/Administrative-Simplification/NationalProvIdentStand/efi

28. Question. Where will the list of providers (or clinicians) who do not have digital contact information in NPPES be posted? 

• Response. The list of providers who do not have digital contact information in NPPES is available on data.cms.gov here.

Back to top

Provider Types Subject to Providing Digital Contact Information

29. Question. What types of providers (or clinicians) should add their digital contact information into NPPES?

• Response. The types of providers and clinicians who should add their digital contact information into NPPES include those provider types listed below, who have, or may be eligible for a National Provider Identifier (NPI) number. Providers and clinicians who should enter digital contact information in NPPES include:
  • Physicians (including doctors of medicine, osteopathy, dental surgery, dental medicine, podiatric medicine, and optometry)
  • Osteopathic practitioners
  • Chiropractors
  • Physician assistants
  • Nurse practitioners
  • Clinical nurse specialists
  • Physical therapists
  • Occupational therapists
  • Clinical psychologists
  • Pharmacists
  • Qualified speech-language pathologists
  • Qualified audiologists

30. Question. Do hospital-based medical professionals need to have a digital contact listed in NPPES? Do these providers enter their own digital contact information, or may they use the hospitals digital contact information and enter that in NPPES?

• Response. CMS’ policy of publicly reporting the names and NPIs of those providers who do not have digital contact information included in the NPPES system applies to individual providers and clinicians, regardless of their affiliation or employment with a hospital (85 FR 25584). NPPES can now maintain information about the type of contact information for providers or clinicians and the organizations with which they are associated, along with the preferred uses for each digital address. Each provider (or clinician) in NPPES can maintain their own unique digital contact information or associate themselves with information shared with a hospital or among a group of providers or clinicians. Hospital-based providers or clinicians are included in this policy of public reporting of missing digital contact information in NPPES. Providers or clinicians who work for hospitals or facilities may choose to use their own digital contact or that of the hospital or facility by whom they are employed. See other questions in this document about the bulk data upload process for large organizations, including hospitals. 

31. Question. If an individual provider or clinician practices at multiple hospitals, facilities or practice locations, can they enter multiple digital contact addresses in NPPES, associated with their NPI?

• Response. Yes, NPPES allows providers or clinicians to add multiple digital contacts for multiple practice locations. Each endpoint listed by the provider should be associated with a practice location that is listed on the NPI record. Also, if the endpoint is associated with an organization, the provider clinician may add the organization information on the NPI record when adding the digital contact information.

Back to top

Bulk Upload, Reviewing and Updating Digital Contact Information in NPPES

32. Question. How does an organization update digital contact information for multiple providers, clinicians or medical professionals in one file or submit a bulk update for digital contact information?

• Response. Large organizations with many providers or clinicians with NPIs who wish to conduct a bulk upload or update of provider digital contact information will be able to do so through the Electronic File Interchange (EFI) process. CMS has developed an enhancement that will allow for bulk updating of digital contact information in NPPES. The EFI process will allow only the digital contact information to be updated without impacting the rest of the record in NPPES, and no additional data fields will need to be updated for each individual provider or clinician. The bulk upload functionality is now operational in NPPES.

33. Question. Where can a provider review and verify their digital contact information in NPPES?   

• Response. Information in NPPES is publicly accessible via both an online search option and a downloadable database option. Providers may review and confirm their digital contact information in several web locations, including: the NPPES NPI Registry at https://npiregistry.cms.hhs.gov, the NPPES NPI Registry API at https://npiregistry.cms.hhs.gov/registry/help-api, or the NPPES Data dissemination file at https://www.cms.gov/regulations-and-guidance/administrative-simplification/NationalProvIdentStand/DataDissemination . Each source currently contains all the information that will allow providers to determine the correctness of their information (85 FR 25583).

34. Question. Is it possible for a provider practice to maintain one digital contact (e.g., DoctorOffice@direct.office.net) to accommodate the transfer of electronic health information for all of the practitioners providing services within the group, such that NPPES for each practitioner within the group, and the group’s NPI would reflect the same digital contact?

• Response. Yes, it is possible for a provider practice to maintain one digital contact, however the practice may need to implement workflows to accommodate a process for accurately transferring electronic information to individual providers. For more information on how information is captured in NPPES, we encourage providers to review information available on the NPPES website at https://nppes.cms.hhs.gov/webhelp/nppeshelp/HEALTH%20INFORMATION%20EXCHANGE.html (85 FR 25584).

35. Question. What should a provider enter in the digital contact field if their organization does not have the capability to exchange information electronically? Can they share information through fax? 

• Response. A digital fax number is not considered a digital endpoint (85 FR 25583). For those providers who continue to rely on the use of fax-based modes of sharing information, we hope that greater availability of digital contact information will help to reduce barriers to electronic communication with a wider set of providers with whom they share patients. Ubiquitous, public availability of digital contact information for all providers is a crucial step towards eliminating the use of fax machines for the exchange of health information (85 FR 25581). CMS urged all providers to take advantage of this resource to implement Congress' requirement that the Secretary establish a digital contact information index. If a provider is not exchanging information electronically, and does not have a digital contact, the digital contact field would remain empty in their NPPES record, and they will appear on the public report of providers who do not have digital contact information in NPPES. The report will be updated once they have the capability to exchange electronically and update their digital contact information in NPPES (85 FR 25584).

Back to top

FAQs on Payer-To-Payer Data Exchange on FHIR-based APIs

Payer-to-Payer Data Exchanges

36. Question. Which payers are required to comply with and implement payer-to-payer data exchange requirements as finalized in the CMS Interoperability and Patient Access final rule?

• Response. Payer-to-payer data exchange requirements finalized in the CMS Interoperability and Patient Access final rule apply to MA Organizations, Medicaid Managed Care (MMC) Plans, CHIP Managed Care Entities, and QHP Issuers operating on the FFEs.[19] In an August 2020 letter to the State Health Officers, CMS strongly encouraged state Medicaid agencies and CHIP fee-for-service entities to accommodate such requests from beneficiaries.[20]

37. Question. What data are impacted payers required to send or receive under the payer-to-payer data exchange in the CMS Interoperability and Patient Access final rule?

• Response. Impacted payers are required to exchange, at a minimum, the data es and elements included in the content standard adopted at 45 CFR 170.213, which is (version 1 of the United States Core Data for Interoperability (USCDI)[21],) for data with a date of service on or after January 1, 2016[22] and that are maintained by the payer.  Payers only have to prepare an initial historical set of data (date of service on or after January 1, 2016) for sharing via the payer-to-payer data exchange policy. If certain USCDI information is not maintained by the payer, the payer is not obligated to seek out and obtain the data.[23]  The requirement to exchange this data applies beginning January 1, 2022.

38. Question. How many years of data must payers exchange at an enrollee’s request? For how long after disenrollment are payers required to exchange an enrollee’s data at their request?

• Response. Payers are required to exchange data they maintain with a date of service on or after January 1, 2016.25 Payers are required to send this data to the new payer identified by the enrollee for up to 5 years after disenrollment.[24]

39. Question. Are impacted payers required to implement and use a FHIR-based (Fast Healthcare Interoperability Resources) application programming interface (API) to meet the requirements of the payer-to-payer data exchange?

• Response. Impacted payers are not required to develop, implement or use an API for these payer-to-payer data exchanges and are permitted to use other methods of electronic exchange of this (USCDI) data.[25]  While impacted payers are not required to implement and use a FHIR-based API to meet the requirements of the payer-to-payer data exchange, CMS encourages these payers to consider this method of data exchange to meet the requirement. CMS understands the benefit of having these data exchanged via FHIR-based APIs and supports stakeholder efforts to do so.    
  • In addition, we note that the required data elements, if maintained by the payer and available to the patient through the Patient Access API (also required in the final rule), will be prepared in a FHIR format by these impacted payers. Because the Patient Access API is facilitating the exchange of the USCDI, some of the work to develop an API to exchange these data and the work to map the relevant USCDI data should already be completed by July 1, 2021.

40. Question. When an enrollee changes health plans and requests their health records be transferred from their previous payer to their current payer, is the previous payer required to send the records to the current payer?

• Response. If the previous payer is an impacted payer (MA Organizations, MMC Plans, CHIP Managed Care Entities, and Issuers of QHPs operating on the FFEs), there is an obligation to send the USCDI data, if maintained, to the individual’s current payer.  As finalized in the Interoperability and Patient Access final rule, impacted payers must, with the approval and at the direction of a current or former enrollee or the enrollee's personal representative, send at a minimum, the data es and elements included in the content standard adopted at 45 CFR 170.213 to any other payer that currently covers the enrollee or a payer the enrollee or the enrollee's personal representative specifically requests receive the data.22 When responding to a request to send data to a new payer, impacted payers need only send data received from another payer in the electronic form and format it was received.[26] As stated in the final rule, payers would not be asked to receive paper records from a payer and then share those paper records with another payer in the future at the patient’s direction.  If the payer received a patient’s (electronic) information via an API, the payer must share it via an API if the payer they are sending it to has the capacity to receive it (85 FR 25567).

41. Question. When an enrollee changes health plans and requests their health records be transferred from their previous payer to their current payer, is the current payer required to accept these records?

• Response. If the current payer is an impacted payer (MA Organizations, MMC Plans,  CHIP Managed Care Entities, and QHP Issuers operating on the FFEs), there is an obligation to maintain a process for the electronic exchange of, at a minimum, the data es and elements included in the content standard adopted at 45 FR 170.213 (version 1 of the USCDI), and to receive such data for a current enrollee from any other payer that has provided coverage to the enrollee within the preceding 5 years.[27] Such information received by the impacted payer must be incorporated into the organizations current payer’s records about the current enrollee.[28]

42. Question. May a current payer translate non-FHIR enabled data received from a previous payer into a FHIR-enabled format and make those FHIR resources available to a subsequent payer? Is the impacted payer required to do this translation?

• Response. The Interoperability and Patient Access final rule does not require impacted payers to translate information received from a prior payer under the payer-to-payer data exchange requirement. If a payer received data in a non-FHIR format (e.g., PDF document), the payer is not required to prepare that data to be shared through a FHIR-based API. Payers are only required to send (USCDI) data received under the payer-to-payer exchange in the electronic form and format it was received.29 However, a payer may translate data it maintains to be sent via a FHIR based API if that payer chooses to do so, and may send that data to a new payer if that new payer has the capacity to receive it (85 FR 25567).
  • While the May 2020 payer-to-payer data exchange policy does not require use of an API or translation to or overall use of a FHIR format starting in January 2022, CMS encourages payers to consider using available technology resources to exchange data. For example, the required data elements maintained by the payer (other than those received from another payer) are, under the Patient Access API requirements of the final rule, required to be converted to a FHIR format and shared via the Patient Access API (by July 1, 2021). As these data will already be prepared to be shared in a FHIR format for the Patient Access API requirements, payers may realize some efficiencies by building and maintaining a FHIR-based API to meet payer-to-payer data exchange requirements as well. For additional information, please refer to DaVinci's website: https://confluence.hl7.org/display/DVP/CMS+Final+Rule+Questions+and+Answers+log.

43. Question. If data has been received from a prior payer in a format other than FHIR, may the data be exchanged by a separate method or made available through a FHIR Document Reference resource?

• Response.  The Interoperability and Patient Access final rule requires payers to send data received from another payer in the electronic form and format it was received.29 If the payer received a patient’s information via an API maintained by the receiving payer, the payer must share the data via an API if the payer they are sending it to has the capacity to receive it.  Finally, as discussed in the final rule, these regulations do not require a payer to receive paper records from a payer under this policy and then in turn share those paper records with another payer if requested by the patient (85 FR 25567). 

44. Question. May an enrollee request that data be exchanged between two (or more) concurrent payers, for example, between a MA dual eligible special needs plan and a Medicaid managed care plan?

• Response. Yes. In the final rule, we stated the requirement would support dually eligible individuals who are concurrently enrolled in MA plans and Medicaid Managed care plans (85 FR 25565). At any time the enrollee is currently enrolled in the MCO and up to 5 years after disenrollment, the payer may send all USCDI data to any other payer that currently covers the enrollee or a payer the enrollee or the enrollee’s personal representative specifically requests receive the data. Furthermore, the data is to be sent in the electronic form and format it was received.[29] The enrollee may request this payer-to-payer exchange just once or more frequently. We did not propose, nor finalize any requirement for continuous data exchange (85 FR 25568).

45. Question. Does the final rule allow payers impacted by the payer-to-payer data exchange requirements to accept another payer’s requests for a payer-to-payer data exchange on behalf of a member? Can a health plan be considered the enrollee’s personal representative for the purpose of payer-to-payer data exchange?

• Response. The requirement(s) for payer-to-payer exchange apply only to certain impacted payers:  MA organizations, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs. There are currently scenarios where payers can exchange data without a request, such as for payment and health care operations,[30] but the CMS Interoperability and Patient Access final rule (CMS-9115-F) imposes a requirement for certain impacted payers to send, at a current or former enrollee's request (or at the request of a personal representative), specific information they maintain with a date of service on or after January 1, 2016 to any other payer identified by the current enrollee or former enrollee.[31] CMS noted in the final rule that when we discussed patients, we acknowledged a patient's personal representative.[32] Per the Health Insurance Portability and Accountability Act (HIPAA) privacy regulations at 45 CFR § 164.502(g), a personal representative is someone authorized under state or other applicable law to act on behalf of the individual in making health care related decisions (such as a parent, guardian, or person with a medical power of attorney). Policies in this final rule that require a patient's action could be addressed by a patient's personal representative. However, a health plan cannot be considered an enrollee’s personal representative. 

Back to top

HHS is committed to making its websites and documents accessible to the widest possible audience, including individuals with disabilities. We are in the process of retroactively making some documents accessible. If you need assistance accessing an accessible version of this document, please reach out to the guidance@hhs.gov.

DISCLAIMER: The contents of this database lack the force and effect of law, except as authorized by law (including Medicare Advantage Rate Announcements and Advance Notices) or as specifically incorporated into a contract. The Department may not cite, use, or rely on any guidance that is not posted on the guidance repository, except to establish historical facts.