Stream: genomics / eMerge Pilot
Topic: Report Comments
Larry Babb (Jun 18 2019 at 19:22):
eMERGE and other clinical genetic test results have a comments or additional notes section with case specific information. These comments are not really recommendations, conclusions or observations. They are additional information that the reporting lab wants to provide the ordering physician and patient related to the outcomes related overall or to some grouped set of results.
We would like to have the flexibility of identifying these zero to many (0..*) comment blurbs at the DiagnosticReport, Observation and/or Observation Grouper levels.
We see the availability of the Observation.note:Annotation and feel it may be a good candidate, but are not sure how we might distinguish notes that are "comments" from notes that might be for other purposes (maybe this should not be a worry if we dedicate "note" for only comments?). There doesn't seem to be a good answer for DiagnosticReport.
Our other thought was an "extension" for "comments" similar to supporting-info (which we don't think is the right fit).
Finally, we thought that maybe we should create a "special" Observation profile for "comments".
In any case, we'd love to hear how CG WG would address this requirement. Any help would be greatly appreciated.
Kevin Power (Jun 18 2019 at 20:04):
We would like to have the flexibility of identifying these zero to many (0..*) comment blurbs at the DiagnosticReport, Observation and/or Observation Grouper levels.
Usually the question that is asked: If a query was done, and the only thing returned was this "blurb" - would it be useful by itself? Or, to be useful, does this blurb need to be delivered along with the thing the blurb is related too (a Variant or an Implication let's say)? That will first help us answer if it should be its own instance of some resource first.
Given your comments, I think the answer is that the context is important.
Jamie Jones (Jun 18 2019 at 21:50):
I believe Lloyd said Observation.note is intended to be notes "about" the Observation and shouldn't really contain content. I think the most natural place for this would be a component (with valueString) on OverallInterpretation or on Grouper.
Kevin Power (Jun 18 2019 at 22:11):
I do concur on the note - that doesn't seem quite right.
If the blurp is always related to one and only one of our Observations, then a component on almost every profile would make sense. The component just on Overall Interp and/or Grouper would also make sense if the blurps are related to multiple other observations.
Larry Babb (Jun 20 2019 at 13:07):
Thanks guys. Very helpful. We will avoid using note as we were unsure about it use until now.
These "comments" or "additional notes" are important to convey, but have not evolved to the point of being able to structure or codify by the labs and providers yet. (seems like there's bigger fish to fry at this point). However, it does seem like the downstream systems would want to query the diagnostic report or observation grouper (and possibly any observation) and ask whether there are any additional comments or notes provided by the service provider. Granted this wouldn't be very useful in a computational algorithm but it would enable the downstream applications to send it to a UI or report for human consumption. I think that's all we are asking for at this point.
I'll look into the component option, and likely add this to our emerge solution. Since component is not an option on the Diagnostic Report, we will presume that all "comments" will need to be expressed at an observational level. This may force our hand at always providing a "grouper" just for the mere fact that we may want "comments" on the overall report. This continues to surface the need for more flexibility at the DiagnosticReport level for things like this (I think). Either that or treating this "comment" like a separate observation that could be tied to the DR or a group and not limited to the component option that is always dependent on another type of observation. (I do wish there was some more straight forward way to handle this kind of thing).
Kevin Power (Jun 20 2019 at 19:00):
This would make a fine question to #Orders and Observation WG if you want some other perspectives?
Patrick Werner (Jul 30 2019 at 16:53):
Hi,
during todays call we discussed GF#20978 and GF#19827 both submitted by @Mullai Murugan
Patrick Werner (Jul 30 2019 at 16:55):
*wanted to discuss. We skipped our discussion as these two issues were originating from the emerge project.
Patrick Werner (Jul 30 2019 at 17:08):
I personally see a pattern with comments, additional methodology or additional textual interpretations information. These all should be able to be attached/pointing to an Observation, group of Observations or the Report.
They have a textual part, maybe an author, maybe a timestamp and a Coding expressing if this is additional method text, textual interpretation and so on.
So this could be done by a FHIR document with a composition pointing to the Observations and Diagnostic reports but i think this would be a wrong usage of a document, as the section.text is meant as an human-readable narrative and not as a container for extra text parts.
Patrick Werner (Jul 30 2019 at 17:09):
At first i was looking at the related artifact Extension, but it is focused on citations to support your findings.
Patrick Werner (Jul 30 2019 at 17:16):
To also face the problem that if you use a component or Observation.note you can't use it on DR i would lean towards an Extension like dr-relatedArtifact.
But with the datatype Annotation, and a coded type expressing: method|comment|interpretion.....
Patrick Werner (Jul 30 2019 at 17:16):
This then can be attached to Observation, the Grouper or the Diagnostic Report
Patrick Werner (Jul 30 2019 at 17:17):
long story short: CG also needs this and it would be ideal to come up with a compatible solution for emerge as well.
Kevin Power (Jul 30 2019 at 17:28):
Also tagging @Larry Babb -- would be helpful for Larry or @Mullai Murugan to comment on what they landed on in the short term for eMERGE.
Larry Babb (Jul 30 2019 at 19:56):
about the comment extension
emerge is defining its own extension for comments which can be applied to observations and diagnosticreports. I originally thought of using Narrative but decided to keep it simple and stick with datatype "string". We can use your extension if you provide one in the near future.
regarding the textual interpretations - we are creating a separate extension for that as well - again as "string".
regarding methodology we are using the PlanDefinition and its action[] array to describe the genetic test panels and their methodology steps in a way that will be consistent across multiple instances of DRs & ServiceRequests for the same test definition.
Patrick Werner (Jul 31 2019 at 09:48):
We can use your extension if you provide one in the near future.
I made a quick scratch:
https://simplifier.net/patrickssandbox/comment
Patrick Werner (Jul 31 2019 at 09:50):
so this is a complex extension containing the type to express what kind of comment it is (needs a binding), and a Annotation datatype.
So this is basically Observation.note, but with a type and applicable for Observations and DiagnosticReports
Patrick Werner (Jul 31 2019 at 09:54):
This alligns with my tracker: GF#22102 asking for a type inside of Annotation. Will ask O&O once more on a opinion on this.
Patrick Werner (Jul 31 2019 at 10:04):
also asked O&O on their opinion: https://chat.fhir.org/#narrow/stream/179256-Orders-and.20Observation.20WG/topic/Notes.20on.20Observations.20and.20DR/near/172114099
Patrick Werner (Jul 31 2019 at 12:03):
rob replied and asked for examples. As our examples are german could the eMerge project provide an example of an report and the textual parts which are added as comments?
Larry Babb (Jul 31 2019 at 15:19):
One of the 2 sequencing centers uses the caption "Additional Notes" which we discussed are similar to "Comments" and we are considering the same. So your "type" and bindings should provide the nice option to discern when the comments are general or additional or whatever...
I'm not sure we (emerge) needs the Annotation type since it is not necessarily important to track the author making the comments, but I don't think it will hurt if we don't use it.
Here's some example blurbs from an actual reports along with the report heading they are shown within by each sequencing lab...
Addtional Note 1
Disease penetrance and severity can vary due to modifier genes and/or environmental factors. The significance of a variant should therefore be interpreted in the context of the individual's clinical manifestations.
Additional Note 2
Variants of unlikely clinical significance are not included on eMERGE reports but can be shared separately. Please note that variant classifications may change over time if more information becomes available. Please contact us at xxx-xxx-xxxx or xxx@xxx.xxx.
Additional Note 3
We cannot exclude the presence of a variant in the following gene(s) due to <95% coverage at 20x*: KCNQ1 (94.7%), ....
- Additional information (gene and variant lists as well as reference sequence) available at http://lab.hostname.org/xxx/.
Comments
It is recommended that correlation of these findings with the clinical phenotype be performed. Genetic counseling for the
patient and at-risk family members is recommended.
Let me know if you need more examples.
Patrick Werner (Aug 06 2019 at 14:32):
thanks Larry, we will talk about this topic in todays CG call
Larry Babb (Aug 20 2019 at 13:56):
@Patrick Werner how is this coming along? I spoke with Clem McDonald and we discussed whether I was supportive of this approach for the "Summary Interpretation" and "Comments" extensions we have developed for our eMERGE project. Clem and I have seen a very consistent need for "interpretation text" at an observation level in most (if not all) clinical test results we've reviewed over the years. Clem thinks that it may be cleaner to have precisely named extension element for this field on the Observation class. We also see "Comments" and "Notes" on the report with information that may or may not be case specific (usually has some context to the case). While these comments and notes are not "results" they are pretty common and would be helpful to structure in a discrete way in the returned DR message.
I'm a bit on the fence as I do not want to presume we can cleanly define all the various types of annotations that labs will make or want to make on reports and at various levels within the reports. I'm thinking it may be more prudent to take the approach you are advocating with the designed type/annotation extension above. This will allow implementers to begin devising "type" codes that fit their needs and over time we may see patterns that warrant more of a "first class" named element change.
This is tricky stuff as it is nearly impossible to predict the use. But it is very clear to me that there is a need for labs to create annotations and discriminate between the types so that the consuming systems can identify and use them appropriately.
Please share any advances you are making with this extension. I will try to model it for pilot use in our work if it helps us avoid having to manage 2 or 3 new extensions that have similar patterns.
Let Clem and the group know that I'm happy to come and discuss this at one of the meetings. Or even present the current state of the emerge implementation guide.
Thanks.
Bret H (Aug 21 2019 at 03:53):
Are these all disclaimer types of information? Or are they vital to clinically interpret the result? @Larry Babb How does emerge indicate the difference?
Patrick Werner (Aug 21 2019 at 09:17):
thanks @Larry Babb for the examples. I copied them to the O&O discussion of this topic:
Patrick Werner (Aug 21 2019 at 09:19):
Larry Babb (Aug 21 2019 at 13:02):
The labs that include these "comments/notes" and "disclaimers" have different motivations for each, and they don't necessarily all treat them the same way. So, it is not something that is easily put into a neat model.
Regarding Comments and Additional Notes...
The labs, often and frequently want to add comments or notes that are case specific and don't have the weight of an observed result that can be codified and formalized. It can range from additional information about the testing process, the sample, the assessment data, etc.. It may be informative for one of several identified and assessed variants or a general statement about a subset or all of them together.
However, the lab may provide general information, suggestions or guidance to the patient and physician as well.
Regarding Disclaimers...
There is really only one that I am familiar with that most labs put on their reports (it is likely a CLIA requirement - but I am not certain). The disclaimer is not case specific. The particular disclaimer I need to call out is about a class of test types (lab-defined genetic tests). I believe each lab can write it in their own words but it must contain similar meaning and there may be some required phrasing (again, not sure). So the disclaimer is really on the report or the test definition - possibly. I ended up placing it on the report, as there is no good place within the PlanDefinition (which i am using to describe the test performed) to add a "disclaimer".
Larry Babb (Aug 21 2019 at 13:11):
@Patrick Werner as I'm thinking more and more about your Annotation extension, I'm wondering how it will be more formally defined. Is it meant to be treated as an "annotation" on the DR or Observation from which it will extend? If so, I'm not sure these comments/notes/disclaimers are really "annotations". I could be confused about what an annotation truly means and the way it will be described herein. If the annotation behaves like an element of the Observation and DR then I'm okay with it. If it behaves more like a secondary or external statement or assertion about the DR or Observation then it will not work for my purposes.
If this Annotation extension is seen as a useful extension for the purposes described herein, then why wouldn't it be used for things like supporting info and recommendations, etc..? In a way, these are very similar to the pattern I am looking for for comment/notes, disclaimer and also interpretation summaries.
Sorry if I'm getting way off track. I could use some help figuring out if I should be investing more energy into finding a common solution with this approach. I only have so much time to devote to these things and I must make progress.
Kevin Power (Aug 21 2019 at 13:59):
@Larry Babb - You may want to comment on the thread Patrick referenced in the O&O Stream:
https://chat.fhir.org/#narrow/stream/179256-Orders-and.20Observation.20WG/topic/Notes.20on.20Observations.20and.20DR
I think the general consensus of the CG group right now is that this should be a more general solution, and not something specific to CG. So it will likely come up through O&O, but hopefully with our input and guidance. So any feedback we can give will help develop a solution that will work for us.
Larry Babb (Aug 21 2019 at 14:21):
Thanks @Kevin Power I read the OO thread. And it seems to be forming and shaping into something that will partially solve my needs. I think for now emerge will continue with our own extensions. I just seems like it provides us the control we need to get to a final and complete solution even though most it will need to change later based on how these developments go. I do agree with Lloyd's clarification on Annotation - it didn't really sit right with me as well and he helped clarify why. Somehow "Disclaimer" got lost along the way (I think) - this is not a note or interpretationNote or Annotation either I suspect.
And I'm still not sure how this new solution (using Observation.component) will work for the ObsGrouper profile. We do have the need to put summary interpretation text/notes on the collection of observations that fall under a group. If Lloyd is suggesting that we can do an interpretationNote extension on the DR, then could we also do it on the ObsGrouper (since it acts much like an sub-report for organizational purposes)?
I wish I had the time and energy to get more involved in all the various threads and groups to assure that the needs I'm seeing in the real world will be handled well.
Jamie Jones (Aug 21 2019 at 14:55):
I think @Lloyd McKenzie suggests the notes at the DR level because they are meaningful to have there, but was also implying that if you want consumers to reliably find those notes when viewing any particular result Observations, the information also has to be on (or referenced on) the Observations themselves. It can't be assumed a system will go back up to the report and then find the disclaimer from there. The situation should be the same as with Grouper Observations, unless there's a caveat I'm missing.
Lloyd McKenzie (Aug 21 2019 at 14:59):
That's correct. Information on the DiagnosticReport cannot be inferred to apply to the Observations pointed to by the DiagnosticReport (and downstream systems might have access to the Observations (e.g. a particular variant assertion), but not the DiagnosticReport that Observation was originally a part of.
Larry Babb (Aug 21 2019 at 21:49):
that makes sense and is fine for this use case. these summary notes on groups of observations (or for the entire set of observations) should not live with the individual observations since the context would be lost in relation to the set of observations the note is intended to cover. I plan on applying this extension to both DR and Observation Grouper (obsGrouper) and Observations in general so that labs can place notes where ever they see fit.
Last updated: Apr 12 2022 at 19:14 UTC
