Skip to main content
Skip to footer

Information Blocking

Patient with nurse

We all want the same thing – better care for patients.

Health information sharing depends on a fair and level playing field for patient information to be available when and where it's needed. For decades, Cerner has been a leading advocate in shaping policy for the unimpeded exchange of health information giving patients access to a digital, longitudinal health record.

Despite the great strides over the past decade of digitizing health care records, barriers remain in allowing the free flow and exchange of information. Consumers should have the right to access the health care information their providers have about them and dictate where they want it to go.

We can work together as an industry to improve data exchange for healthcare providers and their patients. Cerner enables more than 1B transactions through interoperable exchange from one entity to another. This includes HIE transactions, Hub, CommonWell, ePrescribe, and Direct Messaging. Cerner has been and continues to be a trusted leader of data security for more than 40 years. We are committed to protecting the privacy and security of patient data.

FAQs

What is Information Blocking?

Information Blocking is legally defined by the 21st Century Cures Act of 2016 as "a practice that – is likely to interfere with, prevent, or materially discourage access, exchange, or use of electronic health information (unless required by law or specified by the Secretary pursuant to rulemaking)." Information blocking is also legal and regulatory framework for how an individual or entity subject to the information blocking provisions (known as actors) should respond to and engage in providing access, exchange, or use of Electronic Health Information (EHI) upon an authorized request. There are three actor types subject to the information blocking provisions: health care providers, Health IT Developers, and Health Information Networks/Health Information Exchanges (HIN/HIEs).

The Office of the National Coordinator of Health IT (ONC) published a final rule called the 21st Century Cures Act: Interoperability, Information Blocking, and the ONC HIT Certification Program on May 1, 2020. In that final rule, ONC defined the actor types, provided examples of practices that implicate information blocking, and outlined eight reasonable and necessary activities that are exceptions to information blocking. If an actor meets the conditions of the exceptions, they are protected from being found in violation of information blocking on that issue/practice. If an actor does not meet the exception, it does not mean the actor is in violation of the information blocking provisions, it only means their practice is not protected by the exception in that instance.

Acts or practices that meet the statutory definition of information blocking and do not meet an exception may be information blocking. ONC and the HHS Office of the Inspector General (OIG) have indicated that information blocking violations require intent. Therefore, an actor will not be subject to enforcement of the information blocking provisions if the violation was an innocent mistake. OIG is the agency that has authority to investigate and enforce the information blocking provisions.

In short, no. While information blocking is a new legal and regulatory framework, information blocking works within the current legal and regulatory framework. For example, it does not override Federal or State privacy laws. Information blocking does not create any new rights to access, exchange, or use EHI. Information blocking also does not dictate how and when EHI must be provided. The exceptions to information blocking established by ONC define conditions or practices that if followed may result in an actor determining not to respond to a request without violating the information blocking prohibition.

Privacy is only one of the exceptions outlined by ONC under which a request can be denied. The exceptions outlined by ONC are divided into two categories: exceptions that involve not fulfilling a request for access, exchange, or use, and exceptions that involve procedures for fulfilling a request for access, exchange, or use. The first category contains five exceptions outlining a variety of reasons for which a request for access, exchange, or use of EHI can be denied. The second category outlines the procedures through which requests for access, exchange, or use of EHI should be fulfilled. These exceptions outline reasonable and necessary activities that should be allowed to continue even though some of the actions may violate the definition of information blocking. For this reason, claiming an exception should not be viewed in a negative light but should be viewed a way to enable an actor to continue to comply with other legitimate and reasonable restrictions and reasonable business practices.

The information blocking exceptions from ONC are a framework for actors to work within in how they handle requests for access, exchange, or use of EHI that they are likely already getting. Prior to information blocking there were some pre-existing requirements for health care providers that outlined when health information could be shared or must be shared, such as the Health Insurance Portability and Accountability Act (HIPAA). Information blocking is in many ways an extension of those current requirements and activities that many are already performing.

