FHIR Artifacts > MessageDefinition: ServiceRequest Bundle
A ServiceRequest SHALL be the
focus of messages corresponding to the following events:
|Event||Category||Purpose||Allowed Responses||Response Situation|
|add-servicerequest||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-servicerequest||notification||To notify systems other than the RMS Target that a new ServiceRequest has been created.|
|terminate-servicerequest||consequence||To request that all information related to a ServiceRequest terminated 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-servicerequest||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
Entries in the message Bundle for these business events will be determined by the content of the ServiceRequest which, minimally, SHALL include:
- a MessageHeader
- the ServiceRequest(s) referenced in
- 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
- references to other
ServiceRequest.supportingInfowhere needed (see below)
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.