NHS North West Genomics
2.2.5 - ci-build United Kingdom flag

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

Logical Model: Genomic Test Report

Official URL: https://fhir.nwgenomics.nhs.uk/StructureDefinition/GenomicTestReport Version: 2.2.5
Draft as of 2026-11-05 Computable Name: GenomicTestReportModel

The common core of a Genomic Test Report: the Patient, Hospital Spell, Diagnostic Workflow and Results shared by every report, regardless of test type. Individual test findings are carried as panel-specific results (see Report Panels below).

This is a logical model - it is not exchanged as is. It breaks down into DiagnosticReport, Patient, Encounter, ServiceRequest, PractitionerRole, Organization, Specimen, Observation and DocumentReference/Binary for exchange via HL7 v2 ORU_R01 or FHIR (Message R01 / RESTful API).

This logical model describes the common requirement for a Genomic Test Report, extended by Report Panels for each kind of individual test finding - see Report Panels below for the full list.

Although this model is genomics-specific in name, what it describes - Patient, Hospital Spell, Diagnostic Workflow and Results - is a core model for diagnostic reports generally, not something unique to genomics. The same shape applies equally to pathology, radiology and clinical referral reports; genomics is simply the domain this IG documents it against first. See Diagnostic Model Overview for the basic model this logical model adds detail to, and how it relates to Genomic Test Order on the order side.

It is not a FHIR profile and is not exchanged as is - see From Logical Model to Implementation Model below, and the Mappings tab for where each element goes in HL7 v2 ORU_R01, in this IG's FHIR profiles, and in the Genomic Test Report Questionnaire.

References

Usages:

  • This Logical Model is not used by any profiles in this Specification

You can also check for usages in the FHIR IG Statistics

Formal Views of Profile Content

Description Differentials, Snapshots, and other representations.

This structure is derived from Base

NameFlagsCard.TypeDescription & Constraints    Filter: doco
GenomicTestReport 0..* Base Genomic Test Report
Instances of this type can be the target of a Reference
GenomicTestReport.patient 1..1 BackboneElement Patient
GenomicTestReport.patient.nhsNumber 0..1 NHSIdentifier NHS Number
GenomicTestReport.patient.medicalRecordNumber 1..1 MedicalRecordNumber Hospital Number (Medical Record Number)
GenomicTestReport.hospitalSpell 0..1 BackboneElement Hospital Spell
GenomicTestReport.hospitalSpell.accountNumber 0..1 HospitalProviderSpellIdentifier Account Number (Episode or Stay Number)
GenomicTestReport.hospitalSpell.hospitalService 0..1 CodeableConcept Hospital Service
Binding: Service (extensible)
GenomicTestReport.orderNumber 0..1 OrderIdentifier Order Number (Placer)
GenomicTestReport.orderFillerNumber 0..1 Identifier Order Filler Number
GenomicTestReport.reportNumber 1..1 ReportIdentifier Report Number
GenomicTestReport.orderingFacility 0..1 OrganisationCode Referring Organisation / Ordering Facility
GenomicTestReport.testCode 1..1 CodeableConcept Test Code
Binding: Genomic Test Codes (extensible)
GenomicTestReport.geneticDiseaseAssessed 0..1 CodeableConcept Genetic disease assessed
Binding: Genomic Clinical Indication Codes (extensible)
GenomicTestReport.reportDate 1..1 dateTime Report Date
GenomicTestReport.status 1..1 code Report Status
Binding: DiagnosticReportStatus (required)
GenomicTestReport.resultsInterpreter 0..* PractitionerIdentifier Results Interpreter
GenomicTestReport.performerOperator 0..* PractitionerIdentifier Performer (Operator/Technician)
GenomicTestReport.performerOrganisation 1..* OrganisationCode Performer (Organisation)
GenomicTestReport.specimen 0..* BackboneElement Specimen/Biopsy
GenomicTestReport.specimen.identifier 0..1 Identifier Specimen ID Number
GenomicTestReport.specimen.accessionIdentifier 0..1 SpecimenAccessionNumber Lab DNA Number (if known)
GenomicTestReport.narrativeReport 0..* Attachment Narrative Report
GenomicTestReport.conclusion 0..1 string Conclusion
GenomicTestReport.outcome 0..1 CodeableConcept Outcome
Binding: Genomic Test Outcome Codes (extensible)
GenomicTestReport.result 0..* Reference(Observation) Results

doco Documentation for this format

