This page is part of the Genetic Reporting Implementation Guide (v0.1.0: STU 1 Ballot 1) based on FHIR v3.3.0. The current version which supercedes this version is 2.0.0. For a full list of available versions, see the Directory of published versions 
Contents:
The content in this implementation guide supersedes the genomics profiles profiles that were published as part of the STU (which can be found here. This page provides guidance for implementers of those profiles to understand how to map content from those older profiles to those provide in this implementation guide.
As mentioned in the principles section of the introduction, this implementation guide tries to leverage the Observation resource and minimize the use of extensions. This approach is expected to maximize the number of systems that can capture, store, convey and otherwise manipulate genomic reporting results. Over-reliance on extensions increases the risk of information loss, particularly as results pass through systems that may not have been specifically designed to convey genomics-related information. As a Standard for Trial Use, both the prior profiles and the contents of this implementation guide are subject to non-backward compatible change based on feedback from the implementation community and the continuing evolution of the authoring work group's understanding of implementer requirements and how best to express them within FHIR's data structures.
Guidance for converting from the STU3 ProcedureRequest-genetics profile to the Order for Genetics Test profile.
The STU3 model made no assertions about the use of ProcedureRequest beyond the introduction of a single optional repeating complex extension. In FHIR R4, ProcedureRequest has been renamed to ServiceRequest. Additional guidance has been provided on a minimum set of data elements to support.
More importantly, the mechanism to support ordering of multiple tests has changed. In alignment with the overall Request pattern, orders for multiple tests are handled with multiple separate service requests. This allows each request to be managed independently from a fulfillment and status perspective - some tests might be completed successfully, others cancelled or transferred to other labs. As such, the code, specimen and status elements of the complex extension are now covered by the same-named elements in ServiceRequest. Multiple service requests can be linked together with a single requisition identifier to indicate that multiple tests were ordered simultaneously as part of a single action. Support for the requisition element is required as part of the R4 genomics service request profile.
The one remaining component of the complex extension is the geneticsObservation component whose purpose is described as being to identify the variant to be tested. However, Observation is appropriate to identify a variant that has already been found, not one to be looked for. In R4, serviceRequest has an orderDetail code that can be used for this purpose. The Observation.value of the Observation pointed to by the geneticsObservation extension component would be sent as the orderDetail code.
Guidance for converting from the STU3 DiagnosticReport-genetics profile to the CG Diagnostic Report profile.
The STU3 profile prohibited the population of codedDiagnosis element and asserted 3 optional repeating extensions - geneticsAssessedCOndition, geneticsFamilyMemberHistory and geneticsAnalysis. In the R4 profile, we no longer prohibit the inclusion of codeDiagnosis. While it would be unusual for a lab to assert diagosis, it is possible that some organizations, with appropriate knowledge of the patient and clinician oversight could do so. The R4 profile merely provides guidance on this element.
The content conveyed by geneticsAssessedCondition is not yet supported by the R4 profile. As noted in the General Genomics Reporting section, the reporting of assessed conditions (and assessed genes, assessed variants, and assessed variants) must be handled differently in FHIR as this information must be conveyed with each Observation where it would affect the interpretation of the Observation. An R3 mapping will be provided once this issue is resolved, but it is likely that the mechanism will be handled through related Observations and Observation components, not extensions.
The purpose of geneticsFamilyMemberHistory is now handled by the more generic supportingInfo extension which can handle a variety of inputs that help to inform the genetic report (or any other type of report). It is possible that this element will be elevated to a core element of DiagnosticReport.
The geneticsAnalysis complex extension is handled by the various "Interpretation" Observations - every interpretation is conveyed as a distinct Observation because each such assertion can stand alone can can also be referenced as the reason for subsequent actions.
The STU3 Observation-genetics profile largely mapps to the Described Variant profile in FHIR. The STU3 profile makes heavy use of extensions. In the R4 profiles, these are almost entirely handled as Observation components. The specific mappings are as follows:
TODO - include mapping document from LIN
The Sequence resource is supported in both the STU3 and R4 profiles. However, the R4 profiles propose to limit the use of Sequence to "definitional" data rather than patient-specific sequence information, preferring to use Observation for the former. As a result, several STU3 Sequence elements are mapped to Observation elements in R4.
TODO - define specific mappings and identify which additional sequence elements (particularly quality elements) should be brought into the Observation profiles
This version of the implementation guide has not incorporated
© 2017+ HL7 International Clinical Genomics Work Group. Based on FHIR version (3.3.0-13671). IG generated on Wed, Apr 4, 2018 06:23+1000.
Links: Version History |
Table of Contents |
|
Propose a change