Thought Leadership Blog. Click a post title below to open it.

From the Desk of Shreya Patel-CMS Prior Authorization Proposed Rule


This month, CMS released their long-awaited proposed rule on Prior Authorization, Provider Access API, and Payer to Payer Exchange.

Initially released in December 2020, CMS proposed an expansion of the Patient Access Final Rule. As a reminder, the CMS Patient Access Final Rule required certain Federal payers to share clinical and claims information they maintained with their enrollees or beneficiaries through the use of open APIs and mobile applications. The expansion to this rule would have built upon the open API infrastructure that payers put in place for the patient access component. This would be achieved by allowing providers to have access to the same information patients would through a Provider Access API. In addition, payers would be required to share information with other payers as their enrollees or beneficiaries changed plans or had concurrent enrollment. Lastly, through the new Prior Authorization API, CMS urged payers to release information to patients, providers, and new payers on prior, current, pending, and denied prior authorization requests. This rule had a set compliance date of 2023, but it was never finalized after many voiced concerns surrounding the ability for payers to meet this deadline. Further, there was much ambiguity on the payer to payer exchange, which required drafters of the proposed rule to revisit.

As mentioned, this month CMS decided to retract the prior proposed rule and release a new one, which would cover the same topics listed above—and more. Below, we have included our condensed fact sheet on important portions of this rule.

Prior Authorization API

CMS proposed to expand on Patient Access API to include a process for sending and receiving Prior Authorization.


  • What information must be made available via Patient Access API
    • All prior authorization requests and decisions for items and services (excluding drugs) for which the payer has data
    • Prior authorization status
      • Whether the decision is still pending, active, denied, expired, or in another status
    • Date the prior authorization was approved or denied
    • Date or circumstance under which the authorization ends
    • Items and services approved
    • Quantity used to date under the authorization
    • Any materials that the provider sends to the payer to support a decision
    • Specific reason for denial
  • Implement and maintain a FHIR Prior Authorization Requirements, Documentation, and Decision API (PARDD API)
  • Automate the process to determine whether a prior authorization is required for an item or service
  • Query the payer’s prior authorization documentation requirements and make those requirements available within the provider’s workflow
  • Support an automated approach to compiling the necessary data elements to populate the HIPAA-compliant prior authorization transactions and enable payers to compile specific responses regarding the status of the prior authorization, including information abut the reason for a denial
  • Respond to prior authorization requests within one day
  • Require impacted payers to publicly report certain metrics about their prior authorization processes for transparency (aggregated, deidentified)


  • CMS proposed payer share the same information about prior authorization requests and decisions with a patient’s provider via the Provider Access API and via the Payer-to-Payer API, and of course PARDD
  • What this does not apply to:
  • Drugs of any type that could be covered by an impacted payer, including, for example, outpatient drugs, drugs that may be prescribed, drugs that may be administered by a provider, or drugs that may be administered in a pharmacy or hospital
  • How long must they be available:
  • In the Patient Access API as long as the authorization is active and at least one year after the last status change

Provider Access API

CMS gives providers access to the same information patients get access to in the Patient Access API (includes USCDlv1 and all Prior Authorization decisions).


  • Requirement only for providers in payer’s network
  •  Information required:
    • Claims and encounter data
    • All data classes and data elements included in a content standard adopted at 45 CFR 170.213 (USCDI v1) such as Immunizations, Procedures, and Assessment and Plan of Treatment
    • Only if the payer “maintains” that information
    • Prior Authorization information for one year prior
    • No provider remittance information requirement
  • Educational materials to provide for Patients
    • Benefits of provider Access API
    • Their opt out rights
    • Instructions for opting out and opting in after opting out
    • Non technical, easy to understand
    • Public, available at all times on website
  • Educational materials to provide for Providers
    • Resources about Provider Access API
    • Process for requesting patient data from payer using API
    • How to use attribution process to associate patients with the provider
    • Provide through payer website and other modes of communication