EHI stands for Electronic Health Information. The ability to access, exchange, or use EHI without unreasonable interference, prevention, or material discouragement is what is at issue in determining if there has been an act of information blocking. ONC defines EHI as: electronic protected health information (ePHI) as defined by HIPAA (at 45 CFR 160.103) to the extent that it would be included in a designated record set (DRS) as defined by HIPAA (at 45 CFR 164.501), regardless of whether the group of records are used or maintained by or for a Covered Entity as defined by HIPAA (at 45 CFR 160.103), but EHI shall not include: (1) Psychotherapy notes as defined in 45 CFR 164.501; or (2) Information compiled in reasonable anticipation of, or for use in, a civil, criminal, or administrative action or proceeding.

Based on the definition of EHI, understanding what a DRS is becomes very important to actors under information blocking. The DRS is basically any clinical and billing data that is used to make a decision about an individual patient and that is stored or maintained by the covered entity or on behalf of a covered entity. It is tied to that individually identifiable health information that is used for purposes of Treatment, Payment and Healthcare Operations (TPO) by a Covered Entity (or their Business Associates) under HIPAA. This is a concept that each Covered Entity needs to understand and define on their own for the purpose of HIPAA compliance. Based on the definition of EHI, understanding what a DRS is becomes very important to actors under information blocking. As a result of the DRS under HIPAA, health care providers have needed to have an understanding of the DRS and ePHI for years. The similarity of the definition between EHI and ePHI and the basis in DRS allows health care providers to potentially utilize many of the policies they have in place for compliance with HIPAA with some potential modifications.

HIT Developers and HIN/HIEs may not have created the same policies around what the DRS is prior to information blocking.

No, an actor does not need to fill out an application for the information blocking exceptions. Unlike certain quality programs, Promoting Interoperability (PI) programs, and some Alternative Payment Models (APMs), information blocking exceptions do not require an application. The exceptions for information blocking are similar to the safe harbors under the anti-kickback statute. If behaviors or acts meet the conditions of the exception, they are protected from being found to be information blocking violations if/when OIG were to investigate a compliant. In this way, actors would apply the conditions of the exceptions to their policies, procedures and business practices in order to use them but would not need to “apply” for the exception with any external regulatory authority. As a result, actors should review all the conditions of the exceptions as part of their information blocking assessments so the actors can determine if they need to alter any practices or policies to align with the conditions of the exceptions.

The USCDI is a standard set of health care data for which there is an underlying expectation that the data will be available for electronic access, exchange, or use when the data is stored electronically. The USCDI is expected to continually grow from version 1 until the USCDI is the rough equivalent of the Designated Record Set (DRS) under HIPAA and therefore roughly the same as the definition of Electronic Health Information (EHI) under information blocking. USCDI version 1 (v1) begins with the Common Clinical Data Set (CCDS) outlined in the original 2015 Certification Criteria Edition created by ONC in prior rulemaking by carrying forward all of the CCDS data classes and data elements. The 2015 Edition Certification Cures Updates expands on the CCDS base by adding new data elements to the patient demographics data class, modifying the medication allergy data class to be the allergies and intolerance data class which expands the data elements contained within that data class, and by adding two new data classes: clinical notes and provenance.

The USCDI v1 as defined by ONC for the purpose of certification and the conditions and maintenance of certification is bounded by certain content and nomenclature standards required by the Cures Act 2015 Edition certification criteria updates. This connection between standards and certification makes perfect sense when discussing CHIT. However, the USCDI is also a data set and list of health care data classes/elements unto itself that is not strictly bound by specific standards. When it comes to the USCDI's connection to information blocking, the USCDI is simply a set of health care data not bound by specific nomenclature, content, or transport standards. This is in part true because information blocking itself is not bound by standards as a regulatory concept. The information blocking provisions generally require actors to comply with authorized and appropriate requests for EHI in the manner requested and the manner by which EHI is requested may or may not be in a standardized format or structure. EHI may also not be stored electronically in any given standardized format or structure. ONC also repeatedly frames its reliance on the USCDI in the information blocking provisions as the EHI identified by the data elements of the USCDI. ONC never indicates the standards associated with those data elements are also required for information blocking.

