Stream: implementers
Topic: Adding extensions to a repeating element
Mark Kramer (Feb 20 2017 at 18:38):
What is the best way to add an extension to a repeating element that is not a backbone element? An example is adding language proficiency to Practitioner.communication, which is 0..* CodeableConcept. You can't add that extension to Practitioner at the top level, because the language proficiency pairs with a specific language. All I can think of is to extend CodeableConcept by adding language proficiency, and then restrict Practitioner.communication to use that profiled version of CodeableConcept. This seems wrong, somehow. Maybe I'm getting hung up on why I should be making an extension to CodeableConcept, and not something more directly associated with communication ability.
Lloyd McKenzie (Feb 20 2017 at 19:00):
You can define the extension with a context of Practioner.communication
Chris Moesel (Feb 21 2017 at 01:07):
@Lloyd McKenzie, in the StructureDefinition profiling Practitioner, does that mean we're defining elements with paths Practitioner.communication.extension?
Lloyd McKenzie (Feb 21 2017 at 06:08):
@Chris Moesel I'm not sure I understand the question. When you're specifying the context for an extension, you can definitely list paths within the resource the extension applies to, not just the base data type or resource. And you can pass type boundaries too. So I could have an extension with a context of Observation.code.coding.system if I really needed to (though that would be a rather odd context for an extension).
Chris Moesel (Feb 21 2017 at 06:17):
@Lloyd McKenzie Isn't the context defined in the extension definition itself? And it just indicates allowable places? How would we indicate in the profile itself that the extension should be applied in communication? Perhaps the extension context is * or can go on any codeable concept -- Even if we list it in the profile, it's ambigous where it goes unless we somehow specifically tie it to the path in the structure definition. Otherwise how does someone using my profile know where it is expected if the element definition context allows it in multiple places?
Lloyd McKenzie (Feb 21 2017 at 08:56):
When you include an extension in your profile, you slice one of the ".extension" elements in your instance where you want the extension to appear. So long as the path to that element jives with one of the context paths specified in that extension's definitions, you're fine. I'm not sure I'm understanding the question here.
Chris Moesel (Feb 21 2017 at 14:20):
@Lloyd McKenzie Sorry if I'm not being clear. Let me try it this way: In the use case above (wanting to add language-proficiency extension to Practitioner, related to Practitioner.communication) -- where do we put the language-proficiency extension in the profile structure definition?
Practitioner.extension:language-proficiency
(in which case the placement doesn't exactly match the context where it is intended to be used), or can we do this:
Practitioner.communication.extension:language-proficiency
The second is preferred, I think -- but Practitioner.communication.extension isn't an existing path element in the Practitioner structure definition snapshot (but you can get there by drilling into the CodeableConcept). So I want to be sure it is legal to add that path to the profile on Practitioner.
Lloyd McKenzie (Feb 21 2017 at 17:47):
You can absolutely drill down into CodeableConcept - or any other data type - when profiling.
Chris Moesel (Feb 21 2017 at 18:01):
Thanks, @Lloyd McKenzie. Sorry it took me so long to ask the right question.
Lloyd McKenzie (Feb 21 2017 at 18:05):
No worries. Slicing is definitely in the deep end of the FHIR pool :)
Last updated: Apr 12 2022 at 19:14 UTC
