Non-WGS Test Request - Rare Disease

The National Genomics Test Directory specifies available tests and eligibility criteria. Testing within genomics goes beyond cradle to grave. Genomic testing may occur on fetuses, patients who are alive, their family members or patients who are deceased. Any electronic test ordering system SHALL have the ability to communicate with the national Patient Demographic Service (PDS), provide the ability to place test requests for both patients who are alive or deceased and enable the receipt of the test request by the laboratory.

A new test request may be accompanied with a request for samples. Once collected the sample and test request are sent to the Home GLH for processing. The requirement is when an electronic test request is submitted by the requester, the GLH will be notified in real time of the test request. As the sample may be collected later, the requirement is that the lab involved in collecting the sample provide an update of the sample sent and once the sample arrives at the GLH, the status of sample received is provided.

The following steps is a walk through of a Non-WGS Test order workflow:

Link to the High Fidelity Wireframe for the Non WGS Rare Disease Test Scenario

1. Requester searching for a patient (a dummy patient has been pre-populated as an example) - Via PDS GET /Patient request

Parameters:

given=Meir
family=Lieberman
birthdate=eq2005-12-19

Response:

Patient-MeirLiebermanPDS-Example

2. Requester selects a Non WGS Rare Disease Test Order Form - UI Only

Represented in ServiceRequest via ServiceRequest.category:

{
    "system":"https://fhir.hl7.org.uk/CodeSystem/UKCore-GenomeSequencingCategory",
    "value":"rare-disease-non-wgs",
    "display":"Rare Disease - Non-WGS"
}

3. Requester completes the Non WGS Rare Disease Test Order Form and submits the request -

POST transaction Bundle to GMS baseURL:

Bundle-NonWGSTestOrderForm-Example

Response:

OperationOutcome with appropriate success/failure codes: OperationOutcome-SuccessfulValidation-Example

4. Requester indicates that sample is going to be collected at a later date

Indicated through absence of Specimen resource in message or absence of Specimen.collectedDateTime/Specimen.status=unavailable

The lab receives the test request and:

1. Views the completed test order form

Obtained through GET /ServiceRequest or /GET Task requests (using parameters on CapabilityStatements to filter results) for non-routed requests. (Dashboard of available requests)

OR

Obtained through GET /Task request (filtered by GLH owner) for routed requests.

Then

GET /Task by Id and referenced ServiceRequest for view of individual.

2. Accepts the test request

PUT of Task-NonWGSRareDiseaseTestOrderAccepted-Example

OR

3. Rejects the test request

PUT of Task-NonWGSRareDiseaseTestOrderRejected-Example

OR

4. Modifies the test request

PUT of ServiceRequest-SavedTestOrderUpdated-Example

View of Status History

GET /Task(s) with focus ServiceRequest for status of each task (e.g. Sample Sequencing, Interpretation etc.), subsequent call for /AuditEvent(s) with entity.what=Task for history of updates to tasks if needed (e.g. accepted, in-progress, completed)

WGS Test Request - Rare Disease

For each individual WGS Test Request ordered (includes duos/trios/larger family groups), an accompanying Record of Discussion (RoD) is a mandatory requirement to progress with the test request. NGIS requires both the completion of the test request, associated sample, and the RoD, which is first routed to the appropriate Home GLH. Currently, WGS Test Requests are manually transcribed onto an electronic form within NGIS by the GLH. Rollout of direct clinician access to NGIS remains limited.

In the future state, the electronic test request, sample, and RoD (electronic or pdf attachment) will be completed by members of the requesting team. Information may be completed at different stages and the GLH may receive the WGS test request, the sample, and the RoD at different times. The requirement is to remove the double entry of the test order and RoD into NGIS and provide the GLH with the ability to forward on all order components electronically to NGIS. The central service will indicate when each component (Test order, sample, and RoD) has been received by the GLH and once all components have been forwarded onto to GEL.

Representation of the RoD form can be through either an uploaded PDF or an electronically filled form. These SHOULD be linked through the Consent.source element. The Source element MAY either be a pointer to the location of the PDF version of the RoD, either hosted by the source/client system, accessed via NRL; or embedded within the message payload, base64 encoded (using sourceAttachment); or a reference to a QuestionnaireResponse resource (using sourceReference), if this has been collected in a structured format, using the Questionnaire-Genomic Testing RoD template.

For further details on WGS Test Requesting and RoD, refer to WGS Resources and Genomics England.

NOTE: For WGS Tumour First - Germline Late scenarios, it is expected that each would be send as in individual request (ServiceRequest), linking the 2 via basedOn, i.e. the Germline ServiceRequest would reference the Tumour ServiceRequest, via ServiceRequest.basedOn. Each ServiceRequest would reference the relevant specimen, tumour or germline.

The following steps is a walk through of a WGS Test order workflow:

Link to the High Fidelity Wireframe for the WGS Rare Disease Test Scenario

1. Requester searching for a patient (a dummy patient has been pre-populated as an example) - Via PDS GET /Patient request

Parameters:

given=Lindsay
family=Sorrell
birthdate=eq2011-04-12

Response:

Patient-LindsaySorrellPDS-Example

2. Requester selects a WGS Rare Disease Test Order Form - UI Only

Represented in ServiceRequest via ServiceRequest.category:

{
    "system":"https://fhir.hl7.org.uk/CodeSystem/UKCore-GenomeSequencingCategory",
    "value":"rare-disease-wgs",
    "display":"Rare Disease - WGS"
}

3. Requester completes the WGS Rare Disease Test Order Form and submits the request -

POST transaction Bundle to GMS baseURL:

Bundle-WGSTestOrderForm-Example

Response:

OperationOutcome with appropriate success/failure codes: OperationOutcome-SuccessfulValidation-Example

4. Requester indicates that sample is going to be collected at a later date

Indicated through absence of Specimen resource in message or absence of Specimen.collectedDateTime/Specimen.status=unavailable

5. Requester indicates that Record of Discussion is going to be collected at a later date

Indicated through absence of QuestionnaireResponse resource in message with QuestionnaireResponse.questionnaire:"https://fhir.nhs.uk/Questionnaire/NHSDigital-Questionnaire-Genomics-Example" or Consent.status:"proposed"

