Stream: implementers
Topic: Patient confidentiality setting
Elliot Silver (Nov 14 2018 at 04:04):
A discussion came up today at the IHE Radiology meeting, and we were trying to figure out how to map a particular DICOM tag into FHIR.
Confidentiality Constraint on Patient Data Description (0040,0031) "Special indication to the modality operator about confidentiality of Patient information (e.g., that he should not use the Patient's name where other patients are present."
The DICOM attribute is just plain text.
I don't think that the patient-importance extension maps correctly, since this could cover more than VIP status. I don't think it lines up with Consent either. Is this an appropriate use of Flag? Encounter.specialCourtesy?
Grahame Grieve (Nov 14 2018 at 04:51):
sounds like a security label to me
Elliot Silver (Nov 14 2018 at 15:05):
Thanks, I was looking in the resources, and didn't think about labels.
John Moehrke (Nov 14 2018 at 16:01):
Yes, confidentiality would be a security-tag, thus use the meta.security element that is present in every FHIR Resource. Your vocabulary should leverage the HCS vocabulary, but this is extensible so any vocabulary will do based on local policies.
John Moehrke (Nov 14 2018 at 16:04):
Note that ImagingStudy might possibly need to do like DocumentReference, in that these are meta resources. Their own meta.security is the tag for themselves, so they need to carry an element (metadata) for the security-tag of the object they are describing. In the case of DocumentReference this is done with DocumentReference.securityLabel which is describing the security-tags of the attached Binary. For ImagingStudy there might be a need to have a ImagingStudy.securityLabel to do similar for the DICOM object. This enables the metadata resource (ImagingStudy, DocumentReference) to have different security-tag (usually less restrictive) than the object they describe.
Elliot Silver (Nov 14 2018 at 16:21):
I'm not sure how far down this needs to go. The DICOM attribute is in the patient demographics module, and the description includes:
Special indication to the modality operator about confidentiality of Patient information (e.g., that he should not use the Patient's name where other patients are present).
The use case wasn't applying this element to an ImagingStudy. Instead we were considering how a modality would populate a DICOM instance if it was extracting information from a FHIR server, rather than from the typical DICOM modality worklist server. We weren't able to find where we would look to populate this element (or conversely, what expectations we should impose on the FHIR server if we expect a modality to be able to create instances from the information the FHIR server provides).
John Moehrke (Nov 14 2018 at 16:54):
okay, the Patient.meta.security should be sufficient
Last updated: Apr 12 2022 at 19:14 UTC
