Talk:FHIR Extensibility Page

Historical (Obsolete) comments

Must Understand

The mustUnderstand attribute appears in both the profile and an actual extension conforming to that profile. Thus there is room for confusion. As the profile defines the extension, if the profile has mustUnderstand set to yes, then the actual extension must also have it set to yes also. (this means that a recipient doesn't need to check the profile when processing a message).

However, it is also possible for the profile to have mustUnderstand=no, and the resource have mustUnderstand=yes (not quite sure of the use case for this would be, but it is permissible).

MustUnderstand worked over after the Atlanta meeting --GrahameGrieve 03:39, 5 June 2013 (UTC)

Context of the extension

GG: this section was based on mis-interpretations of a very misleading profile definition. I restructured the profile definition and clarified the definitions to be clear. This section should be considered as deprecated

The specification mentions a set of contexts of an extension. The spec is just a bit to terse to fully understand what they entail. So, below I have given my interpretation of them, as a candidate for extending the documentation:

In instances, extension elements can be found under the Resource.extensions element and refer to an element in within the same resource. The referenced element can be explicitly identified by the id/idref construction (though that is going to change), but is otherwise determined by the 'path' attribute of an extension definition (see below for details). Logically, this extension becomes a child element of that referenced element.

1. A particular element in a single resource - When defining the extension, the "code" indicates the resource type to which this extension applies, the "path" is the path to an element within that resource that is extended. id/idref is only necessary when this element has a cardinality > 1, to indicate a specific occurrence of the element to extend.
2. Anywhere a particular data type is used - When defining the extension, the "code" indicates the composite type to which this extension applies (how?), the "path" is the path to an element within that composite type that is extended. Unless a specific element is referenced using id/idref, all elements within the resource that are of the type that this extension applies to will be extended.
3. A set of elements across one or more resources - I cannot think of a way to do this unambiguously using code and path. Multiple code/path combi's to indicate specific elements? Just a name and extend any element with that name?
4. A particular context in one of the mapped reference models - This requires a computable mapping specification and deduction of the context from that mapping. "code and "path" would be used to indicate the context within the mapped model (a RIM class + attribute path?) and any element that has a mapping that specifies values for that indicated context would then be extended. The value of the extension is derived from the value of the attribute indicated in the context? Since these extensions are implicitly "created" by the mapping, extensions of this type are not found within Resource.extensions.
5. Another extension - When defining the extension, the "code" indicates the extension to extend. "path" is not used. Logically, this extension becomes a child element of the extended extension. Since the extended extension is itself a child of some element in a resource, this extension is a "grand child" of the resource element the extended extension refers to. (are you still there?)

--Lmckenzi 13:42, 29 June 2012 (UTC)

• I had at one point proposed that resources could identify one or more "groups" that they were part of and that the "code" for context would then just need to identify the group. That would satisfy #3.
• #4 is going to be messy. The mappings will need to include constraints on things like classCodes, moodCodes, relationships, negation, etc. I don't understand what's meant by "these extensions are implicitly "created" by the mapping. They should behave like any others. You define the extension in a profile, identifying where it can occur. You then declare an instance of the extension as part of an actual instance, identifying where it does occur.