Stream: smart
Topic: OAuth2 and Consent
Lloyd McKenzie (Aug 27 2021 at 16:22):
This isn't specifically a SMART question, but more a generic OAuth2 question. However, I figured this community was likely the highest density of those who might be able to answer the question.
Da Vinci has a use-case where payer A wants to get an authorization token to query data held by Payer B. Before Payer B will grant permission, it wants evidence that Payer A has received explicit patient consent for that information to be shared. This evidence need be no more than an identifier that can be followed up with out-of-band audit processes to an electronic or wet-ink signed consent.
Is there any mechanism either within SMART's OAuth profile or with an extension to it that would allow conveying that consent identifier? The alternative is to define a custom operation that would provide a JOT in exchange for a consent and an indication of the type of access desired, however it'd be nice to be able to use the refresh token approach that OAuth provides, as the access might need to be valid for up to 13 months.
John Moehrke (Aug 27 2021 at 16:42):
This is not core to SMART. But is part of the IHE-IUA profile of OAuth. The concept you have outlined has been around in IHE for many years. It started in the SAML days, and now has equivalent function in OAuth. The model is generic like you have mentioned, there is an extension parameter that holds the identifier of the consent instance that the requester believes authorizes them. The relying party is allowed to check that assertion (really should). See the discussions in IUA around the acp: Patient Privacy Policy Identifier.
https://profiles.ihe.net/ITI/IUA/index.html
John Moehrke (Aug 27 2021 at 16:44):
The current HL7 ballot http://build.fhir.org/ig/HL7/fhir-udap-security-ig/b2b.html
has been working toward harmonizing in some of the IUA concepts. You will find what you are looking for here called consent_reference
Michele Mottini (Aug 27 2021 at 16:58):
Da Vinci has a use-case where payer A wants to get an authorization token to query data held by Payer B. Before Payer B will grant permission, it wants evidence that Payer A has received explicit patient consent for that information to be shared.
'that information' is coming out of Payer B, why would the patient give authorization to share that to A - that does not have the data? It is B that needs to be authorized
Lloyd McKenzie (Aug 27 2021 at 18:18):
The patient is engaging with a new plan. The consent for B to share with A is given to A and needs to be relayed to B. We don't want the patient to have to engage with B at all. (And in many cases, they won't have a means to do so - they won't have coverage anymore, so no portal access, etc.)
Gino Canessa (Aug 27 2021 at 18:34):
If the patient doesn't have a relationship with B, I'm not sure how there can be a verifiable consent. I think the most that can reliably* happen is that A can attest that the patient is authorizing it, but if there's no validation between Patient and B, B would have to take A's word for it.
The patient in me would say that B should continue giving Patient access as long as their records are present. In that case, A can use a standard OAuth flow (SMART) to authorize access.
*Of course, B could also arrange something with Patient during termination (e.g., a code they send via paperwork, a 'secret' provided by Patient, etc.). While that could later be used as verification, I think that practically speaking the Patient would need continued access to read/reset that token. If the goal was to remove portal access, that could be a manual process though (e.g., via phone, or even fax =).
Lloyd McKenzie (Aug 27 2021 at 18:40):
The patient has a past relationship with B. The expectation is that A holds the consent and B can come and audit it if necessary.
Lloyd McKenzie (Aug 27 2021 at 18:41):
@John Moehrke IUA seems to support referencing a consent in the token that comes back from the auth server. What I'm looking for is consent to be an input to the auth server.
Gino Canessa (Aug 27 2021 at 18:43):
At some point in time, Patient needs to have some sort of relationship with both A and B concurrently. Otherwise, we are relying on A's word, B's word, or Patient's ability to maintain something verifiable over time. The first two are pointless, and the last is (in my opinion) infeasible.
At any time that Patient can access both A and B, there's no additional work needed - it can just be a standard flow. Note that it doesn't have to be the same portal as active users, it can just be an auth frontend for giving access to historical records.
Lloyd McKenzie (Aug 27 2021 at 18:51):
The requirement is that the patient have zero engagement with B. It is indeed true that B needs to take A's word, however, B can also go through a non-electronic process to audit and actually see the wet-signature consent that A holds (or electronic equivalent).
Lloyd McKenzie (Aug 27 2021 at 18:52):
B is not allowed to ask for explicit consent from the patient and must accept the process of the consent being provided through A. (Doing otherwise is considered to be introducing unnecessary barriers to data flow.)
Josh Mandel (Aug 27 2021 at 19:02):
The patient has a past relationship with B.
The thing that works out of the box today is: patient also has a current relationship with B. Specifically: as long as B is obligated to retain records, they're obligated to provide patient access. So, patient uses their account at B to authorize a SMART app deployed by A.
I'm echoing what @Gino Canessa and @Michele Mottini have expressed above because it bears re-emphasis.
Josh Mandel (Aug 27 2021 at 19:03):
The requirement is that the patient have zero engagement with B.
That's a tough requirement that will block near-term progress. There is no good way to meet these requirements with widely available infrastructure. You have to solve major challenges in cross-organizational identity management and matching, as well as cross-organizational permissions management first. You can certainly string some pieces together and tell a story, like:
- Patient interacts with a Consent Management Service trusted by Provider B to receive a "Signed Consent Object"
- Consent Management Service identity-proofs patient at LOA 2 or higher (perhaps relying on an external service like https://www.au10tix.com/ or https://stripe.com/identity)
- Consent Management Service helps the user create a
PermssionorConsentresource, which is cryptographically signed by the Consent Management Service, bound to- Sufficient number of identity attributes from the ID proofing step
- A specific requesting party (Provider A)
- A specific set of data sources (audiences) including Provider B
- Patient takes this a "Signed Consent Object" and hands it to Provider A
- Provider A uses the Signed Consent Object to authorize a request with Provider B
- Provider B validates the request (signatures, consent, etc) and tries to match supplied demographics to run the query
^^ This is a lot of moving parts that need to be designed, built, deployed, and trusted.
Josh Mandel (Aug 27 2021 at 19:05):
I suspect @Mohammad Jafari, @Luis Maas, and @Jim StClair have thought about these workflows more than most!
Josh Mandel (Aug 27 2021 at 19:06):
It touches on aspects of TEFCA, FAST, Decentralized Identifiers...
Lloyd McKenzie (Aug 27 2021 at 23:07):
We have a mechanism to handle cross-organizational identity management (the member match operation). The permissions management is also not an issue because there are only two permissions possible - "all data" or "all data, including sensitive data" (where sensitive is as defined by state and federal regulations). There's no expectation that the consent will be electronic.
Lloyd McKenzie (Aug 27 2021 at 23:09):
In talking with @Eric Heflin and @Joe Lamy, it looks like the UDAP B2B extension will do what I need (consent_policy and consent_reference).
Josh Mandel (Aug 27 2021 at 23:19):
The "match" operation is an API wrapper around the last step in that workflow; the challenges of design/build/deploy/test/trust require careful attention.
Lloyd McKenzie (Aug 27 2021 at 23:25):
In practice what the first parts of the workflow will look like are:
- patient signs a paper form and mails it in or 'signs' an electronic form by logging on to payer A's portal and clicking a button or filling in their initials. The paper or electronic form will allow them to fill in their prior healthcard information and will let them pick which of the two sharing options they want.
- once established, the permission to access data could run for up to 13 months (over which time, numerous queries would be initiated)
- the consent document would only actually be looked at in an audit situation.
We're separating 'match' from 'access' because match would happen once between two payers - once they each know their respective member identifiers for the same patient, no need to do a match again. However, establishing permission to query could occur many times.
Josh Mandel (Aug 27 2021 at 23:58):
Which parties are responsible for identity proofing the patient? What attributes need to be verified and which are optional?Who establishes the list of acceptable proofing practices and how do they convey the level at which they have performed this to relying parties? I see active discussion of these in #FHIR at Scale (FAST): Exchange with/without intermediaries
Paul Church (Aug 28 2021 at 01:34):
The demographic matching in the member-match operation is critical to the security of the entire scheme.
If Provider B is trusting a consent object signed by Provider A, then every plan in the country has to have this trust relationship with every other plan and they are all equally capable of forging a consent object.
An attacker only has to compromise one of them (out of thousands), and then exploit this bilateral relationship to be trusted by every other plan. However, the next barrier to "download everyone's data and sell it on the black market" is that the attacker has to figure out what to ask for.
This is where member-match comes in - if it's too permissive the attacker can brute force iterate through member IDs, or use identity theft data dumps to guess identifying info. If the attacker can skip member-match and use the 'access' step to iterate through Provider B's member IDs without providing any identity proofing, then it's game over.
In case it's not obvious I think this entire scheme is going in the wrong direction.
Josh Mandel (Aug 28 2021 at 01:51):
Indeed. In case it's not obvious, I agree with @Paul Church; and of course we should assume that any attacker has a leaked set of fairly comprehensive demographics for tens to hundreds of millions of people to start with, so calling $match doesn't provide useful security protection, just an extra mechanical step.
Josh Mandel (Aug 28 2021 at 01:53):
(The story gets a little bit better if there are a small number of widely trusted identity proofing providers, and if the full context of the identity proofing operation can flow through the trust fabric. But none of this is straightforward in the way I worry you think it might be, Lloyd.)
Lloyd McKenzie (Aug 28 2021 at 02:52):
- member match only occurs after mutual TLS - so hard for someone who isn't trusted as being a payer (either by prior arrangement or being listed in a trusted registry) to attempt to spoof anything
- member match must occur before authorization could be granted, as authorization must be specific to a particular patient URL
- The member match information includes name, gender, date-of-birth as well as insurance card information. We don't currently establish a minimum, but we do say that there must be one exact match to get a response. If there are thoughts on what the minimum should be, I'd welcome a change request. A change request requiring that payers be required to monitor for brute force attempts would also be useful.
Lloyd McKenzie (Aug 28 2021 at 02:53):
Anyhow, that's still somewhat orthogonal to "want to be able to pass patient consent as part of the OAuth request". But it appears that UDAP meets the requirement.
Lloyd McKenzie (Aug 28 2021 at 15:23):
Raised FHIR#33261
John Moehrke (Aug 30 2021 at 12:34):
There is also audit requirements, and there should be a governance expectation of watching for misbehaving partners. As in partners that are doing something different than their normal.
Once misbehaving is detected, that partner certificate should be revoked.... presumably everyone has implemented BCP195 fully and thus a revoked certificate is detected.
Is this reasonable for everyone to do this behavior analysis? probably unreasonable, but enough that are doing it will detect misbehaving partners, and their certificate revocation protects everyone (that is following BCP195 and looking at revocation).
An additional mechanism, is to feed these audit logs to a centralized or regional party that looks for misbehaving.
THIS is the dark-art of security. No one likes to speak of it. It is not as exciting as the front door security, but it is none the less important.
Michele Mottini (Aug 30 2021 at 13:28):
This is a very bad idea
Michele Mottini (Aug 30 2021 at 13:29):
We are working with payers and we are just pushing them to have a way to (re-)issue credential for old members, that is totally feasible
John Moehrke (Aug 30 2021 at 14:54):
Michele Mottini said:
This is a very bad idea
ah, which part of the thread is a bad idea?
Michele Mottini (Aug 30 2021 at 15:32):
Having patients give authorization to Payer A to get their data from Payer B is a very bad idea
Lloyd McKenzie (Aug 30 2021 at 16:10):
Even if the patient's have a portal to connect to, < 10% of patients bother to set up portal access. That's not sufficient. Forcing the patient to do anything with an electronic system simply isn't viable.
David Pyke (Aug 30 2021 at 16:11):
Do you have a source for the <10%? I've been looking for one.
Lloyd McKenzie (Aug 30 2021 at 16:24):
Bob Dieterle
John Moehrke (Aug 30 2021 at 17:10):
even if it was much higher. The motivating factors are that the Patient has a motivation to give Consent to their payer, and the Payer has motivation to provide a user experience to capture that Consent. There is clear evidence that there are significant numbers of Care Providing organizations that are unwilling to provide a user experience at all.
Further, I don't think the model mandates this flow, but rather enables this flow when that is the right flow to use. Right?
Lloyd McKenzie (Aug 30 2021 at 17:19):
Correct.
Michele Mottini (Aug 30 2021 at 18:23):
The fact that something is desirable does not make it reasonably implementable
Paul Church (Aug 30 2021 at 18:26):
Also this is an interoperability problem. If some payers are unwilling to release member data under this scheme because they don't feel it meets their legal obligations, then the ecosystem isn't going to succeed.
John Moehrke (Aug 30 2021 at 18:30):
I do question the need under HIPAA and this being the P in TPO...
Lloyd McKenzie (Aug 30 2021 at 21:27):
Payers will do what the regulator has said they need to do. The Office of Civil Rights (who apparently is in charge of this patient consent thing?) has definitively said that the Payer A request to Payer B is a business-to-business flow and the patient does not need to separately provide consent to Payer B.
Lloyd McKenzie (Aug 30 2021 at 21:28):
(Or, I guess, they could violate the regulations and face the consequences...)
Josh Mandel (Aug 30 2021 at 21:33):
There's a hellscape of pragmatics here where payers turn on an API but (by following our specs) have to configure it in such a way that security considerations prevent its real-world use.
Josh Mandel (Aug 30 2021 at 21:34):
(It's not information blocking if the actual security considerations lead to the conclusion that it's unsafe -- which is a real risk if we don't get the protocol specs right.)
Gino Canessa (Aug 30 2021 at 22:07):
Hmmm.. this is tough because the limitations make any authorization essentially pointless (unless I'm missing something?). B asking for verification by A is just an extra step without benefit. E.g., if there's a document that is signed by the patient and on file, whether it is maintained by A or B is somewhat irrelevant - A is the source of the document. Presumably, A is already trusted enough to connect to B and ask questions.
If the goal is to be able to blame someone after a problem has occurred, this can help... but I don't know that it provides any more value than just logging that A made the request. If the document is reviewed after the request is processed (e.g., manually), the data will have been sent before anything is checked. In the case of an issue that is being investigated/litigated, both A and B will be involved, so the same document will surface either way, and what's important is the actual access/misuse.
In my experience, B won't want that document, because they would rather keep the liability with A for making the request*.
All said, if the goal is to have a standardized protocol for what that document is and how to transmit it, I would want to be very clear about assumptions and limitations.
TLDR: If the patient can only attest to A, then forwarding that to B is relatively useless - my reading of the constraints is that B can neither contact the patient nor refuse the request. It could make someone keeping books at B happy to have, but it also means there is a case that B is on the hook for authenticating that document before sending data.
*I am not a lawyer and this is not legal advice. Statutes and regulations will vary by jurisdiction and should be evaluated by licensed legal professionals =).
Lloyd McKenzie (Aug 31 2021 at 00:29):
Really all we're interested in doing is forwarding a reference to the consent from A to B that B can look at if it wishes to. A is already obligated to only access the data it has access to. It's possible that some payers will look at the consent every time. Others may spot-check. Others may only look if there's been an issue raised.
Lloyd McKenzie (Aug 31 2021 at 00:31):
@Josh Mandel I'm confused about what would prevent the real-world use of the specification we're proposing to use. Mailed, faxed and phoned-in consents are the norm today, so they're certainly useable in the real world. All we're trying to do is ensure that the data flows electronically in computable form instead of over a fax machine.
John Moehrke (Aug 31 2021 at 13:03):
The model in this specification is based on existing models that are indeed used. It is a design that isolates Privacy in a layer between business and security. It is a design born from Privacy-By-Design. The usual reason it is used is because "A" has a legal obligation to get consent first, and that legal obligation requires that they send it to "B" prior to any patient healthcare data interaction. Case in point, this is how SSA must act when they are the payer on workers compensation injury cases. This because SSA is not a HIPAA covered entity. This because SSA is a government arm. EVERY request by SSA for workforce injury cases that use the existing nationwide health exchange(s) uses this model. In that case they are using IHE-BPPC, and IHE-XUA. So, I assure you it is being used.
John Moehrke (Aug 31 2021 at 13:04):
if it is not used, then no harm done. If it is needed and that need prevents appropriate use, then harm is done.
John Moehrke (Aug 31 2021 at 13:16):
Here is an article I wrote on the topic in 2017 when the nationwide exchanges were working on this - https://healthcaresecprivacy.blogspot.com/2017/01/enabling-point-of-care-consent.html
John Moehrke (Aug 31 2021 at 13:17):
and this is why the IHE-IUA (profile of OAuth) has the support for authorization policy
Gino Canessa (Aug 31 2021 at 13:51):
Thank you for bearing with me while I try to understand what I am missing. If SSA makes a request to a facility (e.g., SSA is facility A, data is housed in random facility B), they are honoring the request because B has to honor a request from SSA, not because they received a document A attests has patient consent on it.
As far as I can tell, that is also the case with the B2B transactions being described in this thread - B is required to fulfil the request, which includes a consent artifact from A. B does not have the option of manually reviewing the consent prior to honoring the request, and even if they did, I doubt they would want to spend the resources doing that for every former customer. (This is beyond possible issues with claiming that a request from A wasn't valid vs. information blocking, etc.)
While I have no doubt that this is being used, especially given the translation from paper-based workflows, I cannot understand the reason that we need to define a protocol to give B an artifact that has no meaning. A is on the hook for validating and maintaining that document, and must be able to reliably reproduce it (or face consequences).
So if A is trusted to: make the request, verify that the document is valid to B, and reproduce it on demand... what is the purpose of sending around the additional artifact? If sending the document is security theatre, that's fine - but we should be clear about the purpose. If the purpose is bookkeeping for B, sure (though again it opens the door for litigation, so I'm curious why they would want it). If there is another reason, what is it?
So, my now traditional TDLR: I can't see the use of passing around a consent that cannot be verified and is not consulted before processing a request. Am I misunderstanding the flow, or missing something else?
John Moehrke (Aug 31 2021 at 14:16):
I am hard pressed to personally disagree, as you are holding a position I have held. But I will point out some facts that you are not including that are important to the interaction.
a) A is obligated to do this work, regardless of what B does. A must perform this obligation, therefore they need a way to perform. This performance (feeding into your statement on theatre) needs a well defined mechanism, they can't just send a stream of bits and say that it is good. (Although I have been with the lawyers arguing over byte sequence on the wire discussions, but I will not get started on that).
b) These are not TPO, so B is not obligated to respond. A is very clearly identified as SSA, and thus B is obligated to have different rules for SSA than they have for their cohort of HIPAA Covered Entities. B could choose to do no validation, they could choose to fail the authZ request with a "come back tomorrow", where they do have a physical review of the documentation, record their assessment in their authorization schema with their refresh timeout.
c) The mechanism is a building block that simply supports two policies in this DaVinci spec. They have not invoked more involved consents, but by starting with a building block layer focused on consent we start with a simple solution that can build into something better
d) As written, it might also fail as you predict. I would never indicate that just because a standards organization has defined a standard that the standard will succeed. So, the market may prove you right. But I assure you that the market can't even give it a try if it is not specified somewhere. There are participants in the DaVinci specification calling for a functionality like this, they would like to give it a try. Hence "Standard for Trial Use".
We are talking about SSA and how they use the existing nationwide exchange... I have no idea if SSA will be using this DaVinci specification, or who is the target A or B for this specification.
I would hope that others could chime in on the B side. I would hope others speak up for use of this structure beyond SSA.
My only point is to indicate it is architected off of something that is working today on a nationwide scale.
My preference would be that we continue to use the existing nationwide exchange and just define FHIR content. The existing nationwide exchange has built up from simple (Note side conversations on Gall's Law). It has had incremental new features added, some failed to catch hold, some succeeded. This nationwide exchange is content agnostic, and content preserving. It might be not obvious to some, but it is both nationwide and working today. I would prefer if DaVinci just focused on their content needs and left the whole of infrastructure to modular approaches that could work on the existing nationwide network and transition over to http/REST.
Lloyd McKenzie (Aug 31 2021 at 15:16):
The business world passes around consents all the time that can't be electronically verified. If things get into a legal kerfuffle, then everything traces back to the original ink signature or audio recording and forensics experts try to determine if it's legitimate or not. What's needed for the business process is "sufficient" due diligence and traceability. If A asserts to B that they have patient consent and provide enough information for traceability, that's sufficient to enable the flow - and sufficient to enable traceback if there's a problem.
Gino Canessa (Aug 31 2021 at 16:32):
Thanks John and Lloyd!
I'll say that I have a pretty visceral reaction to a workflow that expressly prohibits B from verifying with the patient. Instead of "the bar for gaining patient consent is too high" I would prefer "this is how we can do this, even if it isn't a great story yet today". And yes, I know this is often unrealistic - doesn't mean I can't hope/advocate for it =). I also think moving from 5% to 15% of patients being able to verify (and then to 20%, etc.) is easier progress than moving a solution from 0% to 100%. (I will note that I understand constraints and scopes - if this is in the area of "decisions we are stuck with".. well, it doesn't change my opinion, but I won't harp on it either).
On the same front, while I understand that non-verifiable consent is common, I would argue that whenever we can to push the needle towards verifiable we should take it.
I follow the need for breadcrumbs back to the initial document - I was unaware that making the request (with proper logging/auditing) wasn't considered sufficient evidence of... making the request. In my experience, passing the consent document means that B has increased liability (again, not a lawyer), e.g., in the cases where a cursory examination of the document would have proven it was invalid (signed by Bugs Bunny), B should reasonably have a workflow that detects it, etc.. Showing that B trusted A and A is the sole entity responsible for verification is a cleaner process.
(edit: In a workflow that doesn't include the patient) Entity A could be required to attest that they believe they have proper authorization to make this request. That is a document that could be useful for B (and something that can easily be built to be verifiable). In that case, it is clear that the chain then leads back to A: why did you feel you were authorized to make this request. That said, it goes back to the fact that A is actually making the request - it would just be a document saying what they're doing. While I'm generally not a fan of that kind of artifact, I do understand that it has a place.
In a workflow like that, Patient provides consent to A, A provides consent to B, etc. Whatever documentation/process A has in place between them and the patient shouldn't be relevant to B (since B isn't allowed to check with the Patient that it's actually valid). It makes more sense to me, since B is responsible for trusting the attestation of A (which they have established) and A is responsible for everything beyond that. It also has the "side" benefit of being more privacy-preserving for the patient - it doesn't leak any information about the initial request that the initial consent document may contain.
Finally (yes, finally =), I would agree with several others in that I'd prefer that an IG in this space leverages existing work. There are years to decades of effort already invested, and building a trust framework takes a long time.
John Moehrke (Aug 31 2021 at 16:40):
You seem to be under the assumption that B must accept the A assertion that the Consent referenced is legitimately authorizing A to access B. That is not a fact. As with ANY assertion, the relying party has the obligation to verify that assertion. Even in the simple SMART-on-FHIR flow the token received at the relying party needs to be validated as both legitimate and authorizing the scope of the request.
We need to make it clear that the reference to a consent is to be interpreted as "A is asserting that Consent C is evidence". The most basic validation is (this came from A, and I trust A to make these assertions). But this does not prevent future cases where the Consent includes more detail, and digital signatures. However we start simple and build up to that.
John Moehrke (Aug 31 2021 at 16:43):
for example in the SSA / IHE flow I have mentioned. It is common for trust to be strong enough in the SSA. But the content is there to be reviewed, the content has specific structure and coding, the content has mechanism to have digital signature.
John Moehrke (Aug 31 2021 at 16:44):
A relying party (Which likely is the Oauth authority for the organization, protecting their FHIR api) can certainly pull the content. Confirm the patient, the organization, the policy, the validity timeperiod, etc...
Lloyd McKenzie (Aug 31 2021 at 17:10):
The notion of 5-15% then 20%, etc. is nice in theory, but the reality is that something is needed that will work for as close to 100% as possible from day 1. And if a solution that works from day 1 that doesn't involve patient engagement meets the need, it's hard to justify the development cost of an add-on that enables it.
Making the request is certainly evidence of making the request - but you still need the traceback functionality for those who want/need to chase can do so. B's duty is to provide sufficient due diligence in granting the authorization. For some, that might mean looking at the Consent every time. For some it might mean spot checking. Different payers (and payer lawyers) will have different notions of what's necessary. What's clear is that patient electronic authorization is neither necessary nor desired, so we can't really tie the process to a specification where that's the foundation.
Gino Canessa (Aug 31 2021 at 17:12):
I was under the impression that in this scenario B isn't allowed to communicate with Patient, so the ability to actually verify the request is very limited.
In that case, it comes back to B trusting that what A provided is authentic and valid - an attestation of that from A is more useful than 'passing through' what they patient did, since it's easier to make computable and verifiable.
(Additionally, the legal language that A in their documents with Patient may or may not be what B would use. Expecting that B will have legal review each type of release for every other party in the network feels like a high bar.)
Overall, I believe that having A describe, in a standard way, both the request and why they believe they are authorized (patient has given consent, court ordered, whatever) to B is more useful than passing a release form between Patient and A, and making B try to interpret it. I believe there are standards and/or components for this which are already well-defined.
TLDR: If there isn't sufficient trust between A and B to allow that type of workflow, then how is the unverified document from A any better?
If this isn't the case (e.g., B is allowed to communicate with Patient regarding the request), then it opens more doors - but it also has significant challenges. Assuming a former relationship between B and Patient, contact information may be out of date, if contact information is provided by A, how is that any more trusted than the initial document, etc..
Gino Canessa (Aug 31 2021 at 17:19):
In short, if the only thing B has to verify the request is the document provided by A, I think it's more efficient to have A attest what it wants and why. B can still make decisions based on that attestation, but it can be done computably instead of by propagating whatever document, identification process, patient matching, etc. to every individual provider on every request.
Lloyd McKenzie (Aug 31 2021 at 17:20):
a) Unverified documents is how things work now. "I want X. Here's a faxed copy of the patient consent, please fax back the results"
b) The requirement is "patient has consented". If they've received evidence that a consent exists, they've satisfied their due diligence. If they just have an assertion that "payer A says they're authorized", at least some payers feel they haven't done due diligence. There's no business requirement for non-repudiatable proof at either layer. Tons of B2B processes work without an expectation of non-repudiatable assertions. Each system has their logs and their documented procedures for handling their logs and that process has sufficed for lawyers for decades. Again, no-one's going to pay more for more complexity unless there's a business problem addressed by the more complex solution that the community feels is worth the complexity increase.
John Moehrke (Aug 31 2021 at 17:27):
@Gino Canessa There is nothing keeping a "B" organization from doing exactly what you outline. You are perfectly right to ignore the consent assertion because you trust "A" has consent-on-file. NOTHING stops this.
So, why are you so afraid of people who have a different opinion (legal opinion) than you do?
John Moehrke (Aug 31 2021 at 17:29):
I have worked with Lawyers that insisted that this flow is necessary. I had exactly the opinion you have at that time. I trusted that their opinion was more important than mine. They were going to be in any legal hot-seat. I was not.
Gino Canessa (Aug 31 2021 at 17:59):
Yes, unverified documents are used - because that is what was available. Workflows are designed around the capabilities and limitations of whenever they are implemented.*
I'm not arguing that it doesn't work. I'm arguing that we can do better.
Different people are going to have different ideas on what is acceptable for something like 'due diligence'. My worry is building a system that appears to provide more than it does, especially when alternatives actually can provide more. We can easily make verifiable claims between A and B - they are both systems that will be using the same specification. But I don't think we have any hope of making the initial document computable, and having a spec that includes computable and verifiable claims is (in my mind) better. It means that B can trust that the request from A is authentic and that A is willing to attest to having done their due diligence with the patient. If it includes the initial document to satisfy a legal department.. sure, but I don't believe that's how existing trust frameworks are built or operated today (correct me if I'm wrong here, please).
@John Moehrke : I'm not worried about different legal opinions than mine - I'm not properly qualified to have one of those anyway (I am not a lawyer, and this is not legal advice =). My concern is that it feels like so much care is being taken to fit exactly into the existing workflow that no progress is going to be possible. If that's the case, that's fine! There's a place for that kind of spec... but there's also no need for any discussion - the solution is just going to be "what we've been doing".
*I'm sure everyone has similar stories - but back in the film days of radiology, facilities lost roughly 5-10% of their entire film library per year (melted in the car on a hot day, misfiled, accidentally recycled, etc.). This was 'acceptable' because it was reality - printing and storing multiple copies was financially infeasible. Once the change to digital was made, 0% was the only 'acceptable' loss rate.
John Moehrke (Aug 31 2021 at 18:03):
what do you propose as computable, and what is your arguments against the FHIR Consent being computable?
John Moehrke (Aug 31 2021 at 18:03):
HEART assertions could certainly be used.. but they are not.
John Moehrke (Aug 31 2021 at 18:04):
are you asserting that FHIR resources are not computable?
John Moehrke (Aug 31 2021 at 18:08):
if we have a cohort of people interested... I would love to take this page out of DaVinci and make it a standalone Implementation Guide of more substance that could be orchestrated into many higher level IG like DaVinci. I have just never been able to get anyone interested. Security holds a "Computable Consent" track at almost EVERYONE of the FHIR-Connectathons. Join, and help us make progress.
John Moehrke (Aug 31 2021 at 18:09):
track leader is @Mohammad Jafari
Consent resource leader is @David Pyke
Lloyd McKenzie (Aug 31 2021 at 18:19):
"better" for whom? If it means a patient has to:
a) get access to an electronic device (a whole lot of people still don't have them/feel comfortable with them)
b) figure out how to use it
c) jump through the hoops necessary to get a portal account or otherwise provide electronic proof of identity
d) electronically authorize their request
is that truly "better" than sticking a form in the mail along with their application or making a phone-call? Especially if that additional complexity results in fewer patients having their data transferred and as a result experience sub-optimal care. 'Better', in this case is, what's going to get data for the most patients shared most expeditiously without introducing greater risk than is tolerated now.
We could absolutely make a verifiable claim from A to B. Just throw a digital signature into the mix. But if there's no requirement for it and it adds implementing and testing complexity and potentially an extra point of failure, why would we do it?
'Better' must always be in terms of business objectives. If the risk of payers fraudulently asserting access privileges/consent is low, then adding complexity to participants is hard to justify. If there was a significant problem of systems inappropriately asking for data, then the solution might well look different and it might be justifiable to push additional work onto patients.
John Moehrke (Aug 31 2021 at 18:21):
I don't think that a digital signature is needed. We are already trusting Observations flowing over the very same communication channel. WHY is a Consent resource different than ALL the other FHIR Resources.
Paul Church (Aug 31 2021 at 18:29):
@Lloyd McKenzie It feels like we are completely talking past each other here. It's not a coincidence that people from Google and Microsoft are arguing against this idea - we have a lot of experience with security at scale.
The threat model is very different between a model where Patient A authenticates to Payer A to retrieve their data, and a model where Payer A authenticates to Payer B and asserts that Patient A has consented - that assertion has exactly zero value from a security perspective unless it's digitally signed by the patient. Patient A's credentials give them access to one patient's data, but Payer A's credentials give it access to every patient, not just from Payer B but from every payer. Credentials like that are the holy grail to an attacker.
What makes this quadratically worse is that each payer has to trust every other payer, so an attacker only has to find the least secure payer and attack them, and then exploit this chain of trust. I guarantee you that the least secure payer will not be very secure. We have to reduce the attack surface back to the point where compromising the least secure payer only gets you that payer's data (which they are on the legal hook for already), not everyone else's.
Doing this transfer through APIs is much more scalable than Payer B calling up Payer A on the phone or faxing them to say "please send me Patient A's data". An attack through those means can only get data for a small number of patients at a time. An API is limited only by whatever rate limiting and intrusion detection is in place.
I am not contesting that Payer A has processes for receiving mailed, faxed, wet ink, or any other kind of consents, and I'm not contesting that Payer B can audit those consents through reasonable processes if they have concerns. The scenario I am trying to prevent is that we wake up one morning to headlines in the New York Times about how hackers downloaded 100 million medical records through an insecure API.
Lloyd McKenzie (Aug 31 2021 at 18:33):
Payer A only has access to Payer B's patients that it happens to know the insurance identifier for that patient for on Payer B's insurance.
Lloyd McKenzie (Aug 31 2021 at 18:38):
It's true that if someone managed to grab the private key of a payer and grab a list of patient demographics and associated insurance card numbers they could then access those individuals' health information appropriately. The question is - is that risk sufficiently large that it's worth imposing a barrier that would (realistically) prevent a good portion of any patients' data being shared appropriately. The assertion is that the payer community feels that the risk of non-participation resulting from requiring patient electronic authorization is a source of greater harm and cost than the risk of inappropriate disclosure caused by insecure handling of credentials. That's a balance of risk that, to me, seems a reasonable one to make.
Gino Canessa (Aug 31 2021 at 19:33):
Lol, a little late getting back, but I didn't have it coherent before I stopped for lunch. So.. sorry if this is a bit back in the conversation.
FHIR meets computable out of the box - to my knowledge there is not a good story around verifiable/tamper proof - but between John and Lloyd, I'm sure someone can tell me if I've missed it =).
re: connectathon: one of the unfortunate issues with how connectathons work is that I'm the lead for Subscriptions. I've tried also attending another track in the past, and I have to admit it's beyond my ability to do.
I've added reviewing those specs to my list to see if there is a meaningful way for me to contribute.
re: better: I'm not arguing that the only flow should be patient-centric. I'm arguing that a specification that allows patient involvement in a structured way is probably 'better'. I don't think this is easy or solved - just that it would be worth doing. It may have already been discussed and discarded. It may not be feasible in the timeframes for this project. It may be something that is flat out impossible today. Those are the kinds of things I'm trying to discover - has it been considered, is it possible? I trust all of your experience - I am just trying to provide questions from another viewpoint/angle.
Yes, 'better' must fit in business objectives. But in healthcare, 'better' also has a responsibility to patients, independent of business interests. Sometimes those two 'betters' are at odds, and they have to duke it out to see who wins or how to compromise. (note: I understand I'm preaching to the choir here, but you asked... in this case I believe you are focused on payors, and I am trying to provide balance from patient/vendor perspectives).
re: verifiable claim: If the goal is traceability, this is desirable. I'm not into blockchain (but saying it should give someone bingo points!) - however, I would prefer any documentation that comes up in a legal context to be verifiable. I'll freely admit that I'm probably too far over in my perspective - which is why it's good to have these debates.
re: general security: The crux of my issue is that this sounds to me like a protocol in which A provides a document to B that B uses decide if A is authorized or not. This feels entirely pointless - A is providing the request and the documentation. In a trusted context, if A doesn't feel a request is valid, they shouldn't make it. If A and B have a trust relationship, presumably they also have enough of a common understanding of the criteria to know what is an acceptable request to B (not that A will only honor the same requests as B, just that acceptable use for B is the only way to trigger a request to B). Passing B the documentation doesn't help in a security context if B has no way of actually verifying the document. Yes, it can make people feel better (theatre), but how is it useful? Anyone who can forge a request from A can also forge a document that supposedly comes from the patient via A.
Making the source document verifiable would be ideal! But that requires B to either have an active relationship with the patient or a third party trusted by both that can validate the document. So, while great, I don't think this is an achievable goal today (hence this being the first time I've mentioned it).
Short of that.. I think:
- making claims from A harder to forge is good
- improving the traceability of requests is good
- if it's included, being able to verify the source document hasn't been tampered with is good
- building in verifiable claims today paves a better road for verifiable consent in the future
- that I'm writing way too much on this thread and will endeavor to stop =)
Lloyd McKenzie (Aug 31 2021 at 19:48):
Patients care about 3 things - privacy protection, simplicity, and being well cared for. Going to the extreme on privacy protection in a way that makes more work for them isn't a good outcome.
If a payer wants to do patient-mediated, they can. Da Vinci doesn't need to write a specification for that. The existing specs cover it. We're not telling them they can't. But we're trying to write a spec for a significant majority of payers who see a patient mediated experience as counter-productive to the free-flow of information (for improved patient care) the regulation is trying to achieve.
The document being provide isn't so B can decide if A is authorized. B will presume that A is authorized (because there are consequences for asking if you're not). However, there are also consequences for providing the data without doing due diligence. Sharing the document (even though falsifiable) meets that requirement. If A falsifies a consent, it's clear they're committing fraud. If A just asks when they shouldn't have, maybe they made a mistake. B just needs to ensure that A has used enough rope to hang themselves if they've misbehaved.
Gino Canessa (Aug 31 2021 at 19:59):
Fair on most points! One problem I see is that by creating a spec without it and leaving it up to the payer... I don't have faith it will happen (patients won't have the choice unless a payer goes beyond the requirements to establish this process for their former patients). Also fair though is that perhaps this is an area for regulation instead of a payer-driven specification =).
Passing around consent documents, which may be just scanned papers, still doesn't feel like a great workflow to me. It's a lot of extra transfer and storage (long-term) for a document that is just providing traceability back to the request source - which could be done with a verifiable request. Since the request needs to be stored anyway, it's less overhead and I think has more desirable properties... but again, other than making a suggestion :shrug:.
Josh Mandel (Aug 31 2021 at 20:01):
(Some patients will care about additional things beyond those three -- e.g., process transparency, autonomy, accuracy, equitability. Worth checking with #patient empowerment for some perspectives.)
Lloyd McKenzie (Aug 31 2021 at 21:09):
@Gino Canessa What's actually being passed is the reference. Whether Payer B chooses to store the reference or download and store the PDF/whatever is up to them. Obviously the request itself will be stored and logged too. However, payers feel they need to have access to the Consent. The IG does that. I don't see a migration path to a patient-mediated approach being a likely outcome here. It would have to deliver a clear meaningful benefit worth the complexity and I don't think, from the perspective of most patients or payers, that it does.
@Josh Mandel Neither of the two approaches make much difference in terms of accuracy, autonomy or transparency. The data is being transferred as is and in both cases the scope of what's available for access and by whom is clear to the patient. They get to decide whether transfer happens or not and whether sensitive data is included or not. As for equitability, a solution that doesn't require access to or skill or comfort with technology solutions to effect the patient's desires seems more equitable, at least in how I understand the concept?
Josh Mandel (Aug 31 2021 at 21:14):
at least some payers feel they haven't done due diligence
payers feel they need to have access to the Consent.
no-one's going to pay more for more complexity unless there's a business problem addressed by the more complex solution that the community feels is worth the complexity
Are we just segregated into different community streams? Where are the discussions happening that elucidate these feelings and requirements?
Isaac Vetter (Aug 31 2021 at 21:45):
Friends, John kind of said this already, but it's good to understand. What Lloyd's describing (called consent_reference in UDAP) is the primary method of how treatment-based interoperability between healthcare organizations works in the US in prod right now. (See "Access Policy Assertions in Carequality's QBDE spec). Of course, patient chart interop in the ED is an important workflow for treatment.
John Moehrke (Sep 01 2021 at 12:22):
The thing that I continue to struggle with is how a Consent Resource is somehow needing more protection than all of the other FHIR resources. That somehow the Consent Resource holds some legal position that a falsified medical record does not hold. Our communications pathway is either secure enough for medical records AND consent records or we can't even support allergies. How do we know that a Consent is not falsified, the same way we know that an allergy record is not falsified. The concern that a Consent is an assertion by the Patient is true, but so is the allergy. The recording of both were mediated by a trusted organization who has responsibility to maintain, protect, and communicate it when appropriate. There should be no reason to throw crypto theatre at a Consent when there is no equal reason to throw crypto theater at allergy records. Somehow we need to breakdown this fallacy.
Does this mean that I don't think that Consent needs to be special, or designed carefully? No, it is my passion, and I don't like many compromises that are taken. But sometimes one needs to take steps toward the light.
John Moehrke (Sep 01 2021 at 12:31):
In the IHE BPPC/XUA/IUA model, there is another option. One can just include the policy id in the request context, right there with username, organization, roles, PurposeOfUse(s), etc. This model just communicates that A is asserting they have the consent on file. It does not make it available to B in the transaction, but in theory B can request it from A (it is just a simple query on Consent for this patient where policy is X. The difference is passing the policy vs an instance of a Consent/DocumentReference resource.
The DaVinci model does define these two codes. and the IHE IUA does have the attribute. Here is the excerpt from IUA. (Note that DaVinci adds that the reference could be a reference to a Consent resource or a DocumentReference. ) This is an extension, so I think it could be used as is. https://profiles.ihe.net/ITI/IUA/index.html
3.71.4.2.2.1.2 JWT BPPC extension
In an environment that uses the IHE Basic Patient Privacy Consents (BPPC) Profile for documenting the consent, the Authorization Server and Resource Server shall support the following extension parameter:
patient_id: Patient identifier related to the Patient Privacy Policy Identifier. Its value should be the patient identifier in CX syntax or as URL.
doc_id: Patient Privacy Policy Acknowledgment Document. Its value should be an URN or URL.
acp: Patient Privacy Policy Identifier.
If present, the claims shall be wrapped in an "extensions" object with key 'ihe_bppc' and a JSON value object containing the claims, e.g.,
"extensions" : {
"ihe_bppc" : {
"patient_id": "543797436^^^&1.2.840.113619.6.197&ISO",
"doc_id": "urn:oid:1.2.3.xxx",
"acp": "urn:oid:1.2.3.yyyy",
"other_value": "..."
}
}
John Moehrke (Sep 01 2021 at 12:36):
Given that much of the discussion seems to have been around a misunderstanding that 'this' is the only acceptable way for B to decide to provide data to A. Does this page in the DaVinci specification need to enumerate all the other possible reasons why B could decide to provide access? B could already have consent with the patient, B could simply trust A, blah blah... it is only when B would not have other reason to provide access that the additional claims of having a Consent at A that is being asserted as authorizing A access to B data...
Josh Mandel (Sep 01 2021 at 13:22):
Totally agree with your point about server B simply passing along a non-dereferable consent document identifier; that works about as well as passing an actual consent in this trust model.
To the earlier question about why consent records might need stronger protection against falsification than say allergy records? It's not about the resources themselves; it's about the context in which they are used. There is little obvious privacy risk associated with server a fabricating an allergy record. There is a huge privacy risk associated with a falsified consent resource in the context of an authorization flow (e.g., if this resource plus access to server B's credentials it is all that's required to convince A to open up access).
(To the clear, I'm not saying that privacy risks somehow outweigh clinical risks in some grand reckoning -- I'm just saying that in the context of an authorization protocol, mitigating those privacy risks is the job at hand.)
John Moehrke (Sep 01 2021 at 13:48):
right on... privacy risk vs safety risk is not something I want to declare. I definitely recognize the risk vectors. But if an authenticity / integrity risk exists, it exists for all.
Jim StClair (Feb 21 2022 at 22:21):
Josh Mandel said:
I suspect Mohammad Jafari, Luis Maas, and Jim StClair have thought about these workflows more than most!
Absolutely, @Josh Mandel and I failed to update my email in Zulip (until now) and missed the discussion. Excellent discourse though. Coincidentally (timing is everytihng) a colleague of mine is working on a related workflow in a decentralized use case, but isn't part of the HL7 community. I'm going to share this with him to consider as factors in his effort.
Debbie Bucci (Feb 22 2022 at 09:34):
Which leads me to ask ... why not consider a verified claim that the consent was gathered ? Would it be the lack of verifier for this information in today's exchange? Actually looking for where the SMART 2.0 conversations are occurring for Read/write/consent/delegation ... someone point me in the right direction please?
Josh Mandel (Feb 22 2022 at 14:48):
This is the main discussion forum for the SMART spec. Our focus has been expanding support for the latest revision of the spec, published last fall. But we don't have any guidance specific to FHIR Consent or Verifiable Credentials; it's a pretty conventional OAuth workflow.
Josh Mandel (Feb 22 2022 at 14:50):
You may be interested in some of the B2B DaVinci specifications or in Carequality re: queries like "please give me data about Josh, I have his consent".
Debbie Bucci (Feb 22 2022 at 19:12):
So my dated understanding current requirement is focused on read only but so much more is needed. Wherever that focus is - I’d like to tag along. In the thread above I really don’t think consent is needed if member moving from a to b or b to a whatever. Doesn’t that make the member known to both parties ? . Unless payers do not fall under TPO is there an equivalent HIPAA authorization. The idea that a patient is kind of force into the middle of something primarily use for IAS (as I think TEFCA puts it ) seems a bit over kill. I have been following the DaVinci work and updates the IHE profiles as well. Curious about the sausage making and want to follow along. Thanks for the response!
Josh Mandel (Feb 22 2022 at 19:57):
I don't have a lot of faith in the TEFCA Individual Access Service model, personally. I think it requires everyone to have to trust consumer-facing apps too strongly, when really only the consumer should need to have this trust in the apps they choose. I'd rather see a model where each network ("QHIN") is responsible for hosting an RLS-focused SMART on FHIR API. This means QHINs would:
* interact with consumers to manage (i.e., call out to trusted providers of) identity verification
* allow consumers to approve an app to access their record location
* allow the app to query for a list of endpoints where this patient's data live
* (potentially) provide the app with a signed login_hint including the verified ID of the patient and the QHIN who asserted it; the app can share this with each EHR endpoint to jumpstart/streamline user authentication at the EHR portal
Josh Mandel (Feb 22 2022 at 20:07):
I've updated https://hackmd.io/@jmandel/tefca-smart-individual-accessto reflect this position.
Debbie Bucci (Feb 22 2022 at 20:12):
That's interesting ... kind of a master index locator in reverse
Josh Mandel (Feb 22 2022 at 20:13):
I think it's still the "forward" direction: QHINS host Record-Location APIs, and Healthcare Providers host Record-Access APIs -- all supporting the same authorization paradigm, so apps only need to be trusted by their users, and not by "the whole system at large".
Debbie Bucci (Feb 22 2022 at 20:15):
The trust bound to the identity verification that each QHIN performs?
Debbie Bucci (Feb 22 2022 at 20:16):
QHIN trusts the verification
Debbie Bucci (Feb 22 2022 at 20:20):
I guess what I am asking - is SSI implied or Federation across/within QHIN assumed with trusted verifiers streamline means one credential needed?
Josh Mandel (Feb 22 2022 at 20:26):
My position is that TEFCA already requires that:
- QHINS exist
- QHINS follow trustworthy practices
- QHINS trust each other
As such, the QHINS are best positioned to manage individual access to RLS services, without having to introduce a new kind of entity ("Individual Access Provider") and without letting anyone fall through the cracks of IAS-provider-optionality. I don't care too much how a QHIN decides to perform ID verification, but ideally:
- they'd outsource this functionality to companies that do it well -- could involve decentralized ID technology but doesn't need to
- they'd stand behind their work so that, having gone through the trouble/expense of ID verification once, patients could re-use an artifact of this process for subsequent authn/authz interactions -- again, could involve decentralized ID technology but doesn't need to; OpenID Connect is a good current option here, if QHINS act as IDP
Debbie Bucci (Feb 22 2022 at 20:29):
:+1:
Debbie Bucci (Feb 22 2022 at 21:16):
@josh BTW - I'm getting a 404 with the above link - if its an access issue - no big deal. I trust you said what you said :-)
Josh Mandel (Feb 22 2022 at 21:18):
Fixed my message above, thanks @Debbie Bucci -- I was missing a space. Direct link.
Last updated: Apr 12 2022 at 19:14 UTC
