Genomics Reporting Operations

For Genomic Data Retrieval, including integration with the proposed NHS England Unified Genomic Record, the NHS England Genomics Unit are currently considering adoption of the GenomeX Genomic Operations guidance.

find-subject-variant

Specifically, the find-subject-variants operation (Structured FHIR variant query) can be implemented as a facade on the htsget operation (binary VCF query), with the regions passed through to the htsget call, and the returned variants converted to FHIR resources, using the component allele slices as an un-altered copy of the VCF Variant, and potentially cached. The FHIR representation can then be further enriched with annotations and alternative representations of the variant using other component slices.

The VCF model has support for annotations e.g. through the text field (8th column) within a VCF file. While this can be split by commas etc. fully structured annotation is not supported.

While storing all variants as FHIR resources would be prohibitively costly, FHIR variants can be generated for variants of clinical significance. As structured reporting progresses, representing variants within FHIR can be incorporated into the interpretation process, using guidance from the Genomics Reporting IG. Variants can then be linked directly to the report that uses this data.

This operation is linked to the DocumentReference resource in that the DocumentReference, within the context of the Genomics FHIR Implementation Guide, will point to the binary Genomic Data file, potentially using a DRS url. This file may be a full list of the variants found. htsget, and the FHIR equivalent find-subject-variants, will search this file for variants at particular locations and transform these into the relevant FHIR Variants (a profile on Observation).

Other subject level operations

Implementation of other subject level operations are pending use cases to support these operations.

Population level operations

Implementation of population level operations are pending use cases to support these operations. It is expected these operations may be used to support research or population health based statistics.

Metadata operations

The find-study-metadata operation can be used to query for subject/test specific metadata such as regions studied and DNA change types tested for.

It is expected that the test requested will have its own set of metadata, driven by the genomics testing service (Test Directory) but actual delivered tests may differ due to a number of factors, e.g. specimen quality, equipment available etc.

The delivered test metadata will need to be recorded against the outcome of a test i.e. the DiagnosticReport. As per the Genomics Reporting IG, it is expected that this would be recorded via the Genomic Study profile on procedure, and component Genomic Study Analysis. Effective use of this operation requires the analyses performed to be consistently and routinely structured (which is not currently the case within Genomics in the UK. As such preliminary work to structure the metadata surrounding tests will need to be performed, this may be facilitated by the work programmes within NHS England to standardise and share bioinformatics pipelines/workflows.

DocumentReference generate

This operation is a customization of the R5 generate operation for DocumentReference.

It will take in a URL (either DRS or presigned URL) for a Genomic Data file, optionally pulls the file into a common data store, generates a DRS URL if this has not already been assigned, and creates a DocumentReference resource to hold the URL and associated metadata.

The selected input parameters as well as specific profiles for input or output parameters, e.g. for certain data file types, are pending further investigation by GEL, as such, this OperationDefinition SHOULD be considered for illustrative purposes only.

URL: [base]/DocumentReference/$genomics-generate

An example of the Parameters needed to invoke the Operation are provided at Parameters-Generate-Example

The resulting output would be a SearchSet Bundle containing the created DocumentReference, if successful, an example of a DocumentReference for a Genomic Data file can be found at DocumentReference-PharmCAT-Example.

Failure will result in an OperationOutcome detailing the reasons for failure, e.g. missing required parameters, unable to access data file, etc. The full list of possible error scenarios is pending further investigation.

Composition document

As a consequence of supporting RESTful update operations on resources within the central broker, some information, such as patient history may change over time. This poses a problem when interrogating past 'documents', or resources such as ServiceRequests or DiagnosticReports, as the information contained within them, or the references to other resources, may change after a test request has been closed.

To maintain the accuracy of historic information, such as the observations a genomic report was based on, it may be necessary to create an immutable snapshot of the resources related to a ServiceRequest or DiagnosticReport after closure of a request.

To support this, the central broker can create Document Bundles using the $document operation on Composition. The Compositions would need to be generated on closure of a ServiceRequest (e.g. a ServiceRequest being marked as 'completed' or 'revoked', or a DiagnosticReport marked as 'final', 'amended', 'corrected' or 'appended') to capture the final IDs for the ServiceRequest and DiagnosticReport.

Upon generation of the Composition, the central broker can call the $document operation on the Composition resource, using the appropriate GraphDefinitions to follow the required resource references and generate a Bundle of type 'document' containing all the resources forming the order or result:

GET [base]/Composition/[id]/$document?persist=true&graph=genomics-test-result

This Bundle could then be stored/accessible via the Bundle endpoint as an immutable snapshot of the order/result at that point in time, regardless of whether any changes were made to those resources after generation:

GET [base]/Bundle/[id]

or searched via:

GET [base]/Bundle?composition.entry:DiagnosticReport=[id]
GET [base]/Bundle?composition.entry:ServiceRequest=[id]

The sequence diagram for the proposed process is given below:

Observation lastn

As part of identifying the latest HPO terms applicable to a patient, servers MAY implement the $lastn operation, which uses the Observation search parameters to filter results and restricts the return of matching resources to the last n Observations for the patient. e.g. for the latest Renal Insufficiency HPO code value for Meir Lieberman:

GET [base]/Observation/$lastn?max=1&patient=Patient/Patient-MeirLieberman-Example&code=https://hpo.jax.org/app/|HP:0000083

Resource validate

An operation to support validation of resources against a GraphDefinition. This OperationDefinition is an extension to the Resource-validate operation (please see the deifinition for this operation to determine functionality for the base input/output parameters).

Use of this operation SHALL invoke FHIR validation (structural validation), Ontology Server validation (semantic validation) and Business Rules/Genomic MDS validation (business validation) by default.

This Operation is intended to support two specific use cases:

1. To allow validation of resources before submission/creation on the central order management broker, e.g. in the case of a client/front-end system for constructing an order form, allowing display of validation issues to the user.

2. To allow downstream systems to validate or check test orders for warnings, e.g. omitted items marked as Mandatory in the Genomic Test Order MDS, allowing these systems to assess validity before injecting resources into their own pipelines.

URL: [base]/$genomics-validate