Wes Rishel

A member of the Gartner Blog Network

Wes Rishel
VP Distinguished Analyst
12 years at Gartner
45 years IT industry

Wes Rishel is a vice president and distinguished analyst in Gartner's healthcare provider research practice. He covers electronic medical records, interoperability, health information exchanges and the underlying technologies of healthcare IT, including application integration and standards. Read Full Bio

Coverage Areas:

Simple Interop: the PHR

by Wes Rishel  |  December 31, 2009  |  4 Comments

This post seeks not to define the full scope of interactions of a PHR but simply to define a simple connection between PHRs and other health IT systems. We make two claims for this approach. (1) it greatly simplifies the roll-out of connections between PHRs and other healthcare IT systems, thus accelerating the roll-out of EHRs that can meet anticipated requirements for meaningful use in 2013; and, (2) the combination of this link with our other simple interop proposals comprises a national health internet for the U.S. that allows substantial progress unimpeded by the slow pace of the resolution of policy issues around information sharing.

In our definition we provide a minimalist definition of the PHR, taken from the ARRA. We don’t begin to describe the advanced capabilities that could be built on such a record. A PHR is characterized by giving control of personally identifiable information to the consumer or someone using the PHR on behalf of the consumer. As an exemplar Gartner clients can read my November 2007 analysis of the Microsoft HealthVault privacy policy at Microsoft HealthVault Is One Important Step Toward a Workable Personal Health Record. However we do not rely on anything specific to Microsoft or any other vendor in these definitions. We are satisfied to know that consumers are willing to trust the vendor of whatever PHR they choose.

The PHR limits sharing of the consumer’s protected health information (PHI) to those transfers where the consumer has given explicit consent. Such transfers can be incoming to the PHR or outgoing to another health IT system. The transfers may happen one-time or the consumer may give consent for recurring transfers. The PHR need not enforce most jurisdictionally-specific requirements for limiting data exchange. Explicit consent from the consumer trumps most of those requirements.

There is the opportunity for those that offer PHRs to be endlessly creative in finding ways to provide value to the consumer based on her accumulated health information. Whatever their full value propositions it seems likely that they all have to include solutions to certain problems:

  1. Receiving information about the consumer from multiple healthcare organizations (HCOs) and associating that information with the correct consumer (even though each sending organization has a different ID for the consumer)
  2. Delivering information to authenticated healthcare organizations as directed by the consumer, identified so that the receiving healthcare organization can file the information properly by patient.

We would like to encourage the developers of PHRs to enhance their business value by designing new ways to interconnect with other health IT systems. New ways will often involve proprietary interfaces. At the same time, we believe PHRs should support a simple, “least common denominator” interface that is very easy for developers of EHRs to implement. Such a common interface is a necessity if a substantial number of EHRs will be able to implement connections to the PHR of the patient’s choice in 2013 in order to meet expected requirements for meaningful use.

The approach specified in Simple Interop: The Health Internet Node provides a straightforward way to provide standard support for these functions. The key to this approach is the the  health email address. It is an Internet email address for which the domain name is a health domain name. The user name is assigned arbitrarily the organization that operates the health Internet domain. There is no a priori reason to believe that wrishel@BigBoxStore_clinic.com, wrishel@StJosephsEureka.org and wrishel@MyFavoritePHR.com are the same purpose or to know for certain that any of them has the last name “Rishel.”

All operators of PHR would agree to certain premises for communication of protected health information. They need not agree to use this approach to the exclusion of other communication approaches, but the one described here would be common to all PHRs.

The PHR would

  • Have a health Internet domain for the purpose of accepting email transmissions from and sending them to other health Internet domains.
  • Assign health consumer emails addresses from their health Internet domain to the subjects of personal health records. (Sidebar, this is not always the user of the PHR, since the user may be a parent, adult child or other representative of the consumer)
  • Allow subjects to have multiple email addresses concurrently while keeping a common record of information collected for the subject via multiple email addresses.
  • Allow subjects to discontinue the use of any of their email addresses in the PHR domain upon request.
  • Accept incoming email according to the rules for a health Internet node (TLS and only from other healthcare domains) and file the information contained in the mail in the PHR of the subject related to the email address.
  • Accept instructions from authenticated PHR users to send selected information about the subject to another health Internet address (presumably that of a healthcare organization).

All the points above about multiple health email addresses for a subject combine to meet two goals: (1) to enables people to assure that their health email addresses to not constitute an ad hoc key to all their protected health information; and, (2) it enables users to deal with a compromised health email address with no more difficulty than dealing with a compromised credit card number.

How Relationships Are Established
Patients that use PHRs would have established a health Internet address associated with the PHR. They would give this information to their healthcare provider. The healthcare provider could use it to exchange secure email with the patient. It could also use it to dispatch specific or recurring reports of visits to the PHR of the patient. Hopefully these payloads will be structured to the maximum extent practical but we wouldn’t rule out simple email messages typed by the physician and PDFs where they made sense.

