Logo

HHS XMS Proof of Concept Kickoff - Gallery view
Kyle Neuman (DirectTrust)
20:32
Hey Ryan, what is a relying party?
Josh Lamb Optum
26:37
How do payers tie an identity (assuming there is trust for the identity provider) to a member? Similar question for a payer.
Lisa Nelson (MaxMD)
28:09
What does XMS stand for?
Jill DeGraff (b.well)
28:12
@Ryan, can you please define the HHS XMS flow?
Gaurav Mehta (HHS/PSC)
28:24
Overview is coming shortly
Gaurav Mehta (HHS/PSC)
28:37
It stands for External User Management System (XMS)
Lisa Nelson (MaxMD)
29:33
@ Gaurav Thank you.
Julie Maas (UDAP.org)
29:35
@Josh the draft HL7 Interoperable Digital Identity and Patient Matching IG includes the member identifier in the OIDC user profile; see: https://build.fhir.org/ig/HL7/fhir-identity-matching-ig/digital-identity.html
Kyle Neuman (DirectTrust)
29:40
@Josh Lamb: there are multiple ways that can be accomplished. Many payers outsource that activity to a third party credential service provider, but can also carry out that work themselves by offering members an opportunity undergo a step-up ID proofing process if they want be able to use their credential with parties outside of the payer
Kyle Neuman (DirectTrust)
30:10
^ that of course is the abridged version, and deserves a longer discussion
Raj Sankuratri
35:04
How does this work integrate with the work HHS is doing with Real-ID?
Josh Lamb Optum
35:22
Thank you Julie and Kyle. If my understanding is correct, if there was a network of payers/providers who elected to have these ids created then they could begin to share information using this identity. If this is correct, I am still a bit fuzzy on how a member/patient match will work so that the single identity can begin to represent many separate identities. Or is this meant to help support member/patient match but it does not solve that issue?
Cille Kissel Watkins (Humana)
35:58
I would encourage thinking about this from the customer-first lens. Having to have someone sign up with an external site/company/app is really clunky. Would encourage thinking about how to make this happen via API calls vs. separate user experiences that are disconnected from the user experience the person is actually trying to use.
Ricky Bloomfield
36:27
No OAuth2?
Jennifer Blumenthal (OneRecord)
36:38
+1 Cille
Barbara Valeno (CVSHealth/Aetna)
37:07
great point Cille - i totally agree
Ricky Bloomfield
37:40
Or is OAuth2.0 implied with OIDC?
Ryan Howells
37:45
The user experience @cille is the same as it is today. You would go to a site/app and register yourself and log in.
Julie Maas (UDAP.org)
39:57
Is the idea that the Mayo Clinic (say) may join XMS so your patient portal credentials issued by Mayo, which become XMS-compatible, can then be reused to authenticate you at other health systems?
Deven McGraw
40:25
It will not be the same experience for consumer portal users, who today do not have to be formally credentialed - how portals get assigned today is not typically through an IAL2 compliant credential process. So this will be different for consumers.
Lloyd Fischer (Centene)
41:29
so Humana.com or centene.com or ID.me can be an credential service provider? isn't there still a problem with the user having a bunch of CSPs?
Kurt Olson
43:16
As a payer and relying party in this future state, our members would still need to create an account and go through identity proofing with us before leveraging XMS, correct?
Adeel Aslam (Marshfield Clinic Health System)
44:11
Yes Thats how I understand
Ryan Howells
45:47
@kurt yes although you as a relying party could accept a digital identity from another source
Ryan Howells
46:47
@lloyd yes, any of those could be CSPs. You have a bunch of CSPs today in your consumer world. We are looking at reducing the number of CSPs you would need to authenticate yourself across systems.
Ryan Howells
47:01
yes @julie
Raj Sankuratri
48:29
I was/am under the impression that HHS would participate in collaborating with the Real-ID work and extend its use for HealthCare. Is that not accurate?
Ryan Howells
48:32
@Guarav Can you address Ricky's question on how XMS uses OAuth and OIDC?
Gaurav Mehta (HHS/PSC)
49:47
@Ricky - Yes OAuth2.0 is implied in OIDC support.
Ricky Bloomfield
50:16
What are the privacy guarantees of XMS? Will patients be able to have confirmation that usage of their certified credential will not be tracked across various servers?
Lloyd Fischer (Centene)
52:45
thanks - so at registration time we should say "if you have registered at any of these places you can use those credentials - followed with list of trusted CSPs". And at login we should say the same. And we could just send them to our preferred CSP even if they said they wanted to register with us, or didn't understand the question
Lisa Nelson (MaxMD)
53:35
How do the back channel connections get established? It that an out-of-band dependency that you have to assume already exists to support this flow?
Ryan Howells
54:11
Directionally @lloyd, yes. In a decentralized way using Tiered OAuth or using the XMS identity broker service.
Deven McGraw
54:58
Seems like lots of confirming steps needing to be taken by the patient. Step 1 Jane said she wanted to get the info from the health care organization. Why canโ€™t the credential assertion contain all of those confirmations vs. having to keep going back to the patient?
Adam McBride HHS/PSC
55:17
@lloyd, For a CSP to be integrated on XMS, the CSP has to be certified by a third-party certifier such as Kantara Int or DirectTrust. We will only bring on CSPs that can provide the certification that they are NIST 800-63-3 Compliant.
Lisa Nelson (MaxMD)
57:32
Do you need to click to get step 7?
Lloyd Fischer (Centene)
58:01
does the patient select the CSP or does the XMS find the "appropriate" CSP? I'm still trying to nail the user experience.
Julie Maas (UDAP.org)
58:36
The idea is that UDAP Tiered OAuth feels like single sign on but it's enabled dynamically using trusted digital certificates.
Gaurav Mehta (HHS/PSC)
59:06
@lloyd - It is a user driven process to select the CSP they have an IAL2 credential
Lisa Nelson (MaxMD)
59:11
Can you summarize the roles and how many players are wanted in each role
Luis Maas (EMR Direct)
59:28
@Lisa: the back-channel is standard OIDC where the hospital can use the OIDC user info endpoint to request data from the IdP.
Jennifer Blumenthal (OneRecord)
59:29
OneRecord like to participate since we did TDRAAP
Josh Lamb Optum
59:40
Are there plans for an API to support IL2 Compliant accounts to be created using pre-existing information? This would allow for upgrades without user engagement (with opt-in).
Luis Maas (EMR Direct)
01:01:38
@Deven, from a privacy point of view, each actor should be confirming that the user is ok with the data that actor holds being shared with others. This could be simplified by user preferences like "always share my information with trusted entities", etc.
Sebastian Jayaraj, Providence Digital Innovation Group
01:02:07
Is there a plan to support an ecosystem of 3rd party digital health apps using this system?
Gaurav Mehta (HHS/PSC)
01:02:31
@Josh - User engaged ID proofing is required for an IAL2 account (and not to be done on user's behalf) per NISt - APIs, etc. could be/are beneficial for enriching the data attributes about the user
Kyle Neuman (DirectTrust)
01:03:02
@Sebastian 3rd party digital health apps play a critical role in UDAP flows, so yes, absolutely
Sebastian Jayaraj, Providence Digital Innovation Group
01:03:39
๐Ÿ‘๐Ÿป
ThirzaDuensing
01:04:32
Thank you apologies have to jump. Look forward to receiving the deck and your summary. GREAT!
Kurt Olson
01:05:05
Is there a timeframe when you want a response on POC participation?
Doug Williams, 1upHealth
01:06:17
Hi Ryan, are you planning to send out these slides ?
Doug Williams, 1upHealth
01:06:25
;-)