Terminology Bindings (Differential)

Path Status Usage ValueSet Version Source
GenomicTestReport.hospitalSpell.​hospitalService Base extensible Service 📦2.2.5 This IG
GenomicTestReport.testCode Base extensible Genomic Test Codes 📦2.2.5 This IG
GenomicTestReport.geneticDiseaseAssessed Base extensible Genomic Clinical Indication Codes 📦2.2.5 This IG
GenomicTestReport.status Base required DiagnosticReportStatus 📦4.0.1 FHIR Std.
GenomicTestReport.outcome Base extensible Genomic Test Outcome Codes 📦2.2.5 This IG
NameFlagsCard.TypeDescription & Constraints    Filter: doco
GenomicTestReport 0..* Base Genomic Test Report
Instances of this type can be the target of a Reference
GenomicTestReport.patient 1..1 BackboneElement Patient
GenomicTestReport.patient.@id 0..1 string Unique id for inter-element referencing
GenomicTestReport.patient.extension 0..* Extension Additional content defined by implementations
Slice: Unordered, Open by value:url
GenomicTestReport.patient.modifierExtension This element is a modifier element. This element is included in summaries. 0..* Extension Extensions that cannot be ignored even if unrecognized
GenomicTestReport.patient.nhsNumber 0..1 NHSIdentifier The snapshot does not say whether the constraints on the root of this type profile have been applied to this element, so assume they have not. Check the type profile directly as well NHS Number
GenomicTestReport.patient.medicalRecordNumber 1..1 MedicalRecordNumber The snapshot does not say whether the constraints on the root of this type profile have been applied to this element, so assume they have not. Check the type profile directly as well Hospital Number (Medical Record Number)
GenomicTestReport.hospitalSpell 0..1 BackboneElement Hospital Spell
GenomicTestReport.hospitalSpell.@id 0..1 string Unique id for inter-element referencing
GenomicTestReport.hospitalSpell.extension 0..* Extension Additional content defined by implementations
Slice: Unordered, Open by value:url
GenomicTestReport.hospitalSpell.modifierExtension This element is a modifier element. This element is included in summaries. 0..* Extension Extensions that cannot be ignored even if unrecognized
GenomicTestReport.hospitalSpell.accountNumber 0..1 HospitalProviderSpellIdentifier The snapshot does not say whether the constraints on the root of this type profile have been applied to this element, so assume they have not. Check the type profile directly as well Account Number (Episode or Stay Number)
GenomicTestReport.hospitalSpell.hospitalService 0..1 CodeableConcept Hospital Service
Binding: Service (extensible)
GenomicTestReport.orderNumber 0..1 OrderIdentifier The snapshot does not say whether the constraints on the root of this type profile have been applied to this element, so assume they have not. Check the type profile directly as well Order Number (Placer)
GenomicTestReport.orderFillerNumber 0..1 Identifier Order Filler Number
GenomicTestReport.reportNumber 1..1 ReportIdentifier The snapshot does not say whether the constraints on the root of this type profile have been applied to this element, so assume they have not. Check the type profile directly as well Report Number
GenomicTestReport.orderingFacility 0..1 OrganisationCode The snapshot does not say whether the constraints on the root of this type profile have been applied to this element, so assume they have not. Check the type profile directly as well Referring Organisation / Ordering Facility
GenomicTestReport.testCode 1..1 CodeableConcept Test Code
Binding: Genomic Test Codes (extensible)
GenomicTestReport.geneticDiseaseAssessed 0..1 CodeableConcept Genetic disease assessed
Binding: Genomic Clinical Indication Codes (extensible)
GenomicTestReport.reportDate 1..1 dateTime Report Date
GenomicTestReport.status 1..1 code Report Status
Binding: DiagnosticReportStatus (required)
GenomicTestReport.resultsInterpreter 0..* PractitionerIdentifier The snapshot does not say whether the constraints on the root of this type profile have been applied to this element, so assume they have not. Check the type profile directly as well Results Interpreter
GenomicTestReport.performerOperator 0..* PractitionerIdentifier The snapshot does not say whether the constraints on the root of this type profile have been applied to this element, so assume they have not. Check the type profile directly as well Performer (Operator/Technician)
GenomicTestReport.performerOrganisation 1..* OrganisationCode The snapshot does not say whether the constraints on the root of this type profile have been applied to this element, so assume they have not. Check the type profile directly as well Performer (Organisation)
GenomicTestReport.specimen 0..* BackboneElement Specimen/Biopsy
GenomicTestReport.specimen.@id 0..1 string Unique id for inter-element referencing
GenomicTestReport.specimen.extension 0..* Extension Additional content defined by implementations
Slice: Unordered, Open by value:url
GenomicTestReport.specimen.modifierExtension This element is a modifier element. This element is included in summaries. 0..* Extension Extensions that cannot be ignored even if unrecognized
GenomicTestReport.specimen.identifier 0..1 Identifier Specimen ID Number
GenomicTestReport.specimen.accessionIdentifier 0..1 SpecimenAccessionNumber The snapshot does not say whether the constraints on the root of this type profile have been applied to this element, so assume they have not. Check the type profile directly as well Lab DNA Number (if known)
GenomicTestReport.narrativeReport 0..* Attachment Narrative Report
GenomicTestReport.conclusion 0..1 string Conclusion
GenomicTestReport.outcome 0..1 CodeableConcept Outcome
Binding: Genomic Test Outcome Codes (extensible)
GenomicTestReport.result 0..* Reference(Observation) Results

