Stream: genomics
Topic: GenomicsReport 0..0 JIRA ticket
May Terry (Jan 31 2022 at 17:02):
@Jamie Jones Following up on our meeting today - here's the JIRA issue to remove the 0..0 constraint on GenomicsReport: https://jira.hl7.org/browse/FHIR-35907
Patrick Werner (Feb 03 2022 at 13:56):
Just saw, that specimen also includes a 1..1 on patient. I think we should remove this as well. Commented on the ticket.
Kevin Power (Feb 03 2022 at 14:01):
Seems like we could just remove our profile of Specimen completely?
Bret H (Feb 03 2022 at 15:21):
Yes. But then the IG does not enforce specimen's connected to a patient or group or location. That is, one could send a specimen without a patient. Before removing it, I think a time-boxed 15 min on a FHIR subgroup call would be good to get perspectives. I'm thinking Bob M or Bob F might wish to comment.
Bob Milius (Feb 04 2022 at 19:25):
I would not require specimen to have a Patient. We send specimen that only has an specimen ID to our contract labs. Multiple specimen IDs may come from the same patient. Labs have no idea who the Patient is.
Kevin Power (Feb 04 2022 at 19:29):
I agree with @ Bob Milius -- I think this is an area we should be less prescriptive, meaning I still support dropping our specimen profile completely. If Specimen as is suffices for other lab workflows, I am not sure why would we force something different?
Kevin Power (Feb 04 2022 at 19:35):
Just so everyone knows, our specimen profiles does the following:
- changes 'subject' attribute from 0..1 to 1..1
- limits 'subject' references to only Patient, Group, or Location (removing the options for Device and Substance)
Kevin Power (Feb 04 2022 at 22:27):
@Jamie Jones - Can we put this on the agenda for Monday?
Kevin Power (Feb 04 2022 at 22:31):
Will post on the JIRA, but we have 4 total places we do 0..0 an attribute:
RegionStudied(Observation).value[x]
GenomicsServiceRequest(ServiceRequest).doNotPerform
GenomicsReport(DiagnosticReport).imagingStudy
GenomicsImplication(Obervation).value[x] -- which means DiagnosticImplication and TherpeuticImplication have value[x] as 0..0
Bret H (Feb 05 2022 at 17:30):
Sounds great to me. I was trying to elicit the use case that prompted the cardinality. It was done intentionally, I was essentially wondering why. I can't remember and if no one can think of a use case, then seems pretty straightforward.
Kevin Power (Feb 08 2022 at 17:16):
For anyone who might be thinking about working on this one, I would propose we wait to implement this until after we merge the component definition updates. Those changes were not complicated, but they were wide spread - so maybe easier to wait?
Patrick Werner (Feb 09 2022 at 11:17):
PR for the definition update is reviewed, approved & merged.
Kevin Power (Feb 09 2022 at 15:17):
I am creating a branch for FHIR-35907 (0..0 removal) and will be working on applying it during breaks today.
Kevin Power (Feb 09 2022 at 15:21):
Just curious - I noticed that we have constrained the DiagnosticReport.media to 0..1 (from 0..*) - anyone know why we did that?
Kevin Power (Feb 09 2022 at 15:25):
Looks like this was part of our very first release - but I really don't remember why we did that, and it seems a little weird now that I look at it.
Bret H (Feb 09 2022 at 15:48):
I don't see the element in DSTU2 or DSTU3. Maybe we added it prior to R4. I'm glad we have JIRA we can link to changes today.
Kevin Power (Feb 09 2022 at 15:52):
Thanks @Bret H - Do you see any concerns with removing our constraint?
Bret H (Feb 09 2022 at 16:03):
If we keep the constraint, I guess we'd force someone to make a second report? No, I can't see a strong reason other than maybe in most circumstances you would want to only send one (smaller package perhaps and less ambiguity about which media file is important - but the comment might help a human with that). A reason to remove the cardinality would mean that someone using US CORE could use multiple media and validate with our IG.
If someone sends multiple media they better make sure that one can tell what the media is and how it impacts the report.
The worst case I am coming up with, regards genomics, is multiple FISH results and someone wanting to send an image of the FISH results without connecting to the Observation directly, causing some confusion as to which image goes where -- but I can't see that being sent. If someone has a graphical image they wish to render, I wonder if adding it to the .text Narrative or elsewhere would be good?
One thought is that a PDF could go there, but the PresentedForm is a much better option (R4).
Sorry
Kevin Power (Feb 09 2022 at 17:03):
It is always possible that those images would be included in the report (presentedForm). But, it seems weird that if someone wanted to include 3 images, they couldn't with our profile today. I propose we drop it.
Kevin Power (Feb 09 2022 at 20:32):
OK, i have made the approved change, and a few more based on the 'spirit' of what we voted on. I summarized them on the JIRA:
https://jira.hl7.org/browse/FHIR-35907
I tried to format something to put it here too, but its proving difficult - please review the comments on the JIRA.
Kevin Power (Feb 09 2022 at 20:35):
Would like a review by (AT LEAST) @Jamie Jones @Patrick Werner @ Bob Milius @Bret H @May Terry
Kevin Power (Feb 09 2022 at 20:46):
I pushed all of the changes to a branch, and created the following PR to make the review of the changes easier:
https://github.com/HL7/genomics-reporting/pull/55
Patrick Werner (Feb 10 2022 at 09:28):
currently reviewing.
What do you think about statements like:;
`
- for only Reference(Patient)
- requester only Reference(Organization)
`
Patrick Werner (Feb 10 2022 at 09:28):
MedicationRecommendation
Patrick Werner (Feb 10 2022 at 09:30):
i would propose to allow Reference(Patient | Group | Device | Location) for Task.for. This reflects the allowed data types in Observation.
Patrick Werner (Feb 10 2022 at 09:31):
requester i would unconstrain to the default of Task
Patrick Werner (Feb 10 2022 at 09:32):
- removed constrains on GenomicsBase (commited and pushed)
Kevin Power (Feb 10 2022 at 13:16):
Good find and yes I agree with those. Do you mind adding them to the JIRA (if you haven’t already)?
Bret H (Feb 10 2022 at 13:17):
@Patrick Werner what do you mean "requester i would unconstrain to the default of Task"
Kevin Power (Feb 10 2022 at 13:20):
I think he means just remove any constraint on the Task.requester attribute
Patrick Werner (Feb 10 2022 at 15:12):
which i already applied in the branch
Bret H (Feb 10 2022 at 15:13):
just a note, but where we have derived-from with required cardinality (e.g. 1..*) is a place where someone not looking at our IG could send, for example, a Diagnostic implication without a derived-from. However, that would be incorrect based on our IG, even though it can validate against US CORE. My point is that if someone wants to be validated against multiple IGs they will always need to understand both IGs. We've made it so that profile instances from the CG universal IG will not inherently conflict with the US CORE IG. I think that is the best we can do. And anyway, if someone is sending the CG IG Diagnostic Implication then I guess they should have noticed the cardinality requirement.
Ultimately, it's about people knowing there is an IG and deciding to adopt it.
Kevin Power (Feb 10 2022 at 15:19):
I actually propose going even further than Patrick: for our task profiles, I would propose we completely remove the constraint on 'for' rather than limit it.
Kevin Power (Feb 10 2022 at 15:28):
Bret H said:
Ultimately, it's about people knowing there is an IG and deciding to adopt it.
I would agree 100% with that and the rest of your comment. We are not saying we shouldn't implement constraints, I think this exercise is making us look closely at 'do we really need that, or not?' -- for something like derivedFrom on Implication, yes, I think we all think we would keep them.
Patrick Werner (Feb 10 2022 at 16:01):
+1 for brets comment. There are places where we want to enforce stuff
Patrick Werner (Feb 10 2022 at 16:02):
Kevin Power said:
I actually propose going even further than Patrick: for our task profiles, I would propose we completely remove the constraint on 'for' rather than limit it.
i'm fine with that, i just constrained it to all possibilities of observation.subject.
Kevin Power (Feb 10 2022 at 17:41):
So, have heard from Bret and Patrick - any comments from @Jamie Jones @ Bob Milius @May Terry ? Or others who want to weigh in?
Kevin Power (Feb 10 2022 at 17:43):
It is really two questions:
1) Is everyone in agreement that these additional changes that were not explicitly called out in the JIRA still meet the spirit of the JIRA and should be made?
2) If yes, should we revote on the JIRA?
Jamie Jones (Feb 10 2022 at 18:03):
I approve of the serviceReq change, here's updated diagrams for general and Pgx: image.png image.png Also fine with removing those constraints on our Tasks. Our main value there is identifying the Codes to use and specifying that the reasonReference Obs should be a Tx Imp
Jamie Jones (Feb 10 2022 at 18:15):
image.png image.png Couple other updates to fix "Medication Recommendation" name while we're here ;)
Kevin Power (Feb 10 2022 at 18:18):
Thanks Jamie! I will update the branch with these images.
Arthur Hermann (Feb 10 2022 at 18:24):
@Jamie Jones Do we need to make any changes to the service request code on the Pharmacogenomics page? I don't believe so, but just double checking. Thanks for updating all of those diagrams!!
Jamie Jones (Feb 10 2022 at 18:36):
@Arthur Hermann I reviewed, looked good to me
Bob Milius (Feb 10 2022 at 18:38):
Kevin Power said:
So, have heard from Bret and Patrick - any comments from Jamie Jones Bob Milius May Terry ? Or others who want to weigh in?
Which artifact to you want comments on? the jira ticket? the github branch? the constraint-updates build?
Kevin Power (Feb 10 2022 at 18:46):
Bob Milius said:
Which artifact to you want comments on? the jira ticket? the github branch? the constraint-updates build?
Yes? :smile:
In theory, they should all have the same changes documented, so it just depends on what you find easiest to review.
Kevin Power (Feb 10 2022 at 18:48):
To see specifically what changed, you will probably need to review either the JIRA comments or the GitHub Pull Request. If you then want to see how the changes actually look, you can review the constraint=update branch.
Kevin Power (Feb 10 2022 at 18:51):
RE: images - I just pushed them to the 'constraint-updates' branch. And as I did, I realize that the ones where you renamed 'Med Usage Task' to 'Med Recommendation' are really NOT tied to the constraint updates but are really tied to the new technical correction JIRA that was created by @Bret H -- so Bret, sorry about that, but I guess the easiest thing for you to do is just not worry about the image changes knowing that once we merge this branch, they will be fixed.
Kevin Power (Feb 10 2022 at 18:59):
I should acknowledge this really isn't best practice, so I wouldn't encourage we do things like this on a regular basis. I think for this situation, it is probably OK to leave it though. In the end, the fix will get applied, which is the important thing.
Kevin Power (Feb 10 2022 at 19:00):
And by "this" I mean "fixing an issue that is just a part of Jira B in a branch where we are focused on Jira A"
Jamie Jones (Feb 10 2022 at 19:02):
I agree, could use the first 2 images in this branch and then put the rest in elsewhere if preferred. My thinking is that since the profile name in this branch is already updated, it seems silly to purposefully NOT fix the typos in the graphics that we are aware of
Kevin Power (Feb 10 2022 at 19:05):
Yea, to be honest, the real problem here is that when the name change was applied, the implementer (me :frown: ) should have made these changes along the way.
Kevin Power (Feb 11 2022 at 19:49):
Hey @May Terry or @Bret H - I was taking a spin through our JIRA backlog, and found this one that we haven't addressed yet:
https://jira.hl7.org/browse/FHIR-34144 (Variant valueCodeableConcept too constrained. Conflicts with USCoreLabResultObservation)
Since one of the reasons we did the work on the '0..0' JIRA was to help our alignment to USCORE, do we need to also consider this one? It is really late in the game to consider new work, but I would also hate to make really good progress on this theme of making our profiles easier to use with USCORE to simply miss this one thing that would limit the ability to use Variant (obviously one of our most important profiles).
Thoughts?
Bret H (Feb 11 2022 at 20:42):
Technically it does not violate US CORE if the codes in the value set are not in SNOMEDCT. So there's nothing that needs to be done. @Kevin Power
Kevin Power (Feb 11 2022 at 21:12):
Thanks @Bret H -- I did see the SHOULD in the requirements and wondered the same. But I also saw where @May Terry said on the JIRA that This broke validation of mCODE examples for CancerGenomicVariant profile so thought maybe I was missing something?
Bret H (Feb 11 2022 at 21:13):
The JIRA was long before we did the analysis at the WG meeting.
Last updated: Apr 12 2022 at 19:14 UTC
