Interoperability and Patient Access Final Rule: Are You Compliant?

As with many government mandates, the Interoperability and Patient Access final rule (CMS-9115-F) has clear overarching goals. But the details of what’s involved and how to implement it can be confusing. Here’s the intent: to give patients access to their health information in a manner that’s easy for them to use it. That means healthcare interoperability so the patients can not only access their medical records and health information, but also share it with other clinicians and third party applications. This final rule was published May 1, 2020, and is taking effect this year. It’s one piece of the government’s focus on addressing healthcare data requirements under the 21st Century Cures Act, which was signed into law in 2016.

Who is affected?

• Do you have patients covered with Medicare Advantage?
• Do you have patients covered by Medicaid?
• Do you have patients covered with CHIP?
• Do you have patients covered by Qualified Health Plan (QHP) issuers on the federally-facilitated exchanges (FFEs)?
• Are you a healthcare provider working with the above plans? Affected providers include hospitals, healthcare clinics, ambulatory surgery centers, group practices, pharmacists and pharmacies, laboratories, therapists and physicians.

If yes, you need to comply. The government is using the regulation authority of the Centers for Medicare and Medicaid Services (CMS) to liberate patient data.

What is the context?

The Interoperability and Patient Access final rule was developed by CMS and the Office of the National Coordinator for Health Information Technology (ONC). It’s one portion of a two-prong interoperability effort in healthcare. CMS is in charge of enforcing the provider portion, which is the main discussion topic here. The other prong is the Interoperability, Information Blocking and ONC Health IT Certification Program, aimed at payers, healthcare information technology developers, health information networks and exchanges. We’ll discuss that a little as well, as it does impact providers, but they are not the main target.

What are you required to do – and by when?

If you fall under the Interoperability and Patient Access final rule’s umbrella, here’s what you are required to do, and the timeline:

Patient Access API: You must make patient healthcare claims and clinical information available through standards-based APIs (HL7 FHIR), for the coverages mentioned above. Deadline: January 1, 2021, but not enforced until July, 2021

Provider Directory API: You must make standardized information about provider networks available through a published provider directory API. Deadline: January 1, 2021, but not enforced until July, 2021

Payer-to-Payer Data Exchange: When patients request that you send their clinical data (that is included in the U.S. Core Data for Interoperability (USCDI) version 1 data set) to other CMS payers, you must do so. (That data aligns with what’s expected in the ONC’s sister rule, explained below). Deadline: January 1, 2022

Admission, Discharge and Transfer Event Notifications: Hospitals must send event notifications about admission, discharge and transfers to other providers. Deadline April 30, 2021 

Penalties

While penalties for violating the ONC’s final rule are up to $1 million per violation, that penalty is for information blocking by health information technology developers, networks and exchanges.

What is information blocking?

Information blocking is a big part of the ONC’s interoperability effort. It’s worth discussing here because it affects providers too. Information blocking is the practice of interfering with access, exchange, or use of electronic health information, except when covered by an exception. Under the new rules, patient information must be shared with patients, other healthcare providers, third-party systems, and APIs when appropriately requested. If the information is not accessible and reasonably should have been, this could be considered information blocking.

A clinician or healthcare organization can be liable for information blocking if only allowing access to a lab report for a certain number of days, for example. Or by disabling the use of an electronic health records’ ability to share information with other system users.

Interoperability data sets

As previously mentioned, the USCDI standardized health data classes covered by information blocking was specified, and is in effect from November 2020 until May 2022. After that date, all electronic health information will be included. The current USCDI data set includes high-level clinical data for:

• Allergies
• Assessment and plan of treatment
• Care team
• Clinical notes
• Goals
• Health concerns
• Immunizations
• Labs
• Medications
• Demographics
• Problem list
• Procedures
• Provenance
• Smoking status
• Unique device identifiers for implants
• Vitals

There are eight exceptions to the information blocking provision and what’s included. If certain conditions are met, those exceptions include:

• Preventing harm: If the actions are reasonable and necessary to prevent harm to a patient or another person. For example, the data is inaccurate or the data misidentifies the patient.
• Privacy: Protecting an individual’s privacy. The American Medical Association details the exception in more depth.
• Security issues: Protecting the electronic health information security.
• Infeasibility: If the request is not feasible. An example is the healthcare organization is in the midst of an uncontrollable event, whether natural disaster or other public health emergency or telecommunications interruption.
• Health IT performance: If the overall IT system’s performance would be degraded or temporarily unavailable as a result of fulfilling the request, it may not be considered information blocking.
• Fees: Fees can be charged to access or use the electronic health information, and this is not considered information blocking.
• Content and manner: The content and manner shared can be limited, under certain conditions.
• Licensing: The organization can license interoperability elements to meet the requirements.

And while not one of the eight exceptions, clinicians still need to follow state or federal laws concerning medical records releases first. This falls under “certain conditions” being met.

Stakeholders

As with many aspects of healthcare IT, there’s a wide group of stakeholders who need to be involved in understanding and complying with the regulations. That includes providers, legal, compliance, privacy/security officers, medical records staff, interoperability experts, clinical leadership, and third party vendors.

Do you have a plan?

Unfortunately, there is no off-the-shelf software for compliance. Healthcare organizations can see this as an obligation or an opportunity. Our recommendation is to see it as the latter, to see the possible gains from data-driven innovations. Increasingly, data will help healthcare organizations compete for patients, and help them operate more efficiently and effectively.

Using or migrating to cloud can help in complying with these new regulations, and improving interoperability. Cloud implementation allows for AI insights, and there’s no need to go through third-party vendors to use your own data. You’ll have access to what you need, and you own the data.

Maven Wave is working with healthcare organizations to ensure they are compliant through the use of a solution built on Google Cloud that implements the open data standards of FHIR. Step one involves ingesting data such as access claims, payment & clinical data via API, ETL, and interface engines, into Google Cloud. Then Maven Wave can transform that data by mapping source data into FHIR resources and align vocabularies and concepts. The final step in this stage is to validate that the transformed data complies with FHIR profiles, value sets, and more. 

The next stage is to store and manage data with FHIR standards. Healthcare organizations can start reconciling data by blending data together to form a single longitudinal view. Then, Maven Wave can help track the provenance of data and operational reporting of pipelines. Finally, you’re able to store data in the FHIR server and provide REST API access at scale.

The final stage is to serve and receive data as FHIR. First, our team helps securely enable oAuth2, OpenID Connect, and constrain FHIR resource access. Then, we serve API Proxy to enable data access constrained by SMART scopes. Finally, you are able to register apps that connect through APIS & collect consent. From there, healthcare providers are set-up to compliantly run apps in the cloud.

Maven Wave has a proven history helping healthcare organizations with cloud and interoperability solutions using Google Cloud. Please contact us to learn more about how we can help your organization comply and innovate.