Intro

This paper proposes a solution to privacy and liability issues raised by the exchange of private health information over the Internet. The health care system is modeled as a collection of service providers communicating with each other over the Internet. Patient identity, identity credentials, trust between communicating providers, federation of services that trust each other and patient consent for release of private information are difficult concepts for a service provider to master even in a traditional mail and fax infrastructure. The first part describes user identity and digital identity credentials on the Internet. The second part introduces the concept of addressing private health information using a patient’s digital identity on the Internet. The third part describes the role of trust between service providers or members of a federation. Finally, the paper shows how moving beyond trust to patient control can drive viral adoption of patient-centered health information accounts on the Internet.

Identity and Credentials

Few would argue that a passport or equivalent obligatory positive identity credential should be required to receive a private local service from a doctor or a lab. For cash paying patients at least, it seems reasonable for health care providers to accept any identity the patient presents. An interesting quandary arises when that doctor’s note or blood test is to become networked and accessible through a health information exchange (HIE). The use of inconsistent patient IDs across the scope of the exchange becomes an obvious patient safety issue.

The quandary arises as the scope of the exchange expands beyond a few local providers and over a patient’s entire life. Under these circumstances, a positive and obligatory ID brings the risk of inappropriate access and unintended consequences. A positive and obligatory ID is clearly sub optimal for national-scale or longitudinal health information exchange.

Identity on the Internet is neither positive nor obligatory. Email addresses, for example, are not positive since people have multiple emails that change over time. Email addresses are hardly obligatory; even sites that require an email will accept a free and transient account. Unfortunately, email addresses are also very insecure and limited as a digital credential.

OpenID

OpenID is a newer protocol expressly designed for the purpose of asserting one’s identity in a secure and convenient way. OpenID is still in the adoption phase and is becoming more and more popular, as large organizations like AOL, Microsoft, Sun, Novell, etc. begin to accept and provide OpenIDs. Today it is estimated that there are nearly ten-thousand sites supporting OpenID logins. Used as a medical identifier, OpenID allows the patient a combination of safety in information exchange and the opportunity to restrict the scope of involuntary medical records aggregation. OpenID uses an independent identity provider as the person’s proxy on the Internet. Like the code keeper in a double blind research trial, the identity provider service can prevent any particular doctor or lab from making unintended use of information about a particular patient.

OpenID is easy to understand, it looks like a typical URL with a web host and a personal component. For example, https://johnsmith.pip.verisignlabs.com or http://openid.aol.com/johnsmith721 are valid OpenID. The simple idea is that any service provider can use the OpenID protocol to retrieve credentials controlled by the patient John Smith from the web site controlled and countersigned by their chosen identity provider such as Verisign or AOL.

OpenID inspires the HealthURL

How would OpenID work in health services? Upon registration, the health service provider’s software creates an account for that patient as always. The account is represented on the Internet as https://healthurl.mercyclinic.org/3274569172525933 or any other valid OpenID protocol identifier. Mercy Clinic is effectively saying: “We control the information in this account on behalf of the patient 3274569172525933″.

In this example, 3274569172525933 could have been assigned by the clinic as their patient ID or it could have been requested by the patient themselves. https://healthurl.mercyclinic.org/3274569172525933 is an example of a HealthURL. Any information the clinic is willing to exchange about this particular patient is secured behind the patient’s personal portal at this Web address.

