Stream: genomics
Topic: STU2 Theme: Implications
Kevin Power (Nov 18 2019 at 20:30):
I decided to split out the discussion around the STU2 theme of implications here.
On page 2 and 3 of the document where I put the themes, I have added a quick analysis of the types of implications we have today, and their corresponding answer lists. This typically comes up in every conversation, so I thought it would be helpful to see them all in one, hopefully easily digestible location:
https://docs.google.com/document/d/17r-HNm-gyqthepU40gqh39uYK9PV3HmBl1VM-vW6TuY/edit
Welcome any and all input and recommendations.
Jamie Jones (Nov 18 2019 at 20:31):
Great resource, thanks!
Jamie Jones (Nov 18 2019 at 20:40):
I added the article links you provided in the other thread for background on our profile outlines
Kevin Power (Nov 18 2019 at 20:54):
I have also added the ACMG guidance for inherited, and the additional MVLD paper.
Jamie Jones (Nov 18 2019 at 21:00):
I think it is beneficial to view not just the value lists but the components. Tough to keep the info contained/readable however
Kevin Power (Nov 18 2019 at 21:09):
Yup - looks like your draft used the current build, do you want to structure that for my branch?
Jamie Jones (Nov 18 2019 at 21:10):
Didn't realize you were building from the proprosal at first, I'll revisit
Jamie Jones (Nov 18 2019 at 21:18):
When making a list of selectable codes (as in http://build.fhir.org/ig/HL7/genomics-reporting/branches/kpower_SomaticImplication/valueset-somatic-classes.html), is there anything stopping us from updating the codes to LOINCs?
Need to also consider if we can/should have them validate on separate answer lists for Observation.value. My guess is best would be multiple codes corresponding to one common set of values, (@Patrick Werner suggested LOINC Answer List LL1971-2)
Kevin Power (Nov 18 2019 at 21:28):
When making a list of selectable codes (as in http://build.fhir.org/ig/HL7/genomics-reporting/branches/kpower_SomaticImplication/valueset-somatic-classes.html), is there anything stopping us from updating the codes to LOINCs?
Would be easy I think - but I couldn't find any LOINCS?
Need to also consider if we can/should have them validate on separate answer lists for Observation.value. My guess is best would be multiple codes corresponding to one common set of values, (Patrick Werner suggested LOINC Answer List LL1971-2)
I can see the argument for 'present / absent' as we did with Variant(Observation).value, though it does seem more awkward here. The problem is still how to best show / validate the relationship between the different codes -> values.
Bret H (Nov 21 2019 at 11:14):
@Kevin Power @Jamie Jones a profile off of an observation derived profile is a clear/clean way to indicate an observation.code and an answer list paring. For the general public, how is what is proposed better.
Bret H (Nov 21 2019 at 11:22):
A single profile with a constraint on observation.code and well named value sets is nice. But it is a bit of a half-way step towards moving away from multiple profiles. This is just a statement for clarity: The profiles give specific, computable instruction that a specific value set is used for a specific observation.code (or context). If we move to a single profile it is left to implementers to use the correct value sets. We can leave it to other groups to determine more constrained profiles - but this can lead to different choices in values sets for each observation.code. In other words, the single profile would enable/accommodate the current inconsistencies we see in value sets. Just a note - if we as a group favor simplicity in architecture then so be it. Look at the success of standards such as JSON or REST.
Kevin Power (Nov 21 2019 at 14:53):
I believe the primary concern with the specific profiles was generally "are we sure they are right?" By consolidating we become less prescriptive and allow for a wider variety of use cases. However, to no surprise I guess, we end up giving up some of the niceties with being more prescriptive.
Kevin Power (Nov 21 2019 at 15:39):
@Jamie Jones I would propose this be a topic on Monday's call, if that is OK. See if we can consolidate this feedback for discussion, and perhaps try to make a decision if the group wishes to move forward with this consolidation or not, given everything we have discussed recently.
Jamie Jones (Nov 21 2019 at 15:44):
Yes I agree, I think we can predict pros and cons on consolidation (and see where it may work and may be less effective)
Kevin Power (Nov 21 2019 at 15:54):
Would add that a decision to move forward would probably still not be a “final” decision. More likely it would be a decision to keep moving down this path and working up specific proposals for handling the issues we have seen so far.
Kevin Power (Nov 25 2019 at 22:44):
For all watching here - I moved the Implication Theme details into its own Google Doc.
https://docs.google.com/document/d/1SYdzxanCgkwzhhBJCBrguZ6H8HdjQFjG_l2nufAkCGU/edit
I created a 'brainstorming' section, and I would encourge everyone to get your thoughts documented. It seems we talk about edge cases a lot, but I would like to get them written down somewhere. In this case, I will take anything even if it does not include a specific proposal/change request. If someone is going to help drive this theme, I think this will help gather requirements.
Jamie Jones (Nov 25 2019 at 22:59):
I added the 7 or 8 things I can recall us talking about with them, there may be a couple others as well (and plenty I am not aware of!)
Bret H (Nov 26 2019 at 16:01):
boy this is getting obfuscated.
Jamie Jones (Dec 02 2019 at 15:07):
@Bret H @Kevin Power Thanks for getting the slides together with the PGx considerations. Will either of you be in the call today to speak about them?
Kevin Power (Dec 02 2019 at 15:07):
I will be there today.
Kevin Power (Dec 02 2019 at 15:08):
Though @Bret H did the hard work on the slides :slight_smile:
Bret H (Dec 02 2019 at 16:15):
put the slides into https://chat.fhir.org/#narrow/stream/179197-genomics/topic/slides.20PGx.20CG.20IG.20use.20and.20proposal.20components.20versus.20profiles/near/182361014 for comments
Bret H (Dec 02 2019 at 16:15):
please comment on the suggestions in the slides there
Jamie Jones (Dec 07 2019 at 02:26):
Our somatic prognostic profile is currently able to convey prognoses for outcomes of a given condition (cancer) for specific non-medicinal therapies. Is there any non-cancer analog for this in reports or is this truly a cancer-specific use case?
Bret H (Dec 07 2019 at 22:15):
@Jamie Jones can you unpack your comment? Are you asking : Does anyone have an example where the effectiveness of non-medicinal therapeutic option (like a brace) has a genetic variation associated with predicting the effectiveness?
Jamie Jones (Dec 07 2019 at 22:22):
Yes Bret, looking at which components from the somatic profiles can line up with the other PGx profiles and/or inherited disease pathogenicity.
Bret H (Dec 07 2019 at 22:23):
A major theme in things 'somatic' is weather the patient or the patient's tumor is the target. Very similar to pathogens.
Jamie Jones (Dec 09 2019 at 05:53):
Updated what I could see from the pgx proposal to http://build.fhir.org/ig/HL7/genomics-reporting/branches/kpower_SomaticImplication/artifacts.html
Kevin Power (Dec 09 2019 at 15:00):
That looks good. One thought - we may want to consider a new name for 'associated-phenotype' as it might be confused with what we are delivering in the 'component:medication-metabolism.'
Jamie Jones (Dec 09 2019 at 15:21):
We can edit the name to be more precise for the use-case, my bigger concern is if we are fine to reuse the LOINC code (https://loinc.org/81259-4/) in a different context, same I have with the associated-cancer concept. For context, Bret suggested we include this component here to be able to coordinate with component:medication-high-risk, so we can state what phenotype is being flagged as a risk.
Kevin Power (Dec 09 2019 at 16:34):
We can edit the name to be more precise for the use-case, my bigger concern is if we are fine to reuse the LOINC code (https://loinc.org/81259-4/) in a different context, same I have with the
associated-cancerconcept. For context, Bret suggested we include this component here to be able to coordinate withcomponent:medication-high-risk, so we can state what phenotype is being flagged as a risk.
In the case of PGx, I get Bret's request and it makes sense, but that doesn't feel like the same concept as represented in that LOINC code.
Bret H (Dec 09 2019 at 16:38):
We can edit the name to be more precise for the use-case, my bigger concern is if we are fine to reuse the LOINC code (https://loinc.org/81259-4/) in a different context, same I have with the
associated-cancerconcept. For context, Bret suggested we include this component here to be able to coordinate withcomponent:medication-high-risk, so we can state what phenotype is being flagged as a risk.In the case of PGx, I get Bret's request and it makes sense, but that doesn't feel like the same concept as represented in that LOINC code.
@Kevin Power can you expound what you mean by 'doesn't feel like the same concept?'
Bret H (Dec 09 2019 at 16:40):
the variant is connected through the implication. from LOINC code "The possible phenotype associated with the genetic variant found in this study" so having variant connected is relevant. in the context of the medication implication, one could say that the associated variant and medication
Kevin Power (Dec 09 2019 at 16:42):
I see it this way:
"here is the condition/disease related to a genetic change" (how we have used it to date)
versus
"here is something that might happen if you take this drug give the genetic change"
Kevin Power (Dec 09 2019 at 16:44):
I don't have a strong feeling about it, just feels different to me. I am fine keeping it the same if others are comfortable with it.
Bret H (Dec 09 2019 at 16:55):
It's what was there at the time. Could use something else, perhaps condition or link to MedicationKnowledge. Perhaps ask/demand : ^ ) that the Hl7 Pharmacy WG tell us what to do...punt to medication SMEs?
Bret H (Dec 09 2019 at 17:09):
aside: once we leave genetic finding and consider the annotations and context-dependent implications, we venture into aspects of pathology, diagnosis, pharmacy, etc... I know we've worked hard on these annotation/implication elements because they appear in current clinical genomic reports. Medication Task is a nice example of where existing resources/profiles outside of the genomics space were used. Hope more of our solutions in the annotation space can come from adopting the work of other HL7 WGs.
Jamie Jones (Dec 09 2019 at 17:31):
I see it this way:
"here is the condition/disease related to a genetic change" (how we have used it to date)
versus
"here is something that might happen if you take this drug give the genetic change"
I would love us to double down on this split in a proposal:
1. inh-dis-path combined with somatic-diagnostic,
versus
2. all the others unified into one profile (cancer or not)
would have to realign lists in #2 in terms of perspective but could provide mappings from current lists
Kevin Power (Dec 09 2019 at 17:32):
What would we call those two remaining profiles?
Jamie Jones (Dec 09 2019 at 17:33):
diagnostic implication and therapeutic implication
Jamie Jones (Dec 09 2019 at 17:35):
Both cancer and medicine would have to be optional, but I think I prefer that anyways. IGs could inherit either implication in multiple disjoint sub-profiles if they have stricter use-case requirements
Jamie Jones (Dec 09 2019 at 17:40):
It's what was there at the time. Could use something else, perhaps condition or link to MedicationKnowledge. Perhaps ask/demand : ^ ) that the Hl7 Pharmacy WG tell us what to do...punt to medication SMEs?
@Bret H I hear phenopackets has some potent ideas to represent this sort of thing. We need to push to reopen that discussion and either interface with that effort or align with it, as this is what research/labs may be looking to send here in the future.
Kevin Power (Dec 09 2019 at 18:34):
Hmm I like it.. let’s try it so we can see it?
Jamie Jones (Dec 09 2019 at 18:35):
I may be able to sneak it up today so we can look at it alongside the first approach tomorrow
Bret H (Dec 10 2019 at 02:42):
Phenopackets had a FHIR project ongoing. All it takes is a co-chair to reach out to them : ^ ) @Jamie Jones in the Sep meeting notes the contact left their email address. A difference might be knowledge versus annotation - but I digress. Would be lovely.
Bret H (Dec 10 2019 at 02:49):
Be careful about inheritance - its hard to see unless one looks at both the snapshot and the differential...But aficionados will know that.
Bret H (Dec 10 2019 at 02:50):
@Kevin Power how'd you get a space to publish in the FHIR build? Is this available to anyone?
Bret H (Dec 10 2019 at 02:50):
or only co-chairs?
Bret H (Dec 10 2019 at 02:52):
@Jamie Jones with prognostic, therapeutic and diagnostic implication - how do these differ from each other? Wouldn't you just end up with our current profiles but with different names and oncology possible folded back in?
Kevin Power (Dec 10 2019 at 02:55):
I think Phenopackets is a topic that has been on the agenda but perhaps not fully covered yet? I think it was @Bob Freimuth who was going to talk about it? Or maybe he did at WGM?
Kevin Power (Dec 10 2019 at 02:57):
Regarding “space to publish “ - since ours is an HL7 IG, it is hosted by HL7.
Bob Freimuth (Dec 10 2019 at 03:20):
@Kevin Power @Bret H GA4GH Phenopackets will be FHIR-ized. I was going to present that last week but we ran out of time. I will bring it to the group whenever we have the time on the agenda. (Nothing was known/presented at the WGM, but it was in place just in time for the GA4GH Plenary in October and it was announced there. We also presented it at the AMIA Annual Symposium in November.)
Bret H (Dec 10 2019 at 17:14):
@Kevin Power so as a WG member, can I use it to host profiles I've altered for specific exploration? Or ideas on changes? Or should only co-chairs be publishing to the space? Or at least co-chair approved changes? Here I am talking about the kevin branch.
Bret H (Dec 10 2019 at 17:15):
personally, having a co-chair involved is probably a good governance move
Kevin Power (Dec 10 2019 at 17:46):
If you define a new branch, it will be deployed as you see with the 'somaticeimplication' branch. If you wish to play around with your own branch, feel free.
Kevin Power (Dec 10 2019 at 18:52):
Practically speaking, I would NOT recommend anyone playing around with "anything" they want on a branch. I would say if the group has discussed something, and someone opens a branch to apply some changes for evaluation purposes, that seems perfectly logical to me. For example, if Bob D wanted to use a branch to do his Operation, that would be a perfectly valid use. And of course, this 'implication redo' makes good sense as a branch.
Jamie Jones (Dec 10 2019 at 23:02):
So what do folks think about aligning inherited disease pathogenicity and the pgx implications to the cancer splitting of use cases? (Diagnostic and Therapeutic)
Jamie Jones (Dec 10 2019 at 23:03):
And I know we currently have guidance to split off prognostic from predictive in the somatic profiles, but I think putting them as separate components keeps that distinction
Jamie Jones (Dec 10 2019 at 23:10):
In cases where somatic concepts are sometimes semantically about the effect on the tumor and not the patient, should we consider suggesting Cancer be modeled as a Condition/BodyStructure, and using Observation.focus to refer to it? Should look at other cancer IGs
I understand the scope of the Observation here is to comment on the variant/finding, but similar to how we have the option to link to current medication, we could link to a different resource if needed.
Kevin Power (Dec 10 2019 at 23:22):
So what do folks think about aligning inherited disease pathogenicity and the pgx implications to the cancer splitting of use cases? (Diagnostic and Therapeutic)
I like the idea of using the two profiles (Diagnostic and Therapeutic) as our baseline, then creating "Inherited Disease", "PGx", and "Somatic" pages in the IG as 'here is how you use our two profiles for these use cases'
Kevin Power (Dec 10 2019 at 23:29):
In cases where somatic concepts are sometimes semantically about the effect on the tumor and not the patient, should we consider suggesting Cancer be modeled as a Condition/BodyStructure, and using Observation.focus to refer to it? Should look at other cancer IGs
I understand the scope of the Observation here is to comment on the variant/finding, but similar to how we have the option to link to current medication, we could link to a different resource if needed.
When I think about Labs producing this data, asking them to link to other resources like that is going to be problematic - or at least I am fearful that it will be. I think the lab will say "Hey, we are not diagnosing or confirming a Condition, or even making the specific recommendation that you change the dose of Med X that the patient is on - I am simply making Observations, and am happy to provide you some codes (SNOMEDs, NDCs, etc ...) to things that might be related to these findings." If that is the thinking we will encounter, perhaps we should really focus on components only.
Or maybe I am completely missing the boat on it (at least equally likely :slight_smile:)
Jamie Jones (Dec 11 2019 at 16:26):
The 1..1 cardinality on Condition.subject rules it out, nevermind... Can't use it to talk about a cancer in a general sense, only in stating a patient has it... I'll keep looking to see if something other than a component might make sense
Jamie Jones (Dec 12 2019 at 21:12):
If it may help labs be more confident making implication Observations, we could suggest using Observation.focus to point to genomic findings rather than Observation.derivedFrom. This way they are explicitly stating that they are saying something about the data and not about the patient...
Any thoughts on that?
Jamie Jones (Dec 12 2019 at 21:42):
The textual implications in the reports I'm reading are often only tangentially related to the observed changes, much less the patients themselves...
for example, in one of the Foundation One reports, they report a stop_gained in the NF2 gene, show evidence that it likely leads to loss of function, and then go on to state that,
"Heterozygous germline NF2 loss or inactivation is associated with neurofibromatosis type 2 syndrome, which results in the development of vestibular schwannomas, meningiomas, ependymomas, and ocular disturbances (65,66,67). Prevalence for this disorder in the general population is estimated to be 1:25,00067."
It is quite tricky to report something analogous to this statement with the framework around our current inherited disease pathogenicity profile, since it is unclear if it even applies to the finding (which I assume is "somatic" or "likely somatic"), let alone the patient, and I don't have a great recommendation for how to encode the necessary caution in the context.
Jamie Jones (Dec 16 2019 at 14:06):
What if we put the entire text string of the implication in as Observation.Value? The components could still attempt to encode as much of the observation context/details as possible, and no details get lost in what the lab is trying to say...
Jamie Jones (Dec 16 2019 at 14:06):
That would certainly answer the question "what is the implication?"
Jamie Jones (Dec 16 2019 at 14:14):
The other option is leave value blank and put this in observation.text.div, which is html for human interpretation, but it wouldn't say more than the other fields in the observation
Jamie Jones (Dec 16 2019 at 14:25):
This would be very synergistic with the current paradigm of NLP research performed on clinical data, and wouldn't interfere with common systems that automatically generate the Narrative for Observation.text to summarize the whole resource.
Bret H (Dec 16 2019 at 14:28):
@Jamie Jones Your observations are consistent with statements made across labs and types of reports. Labs report finding a variant and then provide interpretative guidance - usually in the form of knowledge related to the variant and sometimes specific to the test 'name.' There are also reports that use information provided in the order. The specific statement you have mentioned includes 3 references - these can go into the related artifact link. The data on prevalence is interesting but we have not done much on it. The phenotype associated is "neurofibromatosis type 2 syndrome." Heterzygous germline NF2 could be stated with variant profile. Can you narrow down what you mean ? @Jamie Jones most of the statement has places in our current CG IG.
Jamie Jones (Dec 16 2019 at 14:40):
It's hard to extrapolate the full context here from just the narrative report (if only someone were trying to give them a more structured alternative!!) But my understanding is that the NF2 variant they observed is likely somatic origin and the patient would need follow-up testing (if clinical context suggested) to check for germline mutations indicative of the disorder. So, while our model of "here's a variant, here's a (potentially related) inheritable disease" does a good job in capturing the clinical actionability, it does a poor job of modeling the lab's workflow or justifications
Bret H (Dec 16 2019 at 14:42):
@Jamie Jones ?workflow? justifications? related artifact is a place for justifications. Workflow? what do you mean?
Jamie Jones (Dec 16 2019 at 14:47):
Before I get into splicing hairs here, are you thinking that the actual text of the observation should be present in observation.text?
Jamie Jones (Dec 16 2019 at 14:57):
Or would you suggest putting it into relatedartifact.display (string)
Jamie Jones (Dec 16 2019 at 15:00):
Relatedartifact.display should be a "brief description of the related artifact". Using that space to make the justification could be tight, and if you don't then you are requiring a reader to follow the citation or potentially miss the logic involved
Jamie Jones (Dec 16 2019 at 15:02):
I feel the lab should be able to make the statements however they want to make the statements and then tag the coded metadata (or approve/correct a system suggesting metadata tags based on the statement)
Bret H (Dec 16 2019 at 16:10):
"feel the lab should be able to make the statements however they want to make the statements" ? now I'm very confused. I thought we working in FHIR to provide a structure for reporting. Can you clarify what you mean? @Jamie Jones
Bret H (Dec 16 2019 at 16:13):
FYI .. conclusion I 0..1 string Clinical conclusion (interpretation) of test results
Bret H (Dec 16 2019 at 16:13):
in Diagnostic report there is a conclusion field that is string
Bret H (Dec 16 2019 at 16:13):
this is a fine place for lab to place a LAB generated summary statement
Bret H (Dec 16 2019 at 16:14):
That is what it is used for
Bret H (Dec 16 2019 at 16:14):
in pathology etc...
Bret H (Dec 16 2019 at 16:22):
I would recommend that any 'summing' up statements, i.e. conclusion, statements that incorporate data delivered in the associated observations (like a table of medications, variants and phenotype OR a statement like "Heterozygous germline NF2 loss or inactivation is associated with neurofibromatosis type 2 syndrome, which results in the development of vestibular schwannomas, meningiomas, ependymomas, and ocular disturbances (65,66,67). Prevalence for this disorder in the general population is estimated to be 1:25,00067") would go into DiagnosticReport.conclusion as a big string field.
Bret H (Dec 16 2019 at 16:38):
are you constraining to a specific type of conclusion?
Bob Dolin (Jan 02 2020 at 16:38):
I'm not sure if this is a bug or a feature or a misunderstanding on my part. Have we precluded adding additional components to the medication implication profiles? It looks like slicing is open but that all slices must have LOINC 51963-7. Similar situation for somatic profiles.
Bob Dolin (Jan 02 2020 at 16:38):
Jamie Jones (Jan 02 2020 at 16:40):
Great catch! That explains some errors I was getting previously in validation... I'll get a fix going shortly
Bob Dolin (Jan 02 2020 at 16:42):
Thanks Jamie. Here is the corresponding issue for somatic:
Bob Dolin (Jan 02 2020 at 16:42):
Jamie Jones (Jan 02 2020 at 21:15):
The extra constraints should be gone on the build version now. I also added proper slicing to Observation.category and DiagnosticReport.category, which we were similarly constraining on all slices (you could add multiple categories, but they all had to be the one we picked).
Bob Dolin (Jan 02 2020 at 21:16):
Great. Thank you Jamie. and Happy New Year!
Kevin Power (Jan 08 2020 at 15:38):
I wanted to restart the conversation between @Jamie Jones / @Bret H regarding where to place the 'summing up text' statements. Bret asked about using the DiagnosticReport.conclusion field - I am not sure that works, as many of the statements should probably be within a more specific context. I think I am OK with Jamie's proposal to use the Implication(Observation).text (or really any of our Observation based profiles) to keep this sort of info. Given the definition, I think it makes sense:
Observation.text:
A human-readable narrative that contains a summary of the resource and can be used to represent the content of the resource to a human. The narrative need not encode all the structured data, but is required to contain sufficient detail to make it "clinically safe" for a human to just read the narrative. Resource definitions may define what content should be represented in the narrative to ensure clinical safety.
Jamie Jones (Jan 08 2020 at 15:44):
Hoping to have some good examples for this by Monday, would love input from everyone
Kevin Power (Jan 08 2020 at 15:45):
@Lloyd McKenzie - Any concerns with using Observation.text in this way? Or is this better directed to O&O?
Lloyd McKenzie (Jan 08 2020 at 15:52):
So the intention would be to have an Observation where you just had narrative? I would think that code + value would be more computable...
Jamie Jones (Jan 08 2020 at 15:56):
Components would have codes and values, but the actual interpretive statement from the lab could be sent as Observation.text (or would value.text be more suitable?)
Kevin Power (Jan 08 2020 at 15:57):
We would still do all the codes we have today, but there is a need to include more human consumable textual narrative at times. An example was something like this (that I think would be related to an Implication, but others could be associated to Findings as well):
Heterozygous germline NF2 loss or inactivation is associated with neurofibromatosis type 2 syndrome, which results in the development of vestibular schwannomas, meningiomas, ependymomas, and ocular disturbances (65,66,67). Prevalence for this disorder in the general population is estimated to be 1:25,00067")
Lloyd McKenzie (Jan 08 2020 at 15:59):
So the issue is that Observation doesn't support valueMarkdown. I think that's a definite omission and would support submitting a change request to fix that. You need that to have the equivalent of V2's FT observations.
Kevin Power (Jan 08 2020 at 16:00):
valueString would be fine - don't know that markdown is needed in this case.
Kevin Power (Jan 08 2020 at 16:04):
We had considered introducing a new Observation.component[] as well if using Observation.text or Observation.valueString isn't right. But I think we need to pick one and do it. This continues to come up, and it seems like we should define a way to do this.
Jamie Jones (Jan 08 2020 at 16:06):
Markdown would allow the footnotes to function but we would be putting them in relatedartifact extensions
Bret H (Jan 13 2020 at 15:41):
@Kevin Power The best place is narrative, if you look at the content. Observation.text? not great as the statements are summing up statements. Observation.conclusion (a field that does not exist) would be closer in meaning to the summary. The summing up statements span more than one observation if you look at what Larry indicated.
Bret H (Jan 13 2020 at 15:42):
I do not think narrative has been explored enough. Again, the statements are often repreated almost verbatium from published sources
Jamie Jones (Jan 13 2020 at 15:42):
Isn't "Narrative" just the datatype for Observation.text?
Jamie Jones (Jan 13 2020 at 15:43):
It is inherited from domainResource, as I understand
Kevin Power (Jan 13 2020 at 15:43):
Yea, was about to ask what field you are talking about @Bret H ? There is not a field called "narrative" that I see?
Bret H (Jan 13 2020 at 15:44):
Yep. Text summary of the resource, for human interpretation
Bret H (Jan 13 2020 at 15:44):
good catch, trying to do to much at one time
Kevin Power (Jan 13 2020 at 15:44):
So, you are OK with Observation.text then?
Bret H (Jan 13 2020 at 15:44):
if the information is not found in the speifiic resource instance then it shuld not be in observation.text
Bret H (Jan 13 2020 at 15:45):
that's where thinking about X.conclusion comes in
Jamie Jones (Jan 13 2020 at 15:45):
yes, this is why my current push is for Observation.valueString
Bret H (Jan 13 2020 at 15:45):
The heart of the matter is who makes the statement. Look at a pathology report as an example
Jamie Jones (Jan 13 2020 at 15:46):
code as much as we can in components but still convey the lab's full statement as the value
Bret H (Jan 13 2020 at 15:46):
molecular pathology reports have a section that speaks to specific observations with an overall conclusion
Bret H (Jan 13 2020 at 15:46):
Nested diagnostic reports with diagnosticreprot.conclsuoin @Jamie Jones would do that
Jamie Jones (Jan 13 2020 at 15:47):
I agree, nested reports could also work
Jamie Jones (Jan 13 2020 at 15:47):
but I want the individual observations to stand alone with as much "value" as possible
Bret H (Jan 13 2020 at 15:47):
however, some of the conclusion comes from assimilation of knowledge beyond the observations
Jamie Jones (Jan 13 2020 at 15:47):
especially when we consider the ability to sort/filter them by level of evidence
Jamie Jones (Jan 13 2020 at 15:47):
or applicability to certain phenotypes
Bret H (Jan 13 2020 at 15:48):
so...is it a clinical statement with the evidence of the author of the report? or a lab finding?
Bret H (Jan 13 2020 at 15:48):
evidence 'as' not 'of'
Jamie Jones (Jan 13 2020 at 15:55):
I'm not sure how to answer that, our implications were meant to represent the statements labs make on the reports as I understand it. On reports they are often the conclusion of a complicated workflow of applying multiple/proprietary look-ups and using domain expertise
Bret H (Mar 31 2020 at 12:48):
Right. So, when a molecular pathologist signs off a genomics report - is the 'conclusion' which spans the entire set of observations now a clinical statement? w
Kevin Power (Mar 31 2020 at 13:06):
So Bret, my answer to your question is "yes" (I think). My overall take is that what we are representing with the Implication profiles closely aligns with the definition found in DiagnosticReport.conclusion 0..1 (string) and DiagnosticReport.conclusionCode 0..* (CodeableConcept). But there are two problems:
- Using these fields would require lots of sub-reports (and DR per implication seems like a lot)
- There are still other attributes on our Implications that would still need a home
Bret H (Mar 31 2020 at 13:08):
Ok. not sure we are talking about the same thing.
Bret H (Mar 31 2020 at 13:14):
@Kevin Power wouldn't your statement preclude the use of observation.text? unless you mean the pair of an implication observation with its observation.txt having a human readable summary - in which case that would be consistent with the use of the element in resources across FHIR. IF you are talking about summary information which goes beyond what is computable from the profile instance then it would not be good. Which did you mean?
Kevin Power (Mar 31 2020 at 13:38):
Maybe I should ask you - what definition/background info about Observation are you using to make your assertion about "consistent with the use of the element in resources across FHIR?" Perhaps we should work from that.
Bret H (Mar 31 2020 at 13:41):
Information on Narrative: https://www.hl7.org/fhir/narrative.html Observation.text has type Narrative: https://www.hl7.org/fhir/domainresource.html#DomainResource use of narrative is well defined in FHIR
Jamie Jones (Mar 31 2020 at 13:45):
Please remind me, we are considering here if implication text should be given in Observation.text vs Observation.note here?
Kevin Power (Mar 31 2020 at 13:46):
And this is what I get for not re-reviewing the full context of a thread before responding. I thought we were talking about using Observation.valueString() -- my apologies for the rabbit hole.
Bret H (Mar 31 2020 at 13:46):
"The narrative for a resource MAY contain additional information that is not in the structured data, including human-edited content. Such additional information SHALL be in the scope of the definition of the resource, though it is common for the narrative to include additional descriptive information extracted from other referenced resources when describing references. Narrative for a resource SHOULD include summary information about any referenced resources that would be required for a consumer of the resource to be able to understand the key, essential information about a resource without retrieving any additional resources." if the info is in a referenced profile then it is in scope for the narrative. But bear in mind if you have stuff in the narrative that is not represented in the structured data (i.e. not structured in referenced profiles or the specific profile) you can't compute on it as easily.
Bret H (Mar 31 2020 at 13:47):
want me to delete my comments?
Jamie Jones (Mar 31 2020 at 13:47):
I know I was pushing for valueString for a while, and as Bret has shown here I think I am converted to Observation.text
Jamie Jones (Mar 31 2020 at 13:48):
that said, our recent diagrams and guidance are highlighting Observation.note currently, which may be the wrong field to point folks to.
Kevin Power (Mar 31 2020 at 13:48):
Don't delete anything @Bret H -- But for clarity, do you mind stating where you think this sort of information best fits?
Bret H (Mar 31 2020 at 13:49):
I'm slow. can you clarify the information you refer too? sorry
Kevin Power (Mar 31 2020 at 13:52):
@Jamie Jones gave this example a while back:
"Heterozygous germline NF2 loss or inactivation is associated with neurofibromatosis type 2 syndrome, which results in the development of vestibular schwannomas, meningiomas, ependymomas, and ocular disturbances (65,66,67). Prevalence for this disorder in the general population is estimated to be 1:25,00067."
Bret H (Mar 31 2020 at 13:53):
perfect
Bret H (Mar 31 2020 at 13:56):
so, looking at an Implication profile. I would think that NF2 loss is found through the variant link. 'associated with neurofibromatosis type 2 syndrome' is in the profile component. The rest "which results in the development of vestibular schwannomas, meningiomas, ependymomas, and ocular disturbances (65,66,67). Prevalence for this disorder in the general population is estimated to be 1:25,00067." maybe in a related reference. So, why not put it into Oberservation.text? seems ok. Have to check that you can get the variant from the implication profile.
Jamie Jones (Mar 31 2020 at 13:57):
derivedFrom, for sure
Jamie Jones (Mar 31 2020 at 14:00):
My concern with using Observation.text is that it is 0..1 and normally generated. So you'd have to do some extra work to get it in the right place (likely some concatenation with your usual generation algorithm, which may lead to some awkward/repeated text). The spec says it shouldn't be lost if populated but that doesn't mean that it's easy to accomplish.
Jamie Jones (Mar 31 2020 at 14:06):
That said, I suppose asking systems to be careful with these statements from the labs isn't the worst guidance we could give.
Kevin Power (Mar 31 2020 at 14:09):
I will have to admit I was assuming that if we used Observation.text, these statements we are discussing would be the only thing there.
If we are concerned that these statements would be lost inside the rest of a typically generated Observation.text, then I am less interested.
Jamie Jones (Mar 31 2020 at 14:10):
I agree having them be the only thing there is best.
Jamie Jones (Mar 31 2020 at 14:12):
As long as we can agree it satisfies "It SHALL be safe to render only the narrative of the resource without displaying any of the resource's discrete/encoded information."
Kevin Power (Mar 31 2020 at 14:13):
That sounds EXACTLY like guidance we would include in our profiles.
Kevin Power (Mar 31 2020 at 14:14):
But to ask a question that was probably answered above, did we rule out using Observation.valueString ?
Jamie Jones (Mar 31 2020 at 14:16):
An issue Lloyd brought up was that it can't do citations well compared to .text's Narrative datatype and ValueMarkdown isn't an option. Pros and cons.
Kevin Power (Mar 31 2020 at 14:30):
Well, citations don't work well inside an otherwise generated .text Narrative either right? :slight_smile:
Patrick Werner (Mar 31 2020 at 14:33):
:thumbs_down: for Observation.text. Nobody looks at this, and it should represent the content of the resource.
Patrick Werner (Mar 31 2020 at 14:33):
Also gets autogenerated a lot. To me this doesn't feel save.
Jamie Jones (Mar 31 2020 at 14:36):
value feels safer for sure, I personally wish narrative were a useful field (as it is what gets rendered by default in systems) but it seems like it's used as a fallback and not a real view
Kevin Power (Mar 31 2020 at 14:42):
Other than being limited by the string datatype, any other arguments against .valueString ?
Patrick Werner (Mar 31 2020 at 14:50):
its the best we are having (valueMedia or valueDocRef would be my preferred choices, but Observation.component is restricted in its data types)
Vassil Peytchev (Mar 31 2020 at 14:53):
Does valueAttachment help?
Kevin Power (Mar 31 2020 at 14:54):
All of those feel too heavy - This is one of the examples of the value we are discussing:
"Heterozygous germline NF2 loss or inactivation is associated with neurofibromatosis type 2 syndrome, which results in the development of vestibular schwannomas, meningiomas, ependymomas, and ocular disturbances (65,66,67). Prevalence for this disorder in the general population is estimated to be 1:25,00067."
Jamie Jones (Mar 31 2020 at 14:59):
Currently no good way to link to those citations
Patrick Werner (Mar 31 2020 at 15:00):
Vassil Peytchev said:
Does valueAttachment help?
it is non-existing. But Kevin is probably right: This is about plain text so String should be sufficient (Strings max size is 1MB, should be plenty)
Bret H (Apr 04 2020 at 17:17):
Link to citations in relatedreference @Jamie Jones ?
Bret H (Apr 04 2020 at 17:17):
@Vassil Peytchev value attachment should be worth considering.
Bret H (Apr 04 2020 at 17:20):
Kevin Power said:
All of those feel too heavy - This is one of the examples of the value we are discussing:
"Heterozygous germline NF2 loss or inactivation is associated with neurofibromatosis type 2 syndrome, which results in the development of vestibular schwannomas, meningiomas, ependymomas, and ocular disturbances (65,66,67). Prevalence for this disorder in the general population is estimated to be 1:25,00067."
To give an example, in HL7v2 you'll find a note segment with 1 of two things - a string of text like kevin has above (string), or a pdf (attachment). Or sometimes a link to an pretty pdf. Systems handle the note segment with different levels of support. @Patrick Werner valid to say that observation.txt is not structured, often auto-generated, but it SHOULD NOT be ignored. systems need to be able minimally handle the observation.txt field as some systems maybe incapable of sending data anywhere else.
Bret H (Apr 04 2020 at 17:22):
The use of valuestring you suggest would superceede the function of observation.text, right?
Kevin Power (Apr 04 2020 at 17:39):
@Bret H — Yes I think we are talking about valueString or text
Kevin Power (Apr 04 2020 at 17:45):
I don’t think Observation has valueAttachment any longer. Some discussion about that with O&O in the past and think they considered bringing it back but I haven’t seen any official word on that.
But still, for these relatively small pieces of text, anything more than a string or maybe a Narrative still feels like too much. I am leaning more towards valueString all the time as our starting point and let’s see how the community reacts?
Bret H (Apr 04 2020 at 17:48):
Will the information in the valueString be guaranteed to be in Observation.txt (narrative)? i.e. the text would be in both places
Kevin Power (Apr 04 2020 at 17:51):
For the systems that generate text I would say yes, it would then be in both. But of course it is up to the system generating and/or returning the Observation
Bret H (Apr 04 2020 at 17:52):
ok. but minimally the information is in obersvation.txt, right?
Jamie Jones (Apr 04 2020 at 17:53):
That should be true for all our fields
Bret H (Apr 04 2020 at 17:55):
"Any resource that is a DomainResource (all resources except Bundle, Parameters and Binary) may include a human-readable narrative that contains a summary of the resource and may be used to represent the content of the resource to a human.
If narrative is present with a status other than 'empty', it SHALL reflect all content needed for a human to understand the essential clinical and business information for the resource. It SHALL be safe to render only the narrative of the resource without displaying any of the resource's discrete/encoded information. Resource definitions and/or profiles on resources MAY define what content should be represented in the narrative to ensure clinical safety." from https://www.hl7.org/fhir/narrative.html
Bret H (Apr 04 2020 at 17:55):
So we are safe. IF the instance has an empty observation.txt (no narrative) that is ok. - just to make it clear
Bret H (Apr 04 2020 at 17:57):
unless we define that something is needed in the narrative for safety
Kevin Power (Apr 04 2020 at 17:58):
I say we stay away from defining what to put in text and go with valueString guidance.
Bret H (Apr 04 2020 at 18:01):
it works for the example.
Bret H (Apr 05 2020 at 17:34):
However what makes it a result? and by the use of valuestring you're opening to misuse. But let's clarify why it makes sense as the value of the observation> You certainly cannot compute on it. but you can find it.
Bret H (Apr 05 2020 at 17:34):
is the statement meant to be the result?
Bret H (Apr 05 2020 at 17:34):
then what are the components and other data fields for?
Bret H (Apr 05 2020 at 17:35):
please clarify
Jamie Jones (Apr 05 2020 at 17:37):
You're right it would be a subtle departure from our usual patterns. It would be a textual value with components to clarify and attempt to encode as much of the meaning as we can
Bret H (Apr 05 2020 at 17:39):
good start, but that sounds a lot like observation.text
Bret H (Apr 05 2020 at 17:40):
its a queryable field - so ...
Jamie Jones (Apr 05 2020 at 17:49):
We can try uploading our examples to hapi and checking the queriability of .text based on what is generated from our coded components
Kevin Power (Apr 05 2020 at 17:50):
I think we have a disagreement on the actual usage of Observation.text - The more I look at it, I am agreeing with @Patrick Werner -- I think most system simply autogenerate Observation.text, and if we recommend doing something different with it, could we be making this harder to implement? Hence, I don't think I want to use Observtion.text unless someone can make a more compelling argument than I have heard so far.
Our problem has always been that we (rarely at least) has a single 'result' to represent our Observations - hence our abundance of components. It is hard (impossible) to point at a single thing and say "THAT is the result of our implication" as it takes all of the values to really tell the full story. To me, this 'summary text' thing is probably as close to a "result" as we would typically have.
So, at this point, perhaps we continue down the 'component' route. If we are uncomfortable with using Observation.valueString, perhaps we just add it as a new component?
Bret H (Apr 05 2020 at 21:21):
" "THAT is the result of our implication" as it takes all of the values to really tell the full story. To me, this 'summary text' thing is probably as close to a "result" as we would typically have." - from Kevin Power. and @Jamie Jones "It would be a textual value with components to clarify and attempt to encode as much of the meaning as we can" @Kevin Power @Patrick Werner @Jamie Jones it keeps sounding like observation.text...But were just working on a clear definition, how does this sound as a next draft of the definition : place where a summation of the implication can be found, it is not computable, for computable meaning the other components should be used. (it is weird to replicate the purpose of observation.txt which is for systems than cannot handle either sending or receiving the data fields but not the worst thing).
Bob Milius (Apr 05 2020 at 21:37):
I've been trying to follow this discussion, and I keep going back to the spec re the purpose of .text
https://www.hl7.org/fhir/domainresource-definitions.html#DomainResource.text
Definition
A human-readable narrative that contains a summary of the resource and can be used to represent the content of the resource to a human. The narrative need not encode all the structured data, but is required to contain sufficient detail to make it "clinically safe" for a human to just read the narrative. Resource definitions may define what content should be represented in the narrative to ensure clinical safety.
My understanding of this is that .text is a human readable summary of the resource instance. But, I'm not sure how this affects my thinking on this topic.
Patrick Werner (Apr 06 2020 at 08:54):
From a Implementer perspective: i need to put lab texts somewhere in my gui. I can't display Observation.text at this position, as i only want to display the textual additional lab guidance here.
If i would just display text, i would have a repetition of all my coded values and components.
Patrick Werner (Apr 06 2020 at 08:55):
So text is great as a Fallback in certain situations - but text has no structure, so i can't distinguish between parts of it.
Kevin Power (Apr 06 2020 at 13:07):
So, there are concerns with Observation.text, and with Observation.valueString - that probably leaves us with a new component. Any disagree, or want to still push hard for .text or .valueString ?
Jamie Jones (Apr 06 2020 at 13:14):
I find it cumbersome as to properly define that we will need a redundant code for the component. The description of that component's code will be 99% the same as the description of the Observation's overall code (:
Jamie Jones (Apr 06 2020 at 13:17):
We could phrase it to make sense though, and is probably the most consistent approach. To that end, it should be an unbound codeableConcept as ways to encode it in the future may be identified (and can just use component.value.text until then, same as we do for many concepts)
Kevin Power (Apr 06 2020 at 13:17):
I could see this 'additional-guidance' component being useful for several profiles, certainly the implication profiles, but I think Larry Babb was even thinking it would be helpful on Variant
Kevin Power (Apr 06 2020 at 13:21):
Jamie Jones said:
To that end, it should be an unbound codeableConcept as ways to encode it in the future may be identified (and can just use component.value.text until then, same as we do for many concepts)
Do you mean Observation.component[additional-guidance].code should be unbound, or we should deliver this guidance in Observation.component[additional-guidance].valueCodeableConcept and have it be unbound?
Jamie Jones (Apr 06 2020 at 13:31):
the latter--fully defined code for the concept and don't see why we'd want to bind guidance to a string.
Kevin Power (Apr 06 2020 at 13:33):
I don't see any way to bind the guidance to a code? All the examples I have seen of this sort of data is more like "hear is some additional text the lab finds important and would like to share"
Kevin Power (Apr 06 2020 at 13:38):
My opinion here - but I am not worried about this 'additional guidance' being searchable, computable, or coded. I think a string meets the requirements as I have understood them.
Honestly, if we didn't have a ton of baggage with Observation.text (as in how so many systems seems to auto-generate it today), I think the strict definition of it seems reasonable to meet our requirements. However, that baggage does make me leery of using it for this purpose.
Jamie Jones (Apr 06 2020 at 13:39):
Sounds like you're ready to make a proposal ;)
Kevin Power (Apr 06 2020 at 13:41):
I am - but like to test here first :slight_smile:
Jamie Jones (Apr 06 2020 at 13:42):
FHIR#26379, happy to put this to vote soon
Kevin Power (Apr 06 2020 at 13:48):
I think you can also use J#26379 ?
Jamie Jones (Apr 06 2020 at 13:50):
I think they are planning to port other non-fhir projects to Jira too and discouraged J# but don't quote me on it
Vassil Peytchev (Apr 06 2020 at 14:09):
On Observation.text auto-generation - is this really a verified problem? I think the reason you see auto generated .text in any resource is because implementers are urged to populate the field for human consumption. I don't think that means that when a legitimate .text content is present, it will be overridden by some auto-generated text. It might be worth it checking with #implementers
Vassil Peytchev (Apr 06 2020 at 14:10):
And lastly regarding options, has Observation.note been considered?
Lloyd McKenzie (Apr 06 2020 at 14:31):
Observation.text is intended to be a stand-in for the whole Observation. You're allowed to display 'text' instead of displaying any of the discrete data in the Observation. It's used as an either/or, not to supplement. (Though Observation.text may contain information the discrete data doesn't.) Observation.note conveys comments about the Observation - it shouldn't convey what was observed. Observation.valueString conveys what was observed.
Kevin Power (Apr 06 2020 at 18:25):
I know this was discussed on the call today, and I had to drop before the call ended. I don't see any final recommendations in the notes, but am curious if any suggestions seemed to get more traction by the end of the call?
Kevin Power (Apr 06 2020 at 19:57):
Also, wanted to share https://jira.hl7.org/browse/FHIR-20978 -- this was the original request made by @Mullai Murugan
Kevin Power (Apr 07 2020 at 22:39):
Hey all, update. After the call today (Tuesday), we discussed using a complex extension off of GenomicsBase (hence available on all Observation profiles) to model this 'additional guidance' concept. I drafted the proposal and committed to our implication branch:
http://build.fhir.org/ig/HL7/genomics-reporting/branches/kpower_SomaticImplication/extension-AdditionalGuidance.html
http://build.fhir.org/ig/HL7/genomics-reporting/branches/kpower_SomaticImplication/genomics-base.html
Let me know if anyone has thoughts.
Jamie Jones (Apr 07 2020 at 23:45):
Coded Markdown! :tada: A thought, other fields may also want this, as there is nothing CG specific to it. Should we reach out to O&O?
Jamie Jones (Apr 07 2020 at 23:45):
High potential for misuse here unless we restrict the code
Kevin Power (Apr 08 2020 at 00:05):
@John David Larkin Nolen will be talking to O&O Thursday.
Can’t really argue the possible misuse point, but no idea what value sets to use. Anyone have ideas?
Patrick Werner (Apr 08 2020 at 07:27):
define misuse?
Kevin Power (Apr 08 2020 at 12:15):
It could be used for anything. I think the best we can do is put some good textual guidance in the IG to describe how it should be used along with some good examples?
Patrick Werner (Apr 08 2020 at 12:31):
sounds great.
Patrick Werner (Apr 08 2020 at 12:32):
misuse to me would be using the extension for things we already have profiled somewhere else.
Jamie Jones (Apr 08 2020 at 12:36):
To be clear, this is only needed because there is no valueMarkdown on Observation, yes?
Jamie Jones (Apr 08 2020 at 12:38):
A lighter proposal could be to add a markdown extension to component, along with our relatedArtifact extension (which would also be way better if just part of component inherently imo)
Kevin Power (Apr 08 2020 at 12:40):
Discussion yesterday led us to want the ability to put a type on the guidance- meaning just having valueMarkdown or component.valueMarkdown wouldn’t be enough
Jamie Jones (Apr 08 2020 at 12:43):
Component.code provides that, unless there's a nuance I'm missing
Kevin Power (Apr 08 2020 at 12:45):
We slice on component.code so it has to be a single fixed value (like a tbd-code for “additional-guidance”)
Patrick Werner (Apr 08 2020 at 12:48):
The conclusion of the discussion was:
- should be usable without code (code optional) as you get some context from the element you are attaching to
- should not only be able to be used with components, but also for method or interpretation
Patrick Werner (Apr 08 2020 at 12:49):
- If we have only have a component/Observation with valueMarkdown, we can't bind the guidance to an element.
Jamie Jones (Apr 08 2020 at 12:52):
Identifying codes for areas folks need to send additional guidance feels like a key part of our job in this space. The more I think about this proposal the more I feel like it's punting all of those decisions to implementers, giving them an easy way out that could kill the need for any of our other guidance
Jamie Jones (Apr 08 2020 at 12:52):
Feels like a nuclear option
Jamie Jones (Apr 08 2020 at 12:55):
As a hacker, I like it ^.^ ...but I don't think it's consistent with our approach up to this point and we should be very careful with the decision
Patrick Werner (Apr 08 2020 at 12:59):
Jamie Jones said:
As a hacker, I like it ^.^ ...but I don't think it's consistent with our approach up to this point and we should be very careful with the decision
i agree. The alternative (at least to me) would be having this as an extension in my derived IG/use-case.
Kevin Power (Apr 08 2020 at 13:06):
We have had this request from a variety of folks, so I don’t think we should punt to further down to derived IG / use cases.
We could draft a ValueSet for the code and make it preferred if that puts sufficient boundaries on it?
Jamie Jones (Apr 08 2020 at 13:08):
I think drafting a valueset is very important here and we should be certain none of the concepts in it are better suited to the component structure
Patrick Werner (Apr 08 2020 at 13:09):
Kevin Power said:
We have had this request from a variety of folks, so I don’t think we should punt to further down to derived IG / use cases.
We could draft a ValueSet for the code and make it preferred if that puts sufficient boundaries on it?
1.) oh, thats not what i meant. I wanted to express the need of such thing from different parties, so if we don't provide smth. everyone will create their own stuff
2.) yes, good idea. Preferred gives some guidance, but doesn't force too much here.
Jamie Jones (Apr 08 2020 at 13:11):
I've come to be quite fond of our key+value stores and this still feels like a big anti-pattern so I hope you guys can convince me it is needed
Patrick Werner (Apr 08 2020 at 13:12):
how would you create a component which allows you to add additional guidance to any element of a resource? Or even a subset like method, interpretation, value, etc...-
Patrick Werner (Apr 08 2020 at 13:14):
After profiling the extension i'm not quite sure anymore if we need the additional type code, or if the context of Extension usage would be enough
Jamie Jones (Apr 08 2020 at 13:14):
Component.code: additional methodology guidance, component. ValueString
Jamie Jones (Apr 08 2020 at 13:15):
Component. Code: additional interpretation guidance, component. ValueString
Patrick Werner (Apr 08 2020 at 13:15):
Yes, could be an alternative, but then we would have to introduce a lot of new components
Jamie Jones (Apr 08 2020 at 13:15):
More than 2?
Patrick Werner (Apr 08 2020 at 13:16):
I'm still trying not to push in one direction, just want to explore possible solutions
Patrick Werner (Apr 08 2020 at 13:17):
Jamie Jones said:
More than 2?
probably? Maybe there is a need of having comments on other components. Should have a look at the emerge example again.
John David Larkin Nolen (Apr 08 2020 at 13:51):
I brought the note vs. component topic up on the OO on FHIR call. After a 20 minute debate about things, the group landed on the suggestion of making an extension on Observation.note so you could add in more of a structure (codeableConcept and text) to the information beyond just the free text that Observation.note currently has.
Thoughts?
Patrick Werner (Apr 08 2020 at 13:58):
hmm could work. Then we loose the possibility to bind the extension anywhere. But are declaring the note context through a coding.
Patrick Werner (Apr 08 2020 at 13:59):
Should be sufficient, and having this coming from O&O is definitely good for interoperability.
Kevin Power (Apr 08 2020 at 14:03):
I had started wondering if we could make an extension on 'interpretation' only and have our focus there for the time being. However, I am ok with O&O's guidance. @John David Larkin Nolen -- Would O&O put this into R5, or are they simply recommending we do it?
John David Larkin Nolen (Apr 08 2020 at 14:07):
@Kevin Power we did not talk about the "how" of it ;)
One thought that @Rob Hausam and I kept having about this was that some/all of the information to be put into these "notes" was going to be re-used over time, so it feels like some weird cousin of a terminology server. I say O&O does it since it feels like other groups might use it. Looping @Eric Haas into the fun...
Patrick Werner (Apr 08 2020 at 14:17):
It is not an equivalent of a terminology server. This is for additional textual guidance on Genomic findings.
Patrick Werner (Apr 08 2020 at 14:19):
https://jira.hl7.org/browse/FHIR-20978 is the original issue, https://jira.hl7.org/secure/attachment/15659/SampleReportTemplateAllPositiveforgForge.docx is an example report with highlighted parts what this extension should be able to capture
Kevin Power (Apr 08 2020 at 14:21):
John David Larkin Nolen said:
One thought that Rob Hausam and I kept having about this was that some/all of the information to be put into these "notes" was going to be re-used over time, so it feels like some weird cousin of a terminology server.
I say partially correct. A good chunk of the examples we have seen are mostly reusable over time (if you have variant X, the lab wants to say Y). But, as always, it would not surprise me if at least some of the things the lab will want to say would be tailored to a patient in some cases.
We have lots of 'knowledge' type things similar to this. As a matter of fact, a fair number of our Observation profiles today could fall into that category. We have a future to-do in that space.
Patrick Werner (Apr 08 2020 at 14:23):
Just had such a report: "patient has variant ....., which is not a described SNP. Computer prediction says pathogenic..., there is another variant on the sam gene which is known causing this, also have a look at the symptoms if they are the same treat it the same"
Bret H (Apr 10 2020 at 13:19):
@John David Larkin Nolen @Eric Haas I do not think what were talking about is appropriate in Note. Within the EMERGE @Larry Babb|196622 and @Patrick Werner use case they want to be sure the information is ''seen"' by the clinicians. The information is thought to be of importance to use the result but does not qualify as a note on how the result was obtained. It is additional knowledge that is being shared - more similar to a Diagnostic Report conclusion...that's my two cents
Eric Haas (Apr 10 2020 at 16:39):
Perhaps I am missing something, but so far it sounds like a comment to me. Comments are not limited to how the result was obtained but a lot about how to interpret the results or something about the specimen. etc.
they want to be sure the information is ''seen"' by the clinicians.
by adding an extension to comment you provided a structure that can be used to decide who the intended audience is, I don't see the issue here.
Last updated: Apr 12 2022 at 19:14 UTC
