10.5.11 | Twiin-08 | Get ActivityDefinition / PlanDefinition

This section describes a transaction needed for the routing of a Task.

Scope

Twiin-01.png

This transaction supports retrieving an ActivityDefinition by the Requesting System at the Resource Server, based on a reference previously obtained from a HealthcareService.

This transaction is used to obtain more detailed information on how a selected service is to be requested or processed, and which action or workflow step is expected by the responding party.

If the retrieved ActivityDefinition references a PlanDefinition as additional workflow context, that PlanDefinition may be retrieved using the same transaction pattern.

Use Case Roles

Actor: Sending GTK

Role: Retrieves the ActivityDefinition referenced from a previously obtained HealthcareService.

Actor: Receiving GTK

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

Referenced Standards

Messages

Request message

The requesting system wants to obtain an ActivityDefinition that is referenced from a HealthcareService. The ActivityDefinition is retrieved using the FHIR read interaction.

GET [base]/ActivityDefinition/[id]

The requesting system may provide the HTTP Accept header. Valid values for this header are:

  • application/fhir+json

  • application/fhir+xml

If none is set, the resource server will use its default.

Response message

The resource server returns the requested ActivityDefinition.

The payload of this message consists of an ActivityDefinition resource that contains relevant information for interpreting or constructing the workflow Task or related request.

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

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

The HTTP response shall be accompanied with the appropriate HTTP status code, including but not limited to:

  • 200 OK – the ActivityDefinition was successfully retrieved

  • 401 Unauthorized – authorization is required

  • 403 Forbidden – the client is not permitted to access this resource

  • 404 Not Found – the referenced ActivityDefinition does not exist or is not available at this endpoint

  • 410 Gone – the referenced ActivityDefinition existed before, but is no longer available

  • 500 Internal Server Error – the server encountered an unexpected condition

  • 503 Service Unavailable – the server is temporarily unable to handle the request

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

Relationship to PlanDefinition

If the retrieved ActivityDefinition contains a reference to a PlanDefinition that is needed for additional workflow interpretation, the requesting system may retrieve that PlanDefinition explicitly using the same FHIR read interaction pattern.

GET [base]/PlanDefinition/[id]

This retrieval is considered an optional follow-up within the same transaction pattern.