FHIR Chat · Extending Choices

When creating a profile, the base resource might contain a property representing the right basic idea, but not the right representation. For example, a profile on Goal might want to support declaring a start period or start age. The “start[x]” property applies, but the choice doesn’t allow for Period or Age (unlike some other date choice properties in FHIR). As I understand it, there are two possible ways to address this:

Create a “startPeriod” extension with context “Goal”. This doesn’t seem like the right approach, in that it spreads the representation of start across the resource and isn’t formally tied to “start[x]”. A consumer that does not understand the extension would interpret an instance containing the extension as having no start, when in fact that is not the case.
Create an extension with context “start[x]”. According to the spec, this means the extension can be applied to any of the existing choices. The problem here is that the Period or Age isn’t really an extension of a datetime or CodeableConcept – it is its own thing. It really should be a sibling to those options, not an extension of one of them. (For the same reason, making the context one of the specific options doesn’t make sense either). <br/>

Is it possible to extend “start[x]” in such a way that the extension is an additional option in the choice – rather than an extension of an existing option in the choice? Semantically, I believe there is a difference between the two.

Grahame Grieve (Jun 09 2017 at 22:28):

no there's no support for doing that, I'm afraid. You'll have to do an extension of one kind of other. And you could create a task on thi

Eric Haas (Jun 10 2017 at 01:34):

task to extend the choices? or a task to add choices to the element?

Grahame Grieve (Jun 10 2017 at 02:01):

to fix Goal

Lloyd McKenzie (Jun 10 2017 at 05:05):

Adding choices to the element would break parsers and schema, so that's pretty much a non-starter for people to do on their own - though it is something for us think about in terms of forward/backward compatibility rules. You could put an extension inside startDateTime that specifies the period or you could create a parallel extension. It might be useful to give guidance to people on which approach is better. I think a parallel extension is less likely to be confusing to implementers

Mark Kramer (Jun 12 2017 at 12:14):

The ability to add choices to [x] is important. There is also a very similar need to add one or more data type choices to non-[x] attributes and turn them into [x] elements. An example is where body site is specified in the spec to be given by a code, but a code alone is insufficient -- for example, the case where the body site is defined by a distance and direction from a landmark. In that case, body site would be a choice of a code or a reference. (I know that's not an [x] example, so maybe it is poorly chosen)

Lloyd McKenzie (Jun 12 2017 at 15:40):

Turning non-choices into choices would be a breaking change as it would require renaming existing elements. That's something we absolutely cannot do once things go normative. Adding additional options to an existing choice doesn't change the path to old data, so that's more of a possibility.