HIPAA and HIE – part 3: Library-Style Connection

This is the third in 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 this installment we will review the library-style approach to HIE. In the 4th article we will try to present a framework for HIPAA that can address all 3 HIE styles, and at the same time “keep it simple” for the patient end-user.

This third in the series will examine the library-style method of exchanging health information.

Library-style data sharing
Sometimes, getting a patient’s health data from one physician (doc A) to a recipient (doc B) involves passing the data through a conduit that keeps a copy of the information that is passed. The important distinction between this method of data transport and the simpler point-to-point connection described previously is that a copy of the actual data content is kept by the data-exchange intermediary.

In essence, the intermediary acts as a library. The sender (doc A) uploads the patient data into the library (“push”) – an alert to the intended recipient (doc B) may be generated indicating that there is new data on that patient. Doc B can then query the library and retrieve the data that has been uploaded (“pull”).

Immunization Registries represent an example of this kind of approach. Upon giving a patient an immunization, that data can be uploaded into a regional or state Immunization Registry – either through a manual web portal supplied the Registry, or directly from the EHR. In fact, one of the menu-set Stage 1 Meaningful Use specifications lays the foundation for doing this automatically, though the connectivity pieces are not yet fully mature on a national basis. Once this kind of connectivity is mature, an EHR can both upload and also download immunization data from the local Registry, and augment the local EHR data with vaccinations given to the patient by others outside the practice.

Many of the federally-recognized Health Information Exchanges have approached data exchange this way. This allows for asymmetric data transfer, much like email – the recipient (doc B) does not have to be on the line in order to get the information (as might be the case with point-to-point connection). Hospitals can upload their information to the library-style HIE, and community docs can retrieve it when they need it.

There are also private companies emerging in the Health 2.0 innovation environment that have approached health data exchange this way – upload data (structured data, free-text data, even scanned .PDF documents), and the data is then tagged for subsequent retrieval and stored in a central repository. Then, on demand, the data repository can be queried (even using free-text natural language querying, similar to Google searches), and whatever has been uploaded (from whatever multiple sources) can be retrieved on that patient. Of course, proper tagging and privacy of that data is enforced, so that only those requestors that have permission can access this Protected Health Information (PHI).

Challenges with library-style HIE
By adding a middle layer of PHI accumulation between the sender (doc A) and the recipient (doc B), a new level of security and privacy is introduced. Neither doc A nor doc B may be aware of any details of this intermediary source.

A sophisticated way of tagging the data that is uploaded, such that specific permission as to who has access to view it downstream, needs to be in place. HIPAA Business Agreements need to be in place to cover these intermediaries. This is true regardless of whether the library-style HIE is an Immunization Registry, a state-sponsored public-health-oriented HIE, or a private commercial company.

To date, most library-style HIEs have required that only highly standardized file types be uploaded (mainly because the HIE is unable to handle anything not in a specified format). This can be HL7 Immunization Record standards, or CCRs, CCDs, CDA or other types of HL7 documents. Both the sender and the recipient need to be able to create and consume files of the particular standard. This tends to limit the use of such HIE libraries, though newer technologies are now emerging that allow more sophisticated data tagging, which can upload and manage a much broader range of data types (even data that only exists on scanned .PDF documents).

The value of a given HIE library, then, is a function of the number of connections they make. If a library can aggregate data from hospitals, labs, and multiple doctors offices (which may use a variety of EHRs, or may all use the same EHR), then it is valuable; if there are only a few connections, then the value drops off. Like with cell phones, the value of the device is a function of the network (more than the device itself). To date, what few HIE libraries that currently exist do not have a robust client/subscriber base – unless this hurdle can be overcome, such HIEs will not be successful.

This is the third method of Health Information Exchange models we will review. In the next segment, we will try to pull it all together and address how HIPAA can address each of these information-sharing scenarios in a unified way.