§170.401 Information Blocking

Updated on 05-04-2022
Revision History
Version # Description of Change Version Date
1.0

Initial Publication

06-15-2020
1.1

Updated compliance dates per the Interim Final Rule (IFR), Information Blocking and the ONC Health IT Certification Program: Extension of Compliance Dates and Timeframes in Response to the COVID-19 Public Health Emergency. 

11-02-2020
1.2

Updated to provide additional clarity on the Attestations Condition and Maintenance of Certification requirements. 

03-12-2021
1.3

Included information on the ONC Information Blocking Frequently Asked Questions resource

10-18-2021
1.4

Updated compliance date per the Interim Final Rule (IFR), Information Blocking and the ONC Health IT Certification Program: Extension of Compliance Dates and Timeframes in Response to the COVID-19 Public Health Emergency.

05-04-2022
Regulation Text
Regulation Text

§ 170.401 Information blocking.

  1. Condition of Certification requirement. A health IT developer must not take any action that constitutes information blocking as defined in 42 U.S.C. 300jj-52 and § 171.103 on or after April 5, 2021.
  2. [Reserved]
Standard(s) Referenced
Standards Referenced

None

Certification Companion Guide: Information Blocking

This Certification Companion Guide (CCG) is an informative document designed to assist Certified Health IT Developers in meeting the Conditions and Maintenance of Certification requirements. The CCG is not a substitute for the 21st Century Cures Act: Interoperability, Information Blocking, and the ONC Health IT Certification Program Final Rule (ONC Cures Act Final Rule). It extracts key portions of the ONC Cures Act Final Rule’s preamble and includes clarifying interpretations. To access the full context of regulatory intent please consult the ONC Cures Act Final Rule or other included regulatory reference. The CCG is for public use and should not be sold or redistributed.

Attestation Requirements

Outlined below is a summary of the attestation requirements for the Information Blocking Condition of Certification (45 CFR 170.401). This attestation is a part of the Attestations Condition and Maintenance of Certification requirements and will be available for developers to attest alongside the other attestation requirements in 45 CFR § 170.406 beginning on April 1, 2022, and semiannually thereafter. For additional details related to the attestation requirements, please refer to the Attestations Condition and Maintenance of Certification CCG.

  • A health IT developer of certified health IT does not take any action that constitutes information blocking on or after April 5, 2021.
Certification Requirements

Applicability of Condition: The Condition of Certification applies to all Certified Health IT Developers. A Certified Health IT Developer is responsible for ensuring that all of its health IT and related actions and behaviors do not constitute information blocking or inhibit the appropriate access, exchange, and use of electronic health information (EHI).

Condition Explanations and Clarifications

Applies to Entire Condition

Clarifications:

  • The Condition of Certification prohibits any Certified Health IT Developer who has at least one health IT product certified under the ONC Health IT Certification Program (Certification Program) from taking any action that constitutes information blocking as defined by section 3022(a) of the Public Health Service Act (PHSA) and codified in 45 CFR 171.103.
  • For information blocking purposes, the “actor” that is covered by the Information Blocking Condition of Certification is a “health IT developer of certified health IT.”
    • Health IT developer of certified health IT means an individual or entity, other than a health care provider that self-develops health IT for its own use, that develops or offers health information technology (as that term is defined in 42 U.S.C. 300jj(5)) and which has, at the time it engages in a practice that is the subject of an information blocking claim, one or more Health IT Modules certified under a program for the voluntary certification of health information technology that is kept or recognized by the National Coordinator pursuant to 42 U.S.C. 300jj-11(c)(5) (ONC Health IT Certification Program) (45 CFR 171.102).
  • The Condition of Certification is not limited only to certified health IT.
    • For the Information Blocking and Assurances Conditions and Maintenance of Certification requirements, consistent with the 21st Century Cures Act’s provisions and ONC’s implementation of section 3022(a) (information blocking) of the PHSA, a health IT developer is also responsible to ensure that all of its health IT and related actions and behaviors do not constitute information blocking or inhibit the appropriate access, exchange, and use of EHI.
    • A developer’s health IT product suite that a hospital, clinician office practice, or other health care provider uses (and colloquially references) as its “EHR system” will typically include a wide variety of functions, services, components, and combinations thereof. Even where such a health IT product suite meets the definition of “Certified EHR Technology” for purposes of participation in the Promoting Interoperability Programs, there is no guarantee that every part of the overall product suite will meet the requirements of at least one certification criterion adopted by the Secretary of the Department of Health and Human Services (Secretary). In fact, typically only a subset of the functions, services, components, and combinations thereof within the overall product suite will meet the requirements of at least one certification criterion adopted by the Secretary and be Health IT Modules certified under the Certification Program. The Condition of Certification will apply to all of the Certified Health IT Modules within a developer’s product suite(s) so long as at least one Health IT Module is certified under the Certification Program at the time the developer engages in a practice that is the subject of an information blocking claim.
  • The Interim Final Rule (IFR) provides needed flexibilities to respond effectively to serious public health threats posed by the spread of the coronavirus disease 2019 (COVID-19). ONC issued the IFR to extend certain compliance dates; therefore, ONC will not enforce this Condition of Certification until April 5, 2021. 
  • ONC shares answers to Information Blocking Frequently Asked Questions (FAQs) that may be helpful in more broadly understanding actions that may constitute information blocking. 

