FHIR Chat · Grouper Profile Usefulness · genomics

Stream: genomics

Topic: Grouper Profile Usefulness

---

Hayden Bader (Mar 05 2021 at 22:59):

One more question for the stream:

I haven’t really been seeing the Observation Grouper get much attention in the spec, but it looks very useful to me.

For example, say there is a DiagnosticReport that documents a test that found 5 variants and each of those variants come along with one haplotype and one diagnostic implication. In a flat DiagnosticReport, those Observations could end up structured like this..

DiagnosticReport
|--result
....|--Variant 1
|--result
....|--Haplotype 1 (derived from Variant 1)
|--result
....|--Haplotype 3 (derived from Variant 3)
|--result
....|--Diagnostic Implication 2 (derived from Variant 2)
|--result
....|--Variant 2
|--etc

This structure is possibly needlessly scrambled, but there is no order requirement for diagnostic reports, so systems should be able to handle this “scrambled” report the same way as one that might have the results “in the right order” – or at least an order that makes more sense to humans.
If we were to recommend the use of groupers, we could have reports that look like this:
DiagnosticReport
|--result
....|--Group 1
........|--HasMember Reference to Haplotype 1 (derived from Variant 1)
........|--HasMember Reference to Variant 1
........|--HasMember Reference to Diagnostic Implication 1 (derived from Variant 1)
|--result
....|--Group 3
|--result
....|--Group 2
|--etc.

In this structure, data can still be scrambled, but is more organized. Notably, this organization is intended to create a group composed of a variant and any other Observations “derivedFrom” or logically associated with that variant. Each non-variant Observation would need to contain some way of communicating this relationship (likely with a reference back to the original Observation variant), but this should still allow each Observation to stand on its own. I would think this would be useful for any situation where other Observations besides the variant is being reported.

Is there a reason we are not recommending data be represented this way and instead kind of leaving it open?

Additionally, would there be a problem if we were to represent the data in the second format?

Tagging Rachel and Dan to keep them in the loop @Rachel Kutner @Daniel Rutz

Daniel Rutz (Mar 05 2021 at 23:09):

We were actually just talking about this on the OO call yesterday too - I forget exactly what the topic was but it occurred to me that the "observation grouper" concept was relevant in that setting too. Effectively like v2's OBX-4, where there are multiple observations which are related to each other (but can, strictly speaking, stand alone so .component isn't appropriate). Any OO folks remember or have the notes? Looks like they're not posted yet (https://confluence.hl7.org/display/OO/2021-03-04+Main)

Kevin Power (Mar 08 2021 at 01:40):

Thanks @Hayden Bader this is good feedback. So you are proposing to use the Grouper profile to group together all observations related to a variant? We have tossed around several ideas for Grouper so far but not sure we had considered that one. To date we feel like it will likely be a useful we just haven’t decided the right way to leverage it. Other ideas so far:

• sections of the report
• panels of the test
• features like ‘gene’
  The section and panel ideas might likely be solved better by the introduction of a Composition attribute on Diagnostic report that would allow the expression of structure on a report and its results. However grouping by Variant is close to the feature grouping I had mentioned. It is probably an idea worth exploring.
  And as @Daniel Rutz points out, this has always felt like something that could be more generally applicable. I will be curious to hear more about the O&O discussion.

Hayden Bader (Mar 08 2021 at 15:51):

@Kevin Power yeah that's essentially what I'm proposing. I'm not saying that needs to be its only use, but it feels like it'd be useful from a processing standpoint. I've been told we might see ~100 variants on some complicated genomic reports. If each of them has one associated haplotype and one associated diagnostic implication, that quickly becomes 300 Observations (despite there possibly being even more associated Observations). From a software perspective, that feels worrisome - if an Observation I'm trying to format references another Observation I haven't processed yet (due to weird ordering shenanigans).

I also think conceptually, it makes some sense. The "result" of a lab test for genomics conceptually seems to more be the literal finding in the variant + the incidental findings and implications. The groupers in these cases would/could be more representative of that concept.

@Daniel Rutz I'm not sure if this is what you were thinking with regards to O&O, but I could see the above being generalizable.

That being said, take that bit with a grain of salt. This is kind of me looking at things based on how we model genomic data. It might not actually work in real-world scenarios. But I guess that might be the point of discussing it.

Riki Merrick (Mar 09 2021 at 18:25):

@Daniel Rutz I just posted the 3/4 notes you are referring to. We talked about it as part of the reflex order discussion - the use of observation.has member feels more like use of OBX-4. We had talked about talking more about this on next Monday's specimen call.

Riki Merrick (Mar 09 2021 at 18:28):

OOPS - I meant to add the reference to the minutes and the page where we are collecting feedback - thoughts: https://confluence.hl7.org/display/OO/2021-03-02+FHIR
The date for the specimen call would be Monday 3/15 from 2 - 3 PM ET at these coordinates: Join Zoom meeting: https://zoom.us/j/5100467805 | Meeting ID: 510 046 7805 | +1 929-436-2866-US (New York)

Bret H (Apr 01 2021 at 13:06):

@Hayden Bader I don't see "derived from" being used in your hierarchy picture. This is used to relate between variant findings and things like therapeutic implications, also between haplotypes and variants there is a link. So the nesting you are suggesting is accomplished through using the related reference links found in the profiles.

Bret H (Apr 01 2021 at 13:08):

Software implementation processing from FHIR to a relational database, as an example, might benefit from processing links last

Hayden Bader (Apr 01 2021 at 14:09):

@Bret H

So two things here:
1) I'm going to repost the model I'm imagining
DiagnosticReport
|--result
....|--Group 1
........|--HasMember Reference to Haplotype 1 (derived from Variant 1)
........|--HasMember Reference to Variant 1
........|--HasMember Reference to Diagnostic Implication 1 (derived from Variant 1)
|--result
....|--Group 3
|--result
....|--Group 2
|--etc.

What I imagine this would look like in a report is Group 1 would be 4 Observations. The Grouper piece would have a reference to haplotype 1, diagnostic implication 1, and variant 1. Variant 1 would stand on its own, and Haplotype 1 / Diagnostic Implication 1 would have a reference to Variant 1 through their "derivedFrom" properties. This way we essentially end up having an organizational structure that groups "everything known about and because of variant 1" - which I've also been calling the "result" - that whole piece together. We also still communicate that "we know about haplotype 1 because of variant 1" without having to rely on the grouper.

2) From a relational database standpoint, processing the links last seems costly especially as the number of flattened elements increases.
Ex: I have 10 therapeutic implications - each of which was determined because of 1 (or more) variants (aka derivedFrom). In order to process the relational components last, I might need to pause processing a therapuetic implication as soon as I see it is derivedFrom something - which would likely require holding on to some part of it in memory. I think this gets worse as more things are derived from a given variant and as more complex relationships pop up. It might be that the observations with no relationships should be processed first, but then I would think you might end up sifting through all sent observations to find the terminal ones - then you might need to iterated back over your list to see what can now be processed.

I will note that for groupers, you probably would still probably want to process the relational pieces last, but if we could set the groupers up to group what generally is related, I think it becomes a little easier to break the original list into groups of smaller things you could check for relationships between - if that makes sense

Bret H (Apr 01 2021 at 14:45):

Do you have a system that you could demo into which you are processing the data? Something like this: FHIR endpoint/server connected to underlying non-FHIR architecture feeding into application which displays. If so, it would be awesome to bring to a connectathon. Cerner brought their sandbox and ELIMU brought their SMART-on-FHIR application to a connectathon once. But the process started from the genetic observations (not a processed diagnostic report). I think the target of your implementation would be informative. If there was a way to have something to share as a system in the connectathon that might be really helpful. Jamie is cooking something up for displaying, but that'll only be one implementation. Once the report is consumed, I wonder how you'll implement the FHIR queries.

Bret H (Apr 01 2021 at 14:45):

send the links to a separate table for processing later. don't need to pause?

Hayden Bader (Apr 01 2021 at 15:27):

No system right now. We're going to focus on making sure we can represent outgoing genomics data before trying to process incoming data. We have talked a bit about how a diagnostic report would even be consumed, and a worry that has come out of that is scaling/references. Processing a diagnostic report with 10 results would likely mean wanting to validate each result in some way which would likely be even more annoying if they reference each other. (Assuming you want to save/interpret the discrete data as opposed to just display a reconstructed view of what was sent).