The lab receives the test request and:

1. Views the completed test order form

Obtained through GET /ServiceRequest or /GET Task requests (using parameters on CapabilityStatements to filter results) for non-routed requests. (Dashboard of available requests)

OR

Obtained through GET /Task request (filtered by GLH owner) for routed requests.

Then

GET /Task by Id and referenced ServiceRequest for view of individual.

2. Places the test request as awaiting further information - Record of Discussion

PUT of Task-WGSRareDiseaseTestOrderAccepted-Example

3. The lab receives the Record of Discussion, Sample and changes status from Awaiting Further Information to Accepted

POST of Bundle-WGSRoD-Example and subsequent marking of Task as accepted by Lab

4. The lab reviews the completed WGS Test Order Form, Sample and Record of Discussion and forwards the components to NGIS

PUT of Task-WGSRareDiseaseTestOrderForwarded-Example

View of Status History

GET /Task(s) with focus ServiceRequest for status of each task (e.g. Sample Sequencing, Interpretation etc.), subsequent call for /AuditEvent(s) with entity.what=Task for history of updates to tasks if needed (e.g. accepted, in-progress, completed)

Re-analysis (R387)

The National Genomic Test Directory defines the testing criteria for reanalysis as genomic data which has previously been interpreted and reported and is required due to:

• New clinical information or clinical events which would substantially change the relevant genomic target OR
• Sufficient time has passed since the initial analysis that new gene discovery will have substantially increased the relevant genomic target OR
• A technical or scientific advance requires reanalysis of a group of test to detect an important new source of actionable diagnoses.

The requirement for electronic test ordering is to consider reanalysis as a new test request (Non-WGS and WGS), in addition to the original test request, where there is no sample allocated. The new test will be based on existing sequenced data resulting in the generation of new report once the data has been re-analysed. There is a requirement to indicate the original test directory code for which reanalysis is being actioned upon as part of the electronic test request ordered and capture additional information as part of the test request.

For further details, refer to Reanalysis of genomic sequencing data for rare disease patients.

Reinterpretation/ Reanalysis Impact on WGS (NGIS- current challenge)

NGIS’s interpretation portal can only hold one single version of the analysis. This means that if a WGS test request is generated on the patient, the single current version of the analysis is held. If there is a need for secondary analysis and a subsequent test is requested, the data previously held in the interpretation portal is overwritten. The problem of overwriting the primary analysis of the original data has been raised as a clinical safety risk and is being progressed with NGIS and will remain the responsibility of NGIS to address.

From a requirements standpoint, the requester should have the ability to create a request for secondary analysis. The GLH will submit the request to NGIS in a business-as-usual capacity.

Link to the High Fidelity Wireframe for the Re-analysis Scenario

Requester:

1. Requester to create a new test request for reanlaysis

2. Requester to indicate no sample required

POST transaction Bundle to GMS baseURL:

Bundle-NonWGSTestOrderForm-Reanalysis-Example

No Sample Required indicated through test code and note on ServiceRequest.

Response:

OperationOutcome with appropriate success/failure codes: OperationOutcome-SuccessfulValidation-Example

Lab:

1. Recieve the test request for reanalysis

Obtained through GET /ServiceRequest or /GET Task requests (using parameters on CapabilityStatements to filter results) for non-routed requests. (Dashboard of available requests)

OR

Obtained through GET /Task request (filtered by GLH owner) for routed requests.

Then

GET /Task by Id and referenced ServiceRequest for view of individual.

2. Accept test request for re-analysis

PUT of Task-NonWGSRareDiseaseTestOrderAccepted-Reanalysis-Example

Requester:

1. Requester to view current status of Test Request

GET /Task(s) with focus ServiceRequest for status of each task (e.g. Sample Sequencing, Interpretation etc.), subsequent call for /AuditEvent(s) with entity.what=Task for history of updates to tasks if needed (e.g. accepted, in-progress, completed)

Non-WGS Haem-Onc Test Scenario

The Cancer test order process is equivalent for WGS and Non-WGS tests. For WGS, it is expected Tasks would be routed to GEL (or have GEL indicated as the performer on the ServiceRequest) and the ServiceRequest.category would indicate the test is a 'cancer-wgs' test as with the WGS Rare Disease scenario. All WGS tests are expected to include a RoD form: Questionnaire-Genomic Testing

For the WGS Tumour First, Germline Later use case, it is expected requesters would submit an additional ServiceRequest for the Germline Later test, using ServiceRequest.basedOn to reference the initial Tumour First test.

Link to the High Fidelity Wireframe for the Non WGS Haem-Onc Test Scenario

The following steps is a walk through of:

1. Local SIHMDS consultant to search for a patient (a dummy patient has been pre-populated as an example)

Parameters:

given=Patrick
family=Sammy
birthdate=eq1982-10-06

Response:

Patient-PatrickSammy-Example

2. SIHMDS consultant selects a Non WGS Haem Onc Test Order Form

Represented in ServiceRequest via ServiceRequest.category:

{
    "system":"https://fhir.hl7.org.uk/CodeSystem/UKCore-GenomeSequencingCategory",
    "value":"cancer-non-wgs",
    "display":"Cancer - Non-WGS"
}

3. SIHMDS consultant completes the Non WGS Haem Onc Test Order Form and submits the request

POST transaction Bundle to GMS baseURL:

Bundle consists of:

ServiceRequest-NonWGSTestOrderForm-HaemOncology-Example

PractitionerRole-HazelSmithPathology-Example

Observation-WhiteBloodCell-Example

Observation-Platelets-Example

Observation-Neutrophils-Example

Observation-Haemoglobin-Example

Observation-Bruising-Example

Condition-Hepatosplenomegaly-Example

Response:

OperationOutcome with appropriate success/failure codes: OperationOutcome-SuccessfulValidation-Example

4. SIHMDS consultant enters sample details

Post of Specimen and associated resources (can be part of initial test order bundle if known at time of order submission)

Specimen-BoneMarrowAspiration-Example

Observation-BlastPercentage-Example

Observation-NucleatedCellCount-Example

The GLH lab recieves the test request

1. Views the completed test order form

Obtained through GET /ServiceRequest or /GET Task requests (using parameters on CapabilityStatements to filter results) for non-routed requests. (Dashboard of available requests)