§ 171.103 Information Blocking

  1. Information blocking means a practice that—
    1. Except as required by law or covered by an exception set forth in subpart B or subpart C of this part, is likely to interfere with access, exchange, or use of EHI; and
    2. If conducted by a health IT developer, of certified health IT network or health information exchange, such developer, network or exchange knows, or should know, that such practice is likely to interfere with, access, exchange, or use of EHI; or
    3. If conducted by a health care provider, such provider knows that such practice is unreasonable and is likely to interfere with, prevent, or materially discourage access, exchange, or use of EHI.
  2. For the period before October 6, 2022, EHI for purposes of paragraph (a) of this section is limited to the EHI identified by the data elements represented in the United States Core Data for Interoperability (USCDI) standard adopted in § 170.213.

Clarifications:

  • No additional clarifications.

§ 171.200 Availability and effect of exceptions

A practice shall not be treated as information blocking if the actor satisfies an exception to the information blocking provision as set forth in this subpart B by meeting all applicable requirements and conditions of the exception at all relevant times.

Clarifications:

  • No additional clarifications.

§ 171.201 Preventing harm exception – When will an actor’s practice that is likely to interfere with the access, exchange, or use of EHI in order to prevent harm not be considered information blocking?

An actor’s practice that is likely to interfere with the access, exchange, or use of EHI in order to prevent harm will not be considered information blocking when the practice meets the conditions in paragraphs (a) and (b) of this section, satisfies at least one condition from each of paragraphs (c), (d), and (f) of this section, and also meets the condition in paragraph (e) of this section when applicable.

  1. Reasonable belief. The actor engaging in the practice must hold a reasonable belief that the practice will substantially reduce a risk of harm to a patient or another natural person that would otherwise arise from the access, exchange, or use of EHI affected by the practice. For purposes of this section, “patient” means a natural person who is the subject of the EHI affected by the practice.
  2. Practice breadth. The practice must be no broader than necessary to substantially reduce the risk of harm that the practice is implemented to reduce.
  3. Type of risk. The risk of harm must:
    1. Be determined on an individualized basis in the exercise of professional judgment by a licensed health care professional who has a current or prior clinician-patient relationship with the patient whose EHI is affected by the determination; or
    2. Arise from data that is known or reasonably suspected to be misidentified or mismatched, corrupt due to technical failure, or erroneous for another reason.
  4. Type of harm. The type of harm must be one that could serve as grounds for a covered entity (as defined in § 160.103 of this title) to deny access (as the term “access” is used in part 164 of this title) to an individual’s protected health information under:
    1. Section 164.524(a)(3)(iii) of this title where the practice is likely to, or in fact does, interfere with access, exchange, or use (as these terms are defined in § 171.102) of the patient’s EHI by their legal representative (including but not limited to personal representatives recognized pursuant to 45 CFR 164.502) and the practice is implemented pursuant to an individualized determination of risk of harm consistent with (c)(1) of this section;
    2. Section 164.524(a)(3)(ii) of this title where the practice is likely to, or in fact does, interfere with the patient’s or their legal representative’s access to, use or exchange (as these terms are defined in § 171.102) of information that references another natural person and the practice is implemented pursuant to an individualized determination of risk of harm consistent with paragraph (c)(1) of this section;
    3. Section 164.524(a)(3)(i) of this title where the practice is likely to, or in fact does, interfere with the patient’s access, exchange, or use (as these terms are defined in § 171.102) of their own EHI, regardless of whether the risk of harm that the practice is implemented to substantially reduce is consistent with paragraph (c)(1) or (c)(2) of this section; or
    4. Section 164.524(a)(3)(i) of this title where the practice is likely to, or in fact does, interfere with a legally permissible access, exchange, or use (as these terms are defined in § 171.102) of EHI not described in paragraph (d)(1), (2), or (3) of this section, and regardless of whether the risk of harm the practice is implemented to substantially reduce is consistent with paragraph (c)(1) or (2) of this section.
  5. Patient right to request review of individualized determination of risk of harm. Where the risk of harm is consistent with paragraph (c)(1) of this section, the actor must implement the practice in a manner consistent with any rights the individual patient whose EHI is affected may have under § 164.524(a)(4) of this title, or any Federal, State, or tribal law, to have the determination reviewed and potentially reversed.
  6. Practice implemented based on an organizational policy or a determination specific to the facts and circumstances. The practice must be consistent with an organizational policy that meets paragraph (f)(1) of this section or, in the absence of an organizational policy applicable to the practice or to its use in particular circumstances, the practice must be based on a determination that meets paragraph (f)(2) of this section.
    1. An organizational policy must:
      1. Be in writing;
      2. Be based on relevant clinical, technical, and other appropriate expertise;
      3. Be implemented in a consistent and non-discriminatory manner; and
      4. Conform each practice to the conditions in paragraphs (a) and (b) of this section, as well as the conditions in paragraphs (c) through (e) of this section that are applicable to the practice and its use.
    2. A determination must:
      1. Be based on facts and circumstances known or reasonably believed by the actor at the time the determination was made and while the practice remains in use; and
      2. Be based on expertise relevant to implementing the practice consistent with the conditions in paragraphs (a) and (b) of this section, as well as the conditions in paragraphs (c) through (e) of this section that are applicable to the practice and its use in particular circumstances.