Yeah, you could probably send the links to another table for processing later, but as soon as that happens, you should be wary of processing the piece doing the linking because that might only be valid as soon as the link is resolved. That would likely result in some sort of loop for chains - A->B->C
1) resolve C
2) check references
3) B has all references resolved
4) finish / resolve B
etc.
That's not necessarily bad, but might scale poorly and could have a single point of failure - if C fails, we'd likely need to bubble up to fail A. Though I will grant that this may be an overcomplicated assumption of what could happen

Bret H (Apr 02 2021 at 01:57):

Let's move on to think about grouper. Does it solve the problem of resolving references? And recall in FHIR a reference can be a URL that indicates a profile instance that is not in the message (id of a patient profile that can be retrieved but not the actual patient profile itself).

Hayden Bader (Apr 05 2021 at 14:59):

@Bret H
From a processing standpoint, groupers don't really solve the referencing issue. You could even say that groupers just end up adding an extra reference. That being said, even if they end up increasing some sort of resolution chain length, I don't think they complicate the underlying technical issue. However, structuring data that way may make resolving some pieces of that easier down the road especially if we can make some assumptions / recommendations. (This is in addition to just the organizational benefits I was initially talking about).

It sounds like you've thought about this a bit, so I'd be interested in whether you have some sort of planned system?

But an example assumption I would want to try to make is that for a gropuer, each member is resolvable to the same FHIR server. Now, there's nothing that guarantees this, and you could probably code a general solution, but 90% of the time, I would think it's reasonable for a literal observation and a derived observation to be represented in the same system.

In the scenario where the processor needs to resolve other references, this would at the least help with making fewer requests to other servers. You can do a search on _id=<grouperID>&_include=Observation:hasMember. There's a chance that a really smart processor could compile a list of which references are on the same server / have a similar base URL, but that seems a bit risky to me.

In the scenario where all references are local (either sent in the bundle or somehow already on the server) each of the pieces is logically now a lot more separable. By construction, the grouper I'm talking about should contain its interrelated observations. Then, all the diagnostic report processing might look like is whether each of the groupers is a full grouper - as opposed to whether each of the included Observations has each of its references. There'd also need to be some validation in the end, but the overall possible options of which references can interrelate should decrease.

Jamie Jones (Oct 26 2021 at 17:40):

Showing different examples of Observation grouping came up again on call today. Played around in Lucidchart a bit, serving up one example report 3 valid ways:
image.png image.png image.png what do folks think??

Jamie Jones (Oct 26 2021 at 17:50):

one potential best practice guidance is to have every result either be on the report or hasMember of a grouper result... I may be wrong but I don't think we want folks to use haplotypes/genotypes/implications (derivedFrom) to be the only way to find a result.

Kevin Power (Oct 26 2021 at 20:14):

Good stuff @Jamie Jones Two thoughts:

• Should we remove the word 'panel' from the diagram labels? I think panel has a different meaning that how we are using it? At least I recall @Bret H saying something similar.
• Agree 100% on your guidance suggestion above. That fits nicely with the 'rarely deeper than 2 levels' in the DiagnosticReport guidance we found.

Kevin Power (Oct 26 2021 at 20:19):

Ironically, with the picture examples, and that additional guidance that Jamie suggested, I sort of wonder if that clarifies enough about how we suggest to use Grouper that we can now keep it? :smile:

Jamie Jones (Oct 26 2021 at 20:19):

Can definitely call them all Grouper, but I wanted to be generic (especially if we are thinking about removing our Grouper profile) and point out that labs MAY also build them out from panels.

Jamie Jones (Oct 26 2021 at 20:20):

one thing I wonder is if it is clear that these are all "references" rather than contained resources, and that the actual instances will still need to be passed in a transaction bundle or other method...

Jamie Jones (Oct 26 2021 at 20:30):

Given that they are references, I think the overlapping / reused arrows may be misleading... really the third one should look like this to be consistent with the first: image.png

Kevin Power (Oct 26 2021 at 20:31):

Jamie Jones said:

Can definitely call them all Grouper, but I wanted to be generic (especially if we are thinking about removing our Grouper profile) and point out that labs MAY also build them out from panels.

Makes sense to want another name, but I thought 'panel' was a bit loaded - as in, a panel is something where you get the same X results every time? And that probably doesn't fit for us? But maybe I am mis-remembering.

Jamie Jones (Oct 26 2021 at 20:43):

redo of the second one to align as well: image.png

Kevin Power (Oct 26 2021 at 20:45):

Hmmm, even though the boxes on the right have the same name, it still looks like they are different instances - which they are not, correct?

Jamie Jones (Oct 26 2021 at 20:45):

image.png they're references to the same Obs, lined them up to make it more clear here

Jamie Jones (Oct 26 2021 at 20:49):

