Wednesday, January 13, 2010

Sharing Data per Patient Preference

One aspect of the Interim Final Rule and Meaningful Use is the notion of sharing office summaries and transitions of care with patients electronically. The vendor community does not currently have a unified strategy to do this.

Although the Interim Final Rule describes the content and vocabularies for the clinical summary record, it does not provide implementation guidance for transmitting that record to the patient's preferred repository - a PHR, secure email, fax, or mobile storage device. Additionally, ambulatory offices and hospitals do not have a workflow defined that enables them to accomplish this task.

There is the FHA Connect NHIN project which clearly defines a mechanism for sending records to and among Federal agencies, but there is no project to connect existing personal health records, patient portals, secure email, and fax via a single easy to use approach.

There are several possible architectures to enable patient data to be routed

a. A mechanism to leverage existing email systems with added security (SMTP over TLS). For a broad discussion of these issues, see Wes Rishel's blog

b. A gateway (vendor provided or open source) that sits on the edge of a provider network and is capable of interacting with PHRs, email systems, fax systems, or patient controlled data repositories.

c. An industry standard API that would serve as the virtual front door to every PHR, so that EHR vendors could easily route patient records to the PHR of a patient's preference. For example, every patient could get a standard URL i.e.

http://www.google.com/health/jhalamka

http://www.healthvault.com/jhalamka

http://www.patientsite.org/jhalamka

and with this URL, the EHR or Hospital Information System could use a RESTful protocol to send a summary of care to the patient's desired repository.

Providing a mechanism for secure, simple transmission to the site of patient's choice will put the consumer at the center of the care process - ensuring the patient gets electronic copies of their records at each transition of care and access to educational materials so that patients understand their diagnoses and their medications. The result will be more shared decisionmaking, enhancing the patient/provider partnership. Once the data is stored in the site of the patient's preference, the patient could choose to share their data for clinical research, public health surveillance, or coordination of care with other clinicians via a local health information exchange or the FHA Connect NHIN approach.

My comments on the IFR and NPRM will include the need for this work.

8 comments:

John Moehrke said...

You indicate "The vendor community does not currently have a strategy to do this.". I think you must have meant to say that there is no single best solution that has weathered experimentation.

First, you are presuming that participating with a consumer must be a 'push'. This is an architectural choice, but why is it a requirement? In other discussions I see far more openness to architectures, yet here it must be a push.

Second, HITSP has provided multiple solutions offering multiple topologies. This is offered because at this point it is not clear which topology will be best: push vs pull, web-services vs RESTful, networked vs removable-media. So HITSP offers all of them, yes all of them: See IS03, IS05, and IS12.

And they are all based on standards that were developed using an open consensus process that includes a formal ballot process, not a proprietary decree. These standards were selected by the HITSP open process and assembled into the workflow requested by HHS/ONC.

sdowns said...

John,

I'm intrigued by solution "c." What would it take to get that going?

- Steve Downs

Adrian Gropper said...

It was wise of ONC not to over-specify the architecture. The Interim Final Rule specifies the content and the vocabulary and seems to be challenging vendors and practices to work out the architecture.

The EHR vs PHR distinction is secondary. The Interim Final Rule seems compatible with both institution-centric and patient-centric health IT architectures. An EHR that supports a patient-centered architecture will, of-necessity, implement a free, simple and accessible interface to other vendors - including competitors - just as email interfaces are supported on the web and DICOM interfaces are supported in radiology.

An EHR based on institution-centric architecture will continue to charge for complex interfaces as is common in the HL7 world and they may assume that gateways or regional exchanges will take care of interoperability with other institutions, service providers and yes, patients.

ONC seems to be promoting innovation by allowing the doctors and hospitals to choose between monolithic or modular EHR architectures and challenges the modular vendors to demonstrate effective support for free, simple and accessible interfaces to other vendors.

gershater said...

I am sure that "e-patient Dave" loves this approach.

My concern is patients who are technical enough to share their data wisely and appropriately. I am sure there will be many security issues and nefarious scams encouraging patients to unwillingly share their private data.

Anand Shroff said...

John,

Very interesting post. Clearly multiple architectures are appropriate - no one clear winner yet. We've chosen approach B as our interim strategy and are in the process of deploying a gateway in some of our HIE communities that will push data into PHRs of the community's choice.

Gerald Beuchelt said...

John and sdowns -

We already have a proposal for c. - hData (see http://projecthdata.org/). Within this project, we propose a very simple RESTful API for health data exchange. The framework is flexible enough to allow for a very diverse set of content, and we have already made available a set of C32/C80/C83 aligned schemas that can capture the content of a CCD.

Regards,

Gerald Beuchelt

gwt said...

Patient URL is a great concept and could potentially any EMR vendor to use REST or WSDL .. protocol. However another mechanism needs to be defined - something like an OAAuth .. so you don't have "unauthorized" entities posting junk to the URL.

Jeff Brandt said...

There are three subjects here; transport, security, and packaging.

First the transport, weather it is REST, SOAP or secure FTP all of these are fairly simple, Lets just pic one. My vote is REST. Vendor can provide tools to transform, i.e., gateways.

Packaging of the data, we have several standards currently being used; CCR, CCD and HL7 V3 (soon to be). HITSP supports the CCD but this will eliminate connectivity of most PHR which support only the CCR. How about supporting both as HealthVault does today. Again a transform gateway can handle most of the problem.

Patient matching algorithms are probably one of the biggest issues and where a lot of the work will end up being.

As for the personal URL, love the concept, It is a lot like a National patient Id but not called that.

Jeff Brandt
www.hieconnect.net




Security; There is a reliable PKI system used for most secure transfers today.