Stream: genomics
Topic: mCODE Sept 2019 Ballot General CG Reporting-related comments
May Terry (Oct 22 2019 at 04:38):
As a follow-up to the mCODE/CG alignment review on 101/15, attached is a spreadsheet export of the mCODE FHIR IG Sept 2019 Ballot GForge comments filtered for those related to clinical genomics. mCODE_GForgeComments_ClinGenomics_20191022.xls
Kevin Power (Oct 22 2019 at 17:17):
Thanks for sharing @May Terry - It is great to see the whole list, but are there specific items you want input on?
May Terry (Oct 23 2019 at 03:05):
@Kevin Power - I guess to start, the following would be great for group review/discussion - reviewing the proposed ballot resolution description and/or follow-up comments: 23994. 23999, 23987, and 23997 might need discussion on a Monday call, but it's about consideration of our definition of "alignment" of profiles by agreeing to mCODE created FHIR instances that validate with a genomics profiles (e.g.: obs-variant) as opposed to having the mCODE profile derived from obs-variant. cc: @Mark Kramer
Mark Kramer (Oct 23 2019 at 11:20):
Which version of the genomics IG should we be looking at?
Kevin Power (Oct 23 2019 at 13:19):
@Mark Kramer -- We are going through publishing, so for now current build: http://build.fhir.org/ig/HL7/genomics-reporting/
Kevin Power (Oct 23 2019 at 13:20):
@James Jones - Can we add the trackers that @May Terry mentioned to the Monday agenda?
Jamie Jones (Oct 23 2019 at 15:12):
Sure thing
Bret H (Oct 25 2019 at 14:01):
I spoke to @Lloyd McKenzie during September's connecathon. How validation is done is up to the IG or at least that is how I recall his comment. It makes sense that instance data could be valid against multiple IGs - where those IGs are validating on non-overlapping sections (i.e. are compatible). @Lloyd McKenzie can you comment on validating instance data against multiple IGs? Many thanks.
Lloyd McKenzie (Oct 25 2019 at 14:33):
It's certainly possible for instances to be valid against multiple IGs.
Lloyd McKenzie (Oct 25 2019 at 14:35):
However, if you want the publication process to do the checking, the IG you want to do the validating would have to declare a dependency on the others
Bret H (Oct 28 2019 at 15:16):
@Lloyd McKenzie for conformance to a specific profile, would the lack of a 0...* or 0..1 cardinality on a specific slice of component mean that any instance that had the specific slice would fail?
Lloyd McKenzie (Oct 28 2019 at 15:16):
If you don't declare cardinality on a slice you inherit the cardinality of the base element (which would presumably be 0..*
Bret H (Oct 28 2019 at 15:17):
thx. also, I think we need to clarify the technical constraints on publication validation versus expectations in a live server environment.
Lloyd McKenzie (Oct 28 2019 at 15:20):
Shouldn't be any situation where those would be different that I can think of
Bret H (Oct 28 2019 at 15:24):
You mentioned that an instance can be valid against multiple IGs. Yet, you remark that 'if you want the publication process to do the checking' one must declare a dependency. However, when I send an instance to a server, I send and instance and do not declare the IGs that the instance validates against. Right? The recipient server determines the validity of the message and what to do with the information in the message, correct?
Lloyd McKenzie (Oct 28 2019 at 15:41):
Right. IG dependency is relevant in the publication and example checking process. Doesn't matter as much at runtime
May Terry (Nov 06 2019 at 20:13):
CGers! :-) - attached is the latest snapshot of the mCODE ballot comments, filtered for Clinical Genomics related issues. 19 of them are up for BlockVote#3 and BlockVote#A, to be voted on 11/13 at 10am ET at the Cancer Interop meeting. Please review and provide comments/feedback by 11/12 - preferably sometime this week if possible. Thanks! (cc: @Mark Kramer ) mCODE_GForgeComments_ClinGenomics_20191106.xls
Jamie Jones (Nov 07 2019 at 17:51):
Thanks for the share! Recap of the proposed votes for those too lazy to download excel files:
May Terry (Nov 08 2019 at 05:11):
re: mCODE Tracker GF24538 (https://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=24538&start=0), there is a suggestion to use LOINC 55233-1 (Genetics Analysis Master Panel ) instead of 69548-6, which is what mCODE, and the Genomics Reporting IG GenomicsReport profile also uses. What does the group think?
Kevin Power (Nov 08 2019 at 15:17):
I much prefer using 69548-6 (Genetic variant assessment) for the Variant profile as opposed to 55233-1 (Genetic analysis master panel). I am not sure if it is a requirement that codes used as Observation.component[].code should always be part of a panel of Observation.code? I think this is what the submitter was concerned about:
The profile constrains out the value and uses components to represent the results. These components are not children of 69548-6 and should not be used in this manner.
Jamie Jones (Nov 08 2019 at 17:58):
It's an interesting idea, restricting component codes based off of the panel structure in LOINC but my understanding is that aspect of the codes hasn't been widely adopted yet. If LOINC were more of an ontology I'd feel more confident in pushing for that but currently I don't think it's warranted
Jamie Jones (Nov 08 2019 at 17:59):
Is something to think about however, if we're able to structure all our concept in LOINC too it may add extra clarity
May Terry (Nov 11 2019 at 21:36):
Thanks @Kevin Power and @James Jones - It's a negative-major vote from the submitter, and we want mCODE to be as aligned with the CG IG as possible, at least in the use of LOINC 69548-6. So I'll propose the resolution as "Not Persuasive" at this time and note that CG might consider this at some point in the future. Thanks again!
May Terry (Nov 13 2019 at 01:26):
Hi CGers...working through GF#24002 (https://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=24002&start=0) on a Clem question whether we want to limit mCODE to probe testing? While the answer is no, would it be good enough if we made our TumorMarkerTestVS value set extensible to at least have coverage to tests which aren't covered? How does the CG Reporting IG handle this? Open to suggestions.
Patrick Werner (Nov 13 2019 at 09:37):
This tracker is about this profile: http://hl7.org/fhir/us/mcode/2019SEP/StructureDefinition-onco-core-GeneticVariantTested.html right?
Patrick Werner (Nov 13 2019 at 09:40):
if it is a probe test or not is coverd through the method. The VS bound to it (http://hl7.org/fhir/us/mcode/2019SEP/StructureDefinition-onco-core-GeneticVariantTested.html) allows to express probe test as well as NGS. So i don't see or get the issue.
May Terry (Nov 13 2019 at 15:31):
@Patrick Werner - yep! It's about GeneticVariantTested. I thought the VS could express both as well. ok. Since it's an affirmative comment, I'll reply with our discussed assumptions and propose as Considered - Question Answered. Thanks!
May Terry (Nov 13 2019 at 18:02):
actually, one correction...turns out that GF#24002 a major-negative asking an enhancement that we support more than just probe tests. Regardless, that doesn't change the positioning that we can support both. We can however make a note of it in our IG documentation and propose "Persuasive with Mod" instead.
Bret H (Nov 18 2019 at 17:50):
where is this?
Bret H (Nov 18 2019 at 17:50):
Thanks Kevin Power and James Jones - It's a negative-major vote from the submitter, and we want mCODE to be as aligned with the CG IG as possible, at least in the use of LOINC 69548-6. So I'll propose the resolution as "Not Persuasive" at this time and note that CG might consider this at some point in the future. Thanks again!
Which profile is in question? Can you shoot the link? I think I am confused. Maybe follow-up with you @May Terry privately for clarity?
May Terry (Nov 18 2019 at 17:58):
@Bret H - the link is http://hl7.org/fhir/us/mcode/2019SEP/StructureDefinition-onco-core-GeneticVariantTested.html
May Terry (Dec 03 2019 at 21:57):
Hi CG-ers! I've been making actively making changes to our mCODE genomics-related profiles which more closely align with the CG Reporting IG STU release that I'd like to review with you. Our plan is to distribute an STU1 "candidate draft build" for the overall community on Dec 15, however I'd like to present the changes to the team in a meeting prior to the release.
Would it be possible to have about 15-20 min during the upcoming 12/9 CG modeling sub-team meeting for an mCODE-CG alignment walkthrough?
I was previously asked if I can distribute a zip file or temporary CI build site but a decision was made internally to have controlled candidate releases instead.
cc: @Mark Kramer
Jamie Jones (Dec 03 2019 at 22:00):
There's room on the agenda for the CG FHIR subgroup call on 12/9. I believe either Gil or I will be presiding and we'd love to see the update
May Terry (Dec 17 2019 at 21:52):
Hi CG-ers! The mCODE STU1 Pre-release #1 has been posted to the HL7 CI: http://build.fhir.org/ig/HL7/fhir-mCODE-ig/branches/master/index.html. Also, attached is a spreadsheet with the latest ballot reconciliation status, filtered for the Clinical Genomics-related ballot issues. Given the upcoming holidays, we've extended the time for review so please provide feedback no later than Tuesday, January 7th so that we can address any fixes before our release of STU1 Candidate#2 on Jan 15th. Thanks to everyone in this WG who has been so helpful and proactive in helping us get to this point. mCODEBallotReconStatus_STU1PreRel1_CGFilter.xlsx cc: @Mark Kramer , @Caroline Potteiger
Last updated: Apr 12 2022 at 19:14 UTC
