Information Blocking in the 21st Century Cures Act FAQ

PCC created this FAQ to help pediatric practices learn about Information Blocking in the 21st Century Cures Act.

Watch PCC's Presentations on Information Blocking: To learn more, you can watch PCC’s Information Blocking presentation, or the April 2021 live Information Blocking Q&A session.

Consult Your Practice's Legal Counsel: PCC shares what we learn about pediatric industry issues and best practices, but we do not provide legal advice. For questions, consult your practice's legal counsel.

Contact PCC if you have questions about implementing solutions at your practice.

General Questions

What is Information Blocking?

Information blocking is defined in the 21^st Century Cures Act. In summary, information blocking is “a practice that…is likely to interfere with, prevent, or materially discourage access, exchange, or use of electronic health information,” unless such practice is required by law (e.g., HIPAA), or it meets an exception established through federal rulemaking (42 U.S.C. § 300jj-52(a)(1)).

Does information blocking apply to me?

Yes, information blocking applies to physicians and practitioners. Information blocking applies to three types of “actors”: Certified health IT vendors, HIN/HIEs and health care providers, regardless of whether or not they use a certified product or participate in federal or state quality incentive programs.

ONC uses the Public Health Service Act definition of a health care provider to further define what which health care providers information blocking applies to. The Public Health Service Act health care provider definition includes licensed physicians and practitioners (physician assistant, nurse practitioner, and clinical nurse specialist). For more information, please see this Fact Sheet published by the ONC: Cures Act Final Rule: 2015 Edition Cures Update Overview (healthit.gov)

When do the Information Blocking guidelines go into effect?

Information blocking guidelines go into effect on April 5, 2021. There are also several milestone due dates for the various “actors”; they are outlined here: New Applicability Dates included in ONC Interim Final Rule (healthit.gov)

Do I need to be using a Certified EHR?

No. The information blocking regulations do not require actors to have or use health IT certified under the ONC Health IT Certification Program.

How does the Cures Act handle paper charts?

While the intent of the Cures Act is to increase the electronic exchange of health data through various means of interoperability, paper charts are okay to use. At the same time, using paper charts does not exempt one from complying with the Cures Act. When patient health data is requested, it needs to be fulfilled in an alternate manner, likely via paper copy or fax. It is recommended to review the Infeasibility and Content and Manner exceptions to ensure compliance.

What is the United States Core Data for Interoperability?

USCDI stands for the United States Core Data for Interoperability. The USCDI replaces the Common Clinical Data Set (CCDS).
USCDI Definitions:

• USCDI: a standardized set of health data classes and data elements for nationwide, interoperable health information exchange
• USCDI Data Class: an aggregation of various data elements by a common theme or use case
• USCDI Data Element: the most granular level at which a piece of data is represented in the USCDI for exchange

The USCDI will be updated through a transparent, collaborative process of public commenting and input on an annual basis.

What is Electronic Health Information (EHI) and am I required to provide to patients upon request?

Please see the ONC fact sheet that explains what Electronic Health Information (EHI) is, and the intent of its use: Understanding_EHI.pdf (healthit.gov). The Information Blocking regulation requires a response to fulfill requests, and EHI is the most common way to fulfill said requests. If you are unable to fulfill a request, please review the Information Blocking Exceptions.

When is Information Blocking allowed?

There are circumstances when information blocking is allowed. The ONC defined eight exceptions for information blocking. There are five exceptions for not fulfilling information and three exceptions that apply to information being fulfilled, but in a different, or certain way. Please see the Information Blocking Exceptions section for more information.

Exceptions for not fulfilling information:

• Preventing Harm
• Privacy
• Security
• Health IT Performance
• Infeasibility

Exceptions applying to information fulfilled in a different (or certain) but still acceptable way:

• Content and Manner
• Fees
• Licensing

Should I be updating my practice’s policies and procedures to address Information Blocking?

Yes. Three of the Information Blocking exceptions (preventing harm, privacy, and security) require a written policy. In addition to the required policies it is recommended to write and maintain an Information Blocking policy that includes protocols for sharing electronic and non-electronic health data.

PCC created a sample Electronic Health Information Access Policy. PCC does not provide legal advice. This policy is an example of what you may want to consider including in your own policy. Before you finalize a policy such as this, we recommend you consult your own legal counsel.

Should my practice have a written “data sharing” policy? What should it include?

Written policies are encouraged by the ONC, however a written policy is not automatically a safe harbor to prevent allegations of Information Blocking.

Information Blocking is a practice that is likely to “interfere with, prevent, or materially discourage access, exchange, or use of electronic health information.” Your practice’s policies should be written with this statement in mind.

For example, setting a standard 10 business day turnaround time to respond to requests for information (especially those that can be fulfilled electronically much faster) will likely constitute Information Blocking. Requests for patient data should be completed in an appropriate amount of time given the capabilities of the practice and the needs of the patient.

PCC created a sample Electronic Health Information Access Policy. PCC does not provide legal advice. This policy is an example of what you may want to consider including in your own policy. Before you finalize a policy such as this, we recommend you consult your own legal counsel.

