The Office of National Coordinator (ONC) for Health Information Technology has proposed a new rule to support seamless and secure access, exchange and use of Electronic Health Information (EHI). The proposed rule would require the patient electronic access to this EHI be made available at no cost.
The proposed rule aims to alleviate few challenges attributable to practices that ONC considers are likely to interfere with access, exchange or use of EHI. It aligns with CMS’s new regulation implementing the Cures Act provisions. The released rule regarding information blocking and API access to data are expected to have a transformative force on interoperability and the method of data exchange between patients, providers, plans, technology developers and other health care stakeholders.
What does the proposed rule say about Information Blocking?
There are few criteria that describe information blocking:
- An act or course of conduct that interferes with the ability to exchange or use electronic health information where permitted/authorized
- Actor should know that the actions are likely to cause interference
- Under the circumstances, there is no reasonable justification for engaging in the act or a course of conduct
- Information blocking is likely to prevent, interfere with, or materially discourage access, exchange or use of EHI when the entity knows it is likely to do so
- In the proposed rule it:
- Defines EHI;
- Provides a list of activities that would be possible to get in the way with access, exchange or use of EHI;
- Condition of Certification as provision for information blocking
Technology Impact
ONC proposes to use FHIR as the underlying standard to enable API access. Vendors should make a certain set of FHIR resources available that correspond to the USCDI, names API Resource Collection in Health (ARCH).
- It is proposing a new API certification criterion at 170.315(g)(10) to effectively replace the 2015 criterion (g)(8) that allowed access to each of the data categories in the CCDS. The new (g)(10) requirement should support the following use case:
- Patient access to their own data, and
- Population level access of data (such as a provider’s patient panel or all patients under a particular health plan)
- APIs must offer the following functionalities:
- Data response
- Search support
- App registration
- Secure connection
- Authentication and authorization (lever aging OpenID Connect Care)
- (g)(7) and (g)(9) to remain as it is
- Patients should get “persistent access” to their health information without having to re-authenticate for a proposed minimum period of three months
To enable a successful implementation of this rule, the technology vendors will need to extend their support to providers in US healthcare ecosystem. Health IT developers that have a Health IT module with capabilities that give access and exchange of EHI would be best suitable to participate in TEFCA and in a place to provide connection services to HINs.
To understand more about the proposed rule you can also reach out to us at info@nalashaa.com.