Using PDS FHIR API on INT, most patients are assigned confidentiality code U (Unrestricted)
. For example (trimmed for brevity):
{
"birthDate": "2021-03-07",
"id": "9449306028",
"meta": {
"security": [
{
"code": "U",
"display": "unrestricted",
"system": "http://terminology.hl7.org/CodeSystem/v3-Confidentiality"
}
]
},
"resourceType": "Patient"
}
The security codes are taken from the HL7 V3 Confidentiality CodeSystem.
Code U
means:
Privacy metadata indicating that no level of protection is required to safeguard personal and healthcare information that has been disclosed by an authorized individual without restrictions on its use.
This metadata indicates that the receiver has no obligation to consider privacy policies other than its own when making access control decisions.
I would have expected the default to be N (Normal)
.
Does the production system also assign U
as the default confidentiality code?
Hi.
Please see Personal Demographics Service - FHIR API āGet Patient detailsā schema for the meta.security.code values and their meaning - Personal Demographics Service - FHIR API - NHS Digital
These are used in all environments.
Hi David,
Thanks for your response. Iāve reviewed the information on the link you provided and this doesnāt resolve the query.
There are 2 interpretations of the PDS FHIR API behaviour:
-
PDS FHIR API intentionally defines the returned data as U (unrestricted)
as per the HL7 V3 Confidentiality CodeSystem ā⦠indicating that no level of protection is required to safeguard personal and healthcare information that has been disclosed by an authorized individual without restrictions on its use.ā This option āindicates that the receiver has no obligation to consider privacy policies other than its own when making access control decisionsā, which appears to contradict the data sharing agreement.
-
PDS FHIR API intentionally redefines the meaning of the HL7 V3 Confidentiality CodeSystem so that U (unrestricted)
actually means N (normal)
. This option wouldnāt be best practice for FHIR implementation. There is a risk that a receiver is unaware of this redefinition e.g. where the Patient resources are synchronised with a local system that makes FHIR resources available within a local system.
Unless advised otherwise, weāll assume the latter and implement a workaround in our implementation so that we mitigate the risk of a data breach.
Thank you for your response. We will take a look at this further and get back to you.
Is there any update on this?
Hi. Unfortunately not. A ticket has been raised to confirm the reason behind this design decision, made a number of years back now.
I will link this conversation in the ticket so that when the ticket is concluded, an update will be posted here. Given various constraints, Iām unable to give you a timeframe for this.
Thanks for letting me know.
Has this been raised with your DPO?
Hi Dunmail, many thanks for raising this. The default should be āNā or not returning a security code by default. I will look into the redefinition and align to best practices where applicable (IG guidance will also be sought as part of the process). As this will be breaking change, we will consider this for PDS FHIR V2. I will follow up this thread with delivery timescales.
1 Like
Hi Christina,
Thanks for the update - itās much appreciated!
Dunmail