OR

Obtained through GET /Task request (filtered by GLH owner) for routed requests.

Then

GET /Task by Id and referenced ServiceRequest for view of individual.

2. Accepts the test request and proceeds with request

Updated ServiceRequest: ServiceRequest-NonWGSTestOrderForm-HaemOncologyUpdated-Example

PUT of Task-NonWGSRareDiseaseTestOrderAccepted-HaemOncology-Example

SIHMDS Consultant

1. View current status of test.

GET /Task(s) with focus ServiceRequest for status of each task (e.g. Sample Sequencing, Interpretation etc.), subsequent call for /AuditEvent(s) with entity.what=Task for history of updates to tasks if needed (e.g. accepted, in-progress, completed)

Note: the genomic laboratory is responsible for the generation of the genomic report. The creation of an integrated report is out of scope and will be managed as per current processes by the SIHMDS consultant

CPGC Non-WGS Solid Tumour Scenario

The Cancer test order process is equivalent for WGS and Non-WGS tests. For WGS, it is expected Tasks would be routed to GEL (or have GEL indicated as the performer on the ServiceRequest) and the ServiceRequest.category would indicate the test is a 'cancer-wgs' test as with the WGS Rare Disease scenario. All WGS tests are expected to include a RoD form: Questionnaire-Genomic Testing

For the WGS Tumour First, Germline Later use case, it is expected requesters would submit an additional ServiceRequest for the Germline Later test, using ServiceRequest.basedOn to reference the initial Tumour First test.

Link to the High Fidelity Wireframe for the CPGC Non WGS Solid Tumour Scenario

The following steps is a walk through of a Non WGS Solid Tumour Test Request. This scenario takes into considersation the set up CPGC's location as the initial point of triage and prep prior to forwarding the test request/sample to GLH.

1. Cellular Pathologist(Requester) to confirm Genomic Testing/ specimen block required.

Outside scope for central genomic order management

2. Cellular Pathologist(Requester) to search for patient (a dummy patient has been pre-populated as an example)

Parameters:

given=Zelma
family=Hadgkiss
birthdate=eq2011-03-19

Response:

Patient-ZelmaHadjkiss-Example

3. Cellular Pathologist (Requester) to indicate appropriate Test directory code/description

Code M119 selected for ServiceRequest.code

4. Cellular Pathologist (Requester) to complete (as an example)- Non WGS Cancer (Solid Tumour) form and submit request with specimen details. Please note:specimen(s) may come from another lab in the region.

POST transaction Bundle to GMS baseURL:

Bundle-NonWGSTestOrderForm-CancerSolidTumor-Example

Response:

OperationOutcome with appropriate success/failure codes: OperationOutcome-SuccessfulValidation-Example

Specimen details:

BodyStructure-BodySiteLocationLungs-Example

Observation-Cellularity-Example

Observation-Necrosis-Example

Observation-NeoplasticCell-Example

Observation-TumourType-Example

Specimen-CancerSolidTumor-Example

ServiceRequest-NonWGSTestOrderFormUpdated-SolidTumor-Example

CPGC: (Set up to manage triage and prep for all solid tumors listed on the Test Directory)

1. Recieve test request electronically (* Note a CPGC may be in the same location as the GLH or at a different location) and specimen details

Obtained through GET /ServiceRequest or /GET Task requests (using parameters on CapabilityStatements to filter results) for non-routed requests. (Dashboard of available requests)

OR

Obtained through GET /Task request (filtered by GLH owner) for routed requests.

Then

GET /Task by Id and referenced ServiceRequest for view of individual.

2. Review/ Triage test request and specimen (when delivered to location)

GET of resources linked to ServiceRequest

3. Accept Test request and complete prep if specimen/test request meets criteria

PUT of Task-NonWGSRareDiseaseTestOrderAccepted-SufficientSample-Example

Or

4. Set status to awaiting further information or Reject in the event criteria is not met

PUT of Task-NonWGSRareDiseaseTestOrderRejected-CancerSolidTumor-Example

and Task-NonWGSRareDiseaseTestOrder-InsufficientSample-Example

5. CPGC to forward (test request req details electronically) & sample to GLH once prep is complete to progress the request

PUT of Task-NonWGSRareDiseaseTestOrderForwarded-SolidTumor-Example

Fetus Management

The following scenarios have been captured to indicate various specialist testing scenarios associated with testing for either the woman or the fetus:

The requirement for electronic test order forms is to allow for configuration of specialist testing requirements and enable the management of samples associated with the fetus. Further input is required from the GMS to confirm the scenario as part of the testing phase within the Alpha.

Link to the High Fidelity Wireframe for the Fetal Scenario

The following steps is a walk through of:

1. Requester (e.g Midwife) searches for woman (a dummy patient has been pre-populated as an example)

Parameters:

given=Ryanne
family=Boulder
birthdate=eq1980-09-02

Response:

Patient-RyanneBoulder-Example

2. Requester (e.g. Midwife) to search for approrpiate specialist testing description or code

ServiceRequest.code = R21

3. Requester (e.g.Midwife) completes the Non WGS Rare Disease Test Order Form (with specialist requirement) and submit the request

POST transaction Bundle to GMS baseURL:

Bundle-NonWGSTestOrderForm-FetalScenario-Example

and subsequent POST with updated reference for Paternal Sample:

Bundle-NonWGSTestOrderFormUpdated-FetalScenario-Example

Note: The Test Order is related to Patient-FoetusOfRyanneBoulder-Example with Ryanne Boulder linked to the resource through a RelatedPerson

Response:

OperationOutcome with appropriate success/failure codes: OperationOutcome-SuccessfulValidation-Example

4. Requester indicates that sample is going to be collected at a later date

Indicated through absence of Specimen resource in message or absence of Specimen.collectedDateTime/Specimen.status=unavailable

Specific Observation, Specimen and Procedure resources related to the above request can be found on the relevant Example pages.

The lab recieves the test request and:

1. Views the completed test order form

Obtained through GET /ServiceRequest or /GET Task requests (using parameters on CapabilityStatements to filter results) for non-routed requests. (Dashboard of available requests)

OR

Obtained through GET /Task request (filtered by GLH owner) for routed requests.

