Stream: fhir/infrastructure-wg
Topic: FHIR Technical Correction
Grahame Grieve (Oct 02 2019 at 22:48):
Another candidate for the technical correction: GF#23068
Grahame Grieve (Oct 02 2019 at 22:48):
so is GF#23073
Lloyd McKenzie (Oct 02 2019 at 23:02):
Agree with fixing both
Bryn Rhodes (Oct 08 2019 at 15:06):
I'd like to propose GF#24856 as a technical correction, it's a clarification on how to represent FHIR quantities in FHIRPath, based on the final result of ballot reconciliation for FHIRPath.
Grahame Grieve (Oct 10 2019 at 06:36):
did we approve any technical corrections this week?
Yunwei Wang (Oct 10 2019 at 13:04):
we didn't have FHIR-I call this week.
Grahame Grieve (Oct 11 2019 at 01:50):
thx
Yunwei Wang (Oct 11 2019 at 13:14):
I'd like to propose GF#24856 as a technical correction, it's a clarification on how to represent FHIR quantities in FHIRPath, based on the final result of ballot reconciliation for FHIRPath.
This tracker in under ITS. Is it already approved or not?
Grahame Grieve (Oct 11 2019 at 16:31):
it should be assigned to FHIR-I - the content it relates to is owned by FHIR-I
Yunwei Wang (Oct 11 2019 at 16:55):
OK. I will add that to Monday's call too
Grahame Grieve (Oct 15 2019 at 21:18):
did FHIR-I approve any technical corrections yesterday?
Yunwei Wang (Oct 15 2019 at 22:18):
Yes. Here is a list:
GF#23024
GF#24068
GF#24562
GF#24917
GF#24918
Grahame Grieve (Oct 15 2019 at 22:18):
thanks
Bryn Rhodes (Oct 16 2019 at 04:38):
My proposed technical correction (GF#24856) did not survive its encounter with @Lloyd McKenzie :) He correctly pointed out that I was incorrectly applying semantics to UCUM annotations. I've adjusted the application of GF#21606 in FHIRPath to address this concern, and updated the proposed technical correction in GF#24856 to reflect it.
Grahame Grieve (Oct 16 2019 at 10:49):
so it's a still a proposed technical correction? when can it be approved?
Lloyd McKenzie (Oct 16 2019 at 13:36):
@Bryn Rhodes Is the plan to re-open and re-vote these?
Bryn Rhodes (Oct 16 2019 at 14:43):
On GF#21606, I think the adjustment fits within the intention of the existing disposition, so I've applied it to the draft and raised it on the FHIRPath stream for review, in particular the original submitters that raised the driving concerns.
Bryn Rhodes (Oct 16 2019 at 14:44):
On GF#24856, it wasn't approved on Monday's call, so it's still waiting approval, but I didn't hear any other concerns raised on the call.
Yunwei Wang (Oct 21 2019 at 20:57):
3 technical corrections were approved in today's meeting:
GF#24856
GF#25027
GF#24056
@Grahame Grieve
Grahame Grieve (Oct 21 2019 at 20:57):
thanks
Grahame Grieve (Oct 21 2019 at 21:20):
@Yunwei Wang you previously said that GF#24068 was part of the technical correction. Can you check that? I'm not sure how that makes sense
Grahame Grieve (Oct 21 2019 at 21:26):
@Lloyd McKenzie with regard to GF#24562, the same issue exists in the Request pattern - I presume the text should be changed to 'revoked'?
Grahame Grieve (Oct 21 2019 at 21:30):
@Jose Costa Teixeira this is a definitional problem in Product too
Lloyd McKenzie (Oct 21 2019 at 22:31):
@Grahame Grieve yes. Looks like it got changed to revoked, so the other wording should be aligned
Yunwei Wang (Oct 22 2019 at 02:28):
@Grahame Grieve You are correct! It is GF#24086
Grahame Grieve (Oct 28 2019 at 01:52):
The constraint ctm-1 on the Careteam resource says:
onBehalfOf.exists() implies (member.resolve() is Practitioner)
Grahame Grieve (Oct 28 2019 at 01:52):
this constraint is a problem, and you can see that it's caused a stream of questions here in Zulip by searching for onBehalfOf.exists().
Grahame Grieve (Oct 28 2019 at 01:53):
the problem is that the invariant says that if there's an onBehalfOf element exists, the mobe must resolve to a Practitioner resource
Grahame Grieve (Oct 28 2019 at 01:53):
the problem with that is that very often the invariant does not resolve at all, which is also an error for this constraint
Grahame Grieve (Oct 28 2019 at 01:55):
for some reason, we'e never turned the stream of questions about this into a task to actually fix the constraint. Really, it should say:
(onBehalfOf.exists() and member.resolve.exists()) implies (member.resolve() is Practitioner)
Grahame Grieve (Oct 28 2019 at 01:55):
Should I fix this in the technical correction? @Josh Mandel @Yunwei Wang @Lloyd McKenzie @Rick Geimer
Grahame Grieve (Oct 28 2019 at 01:56):
I think that we have to, so I'm going to go ahead and make the change... please approve it on tomorrow's phone call (I will not be on the call, will be on a plane, but may be available on chat
Michel Rutten (Oct 28 2019 at 09:28):
Having to resolve the same resource twice seems expensive... Is there any way we could avoid this?
Chris Moesel (Oct 28 2019 at 12:23):
Also -- minor typo -- that first resolve needs a ().
Grahame Grieve (Oct 28 2019 at 13:51):
hmm
Grahame Grieve (Oct 28 2019 at 13:53):
onBehalfOf.exists() implies (member.resolve().iff(empty(), true, ofType(Practitioner).exists)
Grahame Grieve (Oct 28 2019 at 13:53):
I think that does it
Michel Rutten (Oct 28 2019 at 13:59):
Neat!
Vassil Peytchev (Oct 28 2019 at 15:11):
iff -> iif
?
Grahame Grieve (Oct 28 2019 at 15:11):
yes
Brian Postlethwaite (Nov 14 2019 at 21:22):
resolve().exists() doesn't cater for where just the display name is defined in the resource reference.
Grahame Grieve (Nov 14 2019 at 21:28):
is that a problem?
Brian Postlethwaite (Nov 14 2019 at 22:04):
Would mean that you can't specify a practitioner as just the name, and the organization by name too.
Grahame Grieve (Nov 14 2019 at 22:05):
why?
Brian Postlethwaite (Nov 14 2019 at 23:07):
There's not reference.reference value to resolve, you just have reference.display (and reference.type), so it won't come back with an ofType(Practitioner)
(unless your "resolver" just fudges that the resource resolves as it knows that it is a practitioner based on the reference.type)
Last updated: Apr 12 2022 at 19:14 UTC
