FEDidMGT – Federated Identity Management Profile

1. Proposed Workitem: FEDidMGT – Federated Identity Management Profile

• Proposal Editor: John Fraser
• Editor: N/A
• Date: N/A (Wiki keeps history)
• Version: N/A (Wiki keeps history)
• Domain: IT Infrastructure

2. The Problem

Much work has been done on federated identity management systems. Shibboleth in particular has a well developed system for attribute exchanges and attribute definitions. However, in health care we need the ability to trust federated identities based on explicit attributes shared between independent organizations. For example, in an emergency, the ER doc should be able to share with remote EMR/PHR systems an identity and attributes sufficient for the remote systems to allow/disallow this person, which must include full identity for audit purposes. Without standardized attribute exchange naming systems, these types of interactions can’t function.

This profile must also include a minimum recommended role naming system, so that access control decisions can be based on standardized roles by remote systems. This is more commonly referred to as Role-Based Access Control, or RBAC.

3. Key Use Case

Current Use Case:

First responder attends to a victim in a bridge collapse. No medical information is known about this person. Medication allergies, pre-existing conditions or medication history are unknown, which potentially reduces the quality of care given to this patient.

How It Should Work:

First responder attends to a victim in a bridge collapse. An identity card is found on the patient, and swiped through a card reader system, linked to the Internet and authenticated using the federated id provided to the first responder and shared within this community. The patient’s EMR system is queried in real-time for a problem list, medication summary, allergies, problem list, emergency contacts and medical directives. The interconnected systems make access control decisions based on the identification of this first responder. The First Responder can then treat the patient very intelligently and inform the patient’s emergency contacts of the patients condition and the location of the hospital where the patient will be taken in real time. The hospital is immediately messaged of the incoming patient’s name and condition, allowing the hospital to start pre-admission efforts to ready appropriate care for this particular patient. The hospital can contact the EMR of the patient’s primary care provider, to get more detailed information, providing to the remote EMR the identity of the requesting person via this same community id. Recent radiology and other images of this patient should be available to the hospital through standardized information sharing mechanisms.

4. Standards & Systems

The following standards and related efforts should be investigated to assist in the development of this profile:

• SAML/2.0 – standardized XML documents for sharing identities
• Liberty Alliance – standardized, industry driven federated identity management.
• Shibboleth/2.0 – open-source, globally utilized federated identity management systems developed by Internet/2, moving toward Liberty Alliance compatibility.
• FIPS-201 – standardized identity vetting developed by US federal government.
• ITU-T X.509v3 – standardized digital certificate
• ISO 17090 – public key infrastructure standards for health care
• NIST 800-63 Version 1.0.2 Electronic Authentication Guideline
• HL7 RBAC activities
• Veterans Administration - VHA Role-Based Access Control Task Force
• XDS.a, XDS.b, XUA, and other IHE profiles.
• HITSP standards

5. Discussion

IHE has been successful attracting PACS/PMS/EMR/PHR vendors to test interoperability of their standards. Since federated identity management requires interoperability to work, IHE would be a good standards body to develop the additional roles, attributes and exchange standards to make federated identities useful in the health case domain.

Additionally, the Connectathon is a great forum to test this type of profile, since it will require the interactions of a number of different vendor systems to make a system like this useful in real world use cases.