Stream: fmg
Topic: STU confusion
Grahame Grieve (Mar 21 2017 at 00:13):
After quite some confusion amongst the insiders (let alone outsiders) today, I'm going to refer to TSC the problem of "US-CORE STU1 based on FHIR STU3"
John Moehrke (Mar 21 2017 at 11:48):
are we going to always force brand-new projects to use the FHIR STU number? That is going to look very ugly 3 years from now. Everything should version based on their own ballot, their titles can contain other signficant identifiers. Note this is what I did in IHE with the various profiles. They each have their own version, but their title indicates which FHIR DSTU they have profiled.
Grahame Grieve (Mar 21 2017 at 12:01):
that's where we are now. feedback from insiders is that it's confusing. Ive leant not to ignore that kind of feedback
John Moehrke (Mar 21 2017 at 12:06):
Grahame, who are these people that don't understand versions? (Don't answer that, I don't want to know... well I do, but don't). These people are driving ridiculous behavior at the technical level. Next year when we are at R4, and someone brings a brand new IG proposal; are we going to require that their first ballot at R4? This logic does not work. All this because a few executives can't understand the concept of versions?
Paul Knapp (Mar 21 2017 at 12:11):
There are naming rules to be followed, or amendments suggested, rather than ad hoc specification naming.
Lloyd McKenzie (Mar 21 2017 at 15:25):
The discussion would lead to a proposed change to the rules. In the end, the rules need to serve the needs of the community.
Lloyd McKenzie (Mar 21 2017 at 15:27):
I think moving to a year-based labeling might be easiest for most to wrap their heads around. It would mean that US Core 2018 would be based on FHIR 2018, which would be nice and clean. In the unlikely event there were two releases of an IG in a single year, we could go with US Core 2018B or something like that. (No chance of it happening to the base standard I think)
Lloyd McKenzie (Mar 21 2017 at 15:27):
We'd need to deal with the fact that some years there wouldn't be a release and make sure people know that going with the year in the name isn't a commitment to annual releases, but I think that's doable.
Lloyd McKenzie (Mar 21 2017 at 15:28):
Only downside I can see is if there was a US Core 2018 published in Jan and a FHIR 2018 published in Nov. One wouldn't be tied to the other.
Grahame Grieve (Mar 21 2017 at 15:29):
DICOM are on a 10-12 week cycle. We could be later on too
Grahame Grieve (Mar 21 2017 at 15:29):
I don't say that this is likely, but it is possible, and a quicker turnaround has advantages
Lloyd McKenzie (Mar 21 2017 at 15:31):
I suppose if what was changing was rigorously controlled, review wouldn't have to be as evil as it is now.
Last updated: Apr 12 2022 at 19:14 UTC
