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.
Imagine a world where the patient data that a clinician needs to provide the highest quality of care is available and easily accessible. Or where data can be safely and efficiently exchanged among stakeholders to increase knowledge of a virus and develop therapies and vaccines during a public health crisis.
Innovation. Collaboration. Interoperability. Scale. Speed. These elements are necessary to meet the demands of the evolving health care landscape. The process of transforming the future of health care is complex, and embracing openness ─ in platforms, technology and culture ─ is a key to getting where we need to go.
At Winona Health, we exchanged more than a million pieces of data in the past year, which is a lot of information for a town of 27,000 people. We’re a nonprofit health care organization in Minnesota with more than 90 providers and 13 specialties, a 49-bed hospital and a 110-bed nursing home.
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:
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:
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:
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:
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.
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:
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.
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.
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.
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.
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.
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.