Differences between this and Patient Access API:

  • Patient requests through health application, provider requests through EHR practice management system or other technology solution for treatment purposes
  • No provider remittances or cost sharing shared on Provider Access API
  • Proposing to require the FHIR Bulk Data Access Implementation Guide
  • If a provider does not have a provider agreement or is not enrolled with a payer that holds their patient’s data, the payer would not be required to provide patient data to this provider under this proposed rule
  • HIPAA interpretation-would this exchange be considered a healthcare transaction? Although the proposals would facilitate sharing claims data from payers to providers, the transmission would not be subject to HIPAA transaction standards because the purpose of the exchange would not be to request or issue a payment.

Other Proposals:

  • Patient Attribution
    • Acknowledged HIEs here-and guided payers to utilize these to not recreate the wheel. Utilize HIEs for patient attribution
  •  Opt Out Patients have an option to opt out of provider access API, whatever process that may be. Payer to Payer will be opt in.
  • The encourage granular opt out
  • Cited that opt out models are linked with significantly higher HIE utilization and maturation
  • CMS stated, “we also note that the HIPAA Rules permits health plans to disclose PHI, without an individual’s authorization, to providers via the Provider Access API for certain permitted purposes under the HIPAA Rules, such as, for example, treatment, payment, or health care operations”

Payer to Payer Exchange

Require existing payers to send a patient’s information to a new payer for a certain number of years after they leave the plan via API or to provide to individuals with concurrent coverage. This is meant to create a longitudinal record that follows the patient as they go from payer to payer.


  • Same data classes for the Patient Access API
  •  OpenID Connect authorization and authentication protocols to authenticate identity of payer requesting access
  • FHIR Bulk Data Access (Flat FHIR) used for exchanging multiple patients’ data at one time
  • Allow patients to opt INTO payer to payer exchange (with previous and current payers) prior to start of coverage
  • Cannot be used as reason to delay an applicant’s eligibility for start of coverage
  • Only can request enough information to identify and make successful request
  • Opt in is to identify the appropriate payers using the patient as the source of truth, it is not an opt in to share health information that is able to be shared without patient authorization
  • Require the requesting payer to include an attestation with the request for the data affirming the patient has enrolled with the payer and opted in to payer to payer exchange
  • Information with Payer to Payer must be incorporated into the patient’s record with the new payer as longitudinal record
  • For concurrent coverage, exchange patient’s data available to each other every quarter at a minimum; data retention requirements are not impacted
  • Patient education information requirements
  • Non technical, simple
  • On ability to opt in or withdraw opt in and instructions
  • Require to provide before requesting permission for payer to payer
  • Only must provide to those currently enrolled in plan-but available publicly on website (seems contradictory)
  • Must be provided annually

Information Required

  • USCDI version one
  • Adjudicated claims and encounter data (not including provider remittances and enrollee cost-sharing information)
  • Prior Authorization decisions
    • While patient will be required to resubmit prior auths under a new payer, this will help will efficiency

Important Points:

  • This is a one time share, not an ongoing share
  •  Patients can request subsequent data if they choose for other situations


  • Make request no later than one week after the start of the coverage
  • One business day turnaround time for other requests if an impacted payer receives a request from another payer to make data available for former patients who have enrolled with the new payer or a current patient has concurrent coverage
    • This is if they have been authenticated and demonstrated opt in

Requests for Information

  1. Barriers to adopting standards, and opportunities to accelerate the adoption of standards, for social risk data (e.g. housing and food insecurity)
  2.  How CMS could leverage APIs (or other technology) to facilitate electronic data exchange between and with behavioral healthcare providers
  3. How Medicare FFS could support improved medical documentation exchange between and among providers, suppliers, and patients
  4. How using data standards and electronic health records and prior authorization can improve maternal health outcomes
  5. How to encourage providers and payers to enable exchange under TEFCA to make patient information more readily available for access and exchange in a variety of circumstances

From the Desk of Shreya Patel-HHS & SAMHSA Proposed Rule Update from MiHIN

On November 28, 2022 the Health and Human Services Department (HHS) and the Substance Abuse and Mental Health Services Administration (SAMHSA) released a proposed rule for 42 CFR Part 2 information (Part 2 Information).

Part 2 information is information that comes from a facility regulated by 42 CFR Part 2 and is federally defined as an entity that 1. Receives federal funding and 2. Holds itself out as an entity primarily concerned with the treatment of substance use disorders.

