Feature iops 3702 withheld data items

[vickyjaiswal0308]

Marking Data Items as Withheld
Where a data item is required for clinical interpretation but must not be disclosed to the patient (e.g. sex assigned at birth used for interpretation of results or genomic analysis), it SHALL NOT be replaced with a placeholder value such as “unknown” or “not stated”.
Instead, the original value SHALL be retained in the FHIR resource for clinical use.
Implementations MAY use security labels or element-level visibility annotations to support classification of such data items. Exclusion from patient-facing views SHALL be performed through implementation-defined disclosure rules applied at the time of data presentation.

[KazeemHamzat]

Keeping the PR for @omarisgreat contribution.

[omarisgreat]

I like the approach but is there any possibility we could align to DS4P extensions/codes, if appropriate? https://build.fhir.org/ig/HL7/fhir-security-label-ds4p/inline_security_labels.html

e.g. use the DS4P extension for the inline label and possibly use something like a core confidentiality code (e.g. using ActCode#TBOO, REDACT or NOPAT) for coding whether the information should be withheld. If not, we might need to take this to DA first to get agreement.

No inline label can then be the default, e.g. allowing patient disclosure

[omarisgreat]

Comment as above

[vickyjaiswal0308]

I like the approach but is there any possibility we could align to DS4P extensions/codes, if appropriate? https://build.fhir.org/ig/HL7/fhir-security-label-ds4p/inline_security_labels.html

e.g. use the DS4P extension for the inline label and possibly use something like a core confidentiality code (e.g. using ActCode#TBOO, REDACT or NOPAT) for coding whether the information should be withheld. If not, we might need to take this to DA first to get agreement.

No inline label can then be the default, e.g. allowing patient disclosure

I initially proposed a custom extension because I interpreted the requirement as a report visibility concern, with the extension acting as an element-level classification marker for report generation. After reviewing the HL7 DS4P IG, I think we should first assess whether the Inline Security Label extension and existing HL7 security label codes can satisfy this use case. While it provides a standard mechanism for element-level tagging, it is primarily intended to express confidentiality and disclosure policies. My understanding was that our requirement is specifically to classify data for patient-facing report visibility while retaining it for clinical interpretation.

[omarisgreat]

I like the approach but is there any possibility we could align to DS4P extensions/codes, if appropriate? https://build.fhir.org/ig/HL7/fhir-security-label-ds4p/inline_security_labels.html
e.g. use the DS4P extension for the inline label and possibly use something like a core confidentiality code (e.g. using ActCode#TBOO, REDACT or NOPAT) for coding whether the information should be withheld. If not, we might need to take this to DA first to get agreement.
No inline label can then be the default, e.g. allowing patient disclosure

I initially proposed a custom extension because I interpreted the requirement as a report visibility concern, with the extension acting as an element-level classification marker for report generation. After reviewing the HL7 DS4P IG, I think we should first assess whether the Inline Security Label extension and existing HL7 security label codes can satisfy this use case. While it provides a standard mechanism for element-level tagging, it is primarily intended to express confidentiality and disclosure policies. My understanding was that our requirement is specifically to classify data for patient-facing report visibility while retaining it for clinical interpretation.

Hi Vicky, I believe the existing HL7 security labels/inline extension can satisfy the use case as I see patient facing report visibility as a disclosure policy, i.e. not disclosing to patient through the report. An example use case was sex of a fetus where the parents did not want to know the sex. In this case, the sex should not be relayed to the patient, the report is currently the only mechanism to return details to the patient but this may not be the case in the future so the solution will most likely need to extend beyond reports. Happy to discuss.