{
"sendingFacility": "Facility A",
"patientId": "987654",
"testCode": "L12345",
"testName": "Blood Glucose",
"unitOfMeasure": "mg/dL",
"value": "5.4",
"otherMetadata": {
"loincCode": "2339-0",
"labSystem": "LabSoftX"
}
}
Part of SNOMED CT PaLM Mapping Best Practice
Appendix
Definitions of data elements used in DAPB4101
Laboratory test report - this contains all the data items relating to a laboratory test(s), represented by a FHIR UK Core R4 bundle.
Laboratory test result code ('reportable') - a single data item contained in the report identifying the specific laboratory test to which a value(s) and interpretation can be assigned, represented by SNOMED CT Observable entity concepts.
Laboratory test request code ('requestable') - a single data item contained in the report identifying the specific laboratory test(s) initially requested that led to the generation of results. These will also represent test panels or batteries within the reports. represented by SNOMED CT Procedure concepts.
Report identifier - a single data item contained in the report identifying the FHIR message as a diagnostic studies report. To be represented by the SNOMED CT concept 721981007 Diagnostic studies report (record artifact).
Laboratory test result value – a single data item contained in the report, often accompanied by a unit of measure, representing the information determined by making the observation. Currently represented by numerics or text strings, to be represented by numerics or codes contained in FHIR UK Core value sets where possible or, where appropriate, text strings.
Unit of measure (UoM) - a single data item contained in the report accompanying a laboratory test result value. Currently represented by text strings, to be represented by Unified Code for Units of Measure (UCUM) codes where possible or, where appropriate, text strings.
Laboratory test result interpretation - a single data item contained in the report, representing a categorical assessment of an observation value (for example, high/low/normal). Currently represented by text strings, to be represented by codes contained in FHIR UK Core value sets where possible or, where appropriate, text strings.
Laboratory test specimen – a single data item contained in the report identifying the specimen upon which the test was performed. Currently represented by text strings, to be represented by SNOMED CT Specimen/Substance/Morphologic abnormality/Body structure/Physical object concepts, or where appropriate, text strings.
Test results
Test results are reported in a variety of ways:
Quantitative result
The result is expressed as a number, usually with an associated unit of measure. Comparators may be used to indicate that the actual value is greater than or less than the stated value. A range of values may be reported instead of a single value.
Examples of quantitative test results include:
Mass concentration of albumin in serum: 47 g/L
eGFR (estimated glomerular filtration rate) using creatinine Chronic Kidney Disease Epidemiology Collaboration equation per 1.73 square metres: >90 mL/min/1.73m2
Semi-quantitative result
The result is expressed using a descriptor to indicate the relative degree of positivity or negativity based on a scale. The scale is not always formally defined. Semi-quantitative results are widely used in microbiology, particularly for reporting microscopy and culture test results to indicate the amount or level of growth of organisms.
Examples of semi-quantitative test results include:
Organism susceptibility to nitrofurantoin: RESISTANT
Qualitative result
The result is expressed using a descriptor to indicate positivity or negativity. The descriptors are usually defined as pairs, for example: positive/negative, detected/not detected, isolated/not isolated. In this respect, qualitative results can be seen as a subset of semi-quantitative results in that they contain only 2 scale points to indicate positivity or negativity.
Examples of qualitative test results include:
Qualitative result of Hepatitis B surface antigen in serum: NEGATIVE
Qualitative result of methicillin resistant Staphylococcus aureus ribonucleic acid nucleic acid amplification: NOT DETECTED
Quantitative result combined with an interpretation
In some cases, a result may contain a combination of quantitative and non-quantitative elements. The non-quantitative element is sometimes expressed separately as an interpretation to provide a categorical assessment of the quantitative value.
Examples include:
Count of lymphocytes in blood: 0.70 10*9/L: LOW
Arbitrary concentration of Rubella immunoglobulin G antibody in serum: >10 IU/ml: DETECTED
Narrative result
The result is presented as text. For example:
Aerobic culture: No growth detected after 5 days incubation.
Prompt used in testing for LLM source data cleansing
Objective
You are purposed with breaking down a set of local lab pathology data into its component elements in order to provide an input to map to a set of SNOMED CT concepts which will be provided. The model should enable us to break down the concepts in order to help another tool generate highly accurate mappings, while maintaining clarity and confidence in its suggestions.
Input requirements
The GPT will receive the local laboratory codes in the spreadsheet 'GPTImportSheet'. The format is:
Local Code: Unique identifier for the local lab test (for example, CREA)
Local Description: Description of the test for example, 'Creatinine')
UoM: Unit of measure (for example, 'umol/L')
Read PBCL Code (optional): Legacy Read PBCL code (for example, 44J3.)
Read PBCL Description (optional): Description corresponding to the Read PBCL code
Output requirements
Deepseek will return the output as a table with the following column headers:
Local Code: From Input Unique identifier for the local lab test (for example, CREA)
Local Description: From Input Description of the test (for example, 'Creatinine')
UoM: From Input Unit of measure (for example, 'umol/L')
Read PBCL Code (optional): From Input Legacy Read PBCL code (for example, 44J3.)
Read PBCL Description (optional): From Input Description corresponding to the Read PBCL code
Deepseek will interpret the above and populate the following fields:
Component
Property
Sample
Combined
Component field
This is the specific component which we are measuring. This can be a substance such as calcium, protein such as albumin, or a cell such as lymphocyte. This information is generally in the local description or Read PBCL description. Some processing of these fields can be required including expanding any acronyms, for example, MCH for mean corpuscular haemoglobin.
Property field
This is the measurement technique used to measure the component examples, which can be substance for example, concentration, molar concentration or percentage. The technique can be obtained through the use of the Units of Measure Field.
There is a sample mapping table between the UoM and their properties in 'Units_of_measure'.
Sample field
This is the sample in which the component is measured for example, blood, serum or urine. This information can be picked up from the local description or Read PBCL description. Where no example exists then place a guess based on the most likely substance, for example 'blood' for 'basophils' or 'urine' for 'epithelial cells'.
Use only the fields found in 'Direct Site Attributes in PALM-20250225-183230'.
Combined field
Combine the other 3 calculated fields into the following format '{property} of {component} in {sample}' for example, 'Substance concentration of magnesium in serum' or 'Count of lymphocytes in blood'. Keep the expanded form of the acronym in this field.
Onotology and semantic translation architecture
Indicative architecture
This proposed design outlines the implications for national SNOMED CT PaLM mapping and is subject to approval by NHS England Transformation Directorate.
SNOMED CT PaLM mapping workflow - high-level architecture
Middleware subsystem for SNOMED CT PaLM mapping and messaging
Breakdown of core system components
Terminology server components and interactions
Semantic translator system - user interaction and mapping workflow
Security and performance considerations
Security
Security requirements at high level requires implementation of authentication and authorisation for API access. The authorisation plays a pivotal roles to ensure a pathologist or biomedical scientist from a source lab can only add, amend or view their own lab codes and mappings.
Performance
Optimise API response times.
Implement caching for frequent terminology lookups.
Ensure scalability across all NHS labs.
Message flow design
Step 1: Lab sends message
Labs may send messages in different formats (HL7 v2, JSON, XML, CSV, or proprietary formats).
Each message must contain:
Sending facility (for example, Facility A vs. Facility B may impact translation)
Local codes (Lab’s internal reportable codes)
Unit of Measure (for example, mg/dL, mmol/L—important for conversion logic)
Relevant metadata (LOINC, System IDs, or any extra identifiers)
Example incoming proprietary message (JSON) format
Example incoming HL7 message
MSH|^~\&|LabSystem|Facility A|Middleware|NHS|20250224090000||ORU^R01|12345|P|2.5.1 PID|||987654^^^NHS||Doe^John||19800101|M|||123 Test St^^London^^SW1A2AA||| OBR|1|1234|5678|BLOOD GLUCOSE^LOCAL|||20250224090000 OBX|1|NM|L12345^LOCAL|1|5.4|mg/dL|||N|||20250224090000
Step 2: Middleware receives and normalises message
Middleware identifies the format (for example, HL7, JSON, XML) and converts it to a common structure.
Extracts Sending Facility, Local Code, Unit of Measure, and Metadata.
Normalises UoM (if needed).
Sends structured request to the Terminology server.
Standardised request to Terminology server (FHIR ConceptMap API)
GET /ConceptMap/$translate?code=L12345
&system=http://local.lab.codes
&context=sendingFacility=Facility A
&unitOfMeasure=mg/dL
Step 3: Terminology server determines SNOMED CT Mapping (conditional translation)
Standardised request to Terminology Server (FHIR ConceptMap API)
The Terminology Server does not perform simple one to one mappings. Instead, it evaluates context:
Local Code + Sending Facility + Unit of Measure may influence mapping.
Other metadata (LOINC codes, system ID, lab-specific codes) may also contribute.
May require rule-based logic to determine the correct SNOMED CT PALM code.
Example: How context changes the mapping
| Local code | Sending facility | Unit of Measure | SNOMED CT PaLM Mapping |
|---|---|---|---|
| L12345 | Facility A | mg/dL | 43396009 (Blood Glucose Measurement) |
| L12345 | Facility B | mmol/L | 271062007 (Glucose level in plasma) |
| L67890 | Facility C | mg/L | 1049381000000107 (Protein Level Test) |
FHIR ConceptMap Response (Conditional Mapping applied)
"resourceType": "Parameters",
"parameter": [
{
"name": "match",
"resource": {
"code": "43396009",
"system": "http://snomed.info/sct",
"display": "Blood Glucose Measurement"
}
}
]
}
Step 4: Middleware Updates Message & Sends to GP System
Middleware updates the original message with the translated SNOMED CT codes.
Constructs HL7 v2 message (if GP system requires it) or FHIR resource.
Example: FHIR Observation Sent to GP System
{
"resourceType": "Observation",
"id": "blood-glucose",
"status": "final",
"code": {
"coding": [
{
"system": "http://snomed.info/sct",
"code": "43396009",
"display": "Blood Glucose Measurement"
}
]
},
"valueQuantity": {
"value": 5.4,
"unit": "mg/dL",
"system": "http://unitsofmeasure.org",
"code": "mg/dL"
},
"subject": {
"reference": "Patient/987654"
}
}
FHIR Data structures
FHIR ConceptMap (Core mapping storage)
Stores local lab-to-SNOMED CT mappings.
Enables automatic translation via '$translate' API.
FHIR ValueSet (Defining valid local codes)
Ensures that only valid local lab codes are used in mappings.
Helps with UI dropdowns and validation.
FHIR ConceptMap API calls
Translate Local → SNOMED CT via GET '/ConceptMap/$translate'.
Add New Mapping via POST '/ConceptMap'.
Last edited: 22 May 2025 5:14 pm