doco Documentation for this format

Terminology Bindings

Path Status Usage ValueSet Version Source
GenomicTestReport.hospitalSpell.​hospitalService Base extensible Service 📦2.2.5 This IG
GenomicTestReport.testCode Base extensible Genomic Test Codes 📦2.2.5 This IG
GenomicTestReport.geneticDiseaseAssessed Base extensible Genomic Clinical Indication Codes 📦2.2.5 This IG
GenomicTestReport.status Base required DiagnosticReportStatus 📦4.0.1 FHIR Std.
GenomicTestReport.outcome Base extensible Genomic Test Outcome Codes 📦2.2.5 This IG

Constraints

Id Grade Path(s) Description Expression

Differential View

This structure is derived from Base

NameFlagsCard.TypeDescription & Constraints    Filter: doco
GenomicTestReport 0..* Base Genomic Test Report
Instances of this type can be the target of a Reference
GenomicTestReport.patient 1..1 BackboneElement Patient
GenomicTestReport.patient.nhsNumber 0..1 NHSIdentifier NHS Number
GenomicTestReport.patient.medicalRecordNumber 1..1 MedicalRecordNumber Hospital Number (Medical Record Number)
GenomicTestReport.hospitalSpell 0..1 BackboneElement Hospital Spell
GenomicTestReport.hospitalSpell.accountNumber 0..1 HospitalProviderSpellIdentifier Account Number (Episode or Stay Number)
GenomicTestReport.hospitalSpell.hospitalService 0..1 CodeableConcept Hospital Service
Binding: Service (extensible)
GenomicTestReport.orderNumber 0..1 OrderIdentifier Order Number (Placer)
GenomicTestReport.orderFillerNumber 0..1 Identifier Order Filler Number
GenomicTestReport.reportNumber 1..1 ReportIdentifier Report Number
GenomicTestReport.orderingFacility 0..1 OrganisationCode Referring Organisation / Ordering Facility
GenomicTestReport.testCode 1..1 CodeableConcept Test Code
Binding: Genomic Test Codes (extensible)
GenomicTestReport.geneticDiseaseAssessed 0..1 CodeableConcept Genetic disease assessed
Binding: Genomic Clinical Indication Codes (extensible)
GenomicTestReport.reportDate 1..1 dateTime Report Date
GenomicTestReport.status 1..1 code Report Status
Binding: DiagnosticReportStatus (required)
GenomicTestReport.resultsInterpreter 0..* PractitionerIdentifier Results Interpreter
GenomicTestReport.performerOperator 0..* PractitionerIdentifier Performer (Operator/Technician)
GenomicTestReport.performerOrganisation 1..* OrganisationCode Performer (Organisation)
GenomicTestReport.specimen 0..* BackboneElement Specimen/Biopsy
GenomicTestReport.specimen.identifier 0..1 Identifier Specimen ID Number
GenomicTestReport.specimen.accessionIdentifier 0..1 SpecimenAccessionNumber Lab DNA Number (if known)
GenomicTestReport.narrativeReport 0..* Attachment Narrative Report
GenomicTestReport.conclusion 0..1 string Conclusion
GenomicTestReport.outcome 0..1 CodeableConcept Outcome
Binding: Genomic Test Outcome Codes (extensible)
GenomicTestReport.result 0..* Reference(Observation) Results

doco Documentation for this format

Terminology Bindings (Differential)

