A Guide to the ONC's
Final Rule and FHIR
Integration
Final Rule and FHIR
Integration
What is the ONC’s Final
Interoperability Rule?
Interoperability Rule?
In 2016, Congress passed the 21st Century Cures Act to drive electronic access, exchange, and the use of health data. The Cures Act breaks down barriers in the U.S. health system. It improves interoperability and unleashes innovation, allows patients better access to their health information, and reduces the burdens on payers and providers.
The ONC's Final Rule clarifies exceptions to information blocking while establishing new rules to prevent "information blocking" practices (e.g., anti-competitive behaviors) by healthcare providers, developers of certified health IT, health information exchanges, and health information networks as required by the Cures Act.
When data is able to flow more freely and securely between payers, providers, and patients, the healthcare system can hope to achieve more coordinated care, improved health outcomes, and reduced costs.
The rule focuses on changes in the existing health IT certification program. Specifically, the rule implements the interoperability provisions of the Cures Act to allow for seamless data exchange among providers, payers, and patients. The rule also holds health IT developers accountable as a condition of certification.
The ONC's key regulatory requirements – information blocking and information exchange via application programming interfaces (API) – will also apply to healthcare providers and healthcare information networks. To make sense of the final ruling, we have gathered and analyzed the needed data. First, we need to understand the concept of information blocking and who is affected by the rule. Then, we will demonstrate how the Fast Healthcare Interoperability Resources (FHIR) standard comes into play and highlight some key dates to remember. Let's dive in!
The ONC's Final Rule clarifies exceptions to information blocking while establishing new rules to prevent "information blocking" practices (e.g., anti-competitive behaviors) by healthcare providers, developers of certified health IT, health information exchanges, and health information networks as required by the Cures Act.
When data is able to flow more freely and securely between payers, providers, and patients, the healthcare system can hope to achieve more coordinated care, improved health outcomes, and reduced costs.
The rule focuses on changes in the existing health IT certification program. Specifically, the rule implements the interoperability provisions of the Cures Act to allow for seamless data exchange among providers, payers, and patients. The rule also holds health IT developers accountable as a condition of certification.
The ONC's key regulatory requirements – information blocking and information exchange via application programming interfaces (API) – will also apply to healthcare providers and healthcare information networks. To make sense of the final ruling, we have gathered and analyzed the needed data. First, we need to understand the concept of information blocking and who is affected by the rule. Then, we will demonstrate how the Fast Healthcare Interoperability Resources (FHIR) standard comes into play and highlight some key dates to remember. Let's dive in!
Information Blocking
Section 4004 of the Cures Act defines information blocking as a practice by a healthcare provider, health IT developer, health information exchange, or health information
network that is likely to interfere with, prevent or materially discourage access,
exchange, or use of EHI.
The Act specifies certain practices that may constitute information blocking:
network that is likely to interfere with, prevent or materially discourage access,
exchange, or use of EHI.
The Act specifies certain practices that may constitute information blocking:
- Imposing formal or informal restrictions on access, exchange, or use of EHI
- Implementing health information technology in ways that are likely to restrict the access, exchange, or use of EHI with respect to exporting complete information sets or in transitioning between HIT systems
- Discouraging efforts to develop or use interoperable technologies or services by exercising influence over customers, users, or other persons
- Discriminating individuals which leads to frustration and discourages efforts to reach interoperability
- Allowing rent-seeking and opportunistic pricing practices to make information sharing cost-prohibitive
Who is Affected by the Information
Blocking Regulations?
Blocking Regulations?
There are three categories of "Actors" who are regulated by the information blocking provisions:
- Healthcare providers (healthcare facilities, laboratories, pharmacies, physicians, etc.)
- Health information networks
- Health IT developers of certified health IT
When Must Actors Comply?
The information blocking compliance date is six months after the rule is published in the Federal Register (May 1, 2020). For the first 18 months after the compliance date, actors must only comply with the requirements with respect to the limited EHI identified by the data elements represented in the U.S. Core Data for Interoperability (USCDI). Consequently, actors will need to expand compliance to include the full scope of EHI captured by the definition in the Cures Act.
What Types of Information Blocking Could Incur Penalties?
Section 4004 identifies possible penalties for information blocking:
- Practices that restrict authorized access, exchange, or use under applicable state or federal law of such information for treatment and other permitted purposes under such applicable law, including transitions between certified health information technologies (health IT)
- Implementing health IT in nonstandard ways that are likely to substantially increase the complexity or burden of accessing, exchanging, or using EHI
- Implementing health IT in ways that are likely to:
- Restrict the access, exchange, or use of EHI with respect to exporting complete information sets or in transitioning between health IT systems
- Lead to fraud, waste, or abuse, or impede innovations and advancements in health information access, exchange, and use, including care delivery enabled by health IT
Who is Affected by the Rule?
To promote data sharing, Centers for Medicare & Medicaid Services (CMS) and ONC jointly released two proposed rules:
The CMS Rule applies to Medicare- and Medicaid-participating short-term acute care hospitals, long-term care hospitals, rehabilitation hospitals, psychiatric hospitals, children's hospitals, oncology hospitals, and critical access hospitals (CAHs).
The ONC's Rule applies more generally to payers, health IT vendors, patients & HIEs, and providers in the years ahead.
The CMS Rule applies to Medicare- and Medicaid-participating short-term acute care hospitals, long-term care hospitals, rehabilitation hospitals, psychiatric hospitals, children's hospitals, oncology hospitals, and critical access hospitals (CAHs).
The ONC's Rule applies more generally to payers, health IT vendors, patients & HIEs, and providers in the years ahead.
Payers
While most entities already maintain online member portals, the requirement to provide APIs so that members can access data through mobile apps may be challenging. Per the regulation, payors won't be able to limit the app usage in any way. The regulatory text clearly shows what needs to be provided to members: "The Patient Access API must include all of the specified clinical information for the enrollee maintained by the payer with a date of service on or after January 1, 2016." (CMS Page 105)
These APIs will use a new standard for data access called Fast Healthcare Interoperability Resources (FHIR, pronounced like "fire"). We will return to this in the next section. Using the FHIR standard, health plans will need to make specific types of information available, namely:
These APIs will use a new standard for data access called Fast Healthcare Interoperability Resources (FHIR, pronounced like "fire"). We will return to this in the next section. Using the FHIR standard, health plans will need to make specific types of information available, namely:
- adjudicated claims
- encounters with capitated providers
- provider remittances
- enrollee cost-sharing
- clinical data (including laboratory results)
The expectation is that information will be available the next business day after being processed by a health plan.
Health IT Vendors
Following payers, health IT vendors are next in terms of providing patient access. The rule requires that certified health IT technology provide data access using the FHIR 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, patients will have unprecedented access to their claims and clinical information through APIs by 2023. Both payors and vendors are required to use the FHIR standard for data exchange.
While the exact date for providers to comply is ambiguous, patients will have unprecedented access to their claims and clinical information through APIs by 2023. Both payors and vendors are required to use the FHIR standard 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.
the FHIR standard (R4) and pair its usage with the US Core
and CARIN Alliance BlueButton profiles for the standard.
The ONC has made it clear that health IT vendors will use the USCDI as the basis for establishing new data requirements as well as streamlining updates to the requirements using a new process – Standard Version Advancement Process (SVAP). It allows vendors and certifying parties to update to more recent guidance without waiting 3 to 5 years for the federal government to catch up through regulatory action.
The expectations of the health IT vendors and providers are quite strict:
And, fundamentally, patient access to their own data using the standards should be free. These rules around information blocking apply primarily to certified health IT products and go into effect this year.
The expectations of the health IT vendors and providers are quite strict:
- As a health IT vendor, you cannot charge whatever you want for data access – prices must be proportionate to costs.
- You cannot block access to patient data so long as the person is authorized to access it.
- Same as a payer, you can't create a list of "permissible apps."
- While remaining secure, APIs need to be open to any app when someone has a right to the data.
- Vendors cannot charge one app more than another app to access clinical data.
And, fundamentally, patient access to their own data using the standards should be free. These rules around information blocking apply primarily to certified health IT products and go into effect this year.
Note: Data access 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 the day-to-day workflow of clinicians. But read-access will be sufficient for a new app ecosystem to emerge among smartphones. For example, Epic provided a preview of this using Apple's Health Kit a few years back. Expect this type of data access to become prevalent in the coming years.
Patients & HIEs
HIE activity will largely continue as is in the short-term. The new requirements from the CMS regulation that requires hospital event notifications may spur some activity for HIEs, although many health systems are already far down the road of how to share alerts among physicians.
The new standards for the adoption of FHIR for information exchange should be on the dashboard of every HIE business executive but remain at least 2 years out for providers.
The critical national infrastructure of HIEs is one of the least affected groups by major federal regulations for interoperability. The reason behind this represents a new directional focus for the federal government, which has turned toward patient access to data.
The desired outcome is that pairing required APIs by health plans and providers with smartphones will substantially lower the barrier to adoption.
However, many industry participants voice concerns about this. Once an app has your health data on your phone, HIPAA no longer applies. That's why Epic expressed a serious concern that these apps may not meet the privacy or security expectations of patients.
The new standards for the adoption of FHIR for information exchange should be on the dashboard of every HIE business executive but remain at least 2 years out for providers.
The critical national infrastructure of HIEs is one of the least affected groups by major federal regulations for interoperability. The reason behind this represents a new directional focus for the federal government, which has turned toward patient access to data.
The desired outcome is that pairing required APIs by health plans and providers with smartphones will substantially lower the barrier to adoption.
However, many industry participants voice concerns about this. Once an app has your health data on your phone, HIPAA no longer applies. That's why Epic expressed a serious concern that these apps may not meet the privacy or security expectations of patients.
Providers
The ONC regulations provide a host of actions to make sure that EHRs can share more information using a FHIR standard between providers, payers, and patients. Apps will access patient medical data using FHIR, which will span across data requested from hospitals, ambulatory providers, and payers.
As we have mentioned in a note before, the regulations only require EHRs to output data – read-only access. Providers do not need to create write capabilities. Do you have an app that will help with medication reconciliation? It will be able to listen but can't speak back to your EHR. Do you have a new medical risk prediction algorithm? It will be able to fetch data to make predictions, but it won't be able to flag the patient in the EHR or share clinical decision support.
Although the Rule's impact is read-only, patients will be able to get their information on their phones and laptops and use third-party applications to visualize and understand that data.
Expectations at a glance:
As we have mentioned in a note before, the regulations only require EHRs to output data – read-only access. Providers do not need to create write capabilities. Do you have an app that will help with medication reconciliation? It will be able to listen but can't speak back to your EHR. Do you have a new medical risk prediction algorithm? It will be able to fetch data to make predictions, but it won't be able to flag the patient in the EHR or share clinical decision support.
Although the Rule's impact is read-only, patients will be able to get their information on their phones and laptops and use third-party applications to visualize and understand that data.
Expectations at a glance:
- EHR vendors will have to enable the export of electronic health information for a single patient's data
- Vendors will also have to enable an export of all patient records when a health care provider is switching health IT systems
- Patient's health records should be accessible from any platform at any time
EHR companies have 36 months to comply with that requirement.
Regulatory Benefits
For Patients
For Doctors & Hospitals
For Health IT Developers
Providing Access to Their Chart
in Novel and Modern Ways
in Novel and Modern Ways
Making Responses to Patient Data
Requests Easy and Inexpensive
Requests Easy and Inexpensive
Minimizing API Development
and Maintenance Costs
and Maintenance Costs
It gives patients more control of their health care and their medical record through smartphones and software. There will likely be disease- and condition-specific apps that offer patients complementary services (i.e., patient education, progress metrics, and community support)
Patients will be able to access their health data from EHRs using an app of their choice simply, without any additional action on the part of the provider other than the initial effort to enable the technical capabilities.
It makes significant effort to minimize development costs. The certified API requirements focus on standardized data sets, notably the USCD). Most major health IT developers, like Newfire Global Partners already have the necessary infrastructure (i.e., HL7 FHIR servers).
Protecting Patient Privacy and Security
Allowing Choice of Software
Respecting Intellectual Property
Industry-standard technical security requirements are a part of the certification. They enable patients to choose which data in their electronic medical record they authorize an app to receive. Providers and other stakeholders can instruct patients on privacy and security matters without implicating information blocking.
It allows providers to choose software that helps them improve care quality. They should be allowed to benefit from a competitive marketplace where the choice of software services lies with them and not a health IT developer.
Certified EHR developers are permitted to first negotiate agreeable terms in the open market for the licensing of their intellectual property (IP) that is needed for the access, exchange, and use of EHI. If they can't reach an agreement, developers can meet their regulatory obligations through specified alternative means. Health IT developers also may restrict certain communications under the Certification Program that include IP so long as the restrictions are no broader than necessary and meet other specified limitations.
Enabling the Ability to Shop for
Care and Manage Costs
Care and Manage Costs
Improving Patient Safety
Expands patient choice in health care through increased transparency about care quality and costs. To help the patient in making decisions, mobile applications will deliver all the information.
Permits the sharing of patient safety concerns arising from certified EHRs. Protects patients and others by recognizing practices that prevent the sharing and use of health data that may cause harm through the Preventing Harm Exception for information blocking. Supports improved patient matching through the exchange of the USCDI and its patient demographic data elements.
What to Expect From the Rule
Provider
Making Patient Data Requests Easy and Inexpensive
Modern technology allows clinicians and hospitals to easily provide patients with access to their information in a fully automated, low-cost manner. Patients will be able to access their health information from an app of their choice. Secure, standardized application programming interfaces (APIs) allow for this access without special effort on the part of the clinician.
Allowing Choice of Apps
Clinicians, hospitals, and health systems should be allowed to benefit from a competitive and vibrant app marketplace. The Rule calls for open APIs, which encourages secure access to data for applications. It also will help ensure these certified APIs are made available in a safe, secure, and affordable way. These APIs support innovation in the marketplace for health IT and app developers.
Implementation
While the Cures Act prohibits information blocking, it also defines which practices are reasonable and necessary activities that might otherwise be considered information blocking. ONC's Cures Act Final Rule establishes these exceptions to allow clinicians and hospitals common-sense operational flexibility, including protecting patient privacy and security as well as handling situations where moving data is technically infeasible.
Improving Patient Safety
The final rule aims for a thoughtful balance between patient and clinician needs. It encourages transparency around patient safety issues within health IT, while also attempting to protect the intellectual property rights of health IT developers who have made large investments in building user interfaces and workflows.
Patient
Ease of Access to Records
The rule supports a patient's control of their health care and their medical record through smartphones and modern software apps.
Protecting Patient Privacy and Security
The rule supports secure patient access to their electronic medical record data. Patients will be able to authorize and use applications to receive data from their medical records. OAuth 2.0 is used to authorize applications – the same highly secure protocol used on travel and banking apps.
Promoting the Ability to Shop for Care and Manage Costs
The final rule looks to expand patient and payer choice by increasing the availability of data that supports insights about care quality and costs. Much in the way apps have provided customer transparency in industries like travel and banking, they can be used within healthcare to deliver information to patients and payers to assist in making medical decisions.
Vendor
API Conditions of Certification Requirements
The ONC has established the API Conditions of Certification to address the use of APIs and the healthcare ecosystem in which APIs will be deployed, including health IT developers' business practices. The API Conditions of Certification only apply to the actions and behaviors of certified health IT developers and their certified API technologies.
HIE
The critical national infrastructure of HIEs is one of the least affected groups by major federal regulations for interoperability. The reason behind this represents a new directional focus for the federal government, which has turned toward patient access to data.
HIE's will pair required APIs by health plans and providers with smartphones to substantially lower the barrier to adoption.
HIE's will pair required APIs by health plans and providers with smartphones to substantially lower the barrier to adoption.
How does FHIR come into play?
In response to the Cures Act, the ONC has adopted a new secure and standards-based API certification criterion – HL7 FHIR. HL7 has been addressing these challenges by producing healthcare data exchange and information modeling standards for over 20 years. FHIR is a new specification based on emerging industry approaches, but informed by years of lessons around requirements, successes and challenges gained through defining and implementing HL7 v2, HL7 v3 and the RIM, and CDA.
But before understanding the new interoperability API standard, let's understand how APIs work.
But before understanding the new interoperability API standard, let's understand how APIs work.
What Is an API?
An application programming interface (API), is a "messenger" that works behind the scenes to help software or servers communicate with each other. Most of us have likely used APIs in our everyday lives without even realizing.
For example, every time you search for an airline flight, APIs are in use. Before APIs, one would have to visit various airlines' websites to compare prices. Now, third-party applications can aggregate flight information by connecting to the different airlines' information systems using unified "messengers", or APIs.
The ONC has established several technical criteria for certified APIs. In particular, they identified HL7 FHIR Release 4.0.1 as the foundational standard to support data exchange via API.
For example, every time you search for an airline flight, APIs are in use. Before APIs, one would have to visit various airlines' websites to compare prices. Now, third-party applications can aggregate flight information by connecting to the different airlines' information systems using unified "messengers", or APIs.
The ONC has established several technical criteria for certified APIs. In particular, they identified HL7 FHIR Release 4.0.1 as the foundational standard to support data exchange via API.
What Is HL7 FHIR?
FHIR is a framework standard that solves the interoperability challenges by increasing access to electronic health records and data sharing.
FHIR combines the best features from previous standards while also adding some improvements. Unlike HL7 standards, which were not freely available until 2013, the specifications for FHIR are free for use without any constraints.
With FHIR, care providers can access patient health records and export specific data such as medication history or vital signs records to email or other EHR systems.
Providers can also track what particular apps and data downloads their patients are using. Tracking this data via FHIR can offer healthcare providers insights ranging from what apps and data are most popular among their patients to detecting abnormal usage patterns and malicious activity.
With FHIR, care providers can access patient health records and export specific data such as medication history or vital signs records to email or other EHR systems.
Providers can also track what particular apps and data downloads their patients are using. Tracking this data via FHIR can offer healthcare providers insights ranging from what apps and data are most popular among their patients to detecting abnormal usage patterns and malicious activity.
Things To Consider Before Starting FHIR Integration
- Does your system or vendor support FHIR APIs?
- Does your vendor provide all the FHIR functionality?
- What's the time and cost of the FHIR implementation?
Pro tip: Many third parties may only partially implement FHIR. We encourage you to consult Newfire Global Partners and allow our expertise to solidify the data exchange requirements and de-risk your FHIR integration process.
Key Dates to Remember
Not sure about your future steps?
Fill out the form or write us an email and our representative will contact you directly
Newfire Global Partners, 210 Broadway Ste 201, Cambridge, MA 02139-1959
© All Right Reserved. Newfire Global Partners.
