Digital Diagnostics & Pathology Messaging V1.0.0
Introduction
Pathology messaging involves the electronic transmission of results of pathology tests to GP systems in response to a test request placed with laboratories.
In addition to the main exchange of messages, the National Messaging Assurance Service (NMAS) provides a level of automated assurance of message correctness.
Pathology messaging is currently based on EDIFACT Pathology Message Implementation Project (PMIP).
Additional information can be found at NHS Digital's Pathology homepage.
Compliance and Assurance
For advice and support on assurance please contact businesspartners@nhs.net or visit https://digital.nhs.uk/services/nhs-business-partners
Requirements
ID | Requirement | Level |
DDP02 | The system SHOULD continue to support the use of the v1.001 version (also known as MIG variant NHS002) of the (Pathology) Laboratory Service Report message. | SHOULD |
DDP03 | Retransmission of a Pathology PMIP EDIFACT Acknowledgement message MUST be solely in response to a request from the receiving organisation: automatic retransmission is not acceptable. | MUST |
DDP04 | The EDI management software for EDIFACT messages MUST comply with the requirements specified in 'Core Functional Requirements for EDI Management Software in the NHS', sections:
| MUST |
NPFIT-FNT-TO-TAR-0103.01 Pathology Messaging - GP System Requirements
Introduction
This document has been written as an update to the suite of pathology messaging documents published in 2000 by the Pathology Messaging Enabler Programme and subsequently the Pathology Messaging Implementation Programme.
The previously published, and still mostly current, documentation comprises MS Word 232 files in 14 folders with many thousands of hyperlinks between the documents resulting in a 'pack' or approximately 32Mb. Since its publication, much of the messaging infrastructure used to carry messages between organisations has been replaced, the organisation who authored the requirements has been decommissioned and the tooling to generate and maintain the hyperlinks is also no longer available. Some of the requirements have also changed (e.g. the need to encrypt the messages).
For convenience, and to align with common reference, the documentation is referred to as the 'PMIP Specs' and will be referred to as such within this document.
Document Purpose
The purpose of this document is:
- to provide a description of the scope of the requirements in the various sections (folders) of documentation,
- to highlight any obsolete requirements and
- to document any changed requirements.
Audience
The intended audiences for this document are:
- GP System Suppliers
- Laboratory System Suppliers
- Laboratory 'Middleware' Suppliers
- Any NHS/DHSC Authority who is or may become the owner or custodian of these requirements
Document Scope
The scope of the requirements is Laboratory to GP Practice Results Messaging for the following clinical disciplines:
- Haematology
- Biochemistry
- Microbiology (limited)
The requirements do NOT cover any other disciplines, lab to lab messaging or test requests/orders.
Description of Documentation
The PMIP Specs were published to GP system suppliers under the 'RFA' scheme, the latest version being RFA99 v1.2. Within this release they were listed under the 'Clinical Messages' folder. At the time, the intention was to produce further clinical messaging requirements for domains such as Radiology and Discharge and so the requirements were written generically and structured in such as way as to allow other domains to be readily added with little change.
Beneath the 'Clinical Messages' folder are 14 sub-folders, each of which is listed and described in the table below.
Folder Name | Description of Contents |
---|---|
ACK | NHS Standard for Acknowledgement of Clinical Messages – Message Specifications |
CEG | Specification of Clinical EDI Functions for GP Systems |
CEP | Pathology Messaging Requirements |
EDIG | Core Functional Requirements for EDI Management Software in the NHS
|
ISR | IRM Solutions Register |
JCG | Joint Computing Group of the Royal College of General Practitioners & General Medical Services Committee - EDI-RELATED APPLICATION FUNCTIONALITY IN GP CLINICAL SYSTEMS: USER REQUIREMENTS V1.0 |
LSR | NHS Standard for Pathology Reports - Laboratory Service Report Message Specifications |
MREJ | Potential Types of Error in Clinical Messaging and Requirements for their Detection and Rejection |
PMEP | PMEP Technical Products |
RAD | Version 1 Trial NHS Standard EDIFACT Messages for Radiology Requests and Reports |
READ | Laboratory Messaging Subset |
SPEC | Version 1 Trial NHS Standard EDIFACT Messages for GP-Hospital Specialist Service Request & Report |
SRID | Using Sender/Recipient Identifiers |
TCON | Technical Messaging and Networking Requirements for Secure EDI |
Terminology & High-Level Requirement Changes
The major changes to the Pathology messaging environment that have occurred since 2000 are described below. The impact of these changes varied with any consequential changes to messaging systems having been made and the systems have now been operating successfully without change for approximately 10 years. However, the PMIP Specs have not been updated to reflect these changes and it is therefore necessary to document the changes to enable a new reader to fully understand the requirements.
Ref:z | Description of Change and its consequence |
---|---|
1 | Change: The NHS Cryptography Service has been decommissioned and there is therefore no longer a requirement for Laboratories to encrypt messages before sending to GPs or for GPs to decrypt messages upon receipt. |
Consequence: All references to 'cryptography', 'encryption' and 'decryption' in the PMIP Specs should therefore be ignored. | |
2 | Change: The NHS X.400 messaging system, also referred to as the 'MMHS', was replaced by the 'Data Transfer Service' (DTS). DTS has subsequently been replaced by 'Message Exchange for Social Care and Health' (MESH). All pathology messages must now be sent over MESH. The requirements to audit the transport level delivery status of messages still remains – system must record the MESH delivery status instead of the X.400 delivery status. |
Consequence: All references to 'X.400' shall be interpreted as references to 'MESH'. All references to 'MMHS' shall be interpreted as the 'message handling service' which is currently MESH. | |
3 | Change: The 'NHSnet' network has been replaced by the 'N3' network which itself is undergoing a re-procurement. The N3 network is currently being transition to the next generation 'Health and Social Care Network' (HSCN) but will essentially remain the underlying network for the NHS. |
Consequence: All references to 'NHSnet' shall be interpreted as references to 'N3/HSCN'. | |
4 | Change: The 'Codesets' (the allowable subset of Read codes that can be used for reporting) has become the 'Pathology Bounded Code List' or 'PBCL'. It is maintained by the UKTC (UK Terminology Centre) and updates are released every 6 months. Additional 'bonus' files now provide the equivalent CTV3 code for each Read2 code. |
Consequence: The UKTC PBCL publications and associated documentation is the authoritative source of Pathology result 'Codeset' data and the 'READ' folder requirements are limited to the use of the codes only. | |
5 | Change: The latest UKTC PBCL files contain a default UOM (Units of Measure) for most of the PBCL codes. This is a new development intended to improve clinical safety by the adoption of standardised units across laboratories. |
Consequence: GP Systems will receive less variability in UOMs which will enable greater potential for graphing (where this is not disallowed). System should also use these defaults when results are entered manually. | |
6 | Change: Another recent change to the PBCL release is that each test is flagged to indicate whether it is safe to combine results (e.g. for graphing). |
Consequence: Although there are no requirements to graph results it is known that suppliers do provide such facilities in their systems. Where such facilities are provided, suppliers should make any necessary changes to their systems to ensure they support these best clinical practice recommendations. | |
7 | Change: Many of the folders have a document containing a Glossary and many of these glossary items no longer exist or are no longer applicable, for example
|
Consequence: These are historical projects or organisations and there are no materials from these entities that are required as part of the Pathology Messaging specifications and thus none need to be sought. |
Requirements Applicable to GP Systems
The requirements applicable to GP systems are contained in the following subsections of the PMIP Specs:
- ACK
- CEG
- EDIG
- JCG
- LSR
- MREJ
- PMEP
- READ
- SRID
- TCON
Note: Some of the documents in the above sections will contain requirements for Laboratory systems as well as GP systems.
Of particular note is the JCG section which contains a statement of GP User requirements from the Joint Computing Group of the RCGP and BMA. These requirements have been formally documented in the other sections and mostly in the CEG section. It is important to note the following:
- Some of the 'should' and 'may' requirements have since become 'shall' requirements as a result of requirements from other domains, e.g. the functional requirements for handling the receipt of CDA documents contain generic 'received report/document handling' requirements which apply equally to Pathology reports as they do CDA documents and any other received document. The CDA requirements also require systems to implement a common 'Inbox' or 'In-tray' containing all clinical communications, suitably categorised and identified to assist with user 'processing'.
- The patient matching algorithm specified in the CDA Functional Requirements – Receiver Requirements is different to that specified in CEG_04_C_008. Systems should use the Patient matching rules stated in the CDA Functional Requirements rather than those used in the CEG requirements.
GP suppliers will find it useful to read the CEP section which documents the requirements for Pathology laboratory systems as this provides useful information on how they populate messages.
High Level Requirements
Req ID | Requirement Text | Status |
---|---|---|
PM4.1.01 | System MUST meet all the requirements contained in the 'PMIP Specs' as listed at the beginning of this section ($5). | MUST |
PM4.1.02 | Where conflicting, changed or expanded requirements are found in other GP system requirements documentation, including this document, the system MUST meet the requirement(s) stated in the latest published document. | MUST |
PM4.1.02.1 | Systems MUST meet the Patient Matching (automatic and manual) requirements in the CDA Document Receiver Requirements in place of those listed in CEG_04_C_008. | MUST |
PM4.1.02.2 | System MUST support the 'Clinical Review' action (see CDA Document Receiver Requirements) instead of, or in addition to, the 'Viewed' status as specified in CEG_04_D_008. A clinical user must now consciously indicate (by confirming that the action has taken place) that the report/document has been clinically reviewed rather than it being inferred by the system if the report/document has been displayed. | MUST |
Changes since initial publication of requirements
The main changes to the requirements since their initial publication are:
- The X.400 messaging systems has been decommissioned and was replaced by the Data Transfer Service (DTS), itself subsequently replace by 'Message Exchange for Social Care and Health' (MESH).
- The NHS Cryptography PKI Toolkit has been decommissioned and has not been replaced. Consequently there are no requirements to encrypt, decrypt or digitally stamp messages.
- NHSnet has been replaced by the N3 network. The N3 network is currently being transition to the next generation 'Health and Social Care Network' (HSCN)
- The 'Codelists' file, is now known at the Pathology Bounded Code List (PBCL) and is now subject to 6-monthly releases via TRUD along with a release note and an additional file providing mappings to CTV3 codes.
Req ID | Requirement Text | Status |
---|---|---|
PM4.2.01 | Systems MUST receive EDIFACT 'MEDRPT' (Pathology Result) messages, variant NHS003, over MESH and MUST return acknowledgements over MESH. | MUST |
PM4.2.01.1 | System MUST make the following 'translations' when reading the PMIP Specs:
| MUST |
PM4.2.02 | Systems MUST support the receiving and acknowledgement of unencrypted and not digitally stamped EDIFACT 'MEDRPT' (Pathology Result) messages. | MUST |
PM4.2.03 | Systems MUST use the Pathology Bounded Code List (see TRUD website) to validate received EDIFACT 'MEDRPT' (Pathology Result) messages. | MUST |
PM4.2.03.1 | All implemented instances of the System MUST be updated with each new release of the PBCL by the implementation date for GP systems as documented in the PBCL Release Note. This will be no sooner than 1 month from the release date. | MUST |
PM4.2.04 | Within LSR_04_C_001.doc the Interchange number sequence should read 1..99,999,999 and not 1..999,999. Systems MUST restart Interchange numbering upon reaching 99,999,999 with the next Interchange being 1. | MUST |
Recent Changes
During 2011-2012 a number of changes have been introduced into the Pathology Messaging domain. These have centred on the use of UOMs by laboratories. The changes are documented in the PBCL release documentation as published on TRUD and fall into three categories
- A standard set of UOMs has been agreed by the pathology community and laboratories can only use UOM representations published in the Oct 2011 PBCL release pack.
- Certain (Read-coded) tests/investigations have been assigned a default UOM and laboratories have been requested to adopt these defaults as soon as possible with effect from May 2012.
- All (Read-coded) tests/investigations have also been assigned a 'combination' status – a status flag to indicate whether the results for a particular test can be safely combined, e.g. graphed. This is due to differences in the equipment used by different labs and thus the result (and reference range) from one lab may be legitimately different to that of another but they cannot be compared with each other.
The implications of these changes on GP systems will vary depending on the way in which GP systems function. There are no requirements for GP systems to validate UOMs or to use default UOMs when supporting manual entry of results or for systems to combine (e.g. graph) results, however, it is know that some GP systems do provide such functionality.
Req ID | Requirement Text | Status |
---|---|---|
PM4.3.01 | For manually entered pathology test results, the system SHOULD offer the default UOM for each test that has a default UOM assigned (see PBCL UOM Supplemental File – part of the PBCL release pack) | SHOULD |
PM4.3.02 | Systems MAY validate received Pathology results against the UOM file to check for:
| MAY IF validation fails: MUST, SHOULD |
PM4.3.03 | Systems SHOULD NOT combine results (e.g. in graphical form) for a test if the PBCL_CombinationCategory value for the test is '3' (Do not combine). | SHOULD NOT |
Detailed Requirement Changes & Errata
This section details errata and requirement changes in individual documents with the PMIP Specs.
ACK
None
CEG
Filename | Section / Page | Description |
---|---|---|
CEG_01_D_007 | $2 | Ignore all references to cryptography and 'Digital Stamps'. |
CEP_02_A_007 | Various | Ignore all sections on and references to cryptography |
CEG_03_C_008 | $2 | Ignore all references to cryptography and 'Digital Stamps'. |
CEP_04_A_008 | Various | Ignore all sections on and references to cryptography. |
CEG_04_B_007 | Various | Ignore all references to cryptography and 'Digital Stamps'. |
CEG_04_C_008 | $2 | Ignore reference to "Intermittent dial-up connections via PSTN or ISDN" – systems are all permanently connected to N3/HSCN now. Ignore reference to "General (unstructured) E-mail". |
CEP_04_D_008 | Various | Ignore all references to cryptography and 'Digital Stamps'. |
CEP_04_H_007 | $2 | For 'Requirements for Accreditation … (RFA)" read 'GP Systems Compliance Module'. |
CEP_07_A_008 | Various | Ignore all sections on and references to cryptography. |
CEG_07_B_008 | $1 | Ignore all references to cryptography and 'Digital Stamps'. |
CEG_09_A_008 | $2 | MESH Identifiers are issued by NHS Digital. |
CEP
Filename | Section / Page | Description |
---|---|---|
CEP_02_C_003 | p1 | Web link to leeds.ac.uk is no longer valid. For PBCL files go to TRUD (https://isd.digital.nhs.uk/trud3/user/guest/group/0/home) |
CEP_02_D_003 | pA1-3 | Web link to leeds.ac.uk is no longer valid. For PBCL files go to TRUD (https://isd.digital.nhs.uk/trud3/user/guest/group/0/home) |
CEP_03_A_003 | Table 2 | Ignore sections associated with 'Request to Lab'. |
CEP_03_B_003 | Various | Ignore all sections on and references to cryptography |
CEP_11_A_003 | Various | Ignore all sections on and references to cryptography |
CEP_12_A_003 | Various | Ignore all sections on and references to cryptography. |
CEP_13_A_003 | Various | Ignore all sections on and references to cryptography |
CEP_13_B_003 | Various | Ignore all sections on and references to cryptography |
CEP_13_D_003 | $3 | Note that it is not possible to request a read-receipt over MESH. Senders requiring this additional level of reporting must request an Acknowledgment message to be returned (as per CEP_13_B_003) |
CEP_16_B_003 | Various | Ignore all references to cryptography and stamped for authentication. |
CEP_13_C_003 | Various | Ignore all sections on and references to cryptography |
CEP_17_A_003 | Various | Ignore all sections on and references to cryptography |
CEP_17_B_003 | Various | Ignore all references to cryptography and 'Digital Stamps'. |
CEP_21_D_003 | $3 | For MMHS Address, read MESH Mailbox ID. |
CEP_21_E_003 | $3 | For MMHS message ID, read MESH 'sequence identifier' (see MESH File Interface Specification) |
EDIG
Filename | Section / Page | Description |
---|---|---|
EDIG_03_B_005 | $2 | For "Health Authority message flows" read "NHAIS messaging". |
EDIG_04_A_005 | $1 | Ignore whole of section 1.1 re X.400 and refer to MESH messaging specifications for details of construction of MESH messages. |
EDIG_04_B_005 | All | Ignore the whole document. |
EDIG_05_A_005 | All | Ignore all references to cryptography and 'Digital Stamps'. |
ISR
This document provides a record of issues raised during development and early trials and provides an audit record and justification for changes resulting in the current PMIP Specs. There are several references to projects, organisations and technologies that have been superseded and which are documented elsewhere in this document. As the ISR document does not contain any requirements it has not been analysed and therefore revisions or interpretations have not been made. Readers should therefore not regard the contents of this document as authoritative in any way.
JCG
The JCG document is similar to the ISR document in that it does not contain any formal requirements for systems. It does, however, provide a useful reference to the original GP User Requirement and much of the content, aside from references to projects, organisations and technologies that have been superseded, is as valid today as it was when it was written. The user requirements therein are encapsulated elsewhere in the PMIP Specs and as such, any formal changes are captured in changes to other documents within the set.
LSR
Filename | Section / Page | Description |
---|---|---|
LSR 04-C-001 | $1 | Errata: Interchange number sequence 1..999,999 should be 1..99,999,999 |
None
MREJ
None
PMEP
None
READ
Filename | Section / Page | Description |
---|---|---|
READ_02_A_001 | $1 | Web link to leeds.ac.uk is no longer valid. For PBCL files go to TRUD (https://isd.digital.nhs.uk/trud3/user/guest/group/0/home) |
SRID
Filename | Section / Page | Description |
---|---|---|
SRID_01_A_001 | $2 | Ignore reference to NHSIA Helpline. Contact NHS CFH Networking Address Registration Manager. |
TCON
Filename | Section / Page | Description |
---|---|---|
TCON_03_A_005 | Various | Ignore all sections on and references to cryptography and PKI. |
TCON_04_A_005 | Various | Ignore all sections on and references to cryptography. |
TCON_04_B_005 | Various | Ignore all sections on and references to cryptography. |
TCON_04_C_005 | All | Ignore whole document. |
Documentation
We are aware that there are older versions of PMIP documentation available online from archived websites. The links to the documentation provided on this site are the authoritative ones. So users are strongly recommended to use these versions in preference to any other versions.
Edifact_Messaging_Implementation_Guidelines.pdf
EDIFACT pathology messaging Standard ISB 1557
Note: the link above does not currently hold the EDIFACT message specifications themselves. They have now been uploaded to the NHS Developer Network
Dependencies
Creating a compliant implementation requires implementing the following dependent interface standard:
- Messaging Exchange for Social Care and Health (MESH)