Stream: conformance
Topic: Allowed element changes on UPDATE
Simone Heckmann (Mar 07 2022 at 13:57):
I have been asked whether there is an option to indicate in a profile, which elements are allowed to be changed on an update: e.g. you can change the date on a Procedure but not the Patient-Reference. Of course, systems can always return errors if business logic is violated when processing an update, but I think there is also a benefit in telling Clients beforehand what they can and cannot do.
Any ideas on how to profile that?
Lloyd McKenzie (Mar 07 2022 at 19:34):
There are no discrete data elements for that purpose. Often the rules vary based on business state as well as who's making the change. For example, changing the drug on a MedicationRequest in 'draft' state is fine. Changing it once it's active it not. Similarly, there may be restrictions on who's allowed to correct a patient's birthDate.
John Moehrke (Mar 07 2022 at 20:12):
possibly this could be a use-case for Permission, but it is not yet today a use-case for Permission. Unclear what the use-case need is.
Chris Moesel (Mar 07 2022 at 23:08):
It's almost like you need an onUpdate constraint that would allow you to use FHIRPath with built-in $current and $updated variables so you can do whatever checks you want and return true/false. That said, I bet you might run into some gnarly FHIR path depending on the complexity of what you need to do.
Grahame Grieve (Mar 08 2022 at 05:06):
I have such a thing in my server - see EventDefinition
Jens Villadsen (Mar 11 2022 at 10:12):
@Grahame Grieve you got an example of such an EventDefinition?
Grahame Grieve (Mar 11 2022 at 10:13):
not off hand
Grahame Grieve (Mar 11 2022 at 10:13):
@Bryn Rhodes might
Simone Heckmann (Mar 21 2022 at 12:49):
I am not sure whether this needs to be computable for a validator. I'd leave it to the server to decide where these checks happen (whether it's interface logic or business logic or database logic). I am merely looking for a way to indicate through profile to a client what can and cannot be changed, so they can adapt and e.g. allow/not allow user edits in the UI. In the simplest of cases, it could be a boolean flag on element level.
But I agree, that a dependency on Resource status is avalid use case.
Last updated: Apr 12 2022 at 19:14 UTC
