Frequently Asked Questions

Information blocking is any action that will knowingly limit the ability of an individual or organization to access, exchange, or use electronic health information. This includes charging fees, using contracts, creating organizational policies, or implementing technology in custom ways that limit access, exchange, or use of electronic health information.

However, when you meet one of ONC’s exceptions and choose not to share health information or share it within certain boundaries it is not considered information blocking.

Compliance with ONC's interoperability regulation information blocking provisions went into effect on April 5, 2021.

Almost all USCDI data elements are captured within 2015 Edition certified EHRs today, meaning the info blocking policies will apply to the data within such systems. According to the rule, the definition of EHI will continue to expand beyond the USCDI. In 2022, the EHI definition expanded to include the full HIPAA electronic designated data set.

Healthcare providers, developers of certified health IT, health information networks and health information exchanges all must follow the information blocking rules or risk incurring penalties.

When an Actor is found to have information blocked, they will face a penalty which varies on the type of Actor they are.

Healthcare Provider – Hospital and CAH

• Fail Promoting Interoperability – reduction to the applicable percentage increase to the Inpatient Prospective Payment System (IPPS) payment rate for the next CY
• If they have already attested to Promoting Interoperability that they did not information block a False Claims Act penalty may be applied

Healthcare Provider/Providers under Medicare program

• Fail Promoting Interoperability – negative payment adjustment (7% or more) for the applicable calendar year

• If they have already attested to Promoting Interoperability that they did not information block a False Claims Act penalty may be applied

Certified Health IT Developer

• Penalty of up to $1 million dollars per infraction (i.e. patient record)

• May be removed from ONC’s Certification Program depending on the cause of information blocking

Health Information Network/Health Information Exchange

• Penalty of up to $1 million dollars per infraction (i.e. patient record)
  
  

Any organization or individual can file a complaint with ONC if they feel an actor who is obliged to comply with the ONC rule is engaging in information blocking. ONC will pass on complaints to the Office of the Inspector General (OIG), who is responsible for investigating complaints. OIG is currently going through notice and comment rulemaking to define the civil monetary penalties for information blocking; the proposed rule was published Apr 24.

The accused will be required to present documentation and prove that they did not information block by claiming one of ONC’s eight exceptions and proving that they met all of the requirements of the exception at all times during the period the organization had been accused of blocking. Documentation will be key, therefore, in defending against information blocking claims.

The following technical updates are required:

• FHIR v4 (read-only) in conjunction with a number of IGs
• HL7 FHIR US Core Implementation Guide STU 3.1.0 specification
  Argonaut spec
• SMART on FHIR with OAuth 2.0
• HL7 FHIR Bulk Data Access (Flat FHIR) (v1.0.0: STU 1)
• EHI Data Export for patient access and switching EHRs will require a full output of EHI a certified developer maintains in any format with a data map

Examples of info blocking include:

• Formal or informal restrictions on access, exchange, or use of EHI
• Implementing health information technology (HIT) in ways likely to restrict access, exchange, or use of EHI with respect to exporting complete information sets or transitioning between HIT systems
• Discouraging development or use of interoperable technologies / services by exercising influence over customers, users, or other parties
• Discrimination that frustrates efforts to strengthen interoperability
• Opportunistic pricing and rent-seeking that make information sharing cost-prohibitive.
• Significant questions remain over how info blocking will be addressed for specific cases

CMS can publicly report providers that may be information blocking based on how they attested to the Promoting Interoperability reporting requirements as part of the Quality Payment Program.

The rule is laid out a uniform manner for reporting info blocking to ONC; actual determination of info blocking will be done on a case-by-case basis.

Any organization or individual may lodge a complaint with ONC about an Actor information blocking. ONC will setup a process for receiving complaints and sharing them with the Office of the Inspector General (OIG) who is responsible for investigating complaints. All investigations will be reactive to a complaint being lodged. OIG will lead all investigations with ONC providing technical assistance and knowledge to OIG investigators. Additionally, if a certified health IT developer is accused of information blocking using their certified technology, ONC will also investigate the claim for a violation of Certification Program requirements.

Investigations will look at all relevant facts similar to a court proceeding/trial. The onus is on the accused Actor to present documentation and proof that they did not information block by claiming one of ONC’s exceptions. Over time, these investigations will build a structure similar to case law, giving all organizations a better idea of what is and is not allowed.

There are two categories of exceptions to information blocking: The first category includes instances where an organization/individual does not fulfill a request or chooses not to share health information with a requestor; the second category involves procedures and policies that are allowed when fulfilling a request. For the purposes of this post, we’ll break the exceptions into “fail to fulfill” and “policies and procedures” categories.

In the “fail to fulfill” category, exceptions include:

1. Preventing harm – This exception says data can be withheld if there is risk of substantial harm to the patient if that data is shared.
2. Protecting privacy – This exception says information can be blocked if state or federal law places privacy limitations on data sharing or the patient chooses to keep their data private.
3. Protecting security – This exception says information can be blocked if appropriate data security measures are not in place or data security is threatened.
4. Infeasibility – This exception says information can be blocked if the request is infeasible, such as if there is a state of emergency or something outside of an organization’s control (natural disaster, mass casualty event, etc.).
5. Health IT performance – This exception says information can be blocked if the health IT system is unavailable due to planned or unplanned maintenance or upgrades, or allowed throttling/network load balancing.

In the “policies and procedures” category, exceptions include:

1. Content and manner – This exception sets rules for how organization’s fulfill requests and what data must be provided. It provides flexibility concerning the required content of an organization’s/individual’s response to a request to access, exchange or use EHI and the manner in which the actor may fulfill the request (provided certain conditions are met).
2. Fees – This exception sets the rules for what and who an organization can charge.
3. Interoperability elements – This exception sets the rules for how organizations may license interoperability elements.

