ONC & CMS Interoperability Regulations: Part 2 – Health IT Vendors
John D’Amore, MS, President and Chief Strategy Officer
This is Part Two of a four-part series that will cover major implications of the March 2020 ONC and CMS regulations for interoperability. Each part highlights the impact of the regulations on one stakeholder group in the healthcare ecosystem: Health Insurers, Health Information Technology, HIEs/Patients and Providers. This installment covers the implications of the federal regulations for health IT vendors.
The major themes of these regulations are divided in sections below. While this isn’t a comprehensive summary of 1,700+ pages, it touches the most important considerations.
It’s All About Consumer Access to Health Information
Depending on their target markets, vendors must be aware of different requirements and timelines. Payer market vendors need to prepare for the near-term demand on their customers to provide member access to claims and clinical information with deadlines beginning as soon as January 1, 2021. Vendors that license technology to the health plan and insurer markets will see increased requirements for streamlining the flow of clinical information to complement claims information. Gartner has previously referred to this market as clinical data integration ( If development is not underway, new partnership strategies will be required to meet market needs. For more details on payer implications, refer to Part One (Link) of our series outlining the impact on payers and health plans.
After payers, health IT providers are next in terms of when they need to provide patient access according to ONC’s data access timeline. The ONC regulations require that certified health IT technology provide data access using the new application programming interface (API) standards by mid-2022. This timing supports subsequent requirements that clinicians and hospitals must empower patients to access their clinical information. While the exact date for providers to comply is ambiguous, by 2023 patients will have unprecedented access to their claims and clinical information through APIs.
FHIR R4 or Bust
Next, both CMS and ONC regulations settle the go-forward technical plan for how clinical and claims information will be shared. Both payers and providers are required to use the same interoperability standard, namely Fast Healthcare Interoperability Resources (FHIR), for data exchange. Specifically, they will need to use the most recent version of the FHIR standard (R4) and pair its usage with the US Core and CARIN Alliance BlueButton profiles for the standard. Since FHIR is an international standard and provides great flexibility, these profiles further constrain the standard in terms of what data classes are expected and what terminologies must be used. These specifications are important because they are designed to help avoid ambiguity that leads to lack of semantic interoperability, such as what we have experienced with C-CDA. If you haven’t already, begin to review these profiles here:
- US Core Profile 3.1.0 (which constrains FHIR R4): https://www.hl7.org/fhir/us/core/
- CARIN Alliance BlueButton profile (also on FHIR R4): https://build.fhir.org/ig/HL7/carin-bb/
Again, if a health IT vendor for the payer or provider market hasn’t already begun FHIR development, they are behind. Way behind. The timelines for health plans come first in 2021 and requirements for EHRs and other certified health IT product follow. Each of these data profiles and the accompanying terminologies open complex questions, such as how will Hl7v2 and C-CDA be effectively converted?
Defining the Data via USCDI
In addition, a new advisory body will continue to expand the list of required data classes and terminologies for use in standards. That group is called the US Core Data for Interoperability (USCDI). While USCDI does not have regulatory authority on its own, the ONC has made it clear that they will follow its guidance on the requirements for new data and streamline updates to the requirements using a new process. This process is called the Standard Version Advancement Process (SVAP), and it is included as part of the final rule. Essentially, it allows vendors and certifying bodies to update to more recent guidance without waiting 3 to 5 years for the federal government to catch up through regulatory action. Diameter Health leadership presented to the USCDI group in 2019 and if you have more questions, we are well-versed in the ways USCDI will affect data structure and codification.
Information Blocking is a “No No”!
The single largest portion (by page count) of the regulations deal with a concept introduced by Congress through the 21st Century Cures Act known as information blocking. Information blocking is defined as any “practice by a health care provider, health IT developer, health information exchange, or health information network that, except as required by law or specified by Health and Human Services (HHS) as a reasonable and necessary activity, is likely to interfere with, prevent, or materially discourage access, exchange, or use of electronic health information (EHI).” These regulations work to address many concerns in the health IT industry that vendors would make it costly or difficult to access EHI. While the nuances of the regulations are complex as there are multiple exceptions and restrictions on cost, the big picture is relatively simple. As a health IT vendor, you cannot charge whatever you want for access to data. Prices must be proportionate to costs. As a vendor or provider, you cannot block access to patient data so long as the person is authorized to access it. You can’t create a walled garden of permissible apps. While remaining secure, APIs need to be open to any app when someone has a right to the data. Next, pricing for data access must be a level playing field. Vendors cannot charge one app more than another app to access clinical data. And, fundamentally, patient access to their own data using the standards discussed previously should be free. These rules around information blocking apply primarily to certified health IT products and go into effect this year.
This will unlock information exchange from health information systems and EHRs over the coming years. It’s important to note that this flow is only required to be one-way, which is read-access. EHRs will not need to provide write access back to their systems, so this limits app usage in day-to-day workflow of clinicians. But read-access will be sufficient for a new app ecosystem to emerge among smartphones and other devices. Epic provided a preview of this using Apple’s Health Kit a few years back (https://www.apple.com/healthcare/health-records/); expect this type of data access to become universal in coming years.
Don’t Panic. Help Is Here
This regulatory mandate will require that your organization tap into expertise and the right tools for success – now.
Diameter Health can be a business partner for Health IT vendors to fulfill these needs, particularly around clinical data integration and FHIR based access. If you have HL7v2, C-CDA and other legacy data, we can translate them to newer standards. Plus, our data normalization and enhancement technology ensures that data are interoperable with downstream systems for multiple business processes. We know clinical data inside and out because Diameter Health has processed over one hundred million clinical documents and billions of data elements.
Now is the time to get the conversation rolling given the import of this rule. For more information, please reach out to Diameter Health (use the “Sign Up” form at the top right of this page and we’ll alert you to future posts) or listen to our virtual HIMSS 2020 sessions here: https://www.diameterhealth.com/virtual-himss20/