Then

GET /Task by Id and referenced ServiceRequest for view of individual.

2. Accepts the test request

PUT of Task-NonWGSRareDiseaseTestOrderAccepted-FetalScenario-Example

OR

3. Rejects the test request

PUT of Task-NonWGSRareDiseaseTestOrderRejected-FetalScenario-Example

OR

4. Modifies the test request

POST of ServiceRequest-NonWGSTestOrderFormUpdated-FetalScenario-Example

and Provenance-NonWGSTestOrderForm-FetalScenario-Example

in a Transaction Bundle

Direct to Lab

The National Genomic Medicine Service is currently delivered through seven regional GLHs. The GLHs are responsible for coordinating services for their region. Currently, all tests are routed via the Home GLH from any requester (primary, secondary, or tertiary care) within the region. For some specialist tests, a requester may directly send the test request and the sample directly to the specialist lab. R14 (as test directory version 5.2, June 2023) is one such example. The requester will create and submit the test request and sample. The receiving lab (Exeter) will be immediately notified of the test request via messaging.

The sample may be received later (transport to Exeter) and will be reflected in the messaging as test received, awaiting sample. Confirmation is required from the GMS on if the Home GLH (i.e., the region in which the request was made, should be notified as cc from a monitoring perspective).

The introduction of a central service will support the routing of tests to the given lab defined within the routing tables. In the event no rule exists, the test request will be defaulted to the Home GLH.

Link to the High Fidelity Wireframe for the Direct to Lab Scenario

The following steps is a walk through of:

1. Requester searches for a patient (a dummy patient has been pre-populated as an example)

Parameters:

given=James
family=Meltcalfe
birthdate=eq2013-10-10

Response:

Patient-JamesMetcalfe-Example

2. Requester searches for appropriate code (R14- test routes directly to Exeter)

Call to Digital Test Directory (out of scope for GMS central broker)

3. Requester completes the test order form and submits the request and indicates that ROD will follow

Transaction Bundle consisting of:

Patient-JamesMetcalfe-Example

Observation-DiseasePenetrance-Example

Observation-Immunodefficiency-Example

PractitionerRole-EugeneSmith-Example

ServiceRequest-WGSTestOrderForm-DirectToLab-Example

4. Requester indicates that sample is going to be collected at a later date

Indicated through absence of Specimen resource in message or absence of Specimen.collectedDateTime/Specimen.status=unavailable

The lab (exeter) recieves the test request and:

1. Views the completed test order form

Obtained through GET /ServiceRequest or /GET Task requests (using parameters on CapabilityStatements to filter results) for non-routed requests. (Dashboard of available requests)

OR

Obtained through GET /Task request (filtered by GLH owner) for routed requests.

Then

GET /Task by Id and referenced ServiceRequest for view of individual.

2. Triages the test request as Awaiting further information (sample/ROD)

PUT of Task-WGSRareDiseaseTestOrderHold-DirectToLab-Example

1. Requesting Team completes Record of Discussion

POST of Consent, RoD and update to ServiceRequest to add supportingInfo link (in Transaction Bundle):

(note examples reference incorrect patient but structure remains the same)

Consent-RoDYoungPersonAssentFormAvailable-Example

QuestionnaireResponse-RoD-PheobeSmithamYPAForm-Example

ServiceRequest-WGSTestOrderFormUpdated-DirectToLab-Example

Provenance-WGSTestOrderForm-DirectToLab-Example

2. Lab recieves sample/ROD

POST of Specimen resources and GET from Lab

Specimen-JamesMetcalfeBloodEDTA-Example

3. Accepts the test request once sample is aligned with the test request at the lab

PUT of Task-WGSRareDiseaseTestOrderAccepted-DirectToLab-Example

1. Requester view status of test (complete)

GET /Task(s) with focus ServiceRequest for status of each task (e.g. Sample Sequencing, Interpretation etc.), subsequent call for /AuditEvent(s) with entity.what=Task for history of updates to tasks if needed (e.g. accepted, in-progress, completed)

2. Requester access PDF Report

The report will be linked as an output to the associated Task:

Task-WGSRareDiseaseTestOrderCompleted-DirectToLab-Example

For unstructured reports, minimal metadata is required in the DiagnosticReport resource:

DiagnosticReport-JamesMetcalfeGeneticReport-Example

Out of Country

In certain circumstances, genomic tests may be sent to a laboratory team outside of the UK for further analysis. One such example of a test is Oncotype DX (M3.2). Oncotype DX is currently dispatched out of the UK by courier to Genomic Health in the U.S. Currently, the oncologist partially completes the tissue requisition form prior to sending the form to the cell path department, where the requisition is married up with the breast cancer tissue block and tumour information prior to dispatching by courier to the U.S. In another scenario, (M2.5- genomic instability testing for ovarian cancer by Myriad), the local lab will collect and send the tissue to the GLH. The GLH will forward on the request and the sample and dispatch by courier to the US.

In both instances, a new test request is created and the sample along with the test request is forwarded by the Home GLH to any out of country partners.

Link to the High Fidelity Wireframe for the Out of Country Scenario

The following steps is a walk through of:

1. Requester searches for a patient (a dummy patient has been pre-populated as an example)

Parameters:

given=Kay
family=Burbridge
birthdate=eq1983-06-02

Response:

Patient-KayBurbridge-Example

2. Requester searches for Test code (for e.g. M3.2)

Call to Digital Test Directory (outside scope for GMS central broker)

3. Requester completes the test order form and submit requests to lab

POST of transaction Bundle consisting of the following resources:

BodyStructure-SpecimenBodySiteLocation-Example

Condition-BreastCancer-Example

Observation-NecrosisKayBurbridge-Example

Observation-CellularityKayBurbridge-Example

Observation-NeoplasticCellKayBurbridge-Example

Observation-TumourTypeKayBurbridge-Example

Patient-KayBurbridge-Example

ServiceRequest-NonWGSTestOrderForm-OutOfCountry-Example

Specimen-TissueResection-Example

The lab recieves the test request and:

1. Views the completed test order form

Obtained through GET /ServiceRequest or /GET Task requests (using parameters on CapabilityStatements to filter results) for non-routed requests. (Dashboard of available requests)