Clarifications:

  • No additional clarifications.

§ 171.202 Privacy exception – When will an actor’s practice of not fulfilling a request to access, exchange, or use of EHI in order to protect an individual’s privacy not be considered information blocking?

An actor’s practice of not fulfilling a request to access, exchange, or use EHI in order to protect an individual’s privacy will not be considered information blocking when the practice meets all of the requirements of at least one of the sub-exceptions in paragraphs (b) through (e) of this section.

  1. Definitions in this section.
    1. The term HIPAA Privacy Rule as used in this section means 45 CFR Parts 160 and 164.
    2. The term individual as used in this section means one or more of the following—
      1. An individual as defined by 45 CFR 160.103.
      2. Any other natural person who is the subject of the EHI being accessed, exchanged, or used.
      3. A person who legally acts on behalf of a person described in paragraph (a)(1) or (2) of this section in making decisions related to health care as a personal representative, in accordance with 45 CFR 164.502(g).
      4. A person who is a legal representative of and can make health care decisions on behalf of any person described in paragraph (a)(1) or (2) of this section.
      5. An executor, administrator, or other person having authority to act on behalf of a deceased person described in paragraph (a)(1) or (2) of this section or the individual’s estate under State or other law.
  2. Sub-Exception – precondition not satisfied. To qualify for the exception on the basis that State or Federal law requires one or more preconditions for providing access, exchange, or use of EHI that have not been satisfied, the following requirements must be met—
    1. The actor’s practice is tailored to the applicable precondition not satisfied, is implemented in a consistent and non-discriminatory manner, and either:
      1. Conforms to the actor’s organizational policies and procedures that:
        1. Are in writing;
        2. Specify the criteria to be used by the actor to determine when the precondition would be satisfied and, as applicable, the steps that the actor will take to satisfy the precondition; and
        3. Are implemented by the actor, including by providing training on the policies and procedures; or
      2. Are documented by the actor, on a case-by-case basis, identifying the criteria used by the actor to determine when the precondition would be satisfied, any criteria that were not met, and the reason why the criteria were not met.
    2. If the precondition relies on the provision of a consent or authorization from an individual and the actor has received a version of such a consent or authorization that does not satisfy all elements of the precondition required under applicable law, the actor must:
      1. Use reasonable efforts within its control to provide the individual with a consent or authorization form that satisfies all required elements of the precondition or provide other reasonable assistance to the individual to satisfy all required elements of the precondition; and
      2. Not improperly encourage or induce the individual to withhold the consent or authorization.
    3. For purposes of determining whether the actor’s privacy policies and procedures and actions satisfy the requirements of paragraphs (b)(1)(i) and (b)(2) above when the actor’s operations are subject to multiple laws which have inconsistent preconditions, they shall be deemed to satisfy the requirements of the paragraphs if the actor has adopted uniform privacy policies and procedures to address the more restrictive preconditions.
  3. Sub-exception – health IT developer of certified health IT not covered by HIPAA. If the actor is a health IT developer of certified health IT that is not required to comply with the HIPAA Privacy Rule, when engaging in a practice that promotes the privacy interests of an individual, the actor’s organizational privacy policies must have been disclosed to the individuals and entities that use the actor’s product or service before they agreed to use them, and must implement the practice according to a process described in the organizational privacy policies. The actor’s organizational privacy policies must:
    1. Comply with State and Federal laws, as applicable;
    2. Be tailored to the specific privacy risk or interest being addressed; and
    3. Be implemented in a consistent and non-discriminatory manner.
  4. Sub-exception – denial of an individual’s request for their EHI consistent with 45 CFR 164.524(a)(1) and (2). If an individual requests EHI under the right of access provision under 45 CFR 164.524(a)(1) from an actor that must comply with 45 CFR 164.524(a)(1), the actor’s practice must be consistent with 45 CFR 164.524(a)(2).
  5. Sub-exception – respecting an individual’s request not to share information. Unless otherwise required by law, an actor may elect not to provide access, exchange, or use of an individual’s EHI if the following requirements are met—
    1. The individual requests that the actor not provide such access, exchange, or use of EHI without any improper encouragement or inducement of the request by the actor;
    2. The actor documents the request within a reasonable time period;
    3. The actor’s practice is implemented in a consistent and non-discriminatory manner; and
    4. An actor may terminate an individual’s request for a restriction to not provide such access, exchange, or use of the individual’s EHI only if:
      1. The individual agrees to the termination in writing or requests the termination in writing;
      2. The individual orally agrees to the termination and the oral agreement is documented by the actor; or
      3. The actor informs the individual that it is terminating its agreement to not provide such access, exchange, or use of the individual’s EHI except that such termination is:
        1. Not effective to the extent prohibited by applicable Federal or State law; and
        2. Only applicable to EHI created or received after the actor has so informed the individual of the termination.

