Breaking changes in FHIR 1.0.2 modelinfo

Previously, CQL could reference an Observation’s value as a quantity via the field valueQuantity (e.g., Observation O where O.valueQuantity < 40 'mg/dL').

Since that time, the fhir-modelinfo-1.0.2.xml definition has changed to support the new choice options, and the previous way of referencing a value quantity is no longer valid. Now it seems that you just reference value and the CQL-to-ELM will cast appropriately if needed.

While this is easier for authoring (in some ways), it does reflect a departure from the way that FHIR is actually serialized on the wire – you would never see a value field in FHIR data – it would always be valueQuantity or valueCodeableConcept, etc. From an implementation point of view, I found the more specific field names easier to deal with. (Furthermore, I’m not sure you even see value in the FHIR spec, isn’t it always value[x]?). Is this representation up for discussion or is set in stone?

This also brings up an important point regarding versioning. Our CDS artifacts on CDS Connect were compiled against the old version of the fhir-modelinfo-1.0.2.xml file – and thus use valueQuantity, effectiveDateTime, etc. They will not compile against the new version of that file. The problem is, the modelinfo version number is tied to the FHIR version number (1.0.2), so even though significant breaking changes were made to the modelinfo file, the version number was not incremented – and as a result there is no way for the CDS Connect artifacts to indicate they used the previous version of that modelinfo. Worse yet, there are now two very different versions of the FHIR modelinfo version 1.0.2 floating around.

I think that the FHIR modelinfos (and perhaps others as well) need to somehow support versioning independent of the version of what they’re modeling. This means putting the FHIR version number in the model name and starting at version 1.0 of the modelinfo, or needing to introduce a 4th component to the version number, where components 1-3 match the FHIR version, but component 4 is incremented w/ changes to the modelinfo file (but at that point we are breaking semantic versioning).

[brynrhodes]

Included in 1.2.15

[cmoesel]

If we don’t think others have adopted the DSTU2 model since it’s been merged into master, then I’m fine with rolling it back – and that would make our artifacts in CDS Connect compliant. If we think others have adopted the new one though, I don’t want to put them into the same situation I am – so in that case we would want to offer two variants (but for DSTU2 only – not STU3).

As for labels, it was just an idea for consideration. You’re right though – the labeling would have to be applied to type specifiers, and that would introduce a new pattern. I was trying to figure out how we make DSTU2 support both the new approach and old approach at the same time – but if we rollback the DSTU2 model, then that’s less important – and we can go with standard choices for STU3, as you suggest.

As for modelinfo versioning, I guess we just have different opinions. While I understand what you’re saying, even in the situation you described (a bug that is fixed in the modelinfo), without versioning it’s difficult to identify which artifacts are potentially susceptible to it (e.g., “was this artifact built against the fixed or unfixed version?”). In addition, it means we should never do what you tried to do with DSTU2; there is no opportunity for non-bug-fix enhancements or feature additions – because you would run the risk of breaking artifacts (or implementations) that don’t need to be broken.