OR

Obtained through GET /Task request (filtered by GLH owner) for routed requests.

Then

GET /Task by Id and referenced ServiceRequest for view of individual.

2. Accepts the test request

PUT of Task with status=accepted

3. Lab indicates in LIMS that request is to be sent abroad (For e.g. Genomic Health- U.S.A)

PUT of Task-NonWGSRareDiseaseTestOrderForwarded-OutOfCountry-Example

Note: in cases where the responsible owner of a Task is not capbable of providing status updates to the broker, it is the responsibility of the referring organization to provide updates on the owners behalf and reallocate Tasks once ownership changes.

Variant Re-interpretation (R442)

The testing criteria for Variant Re-interpretation is defined in the National Genomic Test Directory as the requirement for an interpretation of a known variant to determine if the pathogenic status has changed since primary analysis and reporting or a previous re-interpretation. Re-interpretation of a variant may be performed due to:

• A request from a clinician responsible for a patient with a report variant of uncertain significance, OR
• New evidence available that will likely change the classification of a variant. For example, the identification of additional patient(s) with the same genetic variant or new functional evidence, AND
• Where either, there is new clinical information related to the patient or their family, or sufficient time has passed that there may be additional published evidence or knowledge, that could result in a change to the classification of the variant.

Variant Re-interpretation SHALL be treated as a new test request (WGS and Non-WGS) where there is no sample allocated, based on re-interpretation of existing sequenced data and the generation of a new report once re-interpretation is complete. Existing or old data SHALL NOT be lost or overwritten in the event a new there is a new re-interpretation request.

Link to the High Fidelity Wireframe for the Variant Re-interpretation Scenario

The following steps is a walk through of:

1. Requester searches for a patient (a dummy patient has been pre-populated as an example)

Parameters:

given=Salima
family=Pomfrets
birthdate=eq1993-11-27

Response:

Patient-SalimaPomfrets-Example

2. Requester searches for approrpriate test directory code R442- Variant Re-interpretation

Call to Digital Test Directory (out of scope for GMS central broker)

3. Requester completes the electronic form and submits the request

POST of ServiceRequest-NonWGSTestOrder-VariantReinterpretation-Example

Note: Supporting info can be optionally obtained from data related to the previous ServiceRequest (linked from ServiceRequest.basedOn), if unchanged.

4. Requester indicates that no sample is required.

Indicated through absence of Specimen resource in message or absence of Specimen.collectedDateTime/Specimen.status=unavailable

The lab recieves the test request and:

1. Views the completed test order form

Obtained through GET /ServiceRequest or /GET Task requests (using parameters on CapabilityStatements to filter results) for non-routed requests. (Dashboard of available requests)

OR

Obtained through GET /Task request (filtered by GLH owner) for routed requests.

Then

GET /Task by Id and referenced ServiceRequest for view of individual.

2. Accepts the test request

PUT of Task-NonWGSTestOrderAccepted-VariantReinterpretation-Example

Cascade Testing

Cascade testing may be defined as the positive result of a singleton test triggering the need for family members to be tested by a requester. For example, in the instance of Familial Hypercholesterolaemia (R134), a positive result of the test will guide the management for the patient and their family members.

Cascade Testing is recorded on a rare disease test request order as the “Reason for Testing- Carrier or Predictive/ Pre-symptomatic.” Each cascade test is treated as a new test request and will be sent to the GLH with a sample(s).

Link to the High Fidelity Wireframe for the Cascade Testing

The following steps is a walk through of:

1. Requester (Specialist Nurse) searches for a patient (a dummy patient has been pre-populated as an example)

Parameters:

given=Fay
family=Mutlow
birthdate=eq1990-06-01

Response:

Patient-FayMutlow-Example

2. Requester (Specialist Nurse) searches for appropriate description/code (For e.g. FH is used in this scenario)

ServiceRequest.code=R134

3. Requester (Specialist Nurse) completes the Non WGS Rare Disease Test Order Form. In this example, a family member is being tested due to a positive result.

POST of ServiceRequest-NonWGSTestOrderForm-CascadeTesting-Example

Linked to previous ServiceRequest through ServiceRequest.basedOn to indicate this is a cascade test.

4. Requester (Specialist Nurse) submits test order and indicates that sample is to be collected at a later date

Post of transaction Bundle consisting of the following resources:

Patient-FayMutlow-Example

ServiceRequest-NonWGSTestOrderForm-CascadeTesting-Example

Observation-DutchLipidScore-Example

Observation-QueryXanthoma-Example

Observation-SimonBroomeCriteria-Example

PractitionerRole-LoisLane-Example

PractitionerRole-MarySmith-Example

Specimen-BloodEDTA-WithCollectionDetails-Example

The lab recieves the test request and:

1. Views the completed test order form

Obtained through GET /ServiceRequest or /GET Task requests (using parameters on CapabilityStatements to filter results) for non-routed requests. (Dashboard of available requests)

OR

Obtained through GET /Task request (filtered by GLH owner) for routed requests.

Then

GET /Task by Id and referenced ServiceRequest for view of individual.

2. Modifies the test request with the appropriate additional information and accepts the test request

PUT of ServiceRequest-SavedTestOrderUpdated-CascadeTesting-Example

(and Provenance resource to indicate reason for change)

3. Once analysis is complete, the lab issues the final report to the requester

PUT of Task-NonWGSRareDiseaseTestOrderCompleted-CascadeTesting-Example with reference to report resource

The requester:

1. Views the current status of the test and accesses the final report.

GET of linked DiagnosticReport: DiagnosticReport-FayMutlowGeneticReport-Example

DNA Storage

DNA Storage (R346, R373, R332, R374) may be requested where genomic testing is likely required in the future, but further information or discussion is required prior to making the test request. In this scenario, DNA may be stored for future genomic testing or to help with testing of other family members.

The requester will create a test request electronically (e.g., R346 1) and record the reason for testing as “Stored DNA”, with the option to record the storage location (if known). The lab receives the test request in real time and samples (at a later date) and follows the current procedure for DNA storage. The requester can then indicate any subsequent electronic test requests the use of stored DNA (sample type). There would be no need to collect a new sample from the patient and the lab will activate the testing in the laboratory systems (LIMS).

