Stream: Da Vinci PDex
Topic: OAuth2 Tokens for Member Match Operation
Spencer Kathol (Sep 23 2021 at 22:42):
Hi all, I'm looking at the member-match specification, and trying to come up with the best way to layer in authorization. At this time, I'm thinking of using backend services specification in the bulk data IG to drive this use case. We would have the client (other payer) request a token using client credentials and execute the member-match operation. Scopes would be member-match and appropriate patient-restricted scopes (e.g. patient/DiagnosticReport.read). If there's a successful response, the returned patient's resource ID would be added to the introspection claims so subsequent resource calls can be appropriately restricted. I wanted to get feedback on this approach. Let me know if you have any questions.
Josh Mandel (Sep 23 2021 at 23:00):
If I understand correctly, you are contemplating generating an access token that is initially not bound to any specific patient but becomes bound upon successful completion of a match operation? That is an interesting pattern. Just to be sure, I don't think this needs to rely on the introspection response as long as your member match is returning the relevant patient id. It's a nice touch to include this information in an introspection response, but it would be best not to assume that clients will be able to or will need to call the introspection api.
Josh Mandel (Sep 23 2021 at 23:03):
It's also worth mentioning that we don't have standardized scopes for custom operations; you might want to use our extension syntax, which either leverages a double underscore prefix or a full URL for the scope names (e.g., __$member-match)
Michele Mottini (Sep 23 2021 at 23:24):
The way authorization should work is specified here: http://build.fhir.org/ig/HL7/davinci-ehrx/consent-oauth.html#workflow
Michele Mottini (Sep 23 2021 at 23:24):
So no backed auth, but mutual TLS
Michele Mottini (Sep 23 2021 at 23:24):
With a payer directory system handling the certificates
Michele Mottini (Sep 23 2021 at 23:25):
And then using UDAP for the patient restriction / consent part
Michele Mottini (Sep 23 2021 at 23:29):
(Having said that, everyone appear to be going the SMART - OAuth2 route with the patient authorizing the connection instead of using member-match)
Lloyd McKenzie (Sep 23 2021 at 23:31):
I don't think that's true of 'everyone' and now that there's more breathing space, there may be some shifts.
Michele Mottini (Sep 23 2021 at 23:33):
Everyone that answered the question 'what are you implementing' during the connectathon said that
Spencer Kathol (Sep 23 2021 at 23:35):
Thanks @Josh Mandel and @Michele Mottini. I will read over that HRex consent spec - it seems to provide the direction I've been looking for. FWIW, I'm working with an organization who has opted to go the member-match route.
Lloyd McKenzie (Sep 23 2021 at 23:38):
Yes, but a number of payers not at the connectathon have said other things
Lloyd McKenzie (Sep 23 2021 at 23:39):
Also, any solution that requires patients to log on and do anything with a computer excludes a significant portion of the patient population.
Spencer Kathol (Sep 24 2021 at 15:45):
Is this the appropriate standard to reference for OAuth mTLS? https://datatracker.ietf.org/doc/html/rfc8705 I assume we don't need to make the payer directory access dynamic - we can download public keys in a batch and update static configuration periodically?
Isaac Vetter (Sep 24 2021 at 16:56):
Spencer, I think the appropriate takeaway here is that there's a couple of possible ways to do this, all of them are complicated, and there's not yet clear direction on if or what the single right way will be.
Josh Mandel (Sep 24 2021 at 16:58):
I'm also eager to understand how these decisions align or diverge from what is being contemplated in TEFCA/carequality
Isaac Vetter (Sep 24 2021 at 16:59):
Also, http://build.fhir.org/ig/HL7/davinci-ehrx/consent-oauth.html, wow! There's a lot on this page. Using system-level authnz for patient-facing apps is an invitation to PHI breaches. What happens when $member-match returns the wrong patient? This page lists a pou of "PATRQT", (patient request) which invites PHI breaches.
Spencer Kathol (Sep 24 2021 at 17:20):
Member match returning the wrong patient seems like a significant risk regardless of auth... Especially if the requesting payer decides to merge data they receive. We are talking about using the old coverage member ID + MBI + DOB for matching which should be pretty solid, but still, there should probably be an oh s*** button. In any case, we'll probably stick with something close to what I originally proposed, maybe with a few tweaks driven by the link shared above. It's less complicated, and actually not too terribly different.
Lloyd McKenzie (Sep 24 2021 at 19:40):
@Isaac Vetter There's no intention to use the HRex consent-oath for patient facing apps. This is only for system-to-system exchange between payers who are already mutually authenticated to each other over TLS. Patient's only involvement is signing a paper form or making a phone call. (And sometimes not even that, as for some types of data sharing between payers, no consent is necessary.)
Isaac Vetter (Sep 24 2021 at 19:52):
Thanks, Lloyd. That's not the case in other UDAP, pou={patient request} network scenarios. Appreciate the clarification.
Lloyd McKenzie (Sep 24 2021 at 21:05):
I think I made the mutual TLS bit clear on the page. If you think there's anything further I need to make explicit, feedback is welcome @Isaac Vetter
Lloyd McKenzie (Sep 24 2021 at 21:05):
(and everyone else :smile: )
Isaac Vetter (Sep 24 2021 at 21:46):
Lloyd, one possible clarification (I feel like Bas would appreciate) is defining what's meant by mutual TLS by pointing to an RFC. I think that the page refers to TLS client and server authentication as described here: https://www.ietf.org/rfc/rfc2246.html#appendix-F.1.1, but note that Spencer thought that it referred to this: https://datatracker.ietf.org/doc/html/rfc8705, which I'm pretty sure is totally different. So, specific wording could be:
All such exchanges SHALL be conducted under mutually authenticated TLS as defined in rfc2246
Lloyd McKenzie (Sep 25 2021 at 01:49):
Done
John Moehrke (Sep 27 2021 at 12:45):
Isaac Vetter said:
Also, http://build.fhir.org/ig/HL7/davinci-ehrx/consent-oauth.html, wow! There's a lot on this page. Using system-level authnz for patient-facing apps is an invitation to PHI breaches. What happens when $member-match returns the wrong patient? This page lists a pou of "PATRQT", (patient request) which invites PHI breaches.
@Isaac Vetter why do you say this? Patients should be able to access their own data, and when they do that the purposeOfUse is PATRQT. It is the purpose of use for patient is asking for their own data.
Isaac Vetter (Sep 27 2021 at 13:59):
Hey @John Moehrke , only that EMPI lookup is fallible and inferior to the OAuth auth code flow for establishing patient identity and that the risks for failing are higher.
Spencer Kathol (Sep 27 2021 at 14:02):
@Lloyd McKenzie Regarding documentation on mTLS, a few things that could help clear up confusion for me:
- The mTLS line item in the diagram specifies "Server-to-Server OAuth - Establish Mutual TLS" which is what led me to 8750 as it has a similar title. 8750 describes additional requirements for checking the client certificate against the client_id, which it sounds like isn't necessary. It may help to update the diagram as well so this is more clear?
- The B2B link you have on that page is out of date. I've been looking at this one: http://hl7.org/fhir/us/udap-security/2021Sep/b2b.html
- Since the client certificate lookup appears to be dynamic, is the expectation that it happen in real time, or can the set of public keys be retrieved all at once on a schedule?
- Are payers at liberty to issue certificates on their own, or will they need to request one from a single authority for this purpose (and have a common issuer or small set of issuers)?
The answers to some of these may or may not be known/determined which is fine. And I may be misinterpreting in some areas, if so feel free to correct my understanding. :smile:
Lloyd McKenzie (Sep 28 2021 at 01:44):
@Isaac Vetter If you have system-to-system between payers, a 'pou' of PATREQ would mean that one of the uses of the information retrieved by the requesting payor would be to respond to patient requests. In practice, we don't want/need to track any pou at all, but the base spec doesn't currently give us a choice. So our default expectation is that all of the top-level pou values will be sent. This is only for system to system between payers. The 'lookup' process would be equivalent to what happens now by phone and fax (payer 1 phones payer 2, provides information about the patient, payer 1 looks up the patient in their system and, if they find a single match, returns the data. All we're doing is removing the human from the loop. The algorithm won't be different (and less chances of transcription error). The risk is that the wrong patient's data is received by payer 2 and becomes incorporated in that patient's record (same risk as before). It has the benefit that it will work for the entire patient population, as opposed to the subset who have established portal accounts and know how to access and uses them.
@Spencer Kathol I'll update the link to hard-code to the ballot release for now. Can you put the other questions into a tracker item against HRex? They'll need some broader discussion in terms of how tight we want to get. Certainly there needs to be some degree of tightening, but I'm not sure how far to go.
John Moehrke (Sep 28 2021 at 13:04):
@Lloyd McKenzie you say
In practice, we don't want/need to track any pou at all, but the base spec doesn't currently give us a choice
where is this required? It is common for B2B to have overall policies that fix the purpose of use such that transactions do not need to re-state them.
Lloyd McKenzie (Sep 28 2021 at 14:39):
http://hl7.org/fhir/us/udap-security/2021Sep/b2b.html - purpose_of_use is marked as required. There's been a change request submitted asking for this to be softened to optional.
John Moehrke (Sep 28 2021 at 14:43):
okay, that is not "core".. also, just balloted, You and I commented strongly against this mandate, and we did discuss it and did not have sufficient participation to overturn. It was considered better to mandate than not. Note the vocabulary was also relaxed with discussions of a vocabulary value that represented the lack of a purpose of use. I tried to argue "null-flavor violation!", but failed.
John Moehrke (Sep 28 2021 at 14:45):
https://jira.hl7.org/browse/FHIR-33636
John Moehrke (Sep 28 2021 at 14:46):
UDAP is an IG, so one chooses to be compliant to UDAP.
Lloyd McKenzie (Sep 28 2021 at 15:41):
Agree that having a value that says "no purpose of use" is a bad idea. Far better to make the element optional. I realize that Da Vinci can choose not to comply, but that creates other issues. For now, we'll just recommend sending all purposes of use when purpose of use is irrelevant. It's annoying, but doable.
Yukta Bellani (Nov 17 2021 at 18:55):
@Lloyd McKenzie Agree that for a HIPAA covered transaction consent is not required but i heard @Robert Dieterle mentioning that we are adding it in HRex so that both payers have a record of this consent. So sounds like we are trying to have an audit trail. Correct?
Also what if we do NOT get consent from the requesting payer...can we deny that request or will we still be responding back w/ minimum necessary data (per HIPAA rule). USCDI is probably more than just minimum necessary. Thoughts on this scenario?
Lloyd McKenzie (Nov 18 2021 at 00:21):
@Robert Dieterle
Robert Dieterle (Nov 18 2021 at 13:40):
The specification will require that the "new" payer make a consent resource available to both indicate that consent was obtained from the member and the scope of the consent (e.g., does it include specially protected information). Since the intent is to exchange USCDI information, I assume the payer may deny the request if the consent resource is not provided.
Last updated: Apr 12 2022 at 19:14 UTC
