Question 1

When do payers need to exchange data with other payers?

Accepted Answer

When an inactive member has moved to another health plan, the member can request for their data to be exchanged with their current health plan. All payers must have a process in place for members to make this request, as well as the mechanism to send and receive data at their request.

Question 2

Why is a Provider Directory API important?

Accepted Answer

Creating a publicly available and comprehensive Provider Directory means that all in-network provider information is kept in one place. With regular updates, this open resource will promote transparency, accessibility, workflow efficiency and continuity of care. In addition, the consistent FHIR format enables interoperability, promoting seamless data flow between health systems.

Question 3

Why is Payer to Payer Data Exchange important?

Accepted Answer

Enabling the sharing of member information between payers helps keep clinical data (USCDI v1) for individual patients together while they switch between health plans. This creates a comprehensive picture of their health that will open new opportunities for improving care.

Question 4

What data needs to be included in the Provider Directory API?

Accepted Answer

All CMS-regulated payers must include the following information: 
Provider names and network status
 • Addresses
 • Phone numbers
 • Specialities
MA’s that include a Medicare Advantage prescription drug plan (MA-PD), must also include the following information within a pharmacy directory: 
 • Pharmacy name
 • Address
 • Phone number
 • Number of pharmacies in the network
 • Type of pharmacy

Question 5

What requirements do providers within my network have to follow?

Accepted Answer

1. All individual health care providers, facilities, or practices must make available their Digital Contact Information. Just as payers need to provide an updated Provider Directory API, providers must maintain digital contact information in the National Plan and Provider Enumeration System (NPPES) updated.
2. Eligible clinicians, hospitals and CAHs in the Promoting Interoperability Program must enable Public Reporting and Information Blocking. To enforce this, CMS will publicize a list of all providers who submit a “no” response to any of the three Prevention of Information Blocking Attestation statements under the Medicare FFS Promoting Interoperability Program. Providers will have 30 days to contest this prior to publication.
3. Hospitals, including Psychiatric, and Critical Access Hospitals (CAHs) must enable Admission, Discharge, and Transfer (ADT) Event Notifications. Hospitals with EHRs will be required to alert providers when their patients are admitted, discharged, transferred or receive any services in the ED. This will improve coordination of care.

Question 6

How will the new health plan know which health plan to contact in order to reach out and obtain a member’s previous health data? For example, will there be a directory of health plan endpoints?"

Accepted Answer

Currently the process for requesting data must be defined and implemented by each payer. A new payer should receive information from the member regarding their old health plan to help facilitate the data exchange. That said, CMS is working to identify ways to create an accessible, complete and accurate directory that includes endpoints. They are currently having listening sessions and conducting outreach on this topic.

An upcoming proposed CMS rule “Reducing Provider and Patient Burden by Improving Prior Authorization Processes, and Promoting Patients’ Electronic Access to Health Information” (CMS-9123-P), suggests that the Payer to Payer exchange will occur at the time of member enrollment and be expanded beyond just clinical (USCDI v1) data. This rule is not yet final; based on the proposed rule it is expected to take effect on January 1st, 2023.

Question 7

What are the benefits of enabling Payer to Payer Data Exchange?

Accepted Answer

1. Interoperability: The seamless exchange of member data between payers enables the creation of an up-to-date and comprehensive patient record. This improves administrative and healthcare efficiency by reducing turnaround times, and facilitating care coordination and transitions between systems. Ultimately, this leads to:
 • Improved patient care
 • Reduced administrative burden
 • Greater industry potential
2. Patient Empowerment and Improved care: Previously siloed data will now be able to flow seamlessly between payers upon member request. This puts patients in charge of their own information and therefore in control of the future of their personal health. The Payer to Payer Exchange API enables data to follow individual patients across disparate health plans, ensuring that no information is lost. Examples of meaningful data flow:
 • When a patient ages into Medicare
 • When a patient changes health plan
 • When a patient is dually-eligible for both MA plans and Medicaid managed care plans
 
This patient continuity allows for a comprehensive picture of an individual’s health. This also facilitates informed decision-making, where a patient can choose which health plan to enroll with. Patient empowerment ultimately enables individuals to more effectively manage their own health, care and costs. Together, improved data flow, patient continuity, and empowerment improve health care outcomes.
 
3. Reduced Administrative Burden: The increased automation enabled by the use of a specialized Payer to Payer Data Exchange API reduces the administrative burden for both payers and providers. For payers, work and cost-efficiency is improved. For providers, high-quality coordinated care is made possible.
 
4. Broader Industry Potential: Payer to Payer Data Exchange is built on top of the Patient Access API rule. This means that years of health care data, that was made available through the Patient Access API, can now be exchanged between payers and enable:
 • Minimization of burdens Cost reduction
 • Transparency between payers and patients, who can access the same information within the same time-frame
 • Creation and maintenance of a comprehensive health record
