The Office of the National Coordinator (ONC) released its long-awaited proposed rule on interoperability and information blocking, the 21st Century Cures Act, by identifying conduct that is not information blocking. If finalized, ONC’s proposed rule would have a significant impact on data sharing arrangements and other relationships among health care providers, health IT developers, and other stakeholders.

The Groundwork

In 2016, President Obama signed into law the 21st Century Cures Act (CURES). CURES amended the Health Information Technology for Economic and Clinical Health Act (HITECH), requiring HHS to develop a strategy, define terms, and make recommendations for the purposes of reducing the administrative burdens relating to the use of electronic health records (EHR). CURES defined “information blocking,” authorized HHS to identify reasonable exceptions to the definition of information blocking, and granted HHS the authority to investigate information blocking claims against health information technology developers, health care providers, and health information exchange or networks engaged in information blocking. If after an investigation, HHS finds that an EHR vendor, technology developer or health information exchange has committed information blocking may be subject to a civil monetary penalty. Health care providers will be subject to as yet to be defined “financial disincentives”, probably related to their reimbursements or participation in the Medicare and Medicaid programs.

What Is Information Blocking?

Information blocking occurs when a person or entity, usually a health care provider, information technology (IT) developer, or EHR vendor, interferes with the exchange and use of electronic health information. The three elements that comprise information blocking are: (1) an act that interferes with the permitted or authorized exchange or use of electronic health information; (2) the actor knows or should know that the actions are likely to cause such interference; and (3) under the circumstances, there is no reasonable justification for engaging in the act that caused the interference.

The interference with the exchange or use of electronic health information can occur in many forms, directly and indirectly. For example, cost-prohibitive fees for the transfer of electronic health information or restrictions incorporated into entity policies or contracts that prohibit the exchange of electronic health information would both be considered instances of information blocking. Information blocking interferes with the exchange or transfer of electronic health information by preventing individuals from immediately accessing their EHR, and it restricts providers from exchanging data necessary for effective patient care.

CURES also established seven exceptions to the definition of information blocking, which include actions to prevent patient harm, promote privacy and security of data, recover costs for data transfers, license interoperability elements necessary for access to electronic health information, or to maintain or improve health IT performance.

Application Programming Interfaces

Last month the Office of the National Coordinator for Health Information Technology (ONC) released the mandate of CURES. CURES set out a requirement that the exchange or use of electronic health information must be done “without special effort.” In efforts to satisfy this requirement, the ONC has adopted the use of Application Programming Interfaces (APIs), namely Fast Healthcare Interoperability Resources (FHIR), as a central component to their approach to interoperability and further enabling patient access to personal health information. APIs are standardized software intermediaries or interfaces that allow two applications to communicate or transmit data to each other, regardless of how they were originally developed. The proposed rule outlines specific criteria for APIs to ensure uniform deployment, including but not limited to technical, security, and access requirements to easily share electronic health information.

In addition, the ONC also outlined the guidelines for recouping costs and expenses incurred when developing, maintaining, and upgrading API services. According to ONC, health care organizations are using APIs to create interoperability between apps, EHRs, and other data exchange tools and to manage the flow of electronic health information between systems, making it possible to access the data faster and with more efficiency. More broadly, HHS is moving towards the widespread use to APIs in an effort to make EHR data accessible to authorized users while protecting the data from external threats.

However, there are concerns that ONC’s purported security standards for APIs lack rigor and little oversight or surveillance. API developers and apps are generally not subject to the requirements of the HIPAA Privacy Rules that restrict the disclosure individually identifiable information to third parties leading to concerns over data sharing and privacy practices.

Learning More About the Proposed Rule on Information Blocking

ONC has developed an in-depth series of materials to accompany the proposed rule including fact sheets and recordings of a webinar series to explain key provisions of the proposed rule.

New OCR FAQs on Patients Requests to Access Their PHI Through APIs

The HHS Office for Civil Rights (OCR) has recently released a package of FAQs to address the HIPAA Privacy Rule patient right of access to their PHI, Apps, and APIs. The FAQs are intended to steer health care organizations towards acceptance of “apps” designated by individual patients and application programming interfaces (APIs) used by a healthcare provider’s electronic health record (EHR) system.

The FAQs clarify that once protected health information has been shared with a third-party app, as directed by the individual, the HIPAA covered entity will not be liable under HIPAA for subsequent use or disclosure of electronic protected health information, provided the app developer is not itself a business associate of a covered entity or other business associate.  However if the app was developed to create, receive, maintain, or transmit ePHI on behalf of the covered entity, or was provided by or on behalf of the covered entity (directly or through its EHR system developer, acting as the covered entity’s business associate), then a business associate agreement would be required.