Support Obligations and 'Multiple inheritance'-light

[wardweistra]

Is your feature request related to a problem? Please describe.

From R5

R5 has the new obligation extension that can (optionally) be used on Must Support elements to be more specific in what it means in that context: http://hl7.org/fhir/extensions/StructureDefinition-obligation.html
As stated on http://hl7.org/fhir/R5/obligations.html#obligations:

If an element is labelled as "must-support", the element can specify the obligations associated with its use by providing one or more obligations using the Obligation.

It also introduces the Impose Profile extension, which indicates additional profiles that a resource should be validated against: http://hl7.org/fhir/extensions/StructureDefinition-structuredefinition-imposeProfile.html

Instances can only be valid against this profile, if they also successfully validate against the profile referenced by this extension.
This is an instruction to validators to go and check the profile this extension refers to, and enforce that the instance being validated is valid against both source and target profiles. In general, the source profile won't restate the constraints in the target profile.

From the Tooling IG

Alternatively the tooling introduces an alternative way to comply with two profiles, leveraging Obligation, called the Inherit Obligations extension: https://build.fhir.org/ig/FHIR/fhir-tools-ig/StructureDefinition-inherit-obligations.html

Inherit all the obligations from an Obligation Profile

The Obligation Profile Flag extension marks profiles as an obligation profile: https://build.fhir.org/ig/FHIR/fhir-tools-ig/StructureDefinition-obligation-profile.html

Profiles marked to be ‘Obligation Profiles’ cannot introduce new structural elements or slicing, but they can add additional bindings, and additional obligations on the elements that are already defined

Why are they useful?

• The Obligation extension makes the ambiguous Must Support flag more computable.
• Impose Profile and Obligation Profiles both provide a way to allow an author to comply both with, for example, a National base IG and an international realm use case IG. Or, a company wide base IG and a national base/use case IG.

Describe the solution you'd like
Can we support these concepts in the SDK so users can experiment with the best way of conforming with multiple IGs which are not in the same hierarchy?

I imagine the Obligation and Impose Profile extension mainly influence the validator and the Obligation Profile to impact snapshot generation.
Perhaps we should split in three tickets (in order of priority: Obligation extension / Impose Profile / Obligation Profiles), but started like this given their relationships.

Describe alternatives you've considered
Currently these can be used in the IG Publisher for testing.

Additional context
Supporting the tooling IG is more widely captured in #2346

[brianpos]

p.s. Obligations = no thanks, the impose profile extension, yes please! :)

[wardweistra]

@brianpos Not a fan of the regular Obligation extension too? Or just Obligation Profile (Obligation Profile Flag extension/Inherit Obligations extension)

[wardweistra]

Few more conclusions from conversation with @grahamegrieve at WGM:

• ImposeProfile will also in Java tooling be implemented in the 'naive' way, where the snapshot will only take constraints from the base profile into account, and afterwards instances will additionally be validated against the ImposeProfile profile. Since any constraints from the ImposeProfile will not be shown in the snapshot/rendering, this can be annoying for users (elements can be stricken out or made mandatory without showing directly) so this should be used with care by authors.
• The Obligation Profile is constrained in what it can change (Grahame is considering allowing cardinality changes too), so creating a snapshot containing all constraints (from base profile and Obligation Profile) should be possible. Grahame suggested to, when snapshotting an element, check if the other Obligation Profile(s) also have this element, rather than running the snapshot generator over it multiple times.
• Both ImposeProfile and Obligation Profiles will need to be inherited to children.