FHIR Artifacts > MessageDefinition: Task Bundle
A Task SHALL be the
focus of messages corresponding to the following events:
|Event||Category||Purpose||Allowed Responses||Response Situation|
|notify-add-process-request1||notification||To notify systems that an RMS Target has created a Task for a user to perform a ServiceRequest.|
|notify-update-process-request1,2||notification||To notify systems that work has been performed in response to a ServiceRequest and that the Task, its status or related information has changed.|
|add-rfi3||consequence||To request additional information in response to a ServiceRequest.||add-communication
|The RMS Source has received the message and the requester responds with a Communication or an update to the ServiceRequest|
1 'perform-request' Tasks are identified with
2 in cases where discreet events are not defined in this IG, implementers SHOULD use the notify-update-process-request event to share information about actions the Performer has planned or taken in response to the ServiceRequest. In these cases, a message MAY include more than one
MessageHeader.focus to convey information about both the 'process-request' Task's status and any additional resource(s) added or updated.
3 'rfi' Tasks are identified with
Message Bundle: Task
Entries in the message Bundle for these business events will be determined by the content of the ServiceRequest the Task is based on which, minimally, SHALL include:
- a MessageHeader
- an Task referenced in
- the ServiceRequest the Task is based on (
- the Patient who is the subject of the ServiceRequest (
- PractitionerRole(s) referenced in
ServiceRequest.requester, the requested
ServiceRequest.performerwhere, each SHALL reference an Organization, Location and/or Practitioner
The message SHOULD also include references to the PractitionerRole of the Organization or Practitioner responsible for the task (
Task.owner) and MAY include references to other
ServiceRequest.supportingInfo sent by the Source.
To enable conformance testing against the requirements of this IG, the requirements above are formally specified withing the FHIR artifacts published in this IG . Implementers are strongly encouraged to become familiar with these formal specifications and rely on them as the source of truth.
Information about how implementers can validate message instances is provided on the downloads page of this IG.