Stream: Orders and Observation WG
Topic: Notes on Observations and DR
Patrick Werner (Jul 31 2019 at 10:03):
The clinical genomics WG has the need of notes on Observations, as well as notes on DiagnosticReports to include a narrative of the used method(s) or other textual comments which often times is half a page or more.
During the may WGM Observation.note was suggested.
This could work, but:
- note doesn't contain a type to express the type of note
- note doesn't exist in DiagnosticReport
My first idea was to add type to the Annotation data type: GF#22102 which would solve the type problem but not the "notes on DR" problem.
What does O&O think?
Rob Hausam (Jul 31 2019 at 12:00):
@Patrick Werner At least at first glance this seems to me like a pretty reasonable request, and possibly solutions. We'll need to have some further discussion of it, of course. I can try to review what we have from the discussion in May. Would you be able to provide some further details and ideally example(s) of the information that you want to include this way?
Patrick Werner (Jul 31 2019 at 12:17):
Thanks Rob, i asked the emerge project about an example as our examples are german ones. Will post these as soon as i receive them.
Eric Haas (Jul 31 2019 at 17:17):
When you start wanting a note type it sounds like you want more than a note or annotation. I think these are component or free standing observations. So it will be great to see example instances (German is fine) and see what existing options exist or whether Need to add to the spec.
Lloyd McKenzie (Jul 31 2019 at 17:20):
Key question is whether it's a situation where different people will be capturing comments over the lifetime of the Observation/report (especially after they are final). If so, and if there's a need to sub-categorize (and you're expecting multiple note repetitions for a single category), then adding a category to Annotation might be reasonable. However, if the intention is to capture a bunch of 'categorized' string fields that are part of what's captured by the lab and the "who said it and when" doesn't much matter and you're not expecting the notes to be captured after the observation/report is final, then agree with Eric that component is probably better.
Rob Hausam (Jul 31 2019 at 18:01):
Eric said component or free standing observations. I'm a little skeptical about whether component would be the right fit for this, but first it would be good to look at some examples.
Patrick Werner (Aug 21 2019 at 09:18):
I got some eMerge examples:
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.
Rob Hausam (Aug 21 2019 at 12:21):
Thanks, @Patrick Werner. These do seem to be additional notes that are intended to aid the clinician in interpreting and using the results (and in the past I've seen plenty of similar notes that often are included for relatively complex tests and results like this). And I think they truly are notes and wouldn't be separate observations/components. I'm somewhat inclined to agree with your suggestion in GF#22102, but the Data Types are owned by FHIR-I and are normative. You likely would need to use an extension for now, and maybe this could be considered as a change for R5? I also wonder if adding a separate 'interpretationNote' element as an Annotation (without changing the data type) would be even clearer and better? There is still the issue of changing a normative resource, but it wouldn't be a breaking change (and it is under OO control). You could also make 'interpretation' a backbone element, but that would be much more disruptive and I don't think it would be considered. I do think that adding a 'note' (and potentially 'interpretationNote') element to DR would be reasonable.
Lloyd McKenzie (Aug 21 2019 at 12:24):
"Annotation" isn't really for capturing notes made at the time the result is created. It's more for capturing comments after the fact - that's why we care about the author and the timestamp so that we know who said what, when. If we're capturing additional discrete data as part of an Observation/report, then we should be looking at components (or extensions for DiagnosticReport).
Rob Hausam (Aug 21 2019 at 12:36):
That's a reasonable point about Annotation. But these notes aren't additional discrete data that is being captured. They are explanatory notes included to aid in the interpretation and use of the results. So maybe 'interpretationNote' (with an appropriate data type) is what is needed (as an extension now and possibly added for R5, to both Observation and DiagnosticReport?).
Lloyd McKenzie (Aug 21 2019 at 13:53):
Extension on DiagnosticReport makes sense to me. For Observation, I have a bias towards using Observation.component if the information is describing/qualifying the reported result - which is what the interpretation notes seem to be doing.
Rob Hausam (Aug 21 2019 at 14:04):
I think the way to decide whether it's a "note" (in whatever flavor) or if it's a component is whether or not the notes are specific to this particular instance of the observation, or whether they are more general and the same (or very similar) note is included for each instance of this type of observation (likely based on Observation.code). In the former case I think that component does make sense, and in the latter I think it's an "interpretation note" (however we decide to handle that). The examples that @Patrick Werner gave I think fit more into the latter category of being general based on type (but he can say what he thinks about that).
Kevin Power (Aug 21 2019 at 14:22):
I think @Larry Babb would say there are classes of these 'notes' that fall into both sides - some are specific to a particular instance of an observation, others apply more broadly.
Rob Hausam (Aug 21 2019 at 14:23):
agree
Lloyd McKenzie (Aug 21 2019 at 14:26):
If they apply to the 'type', then they'd ideally be on the ObservationDefinition. However, the reality is that in v2, they'd all be sent as an OBX, so I'm not sure why FHIR would try to make a distinction...
Rob Hausam (Aug 21 2019 at 14:26):
in V2 lab reporting I think we handle them all in essentially the same way
in FHIR I guess we need to decide if we should/want to make a distinction
Rob Hausam (Aug 21 2019 at 14:26):
had almost the same thought at the same time :)
Kevin Power (Aug 21 2019 at 15:15):
@Patrick Werner - Perhaps we should broaden the scope of GF#22102, and include Larry's other examples that are not methodology related?
Eric Haas (Aug 21 2019 at 15:22):
I not sure what it is buying you to slice and dice these notes into further subcategories. Is the clinician going to care or misunderstand that one note is boilerplate for observation A vs a another that is specific to it? In the end we read display them them all in a report
Lloyd McKenzie (Aug 21 2019 at 15:25):
There's "what does the clinician care about?" and there's "how do systems stick the information into their databases?" and there's "are there specific business rules about what must be present and when?". All of those can influence what's captured as distinct elements.
Larry Babb (Aug 28 2019 at 12:50):
@Mullai Murugan and I need to be able to share "notes and comments" that the results interpreters and test performers include at report, observation group and observation levels as part of the signed out information. We are not in a position to do an exhaustive analysis with the labs to find out all the uses of these notes and comments, but they definitely seem important enough to be included on the report.
If we make them separate OBXs or Observations in FHIR, then I would need to provide the linkage to point them to the one, several or report level that they are commenting/noting about. So that seem less than ideal. I'd also have to codify them which I suppose is possible (assuming there's at least one LOINC code that means "comment"). But this seems less than ideal
If we go with an "interpretationNote" extension on the DR and use a codified component on the Observation and Observation Groups, then i would need a "code" for the Observation.component, please suggest if you have one or let me know if I can simply go with a codeableconcept.text approach.
I would like to allow the authors of the report to be able to label the notes as they see fit. This labeling (Additonal Note 1, Comment, Disclaimer, etc...) is useful and helps add context that the human consumer needs to put the note in perspective. So, in light of the fact that I believe it is quite unrealistic to figure out every type of "comment/note" labeling that lab reporters would want to provide, I think I should allow the note to be passed as markdown or xhtml rather than just a simple string. If I use a string value then I think I will need a "label" or "type" field that allows the reporters to label or type the notes and provide the context (kind of comment) it is.
I understand the rationale of all the arguments made above. But I simply need a solution that I can apply now. One that allows the producers of reports to convey "note-like" text blurbs with some form of label, heading or type that enable the downstream systems to store it in a place related to a report or observation object so that it can help communicate information that the reporter feels is useful to the consumers.
I was starting to lean towards @Patrick Werner s solution. I do agree that Annotation seems more like a comment that is made by some party after the report is created are made not as part of the returned report contents. I do think it is important to provide a context, label or type that the reporters can convey with their text blurb and possibly include links and such. I recognize that users could misuse this field to send true observation data in an less structure or unstructured way which may provide the opportunity for bad behavior, but I believe that guidance and definitions are our best defense against those that misuse these structures for unintended use.
In any case, I think @Mullai Murugan and I will be likely creating our own extension to pass markdown or xhtml text blurbs as "interpretationNote(s)" on either DRs or Observations unless you guys can provide a clear and straightforward solution to this requirement.
Any help in this direction is greatly appreciated.
Lloyd McKenzie (Aug 28 2019 at 17:43):
Generally, reports are treated as having only one author - the lab. Responsibility for individual pieces is generally not reflected in the report. Do you have a use-case to differentiate where different people in the lab are uniquely attributed to specific comments/observations?
Larry Babb (Aug 29 2019 at 14:09):
No. these comments and notes are part of the report and considered as part of the "sign out" process. There is no specialized attribution on these items. They are simply "text blurbs" that get placed at a report level, an observation level or an subset of observations. I do not need Annotation and think that it is not the correct data type for our needs.
Lloyd McKenzie (Aug 29 2019 at 15:57):
Ok. To have a general comment about an Observation, you could just have a component with LOINC code 8251-1 (Service comment). At the report level, you'd have a member Observation with LOINC code 86467-8 (Report comment).
Larry Babb (Sep 02 2019 at 02:23):
Thanks @Lloyd McKenzie . For comments at an observation group level would I use a the component method above on the "observation" that groups the other observations that the comment is about collectively? Or should I use a separate Observation off of the grouped Observation (like a nested report section) and use the (Report Comment) loinc code above to show that the comment is for all of the observations in the group?
Lloyd McKenzie (Sep 02 2019 at 14:29):
For a panel, I'd probably use the memberOf approach but either would be valid.
Andrea Pitkus, PhD, MLS(ASCP)CM, CSM (Apr 29 2020 at 13:17):
typically anything added after a report is finalized is an amendment or addendum to the report and follows regular requirements, including for corrections.
Andrea Pitkus, PhD, MLS(ASCP)CM, CSM (Apr 30 2020 at 00:04):
In DR, results are typically as observations or lab results. They are structured in a standardized way for pathology reports to communicate information about specimens unambiguously. The reason you want them structured as discrete data so they can be codified and utilized in clinical decision support, so they are computer processable. Also items which are part of panels need to be kept together for context and appropriate interpretation.
Andrea Pitkus, PhD, MLS(ASCP)CM, CSM (Apr 30 2020 at 00:10):
Typically I'd treat an interpretation as a observation/result value and it can be LOINC encoded appropriately. I wouldn't make them observation components or notes or other items.
Last updated: Apr 12 2022 at 19:14 UTC
