Interoperability has been a buzz word in healthcare for many years now. As a country, we have established the Office of the National Coordinator for Healthcare IT (the ONC) to institute programs and introduce new legislations such as, Meaningful Use and the 21st Century Cures Act. These and others have moved us forward towards a reality of interoperable healthcare data, in hopes of improving the quality of care, lowering costs, and improving patient and provider satisfaction. While progress has been made, much of healthcare’s data still lives is silos, is not easily accessible, and patients are not in control of their own data.
I for one, am excited to see the release of two companion rules on interoperability that both aim to break down those silos, releasing the data into the hands of those who need it most. In case you missed it, on March 9, 2020 the ONC and the Centers for Medicare & Medicaid Services (CMS) finalized two new interoperability rules. These rules represent a coordinated effort to allow patients and their designated representatives to access their health information electronically from both their providers and their insurers using common consumer technologies and without special effort.
I hope that you were able to tune into our recent webinar hosted by Fierce Health titled “The ONC/CMS Interoperability Rules – Start Now to Comply by the Deadlines” where I defined those terms according to the CMS. If you were not able to attend, I encourage you to watch it now, on-demand. During this webinar, Bob Hussey, Founder & Principal RGH Health Consulting, LLC, and I had the privilege of talking through the aggressive timelines and detailed requirements, especially focused on payers. We chose to focus on payers because so much of this is new to them. Remember that health IT vendors and providers have been working through meaningful use requirements for many years now. But rest assured the information shared about FHIR API’s and the United States Core Data for Interoperability (USCDI) applies across the healthcare spectrum.
Bob kicked off the presentation by talking us through the important legal details of these rulings making sure that we understood the nuances that have changed from the proposed rule to the final rule. First, Bob talked through the changes in the 2015 EHR certification criteria, and then turned to focus on the key concepts introduced in these rulings - information blocking. Information blocking, or really NOT participating in information blocking will be a turning point in interoperability and has the potential to truly unlock all of this data to be fully shared across the healthcare ecosystem. Finally, Bob highlighted the specific requirements called out in the CMS ruling that apply directly to the payer segment of healthcare. Requirements like a patient access API that allows patients to access their data or EHI (currently as defined by the USCDI) dating back to January 1, 2016 via a third-party app of their choice using the FHIR 4.0.1 standard.
With a solid foundation of the rules from Bob, I took the next section to dive deeper into the USCDI V1, the FHIR 4.0.1 standards, and how they work together to define the data that is mandated to be shared with patients and their designated representatives. In an effort to recap, let’s keep in mind that the intent of these rulings is to share data. First and foremost, it’s all about the data, more specifically, it’s all about sharing data with consumers using common consumer technologies like computers and smart devices and without special effort through the use of public facing, standards-based API’s (FHIR 4.0.1).
If you are asking yourself what kind of data that statement is referring to, that’s where the USCDI comes into play. Both rules talk about EHI. Initially EHI is defined as the data elements that are called out in the USCDI, things like clinical notes, allergies and intolerances, and medications. This definition applies to actors subject to the information blocking ban as defined in the ONC ruling. The data that payers are expected to share with their members includes the data classes as defined by the USCDI but also includes claims and encounter data dating back to January 1, 2016. Again, the FHIR API is the required standard used to make this data available.
So, what exactly is this USCDI and why is it so important? This document really sets the stage and defines the actual data that are required to be made accessible to members. You can think of a data class as the type of data to be shared grouped by common theme or use case. A data element is the most granular level of information to be shared, and there can be many data elements in a given data class. Data elements are the specific pieces of information that need to be available in your FHR based API. Digging even deeper, the USCDI identifies required and recommended terminology standards such as LOINC® , SNOMED CT®, and RxNORM to be used to enhance the exchange of data in an understandable and useable, interoperable format. After all, the end goal is to make this data accessible and useable by the consumer.
Preparing for the rules is often seen as a technical exercise that simply requires standing up a FHIR API and making data accessible to third party apps. Not so fast! That part is just the beginning. Each of the data elements listed in the USCDI can be represented by one or more FHIR implementation guides. Each FHIR implementation guide will call out multiple profiles that reference multiple terminology bindings, which may be well defined or leave room for interpretation. All of this will require careful thought and planning as you prepare to stand up a FHIR based API. You really do need to understand the underlying terminology and data to be successful in achieving the pinnacle of interoperability - semantic interoperability. I encourage everyone who is involved in readying your organization for meeting the requirements of these rulings, to think beyond the FHIR API.
One of our polling questions during the webinar revealed that most organizations are concerned about meeting both the technical FHIR requirements and the content and vocabulary requirements as spelled out in the USCDI.
Other things to consider as you prepare to meet the requirements of the ONC and CMS rulings include protecting the privacy of your patients and making the data understandable to them. Claims and encounter data is typically highly structured, recorded using standard terminology, and relatively easy to exchange. However, it is not easily understood by the average consumer. The standards use highly technical medical jargon that needs to be translated into common language to make it truly understandable by the consumer. Clinical data is not highly structured, nor is it recorded using standard terminology. Data that is not recorded in standards cannot be exchanged in meaningful ways. Having dealt with that data for many years now, I can confidently say that the data being sent between systems today, is none of the above. Believe it or not, we have seen over 500 different ways to capture the medication concept of aspirin in an EHR. Unless you map those 500 different terms to a common clinical standard like RxNORM, the data you send will not be understandable or useable to the member or receiving system.
While it is technically true that you do not have to map or translate this data for your members, it all comes down to what experience do you want them to have? Do you want the data to be confusing or understandable? Do you want to share complete information or only those fragments that are recorded in a standard, leaving so much rich clinical information unshared and unusable? You certainly want to protect your members most sensitive information following the guidance that federal, state, and local regulations require of you.
Health Language can not only help you standup that FHIR based API, we can help you in your long term vision of a great consumer experience as they access the data that you and your organization will be sharing with them. Visit our ONC/CMS resource page, or speak to an expert to learn how we can help you comply.
LOINC® is a registered trademark of Regenstrief Institute, Inc.
SNOMED CT® is a registered trademark of the International Health Terminology Standards Development Organisation (IHTSDO).
Reference: https://www.healthit.gov/isa/united-states-core-data-interoperability-uscdi
