Interoperability– Everything You Wanted to Know

By November 24, 2020Interoperability

As the date for compliance with the Interoperability Rule draws closer, BluePeak answers all of your questions, to help you stay in the know.

1 Question:

I read the required implementation date of the Interoperability Rule has been delayed. Is that true? 

Answer: HHS recently announced it was delaying the implementation of the information blocking provisions of the 21st Century Cures Act final rule.  This announcement delays the implementation of the information blocking provisions only (i.e., provisions that impacted providers).  It does not delay the implementation of the Interoperability Rule, which requires health plans implement the Patient Access API and Provider Directory APIs, which CMS will start enforcing on July 1, 2021, and the Payer-to-Payer Exchange provisions, which are effective January 1, 2022.

2 Question:

Under the Interoperability rule, does CMS requires that a Plan make data available through the Patient Access API to members that are no longer enrolled in the Plan but were enrolled at some point?

Answer:  No, but you may wish to build the Patient Access API to be able to access the data of former enrollees so that you can leverage it for the Payer-to-Payer Exchange requirement (see below).

The Patient Access API requirements are covered by 42 CFR 422.119(a)-(e) and these requirements are effective January 1, 2021 (with enforcement discretion until July 1, 2021).  The Payer-to-Payer Data Exchange requirements are covered by 42 CFR 422.119(f) and these requirements are effective January 1, 2022.  42 CFR 422.119(g)-(h) applies to both the Patient Access API and Payer-to-Payer Data Exchange and (g) is effective January 1, 2021 (with enforcement discretion until July 1, 2021).

Medicare Advantage (MA) Plans must make the specified data available through the Patient Access API to current members (42 CFR 422.119(a) states: “A Medicare Advantage (MA) organization must implement and maintain a standards-based Application Programming Interface (API) that permits third-party applications to retrieve, with the approval and at the direction of a current individual MA enrollee or the enrollee’s personal representative, data specified in paragraph (b) of this section through the use of common technologies and without special effort from the enrollee”).

The Payer-to-Payer Data Exchange requirement is different.  There, MA Plans must, with the approval and at the direction of a current or former enrollee or the enrollee’s personal representative, electronically exchange the same specified data as set forth in the Patient Access API requirements as follows:

  • Receive all such data for a current enrollee from any other payer that has provided coverage to the enrollee within the preceding 5 years (So, MA Plans must receive data for current enrollees only);
  • At any time an enrollee is currently enrolled in the MA plan and up to 5 years after disenrollment, send all such 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 (so, MA Plans must send data for both current enrollees and for 5 years after disenrollment for former enrollees).

So, while the Patient Access API only requires MA Plans to make the data available for current enrollees, the Payer-to-Payer Data Exchange requirement (which must be implemented by 1/01/22 will leverage the same data set and presumably the same coding as the Patient Access API) requires you to send the data of former enrollees (up to 5 years after disenrollment) to another payer.  It may be wise to develop the Patient Access API to meet this requirement (i.e., make data available to current and enrollees who were formerly enrolled within the past 5 years) now.  That way, the MA Plan won’t have to address this part of the coding again to meet the data availability requirements for the 1/01/22 Payer-to-Payer Exchange.

3 Question:

Do the information blocking provisions of the HHS ONC Cures Act Final Rule apply directly to health plans?

Answer: No.  The information blocking provision applies to health care providers, health IT developers, exchanges, and networks.

The ONC Cures Act Final Rule provides the HHS interpretation of the information blocking definition as established in the Cures Act.

The Cures Act defines “information blocking” as a practice that…“is likely to interfere with, prevent, or materially discourage access, exchange, or use of electronic health information” AND: (i) if conducted by a health information technology developer, exchange, or network, such developer, exchange, or network knows, or should know, that such practice is likely to interfere with, prevent, or materially discourage the access, exchange, or use of electronic health information; or (ii) if conducted by a health care provider, such provider knows that such practice is unreasonable and is likely to interfere with, prevent, or materially discourage access, exchange, or use of electronic health information.” (see 42 USC 300jj-52(a)).

