NHS North West Genomics - Local Development build (v2.2.0) built by the FHIR (HL7® FHIR® Standard) Build Tools. See the Directory of published versions

Use Case: StarLIMS / iGene Integration

NW Genomics — StarLIMS / iGene Integration.

References

1. Inter Laboratory Workflow (ILW) - Sub-orders LAB-35 and LAB-36
2. Diagnostic Model Overview
3. Regional Integration Engine (RIE)
4. FHIR Validation
5. nw-gmsa.github.io/en/index.html - the North West "data contract" all FHIR Repository resources must conform to
6. 02 - Work Orders: A Worked Example - worked example of retrieving orders from the Resource Access Provider (FHIR Repository), the mechanism used by both the existing sub-contracting path and the future RIE-routed path (see Developer Guides)

Clinical Pathway Overview

What is being tested

This use case isn't about a specific clinical test - it's about how a test allocated to StarLIMS (the Liverpool GLH's satellite LIMS) gets its order and result moved correctly between iGene (the master LIMS) and StarLIMS, so which system actually processes the test stays invisible to the referring clinician.

The end-to-end clinical journey

1. Order placed - a clinician orders a genomic test, the same way regardless of which LIMS will eventually process it.
2. Order clerked into iGene - the order is entered into the master LIMS.
3. Test allocated to StarLIMS - some tests are work-ordered to StarLIMS for processing.
4. Testing performed - StarLIMS carries out the test.
5. Result flows back - the result returns to iGene, and from there to the ordering clinician.
6. Clinical decision - the clinician acts on the result, without needing to know which LIMS actually ran it.

flowchart LR
    A[Clinician<br/>orders test] --> B[Order clerked<br/>into iGene]
    B --> C[Test allocated to<br/>StarLIMS]
    C --> D[Testing<br/>performed]
    D --> E[Result flows back<br/>through iGene]
    E --> F[Clinician<br/>acts on result]

Why this matters for developers

• Whether a test runs on iGene or StarLIMS is purely an internal allocation decision - it should never be visible in what the referring clinician receives.
• A "work order" is a different concept from the original Laboratory Order (LAB-1): the work order is the internal routing of a specific test to whichever system (StarLIMS or otherwise) will actually process it.

Actors

Transactions

Current Process

North West Genomics was formed from two Genomic Laboratory Hubs — one in Manchester and one in Liverpool. Many tests for Liverpool hospitals were historically processed in Liverpool using StarLIMS at the Liverpool GLH.

The move to a single organisation includes consolidating onto one master LIMS, iGene. For ordering and reporting, this means:

• Orders and specimens are clerked into iGene. Most orders arrive on paper, though a growing number of NHS Trusts in the region now send electronic orders (IHE LAB-1). Some tests are allocated to satellite LIMS, and these are referred to as work orders.
• Reports still originate from a variety of LIMS in multiple formats, though this is also being centralised in iGene. NW Genomics is moving towards electronic transmission (HL7 ORU / IHE LAB-3, with FHIR Laboratory Report support planned) to return reports to NHS Trusts.

Future Process

Two future developments are planned for StarLIMS integration:

• Order and Report Routing - the Regional Integration Engine (RIE) will receive Laboratory Orders (LAB-1) directly from NHS Trusts and route each one to iGene or StarLIMS, in addition to the existing sub-contracting path from iGene.
• Automated Sub-Contracted Orders - the existing sub-contracting path, where iGene routes selected work orders to StarLIMS, moves from manual entry to an automated feed.

Order and Report Routing

Today, NHS Trusts (Order Placer) send Laboratory Orders (LAB-1) to iGene (Order Filler), and iGene alone decides - internally - which orders to sub-contract to StarLIMS (see Sub-Contracted Orders below). As a further future development, the RIE will sit in the LAB-1/LAB-3 path itself: it will receive Laboratory Orders directly from NHS Trusts, inspect order metadata such as the Test Directory Code, and route each order to whichever system - iGene or StarLIMS - is the correct Order Filler for that test.

The existing sub-contracting process from iGene to StarLIMS is unaffected and continues to exist alongside this - it is, in effect, a second, iGene-internal routing step for orders the RIE has already routed to iGene.

For StarLIMS, the mechanism for receiving these RIE-routed orders is the same as receiving iGene's sub-contracted orders today: StarLIMS picks them up by querying the Resource Access Provider (FHIR Repository), as described in Overall Workflow (Sub-Contracted Orders) below - there is no new, bespoke integration for the NHS Trust-routed case. The two are distinguished in the FHIR Repository by ServiceRequest.intent: RIE-routed Laboratory Orders (LAB-1) use order, while iGene's sub-contracted orders (LAB-35) use filler-order.

Laboratory Reports follow the same pattern in reverse. The process that populates the FHIR Repository from a Laboratory Report is unchanged (see Subcontracted Laboratory Report below for the sub-contracting case); what's new is that the RIE also acts as a router, forwarding each Laboratory Report on to the NHS Trust that originally placed the order.

flowchart LR
    OP["NHS Trusts<br/>Order Placer"]

    subgraph RIE["Regional Integration Engine (RIE)"]
        R1{"Inspect order metadata<br/>e.g. Test Directory Code"}
    end

    IGENE["iGene<br/>Order Filler"]
    STARLIMS["StarLIMS<br/>Order Filler"]

    OP -->|"LAB-1: Laboratory Order"| RIE
    R1 -->|Routed Order| IGENE
    R1 -->|Routed Order| STARLIMS
    IGENE -->|"LAB-3: Laboratory Report"| RIE
    STARLIMS -->|"LAB-3: Laboratory Report"| RIE
    RIE -->|Routed Report| OP

    IGENE -.->|"Sub-Contracted Orders<br/>LAB-35/LAB-36 - existing, unchanged"| STARLIMS

Automated Sub-Contracted Orders

Work orders are currently entered into StarLIMS manually; this process will be automated. The data transferred includes patient demographics (NHS number, gender, date of birth, name), order details (placer and filler order numbers), and specimen information (type and identifier). Reports will flow from StarLIMS to iGene, and from there be distributed to NHS hospitals.

The overall design is broadly the same as the IHE Inter Laboratory Workflow, with StarLIMS acting as the Sub-Contractor and iGene acting as the Order Filler. The order process described above corresponds to transaction LAB-35, and the report process corresponds to LAB-36.

This fits inside the IHE Laboratory Testing Workflow, as illustrated at nw-gmsa.github.io/en/ILW.html#sub-orders-lab-35-and-lab-36.

Overall Workflow (Sub-Contracted Orders)

flowchart LR
    subgraph OF["iGene — Order Filler"]
        OF1[Orders and Specimens<br/>clerked into iGene]
        OF2[Reports distributed<br/>to NHS Trusts]
    end

    subgraph RIE["Regional Integration Engine / FHIR Repository"]
        R1[(FHIR Repository<br/>Patient, ServiceRequest,<br/>Specimen, Reports)]
    end

    subgraph SC["StarLIMS — Sub-Contractor"]
        SC1[Work Orders received<br/>tests managed in StarLIMS]
        SC2[Reports produced<br/>in StarLIMS]
    end

    OF1 -->|LAB-35: Sub-Order<br/>CSV export - daily| RIE
    RIE --> SC1
    SC2 -->|LAB-36: Sub-Order Report<br/>CSV| RIE
    RIE --> OF2

Subcontracted Orders

The initial design for handling work orders is as follows:

1. Orders and specimens are clerked into iGene.
2. Work orders for StarLIMS are generated, with specific tests managed within StarLIMS.
3. Work orders are exported as CSV files on a daily basis.
4. The regional integration engine (RIE) picks up these files and stores them in the FHIR Repository as Patient, ServiceRequest, and Specimen resources. Details of this data model are available at nw-gmsa.github.io/en/diagnostic-core.html.
5. A StarLIMS Import process polls the FHIR Repository for new work orders, and imports them directly into the StarLIMS SQL database.

flowchart TD
    A[Orders and Specimens<br/>clerked into iGene] --> B[Work Orders created<br/>for StarLIMS tests]
    B --> C[Work Orders exported<br/>as CSV - daily]
    C --> D[Regional Integration Engine<br/>RIE picks up CSV files]
    D --> E[(FHIR Repository)]
    E -.->|StarLIMS Import process polls<br/>for new Work Orders| F[StarLIMS SQL database<br/>updated with Work Orders]

Subcontracted Laboratory Report

Once results have been produced in StarLIMS, a StarLIMS Export process (in the RIE, or an external process - probably developed in Python for both) extracts the report from StarLIMS via SQL (and other sources, if required). This output is converted to a FHIR Laboratory Report Message R01, and sent to the RIE - from there it is handled the same way as reports from iGene or Histotrac, as described in Regional Integration Engine (RIE) - Report Process.

flowchart TD
    A[(StarLIMS SQL database)] --> B[StarLIMS Export process<br/>extracts report via SQL<br/>- and other sources if required]
    B --> C[Converted to FHIR<br/>Laboratory Report Message R01]
    C --> D[Sent to Regional<br/>Integration Engine RIE]
    D --> E["Handled as any other report<br/>(see RIE Report Process)"]

Note: the Reports process is anticipated, not yet finalised.

Data Models

• ServiceRequest - work orders (placer and filler order numbers)
• Specimen - specimen type and identifier
• Patient - NHS number, gender, date of birth, name

Work Order CSV Export from iGene

The daily work-order CSV export from iGene (step 3 of Subcontracted Orders above) has the shape below - see StarLIMSSampleData.csv for a full example file. This same export shape/pattern is reused by OMICS DSS Result Integration for DLIMS work order metadata.

TestAccessionIdentifier, and the PLAC/FILL split on PlacerOrderNumber/ FillerOrderNumber, are not yet confirmed against a published identifier system - see the Questionnaire's own item design notes for detail.

Examples

No example resources are published yet for this scenario.

Security Considerations

Includes:

• OAuth2 Standard for Authorisation
  • including use of JWT access tokens and future support for SMART-on-FHIR Scopes
• FHIR AuditEvent/IHE BALP for Audit Logging
• TLS for Transport Security/Encryption

Developer Guides

• 02 - Work Orders: A Worked Example - worked example of retrieving orders from the Resource Access Provider (FHIR Repository), the mechanism used by both the existing sub-contracting path and the future RIE-routed path

See Developer Guides for the full notebook series.