Extending anonymization / pseudonymization to values which are part of Conditional References.
The most common example is probably identifier match urls, i.e. "reference": "Patient?identifier=http://fhir.test.de/sid/patient-id|123".
This can be achieved by adding an additional Regular expression in the ReferencyUtility class matching those Ids in conditional references.
Currently, only literal references are supported. I suggest treating conditional references as resource references, too (since they are both refering to a FHIR resource and are checked against supported resource types).
In addition, the feature which implicitly sets the domain name (if omitted in the settings) could also be extended.
The resource type can be parsed from both literal and conditional references.
I have tested these changes locally and will create a pull request to further discuss this proposal and review changes. I intend to only support identifier match urls for now, since those are - in my opinion - the most common use case.
Proposed feature
Extending anonymization / pseudonymization to values which are part of Conditional References. The most common example is probably identifier match urls, i.e.
"reference": "Patient?identifier=http://fhir.test.de/sid/patient-id|123"
.Use cases
Conditional References in transaction bundles (https://www.hl7.org/fhir/http.html#trules):
Request urls in Conditional updates (https://www.hl7.org/fhir/http.html#cond-update):
Proposed changes
This can be achieved by adding an additional Regular expression in the ReferencyUtility class matching those Ids in conditional references. Currently, only literal references are supported. I suggest treating conditional references as resource references, too (since they are both refering to a FHIR resource and are checked against supported resource types).
In addition, the feature which implicitly sets the domain name (if omitted in the settings) could also be extended. The resource type can be parsed from both literal and conditional references.
I have tested these changes locally and will create a pull request to further discuss this proposal and review changes. I intend to only support identifier match urls for now, since those are - in my opinion - the most common use case.