Info Blocking

Frequently Asked Questions

Answers to your most pressing 21st Century Cures Act questions.


What is info blocking?


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.


When did enforcement go into effect?


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


What data is subjected to info blocking regulations?


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.


What are the penalties for info blocking?


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.


What technical updates are required for info blocking regulations?


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

What are some examples of infoblocking?


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

How will info blocking be investigated?


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.


What are exceptions to info blocking?


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.


What are the parameters for the "Preventing Harm" exception?


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

What are the parameters for the "Protecting Privacy" exception?

  • 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

What are the parameters for the "Protecting Security" exception?


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

What are the parameters for the "Infeasibility" exception?

  • 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


What are the parameters for the "Health IT Performance" 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

What are the parameters for the "Content and Manner" exception?

  • 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


What are the parameters for the "Fees" exception?

  • 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


What are the parameters for the "Licensing of Intellectual Property (IP) for Interoperability Elements" exception?

  • 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

How does the ONC rule impact the CMP PI program measures?


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.


Are healthcare providers subject to this regulation even if they don't use certified health IT?


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.


Is my organization a health information network (HIN) or health information exchange (HIE) in this instance?


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.


Don't see your question listed above?


Submit your question below and we’ll research the answer and get back to you.


The information provided on this website does not, and is not intended to, constitute legal or compliance advice; instead, all information, content, and materials available on this site are for general informational purposes only. No user of this site should act or refrain from acting on the basis of the information on this site without first seeking advice from a qualified legal or compliance expert. Information on this website may not constitute the most up-to-date legal or other information. All liability with respect to actions taken or not taken based on the contents of this website are hereby expressly disclaimed. The content on this website is provided "as-is;" no representations are made that the content is error-free, and relying on the contents of this website does not guarantee compliance with any law or laws. This website contains links to other third-party websites. Such links are only for the convenience of the reader, user or browser; Moxe does not recommend or endorse the contents of the third-party sites.