Stream: Security and Privacy
Topic: Search by security
Josh Mandel (Jun 05 2019 at 20:43):
I'm thinking about examples that illustrate the concept of structured scopes, as part of a (not super directly related) DevDays session next week. I was trying to write an example that said "Meds and Labs are fine, but not sensitive labs" and wanted to write something like the following (recognizing it's probably not easy or practical to support, but just exploring syntax and semantics a bit):
{
"terms" [
{"allow": "MedicationStatement?patient=$patient"},
{"allow": "Observation?patient=$patient&category=laboratory"},
{"deny": "_security:below=http://terminology.hl7.org/CodeSystem/v3-Confidentiality|R"}
]
}
When I did this, I realized that in the confidentiality classification, V ("Very Restricted") is not modeled as a sub-concept of R ("Restricted"), so the :below query in my deny example would block access to "Restricted" content, but would fail to block access to "Very Restricted" Content. @John Moehrke do you know why V is not modeled as a sub-concept of R?
John Moehrke (Jun 05 2019 at 20:52):
the codes in confidentialityCode are non-overlapping risk evaluation. So they are not sub-concepts. So it seems :below is speaking of hierarchy. This seems logical for most codes.... To make this work with confidentialityCode we would need to have each value to be a sub-concept of the other.
Josh Mandel (Jun 05 2019 at 21:38):
I guess the question is, would you want to do this? I think it'd be nice to express the semantics in the hierarchy, personally (because it makes it easy to do things like "no more than moderately sensitive"
John Moehrke (Jun 05 2019 at 22:09):
Given that there are only 6 values confidentiality code values, it is usually done by just listing each value allowed.
This below concept might be more valuable with PurposeOfUse which is a hierarchy -- http://build.fhir.org/v3/SecurityPolicy/vs.html
Josh Mandel (Jun 05 2019 at 22:21):
Fair enough. I'll update my example to just list multiple codes. Thanks!
Mohammad Jafari (Jun 05 2019 at 22:31):
on that note @Josh Mandel, is that a teaser for the next generation of SMART scopes? If yes, please tell more! :-)
Josh Mandel (Jun 06 2019 at 03:23):
It really wasn't -- more like, I'm trying to describe a spectrum of "scope expressiveness" to talk about tradeoffs
Josh Mandel (Jun 06 2019 at 03:24):
Draft deck for the devdays talk is at https://docs.google.com/presentation/d/1CqRCrNB17XXzeff0guDo1inM-gdy2k0aBc16OcdZKHM/edit?
Grahame Grieve (Jun 07 2019 at 04:05):
@Josh Mandel this would be a search by value set. But the Ian McNicoll thinks that ordering in code systems is more widespread than we admit, and this is one that is clearly ordered.
Grahame Grieve (Jun 07 2019 at 04:05):
we might allow gt[code] in a future version...
Josh Mandel (Jun 07 2019 at 14:52):
Search by value-set meaning ... ? Is my example wrong?
_security=http://terminology.hl7.org/CodeSystem/v3-Confidentiality|R
Mohammad Jafari (Jun 07 2019 at 16:14):
I checked with @k connor and she confirmed that this value set was intended from the outset to be a 'total order' as the following:
V > R > N > M > L > U Adding the subsumption to the vocabulary definition might be worth it if there are no undesirable consequences.
In our demos I have always followed what John suggested above since the number of codes is small and "not belonging to a range" can be turned into a conjunction of negations against specific codes.
But this only applies to confidentiality labels and not for instance to sensitivity labels which are covered by the same query parameter.
Grahame Grieve (Jun 07 2019 at 18:55):
order is not subsumption.
Grahame Grieve (Jun 07 2019 at 18:55):
Josh: _security:in=http://my-value-set
where my-value-set specifies the values you care about.
Grahame Grieve (Jun 07 2019 at 18:55):
though
Grahame Grieve (Jun 07 2019 at 18:55):
_security=R,X
Mohammad Jafari (Jun 07 2019 at 19:29):
@Grahame Grieve The subsumption relationship on the confidentiality codes set is a "total order" in the algebraic sense of "order." Order is not subsumption but the subsumption relationship orders a set of codes. That's what I meant in the above. Has "order" been defined in a different sense in this context? If it has, Kathleen and I will revise to clarify and avoid confusion.
Josh Mandel (Jun 07 2019 at 19:57):
Josh: _security:in=http://my-value-set
where my-value-set specifies the values you care about.
Is this to suggest that I should define a new valueset containing just R and X and then get servers to recognize it? The latter option (supplying values directly) seems more staightforward.
Grahame Grieve (Jun 07 2019 at 20:05):
for a few values, the second approach is clearly better, but once you have enough values, it's not practical anymore
Josh Mandel (Jun 07 2019 at 20:09):
Agreed. Here it's a short list at least. And obviously geR("Restricted or greater") would be even more convenient.
John Moehrke (Jun 08 2019 at 14:50):
Good to see confirmation of my approach... Note that I would expect that an organization would create a valueSet of the sensitivity codes that they consider Restricted... (where organization could be a large domain of organizations). Related to that would be a set of valueSet(s) of loinc/snomed codes that they consider are indicators of each of the sensitivity codes, something for a Security-Labeling-Service (SLS) to operate on. The SLS also is expected to use all the power of a CDS to mark as sensitive, data that has inference to a sensitivity... Thus we (security/privacy) want to engage the good works of CDS and vocabulary to tell us what is (and is not) sensitive, we will be happy to leverage that in access control decisions and enforcement. We engage a SLS which engages CDS... because security geeks are not good at figuring out what is sensitive...
Josh Mandel (Jun 08 2019 at 14:54):
My take is that "sensitive" tends to be extremely personal, cultural, and other flavors of contextual -- by place, time, political alignment. I'm all for trying to find some low hanging fruit, but I'm skeptical that institutions can make these kinds of determinations on behalf of individual patients/consumers.
John Moehrke (Jun 08 2019 at 15:00):
There are multiple sides of sensitive. It does NOT address all vectors. I was only speaking of the data classification found in the sensitive valueset. http://build.fhir.org/v3/InformationSensitivityPolicy/vs.html There are people that find 'sensitive' things beyond this vocabulary, but it is there as a vocabulary to use. This does not mean it is the only thing that can be sensitive. There are clearly not things on the list that have not yet been discovered or deemed sensitive. A locally managed valueset can more quickly adjust to these 'norms', that was my point. Yes a person will have an episode they want marked sensitive, timerange often works well.
John Moehrke (Jun 08 2019 at 15:10):
The patient can/should be allowed to manually mark data. There is legitimate concern for how this can e done in an informed way, or at scale. Further concern is that a crafty malicious (e.g. drug seeking person) can use this to hide information that would prevent them from some goal (e.g. getting more narcotics). Logging, and review of actions is likely an effective defense against this, but does require comprehensive logging and system of continual evaluation.
Mohammad Jafari (Jun 10 2019 at 00:41):
I think we should make a distinction between sensitive data in the colloquial sense (which is deeply subjective and personal) and sensitivity as defined by the sensitivity vocabulary. I think the intention of the vocabulary was to identify any category of information which has been singled out for additional protections by the existing laws and regulations. This is clearly jurisdiction-dependent and also changes with time. For example, I have heard some people questioning whether Sickle Cell anemia is still a sensitive condition although it is a protected category by the law.
Then there is the issue of categories of information which are personally sensitive to a patient but not singled out by the law. For example, a knee injury could be considered very sensitive information for a high profile athlete. In these cases, I think the patient or someone on their behalf can directly assign a confidentiality label to that information where overarching policies enable them to do so. For example the resources related to the knee injury can be marked as R by the patient or by the clinician.
Also, determining the sensitivity labels by the SLS can be more complicated than a simple list of SNOMED or LOINC codes although that's a good place to start as we have shown in our demos. Aside from the complexities resulting from the use of unstructured text and use of NLP, even in structured information, there are issues around inference and related resources which cannot be addressed with simple codes; for example one case we encountered was when antibiotics prescriptions which are not sensitive per se, would have to be marked as HIV-sensitive if other information in the patient's information could be indicative of HIV. So, supporting basic conjunction and disjunction seemed necessary alongside having a list of LOINC and SNOMED codes in order to be able to assign sensitivity codes with less false positives and false negatives. As soon as we had to consider AND/OR rules, we realized that there are probably cases which call for more complicated rules or where non-rule-based and learning-based methods would be applicable.
Grahame Grieve (Jun 10 2019 at 12:15):
Should a patient be able to tag a resource with a patient confidentiality without claiming that this is the overall confidentiality? RIght now, they can't, but this discussion seems to imply that they should be able to. Seems like a missing security label to me?
John Moehrke (Jun 10 2019 at 13:14):
@Grahame Grieve what part of FHIR keeps them from being able to do that?
Grahame Grieve (Jun 10 2019 at 13:16):
well, how would they do that? putting a security label on a resource? what kind of label?
Jose Costa Teixeira (Jun 10 2019 at 13:22):
This seems in line with what we discussed last week, @John Moehrke @David Pyke : a resource that describes the permission including the scope of that permission. That scope can be for many dimensions : only some content, or some categories of data, or some parties or some purposes...
Jose Costa Teixeira (Jun 10 2019 at 13:24):
I think the initial topic is about some categories of data, and I agree classification is not something we can completely standardize.
John Moehrke (Jun 10 2019 at 13:24):
well, how would they do that? putting a security label on a resource? what kind of label?
They would be using some tool that understands the policies and organization (aka patient portal), and it offers a vocabulary for this purpose. It might be a standards vocabulary (TABOO), or it might be a local vocabulary.
Grahame Grieve (Jun 10 2019 at 13:26):
so they put TABOO on there - is that different in meaning than if a clinician puts TABOO on there?
Grahame Grieve (Jun 10 2019 at 13:26):
I'm asking for a standard vocab approach....
John Moehrke (Jun 10 2019 at 13:26):
is loinc 1234 different if a patient puts it in vs provider?
John Moehrke (Jun 10 2019 at 13:27):
vocabulary are vocabulary... right?
Grahame Grieve (Jun 10 2019 at 13:27):
I don't think so, no. But I think there is a difference in this use case.
John Moehrke (Jun 10 2019 at 13:27):
why?
Jose Costa Teixeira (Jun 10 2019 at 13:27):
Do the same rules apply in all contexts for the same term in the vocabulary?
John Moehrke (Jun 10 2019 at 13:27):
note that I did preferece that a authorized app is doinging the marking.. this is not a patient twiddeling bits
John Moehrke (Jun 10 2019 at 13:29):
More likely they just list the specific FHIR objects by .id and put them in a Consent.provision with provision.type==DENY and provision.data.reference listing all those things they want hidden
John Moehrke (Jun 10 2019 at 13:29):
@Jose Costa Teixeira you know that the world is full of too many variations on privacy policy to think that there is one policy that rules them all...
John Moehrke (Jun 10 2019 at 13:30):
but, yes I do expect that the definitions that a vocabulary has been given by a standards organization is universally understood as having THAT definition
John Moehrke (Jun 10 2019 at 13:32):
and, I totally expect that some messed-up organization will not follow those definitions.. nothing any vocabulary organization can do to prevent idiots from using their vocabulary improperly. but we don't design to this abuse... right?
Grahame Grieve (Jun 10 2019 at 13:34):
@John Moehrke ok i don't mind the notion of using Consent, but which consent? I don't believe that there's a way to know what Consent resource applies
John Moehrke (Jun 10 2019 at 13:35):
what>?
John Moehrke (Jun 10 2019 at 13:37):
In the simplest of environment, there is only ONE...In a slightly more complex one, they are likely based on PurposeOfUse... in a more complex environment, they better explain their complexity.
John Moehrke (Jun 10 2019 at 13:46):
The application(s) responsible for supporting updating of consent must recognize previous, likely offer that set of terms, and offer changes. The resulting update of Consent replaces the previous. If you have more than one consent, and they appear to conflict, then there is some consent application problem.
John Moehrke (Jun 10 2019 at 13:49):
so you think this should be said in the core? I was hoping it would be the kind of thing that an IG would say... Seems core should not include a policy statement like this (there shall be only one). If so, please make a CR; as your CR will carry more emphasis than one I might enter...
Grahame Grieve (Jun 10 2019 at 14:04):
I'm not sure how much core should say. but I expect that a patient will have multiple different consent arrangements applicable to the control of the information, made at different times, for different purposes, with different parts of a provider organization. Is there some expectation that a consumer will only have one? If there's more than one, how are they supposed to differentiate them? would they differentiate by category?
Also, If a consent agreement is subject to control, it doesn't seem like it's easy add some random resource id to it - that's a process question
Mohammad Jafari (Jun 10 2019 at 15:37):
I think it's not realistic to assume that there will only be a single applicable consent at any given time. It's an integrity rule that's hard to enforce when multiple systems are involved. Especially where the patient can use multiple consent management systems to file a consent, it's practically inevitable to have conflicting consents ending up in the system.
It's matter of policy and configuration to handle such cases, for example, "most recent consent overrides" or "the one filed in the EHR's own consent management system overrides", etc.
Grahame Grieve (Jun 10 2019 at 15:39):
so that's the problem I'm concerned about. How can this be manageable from the consumer point of view? WHat's a consumer App to do? (specially if we don't let the consumer tag resources as confidential)
John Moehrke (Jun 10 2019 at 15:46):
so in the core... we do allow resources to be individually tagged... but a more realistic solution is to have consent that targets the data by id, type, timeframe, or the other vectors found in .provisions. These vectors are in the model, because they are the vectors that consent use-cases brought to us needed. It is hard to model something that no-one brings forward a realistic example.
Grahame Grieve (Jun 10 2019 at 15:46):
I don't feel as though that is more realistic given the discussion here
John Moehrke (Jun 10 2019 at 15:46):
as to the question of ONE or MANY.. this is a domain choice. There are definitely domains that have indeed chosen that there shall be only ONE.
John Moehrke (Jun 10 2019 at 15:47):
I don't feel as though that is more realistic given the discussion here
and I am trying to understand why you don't 'feel' this
John Moehrke (Jun 10 2019 at 15:47):
yet, somehow you think it is easier to support access-control rules that allow for CHANGING EHR data? touching the .meta element of Resources inside the EHR.
Grahame Grieve (Jun 10 2019 at 15:47):
because you can't know which consent to do that in
John Moehrke (Jun 10 2019 at 15:48):
In any given domain... yes I can.
John Moehrke (Jun 10 2019 at 15:48):
because any given reality based domain will need to answer the questino you find unanswered
John Moehrke (Jun 10 2019 at 15:49):
For example, In the VA there is only ONE consent on file at any time. Any updates can be done at any time, but result in replacing the existing consent with a new one.
John Moehrke (Jun 10 2019 at 15:49):
This has been the model in multiple HIE based on XDS and XCA using BPPC and now APPC.
John Moehrke (Jun 10 2019 at 15:49):
at some point, rubber hits the road, and a policy model must be chosen.
John Moehrke (Jun 10 2019 at 15:51):
I can confidently say that they all start with 'there can be only ONE'.
John Moehrke (Jun 10 2019 at 15:54):
well... there can be only one Privacy Consent.
David Pyke (Jun 10 2019 at 15:54):
All of the implementations I have worked with have a single registry with all records tied to the patient MRN/eMPI with specific exceptions. I'm not aware of a system that would allow multiple records to affect a single patient for the same context
Grahame Grieve (Jun 10 2019 at 15:57):
I think that we need some special query to fetch the consents applicable to the interface like
[base]/Consent?list=$applicable
Grahame Grieve (Jun 10 2019 at 15:58):
which returns all consent resources that have bearing on requests made through the interface (though policy would dictate whether they are all actually visible or not)
David Pyke (Jun 10 2019 at 16:02):
That's a privacy violation as that would show that such information exists.
David Pyke (Jun 10 2019 at 16:05):
Having the ability to fish for consent policies is a terrible idea
David Pyke (Jun 10 2019 at 16:54):
John and I have worked out possible pseudo code for searches. Comments are requested:
1. Request one or more Consent where status=active by Consent.scope (with patient(s), if none specified, get all)
2. Locally inspect Consent.provision for base policy acceptance/denial with Consent.policyRule
If failure mode for policyRule not understandable, refer to Privacy Office
3. Locally inspect Consent.provision for contexts as above
4. Inspect Consent.provision.provision (et.al) for exceptions
Note: server required to filter based on Consent.provision.period for only active consents.
David Pyke (Jun 10 2019 at 17:04):
Contexts aren't above, they're:
Who - The patient
What - The data - specific resources are listed, empty list means all data covered by the consent.
Where - The organization- what is the location boundary and authority boundary of this consent
When - The issued or captured
When - The timeframe for which the Consent applies
How - The actions covered. (such as purposes of use that are covered)
Whom - The actor who is/are are grantees by the consent.
Jose Costa Teixeira (Jun 10 2019 at 17:08):
How does this relate to the discussion we had 1 week ago, about consent!=permission? I think the above reads well as if consent actually means permission, whether given by the subject or by the law
David Pyke (Jun 10 2019 at 17:24):
It fits with our discussion
Jose Costa Teixeira (Jun 10 2019 at 17:31):
Hope so. I will work on what we agreed
Grahame Grieve (Jun 10 2019 at 17:31):
I don't understand why providing a query where the server figures out what is valid is a privacy violation. Is it a privacy violation to propose that the server knows what consents are relevant for the interface?
David Pyke (Jun 10 2019 at 17:35):
No, we just need to make sure that the query has to provide proof they are authorized to know consents (like a consent management server). I just am paranoid that it would be used to find out if patient X has hidden information
Grahame Grieve (Jun 10 2019 at 17:38):
well, we always take it for granted that the server has to check access control. What the search I proposed does is not short circuit access control but short circuit error prone logic on the part of the client trying to figure out which consents it has access to are relevant for the interface it is working with
Mohammad Jafari (Jun 10 2019 at 17:38):
@David Pyke I think we should not conflate defining a query at the API level with authorizing the ability to run that query to clients.
Mohammad Jafari (Jun 10 2019 at 17:42):
RE finding applicable consent, here is an excerpt from our demo report from 2017:
In this demo, we simply used a query mechanism to find the patient to whose FHIR Compartment the requested resource belongs. To find a patient’s applicable consent, we relied on a Consent Discovery component within the Consent Handler module. A simple instantiation of this component was used in the original demo which accepts the URI for a number of FHIR repositories where it can look for a patient’s consents by a simple FHIR search query based on that patient’s identifier assumed to be uniquely identifying a patient across different consent repositories (not to be confused with local FHIR server id for the patient resource). Moreover, this component will also look for Consents filed by others (e.g. a legal guardian) on behalf of the patient in question. In general, this mechanism can be expanded to include more sophisticated forms of consent lookup, such as direct Consent push by the requester in which the Client provides a copy of the patient’s consent as an evidence for proving it has earned the patient’s approval for the requested access.
Grahame Grieve (Jun 10 2019 at 17:44):
ouch. I want to move that load from the client to the server
Mohammad Jafari (Jun 10 2019 at 17:45):
This was not implemented in the client; it was implemented in the "authorization service" protecting the FHIR server. At the time it was implemented as a Servlet Interceptor inside HAPI. @Grahame Grieve
David Pyke (Jun 10 2019 at 17:45):
"In general, this mechanism can be expanded to include more sophisticated forms of consent lookup, such as direct Consent push by the requester in which the Client provides a copy of the patient’s consent as an evidence for proving it has earned the patient’s approval for the requested access."
We are discussing this aspect via an X-Consent header
Grahame Grieve (Jun 10 2019 at 17:46):
could there be more than one such header?
David Pyke (Jun 10 2019 at 17:47):
What is the use case for more than one?
Grahame Grieve (Jun 10 2019 at 17:48):
if more than one was involved in earning the patient's approval
Mohammad Jafari (Jun 10 2019 at 17:49):
X-Consent header was not a thing at the time but we did consider something like a subscription service to ensure the authorization service receives regular updates on Consent resources to sync up.
David Pyke (Jun 10 2019 at 17:49):
They would all be attached to the Consent resource under Consent.source referred to by the X-Consent header
Mohammad Jafari (Jun 10 2019 at 17:50):
could there be more than one such header?
hard to think of a use-case where that's a requirement because the idea of X-Consent is primarily based on the use-case in which the client has confidence that it has the consent which authorizes the request.
Grahame Grieve (Jun 10 2019 at 17:52):
it might not though. And David's response inplies that it creates a new one that quotes other ones that it inlines?
David Pyke (Jun 10 2019 at 17:53):
Yes, you can attach Consent resources as Consent.source. But I was assuming that you meant signed documents, not resources.
John Moehrke (Jun 10 2019 at 17:54):
I think we are getting close to helping the audience understand realistic situations... I don't think we need to get sidetracked by theory of two client side consents... not saying we won't address it, but rather asking that we get the realistic situation down first
Grahame Grieve (Jun 10 2019 at 17:54):
it's not realistic?
John Moehrke (Jun 10 2019 at 17:54):
I don't think so... do you have example?
John Moehrke (Jun 10 2019 at 17:55):
What do systems do today? what happens in the paper world today? I really don't think multiple client side consents to enable access to a single patient record is realistic.
Grahame Grieve (Jun 10 2019 at 17:56):
if the client doesn't know what the consents the server will offer - it just gathers the ones it has an hopes for the best... seems realistic to me...
John Moehrke (Jun 10 2019 at 17:56):
why would a client do that?
John Moehrke (Jun 10 2019 at 17:56):
in what way does a server ever 'offer' a consent>?
Grahame Grieve (Jun 10 2019 at 17:57):
offer : I meant honor
John Moehrke (Jun 10 2019 at 17:59):
I think this is a side project, and want the basics worked out first.... But I think you are asking about the situation where a client could get a point-of-care consent, and it just doesn't know which of a small set of them that it knows how to execute on, would satisfy the server... right?
John Moehrke (Jun 10 2019 at 18:00):
We have not addressed that in FHIR... in XCA we addressed it through error processing... as in the initial query was consentless, and got a specific error indicating that the request was mostly okay, but was lacking a consent... and in that error package was a list of policy identifiers that could satisfy the server.
John Moehrke (Jun 10 2019 at 18:01):
In this way the client knows that it is not being told to go away completely, but is given the list of policy identifiers that it can then use to determine which of the point of care consents it will interact wiht the patient to achieve. Once it has that, recorded somewhere. If that somewhere is not on the target server, then it could use the x-consent header to point at it.
John Moehrke (Jun 10 2019 at 18:01):
is that the workflow you are asking about?
John Moehrke (Jun 10 2019 at 18:03):
note that the list of policy identifiers returned by the server might be trimmed based on the client context... and the acceptance (honoring) of the x-header may also be based on the client context and server context... so no guarantee, but it is a process.
John Moehrke (Jun 10 2019 at 18:04):
In the context of FHIR consent the policy identifier would be the Consent.policyRule value.
Grahame Grieve (Jun 10 2019 at 18:12):
I'm just not sure what a practical argonaut level consent api looks like, how it's framed. Any discussion turns so complicated - I want something as simple as posible for patient apps
Josh Mandel (Jun 10 2019 at 18:14):
Do we have a good write-up on when we'd favor consent-via-OAuth (with some kind of scopes v2) vs when we'd favor consent-via-explicit-FHIR-Consent-Resource?
Grahame Grieve (Jun 10 2019 at 18:15):
that's for discussion this afternoon for me. I think of smart on fhir authorization as a connection specific consent, that would best build on top of the general patient consent
Josh Mandel (Jun 10 2019 at 18:17):
In other words, I think this is saying "the venn diagram of use cases for OAuth vs. FHIR Consent Resource is highly overlapping" -- in fact, maybe the OAuth use cases are entirely subsumed by FHIR Consent Resource use cases. But we might still like the OAuth approach for the subset where it applies, because we like something about the UX or consistency with other web workflows?
John Moehrke (Jun 10 2019 at 18:17):
Do we have a good write-up on when we'd favor consent-via-OAuth (with some kind of scopes v2) vs when we'd favor consent-via-explicit-FHIR-Consent-Resource?
that i what HEART supports... so, when is tied up in lots of deployment and trust issues
Grahame Grieve (Jun 10 2019 at 18:18):
OAuth scopes are just maps into a consent resource, for me - a simple facade to it
John Moehrke (Jun 10 2019 at 18:18):
In other words, I think this is saying "the venn diagram of use cases for OAuth vs. FHIR Consent Resource is highly overlapping" -- in fact, maybe the OAuth use cases are entirely subsumed by FHIR Consent Resource use cases. But we might still like the OAuth approach for the subset where it applies, because we like something about the UX or consistency with other web workflows?
I think that the consent rules should not be duplicated in a normal SMART scope. The scope authorizes based on app/user/role... and the server enforces that, and addes consent enforcement.
John Moehrke (Jun 10 2019 at 18:19):
trying to move the complexity of the consent rules into scopes adds no value
John Moehrke (Jun 10 2019 at 18:19):
unless you are creating a third party consent service.. like HEART... and if you are doing that, then use HEART
Grahame Grieve (Jun 10 2019 at 18:19):
all the scopes are in consent. I don't think we should try squeezing everything into scopes but we need to do more
Mohammad Jafari (Jun 10 2019 at 18:20):
Do we have a good write-up on when we'd favor consent-via-OAuth (with some kind of scopes v2) vs when we'd favor consent-via-explicit-FHIR-Consent-Resource?
we have also demo-ed a hybrid approach, i.e. an OAuth server that issues tokens based on the consents stored in a (potentially separate) FHIR server.
John Moehrke (Jun 10 2019 at 18:20):
why? What is the value of passing something from the authorization server to the resource server through the client... when the resource server MUST check again
Josh Mandel (Jun 10 2019 at 18:21):
OAuth scopes are just maps into a consent resource,
I'm more interested in when we'd deploy an OAuth flow, though (because that's a consumer-facing workflow). How the details are modeled under the hood (mapped into Consent or whatever) is an implementation detail. (And on the flip side: when/where do we advocate for pre-sepcified Consents that authorize a diverse set of downstream access? When/where do consumers go through the workflow to establish this, review, etc?)
John Moehrke (Jun 10 2019 at 18:21):
unless you are doing the configuration that HEART is targetting.... and if you are doing that, then look to HEART; and have no FHIR Consent resources.
Grahame Grieve (Jun 10 2019 at 18:22):
I don't understand this question:
why? What is the value of passing something from the authorization server to the resource server through the client... when the resource server MUST check again
John Moehrke (Jun 10 2019 at 18:22):
SMART binds closely the authorization server with the resource server... right?
Grahame Grieve (Jun 10 2019 at 18:24):
it doesn't bind it. It say nothing about it. in practice, that means bound yes
John Moehrke (Jun 10 2019 at 18:25):
If you want to encode the power of consent into OAuth scopes.. then this is what HEART tried to address. Not saying they have everything solved, but it is what they focused on. In their case they kept the consent rules as a propritary responsibility of the design of the authZ server, and only defined scope values for permissions allowed. This is a different design decision than we addrssed with the FHIR Consent, where we focused on how to encode the rules, and left as an implemention detail how to decide and enforce.
Grahame Grieve (Jun 10 2019 at 18:27):
I didn't say I wanted to do that. All I said was: the existing smart on fhir scopes are a connection specific consent that can be represented as a consent resource
Josh Mandel (Jun 10 2019 at 18:30):
"Can be represented as a consent resource" is true, but not super interesting yet: I mean, the Consent resource is super flexible right now, so sure anything can be mapped.
Josh Mandel (Jun 10 2019 at 18:30):
Do we have use cases where we want consumers to create proactive Consent policies and manage them centrally (within an org? across orgs? worldwide?) Where/how should these be used by third parties? It'd be good to spell these out. Maybe this has already been done?
John Moehrke (Jun 10 2019 at 18:30):
I can parse your statement at least two different ways, one that I am worried about.... FHIR scopes could stop at what the app/user is authorized by Role/Organization to do leaving Privacy/Consent rules to be applied later at the server... Or we could improve FHIR scopes so that they can do THAT and also encoee Privacy/Consent restrictions... But we should not assume that because we have addressed the first, that it automatically has addresed th esecond
Grahame Grieve (Jun 10 2019 at 18:30):
yes very much we have use cases. The Australian national program is drifting that way
Josh Mandel (Jun 10 2019 at 18:31):
Cool -- is there a write-up of the use case, who'll participate, etc?
John Moehrke (Jun 10 2019 at 18:31):
me too.
Grahame Grieve (Jun 10 2019 at 18:32):
John the scopes need to get more useful. I don't know how much complexity that means. But we need to give the patient a useful language to say what they want to say to control sharing on a particular connection
Grahame Grieve (Jun 10 2019 at 18:32):
the only publish write up is:
Grahame Grieve (Jun 10 2019 at 18:33):
http://www.healthintersections.com.au/?p=2868
Grahame Grieve (Jun 10 2019 at 18:33):
analysis is going to give slightly different details, of course
Josh Mandel (Jun 10 2019 at 18:35):
A consumer’s consent choices might look something like:
[√] Share my records between organisations that provide care for me
[ ] Share my records with [choose organisation]
[√] Only share my records if I set up the connection
[ ] Register all my care providers in [choose record location service]
[√] Keep a copy of my health records in [choose repository]
[ ] My care plan is found [choose care plan repository]
[√] My advance care directive is [choose repository+document]
[ ] Approve all/de-identified research use | check with me when research use is requested
This is super interesting. A lot of these don't seem obviously tied to Consent for me, but they're certainly relevant consumer-centric system behaviors (like requesting records be forwarded to a specific repository, or setting up an advance care directive).
Josh Mandel (Jun 10 2019 at 18:36):
The idea here is that once a Consent repository is in place, the national system will do some kind of system-level authorization that's backed by these policies (like, it'd have a bunch of clients allowed to connect, on behalf of certain care providers, and then the central system would compute a graph of patient/provider relations to enforce policies like "Share my records between organisations that provide care for me"?
Grahame Grieve (Jun 10 2019 at 18:36):
the relationship between "consent (information sharing permissions)" and "information sharing instructions" is slippery and not useful for us to draw
Grahame Grieve (Jun 10 2019 at 18:37):
the idea is that the clinical systems trust the central consent server and ask it what the patient choices are
Josh Mandel (Jun 10 2019 at 18:37):
Oh, so the data aren't actually centralized here, just the consent?
Grahame Grieve (Jun 10 2019 at 18:37):
the central system doesn't do no computing
Grahame Grieve (Jun 10 2019 at 18:37):
right
Josh Mandel (Jun 10 2019 at 18:38):
And how does System A determine that System B is providing care for Patient 123?
Josh Mandel (Jun 10 2019 at 18:38):
(In order to act on Patient 123's centralized Consent that says "Share my records between organisations that provide care for me" -- which System A can read.)
Grahame Grieve (Jun 10 2019 at 18:39):
I expected that this would be based on the existing connection points established by referrals in the system
Grahame Grieve (Jun 10 2019 at 18:39):
that leaves some gaps that I did not address
Josh Mandel (Jun 10 2019 at 18:39):
Sure. So "out of scope" for now; that's fair.
Grahame Grieve (Jun 10 2019 at 18:40):
MIHIN are aggressively collecting and collating the Patient's careteam to enable consent agreements framed like that (among other things)
Josh Mandel (Jun 10 2019 at 18:41):
To be clear, in this framework if I write:
[√] Keep a copy of my health records in ["Apple Health"]
... this is where the scope obviously overlaps with our existing workflows.
Grahame Grieve (Jun 10 2019 at 18:42):
yes. In this case, I would imagine that the OAuth login for a healthcare service for apple would work like this:
- connect to Provider RS end-point, get redirected to Provider AS
- provider AS redirects you to national authentication server
- that returns you to provider AS, which looks at the consent registry (and sees Apple is already consented)
- it preselects "yes" to selection and asks user to confirm
- user decides "yes" and then gets token etc
John Moehrke (Jun 10 2019 at 18:43):
so the consent repository could be implemented as a 'there shall be only one' system. which simplifies everything at run-time. pushes the complexity at user-giving-their-consent time.
David Pyke (Jun 10 2019 at 18:44):
Only one per Consent.scope
Grahame Grieve (Jun 10 2019 at 18:44):
It's not my intent that there is only one consent repository
John Moehrke (Jun 10 2019 at 18:44):
the idea of 'preferences' has not come up yet.. (dealt with it elsewhere, where it is a special case of Privacy Consent that simply has no custodian or performer
Josh Mandel (Jun 10 2019 at 18:44):
Hmm, so:
user decides "yes" and then gets token etc
suggests the national registry is really just a kind of hint, and that it has no direct effect without the user taking action on the bilateral (Apply / Provider 123) authorization step.
David Pyke (Jun 10 2019 at 18:46):
Then there would be only one per repository and you'd need very specific requirements for conflict resolution
John Moehrke (Jun 10 2019 at 18:46):
It's not my intent that there is only one consent repository
so there might be multiple consent repositories... and multiple consents at each? sounds like an NP problem
John Moehrke (Jun 10 2019 at 18:46):
fill out each repository with conflicting consents and watch the system tip over
Grahame Grieve (Jun 10 2019 at 18:46):
there's always that, but I think it's inevitaable - which is why we need to be clear about how to find the applicable consents
John Moehrke (Jun 10 2019 at 18:47):
multiple repositories doesn't seem too bad, but there should be a rule that any patient can only have their consents managed by ONE of them..
David Pyke (Jun 10 2019 at 18:48):
Or you end up needing a central query responder that queries all the repositories and gives back the aggregated reply
John Moehrke (Jun 10 2019 at 18:49):
fill out each repository with conflicting consents and watch the system tip over
repeat
Grahame Grieve (Jun 10 2019 at 18:49):
there should be a rule that any patient can only have their consents managed by ONE of them
Seems unlikely to me
John Moehrke (Jun 10 2019 at 18:49):
fill out each repository with conflicting consents and watch the system tip over
repeat
Grahame Grieve (Jun 10 2019 at 18:49):
I would have consents centrally and then make very specific consents with my actual health services
John Moehrke (Jun 10 2019 at 18:51):
but that doesn't keep me from putting 'specific to each health service' conflicting consents in the various consent repositories... and watching the system tip over
Grahame Grieve (Jun 10 2019 at 18:51):
why would the system let you do that?
John Moehrke (Jun 10 2019 at 18:51):
push the complexity to the consent-capturing time... so that real-time is clean
John Moehrke (Jun 10 2019 at 18:52):
why would the system let you do that?
I would hope it wouldn't... but it seems every solution I have offered has been rejected... so clearly there is nothing preventing it
Grahame Grieve (Jun 10 2019 at 18:53):
I missed it if you offered a solution. National (or HIE) consents for general agrements overriden by local consent agreements - is that unreasonable ?
John Moehrke (Jun 10 2019 at 18:53):
so then in this central consent repository is only one per patient... right?
John Moehrke (Jun 10 2019 at 18:54):
where the local are... local to the custodian of that data... local
David Pyke (Jun 10 2019 at 18:54):
Not at all, the central consent repository is the HIE for consents across organizations and consents that only impact local users are managed locally.
John Moehrke (Jun 10 2019 at 18:55):
not at all? I think we just said the same thing
John Moehrke (Jun 10 2019 at 19:01):
so I think the pseudocode that Dave and I worked up should work for this central consent repository. That pseudocode does not assume consents are managed in the same place anything else is managed... However the software doing this pseudocode should be a consent service, as it needs authorization to do a potentially sensitive query... and it should only expose appropriate results... and it is the results that I think we have been discussiong mostly all day.. is the results a OAuth scope? Is the results a pointer to a FHIR Consent? Is the results a XACML policyset ID? etc... what is the result.. There is not a good solution yet, because we are not there yet.
Grahame Grieve (Jun 10 2019 at 19:01):
ok so we have 2 different use cases:
- a central consent repository which stores all the consents for the inter-system
- a central consent rspository that stores the consent arrangements pertinent to the inter-system
John Moehrke (Jun 10 2019 at 19:02):
im not sure I understand what a consent arrangements pertinent means
Grahame Grieve (Jun 10 2019 at 19:03):
well, consent about the central store, and default consent arrangements for the inter-system, but maybe overridden in the systems
John Moehrke (Jun 10 2019 at 19:05):
are you trying to apply consent rules to accessing of consent rules? I don't think that is needed. The service that does the consent management and the service that does the consent decision are privileged enough to access consents (tends to not be privileged to access anything else).
Grahame Grieve (Jun 10 2019 at 19:06):
no I said nothing about that
John Moehrke (Jun 10 2019 at 19:06):
whew... well then what is "consent about the centeral store" mean?
Grahame Grieve (Jun 10 2019 at 19:09):
cosent about the health records stored in the central store (e.g. an HIE)
John Moehrke (Jun 10 2019 at 19:09):
clinical repository service?
Grahame Grieve (Jun 10 2019 at 19:10):
we don't usually use that term but yes
John Moehrke (Jun 10 2019 at 19:10):
you used it on your blog article, so I was confused
John Moehrke (Jun 10 2019 at 19:11):
YES, you must have a policy for "what should happen if the patient as ZERO consents"
John Moehrke (Jun 10 2019 at 19:12):
I will say that there could be a design criteria that indicates that for any one patient they only have one Privacy Consent... thus a business rule that means a patient must pick a consent repository, or have a way to move their rules from one consent repository to another.
John Moehrke (Jun 10 2019 at 19:14):
and then one FHIR Consent can have provisions sighting the rules for each clinical repository, possibly for each requesting organization, for each PurposeOfUse, for each type of data, for various timeframes within that repository... One big massive Consent. Assured as consistent by the consent management UI before it commits that Consent..
John Moehrke (Jun 10 2019 at 19:15):
or it could work harder, and have a different Consent for each clinical repository... or different Consents for each PurposeOfUse... or different Consents for each requesting organization... and make sure that they are always not conflicting prior to saving them.
Jose Costa Teixeira (Jun 10 2019 at 19:26):
Patient may have expressed no consent (which is most likely) but patient will have many permissions defined by policy.
John Moehrke (Jun 10 2019 at 19:28):
YES, you must have a policy for "what should happen if the patient as ZERO consents"
I think that is what I said here... right?
Jose Costa Teixeira (Jun 10 2019 at 19:28):
Imo a patient might not "pick" a consent. The permissions applicable are selected for the patient.
Jose Costa Teixeira (Jun 10 2019 at 19:30):
YES, you must have a policy for "what should happen if the patient as ZERO consents"
I think that is what I said here... right?
Yes, and that policy should be linked to the patient's data, and be expressed as a Permission or something
John Moehrke (Jun 10 2019 at 19:32):
That policy is a statement of rules and situations that are authorized (permissions) when no consent is found for the patient. The lack of a Patient specific Consent is what activates this default policy.
Jose Costa Teixeira (Jun 10 2019 at 19:33):
If a patient enters a ER there may not be any consent. Just a legal policy that applies to the patient's data, some of which applies whether the patient consents or not.
John Moehrke (Jun 10 2019 at 19:34):
yes. that default policy is a hard thing to write... and does need to concern itself with safety of the patient, safety of the care-givers, etc... Yup, very hard to write
John Moehrke (Jun 10 2019 at 19:35):
that default policy needs to deal with physical actions as well... so it is beyond the domain of FHIR.
Jose Costa Teixeira (Jun 10 2019 at 19:35):
True and my concern here is not how hard it is, but how is it transmitted in a computable way
John Moehrke (Jun 10 2019 at 19:35):
why does it need to be transmitted?
Jose Costa Teixeira (Jun 10 2019 at 19:36):
We will soon work on a couple of use cases for this incl GDPR.
Jose Costa Teixeira (Jun 10 2019 at 19:37):
Then what do you search? What metadata do you obtain that says "hey CPOE, here is what you can do with this data"?
John Moehrke (Jun 10 2019 at 19:38):
I agree that many people spend hours with lawyers and clinicians writing these default policies.. I just don't know of why they need to be encoded in an interoperable. There is no CPOE today that can read a defult policy and self-configure. That is a dream that is 50 years out.
John Moehrke (Jun 10 2019 at 19:39):
CPOE is configured by hand, with legal text from the lawyers in hand... hopefully the legal and clinician people test that it got configured properly.
John Moehrke (Jun 10 2019 at 19:40):
most important is that the default policy includes many physical access rules, many rules accessing systems that are not FHIR, and more... so to have a rules language that is that generic is to re-invent good rules languages such as XACML.
John Moehrke (Jun 10 2019 at 19:41):
default policy is hard enough to write in human readable language safactory to lawyers and clinicians.
Jose Costa Teixeira (Jun 10 2019 at 19:42):
I will look at the use cases. In any case, if we set some clarity between patient-expressed-consent and permission-to-operate-with-data that would be a step forward, i think
John Moehrke (Jun 10 2019 at 19:42):
note that the same is true of what "Permit HIE access for Treatment"... this short form is built upon a large document (e.g. DURSA) that expreses what HIE is, what 'access' is, what 'for' means, what 'Treatment' is and is not...
k connor (Jun 10 2019 at 20:15):
RE Sensitive clinical information. SAMHSA registered a set of condition, procedure, observation, medication and Lab codes that map to some of the HL7 Sensitivity codes in VSAC. These were drawn from sensitive clinical code value sets used by 42 CFR Part 2 facilities, and mental health and HIV as sensitive categories to accommodate state and local consent requirements. As I understand it, some are from the VA for Title 38 Section 7332 protected conditions such as sickle cell anemia, substance use disorders, and HIV/AIDS. To access, use your UMLS account. Search for SAMHSA stewarded value sets.
Last updated: Apr 12 2022 at 19:14 UTC
