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

Use Case: OMICS DSS Result Integration

DSS and iGene Integration Overview.

References

1. HL7 Genomic Reporting standard
2. StarLIMS / iGene Integration - the work order metadata export pattern this mirrors
3. HL7 Lab Results Interface (LRI), Release 1 from May 2017 - source for the NTHL1 and CFTR variant examples the Result Panel below is partly built from
4. iGene Custom Fields Master Dataset - Updated 13-Aug-26.xlsx, "Variant Level Data" sheet (internal iGene specification document, not publicly linked) - the original iGene field spec and LOINC crosswalk the Result Panel below is otherwise built from

Clinical Pathway Overview

What is being tested

This use case isn't a specific clinical test in its own right - it's the pipeline that turns a genomic laboratory's raw molecular testing output (from a satellite LIMS, "DLIMS") into the structured, reportable genomic variants used in a patient's genomic report. Any DLIMS-processed molecular/NGS test - for example a cancer or rare disease gene panel - uses this same pattern.

The end-to-end clinical journey

1. Work order created - iGene generates a work order for a specific molecular test as part of processing a patient's sample.
2. Test performed - DLIMS carries out the test against the work order.
3. Bioinformatics processing - Omics DSS processes the DLIMS output into discrete, reportable variants, linked back to the originating work order.
4. Report compiled - iGene incorporates the reportable variants into the patient's genomic report.
5. Clinical decision - the reporting clinical scientist/clinician reviews the reportable variants to interpret and finalise the report for the referring clinician.

flowchart LR
    A[Work order created<br/>in iGene] --> B[Test performed<br/>by DLIMS]
    B --> C[Bioinformatics<br/>processing - Omics DSS]
    C --> D[Reportable variants<br/>compiled into report]
    D --> E[Clinical scientist<br/>reviews and finalises]

Why this matters for developers

• Reportable variants follow the HL7 Genomics Reporting IG's discrete Observation pattern - not a single free-text result - see Variant (Reportable Variant).
• The FHIR Repository is the intermediate handoff point between Omics DSS and iGene - Omics DSS doesn't write results back to iGene directly, see Future Process below.

Actors

Transactions

Current Process

The current process works as follows:

1. A work order is created in iGene (for DLIMS)
2. Once the test in DLIMS is complete, the results are sent to Omics DSS
3. Omics DSS processes the results
4. The processed output is sent to iGene

    flowchart TD
        OP["Order Placer<br/>Test Ordering Entity"]
        OF["Order Filler<br/>iGene"]
        SC["Sub Contractor<br/>DLIMS"]
        ANP["Automation Manager<br/>Analyser and<br/>Analytics Processor"]

        OP -- "LAB-1<br/>laboratory order" --> OF
    
        OF -- "LAB-3<br/>laboratory report" --> OP
        OF -- "LAB-4<br/>Work Order" --> SC
        SC -- "Result Metadata" --> ANP
        ANP -- "LAB-5<br/>Test Result and Reportable Variant" --> OF

The diagram above shows the entire background process end-to-end - Order Placer through to Automation Manager - for context only. The interaction this page actually elaborates is LAB-5 (the test result/reportable variant leg); everything else, including LAB-4 (the Work Order sent to DLIMS), is background. LAB-4 is drawn here as a simple arrow, but today it isn't actually delivered to Omics DSS at all - that gap is exactly what Future Process below, and Outstanding Issues item 3 in particular, are looking at methods of solving, rather than something already resolved by this Current Process diagram.

Future Process

Rather than sending processed output directly to iGene, it will instead be converted to a FHIR Genomics Report and stored in the FHIR Repository, following the HL7 Genomic Reporting standard. The Regional Integration Engine will then transform this data into a format suitable for iGene (likely a CSV file).

For this to work, the DLIMS work order will be exported to the FHIR Repository — mirroring the process already used for StarLIMS — so a copy of the work order is held there. Omics DSS will then access the work order metadata via the FHIR Repository, so results can be correctly linked back to the originating work order.

