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.
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:
- 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)
- 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 firstname.lastname@example.orgPHR.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.
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.
View Free, Relevant Gartner Research
Gartner's research helps you cut through the complexity and deliver the knowledge you need to make the right decisions quickly, and with confidence.Read Free Gartner Research
Category: healthcare-providers interoperability vertical-industries
Tags: arra ehr health-information-exchange health-internet health-it health-record-bank healthcare-interoperability hrb meaningful-use nhin personal-health-record phr stimulus
Comments or opinions expressed on this blog are those of the individual contributors only, and do not necessarily represent the views of Gartner, Inc. or its management. Readers may copy and redistribute blog postings on other blogs, or otherwise for private, non-commercial or journalistic purposes, with attribution to Gartner. This content may not be used for any other purposes in any other formats or media. The content on this blog is provided on an "as-is" basis. Gartner shall not be liable for any damages whatsoever arising out of the content or use of this blog.