Clarifications:

  • No additional clarifications.

§ 171.203 Security exception — When will an actor’s practice that is likely to interfere with the access, exchange, or use of EHI in order to protect the security of EHI not be considered information blocking?

An actor’s practice that is likely to interfere with the access, exchange, or use of EHI in order to protect the security of EHI will not be considered information blocking when the practice meets the conditions in paragraphs (a), (b), and (c) of this section, and in addition meets either the condition in paragraph (d) of this section or the condition in paragraph (e) of this section.

  1. The practice must be directly related to safeguarding the confidentiality, integrity, and availability of EHI.
  2. The practice must be tailored to the specific security risk being addressed.
  3. The practice must be implemented in a consistent and non-discriminatory manner.
  4. If the practice implements an organizational security policy, the policy must—
    1. Be in writing;
    2. Have been prepared on the basis of, and be directly responsive to, security risks identified and assessed by or on behalf of the actor;
    3. Align with one or more applicable consensus-based standards or best practice guidance; and
    4. Provide objective timeframes and other parameters for identifying, responding to, and addressing security incidents.
  5. If the practice does not implement an organizational security policy, the actor must have made a determination in each case, based on the particularized facts and circumstances, that:
    1. The practice is necessary to mitigate the security risk to EHI; and
    2. There are no reasonable and appropriate alternatives to the practice that address the security risk that are less likely to interfere with access, exchange or use of EHI.

Clarifications:

  • No additional clarifications.

§ 171.204 Infeasibility exception – When will an actor’s practice of not fulfilling a request to access, exchange, or use EHI due to the infeasibility of the request not be considered information blocking?

