Design Overview

Pathology Business Information Model and FHIR Profile Mapping

The following diagram is a high-level logical representation of the key business entities relating to pathology test requesting and reporting:

To aid clarity, individual and organisation type entities (e.g. Performer / Performing Organisation) have been combined in the diagram but may be referenced independently. Each business entity is summarised below, together with links to the corresponding FHIR R4 resource (as defined in the base FHIR R4 Specification) and FHIR UK Core R4 profile (as described in the Profiles section of this implementation guide).

Pathology FHIR Data Model

The following diagram shows the key relationships between each of the pathology related FHIR resources (and associated profiles). It illustrates how the high-level information model described above is represented using FHIR. The arrows show the direction of the references between the FHIR resources.

Key aspects of the data model are summarised below:

• DiagnosticReport contains the overall findings and clinical interpretation relating to one or more pathology tests.
• Test results and test groups are defined as Observations and are referenced from DiagnosticReport using DiagnosticReport.result.
• Observation.hasMember relationships are used to link test result Observations to an associated test group Observation. This is aligned with the Observation.hasMember grouping method described in the base FHIR R4 Specification.
• To indicate that an Observation represents a test group, Extension UKCore-ObservationOrganizer is used.
• Multiple levels of test group Observations and test result Observations may be nested to support complex report structures, such as those used in Microscopy, Culture and Sensitivity (MC&S) reports.
• ServiceRequest is used to carry summary details relating to the test request that the test report was based on.
• If multiple tests or test groups are requested as part of the same “event” (generally by the same practitioner at the same time for the same subject), an instance of ServiceRequest is required for each requested test or test group. ServiceRequest.requisition acts as a common identifier to link the requests.
• The Specimen.request data element is used to reference the ServiceRequest that a specimen relates to. This should be used when a test was requested before the specimen was collected.
• It is also possible to link a ServiceRequest to a specimen using the ServiceRequest.specimen data element. This should be used when a test is requested and the specimen has already been collected.

The diagram below shows a simplified data model for an example pathology test report:

SNOMED CT Usage

SNOMED CT concepts are used to populate the following key data elements in the FHIR profiles described in this implementation guide:

• The code element of UKCore-DiagnosticReport-Lab SHALL be populated using the following fixed SNOMED CT record artifact concept and description:
  • 721981007 | Diagnostic studies report
• The code element of UKCore-Observation-Lab (Test Result) SHALL be populated using one of the following:
  • memberOf 999002881000000100 | PBCL (Pathology Bounded Code List) observables simple reference set, OR
  • memberOf 1853551000000106 | PaLM (Pathology and Laboratory Medicine) observable entity simple reference set, OR
  • if an Observable Entity concept from either of the above reference sets cannot be identified (e.g. if a local reportable has yet to be mapped to SNOMED, or if the reportable is not yet represented in SNOMED), then it is acceptable to use a local code
• The code element of UKCore-Observation-Lab (Test Group) SHALL be populated using one of the following:
  • memberOf 999002881000000100 |Pathology Bounded Code List observables simple reference set, OR
  • if an Observable entity concept from the above reference set cannot be identified, use a SNOMED CT Observable entity code taken from descendantOf 363787002 |Observable entity (observable entity)|, OR
  • if the two methods described above fail to identify a suitable code, then it is acceptable to use a local code
• The category element of UKCore-ServiceRequest-Lab SHOULD be populated with the following:
  • ServiceRequest.category.coding.system = http://snomed.info/sct
  • ServiceRequest.category.coding.code = 108252007
  • ServiceRequest.category.coding.display = Laboratory procedure

The diagram below illustrates how these elements of SNOMED CT are applied, using the example test report data model shown earlier. SNOMED PBCL concepts are used to represent the reportable items associated with each Observation.

Further information on the use of SNOMED CT for pathology reporting can be found on the Pathology Standards Implementation website.