Stream: implementers
Topic: Multiple profile support
Drew Torres (May 06 2020 at 12:31):
It seems it is possible to declare support for multiple profiles in the capability statement. There is a comment in the spec that state that really that means the union of 2 profiles is supported. Has there been thoughts about leveraging that as a way for a client to request specific profiled versions of a resource? The problem that servers may want to address is globalization of their server. Should it be possible for an implementer to build 1 FHIR server that can support multiple profiles and produce profiled version of the same resource without having to fork based on location in code? A client could pass in some header/parameter requesting a specific profiled version of a resource.
Lloyd McKenzie (May 06 2020 at 15:21):
Taking an arbitrary instance and a profile URL and then filtering that instance to adhere to a profile is a super-hard problem. In most cases, an implementation would simply be coded to spit out instances that are valid against all the profiles of interest - which should be possible if the profiles don't inappropriately impose constraints (e.g. limiting name to 1..1)
Drew Torres (May 06 2020 at 16:48):
There are instances where I have seen profiles going even further by profiling a field to 0..0. Then the concern is about extensions for different profiles, and lastly where the profiles use different value sets for some fields.
Drew Torres (May 06 2020 at 16:49):
It may be possible leveraging ontologies to help mitigate mapping internal codes to externally available codes, but then how do you flex that represented resource for each profile.
Lloyd McKenzie (May 06 2020 at 16:53):
Constraining max cardinality is a bad design choice unless it's reflecting a business rule about the characteristics of the business object. For example, prohibiting deceased[x] is fine if the rule is that the patient can't be dead, but prohibiting other things is problematic. Only possible reason is if you're in a "minimum necessary" type situation and need to strip data for privacy reasons - but that should ideally be handled by the privacy layer, not the profile. The desired outcome is you send all possible elements to everyone (filtered by the privacy rules for that recipient), include all codings that are relevant to anyone and for those systems that need to be able to pick one or two items out of a collection, use type, use and other qualifying elements and if necessary extensions to allow them to grab what they need - while still allowing you to send all the others you know.
Drew Torres (May 07 2020 at 04:01):
I agree with the statements made, but I haven't seen that in reality. In multiple regions, I have seen fields removed simply to make the API response "cleaner" making implementation work globally nearly impossible. I would also agree that sending codes from multiple systems should also be OK, but I fear that is not how they would interpret a required binding.
Would it be prudent to add more explicit language around how multiple profiles in a single resource could/should be supported?
Lloyd McKenzie (May 07 2020 at 06:45):
Probably. As well as some guidance around good practice to provide a bit more weight when implementers need to argue with those who are making interoperability harder...
Mikael Rinnetmäki (May 07 2020 at 11:39):
We have had that experience with the #finnish PHR and would have benefited from such guidance.
Frank Oemig (May 07 2020 at 13:29):
We are discussing those topic in the conformance group. But that seems to be too far away ...
David Reeves (Jun 02 2020 at 23:25):
On a related note (I think), is it possible (or desirable) to have multiple profiles of the same resource in a single IG? For example, multiple QuestionnaireResponse profiles representing multiple types of assessments?
Jean Duteau (Jun 02 2020 at 23:27):
I do that regularly. I have multiple Organization profiles depending on use, obviously multiple Observation profiles for different types of Observations.
Lloyd McKenzie (Jun 02 2020 at 23:34):
Generally you wouldn't use profiles on Questionnaire for different types of assessments - you'd just have different Questionnaires. Profiling of Questionnaires is for when you want to set a particular set of rules for a whole collection of questionnaires (e.g. none of my questionnaires are allowed to use value sets).
Last updated: Apr 12 2022 at 19:14 UTC