See additional FAQs for parameters regarding each exception.

Note: ONC put together a document that further explains the exceptions and their key conditions.

Organizations claiming "Preventing Harm" exemption:

• Can limit data sharing when the safety or life of the patient is at risk – linked to the HIPAA definitions for providers withholding data and typically used for mental health data, partner abuse situations, etc.
• Can limit data sharing when data is known to be corrupt or incorrectly matched. Limited only to the corrupt data or the mismatched data
• Requires organizations to have organizational policies in place

• Organizations can claim this exemption if preconditions from federal or state law—i.e. if the law requires a consent or authorization and it has not been obtained—can withhold data
• Organization must use "reasonable effort" to obtain consent/authorization (i.e. the data holder does not have use every mean possible), but "reasonable" has not yet been defined
• If operating in multiple states, you can adopt the strictest state policy for your entire organization
• Organizations must have organizational policies documented
• Organizations may respect patients’ requests not to exchange their info, unless required by law

To claim this exception, organizations:

• Must have security policies and practices documented in writing.
  • Those policies must be directly related to safeguarding confidentiality, integrity, and access to data
• Have to respond to actual security threats – i.e. their risk assessment could be used to demonstrate this
• Must align with a consensus-based standard or best practice – HIPAA, NIST Cybersecurity Framework, etc.
• Must clearly state that requiring ID proofing and Authentication is allowed, even when it’s a patient app
• Are allowed to restrict patient apps that pose an actual security threat based on documented policy

• If you couldn’t share data because of something beyond your control, think pandemic, natural disaster, state of emergency, you can claim this exception
• ONC was clear that if some data can’t be shared due to state or federal restrictions, the data must be segmented and then share what you’re allowed to.
  • However, actors can claim this exception if they cannot segment data that is required by law to be segmented – i.e. if you can’t pull out psych notes
• If you don’t own the IP for the interoperability element needed and therefore can’t provide the access, you can claim this exception
• If it was unfeasible under the circumstances, you must document all of the details and respond to the requestor within 10 days
• TEFCA is not a de facto way to claim this exception, but could be used in conjunction with the Content and Manner exception

• Health IT can be made unavailable for maintenance for the shortest time possible and in a non-discriminatory manor
• For both planned and unplanned it must be in accordance with SLAs and for unplanned must be agreed upon by users in advance
• Throttling is allowed, even with third party patient apps, so long as it’s part of SLAs and for the shortest amount of time necessary
• When a shut down is related to a security incident, must meet the protecting security exception requirements too

• Establishes USCDI as the requirement for first 24 months
• Organization must fulfill a request in any manner requested—unless technically unable to do so or can’t reach agreeable terms with the requestor
• If an actor fulfills the request in any manner requested they are not limited by the info blocking fee and licensing exceptions
  • This means that a pricing agreement may not be reached
• If an actor technically can’t—or can’t reach an agreement (probably mostly on pricing or royalty terms)—than the request must be fulfilled in another manner

1. The first choice is certified health IT
2. Second is a standard published by the feds or from an ANSI accredited SDO (the HL7 specs),
3. And last is alternative machine-readable format with a data map
   1. If they do this method, they must follow the fee and licensing exceptions

• Organizations may charge fees for development, deployment, upgrades, etc.
• Fees must be reasonably related to the actor’s costs of providing the type of access, exchange, or use of electronic health information to, or at the request of, the person or entity to whom the fee is charged (reasonable has not yet been defined)
• An actor may put a reasonable profit on top of the fees related to cost (reasonable profit has not yet been defined)
• Rule will likely require a cost accounting system be in place
• Organizations have to charge similarly situated entities the same way—so all large hospitals have the same fees, but could charge small and large hospitals differently
• Fees can’t be based on decisions made to use non-standard design/development—unless the requestor asked for a non-standard way and agreed to the fees in advance, then you have to meet the fee exception requirements
• No actor may charge third parties acting on the behalf of the patient a fee
• Cannot charge both a data holder and a third party the same fees—so you charge one or the other no double-dipping
• If you charge for development fees, you cannot charge a licensing fee for your IP

• Generally, can only charge a licensing fee for IP you own
• Meaning you can’t charge it when you’re using standards developed by an SDO
• EHI is not considered IP
• If you charged a development fee, can’t charge a licensing fee
• If you charge a royalty fee, it must be reasonable, non-discriminatory, and not based on the value to the licensee or their future sales
• If you pay a license fee for an interop element, you can pass that fee on to the other party (i.e. you pay for the CPT code sets)
• Can’t enforce non-competes, revenue sharing, or IP sharing
• Certified APIs must follow the certification fee restrictions

The info blocking rule doesn't directly affect CMS' Promoting Interoperability (PI) program.

Changes to the PI reporting requirements are established through CMS rulemaking.

However, the scope of the ONC rule includes data elements specified by the PI program. Meaning providers need to expand their scope of how they think about info blocking—similarly to how they would for HIPAA or Stark Laws.

Yes. Healthcare providers are considered actors as defined in 45 CFR 171.102 regardless of whether any of the health IT the provider uses is certified under the ONC Health IT Certification Program.

Full explanation here.

HINs and HIEs currently are written as a single, functional definition in 45 CFR 171.102. In order to determine whether your organization is a HIN/HIE for information blocking purposes, you should assess whether your organization’s functional activity meets the HIN/HIE definition in 45 CFR 171.102.

Visit the Information Blocking Actors fact sheet for actor definitions.