Stream: bulk data
Topic: bulk-data export identifier
John Moehrke (Aug 08 2019 at 18:11):
do bulk-data exports have a unique identifier? I am working up a usecase where a set of permissions needs to flow with the set of bulk data that was exported. I am trying to figure out how to identify the whole bulk given in an easy way.
Josh Mandel (Aug 09 2019 at 00:55):
Not exactly; this hasn't come up. Right now a combination of the request and timestamp fields is probably the closest thing.
John Moehrke (Aug 09 2019 at 12:36):
Thinking out loud... Is there a logical place to throw the terms (for now just imaging a json blob). I guess we could just attach (URL or contained) the terms into the http response entity-headers? Or is there a logical place in the FHIR encoded response?
Grahame Grieve (Aug 09 2019 at 12:37):
terms?
John Moehrke (Aug 09 2019 at 12:39):
the permission terms such as reminder to recipient that they were authorized for XYZ purpose, they must keep the data encrypted at rest, they must not re-dislose, etc... Some of these are vocabulary already in our security label valueset, so could be in Bundle.meta.security; and maybe that is sufficient for most use-cases. However there might be terms like the data must be destroyed after 90 days.
John Moehrke (Aug 09 2019 at 12:41):
The thing driving this is that some lawyers insist on seeing these 'terms' attached to the data. These lawyers are not satisfied with a B-2-B 'agreement'. Some expect this kind of thing is required by GDPR
John Moehrke (Aug 09 2019 at 12:42):
I know that most are happy separating policy from transaction. This set of people are confident that the release of data would not happen if there was not agreement. So I am not saying that this group doesn't exist...
John Moehrke (Aug 09 2019 at 12:50):
ah, so we could add required fields to carry these terms https://build.fhir.org/ig/HL7/bulk-data/export/index.html#response---complete-status
But are these repeated each response? yuck. Is there response fields only returned on the first? I guess it could be in the original OperationOutcome https://build.fhir.org/ig/HL7/bulk-data/export/index.html#response---success
John Moehrke (Aug 09 2019 at 12:51):
Note I am not looking to push this fast... just experimenting
Grahame Grieve (Aug 09 2019 at 12:53):
it sounds to me like a use for the Contract resource....
John Moehrke (Aug 09 2019 at 13:10):
yes, Contract possibly... my question is how to bind that contract with the bulk response
Josh Mandel (Aug 09 2019 at 18:29):
Right now you can put a Contract inside of .extension.terms.
Josh Mandel (Aug 09 2019 at 18:29):
(The bulk data JSON response format gives you free rein over an "extension" property.)
Jose Costa Teixeira (Aug 10 2019 at 12:11):
The thing driving this is that some lawyers insist on seeing these 'terms' attached to the data. These lawyers are not satisfied with a B-2-B 'agreement'. Some expect this kind of thing is required by GDPR
This aligns with the discussion we had on the Security stream. I for one expect something like this to be required for proper data traceability:
Companies have the obligation to inform who has a given subject's data.
Not only "Hospital A has 2 contracts with company B that may require sending data" but
"Data from patient X was sent from Hospital A to Company B because they need it for Purpose XYZ as stated in contract 1"
Jose Costa Teixeira (Aug 10 2019 at 12:15):
I think there is something linking the transfer and the contract, and not a direct link.
Perhaps that something is a contract clause, perhaps it is an assertion by the DPO. But Contract may be too big a blanket.
Brian Postlethwaite (Aug 10 2019 at 12:40):
Wouldn't that be a consent to use?
Jose Costa Teixeira (Aug 11 2019 at 04:55):
That is my spot : No, i don't think it is a consent (as in "expression of agreement"). In my use cases I am considering that the patient does not need to consent that this data is shared.
There is something there and it should be close to our consent construct, but it does not depend on the patient having a say.
John Moehrke (Aug 11 2019 at 17:57):
Wouldn't that be a consent to use?
Brian, I think there are cases where Consent would be explicitly captured, but there are also other cases where a consent is not necessary but a chain of trust and terms of use must be written down. ALSO, in either of these cases there will likely be equal cases where there is no need for the facts to be inserted into the stream, from those times when participants feel they need to carry the facts in the stream. Thus I am looking for how to do that for those second cases. Carrying one or more consents, or one or more contracts, is a possible once we determine how something can be carried. I think Josh mention of .extension.terms seems the best shot for now.
Brian Postlethwaite (Aug 11 2019 at 22:48):
Ok cool. I wasn't intending patient consents, but no matter.
John Moehrke (Aug 12 2019 at 12:37):
Brian, I am also trying to encode nonPatient permissions in a Consent with no subject. This has uncovered a few modeling gaps, as the current design is rather focused on a Patient as the scope of the Consent. Thus when something else is scope, like Organization or Practitioner, there is a gap.
John Moehrke (Aug 12 2019 at 12:41):
These are not unique or special for bulk-data, but bulk-data really accentuates the issue. Sorry to make it look like I am picking on bulk-data.
Last updated: Apr 12 2022 at 19:14 UTC