For the first eighteen months of compliance with information blocking (April 5, 2021 through October 5, 2022), actors under the information blocking provisions do not need to comply with requests for the full set of EHI but rather only a limited set of health care data as outlined in the USCDI v1. During this eighteen-month period, the USCDI data set should be treated in the same manner that a request for the broader set of EHI would be treated on October 6, 2022 and after. This means that the requestor requesting access, exchange, or use of data in the USCDI data set can request the data in any manner that best suits the requestor 's needs. That could be a standardized format, a proprietary format, or a simple machine-readable format as long the format meets the requestor 's needs. As a result, the USCDI 's connection to information blocking is simply as a defined set of health care data.

To understand what is required for compliance with information blocking on April 5, 2021 through October 5, 2022, the best place to start is with the content and manner exception. The content and manner exception is one of the category of exceptions that involve establishing procedures for fulfilling requests for access, exchange, and use of EHI and it controls when the other two exceptions in that category are applicable. This makes the content and manner exception the key to understanding compliance with the exceptions when fulfilling requests and therefore provides excellent insight into what compliance looks like for information blocking at any point in time including on April 5, 2021.

The content and manner exception has two main conditions:

  • The content condition scopes the health information that actors are required to provide upon request.
  • The manner condition addresses how the EHI is made available. This condition enables actors to work with the requestor to determine the best format the parties can agree to for fulfilling a request.
The actor can use the content and manner exception to understand which requests should be fulfilled and the best manner in which to provide the EHI for the requests. This intent and use of this exception underscores that information blocking compliance is a request driven effort, and that if the actor centers their compliance focus responding to requests, the actor will generally be compliant. An actor does not commit an information blocking violation if they do not make EHI information available proactively absent a request for EHI. There are other compliance requirements outside of information blocking an actor should consider that do require proactive information sharing such as Promoting Interoperability (PI) and the Admission, Discharge, Transfer (ADT) notification requirements, but those carry their own compliance requirements. Aside from such requirements, the actor center their information blocking compliance efforts on waiting for a request for enabling access, exchange, or use of EHI.

For the first eighteen months after the compliance date for the information blocking provisions (April 5, 2021 through October 5, 2022), the content and manner exception scopes the content requests for information blocking to the USCDI v1 data set. For an actor to determine if there is a compliance risk for information blocking for the period of April 5, 2021 through October 5, 2022, it is important for the actor to know all of the manners and methods through which the USCDI data classes/elements can be provided upon request. This enables an actor to respond to requests for access, exchange, or use of the USCDI v1 data set.

If an actor cannot fulfill the request for EHI in the manner requested, the content and manner exception provides the actor the ability to fulfill the request in an alternate manner. Under the manner condition of the content and manner exception, an actor must comply with a request in the manner requested (assuming the request does not fall under another exception) unless the actor is technically unable to provide the EHI/USCDI in the manner requested or the actor and the requestor cannot reach agreeable terms to fulfill the request in the manner requested. In such a case, the actor can use the manner condition to offer alternate manners of providing the EHI by applying the following in order to identify the alternate manner used in a counter offer:

  1. Using technology certified to standards adopted by ONC in the Certification of Health IT (CHIT) program;
  2. Content and transport standards published by either the Federal Government or a Standards Development Organization (SDO) that is accredited by the American National Standards Institute (ANSI); or
  3. In an alternative machine-readable format, which would need to include the ability to interpret the EHI.

Any of these alternate manners would need to be agreed to by the requestor.

If an actor cannot fulfill the request using any of the alternate manners, the actor should consider the infeasibility exception. The actor can deny a request under the infeasibility exception-based on three conditions:

  • Uncontrollable circumstances,
  • Segmentation issues, and
  • The all-encompassing infeasibility under the circumstances

The infeasibility exception must be claimed through a written response to the requestor within ten business days of receipt of the request. The infeasibility under the circumstances condition requires the actor to consider the following in claiming a request is infeasible:

  • The type of EHI and the purposes for which it may be needed;
  • The cost to the actor of complying with the request in the manner requested;
  • The financial and technical resources available to the actor;
  • Whether the actor's practice is non-discriminatory, and the actor provides the same access, exchange, or use of EHI to its companies or to its customers, suppliers, partners, and other persons with whom it has a business relationship;
  • Whether the actor owns or has control over a predominant technology, platform, health information exchange, or health information network through which electronic health information is accessed or exchanged; and
  • Why the actor was unable to provide access, exchange, or use of EHI consistent with the Content and Manner Exception in § 171.301.