Path Status Usage ValueSet Version Source
GenomicTestReport.hospitalSpell.​hospitalService Base extensible Service 📦2.2.5 This IG
GenomicTestReport.testCode Base extensible Genomic Test Codes 📦2.2.5 This IG
GenomicTestReport.geneticDiseaseAssessed Base extensible Genomic Clinical Indication Codes 📦2.2.5 This IG
GenomicTestReport.status Base required DiagnosticReportStatus 📦4.0.1 FHIR Std.
GenomicTestReport.outcome Base extensible Genomic Test Outcome Codes 📦2.2.5 This IG

Snapshot ViewView

NameFlagsCard.TypeDescription & Constraints    Filter: doco
GenomicTestReport 0..* Base Genomic Test Report
Instances of this type can be the target of a Reference
GenomicTestReport.patient 1..1 BackboneElement Patient
GenomicTestReport.patient.@id 0..1 string Unique id for inter-element referencing
GenomicTestReport.patient.extension 0..* Extension Additional content defined by implementations
Slice: Unordered, Open by value:url
GenomicTestReport.patient.modifierExtension This element is a modifier element. This element is included in summaries. 0..* Extension Extensions that cannot be ignored even if unrecognized
GenomicTestReport.patient.nhsNumber 0..1 NHSIdentifier The snapshot does not say whether the constraints on the root of this type profile have been applied to this element, so assume they have not. Check the type profile directly as well NHS Number
GenomicTestReport.patient.medicalRecordNumber 1..1 MedicalRecordNumber The snapshot does not say whether the constraints on the root of this type profile have been applied to this element, so assume they have not. Check the type profile directly as well Hospital Number (Medical Record Number)
GenomicTestReport.hospitalSpell 0..1 BackboneElement Hospital Spell
GenomicTestReport.hospitalSpell.@id 0..1 string Unique id for inter-element referencing
GenomicTestReport.hospitalSpell.extension 0..* Extension Additional content defined by implementations
Slice: Unordered, Open by value:url
GenomicTestReport.hospitalSpell.modifierExtension This element is a modifier element. This element is included in summaries. 0..* Extension Extensions that cannot be ignored even if unrecognized
GenomicTestReport.hospitalSpell.accountNumber 0..1 HospitalProviderSpellIdentifier The snapshot does not say whether the constraints on the root of this type profile have been applied to this element, so assume they have not. Check the type profile directly as well Account Number (Episode or Stay Number)
GenomicTestReport.hospitalSpell.hospitalService 0..1 CodeableConcept Hospital Service
Binding: Service (extensible)
GenomicTestReport.orderNumber 0..1 OrderIdentifier The snapshot does not say whether the constraints on the root of this type profile have been applied to this element, so assume they have not. Check the type profile directly as well Order Number (Placer)
GenomicTestReport.orderFillerNumber 0..1 Identifier Order Filler Number
GenomicTestReport.reportNumber 1..1 ReportIdentifier The snapshot does not say whether the constraints on the root of this type profile have been applied to this element, so assume they have not. Check the type profile directly as well Report Number
GenomicTestReport.orderingFacility 0..1 OrganisationCode The snapshot does not say whether the constraints on the root of this type profile have been applied to this element, so assume they have not. Check the type profile directly as well Referring Organisation / Ordering Facility
GenomicTestReport.testCode 1..1 CodeableConcept Test Code
Binding: Genomic Test Codes (extensible)
GenomicTestReport.geneticDiseaseAssessed 0..1 CodeableConcept Genetic disease assessed
Binding: Genomic Clinical Indication Codes (extensible)
GenomicTestReport.reportDate 1..1 dateTime Report Date
GenomicTestReport.status 1..1 code Report Status
Binding: DiagnosticReportStatus (required)
GenomicTestReport.resultsInterpreter 0..* PractitionerIdentifier The snapshot does not say whether the constraints on the root of this type profile have been applied to this element, so assume they have not. Check the type profile directly as well Results Interpreter
GenomicTestReport.performerOperator 0..* PractitionerIdentifier The snapshot does not say whether the constraints on the root of this type profile have been applied to this element, so assume they have not. Check the type profile directly as well Performer (Operator/Technician)
GenomicTestReport.performerOrganisation 1..* OrganisationCode The snapshot does not say whether the constraints on the root of this type profile have been applied to this element, so assume they have not. Check the type profile directly as well Performer (Organisation)
GenomicTestReport.specimen 0..* BackboneElement Specimen/Biopsy
GenomicTestReport.specimen.@id 0..1 string Unique id for inter-element referencing
GenomicTestReport.specimen.extension 0..* Extension Additional content defined by implementations
Slice: Unordered, Open by value:url
GenomicTestReport.specimen.modifierExtension This element is a modifier element. This element is included in summaries. 0..* Extension Extensions that cannot be ignored even if unrecognized
GenomicTestReport.specimen.identifier 0..1 Identifier Specimen ID Number
GenomicTestReport.specimen.accessionIdentifier 0..1 SpecimenAccessionNumber The snapshot does not say whether the constraints on the root of this type profile have been applied to this element, so assume they have not. Check the type profile directly as well Lab DNA Number (if known)
GenomicTestReport.narrativeReport 0..* Attachment Narrative Report
GenomicTestReport.conclusion 0..1 string Conclusion
GenomicTestReport.outcome 0..1 CodeableConcept Outcome
Binding: Genomic Test Outcome Codes (extensible)
GenomicTestReport.result 0..* Reference(Observation) Results

