Tuesday, January 19, 2010

Solving Secure Transport

I've written extensively in my blog about the need for the healthcare IT industry and government to implement a single (or maybe 2) ways to transport healthcare data securely. I feel that content and vocabulary standards are on the right track, but transport is still in need of a breakthrough. Here's a brief description of where the industry is today:

e-Prescribing - transport is an industry specific SOAP 1.2 implementation by Surescripts

Administrative - transport is often CAQH Core Phase II, an industry specific SOAP 1.2 implementation. The Workgroup for Electronic Data Interchange (WEDI) has suggested SMTP, so currently CAQH and WEDI are debating transport.

Lab - transport is Minimal Lower Layer Protocol (MLLP) and TCP/IP

Personal Health Records - Google and Microsoft Healthvault use proprietary RESTful approaches

Federal agency submissions (Social Security Administration, Food and Drug Administration) - NHIN FHA Connect, which is XDS.b, a specific implementation of SOAP 1.2

Clinical summary exchange - heterogeneous as implemented by various stakeholders

What is needed in the short term?

1. The Clinical Summary exchange transport is the place to focus, which is what we've done in Massachusetts with the NEHEN CDX gateway. An industry or government reference implementation that becomes widely adopted would help significantly.

2. Many Personal Health Record vendors have told me that they are ready to create a single RESTful front door for their PHRs to receive information.

3. Some industry stakeholders have talked about creating open source and vendor supported health hub software that offers SMTP, SOAP and REST in an appliance.

Of course, there could be other approaches.

There is an emerging technology, just implemented by eClinicalWorks in their EHR. It's called eClinicalWorks P2P and it works like linkedIn, Plaxo, Facebook i.e.

I'm a clinician and want to share patient data (after obtaining patient consent) with another clinician. I send an invite via regular email (SMTP ) that contains an embedded URL. If the clinician accepts the invite, that clinician is added to my "friend" list and I can push a record to them at anytime, which is delivered as a URL via email. Interestingly, if the clinician uses eClinicalWorks, my EHR can natively send and receive CCD's with "friends" via a RESTful approach.

Meaningful use requires many data exchanges among stakeholders. I'm confident that we'll see several reference implementations in 2010 that will accelerate interoperability by unifying approaches to transport.

4 comments:

  1. John -

    Reiterating my comment regarding a RESTful API - we have the hData Network Transport at http://tinyurl.com/ylljs7p which describes a very simple RESTful API for health data exchange. Our core idea is to look at the individual data points within a complete record and define a canonical way to create, update, and delete those data items. It maps nicely to existing CCD standards (such as the C32 family), and introduces a number of new features such as near-real time updates through subscriptions.

    Best,

    Gerald Beuchelt

    ReplyDelete
  2. Your examples for personal health records and clinical summary exchange are both RESTful and both carry a similar CCR / CCD payload. Once your EHR implements the Facebook model for email invitation, what limits the clinicians from using exactly the same interface to send the clinical summary to the patient or anyone the patient designates?

    I can imagine three kinds of solutions:

    a) Policy restrictions - discipline a clinician that sends a clinical summary to a patient

    b) Directory restrictions - maintain a directory of approved email-recipients

    c) Consent restrictions - provide a clear and fast interface for the patient to add a consent

    Much of the early work on the National Health Information Network (NHIN) and the HITSP standards seems to have focused on b) and this may be the reason why neither has embraced RESTful architecture.

    Patient-centered architectures, of necessity, focus on c) and adapt the need for directory restrictions only as needed for their particular customers. This is a powerful driver for innovation. You and the folks at ONC are to be congratulated for allowing REST and CCR to be part of the federal specifications.

    ReplyDelete
  3. Wouldn't this all be easier if the States had public healthcare and one medical record for each person?

    ReplyDelete
  4. But is the security of information really going to provide the value expected of it?

    As much as CIOs are concerned with information security, what if information security is a symptom of another underlying problem?

    ReplyDelete