HIMSIG20080613

Liberty Alliance Project
SIG Health Identity Management
June 13, 2008
11:00-12:00 EST
Conference Call
Meeting Notes
Author: Kurt Kolok

Attendance:

Peter Palmer, Wells Fargo (Co-Chair)
Matt Madison, CORHIO
Asa Hardcastle, OpenLiberty
John Fraser, Mednet USA (Co-Chair)
Rick Moore, eHealth Ohio
Rick Drummond, Drummond Group
Paul Donfried, SAIC

Eric Tiffany, Liberty Staff
Kurt Kolok, Liberty Staff

Agenda:

Discussion of the services offered by OpenLiberty and its benefits to the healthcare industry. Asa Hardcastle of OpenLiberty is present and will continue his discussion points from the last HIM SIG call on 5/30, specifically OpenLiberty’s solutions to the following use cases:
1. ER Doctor log-in credentials
2. ER Doctor location of patient information
3. ER Doctor standardized role/authentication/authorization service
4. Doctor or ER staff access to patient information

Overview of last call: ID Theft SIG—partnering with them. Asa began talking about Open Liberty and started to define use cases which would use Liberty and Liberty services. We will continue to discuss these use cases.

1. ER Doctor log in credentials: SAML 2 player.
Preconditions (required for any Liberty solutions): 1) trusted IdPs that have to be federated (business relationships that drive metadata).
a) Doctor would have credentials at this IdP.
b) Insurance provider would provide some sort of identity to the users.
c) Hospital would have to maintain those credentials as part of what they do.
d) Rich community information about the doctor, ambulance driver, etc…could be stored in a number of ways (directory service, profiles for extracting attributes, etc…). There is nothing in SAML that tells you how to store that information. There could be different stores for different attributes. The doctors themselves and selected others would have access to the information. There can be pseudonymous handles in Liberty.

--How do we handle the instance when there are multiple handles that have different attributes on that doctor? You can build as many ID-WSF services as you need. It begins with discovery (what information is there about this doctor?). There would be a set of permissions around who can access that information. You could use People Service (store ability to access that information as well as a grouping designated to access it). Specialties, etc…might not be ‘private’ information; there may be accounting or other activities that would be specific to a different level of access. DS would point to an appropriate WSP (web service providers). The gate keeper could be the hospital, doctor or other party. All policy around release of specific information would be dependent on who was asking, who had access to that info, etc…

ID-WSF is dynamic enough to model any service with different types of information as well as prearranged policies (re: who can/cannot have access to certain things).

If you expose LDAP directory to the web anyone can access the information. This seems to solve that problem (ID-DAP--Directory Access Protocol) and is a server implementation released by Symlabs. Open Liberty has access to ID-DAP but it would need to be customized and would need an overlay of identity web services.

--When vetting doctors and other users would you register your directory in the community as an IDP? You would need to associate the identity within the directory with an IDP. Token-based look up would link them (‘look up’ would happen in the ID mapping layer). Token would connect the dots when information is requested. Think about how ID is represented as compared to how it is passed around. It would be nice to map all of those identities to the directories. IDP can do this federation where it knows how to map identities to different SPs.
--Within Liberty services is there a namespace in ID-DAP? Needs to be answered by Sampo.
--What is the actual identifier? It might be a SAML assertion. There is an ID Mapping service. The problem with bootstrapping is that phishing and other issues become a big deal when people update their information. We need to build something strong from a privacy perspective.
--How do we bootstrap into the security system? Correlation is one of the issues.
--In order to be certified and added into a trusted environment there is a need for technical certification and processing features.

2. ER Doctor location of patient information
: An individual owns a card which could be swiped so the system could look up my information (this is an insecure use case). There are privacy and security concerns. ID-WSF allows the individual to make decisions about how private/secure that information would be or get a notification on their cell phone anytime someone tries to access their information. A patient could access their information at any time and determine who else has access to it.

• Swipe your card and your information comes up
• Card contains an end point reference that allows the user to access information.
• Card would understand who is asking for the information
• Card would refer back to the medical information system (the system is registered as a new system for the specific user and through a network the information could be shared between hospitals/doctors). There is no reason that the individual cannot be registered with a Discovery Service. No need for duplication.

Summary of relevant CORHIO work:
CORHIO is building a data exchange, RHIO and record locator service model—would these be irrelevant?
CORHIO has centralized user authentication (looking at the physician point of view, not the patient).
Need to begin looking at how LAP framework may be applicable.
CORHIO has organizational relationships between hospitals and central RHIO (a COT with predefined data sharing agreements ensuring doctors are entered properly).

ID-WSF would allow for adding to and growing RHIO and creating a relationship with RHIO. The web services layer has been well vetted by a lot of enterprise level companies. Building on top of web services layer makes sense.

Master patient index: it would be good if there were multiple indices around the country (decentralized servers around the world that are in agreement). ID-WSF methodology is a web service layer taking care of all details which allows you to build another solution on top of it (this speaks to the need for discovery at the user level).

What are the building blocks?
--Partnership with Sun Microsystems
--Core architecture is built on JCAP components for master patient index, interface engine, access manager and managing users and user authentication tools.
--Limited release (currently no scope to get into federated authentication however that is a priority in the next year).
--Open SSO (Sun) is providing a SAML 2 infrastructure.
-- All pieces are meant to work together.

NOTE: NHIM backbone (federal government is working on it). RHIO to RHIO data exchange using IHE profiles (XUA) which requires SAML assertion and SOAP message.

• We need to look at XUA and develop a recommendation to incorporate IHE profile and Liberty profile. We do not have services yet to define the Liberty concept (exchange information without SSL connection ahead of time for example).
• We should work with the Federal govt.

HISPC: Colorado is working with this in the area of user authentication (how to identify a doctor across multiple systems). Unless we use a federated model there is no other solution.
Next Steps:
• We should have a call dedicated to discussion of the fundamental building blocks which would focus on two audiences: technical and business.
• In two weeks we will pick up on today’s discussion. John will work with Asa to get more details together. We could discuss an actual prototype on the mail list (less technical, more practical).
• Open Liberty is a place where things can be prototyped early.

Meeting Adjourned