doco Documentation for this format

Terminology Bindings

Path Status Usage ValueSet Version Source
GenomicTestReport.hospitalSpell.​hospitalService Base extensible Service 📦2.2.5 This IG
GenomicTestReport.testCode Base extensible Genomic Test Codes 📦2.2.5 This IG
GenomicTestReport.geneticDiseaseAssessed Base extensible Genomic Clinical Indication Codes 📦2.2.5 This IG
GenomicTestReport.status Base required DiagnosticReportStatus 📦4.0.1 FHIR Std.
GenomicTestReport.outcome Base extensible Genomic Test Outcome Codes 📦2.2.5 This IG

Constraints

Id Grade Path(s) Description Expression

 

Other representations of profile: CSV, Excel

Notes:

From Logical Model to Implementation Model

The logical model above is one aggregate - the report as recorded in the LIMS. For exchange it breaks down into several FHIR resources (or HL7 v2 segments), each owned by a different actor and each reusable on its own.

flowchart LR
    subgraph LM["Genomic Test Report (logical model)"]
        LP["patient"]
        LH["hospitalSpell"]
        LO["orderNumber<br/>orderFillerNumber<br/>orderingFacility"]
        LW["reportNumber, testCode,<br/>reportDate, status,<br/>conclusion, outcome"]
        LPR["resultsInterpreter<br/>performerOperator<br/>performerOrganisation"]
        LS["specimen"]
        LR["result"]
        LN["narrativeReport"]
    end

    subgraph IM["Implementation model (FHIR)"]
        PAT["Patient"]
        ENC["Encounter<br/>(Hospital Spell)"]
        SR["ServiceRequest"]
        DR["DiagnosticReport"]
        PRAC["Practitioner /<br/>Organization"]
        SPEC["Specimen"]
        OBS["Observation<br/>(Report Panels)"]
        BIN["Binary<br/>(DocumentReference)"]
    end

    LP --> PAT
    LH --> ENC
    LO --> SR
    LW --> DR
    LPR --> PRAC
    LS --> SPEC
    LR --> OBS
    LN --> BIN

    DR -. subject .-> PAT
    DR -. encounter .-> ENC
    DR -. basedOn .-> SR
    DR -. performer / resultsInterpreter .-> PRAC
    DR -. specimen .-> SPEC
    DR -. result .-> OBS
    DR -. presentedForm .-> BIN

DiagnosticReport is the root: every other resource is referenced from it, and it carries the report-level elements itself.

Logical model element(s) FHIR Profile HL7 v2 Segment Owned by
patient Patient PID Patient administration (PAS/EPR); referenced, not created, by the LIMS
hospitalSpell Hospital Spell (Encounter) PV1 Order Placer (PAS/EPR)
orderNumber, orderFillerNumber, orderingFacility ServiceRequest - see Genomic Test Order ORC Order Placer (order number); Order Filler (filler number). Absent for an unsolicited report
reportNumber, testCode, geneticDiseaseAssessed, reportDate, status, conclusion, outcome DiagnosticReport OBR, OBX Order Filler (LIMS)
resultsInterpreter, performerOperator Practitioner OBR-32/33/34 Order Filler (LIMS)
performerOrganisation Organization - Order Filler (LIMS)
specimen Specimen SPM Order Placer (specimen id); Order Filler (accession id)
result Report Panel results, e.g. Reportable Variant, Laboratory Analyte Result - see Results OBX Order Filler (LIMS)
narrativeReport Binary, via DiagnosticReport.presentedForm and DocumentReference OBX (type = ED) Order Filler (LIMS)