flowchart TD
    A[iGene: Work Order Created] -->|for DLIMS| B[DLIMS: Test Performed]
    A -.->|<b>Proposed process</b><br/>DLIMS Work Order metadata export<br/>same process as StarLIMS| F

    B -->|Test Data| C[Omics DSS]
    B -->|<b>Proposed solution to #3</b><br/>Laboratory Results ORU_R01 or equivalent| F
    C -->|Processes Results,<br/>linked to Work Order metadata| D[Processed Output]
    F -.->|<b>Proposed process</b><br/>Omics DSS reads<br/>Work Order metadata| C

    D -.->|Current process<br/>direct send - being replaced| G[iGene]

    D -->|<b>Proposed process</b><br/>Convert to FHIR Genomics Report and link to the Work Order| F[(FHIR Repository<br/>HL7 Genomic Reporting standard)]
    F -->|Results + linked Work Order metadata| E[Regional Integration Engine]
    E -->|Transforms to CSV| G

    style F fill:#e8f4fd,stroke:#1c7ed6,stroke-width:2px
    style E fill:#fff3bf,stroke:#f08c00,stroke-width:2px
    style D fill:#f8f9fa,stroke:#868e96

Detailed Process Flow

1. iGene exports work orders for DLIMS - this export does not go to DLIMS directly.
2. The RIE imports the file and stores it in the FHIR Repository.
3. Once the results have been produced by DLIMS, Omics DSS processes the output. a. In addition DLIMS may also send out Laboratory Reports. This likely holds the metadata we need to solve Outstanding Issues #3 below
4. This output is converted to a FHIR Genomic Report.
5. These resources are matched with the DLIMS work order stored in the FHIR Repository, and a FHIR Message R01 (Test Result) is produced.
6. This is either stored directly in the FHIR Repository, or sent to the Regional Integration Engine.
7. The RIE will then convert this into a CSV file to be imported into iGene LIMS.

sequenceDiagram
    participant iGene as iGene<br/>Order Filler
    participant RIE as Regional Integration Engine (RIE)<br/>Intermediary
    participant FHIRRepo as FHIR Repository<br/>Resource Access Provider
    participant DLIMS as DLIMS<br/>Automation Manager
    participant DSS as Omics DSS<br/>Automation Manager

    note over iGene, FHIRRepo: Work Order
    iGene ->> RIE: 1. Export Work Order for DLIMS<br/>(does not go to DLIMS directly)
    RIE ->> FHIRRepo: 2. Import and store Work Order
    Note over DLIMS: Test performed
    DLIMS ->> DSS: 3. Test output
    DSS ->> DSS: 3a. Process test output
    Note over iGene,DSS: Test Result
    DSS ->> DSS: 4. Convert to FHIR Genomic Report
    DSS ->> FHIRRepo: Retrieve linked DLIMS Work Order
    FHIRRepo -->> DSS: DLIMS Work Order
    DSS ->> DSS: 5. Match to Work Order,<br/>produce FHIR Message R01 (Test Result)
    alt Stored directly
        DSS ->> FHIRRepo: 6. Store FHIR Resources
        RIE ->> FHIRRepo: 6a. Poll for Test Result
    else Sent to RIE
        DSS ->> RIE: 6. FHIR Message R01
    end    
    RIE ->> RIE: 7. Convert to CSV
    RIE ->> iGene: Import CSV

Data Models

• ServiceRequest (Work Order) - the DLIMS work order exported to the FHIR Repository
• DiagnosticReport - the FHIR Genomics Report Omics DSS produces
• Variant (Reportable Variant) - the discrete result Observations, following the HL7 Genomics Reporting IG
• Molecular Consequence - a separate derivedFrom Observation for a variant's downstream effect, including Loss of Heterozygosity - see Outstanding Issues below

In everyday terms: the work order above leads to a specimen and a report, and the report is the hub everything else hangs off - it's the one resource that both the work order/specimen side and the variant results side both relate back to. The patient sits behind all five resources as their common subject, rather than only being reachable via the work order. Each entity below is also tagged with which of the two feeds actually populates it - see Current Process and Future Process above for the two-stage flow this reflects: Patient/ServiceRequest/Specimen arrive first, in the Work Order CSV export from iGene; DiagnosticReport/Variant/Molecular Consequence are added later, once DLIMS testing is complete and Omics DSS converts its output into the Test Result (a FHIR Genomic Report matched back to that same work order).