Note: DNA storage depends on the quality/amount of DNA originally obtained and banked samples maybe used for multiple tests over multiple years.

Link to the High Fidelity Wireframe for the DNA Storage Scenario

The following steps is a walk through of:

1. Requester searches for a patient (a dummy patient has been pre-populated as an example)

Parameters:

given=Tim 
family=Mclullichs
birthdate=eq1954-10-29

Response:

Patient-TimMclullichs-Example

2. Requester selects code appropriate Test directory code for storage of material (R346, R373, R332, R374)

Saved against ServiceRequest.code

3. Requester completes test order form

POST of test order bundle with ServiceRequest-TestOrderForm-StorageOfMaterial-Example

4. Requester indicates that sample is going to be collected at a later date

Indicated through absence of Specimen resource in message or absence of Specimen.collectedDateTime/Specimen.status=unavailable

The lab recieves the test request and:

1. Views the completed test order form

Obtained through GET /ServiceRequest or /GET Task requests (using paramets on CapabilityStatements to filter results) for non-routed requests. (Dashboard of available requests)

OR

Obtained through GET /Task request (filtered by GLH owner) for routed requests.

Then

GET /Task by Id and referenced ServiceRequest for view of individual.

2. Accepts the test request and indicates the material is to be stored

PUT of Task-TestOrderFormAccepted-StorageOfMaterial-Example

3. Lab completes test request once material is stored

Marking of Task as completed

1. Requester contacts the lab to confirm material avaialble and can be used for new test

Outside Genomic Order Management Comms

2. Requester creates new test request and indicates use of existing sample in storage (sample collected at later date)

POST of test order bundle with ServiceRequest-NonWGSTestOrderForm-UsingStoredSample-Example

3. Lab recieves test request, accepts test request once sample and request are aligned

PUTT of Task-NonWGSTestOrderFormAccepted-UsingStoredSample-Example

and

Task-NonWGSTestOrderFormRequested-UsingStoredSample-Example

Follow-up Testing

The following test types may be requested as an additional or follow up test at the lab. In these instances, the lab acts as the originating requester and may add on additional tests to validate the pathway (these tests may or may not be on the National Genomics Test Directory).

• Confirmatory Test (R443): use of alternative test methods to confirm the conclusions of an original genomic test requested.
• Reflex Test: is the next course of action (new test request) based on the outcome of the original genomic test requested and are related to the outcomes. These tests are internal to the laboratories.
• Lab Recommended Testing: management of situations where the requester has placed a test request however, the lab has replaced the test with a better option or where the optimal test could not be delivered due to sample limitations.
• Re-test: based on quality or a change in what the test provides (panels) and is treated as a new test.
  In these instances, existing samples on the patient may be used by the lab to perform additional testing. Note: Existing DNA/RNA, Cultures may be used for testing in the future for unrelated episodes of testing.

Link to the High Fidelity Wireframe for the Non WGS Rare Disease Test Scenario

The following steps is a walk through of a follow up test type (e.g. Reflex Testing) for a patient:

1. Requester searches for a patient (a dummy patient has been pre-populated as an example)

Parameters:

given=Anita
family=Lamberts
birthdate=eq1993-11-14

Response:

Patient-AnitaLambertsDeceasedPatient-Example

2. Requester searches for test directory code

Call to Digital Test Directory (outside scope for GMS central broker)

3. Requester completes test order form and submits request

POST of Test order transaction bundle including ServiceRequest-NonWGSTestOrderForm-FollowupTest-Example

4. Requester indicates that sample is going to be collected at a later date

Indicated through absence of Specimen resource in message or absence of Specimen.collectedDateTime/Specimen.status=unavailable

The lab recieves the test request and:

1. Views the completed test order form

Obtained through GET /ServiceRequest or /GET Task requests (using parameters on CapabilityStatements to filter results) for non-routed requests. (Dashboard of available requests)

OR

Obtained through GET /Task request (filtered by GLH owner) for routed requests.

Then

GET /Task by Id and referenced ServiceRequest for view of individual.

2. Accepts the test request

PUT of Task-NonWGSRareDiseaseTestOrderAccepted-FollowupTest-Example

3. Lab indicates that further testing is required

This could be added as a note on the original ServiceRequest or Task which prompted further testing.

4. Lab requests a new test (reflex) to aid interpretation

Creation of new ServiceRequest through post of ServiceRequest-NonWGSTestOrderForm-NewFollowupTest-Example

According to scenario, previous test is cancelled (indicated by PUT of Task-NonWGSRareDiseaseTestOrderCancelled-FollowupTest-Example)

5. Lab issues report for patient

Tasks marked as completed Task-NonWGSRareDiseaseTestOrderCompleted-FollowupTest-Example

6. Requester views status and final report

GET of linked DiagnosticReport DiagnosticReport-AnitaLamberts-Example

Duo Trio Testing

The current modelling for Duo/Trio testing assumes a single ServiceRequest is sent, referencing the Proband as the subject, with Consultands being referenced though RelatedPerson resources.

Alternative approaches are to either have the ServiceRequest for the Proband reference a group comprising each subject; or have multiple ServiceRequests, one for each subject, linked via ServiceRequest.basedOn for the parent/proband request or via a a requisition identifier.

These alternative aproaches are expected to be tested through the Alpha and may have implications on the model used.

Link to the High Fidelity Wireframe for Duo/Trio testing (family sample)

The following steps is a walk through of:

1. Requester searches for a patient (a dummy patient has been pre-populated as an example)

Parameters:

given=Phoebe
family=Smitham
birthdate=eq2013-09-27

Response:

Patient-PheobeSmitham-Example

2. Requester selects appropriate code. In this scenario, the example used is Likely Inborn Metabolism (R98)

Saved under ServiceRequest.code

3. Requester completes the Test Order Form and indicates family members ROD and sample associated to the test request

POST of Test order transaction Bundle for Pheobe Smitham consisting of the following resources:

Patient-PheobeSmitham-Example

Observation-AutisticBehaviour-Example

Observation-DelayedSpeechLanguageDevt-Example

Observation-DiseasePenetrancePheobeSmitham-Example

Observation-IntellectualDisabilityProfound-Example

Observation-NonConsanguinousUnionProband-Example