An actor’s practice of not fulfilling a request to access, exchange, or use EHI due to the infeasibility of the request will not be considered information blocking when the practice meets one of the conditions in paragraph (a) of this section and meets the requirements in paragraph (b) of this section.

  1. Conditions.
    1. Uncontrollable events. The actor cannot fulfill the request for access, exchange, or use of EHI due to a natural or human-made disaster, public health emergency, public safety incident, war, terrorist attack, civil insurrection, strike or other labor unrest, telecommunication or internet service interruption, or act of military, civil or regulatory authority.
    2. Segmentation. The actor cannot fulfill the request for access, exchange, or use of EHI because the actor cannot unambiguously segment the requested EHI from EHI that:
      1. Cannot be made available due to an individual’s preference or because the EHI cannot be made available by law; or
      2. May be withheld in accordance with § 171.201.
    3. Infeasible under the circumstances.
      1. The actor demonstrates, prior to responding to the request pursuant to paragraph (b) of this section, through a contemporaneous written record or other documentation its consistent and non-discriminatory consideration of the following factors that led to its determination that complying with the request would be infeasible under the circumstances:
        1. The type of EHI and the purposes for which it may be needed;
        2. The cost to the actor of complying with the request in the manner requested;
        3. The financial and technical resources available to the actor;
        4. 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;
        5. Whether the actor owns or has control over a predominant technology, platform, health information exchange, or health information network through which EHI is accessed or exchanged; and
        6. Why the actor was unable to provide access, exchange, or use of EHI consistent with the exception in § 171.301.
      2. In determining whether the circumstances were infeasible under paragraph (a)(3)(i) of this section, it shall not be considered whether the manner requested would have:
        1. Facilitated competition with the actor.
        2. Prevented the actor from charging a fee or resulted in a reduced fee.
  2. Responding to requests. If an actor does not fulfill a request for access, exchange, or use of EHI for any of the reasons provided in paragraph (a) of this section, the actor must, within ten business days of receipt of the request, provide to the requestor in writing the reason(s) why the request is infeasible.

Clarifications:

  • No additional clarifications.

§ 171.205 Health IT performance exception – When will an actor’s practice that is implemented to maintain or improve health IT performance and that is likely to interfere with the access, exchange, or use of EHI not be considered information blocking?

An actor’s practice that is implemented to maintain or improve health IT performance and that is likely to interfere with the access, exchange, or use of EHI will not be considered information blocking when the practice meets a condition in paragraph (a), (b), (c), or (d) of this section, as applicable to the particular practice and the reason for its implementation.

  1. Maintenance and improvements to health IT. When an actor implements a practice that makes health IT under that actor’s control temporarily unavailable, or temporarily degrades the performance of health IT, in order to perform maintenance or improvements to the health IT, the actor’s practice must be —
    1. Implemented for a period of time no longer than necessary to complete the maintenance or improvements for which the health IT was made unavailable or the health IT’s performance degraded;
    2. Implemented in a consistent and non-discriminatory manner; and
    3. If the unavailability or degradation is initiated by a health IT developer of certified health IT, health information exchange, or health information network:
      1. Planned. Consistent with existing service level agreements between the individual or entity to whom the health IT developer of certified health IT, health information exchange, or health information network supplied the health IT; or
      2. Unplanned. Consistent with existing service level agreements between the individual or entity; or agreed to by the individual or entity to whom the health IT developer of certified health IT, health information exchange, or health information network supplied the health IT.
  2. Assured level of performance. An actor may take action against a third-party application that is negatively impacting the health IT’s performance, provided that the practice is—
    1. For a period of time no longer than necessary to resolve any negative impacts;
    2. Implemented in a consistent and non-discriminatory manner; and
    3. Consistent with existing service level agreements, where applicable.
  3. Practices that prevent harm. If the unavailability of health IT for maintenance or improvements is initiated by an actor in response to a risk of harm to a patient or another person, the actor does not need to satisfy the requirements of this section, but must comply with all requirements of § 171.201 at all relevant times to qualify for an exception.
  4. Security-related practices. If the unavailability of health IT for maintenance or improvements is initiated by an actor in response to a security risk to EHI, the actor does not need to satisfy the requirements of this section, but must comply with all requirements of § 171.203 at all relevant times to qualify for an exception.

Clarifications:

  • No additional clarifications.

§ 171.300 Availability and effect of exceptions

A practice shall not be treated as information blocking if the actor satisfies an exception to the information blocking provision as set forth in this subpart C by meeting all applicable requirements and conditions of the exception at all relevant times.

Clarifications:

  • No additional clarifications.

§ 171.301 Content and manner exception – When will an actor’s practice of limiting the content of its response to or the manner in which it fulfills a request to access, exchange, or use EHI not be considered information blocking?

