Stream: genomics / eMerge Pilot
Topic: Representation of interpretation text in DiagnosticReport
Mullai Murugan (Mar 07 2019 at 00:29):
What would be an appropriate use of the fields conclusion and conclusionCode in the Genomics Reporting resource? Could the conclusion field be possibly used to represent text highlighted in yellow in the attached in sample report?
As also detailed in a gforge tracking item #19830
Kevin Power (Mar 07 2019 at 14:29):
I think this question relates closely to several of the threads that Larry started yesterday. This is a great example of where I would suggest summarizing the various discussions into a single document, and we can start brainstorming on the best ideas to solve the problem. And the DR.conclusion* fields should be considered as at least part of a solution.
Larry Babb (Mar 13 2019 at 22:04):
I'd like to suggest that the ObsGenePanel add 2 new components that correspond to the conclusion and conclusionCode elements on the DiagnosticReport. The argument in favor is that the ObsGenePanel ends up playing the role of an aggregated set of results analogous to a mini-report. These nest panel (mini-reports) all have a text blurb that is seemingly analogous to the "conclusion" and "conclusionCode" fields' purposes on the top level DR.
We need to be able to put the conclusion for the various analyzed results whether they be for the diagnostic pathogenic analysis or the PGx analysis for given medication impacts or other kinds of discrete results included in clinical genomic reports. These "blurbs" are the key to representing the information in a manner that aids the clinician significantly. It is a critical element.
This is a very critical field to provide, if the choice is to consider nested DRs versus expanding the ObsGenePanel to behave more like a nested DR, is not as important to us, which ever one is chosen will drive how folks use this guide for any type of genetic reporting that involves nested analysis - which appears to be a lot from my experience.
Lloyd McKenzie (Mar 13 2019 at 22:19):
If you've got a "conclusion", then you should probably be looking to use nested DiagnosticReport for your panel rather than Observation
Kevin Power (Mar 13 2019 at 22:21):
Was about to ask that very question Lloyd. We will likely have models where we want multiple DRs, others where ObsGenePanel should be used. And perhaps this is the one of the distinctions to help decide which way to go?
Lloyd McKenzie (Mar 13 2019 at 22:27):
Yup
Larry Babb (Mar 14 2019 at 11:51):
OK. I'm good with the nested DR approach. It always seemed like a more natural fit. Can anyone point me to guidance or examples on how to nest DRs?
Larry Babb (Mar 14 2019 at 12:03):
(While I'm waiting on the nested DR request)
I am processing what @Lloyd McKenzie precisely means by "conclusion" from above
If you've got a "conclusion", then you should probably be looking to use nested DiagnosticReport for your panel rather than Observation
While each section (panel) of these composite genetic reports has a "conclusion" of its own. It is very possible that these reports might be crafted to also provide an overall "conclusion" as well.
For example, a lab could define a "cardio" genetics panel (similar to the heartcare example report that has been referenced in the topic Housing extended test, methodology and reference information.
In this report each nested section (or nested report) has it's own conclusion with text and coding that provides an summation of the analysis from that section of the report (gene panel molecular diagnostics for cardio genes, polygenic risk score of the cardio-related indication, and the pharmacogenetic analysis for the cardio-related drug-gene phenotypes.
In addition, there is an overall top-level DR interpretation and conclusion text and coding that provides the clinician with a summary of the entire reports compilation of findings considered. This top level DR would hold the overall recommendations (management and family screening) that the test's results would support. There may or may not be a coded conclusion or overall interpretation at this level as it may be difficult to derive a standard for how one might place an composite conclusion code or interpretation on the report, but each lab may created a coded conclusion and interpretation for these composite reports as part of the tests reporting SOP. So it cannot be ruled out.
The heartcare composite report is somewhat clean, but when it comes to other types of report structures, there may truly be an a la carte approach to the sub-reports and sets of conclusions provided. I've seen exome reports that have analysis on blood groups, and a set of molecular diagnosis for a gene panel with one or more indications (separated), incidental findings analysis (separated), Pgx analysis for pharmacogenomic genes related to drugs for varying indications (sometimes grouped together sometimes separated) and other kinds of analysis that I cannot recall at this time.
So it truly feels as if nested DRs will be required in delivering the eMERGE report. And, we should provide clarification in the IG that the Gene Panel is not meant to be an alternative for sub-reporting that convey independent conclusions.
To be clear, observations themselves don't have "conclusions", correct? I see the Observation.interpretation (which is a kind of coded conclusion or outcome and has been explicitly removed from the ObsBase profile in the CG IG). I see the Observation.value which is a specific coded result for a specific observation.code (type). And, I see an Observation.note which is more of an annotation or note about a specific observation. So there is really no where on an Observation to add the final interpretation text that is equivalent to the DRs. conclusion. Please correct me if I have missed something.
Lloyd McKenzie (Mar 14 2019 at 14:49):
If a panel has an independent sign-off and could potentially be shared on its own, then it should be represented as a DiagnosticReport. If it just includes a couple of high-level summary observations that describe the overall results of the different tests in the panel, you could still do that using Observation.
Kevin Power (Mar 14 2019 at 21:06):
In case you haven't see it @Lloyd McKenzie , this is the sort of report the are modeling.
If a panel has an independent sign-off and could potentially be shared on its own, then it should be represented as a DiagnosticReport.
I don't get the sense their "panels" would have independent sign-off? @Larry Babb or @Mullai Murugan ?
They would have value on their own.
If it just includes a couple of high-level summary observations that describe the overall results of the different tests in the panel, you could still do that using Observation.
Not sure I know how to help distinguish between 'high-level summary observations' and 'conclusion on DiagnosticReport' ?
Larry Babb (Mar 14 2019 at 22:00):
The panels would NOT have independent sign off. I’m not sure how that would work. If they had independent sign off then it presumes they could be sent out independently. Conceptually that could but alone they wouldn’t satisfy the requested service, which is designed to deliver all the conclusions together with an overarching summary.
Bret H (Mar 19 2019 at 15:37):
the component observations are required to understand the 'overall interpretation' correct? @Larry Babb
Larry Babb (Mar 20 2019 at 23:59):
It's not that simple I think. I've spoken with a geneticist that works on designing WES test and reporting and it is true that there isn't one set way to design these reports. In some cases they will use the report's "overall" or "main" interpretation/conclusion to represent a result for the primary indication for testing (e.g. molecular diagnosis for HCM, or familial history of Hearing Loss, etc...) but there may also be additional (sort of supplemental) results returned related to the indication (like PGx related results) or blood group assessment or polygenic risk scores. And it is even more ambiguous when these tests are designed for clinical research studies like eMERGE where they report a general set of results for PGx related genes, and test a broader spectrum of genes for the purpose of a study.
So, it does seem (to me) that there is a lot of variability that the reporting labs use when defining these composite report models. It may be good to do some deeper analysis, but this does beg the question of why we wouldn't design a model that permits nested reporting? Isn't it logical that reporting practices would benefit from being able to deliver composite results and not be limited to a one overall interp per report model?
Kevin Power (Mar 21 2019 at 16:26):
I agree we want a model to handle these composite reports (I like that name), and we are trying to come to conclusion on the best way(s) to accomplish it. We have options to support this with our current model, just need to write up guidance - mostly have to related the multiple DR's
Bret H (Mar 25 2019 at 11:52):
don't forget about region studied, and a space for defining what was able to be reported on (e.g. 'studied gene region X, Y' but only was able to report on 'Y' as 'X' was of poor quality) in the model.
perhaps even an optional pointer to the labs NGS data repo, VCF or original media results (e.g. FISH image, etc...) for recall - for a research network such as EMERGE it seems reasonable that study partners would communicate the location, especially if in a federated network, at least using an identifier and relative location (something the owning network could use to find or execute on the data).
Kevin Power (Mar 25 2019 at 13:36):
Yes, those will still be in the model. I wasn't trying to imply that my quick summary was all inclusive.
Bret H (Dec 17 2019 at 17:05):
so this was helpful for me as part of the argument for something like conclusion from diagnostic report being added to observation. statement is like conclusion in diagnostic report, but to be placed in variant observation. 'bundle of interpreted knowledge' will need provenance. The link to a resource like ClinVar is considered not sufficient for this purpose.
Bret H (Dec 17 2019 at 17:08):
my contention is that the statements I have seen can be discretely represented - but if the intent is summary statement with provenance that is like interpretation but textual to be delivered as as summary of the discrete profiles that capture variant data, inherited disease pathogenicity, then the field would be safer. My fear is replacement of using the variant fields etc with only populating the text field
Jamie Jones (Dec 17 2019 at 17:08):
This is the "lab's workflow and justifications" I was trying to communicate the other day
Bret H (Dec 17 2019 at 17:08):
@Larry Babb @Mullai Murugan thanks for today's talk. it really is clarifying
Jamie Jones (Dec 17 2019 at 17:10):
If our implications become a list of components, we could use the value field to have them give their own narrative. Do run the concern with them not populating any of the components, so may have to set them to required (1..1/etc)
Jamie Jones (Dec 17 2019 at 17:10):
Suggest not adding text field to Variant, just to implications
Jamie Jones (Dec 17 2019 at 17:11):
As those are separate observations made by the lab about the variants, and they can describe the methods and references there
Bret H (Dec 17 2019 at 17:23):
tricky. but we're not talking about knowledge, we're talking about interpretive guidance that includes knowledge + a human. it is ephemeral and sometimes almost verbatim from a knowledge resource like ncbi's gene pages (like a reinterpretation of knowledge). The element needs provanance, perhaps this is gained int he instance of the profile by other elements. A FHIR data architecture question is: how is this really different from Narrative? other than making sure other important fields are populated, this is an important question. Third would be - how much can be inherited form other elements within the profile.
Bret H (Dec 17 2019 at 17:27):
lastly need to support why using Diagnostic report conclusion is not sufficient - for example, with nesting of diagnostic reports I could get a diagnostic report conclusion field for every variant (just technically possible). TO SUM UP: Need to support why on the VARIANT Observation Observation.narrative and Observation.code are not sufficient. @Larry Babb
Jamie Jones (Dec 17 2019 at 17:29):
I'd also love to see this level of guidance be generated solely from coded elements, but I don't think we're there quite yet. For a few limited use cases we could do it now, but if we try and set rules for all of the different logical structures that labs want to make here, the model may be overwhelming.
The observation value would be included in generated narrative, but I agree we need OO guidance on this "panel with narrative summary" pattern.
Jamie Jones (Dec 17 2019 at 17:41):
My understanding is that Observation.Text isn't supposed to add meaning on top of the combined elements.
It feels we are being asked to add additional subtle value that is difficult to capture in coded components.
Last updated: Apr 12 2022 at 19:14 UTC