Condition-InbornErrorOfMetabolism-Example

PractitionerRole-EugeneSmithLeedsSTH-Example

ServiceRequest-WGSTestOrderForm-TrioTestingProband-Example

Specimen-PheobeSmitham-Example

Details for Mother added to request:

Patient-PheobeSmithamMother-Example

RelatedPerson-AliceSmithamProbandMother-Example

Specimen-PheobeSmithamMother-Example

Observation-NonConsanguinousUnionProbandMother-Example

Observation-NoTransfusionProbandMother-Example

Observation-NoBoneMarrowTransplantProbandMother-Example

Details for Father added to request (sample not collected at time of submission):

Patient-PheobeSmithamFather-Example

RelatedPerson-JamesLawrenceProbandFather-Example

Observation-NonConsanguinousUnionProbandFather-Example

Observation-NoTransfusionProbandFather-Example

Observation-NoBoneMarrowTransplantProbandFather-Example

Observation-IntellectualDisabilityMild-Example

Record of Discussion form resources added to request (YPA and CD forms for Pheobe Smitham and RoD for the Mother, Father's RoD/consent not collected at time of submission):

Consent-RoD-PheobeSmitham-Example

Consent-RoD-PheobeSmithamYoungPersonAssentForm-Example

Consent-RoD-PheobeSmithamMother-Example

QuestionnaireResponse-RoD-PheobeSmithamCDForn-Example

QuestionnaireResponse-RoD-PheobeSmithamYPAForm-Example

QuestionnaireResponse-RoD-PheobeSmithamMother-Example

4. Requester indicates that sample is going to be collected at a later date

Indicated through absence of Specimen resource in message or absence of Specimen.collectedDateTime/Specimen.status=unavailable for appropriate specimen

The lab recieves the test request and:

1. Views the completed test order form

Obtained through GET /ServiceRequest or /GET Task requests (using parameters on CapabilityStatements to filter results) for non-routed requests. (Dashboard of available requests)

OR

Obtained through GET /Task request (filtered by GLH owner) for routed requests.

Then

GET /Task by Id and referenced ServiceRequest for view of individual.

2. Indicates awaiting sample/ ROD from father and changes request to awaiting further information

PUTT of Task-WGSRareDiseaseTestOrderHold-TrioTestingProband-Example

3. When all samples/ ROD arrives at the lab, test request is triaged and accepted

Receipt of:

Consent-RoD-PheobeSmithamFather-Example (wrapper for RoD)

QuestionnaireResponse-RoD-PheobeSmithamFather-Example (RoD if collected as structured QuestionnaireResponse)

Specimen-PheobeSmithamFather-Example (collected specimen)

ServiceRequest-WGSTestOrderFormUpdated-TrioTesting-Example (update to SR to link consent/specimen)

Provenance-WGSTestOrderForm-TrioTestingProbandFather-Example (Provenance to track reason for change to SR)

PUT of Task-WGSRareDiseaseTestOrderAccepted-TrioTestingProband-Example

AND

Task-WGSRareDiseaseTestOrderAccepted-TrioTestingFather-Example

AND

Task-WGSRareDiseaseTestOrderAccepted-TrioTestingMother-Example (for Tasks related to the prepping of the Mother's and Father's samples)

4. Lab forwards test request/ ROD/ samples to GEL/NGIS.

Change of owner on Task to GEL.

TBC: The specific Task triggering the start of the GEL workflow is still under discussion. This may be the ProcessGenomicTestRequest task, after prerequisite RoD and Samples have been added, or may be the set of SamplePrep Tasks (one per Specimen) after prep has been completed by the managing GLH.

5. Requester checks current status of test request

GET /Task(s) with focus ServiceRequest for status of each task (e.g. Sample Sequencing, Interpretation etc.), subsequent call for /AuditEvent(s) with entity.what=Task for history of updates to tasks if needed (e.g. accepted, in-progress, completed)

6. Requester views final report on patient

Task marked as completed: Task-WGSRareDiseaseTestOrderCompleted-TrioTestingProband-Example

DiagnosticReport, referenced from Task: DiagnosticReport-PhoebeSmithGeneticReport-Example

Modification of Test Requests

The proposed central architecture supports the traceability required in the modification of tests or the validity of the test itself based on activity timestamps. This may also include the addition of further tests to a request already submitted. The functional requirement is to enable the modification of test requests both in an incomplete test request state and once the test request has been submitted (inclusion of additional tests requests following submission).

Modification

In the event the receiving lab requires further information, the requirement is to allow for communication between the lab and requester through means of indication where further information is required on the submitted test. The requester SHALL be notified where additional information is required to proceed with the test and the lab when the update has been made.

The lab may also update the test request (including clinical indication code) based on the decision made by the clinical scientist. The test may be modified or amended in some instances up to the point of a report being issued. Amendments to a test request SHALL be visible to a user accessing the test request. Details of date, and time and user who made the change SHALL be shown on both the original entry and the amendment.

The business rules for confirming when modification (e.g., requires further information by requester) is applicable on a submitted test and requires confirmation from the GLHs. Modifications, cancellation, and mark in error will be tested for all test request types including WGS Test Requests. Any updates required to enable interoperability and workflow improvements to current practices will be made in coordination with GEL and reflected in the NGIS SOPs.

Cancellation

All users of an electronic order management system are responsible for maintaining the accuracy of the tests ordered. In the event a test has been cancelled, the requirement is to allow for transparency on the reason for cancellation (by either requester or lab) and reflect the changes in real time. When a cancellation occurs, the requirement is to record the date of cancellation, the details of the cancellation. Any changes made SHALL be visible to any user accessing the order management system.

A test may be cancelled based on some of the example scenarios listed below:

• Test no longer required (i.e., patient has changed their decision to proceed with the test)
• Multiple tests requested on the same patient and where only one test is required
• Decision not to progress with a test request
• Test could not be delivered due to process failures

Mark-in Error

A test may be marked in error when:

• Data has been recorded on the wrong patient
• Sample collected has been aligned to the wrong patient
• Patient choice was incorrectly recorded status (WGS Test Requests only)- correction of patient choice status any time after a test request has been submitted by the GLH
• Correction of clinical data: correction of test information submitted including HPO terms, clinical indications. For WGS Test Requests, the current process for marking at test in error will be tested as part of the requirements validation within the Alpha phase.

The requirement for managing mark-in-error is to provide transparency to all organisations involved in the provision of the test. Organisations SHALL be informed of the test request being marked in error. If the error was not immediately recognised, information will need to remain to provide an audit trail and reasoning. Details such as reason the test was marked in error, by whom, the date the request and any further information associated with the test request SHALL be maintained.

Policy guidance is required on how the notification and mark -in-error scenarios are managed across organisational boundaries as all of the different organisations will need to be informed of the Mark-in-Error.

[Link to the High Fidelity Wireframe for the Non WGS Rare Disease Test Scenario]https://wi9ul1.axshare.com)

The following steps is a walk through of:

1. Requester or Lab searches for a patient (a dummy patient has been pre-populated as an example)

Parameters:

given=Meir
family=Lieberman
birthdate=eq2005-12-19

Response:

Patient-MeirLiebermanPDS-Example

2. Requester or Lab views request ordered on the patient

Search on /ServiceRequest?subject:identifier=https://fhir.nhs.uk/Id/nhs-number|9449307873

This would return a searchset bundle containing the ServiceRequest: ServiceRequest-NonWGSTestOrderForm-Cancellation-Example

3. Requester or Lab is provided with the functionality to cancel test request

This is recorded through marking the ServiceRequest.status as revoked.

PUT of ServiceRequest-NonWGSTestOrderFormUpdated-Cancellation-Example

4. Requester or Lab indicates reason for cancellation

This is recorded through the associated Provenance resource sent alongside the updated ServiceRequest Provenance-NonWGSTestOrderFormCancellation-Example

5. Test displayed as cancelled on patient's test request history

GET of /ServiceRequest?subject:identifier=https://fhir.nhs.uk/Id/nhs-number|9449307873

Deceased Patient Testing

Link to the High Fidelity Wireframe for the Non WGS Rare Disease Test Scenario

The following scenario covers the eventuality of a patient being marked a deceased while a test is in progress or in the event a deceased patient's sample is being utilised for further testing on a family member. In some instances, requests may be placed on patients who have died (coroner) and a test/ sample may be requested by the coroner.

In each of these scenarios, the requirement is to allow for testing and reporting to continue until a report has been issued on the patient.

1. Requester searches for a patient (a dummy patient has been pre-populated as an example)

Parameters:

given=Anita
family=Lamberts
birthdate=eq1993-11-14

Response:

Patient-AnitaLambertsDeceasedPatient-Example

2. Requester searches for test directory code

Call to Digital Test Directory (outside of scope for GMS central broker)

3. Requester completes test order form and submits request (patient may be alive or deceased and life status is recorded on the test order form)

POST of test order bundle with ServiceRequest-NonWGSTestOrderForm-DeceasedPatient-Example

(Deceased status or date of death marked on Patient resource: Patient-AnitaLambertsDeceasedPatient-Example

Or

1. Test request is on family member

Family members indicated through RelatedPerson resources e.g. RelatedPerson-AnitaLambertsDeceasedPatient-Example

Linked from Patient resource Patient-AnitaLambertsMotherDeceasedPatient-Example

2. Sample provided by deceased patient

Specimen resource linked to Patient through subject element as usual.

Test Routing

All genomic tests and samples are routed initially to the GLH or to the LGL. The scope of the test routing is from the requestor to the coordinating GLH or processing LGL.

For the management of send aways, the Home GLH or LGL SHALL have the ability to manually select a recipient for the order forwarding (send aways) using the central infrastructure.

The LGL/GLH may be responsible for all stages of the testing, such as prep-work, processing, and reporting tasks. Alternatively, the LGL/GLH may act as the distribution point for test request and samples to be sent either to another GLH for specialist testing, NGIS or in some instances, abroad.

The GLH/LGL also act as the gatekeeper for genomic testing ensuring that only tests which meet the eligibility requirements are accepted and the requester is notified of any rejections. In the event a specialist test is directed to the LGL, there is a requirement for the GLH to be informed of the test.

Once the test and sample requested are aligned at the intended lab, the testing process commences, and further routing may be required at each of the processing stages. Prospectively, organisational boundaries may be crossed multiple times. The output of each task (send/receive update) SHALL provide the ability to update the central infrastructure (indicating if the routing has changed to a different organisation) with the overall status of the test or sample.

There is a dependency on the digitisation of the test directory and the management of configurable routing rules centrally, in order to enable interoperability nationally.

Black Box

Currently, there is variation across England in the functional capability available within pathology and genomics LIMS implementations. As a result, there is a potential that any of these laboratories may not be able to meet the interoperability messaging requirements from a genomic central broker creating a black box scenario where the test or sample if received by the lab, will not have an update on current status until the test or sample arrives at the next organisational boundary.

The potential black box scenarios include:

• Requester is the Black Box: In this scenario, if the requester is the black box, the first update will be created when the sample is received. The requester is completing the test order on paper and is sending the request and sample to the GLH. The GLH will provide the update of test request received/sample received.
• Black Box between requester and location where sample is being collected from: For e.g., a GP places a genomic test request to the GLH, and the sample is to be collected at the hospital. In this scenario, the hospital (location) may be a black box and unable to provide sample updates. In this scenario, the GLH is aware of the test request and will be awaiting the sample. Only when the sample arrives at the GLH and is aligned with the test request, an update of the sample received will be provided.
• Home Lab is the Black Box: the GLH is unable to provide a test request or sample status update to the requester. This may be a low possibility however, in the event the GLH is the Black Box, the requester will only receive an update when the final report has been issued.
• Black Box between requester, specialist lab and home lab: E.g., oncologist refers the patient for genomic testing and the sample is collected and the specialist centre for the test. If the specialist lab is the black box, and is unable to indicate that the test request/sample has been received, the home lab GLH, may not be notified of the status of the test request and sample until a final report has been received by the requester

A programme board decision is required to understand how black box scenarios should be dealt with post Alpha phase. A further decision is required to confirm if black boxes should exist or can be mitigated through access provided at the GLH level to the lab team to enable entry of electronic test requests and the management of sample and test status updates within the central portal.