Stream: fmg
Topic: QA - GF#13007 - Approved
Lloyd McKenzie (Mar 11 2017 at 03:27):
GF#13007 - need 'unknown' added to PublicationStatus. We have a QA rule and an MnM decision that says all mandatory elements bound to "codes" must allow for the possibility of exchange by systems that don't know the authoritative status (i.e. don't know if something is draft, active or retired, they just know the set of codes or the set of constraints, etc. (This was identified when attempting to harmonizate Questionnaire with the definition pattern.)
Lloyd McKenzie (Mar 11 2017 at 03:27):
+1
Paul Knapp (Mar 11 2017 at 09:40):
Why then is status required?
Lloyd McKenzie (Mar 11 2017 at 15:36):
That'd be the alternative. It's a bit more work to make it minOccurs=0 everywhere, but that's doable.
John Moehrke (Mar 11 2017 at 16:02):
+1 -- Prefer explicit flavors of null.
Paul Knapp (Mar 13 2017 at 10:38):
I agree except that is not the situation here. If the status field needs and is missing the value 'unknown' then add it, but specifying 'unknown' for a subset of the resource because you don't have the actual value is wrong - if you don't know the actual value then you should say nothing for example in a contained resource. Otherwise you risk the actual resource having status X but you subset claiming it is status Y.
Lloyd McKenzie (Mar 13 2017 at 15:48):
Paul, not sure why you're talking about contained resources. There's no inheritance. If a contained resource were allowed to have a missing status, you absolutely *could not* infer that it had the same status as the containing resource. We have two choices here - make status minOccurs = 0 or add a status of "unknown". The semantics would be the same in either case, but are someone more explicit in the latter, which is why I prefer it.
Lloyd McKenzie (Mar 13 2017 at 19:50):
Robust discussion on today's FHIR-I call, but decision was to approve. This is the pattern that was set for Request and Event and that most resources now follow (e.g. MedicationRequest, ProcedureRequest, Observation, etc.)
Grahame Grieve (Mar 13 2017 at 20:19):
"an MnM decision that says all mandatory elements bound to "codes" must allow for the possibility of exchange by systems that don't know the authoritative status" - say what?
Grahame Grieve (Mar 13 2017 at 20:20):
Committees should definitely be empowered to say "if you don't know this, you can't communicate".
Grahame Grieve (Mar 13 2017 at 20:20):
don't want them to say that without thought, but do need to be able to say it
Lloyd McKenzie (Mar 13 2017 at 20:41):
Sure. But this isn't one of those cases. There's no circumstance where we would consider saying "if you don't know if the ValueSet is active vs. retired, you can't share it"
Grahame Grieve (Mar 13 2017 at 20:45):
I guess it creates a problem for me in it's own right - if a value set is known not to be draft, and known not to be required, is it therefore active? or is that something more?
Grahame Grieve (Mar 13 2017 at 20:45):
what's the proposed definition?
Lloyd McKenzie (Mar 13 2017 at 20:51):
The authoring system does not know which of the status values currently applies for this resource. Note: This concept is not to be used for "other" - one of the listed statuses is presumed to apply, it's just not known which one.
Lloyd McKenzie (Mar 13 2017 at 20:51):
Same as the definition used for event and request
Grahame Grieve (Mar 13 2017 at 20:56):
have to update the shareable value set and code system to ensure that 'unknown' is not a valid value
Grahame Grieve (Mar 13 2017 at 20:57):
+1 though I'm not wildly in favor
Lloyd McKenzie (Mar 13 2017 at 21:04):
Ok. I can do that as part of the change
David Hay (Mar 14 2017 at 00:24):
+1
Brian Postlethwaite (Mar 14 2017 at 05:31):
I would have preferred to make it optional than imply a value, but not enough to get vocal about it.
+1
Lloyd McKenzie (Mar 14 2017 at 05:35):
Approved
Last updated: Apr 12 2022 at 19:14 UTC