How the Pieces Travel

Exchange Format What is sent
HL7 v2 messaging ORU_R01 PID, PV1, ORC, OBR, OBX (including OBX type = ED for the PDF), SPM segments
FHIR Messaging FHIR Message R01 Bundle (type = message) containing MessageHeader, DiagnosticReport and the resources it references
FHIR RESTful API Health Data API / IPA/QEDm DiagnosticReport and its referenced resources, queried individually
Document sharing MHD / NHS England NRL DocumentReference pointing at the PDF (Binary), or a FHIR Document (Composition-led Bundle)

Rules

  • The Report Number (DiagnosticReport.identifier[ReportNumber], OBR-3) is present on every report, whichever format is used.
  • The Order Number is present only for a closed-loop report - see Order Reference.
  • Patient, Encounter and ServiceRequest are owned by the Order Placer; the LIMS references them, using business identifiers, rather than creating its own copies.
  • Individual test findings are never modelled inline - they are carried as separate results under DiagnosticReport.result, one Report Panel per kind of test.
  • DiagnosticReport.presentedForm and DocumentReference.content both point at the same Binary holding the PDF.
  • The Genomic Test Report Questionnaire is the form representation of this model, as recorded in the LIMS - its linkIds are listed on the Mappings tab. It is the resources above, not the Questionnaire/QuestionnaireResponse, that are exchanged.

Domain Archetype

This is a level 2 (field-level) view of the basic model introduced in Diagnostic Model Overview, showing the entities and key attributes a Genomic Test Report actually carries:

