FHIR Chat · StructureDefinitions - Type · implementers

Stream: implementers

Topic: StructureDefinitions - Type

Richard Kavanagh (Mar 02 2016 at 08:12):

In a structure Definition when defining an element are the following equivalent

        <type>
            <code value="Reference"/>
            <profile value="http://hl7.org/fhir/StructureDefinition/Patient"/>
        </type>
        <type>
            <code value="Reference"/>
            <profile value="http://hl7.org/fhir/StructureDefinition/Practitioner"/>
        </type>
        <type>
            <code value="Reference"/>
            <profile value="http://hl7.org/fhir/StructureDefinition/RelatedPerson"/>
        </type>
        <type>
            <code value="Reference"/>
            <profile value="http://hl7.org/fhir/StructureDefinition/Device"/>
        </type>

and

        <type>
            <code value="Reference"/>
            <profile value="http://hl7.org/fhir/StructureDefinition/Patient"/>
            <profile value="http://hl7.org/fhir/StructureDefinition/Practitioner"/>
            <profile value="http://hl7.org/fhir/StructureDefinition/RelatedPerson"/>
            <profile value="http://hl7.org/fhir/StructureDefinition/Device"/>
        </type>

Marten Smits (Mar 02 2016 at 09:50):

I think the last example means the reference must conform to all profiles. And the first is a choice.

Michel Rutten (Mar 02 2016 at 12:03):

Hi Richard, during the last WGM in Atlanta I had a discussion with Grahame about the interpretation of multiple profiles. Multiple <type> elements express an "OR" relationship, i.e. the target resource should conform the (at least) one of the listed types. Support for multiple profiles on a single <type> element was originally intended to express an "AND" relationship, i.e. for a target resource to be valid it must conform to all the specified type profiles.
However multiple profiles may express conflicting constraints. In practice, this is (very) hard to compute. Also this introduces challenges for e.g. code generation and UI generation on profiles. Currently I don't know of any FHIR tools that actually provide support for multiple type profiles. Grahame told me that he does not intend to implement support for this. Forge supports multiple type profiles (press enter in the profile textbox to add another line), however Grahame and I agreed that we only consider the first profile for type checking, validation etc. So although Forge accepts additional (secondary) type profiles, they are ignored by the application logic.

Richard Kavanagh (Mar 02 2016 at 13:00):

Thanks Michel - makes sense

Jason Walonoski (Mar 02 2016 at 13:25):

I'm anticipating resources complying with multiple profiles -- in fact, I think the Resource.meta.profile data should be mandatory (I'll make a profile for that [joking]). In the US, I can easily see resources complying with multiple profiles -- both DAF and QICore for example. Or an Observation complying with DAF, QICore, and US Lab. If a resource specifies that it adheres to multiple profiles (Resource.meta.profile is 0..*) then validation tooling should validate all of them.

Grahame Grieve (Mar 02 2016 at 13:46):

Jason: correct

Grahame Grieve (Mar 02 2016 at 13:48):

and that was why the committee added multiple profiles - sounded like a good idea at the time. but the committee that decided that did not include any of us who actually use this stuff, and none of us have done it.

Jason Walonoski (Mar 02 2016 at 13:50):

Not sure who "the committee" is, but I have validation code in Crucible that could easily check multiple profiles (just iterate on Resource.meta.profile). Doesn't seem that hard to me -- am I missing something?

Grahame Grieve (Mar 02 2016 at 14:03):

You're thinking about the wrong element. My validator will validate multiple profiles there too. The element in question is ElementDefinition.type.profile, and what the cardinality of that should be.

Grahame Grieve (Mar 02 2016 at 14:03):

and the committee was CGIT

Last updated: Apr 12 2022 at 19:14 UTC