Stream: workflow
Topic: meta.tag "actionable" --> request.actionable?
Jose Costa Teixeira (Dec 09 2019 at 21:29):
It seems tricky to have a meta tag "actionable" - shouldn't we emerge this to the request pattern?
Jose Costa Teixeira (Dec 09 2019 at 21:30):
reason for this is that this tag has an impact, and seems more instructing about the request than metadata about the request
Lloyd McKenzie (Dec 09 2019 at 21:35):
It needs to be a tag rather than an element because it needs to be changeable when moving from one system to another without breaking signatures.
Jose Costa Teixeira (Dec 09 2019 at 21:41):
you mean when forwarding a request as a JFYI, the forwarder just sets a tag?
Lloyd McKenzie (Dec 09 2019 at 21:47):
y
Lloyd McKenzie (Dec 09 2019 at 21:47):
Or clears a tag
Jose Costa Teixeira (Dec 09 2019 at 21:54):
Ok, but the JFYI request can also be a new derived request thing, right? Forcing systems to determine behaviour because of a tag seems like a big thing. 1 - can a system ignore a tag? 2 can we make that tag "must support"?
John Moehrke (Dec 09 2019 at 21:54):
and the very fact it is in .meta does not mean it is outside signatures.
Jose Costa Teixeira (Dec 09 2019 at 21:55):
I think the tag makes sense as one option. There should be a value for request.intent "JFYI" for systems that want to have this as a new request instance. (I think forwarding a request JFYI in some cases is a clinical decision and therefore needs its own resource instance)
Lloyd McKenzie (Dec 09 2019 at 21:57):
Tags can be very critical things to look at. IGs can certainly set conformance expectations around tags. Absent IG rules, consuming systems are free to ignore anything they wish (though they must be cautious when ignoring modifier elements)
Last updated: Apr 12 2022 at 19:14 UTC
