FHIR Workflow
The traditional approach for workflow is to exchange messages or documents, which in FHIR is implemented as:
This can result in a considerable duplication in the health system and issues around stale or out of date information.
In FHIR Workflow this clinical data is shared rather than distributed. This sharing should be as close as possible to the source.
Observation Message Example
HL7 v3 and HL7 FHIR STU3 Messaging approach
For example if we look at Observation messages which using NHS Pathology as a guide would result in a FHIR R4 Message Bundle with this stucture:
Resource | Cardinality |
---|---|
MessageHeader | 1..1 |
Patient | 1..1 |
DiagnosticReport | 0..1 |
Observation | 1..* |
ServiceRequest (Test Request) | 0..1 |
Specimen | 0..1 |
Organization | 0..1 |
Practitioner | 0..1 |
This kind of message is quite common and most often appears in pathology messaging but also other exchanges of observations such as NEW2 or COVID-19 at home.
This message has several issues:
- Reference information such as Patient, Organization and Practitioner is exchanged. These resources can be identified instead by identifiers such as NHS Number for Patient, ODS Code for Organization and professional codes such as GMC or GMP for Practitioner. If the full details of these resources are required they can be obtained via API's.
- Specimen details, the sender of this message is not the originator or owner of this resource and so may have concurrency issues. It is common in messaging to reference this resource via identifiers.
- ServiceRequest, the sender is not the originator or owner of this resource and so may have concurrency issues. Like Specimen it is often referenced via identifiers.
- DiagnosticReport and Observation are not available for other practitioners. The solution to this is to send copies of the message to the other interested parties which increases the duplication and concurrency issues.
HL7 v2 and HL7 FHIR R4 Messaging approach
HL7 v2.4 ORU unsolicited-observations solves many of these issues by making use of identifiers and/or enough information to identify reference or external resources. This results is a slimmmer message:
Resource | Cardinality |
---|---|
MessageHeader | 1..1 |
Patient | 1..1 |
DiagnosticReport | 0..1 |
Observation | 1..* |
Patient is still included to help with Patient identification, however with strong identifers such as NHS Number this can also be referenced. This is the approach taken with EPS (FHIR R4) dispense-notifications, the Patient resource is still supported but it is expected NHS Number will be used.
HL7 FHIR R4 Workflow approach
This still leaves the core issues of only using messaging, clinical data is not available for resuse and distribuation of data results in concurrency issues.
The recommended approach is to share these records via a RESTful API and the notifying the recipient of the Task also by RESTful API
For Observations this would require the sender to expose FHIR Observation and DiagnosticReport query endpoints e.g.
The recieving system would need to expose endpoints to receive these notifications.
Advanced Workflow
One of the other disadvantages of the traditional messaging approach is the workflow is one way ('lob over the wall'). This occurs around Request events. For example referrals, lab tests and prescriptions will pass over the ServiceRequest or MedicationRequest. In FHIR it is possible to move away from the technical one way interactions and move to conversations based around business process. So:
'Do this prescription' becomes 'Can you fulfil this prescription?' 'I am bringing patient A to your ED dept' becomes 'Can I bring patient A to your ED dept?'
Put another way we can move to a request-response pattern based around exisitng business process. This workflow is centred around the NHSDigital-Task resource.
The example below shows an example of a Task sent from a hospital trust to a pharamcy. The MedicationRequest is not sent but is availble if required (the example resource reference is to the EPS Query API). References to other resources such as Patient and Organisation use identifier references (NHS Number and ODS codes) and are again available via an API
{ "resourceType": "Task", "status": "requested", "intent": "order", "code": { "coding": [ { "system": "http://hl7.org/fhir/CodeSystem/task-code", "code": "fulfill", "display": "Fulfill the focal request" } ] }, "focus": { "reference" : "https://api.service.nhs.uk/electronic-prescriptions/FHIR/R4/MedicationRequest/A7B86F8D-1D7C-FC28-E050-D20AE3A215F0", "identifier": { "system": "https://fhir.nhs.uk/Id/prescription-order-item-number", "value": "A7B86F8D-1D7C-FC28-E050-D20AE3A215F0" }, "display": "Morphine 10mg modified-release tablets" }, "for": { "identifier": { "system": "https://fhir.nhs.uk/Id/nhs-number", "value": "9446368138" } }, "owner": { "identifier": { "system": "https://fhir.nhs.uk/Id/ods-organization-code", "value": "M12345" } }, "requester": { "identifier": { "system": "https://fhir.nhs.uk/Id/ods-organization-code", "value": "RR8" }, "display": "Leeds Teaching Hospitals" }, "authoredOn": "2021-10-09T12:00:00+00:00", "reasonCode": { "coding": [ { "system": "http://snomed.info/sct", "code": "33633005", "display": "Prescription of drug" } ] } }
The recipient of this request can respond and they will typically do this by altering:
owner
reassigning or removing themsevles as the owner.status
such as changing this to 'accepted' or 'rejected`statusReason
normally used when the status has changed torejected
,cancelled
orfailed
.
For example: In the (fragment) example below the pharmacy has rejected
the Task as they were unable to dispense the medication.
{ "resourceType": "Task", "status": "rejected", "statusReason": { "coding": [ { "system": "https://fhir.nhs.uk/CodeSystem/EPS-task-dispense-return-status-reason", "code": "0002", "display": "Unable to dispense medication on prescriptions" } ] } }