erDiagram
    PATIENT ||--o{ SERVICE_REQUEST : "subject"
    PATIENT ||--o{ SPECIMEN : "subject"
    PATIENT ||--o{ DIAGNOSTIC_REPORT : "subject"
    PATIENT ||--o{ VARIANT : "subject"
    PATIENT ||--o{ MOLECULAR_CONSEQUENCE : "subject"
    SERVICE_REQUEST ||--o{ SPECIMEN : "requests collection of"
    SERVICE_REQUEST ||--o{ DIAGNOSTIC_REPORT : "is basis for"
    SPECIMEN ||--o{ DIAGNOSTIC_REPORT : "is basis for"
    DIAGNOSTIC_REPORT ||--o{ VARIANT : "result - SEQV/ICNV/MCNV/SV"
    DIAGNOSTIC_REPORT ||--o{ MOLECULAR_CONSEQUENCE : "result - LOH"
    VARIANT ||--o| MOLECULAR_CONSEQUENCE : "derivedFrom - accompanying LOH finding"

    PATIENT {
        string Source "Work Order - iGene CSV export"
        string NHS_Number
        string Medical_Record_Number
    }
    SERVICE_REQUEST {
        string Source "Work Order - iGene CSV export"
        string Placer_Order_Number
        string Filler_Order_Number
        string Requested_Procedure_Code "NGTD Test Code"
    }
    SPECIMEN {
        string Source "Work Order - iGene CSV export"
        string Specimen_Accession_Identifier
        string Specimen_Type
        string Specimen_Taken_DateTime
    }
    DIAGNOSTIC_REPORT {
        string Source "Test Result - Omics DSS FHIR Genomic Report"
        string Report_Identifier
        string Status
        string Conclusion
    }
    VARIANT {
        string Source "Test Result - Omics DSS FHIR Genomic Report"
        string Variant_Category "iGene type - SEQV/ICNV/MCNV/SV, LRI B.1"
        string Gene_Studied
        string DNA_Change_cHGVS
        string Classification
    }
    MOLECULAR_CONSEQUENCE {
        string Source "Test Result - Omics DSS FHIR Genomic Report"
        string Gene "iGene type - LOH"
        string LOH_State
    }

DiagnosticReport.result is annotated above with the specific iGene variant type(s) each relationship carries, since that's what ultimately decides which of the five iGene variant types a result becomes when converted to the flat CSV shape in Mapping to the iGene CSV below:

• Four of the five - Sequence Variant (SEQV), Intragenic CNV (ICNV), Multigenic CNV (MCNV) and Structural Variant (SV) - are Variant Observations referenced directly from DiagnosticReport.result, distinguished from one another by the coded Variant Category component (LRI row B.1).
• The fifth, Loss of Heterozygosity (LOH), is a Molecular Consequence Observation rather than a Variant - also referenced from DiagnosticReport.result in its own right, and derivedFrom the Variant it accompanies (see iGene Variant Types above for why LOH doesn't fit the Variant shape the other four share).

Work Order CSV from iGene

The proposed DLIMS work order metadata export (see Future Process above, "mirroring the process already used for StarLIMS") is expected to reuse the same CSV shape as iGene's existing StarLIMS work order export - see StarLIMS / iGene Integration - Work Order CSV Export from iGene for the canonical version of this table (kept there to avoid the two drifting apart) and StarLIMSSampleData.csv for an example file. DLIMS/Omics DSS work orders carry the same underlying order/patient/specimen data as a StarLIMS work order, just a different downstream processor:

TestAccessionIdentifier, and the PLAC/FILL split on PlacerOrderNumber/ FillerOrderNumber, are not yet confirmed against a published identifier system - see the Questionnaire's own item design notes for detail.

Test Result

iGene Variant Types

iGene's own custom field spec (see References) splits reportable variants into five types, each with its own repeating set of custom fields - SEQV1-SEQV10 (Sequence Variant), ICNV1-ICNV3 (Intragenic Copy Number Variant), MCNV1-MCNV3 (Multigenic Copy Number Variant), SV1-SV3 (Structural Variant) and LOH1-LOH2 (Loss of Heterozygosity). These are different kinds of genomic change that can all appear on the same report - not different tests - which is why iGene buckets them into separate repeating slots rather than one flat list.

• Sequence Variant (SEQV) - a small change at a specific point in a gene: substitution, insertion, deletion, indel. Anchored to a transcript, e.g. BRCA1 c.68_69del - the "classic point mutation."
• Intragenic CNV (ICNV) - a copy-number change (usually a loss) still contained within one gene - e.g. deletion of exons 13-15 of FBN1. Still gene/transcript- anchored (its Description field combines transcript+gene+HGVS, the same shape as SEQV), but describes exon-level gain/loss rather than a single base change.
• Multigenic CNV (MCNV) - a copy-number change spanning a larger region covering multiple genes or a chromosome band, e.g. loss of Xq22.1-q28. No longer anchored to one gene, so its Description field is just the cytogenetic location, not a transcript+HGVS string.
• Structural Variant (SV) - large-scale rearrangements (translocations, inversions, complex events) that aren't necessarily a simple copy-number gain/loss
  • could be balanced. iGene gives it only one free-text HGVS-style field and drops the Inheritance field entirely (parent-of-origin isn't typically assessed for these).
• Loss of Heterozygosity (LOH) - not really a "variant" in the same sense at all: it's a state where one parental copy of a region is lost or indistinguishable from the other, often reported in cancer alongside a point mutation on the other allele (a classic "two-hit" tumour-suppressor finding). That's why it's the odd one out with only 2 fields (Gene(s), and a yes/no-ish LOH flag) rather than the usual 7
  • and why this IG models it as a separate Molecular Consequence Observation, derivedFrom the variant it accompanies, rather than folding it into Variant itself - see Outstanding Issues below.

How they interrelate:

• They are not mutually exclusive - a single report commonly carries findings from more than one type at once (e.g. one SEQV plus LOH at the same locus).
• They form a rough scale of scope: SEQV (single base/small indel) → ICNV (whole gene, exon-level) → MCNV (multiple genes/chromosome band) → SV (large rearrangement, not necessarily copy-number). LOH sits outside that scale entirely.
• They share the same 7-field shape (Description/State/Inheritance/Level/ Genomic_coordinates/Classification/Evidence) because iGene applies one generic reporting workflow to all of them - what narrows as scope widens is what goes into the Description field.
• Crucially, neither LRI nor the international FHIR Variant profile treats these as five separate things at all - they are all just the same single Discrete Variant Panel/Observation, distinguished only by which components happen to be populated (an SV row has ref/alt allele and DNA change type but no allelic state; an MCNV row has cytogenetic location but no gene). iGene is the only place that formally splits them into five field-groups - the tension this raises with LRI/FHIR is captured in Outstanding Issues below. LOH is the sharpest case, since it has no home in either standard at all.

Result Panel

The HL7 LRI already defines a single Discrete Variant Panel (LOINC 81250-3, LRI Chapter 5 Table 5-2, plus the Structural Variant Addenda in Table 5-3) covering both simple and structural variants - the same panel the NTHL1 and CFTR examples are based on. Rather than iGene's separate per-variant-type field sets, the Result Panel Questionnaire is structured around this one LRI panel, with each item mapped to its LRI OBX row, its component in the HL7 Genomics Reporting IG's Variant profile, and the iGene field it rolls up into. Only elements genuinely populated by at least one current example are modelled - see Result Panel: Elements Not Included below for the rest.

All example values below are taken from a single variant - the small-variant Observation (ctdna9737383222-seqv1, a BRCA1 deletion) in Bundle-ctdna9737383222-testresults - so they show one coherent, real result rather than a patchwork from different examples. Rows marked N/A are structural/CNV-specific and don't apply to this simple variant; see the mapping table's own examples for the intragenic-CNV, multi-gene-CNV and structural-variant Observations in the same Bundle if a worked CNV/SV example is needed.

Three gaps are not yet resolved:

• Loss of Heterozygosity is one of iGene's five variant types, but has no corresponding row anywhere in LRI's Discrete Variant Panel - LRI's closest concept, Allelic State (B.23), has no LOH answer option. No current FHIR example produces LOH data either.
• Coordinate System [Type] (92822-6) and Origin of Germline Genetic Variant [Type] (94186-4), both used by the ctDNA Bundle examples (and mapped to the FHIR profile's coordinate-system and variant-inheritance slices respectively), have no row in LRI's Discrete Variant Panel. LRI's closest concept to the latter is Allelic Phase (82120-7, row B.26) - a different LOINC code whose answer list happens to include Maternal/Paternal among several "set of variants in cis" options, not a dedicated parent-of-origin field.
• Structural Variant: iGene expects a single 81262-8 "Complex variant HGVS name" field (itself an LRI Complex Variant Panel code, row C.2 - not part of the Discrete Variant Panel at all), but the ctDNA Bundle's structural-variant Observation instead uses several Discrete Variant Panel components (B.9, B.11, B.13, B.7, B.10) - no example yet confirms how these decompose into, or recombine into, 81262-8.

Result Panel: Elements Not Included

LRI's Discrete Variant Panel (Table 5-2/5-3) defines further rows, and the HL7 Genomics Reporting Variant profile defines further component slices, that neither iGene's own field spec nor any current example populates - these are deliberately left out of the Result Panel above, since they aren't needed for the iGene feed today:

If a future DLIMS/Omics DSS feed starts populating any of these (for example, read depth or a repeat-expansion result), or iGene's own spec adds a discrete field for one, the corresponding item should move up into the Result Panel above, following the same "only what is currently used" rule.

Mapping to the iGene CSV

The Result Panel above describes the discrete variant shape on the FHIR side - one Observation per variant, repeated as many times as needed. iGene's own import is expected to be a flat CSV file, not a repeating FHIR-style structure: iGene's "Variant Level Data" spec names each field with a fixed slot prefix (SEQV1_… SEQV10_, ICNV1_…ICNV3_, MCNV1_…MCNV3_, SV1_…SV3_, LOH1_, LOH2_), which reads as one row per report/order with up to 21 variants' worth of columns (10 + 3 + 3 + 3 + 2), rather than one row per variant.

Converting the Result Panel's repeating Discrete Variant Panel Observations into that flat shape means the RIE (or whatever produces the CSV) must, for each DiagnosticReport:

1. Classify each Variant Observation by type, using the coded Variant Category component (LRI row B.1, 83005-9, bound to IGeneVariantCategory - see Outstanding Issues above) directly into iGene's Sequence Variant / Intragenic CNV / Multigenic CNV / Structural Variant bucket. Every current Variant example now populates this, so classification is an explicit, coded value rather than an inference from which other components happen to be populated.
2. Assign a slot number within that type, in order (first Sequence Variant found becomes SEQV1, second becomes SEQV2, and so on).
3. Populate that slot's seven flat columns (Description, State, Inheritance, Level, Genomic_coordinates, Classification, Evidence - or just Description/ State for LOH) from the Result Panel items, per the mapping table above - for example, SEQV1_Description is the concatenation of that variant's Transcript Reference Sequence (B.4), Gene Studied (B.3), DNA Change c.HGVS (B.5) and Amino Acid Change p.HGVS (B.6).

This raises two open questions, neither resolved by any current example:

• Slot capacity: iGene has a fixed maximum per type (10 Sequence Variants, 3 of each CNV type, 3 Structural Variants, 2 LOH results). A report with more variants of one type than iGene has slots for cannot be fully represented in the CSV as currently specified.
• Slot ordering: iGene's spec doesn't state what determines slot order (e.g. SEQV1 vs SEQV2) when a report has more than one variant of the same type - candidates include order of detection, clinical significance, or allelic frequency, but none is confirmed.

Outstanding Issues

1. Should the Variant profile and Result Panel be restructured around iGene's own five variant-type categories (Sequence Variant / Intragenic CNV / Multigenic CNV / Structural Variant / Loss of Heterozygosity), rather than the current single generic Discrete Variant Panel that mirrors LRI? Partially decided: rather than a full restructure into five separate profiles/panels (which would diverge from both LRI's Discrete Variant Panel and the international HL7 Genomics Reporting Variant profile, both of which treat simple and structural variants, and implicitly CNVs, as one panel distinguished by which components are populated), this IG adds a coded Variant Category component (LRI row B.1, LOINC 83005-9) to Variant, bound to a new IGeneVariantCategory CodeSystem/value set (SEQV/ICNV/MCNV/SV/LOH) - an IG-specific extension of LRI's own answer list for that row, which only distinguishes Simple Variant vs Structural Variant. This makes "which iGene slot type is this" an explicit, coded value on the single panel, addressing the CSV mapping ambiguity above without a structural profile split - see every current Variant example, which now populates it. See item 2 below for the separate Loss of Heterozygosity decision.

2. Decided: Loss of Heterozygosity is modelled as a separate Molecular Consequence Observation, not as a component (or extension) on Variant itself. This follows the HL7 Genomics Reporting IG's own Molecular Consequence profile: a derivedFrom reference back to the Variant it is the consequence of, with a functional-effect component coded from Sequence Ontology (SO_0001786 loss_of_heterozygosity, among other possible values such as loss/gain of function) - see Molecular Consequence - Loss of Heterozygosity (BRCA1) for a worked example, representing the classic germline-mutation-plus-somatic-LOH "two-hit" finding at the same locus as Variant - ctDNA Small Variant (BRCA1). This fits the case where LOH is the consequence of an already-reported variant cleanly, but doesn't fit iGene's broader usage, which allows LOH to be reported standalone for a gene/region with no companion variant required - that gap remains open.

3. The Data Model doesn't yet capture how a DSS result gets matched back to the correct iGene Test ID - needed to look up (and populate) iGene's own test-level custom fields (see iGene Variant Types above) from a DSS-produced result. Omics DSS itself only holds the DLIMS Lab Number, patient name and worksheet - it doesn't currently hold enough patient-identifiable information to look the patient up in iGene directly (there's no NHS Number held in DSS). The workaround in use today is a multi-step manual/semi-manual lookup:

   1. Look up the iGene referral number from DLIMS, using the DLIMS Lab Number.
   2. Use that referral number (which may or may not be the referral for the current test) to look up the patient in iGene's Patient/PatientDetails tables.
   3. Use that patient ID to list every test linked to the patient - if the correct one can't be determined automatically, this is where human interaction is currently needed to select it.
   4. Once the correct Test ID is confirmed, use it to look up (and populate) iGene's test-level custom fields.

   Proposed direction (not yet decided or reflected in the Data Models erDiagram above): carry the DLIMS Lab Number itself into the Data Model, most naturally as an identifier on Specimen rather than Patient or ServiceRequest - since a single patient can have multiple specimens/samples, Specimen is the level a lab-assigned sample number actually belongs at. That would let a DSS result be linked back to the correct specimen (and from there, order and report) directly from data already available to DSS, rather than through the referral-number/patient-lookup chain above.

   As a potential second, complementary solution: have DLIMS send its lab report through the Regional Integration Engine (RIE), the same route the Work Order already travels (see Future Process above), rather than relying on the lookup chain above at all. The RIE already holds a copy of the Work Order once iGene exports it, keyed by identifiers iGene itself assigned; if that Work Order also carries the DLIMS Lab Number (per the first proposed direction above), the RIE could match a DLIMS-originated report straight back to the correct Work Order/Test ID itself - without Omics DSS needing to hold, or reconstruct via iGene's Patient/PatientDetails tables, any patient-identifiable information at all. This would need to sit alongside, not replace, the Omics DSS-produced FHIR Genomic Report already described in Future Process - DLIMS's own report would need to be reconciled with (or feed into) that same report, not run as a second, independent path to iGene. This is one option, not a decided design - the options for resolving this linkage still need to be identified and compared before one is chosen.

   A third, longer-term possibility: Clarity LIMS, proposed to eventually replace both DLIMS and Omics DSS, may resolve this linkage problem differently again - as a full LIMS rather than a downstream processing layer, it would be expected to hold proper sample/patient tracking natively, potentially removing the need for the referral-number/patient-lookup chain (or a DLIMS Lab Number-on-Specimen workaround) altogether. Not yet confirmed - see Clarity LIMS - Outstanding Issues.

Examples

The four Variant Observations inside that Bundle are also extracted as standalone Variant examples, for individual reference:

Security Considerations

Includes:

• OAuth2 Standard for Authorisation
  • including use of JWT access tokens and future support for SMART-on-FHIR Scopes
• FHIR AuditEvent/IHE BALP for Audit Logging
• TLS for Transport Security/Encryption

Developer Guides

• 02 - Work Orders: A Worked Example - retrieving the DLIMS Work Orders from the FHIR Repository, the metadata Omics DSS links its results back to
• 05 - Test Results: GA4GH VCF to FHIR Genomics Reporting - converts a GA4GH VCF file into discrete variant Observations conforming to the HL7 Genomics Reporting IG, plus an NW-GMSA R01 Test Results message

See Developer Guides for the full notebook series.