Stream: IG creation
Topic: profile combining 2+
John Moehrke (Nov 01 2021 at 14:11):
Is there a way to have a profile combining the constaints of two (or more) other profiles? The structureDefinition.baseDefinition is limited to 0..1. I do understand that combining might need combining rules. So I just wondered if there was a solution.
In my case I have two standalone profiles that each have their own use-cases, but I also want to show the resulting profile of grouping them. (e.g. AuditEvent for RESTful activities + AuditEvent impact on OAuth credentials identifying the .agent participant).
Lloyd McKenzie (Nov 01 2021 at 14:18):
The only thing you can do is inherit from one and mandate that meta.profile contains the URL for the second - and that's not a super attractive solution.
Combining profiles is a tremendously difficult thing to do.
John Moehrke (Nov 01 2021 at 14:26):
understood. :-(
Elliot Silver (Nov 01 2021 at 17:55):
Lloyd McKenzie said:
Combining profiles is a tremendously difficult thing to do.
Do you mean conceptually difficult, or that we've made it tremendously difficult to do?
Grahame Grieve (Nov 01 2021 at 20:39):
both
Grahame Grieve (Nov 01 2021 at 20:39):
simple cases are simple, but the last 10% rapidly turn into an intractable nightmare
Lloyd McKenzie (Nov 01 2021 at 21:17):
E.g. two profiles that have sliced (or better yet, re-sliced) the same element with different discriminators. Especially if the slices overlap. Misery...
John Moehrke (Nov 02 2021 at 15:12):
I expected as such.
John Moehrke (Nov 02 2021 at 15:13):
in my case I know the two profiles are not conflicting. So need to figure out some other way to replicate the profiling.
John Moehrke (Nov 02 2021 at 15:14):
IHE often has cases where multiple IGs are combined to a bigger capability. Sometimes we need to expresess specific behaviours "when grouped"
John Moehrke (Nov 02 2021 at 15:26):
the current model in FHIR allows me to linearly combine profiles into bigger ones. But this forces a specific build sequence. In IHE we have layered approach that allows grouping. This enables more distinct modularity at content, vs transport, vs identity, vs security, vs privacy, etc.
Elliot Silver (Nov 02 2021 at 17:20):
John Moehrke said:
IHE often has cases where multiple IGs are combined to a bigger capability. Sometimes we need to expresess specific behaviours "when grouped"
Lots of organizations have this need. Even HL7 has this need (try profiling vital signs).
Elliot Silver (Nov 02 2021 at 17:23):
Lloyd McKenzie said:
E.g. two profiles that have sliced (or better yet, re-sliced) the same element with different discriminators. Especially if the slices overlap. Misery...
Could we just detect the edge cases and throw an error? If we can detect an error on validation for adding in meta.profile, shouldn't we be able to detect it here? "Multiple base profiles may conflict, please reprofile with one base"
Lloyd McKenzie (Nov 03 2021 at 03:51):
Generating snapshots is already a nightmare. Generating snapshots when you have two bases would be quite horrendous, though I guess it would be done in two phases - first, try to merge the two base snapshots, then apply the differential. So the 'merge' process would be net new code. Having multiple parents would have to be extension space because the cardinality of 'base' is already normative. If we limited the "additional" profiles to not permitting slicing, then perhaps it wouldn't be too bad. However, there'd be lots of other gotchas - if the definitions, comments, etc. are different - which one wins? For a start, perhaps someone should write up a detailed algorithm (probably on a confluence page) that describes the algorithm for merging two sibling profiles going through all of the core elements and standard extensions that can be defined on StructureDefinition and ElementDefinition. If the algorithm isn't a nightmare and the restrictions it imposes don't rule out most of the use-cases people have for doing this, then I guess there's at least a theoretical possibility of it happening.
Grahame Grieve (Nov 03 2021 at 03:52):
there's a simpler way to half solve this: a profile can nominate additional profiles that a resource must also conform to. Doesn't merge the rules, but can be tested and rendered
Lloyd McKenzie (Nov 03 2021 at 03:55):
Can you do that without slicing meta.profile and requiring declarations?
Grahame Grieve (Nov 03 2021 at 03:55):
sure. it'd be an extension in the profile itself that the validator and the renderer know about
Grahame Grieve (Nov 03 2021 at 03:55):
I mean, you could declare it in meta.profile, but you wouldn't need to
Lloyd McKenzie (Nov 03 2021 at 03:56):
Technically, you could do it now without an extension - just assert the profile as an invariant
Grahame Grieve (Nov 03 2021 at 03:57):
i guess. But it would be a lot more computable as a direct declaration
Elliot Silver (Nov 03 2021 at 05:43):
I think @Grahame Grieve 's suggestion would address a majority of the use cases.
Actually, it probably would address all the use cases I can think of, since it would let you solve the complex cases @Lloyd McKenzie is referring to:
- Given complex profile B with base A, complex profile C with base A, and the desire for profile D "inheriting" B and C
- You could have D be based on B, and also conform to C
- You could have D be based on C, and also conform to B
- You could have D be based on A, and also conform to B and C
Which you pick would probably be based on which element descriptions/slicing were closest to how you wanted your profile to look (look, not behave).
Oliver Egger (Nov 03 2021 at 07:00):
Lloyd McKenzie said:
Technically, you could do it now without an extension - just assert the profile as an invariant
we do that approach on our ig's where our national ig is depending on the core and the ihe ig's. see example here: http://fhir.ch/ig/ch-epr-mhealth/StructureDefinition-ch-mhd-providedocumentbundle-comprehensive-definitions.html#Bundle.entry:DocumentRefs.resource it works, however the constraint is quite hidden then and not obvious for implementers.
Last updated: Apr 12 2022 at 19:14 UTC
