Stream: implementers
Topic: Building permissive profiles with mustSupport flag
Yoni De Witte (Dec 02 2019 at 13:56):
Dear FIR Community,
We recently defined a profile to capure clinical data based on the Observation profile. How it works is that on a workflow trigger our backend creates a new resource with some pre-filled elements. A client application reads that resource and presents it to a clinical user who fills in some additional data and the application persists that to our backend by updating the resource. Our FHIR service is only a facade so we don't support every element in the Observation resource. At first we naively defined our own MyObservation profile which modifies types, constraints and cardinality of the Observation profile to exactly match our backend. Inspired by talks on the Amsterdam DevDays, we started thinking about making our profiles more permissive and using the mustSupport flag. Our current interpretation is that when reading a resource, we can include all the elements that our backend supports. Elements that are not supported can be left out as long as the profile does not mark them as required. For all operations that modify the resource, we set mustSupport=true and if needed restrict the profile to indicate what we allow to be persisted.
Some concrete examples on our MyObservation profile, which is based on the Observation profile:
- Observation.code: This element is pre-filled by the backend. We do NOT set mustSupport to true, because that would indicate that the client application can change the code and update the resource, which we do not allow. If a client would change the code and update the resource, we ignore that element.
- Observation.subject: We always link an observation 1-1 to a patient automatically on the backend. That is compliant so we don't need to modify cardinality to 1..1 and restrict the Subject type to Patient. Again mustSupport=false since we don't allow clients to relink the resource to another patient.
- Observation.bodySite: This element is to be filled in by the client, so we set mustSupport=true and we persist on update.
- Observation.hasMember: This element is to be filled in by the client, so we set mustSupport=true. The members are resources of a proprietary 'Foo' profile, so we need to modify our MyObservation profile to set the allowed target to a single value, being our Foo profile.
Is this the correct interpretation of permissive profiles and the mustSupport flag?
Thanks!
René Spronk (Dec 02 2019 at 14:08):
On the first two I'd reject the instance sent by the client, 'not allowed to change', the client is breaking a business rule. Ignoring that may lead to patient safety issues.
Obs.hasMember: do ALL referenced resources have to conform to Foo, or is it OK to have a Bar, as long as there is at least one Foo ?
René Spronk (Dec 02 2019 at 14:09):
To me .code and .subject sounds like they're mustSupport. However, given that definition of 'mustSupport' is up to you (as a project), what do YOU defined mustSupport to be?
Yoni De Witte (Dec 02 2019 at 15:02):
Yes, all referenced resources have to conform to Foo. If there is a Bar, we can ignore it or return an error.
We don't yet have mustSupport defined in our project. So we're open to suggestions from the community what that definition should be. I would say that there are 3 categories of elements in our application:
1) read-only elements which are populated and persisted by the backend
2) elements which MAY(not SHALL) be populated by a client and are persisted by the backend
3) elements which are not persisted by the backend
In the current proposal, we would use the mustSupport-flag to distinguish elements of category 2. The difference between elements of category 1 and 3 is simply that category 3 elements are missing when the resource is read, as they are not persisted.
Lloyd McKenzie (Dec 02 2019 at 15:55):
Ignoring an element and throwing it away is a bit different than ignoring an element and holding onto something else. I'd certainly recommend at least including a warning about elements that you ignore but store something else.
Grahame Grieve (Dec 02 2019 at 17:34):
mustSupport = true does not imply that the client has the right to change the value. Only that you think it's not safe if a client ignores the element.
Grahame Grieve (Dec 02 2019 at 17:34):
We've not really had much discussion about specifying rules in a computable form over what can changed or not by the client
Lloyd McKenzie (Dec 02 2019 at 18:19):
mustSupport isn't about what's "safe", it's about what a system is expected to do/pay attention to. So if you want to say "I will pay attention to elements A, B and C, but not to anything else", then marking A, B and C as "mustSupport" is appropriate. And if you're going to ignore submitted data, not marking it as mustSupport is the appropriate way to designate that. What's a bit unique here is that you're ignoring submitted data - but then asserting your own value for it. That's not typical/expected behavior, so throwing out a warning message would be good practice.
Last updated: Apr 12 2022 at 19:14 UTC
