The Message Exchange for Social Care and Health (MESH) is the main secure large file transfer service used across health and social care organisations.

More information on MESH can be found at

The following flows depicts two ways of using MESH to communicate test requests and reponses

Ordering Entity - Central Broker - Home GLH

Ordering Entity - Home GLH

FHIR Workflow

The following pattern has been taken from the workflow management page on FHIR R4, linked above. The workflow broker is assumed to be the general architecture for the Genomic Medicine Service.

The Steps from the generalised pattern can be applied to a Genomic Medicine Service in the following way:

  1. A Placer system (e.g. EHR), POSTs a UKCore-ServiceRequest to a broker (e.g. central GMS orders repository)
    1. The ServiceRequest needs to link to a UKCore-Patient, UKCore-Practitioner, UKCore-Organisation etc.
    2. An associated Specimen will also need to be sent to the broker, linked to the ServiceRequest
    3. A UKCore-Consent should also be linked to the ServiceRequest for recording whether results can be used in research (defined as in scope for the programme).
  2. The Broker notified of new unassigned request (without a Task resource) via a subscription
  3. The Broker POSTs a Task to its own system, pointing to request resource, and seeking fulfilment from filler (UKCore-Organisation, in the case of the GMS, the Home GLH)
  4. The GLH system polls or is notified of Task
  5. The Filler PUTs update to Task to indicate it has been claimed/accepted
  6. The Filler performs the requested tests/analyses, internal to LIMS (outside the scope of the central GMS), and updates (PUTs) Tasks as progress is made
  7. The Filler POSTs a DiagnosticReport back to broker to record results (this implements the Event resource) once the analysis and interpretation has been performed
  8. The Filler finally PUTs an update to its Task, changing the status to completed and pointing to UKCore-DiagnosticReport, which contains the PDF
  9. Workflow broker subscribes to changes to Tasks for automated notification to placers
  10. A Placer polls for completed Tasks (or is notified of completed Tasks)
  11. The Placer inspects results and updates ServiceRequest via PUT to indicate completion.