Kantara Identity Assurance Work Group Teleconference Minutes

Date and Time

• Date: 10, December, 2009
• Time: 11 EDT

Attendees

• John Fraser – MEDNETWorld.com and co-chair
• Rick Moore – eHealth Ohio and co-chair
• Joni Brennan – Kantara Initiative staff

• Barry Hieb – Global Patient Identifiers
• Bob Pinheiro – Consumer Work Group chair
• Alan Nagelberg – CSC
• Mike Kirkwood - Polka
• Kyle Meadors – Drummond Group
• Rick Furr – SAFE-BioPharma

Apologies

• Mark Coderre - Aetna
• Dave Minch - John Muir Health, CA

Agenda

The topic for this call will be: How much security should we recommend when providers access patient information between systems? Specifically we will discuss the identity assurance levels that our group may want to recommend to the community to access protected health information between health information exchanges and similar systems.

1. Introduce the differences between PHI and non-PHI access needs
2. Review the Kantara Identity Assurance Levels 1 thru 4
3. Discuss California’s proposed requirements in this space (picking up from previous calls)
4. Also, Mark Coderre, head of Security Architecture for Aetna, is interested in joining this discussion and has been invited to this call.

Summary:

• Level 3 should be the groups focus to help improve patient privacy and security
• Cell phones will be important to future authentication services
• Barry Hieb requested a simple diagram outlining how a system with cell phone authentication included could work. Rich Furr thought he may have an appropriate diagram and will send to the group.
• Rich Furr – HIT Policy Committee
• Rick Moore: Federal Gov. ID Management ICAM
• Rick Moore: Presentation on e-Gov Identity, See pg 5 & 6 specifically
• Rick Moore: HIMSS GSA Whitepaper 2008

Minutes

John Fraser took these notes. After introductions John Fraser reminded the group that the Work Groups goal is to develop a working system. Rick Moore is hoping the group will pull together a reference implementation, but that may be a ways out. Rick also noted that Mark Coderre, Aetna, could not make this call but may be able to make a call in January.

LEVELS OF AUTHENTICATION:
Fraser charged the group with reviewing the four levels of authentication as defined by the feds. There was a lot of expertise on this standard on the call. The idea of the four levels are to build some level of trust if someone logs into a system based on one of these levels. Rich Furr outlined the following levels:

1. Level one – the user does a self assertion, meaning these is little trust in who they really are. Used by OpenID at it’s lowest level.
2. Level two – Username/passwords with some level of identity verification. Also used by OpenID.
3. Level three – for level three you can add one time passwords to username/passwords, or use software PKI certificates. Vetting of users does not have to be in-person.
4. Level four – in person vetting is required, and in addition you must use some type of approved physical pki token, such as a smartcard or a USB token.

