Uncategorized

Health Internet – The New Consumer-Friendly NHIN

Consumer directed HIE will become the most visible aspect of health IT stimulus and could lead a shift to consumer-directed health plans, increased interest in wellness programs and family-centered collaboration for the young, old and seriously ill.

At a recent Boston meeting on health records infrastructure, key stakeholders recognized the potential of patient control as a strategy to address privacy concerns that could otherwise limit ongoing health networking initiatives. MedCommons proposes one possible approach to making the national health information network (NHIN), currently conceived as a provider-to-provider exchange, consumer-friendly and consumer-accessible. We illustrate the need with a true story, propose a novel addition of independent identity service providers to the NHIN and then illustrate how this could be used to transfer the soldier’s CT to the US for a second opinion even as he’s being transported.

On the morning of the Boston meeting, a friend of mine called to say that his son was seriously wounded in Afghanistan and was being stabilized for transport via Germany to the US. He knew that his son had a CT in the field clinic and wanted to get it before the son was transported over four days through to Bethesda. Could the Health Internet be used to help this family?

The NHIN does not have to run like Big Brother. We propose a voluntary identity principle that distributes trust among multiple private and public institutions and gives consumers a choice of who controls their medical identity. Some might pick a particular hospital, others might choose their regional HIE while others could choose a private service such as a bank or telecom that is not a health care business at all.

The institution that manages a patient’s ID on the Health Internet is referred to as the IDP. To authorize health records exchange on the NHIN, an IDP would have to meet strict requirements and receive a NHIN Certificate. A NHIN Certificate is analogous to the SSL certificates issued to banks and other corporations on the Internet. Larger hospitals, military, VA and integrated delivery networks on the NHIN also hold a NIHN Certificate.

The issue and administration of NHIN Certificates could be handled by state or federal agencies or privatized to Verisign and similar services that already do this for the Internet.

We propose a Health Internet consisting of two kinds of certified entities, health care providers and identity providers. Both are chosen and trusted by the consumer but the identity providers are the key to effective competition and innovation.

Small group practices, insurance companies, web personal health records services and search engines would likely not carry NHIN Certificates and would participate in the Health Internet only under the control of the patient trough their IDP.

Substitutability, the central concept of the Boston platform meeting, is a key benefit of this proposal. An IDP that disappoints a patient could be swapped out without impacting the health care providers and a health care service that disappoints could be ignored or disconnected with a simple message to the IDP.

Public health and research users of the NHIN would not be affected since all entities that carry NHIN Certificates could still interact with each other directly under whatever rules and regulations the Certificates represent.

How would this have worked in the case of a soldier shot in Afghanistan and on his way to Bethesda?

– Before entering the service, the son might have picked Verizon as his IDP because they hold an HNIN Certificate and offer a family member override. He would have established the father, who also has a Verizon account as health care proxy.

– Upon induction, the health service saved the serviceman’s IDP selection (their Verizon health ID, possibly in OpenID format – see references below) along with the rest of his personal contact information.

– The father, when notified of the injury, is unsure which doctors will be available to consult on his son’s case, but needs to have the son’s CT scan at the ready as a first step.

– The father decides to do a transfer using a personally controlled health record service because it will give him control of the CT and make it easy to deliver the images to any physician that offers to help. Neither the father nor the health record service has a HNIN Certificate.

– The father goes to the military health service EHR portal. Without logging in, he goes to a form that requests his son’s Verizon health ID along with the MedCommons-type account ID where the CT is to be delivered.

– The EHR portal contacts Verizon for authorization on the basis of shared trust under the NHIN federation.

– When Verizon’s text message to the son goes unanswered, Verizon contacts the father as Health ID proxy. The father reviews the correctness of the familiar-looking MedCommons-type ID as a the destination and authorizes the transfer.

Note that the military health service does not actually know whether the son or the father actually authorized the request but they trust the transaction because the military health service knows that Verizon holds a valid NHIN Certificate.

In summary, the introduction of certified identity providers into the NHIN together with simple and commercially established OpenID protocol can transform the NHIN into the consumer-friendly Health Internet and bring simple regulation and market forces to bear on solving difficult privacy problems.

CODA: As of 10/4, the the soldier is stable, conscious and out of the ICU in Bethesda. A second opinion is in the works at a Boston hospital. The parents and collaborators are able to see and share 1.75 GB of imaging about their son. Let’s all hope for a good outcome and a speedy recovery.

Adrian Gropper is a physician and the CEO of MedCommons

References:

Patient ID on the Internet; October 12, 2007; Blog; http://agropper.wordpress.com/2007/10/12/patient-id-on-the-internet/

Web leaders initiate govt open identity pilot program; September 30, 2009; Health Imaging Editorial; http://www.healthimaging.com/index.php?option=com_articles&view=article&id=18927

