CMS’s final rule expands patient access to their health information and requires hospitals to alert community providers when one of their patients is admitted, transferred, or discharged.

CMS under Administrator Verma has honed in on improving interoperability with a strong focus on easing patients’ ability to access their electronic data. The final rule requires certain payers (as detailed below) to provide patients with access to their claims data, similar to the Blue Button 2.0 program, and requires a number of actions by providers to improve interoperability. CMS emphasizes that this is only a first step to advance interoperability and patient access; they will be taking additional steps in the future.  To view the full CMS final rule, please visit

Electronic Patient Event Notifications

Starting in May 2021, a new CMS Condition of Participation (CoP) requires Medicare and Medicaid participating hospitals (including psychiatric hospitals and critical access hospitals (CAHs)) to send notifications to certain providers of a patient’s admission, discharge or transfer.  Specifically, hospitals must send notifications of a patient’s inpatient, emergency department, and observation admission/registration, transfer, and discharge (notifications for transfers within an inpatient admission are not required but must occur from outpatient to inpatient).

Hospitals must send notifications to the following recipients, as applicable, for the purposes of treatment, care coordination, or quality improvement purposes.  However, hospitals can send notifications to other providers and entities including payers.

  • the patient’s established primary care practitioner or group;
  • Post-acute care service providers and suppliers with whom the patient has an established care relationship prior to the admission or to whom the patient is being transferred or referred; or
  • other practitioners, groups or entities, identified by the patient as primarily responsible for his or her care.

Hospitals, or an intermediary that facilitates exchange of health information on their behalf, can tailor the delivery of notifications based on the preferences of the receiving provider (i.e. the provider only wants to receive discharge notifications).  A hospital can exclusively use an intermediary if they desire to meet the CoP notification requirement, however the intermediary must connect to a wide range of recipients and not impose restrictions on which recipients are able to receive notifications (i.e. the intermediary cannot limit the delivery of notifications within a specific integrated delivery system).

If the hospital and patient are not able to identify a provider to share the notification with, the hospital is not required to send a notification for that patient.  CMS expects hospitals to have policies and procedures in place to identify the provider(s) who should receive a notification and incorporate this information into the notification system, or through recording information received from patients about their providers.

To demonstrate compliance with this requirement a hospital must show its system:

  • is fully operational and complies with all applicable law and patient’s expressed privacy preferences regarding sending notifications;
  • is capable of using HL7 2.5.1 (other standards can be used to support the notification system, but it must at a minimum support 2.5.1 to conform with the CoP);
  • the notification must include the required minimum patient health information but CMS does not require specific content, format or transport standards for the notification;
    • The name of the patient;
    • The name of the treating provider; and
    • The name of the sending institution.
  • sends notifications at the time of the patient’s admission/registration to the hospital and either immediately prior to or at the time of the patient’s discharge and/or transfer from the hospital; and
  • the hospital must demonstrate that it has made a reasonable effort to ensure that the system sends the notifications to required providers for treatment, care coordination, or quality improvement purposes.

The notification requirement will be enforced through the survey and certification process.  Prior to the effective date of the requirement in May 2021, CMS will issue interpretive guidelines to surveyors on how they should determine compliance with the notification requirement.

Payer Patient Application Programming Interface (API) Requirements

By January 1, 2021, CMS requires Medicare Advantage (MA), Medicaid (both FFS and managed care), CHIP (both FFS and managed care), and Qualified Health Plans (QHPs) in the Federally-Facilitated Exchanges (FFEs) to deploy APIs that can share patients data with any third-party app of their choosing.  CMS will delay enforcement of this requirement until July 1, 2021.  Payers generally must share data as requested by the patient, unless the payer conducts a security analysis (that uses objective and verifiable criteria) and determines connecting to the app via the API presents an unacceptable level of risk to the security of PHI in transit or in the payer’s systems.

CMS requires payers to make publicly accessible documentation that outlines how their API works and how others can access data through it.  The API must use FHIR Release 4.0.1 along with a number of associated implementation guides.

CMS requires payers to make the following data available, at a minimum, via the API using a combination of the U.S. Core Data for Interoperability (USCDI), HIPAA Administrative Simplification transaction, and Part D e-prescribing transaction standards.  Data must be made available within one business day after a claim is adjudicated or encounter data is received.  Payers must make data available they maintain that has a date of service on or after January, 1, 2016.:

  1. adjudicated claims (including costs, provider remittances, and enrollee cost-sharing);
  2. encounters with capitated providers;
  3. clinical data, including laboratory results (when maintained by the payer); and
  4. Formulary or preferred drug lists (except for QHPs in the FFEs).

Payers must establish and maintain routine testing and monitoring of the API to ensure it is functioning properly. Payers must post-education materials on their website to help patients understand the implications and possible risks of sharing their data with third-party apps.  CMS will provide sample educational materials to assist payers in meeting this requirement.  Payers can request that third-party apps attest to certain requirements, but must do this consistently for all apps.  Even if a third-party app does not attest, the payer still must connect to it but can inform patients that the app did not attest and advise them to reconsider using it.

Payer Provider and Pharmacy Directory API Requirements