PHRs receiving the information would rely on the security associated with health Internet nodes to affirm the sender of the document.

Providers that are able to receive information from PHRs would, at a minimum be able to give their health Internet address to the PHR vendor when giving consent to send information. In following the guidelines we describe for a health Internet link they would confirm that the receiver has a current, unrevoked digital certificate each time they use TLS to send information to the domain name in the provider’s health Internet address.

Emergency Health Summaries
We are trying to avoid dictating or assuming what functions would make business sense for providers of PHRs Nonetheless, we have to mention that many of them will want to support the release of information under circumstances where the patient cannot get on-line to give consent. They could be being treated for problems that interfere with their dexterity. They could be being treated in a location where consumer Internet access is not practical. They could be unconscious.

Once a patient has authorized the PHR operator to release information under such extraordinary circumstances, we can imagine any number of ways that a vendor might decide to accept the authorization. The user could carry a card with a freely accessible URL for the PHR, the consumer’s PHR-issued health Internet address and a “break the glass” authorization code that is only valid for a short period after it is first used.

The vendor could accept faxed requests showing a copy of the card and then go to some lengths to verify that the request came from a valid provider. We can imagine that some vendors would offer better (and more expensive) services such as a key fob barely bigger than a USB port that automated connecting to the PHR operator’s portal and uploading the patient’s identity information. Cell-phone pictures of bar codes on the card come to mind. The point here is not to specify standard gadgetry but enable the market to settle on some that provide a reasonable value proposition.

As the notion of Simple Interop grows PHR operators will likely find it convenient to print on the card a health internet address for incoming requests, such as emergency@medinfo.biggerbetterPHR.com.

The CDO might email in the request from ED@medinfo.humongousuniveristy.edu.

When a CDO chooses to use simple interop email the PHR vendor may use the fact that the request came in from a valid a valid healthcare domain name as part of their rationale for determining that it is okay to send the information.

Likewise, PHR vendors can vary in terms of what information that patient can pre-authorize for transmission. One might offer a specially constructed summary of problems, meds, allergies and the names of CDOs that have treated the patient. Another may offer the most recent report that appears to be a patient summary.

We expect that most vendors that include “break the glass” service in their value proposition will want to be able to send the information to CDOs with as few preconditions on the IT capability of the CDO as possible. As such, they will no doubt offer delivery modes that include fax and display on a browser for printing.

As the notion of simple interop expands we would expect they would also find it convenient to deliver the information to the health email address of the CDO and to deliver it in a multipart format that allows it to be viewed and printed, but also allows those CDOs with suitable EHRs to import structured data into their system.

This exemplar of a patient-carried emergency access card illustrates multiple uses of the health Internet address, one for the patient and one for the PHR operator that provides the emergency information service.

HInternetcard

To repeat: we are not suggesting or prescribing specific PHR approaches to this important function. We only mean to indicate how simple interop would evolve into a key alternative for facilitating the interactions, particularly as the ability to work with structured informational attachment becomes widely available.

Nationwide Health Information
This blog post creates linkages between two domains of health information sharing that are separated by the manner in which consent to share information is managed. By definition PHRs exchange information when authorized by the patient or his agent. The other information-sharing domain that we have described is for secure exchange among healthcare organizations where the sender relies on external means to determine that the receiver should legally receive the information.

We have used the fax machine as an analogy for information sharing in this second domain, but of course we mean to imply that, unlike faxes, the information being shared can also be in standard structured formats such as those described in the interim final rule Health Information Technology: Initial Set of Standards, Implementation Specifications, and Certification Criteria for Electronic Health Record Technology. (As of 30 December this IFR is “on display” at this link. It is expected to be in the Federal Register on 13 January.)

Linking these domains together with few other restrictions provides broad opportunities to establish interoperability without making assumptions about the availability of intermediary organizations. Where an HIE is established it can work as a proxy for a healthcare practice, providing the health Internet node for communications. At the same time the HIE may provide many other value added services to a community.

Where an EHR vendor provides systems to small practices it can operate a health Internet node on behalf of their customers.

If it makes business sense a hospital or an ISP may work to qualify themselves to operate a health Internet node and provide services to physicians that only have email or Web support.

Where other policy concerns require the full complement of IT services defined by the NHIN Trial Implementation project there should be no barrier to using those protocols. In the long run, because they offer more complex ways of resolving consent and other policy issues and more security they could come to be the approach chosen vendors and users of health IT.

These relationships are illustrated in the figure below.

HInternet

4 Comments »

Category: Healthcare Providers Interoperability Vertical Industries     Tags: , , , , , , , , , , , ,

4 responses so far ↓