NHS North West Genomics
2.2.0 - ci-build
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
| Official URL: https://fhir.nwgenomics.nhs.uk/Questionnaire/CancerTestAdditionalAskAtOrderQuestions | Version: 2.2.0 | ||||
| Draft as of 2026-09-20 | Computable Name: | ||||
This Questionnaire is a proposal, not an active or planned project.
Test Specific Additional Ask At Order Entry Questions for Cancer orders - used alongside the common core order form and Ask At Order Entry Questions Common, the same "Test Specific" tier pattern WGS Test Additional Ask At Order Entry Questions already follows for WGS orders - see Order Entry Questions.
Its content is inferred, not yet confirmed against a live order-entry
screen the way WGSTestAdditionalAskAtOrderQuestions was: each item below
is a concept that recurs independently across the two Cancer-category NW
GLH paper forms - HRD and Tumour
BRCA (GB-27189) and GMS
WGS Cancer (the national
form) - see NW GLH Paper Test Request
Forms.
Neither of those two Questionnaires has been changed to actually use this
one yet - both remain independent, standalone Questionnaires, each already
carrying its own copy of the fields proposed here.
Diagnostic Genomics
Used alongside Genomic Test Order (the common core) and Ask At Order Entry Questions Common for Cancer orders specifically - see Order Entry Questions, the same "Test Specific" tier pattern WGS Test Additional Ask At Order Entry Questions already follows for WGS orders.
Its content is inferred, not yet confirmed against a live order-entry screen: each item below is a concept that recurs independently across the two Cancer-category NW GLH paper test request forms - HRD and Tumour BRCA (GB-27189) and GMS WGS Cancer (the national form). Neither of those two Questionnaires has been changed to actually use this one yet - both remain independent, standalone Questionnaires, each already carrying its own copy of the fields proposed here.
| Name | Code System | Answer ValueSet | Cardinality | HL7 v2 OML_O21 Message | OBX-2 Value Type | HL7 FHIR Resource (Message + RESTful) |
|---|---|---|---|---|---|---|
| Presentation status | NWGMSA PresentationFirstDiagnosis / PresentationRecurrenceRelapse | First diagnosis/Recurrence-Relapse/Unknown | 0..1 | OBX | CE | Observation.valueCodeableConcept |
| Neoplastic/malignant cell content (%) | NWGMSA NeoplasticCellContent | 0..1 | OBX | NM | Observation.valueQuantity | |
| Pathologist | NWGMSA PathologistName | 0..1 | OBX | ST | Observation.valueString | |
| Pathology hospital / laboratory | NWGMSA PathologyHospital | 0..1 | OBX | ST | Observation.valueString |
Neoplastic/malignant cell content (%) is the field most worth reading
the design note on: the same underlying concept is independently modelled
three times today - on HRD and Tumour
BRCA, GMS WGS
Cancer and WGS Local Test
Order - each under its
own suffixed linkId despite sharing the same NWGMSA code. This
Questionnaire proposes the single shared field this tier exists for,
rather than each Cancer-adjacent form continuing to reinvent its own copy.
Presentation status generalises HRD and Tumour
BRCA's own Pathway
choice (which conflates presentation status with test selection itself,
since on that specific form the pathway and the presentation are the same
choice) into the cleaner, already-separated shape GMS WGS
Cancer uses.
Pathologist and Pathology hospital / laboratory generalise HRD and Tumour BRCA's own two named fields and GMS WGS Cancer's Histopathology Lab ID (a related but not identical concept - a lab identifier rather than a named hospital) into one shared pair of fields.
These two fields most directly relate to the Cheshire and Merseyside
Pathology reflex use case, where a
genomic order follows on from a prior pathology order/report
(LAB-1/LAB-3) rather than starting the clinical episode itself - that
page's own Current
Process still models
the pathology-to-genomics handoff entirely as HL7 v2/FHIR messaging
(LAB-1/LAB-35/LAB-3/LAB-36), which is why today's answer is free
text rather than a machine-resolvable reference. A query-based alternative
may remove the need to duplicate pathology content into the genomic
order/message at all: some NW pathology LIMS deployments (e.g. Medicus)
already support the Australian AU
eReq FHIR IG for on-demand query
access to pathology orders (and potentially reports), and MFT separately
exposes pathology data through Epic's own FHIR Query
API. If a genomics laboratory can query pathology
directly, these two free-text fields could be replaced by a reference
instead - the Pathology Order Filler Number, Pathology Patient Identifier
and/or Pathology Specimen Identifier - letting the genomic order carry a
pointer for on-demand lookup rather than the pathology detail itself.
Profile: Questionnaire
| LinkID | Text | Cardinality | Type | Description & Constraints![]() |
|---|---|---|---|---|
![]() |
**This Questionnaire is a proposal, not an active or planned project.** **Test Specific Additional Ask At Order Entry Questions** for Cancer orders - used *alongside* the [common core order form](Questionnaire-GenomicTestOrder.html) **and** [Ask At Order Entry Questions Common](Questionnaire-GenomicGeneralAskAtOrderEntry.html), the same "Test Specific" tier pattern [WGS Test Additional Ask At Order Entry Questions](Questionnaire-WGSTestAdditionalAskAtOrderQuestions.html) already follows for WGS orders - see [Order Entry Questions](Questionnaire-GenomicTestOrder.html#order-entry-questions). Its content is **inferred**, not yet confirmed against a live order-entry screen the way `WGSTestAdditionalAskAtOrderQuestions` was: each item below is a concept that recurs independently across the two Cancer-category NW GLH paper forms - [HRD and Tumour BRCA](Questionnaire-HRDTumourBRCAAskAtOrderEntry.html) (GB-27189) and [GMS WGS Cancer](Questionnaire-GMSWGSCancerAskAtOrderEntry.html) (the national form) - see [NW GLH Paper Test Request Forms](Questionnaire-GenomicTestOrder.html#nw-glh-paper-test-request-forms). Neither of those two Questionnaires has been changed to actually use this one yet - both remain independent, standalone Questionnaires, each already carrying its own copy of the fields proposed here. | Questionnaire | https://fhir.nwgenomics.nhs.uk/Questionnaire/CancerTestAdditionalAskAtOrderQuestions#2.2.0 | |
![]() ![]() |
Ask At Order Entry Questions | 0..1 | group | Value Set: |
![]() ![]() ![]() |
Presentation status | 0..1 | choice | Definition: Observation.valueCodeableConcept Value Set: Options: 3 options |
![]() ![]() ![]() ![]() |
Inferred from [GMS WGS Cancer](Questionnaire-GMSWGSCancerAskAtOrderEntry.html)'s own `NOS/PresentationStatus` item. Generalises the same distinction [HRD and Tumour BRCA](Questionnaire-HRDTumourBRCAAskAtOrderEntry.html) makes via its own `Pathway` choice (HRD test = newly diagnosed, Tumour BRCA-only = relapsed) plus separate `NewlyDiagnosedAdvancedDiseaseConfirmation`/`RelapsedDiseaseConfirmation` booleans - that form conflates presentation status with test selection itself, since the pathway and the presentation are the same choice on that specific form; here they are kept separate, as GMS WGS Cancer already does. | 0..1 | display | Value Set: |
![]() ![]() ![]() |
Neoplastic/malignant cell content (%) | 0..1 | quantity | Definition: Observation.valueQuantity Value Set: |
![]() ![]() ![]() ![]() |
The same underlying concept is independently modelled three times today, each under its own linkId despite sharing this same `NWGMSA` code: [HRD and Tumour BRCA](Questionnaire-HRDTumourBRCAAskAtOrderEntry.html)'s `NOS/NeoplasticCellContent` ("Approximate % neoplastic nuclei in tumour area highlighted"), [GMS WGS Cancer](Questionnaire-GMSWGSCancerAskAtOrderEntry.html)'s `NOS/NeoplasticCellContent-gms` ("% Malignant nuclei / blasts (or equivalent)"), and [WGS Local Test Order](Questionnaire-WGSLocalTestOrderAskAtOrderEntry.html)'s own `NOS/NeoplasticCellContent-wgs`. Proposed here as the single shared field this tier is for, rather than each Cancer-adjacent form continuing to reinvent its own suffixed linkId for the same value. | 0..1 | display | Value Set: |
![]() ![]() ![]() |
Pathologist | 0..1 | string | Definition: Observation.valueString Value Set: |
![]() ![]() ![]() ![]() |
Present as its own named field on [HRD and Tumour BRCA](Questionnaire-HRDTumourBRCAAskAtOrderEntry.html). [GMS WGS Cancer](Questionnaire-GMSWGSCancerAskAtOrderEntry.html) doesn't ask for the pathologist by name, only a Histopathology Lab ID (see `Pathology hospital / laboratory` below) - proposed here as a genuinely Cancer-wide concept even though only one of the two source forms currently asks for it. | 0..1 | display | Value Set: |
![]() ![]() ![]() |
Pathology hospital / laboratory | 0..1 | string | Definition: Observation.valueString Value Set: |
![]() ![]() ![]() ![]() |
Generalises [HRD and Tumour BRCA](Questionnaire-HRDTumourBRCAAskAtOrderEntry.html)'s own `NOS/PathologyHospital` and [GMS WGS Cancer](Questionnaire-GMSWGSCancerAskAtOrderEntry.html)'s `NOS/HistopathologyLabID` ("Histopathology Lab ID", under that form's own Solid tumour sub-group) - both identify where the pathology specimen/report the order relies on came from, just at different granularity (a named hospital vs. a lab identifier). Kept as free text pending a decision on whether an [Organisation Code](StructureDefinition-OrganisationCode.html) reference would be more appropriate. | 0..1 | display | Value Set: |
![]() ![]() ![]() ![]() |
This item, and Pathologist above, most directly relate to the [Cheshire and Merseyside Pathology](CheshireAndMerseysidePathology.html) reflex use case, where a genomic order follows on from a prior pathology order/report (`LAB-1`/`LAB-3`) rather than starting the clinical episode itself. That page's own [Current Process](CheshireAndMerseysidePathology.html#current-process) still models the pathology-to-genomics handoff entirely as HL7 v2/FHIR messaging (`LAB-1`/`LAB-35`/`LAB-3`/`LAB-36`), which is why today's answer is free text naming the pathologist/hospital rather than a machine-resolvable reference. A query-based alternative may remove the need to duplicate pathology content into the genomic order/message at all: some NW pathology LIMS deployments (e.g. Medicus) already support the Australian [AU eReq](https://hl7.org.au/fhir/ereq/index.html) FHIR IG for on-demand query access to pathology orders (and potentially reports), and MFT separately exposes pathology data through Epic's own [FHIR Query API](https://fhir.epic.com/). If a genomics laboratory can query pathology directly, these two free-text fields could be replaced by a **reference** instead - the Pathology Order Filler Number, Pathology Patient Identifier and/or Pathology Specimen Identifier - letting the genomic order carry a pointer for on-demand lookup rather than the pathology detail itself. | 0..1 | display | Value Set: |
Documentation for this format | ||||
Options Sets
Answer options for NOS/PresentationStatus
Profile: Questionnaire
Ask At Order Entry Questions
Presentation status
Inferred from [GMS WGS Cancer](Questionnaire-GMSWGSCancerAskAtOrderEntry.html)'s own `NOS/PresentationStatus` item. Generalises the same distinction [HRD and Tumour BRCA](Questionnaire-HRDTumourBRCAAskAtOrderEntry.html) makes via its own `Pathway` choice (HRD test = newly diagnosed, Tumour BRCA-only = relapsed) plus separate `NewlyDiagnosedAdvancedDiseaseConfirmation`/`RelapsedDiseaseConfirmation` booleans - that form conflates presentation status with test selection itself, since the pathway and the presentation are the same choice on that specific form; here they are kept separate, as GMS WGS Cancer already does.
Neoplastic/malignant cell content (%)
The same underlying concept is independently modelled three times today, each under its own linkId despite sharing this same `NWGMSA` code: [HRD and Tumour BRCA](Questionnaire-HRDTumourBRCAAskAtOrderEntry.html)'s `NOS/NeoplasticCellContent` ("Approximate % neoplastic nuclei in tumour area highlighted"), [GMS WGS Cancer](Questionnaire-GMSWGSCancerAskAtOrderEntry.html)'s `NOS/NeoplasticCellContent-gms` ("% Malignant nuclei / blasts (or equivalent)"), and [WGS Local Test Order](Questionnaire-WGSLocalTestOrderAskAtOrderEntry.html)'s own `NOS/NeoplasticCellContent-wgs`. Proposed here as the single shared field this tier is for, rather than each Cancer-adjacent form continuing to reinvent its own suffixed linkId for the same value.
Pathologist
Present as its own named field on [HRD and Tumour BRCA](Questionnaire-HRDTumourBRCAAskAtOrderEntry.html). [GMS WGS Cancer](Questionnaire-GMSWGSCancerAskAtOrderEntry.html) doesn't ask for the pathologist by name, only a Histopathology Lab ID (see `Pathology hospital / laboratory` below) - proposed here as a genuinely Cancer-wide concept even though only one of the two source forms currently asks for it.
Pathology hospital / laboratory
Generalises [HRD and Tumour BRCA](Questionnaire-HRDTumourBRCAAskAtOrderEntry.html)'s own `NOS/PathologyHospital` and [GMS WGS Cancer](Questionnaire-GMSWGSCancerAskAtOrderEntry.html)'s `NOS/HistopathologyLabID` ("Histopathology Lab ID", under that form's own Solid tumour sub-group) - both identify where the pathology specimen/report the order relies on came from, just at different granularity (a named hospital vs. a lab identifier). Kept as free text pending a decision on whether an [Organisation Code](StructureDefinition-OrganisationCode.html) reference would be more appropriate.
This item, and Pathologist above, most directly relate to the [Cheshire and Merseyside Pathology](CheshireAndMerseysidePathology.html) reflex use case, where a genomic order follows on from a prior pathology order/report (`LAB-1`/`LAB-3`) rather than starting the clinical episode itself. That page's own [Current Process](CheshireAndMerseysidePathology.html#current-process) still models the pathology-to-genomics handoff entirely as HL7 v2/FHIR messaging (`LAB-1`/`LAB-35`/`LAB-3`/`LAB-36`), which is why today's answer is free text naming the pathologist/hospital rather than a machine-resolvable reference. A query-based alternative may remove the need to duplicate pathology content into the genomic order/message at all: some NW pathology LIMS deployments (e.g. Medicus) already support the Australian [AU eReq](https://hl7.org.au/fhir/ereq/index.html) FHIR IG for on-demand query access to pathology orders (and potentially reports), and MFT separately exposes pathology data through Epic's own [FHIR Query API](https://fhir.epic.com/). If a genomics laboratory can query pathology directly, these two free-text fields could be replaced by a **reference** instead - the Pathology Order Filler Number, Pathology Patient Identifier and/or Pathology Specimen Identifier - letting the genomic order carry a pointer for on-demand lookup rather than the pathology detail itself.
Profile: Questionnaire
| LinkID | Description & Constraints![]() |
|---|---|
![]() |
Value Set: |
![]() ![]() |
Definition: Observation.valueCodeableConcept Value Set: Options: 3 options |
![]() ![]() ![]() |
Value Set: |
![]() ![]() |
Definition: Observation.valueQuantity Value Set: |
![]() ![]() ![]() |
Value Set: |
![]() ![]() |
Definition: Observation.valueString Value Set: |
![]() ![]() ![]() |
Value Set: |
![]() ![]() |
Definition: Observation.valueString Value Set: |
![]() ![]() ![]() |
Value Set: |
![]() ![]() ![]() |
Value Set: |
Documentation for this format | |
Try this questionnaire out:
There are currently no QuestionnaireResponse instances for this Questionnaire defined in this IG.