By the EHR Association Information Blocking Compliance Task Force

This is the second blog in our occasional series on information blocking, the goal of which is to educate our membership and other impacted stakeholders on information blocking requirements and exceptions. The first installment shared the history and description of information blocking. This entry is focused on the Manner Exception, its history, and what it means. 

History of the Exception

Originally called the “Content and Manner Exception” and introduced in ASTP/ONC’s 21st Century Cures Act: Interoperability, Information Blocking, and the ONC Health IT Certification Program, the Exception was included to address concerns that the 2019 proposed rule on information blocking failed to offer sufficiently clear pathways for market-driven technology innovation or incentives for standards-based development. It also provides a path for software developers to provide compliant solutions that are different than originally requested, but still be deemed to have fulfilled an exchange request, allowing for greater response flexibility. 

…the Exception was included to address concerns that the 2019 proposed rule on information blocking failed to offer sufficiently clear pathways for market-driven technology innovation or incentives for standards-based development. It also provides a path for software developers to provide compliant solutions that are different than originally requested, but still be deemed to have fulfilled an exchange request, allowing for greater response flexibility. 

The Content and Manner Exception was renamed the “Manner Exception” in HTI-1 and was updated to remove references to concepts about the temporary definition of electronic health information (EHI), shifting the focus of the Exception to the Manner elements. The Manner Exception Exhausted was also added to the Infeasibility Exception.

What the Exception Means

The Manner Exception, the full definition of which is available at 171.301. has two parts. The first establishes that market-based terms – terms that don’t satisfy the fees or licensing exceptions to information blocking – are permissible if responding to a request for EHI in the manner requested. The second establishes how alternatives can be offered if responding in the manner requested is not possible, and paths to follow if the parties cannot reach business-agreeable terms or because it is not technically feasible.

The Manner Exception can be visualized as a flowchart, with the starting point being the request for EHI in a specific manner, or the “manner requested.” From there:

1. The receiver evaluates whether it is technically feasible to provide the EHI in the manner requested.
2. If yes, the receiver and the requestor proceed to negotiate terms.
3. If agreeable terms are reached, the EHI is provided.
4. If either party determines they are technically unable to provide EHI in the manner requested or agreeable terms cannot be reached, then the second half of the manner exception is used.

In the second half, the receiver offers alternative manners outlined by the regulation. While there is some technical language about standards, the regulation outlines three types of alternatives that should be offered:

1. Using technology certified to standards adopted in part 170: This is technology certified in ONC’s health information technology certification program, or ONC-certified health IT.
2. Using content and transport standards published by the Federal Government or a standards-developing organization accredited by the American National Standards Institute: This could include content standards like US Core Data for Interoperability (a standard published by the Federal Government) or many standards published by standards development organizations (SDOs) that are ANSI-accredited. HL7 is one such SDO.
3. Using an alternative machine-readable format, including the means to interpret the electronic health information: EHI Export is a certification feature that would be an example of a machine-readable format that might fall into this category (though, since it is in ONC’s certification program, it would also fall into the first category).

The regulation indicates that the alternatives must be offered “without unnecessary delay” and in the order given in the regulation. Some actors have found it practical to offer multiple types of other options simultaneously, which seems in the spirit of rapidly finding an agreed-upon way to deliver the requested EHI.

If one of the alternatives is agreed upon by the requestor, then the EHI is provided. However, if none of the alternatives are agreed upon by the requestor, then one option would be to consider the Manner Exception Exhausted portion of the Infeasibility Exception.

Potential Applications

There are several ways an EHR developer might use the Manner Exception when a request for EHI is received. The following is a sample scenario illustrating the application of the Manner Exception, in which a patient app developer approaches an EHR developer with interest in integrating the app with the EHR. To the extent that information blocking is implicated, the Manner Exception may be used in various ways.

Option One: The patient app developer is interested in a joint business venture to market a new product line with the developer. The app has no current users; therefore, there is no current EHI nexus to implicate information blocking regardless of whether the EHR developer is interested in integrating with the app. Each party can make decisions based on its business interests.

Option Two: The patient app developer has a current user with patient data in the EHR that they want to integrate with the app, creating an EHI nexus. The patient app developer is interested in a joint business venture to market a new product line. The EHR developer responds with details of their business development program, and the two parties begin discussions on the possible joint venture. They find a mutually agreeable approach to integrating the products with market-based terms. This falls into 171.301(a)(2) Manner Requested, because the actor is fulfilling the request for EHI in the manner requested.

Option Three: The patient app developer has a current user with patient data in the EHR that they want to integrate with the app. Thus, there is an EHI nexus. The app developer is interested in a joint business venture to market a new product line and suggests a custom-built integration between the two products. The EHR developer responds with details of their business development program. Terms offered by the EHR developer are not agreeable to the app developer, leading the EHR developer to offer several alternative manners for integration between their products, all of which satisfy the fees and licensing exceptions. The app developer agrees that one of the suggested alternatives is sufficient for their users’ access to EHI. This is a use of the 171.301(b) Alternative manner portion of the exception.

Option Four: Similar to Option Three, but instead of determining that agreeable terms cannot be reached for the manner requested, the EHR developer decides that they are technically unable to fulfill the request in the manner requested. They again offer several alternative manners for integration, which satisfy the fees and licensing exceptions. The app developer agrees that one of the suggested alternatives is sufficient for their users’ access to EHI. Like Option Three, this is a use of the 171.301(b) Alternative manner portion of the exception.

Manner Exception Exhausted

When all other options fail, the Manner Exception Exhausted option may come into play. This is when agreeable terms cannot be reached or the actor – in our scenario, the EHR developer – is technically unable to fulfill the request in the manner requested. 

In the following scenario, the request comes in from an app developer. Two alternative manners are offered by the EHR developer, but the app developer responds that they do not accept any of the suggestions. 

Since the EHR developer offered at least two alternative manners, they would be eligible to use the Manner Exception Exhausted option (presuming the EHR developer notified the requestor in writing as to why the request was infeasible within 10 days of receiving the request). This also requires that the EHR developer not provide the same access, exchange, or use of the requested EHI to a substantial number of similarly situated entities but then deny this specific requestor. 

One of the challenges of using the Manner Exception Exhausted is that the process of working through the Manner Exception can easily take longer than 10 business days.

• Business Day 0: EHR developer receives the request
• Day 1: Asks a clarifying question.
• Day 2: Receives clarification back from the app developer.
• Day 5: Offers terms.
• Day 7: The app developer responds.
• Day 9: EHR developer offers multiple alternative manners.
• Day 11: The app developer indicates that the alternative manners are insufficient.

More than 10 days have elapsed since the receipt of the request. When there are more clarifying questions, negotiation of terms, and/or iterative offers of alternative manners, the process can reasonably stretch for weeks. Acknowledging that the Manner Exception Exhausted has limited efficacy due to this 10-day timeline, it is nonetheless a critical Exception that reflects the numerous challenges that remain in finding reasonable technological and business obstacles to exchange. 

Conclusion

We hope these examples help you understand the Manner Exception to Information Blocking and how it might be used, particularly by health IT actors. The next blog in this series will highlight the Infeasibility Exception.