Together, these will broaden industry potential. It will be possible to introduce analytical capabilities through which both payers and providers can gain valuable insights that will ultimately open new frontiers in health care.

Question 8

What are the benefits of enabling a Provider Directory API?

Accepted Answer

1. Interoperability Improves Workflow Efficiency and Reduces Provider Burden:
The FHIR format enables interoperability, promoting seamless data flow between health systems. Having data in a consistent format also reduces provider burden. Providers can easily identify and access other in-network provider information, like: 
 • Provider type 
 • Specialty
 • Contact information
 • Whether they’re currently accepting new patients 
All of this facilitates referrals, transitions of care, and care coordination across providers covered by the same health plan. This ultimately improves workflow efficiency and patient care. 
 
2. Accessibility Enables Patient Empowerment:
With provider information all in one place, the content itself is also regulated: health plans must make all provider data adhere to the standard FHIR-format and publish the directory on their website. This ensures accessibility, continuity, and transparency. As a result, patients are empowered with information: current or prospective users can more easily identify which providers are covered by which payers, enabling them to make informed decisions about which health plans they want to be enrolled with. 
 
3. API Enables Third-party Applications that Meet Individual Care Needs:
The benefit of making provider information available on an API is that third-party developers can build off of the provider data to create apps for the benefit of health plan user needs. For example, an app can help prospective health plan users compare in-network providers by identifying available specialties, hours of operation, and languages spoken. This then enables individuals to choose which health plan they want to enroll with. Connecting users to providers, apps can more efficiently meet individual health care needs.

Question 9

Why is the Cloud better for implementing the CMS Rule?

Accepted Answer

Today, 83% of healthcare institutions are using the Cloud for apps.
Cloud-based servers have high uptime guarantees, optimal security, and require low implementation and maintenance effort. With single tenant or managed offering, and API access for internal usage, health plans can have full access to the system with direct account access to all databases. There are no compromises for this access as payers are the owners of the data. The cloud enables scalability with data from hundreds of customers, including large health plans with millions of members.
Cloud implementation has more benefits compared to utilizing servers on-premises:
1. Security: tested by hundreds of developers, it’s not dependent on local networking and it is resilient to DDOS
2. Low cost: it costs less as a service because there is no need for on premises hosting or management
3. High Speed: it’s quicker to deploy, provides better performance and scalability, and smoothly implements new features

Question 10

Why is the Cloud better for implementing the CMS Rule?

Accepted Answer

Today, 83% of healthcare institutions are using cloud for apps. 
 
Cloud-based servers have high uptime guarantees, optimal security, and require low implementation and maintenance effort. With single tenant or managed offering, and API access for internal usage, health plans can have full access to the system with direct account access to all databases. There are no compromises for this access as payers are the owners of the data. The cloud enables scalability with data from hundreds of customers, including large health plans with millions of members.
 
Cloud implementation has more benefits compared to utilizing servers on-premises:
 
1. Security: tested by hundreds of developers, it’s not dependent on local networking and it is resilient to DDOS
2. Low cost: it costs less as a service because there is no need for on premises hosting or management
3. High Speed: it’s quicker to deploy, provides better performance and scalability and smoothly implements new features

Question 11

If I use a FHIR-based API to implement the Payer to Payer Data Exchange, what are some best practices for payers and developers sharing and receiving patient data?"

Accepted Answer

CMS created a Best Practices for Payers and App Developersd(https://www.cms.gov/files/document/best-practices-payers-and-app-developers.pdf)ocument, which provides links to useful information and best practices to help you build and maintain a FHIR-based API, as well as best practices for payers and third-party app developers.

Question 12

What are some best practices for payers and developers sharing and receiving patient data via FHIR-based APIs?

Accepted Answer

CMS created a Best Practices for Payers and App Developers (https://www.cms.gov/files/document/best-practices-payers-and-app-developers.pdf)document, which provides links to useful information and best practices to help you build and maintain a FHIR-based API, as well as best practices for payers and third-party app developers.

Question 13

How does Payer to Payer Data Exchange differ from Patient Access?

Accepted Answer

https://static.wixstatic.com/media/undefined

Question 14

Are there implementation guides payers can refer to when developing Provider Directory APIs?

Accepted Answer

CMS has provided the Da Vinci PDEX Plan Net IG (http://www.hl7.org/fhir/us/davinci-pdex-plan-net/history.html)implementation guide (IG) for the development of  the Provider Directory API. While use of this IG is not required, it is highly recommended that payers leverage IGs when developing their APIs to avoid duplicative efforts. CMS has been working with HL7 (https://www.hl7.org/)and other industry partners to ensure such resources are freely available to payers.

FAQs for Provider Directory CMS interoperability Rule

Read the most frequently asked questions on how to meet compliance for the Provider Directory API mandate under the CMS Interoperability Final Rule

Frequently Asked Questions