Magentus Practice Management FHIR Implementation Guide - Local Development build (v1.2.35) built by the FHIR (HL7® FHIR® Standard) Build Tools. See the Directory of published versions

Requesting

Electronic Diagnostic Request Profiles

The FHIR Resources used by the Magentus Requesting Service are shown in the diagram below.

Some features to note:

• Requesting depends on a ServiceRequest/Task pattern that is defined as Option F in within the FHIR Workflow description. This uses a Task to track the fulfillment status of a ServiceRequest.
• In addition to a Task for each ServiceRequest, we also allocate a Group Task that provides a resource representing a set of individual Tasks for each ServiceRequest (each individual test or service where multiple may constitute a single order). In addition to the explicit Group Task, they are also implicitly bound together through their common groupIdentifier attribute. The reason for an explicit Group Task resource is to aid searching and discovery of complete orders rather than needing to discover each in isolation.
• Tasks are also used to track the workflow associated with CommunicationRequests. These are used for communication with a patient about their diagnostic service or with a clinician for urgent results.

Consistency of data across tests/services within an order

While our use of individual ServiceRequests and Tasks could allow for unique attributes such as Status, Note, etc., we currently require that all child ServiceRequest and Task share common values, including that within the Group Task.

Requesting Profiles

The FHIR Resources generated by the Magentus Requesting Service are listed below.

ServiceRequest and Task

It should be noted that Diagnostic Service Request should be regarded as a legacy profile and instead replaced by explicit Pathology Request and Radiology Request use as these are more specific to each of their domains of use.

CommunicationRequest and Task

Other Profiles

Contained

Additional resources are contained within the Requesting resources above, the FHIR profiles for these resources are listed below.

Workflow

The eRequesting workflow describes the interactions between a placer and a filler (or alternate filler) via the eRequesting FHIR Service.

Subscribing to Requests

In order to receive subcription notifications from the FHIR Server when resources of interest are created or updated, a subscription is registered. A subscription request includes the following properties.

In this case we are interested in Task resources that are

• in a requested or cancelled status,
• are associated with a Task group, not an individual Task fulfillment, and
• are directed to the Organization with HPI-O of 8003123456789123.

Example The following example creates a new Subscription for the Task resource with criteria as described above.

POST /Subscription

{
  "resourceType": "Subscription",
  "criteria": "Task?status=requested,cancelled&_tag=fulfillment-task-group&owner.identifier=http://ns.electronichealth.net.au/id/hi/hpio/1.0|8003123456789123",
  "status": "requested",
  "reason": "Task requested and cancelled subscription",
  "channel": {
    "type": "rest-hook",
    "endpoint": "https://webhook.site/bbd78ee4-e267-4633-8acc-38a5e1dc54a0",
    "header": ["Authorization: Bearer secret-token-abc-123"]
  }
}

The Subscription endpoint can also be used to Search, Read, Update and Delete as per the standard FHIR REST API pattern.

Subscription POST Notification

A subcription notification is received as a POST request on the endpoint specified in the subscription registration request. The POST request has an empty body.

Example

POST https://webhook.site/bbd78ee4-e267-4633-8acc-38a5e1dc54a0
Authorization: Bearer secret-token-abc-123

Responding to a Subscription Notification

The subscription notification shall respond as quickly as possible with a success status of 200 OK or 202 Accepted, and an empty body. The latter is normally returned when the request is accepted for processing but processing will commence after the response has been returned, which is the preferred approach for subscription notifications.

Any error response may result in a subsequent retry by the FHIR Server to submit the Subscription Notification until the number of retires is exceed at which time the FHIR Server will stop the subscription. See Managing Subscriptions and Errors for more details.

Retreiving Subscription POST Notification Data

When a subscription notification is received, perform a Search request with the corresponding criteria along with a _lastUpdated parameter with the timestamp when the last search request was performed with the gt prefix (see https://hl7.org/fhir/r4/search.html#prefix).

Example

GET /Task?status=requested,cancelled&\
owner.identifier=http://ns.electronichealth.net.au/id/hi/hpio/1.0|8003123456789123&\
_lastUpdated=gt2022-12-13T12:30:00Z

Include Referenced Resources

In order to retrieve the entire Orders, use the following _include and _revinclude parameters.

Example

GET /Task?status=requested,cancelled&\
owner.identifier=http://ns.electronichealth.net.au/id/hi/hpio/1.0|8003123456789123&\
_lastUpdated=gt2022-12-13T12:30:00Z&\
_include=Task:patient&_include=Task:owner&_include=Task:requester&_revinclude=Task:part-of&\
_revinclude:iterate=CommunicationRequest:about:Task&\
_include=Task:focus&_revinclude:iterate=ServiceRequest:copiesTo\
_include:iterate=PractitionerRole:practitioner&_include:iterate=PractitionerRole:organization&\
_revinclude:iterate=Consent:data:ServiceRequest

Claim Order Operation

The claim operation is used create a new fulfilment Task for an alternate filler. It cancels the original fulfilment Task, if it exists, but leaves the ServiceRequest unchanged. The original filler can determine that the order is being alternatively filled but not who is the alternative filler and similarly the alternate filler cannot determine who was the original filler.

Diagnostic Service Claim Operation