10.3.3 | Twiin-03 | Get workflow Task

This section describes the transaction of the retrieval of the workflow Task.

Scope

This transaction supports getting the Workflow Task by the Requesting System at the Resource Server.

Use Case Roles

Actor: Requesting GtK

Role: Requests the workflow Task on behalf of a requesting user.

Actor: Resource Server

Role: Processes the request and responds with the requested resource.

Referenced Standards

HL7® FHIR® standard STU3 https://hl7.org/fhir/stu3

Messages

Request message

The requesting system wants to obtain the workflow Task for information about a known workflow. The workflow Task is retrieved using a the FHIR® read interaction, i.e. executing an HTTP GET request to the Task endpoint of the resource server.

CODE

GET [base]/Task/[id]

The requesting system may provide the HTTP Accept header. Valid values for this header are application/fhir+json or application/fhir+xml. If none is set, the resource server will use its default.

Response message

The resource server returns the workflow Task that is requested.

The payload of this message consists of a https://hl7.org/fhir/stu3/task.html resource that contains relevant information to the workflow. This message is returned to the Receiving System.

The media type of the HTTP body must be either application/fhir+json or application/fhir+xml, based on the Accept header or default response content type.

At this time there is no generic specification of the contents of the workflow Task more specific than the FHIR® specification.

Persistence of the Workflow Task as a FHIR® resource is not necessary.

When an error occurs an OperationOutcome resource must be returned with more details on the reason.

The HTTP response must be accompanied with the correct HTTP status code, e.g.:

200 OK – The request is accepted and responded
202 Accepted – The request is accepted and being processed asynchronous
404 Not Found – The request could not be processed, i.e. the resource with that id doesn’t exist.
410 Gone – The request could not be processed, because the resource does not exist anymore.

The requesting system processes the response according to application defined rules.