An actor’s practice of limiting the content of its response to or the manner in which it fulfills a request to access, exchange, or use EHI will not be considered information blocking when the practice meets all of the following conditions.

  1. Content condition – EHI. An actor must respond to a request to access, exchange, or use EHI with—
    1. USCDI. For the period before October 6, 2022, at a minimum, the EHI identified by the data elements represented in the USCDI standard adopted in § 170.213.
    2. All EHI. On and after October 6, 2022, EHI as defined in § 171.102.
  2. Manner condition.
    1. Manner requested.
      1. An actor must fulfill a request described in paragraph (a) of this section in any manner requested, unless the actor is technically unable to fulfill the request or cannot reach agreeable terms with the requestor to fulfill the request.
      2. If an actor fulfills a request described in paragraph (a) of this section in any manner requested:
        1. Any fees charged by the actor in relation to fulfilling the request are not required to satisfy the exception in § 171.302; and
        2. Any license of interoperability elements granted by the actor in relation to fulfilling the request is not required to satisfy the exception in § 171.303.
    2. Alternative manner. If an actor does not fulfill a request described in paragraph (a) of this section in any manner requested because it is technically unable to fulfill the request or cannot reach agreeable terms with the requestor to fulfill the request, the actor must fulfill the request in an alternative manner, as follows:
      1. The actor must fulfill the request without unnecessary delay in the following order of priority, starting with paragraph (b)(2)(i)(A) of this section and only proceeding to the next consecutive paragraph if the actor is technically unable to fulfill the request in the manner identified in a paragraph.
        1. Using technology certified to standard(s) adopted in part 170 that is specified by the requestor.
        2. Using content and transport standards specified by the requestor and published by:
          1. The Federal Government; or
          2. A standards developing organization accredited by the American National Standards Institute.
        3. Using an alternative machine-readable format, including the means to interpret the EHI, agreed upon with the requestor.
      2. Any fees charged by the actor in relation to fulfillment of the request are required to satisfy the exception in § 171.302.
      3. Any license of interoperability elements granted by the actor in relation to fulfillment of the request is required to satisfy the exception in § 171.303.

Clarifications:

  • No additional clarifications.

§ 171.302 Fees exception – When will an actor’s practice of charging fees for accessing, exchanging, or using EHI not be considered information blocking?

An actor’s practice of charging fees, including fees that result in a reasonable profit margin, for accessing, exchanging, or using EHI will not be considered information blocking when the practice meets the conditions in paragraph (a) of this section, does not include any of the excluded fees in paragraph (b) of this section, and, as applicable, meets the condition in paragraph (c) of this section.

  1. Basis for fees condition.
    1. The fees an actor charges must be—
      1. Based on objective and verifiable criteria that are uniformly applied for all similarly situated classes of persons or entities and requests;
      2. Reasonably related to the actor’s costs of providing the type of access, exchange, or use of EHI to, or at the request of, the person or entity to whom the fee is charged;
      3. Reasonably allocated among all similarly situated persons or entities to whom the technology or service is supplied, or for whom the technology is supported; and
      4. Based on costs not otherwise recovered for the same instance of service to a provider and third party.
    2. The fees an actor charges must not be based on—
      1. Whether the requestor or other person is a competitor, potential competitor, or will be using the EHI in a way that facilitates competition with the actor;
      2. Sales, profit, revenue, or other value that the requestor or other persons derive or may derive from the access, exchange, or use of the EHI;
      3. Costs the actor incurred due to the health IT being designed or implemented in a non-standard way, unless the requestor agreed to the fee associated with the non-standard design or implementation to access, exchange, or use the EHI;
      4. Costs associated with intangible assets other than the actual development or acquisition costs of such assets;
      5. Opportunity costs unrelated to the access, exchange, or use of EHI; or
      6. Any costs that led to the creation of intellectual property, if the actor charged a royalty for that intellectual property pursuant to § 171.303 and that royalty included the development costs for the creation of the intellectual property.
  2. Excluded fees condition. This exception does not apply to—
    1. A fee prohibited by 45 CFR 164.524(c)(4);
    2. A fee based in any part on the electronic access of an individual’s EHI by the individual, their personal representative, or another person or entity designated by the individual;
    3. A fee to perform an export of EHI via the capability of health IT certified to § 170.315(b)(10) of this subchapter for the purposes of switching health IT or to provide patients their EHI; and
    4. A fee to export or convert data from an EHR technology that was not agreed to in writing at the time the technology was acquired.
  3. Compliance with the Conditions of Certification condition. Notwithstanding any other provision of this exception, if the actor is a health IT developer subject to the Conditions of Certification in § 170.402(a)(4), § 170.404, or both of this subchapter, the actor must comply with all requirements of such conditions for all practices and at all relevant times.
  4. Definition of Electronic access. The following definition applies to this section:
    Electronic access means an internet-based method that makes EHI available at the time the EHI is requested and where no manual effort is required to fulfill the request.

