Stream: implementers
Topic: FHIR Versions
nicola (RIO/SS) (Dec 02 2016 at 10:54):
Philosophy of changes by Rich Hickey - https://t.co/59VWzjneNa. Rich decomposes versions and deps - may be useful for strategy for FHIR versioning.
Grahame Grieve (Dec 02 2016 at 19:08):
I'm not going to watch an hour video. perhaps you could summarise it here....
nicola (RIO/SS) (Dec 02 2016 at 21:34):
1) Rich analyses dependency/version hell using maven deps as example
2) He identified two types of changes - safe and breaking - adding new is safe and he named it growing/open system, removing or changing is unsafe (there are parallel with immutability ), closed world assumption is also unsafe
3 ) Then he attacked semantic versioning (major versions) - as a best way of break software and create problems
4) He shows examples how to convert breaking changes (removal, relaxation) into safe changes (addition) and successful examples of this approach in real world (unix, html, java, git, clojure, maven by itself) - it's really true - couple of month ago i've updated in our project (after year) clojure version by 2 (1.7 to 1.9alpha20) and about half libraries (>10) to latest versions (also +2/3) and all keep working (only one library from java world was incompatible - jdbc :) - i never had such experience with other languages.
5) the last part is how clojure deals with it especially by clojure.spec
6) So the main point was that you could change system (languages, services, standards:) using growing/open principle, without breakage and dependency hells
My english is awful, may be somebody will spend an hour and explain it better.
Grahame Grieve (Dec 03 2016 at 01:15):
what I heard is: don't make breaking changes....
John Moehrke (Dec 03 2016 at 16:04):
Breaking changes will be forbidden once FHIR goes Normative. Until then, FHIR is a Standard for TRIAL Use (STU). Right now is is best for trial use. If you choose to use it beyond trial use, you take on the risk of the breaking changes that might happen. We have a principle that once we go normative, then no breaking changes will be allowed. Thus ONE version.
David Hay (Dec 03 2016 at 17:47):
Emphasise that's on a 'per resource' basis: http://wiki.hl7.org/index.php?title=FHIR_Maturity_Model
nicola (RIO/SS) (Dec 03 2016 at 19:36):
Rich talks about simple rules (paradigm) how to change and grow system without breakage
Jenni Syed (Dec 05 2016 at 20:44):
Some of those assumptions about what is breaking and not tend to fall down in the real world. Also, there is both forward and backward compatibility in play.
Jenni Syed (Dec 05 2016 at 20:44):
For example, adding a field should be compatible. As it's been defined in FHIR, it is. However, if an app uses a java library to deserialize json that throws an exception when it finds an "unknown" field, it's not as compatible as you once thought
Jenni Syed (Dec 05 2016 at 20:45):
FHIR has said it will eventually be backward compatible. But apps may need to be forward compatible.
Jenni Syed (Dec 05 2016 at 20:46):
And adding a field while accepting writes can get... nasty (not as bad after Patch.. yay!).
Grahame Grieve (Dec 05 2016 at 21:15):
yes, these things are challenging. And we explicitly note the difference between in principle backwards compatiblity, and in practice compatibility
Michael Lawley (Dec 09 2016 at 05:32):
My plea for a simple improvement in FHIR versioning would be having a clear distinction between "moving versions" (eg those like Maven's x.y.z-SNAPSHOT) and fixed versions (x.y.z)
It's really hard when something is called x.y.z and is changing regularly up until some point in time where it's frozen and a new version number is used (but then pointing at changing content)
Note, I'm not calling for every change to have a unique version (that's what commit ids provide), but just a naming policy such that it is possible to distinguish a fixed version from a moving one.
Grahame Grieve (Dec 09 2016 at 06:37):
is this a HAPI issue?
Michael Lawley (Dec 12 2016 at 04:05):
No, I think it's a FHIR issue (see http://hl7.org/fhir/directory.html) "current" is the problem here. It's version is listed as "(last commit)", but in the generated structures the fhirVersion is reported as 1.8.0 (see org/hl7/fhir/dstu3/model/Constants.java). This is also visible in, for example, dataelements.json which in the "current" build (based off 10555 is still called 1.8.0 even though there's a frozen 1.8.0 (based of 10521)
Grahame Grieve (Dec 12 2016 at 06:09):
migrating to 1.9.0 as soon as I can catch my breath. Takes me about 2 hours to migrate versions, so I didn't get to it last week
Michael Lawley (Dec 12 2016 at 06:23):
But can we call it 1.9.0-SNAPSHOT (or similar) instead, otherwise we won't be able to distinguish a final 1.9.0 from any of the interim ones. That is for an x.y.z version, there should only ever be one associated commit id, but for x.y.z-SNAPSHOT, there can be many.
Grahame Grieve (Dec 12 2016 at 07:54):
there will only be interim 1.9.0 versions. When I next do a milestone - probably the final QA version - it will be 1.10.0. Then there'll be R3 which will be 2.0.0
Grahame Grieve (Dec 12 2016 at 23:43):
done
Vadim Peretokin (Jan 16 2017 at 09:50):
I agree with @Michael Lawley , such a distinction wouldn't hurt
Jose Guerrero (May 21 2020 at 19:41):
Is there a law or requirement for certification for EHR Vendors to use the latest FHIR version for interoperability? (for example: using r5 over r4). Also, can an external healthcare facility using a newer FHIR version still make use of fhir resources obtained from an older FHIR version?
Michele Mottini (May 21 2020 at 19:45):
There is regulation in the US that says 'use R4' (and only R4)
Michele Mottini (May 21 2020 at 19:46):
can an external healthcare facility using a newer FHIR version still make use of fhir resources obtained from an older FHIR version
In general no - some specific resources _might_ be compatible (in one direction or both)
Jose Guerrero (May 21 2020 at 21:38):
Michele Mottini said:
There is regulation in the US that says 'use R4' (and only R4)
Thanks @Michele Mottini . where would this information be indicated? or could you point me to a resource so I could learn more about it?
Vassil Peytchev (May 21 2020 at 21:41):
In general no - some specific resources _might_ be compatible (in one direction or both)
Normative resources will be compatible with newer versions (a newer version client will be able to process and understand older version resources).
Michele Mottini (May 21 2020 at 22:57):
@Jose Guerrero which information? The regulation is at https://www.healthit.gov/curesrule/overview/major-changes-proposed-rule-final-rule
Jenni Syed (May 21 2020 at 23:18):
note that the R4 FHIR API piece doesn't go into full effect at health systems until 24 months after publication. Between now and then you'll likely see more and more R4 support coming out :)
Jose Guerrero (May 23 2020 at 00:52):
Michele Mottini said:
Jose Guerrero which information? The regulation is at https://www.healthit.gov/curesrule/overview/major-changes-proposed-rule-final-rule
Yes, Thank you!
Last updated: Apr 12 2022 at 19:14 UTC
