Stream: committers
Topic: Closing up tasks
Grahame Grieve (Dec 09 2018 at 23:57):
GF#12365 - is this going to happen? should I do it? @Brian Postlethwaite @Cooper Thompson
Grahame Grieve (Dec 09 2018 at 23:57):
same for GF#10762
Grahame Grieve (Dec 09 2018 at 23:59):
@Lloyd McKenzie where are we with GF#19511 ?
Brian Postlethwaite (Dec 10 2018 at 00:02):
I've tagged both of those examples cleanups to get done in R5 (and neither are from any of the ballots).
With the Endpoint MLLP one, @Cooper Thompson and I talked about it, and the format for the address is very easy and clear we could do that in n example, but the rest of the resource was a little less clear as noted in the tracker.
Grahame Grieve (Dec 10 2018 at 00:03):
ok
Brian Postlethwaite (Dec 10 2018 at 00:06):
The other tracker that you might see from PA is GF#14341 which is a terminology harmonization process thing for the definition of a term.
Grahame Grieve (Dec 10 2018 at 00:06):
@Lloyd McKenzie @Jose Costa Teixeira GF#19300?
Jose Costa Teixeira (Dec 10 2018 at 18:01):
I did the investigation at the time, no results, so we have to make our own value set. @Lloyd McKenzie topic for the call today?
Lloyd McKenzie (Dec 10 2018 at 22:42):
On GF#19511 I believe @Michelle (Moseman) Miller has replied already? Jose's drafting something for GF#19300 and should have it ready for commit tomorrow
Michelle (Moseman) Miller (Dec 10 2018 at 22:49):
For GF#19511, I have a comment in gForge saying that I pre-applied the first half of the resolution (before the freeze), but the second half was just voted on last week (after the substantive freeze), so I wasn't planning to apply that in R4.
Lloyd McKenzie (Dec 10 2018 at 23:48):
@Grahame Grieve ?
Grahame Grieve (Dec 11 2018 at 19:16):
so this is about Procedure.asserter and CarePlan.activity.detail.reported[x] - I'm not musch in favor of these. Should I be?
Michelle (Moseman) Miller (Dec 12 2018 at 16:30):
The second half of the resolution (to be applied after R4 is published) was about making Procedure and CarePlan.activity be in alignment with workflow patterns. @Grahame Grieve Are you disagreeing with the workflow pattern itself (that added reported[x])? Procedures do get reported (so we're renaming asserter to reported) and so do CarePlan activities (e.g. medications, procedures, etc.) CC: @Lloyd McKenzie
Grahame Grieve (Dec 12 2018 at 18:44):
I'm not disagreeing with the intent, only the timing. This would be the biggest change made post-freeze, and I'm not seeing a big driver for it as error correction
Brian Postlethwaite (Dec 12 2018 at 22:53):
Just done a regenerate, and note that all the valueset references are now versioned, from:
<valueSet value="http://hl7.org/fhir/ValueSet/address-type" />
to
<valueSet value="http://hl7.org/fhir/ValueSet/address-type|3.6.0" />
I assume that's intentional, and are all using the FHIR Version of the release.
Grahame Grieve (Dec 12 2018 at 23:15):
yes
Grahame Grieve (Dec 12 2018 at 23:15):
it will change to 4.0.0 later today
Brian Postlethwaite (Dec 13 2018 at 01:09):
Reviewing the expansions.xml it seems that some (if not all) valuesets are output twice in the file
Check this one for example http://hl7.org/fhir/ValueSet/action-precheck-behavior
Brian Postlethwaite (Dec 13 2018 at 01:14):
Grahame, is GF#19744 on your list for closing out R4?
Brian Postlethwaite (Dec 13 2018 at 01:47):
On re-generation of the dotnet client I note that the following substantive changes have occurred:
Addition of PractitionerRole reference target to - BiologicallyDervicedProduct, CatalogEntry, DeviceUseStatement, Media (seems weird on subject here), MessageHeader, ResearchStudy, Specimen, SupplyDelivery, Task
Invariant SDF-8 and SDF-8A were updated
And the generation for the search parameters (still to test these though)
This sound about right @Grahame Grieve ?
Grahame Grieve (Dec 13 2018 at 02:29):
yes
Grahame Grieve (Dec 13 2018 at 02:29):
19744 is not on the R4 list; I'll be working on IG generation after publishing R4
Brian Postlethwaite (Dec 13 2018 at 02:30):
The code generation for the dotnet client can handle the new format (and is tolerant of the duplicates in expansions.xml) so its a Go from here I sit.
Grahame Grieve (Dec 13 2018 at 02:30):
thx. I will figure out where the duplicates come from.
Brian Postlethwaite (Dec 13 2018 at 02:31):
np. I'm going to check the Au Guide for that other bug this afternoon too.
Brian Postlethwaite (Dec 13 2018 at 04:28):
the .net fhirpath engine can't handle the sdf-8a invariant - looking into what is wrong with it.
Appears that the \ in the regex expression hasn't been escaped.
Brian Postlethwaite (Dec 13 2018 at 04:28):
The below works in the .net fhirpath evaluator
differential.all((%resource.kind = 'logical' or element.first().path.startsWith(%resource.type))
and (element.tail().not()
or element.tail().all(path.startsWith(%resource.differential.element.first().path.replaceMatches('\\..*','')&'.'))))
Brian Postlethwaite (Dec 13 2018 at 07:10):
And the sd-8a invariant, want me to do that one? the \ needs to be escaped.
Grahame Grieve (Dec 13 2018 at 07:13):
it's on my list
Grahame Grieve (Dec 13 2018 at 07:18):
can you explain where you think it needs to be escaped? here's what I see in the json:
"expression" : "(%resource.kind = 'logical' or element.first().path.startsWith(%resource.type)) and (element.tail().not() or element.tail().all(path.startsWith(%resource.differential.element.first().path.replaceMatches('\\\\..*','')&'.')))",
Grahame Grieve (Dec 13 2018 at 07:19):
looks ok to me?
Brian Postlethwaite (Dec 13 2018 at 07:26):
Looking at it on the site, looks like Lloyd must have grabbed it.
Rechecking the dotnet now.
Brian Postlethwaite (Dec 13 2018 at 07:41):
Yeah, looks like its my issue, not the core spec.
Michelle (Moseman) Miller (Dec 13 2018 at 11:23):
@Grahame Grieve For GF#19511, I was NOT planning to apply the second half of the resolution in R4. PC just voted on it last week and we realize it is too late for R4.
Grahame Grieve (Dec 13 2018 at 11:45):
ok sure.
Grahame Grieve (Dec 14 2018 at 00:25):
we've been busy. For R4:
- 2983 tasks
- 1027 substantive tasks
- 339 non-compatible changes
Last updated: Apr 12 2022 at 19:14 UTC