By January 1, 2021, MA, Medicaid (both FFS and managed care), CHIP (both FFS and managed care), must make publicly available via a FHIR based API provider directory data that contains, at a minimum, information on a payer’s network of contracted providers, including names, addresses, phone numbers, and specialties.  CMS will delay enforcement of this requirement until July 1, 2021.

MA plans that offer Medicare Part D Plans must also make publicly available via a FHIR based API, pharmacy directory data, including the pharmacy name, address, phone number, number of pharmacies in the network, and mix (specifically the type of pharmacy, such as “retail pharmacy”).

For both requirements the payer must update its directory within 30 calendar days after it receives an update to information contained in the directory.

Payer to Payer Data Exchange

Starting January 1, 2022, CMS requires MA, Medicaid and CHIP managed care plans, and QHPs in the FFEs, to (with the approval and at the direction of the patient) share their data with another payer.  Payers must respond to requests from a patient to share their data, up to five years after their coverage ends. Covered payers that receive this data must incorporate it into their system.  The USCDI version 1 is the minimum data set payers must exchange to meet this requirement.  Payers must make data available that has a date of service on or after January, 1, 2016.

Payers can note which data being exchanged was received from a previous payer.  Payers are under no obligation under this rule to update, validate, or correct data received from another payer.  They also do not need to seek out and obtain data if they do not already have it.  A payer is only required to send data received under this payer-to-payer data exchange requirement in the electronic form and format it was received.

CMS allows payers to use multiple methods for the electronic exchange of this information, including use of APIs or an HIE. CMS notes that in future rulemaking they may consider requiring this payer-to-payer data exchange to occur via FHIR based APIs only.

Provider Digital Contact Information

CMS has updated the National Plan and Provider Enumeration System (NPPES) to capture the digital contact information of providers (e.g., Direct address, FHIR server URL etc.). Today it can be difficult to find the digital contact information of another provider. CMS hopes that adding this information to NPPES, which is a publicly available data source, will address this information gap. Beginning the second half of 2020, CMS will publicly identify providers who have not submitted digital contact information in NPESS.  CMS will release guidance later in 2020 outlining the public reporting mechanism and if certain providers will be exempt from public reporting.  CMS notes they may consider adding a reporting requirement in future MIPS rulemaking.


  • Payer Trusted Exchange Network Provision Removed: Based on public comment CMS did not finalize the proposal to require payers to participate in a trusted exchange network.
  • Information Blocking: Providers that attest a no response to certain information blocking attestations will be publicly reported. Eligible Clinicians (ECs) who report no in the MIPS program will be reported on Physician Compare and fail the Promoting Interoperability performance category. Hospitals and CAHs that attest no under the Medicare Promoting Interoperability Program will be listed on a CMS website and fail to be meaningful users and face the associated negative payment adjustment. The 2019 EHR reporting period will be the first year this provision is applicable, and information on providers who attest no will be posted in late 2020.
  • Increased Medicare-Medicaid Data Sharing Frequency Requirements: To support the administration of benefits to Medicare-Medicaid dually eligible patients, CMS requires Medicaid agencies to participate in the daily exchange of “buy-in” data with CMS and to submit “MMA” data daily by April 1, 2022.


Access the PDF Version Here


About Audacious Inquiry and our Consultants

Audacious Inquiry (Ai) is an industry-shaping health information technology and policy company that provides bold solutions for connected healthcare. Nationally recognized in its work to facilitate health data interoperability, Ai is a trusted partner to CMS, ONC, state Hospital Associations and Medicaid agencies across the country; and, delivers a SaaS technology platform that is the catalyst for health information exchange across 13 states. By pioneering technology that enables statewide health information exchange, Ai is raising the bar for how health data is shared, managed, and protected.



Our Strategic Advisory practice offers consulting services to government entities, HIOs, providers, and payers/ACOs in the areas of:

  • Health IT Policy
    Market research and evaluation, legislative and regulatory analysis, and guidance for industry compliance
  • Road-mapping & Advisory
    Health IT evaluation and guidance to support long-term objectives and Delivery System Reform

Further questions? Please contact Kory Mertz at:



Kory Mertz
As the Director of Policy at Ai, Mr. Mertz is a subject matter expert in state and federal health IT policy, interoperability, Meaningful Use and the Quality Payment Programs.  He is experienced at interpreting federal regulation and programs, including Meaningful Use and the Quality Payment Program, and translating that knowledge into actionable steps and strategies for clients.   

He has led work for Office of the National Coordinator for Health IT (ONC) to develop a strategy to measure the adoption and use of standards and to identify the health IT needs of Accountable Care Organizations.  Mr. Mertz supports a health system in meeting Meaningful Use and the Quality Payment Program. He has also provided subject matter expertise to CRISP to develop a strategy to connect all skilled nursing facilities in the state to the HIE.   

Prior to joining Ai, he worked at ONC for six years in a variety of roles helping to launch and execute the HITECH Act.  While at ONC, Mr. Mertz was deeply involved in the State Health Information Exchange Program helping to lead its implementation.  He also frequently worked with the Health Information Technology Policy Committee.