DRAFT Implementation Guide

This is for collaboration and discussion purposes and is subject to change.

North West Genomics Testing Workflow (GTW) - Local Development build (v0.0.1) built by the FHIR (HL7® FHIR® Standard) Build Tools. See the Directory of published versions

Placer Order Management [LAB-1]

Referenced Standards

• A. IHE Pathology and Laboratory Medicine (PaLM) Technical Framework - Volume 2a (PaLM TF-2a) Transactions
• B. Test Order Forms
  • See NW Genomics Test Order Form and Questionnaire Viewer

Scope

This transaction is used by the Order Placer to place an Order Group (FHIR RequestGroup) (i.e., a set of Orders to be tested together for a patient) or a standalone Order to the Order Filler. The transaction enables both Order Placer and Order Filler to notify all subsequent changes of status and/or content of each Order to the other side.

EIP - Command Message

Actor Roles

Messages

The following messages are used to support creation and updating of the Genomics Test Request aggregation/archetype

Laboratory Order

Is based on a HL7 FHIR laboratory order (O21) Message which is backwards compatible with HL7 v2 OML_O21 (or ORM_O01) Message.

Detailed Mapping can be here Message OML_O21 to Bundle Map (Experimental) Further details on genomic specific mapping can be found on NHS England FHIR Genomics Implementation Guide - Clincial Headings

This is an initial (incomplete) map and will change to match exact requirement of GLH LIMS <- This is currently OML, not ORM (EPIC).

Complete Order Test Form

In many Order Placer applications (i.e. the EPR or Order Comms) the order is captured via a form.

Submit Test Order Form (Send HL7 FHIR Message Laboratory Order)

The laboratory order (O21) is sent to the RIA via the $process-message API

POST [base]/$process-messsage

Example payload Bundle ‘Message’ - Genomics Order

Validate Message and Transform FHIR to HL7 v2 Message

The incoming order is checked for validity, this may include FHIR Validation against this Implementation Guide. If the message is accepted it is then transformed to a HL7 v2 Message, else a Response HL7 FHIR Message is returned listing the issues in a FHIR OperationOutcome resource.

Send HL7 v2 Message and Response HL7 v2 Message

The RIE then sends the converted HL7 v2 Message to the Order Filler (LIMS) which responds back with a ORL_O22? message. Depending on the capabilty of the LIMS system this may include a ORC with an accession number (Filler Order Number) and a PID with updated/new identifiers, these can then be converted to a FHIR ServiceRequest and Patient respectively.

Response HL7 FHIR Message

The response message is Laboratory Order Acknowledgement described below.

Laboratory Order Acknowledgement

The response laboratory-order-acknowledgement (O22) (asssumed synchronous at present and so subject to change) is returned to the order placer.

Example payload Bundle ‘Message’ - Genomics Order Acknowledgement

For sucessful messages the MessageHeader will have response.code returned will be ok and will look like:

"response" : {
  "identifier" : "9612365d-52a4-4fab-87e7-8a09d753f095",
  "code" : "ok"
}

where the identifier refers to the Bundle.identifier in the orignial message. The Bundle may also include modified FHIR Patient or ServiceRequest resources with updated and new identifiers.

When the RIE is unable to accept the message due to issues such as FHIR Validation issues, the returned MessageHeader will have response.code returned will be error, e.g.:

"response" : {
  "identifier" : "9612365d-52a4-4fab-87e7-8a09d753f095",
  "code" : "fatal-error",
  "details" :{
    "reference" : "OperationOutcome/TODO"
  }
}

where the details section contains a reference to an included OperationOutcome listing details of the failure.

Should the RIE encounter a technical problem, such as an internal service such as FHIR Validation Service or Terminology Service being unavailable, the message has not been accepted and the sender should wait and try again. the returned MessageHeader will have response.code returned will be transient-error, e.g.:

"response" : {
  "identifier" : "9612365d-52a4-4fab-87e7-8a09d753f095",
  "code" : "transient-error",
  "details" :{
    "reference" : "OperationOutcome/TODO"
  }
}

Asynchronous Message Acknowledgement

The previous section described a synchronous messaging system, where the Order Filler returned a response within a short time frame. This is often not going to occur, for example the response may be delayed by:

• System maintenance, e.g. the LIMS has been taken off-line for an upgrade.
• An order has not been picked up in the GOMS by a remote LIMS and is waiting in a queue.

In these instances we now have asynchronous messaging. The suggested method for these message acknowledgements is Asynchronous Messaging using the RESTful API

Store Message in a Message Queue

The RIE will store the acknowledgement messagge in a Message Queue.

Query for HL7 FHIR Messages

The Order Placer (or TIE) will poll for new messages using a FHIR RESTful query.

GET [base]/Bundle?message.receiver:identifier=[odsCode]&_lastUpdated=[date]

Example returned search results Bundle ‘SearchSet’ - Genomics Order

Initially only queries by ODS Code will be supported to support TIE to TIE exchanges.

Update HL7 FHIR Messages

Messages that have been accepted by the calling Order Place (or TIE), need to be acknowledged and removed from the MessageQueue. This is achieved by sending back the messages with the sender and destination fields reversed, i.e.

Orignial Message Header

{
  "resourceType" : "MessageHeader",
  "eventCoding" : {
    "system" : "http://terminology.hl7.org/CodeSystem/v2-0003",
    "code" : "O22"
  },
  "destination" : [
    {
      "endpoint" : "https//hive.mft.nhs.uk",
      "receiver" : {
        "identifier" : {
          "system" : "https://fhir.nhs.uk/Id/ods-organization-code",
          "value" : "R0A"
        }
      }
    }
  ],
  "sender" : {
    "identifier" : {
      "system" : "https://fhir.nhs.uk/Id/ods-organization-code",
      "value" : "699X0"
    }
  },
  "response" : {
    "identifier" : "9612365d-52a4-4fab-87e7-8a09d753f095",
    "code" : "ok"
  }
}

Message Header for returned update

{
  "resourceType" : "MessageHeader",
  "eventCoding" : {
    "system" : "http://terminology.hl7.org/CodeSystem/v2-0003",
    "code" : "O22"
  },
  "destination" : [
    {
      "receiver" : {
        "identifier" : {
          "system" : "https://fhir.nhs.uk/Id/ods-organization-code",
          "value" : "699X0"
        }
      }
    }
  ],
  "sender" : {
    "identifier" : {
      "system" : "https://fhir.nhs.uk/Id/ods-organization-code",
      "value" : "R0A"
    }
  },
  "response" : {
    "identifier" : "9612365d-52a4-4fab-87e7-8a09d753f095",
    "code" : "ok"
  }
}

This update is sent back to the RIE as a FHIR Transaction

POST [base]/

Laboratory Order Updates

For future discussion, this is equivalent of:

• Patient Identify Crossing Referencing: IHE PIX, HL7 v2 ADT A31 and A40

Which in HL7 FHIR (and IHE PIXm) is:

PUT [base]/Patient?identifier=[identifier]

• Master files notification - Staff/practitioner: HL7 v2 MFN M02

Which in HL7 FHIR is:

PUT [base]/PractitionerRole?identifier=[identifier]