Healthcare Analytics, Population Health Management, Healthcare Big Data

Tools & Strategies News

CMS Sets Rules, Cautions Penalties for Information Blocking, APIs, FHIR

CMS and the ONC have released a highly anticipated proposal outlining the future approach to information blocking, the use of FHIR, and the role of APIs in interoperability.

Information blocking, FHIR, APIs, interoperability

Source: CMS

By Jennifer Bresnick

- CMS and the Office of the National Coordinator have released long-awaited proposed rules governing interoperability, health data blocking, the use of APIs, and the expanding role of FHIR.

Just ahead of the 2019 HIMSS Convention in Orlando, CMS has outlined the definitions for what constitutes information blocking – a hotly debated topic since the passage of the 21st Century Cures Act (Cures Act) in 2016 – and what actions will be excepted from enforcement and stringent penalties.

“These proposed rules strive to bring the nation’s healthcare system one step closer to a point where patients and clinicians have the access they need to all of a patient’s health information, helping them in making better choices about care and treatment,” said HHS Secretary Alex Azar in a press release.

“By outlining specific requirements about electronic health information, we will be able to help patients, their caregivers, and providers securely access and share health information. These steps forward for health IT are essential to building a healthcare system that pays for value rather than procedures, especially through empowering patients as consumers.”

The proposed rules also include new certification criteria for health IT tools, including the use of application programming interfaces (APIs) and the Fast Healthcare Interoperability Resources (FHIR).

READ MORE: 21st Century Cures Act Rekindles Information Blocking Debate

“ONC is responsible for the implementation of key provisions in Title IV of the 21st Century Cures Act that are designed to advance interoperability; support the access, exchange, and use of electronic health information; and address occurrences of information blocking,” CMS explains in the rule.

“This proposed rule would implement certain provisions of the Cures Act, including Conditions and Maintenance of Certification requirements for health information technology (health IT) developers, the voluntary certification of health IT for use by pediatric health providers, and reasonable and necessary activities that do not constitute information blocking.”

The key provisions of the regulation combine to create a much more well-defined framework for health IT vendors to follow as they work to improve the flow of data across disparate systems in support of big data analytics, population health management, and value-based care.

Information blocking provision and list of exceptions

The bulk of the proposed rule focuses on information blocking, also known as data blocking, which has been a top concern for regulators since the beginning of the decade.

The Cures Act requires that a health information developer “not take any action that constitutes information blocking,” CMS says.  However, the parameters of information blocking were not well defined in the landmark legislation, leaving the details up to HHS to define.

READ MORE: Are Pending ONC Health Data Blocking Rules More or Less a Moot Point?

After much industry input and debate, the agency is proposing that information blocking is any action that:

  1. Except as required by law or covered by an exception set forth in subpart B of this part, is likely to interfere with, prevent, or materially discourage access, exchange, or use of electronic health information; and
  2. If conducted by a health information technology developer, health information exchange, or health information 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
  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.

There are seven categories of exemption to this definition which would not incur the monetary or civil penalties threatened for purposeful withholding of data.

Preventing harm – if an action has a well-founded believe that withholding data exchange is “reasonable and necessary” to prevent physical harm to an individual, the entity may refuse to release information.  The decision must be an implementation of an existing organizational policy or must be based on an individual assessment of risk in the case at hand.

Promoting privacy and promoting security of EHI – The dual categories of privacy and security speak to widespread confusion over the interplay between data exchange and HIPAA.  Actors may implement practices that safeguard the privacy and security of EHI according to existing legislation, such as HIPAA, and may address material security risks.

Recovering costs reasonable incurred Actors may charge fees for the release of EHI as long as the fees are uniform, related to the costs of providing access (i.e. copying fees), and are not based in any anti-competitive criteria, such as angling for patient retention.

READ MORE: FHIR Takes Off as ONC Teases Upcoming Data Blocking Definitions

Licensing of interoperability technologies – An entity that controls the flow of information will not be accused of information blocking as long as it licenses its interoperability elements at reasonable and non-discriminatory rates.  This protects health IT vendors, industry collaboratives, HIE organizations, and others from penalties for modeling their business on moderating or enabling the movement of data.

Maintaining and improving health IT performance – Reasonable periods of network maintenance or upgrading will not constitute information blocking as long as the user of the tool or service agrees to the period of downtime.  This ensures that vendors and interoperability organizations can schedule necessary improvements without being accused of maliciously withholding data services.

