Stream: committers
Topic: STU3 Finalization
Grahame Grieve (Mar 15 2017 at 00:02):
ok, 28 hours left for any kind of substantiative change at all
Bryn Rhodes (Mar 15 2017 at 00:03):
Are summary/modifier flags substantive?
Grahame Grieve (Mar 15 2017 at 00:04):
yes
Grahame Grieve (Mar 15 2017 at 00:04):
my R3 todo list is finally empty
Grahame Grieve (Mar 15 2017 at 00:41):
reminder of deadlines:
end of 15th (in EST timezone):
- no more substantiative changes (including no more changes to examples)
- changes to spelling/grammar/module pages still allowed
end of 21st: complete freeze
- no changes of any sort except by me, until I fork R3 off the trunk
around about 22nd: lift the freeze once R3 is forked
Lloyd McKenzie (Mar 15 2017 at 01:24):
Clarification - that's 28 hours left for both substantive changes *AND* examples. After that, only descriptive changes and mappings are permitted.
Lloyd McKenzie (Mar 15 2017 at 02:51):
From this point forward, there's no need to make patches anymore - just commit changes directly (though if they're substantive changes you'll need FMG permission)
Bryn Rhodes (Mar 15 2017 at 17:19):
Reviewing summary flags, I see that the "description" element of the MetadataResource is not marked as summary. Shouldn't it be?
Bryn Rhodes (Mar 15 2017 at 17:21):
It's summary for all the knowledge resources, what about the conformance ones?
Lloyd McKenzie (Mar 15 2017 at 18:12):
It's borderline - it can be pretty big - a few pages of content, so not ideal for lists. On the other hand, it's pretty useful in verifying "is this what I want". Consistency would be good, but I'm not sure which way to go.
Grahame Grieve (Mar 16 2017 at 04:22):
Last Call for substantiative changes.... I know of a commit coming from Lloyd, and from Brian, and Lloyd has to fix the build....
Grahame Grieve (Mar 16 2017 at 04:22):
there's about 30 minutes left
Brian Postlethwaite (Mar 16 2017 at 04:43):
My commits are in.
Grahame Grieve (Mar 16 2017 at 04:45):
thanks
Grahame Grieve (Mar 16 2017 at 06:42):
ok. well, after a rather messy close out process, substantiative freeze is now on. Only changes possible now are spelling, grammar, and module pages. Anything else needs to be discussed with me
Grahame Grieve (Mar 16 2017 at 11:13):
ok. I've upgraded the trunk to version 3.0.0, which is what the FHIR Release 3 version is going to be
Grahame Grieve (Mar 16 2017 at 11:14):
reference implementation maintainers etc have a few days to synchronise on this.
Grahame Grieve (Mar 16 2017 at 11:14):
I will announce any substantiative changes that I cannot avoid here on this topic until Mar 20th. Then there just won't be any changes
Eric Haas (Mar 16 2017 at 19:19):
What will the base be for STU3 its ( http://hl7.org/fhir) for DSTU2 ?
Grahame Grieve (Mar 16 2017 at 19:22):
it will replace DSTU2 at http://hl7.org/fhir
Grahame Grieve (Mar 16 2017 at 19:22):
DSTU2 will still be available at http://hl7.org/fhir/DSTU2
Grahame Grieve (Mar 16 2017 at 19:22):
STU3 will also be published at http://hl7.org/fhir/STU3
Eric Haas (Mar 16 2017 at 19:25):
OK my DSTU2 IGs will all point to the wrong version. I'll need to make a technical correction and remember that for STU3
Eric Haas (Mar 16 2017 at 19:28):
I'm sure I 'm not the only one who did that. I'll update everyone on the implementers channel.
John Moehrke (Mar 17 2017 at 13:02):
It is a good thing. As one does need to adjust your implementation since DSTU2 and STU3 are not directly compatible. So IHE explicitly points at a specific version, and explains to the audience when the change will happen. IHE is starting the change over to STU3, yet must lag so therefore the EU IHE Connectathon will still be using DSTU2.
Bryn Rhodes (Mar 17 2017 at 20:45):
Just double-checking, we're okay to make mapping changes still?
Grahame Grieve (Mar 17 2017 at 20:45):
yes
Grahame Grieve (Mar 19 2017 at 06:31):
Editors: I see STU notes in the following places:
AllergyIntolerance
Appointment
CarePlan
ClinicalImpression
Composition
Condition
DataElement
Patient
+ workflow page
@Michelle (Moseman) Miller @Lloyd McKenzie @Brian Postlethwaite @Rick Geimer can you please revirew, and from now on until freeze, if you add or delete any of these notes, please tell me immediately, or update the page todo.html which registers them all
Lloyd McKenzie (Mar 19 2017 at 07:07):
DataElement one is up-to-date.
Bryn Rhodes (Mar 19 2017 at 07:20):
Clinical Reasoning has several in the developmental roadmap section, they're not marked as an STU note though.
Grahame Grieve (Mar 19 2017 at 08:18):
pldase mark them using this as a template:
Grahame Grieve (Mar 19 2017 at 08:18):
<a name="[xxxx]"> </a> <blockquote class="stu-note"> <p> <b>STU Note:</b> [text]. </p> <p> Feedback is welcome <a href="http://wiki.hl7.org/index.php?title=FHIR_Specification_Feedback_(STU_3)">here</a>. </p> </blockquote> </div>
Grahame Grieve (Mar 19 2017 at 08:19):
you can replace the URL if you have a place you'd rather have feedback go ot
Grahame Grieve (Mar 19 2017 at 08:19):
some are more complex than simple text - have lists. so that bit is flexible
Bryn Rhodes (Mar 19 2017 at 08:25):
Done and linked on the todo.html page
Grahame Grieve (Mar 19 2017 at 08:25):
thanks
Bryn Rhodes (Mar 19 2017 at 09:00):
There's a Planned Change section in QuestionnaireResponse requesting ballot feedback. Should that be updated to STU feedback?
Lloyd McKenzie (Mar 19 2017 at 09:05):
Actually, it should be stripped as it's been done. I'll update.
Bryn Rhodes (Mar 19 2017 at 09:17):
(y)
Paul Knapp (Mar 19 2017 at 09:18):
Are the patch files sent in over the last couple of weeks not going to be applied?
Grahame Grieve (Mar 19 2017 at 09:19):
umm. they should have been
Grahame Grieve (Mar 19 2017 at 09:19):
if they haven't, that would be due to a communication break-down between Lloyd and I but I thought they all had been
Grahame Grieve (Mar 19 2017 at 09:19):
so what hasn't been applied?
Paul Knapp (Mar 19 2017 at 09:22):
GF12919.patch; PK_mappingSpaces.xml.patch; and claim_2.patch
Grahame Grieve (Mar 19 2017 at 09:22):
are any of these substantiative?
Paul Knapp (Mar 19 2017 at 09:24):
yup that's why they are patches. GF12919 changes element name and binding strength for an element in each of Claim and ExplanationOfBenefit. I don't think there is anything substantive on the others but they are dependent on the first one being applied.
Grahame Grieve (Mar 19 2017 at 09:25):
who did you send them to? I don't see them in my email?
Paul Knapp (Mar 19 2017 at 09:26):
To you on the 8th, 9th and 15th respectively.
Grahame Grieve (Mar 19 2017 at 09:28):
hmm in my mail, I can only find one thread, "FM-QA Patch File" - I can't see anything else from you about pathces
Grahame Grieve (Mar 19 2017 at 09:28):
that will be why I have no memory of them
Grahame Grieve (Mar 19 2017 at 09:29):
so. how important are these? how big a problem is this?
Paul Knapp (Mar 19 2017 at 09:29):
and why they haven't been applied, I have resent, they need to be applied in the order above.
Grahame Grieve (Mar 19 2017 at 09:29):
I have them this time
Grahame Grieve (Mar 19 2017 at 09:30):
crap they went into spam
Paul Knapp (Mar 19 2017 at 09:30):
spam! (shaking of fist)
Grahame Grieve (Mar 19 2017 at 09:31):
I have them all now
Grahame Grieve (Mar 19 2017 at 09:31):
but that's what happened. gmail spammed them
Grahame Grieve (Mar 19 2017 at 09:31):
so, as I said, how big a problem is this?
Paul Knapp (Mar 19 2017 at 09:35):
We can live without - it will mean that the identical element in two resources will be different. But people can agree to pre-adopt the changes as shown in what will then be the current build. For the mapping and examples we can direct them to the current build.
Paul Knapp (Mar 19 2017 at 09:38):
Are we not showing the Workflow mapping anymore? They are not there on Claim although they are on the spreadsheet.
Lloyd McKenzie (Mar 19 2017 at 09:39):
Looks like it got lost somehow. Let me check
Lloyd McKenzie (Mar 19 2017 at 09:41):
The mapping space is still there correctly. Not sure why they're not rendering. @Grahame Grieve - any thoughts? I checked Task and they're not showing up there either. They used to.
Paul Knapp (Mar 19 2017 at 09:47):
Note: the element name change is to change resourceType to resource - so the json framework people might consider that a priority change.
Grahame Grieve (Mar 19 2017 at 10:03):
I changed the mapping renderer to observe the <publish>false</publish> in the mappingSpaces.xml
Grahame Grieve (Mar 19 2017 at 10:04):
which means that no <publish> instructions probably means, don't publish
Grahame Grieve (Mar 19 2017 at 10:05):
@Paul Knapp make all the documentation changes as much as you can - just commit them directly
Grahame Grieve (Mar 19 2017 at 10:06):
with regard to the name change.... we have to decide whether to take that to FMG looking for a decision to allow the substantiative change or not.
Grahame Grieve (Mar 19 2017 at 10:07):
we already declined on request, though we said that if we had to make changes for another reason we'd make it too
Grahame Grieve (Mar 19 2017 at 10:07):
substantiatve changes are definitely getting harder...
Grahame Grieve (Mar 19 2017 at 10:07):
so I'm keen not to, but we will if it's justified
Grahame Grieve (Mar 19 2017 at 10:07):
not sure this one is that
Grahame Grieve (Mar 19 2017 at 10:08):
if I track correctly - there's not a big drive for the change from domain pov, more for the reference implemetations. But for them, it wasn't insoluable.
Paul Knapp (Mar 19 2017 at 10:08):
not understanding the above. The change was already approved at FMG.
Grahame Grieve (Mar 19 2017 at 10:08):
is that a correct summary? or is there more to it than that?
Grahame Grieve (Mar 19 2017 at 10:08):
yes, it was approved, but that was before the substantiative freeze.
Grahame Grieve (Mar 19 2017 at 10:09):
we haven't formally said that FMG has to approve changes after the substantiatve freeze, (whether or not they were already approved), but I'm not willing to make a decision on this on my own with out consulting them
Paul Knapp (Mar 19 2017 at 10:09):
as I said, we can life without it, we will point to the current build for anything not allowed into the Release 3.
Grahame Grieve (Mar 19 2017 at 10:10):
this allows something valid? is that the binding change?
Grahame Grieve (Mar 19 2017 at 10:10):
what's the nature of the binding change?
Paul Knapp (Mar 19 2017 at 10:12):
making the binding the same for both uses at extensible, currently it is example in one and required in the other.
Paul Knapp (Mar 19 2017 at 10:18):
Obviously we'd like the resources to be complete and consistent. That being said are we more important than all other concerns, no. Its a judgement call.
Grahame Grieve (Mar 19 2017 at 10:19):
I think you are leaning to not making it
Paul Knapp (Mar 19 2017 at 10:24):
right, because we can apply currently known fixes to the current build then point people to the version we will freeze in a month for the May connectathon.
Lloyd McKenzie (Mar 19 2017 at 10:25):
@Grahame Grieve Lots of the mappings didn't declare "publish", but I suspect most, if not all of them were intended to publish. I'm going to leave w5 turned off because that shows up elsewhere. Any reason I shouldn't turn the rest on?
Grahame Grieve (Mar 19 2017 at 10:26):
not object implementation mappings
Grahame Grieve (Mar 19 2017 at 10:27):
Paul, your solution seems... temporary.... and that it would degrade....
Grahame Grieve (Mar 19 2017 at 10:27):
which is the required binding that would change?
Paul Knapp (Mar 19 2017 at 10:36):
Which solution would degrade? I'm proposing we apply the fix in R4 - that solution or that the list of resources needs to be able to change over time?
Grahame Grieve (Mar 19 2017 at 10:38):
we can fix it in R4, but it's not something you pre-adopt without getting all the other R4 changes...
Grahame Grieve (Mar 19 2017 at 10:38):
I'm leaning towards making the binding change - which elements are we talking about?
Paul Knapp (Mar 19 2017 at 10:39):
If you were to change ExplanationOfBenefit.payee.resourceType to Coding with the binding 'example' then it would at least match claim and be implementatble.
Grahame Grieve (Mar 19 2017 at 10:39):
oh this change
Paul Knapp (Mar 19 2017 at 10:39):
or you could change the binding in EOB and Claim to extensible.
Grahame Grieve (Mar 19 2017 at 10:41):
what a mess those are - they should be codes bound to value sets on the ResourceType code system
Grahame Grieve (Mar 19 2017 at 10:41):
with required bindings
Grahame Grieve (Mar 19 2017 at 10:41):
I think we'll leave all that to R4
Paul Knapp (Mar 19 2017 at 10:42):
id be good with that change as well.
Paul Knapp (Mar 19 2017 at 10:43):
agree that we should use a central resource valueset, but time ran out.
Grahame Grieve (Mar 19 2017 at 10:43):
ok R4 it is. we'll sort that out then
Grahame Grieve (Mar 19 2017 at 10:43):
again, my apologies for missing this in my email
Paul Knapp (Mar 19 2017 at 10:44):
and if we add that element to the reference data type then we don't need it in these resources at all.
Grahame Grieve (Mar 19 2017 at 10:44):
don't hold your breath for that change. we took it out after much argument, and there's been hardly any discussion about it since then
Paul Knapp (Mar 19 2017 at 11:03):
would it be too much to change the data type on EOB from CodeableConcept to Coding so at least the data types matched?
Lloyd McKenzie (Mar 19 2017 at 11:04):
That seems like it's going the wrong direction
Paul Knapp (Mar 19 2017 at 11:04):
What you think it should be CodeableConcept? What translations are there for resource names?
Paul Knapp (Mar 19 2017 at 11:15):
I'd prefer an external codeset which is updated as resources are added to FHIR in which case the element should be a code with a required binding to a valueset which contains that codeset.
Lloyd McKenzie (Mar 19 2017 at 11:17):
If it's resource names, then it'd be code
Lloyd McKenzie (Mar 19 2017 at 11:17):
Because only HL7 can define them
Grahame Grieve (Mar 19 2017 at 11:23):
there's too many issues here. we aren't going to come to a good agreement and so we'll defer all this to next time.
Paul Knapp (Mar 19 2017 at 11:28):
ok, although we have all agreed with what you wrote "Grahame Grieve: what a mess those are - they should be codes bound to value sets on the ResourceType code system
Grahame Grieve: with required bindings"
Paul Knapp (Mar 19 2017 at 11:29):
if the reference data type isn't changing that I expect that is exactly where we will go.
Grahame Grieve (Mar 19 2017 at 11:29):
ok
Michelle (Moseman) Miller (Mar 19 2017 at 12:41):
- CarePlan -- @Grahame Grieve - I don't see CarePlan listed on the todo.html, nor do I see a note on the resource page.
- Clinical Impression -- I think the clinical impression note should remain since the resource is draft.
- AllergyIntolerance (certainty) -- The allergy certainty note needs to be tweaked, but it won't change the todo summary.
- AllergyIntolerance (No Known) -- Personally, I'd like to delete it, but I think we need to leave it in since we updated the note with a 3rd possible way (extension), which is new to STU3. My preferred method is still using the code element- not the new extension or List empty reason.
- Condition (No Known) -- We didn't explicitly discuss deleting this in Patient Care, but personally, I don't mind deleting it. While we discussed using the code element is acceptable for No Known Problems (and updated the value set accordingly), do we want to close the door to getting more feedback on the topic? @Rob Hausam what is your opinion?
In sum, I will tweak the wording of the AllergyIntolerance certainty note, without impact to the todo page. The others will remain unless I hear otherwise (e.g. No Known Condition note can be deleted).
Grahame Grieve (Mar 19 2017 at 19:22):
thanks. Careplan, I deleted because it had been rendered bogus by changes. It won't hurt to leave others there, I think
Michelle (Moseman) Miller (Mar 19 2017 at 19:43):
Ah, OK, thanks. FYI - the AllergyIntolerance (certainty) tweak is done.
Grahame Grieve (Mar 19 2017 at 20:07):
so I have finished my edits on history.html and todo.html. Committers are welcome to review and suggest items to add to either page
Eric Haas (Mar 19 2017 at 21:08):
Would like to add something for the Observation lastn operation ok to add to todo.html?
Lloyd McKenzie (Mar 19 2017 at 21:20):
Yes.
Grahame Grieve (Mar 19 2017 at 22:07):
hmm. I don't know how to add that..
Grahame Grieve (Mar 19 2017 at 22:09):
what text do you want to add?
Eric Haas (Mar 19 2017 at 22:33):
similar to what PA had:
"STU Note: This is the first draft of this operation and we are seeking input from the implementer community on it and whether it should be extended to other resources such as DiagnosticReport. This could be the subject of a future connectathon testing.
Feedback is sought here .
Eric Haas (Mar 19 2017 at 22:34):
The stu note would go in Observation notes section
Grahame Grieve (Mar 19 2017 at 22:35):
ah ok, well you can just add it there. I thought you would want it on the operations page. Add it to the observations page directly - use the template above I posted for Byrn
Grahame Grieve (Mar 20 2017 at 04:02):
ok, all, it's freeze time.
Grahame Grieve (Mar 20 2017 at 04:03):
As of now, all changes are supposed to be committed, so I can start doing the final publication tasks.
Grahame Grieve (Mar 20 2017 at 04:03):
but it turns out, there's a little more time, since I'm off doing something else for a few hours.
Grahame Grieve (Mar 20 2017 at 04:03):
Lloyd can run the close out schedule for the nexst few hours, since he still has a few changes to make
Grahame Grieve (Mar 20 2017 at 04:04):
warning: we really will be closed after that
Grahame Grieve (Mar 21 2017 at 01:35):
QA issue for next time: deal with hard coded references to build.fhir.org
Eric Haas (Mar 21 2017 at 15:22):
maybe document using some variable like {{ site.data.fhir.path }}?
Grahame Grieve (Mar 21 2017 at 15:32):
there already is one but it only works in the html files.
Grahame Grieve (Mar 21 2017 at 15:32):
not that editors are using it anyway
Grahame Grieve (Mar 21 2017 at 15:32):
but it's being used in more places than that
Last updated: Apr 12 2022 at 19:14 UTC