ICAM FRAMEWORK:
We then discussed the ICAM Framework. (See: http://idmanagement.gov/ ) Sponsored by the federal CIO council and co-chaired by Judy Spenser. The IDManagement.gov covers both the Federal PKI Bridge and Certificate infrastructure now being installed at all federal agencies. It also covers the “Identity, Credential and Access Management” (ICAM) project to build a consolidated system for identity, credential and access management across government and externally. See the web site for more information.

Rich Furr noted that Levels 1,2 and 3 non-pki, are the focus of ICAM, while the Federal Bridge Certificate Policy covers Levels 3-4 with PKI certificates. Rich also pointed out that Kantara has submitted to ICAM its current standards as a potentially approved identity assurance program. Rich also mentioned that the Federal Trade Commission has a new personal data protection group just starting.

HIE TO HIE EXCHANGES:
Bob and Rich discussed one of the key issues is how to trust requests and exchanges of Protected Health Information (PHI) between health information exchanges (HIEs). Rich – CCHIT discussions are also germane to this issue. Fraser and Moore reminded the group that California, represented by Dave Minch of the John Muir Health System, is also discussing this issue and is considering requiring a Level 3 authentication to allow HIE to HIE communications.

Barry Hieb – recommended we should develop a simple document, about non-PHI level 1 authentication vs. PHI access requiring higher levels.

Correction from Barry on his position relative to Level 4 authentication requirements:
"When I outlined my examples of four levels of healthcare use for the four levels of authentication I asserted that level 4 authentication should be required when an individual is requesting access to PHI for a group of people, not just an individual. If, for example, a researcher is trying to look at an cluster of medical records identified as all having a specific disease I believe it is reasonable to ask that person to be authenticated at level four. Such a person would be in a position to do a large amount of damage should they misuse such data (e.g. identity theft across a population of patients). For people doing such specialized work I believe level 4 authentication should be required."

These was much discussion about what should be required by consumers, providers for different levels of access. Here is a consensus of what might be appropriate:

1. LEVEL 1 – this could be used to access non-PHI for things like scheduling and other administrative activities.
2. LEVEL 2 – It was acknowledged that this level, username/passwords, are currently used by thousands of providers for access to PHI within their organizations and within a health information exchange.
3. LEVEL 3 – To increase patient privacy and security, the group recommended we develop a method to have consumers and providers reach a level 3 authentication. This level can be reached with one time passwords (OTP) and username/password pairs for example, or you can use software PKI certificates. Rick and Rich recommended, and I think there was group consensus, that this level should be a requirement for HIE-to-HIE connectivity. Possibly even for docs looking up records within a hospital, but much discussion that with thousands of systems installed, doctors would fight this. However these was consensus that if our group could come up with a workable system that supported consumers and providers at level 3, it could be popular.
4. LEVEL 4 – no discussion on this. I think the group feels this will not be practical or commercially successful within health yet.

Barry said we have to careful or we’ll get into a deep swamp quickly. For example, as an MD, Barry said he must get information from the source, not passed thru a patient. Barry is also concerned what happens if a doc can’t get information because they don’t have a token, then how do we enable them to get this information?

Rich – Level 4 “requires”, while level 3 “allows” hardware token”. Can always use a higher level token at lower levels.
Mike – PHR/Healthvault discussion. Patients are already moving data around at level 2. Mike stated that from a consumer point of view, consumers will always go thru easiest path to get connected, such as the current usernames/passwords. He asked why will anyone go higher?
Bob – is level 2 appropriate for Healthvault? Perhaps everyone knows username/passwords, but with OpenID and Infocards, will there be a way for consumers to develop better authentication services, for example using Cell Phones with OTP for example?

CELL PHONE / SMART PHONE DISCUSSION
Much discussion about cell phone usage to provide authentication services to consumers and potentially providers. Some felt that a cell phone is already used for a second factor, with OTP sent to device. We discussed if a cell phone can simply receive a SMS message with a OTP, then type that into a web site; is that level 3 conformant? Some felt you needed some type of application running on the cell phone to reach level 3 conformance. (This is an open issue.)

Rich – OTP with cell phone would be level 3 conformant.
Bob – don’t know if OTP must be in a token?

• Rich, the cell phone is registered with credential service provider (CSP) and/or identity Provider. Then OTP is passed down to phone, then holder of phone enters something to authenticate to other systems.
• Bob – in reviewing IAF Kantara specs, these phones would need to be FIPS-140/2 compliant.
  Mike – token is “something you have”. Person is registered to the cell phone device.
  Bob – Thinks one would need a secure app to get to level 3. Can’t just use an SMS token sent to the phone.

Discussion then ensued about a system that would allow both cell phones with OTP, and USB tokens to reach level 3 within a single connected federation system. Fraser thought that could be very popular as did others.

Rich – Within such a system, we would need some type of SAML identity provider providing SAML identity assertions including the users roles.

• There was much discussion as to whether you needed an identity provider all the time, or just once (a session, a lifetime??).

Meeting ended about after 1 hour, 3 minutes.

Next Meeting

• Date: 7, January, 2010#
• Time: 11 EDT (_Time Chart)