Entities that engage in information blocking actions that do not meet these criteria for exception may be subject to significant penalties, CMS said.

“The information blocking provision defines and creates possible penalties and disincentives for information blocking in broad terms, while working to deter the entire spectrum of practices that unnecessarily impede the flow of electronic health information (EHI) or its use to improve health and the delivery of care,” the rule states.

“The information blocking provision applies to the conduct of health care providers, and to health IT developers of certified health IT, exchanges, and networks, and seeks to deter it with substantial penalties, including civil money penalties, and disincentives for violations.”

The proposal does not specifically chart out a penalty structure, noting that each information blocking case is likely to be unique in nature and will need to be assessed on its own merits.

Governing the implementation of APIs and promoting FHIR

Application programming interfaces form a core component of the ONC’s approach to interoperability and CMS’s focus on enabling patient access to personal health information.

The Cures Act mandates that organizations be able to exchange data “without special effort,” and health IT developers have embraced standardized APIs as a way to meet that directive.

While API functionality is already a part of the 2015 Edition Certified EHR Technology (CEHRT) criteria, the ONC is adding specific criteria for APIs to ensure uniform deployment.

The API Conditions of Certification include technical, security, and access requirements to promote data sharing for individual patients or multiple patients.

“The API technology would need to be able to establish a secure and trusted connection with apps that request data,” the ONC says in a fact sheet. “Additionally, these apps will need to be registered prior to connecting, which means apps would not be able to connect anonymously.”

“App registration provides API technology with the ability to safeguard against malicious apps attempting to gain unauthorized access to patient information through the API. API Technology Suppliers would not be allowed to use app registration as a reason to review specific apps. However, they would be permitted to run a process (no longer than five business days) to first verify the authenticity of an app developer associated with an app seeking to be registered.”

Central to the conditions is the use of FHIR to create a shared platform for development and a known technical framework for furthering API capabilities

FHIR will be the required standard for development – previously, the industry has embraced the standard on a voluntary basis.  The approach is already widely in use and has enjoyed strong support from the ONC.

The ONC has also outlined guidelines for charging for API services.  Actors will be allowed to charge API data providers reasonable costs to recoup expenses incurred to develop, maintain, and upgrade technology, and could also charge for “value-add” services such as software that can connect and interact with API tools.

However, entities are forbidden from charging any other fees associated with API use.

Moving Beyond the Common Clinical Data Set

While the Common Clinical Data Set (CCDS) has included much of the critical data used to support patient care, CMS and the ONC are eager to move beyond the basics of interoperability to support robust population health management and patient-directed healthcare.

ONC is proposing to remove the current definitions of the CCDS and replace them with the updated US Core Data for Interoperability (USCDI) definitions. 

“This will increase the minimum baseline of data classes that must be commonly available for interoperable exchange,” a fact sheet says.

The USCDI includes common and novel elements such as treatment plans, care team members, patient goals, health concerns, labs and medications, problems, procedures and smoking status.

It also includes clinical notes as well as metadata about the provenance of information (i.e. when it was created and by whom).

Developers will also be required to include pediatric-specific data elements, such as pediatric BMI measurements and head measurements for infants.

“ONC intends to establish and follow a predictable, transparent, and collaborative process to expand the USCDI, including providing stakeholders with the opportunity to comment on the USCDI's expansion,” the organization said.

The new proposals would also require electronic health record vendors to include a turnkey export function that allows healthcare organizations to export all their data to switch to a new vendor – and to allow a patient to export all of his or her data for personal needs.

“All EHI produced and electronically managed by a developer’s health IT must be readily available for export,” the agencies said.

The resulting files must be computable and must include supporting information to allow for the interpretation and use of the data.  This additional information must be available via a hyperlink.

While the rule contains few surprises, its release does allow the industry to let out an anticipatory breath and buckle down to ensuring that stakeholders meet the proposed criteria.

CMS and the ONC will be accepting public comment on the rule, and will use the annual HIMSS gathering this week to share more details on the proposals and their potential impact on health IT innovation and patient-centered care.


Join 25,000 of your peers

Register for free to get access to all our articles, webcasts, white papers and exclusive interviews.

Our privacy policy

no, thanks

Continue to site...