Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Breaking changes in FHIR 1.0.2 modelinfo

See original GitHub issue

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).

Issue Analytics

  • State:closed
  • Created 6 years ago
  • Comments:5 (5 by maintainers)

github_iconTop GitHub Comments

brynrhodescommented, Oct 3, 2017

Included in 1.2.15

cmoeselcommented, Sep 26, 2017

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.

Read more comments on GitHub >

github_iconTop Results From Across the Web

History - FHIR v5.0.0-cibuild
Remove support for operations on historical resources Breaking change! Change Money Type to make it simpler Breaking change!
Read more >
Release notes — Firely .NET SDK documentation - Firely Docs
BREAKING : FhirClientOperation.Operation has been renamed to RestOperation. BREAKING: Revision of calls to terminology services to support all parameters and ...
Read more >
Releases · LinuxForHealth/FHIR - GitHub
This release includes a backwards-breaking change for users that have extended the IBM FHIR Server with custom operations and/or interceptors. Specifically, the ...
Read more >
No information is available for this page.
Read more >
FHIR Version History and Maturity -
HL7 ® FHIR® has evolved through four releases since its initial presentation ... In that time the standard has improved and changed to...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Post

No results found

github_iconTop Related Hashnode Post

No results found