Stream: Security and Privacy
Topic: DS4P IG
Jose Costa Teixeira (Apr 06 2020 at 11:53):
Is this public? Can I put this as a reference for non-hl7 members?
HL7 Implementation Guide: Data Segmentation for Privacy (DS4P), Release 1
René Spronk (Apr 06 2020 at 12:05):
This can be downloaded by members as well as non members. As such referencing the URL is fine. Sending a copy to someone else generally isn't.
Jose Costa Teixeira (Apr 06 2020 at 12:09):
Thanks
Jens Villadsen (May 11 2020 at 13:33):
will this IG define search parameters for the resources where the metadata is used?
Jens Villadsen (May 11 2020 at 13:33):
I seem to be in the scenario where I need to find resources based on their security marked metadata
Jens Villadsen (May 11 2020 at 13:49):
and I were wondering if this would be a part of it
John Moehrke (May 11 2020 at 13:54):
can you explain why you need to search by meta.security value?
John Moehrke (May 11 2020 at 13:56):
note that there already is a _security standard query parameter... I just don't see much need to use it.. and certainly don't think that DS4P justifies its use. http://build.fhir.org/search#security
Jens Villadsen (May 11 2020 at 13:57):
great!
Jens Villadsen (May 11 2020 at 13:57):
I need to find all patients whose requested anonymization has expired
Jens Villadsen (May 11 2020 at 13:57):
or 'restriction'
John Moehrke (May 11 2020 at 13:59):
that would be a query of the Consent resource
Jens Villadsen (May 11 2020 at 13:59):
implicit consent is already in place
John Moehrke (May 11 2020 at 14:00):
implicit consent ... expiring?
Jens Villadsen (May 11 2020 at 14:00):
implicit consent to be in the system
Jens Villadsen (May 11 2020 at 14:00):
In DK, You can request that your name and address should not be handed over to private parties under no circumstances (unless you have explicitly given that information yourself)
Jens Villadsen (May 11 2020 at 14:01):
that request expires after a year
John Moehrke (May 11 2020 at 14:01):
which request expires?
Jens Villadsen (May 11 2020 at 14:01):
request of not handing it over
John Moehrke (May 11 2020 at 14:01):
and why would that be in .meta.security tags?
Jens Villadsen (May 11 2020 at 14:02):
why wouldn't it?
John Moehrke (May 11 2020 at 14:02):
Jens Villadsen said:
request of not handing it over
that would be recorded in a Consent resource (consent resource is poorly named, but would also be used for dissent)
Jens Villadsen (May 11 2020 at 14:03):
why not in the security tag?
John Moehrke (May 11 2020 at 14:03):
an expiring dissent is an example of dynamic policy, something that should never be directly represented on data. Look at the discussion going on in the other thread
Jens Villadsen (May 11 2020 at 14:04):
actually , by default it expires after a year - but in some cases is is indefinitely - like witness protection program
John Moehrke (May 11 2020 at 14:05):
that is easy to represent in Consent resource. and what THAT is designed to support
John Moehrke (May 11 2020 at 14:05):
.meta.security is intended to support tagging data with description of the data independent (but related) to dynamic policies.
Jens Villadsen (May 11 2020 at 14:06):
aint this tagging of data?
Jens Villadsen (May 11 2020 at 14:07):
(and by policy you mean law, right)
John Moehrke (May 11 2020 at 14:11):
I am less worried about laws, but yes those are policies.
John Moehrke (May 11 2020 at 14:11):
I am more worried about policies that are dynamic, such as consents or court orders or corporate partnerships
Jens Villadsen (May 11 2020 at 14:14):
I would not consider this as dynamic
Jens Villadsen (May 11 2020 at 14:15):
As it is part of danish law
John Moehrke (May 11 2020 at 14:15):
expiration? sure seems dynamic
John Moehrke (May 11 2020 at 14:16):
what are you putting into the .meta.security to support this use-case?
Jose Costa Teixeira (May 11 2020 at 14:16):
Yes. The law may be static itself because it does not change but what the law expresses is dynamic behaviour
Jose Costa Teixeira (May 11 2020 at 14:17):
"Patient's data can be shared with others unless the patient has issued an explicit refusal in the last year" - seems like Permission
Jose Costa Teixeira (May 11 2020 at 14:19):
= "There is a Permission stating that that Patient data can be shared with others unless there is a Consent affirming that this patient has issued an explicit refusal in the last year"
John Moehrke (May 11 2020 at 14:20):
yes, the new Permission draft resource is also a good place to put these dynamic statements of policy and policy factors
Jens Villadsen (May 11 2020 at 15:19):
there's a permission resource as well ?
Jens Villadsen (May 11 2020 at 15:20):
Is there anywhere where I can see with examples how consent, permission and security label differ and how the intentional use is?
Jens Villadsen (May 11 2020 at 15:22):
I had a pretty good idea of my modelling so far using the http://build.fhir.org/v3/Confidentiality/cs.html#v3-Confidentiality-R in security
Jens Villadsen (May 11 2020 at 15:22):
You may call it a short hand version of consent/permission
Jose Costa Teixeira (May 11 2020 at 15:23):
Permission is draft, and is intended for use in cases where there is a granted permission (by someone e.g. a hospital) but not requiring a patient consent
Jens Villadsen (May 11 2020 at 15:23):
the case is that the name and address is only disclosed in use of public sector systems
Jens Villadsen (May 11 2020 at 15:24):
and since it could be because the patient is under witness protection the information the information may not be disclosed to private companies and so forth
Jens Villadsen (May 11 2020 at 15:25):
the tagging should under all circumstances follow the demographic information of the patient
Jens Villadsen (May 11 2020 at 15:25):
since it only covers and address
Jens Villadsen (May 11 2020 at 15:26):
any citizen can apply for this without any particular reason
Jens Villadsen (May 11 2020 at 15:27):
and it goes beyond healthcare
Jens Villadsen (May 11 2020 at 15:27):
so tagging the patient resource with a security label seemed like the right way to go
John Moehrke (May 11 2020 at 15:27):
yes, and that is a use-case for Consent... yes we know that some people see the word "consent" as having a specific very tight use-case. Our scope is broader than that tight use-case
John Moehrke (May 11 2020 at 15:28):
the obligation to mask a kind of demographics or address is a statement of obligation. not a meta tag
Jens Villadsen (May 11 2020 at 15:28):
the obligation is not to pass the information on
Jens Villadsen (May 11 2020 at 15:28):
to private entities
John Moehrke (May 11 2020 at 15:28):
understood
John Moehrke (May 11 2020 at 15:29):
as an obligation, it is a fine thing to show up in a Consent, Permission, or Bundle.meta.security; but would not be appropriate for data meta.security
Jens Villadsen (May 11 2020 at 15:29):
why not. Then I'm assured that the tagging follows the data
Jens Villadsen (May 11 2020 at 15:30):
technically
John Moehrke (May 11 2020 at 15:31):
I have explained it. you can ignore my warning. I will wait for you to learn the lesson.
Jens Villadsen (May 11 2020 at 18:27):
so what is the preferred way to force clients looking at the consent resource when they inspect patient resources now that you suggest that I use consent instead?
Jens Villadsen (May 11 2020 at 18:41):
Looking back, I can see that I've actually asked this question before: https://chat.fhir.org/#narrow/stream/194447-nordics/topic/Patient - back then @Grahame Grieve suggested meta, while you @John Moehrke suggested Consent. As any allignment been done 'internally' towards this or are you two guys still divided?
John Moehrke (May 11 2020 at 18:47):
everyone has an opinion
Jens Villadsen (May 11 2020 at 18:58):
that wasn't entirely an answer
John Moehrke (May 11 2020 at 18:59):
I have been and continue to be consistent in my recommendations. I back them with painful experience...
Jens Villadsen (May 11 2020 at 19:03):
Don't get me wrong, I value your input. I still would like to know if there's internal allignment.
Grahame Grieve (May 11 2020 at 19:17):
well, with a little more context... I would use Meta.security for marking the content as protected, but I would not use meta.security to implement the management workflow. So I would think that using an extension on meta.security is only appropriate as denormalization from Consent
Jens Villadsen (May 11 2020 at 20:48):
What I think I just read was: feel free to mark up the resource using meta.security, but please go the extra mile and add the gory details in the consent resource -
Jens Villadsen (May 11 2020 at 21:50):
John Moehrke said:
that would be recorded in a Consent resource (consent resource is poorly named, but would also be used for dissent)
@John Moehrke If dissent is also intended to be modelled using Consent, how come it isn't mentioned in the documentation on http://hl7.org/fhir/r4/consent.html? Ain't that a pretty big deal also to mention that use case?
John Moehrke (May 11 2020 at 22:07):
I think it is in the very first sentence
A record of a healthcare consumer’s choices or choices made on their behalf by a third party, which permits or denies identified recipient(s) or recipient role(s) to perform one or more actions within a given policy context, for specific purposes and periods of time.
John Moehrke (May 11 2020 at 22:08):
would be happy if you requested an improvement.
John Moehrke (May 11 2020 at 22:09):
It is the second example in Consent - both narrative http://build.fhir.org/consent.html#model and in the examples http://build.fhir.org/consent-examples.html
Jens Villadsen (May 11 2020 at 22:17):
I would advise to list it in the text in the bullets section - and maybe even in bold, to emphasize that 'the opposite use case' is also embraced. As you said, it's poorly named, so why not make up for it as much as possible.
John Moehrke (May 11 2020 at 22:27):
I am not the owner of Consent. @David Pyke is. You will need to explain it to him. I have however created J#27110
David Pyke (May 11 2020 at 22:31):
I'm sorry, I don't understand. The structure has a Deny code for type, mentions denial of consent in the first sentence in the description. But you want to make it more obvious? Shouldn't we rely on people reading it rather than highlighting what should be obvious?
Jens Villadsen (May 11 2020 at 22:44):
Well, maybe its just me then
Jens Villadsen (May 11 2020 at 22:46):
What seems obvious for you may not seem obvious for me and vice versa
Vassil Peytchev (May 12 2020 at 13:07):
It may be hard for non-native speakers to get past the positive connotation of consent (as in agreeing to something). How about changing the first bullet point to:
- Privacy Consent Directive: Agreement, Restriction, or Prohibition to collect, access, use or disclose (share) information.
David Pyke (May 12 2020 at 13:10):
Okay, can you make that a note on J#27110?
Vassil Peytchev (May 12 2020 at 13:16):
Done. Should I change that to a technical correction and apply it to R5?
Jens Villadsen (May 12 2020 at 13:52):
:+1:
k connor (May 15 2020 at 17:17):
@Jens Villadsen See HL7 Implementation Guide: Data Segmentation for Privacy (DS4P), Release 1 http://hl7.org/fhir/uv/security-label-ds4p/2020May/index.html. I think this may address your use case for referencing consent from meta.security:
http://hl7.org/fhir/uv/security-label-ds4p/2020May/spec.html#sec-label-related-artifact-extension
The sec-label-related-artifact extension is based on the Related Artifact MetaData Type. The RelatedArtifact structure defines resources related to a module such as previous and next versions of documents, documentation, citations, etc. Note that the name resource here is being used in a more general sense than the FHIR-specific Resource. The related resource may be a FHIR resource, or it may be another type of resource, represented using the Attachment data type.
This extension SHOULD be used on a security label code for which justification or documentation can be found in an attached or discoverable information instance. Examples include a policy security label code, which is justified based on a law, patient consent directive, or organizational policy; a provenance security label, which is documented by a Provenance Resource; a trust security label code, which is documented by a trust accreditation certificate, trust mark, or a trust agreement such as a DURSA. http://hl7.org/fhir/uv/security-label-ds4p/2020May/spec.html
Jens Villadsen (May 16 2020 at 12:09):
thx - ill have a look
Last updated: Apr 12 2022 at 19:14 UTC
