This is the fourth of a 4-part series on the HIPAA implications of Health Information Exchange (HIE). ). In the first part, we reviewed Community-based Chart Sharing; in the second part, we reviewed point-to-point connections. In the third part, we reviewed the Library-style approach to HIE. In this final installment, we will try to present a framework for HIPAA that can address all 3 HIE styles, and at the same time keep a unified, simple approach for patient permission-giving.
HIPAA, the Health Insurance Portability and Accountability Act, governs the electronic sharing of a patient’s health data between “covered entities.” The basic concept is that patients “own” their own health data, and physicians are custodians of that data (and, in fact also “own” the information about a patient that they create – their medico-legal documentation of health care rendered). As custodians, physicians are entrusted with this privileged data, and can only share it with others upon permission from the patient.
If unintended access to a patient’s record should occur, that is considered a breach. If a breach is discovered, the “covered entity” must inform the patient promptly – failure to do so carries significant penalties. If a large breach occurs, then the federal government needs to be notified as well. The Office of Civil Rights is responsible for HIPAA breach enforcement.
HIPAA has two components: Security and Privacy. The issues involved are different, and should be considered as separate discussions.
HIPAA Security concerns itself with safeguarding patient data where it resides, as well as when it is transported between places (like between referring doc A and recipient doc B). Much of this is technical (the way in which protection and encryption are managed), but some of it is administrative (like regularly reviewing audit logs to identify any potential breaches, or having employee sanction policies in place).
Part of Meaningful Use (the federal EHR Incentive Program) is for each practitioner who uses an EHR to conduct a Privacy and Security Audit, including identifying vulnerabilities, having a plan to remedy vulnerabilities when they are found, implementing an employee sanction policy, and conducting regular audit log reviews. Since this is incumbent on every physician, we have built a resource that medical practices can download and use in order to achieve this Meaningful Use core requirement.
Intermediaries of the Protected Health Information (PHI) entrusted to “covered entities” (CEs) must have a Business Associate (BA) agreement with the CE – after all, it is the CE who is ultimately responsible for ensuring the security of PHI. A BA may also have subsidiary BA agreements with any ancillary services used that may handle PHI in some way.
For example, a web-based EHR (like Practice Fusion) has a BA agreement with the physicians who use the service (part of the End User License Agreement, or EULA). For Community Chart-Sharing, this is all that is needed, since this form of HIE does not involve any PHI leaving the web servers of the EHR.
When point-to-point connection is used, there can be two scenarios: (1) the physician end-user locally sends data using something available locally (like a Direct Project message), or (2) the EHR centrally sends information to a destination on the physician’s behalf. In the first setting, the physician (the CD) needs a BA agreement with the sending service (usually part of its EULA). In the second scenario, the EHR has the BA agreement with the sending service (a subsidiary BA), and the use of such subsidiary BA’s is allowed in the primary agreement with the end-user (the CE).
The security arrangements of BA’s is similar for library-style HIE. If the intermediary service is one that keeps a copy of the content of the data being sent, then the BA agreements need more complexity, acknowledging that the HIE is entrusted with copies of PHI and must adhere to HIPAA Privacy and Security. But, otherwise, it is the same: if a doc (a CE) engages an HIE locally (such as manually uploading an HL7 file created by the EHR but dropped onto the local user’s computer), then a BA (in the EULA) is set up by the doc; if the library-style HIE is engaged centrally by the EHR, then a subsidiary BA needs to be enacted that addresses those issues.
As one can see, the BA relationships between (potentially) several intermediaries that transport health information about a patient from doc A to doc B can be complicated. That is why the security issues should be the detailed purview of BA agreements between parties, so that transport of data from its source to its destination is maintained securely.
This can be daunting and overwhelming to a patient. The privacy permission should be a single, simple gesture. “Get these elements of my health record from doc A to doc B.” General language can state that any/all intermediaries in the transport of that PHI will be assured by the requisite BA agreements. The public reassurance needs to be that “only what you give permission for is shared between specific identified parties” – PHI will not leak out of that pipe, regardless of the path that the pipe takes in getting it done.
What should not happen is for regulation to require that a separate permission be granted for each step of the way – that can be too onerous. Confusion about this will likely result in the patient balking (out of incomplete understanding and assurance in an increasingly complex network) and the intent of HIE and data sharing between clinicians will be broken. We need to keep it simple. A single gesture of permission should cover the whole process of getting specific PHI from doc A to doc B; protection of the whole “chain of custody” should be encompassed by that single gesture. The specifics of how to safeguard the “chain of custody” is addressed by the BA agreements between intermediaries. But, from the patient perspective, a single “permission gesture” needs to cover the whole intended process.
This is the final installment of our 4-part series on the HIPAA considerations of HIE. This is a very hot topic in health policy circles on the national level. Practice Fusion is an active participant in these discussions, as our web-based EHR has a very large footprint among ambulatory practices, especially small and solo practices in community-based settings not affiliated with any particular institution. If you have insight or comments that would help us better represent our unique perspective in these discussions, we welcome your commentary.