Clarifications:

  • No additional clarifications.

§ 171.303 Licensing exception – When will an actor’s practice to license interoperability elements in order for EHI to be accessed, exchanged, or used not be considered information blocking?

An actor’s practice to license interoperability elements for EHI to be accessed, exchanged, or used will not be considered information blocking when the practice meets all of the following conditions.

  1. Negotiating a license conditions. Upon receiving a request to license an interoperability element for the access, exchange, or use of EHI, the actor must—
    1. Begin license negotiations with the requestor within 10 business days from receipt of the request; and
    2. Negotiate a license with the requestor, subject to the licensing conditions in paragraph (b) of this section, within 30 business days from receipt of the request.
  2. Licensing conditions. The license provided for the interoperability element(s) needed to access, exchange, or use EHI must meet the following conditions:
    1. Scope of rights. The license must provide all rights necessary to:
      1. Enable the access, exchange, or use of EHI; and
      2. Achieve the intended access, exchange, or use of EHI via the interoperability element(s).
    2. Reasonable royalty. If the actor charges a royalty for the use of the interoperability elements described in paragraph (a) of this section, the royalty must be reasonable and comply with the following requirements:
      1. The royalty must be non-discriminatory, consistent with paragraph (b)(3) of this section.
      2. The royalty must be based solely on the independent value of the actor’s technology to the licensee’s products, not on any strategic value stemming from the actor’s control over essential means of accessing, exchanging, or using EHI.
      3. If the actor has licensed the interoperability element through a standards developing organization in accordance with such organization’s policies regarding the licensing of standards-essential technologies on terms consistent with those in this exception, the actor may charge a royalty that is consistent with such policies.
      4. An actor may not charge a royalty for intellectual property if the actor recovered any development costs pursuant to § 171.302 that led to the creation of the intellectual property.
    3. Non-discriminatory terms. The terms (including royalty terms) on which the actor licenses and otherwise provides the interoperability elements must be non-discriminatory and comply with the following requirements.
      1. The terms must be based on objective and verifiable criteria that are uniformly applied for all similarly situated classes of persons and requests.
      2. The terms must not be based in any part on—
        1. Whether the requestor or other person is a competitor, potential competitor, or will be using EHI obtained via the interoperability elements in a way that facilitates competition with the actor; or
        2. The revenue or other value the requestor may derive from access, exchange, or use of EHI obtained via the interoperability elements.
    4. Collateral terms. The actor must not require the licensee or its agents or contractors to do, or to agree to do, any of the following—
      1. Not compete with the actor in any product, service, or market.
      2. Deal exclusively with the actor in any product, service, or market.
      3. Obtain additional licenses, products, or services that are not related to or can be unbundled from the requested interoperability elements.
      4. License, grant, assign, or transfer to the actor any intellectual property of the licensee.
      5. Pay a fee of any kind whatsoever, except as described in paragraph (b)(2) of this section, unless the practice meets the requirements of the exception in § 171.302.
    5. Non-disclosure agreement. The actor may require a reasonable non-disclosure agreement that is no broader than necessary to prevent unauthorized disclosure of the actor's trade secrets, provided—
      1. The agreement states with particularity all information the actor claims as trade secrets; and
      2. Such information meets the definition of a trade secret under applicable law.
  3. Additional conditions relating to the provision of interoperability elements. The actor must not engage in any practice that has any of the following purposes or effects.
    1. Impeding the efficient use of the interoperability elements to access, exchange, or use EHI for any permissible purpose.
    2. Impeding the efficient development, distribution, deployment, or use of an interoperable product or service for which there is actual or potential demand.
    3. Degrading the performance or interoperability of the licensee’s products or services, unless necessary to improve the actor’s technology and after affording the licensee a reasonable opportunity to update its technology to maintain interoperability.

Clarifications:

  • No additional clarifications.