Stream: fmg
Topic: Technical Correction
Grahame Grieve (Apr 06 2017 at 10:31):
ok. so I have a list of tasks to apply as part of the technica correction. What's the process after that? Do I need to post a preview of the technical correction anywhere?
Lloyd McKenzie (Apr 06 2017 at 15:01):
That's probably a question for @Paul Knapp or @John Moehrke - our TSC reps
John Moehrke (Apr 06 2017 at 15:15):
oh sure, call out the noisy ones..... I would really like to see the change much more clearly than we have seen in the proposals today. A trial-balloon is that the CP could be applied to continuous build, so that we can see what the solution looks like. This would be ideal solution in my view... and something that leverages the fact that STU3 is a branch, while build is more freely changeable...
John Moehrke (Apr 06 2017 at 15:20):
and I can't spell TSC... so don't look to me as a TSC rep
Paul Knapp (Apr 06 2017 at 16:38):
Agree with John. I think you should stand up a site with the changes applied so that a quick QA can be done, provide the errata and request the publication of the technical corrections from the CTO.
Grahame Grieve (Apr 06 2017 at 20:27):
for me. that's not agreement. I will have to make the changes to the current build. if people look at them there, that's fine. If I put up another site, that's probably at least a days work for me to do so
John Moehrke (Apr 06 2017 at 20:35):
I specifically meant the current build.
Grahame Grieve (Apr 06 2017 at 21:01):
y. that's not what Paul said..
Grahame Grieve (Apr 07 2017 at 06:08):
ok, I believe that all the technical corrections except for 13168 have been applied to the current build, though it has to build a few times yet
Grahame Grieve (Apr 07 2017 at 07:14):
13168 turned out to be easy - committing shortly.
Grahame Grieve (Apr 09 2017 at 02:44):
ok the technical correction is applied. I'm now on vacation till Thursday, and I don't have the bandwidth to post a technical correction from here, so I'll be posting it over easter. What does FMG need to do so it can ask CTO to approve?
I hope that the answer is: you can all look at here: http://build.fhir.org/history.html#v3.0.1 and work from the links
Lloyd McKenzie (Apr 10 2017 at 22:51):
If I don't hear of a concern by end of day tomorrow, I'll forward the Technical Correction Request letter to Wayne on the basis of our Wed. vote
Grahame Grieve (Apr 19 2017 at 12:20):
The technical correction is posted at http://hl7.org/fhir/STU3-tc1. When FMG approves the 2 extra tasks I added to it on tomorrow's call, I'll rename it to /STU3, and the existing /STU3 will become /ST3-tc0. The I'll update the copy at http://hl7.org/fhir
Grahame Grieve (Apr 19 2017 at 12:21):
the two extra tasks are GF#13217 and GF#13218
Grahame Grieve (Apr 19 2017 at 12:22):
I'll also update the release dates
Lloyd McKenzie (Apr 19 2017 at 15:08):
Is there a reason to retain ST3-tc0? We haven't done that in the past with technical corrections
Grahame Grieve (Apr 19 2017 at 19:57):
it was identified as an issue in the past when we did not.
Lloyd McKenzie (Apr 19 2017 at 19:58):
By whom? Certainly we need to have a snapshot we could retrieve if necessary, but I don't see any reason to have a hosted version available.
Grahame Grieve (Apr 19 2017 at 19:58):
Paul, I think
Grahame Grieve (Apr 19 2017 at 19:58):
I wasn't going to link to the -tc0 copy
Lloyd McKenzie (Apr 19 2017 at 19:58):
We can discuss today
Grahame Grieve (Apr 19 2017 at 20:21):
also GF#13221
David Hay (Apr 19 2017 at 21:59):
GF#13221 - is this the one with the rogue file? (but all the other files present)
Grahame Grieve (Apr 19 2017 at 23:24):
yes
Paul Knapp (Apr 22 2017 at 19:39):
Yes you should keep the originally published version.
Lloyd McKenzie (Apr 23 2017 at 15:16):
We agreed to keep it as a zip only
Grahame Grieve (Aug 07 2019 at 00:10):
On the subject of the technical correction.... for R2, the only technical correction to make is to update the package.. so in fact, that's not a technical correction since R2 doesn't mention packages at all. So I'll just post the new packages, with no other chanages
Grahame Grieve (Aug 15 2019 at 19:29):
I've given up trying to get the technical correction out on schedule; it won't happen until after Atlanta now. see https://chat.fhir.org/#narrow/stream/179177-conformance/topic/Warning.20-.20Technical.20Correction for the nasty details
Grahame Grieve (Oct 22 2019 at 06:51):
ok final copy of the technical correction open for review at http://hl7.org/fhir/R4B
Grahame Grieve (Oct 24 2019 at 03:30):
and the R3 technical correction at http://hl7.org/fhir/STU3TC2 (it's still uploading, for another 12 hours or so)
Richard Ettema (Oct 25 2019 at 13:20):
Just checked STU3TC2 Observation constraint obs-7 and it has not been updated to match the correct expression in R4. I see GF#14073 for R4 but not one for STU3.
Lloyd McKenzie (Oct 25 2019 at 21:48):
We need two more votes for the technical correction before Grahame can proceed. @Josh Mandel @Brian Pech @Brian Postlethwaite @Paul Knapp @David Hay @John Moehrke
Lloyd McKenzie (Oct 25 2019 at 21:48):
https://confluence.hl7.org/display/FMG/FMG+e-Vote+2019-10-24
Josh Mandel (Oct 25 2019 at 21:51):
Thanks. I just followed up on the email thread.
Grahame Grieve (Oct 25 2019 at 21:51):
@Richard Ettema right. I did not have a task to fix obs-7 for R3, and nor was it obvious that met my criteria for fixing, which is that it is giving false fails
Josh Mandel (Oct 25 2019 at 21:54):
(and now followed up in the confluence website )
David Hay (Oct 25 2019 at 22:55):
OK by me...
Richard Ettema (Oct 25 2019 at 23:07):
@Grahame Grieve ok. Should I create a tracker item for this and, if so, will it get in to 3.0.2?
Grahame Grieve (Oct 25 2019 at 23:46):
does it need to be fixed? Does it generate spurious errors, or does it just not work?
Richard Ettema (Oct 25 2019 at 23:51):
It needs to be fixed. The reason it was fixed for R4 is same reason it needs to be fixed in STU3. I doesn't work.
Grahame Grieve (Oct 25 2019 at 23:55):
I'm only fixing constraints in STU3 if they wrongly fail resources, not if they don't work
Grahame Grieve (Oct 25 2019 at 23:55):
or if FHIR-I says so. But I'm pretty late in the process
Richard Ettema (Oct 25 2019 at 23:56):
Sorry. You asked if it didn't work and to me that means validation against this constraint wrongly fails.
Grahame Grieve (Oct 25 2019 at 23:57):
does that happen? have you get an example resource that is valid but fails?
Richard Ettema (Oct 25 2019 at 23:59):
I can get you one. Might take me a little while to find. Get back to you as soon as I can.
Grahame Grieve (Oct 25 2019 at 23:59):
thx
Richard Ettema (Oct 26 2019 at 00:35):
Ok. Got one. This Observation has a code and value with a component.code equal to the code which should fail obs-7 in STU3 but it validates successfully. The issue is the fact that there is more than one component. The extra component causes the constraint to pass.
Observation-obs-7-invalid.xml
Grahame Grieve (Oct 26 2019 at 00:43):
so it doesn't wrongly fail it, it wrongly passes it?
Richard Ettema (Oct 26 2019 at 00:44):
Correct.
Lloyd McKenzie (Oct 26 2019 at 01:27):
Can it wrongly fail? I.e. Reject a legal instance?
Grahame Grieve (Oct 26 2019 at 04:49):
I don't think it can
Richard Ettema (Oct 26 2019 at 17:07):
I would agree, I don't think it can. The question is then - is wrongly passing an illegal instance just as severe as wrongly failing a legal instance?
Lloyd McKenzie (Oct 26 2019 at 17:21):
The validator can't ever protect you from sending all possible illegal instances. So this particular error just means that something that could theoretically be caught automatically won't be.
David Hay (Oct 26 2019 at 18:13):
(deleted)
Richard Ettema (Oct 28 2019 at 13:28):
I wouldn't call this theoretical but actual. I have an actual FHIR R3 3.0.1 Observation resource instance that according to the FHIR R3 3.0.1 base Observation profile should fail validation. However, the FHIR Validation Engine wrongly passes (validates) this instance.
If this was deemed necessary to correct for FHIR R4 4.0.0, why wouldn't it be deemed necessary to correct for the FHIR R3 3.0.2 technical correction?
Grahame Grieve (Oct 28 2019 at 13:55):
because we are correcting more things in R4 than R3
Richard Ettema (Oct 28 2019 at 14:10):
Let me provide the context behind my request. (Apologies for not doing this sooner.) My interest in the STU3 obs-7 constraint is actually prompted by my work with Nictiz and their profiles.
The Nictiz MedMij IG is based on FHIR STU3 3.0.1. Early on in their testing program they found that a number of their Observation profiles were running into this issue where the validation engine was incorrectly passing Observation instances due to the obs-7 constraint. In order to correct this issue I have been manually updating their Observation profile snapshots to update the obs-7 constraint with the corrected expression from FHIR R4.
I had hoped that this would be resolved in the R3 3.0.2 technical correction but it appears that my arguments have not been persuasive.
If the obs-7 constraint is not updated, this will require that I continue to manually update the Nictiz MedMij Observation profiles so that we can continue to support them when they update their IG to R3 3.0.2.
Grahame Grieve (Oct 28 2019 at 14:27):
I guess maybe we should fix it then.
Grahame Grieve (Oct 28 2019 at 14:28):
So I want FHIR-I to approve 3 things today, so that I am good to release the technical corrections:
- this change
- the change to the FHIRPath constraint on CareTeam
- the NPM package spec (still waiting final resolution on .index.json)
Richard Ettema (Oct 28 2019 at 14:29):
Do you need a GForge tracker for this item?
Grahame Grieve (Oct 28 2019 at 14:29):
and I propose that we take these particular things as approved by FMG when the technical corrections are approved by FMG (which I don't believe has quite happened yet), but I am super keen to get the technical corrections out in the next couple of days
Grahame Grieve (Oct 28 2019 at 14:29):
otherwise when is the next opportunity?
John Moehrke (Oct 28 2019 at 16:36):
starting to be very questionable why we are not applying ALL future fixes to ALL past versions of FHIR... sure looks like one more straw on that camel's back.
Lloyd McKenzie (Oct 28 2019 at 17:10):
Workload - the amount of effort would be double or quadruple. Plus there'd still be a dividing line between what's a "necessary fix" vs. what's a "breaking change introduced in the new version"
John Moehrke (Oct 28 2019 at 17:16):
it is not clear to me anymore what our definition of a "necessary fix". all chages to future versions of FHIR were considered 'necessary' by someone...
John Moehrke (Oct 28 2019 at 17:20):
I would much prefer that we did NO modification to old versions. They are old "STU" versions, we warned everyone. I recognize that there is some fixup is more reasonable. But fixing things just because it is inconvenient for some project who has chosen to not move forward seems very much NOT what we should be doing. Because if we do that kind of "necessary fix", we will be in continual maintenance of all past versions.
Lloyd McKenzie (Oct 28 2019 at 17:29):
We make modifications to old versions where they fundamentally can't work - I.e. the technical representation causes tooling to blow up/fail. We don't generally do other things.
Lloyd McKenzie (Oct 28 2019 at 19:12):
FHIR-I moved approval for GF#14073 for publication in STU3 technical correction
Richard Ettema (Oct 28 2019 at 19:46):
Thank you.
Lloyd McKenzie (Oct 28 2019 at 20:02):
@Grahame Grieve FHIR-I did all 3 things you asked for
Grahame Grieve (Oct 28 2019 at 20:53):
Ok thanks
Grahame Grieve (Oct 31 2019 at 04:43):
well, getting this technical correction up has turned into a bit of a monster. I've had to add a couple of things to the packages to make everything work:
- I add a 'fhir-version-list' property to the npm package.json file, an array of string
This is added so that a tool an always tell what fhir-versions the package is for. This was necessary because in the past, the package would simply refer to the core dependency, even if the package it was referring to didn't- and would never - exist. Now, they can't refer to packages that don't exist. So package references can no longer tell you what FHIR version except for the major releases. And many of our balloted IGs don't depend on a major release
Grahame Grieve (Oct 31 2019 at 04:45):
- I added "sub-packages" - array of string - to package-list.json
This was because we now publish the main spec as a set of packages, and I had to know about them somewhere - it's only a message to the publishing tool that builds the package RSS feed
Grahame Grieve (Oct 31 2019 at 04:45):
there's a certain amount of irony in the fact that I just went and added these the same week we decided that changes required FHIR-I approval... but I couldn't complete posting the technical corrections without doing that
Grahame Grieve (Oct 31 2019 at 04:46):
I'll talk to FHIR-I about that
Grahame Grieve (Oct 31 2019 at 04:46):
but there's a much more pernicious problem I hadn't realised before this, and I don't really know what to do about it
Grahame Grieve (Oct 31 2019 at 04:48):
because I am rebuilding the package infrastructure as part of this technical correction (very surely something I will never do again), I have to rebuild and replace all the NPM packages for all the published IGs. I have done and uploaded all the ones on hl7.org, and now have to do fhir.org. And the replaced packages now have to refer to the technical corrections for R3 and R4. Which I think that we want to be the case anyway
Grahame Grieve (Oct 31 2019 at 04:49):
but I haven't done technical corrections for the IGs themselves.. only the packages (we did approve this several months ago),
Grahame Grieve (Oct 31 2019 at 04:49):
which leaves the IGs in an odd state: they declare on the website that they depend on 3.0.1 or 4.0.0, but the packages depend on 3.0.1 or 4.0.1 instead.
Grahame Grieve (Oct 31 2019 at 10:58):
ok - progress update:
- all the package infrastructure is replaced with the new package infrastructure, with technical corrections
- the R3 and R4 technical corrections are posted
- I still have to upload all the other HTML files that have changed (they need to point to a new current version in their publish-box, and I have other consistency changes to make in the html behind the scenes)
- the validator is nearly working - one serious bug has emerged; it looks like a whole day to fix it, so I may release a partially working validator (problem in validating slces)
Grahame Grieve (Oct 31 2019 at 10:58):
- the IGPublisher isn't working
Grahame Grieve (Oct 31 2019 at 10:59):
p.s. both the validator and IG publisher may be working for you right now if your cache is fully populated and nothing happens to the cache, but as soon as anything non-cacheable crops up... boom
Grahame Grieve (Oct 31 2019 at 23:06):
@Wayne Kubick has been looking at the technical correction, and would like a statement like this:
Grahame Grieve (Oct 31 2019 at 23:06):
"The FHIR Management Group has reviewed and approved all the changes, and confirmed that there was no impact on the ANSI normative content of FHIR R4."
Grahame Grieve (Oct 31 2019 at 23:07):
@David Hay @Lloyd McKenzie can we quickly approve this statement please
Lloyd McKenzie (Oct 31 2019 at 23:09):
Can we rephrase that to "no substantive impact"?
Lloyd McKenzie (Oct 31 2019 at 23:09):
Obviously there was some impact
Grahame Grieve (Oct 31 2019 at 23:09):
@Wayne Kubick ?
Grahame Grieve (Oct 31 2019 at 23:10):
but I think that's the intent
Lloyd McKenzie (Oct 31 2019 at 23:12):
I'm happy to approve the statement with that amendment
Wayne Kubick (Oct 31 2019 at 23:14):
I don't mind the words "no substantive impact" - if accurate. that's a very strong statement which clearly limits this to a true errata. But given that we have mixed normative and STU content in R4. I think it's also worth clearly adding "and thus has no impact on normative content" or something like that.
Wayne Kubick (Oct 31 2019 at 23:16):
Recall that this one will be subject to ANSI audit, so we want to reassure them we didn't break the normative rules, since our errata process doesn't apply to changes to a normative spec.
Grahame Grieve (Oct 31 2019 at 23:16):
"The FHIR Management Group has reviewed and approved all the changes, and confirmed that there is is no substantive impact on the ANSI normative content of FHIR R4."
Grahame Grieve (Oct 31 2019 at 23:16):
that does the job, no?
Wayne Kubick (Oct 31 2019 at 23:16):
That works. I can add it to the CTO letter as well.
Grahame Grieve (Oct 31 2019 at 23:17):
ok. I will go with that
Wayne Kubick (Oct 31 2019 at 23:18):
Just note you have 1 too many of "is"
Grahame Grieve (Oct 31 2019 at 23:32):
btw, should there be discussion about this, here is the rationale for 'no substantive changes on ANSI Normative content:
- Add Meta as a special type: Only relevant on $meta operations, which are trial use. Any existing normative use is unchanged
- Change all code system OIDs: there is no normative functionality linked to the code system OIDs
- Add new FHIRPath variable and use it: there is no impact to existing implementations, except for validators, which must support this. Validators are not implementing a normative part of the specification
- fix genomics URLs: no normative part of the specification references these URLs
- fix FamilyMemberHistory binding - it is not Normative
Grahame Grieve (Oct 31 2019 at 23:33):
The rest of the changes are aligning technical represenations with normative statements, or non-substantive clarifications
David Hay (Oct 31 2019 at 23:38):
happy to approve...
Lloyd McKenzie (Oct 31 2019 at 23:56):
I endorse the revised wording
Last updated: Apr 12 2022 at 19:14 UTC
