About the Pathology API category

Pathology API
1

What is this category for?

This category is the primary discussion hub for the NHS Pathology API and the modern digital infrastructure supporting pathology and laboratory medicine in England.

As the NHS moves away from legacy messaging standards (such as PMIP EDIFACT) toward the DAPB4101: Pathology and Laboratory Medicine Reporting Information Standard, this space is for developers, LIMS (Laboratory Information Management System) providers, and middleware vendors to:

  • Discuss the Pathology FHIR Specification.

  • Troubleshoot API authentication, message validation, and event-based architectures.

Why may you want to use this category?

Use this category to stay informed about the national roadmap for pathology interoperability. Whether you are building a new diagnostic tool, updating a LIMS, or managing a regional pathology network, this is where you can find:

  • Implementation Support - Help with mapping legacy codes to SNOMED CT and implementing FHIR bundles.

  • Architecture Discussions - Guidance on how the Pathology API interacts with Patient Data Manager (PDM) and event-driven notifications.

  • Early Access & Testing - Updates on sandbox environments and the “Onboarding” process for pathology integrations.

What should topics in this category contain?

When starting a new topic, please try to include:

  • Standard/Version: (e.g., FHIR R4 UK Core, DAPB4101).

  • Context: Are you a LIMS provider, a GP system supplier, or an independent developer?

  • Specific Error Codes: If you are experiencing technical issues with the Pathology API or PDM validation.

  • Use Case: What is your primary care use case?

2

What is the scope of this?

I am working in (regional) Genomics integration and we are already working cross domain diagnostic workflows for clinical pathways (often cancer related). This is what IHE would call Inter Laboratory Workflow (ILW), we perform subcontracted orders which are LIMS → LIMS.

Some of our results are probably not ‘NHS Genomics’ and more like ‘NHS Pathology’.

3

Hi Kevin,

I’m not sure the original reason for this channel being set up, but we are now using it primarily for https://digital.nhs.uk/developer/api-catalogue/pathology-laboratory-reporting which is based on Home - HL7 Europe Laboratory Report v2.0.0

4

Thanks.

From that I’d infer the initial use case is for a national service for primary care.

What’s the reason for using clinical document architecture i.e. FHIR Document? Most LIMS are using document-messaging in HL7 v2 ORU_R01 format which has a relatively simple transformation to FHIR document-messaging (guidance I’ve wrote on v2 → FHIR transform is here HL7 v2 Standards - NHS North West Genomics v2.0.0) - main issue will be Composition doesn’t exist in source data.

5

Two reasons,

  • Interoperability decision move to REST based architecture where possible

  • The PDM FHIR Server chosen expects RESTful data flow and does not allow for message Bundles

    Yes this is primary care use-case.

    The Composition does not contain any new data, so middleware are happy to create this resource following the EU Specs.

    The data is also to be stored separately in the PDM server, so the composition resource allows for easy access to all the workflow (if needed) via $document operation

    The data flow from GP to Lab, and Lab to Middleware are outside this scope so will not change from the current EDIFACT / HL7 v2 architecture

6

Hi Kevin,

The intitial use of the Pathology API is to support the DAPB4101: Pathology and Laboratory Medicine Reporting Information Standard, which governs the use of FHIR & SNOMED for reporting pathology lab test results to GP practice.
in terms of specialisms, DAPB4101 covers:

  • clinical biochemistry

  • haematology

  • immunology

  • transfusion medicine

  • microbiology – this includes bacteriology, virology and serology

    further specialisms are under review, but it’s unliklely DAPB4101 will extend to cover genomics. My hope is that the Pathology API will in time be used to support other data flows, but that’s something for the future…

    So - DAPB4101 = lab to GP reporting for pathology & lab medicine (not requesting, nor lab-to-lab)

    Pathology API = hopefully multiple use-cases in future, but for now, supporting DAPB4101

    ALAW = Gogs

7

I think the issue is the implementation is still messaging with message processing following receipt of the bundle. FHIR Document is not intended to be broken up for persistence, it is a clinical document maybe legally attested..

8

cheers.

I think their might be a slight terminology issue here which might cause issues:

NHSE Laboratory Middleware is what I would call from NHS Trust/Region perspective Order Comms.
Order Comms is often an output from the main NHS Trust Middleware/Trust Integration Engine which handles most/many lab exchanges.

9

Hi Kevin,

In the context of DAPB4101’s implementation, we refer to pathology middleware as being software that transforms a pathology report generated by a lab’s LIMS (in various formats, carrying local reportable codes) into a pathology report that conforms with the Pathology FHIR Spec. carrying SNOMED reportables to support lab to GP reporting. Each lab currently has such middleware to support PMIP EDIFACT lab to GP reporting.
Whilst the middleware in use today (i.e, Clinisys Labcomm, Iuvo Clin-e Connect, & Optum Keystone) perform additional functions, & in Clinisys’ case is integrated with their ICE Order Comms, we simply refer to middleware as shorthand for the component & functionality we need for DAPB4101’s use-case.

10

Difficult to describe on a forum.

Short version is (as regional NHS diagnostics) I am pushing for standardisation before this hits NHS England infrastructure.
So our version will be aiming at standardising both HL7 v2 and FHIR before it gets converted to PMIP EDIFACT or NHS Pathology.

On a practical level this means standardising LIMS to Secondary Care.