erDiagram
    Patient ||--|{ DiagnosticReport : subject
    HospitalSpell ||--o{ DiagnosticReport : encounter
    ServiceRequest |o--o{ DiagnosticReport : "basedOn (optional)"
    DiagnosticReport }o--o{ PractitionerRole : "performer / resultsInterpreter"
    PractitionerRole }o--|| Organization : organization
    DiagnosticReport ||--o{ Specimen : specimen
    DiagnosticReport ||--o{ Observation : "result (Report Panels)"
    DiagnosticReport ||--o| Binary : "presentedForm (Attachment.url)"
    DocumentReference ||--o| Binary : "content (Attachment.url)"

    Patient {
        Identifier nhsNumber
        Identifier medicalRecordNumber
    }

    HospitalSpell {
        Identifier hospitalProviderSpellIdentifier
    }

    ServiceRequest {
        Identifier orderIdentifier "Placer/Filler Order Number"
    }

    DiagnosticReport {
        Identifier reportIdentifier
        code code "Procedure/Test Code"
        dateTime effectiveDateTime "Report Date"
        code status "Report Status"
        string conclusion
        CodeableConcept conclusionCode "Outcome"
    }

    PractitionerRole {
        Identifier practitionerIdentifier
    }

    Organization {
        Identifier organisationCode
    }

    Specimen {
        Identifier specimenId
        Identifier accessionIdentifier
    }

    Observation {
        code code "Panel-specific finding"
    }

    DocumentReference {
        code type "Narrative Report"
    }

    Binary {
        code contentType
        base64Binary data
    }

ServiceRequest is shown as optional (basedOn) because it is only present for a closed-loop report - one answering a specific prior order the reporting system already knows about. An unsolicited report, produced without a matching order ever having been received, has no order to reference - see Order Reference below.

Narrative Report. The full report, as a PDF, is HL7 v2's OBX (type = ED) - see OBX (type = ED), whose own v2-to-FHIR conversion mapping is to DocumentReference. DiagnosticReport.presentedForm and DocumentReference.content are both just an Attachment with a url - in this IG, both point at the same Binary resource holding the actual PDF bytes, rather than each carrying its own separate copy. DocumentReference is the resource this content would be shared via (e.g. IHE XDS.b/MHD, or the NHS England National Record Locator), while DiagnosticReport.presentedForm is the more direct route for a system that already holds the DiagnosticReport and just wants the PDF alongside it.

Order Reference

DiagnosticReport.basedOn references the ServiceRequest (order, per Genomic Test Order) that this report answers, carried in HL7 v2 as ORC-2/ORC-3 (the orderNumber and orderFillerNumber elements).

  • Closed-loop referral: where the reporting system already holds the original order (e.g. it filled that order itself, or was told about it via a prior LAB-1), basedOn is populated and orderNumber is present.
  • Unsolicited report: ORU_R01 (and its FHIR Message equivalent) is explicitly designed to also support reporting a result for an order the receiving system never saw in the first place. In that case there is no ServiceRequest to reference, basedOn is absent, and orderNumber simply doesn't apply.

See ctDNA Management Information - How the Two Event Messages Link Together for a fuller worked explanation of solicited vs unsolicited reports in this IG.

Diagnostic Report

Unstructured and Structured Laboratory Reports

A laboratory report contains both structured and unstructured information, and they complement each other rather than replace one another.

  • Structured data consists of discrete, machine-readable elements such as the patient, specimen, request, observations (test results), identifiers, and reporting clinician. In HL7 FHIR these are represented by resources such as Patient, Specimen, ServiceRequest, Observation, Practitioner, and DiagnosticReport. In HL7 v2 these correspond to segments such as PID, SPM, ORC, OBR, and OBX.
  • Unstructured data is the human-readable laboratory report (typically a PDF) that includes the full clinical interpretation, comments, formatting, signatures, and contextual information that may not be represented as discrete data. In FHIR this is attached to the DiagnosticReport.presentedForm (or referenced via DocumentReference), while in HL7 v2 it is commonly carried in OBX segments using encapsulated data (ED).

The Laboratory Report acts as the bridge between these two worlds. It references the structured observations for computer processing, clinical decision support, analytics, and interoperability, while also linking to the complete unstructured report that clinicians view as the authoritative laboratory document. This approach ensures that systems can exchange computable data without losing the rich narrative and legal record contained in the original laboratory report.

Laboratory Report with FHIR and V2 Mappings

Genomic Report Page 1

Genomic Report Page 1

Laboratory Report with detailed FHIR Mappings

Genomic Report Page 1

FHIR Document / Clinical Document Architecture

The FHIR DiagnosticReport illustrated above is well suited to workflow-based information exchange, where structured clinical data is exchanged between systems and individual observations can be processed, queried, and acted upon. However, it may be less suitable for document sharing use cases, such as IHE XDS/MHD or the NHS England National Record Locator (NRL), where the laboratory report is exchanged as a complete clinical document. In these scenarios, the preferred approach is a FHIR Document (the FHIR equivalent of a Clinical Document Architecture (CDA) document), which packages the report into a self-contained, attested document with a Composition resource as its root. This preserves the report as a legal and clinical record while still allowing structured data to be included.

Further details are available in the Document Perspective section of the HL7 Europe Laboratory Implementation Guide: HL7 Europe Laboratory Report

NW Genomics example FHIR Document - Genomic Report

Laboratory Report with FHIR Composition Mappings

Genomic Report Page 1

Results

The result element (DiagnosticReport.result) is where the individual findings of a test live. This is specific to genomics and focused on the requirements of general clinicians, not genomic specialists, so this section will tend to be an extract of the wider Genomics Reporting Implementation Guide rather than a complete restatement of it. It divides into two parts:

  • Report Panels - the computable data models (FHIR Questionnaires) this IG has built for specific kinds of result, each derivedFrom/extended from the Genomic Test Report Questionnaire the same way Ask At Order Entry Questionnaires extend the Genomic Test Order Questionnaire.
  • Genomic Results - the underlying HL7 FHIR Genomics Reporting profiles and resources those panels (and this IG's other genomic content) are built from. Some of these are also modelled as a Report Panel Questionnaire above - where that's the case, the table below says so rather than repeating the same content twice.
flowchart LR
    CORE["Common Core<br/>Genomic Test Report"]
    PANEL["+ Report Panel Questionnaire<br/>(varies by result type - e.g. Reportable<br/>Variant, BCR-ABL Monitoring, Chimerism Testing)"]
    RESULTS["+ Genomic Results<br/>(e.g. Reportable Variant, Laboratory Analyte<br/>Result, Diagnostic Implication)"]
    QNAIRE["Report as recorded in LIMS<br/>(NW Genomics)"]
    MSG["HL7 v2 ORU_R01<br/>or FHIR Message R01"]
    EPR["EPR<br/>(NHS Trust)"]

    CORE --> QNAIRE
    PANEL --> QNAIRE
    RESULTS --> QNAIRE
    QNAIRE -->|"report issued"| MSG
    MSG --> EPR

The common core, whichever Report Panel applies, and the actual Genomic Results it carries together are the report as recorded inside the LIMS. HL7 v2 ORU_R01/FHIR Message R01 is a different thing: the wire format that same report is sent onward to an EPR in, once it's issued - not the record the LIMS itself holds. Report Panels and Genomic Results are what vary between result types; the message shape they end up populating downstream does not - the mirror image of Genomic Test Order's Ask At Order Entry Questions/OML_O21/FHIR Message O21 pattern on the order side.

This logical model only models the report-level metadata common to every report (patient, order/report identifiers, dates, status, conclusion, performers) - its result element deliberately doesn't model individual test findings inline. Instead, each individual result is carried under DiagnosticReport.result as a separate, panel-specific Questionnaire, one per kind of test - each documenting the discrete fields a particular result type needs (see How To Engineer (scale and deliver) Interoperability).

Report Panels

Report Panel Questionnaire Code Used In Status
Reportable Variant Result Panel LOINC 81250-3 "Discrete genetic variant panel" OMICS DSS Result Integration Grounded in real Variant examples
BCR-ABL Monitoring Result Panel LOINC 69380-4 "BCR-ABL1 fusion transcript … [# Ratio] … (International Scale)" BCR-ABL Monitoring Grounded in real Observation examples
Chimerism Testing Result Panel Local code (STR-based chimerism testing) Histocompatibility and Immunogenetics Candidate mapping, not yet confirmed against a real example - see the Questionnaire's own description

New result types should follow this pattern - add a new panel Questionnaire (rather than extending this common core), and list it in the table above.

Genomic Results

classDiagram
    class GenomicReport["Genomic Laboratory Report (result)"]
    class Variant
    class GenomicStudy["Genomic Study"]
    class DiagnosticImplication["Diagnostic Implication"]
    class TherapeuticImplication["Therapeutic Implication"]
    class GenomicStudyAnalysis["Genomic Study Analysis"]

    Variant --|> GenomicReport 
    GenomicStudy --|> GenomicReport
    GenomicStudyAnalysis --|> GenomicReport
    DiagnosticImplication --|> GenomicReport
    TherapeuticImplication ..|> GenomicReport
    Variant <|--|> DiagnosticImplication
    Variant <|..|> TherapeuticImplication

The underlying HL7 FHIR profiles/resources this IG's genomic results are built from - either directly, or (where noted) via one of the Report Panels above:

Genomic Result Code Used In Report Panel
Genomic Study (Procedure) - description - Examples below (Lynch syndrome, cystic fibrosis carrier) (none yet)
Genomic Study Analysis (extension on Genomic Study) LOINC 48002-0 "Genomic source class [Type]" Not yet confirmed against a real example (none yet)
Laboratory Analyte Result (Observation) - BCR-ABL Monitoring BCR-ABL Monitoring Result Panel
Reportable Variant (Observation) LOINC 48018-6 "Gene studied [ID]" (component) OMICS DSS Result Integration Reportable Variant Result Panel
Molecular Consequence (Observation) Sequence Ontology (functional-effect), e.g. SO_0001786 loss_of_heterozygosity OMICS DSS Result Integration - see Outstanding Issues for why Loss of Heterozygosity is modelled this way Reportable Variant Result Panel
Diagnostic Implication (Observation) - description - Examples below (Lynch syndrome, cystic fibrosis carrier) (none yet)
Histocompatibility and Immunogenetic Reporting - Histocompatibility and Immunogenetics Chimerism Testing Result Panel (candidate mapping by analogy, not confirmed - see the Questionnaire's own description)
Cytogenetic Genomic Report (this IG's own future/proposed model - no balloted HL7 profile exists yet) LOINC cytogenetics panels, e.g. 62389-2 (master panel), 62356-1 (ISCN), 62367-8 (FISH) Haemato-Oncology Diagnostic Pathway - Future genomic data model (proposed) (none yet - proposed direction only)

Examples

Inherited MMR deficiency (Lynch syndrome) - R210

HL7 LRI (Ref A) Example 2 (5.9.1.2) - FOUND DISCRETE – TARGETED MUTATIONS ANALYSIS THAT STUDIES MANY MUTATIONS (106)

Primary or Secondary Care Examples
Genetic Counseling Examples

Cystic fibrosis Carrier R184

HL7 LRI (Ref A) Example 3 (5.9.1.3) - SIMPLE VARIANT – MUTATION ANALYSIS WITH SEQUENCE PLUS DELETION-DUPLICATION STUDY