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 following guidance relates to how the proband and report subject is represented within the data model, dependent on the who the testing is performed on and who the results are of the benefit of.

It is expected, in practice, all results would be attached to the woman's record until after birth, and assignment of an NHS number for the baby. It is the responsibility of the requesting/reporting systems to attach requests/reports to the appropriate subject within their local systems.

ScenarioModelling Considerations
  • Woman is pregnant and testing is on woman (e.g., prenatal testing): The test request is created on the fetal record and the sample taken is from the woman
  • Confirmation of if the woman has been diagnosed with cancer or is undergoing treatment becomes mandatory
 In this case, the data model SHOULD match the singleton scenario (Woman is the Proband, and testing is on the woman's sample only). The fetal information MAY be added to the request alongside RelatedPerson and Patient resources for the fetus within the ServiceRequest.supportingInfo. The Specimen and DiagnosticReport SHOULD reference the woman as the subject.
  • Woman is pregnant and the specialist testing is on the woman (e.g., NIPD): The test request is created on the fetal record and the sample taken is from the woman
  • NIPD may also require a paternal sample and cord blood or fetal tissue post delivery
  • Confirmation of if the woman has been diagnosed with cancer or is undergoing treatment becomes mandatory
 In this case, the data model SHOULD match the singleton/duo/trio scenario (Woman is the Proband and testing is on the woman's, man's or fetal sample as appropriate). The fetal information SHOULD be added to the request alongside RelatedPerson and Patient resources for the fetus within the ServiceRequest.supportingInfo. The DiagnosticReport SHOULD reference the Woman as the subject.
  • Woman is pregnant and testing is on the fetus (e.g., CVS or amnio): The test requested is created on the fetal record. As part of fetus testing, the following information becomes mandatory:
  • Woman's sample may be required for MCC (regardless of whether the condition is paternal), see R321.1
  • the ability to register a test against the fetus (this may differ from local organisation to another and is typically the woman’s Hospital ID plus indication of fetus ( Ex. WG1342Fetus A) - Used as the unique fetal identifier prior to NHS Number allocation
  • The capture of additional information such as fetal phenotypic sex (M/F/U or Unknown) and number of fetuses also becomes mandatory. - Captured on the Patient resource for the fetus
  • Pregnancy details: capture of Pregnancy type (Spontaneous conception, Surrogacy, or IVF Pregnancy). If IVF, the capture of own/donor egg/sperm and the age of the egg donor becomes mandatory - Observation resources linked to the woman's patient record, as they relate to the pregnancy
  • Note: If fetus is under 24 weeks, the sample is from the woman (as fetal viability is from 24 weeks as per UK law) - in this case the Proband (fetus) does not have any samples associated with their record.
 In this case, the data model SHOULD match the singleton/duo scenario (Fetus is the Proband, woman's record is captured through additional RelatedPerson and Patient records attached to ServiceRequest.supportingInfo, testing may be on both fetal and maternal samples but may be on maternal samples only). The DiagnosticReport SHOULD reference the fetus as the subject.
  • Woman is pregnant with multiple fetuses and test is completed on each fetus with a result per fetus: An electronic test request per fetus is created on the fetal record. A test request/sample collection is required for each fetus. Additional mandatory information required includes:
  • the ability to register a test against the fetus (this may differ from local organisation to another and is typically the woman’s Hospital ID plus indication of fetus (Ex. WG1342Fetus A) - Used as the unique fetal identifier prior to NHS Number allocation
  • The capture of additional information such as fetal phenotypic sex (M/F/Unclear or Unknown) and number of fetuses also becomes mandatory. - Captured on the Patient resource for the fetus
  • Pregnancy details: capture of Pregnancy type (Spontaneous conception, Surrogacy, or IVF Pregnancy). If IVF, the capture of own/donor egg/sperm and the age of the egg donor becomes mandatory - Observation resources linked to the woman's patient record, as they relate to the pregnancy
 In this case, the data model SHOULD be equivalent to multiple singleton/duo tests (Fetus is the Proband for each test, woman's record is captured through additional RelatedPerson and Patient records attached to ServiceRequest.supportingInfo, testing may be on both fetal and maternal samples but may be on maternal samples only). Tests can possibly be linked via a shared requisition identifier on each ServiceRequest (pending further testing). Each DiagnosticReport SHOULD reference the relevant fetus as the subject.
  • Products of Conception testing where the woman has had a miscarriage: In these scenarios, further testing may be required to inform the management of future pregnancies. Testing may occur on the products of conception/stillborn fetus from the previous pregnancy (if available). A test request is created on the woman’s record with the confirmation of sample collected (if after 24 weeks as fetal tissue or cord blood)
 In this case, the data model SHOULD match the singleton/duo scenario (Woman is the Proband, as testing is for the benefit of the woman, with fetal information captured through additional RelatedPerson and Patient records attached to the ServiceRequest). If samples from the previous miscarriage are tested, these should be added as pre-existing Specimens to the ServiceRequest (as per the DNA Storage, using stored sample example). The DiagnosticReport SHOULD reference the woman as the subject.

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.

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 appropriate 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 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-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