Stream: Security and Privacy
Topic: Tracking consent to release
Grahame Grieve (Aug 14 2019 at 01:26):
I’m sitting in a presentation about management of data about indigenous Australians, and one of the subjects that was raised was effectively implying that there’s a need for tagging information with the consent arrangements under which it was released, so that residual implications of the consent (and who it was from) can be considered.
We don’t really have a framework for this... there’s nowhere for me to put a link to policies applicable to the information and it’s restrictions of use. We do have security labels, which allows for concept labels, but not for tracking specific agreements. Is this something we’re missing, or have I missed something?
David Pyke (Aug 14 2019 at 12:20):
If I understand your use case, that's what Consent.policy is for. Then you would use Consent.source[x] to attach the specific consent to the patient.
John Moehrke (Aug 14 2019 at 13:39):
@Grahame Grieve The best approach is to publish the policy and have the policy point at the data that it covers. Having the data point at the policy is a fragle system over time. It seems right at first, but as data ages and as policies change it breaks down. So as long as the access control engine knows it must find the policies that apply to requests for data, then the directionality of the pointer does not matter. Essentially from a high level this is what they are asking for, but technically it is a pointer in the opposite direction.
John Moehrke (Aug 14 2019 at 13:58):
The security tag vocabulary is - mostly - tags that would be used to make factual statements about the data absent any specific policy. However the intent is that becomes bread-crumbs for access control to go find the current policy about that kind of data.
John Moehrke (Aug 14 2019 at 13:59):
There are some security tag vocabulary that are focused more on recording the context under which this data was acquired (e.g. PurposeOfUse), which is also bread-crumbs to policy on use.
John Moehrke (Aug 14 2019 at 14:01):
And there are a set of Security tag vocabulary more intended for a communication wrapper (Bundle.meta.security) that identify handling instructions such as do-not-redisclose, do-not-print, must-encrypt, etc. --- these are the odd balls that are security relevant, but used in a very different way. Aka they should not be on data, but should be on communications or used in policy statements (Consent rules).
John Moehrke (Aug 14 2019 at 14:02):
PurposeOfUse is special in that it can be used in all these ways, and also as a context assertion on a request for data.
Grahame Grieve (Aug 14 2019 at 22:54):
Having the data point at the policy is a fragle system over time.
yes. that's true. OTOH, having the policy point at the data implies a set of assumptions about the overall system that do not hold in this case
Grahame Grieve (Aug 14 2019 at 22:54):
This is about how people feel rather than about good systems engineering
John Moehrke (Aug 15 2019 at 13:27):
You can tag the data as falling into a class of data that requires specific policy. This is what the compartment categories are used for, and often a local compartment is defined for a regional privacy regulation (e.g. HIPAA relevant).
John Moehrke (Aug 15 2019 at 14:12):
most of the time it is not explicitly tagged as the whole repository is dedicated to a specific purpose (the EHR). Thus tagging every resource with the same code is a waste of bits.
Jose Costa Teixeira (Aug 15 2019 at 18:32):
This seems the same thing I implemented for gdpr (not in FHIR) and the reason why I suggested a new thing between consent and data (and policy)
Jose Costa Teixeira (Aug 15 2019 at 18:34):
If someone says that "this data is shared under this policy", this link is new information and someone is responsible for that linking.
Jose Costa Teixeira (Aug 15 2019 at 18:40):
So I think we are missing this. Concretely the "permission" or "granting" that says 'this data instance can be processed because of this reason type' e.g. mr doe's data can be shared with insurer because we need to get coverage info, I.e we need this for a contract, and the contract is .../server/contract/contract1. Or instead of contract we have Mr doe's consent, which we recorded over there .../consent/c002
Grahame Grieve (Aug 15 2019 at 18:43):
I agree with Jose. this is not quite true:
You can tag the data as falling into a class of data that requires specific policy.
Grahame Grieve (Aug 15 2019 at 18:43):
What is true is
You can tag the data as falling into a class of data that requires specific class of policy.
John Moehrke (Aug 16 2019 at 13:42):
fair clarification. not clear to me that distinction is much of a difference. But that clarification is what I intended to say
Grahame Grieve (Aug 16 2019 at 13:46):
because things are not always uniquely identifed by their class; sometimes, you needto refer to a specific policy, not just a class of policies
Mohammad Jafari (Oct 03 2019 at 23:16):
Catching up with thread, I think this demonstrates the need for a more general mechanism for tagging a resource with the custom policies that must govern its use by the recipient. This is very similar to the case of digital rights management where a resource is published together with a license that describes all the rules that must be applied to its use.
General security labels can support this when the applicable rules are general (e.g. do not redisclose or delete after use), but when rules are specific, we need a mechanism to actually articulate the applicable rules rather than referencing them in the form of a value from a standard vocabulary. @Grahame Grieve I wonder if this can be covered by labeling with
Comply with consent directive and an extension that provides the link to the specific consent resource that must be followed.
Grahame Grieve (Oct 03 2019 at 23:17):
that's pretty much what I was thinking, yes. We could define that extension
John Moehrke (Oct 04 2019 at 00:17):
This seems to be the use of a compartment security label.
John Moehrke (Oct 04 2019 at 00:18):
Note that there is discussions of extracting out the permission rules language out of Consent so that one can have a set of rules that one could publish independent of Consent. This concept would be leveraged by Consent, but useful as a set of permission rules for many other use-cases.
Grahame Grieve (Oct 04 2019 at 01:22):
a compartment security label
That still doesn't get at the critical distinction between class and instance
k connor (Oct 04 2019 at 02:56):
The Security Labels include Privacy Tags for Policy and Consent Types - no need to use Compartment, which is more about a specialization of a POU by a particular project - e.g., a specific Care Team or Research Projects. There are already generic and specific privacy policies and consent directives in v.3 under ActPolicy @ https://hl7.org/fhir/STU3/v3/ActCode/cs.html - there's no URL to this part of the code system so search on ActPolicy. Using this Privacy Tag one can differentiate why information is deemed to have a certain level of Confidentiality protection for a particular Sensitivity type and this combination drives the security control/handling caveats for POU, obligations, and refrain codes. One issue that this thread points out, and was discussed on today's FHIR Consent call is that we may need both an URL and a version number because those can change while the policy/consent agreed to may have been made against a precedent and may be effective for those terms for a period of time that extends beyond the introduction of a new version/URL.
k connor (Oct 06 2019 at 21:59):
RE previous discussion on adding an extension to the Obligation label Comply with consent directive and an extension that provides the link to the specific consent resource that must be followed. How would an extension for an instance of a consent directive be constructed? E.g.,
<security>
<system value="http://hl7.org/fhir/v3/ActCode"/>
<code value="42CFRPart2"/>
<display value="42 CFR Part 2"/>
</security>
Or an extension on a Compartment label that identifies a specific Care Team?
Also, any ideas on an extension to point to the entity that assigned the label? For example, a CUI PrivacyMark that is displayed to end users as required under 32 CFR 2002, must also include the name and contact information of the designating Federal agency. Seems like there should be a common approach for these use cases.
Grahame Grieve (Oct 06 2019 at 23:56):
42 CFR Part 2
That's still a class of consent directives. (or if there's only one, an Appellation in the old ISO terminology work)
Grahame Grieve (Oct 06 2019 at 23:57):
an extension on a Compartment label that identifies a specific Care Team?
Well, that would depend on whether the resource already identified a care team, yes?
John Moehrke (Oct 07 2019 at 12:49):
These policies would live in the Consent Resource. (Unless they were broader organizational policy not specific to the patient or transaction). Don't put transactional or patient specific policy into the data. Those are attributes about the transaction or about the patient; they are not attributes about the data. The meta.security should be only meta about the data.
Where a policy is about specific data, the Consent.provision would have rules about that specific data. That is the Observation in question would explicitly be listed in a Consent.provision.data.reference with a .data.meaning of instant; and the .securityLabel holding the security obligation.
John Moehrke (Oct 07 2019 at 12:51):
Extracting out the .provision from Consent into a more general-use "Permission" resource is being discussed, so that this same thing can be done for reasons other than a patient consent. But the method would be the same with a Permission resource as I just described for Consent.
Grahame Grieve (Oct 07 2019 at 13:17):
Still need done reference to something
John Moehrke (Oct 07 2019 at 13:18):
no, the policy references the data, one direction,,, traverse it backward just like any resource reference
John Moehrke (Oct 07 2019 at 13:29):
this argument that the data must have a pointer to the policy is counter to both policy modeling, and to REST itself (we might as well change all of FHIR so that the References are bi-directional, Patient should have a data element that points at every piece of data where the patient is the subject, thus changing Patient every time new data is created) -- this is not the REST model, where one directional pointers are used and the pointer lives in the resource that was created last (usually). There is also plenty of experience in Access Control domain and expressed in Access Control standards that show that policy should point at the data it controls. Attribute-Based-Access-Controls is fundamentally based around this concept. The meta element is meta about the data, independent of policy, yet informing policy about meta attributes about the data.
k connor (Oct 07 2019 at 16:43):
Maybe restating would clarify my question:
I was asking whether the Part 2 policy code in a security label could reference the actual instance of a Part 2 consent directive URL .
This isn't about having the data point to a consent and having to be updated for every consent (Patient Resource example from John.) It's just specifying the instance of a policy code in the security label.
RE Compartment - there are several "team" type codes already in v3. But if I want to limit to access to a team, which may be designated by a consent directive - again, Part 2, it would be helpful to have an extension that could be used as an identifier/URL list of the actual care team members. When the team members want to access/share the care plan, then they could declare the Care Team compartment code and an identifier.
CUI use case is the need to always display the name and contact of the original classifier (designating federal agency) - see page 13 of https://www.archives.gov/files/cui/20161206-cui-marking-handbook-v1-1.pdf.
Having an extension of the PrivacyMark security labels would work for CUI because they are rendered.
But not all security labels are rendered so perhaps I also need to create a new Obligation Code (e.g. Record Classifier, Reclassifer, Declassifier) for the "Share with Protections" use case, and have an extension for the actual contact name/contact.
John Moehrke (Oct 07 2019 at 17:39):
The rules around CUI that compell some message be displayed is something that would be in business logic. The business policy that creates a trust-domain where CUI tags are agreed to, would be that which forces specific messages be displayed when specific tags exist. This would be true of CUI, but would be true of ANY business rule triggered after any Attribute (e.g. ABAC).
Lloyd McKenzie (Oct 07 2019 at 19:09):
Having the policy point to the data doesn't help if you receive the data and have no clue where to look for the policy(ies). Obviously you want to be able to update/add policies without touching the data. However, you also need to be able to give systems hints as to where the relevant policies live.
John Moehrke (Oct 07 2019 at 21:26):
So in your scenario you seem to have access to the repository holding the policy... thus you can just look there to see if there is a policy. If you receive data, and wonder if the policy is remote, you can always check at that time and have an implementation specific policy pointer cache. This efficiency design cache is an implementation detail, not something we break the specification for.
If you don't have access to this policy repository, then it is important that when I send you data, that I also send you the policy.
This sending of the policy may use the current Consent, or might be good use-case for the new Permission resource. (need good use-cases to drive this new design). Even the remote access of a policy repository might be good use-case for the Permission resource. But the Permissions would still point at the data, not the data pointing at the policy.
Lloyd McKenzie (Oct 07 2019 at 22:12):
Having access and knowing where it is are very different things. There could be thousands of policy servers all over the place (and some of them might move). The fact I have access to data doesn't necessarily mean I know what servers are relevant. If I query data, there's no mechanism for you to send me the policy too - at least no mechanism you can count on the client recognizing.
Grahame Grieve (Oct 08 2019 at 00:04):
it's more than that. I might have access to the consent repository but not have access to update the consent several 100000 times to add a new piece of data shared under that policy.
John Moehrke (Oct 08 2019 at 15:58):
the Permission has many vectors that can be used. The above was asking about how a one would handle where a policy applied to an instance of a clinical resource. In that case, one soulution is to list it by reference in the policy. However there are other vectors available.
John Moehrke (Oct 08 2019 at 15:59):
In what use-case is a client being expected to abide by a policy managed somewhere else, and where that client is UNAWARE of that location? This is not realistic. Lets not try to solve situations that don't exist
Grahame Grieve (Oct 08 2019 at 22:45):
actually it's quite realistic in secondary data usage scenarios. And I don't think it would have come up if it didn't exist
Lloyd McKenzie (Oct 09 2019 at 02:24):
I guess the question is whether you presume that a formal legal agreement will exist with all entities where data is disclosed to and that all such entities will also have the technical mechanism to locate all relevant servers. (And/or that if no formal legal agreement exists that asserted policies become irrelevant.) I, personally, think we're trying to move to a place where pre-negotiated agreements are the exception rather than the rule and so long as the players are in a 'community' that the systems involved can come and go without advance notice.)
k connor (Oct 09 2019 at 06:03):
I agree with Lloyd's assessment that we're evolving to an exchange ecosystem in which static agreements are no longer scalable. Mohammad and I have been talking about this idea: Could a Server's CapabilityStatement include the policies it requires of clients, which a client could discover and compare to its own CapabilityStatement capabilities for enforcing? If it can, then it requests interactions with the Server. The Server can examine the client's CapabilityStatement as one of the factors in deciding whether to agree. This could even be legally binding.
E.g., the Server says it only interacts with Clients who are certified to meet some discoverable Trust Framework - e.g., CARIN Alliance Code of Conduct https://www.carinalliance.com/wp-content/uploads/2019/05/2019_CARIN_Code_of_Conduct_05082019.pdf. The client asserts their credentials, which the Server could potentially validate. If the client is non-compliant, at a minimum, the certification would be revoked.
There could also be dynamic negotiations, e.g., if a client can't enforce some aspects of a policy but is able to enforce a subset, then the Server would restrict disclosures to information for which the client could compliantly protect? This is perhaps a FHIR approach to implementing what is described in the HL7 Trust Framework for Federated Authorization conceptual model that Security balloted.
John Moehrke (Oct 09 2019 at 12:42):
We might desire to move toward a more dynamic environment. But the facts are going to stay that one party is not going to send data to another party without a trust-framework that indicates the second party is trustworthy. Somehow you seem to think that data will flow under the hope that the recipient will abide by all possible rules. That world does not, and will not, exist. The malicious actors would love you to believe that.
John Moehrke (Oct 09 2019 at 12:44):
Where it gets really close is with DRM, where the object sent is wrapped in a DRM package which encrypts the content with a header that indicates where the policy engine is. Upon use of a DRM package the policy engine is challanged with various context and user tokens, and possibly a key is exposed to unlock the DRM package. This might be the system you invision, if it is.. then fine.. that solution is available off-the-shelf, and does NOT need us to add pointers at the header of each Resource pointing at the policy.
John Moehrke (Oct 09 2019 at 12:45):
that said... DRM has proven to be nothing but proprietary smoke-and-mirrors... for which the only way it really works is to have regulators forbid someone from breaking DRM (see the Digital Rights Millennium Copyright Act)
John Moehrke (Oct 09 2019 at 12:48):
As to Kathleen's question around security negotiation by using the CapabilityStatement, yes, this is built in today. It needs a set of security Implementation Guides defined. There are a set already available, but more are always useful. Note that the CapabilityStatement takes care of one level of this negotiation where the security protocols themselves take care of other level negotiations (TLS, Open-ID-Connect, App Reg, etc). Where a security layer has negotiations, we should leverage it, and not try to duplicate it.
John Moehrke (Oct 09 2019 at 12:57):
The point I keep trying to make is that data should not have an instance pointer to the policy, that the policy would point at the data. This is a principle that has been learned the hard way in Access Control standards. This is a principle that I learned the hard way in IHE when I originally wrote BPPC to work that way. I am not saying that it should be obvious why this principle must be followed, I failed to follow it myself multiple times. It doesn't fail hard until time and reality come in and make your policies dynamic. Once that happens all of your data must be UPDATED, for only the reason of access control policy reason, while those modifications (with provenance) will not be easy (because data gets copied and moves) and many agents using the data will see the data was updated and not understand it was only for access control policy reasons.
John Moehrke (Oct 09 2019 at 13:00):
Where a Research project receives data, it is common for a research database to create local policies that identify from where did this data come from and what restrictions are on it. They need this Provenance for their records-keeping, and the policy for any further secondary use. This provenance/policy is is often self generated based on business policies informed by the trust-relationship, but could be augmented by policy that might be in the data transfer package (embedded Consent, or 'Permission'). Note that Provenance.policy does exist for this purpose.
Grahame Grieve (Oct 09 2019 at 14:07):
But the facts are going to stay that one party is not going to send data to another party without a trust-framework that indicates the second party is trustworthy
I think you're drawing a false binary choice here. We're saying that there are trust frameworks where the knowledge is incomplete, but the regulation is not
John Moehrke (Oct 09 2019 at 14:54):
I welcome details of this... I would like to do use-case analysis... However when someone comes with a solution that doesn't have a use-case, I push-back. Especially as in this case where I have seen it fail badly.
Last updated: Apr 12 2022 at 19:14 UTC
