Stream: fhir/infrastructure-wg
Topic: Technical correction
Grahame Grieve (Jul 30 2019 at 19:56):
Can we consider GF#23018 on the next concall please - technical correction candidate
Grahame Grieve (Aug 02 2019 at 20:28):
another: GF#23043
Grahame Grieve (Aug 08 2019 at 19:19):
Please approve GF#23069 on this weeks cancall
Grahame Grieve (Aug 09 2019 at 11:39):
hey, I have a question about GF#22807 - the task says for me to fix something.... but I don't see how I can fix this
Some parameters have more than one type specified in their definition, which makes it's way into the narrative untouched. But the code that generates the formal definition only uses the first type, since the resource only allows one type. The task says for me to fix this... but how? I can't change the definition of OperationDefinition - what did FHIR-I intend for me to do here?
@Josh Mandel @Ewout Kramer @Lloyd McKenzie @Rick Geimer
Josh Mandel (Aug 09 2019 at 14:59):
Note you can @*FHIR-I Co-chairs* to tag this group. If OperationDefinition doesn't support this use case, then the build should be failing on the invalid spreadsheet -- but I don't think we understood it was unsupported by OperationDefinition at the time we resolved the gforge issue.
Josh Mandel (Aug 09 2019 at 15:00):
So, beyond tightening up the build tool in a forward-looking way, I don't see what we can do in R4 except amend the documentation for https://www.hl7.org/fhir/codesystem-operation-lookup.html to note that only code is supported, and ask Vocab to work around this with distinct subproperties in r5.
Lloyd McKenzie (Aug 09 2019 at 16:08):
And if we have invalid operations in R4, then we need to figure out what to do about them...
Grahame Grieve (Aug 09 2019 at 19:36):
there's other operations. But Vocab will feel very strongly that this is unusable like that
Lloyd McKenzie (Aug 09 2019 at 19:45):
So - can't have polymorphic parameters, but operation is useless without polymorphic parameters?
Grahame Grieve (Aug 09 2019 at 19:45):
yes. these are the only examples:
Grahame Grieve (Aug 09 2019 at 19:45):
lookup.property: types = code | Coding | string | integer | boolean | dateTime | decimal
lookup.property.subproperty: types = code | Coding | string | integer | boolean | dateTime | decimal
find-matches.property: types = code | Coding | string | integer | boolean | dateTime
find-matches.property.subproperty: types = code | Coding | string | integer | boolean | dateTime
find-matches.match.unmatched: types = code | Coding | string | integer | boolean | dateTime
find-matches.match.unmatched.property: types = code | Coding | string | integer | boolean | dateTime
Grahame Grieve (Aug 09 2019 at 19:48):
seems to me that we should say that the single type is the common root element (Element in this case) and add an extension that enumerates the actual sub-types that are allowed, on the basis that this is what we'll do to solve this properly in R5
Grahame Grieve (Aug 09 2019 at 19:48):
(add the property)
Grahame Grieve (Aug 09 2019 at 19:48):
this lines up with how we might solve more than one type of resource allowed when we already said "Resource"
Josh Mandel (Aug 09 2019 at 19:59):
deleted Er, never mind -- Parameters :)
Rob Hausam (Aug 09 2019 at 23:04):
Probably Grahame's suggestion of adding the extension is the way that we'll need to handle this. But @Grahame Grieve can you clarify how you expect it should look when we "add the property" in R5?
Grahame Grieve (Aug 09 2019 at 23:28):
extension would say 'allowed concrete types, if the type of the parameter is abstract'. Then, in R5, we add a property that does the same thing
Grahame Grieve (Aug 15 2019 at 12:08):
I don't agree with the disposition of GF#22670. see https://chat.fhir.org/#narrow/stream/179177-conformance/topic/Warning.20-.20Technical.20Correction
Josh Mandel (Aug 16 2019 at 16:08):
Let's make sure we take this up on Aug 19.
Grahame Grieve (Aug 20 2019 at 06:28):
so our disposition around the ElementDefinition.type.code from yesterday's call means that sdf-19 has to change - see https://chat.fhir.org/#narrow/stream/179177-conformance/topic/Warning.20-.20Technical.20Correction for details. Is it reasonable to take this is implicitly approved by fhir=i?
Michel Rutten (Aug 20 2019 at 08:34):
Seems reasonable to me.
Yunwei Wang (Nov 05 2020 at 17:11):
What is the release process for technical correction? We do want this J#29654 to be fixed ASAP since validation fails all vital signs using Observation.effectivePeriod.
Lloyd McKenzie (Nov 05 2020 at 18:54):
Next technical correction to R4 will likely be R4B - slated for publication around end of Q2 2021
Yunwei Wang (Nov 06 2020 at 16:31):
As my understand, R4B is a "limited" release for Medication related resources only. If R4B also contains all technical correction from v4.0.1, implementer has to adopt these new Medication resources also.
Lloyd McKenzie (Nov 06 2020 at 20:47):
R4 will be a complete R4 release. The only content up for vote will be the Medication management stuff and a limited set of changes to target resources - and perhaps a few new extensions.
Lloyd McKenzie (Nov 06 2020 at 20:47):
In general, most implementers will move to R4B as they would any technical correction
Grahame Grieve (Nov 12 2020 at 10:49):
In general, most implementers will move to R4B as they would any technical correction
I doubt that this is the case. It certainly won't just happen to them in they way the previous technical corrections have worked
Lloyd McKenzie (Nov 12 2020 at 14:05):
Agree that the migration would need to be a conscious decision rather than automatic. Do you see any other barriers that would make migration difficult (other than a bit of code that will interpret content-type of R4 and R4B as indistinguishable?
Grahame Grieve (Nov 12 2020 at 20:16):
version number won't be 4.0.x, which will make a big difference in practice. And obviously for the actual changes which we don't know what they are yet
Last updated: Apr 12 2022 at 19:14 UTC
