Stream: v2 to FHIR
Topic: task vs message header
René Spronk (Apr 22 2019 at 07:15):
I think I've seen it mentioned before on this thread: when translating v2 to FHIR (REST, I'm not talking about FHIR messages here), then all v2 messages (except queries) when translated to REST should have a Task which represents the 'reciever responsabilities' (which may include the generation of a message response). This is effectively the equivalent of a ControlAct as present in HL7v3. The task would have a reference to the MessageHeader resource as its input (which in turn references the focal resource(s)).
In messages of consequence (orders) there will be tasks for the ordered services as well, but that's not what I'm talking about here, those would be in addition to the main task that represents the message receiever responsabilities.
So why would you do this in notification messages (e.g. ADT)? Well, even those have intended business/workflow consequences, i.e. if you sent a ADT A03 (discharge) to a housekeeping system, it effectively is an order to go clean the bed/room.
This probably needs to be combined with the use of 'implicitRules' (an element in all resources), because there all all these site specific undocumented expectations.
However, an A31 or A08 probably/maybe don't need a task (they're just plain updates), and a merge message maps to an operation. So there are optimisations that can be made, but to me the above (as a generic statement) holds.
Jose Costa Teixeira (Apr 22 2019 at 11:20):
I would add MFN messages to the list of things that do not need a task
Craig Newman (Apr 22 2019 at 12:21):
As part of the v2-to-FHIR project, I've had some initial Task discussions with @Lloyd McKenzie and @Hans Buitendijk and have documented my interpretation of those discussions at https://confluence.hl7.org/display/OO/v2-to-FHIR+Tasks. I'll link this thread to that page or you can just add thoughts to the Confluence page directly.
I'm not convinced that a semi-"universal" Task would be needed, only Tasks when the sending system knows there is an action for the receiving system to take. I'd typically leave Task creation to the receiving system (but admittedly, I don't know much about how this works in the real world).
Lloyd McKenzie (Apr 22 2019 at 14:11):
Agree you wouldn't always need a Task. If you're just doing an encounter location change or something, that should be handleable as a normal update. Task would only be needed if you were seeking fulfillment or if the action couldn't be represented as a create/update/delete/transaction/etc.
René Spronk (Apr 22 2019 at 15:01):
@Lloyd McKenzie I don't think that it's explicitly known to a ADT A03 sending application what business/workflow impact that will have on a housekeeping system, or a dietary/kitchen system, or who knows what system will receive a broadcast ADT. We know that it does have an impact, but the sending system doesn't. IMHO the default should be a 'message processing task', unless there's good (and documented) reason not to.
René Spronk (Apr 22 2019 at 15:03):
@Craig Newman My statement was purposefully NOT about any tasks that are the result of the BODY of order messages. In my mind those would be created in addition to a task for the msg-level-receiver-responsabilities, but they're not the core of my statement.
Lloyd McKenzie (Apr 22 2019 at 16:06):
It will depend on the trigger. If the trigger is specifically asking for something to happen and you can make that thing happen via REST, then you can map it to REST. If someone is mis-using the message and sending it to someone as an FYI rather than a "please do" and thus misusing the message, then they'll have to come up with a different solution for their use-case.
Last updated: Apr 12 2022 at 19:14 UTC