What are examples of Information Blocking?

• Provider has capability to provide same-day access to EHI but takes several days to respond
• Provider organization charges a patient for their electronic data
• Requiring patient consent to exchange electronic health information for treatment where it is not required by law
• Certified health IT developer refuses to share technical information needed to export data
• Health information network/health information exchange charges additional fees to exchange data or refuses to exchange data with non-members

Portal Access

Do we need to enable portal access to our patients if they request access?

Yes, if a patient requests portal access, it must be granted if you have the portal enabled. Additionally, if your practice does not have the portal enabled it is strongly recommended that you do so. If you do not have it enabled, you may choose to use the infeasibility exception, however it is not wise to use this exception for an extended period of time if you do have the ability to enable it and have chosen not to.

Can we charge patients for portal access?

No, charging patients to electronically access their electronic medication information is prohibited.

What exactly is being shared on the portal?

PCC practices have the ability to configure what they share in the patient portal, including the following information: allergies, care plans, clinical instructions, diagnoses, documents, future appointments and date of last physical, growth charts, immunizations, labs, medications, orders, race, ethnicity, preferred language, patient sex, problems, smoking status, vitals, and personal balances.

Practices may continue to share what they normally do. There are no specific requirements to share more or less information in this rule. If a patient requests additional PHI via the portal or otherwise, practices need to be prepared to respond to requests. The request for additional PHI should be provided electronically when that is feasible, otherwise it should be fulfilled in an alternative format (e.g. paper).

Interoperability

Does my practice have to connect to a HIE/HIN?

The Information Blocking rule does not require practices to connect to a HIE/HIN, however other incentive programs or payers may require it. HIE/HINs are actors subject to the requirements of the rule themselves.

Does my practice have to submit data to registries?

The Information Blocking rule does not require practices to connect data registries, however other incentive programs, local or state laws, or payers may require it.

Patient Confidentiality

Do we have to make all of our lab results accessible to patients in the portal?

It is not a requirement of the rule to make all lab results accessible to patients in the portal, it is your choice to do so or not. If a patient requests their lab results via the portal and you do not provide them, this is information blocking. You must acknowledge and respond to all requests for electronic health information. If you are unable to fulfill them in the manner they are requested, or have an additional reason for not fulfilling the request, please refer to the information blocking exceptions for additional guidance within the ONC Information Blocking exceptions Fact Sheet.

Our clinicians store confidential information in various places in PCC EHR. Do we need to make all of those notes available to patients?

The information blocking rule does not supersede the HIPAA privacy and security rules. It is not a requirement of the rule to release all confidential information available to patients (or their guardians). Please refer to the ONC information blocking exceptions to understand more about the circumstances to withhold information.

The ONC FAQ includes a question and answer regarding patient confidentiality when the patient is a minor: Information Blocking FAQs (healthit.gov)
For more information about patient privacy and making certain items confidential, read the Patient Privacy Features article.

If a parent requests their child’s entire health record to be shared (electronically or via paper), am I required to share clinical notes from specialists or hospitals that were included in the patient’s chart?

Providers and practices should share patient data that is clinically relevant and has been requested (e.g. HIPAA minimum necessary rule). If this includes data from other practitioners, then it should be shared. Conversely, if the provider believes there is a risk of harm or security when sharing the patient’s data, they should review and apply the appropriate Information Blocking exception given the specific circumstances.

Information Blocking Exceptions

What are the Information Blocking exception requirements? Read below to learn more.

Disclaimer: For the full regulatory language, please refer to §171.200 – .205 and §171.300 – 303 included in the 21st Century Cures Act: Interoperability, Information Blocking, and the ONC Certification Program final rule located on the Federal Register here.

Preventing Harm

Objective: Blocking information is justified when it is in the public interest to protect a patient and other persons against unreasonable risks of harm.

Conditions:

• The actor must hold a reasonable belief that withholding information will substantially reduce the risk of harm
• The actor’s practice must be no broader than necessary
• The actor’s practice must satisfy at least one condition from each of the following categories: type of risk, type of harm and implementation basis
• The practice must satisfy the condition concerning a patient right to request review of an individualized determination of risk of harm

Examples:

• Risk of corrupt or inaccurate data being recorded or incorporated in a patient’s electronic health record
• Risk of misidentifying a patient or patient’s electronic health record
• Determination by a licensed health care professional that the disclosure of EHI is reasonably likely to endanger life or physical safety
• Reasonable belief that practice is necessary to directly and substantially reduce likelihood of harm

Privacy

Objective: This exception recognizes that if an actor is permitted to provide access, exchange or use of EHI under a privacy law, then the actor should provide that access, exchange or use. However, an actor should not be required to use or disclose EHI in a way that is prohibited under state or federal privacy laws.

Conditions: The actor must meet at least one of the following four sub-exceptions:

• If patient consent or authorization is not in place, the rule refers to this as a pre-condition
• If the health IT developer is not covered by HIPAA
• If the data being requested is addressed by the HIPAA privacy exception; examples include psychotherapy notes and information for a court proceeding
• If the patient requests to keep his or her information private