The proposed rule would increase care coordination for treatment purposes, aligning Part 2 sharing more closely with the Health Insurance Portability and Accountability Act (HIPAA), while simultaneously increasing patient protections to avoid discrimination.

In terms of decreasing barriers to share, the proposed rule would allow generalized, one- time consents for HIPAA Privacy Rule purposes and re-disclosures in accordance with HIPAA. As a reminder, the HIPAA Privacy Rule allows sharing for treatment, payment, and healthcare operations.

In terms of strengthening patient protections, the new rule would give patients explicit rights to obtain an Accounting of Disclosures and expand restrictions on disclosures in civil, criminal, administrative, and legislative hearings.

This change has been long-awaited by Part 2 facilities and other in the health information exchange space, both of which are actively working to appropriately coordinate care for individuals who visit these facilities. This new rule is a large step in the right direction to prevent siloed behavioral health information and put in place practical rules to govern sharing of health information.

MiHIN & Native American Heritage Month

Native American Heritage Month
Health disparities among Native Americans are vast and persistent. Interoperability can help close that gap.

Michigan is home to 12 federally recognized tribes–with approximately 200,000 tribal members in total. Data show that Native American communities face inequity in health care and health status compared to other U.S. populations, including disproportionately higher rates of disease and shorter life expectancy.

The issue doesn’t end there – there are overarching challenges that further exacerbate the lack of access to care for American Indians, including the inability to accurately and seamlessly share digital health information, incomplete and fragmented data, and care processes that are siloed and not shared across boundaries. The bottom line: we must generate improved, more equitable health outcomes for Native populations in the state.
To account for the health disparity data gap, the Michigan Health Information Network (MiHIN), began working with the tribes in Michigan to establish culturally relevant, interoperable, health information exchange opportunities.

Under the leadership of Krystal Schramm, “Miskwa Mishiki Que – Red Turtle Woman,” descendant of Little River Band of Ottawa Indians Tribe, Senior Technical Business Analyst, the MiHIN team met one-on-one with tribes across the state to learn about each tribe’s respective patient populations, cultural needs, tribal clinics and clinical workflows and have been working with tribes to initiate utilization of the health information exchange dataflows to receive data for tribal patients from both tribal and non-tribal facilities.

Additionally, the MiHIN team has been collaborating closely with tribal clinic administrators and key tribal stakeholders to bridge the gap between tribal and non-trial entities in the State of Michigan, including the Michigan Department of Health and Human Services, the Inter-Tribal Council of Michigan, MPHI, Indian Health Service, tribal government officials, the Michigan Tribal Health Directors’ Board, and the Healthcare Information and Management Systems Society Michigan Chapter (HIMSS).

As a member of the Native community herself, Schramm was acutely aware that tribal populations have historically been underrepresented in public health data — and the resulting lack of support available when making decisions regarding tribal healthcare, both at the individual patient level and at clinic and system-wide levels.

Due to the fact that each of the 12 federally recognized tribes in Michigan are sovereign nations, the tribal healthcare system is inundated with piecemeal, disconnected and inconsistent data that leads to poor quality care, delays and no usable personal health record. By enabling the flow of data through the MiHIN network, health information can be shared quickly and seamlessly between systems, therefore establishing order and structure in the digital health ecosystem.

To date, eight of the 12 tribes and the Urban Indian Health Center have signed the necessary legal and technical agreements to join the statewide network of health information exchanging entities. By enabling the flow of data through the MiHIN network, health information can be shared quickly and seamlessly between systems, thereby increasing efficiency, improving patient care and safety and, ultimately, improving health equity amongst Native populations.

By nearly any measure, health care for Native Americans lags behind other U.S. populations. Facilitating a seamless interoperability between systems will provide patients and health professionals alike with real-time access to quality data. Increasing tribal representation in healthcare data will ultimately lead to improved health equity, outcomes, and patient satisfaction for tribal patients. More inclusive data equals better health equity.

To learn more about MiHIN or its work with Michigan’s Native American tribes, visit our website or contact Krystal Schramm at krystal.schramm@mihin.org.