A HealthURL makes privacy protections and confidentiality responsibilities easier for a consumer to understand. Security use the same encryption techniques (https://) employed in financial transactions. The institution responsible for securing the information and keeping it confidential (mercyclinic.org) is clearly shown. Finally, the patient account identifier (3274569172525933) replaces today’s byzantine and error-prone practice of combining name, date-of-birth and institutional identifiers as the basis for information aggregation. This protects privacy by making it easy and intuitive for a patient to understand how their information is aggregated and by allowing them to avoid disclosure of private information if they choose.

Health Information Exchange Example

We are now ready to consider health information exchange. Let’s imagine that John Smith gets an eye exam at Ostco and wants to keep his HealthURL up to date. To register with the optometrist, he simply logs into his HealthURL or OpenID provider and allows it to transfer https://healthurl.mercyclinic.org/3274569172525933 as their online health record identifier. With patient consent, allergies, a diagnosis of diabetes and insurance information could flow to the optometrist at this time as well. Registration is almost complete.

The Ostco optometrist software is also able to operate a HealthURL for their patients. The patient is offered https://healthurl.ostco.com/3274569172525933 (based on their current HealthURL) or https://healthurl.ostco.com/9234111733590602 (an entirely new HealthURL) just like they might be offered a new American Express credit card.

The optometrist and the clinic are competing for the privilege of managing the patient’s health information exchange portal just as AOL and Verisign are competing to mange the patient’s online identity and Amex is competing to be their credit card. This competition for the patient’s trust is what differentiates the HealthURL approach from centralized systems currently operated by a regional authority (RHIO), Revolution Health or Microsoft HealthVault.

In this particular example, the patient declines and keeps their HealthURL at Mercy Clinic. The results of the eye exam are sent to the HealthURL and will be available to the physician the next time the patient calls.

Federation 101

Legal contracts representing trust agreements between clinical services providers must be in place before information can flow. A federation can reduce the cost of putting trust agreements in place by defining a common set of policies and agreements applicable to all members. Federation agreements do not involve the consumer directly but the consumer often has a choice of which federation to use as we do daily in deciding between Visa, an ATM card and cash.

With reference to the previous eye exam example, what if the patient had accepted Ostco’s offer of a new HealthURL? Rather than send the result of the eye exam to Mercy, it is typically in the patient’s interest to consolidate their information at Ostco - otherwise, why open the new account? At this point the patient transfers their information from their old HealthURL to their new HealthURL and may ask Mercy Clinic to disable online access to https://healthurl.mercyclinic.org/3274569172525933 and access the patient’s online medical record at https://healthurl.ostco.com/3274569172525933.

The clinicians at Mercy Clinic are now faced with a simple choice. If they trust Ostco, they accept the eye exam and possibly other documents they find at the patient’s new HealthURL. Some of these documents would be unsigned, some may be signed by the Ostco optometrist and many would be signed by doctors at Mercy Clinic themselves.

Making information exchange decisions on a document by document basis is too cumbersome for routine clinical use. Mercy Clinic and Ostco management now have a potential interest to enter into a trust agreement that allows their clinicians and patients to exchange information under HIPAA and patient consent.

A federation to which both Mercy Clinic and Ostco subscribe makes the negotiation of trust cost-effective. Future health information federations may be established by a regional authority or by a dominant provider or as a community-led process. In practical terms, federation-capable HealthURL software at each institution allows an administrator to enable trust between HeathURL accounts hosted at the other institution as directed by management. Information exchange between members of the federation can proceed with or without direct patient consent as long as the requirements of HIPAA and state law are met.

Patient Control Options for the HealthURL

An institutional trust agreement or federation membership enables the patient to grant access to his HealthURL under HIPAA and applicable state law. However, a patient may also want to grant access to his HealthURL to caregivers, family members and supports that do not have a trust relationship with the service provider hosting their HealthURL. If the service provider allows the friends, family and external consultants feature they may incur some additional liability and cost. If they don’t, the patient may choose to move his HealthURL to one that does. The portable nature of HealthURL enables competition among health services federations just as phone number portability enables competition between telecom services providers.

Conclusion

The HealthURL is modeled directly on the user-centric design of the proven and respected OpenID protocol. Health information exchange among HealthURL service providers can operate point-to-point or with regional federation (including Regional Health information Organization or RHIO) under existing HIPAA and state privacy laws without additional patient involvement.

A patient-centered approach to information management encourages service providers to solve both privacy and interoperability problems by creating a competitive market for health information hosting. The distributed nature of HealthURL hosts promises scalability and rapid innovation as service providers compete on the basis of services, quality and price one patient account at a time.

When patient control is enabled, HealthURL access can expand beyond any pre-established federation, can encourage new national and global federations and may well ignite viral adoption of personalized medicine practices that are difficult to imagine without a patient-centered health IT architecture supporting the delivery of individualized health and wellness.