In the case the actor is not be able to complete the content and manner review and reach a determination of infeasibility within the ten-business day deadline required for the infeasibility exception, it is important to keep in mind that inability to meet an exception does not mean the actor is automatically an information blocker. ONC and OIG have both indicated that information blocking does require intent. This enables the actor to make an argument that it acted in good faith and either did not meet the definition of information blocking through its actions or that the actor did not intentionally violate the definition of information blocking.

Information blocking is designed to stop an actor from preventing, interfering with, or materially discouraging access, exchange, or use of EHI/USCDI data. If the actor does not capture or otherwise have the information that is being requested, then the actor should not be considered as preventing, interfering with, or materially discouraging access, exchange, or use of the information as the actor does not have it in the first place. Therefore, information blocking should not require an actor to capture EHI/USCDI that it would not otherwise capture nor make available EHI/USCDI data elements that it does not otherwise have to make available.





Advocacy


Cerner has long been a strong advocate for the unimpeded sharing of electronic health information and for interoperability through its efforts both within the industry, within the federal advisory committee (FACA) process for the HHS Office of the National Coordinator and through its legislative and regulatory advocacy processes. These include:

Standards Development

  • Having leadership roles and technical committee involvement in interoperability standards in standards development organizations such as HL7, NCPDP, ASC X-12, DICOM, HIE and others, including interoperability accelerators and initiatives such as Argonaut, Da Vinci, CARIN Alliance, and Digital Bridge

Connecting Regionally, and Nationally

  • Enabling any provider organization to connect with any HIE of their choice
  • Enabling eHealth Exchange participant to connect within eHealth Exchange and with other networks
  • Being a founding member of the CommonWell Health Alliance having leadership roles in advancing new use cases and capabilities
  • Active involvement with Carequality since conception
  • Being a founding member of DirectTrust

Promoting Interoperability

  • Having seated membership on ONC FACAs and participation in workgroups operating under the FACAs
  • Being a founding member of the EHRA
  • Being an active member of The Sequoia Project and Interoperability Matters
  • Being an active contributor to the CARIN Alliance focusing on consumer enablement
  • Being and active participant with CHIME and eHI to forge industry alignment
  • Being a supporting member of the American Immunization Registry Association

Document

Cerner clients: Find more information on Information Blocking.

Related Offerings

Client Extensibility

Cerner's platforms are open and extensible, enabling clients to modify and customize extensions to help meet business needs like patient education, and workflow efficiencies to reduce costs and improve care. Clients can work with toolkits and extensions such as MPages, innovation toolkits, advisories and Cerner Command Language.

CommonWell Health Alliance

Cerner is a founding member of the CommonWell Health Alliance, which is advancing interoperability by connecting systems nationwide and making health data available no matter where care occurs. 

Device Connectivity

Cerner’s Device Connectivity solutions use a workflow-driven, open architecture platform designed to support interoperability between validated medical devices and the EHR, regardless of vendor. With more than 50 validated device partners and 1,000 supported devices, we are continuously working toward improving communication between medical devices and systems, including making sure our devices follow the latest industry standards.

Interoperability

Cerner Interoperability makes data flow freely using standards, network connections and nationwide exchange to give clinicians access to relevant information regardless of source and support data sharing across the continuum. With a more complete picture of the person, we empower clinicians to make better care decisions and plan appropriate care.

Lights On Network

Cerner’s industry-leading EHR analytics solution, Lights On Network, provides data-driven analysis to help you understand which interoperability methods are used across your organization. Measure near real-time data such as orders received, results sent, messages exchanged and electronic prescription usage to determine the impact of interoperability as your organization moves from paper processes to newer technologies.

Open Platforms

Cerner’s open platforms, open technologies and open business approach enable innovative collaboration and the development of apps that fulfill edge needs. Our open application programming interfaces, called Cerner Ignite APIs, allow your organization to integrate apps directly into your workflows at the point of care.