FHIR Artifacts > MessageDefinition - ServiceRequest Bundle

ServiceRequest Bundle

MessageDefinition

A ServiceRequest SHALL be the focus of messages corresponding to the following events:

Event Category Purpose Allowed Responses Response Situation
add-service-request consequence To request that a ServiceRequest created on the RMS Source be performed on an RMS Target. notify-add-process-request When the request is successfully processed, a 'process-request' Task with status SHALL be returned to the requester.
notify-add-service-request notification To notify systems other than the RMS Target that a new ServiceRequest has been created.
revoke-service-request consequence To request that a ServiceRequest be terminated and all information related to that ServiceRequest on the RMS Source be removed. notify-update-process-request When the request has been successfully processed, a 'process-request' Task with status 'cancelled' SHOULD be returned to the requester.
notify-update-service-request notification To notify systems that a ServiceRequest or its status has been updated.
notify-data-correction1 notification To notify systems that information in a ServiceRequest or related resource has been corrected on the RMS Target. notify-update-servicerequest When the request is successfully processed, any update to the ServiceRequest or status MAY be sent to the performer.

1 The notify-data-correction message event is used to send information from the RMS Target to the RMS Source when information about a ServiceRequest or related information is updated directly in the RMS Target, therefore the expected response - if any - is an update to the ServiceRequest from the RMS Source (not a Task).

Message Bundle: ServiceRequest


ServiceRequestMessageBundle-HCS


Description

Entries in the message Bundle for these business events will be determined by the content of the ServiceRequest which, minimally, SHALL include:

Note:

To enable conformance testing against the requirements of this IG, the requirements summarized above are formally specified as contraints within FHIR artifacts published in this IG. Implementers are strongly encouraged to become familiar with these formal specifications and to 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.