(it's possible the previous way with multiple arrows pointing to one instance is actually more clear... but I had a lot of trouble making that way work when trying to mock up the first one where they are hasmembered by Implication/derivation)

Kevin Power (Oct 26 2021 at 20:50):

Honestly, I would go back to the originals, but welcome input from others

Bob Dolin (Oct 26 2021 at 21:01):

I haven't used groupers, so don't have a strong opinion here, but given that they can be used in different ways, do we also need to provide guidance on the Query Guidance page?

Arthur Hermann (Oct 26 2021 at 21:20):

@Bob Dolin - yes I think it will be important to provide guidance on the query guidance page... @Jamie Jones @Kevin Power - I have heard a lot of concern about the proper processing of these constructs "OFKAG" (Object Formerly Known AS GROUPER)... Hayden has a question about this above. It seems from the queries I have heard - grouper, per se, is not the issue. The issue is how to process these looping reports in an efficient manner. Do we need to deal with that issue separately? If so - how? Shall I open a JIRA about this?

Kevin Power (Oct 26 2021 at 21:27):

@Hayden Bader Can comment again, but I get the sense his concerns are more general about the IG more generally, and the variety of ways different observations can be related to other observations. So honestly, you can log a JIRA, but I am not sure what it will say?

Hayden Bader (Oct 26 2021 at 21:50):

@Jamie Jones I prefer the original images you had to the new ones. I think the originals make it clearer that the references are linking to existing observations. The figures where Observation 1 is repeated twice makes it ambiguous as to whether there are two "Observation 1"s.

The search query question kind of was resolved for me at the May Connectathon. My takeaway from that was that the best way to return data was that if category = genomics/genetics (there's another JIRA for that), then we return all of the Observations that inherit from the base genomics profile. From there, you can key in by specifying code or the like on other pieces.

So you could do something like this:
Observation?patient=<patient>&category=genomics&code=grouper -> to get all of the groupers (last I checked, the grouper code was the tbd code for the grouper profile)

The query piece that I was referring to in my previous message was that if a third party were to try to get their data to show up on a FHIR server in any of the pictured formats, that the more options you have for how things could be linked, the more tangled the resolution becomes. Which is what @Arthur Hermann says.
Edit: Or at least how I interpret what Arthur said

This is a bigger issue for genomics because the various Observations are inherently linked, but this is kind of a thing that FHIR generally would need to solve for cases where data is intended to relate together. As it stands, it has seemed to me that a lot of FHIR resource creates can stand on their own, so resolution of references hasn't been as big of a deal.

Kevin Power (Oct 26 2021 at 22:17):

@Hayden Bader - Thanks for the detail. It is hard to be overly prescriptive, which does lead to a lot of complexity. We could enforce some constraints to make it more obvious what we recommend (basically design the profiles to better enforce the options Jamie shows in the diagrams). What would others think of that?

Jamie Jones (Oct 26 2021 at 22:19):

Could profile observation to provide specific codes for different types of groups of observations

Jamie Jones (Oct 26 2021 at 22:21):

But we'd want multiple systems to vet/validate those groupings as useful/seen

Bob Dolin (Oct 26 2021 at 22:22):

@Kevin Power I was thinking of being LESS prescriptive, and focus more on query advice. It's starting to look like we will be offering quite a bit of documentation...

Jamie Jones (Oct 26 2021 at 22:26):

I think less prescriptive is exactly what we are trying to go for, and to show a few examples of configurations that could be expected to encounter. Agree query guidance here will be great--as some types of queries just won't get everything depending on the structure of the report. Hopefully this leads to a Must Support statement on search parameters

Kevin Power (Oct 26 2021 at 23:21):

@Hayden Bader - Thoughts on the above?

Hayden Bader (Oct 27 2021 at 14:40):

@Kevin Power We had a similar discussion (on grouper profiles at least) back at the June 7, 2021 meeting. I'm fine with the spec being less prescriptive - especially if it allows us to represent the data we want to which is currently the first figure Jamie linked.

However, I do think that at some point users are going to coalesce around a common way of representing genomics information. I understand where the work group is coming from in that we don't want prevent anyone looking to use the spec from representing the data the way they want. Adding additional documentation/examples serves as a sort of good middle ground to guide others without telling them what needs to be done. But by my view, I think at some point that's going to hit a roadblock... though it also might be that a consensus more naturally evolves as genomic information exchange becomes more common and tools get built out.

Bret H (Oct 27 2021 at 15:54):

Not sure what query advice is being sought? What exactly is being queried? Who is querying? There is already query guidance in the IG - these are more focused on returning matched observations. What is the intended query that is not being met?

How a system represents the data behind their FHIR server post receipt of the report is out of scope.

Bret H (Oct 27 2021 at 15:58):

@Jamie Jones @Hayden Bader Yep, people could do almost anything with grouper. But I am intrigued about thinking that the result of the diagnostic report could be used to point to the most relevant observations - that is, Jamie has an example pointing to a diagnostic implication as a result with the variants connected but not directly referred to as results. It speaks to the diagnostic report as a vehicle to deliver the data as well as a way of indicating meaning (indicating meaning is the purpose of grouper, right?).

Bob Dolin (Oct 27 2021 at 16:04):

Bret H said:

Not sure what query advice is being sought? What exactly is being queried? Who is querying? There is already query guidance in the IG - these are more focused on returning matched observations. What is the intended query that is not being met?

I'm suggesting that rather than trying to provide a lot of guidance as to how or how not to use grouper, we just accept that it's there, that it's use will vary (despite our guidance), and the intent of the query advice is to help people understand that as a result, observations of potential interest will be variably nested beneath the root document, and they should consider that in their queries (with some examples).

Bret H (Oct 27 2021 at 16:07):

Excellent. Yes we have example queries in the IG now that show how to handle nesting (back referencing and all). FYI it was like a cool sudko figuring out the right syntax. Patrick and Jaime reviewed my work, and Jamie tried them out using profiles placed in a basic FHIR server.

Bret H (Oct 27 2021 at 16:08):

However, are people interested in pulling all the results of a specific type or value OR are they trying to rebuild the report as it was received?

Arthur Hermann (Oct 27 2021 at 16:13):

@Bret H People might be interested in either of those use cases. They are both valid depending on how your organization is using this data. Therefore if we can give guidance that is helpful to both use cases, I think we would be doing an excellent job!

Bret H (Oct 27 2021 at 16:15):

The query for the report is self-evident. You query for genomic reports (it's the packaging by the system on the other side of the FHIR server that is where effort lies. Some systems will retain the report as it was received exactly - so pretty quick response, others will need to build it).

Bret H (Oct 27 2021 at 16:16):

The queries in the IG speak to pulling specific values and/or types.

Bret H (Oct 27 2021 at 16:17):

The value of grouper in either query case is close to zero.

Bret H (Oct 27 2021 at 16:17):

grouper gives a layer of meaning when received, but I don't see it's usefulness after that...

Kevin Power (Oct 27 2021 at 18:02):

So, seems like we are settling on an approach. Let me see if I can describe what I understand:

• Remove Grouper profile (will involve updating several artifacts, like examples)
• Add implementation guidance describing how our Genomic Observations can be grouped, using Jamie's diagrams as the basis for that guidance
• Add query guidance based on the implementation guidance described above, showing common patterns and give hints as to various

Does that sound right? Other suggestions?

Bret H (Oct 27 2021 at 19:25):

review the current query guidance already present :grinning: http://build.fhir.org/ig/HL7/genomics-reporting/usecases.html

Kevin Power (Oct 27 2021 at 19:28):

Indeed @Bret H - sure. My last point would be updates to that page, but I added the last point below:

• Remove Grouper profile (will involve updating several artifacts, like examples)
• Add implementation guidance describing how our Genomic Observations can be grouped, using Jamie's diagrams as the basis for that guidance
• Add query guidance based on the implementation guidance described above, showing common patterns and give hints as to various
• Review current query guidance for changes based on the new implementation guidance described above

Bret H (Oct 27 2021 at 19:29):

FYI: 1.10.3.1 is place holder for Panel

Bret H (Oct 27 2021 at 19:32):

Example from the page:
Public Health
Today Registrars manually translate clinical data into public health reporting systems. This data is used to monitor and improve public health (e.g. surveillance and clinical research). In the future, this data will be extracted from the EHR in an automated (or semi-automated) fashion.

For a breast cancer clinical genomic study, get all genetic observations of patients where the variant is associated with breast cancer as a genetic risk. There is some heterogenity in the codes which maybe used to indicate phenotypes. Here we have used the NCI metathesaurus code for Breast Cancer, "C9335," as a likely code to be used. The following query returns all variants that have an annotation of "Breast Cancer" using the NCI metathesaurus code for Breast Cancer, "C9335." "code-value-concept" is a construct to use the code of an Observation instance and the code of a value for the Observation. The Observation.code = 81259-4, "Associated Phenotype," is used for the iG's "Inherited Disease Pathogenicity" profile. The value in this case is NCI metathesaurus code for Breast Cancer, "C9335." Additionally, the "_include:iterate=Observation:derived-from" iteratively follows the Observation.derived-from link. "_include:iterate=Observation:derived-from" tells the FHIR API to look for variants that the annotation is derived from. The iterate modifier is needed as the direct target of a derived-from relationship can be a hapolotype which has a derived-from relationship to a variant (note: haplotypes can have derived-from other haplotypes which makes the number of observations returned larger).

GET /Observation?subject:Patient=123&code-value-concept=http://loinc.org|81259-4$http://ncimeta.nci.nih.gov|C9335&_include:iterate=Observation:derived-from
81259-4: LOINC code for "Associated Phenotype"

http://ncimeta.nci.nih.gov|C9335 : NCI metathesaurus code for "Breast Cancer"

"_include:iterate=Observation:derived-from" tells the FHIR API to look for variants that the annotation of "Unknown Significance" is derived from. The iterate modifier is needed as the direct target of a derived-from relationship can be a hapolotype which has a derived-from relationship to a variant (note: haplotypes can have derived-from other haplotypes which makes the number of observations returned larger).

Bret H (Oct 27 2021 at 19:33):

Ok, needs a refresh the term 'Inherited Disease Pathogenicity" profile is referring to diagnostic implication. But the query does not change.

Kevin Power (Oct 27 2021 at 19:38):

Bret H said:

Ok, needs a refresh the term 'Inherited Disease Pathogenicity" profile is referring to diagnostic implication. But the query does not change.

Yea, it wouldn't surprise me if we find several things on that page that are out of date with changes. We on the authoring/maintaining side need to get better at keeping this sort of thing (and the glossary) updated as we make changes.

Bret H (Oct 27 2021 at 19:40):

thanks to how FHIR works most of it will be the textual guidance and not the queries themselves.

Bret H (Oct 27 2021 at 19:43):

FYI useful for those that are getting into queries: As the CG IG heavily utilizes Observation.component querying Observations rely upon queries using component-code (https://www.hl7.org/fhir/observation.html#search) and component-value-concept search parameters.
More complex queries are also using the _include (https://www.hl7.org/fhir/search.html#revinclude) search parameter.

Arthur Hermann (Oct 27 2021 at 21:13):

I am not a programmer - so my input here may not be beneficial - that is fair, just let me know. As can be seen by the excellent diagrams Jaime created, there can be a lot of complexity in the relationship between the report, observations, variants, implications etc.... I thought that Grouper was created to diminish that complexity. If in fact, it does not do so - then it seems that it helpful from a conceptual point of view, but not from a programmatic point of view. Can somebody explain this to me? If Grouper is helpful as a conceptual concept, then I can see us dropping it. but it it actually allows a programmer to organize their code more easily, then I would still like to see it remain.

Lloyd McKenzie (Oct 27 2021 at 21:22):

Grouping is done to provide a way of organizing content. Computers generally don't need content to be organized, because they can organize however they like based on metadata, so groupers aren't there to make computation easier. In fact, they make it harder. Their purpose is to make navigation easier for humans - and to allow authors to dictate how they want humans to navigate.

Bret H (Oct 27 2021 at 21:35):

I'm seeing RecommendedAction as an element in grouper. That would convey some additional meaning, but not sure if that was just to pull the relevant observations and RecommendAction together as a group (which would imply the RecommendedAction is a copy of one in the Report, FYI RecommendedAction is a CG extension).

Lloyd McKenzie (Oct 27 2021 at 21:44):

Being in a grouper doesn't apply additional meaning. There should always be a link from the recommendation to the reason for it.

Kevin Power (Oct 27 2021 at 22:18):

Bret H said:

I'm seeing RecommendedAction as an element in grouper. That would convey some additional meaning, but not sure if that was just to pull the relevant observations and RecommendAction together as a group (which would imply the RecommendedAction is a copy of one in the Report, FYI RecommendedAction is a CG extension).

I hadn't noticed that before, but that doesn't feel right to me. I would be supportive of removing the RecommendAction extension from Grouper (if we decide to keep Grouper).

Bret H (Oct 27 2021 at 22:23):

it mentions that it can be used in observations in the IG build - if current guidance is to use it only in diagnostic report then the guidance on the artifact page also needs a change.

Kevin Power (Oct 27 2021 at 22:28):

Where do you see that @Bret H ?

Bret H (Oct 27 2021 at 22:31):

The extensions section of the artifacts page: http://hl7.org/fhir/uv/genomics-reporting/2021May/artifacts.html

Extensions
Extensions defined as part of the CG implementation guide

Related Artifact
Captures citations, evidence and other supporting documentation for the observation or report

Recommended Action
References a proposed action that is recommended based on the results of the report or observations

Supporting Information
Additional information relevant to interpreting/understanding the report

Kevin Power (Oct 27 2021 at 22:32):

Bret H said:

Recommended Action
References a proposed action that is recommended based on the results of the report or observations

Ahhh, got it. Yes, that will need to be changed.

Jamie Jones (Oct 29 2021 at 16:40):

So, we'd need to spell out caveats for this proposal: something like, "to increase human navigation, rather than referencing every relevant Observation under DR.result, implementers MAY group results using Observation.hasMember provided the following criteria are met:
... (Fill in the blanks and compare those criteria to the guidance of a profile)

Kevin Power (Oct 29 2021 at 17:06):

Agree, and the ... will be important. Hope it is OK that I mention it here, but @Bret H is working on a branch now with some specific ideas and proposals.

Bret H (Nov 01 2021 at 15:18):

branch for withoutgrouper http://build.fhir.org/ig/HL7/genomics-reporting/branches/withoutGrouper/index.html look to the examples for: diagnostic report EMERGE pharmacogenomics and oncology full bundle. These show what'll it look like to a computer/person.

Bret H (Nov 01 2021 at 15:19):

e.g. http://build.fhir.org/ig/HL7/genomics-reporting/branches/withoutGrouper/DiagnosticReport-PGxGenomicsReportEMERGE.html
and http://build.fhir.org/ig/HL7/genomics-reporting/branches/withoutGrouper/Bundle-oncologyexamples-r4.html

Kevin Power (Nov 02 2021 at 14:26):

@Bret H - I think we had discussed on a call to keep a section on the 'General' page describing that Observations might still be grouped, but just removing references to our Grouper profile. The intention was to describe the images that Jamie dropped into this chat on Oct 26?

Bret H (Nov 02 2021 at 15:09):

Not sure. You and I spoke about removing grouper. It's easy enough to have an example of a profile not using grouper and one using it. But I think it's an important illustration for folks to understand what grouper does or does not do.

It's easy enough to add/change or subtract. But let's have a look at the Emerge and oncology examples in without grouper

Kevin Power (Nov 02 2021 at 15:12):

Kevin Power said:

Indeed Bret H - sure. My last point would be updates to that page, but I added the last point below:

• Remove Grouper profile (will involve updating several artifacts, like examples)
• Add implementation guidance describing how our Genomic Observations can be grouped, using Jamie's diagrams as the basis for that guidance
• Add query guidance based on the implementation guidance described above, showing common patterns and give hints as to various
• Review current query guidance for changes based on the new implementation guidance described above

@Bret H - Here was the suggested plan for updates.

Bret H (Nov 02 2021 at 15:21):

A : Yes. I started with updating examples.

B: You'd like Jaime's diagrams to be the basis for using Observation to group things without grouper? right?

C: Query is interesting. There's no changes to query guidance really, but I can point out the specific queries, and create queries based on the specific examples.
How it looks depends on the type of query.
E.g. give me all implications (or diagnosis or variants) in the report - easier to do without grouper as you now just ask for the results with the right observation.code rather than have to look through all the groupers. I can put in two examples.

E.g. give me the panel of connected results - hopefully the right observsation.code has been used for the Panel observation that is using has member. So you just ask for all the members of the panel (follow has members link). You'd not be able to do that with our grouper profile.

E.g. give me all the profiles linked to the genotype (or haplotype or whatever), follow the links in the profiles with the query iteratively - we've some examples of that now.

Jamie Jones (Nov 02 2021 at 15:23):

@Bret H @Kevin Power Let me know if any changes to the diagrams could support this proposal

Bret H (Nov 02 2021 at 15:26):

@Jamie Jones Not at this time.

Kevin Power (Nov 02 2021 at 15:32):

There are still references to Grouper from images on the General page?

Bret H (Nov 02 2021 at 15:33):

Yes. I started with the examples.

Kevin Power (Nov 02 2021 at 15:38):

@Bret H - To answer B: above, yes, I was thinking that would be some guidance documentation on the General page to describe Observations might be grouped without Grouper.

Jamie Jones (Nov 02 2021 at 15:39):

So is the idea to not allow grouping observations? Or just to not profile grouping

Kevin Power (Nov 02 2021 at 15:42):

More the later. Since we can't prevent grouping, we would draft some guidance based on your diagrams from Oct 26.

Kevin Power (Nov 02 2021 at 15:48):

As far as other images that still refer to Grouper that we would want to change, I was thinking primarily of this one:
http://build.fhir.org/ig/HL7/genomics-reporting/branches/withoutGrouper/general.html#genomic-observations image.png

Kevin Power (Nov 02 2021 at 15:51):

So in that diagram, I would suggest we simply remove the Grouper profile.

For other guidance, we keep a section on the general page named 'Grouping Observations' perhaps include 1..* of Jamie's diagrams, along with some textual guidance. Or, perhaps we just work this guidance into the "Relationships between Resources" section? I will let @Bret H contemplate that one.

Bret H (Nov 02 2021 at 15:52):

How about a problem with grouper's section? where querying is discussed?

Bret H (Nov 02 2021 at 15:53):

Or just add a section about querying on the 'grouping genomics observations' page?

Kevin Power (Nov 02 2021 at 15:54):

Just to be clear, I was suggesting sections on the General page.

Bret H (Nov 02 2021 at 15:56):

Thanks for the clarification.

Kevin Power (Nov 02 2021 at 15:56):

As I discussed with Jamie on the 'Genomics Files' discussion, I usually lean towards starting with a section on the General page. If we draft something and it is really large, we can move it to its own page later.

Arthur Hermann (Nov 02 2021 at 15:57):

I assume you all recognize that the most challenging current area to update will be the pharmacogenimcs example page... we would have to redo all of the images, significant amount of text and even re-code the main example

Jamie Jones (Nov 02 2021 at 15:58):

if we still allow grouping we could just remove the references to grouper code

Jamie Jones (Nov 02 2021 at 15:58):

unless we specifically want to update that example to show a PGx report WITHOUT Observation grouping

Arthur Hermann (Nov 02 2021 at 16:01):

I think it would be very confusing to leave those images as is on the Pharmacogenomics page, if we are not supporting grouper. They are a major focus on how the information and code is designed.

Bret H (Nov 02 2021 at 16:01):

I've updated the example to show a PGx report without observation grouping already. have a look compare: http://build.fhir.org/ig/HL7/genomics-reporting/branches/withoutGrouper/DiagnosticReport-PGxGenomicsReportEMERGE.html and http://build.fhir.org/ig/HL7/genomics-reporting/DiagnosticReport-PGxGenomicsReportEMERGE.html

Jamie Jones (Nov 02 2021 at 16:02):

looks good! I can redo the images (would be good to have them properly in Lucid for maintenance anyways)

Kevin Power (Nov 02 2021 at 16:08):

I think Bret copied/pasted one wrong link above:

Example with Grouper:
http://build.fhir.org/ig/HL7/genomics-reporting/DiagnosticReport-PGxGenomicsReportEMERGE.html

Sample example WITHOUT Grouper:
http://build.fhir.org/ig/HL7/genomics-reporting/branches/withoutGrouper/DiagnosticReport-PGxGenomicsReportEMERGE.html

Here, the 2nd example is showing no 'grouping' at all.

Jamie Jones (Nov 02 2021 at 16:12):

Bret H said:

I've updated the example to show a PGx report without observation grouping already. have a look compare: http://build.fhir.org/ig/HL7/genomics-reporting/branches/withoutGrouper/DiagnosticReport-PGxGenomicsReportEMERGE.html and http://build.fhir.org/ig/HL7/genomics-reporting/DiagnosticReport-PGxGenomicsReportEMERGE.html

Glance value is much improved in the publisher renderer!

Bret H (Nov 02 2021 at 16:18):

Jamie Jones said:

looks good! I can redo the images (would be good to have them properly in Lucid for maintenance anyways)

I can redo the ones done with lucid chart (if the files are in git). Be great If you redo the figs on the pharmacogenomics guidance page (seems like it should be a generic observation profile...which gives us a need for an observation.code). Don't worry about it in the figure. I will add something appropriate in the guidance and the emerge diagnostic example.

Arthur Hermann (Nov 02 2021 at 16:48):

(deleted)

Arthur Hermann (Nov 02 2021 at 17:02):

I assume somebody already referenced this in this thread, but if not - we would also want to update this diagram: http://build.fhir.org/ig/HL7/genomics-reporting/branches/withoutGrouper/general.html#genomics-report

Kevin Power (Nov 02 2021 at 17:05):

Good call @Arthur Hermann - @Bret H is releasing his changes iteratively, so this is certainly a WIP.

Bret H (Nov 02 2021 at 17:16):

I'll post here what and when updates to the branch are made...I planned to talk about the Emerge and oncology example today with a look at the JSON of the example and the computed narrative to provide a flavor of what grouper does. : ^ ) the guidance update and figs will be along soonish.

Bret H (Nov 04 2021 at 17:19):

Hello. I'm close to publishing an update. Should be one later this afternoon.

Bret H (Nov 05 2021 at 09:07):

Draft in. Please take a look and comment, correct, suggest! Looking forward to it!
The following pages are the ones where changes are made, be sure to review the query guidance on general.html.
guidance: http://build.fhir.org/ig/HL7/genomics-reporting/branches/withoutGrouper/general.html
guidance: http://build.fhir.org/ig/HL7/genomics-reporting/branches/withoutGrouper/pharmacogenomics.html

example: http://build.fhir.org/ig/HL7/genomics-reporting/branches/withoutGrouper/DiagnosticReport-PGxGenomicsReportEMERGE.html
example: http://build.fhir.org/ig/HL7/genomics-reporting/branches/withoutGrouper/DiagnosticReport-PGxGenomicsReportEMERGE2.html

example: http://build.fhir.org/ig/HL7/genomics-reporting/branches/withoutGrouper/Bundle-oncologyexamples-r4.html
example: http://build.fhir.org/ig/HL7/genomics-reporting/branches/withoutGrouper/Bundle-oncologyexamples-r4-noGrouping.html

example: http://build.fhir.org/ig/HL7/genomics-reporting/branches/withoutGrouper/Bundle-diagnosticreport-cgexample.html
example: http://build.fhir.org/ig/HL7/genomics-reporting/branches/withoutGrouper/Bundle-diagnosticreport-cgexample-noGroup.html

Kevin Power (Nov 05 2021 at 13:33):

Thanks @Bret H !! I just pushed up a few minor formatting changes to the General page, and will do a deeper review sometime today (I hope).

Kevin Power (Nov 08 2021 at 14:29):

@Bret H - I did a read over the guidance, and I think this looks really good. I noticed a couple of overlaping labels on the 2nd and 3rd diagrams in the General -> Grouping Observations section. Looking forward to getting other feedback.

Jamie Jones (Nov 08 2021 at 17:01):

let's pull up the JIRAs for this!

Kevin Power (Nov 08 2021 at 19:05):

Here are the ones I can find easily:
FHIR-32423
FHIR-32095

Hayden Bader (Nov 10 2021 at 14:51):

Sorry folks, I haven't really had time to respond to this. I don't think that the groupers should be removed.

From this thread, the most I've gotten is that groupers should be removed because they make data processing more complicated. That is technically true, but that seems like a weak reason to "remove" a part of that spec. And @Kevin Power @Jamie Jones neither of those JIRAs really goes into any more details about groupers being removed or why groupers should be removed.

@Bret H
I haven't seen the proposal on panels, but for querying for all of the diagnosticImplications, you should just use the code for diagnostic implication defined in the profile.

Additionally, the proposed withoutGrouper branch is now ceding all control over grouping. Before, CG would have had some say in what a group is. Now, it looks like any lab could define whatever type of grouping they wanted - even adding additional data to their grouping observations. That may allow more labs to use the spec, but it's going to impede labs from communicating with the spec.

Kevin Power (Nov 10 2021 at 15:23):

@Hayden Bader - First off, the JIRAs haven't been kept update with the latest discussions. Sorry about that. I will let @Bret H and others weigh in as well, but I wanted to mention that Grouper was just seen unnecessary overhead within the IG since FHIR Observations support the grouping without our profile. The only unique thing provided by the profile was a common Observation.code which wasn't really providing much value (it wasn't even a real code, it was one of our TBD codes), and really was introducing confusion. We tried explaining that a grouper was just a generic grouping of observations, and didn't have meaning beyond that, but questions about usage remained.

Wish I could give you more, but I have a busy day today and have to leave it there. Feel free to respond with more, and I hope that @Bret H @Jamie Jones or others can also weigh in. I will just add that we have not voted on this yet, so this isn't a done deal.

Jamie Jones (Nov 10 2021 at 15:33):

I can add that while we have yet to request any real control over grouping, we do currently provide a code people can use to tell systems "this is just a grouping obs". Since grouping isn't required or consistent, however, receiving and rendering systems will need to be robust against coded, uncoded, and potentially redundant grouping.

Bret H (Nov 10 2021 at 16:12):

Kevin's nailed it. @Hayden Bader To clarify, only the CG specific Observation profile called 'Grouper' was removed in the branch. It did extremely little, and did not stop an implementer from grouping in any way they wished. The branch shows that Observation can directly be used for those that want to create groupings.

Panels are more interesting. If your panel has a specific code, such as a Panel LOINC code, you could use that code for the Observation.code and create structures similarly (and more meaningfully) to the grouping observations in the branch.

Kevin Power (Nov 10 2021 at 21:18):

@Hayden Bader - Did that help/hurt/do no good? We can make this a topic on a call next Monday or Tuesday if you want to discuss live.

Hayden Bader (Nov 10 2021 at 23:17):

@Kevin Power I think I understand the issue/disconnect a bit better. Right now, we receive genomics data through HL7v2 in a bundle of implications and variants. It's essentially a grouper. So, groupers end up not looking like unnecessary overhead to us, but instead a familiar structure. We met internally a bit to discuss groupers / examples more this week, and @Scott Isaac is working on getting something ready.

But as a start, our use case was derived from the V2 way of representing genomics data. And I would think that if labs were previously interested in V2 that having the FHIR structure more clearly mimic it, it might be a gateway to getting labs more easily involved.

Bret H (Nov 10 2021 at 23:22):

Hayden can you explain a bit more. Seems to me that the correspondence in FHIR to what you are describing is the DiagnosticReport, or even a Bundle. Are you looking for aiding in processing incoming messages?

Kevin Power (Nov 10 2021 at 23:24):

And remind me @Hayden Bader - Is the “grouping” in V2 with OBX4.1 or something similar?

Arthur Hermann (Nov 10 2021 at 23:38):

Hayden Bader said:

But as a start, our use case was derived from the V2 way of representing genomics data. And I would think that if labs were previously interested in V2 that having the FHIR structure more clearly mimic it, it might be a gateway to getting labs more easily involved.

Hayden - I think for the most part, Labs are not used for sending Genomic information in V2 (except those that Epic has nudged along that path :grinning: )... The majority are still sending PDFs. I am speaking of genomics labs here, rather than labs that do a lot of tests and also do genomic tests. So except for the aforemenioned my read of the environment is that genomics labs will need to set up a good deal of their messaging from scratch to send machine readable genomic data.

Are you able to share with the WG what your use cases is? Are you and your team currently working on mapping the V2 work that you have used with many clients to FHIR?

Hayden Bader (Nov 11 2021 at 00:20):

@Bret H No, we're not looking at help processing an incoming message right now. It's just that our internal genomics model was informed by processing incoming messages. Right now, we're focusing on making the genomic results we have accessible through FHIR.

@Kevin Power That's my understanding of it. @Rachel Kutner and @Daniel Rutz could speak more about it than me. I think Dan called it OBX-4 way up this chain.

@Arthur Hermann Right now, it's a similar response as the one to Bret. We internally have data that represents genomics results from orders. We're working on making that data accessible discretely (right now through Observations, though the jump to DiagnosticReports wouldn't be a large one).

Bob Dolin (Nov 11 2021 at 00:22):

Here's a picture @Hayden Bader that may help - it shows how all the OBXs related to a particular variant have the same value in OBX-4

Bob Dolin (Nov 11 2021 at 00:22):

image.png

Bob Dolin (Nov 11 2021 at 16:31):

Might be worth noting what I think is an important distinction between the HL7 v2 LRR guide vs. FHIR Genomics IG. In the LRR guide, the OBX-4 grouping mechanism is required, it is THE way in which to associate, say, a phenotype with a variant. In the FHIR Genomics IG, an implication instance has a required derivedFrom relationship. The contents in the picture would be represented as a diagnosticImplication that is derivedFrom a variant.

Bret H (Nov 11 2021 at 16:36):

Bob's said it well. The relationships like hasMemeber and derivedFrom are key in processing incoming messages in FHIR to understand how it all goes together computably.

Bret H (Nov 15 2021 at 21:14):

Half-way done with changes from the FHIR subgroup meeting today. Here's what's happening in the branch from Today's FHIR subgroup call:
'move most of the guidance in the grouperless branch to the query guidance page, leave a note/link to it from general with a scoping paragraph.'

I have changed the guidance on the general page. The Pharmacogenomics-EMERGE example page is not changed yet. Query guidance change in progress.

(URL for the code system used in the examples has been updated to the owl reference)

Kevin Power (Nov 16 2021 at 19:35):

@Bret H - I tried to do a quick and probably incomplete resolution description on the two jiras. Can you review? I used the same proposal for each. I did include a comment with a few comments from this chat.
https://jira.hl7.org/browse/FHIR-32423
https://jira.hl7.org/browse/FHIR-32095

Bret H (Nov 16 2021 at 19:41):

I think it captures the gist. Thanks Kevin.

Kevin Power (Nov 16 2021 at 19:42):

@Liz Amos @Hayden Bader @Rachel Kutner - I wanted to specifically mention to each of you that I decided to mark the JIRAs as "Not Persuasive with Change" since the change of removing Grouper doesn't really address the requests being made, but instead proposes a different change. I wanted to clarify this because I was on record as saying we would do this as "Persuasive with Change" but honestly that felt wrong as I put the proposal together.

Note - this is still just the proposal, so not set in stone yet. We will review the examples from @Hayden Bader to help us see the specific use case. In the end, we might accept what we have now and log a new JIRA to support the request from Hayden and Rachel - or, we might completely change the current proposal. It will just depend on a deeper analysis of the example and use case presented.

Bret H (Nov 16 2021 at 19:58):

Pushing changes now:
Put the more extensive information on a new page 'groupingGuidance' : http://build.fhir.org/ig/HL7/genomics-reporting/branches/withoutGrouper/groupingGuidance.html

On index.html: image.png

The query guidance use case page is not ready for review. But the rest is.

Arthur Hermann (Nov 16 2021 at 20:16):

@Bret H I suggest that the Title of this section be: Grouping Observations (delete the word About)... However, possibly the title should be Grouping Genomic Observations. The wording may be important to the question of whether we are just speaking of grouping within our IG, or whether there is overlap or broader reference to observations (e.g O&O). I think we are focused only on our IG. If this is the case, then we definitely should call this section Grouping Genomic Observations.

Arthur Hermann (Nov 16 2021 at 20:19):

@Bret H is the text on the page you created for Grouping Observations, the same text which was on the original section before you moved id? If not - is there a way to see that text?

Kevin Power (Nov 16 2021 at 22:57):

@Bret H - Should this new page be referenced from the General Page?

Bret H (Nov 16 2021 at 23:05):

@Arthur Hermann It is the same text and layout. Thanks!

@Kevin Power It is in the table of contents, but right now it is not referenced in the General Page. I'll put one in, good catch. Thanks!

Bret H (Nov 16 2021 at 23:26):

added reference in General Page "The observations could be grouped with grouping observations (see <a
href="groupingGuidance.html">grouping observations</a>)."

Bret H (Nov 16 2021 at 23:27):

@Arthur Hermann I like where 'Grouping Genomic Observations' is going but it seems a little too strong as were not guiding people on how to group genomic observations. But I like the focus on genomic observations. How does 'Genomic Observation Groupings' sound to you? (need some good word smithing here for sure)

Arthur Hermann (Nov 17 2021 at 00:30):

Bret H said:

Arthur Hermann I like where 'Grouping Genomic Observations' is going but it seems a little too strong as were not guiding people on how to group genomic observations. But I like the focus on genomic observations. How does 'Genomic Observation Groupings' sound to you? (need some good word smithing here for sure)

LOL - good catch - we are not grouping Genomic Observations :grinning: I think that Genomic Observation Groupings is good.. certainly open to the ideas of others..

Joel Schneider (Nov 17 2021 at 05:32):

Considering the removal of the Grouper profile, should the following wording on the withoutGrouper/background.html page be revised?

The organization of the report is often accomplished by subsetting (sometimes recursively) using the Grouper Observation. The structure of these groups is usually driven by the types of testing and/or panels requested, though they can vary depending on the reporting lab. In some cases, no subdividing organization will be provided at all.

Kevin Power (Nov 17 2021 at 16:20):

@Bret H - I am not sure what this means (from the grouping guidance page, under "Note" section, first paragraph:

Additionally, observations may not always be encapsulated in a DiagnosticReport. The use of basing queries on Observation resource, as done here, ensures that genomic observations will be found.

Kevin Power (Nov 17 2021 at 16:53):

@Bret H - I had a meeting canceled, and took a few minutes to make some tweaks. I just promoted for a build, but you can review the specific changes I made by reviewing my commit here:
https://github.com/HL7/genomics-reporting/commit/3af93374bb67c45690d48096e03839a09a844656

Arthur Hermann (Nov 17 2021 at 18:30):

I am having trouble with the multiple branches that are now being built and making sure I know where to view the current view of each branch. Would it be a good idea to create a Zulip thread with the links for the different branches? Then if updates are need to that URL - the appropriate person could just update there. I love the use of branches to do this work - but it is getting a bit complicated following all of the different work and all of the different URLs involved in each work stream. I am VERY open to other ideas to make this easier for all..

Kevin Power (Nov 17 2021 at 19:40):

I will see if I can come up with something better, but for now:

Grouper Branch:
http://build.fhir.org/ig/HL7/genomics-reporting/branches/withoutGrouper/index.html

File Attachments Branch:
http://build.fhir.org/ig/HL7/genomics-reporting/branches/kp-file-attachments/index.html

Arthur Hermann (Nov 17 2021 at 20:15):

So is there no information about Grouping on the Genomic Observation Page? I think we should have a small paragraph with a link to the main page about grouping.

Kevin Power (Nov 17 2021 at 20:27):

What page @Arthur Hermann ? @Bret H introduced this page? http://build.fhir.org/ig/HL7/genomics-reporting/branches/withoutGrouper/groupingGuidance.html

He also added a link to that guidance page from the General page, it is the last paragraph under Genomics Report section. Are you referring to the Genomic Observations section of the General page? http://build.fhir.org/ig/HL7/genomics-reporting/branches/withoutGrouper/general.html#genomic-observations

Or something else?

Kevin Power (Nov 17 2021 at 22:56):

Arthur Hermann said:

I am having trouble with the multiple branches that are now being built and making sure I know where to view the current view of each branch. Would it be a good idea to create a Zulip thread with the links for the different branches? Then if updates are need to that URL - the appropriate person could just update there. I love the use of branches to do this work - but it is getting a bit complicated following all of the different work and all of the different URLs involved in each work stream. I am VERY open to other ideas to make this easier for all..

I will say you can look here: http://build.fhir.org/ig/HL7/genomics-reporting/branches/ (with a few caveats)

• It shows the name of the 'branch' that, if the person working on it does right, should give good hint as to what is being worked on.
• It is not the most friendly page in the world, but it is 'built in' to how the FHIR IGs are built (so no extra work)
• It has many very old branches that are completely out of date, so make sure to look at the date to see what is most recent and ignore old stuff.

I will still contemplate something better.

Hayden Bader (Nov 17 2021 at 23:44):

A few comments to start out on the grouping page (http://build.fhir.org/ig/HL7/genomics-reporting/branches/withoutGrouper/groupingGuidance.html)

• Although there is a callout that the mixed use grouper is an exaggeration, I think it raises the question of SHOULD we have recommendations for mixed grouping? The above example could just have a group for each variant.
• The above raises the question - should grouping / groupers be allowed for single observations? It looks like it is for figure 2.
• For 1.7.2 - does O&O recommend using the summaryOf extension to represent subsets of DiagnosticReports? If so, what is supposed to be on the highest level of the DiagnosticReport.results?
• I don't think we should say "if a lab were to not follow good practice and send only grouping observations as results for report" - if we're not making a determination on groupers/grouping, we can't really recommend that it's against best practice to send some non-grouped observations

Arthur Hermann (Nov 17 2021 at 23:51):

Kevin Power said:

What page Arthur Hermann ? Bret H introduced this page? http://build.fhir.org/ig/HL7/genomics-reporting/branches/withoutGrouper/groupingGuidance.html

He also added a link to that guidance page from the General page, it is the last paragraph under Genomics Report section. Are you referring to the Genomic Observations section of the General page? http://build.fhir.org/ig/HL7/genomics-reporting/branches/withoutGrouper/general.html#genomic-observations

Or something else?

Sorry for not being clear... I think we want a paragraph on grouping (with a link to the new page) somewhere on the General Genomic Reporting page: http://build.fhir.org/ig/HL7/genomics-reporting/branches/kp-file-attachments/general.html ... unless I am missing something and there is already a link or text there..

Kevin Power (Nov 17 2021 at 23:59):

@Arthur Hermann - As I mentioned there is a link. It is under the Genomics Report section, 3rd paragraph?

Arthur Hermann (Nov 18 2021 at 00:01):

These sentences on the new grouping detail page reference an example above, but it isn't clear what they are referencing: (similar to the example above without grouping and the pharmacogenomics example based on EMERGE but without grouping): AND similar to the oncology example above

Arthur Hermann (Nov 18 2021 at 01:10):

Kevin Power said:

Arthur Hermann - As I mentioned there is a link. It is under the Genomics Report section, 3rd paragraph?

Thank you! Sorry for the extra work.. was looking at the wrong version of that page.. .as I said.. versioning is getting a bit challenging :oh_no:

Kevin Power (Nov 18 2021 at 13:31):

Hayden Bader said:

A few comments to start out on the grouping page (http://build.fhir.org/ig/HL7/genomics-reporting/branches/withoutGrouper/groupingGuidance.html)

• Although there is a callout that the mixed use grouper is an exaggeration, I think it raises the question of SHOULD we have recommendations for mixed grouping? The above example could just have a group for each variant.
• The above raises the question - should grouping / groupers be allowed for single observations? It looks like it is for figure 2.

We are calling out that FHIR Observation allows for a variety of grouping options, and wanted to provide some examples of what implementers should expect. And yes, groupings of a single observation would be allowed.

• For 1.7.2 - does O&O recommend using the summaryOf extension to represent subsets of DiagnosticReports? If so, what is supposed to be on the highest level of the DiagnosticReport.results?

The current R4 definition of summaryOf is honestly pretty light: "A summary report that points to subordinate target reports." To me, each report (top level or subordinate) should follow the guidance we provide here. I would probably have to refer you to O&O for more concrete guidance on that one though.

• I don't think we should say "if a lab were to not follow good practice and send only grouping observations as results for report" - if we're not making a determination on groupers/grouping, we can't really recommend that it's against best practice to send some non-grouped observations

I want to hear from others on this one, but it's not that we are "not making a determination on groupers/grouping" - we are "not currently constraining what sort of grouping is allowed" - meaning our determination on groupers/grouping as of now is to allow the base Observation features to cover this for us.
I am personally fine with providing the guidance that the best practice is to reference all Observations from the report for the reasons listed.

Bret H (Nov 18 2021 at 16:22):

Joel Schneider said:

Considering the removal of the Grouper profile, should the following wording on the withoutGrouper/background.html page be revised?

The organization of the report is often accomplished by subsetting (sometimes recursively) using the Grouper Observation. The structure of these groups is usually driven by the types of testing and/or panels requested, though they can vary depending on the reporting lab. In some cases, no subdividing organization will be provided at all.
``

Yes. on it

Bret H (Nov 18 2021 at 16:24):

ps to All, darn good comments and discussion. Please keep it coming!

Arthur Hermann (Nov 18 2021 at 21:32):

@Kevin Power - I once again used a Word Document with tracking on - to edit the introductory paragraphs of the grouping page. Of course, others should review my edited version. My changes were simply to ease the reading/understanding of the paragraphs. I certainly don't mean to change the meaning of anything included. Please see attached an make changes as you see fit. Genomic-observations-can-be-organized-and-grouped-together-in-a-wide-variety-of-ways-AH-Edit.docx

Kevin Power (Nov 18 2021 at 21:33):

@Bret H ^^^

Bret H (Nov 19 2021 at 17:30):

Thanks @Arthur Hermann looks good. Should be end by end of day. @Hayden Bader adjusting language as per your comments.

Bret H (Nov 19 2021 at 21:01):

I'm looking to add the text in italics: The genetic findings, implications and region studied profiles all contain links to computably define their relationships (e.g. the variant observation is referenced within the implication profile using derivedFrom). That is, the relationships define a semantic grouping, a composite relationship between implication, haplotype, genotype observations and the appropriate variant observations.

Does it work well?

Bret H (Nov 19 2021 at 21:06):

Here's a preview of the changes made to @Arthur Hermann word doc. Genomic-observations-can-be-organized-and-grouped-together-in-a-wide-variety-of-ways-AH-bh-Edit.odt

I edited in OpenOffice but the format should be able to be opened with word - if there's an issue let me know, or wait for the changes to be pushed to the branch.

Arthur Hermann (Nov 19 2021 at 22:11):

@Bret H - yes that sentence looks good to me. However, should it be haplotype OR genotype observations?

Arthur Hermann (Nov 19 2021 at 22:19):

@Bret H I found a few issues in the doc you provided. Please see this version. Genomic-observations-can-be-organized-and-grouped-together-in-a-wide-variety-of-ways-AH-second-edit.odt

Bret H (Nov 19 2021 at 23:00):

It can be both, essentially any of the genomic observation profiles. An 'or' can help that sentence.

Thanks for your efforts Authur.

Bret H (Nov 21 2021 at 02:21):

fyi pushed the edits to the text. query page not updated yet but the rest is.

Jamie Jones (Nov 22 2021 at 22:19):

Loaded some of the recent examples "with + without grouping" into our old connectathon sandbox and tested the query we want: &_include=DiagnosticReport:result&_include:iterate=Observation:has-member&_include:iterate=Observation:derived-from

• report with grouping (http://build.fhir.org/ig/HL7/genomics-reporting/branches/withoutGrouper/Bundle-oncologyexamples-r4.html)
  --> https://api.logicahealth.org/CGConnectathon27/open/DiagnosticReport?_id=14766&_include=DiagnosticReport:result&_include:iterate=Observation:has-member&_include:iterate=Observation:derived-from

• same report without grouping (http://build.fhir.org/ig/HL7/genomics-reporting/branches/withoutGrouper/Bundle-oncologyexamples-r4-noGrouping.html):
  --> https://api.logicahealth.org/CGConnectathon27/open/DiagnosticReport?_id=14779&_include=DiagnosticReport:result&_include:iterate=Observation:has-member&_include:iterate=Observation:derived-from

Kevin Power (Nov 22 2021 at 22:50):

Thanks Jamie, so seemingly returns everything we want in both cases, right? Although, I suppose the DRs include result() references to All observations. Should our example that includes group observations only have those group observations be referenced from DR.result ? I still like the guidance that everything should be referenced, but it might be worth ensuring that we will still get all results with that query if someone send that?

Jamie Jones (Nov 22 2021 at 22:54):

Yes that is a query parameter that should return all results and nested leaf Obs in them, whether the leaf Obs are "resulted" or not.

Kevin Power (Nov 22 2021 at 22:55):

Fair enough.

Joel Schneider (Nov 23 2021 at 06:34):

Returning all results may be a relatively simple scenario. A consumer of the data may also need to consider the possibility that some of the hasMember or derivedFrom references could not be resolved.

Bret H (Nov 23 2021 at 12:13):

Could you say more Joel? Are you suggesting a scenario where the targets of hasMember where not sent?

Bret H (Nov 23 2021 at 13:26):

BTW to further test out the query, I did some additional examples, including a very contrived one where only a single grouper pointing to Therapeutic implications was referenced by DisagnosticReport.result The query was able to iterate through the grouper hasMember and through the derivedFrom links to get to the variant observation. We could do additional tests but does that seem sufficient @Kevin Power

Bret H (Nov 23 2021 at 13:35):

https://api.logicahealth.org/FHIRGenomics/open/DiagnosticReport?_id=16931&_include=DiagnosticReport:result&_include:iterate=Observation:has-member&_include:iterate=Observation:derived-from

The ampersands with include tell the server to 'include' everything through the result reference, and to include everything that can be found through hasMember or derived-from links (the iterate operator tells the server to iterate through the links).

It's a query to demo the syntax of the iterations.

Can those watching this thread indicate what use case they'd like to have a query for? I would like to highlight which of the queries meet the use case.

Current page in branch is not updated yet.

Kevin Power (Nov 23 2021 at 14:51):

Joel Schneider said:

Returning all results may be a relatively simple scenario. A consumer of the data may also need to consider the possibility that some of the hasMember or derivedFrom references could not be resolved.

What kind of scenarios are you thinking Joel? Cases where someone sends an Implication that doesn't include a derivedFrom() to a Finding, even though it is supposed too? Error-like situations where observations are not linked correctly? Perhaps the situation that Lloyd mentioned yesterday (the other resources are on other servers)? Something else?

Joel Schneider (Nov 23 2021 at 15:50):

Joel Schneider said:

Returning all results may be a relatively simple scenario. A consumer of the data may also need to consider the possibility that some of the hasMember or derivedFrom references could not be resolved.

Bret H said:

Could you say more Joel? Are you suggesting a scenario where the targets of hasMember where not sent?

The Reference data type allows for some variability in its usage. A search might be unable to comprehensively resolve an identifier reference, or an absolute URL reference pointed at a different server, for example.

Kevin Power (Nov 23 2021 at 15:59):

I got ya, thanks for the extra detail. This is where we have to decide how much detail we provide as guidance versus how much do we trust that implementers will read and understand the base spec. I suppose a statement similar to your response above might be sufficient to give our implementers a little nudge in reviewing how FHIR references work.

Bret H (Nov 23 2021 at 16:04):

@Joel Schneider @Kevin Power agreed. I'll add in the statement from Joel.

Joel Schneider (Nov 23 2021 at 16:05):

Yeah, if we're offering an example search, we might also want to mention a need to inspect the search result, to determine whether it's missing some portion of the pertinent data.

Kevin Power (Nov 23 2021 at 16:07):

Might be a challenge for a consumer to know if something is missing or not.

Joel Schneider (Nov 23 2021 at 16:11):

Yes, the consumer would need to look through the search results for dangling references.

Kevin Power (Nov 23 2021 at 16:15):

Sounds like a case to reject the report/bundle to me.

Arthur Hermann (Nov 23 2021 at 18:41):

Based on today's conversation to add the page with extended guidance on grouping as an appendix - I wanted to note that the following changes should be included when we do so:

New Appendix Page and all references to it, should be called: "Grouping of Observations"

I would think that there should be a paragraph about grouping in the General Genomic Reporting Page (not just the Query section) - Do folks agree? : http://build.fhir.org/ig/HL7/genomics-reporting/general.html#general-genomic-reporting

Querying: Add some text re: grouping and point to the appendix for further information :http://build.fhir.org/ig/HL7/genomics-reporting/branches/withoutGrouper/general.html#querying

Add the Appendix itself and text that describes the Appendix - On the Appendix Section on the "Landing Page" : http://build.fhir.org/ig/HL7/genomics-reporting/branches/withoutGrouper/index.html#appendices

Please forgive my ignorance - but I see all of the activity on grouper being focused on Queries. I assume that the page (now to be an appendix) takes care of SENDING information using some type of grouped method correct? If so, this is what should be mentioned on the General Genomic Reporting Page (which also includes a short addition and link to the appendix in the Query section.

Bret H (Nov 23 2021 at 20:32):

Arthur Hermann said:

I would think that there should be a paragraph about grouping in the General Genomic Reporting Page (not just the Query section) - Do folks agree? : http://build.fhir.org/ig/HL7/genomics-reporting/general.html#general-genomic-reporting

There is one currently and it will be modified. Here's the current text:
Results observation profiles, like genomic observations, are typically referenced directly by a Diagnostic Report. For genomics this would be in the genomics report. The genetic findings, implications and region studied profiles all contain links to computably define their composite relationships (e.g. the variant observation is referenced within the implication profile using derivedFrom). Also, the observations could be organized into groups by other observations. See this grouping guidance for an overview with examples and considerations for processing reports.

Arthur Hermann (Nov 23 2021 at 20:58):

That is perfect! "this grouping guidance" would be a link to the appendix of course..

Bret H (Nov 26 2021 at 03:44):

Grouping observations page, Table of contents, Dropdown in header bar, index, general and query pages are done.

http://build.fhir.org/ig/HL7/genomics-reporting/branches/withoutGrouper/groupingGuidance.html
http://build.fhir.org/ig/HL7/genomics-reporting/branches/withoutGrouper/toc.html
http://build.fhir.org/ig/HL7/genomics-reporting/branches/withoutGrouper/index.html#understanding-fhir
http://build.fhir.org/ig/HL7/genomics-reporting/branches/withoutGrouper/index.html#appendices
http://build.fhir.org/ig/HL7/genomics-reporting/branches/withoutGrouper/general.html#genomics-report (be sure to read the whole section, especially 'Genomic Report Overview')
http://build.fhir.org/ig/HL7/genomics-reporting/branches/withoutGrouper/general.html#referencing-observations-from-genomicsreport
http://build.fhir.org/ig/HL7/genomics-reporting/branches/withoutGrouper/general.html#querying
http://build.fhir.org/ig/HL7/genomics-reporting/branches/withoutGrouper/usecases.html#appendix-d-query-guidance

Published :tada:

Kevin Power (Dec 02 2021 at 14:29):

These changes have merged to master! Many thanks to everyone, but especially @Bret H for all his hard work on this one.
https://media2.giphy.com/media/IwAZ6dvvvaTtdI8SD5/giphy.gif?cid=c623cb350b7liios0gfpmueh2tgb7jyibd8ifaps0ionfp07&rid=giphy.gif&ct=g

Arthur Hermann (Dec 02 2021 at 19:07):

Kevin Power said:

These changes have merged to master! Many thanks to everyone, but especially @Bret H for all his hard work on this one.

@Kevin Power - can you clarify where to find this now? Sorry.. so many branches.. when you mean master - do you mean it is actually published to our continuously updated public version? Can you provide a link please?

Kevin Power (Dec 02 2021 at 19:08):

Yup, this is the location for 'master':
http://build.fhir.org/ig/HL7/genomics-reporting/

---

Last updated: Apr 12 2022 at 19:14 UTC