Examples:

• Patient has not agreed to share her information with a certain other provider or has not yet signed a HIPAA consent form.

Security

Objective: This exception is intended to cover all legitimate security practices by actors but does not prescribe a maximum level of security or dictate a one-size-fits-all approach.

Conditions:

• The practice must be directly related to safeguarding the confidentiality, integrity and availability of the EHI. It must be tailored to specific security risks, and it must be implemented in a consistent and non-discriminatory manner.
• The healthcare provider/organization must document its security policy

Examples:

• There is an active or known virus or ransomware attack
• An individual has been unable to prove their identity
• Request for EHI from a patient-facing application or website causes actor’s system to raise a malicious software detection alert

Infeasibility

Objective: This exception recognizes practical challenges to comply with a request for EHI.

Conditions: The actor must meet one of the following
Conditions:

• There is an event beyond the actor’s control, such as a natural or human-made disaster (public health emergency, public safety incident, war, terrorist attack, civil unrest such as a labor strike, telecommunication or internet service being unavailable, or act of military or government authority)
• A request cannot be technically met as requested (via a certain format)
• The actor is not able to understand the request because of patients’ requests to keep it private or to keep them safe
• The current circumstance makes fulfilling the request not possible
• The actor must provide a written response to the requestor within 10 business days of receipt of the request with the reason(s) why the request is infeasible

Examples:

• A natural disaster occurs such as a hurricane, earthquake, or tornado affects electricity and internet availability in an area for a week.
• A small physician practice with limited financial and technical resources may find it burdensome to accommodate requests from other providers to establish and maintain outbound interfaces from the practice’s EHR system that it neither needs for its own health care activities nor to comply with any regulatory requirements

Health IT Performance

Objective: This exception recognizes the need for health IT to be taken offline for system maintenance and improvements.

Conditions:

• Unavailability of health IT must be for no longer than necessary to achieve the maintenance or improvements (e.g. upgrade)
• Unavailability of health IT for maintenance or improvements must be implemented in a consistent and non-discriminatory manner
• Unavailability of health IT for maintenance or improvements must be agreed (e.g., advanced notice of system downtime for maintenance)
• An actor may take action against a third-party app that is negatively affecting the health IT’s performance
• For a period of time that is no longer than necessary
• Implemented in a non-discriminatory manner
• Consistent with existing service-level agreements, where applicable

Examples:

• Planned maintenance or improvements such as routine repairs, updates, or new releases
• Unplanned maintenance or improvements to respond to urgent or time-sensitive issues, which cannot wait for the occurrence of a pre-planned time period to implement the required maintenance or improvements

Content and Manner

Objective: This exception provides clarity and flexibility to actors concerning the required content (scope of EHI) of an actor’s response to a request to access, exchange or use EHI and the manner in which the actor may fulfill the request. Content is the what. Manner is the how.

Conditions:

• Content: Establishes the content an actor must provide in response to a request to access, exchange or use EHI in order to satisfy the exception.
  • Until October 6, 2022, the EHI data must be provided (at minimum) represented in the United States Core Data for Interoperability (USCDI) standard
  • On and after October 6, 2022 , the EHI definition is no longer limited to the EHI identified by the data elements represented in the USCDI

• Manner: Establishes the manner in which an actor must fulfill a request to access, exchange or use EHI in order to satisfy this exception. An actor may need to fulfill a request in an alternative manner when the actor is either:
  • Technically unable to fulfill the request in any manner requested
  • Cannot reach agreeable terms with the requestor to fulfill the request
  • If an actor fulfills a request in an alternative manner, such fulfillment must satisfy the Fees Exception and Licensing Exception, as applicable.

Examples:

• Client requests connection to Commonwell; vendor is not connected to Commonwell, but can offer connection to CareQuality
• Request for EHI that is not able to be fulfilled electronically, therefore it is send using a PDF (or other) format

Fees

Objective: This exception allows actors to charge fees related to the development of technologies and services that enhance interoperability.

Conditions:

• Fees charged must:
  • Be consistent
  • Be reasonable related to the cost to us to provide access, enable exchange or use EHI
  • Be nondiscriminatory
• This exception does not allow:
  • A fee based on the electronic access by an individual patient, his or her personal representative, or another person or entity designated by that individual to access the individual’s EHI
  • A fee to perform an electronic health information export for a patient or a client looking to change to a different EHR unless a fee has been already agreed upon

Examples:

• Provider or practice charging a fee for patient access to their health information electronically (is prohibited)
• Health care provider or practice imposing fees to exchange data with a hospital system they are not affiliated with, but does not charge fees for affiliated facilities (and vice versa)

Licensing

Objective: This exception allows actors to protect the value of their innovations and charge reasonable royalties

Conditions:

• Scope of Rights: The license must provide all rights to enable the access, exchange, or use of EHI and achieve the intended access, exchange or use of EHI via the interoperability elements
• Reasonable royalties are permissible
• Non-discriminatory terms: The terms and conditions must be based on objectively verifiable and uniformly applied criteria
• Non-disclosure agreement safeguards