Every day I experience life in the world of healthcare IT, supporting 3000 doctors, 18000 faculty, and 3 million patients. In this blog I record my experiences with infrastructure, applications, policies, management, and governance as well as muse on such topics such as reducing our carbon footprint, standardizing data in healthcare, and living life to its fullest.

Tuesday, August 14, 2012

An Alternative HIE Architecture

Massachusetts has created a three year, three phased HIE plan based on "pushing" records from place to place, creating analytic repositories, and "pulling" data from providers based on a centralized consent repository/ master patient index. Here's a brief overview from an NPR broadcast yesterday.

We all want to solve the "Unconscious in the Emergency Department problem" which requires states/regions to build significant supporting components including a registry of all the healthcare institutions which a patient has visited and opted in for disclosure of records. Massachusetts has the funding and alignment of stakeholders needed to make this happen.

However, many states will not be able to create consent repositories and record locator services. Is there another approach that does not require significant centralized infrastructure?

BIDMC has created such a "pull" data exchange with the Social Security Administration.

Here's how its works:

The transaction was designed to be as simple as possible.

Social Security identifies themselves via a secure certificate and is considered a trusted partner. Then, Social Security computers send a secure SOAP request, including a scan of the patient's signed medical record release document and patient identifiers to servers at BIDMC. We store the patient release document in our logs. We look up the patient in our system and if we can reliably match the patient using multiple identifiers, we create a CCD/C32 (Summary of Care document) and return that to the Social Security computers via the secure SOAP response.

The transaction is a query/response model without any centralized infrastructure.

Since there are no widely implemented standards for consent data, we're using something simple - a TIFF that is a scan of the patient release document and patient identifiers.

No human reviews these TIFFs during the initial record exchange - the patient release document is stored and the response is sent immediately. If a question about the release arises, we have the original signed scan and audit trails to review.

The C32 document is sent via a secure, encrypted, session back to the Social Security Administration. If the session concludes successfully, then the document was received.

Thus, it is possible to "pull" records from an outside institution without any centralized indexes or registries - just send a scan of the consent with the electronic query for records.

Admittedly a statewide master patient index that includes consent to disclose records from specific institutions will scale better and enable targeted retrieval of data from each location where a patient has data, but for those who want a query response approach for retrieval of data from a specific institution, the Social Security Administration approach works well.

5 comments:

Since the Rishel/McCallie blog days of 2009/2010, I've always believed that the Direct protocols and associated trust fabric, along with built-in Message-ID support (see RFC 5322), allow the creation of the same pull semantics using a push-only building block (secure email). What's needed is a specification/agreement on the semantics of the payload (in your exampe: how to find and parse patient identifiers in the incoming message).

SOAP obviously works well too, but I've always held out hope that the possibilities of building complex workflows from the underlying Direct push-only protocols and trust fabric would become reality. We could all then focus on the payload semantics that would ride on top of Direct and implement a wide variety of workflows on a common foundation.