Likewise, the ONC Cures Act Final Rule (i.e., HHS’ interpretation of the Cures Act definition) defines “information blocking” as: “a practice that— (1) Except as required by law or covered by an exception…is likely to interfere with access, exchange, or use of electronic health information; and (2) If conducted by a health information technology developer, health information network or health information exchange, such developer, network or exchange knows, or should know, that such practice is likely to interfere with, prevent, or materially discourage access, exchange, or use of electronic health information; or (3) If conducted by a health care provider, such provider knows that such practice is unreasonable and is likely to interfere with, prevent, or materially discourage access, exchange, or use of electronic health information.”

4 Question:

How quickly must health plans make available formulary and pharmacy directory information through the Patient Access and Provider Directory APIs?

Answer: The answer varies for the type of information. 

Formulary informationThe final rule does not set forth a timeframe requirement for making updated formulary information available through the Patient Access API, though I’d recommend doing so as soon as administratively possible after the formulary is updated.

  • The governing regulation 42 CFR 422.119(b)(2) states that an MA organization that offers an MA-PD plan must make, among other things, the following information accessible to its enrollees through the Patient Access API: “Formulary data that includes covered Part D drugs, and any tiered formulary structure or utilization management procedure which pertains to those drugs.” (see pg. 25632 of the Final Rule).  Unlike the other data required to be included in the Patient Access API, for which the regulation sets forth – data point by data point – the timeframe in which each data point must be made available via the API (e.g., claims within one business day after the claim is processed, encounter data within one business day after the encounter is received, clinical data within one business day after it is received by the Plan, adjudicated claims for Part D drugs within one business day after the claim is adjudicated, etc.), there is no timeframe set forth in the regulation regarding the formulary data.
  • Pharmacy Directory informationThe final rule requires updated pharmacy directory information be made available through the Provider Directory API within 30 calendar days of the Plan receiving updated pharmacy directory information.
    • “As with the provider directory information, we are finalizing that pharmacy directory information must be updated no later than 30 calendar days after the MA organization that offers the MA–PD plan receives pharmacy directory information or updates to pharmacy directory information.” (see pg. 25560 of the Final Rule). 

5 Question:

How are plans are defining the clinical data that will be provided in the Patient Access API?  Are there any standards or minimum requirements the industry is using?

Answer: The Interoperability Final Rule requires that health plans include clinical data in the Patient Access API only if such clinical data is received and maintained as part of the health plan’s normal operations.  The Final Rule specifically mentions medical records and laboratory results as examples of such clinical data.  Health Plans are required to use the USCDI data set for all data included in the Patient Access API, including clinical data.  Plans should consult these standards when building their Patient Access API as they must include all of these data classes and data elements, if received and maintained as part of the health plan’s normal operations.

Some helpful links for more information on the USCDI data set, including clinical data:

  • The USCDI website that describes the data classes included in the USCDI data set at a high level
  • Further description of the data classes and data elements included in the USCDI data set

6 Question:

Under the Patient Access API, data must be made available no later than one business day after a claim is adjudicated. Our Part D claims are adjudicated by our PBM.  Our interpretation of this final rule is that the one business day referenced in the regulations starts when the Plan receives the Part D claims data from the PBM instead of the date the PBM adjudicated the Part D claim. Is our interpretation correct?

Answer: No.  The one business day referenced in the regulations starts on the date the PBM adjudicates the claims and not when Plan receives the claim data from the PBM.

The relevant regulation is 42 CFR 422.119(b)(1).  It states:

An MA organization must make the following information accessible to its current enrollees or the enrollee’s personal representative through the API described in paragraph (a) of this section:

(i) Data concerning adjudicated claims, including claims data for payment decisions that may be appealed, were appealed, or are in the process of appeal, and provider remittances and enrollee cost-sharing pertaining to such claims, no later than one (1) business day after a claim is processed;

(ii) Encounter data from capitated providers, no later than one (1) business day after data concerning the encounter is received by the MA organization; and

(iii) Clinical data, including laboratory results, if the MA organization maintains any such data, no later than one (1) business day after the data is received by the MA organization.

The regulation only permits encounter data received from capitated providers to be made available within one business day after the encounter is received by the Plan.  It does not apply that same standard to adjudicated claims.  Rather, adjudicated claims must be made available via the Patient Access API “no later than one (1) business day after a claim is processed.”  This means the one business day starts on the date the PBM adjudicates the claim.