Short Description
The purpose of this track is to explore a Diagnostic Requests Implementation Guide to support pathology and radiology requesting.
Long Description
This specification shares requests between an requesting clinician (the placer) and a diagnostic service provider (the filler). The requesting service supports directed requests to a selected provider (or undirected requests) as well as service provision by an alternative provider as directed by patient fulfillment choice.
The service utilises FHIR Task and ServiceRequest resources to capture a set of grouped tests/procedures in a diagnostic request. The group is identified by a common group request number as well as represented by a Task group resource. Each ServiceRequest is associated with a single test/procedure and a fulfillment Task is linked to each ServiceRequest. This follows a derivation of the Option FFHIR workflow pattern.
Requests can be directed to a selected service provider by assigning Task ownership to a service provider. If no filler is pre-selected then the owner of the Task would not be set. The filler monitors (polls/subscribes) for owned Tasks and transitions the Task status through a common set of Status changes to track request fulfillment.
Patient choice may choose alternate service provision. In this case, the alternate provider will request re-assignment of the fulfillment Task to an alternate Filler based on a scanned request barcode. This requires the a Request Service to cancel the original Task and generate a new Task for the alternate Filler. Or in the case of an undirected request, the Task would be assigned through the owner attribute.
The IG does not currently cover Diagnostic Reports but does allow for the the DiagnosticReport to be linked through the output attribute of the Task. A mirrored report delivery task would then track receipt of the report by the request placer through technical, administrative, and clinical acknowledgments.
This track will explore a number of current design decisions that reflect needs of implementation partners:
- The concept of a formal requestTask Groupallowing discovery of whole ServiceRequest/Task sets for a single diagnostic request. These groups play a more significant role in Australia than, say, the US as our clinical, financial, and policy settings are optimised around groups of tests, especially in the case of Pathology.
- There are user needs to carry guidance around various forms of filler to patient and filler to placercommunications. There are various options to support these needs.
- Patient choice of diagnostic provider introduces the need for aflexible fulfillment approach. Current de facto, paper-based request behaviour defaults to selection of a diagnostic provider at placement of the order but our design neither enforces or prohibits this approach. There are various options to allow transition of requests between diagnostic providers.
- Rule 3 exemption in pathology allows for a single Pathology request to be fulfilled multiple times. This is not a standard request feature so is likely requiring an extension but there are ways to carry the period of request validity (6 months for a rule 3 exemption) and the number of times the request may be fulfilled.
Type
Educate on the use ofthe Diagnostic Request IG. The track will include three areas of focus:
- Business
- Policy settings, regulations, business model assumptions, and other foundations.
- This discussion will provide value and seek input from those who deal with diagnostic requests as a business service in support of connected clinical care.
- Business analysts, policy makers, investors, user experience designers.
- Architecture
- Mapping the business needs to appropriate FHIR information and workflow approaches.
- Modellers, architects, developers.
- Technical
- Demonstrating the architecture approach with a live FHIR server.
- Use Postman, FHIR test harness, or test clinical system.
- Developers.
Call for participants
Anyone who is interested in understanding, building or designing:
- Diagnostic request clients (Placer)
- Diagnostic service providers (Filler)
- Diagnostic request service (particularly managing the transfer of Requests between providers)
As described above, we will cover business, architecture, and technical viewpoints of a proposed FHIR Diagnostic request approach.
Track Prerequisites
- Understanding of FHIR
- Have one of:
- a business interest in the adoption of FHIR-based diagnostic request services
- a modelling interest in the information and workflow details mapped into FHIR
- a functioning development environment with or without code that implements one of the roles listed below and can participate in at least one of the test scenarios
Track Lead(s)
Andy Bond, Interoperability Lead, Genie Solutions A Magentus Company
Angus Millar, Client Systems Integration Analyst, Sonic Healthcare
Specification Information
Implementation Guide
Download
Other references
- HL7 FHIR Workflow Management patternshttps://www.hl7.org/fhir/workflow-management.html#optionf
- Video by Rene SpronkFHIR request Communications and Results Reporting
- Code 128 barcode
- RCPA - SPIA Requesting Pathology Terminology Reference Set
- erequests on FHIR Presentation from 2022-12-01 Brisbane Connectathon
Zulip stream
https://chat.fhir.org/#narrow/stream/179173-australia/topic/draft-diagnostic-requests
Request FHIR Server
As yet we don't have an openly accessible FHIR server implementing the Draft Diagnostic Orders IG as referenced above. However you can instantiate your own HAPI, Azure, or other server. There is also a docker image of a HAPI server which you can grab through
docker pull gonatf/hapi-fhir-jpaserver-audiagreq:latest
which has a recent build of the IG. You will need to load a new SearchParameter for the copiesTo extension. This is provided in the attached Postman collection.
Also note that if you are loading the IG into your own HAPI server, you will need at least version 6.8.4 as it fixed a bug with _revinclude:iterate that is used in the search for Consent resources in the Postman colelction.
Track Participants
- Andy Bond
- Angus Millar
- (contact us if you want your name added)
Agenda
- Overview of the diagnostic requesting IG and flow
- Discussion of diagnostic request group approach
- Discussion of diagnostic request patient/placer communication approach
- Discussion of diagnostic request alternative provider approach
- Interconnect request placer and filler systems
System Roles
Requesting Clinical System (Placer)
- This system builds an request through a set of ServiceRequest's linked by a common requisition identifier (the Placer Group Number) and their associated fulfillment Task's optionally assigned to a selected service provider.
- The system polls/subscribes to Task status changes to track acceptance, processing, and completion of requests.
Selected/Primary Diagnostic Service Provider (Filler)
- Polls/subscribes to assigned Task's and transitions Task's through accepted, processed, and completed.
Alternate Diagnostic Service Provider (Alternate Filler)
- The service provider scans an request form barcode to request transfer of the request to the alternate provider.
- The request then appears as though it was a directed request.
Request Service (Transfer)
- Handle barcode scanned transfer requests.
- Withdraw Task from selected provide and generate a new Task for the alternate provider.Handle
System Role Participants
Requesting Clinical System (Placer)
Selected/Primary Diagnostic Service Provider (Filler)
Request Service (Transfer)
Testing Scenario:
Workflows
The FHIR request Service manages fulfillment Task resources and their associated ServiceRequest resources which make up request groups. Filler, Placer, and Transfer roles have obligations to modify the status of Task and ServiceRequest Resources to track the shared state of requests.
A negative Task status (failed, rejected, cancelled) should also provide a Task statusReason to indicate why there has been a request failure.
In the following diagrams, the alternate Filler process has been marked with dashes and italics to indicate it is subject to some ongoing design decisions. Each component defines
- who is responsible (Placer, Filler),
- the purpose
- the status of both the Task and ServiceRequest
While this is focussed on a single Task/ServiceRequest pair, a request made up of a group of pairs is expected to provide a consistent view across the fulfillment Task statuses. Thus any change in Task status must be applied to all Task statuses within the same Placer Group or they will be treated as such regardless. ServiceRequest statuses may reflect individual ServiceRequest statuses.
Successful request
- The Taskreceivedstate acknowledges that the Filler has received the request but has not evaluated the request.
Rejected request
- An request Task can berejectedafter beingreceivedif the Filler is unable to fulfill the request. This may be because the information provided does not meet some structural requirement that is not validated by the FHIR server or a semantic issue such as requesting a test that is not supported or a patient is incompatible with the service requested. The Task statusReason should indicate a reason forrejection.
Failed request
- A Taskfailedrequest occurs after collection/processing has begun and is instigated by the Filler. It means that the request was deemed appropriate but once specimen collection or imaging was completed something occurred that prevented a result/report being generated. For example, sample becomes unusable. ThestatusReasonshould be used to transfer the reason for failure.
Cancelled request
- A Placer can cancel an request at any time prior to a Filler processing the request (i.e. prior to the Task entering thein-progressstate). If there is a timing issue and the cancellation is received after work has begun then that work will likely complete thus cancellations can be regarded as informative rather than normative. Again, astatusReasonshould be given for the why an request has been cancelled.
Transferred request
- An alternate Filler can scan a barcode and request assignment of an request. This request is then accepted by the alternate Filler. For further discussion on alternate Fillers seeAlternateFiller.
Note: Workflow diagrams are now included in the draft eRequesting IG.
Scenario Examples
- LDL, HDL, and Triglycerides request for a Privately Billed patient that requires Fasting
- Urgent Full Blood Count and Blood Culture request for a Bulk Billed patient requesting no Patient SMS
- HIV Serology, Fasting Blood Glucose, and Glucose Tolerance (antenatal) request for a pregnant DVA patient with Last Menstrual Period and Gestational Age information
- Hepatitus C Serology request as a Private billing and instruct not to upload to My Health Record and do not SMS patient
- Giardia request with Copy-To to two other doctors and urgently contact ordering clinician with result
- Uncoded Serum Rhubarb request with both clinical and patient notes
- INR tests over 6 months based on Rule 3 Exemption
Postman Collection
- HL7 AU Diagnostic Requesting Postman Collection - includes a request bundle transaction as well as the components of a request in isolation. It also includes a sample search that downloads a request group in one bundle.
Sample Transaction Bundles
- Pathology request exercising all components
- Filler Task "received" response
- Filler "accepted" response
- Filler "in-progress" response
- Filler "completed" response
Discussion Topics
Request Group
- In Australia, diagnostic request groups play a significant role due to various financial, regulatory, and policy settings.
- FHIR supports group identifiers to bind requests together as well as tasks. This allows related ServiceRequests or Tasks to be discovered through searches. However, the group itself, in this case, has no standalone identity.
- There are a few ways to create the group.
- A RequestGroup is a grouping of actions. It provides a rich set of group ordering semantics as well as other group information. In FHIR r5, this is called RequestOrchestration.
- A Task can be a part of a composite Task which then could represent a group of Tasks where each Task is focussed on a ServiceRequest representing an individual request component.
- A group resource allows discovery/notification of a whole request once while discovering groups through individual components results in mutliple notifications.
- The IG includes the group Task approach but has not at present adopted the RequestGroup. It would be more consistent to both support group concepts for test set specification as well as fulfilment. The one requirement where request groups could be used is in the ordering of requests.
Communication Directions
- There are needs to carry guidance around various forms of filler to patient and filler to placer communications.
- Filler to Patient: Allow the filler to communicate to the patient to provide a copy of a request, guidance to a collection centre, or instructions prior to service fulfillment (e.g. fasting).
- Filler to Placer: Filler is instructed to contact the placer using a particular contact approach to inform the Placer of the outcome of the diagnostic service.
- The CommunicationRequest resource is an obvious way of representing the communication direction.
- There are limited semantics available within the CommunicationRequest to carry the intent of the request.
- The CommunicationRequest links to the Task/ServiceRequest so by itself, the CommunicationRequest needs to make sense on its own.
- Requires a _revinclude search to discover relevant requests. In addition, an additional SearchParameter needs added to allow this searching with the 'about' attribute.
- An alternative to CommunicationRequest is to use an extension.
- Extensions could be structured to exactly cover each of the communication request needs. Alternatively, it could link to a CommunicationRequest resource.
- The extension to Task/ServiceRequest would carry the semantics of the communication direction so a CommunicationRequest would not existing in isolation but rather linked from its target.
Transfer to Alternative Diagnostics Provider
- Patient choice of diagnostic provider introduces the need for a flexible fulfillment approach. Current de facto, paper-based request behaviour defaults to selection of a diagnostic provider at placement of the order.
- Selection of an alternative provider is made when a patient goes to an alternative collection centre in the place of pathology. Radiology services are a little different as many services are not walk-in but instead require some form of booking.
- Assuming that diagnostic services receive a request at the point of "directed" requesting by the clinician, there is an option where an alternative service provider needs access to a digital order based on the bar code of an order that was originally directed to another provider.
- There are a number of ways that the alternate provider could request access to or transfer of the order.
- A new operation could be added to the Task or ServiceRequest FHIR endpoint to request transfer. It would require a barcode and identity of the new provider and could receive the new Task/Task Group as an output. this requires the FHIR server to support an additional operation beyond REST.
- A FHIR message could be used (MessageHeader/Bundle) requesting the transfer. It is possible for the FHIR server to then return a value by updating the Message. This approach adds additional subscriptions/notifications to monitor for new Messages and to check for successful transfer.
- A new operation is the cleanest method but does require custom FHIR server support.
Rule 3 Exemption
- This is a pathology-specific extension that allows for multiple tests to be performed off a single request. The IG can support this through the extension but it also possible for the Requesting Service to obey occurrence and quantity constraints on the ServiceRequest. It is also possible for the service to derive a new request with an updated quantity based on previous fulfilment.
Hospital Diagnostic Requesting
- The current IG is aimed at community requesting and requires additional effort to meet data and workflow needs of hospital-based ordering.
Referrals
- While this IG is aimed at diagnostic requests, the base request should be able to support more generic referral but this is yet to be explored.
Round tripping the Request and Result/Report
- As yet, we have not explicitly called out result/report creation as part of the IG however the roundtripping of the request and result will deliver a more complete clinical experience. The fulfilment Task already allows for liking to a result/report and the DiagnosticReport could refer to the ServiceRequest specified in this IG.
The outcomes for this track are:
- TBD
Slides: TBD
Minutes: TBD