Spread the love

10 replies »

  1. Adrian,
    Interesting use case.
    Based on my experience with Federated Identity I offer a writeup which I hope will provide clarity for anyone confused about IdP, SP etc.
    Thank you

  2. The points you make in this blog post are very interesting, and certainly create a good argument for the use of a NHIN. However as much as I think it is a great idea, for me its detriments (being the privacy of American citizens) outweigh its benefits.

  3. Thanks, Adrian. I think I understand better now and it makes perfect sense.

  4. Margalit
    There are two somewhat different ways to use a HealthURL:
    (1) “Please send my records in electronic form to AAA”, and
    (2) “My current medical situation is BBB”
    This posting mostly deals with (1) and is simply saying to a provider:
    – My voluntary identity is P and is managed by V
    – You, the provider, trusts V
    – When you receive an electronic request co-signed by V with destination AAA you will send the information to AAA regardless of who or where they are.
    Your question mostly deals with (2). There is a potential compromise between care coordination and privacy. Care coordination (a la medical home) benefits when one person (primary care physician, healthcare proxy, family friend, care coordinator) is responsible for the current clinical summary BBB. Privacy might suggest that each provider to patient P keeps their own information and BBB is assembled on the fly whenever it’s needed but, as you point out, this requires a consistent medical identity and that is subject to privacy risks in itself. My proposal is compatible with patient identity correlated by a hospital, exchange or identity provider but the patient is able to choose among these three very different options.
    The HealthURL is the same in both cases. Someone who is very concerned about privacy might have multiple HealthURLs (like people have multiple credit cards). Someone who really mistrusts the system might even have multiple digital identities. The one HealthURL that’s special is BBB, because that’s the one that’s managed and that’s the one the patient typically chooses to present.
    The important thing is that the patient gets the records immediately and inexpensively whenever they ask. This is the law. Facilitating a digital request using a voluptuary identity is the foundation of this proposal.
    Adrian

  5. Adrian, I have a question regarding your paper on this subject.
    I’m not sure I’m understanding this correctly, but it seems to me that a patient can only have one active HealthURL at any given time and that is where all his medical records are aggregated at that moment in time. The next provider or care giver, would access that particular HealthURL and either become the current HealthURL or upload the records created to the original HealthURL.
    If the above assumption is correct, then I don’t really understand two things.
    1) Why would providers compete to host these HealthURLs for patients? There doesn’t seem to be any financial gain and maybe even the opposite is true.
    2) Why have only one HealthURL? Why not introduce a higher level of identification at the identity manager level that would tie multiple HealthURLs to one patient?
    So basically, Verizon would know that a person has records at Mercy Clinic, at Ostco, at Dr. Friedman’s office and at his MedCommons account. If the patient ends up at the ED, or if a family member requests information on behalf of an incapacitated patient, Verizon would aggregate all records on the fly and present them to the attending, or family member. They can peruse the records, pick what they need and transfer into their own record, which in case of the ED would probably become another HealthURL.
    I know this introduces more complexity, but I would be more comfortable, from a security point of view, if records were scattered everywhere and only assembled on a need basis.
    It will also probably increase the fidelity of the record if stays where it was created, instead of being moved around between what will most likely be disparate systems.
    Would this work with your vision, or is it breaking a constraint?

  6. Patient controlled information is the best way for record security….I made that arguement here several months ago as well as I think I wrote about it on my blogs also…granted not as an stand alone article.
    I continue to believe that $20 billion is too much money for health IT. I think a billion or two might be overkill.
    we just need to put the right competencies for strategy deveopment and implementation.
    rgds
    ravi
    blogs.biproinc.com/healthcare
    http://www.biproinc.com

  7. Adrian: Nicely done. I think that the Health Internet (formerly the NHIN) could well end up functioning the way you describe it. DCK

  8. Adrian, as far as I understand the MedCommons concept is somewhat similar to that of Google Health and Microsoft HealthVault, where customers decide who has access to their records. You are correct that the NHIN is intended mainly to connect care providers in order to facilitate integration of patient information collected or created in different care settings, functionally and geographically. Once it is in place, there will be no need for verification of patient authorization to access their data for care purposes because this is regulated by HIPAA and HITECH. PHR systems can and will participate in the NHIN, as well as health plans, wellness programs and other entities. And that is where patient consent management will become a critical requirement. In general, user authentication, authorization and privacy protection is a complex functional area, and I agree that sometimes it may be better handled by a trusted external organization.

  9. Adrian, Well spoken.
    History will be written that it was bizarre for consumers/patients (people) not to be baked in to the NHIN concept from the very beginning.

Leave a Reply

Your email address will not be published. Required fields are marked *