Promoting Interoperability. Although important, administration of health IT certification has kept ONC’s purview relatively focused, but the Information Blocking Rule represents a potentially drastic expansion of ONC oversight powers. This is why discrete defini- tions are so important. For example, in the proposed rule, ONC asked stake- holders

whether price information should be included in their definition of electronic health information (EHI). Stakeholders were concerned whether doing so would allow ONC/OIG to penalize a healthcare entity for with- holding pricing information—such as negotiated rates—under the authority of information blocking? Fortunately, at the request of many

stakeholders including ASCs, ONC did not finalize a definition of EHI that included price information. In fact, ONC decided to narrow the definition from the one proposed to ease Health Insurance Portability and Account- ability Act of 1996 (HIPAA) compli- ance. The final definition aligns with the HIPAA definition of “protected health information”—individually identifiable health information trans- mitted by or maintained in electronic media—but limited to information that would be included in a “desig- nated record set.” A designated record set is the medical records and bill- ing records about individuals main- tained by a healthcare provider, or the enrollment, payment, claims adjudi- cation, and case or medical manage- ment record systems maintained by or for a health plan. Although this defini- tion is narrower than the one proposed in 2019, it is still sufficiently broad to include EHI that ASCs might be inter- acting with.

The definition of “providers” that are subject to information blocking oversight was unchanged from the pro- posed rule. The definition includes pro- viders outlined in section 3000(3) of the Public Health Services Act (PHSA), which explicitly includes ASCs.

To define further what consti- tutes “information

blocking,” ONC

Two of eight exceptions in the rule that would absolve a party from charges of information blocking might apply to ASCs.”

—Alex Taira, ASCA Only developers of certified health

IT are subject to regulation by the information blocking rule. If a health IT developer offers a certified prod- uct, then they are responsible for all EHI that is stored, accessed and exchanged in all their products, not just the certified module. If a devel- oper does not offer a certified product, then they are not liable for any penal- ties for information blocking.

Information Blocking Exceptions The actors listed above are who is regulated under the rule, but the rule doesn’t speak to what is being regu- lated in the first place. As previously mentioned, the Cures Act defines “information blocking” as prac- tices “likely to interfere with, pre- vent, or materially discourage access, exchange or use of electronic health information.” And again, any of the actors listed above found to be practic- ing information blocking could be sub- ject to penalties.


has decided to outline exceptions. The eight scenarios delineated by ONC in the final rule give scenarios that, if occurring, would absolve an actor from penalties for information blocking: 1. Preventing harm exception 2. Privacy exception 3. Security exception 4. Infeasibility exception 5. Health IT performance exception 6. Content and manner exception 7. Fees exception 8. Licensing exception More information on each excep- tion can be found at curesrule. The privacy exception asserts that “It will not be information blocking if an actor does not fulfill a request to access, exchange, or use EHI in order to protect an individual’s privacy.” So, for instance, if an actor such as an ASC does not fulfill a request to share EHI to protect a patient’s privacy at the explicit request of the patient, then that actor will not be found to be information blocking. Another exception that may apply to ASCs is the content and manner excep- tion. This exception would allow an ASC flexibility in fulfilling a request for EHI if the ASC was unable to pro- vide the EHI in the manner requested. For example, an ASC might encounter a situation where a health system or net- work requests EHI via a certified EHR module. If an ASC does not have a certi- fied EHR and cannot fulfill the request, it is not automatically found to be infor- mation blocking. ONC has delineated a stepwise approach for determining an alternative manner, such as transferring via a nationally accredited data transfer standard, or, at the very least, an alter- native machine-readable format.

Page 1  |  Page 2  |  Page 3  |  Page 4  |  Page 5  |  Page 6  |  Page 7  |  Page 8  |  Page 9  |  Page 10  |  Page 11  |  Page 12  |  Page 13  |  Page 14  |  Page 15  |  Page 16  |  Page 17  |  Page 18  |  Page 19  |  Page 20  |  Page 21  |  Page 22  |  Page 23  |  Page 24  |  Page 25  |  Page 26  |  Page 27  |  Page 28  |  Page 29  |  Page 30  |  Page 31  |  Page 32  |  Page 33  |  Page 34  |  Page 35  |  Page 36  |  Page 37  |  Page 38  |  Page 39  |  Page 40  |  Page 41  |  Page 42  |  Page 43  |  Page 44  |  Page 45  |  Page 46