No IM call on March 7. We're repurposing the time for a work session. Enjoy the hour back. (Announcing here as well, email sent to the list.)

Aly and I are preparing a submission for the AMIA symposium. We are targeting a podium presentation focusing on updates to the MolDef resource, citing the work of the IM subgroup. If you would like to take a look at it prior to submission, please let us know! Separately, we are planning at least 2 manuscripts that will derive from the IM work. Let us know if you're interested in contributing to the drafts. We'll be discussing these regularly during the IM calls.

Bob Freimuth said : Aly and I are preparing a submission for the AMIA symposium. We are targeting a podium presentation focusing on updates to the MolDef resource, citing the work of the IM subgroup. If you would like to take a look at it prior to submission, please let us know! Separately, we are planning at least 2 manuscripts that will derive from the IM work. Let us know if you're interested in contributing to the drafts. We'll be discussing these regularly during the IM calls. Hey Bob - I am interested in the IM work can please provide details of these calls. I would like to join them.

Kashmira Sawant said : Hey Bob - I am interested in the IM work can please provide details of these calls. I would like to join them. Thanks for the interest. The calls are announced on the CG listserv, so if you are subscribed to that you should get the info. Zoom room is the same as our regular WG calls. Notes are here: https://docs.google.com/document/d/13mYXDISneb3kpAymQnLpOvQMiZSzI7Y2vp500EYasxQ/edit

No IM calls March 14 and 21 :pie:

Hi All, Yesterday during the CG call, we checked JIRA FHIR-43744 where code systems for Genomic Study methods, change type, and data format were discussed. We got a recommendation of more discussion during the Thursday IM call to promoting the binding strength to preferred rather than example. We aim to discuss this during this Thursday IM call. @Bob Dolin , @Kevin Power will this work for you?

@John David Larkin Nolen will you be available to discuss FHIR-40567 briefly during the same call?

one more discussion point: FHIR-43744 regarding additional meta data

Thanks @Aly Khalifa . If possible, can we schedule this for the April 4 call?

Thanks Bob, I'm double checking with @Bob Freimuth

Apr 4 works. @Aly Khalifa could you please draft the agendas for Mar 28 and Apr 4 and put these topics in as appropriate?

where does the value set/ code system currently live?

April 4th works for me too!

@Bret Heale https://www.hl7.org/fhir/valueset-genomicstudy-methodtype.html https://www.hl7.org/fhir/valueset-genomicstudy-dataformat.html https://www.hl7.org/fhir/valueset-genomicstudy-changetype.html https://www.hl7.org/fhir/valueset-genomicstudy-type.html

Agenda for April 4th call: 1-FHIR-43744 a-Genomic Study value sets binding strength b-Genomic Study additional meta data 2-FHIR-40567, Renaming of Molecular Sequence formatted attribute,

It would be good consider putting them in THO. This way the value set can be independent of the FHIR build. IF you are using preferred rather than example binding, the value set might need the additional flexibility of being in THO

something to consider

@Aly Khalifa

Thanks a lot Bret, I hope we can. Joel Schneider recommended this too during today's discussion.

There is a caveat, we did not develop these lists by ourselves, we borrowed them from some other public resources as mentioned within the code system descriptions. For example, the methods are borrowed from NCBI GTR

Therefore, I hope we may discuss this point further during the call and decide our next step.

Not a problem. You can look for an appropriate copyright statement to add to the Value set copyright statement, or ask the owners for one. Often you'll find one on the source that you can simply copy.

@Bret Heale I'm thinking we may want to also look at the example changetype value set and see if it captures everything we need. I've been using it to better characterize the types of molecular changes detectable by a test, whereas the current value set is fairly broad (e.g. 'DNA changes', 'RNA changes'). In our Somatic example , I wound up using SequenceOntology codes for the changetype.

@Bob Dolin I am not certain we need it to capture everything in a Universal IG

Remember. The CG IG is really universal in scope. The sets need to be broader than the downstream use case IGs

best to avoid required unless absolutely known that an authoritative value set is appropriate (and the value set can change...even if a binding is required...at least theoretically). for example.

@Bret Heale That makes sense, but if we already anticipate needing additional codes, wouldn't we want to add them before advancing the value set from example to preferred?

In other words, the CG IG should not be meant to limit values to be used unless the community is certain. Or to put another way, there's no reason you can't add more values just do not give people the expectation that all values have been captured unless that is really the case (i.e. extensible binding is kinda like saying this without the required part).

Totally Bob Dolin said : Bret Heale That makes sense, but if we already anticipate needing additional codes, wouldn't we want to add them before advancing the value set from example to preferred? I think that's what is being determined in the IM meeting - is the breadth really capturing enough that a step closer to extensible can be made. I kinda see it like saying - 'We're pretty sure you are going to find what you need here, and everyone else is using the concepts from the code systems we indicate here" (for preferred) <--- the and part is where it gets interesting. I look forward to hearing if folks have evidence and believe the code-code-system pairs are truly the ones everyone prefers to use

That would be awesome!

@Aly Khalifa @Bob Freimuth @Bret Heale Here is a brief slide deck that we can look at on Thursday, providing a bit of background on Jiras 43744 and 43745 , along with draft proposals.

I'm looking forward to the discussion

@Bob Dolin Thanks Bob, me too

@Kevin Power @Aly Khalifa Based on this morning's IM discussion (around genomicStudyAnalysis' method-type, change-type, and output-type value sets), I got the sense that I'm not the only one that doesn't fully understand the THO process. Would this be a good topic for a Tuesday call, where we can talk with @Joel Schneider and figure out what our next steps might be?

I would welcome a discussion and review of the process, but this is probably a good place to start: https://confluence.hl7.org/display/TSMG/Terminology+Expectations+for+IG+Developers

And this: https://confluence.hl7.org/display/TSMG/Terminology+Play+Book

And this: https://build.fhir.org/ig/FHIR/ig-guidance/terminology.html

What is the question? I have been through the THO processes recently, perhaps I can share that experience.

When it comes time, I am happy to build the THO value sets. However, there is good reason NOT to add value sets to THO. If we have non-experimental value sets (or code systems) in the IG, we will need to get a root OID for the IG (simply post a request for one on the IG creation zulip chat).

additionally, it is relatively straightforward to have codes added to the TX server. Something, I have also been doing recently.

I think we are not alone in our struggles to work with vocabulary resources, navigate THO processes & policies, etc. The following thread contains additional discussion which may also be informative. https://chat.fhir.org/#narrow/stream/301245-TSMG/topic/Scope.20of.20UTG.2FTSMG.20Policy At a high level, some of the main points of concern are: what to do with "example" code systems whether to keep a code system within the IG (pending TSMG approval) or move it to THO pre-establishing the canonical system URL for a THO code system publishing a THO code system

If the code systems are purely experimental (and flagged as such), then there's no TSMG discussion. I have had experience recently publishing THO code systems - happy to help out. To the list, one should also add Getting codes onto the TX server. It is not a given that codes in THO are represented in the TX server - when validating an HL7 IG through the HL7 publisher one needs the codes on the TX server. I have recently done that as well and am happy to help.

@Bret Heale @Joel Schneider I'll be away tomorrow, but will request agenda time on Tue April 16. I think based on where we landed with IM discussion that a draft proposal is something like: [1] get URLs from THO (whether or not we retain the codes in the IG); [2] method-type: use codes from NCBI genetic testing registry and advance binding to preferred; [3] change-type: add sequence ontology hierarchies SO:0002072 and SO:0001060 and advance binding to preferred; [4] output-type: advance binding to extensible.

*add placing codes onto the TX server.

Other than convenience in the IG publishing process, I presume we have a good description of why the code systems need to be in THO. If the WG has evidence and believes that the consensus of industry is use of these codesystems, then that is important to have documented. But if these are only currently used in the WG's IG, then we should be thoughtful about asking for them to be in THO. If not already, can the description of why the codesystems should be in THO be included in the draft proposal? The WG will need that for the process going forward. @Bob Dolin

Hi All, As mentioned during our last IM call, there will be no IM call this week, i.e., no IM meeting on Thursday, April 11th, 2024. Thanks

@Aly Khalifa @Bret Heale @Joel Schneider fyi, I updated FHIR-43744 "GenomicStudyAnalysis needs additional metadata" and FHIR-43745 "GenomicStudyAnalysis needs value set updates" with concrete proposals.

Hi All, There will be no IM call this week, i.e., no IM meeting on Thursday, April 18th, 2024. Thanks

Hi All, As mentioned during the last CG call, there will be no IM call this week, i.e., no IM meeting on Thursday, April 25th, 2024. Thanks

Bob Freimuth said : Aly and I are preparing a submission for the AMIA symposium. We are targeting a podium presentation focusing on updates to the MolDef resource, citing the work of the IM subgroup. If you would like to take a look at it prior to submission, please let us know! Separately, we are planning at least 2 manuscripts that will derive from the IM work. Let us know if you're interested in contributing to the drafts. We'll be discussing these regularly during the IM calls. As a follow-up: our AMIA presentation got accepted and we will provide updates during the IM call.

As you may already have received through email, there will be no IM call tomorrow.

As highlighted in the HL7 Call Calendar, we will not have an IM call tomorrow.

I've issued the following JIRA ticket considering the autogenerated text of R5 Genomic Study Resource examples. https://jira.hl7.org/browse/FHIR-46541 I'll be working on it soon.

No IM call Aug 22. I need some work time to prep more material for discussion. Grab some coffee, stare blankly out the window, and enjoy 60 minutes of summer.

Something to ponder during tomorrow’s IM void… https://youtu.be/8lz-qrVUecE?si=wg-WdMVSmmAkhz_o

Any one in IM looking at the HL7 Lab Reporting IG? It has a good encapsulation of the report.

John David Larkin Nolen said : Something to ponder during tomorrow’s IM void… https://youtu.be/8lz-qrVUecE?si=wg-WdMVSmmAkhz_o 100%. Many of what I consider to be my most enlightening thoughts have come while staring out the window or pacing idly in circles.

Bret Heale said : Any one in IM looking at the HL7 Lab Reporting IG? It has a good encapsulation of the report. you mean this one https://github.com/HL7/uv-lab-rep-ig ?

Yep. It's just an FYI.

No IM call tomorrow. I've got a conflict that cannot be avoided. Aly and I are working hard on adding examples to the MolDef profiles. I've got a good list that demonstrates different aspects of the spec and Aly is making them real. We hope to be in a position to share them during the call on Sept 5.

I was hoping to hold IM tomorrow (Sept 12), but failed to convert timezones correctly. Apologies for the short notice, but we'll have to skip this one. I've got some interesting material ready to go for the WGM, though. :smile: I hope to see you there!

No IM call on Oct 17. I am visiting with Kevin and JD so will be with you in spirit. Enjoy the time back.

No IM call on Oct 24, as I am traveling (again). We're back on for the following week.

No IM call on Nov 7 due to ASHG

If anyone is going to be there, let me know if you want to meet up!

No IM call on Nov 14 due to AMIA On site meet up is a possibility. IM group lunch? LMK

IM will meet tomorrow (Nov 21). Several topics to discuss as we draft the MolDef specs.

Reminder: IM meeting today (now)

Hi All, We are planning to have our IM meeting this Thursday, Dec 12th, 2024. The agenda items are focusing on Molecular Definition resource: Terminating potentially cyclic/recursive structures Datatypes for IDs, accession numbers, and nomenclature Looking forward meeting you then, Thanks

Hi All, we will not have an IM calls for tomorrow and next week: No IM call on Dec 19th, 2024 No IM call on Dec 26th, 2024 Thanks and happy end of the year vacations.

No IM call on Jan 9. Updates in preparation for the WGM.

IM group is meeting now! Grab some coffee and join us!

IM call in 5 minutes! Agenda: sequence encoding, haplotype, genotype

See you in a bit

As per last week call, we may not meet today for IM call. @Bob Freimuth correct?

IM call today: 1) deciding on next steps for sequence encoding (nearly reached a decision on last call) 2) review/discuss proposed haplotype profile 3) review/discuss proposed genotype profile

Loose ends to be discussed as we have time: tri-allelic example of variation moldef relationship (related sequences) termination options referencing genome builds (ref: seq collections) review cytoband location Next modeling efforts (order TBD): biomarkers annotations features structural variation (e.g., fusions)

within the realm of related sequences, consider representation of homology to a homology set, or other measure of similarity e.g similarity to antibiotic resistance models as found in CARD: https://card.mcmaster.ca/ontology/36355

This sounds like a good use case. Could you please write up an example that illustrates the data that needs to be captured?

IM meeting now - grab some coffee and join us!

IM call today: associated gene to facilitate queries, draft genotype profile, simplified cytoband location structure (proposal)

Reminder: No IM call tomorrow (week following WGM)

Also: no IM call May 29

Some findings on how labs are filing cytogenetic location to our customer's systems: About 20% of the variants with "cytogenetic location" provided don't conform to the chr+arm+band+subband format. Examples of conformant cytogenetic locations (according to the regex I'm using) include "8q", "partial 4p", "4p13", "5q20q25" (range without dash), "3p9.26-p12.6" (range with dash), "7p19.25.2", etc. 70% of the variants do and have chr+arm+region+band, 8% with chr+arm+region, and 2% with chr+arm. Distribution varies between customer systems. For example, we have a customer with a lot more chr+arm than chr+arm+region or chr+arm+region+band. No variant has chr+arm+region+band+subband.

Thanks, Willie. If 70% include granularity down to the band level, I think we should support that in MolDef.

IM will meet on June 5. We're picking back up after the WGM and ISO meetings. Grab a beverage and join us!

Bob Freimuth said : This sounds like a good use case. Could you please write up an example that illustrates the data that needs to be captured? Sure, if I have a collaborator that is interested (someone who would be a future implementer)

Hi All, there will be no IM call this week, Thursday July 17th, 2025. Thanks, Aly

Hi All, As mentioned during today's CG call, please note that there will be no IM call this week, Thursday July 31st, 2025.

Hi All, We plan to have the IM call for this week as scheduled. We will be discussing the interesting topic of association/relationships among various MolDef resources. We will be focusing on: Translation, Transcription, and Predicted amino acid changes for a given genomic variation Looking forward to see you there.

Thanks to those that contributed to the call today. Slides from the last quarter or so have been loaded to the confluence page. https://confluence.hl7.org/spaces/CGW/pages/51227639/IM+Subgroup

Hi All, As per our last discussion during the last IM call and today's CG call, please note that there will be no IM call this week, Thursday August 14th, 2025.

Hi All, please note that there will be no IM call next week, Thursday August 21th, 2025.

Zoom is being cautious. I'm waiting for the security code, but it's taking a while to get through my institution's servers

I will start the zoom asap. If another co-chair gets the code first, please feel free to start

In a thing but got the code: 321769

@Aly Khalifa , I'm wondering if we should update this picture? Our current Variant profile uses observation.value to indicate present/absent, so I don't think we'd use a valueReference to point to MolDef? https://build.fhir.org/ig/HL7/molecular-definition-data-types/MolDef-diagnostic-relations_resized.png

Thanks Bob for raising this point. R6 Observation currently references MolDef from three main locations: value and component.value elements hasMember attribute derivedFrom attribute Link: https://build.fhir.org/observation-definitions.html#Observation.value_x_ One of the reasons to reference MolDef from value/component.value is to indicate the presence or absence of a specific allele, variation, haplotype, or genotype. We aim that when the current Genomics Reporting Implementation Guide be updated to FHIR R6, it would leverage both Genomic Study and MolDef. The Variant (a profile of Observation) may be updated to consider the MolDef Variation for patient agnostic data, while the Observation attributes focus on patient/encounter specific data, e.g., present/absent, interpretation, implications, ... etc. In R6, MolDef replaced MolSeq as per the last vote. Current R5 Observation, references MolSeq from within the same elements, i.e., value, hasMember, and derivedFrom. We also aim to discuss this next week during the WGM for more details and road mapping.

Today's IM call will be a working session to prep for the WGM. We will focus on creating concrete proposals related to the cytoband structure so we can take a WG vote on that topic, and fleshing out the examples for moldef relationships. I do not think we will have time during today's call to get into the other topics that will likely come up at the WGM, including annotations, but for those that will be at the WGM next week we hope to start roadmapping in that direction.

Aly Khalifa said : One of the reasons to reference MolDef from value/component.value is to indicate the presence or absence of a specific allele, variation, haplotype, or genotype. ... The Variant (a profile of Observation) may be updated to consider the MolDef Variation for patient agnostic data, while the Observation attributes focus on patient/encounter specific data, e.g., present/absent, interpretation, implications, ... etc. I think we should document what each of these options mean so that implementors know when to use valueReference(), derivedFrom(), and hasMember(). And it is likely we should document this on Observation? Or perhaps the Diagnostics Module? I just know I won't touch it since I broke that recently :wink: @JD Nolen what do you think?

In the R4 IG we only really discussed pointing to MolSeq via derivedFrom. While we considered the pattern of describing a specific variant in components and using valueCC to indicate the patient did NOT have that variant (negative assertion), I don't think we ever considered pointing to a MolSeq instance describing a sequence the patient didn't have. MolDef is different by way of being definitional so could better support a negative assertion but I'm still not clear anyone ever actually uses that pattern. The genomic operations for example return an operation outcome stating no hits if a certain query comes back empty. One of the other reasons we didn't have variant information in observation.valueCC was that too many elements were needed to fully describe the variant that was found. Kicking all that info out to MolDef is kind of a nice pattern, and implementers may be familiar with it a la MedicationRequest/Medication and a couple others.

I understand there are use cases for using hasMember to group observation(s) (and/or MolDef(s)?) under a grouper observation but I would hope that observation isn't claiming to be one of our variant profiles

All great points. I think having someone document what we currently have to describe when to use what is going to serve two purposes. 1) it is important to help implementors or 2) perhaps it helps clarify we did something wrong and need to undo it.

just to add, in STU3 we have: https://build.fhir.org/ig/HL7/genomics-reporting/histocompatibility-fig1-hla-a-genotype.png

Seems like the diagram would be easier to maintain if it was done using PlantUML .

PlantUML is "easy" to use, and certainly more portable and easier to diff/merge and the like, it seems to be very limited in the ability to manage the diagram yourself. If a specific structure is important, it is not very flexible.

Why not?

The Variant Profiles on Observation provide a means to send genomic data that uses Observation, a resource commonly implemented. Placing the actual result or meaning of on Observation behind an additional reference can be difficult, especially if that reference is an unsupported Resource. There needs to be broader discussion before the Variant Observation profiles are dispensed with.

It would be remove the ability to declare that a Variant was found by a Variant Profile instance if valueRef is used in that Variant instance.

FWIW - I have a feeling the Observation profile we use once MolDef is in the picture will not be the same Variant profile we have in the GRIG today. It will be a very different approach from the 'component heavy' approach in Variant, so we will (likely/probably?) have to develop a different set of Observation profiles that utilize MolDef. That comes with its own set of problems and issues, but it will probably be the safest option. At this point, we don't really know what it will look like. At least I don't :slight_smile:

That is something which should be discussed and properly trialed against the current approach at multiple connectathons. Especially as the Variant Profile is being implemented. I have yet to see an example that includes a diagnostic report compared to an example of the same thing using the variant profile, for example. I have to be unconvinced till the proper work is done. Btw, The promise was not replacement when the pss was voted on.

There is some risk that having an R6 MolDef IG out there before we have an R6 Genomic Reporting IG out there will cause implementer confusion. We may want to consider prioritizing an R6 Genomic Reporting IG over an R4 STU4 IG.

Further, doing something radically different will need to be weighed with the cost of R6 adoption. Is it the right time? Make sure the whole worlflow is thought thru. I.e. if I was a lab would I send moldefs? Would I retain a server for the reference target? Or, would I hope theres a publicly (stablely) funded, well maintained repository? .... just a tiny piece of the considerations to discuss I would recommend that the points of view of voters be recorded to avoid confusion, if anything is voted on regarding road map - be the voter, implementer, lab system, emr vendor or university professor

@Bret Heale I am confident it will all be discussed in great detail before decisions are made, as is always the case with the WG. We have been so focused on the MolDef resource and MolDef IG that we haven't spent as much time talking about how the Observation profiles that will leverage MolDef profiles. -edit: FWIW, I agree with you that we need testing of the MolDef approach and how it compares to the current GRIG. We all do. This has been challenging due to R6 timelines, but someone must do it. @Bob Dolin Interesting perspective. We should review the MolDef IG index page, and if we don't have a discussion about this, we should. @Bret Heale We do consider workflows in the meetings, you are welcome to attend and bring your views. I know the plan is to continue discussing at the WGM. Regarding voting, and views of voters, are you suggesting a change to the voting process? The ballots (the people, their organization, and how they voted) is available to any HL7 voting member. (edit - Also votes taken during meetings, like to approve the PSS, are documenting in our meeting minutes including everyone who was in attendance and any discussion, and are available to everyone on Confluence). What else are you looking for?

Jamie Jones said : In the R4 IG we only really discussed pointing to MolSeq via derivedFrom. While we considered the pattern of describing a specific variant in components and using valueCC to indicate the patient did NOT have that variant (negative assertion), I don't think we ever considered pointing to a MolSeq instance describing a sequence the patient didn't have. MolDef is different by way of being definitional so could better support a negative assertion but I'm still not clear anyone ever actually uses that pattern. The genomic operations for example return an operation outcome stating no hits if a certain query comes back empty. One of the other reasons we didn't have variant information in observation.valueCC was that too many elements were needed to fully describe the variant that was found. Kicking all that info out to MolDef is kind of a nice pattern, and implementers may be familiar with it a la MedicationRequest/Medication and a couple others. Back to the question at hand (In R6, should we have Observation.valueReference() point at MolDef). Since this will be defined in R6 and without the context adding profiles we would have in IGs, it might be challenging. As @Aly Khalifa said, in R5, we made the decision to point valueReference() at MolSeq, and I think that is the reason we have it pointing at MolDef in R6. But honestly, I can't remember why we added that in R5. I will have to go back to JIRAs and see if I can find details.

OK, here is the JIRA that added it: https://jira.hl7.org/browse/FHIR-40292 -edit: here is the commit: https://github.com/HL7/fhir/commit/398f7536c6715b0d74192b66d93351384e243cf8 It did also add a comment "* The usage of valueReference is restricted to the MolecularSequence resources when used as a definitional resource, not as a patient-specific finding." As an aside, we should fix that comment for Observation for R6. The usage of valueReference is restricted to the MolecularDefinition resources when used as a definitional resource, not as a patient-specific finding. . It should probably read slightly differently: The usage of valueReference is restricted to the MolecularDefinition resources as a definitional resource, not as a patient-specific finding. CC: @JD Nolen do you agree? FYI: @Aly Khalifa we missed tweaking this line in the removing of all references to MolSeq.

I'll go forward and make this tweak

As a side note, the restriction of valueReference to MolDef as defintional is implicit, because MolDef is defitional, no subject or patient elements are there. This was the main principle of MolDef, the separation between patient specific and patient agnostic data elements. Eventually, and hopefully this will make GRIG more robust especially for the Variant profile. There is no intention to change MolDef to patient specific one, we did not discuss this. Also, the current MolDef IG highlight this point and point to GRIG as the one for reporting patient genomic data and also emphasize the current discussion about how future versions of GRIG may leverage MolDef. We have these as points for discussion at the WGM agenda.

BTW, the discussion about how MolDef can be leveraged by GRIG was as early as the MolDef or even the last update of the late MolSeq. I'm very happy that we reached this point and comments here and during CG call are very informative for current work and future ones.

a good next step would be to explore a toy example that has DiagnosticReport etc that has Variant profile w/o MolDef and one with MolDef and one where there is both the Variant Profile and Moldef. One could trim down the Somatic report and simply work on one or two MOlDef there.

Great point, yes examples and supporting use cases will help claridy this a lot and can guide future updates. I need to highlight that MolDef is not a replacement of Variant profile, it suppose to support it by separating molecular details from observational and clinically relevant info. Therefore, the approach of using MolDef with Observation could be profiling R6 Observation into an updated Variant profile within R6 GRIG. This R6 Variant profile can leverage one or more MolDef instances (and profiles) through value, hasMember, and derivedFrom elements in the context of genomics reporting.

It becomes a functional replacement if the component parts are no longer in the FHIR Observation profile bit instead expected to be found in MolDef. just looking for the complete vision It is clear that moldef can support really explicit description of a genomic sequence, including placement in a reference genome. What's not clear is how moldef is intended to be used with DiagnosticReport. Some comments here are indicating that MolDef would be the vehicle to deliver, for example, sequence data. i.e. the components in Variant would not be necessary or used. If that's the case, let's compare with the current state. It should become obvious where the benefit lies. So far, the same scaling, normalization, and bulkiness issues in Variant Profile will exist with MolDef (if used in the same way as Variant is currently). But, moldef should have some clear benefit given that it has inherited from decades of work with Observation profiles. Fully comparative examples are a good way to start.

What's not clear is how moldef is intended to be used with DiagnosticReport MolDef does not currently have a link to or from DiagnosticReport. Those two resources are only related through Observation (and profiles of Obs). The figure in the MolDef IG should help. Primary benefits of MolDef include semantic precision, normalization, and computability. It was not developed to address issues of "bulkiness" (FHIR is not geared for that). There are a host of examples in the IG , many of which were designed to align directly with the examples in the R4 IG. Take a look at the use cases and let us know if you think we're missing any. Better yet, give a try at mocking it up and tell us where the docs need to be improved.

I am not sure where the miscommunication is. I am talking about example ensembles that include: DiagnosticReport, Observations, etc... does that help?

@Bret Heale - The key thing is that the new profiles of Observation with MolDef are not clearly defined yet, so it will be hard to define a very real example. We could take conversations from IM and WGMs where they have been discussed at a high level and give you something?

This is an image that we have some from WGM notes, which is about the deepest thinking we have put into the Observation profiles utilizing MolDef: image.png

I could mock up some examples for you based on what we think as of now, but to be clear, we don't know the exact details yet. But I hope you can see enough to see the strategic direction anyway.

Give the WG capacity right now, we are honestly struggling just to keep up with the MolDef resource and MolDef IG work. And we are like a year behind on the timelines we proposed in the MolDef PSS. Now some of that is due to trying to match up with the R6 ballot cycle, but the bigger constraining factor is capacity to do the work. (all my opinion btw :slight_smile: )

Certainly needs to be thought through, which is the point. I was trying to be helpful by giving a suggested path: take the current somatic report in the IG and work from there to explore what it could look like. It's just one suggestion, it will give a good view both to compare and eventually to provide guidance.

I'd like to thank Bret to raise this point and his insightful suggestions. Also, I'd like to thank Kevin and Bob F for highlighting the current status and the road mapping issue that we may have. I'll take a note of the WGM discussion on this and post them here later so we may continue this motivating discussion. Thanks all, and I wish you a great weekend

I agree with Aly, it is a good suggestion. Taking the entire GRIG and thinking about it when MolDef + new profiles in the picture above is a important step in the validation. I am just trying to affirm that is the plan and that we are working towards that, just at a much slower pace than any of us want right now.

This is true, but we are working hard too :slight_smile:

I can attest to the fact that @Aly Khalifa is working hard on this :slight_smile:

you too and all of us.

Thanks, Kevin, for jumping in and channeling your inner Bob. We've certainly thought through the high level of how everything could work together (it wouldn't be possible to do any of this without a guiding idea of what it could look like), and the design patterns are pretty straightforward. But as you mention, there is a mountain of work to do and we can only move so fast. Contributions are welcome.

Bob Dolin said : There is some risk that having an R6 MolDef IG out there before we have an R6 Genomic Reporting IG out there will cause implementer confusion. We may want to consider prioritizing an R6 Genomic Reporting IG over an R4 STU4 IG. I do want to come back to these points from Bob Dolin. For the first point, I did move up the section talking about the GRIG on the MolDef IG Index page, but it probably could use some beefing up to a) distinguish the intention of the two IGs and then b) help show the future vision: https://build.fhir.org/ig/HL7/molecular-definition-data-types/index.html#relationship-to-the-genomics-reporting-implementation-guide Regarding prioritizing an R6 based GRIG over another version based on R4, I will admit I wasn't thinking that but I can see the value. What do others think? Are there key things anyone is expecting in another release based on R4? Either way, this sounds like a great WGM roadmaping topic :slight_smile:

Current text: "This Implementation Guide is designed to encapsulate the foundational definitional elements of genomic molecules and concepts—such as sequences and alleles—adopting a patient-agnostic perspective crucial for establishing a standardized genomic FHIR artifiacts. To enable the communication of patient-specific genomic information, stakeholders are advised to refer to the most current iteration of the Genomics Reporting Implementation Guide (GRIG). As of today, this IG and the GRIG are independent of each other. At some future time the Clinical Genomics Working Group may decide to include the discrete data structures defined by this Implementation Guide within the GRIG, by addition to and/or substitution of corresponding structures (e.g., Haplotype profile), which is anticipated to improve the ability to exchange structured genomic data produced by clinical testing. That decision will be subject to open discussion and formal vote(s). Note significant value of this IG is in the loose coupling between the well-defined, discrete data structures and the context in which the data are used, so this IG will add value to genomic data interoperability regardless of the decision(s) or timeline(s) related to its inclusion within the GRIG." Suggested edit: " This Implementation Guide is designed to encapsulate the foundational definitional elements of genomic molecules and concepts—such as sequences and alleles—adopting a patient-agnostic perspective crucial for establishing a standardized genomic FHIR artifacts. To enable the communication of patient-specific genomic information, stakeholders are advised to refer to the most current iteration of the Genomics Reporting Implementation Guide (GRIG). The use of <MolDef> would be for <identify the workflows that you would have the MolDef elements used for - e.g. creation of libraries of commonly seen genetic data>." The second paragraph is difficult to interpret when the first paragraph talks about patient-specific data following the GRIG. Additionally, the figure where a DiagnosticReport is shown adds to the confusion. If the intent is that the descrete communication of genetic variant data currently found in the Variant Profile will be redundant or dispensed with in favor of MolDef artifacts, then make it plain. Otherwise it is confusing that the IG says that one should use the GRIG for patient specific information but then you have a figure with DiganosticReport shown. Maybe reconsider the figure to be included in the second paragraph as a 'possible' future state. Importantly, what workflows should be tested for inclusion of MolDef artifacts? E.g. During a clinical trial, patient data is communicated via the GRIG and then the variation data is cataloged and collated as patient-independent definitional instances of labeled genetic data. This is then used to determine baysian associations of phenotypes with genetic phenomena. This will help people who are attempting to use the MolDef profiles.

Thanks for the review @Bret Heale I copy/pasted the 2nd paragraph and diagram from the MolDef PSS, but honestly did it quickly. I’ll integrate your feedback tomorrow. I will add that there will be some uncertainty when it comes to the GRIG Variant profile. As we have said previously, we are not sure how the Observation profiles that use MolDef will look. And honestly we will have to consider current implementers of the GRIG that have already built around Variant.

OK, I made some changes, hopefully it is better now: https://build.fhir.org/ig/HL7/molecular-definition-data-types/index.html#the-future-with-the-genomics-reporting-implementation-guide

Thanks Kevin and Bret for the updated text I like this direction. I'm at the WGM and digging in this week, looking forward to the discussion

I just ran the guidance through Copilot and asked it to review and provide some suggestions. I have pushed those changes, and a few other manual tweaks I made as well.

I think it would help to add the phrase 'for now' in the paragraph that mentions the GRIG. Also, are there specific workflows (such as collation and cataloging ) where the MolecularDefintiion can be used for testing? It is not clear what scenarios (workflows) the MolecularDefinition is meant to support. Thinking through using the proposed future state

Thinking through the proposed future state: Looking at example-variation-cyp2c19-1015-spdi - JSON Representation - Molecular Definition Implementation Guide for Molecular Data Types v1.0.0-ballot1, What will a repo of patient data now look like? Sets of Observations referencing a pool of MolecularDefinitions - a vast multitude of MolecularDefinition that will be maintained with their linking Observation to a Patient (this is similar but better then solely having Observations with ClinVar ids, or specific LOINC code, instead of HGVS for identification of what a patient has directly). The architecture for retrieval should be explored and discussed. I am happy to discuss and think through with others here (or in a specific Zulip chat) the architectural guidance of using MolDef, at least as a starting point for connectathon exploration. It requires a workflow however (reporting of Somatic Variation, for example, with an extension into data analysis across patients). Places like the location for the MolDef instances are particularly interesting aspect, as this could be emr resident, lab resident, or something outside of both (such as a sponsored MolDef library). An important aspect will be the flow when a Novel Observation is made.

Bret Heale said : I think it would help to add the phrase 'for now' in the paragraph that mentions the GRIG. Also, are there specific workflows (such as collation and cataloging ) where the MolecularDefintiion can be used for testing? It is not clear what scenarios (workflows) the MolecularDefinition is meant to support. Thinking through using the proposed future state With your 'for now' comment, do you mean: All of the profiles defined here will be patient-agnostic, so if your use case calls for reporting patient specific results, we would recommend utilizing the GRIG *for now*. ?

Bret Heale said : What will a repo of patient data now look like? Sets of Observations referencing a pool of MolecularDefinitions - a vast multitude of MolecularDefinition that will be maintained with their linking Observation to a Patient (this is similar but better then solely having Observations with ClinVar ids, or specific LOINC code, instead of HGVS for identification of what a patient has directly). The architecture for retrieval should be explored and discussed. This will be important to think through. We have compared this to other definitional resources, so does anyone have insights into how other definitional resources are handled?

I guess overall, I'm wondering if we really want to delve too much into the 'future state' in the MolDef IG, since it seems to presuppose some design decisions that would be made as part of a FHIR R6 GRIG IG. For instance, will we develop an 'Observed Sequence' profile? Will 'Observed Variation' profile include an ACMG classification, or is that conveyed via an implication?

I think it's fine to draft that discussion in the MolDef IG for now since there is no R6 GRIG to put it in

I think it is worth calling out in the first release of the MolDef IG that we understand there needs to be a unification, but admitting we don't know all the details yet. I hoped the changes I made walked that line? If anyone has other suggestions, please drop them here, or propose the change yourself :slight_smile:

Thanks for the updates, Kevin. The paragraph reads well IMO.

I made a couple of minor tweaks just now, and flagged the diagram with a Note To Balloters. Again, welcome any additional feedback to improve it.

make a note to balloters on the landing page that says experimental and conveys the status on a potential timeline of implementation. Also, the IG should be balloted in the first draft as a 'for comment' ballot, given the maturity of the work. FHIR level zero for the IG will help convey the current state as well. what are your thoughts on when you would like to do a 'for comment' ballot? given the current implementations of the GRIG, it would be wise to carefully work through the workflows, rather than rush.

So, I wasn't sure about 'for comment' so I decided to ask the new HL7 'Navigator' what the options are and the recommendation (TLDR; 'for comment' probably does make sense - so I learned something new today :slight_smile: ): My Question: For the first ballot of a new product, what are the options? Should we do a 'comment only' ballot? What are the considerations? Navigator Answer: When considering the first ballot for a new HL7 product, you have several options, each serving different purposes in the development process. According to the HL7 Balloting documentation, here are the key ballot types you might consider: Ballot Types For Comment Ballots: These are used early in the development cycle to gather feedback from the community. They are not intended to result in the publication of a specification but rather to guide the development work by providing insights and direction. There is no "pass" or "fail" outcome, making them ideal for initial feedback without the pressure of reaching consensus. Informative Ballots: Used for content that provides guidance or recommendations but is not binding on implementers. These ballots are suitable if the goal is to share preliminary findings or guidance without enforcing implementation. Standard for Trial Use (STU) Ballots: Intended for content that is ready to be implemented but has not yet been widely tested in real-world scenarios. These ballots allow for time-limited testing and feedback before finalizing the standard. Normative Ballots: Used for final review of specifications intended to be binding on implementers. They require the highest level of consensus and scrutiny, making them unsuitable for initial balloting. Considerations for Choosing a Ballot Type Stage of Development: If the product is in the early stages, a 'For Comment' ballot is appropriate to gather broad feedback without the need for consensus. Intended Use of Feedback: Determine whether the feedback will guide development (For Comment), provide non-binding guidance (Informative), or test implementation readiness (STU). Community Engagement: Early ballots like 'For Comment' can engage the community and gather diverse input, which is crucial for refining the product. Publication Goals: If the immediate goal is not publication but rather feedback and iteration, 'For Comment' is the best choice. In summary, for the first ballot of a new product, a 'For Comment' ballot is often recommended to solicit initial feedback and guide the development process without the pressure of reaching consensus or finalizing the standard.

Bret Heale said : make a note to balloters on the landing page that says experimental and conveys the status on a potential timeline of implementation. Also, the IG should be balloted in the first draft as a 'for comment' ballot, given the maturity of the work. FHIR level zero for the IG will help convey the current state as well. I added a note to the pages.

Kevin Power said : So, I wasn't sure about 'for comment' so I decided to ask the new HL7 'Navigator' what the options are and the recommendation (TLDR; 'for comment' probably does make sense - so I learned something new today :) ): I would advocate for informative, as that also meets the def, but I think it's clear that it's not STU and that's probably the important distinction.

From conversing with the HL7 AI Navigator, I would lean towards 'for comment' : QUESTION: For the first ballot of an implementation guide, help me choose between 'for comment' and 'informative' ballot types. Sent at 2025-09-17T14:59:52 When deciding between a "For Comment" and an "Informative" ballot type for the first ballot of an implementation guide, it's important to understand the purpose and implications of each type. Ballot Types Overview https://navigator.hl7.org/#ballot-types-overview For Comment (O): This type of ballot is used to gather feedback and input from the community on a draft document. It is not intended to approve the document for publication but rather to collect comments and suggestions that can be used to improve the document. This is typically the first step in the balloting process if you want to refine the content before seeking more formal approval. Informative (I): An informative ballot is used for documents that are intended to provide guidance, information, or recommendations but are not intended to be normative or enforceable. An informative ballot allows the document to be published as an HL7 Informative Document after the balloting process. Choosing the Appropriate Ballot Type https://navigator.hl7.org/#choosing-the-appropriate-ballot-type Select "For Comment" if: You are seeking broad feedback on the draft implementation guide. You want to engage the community early in the development process to identify areas for improvement. The implementation guide is not yet ready for publication as an HL7 Informative Document. Select "Informative" if: The implementation guide is intended to provide guidance or information without being enforceable. The document is mature enough to be published with the understanding that it is not a normative standard. You are ready to publish the guide as an Informative Document after addressing any comments received during the ballot. For more detailed information on ballot types and processes, you can refer to the Frequently Asked Questions (FAQs) . This document provides insights into the different ballot types and their purposes within HL7's standards development process. Sent at 2025-09-17T15:00:18 Type your question about HL7 documentation, processes, or governance and press Enter to send QUESTION: Does the Informative ballot type apply to implementation guides that will eventually move to STU and Normative? When considering whether the Informative ballot type applies to implementation guides that will eventually move to Standards for Trial Use (STU) and Normative, it's important to understand the role of each ballot type in the HL7 standards development process. Informative Ballot Type https://navigator.hl7.org/#informative-ballot-type Purpose : The Informative ballot type is used for documents intended to provide guidance, recommendations, or information that does not establish requirements. These documents are not meant to become standards themselves. Application : Informative ballots are typically used for documents that provide background information, educational content, or guidance that supports other standards but are not themselves on a path to becoming normative standards. Transition to STU and Normative https://navigator.hl7.org/#transition-to-stu-and-normative STU (Standards for Trial Use) : This stage is used for standards that are ready for trial implementation but may still require feedback and refinement. A document that is intended to become an STU would usually start with a "For Comment" ballot to gather feedback on the draft standard. Normative : This is the final stage where a standard is considered stable and is intended to be widely adopted. Normative ballots are used to formalize a standard that has undergone sufficient testing and feedback. Given these definitions: Informative Ballots are generally not used for documents that are intended to become STU or Normative standards. Instead, they serve a different purpose by providing information without establishing binding requirements. If your implementation guide is intended to eventually move to STU and Normative, starting with a "For Comment" ballot is more appropriate. This approach allows for the collection of feedback and refinement needed before proceeding to the STU stage. For more detailed information on these processes, you can refer to the HL7 Governance and Operations Manual (GOM) , which provides comprehensive guidelines on HL7's balloting procedures and document types.

Interesting. Thanks for the synthesis. Sounds like for comment is indeed the better choice given the intended path of progression.

Hi All, As was highlighted during yesterday CG call, we will not have an IM call tomorrow. Looking forward for more discussion during the next call. Thanks

The IM group will meet tomorrow (Oct 16). I would like to spend the time on a bit of a diversion: discussing an interesting use case from GA4GH GKS related to the representation of "imaginary" locations (e.g., intronic variant on a transcript). I'll walk through some thoughts and I'd like feedback. This could potentially impact how we model haplotype and genotype, because the location structure might be reused and constrained. As per the priorities set at the WGM, we are focusing on the MolDef IG (please review and comment), then will introduce haplotype and genotype profiles (already drafted). We will then work on MolDef relationships, which will require us to model a more generic "assertion" structure. Bring :coffee: . Or :tea: . Or both.

Did anyone suggest that for things like introns that you are making a good case to dispense with location altogether, in favor of sequence holomology and realtionships to named reference sequences? Chromosome 1 is the name we've given to a structure that contains probable matching to a stretch of sequence data that has been put together as a 'reference' for example. You might talk about where an intron matches this CHromosome 1 but separately the intron sequence that's observed in an instance exists. You also have the conceptual pattern that one asserts has homology to the intron and where that homology pattern has homolgy to the so-called Chromosome 1. Couldn't make it Thursday but these are somethings to think about. You do not have location without an assertion that there is homology of some sequence to some reference sequence. Homology abd probabilitic alignment are what is currently not in the model.

It sounds like you should be joining these discussions. I think there are at least 3 types of things we are representing: a given location on a given sequence an assertion that a given location on a given sequence is homologous to (under some definition) another given location on another given sequence a conceptual feature that may be represented by an exemplar defined as a given location on a given sequence We have a good model for the first. We are working on the second. The third will be addressed in the near future, when we get to the Feature model.

I am not sure that introns are valuable to fully describe with FHIR. A knowledge base such as ClinVar, the USCS Genome Browser etc are able to richly describe the state of knowledge around a sequence. To keep FHIR light, sending a link to the appropriate knowledge base seems adequate. Beyond that, in the STU3 Genomic Reporting spec you have a place for interpretation where Sequence Ontology codes can be used to indicate the 'annotation' that a specific sequence observation is linked to an intron or splice site change. Going back to modeling introns - you're talking about splice-sites and branchpoint etc. These are often interpreted from sequence homology to motiffs there is a percentage likelihood to matching the motiff model. I am not sure there is a use case in FHIR to encode that much detail. A genomics lab has some sequence that they have found or observed. Or they have a biomarker that they wish to report. It is useful to have something like SPDI when possible to relate results and describe a picture of a patient's genome for things like CDS, reinterpretation, population decisions, but describing a sequence as an intron is something that can be interpreted through invoking a reference to a knoweldge base - it is a runtime operation. Before diving into a model for intron (and remember it might be worth looking at different species lineages to see how common a model might be), I ask what the use case is to have a FHIR definitional encoding of an intron? Is it not sufficient to have the sequence described, or a reference to a knowledge base? Currently for reporting, if one wants to mention an annotation that an intron is involved there is an ability to provide a knowledge base reference (and opportunity to add a text summary) and sequence ontology terms. Why do we need a FHIR definitional representation of an intron?

FWIW, the IPD-IMGT/HLA database, which is the reference database for HLA nomenclature, includes exon, intron, and utr sequences. E.g., HLA-A*01:01:01:01 For HLA, there are cases where intron sequences can affect protein expression.

Yep. Those are sequences. Calling them introns is a interpretation of the context in which they are found. The observation that they are found in a sample can be annotated with the current Observation based variant reporting. The question is not representing the annotation of an intron as part of an Observation as reported in a Genomic report but, I ask what the use case is to have a FHIR definitional encoding of an intron? Is it not sufficient to have the sequence described, or a reference to a knowledge base? Currently for reporting, if one wants to mention an annotation that an intron is involved there is an ability to provide a knowledge base reference (and opportunity to add a text summary) and sequence ontology terms. Why do we need a FHIR definitional representation of an intron? What is a use case for that? (GenomicStudy?)

I may have missed some of the discussion around definitional encoding of introns. For the histoimmunogenetics use case described in the GRIG, there has been an interest in defining a mechanism to transmit the (observational sequence) "primary" data pertaining to a (nomenclature-level) HLA allele assignment. The Histocompatibility Reporting section of GRIG STU3 defines FHIR mechanisms to represent sequence data transmitted via an earlier XML-based standard called HML , which aims to implement MIRING principles ... but that's largely concerned with observational sequence data, not definitional sequence data.

Exactly, there are many databases of definitional data. They are accessible through links. The Observational data in FHIR can be labeled if one wants to mention an annotation that an intron is involved there is an ability to provide a knowledge base reference (and opportunity to add a text summary) and sequence ontology terms. Why do we need a FHIR definitional representation of an intron? What is a use case for that? Perhaps for GenomicStudy?

Coming late to the discussion. "Intron" is an example of a sequence annotation (a feature) that may be highly contextualized. Therefore, that information must be separated from the underlying primary sequence. In MolDef, we would model an intron as an annotated feature (typed with a code, defined by attributes) that is associated with a given location (coordinates) on a given contextual sequence (e.g., reference chromosome).

? what do you mean separating the intron from the primary sequence? Are you wanting then to describe a set of sequences - i.e. a pattern with probabilistic alignment - for the specific intron? You can't have a meaningful definition for a specific intron without sequence information. Saying Intron 12 of gene X is only relevant to a specific POTENTIAL transcript of gene X (the number 12 indicates an ordinal position). To do anything with this information one would need coordinates at the very least on a reference Sequence - or positional information that relates to matching a sequence motiff.

Intron 12 of Gene X from transcript Y, is just a meaningless label for a sequence believed to have homology to a sequences that have a high degree of homology to a defined set of references. The definition is in the sequence homology, including branch-point and splice sites ---- but again is this exploration of defining an intron for use in defining regions of study in with GenomicStudy?

With AMIA starting over the weekend, I have not had time to prep for the IM call tomorrow (Nov 13) so I canceled to give the time back. Apologies for the short notice. Best of intentions.

@Bret Heale I agree with you: making use of the concept requires sequence context. Yet we use many conceptual features without that context. Gene X. HLA-B exon 2. You are exactly correct that these concepts represent a motif that might share homology across several sequences. Some might be more precisely defined (e.g., non-degenerate restriction site) than others (e.g., Gene X).

@Bob Freimuth I thought the goal was to have a definition of something like HLA-B exon 2 that was interoperable, or at least where one could be explicit about what HLA-B exon 2 is (e.g. it is a Human sequence with similarity to such and such sequence, found in transcripts like such and such sequence...). Saying HLA-B exon 2 does not mean much computably or interoperably. There is a lot of interpretation needed to know what the concept is. Maybe HLA-B exon 2 is too a vague a concept without some sequence relationship? Same for a concept like Gene X (especially given that there are numerous was to label a gene in Humans).

Is this exploration of defining an intron, or exon, for use in defining regions of study in with GenomicStudy?

I think clinical usage of HLA data doesn't really follow the same patterns as other genomics data. Clinical usage of HLA data tends to operate at the level of HLA ("allele") nomenclature, and research literature involving HLA also tends to operate at this level. For example, HLA-B&#42;57:01 is a protein-level HLA concept with clinical implications. It encompasses multiple synonymous sets ("haplotypes", in GRIG parlance) of nucleotide sequences across HLA-B exons 2 and 3. For discussion purposes, it may sometimes be useful to use the word "phenotype" when referring to a protein-level HLA concept such as HLA-B&#42;57:01 ... So, digging deep into the HLA story has the potential to become more distracting than helpful with regard to other use cases.

I would disagree. I think HLA is a great example of the need to use motifs and probability scores against a set of sequences in the definitions. The alleles all have a nucleotide pattern or nucleotide based location implied. Also, the protein sequences as well. There are at least reference sequences implied by these concepts. For one to know that HLA-B exons 2 or 3 is being discussed one needs to have knowledge of sequence homology at the very least. What method for detection of variation or description of HLA type does not require a sequence? HLA is a good example where the definition uses a set of sequences that define a motif, pattern, as well as intended position within a reference. So in a sense it is not one sequence that would be expected to be seen in the definition but a set, as well as a positional definition. But going back, is the exploration of defining an intron, or exon, for use in defining regions of study in GenomicStudy?

The usage of HLA data has a decades-long history, with a variety of typing methods being used over the years, including serology, sequence-specific oligonucleotide (SSO) probes, sequence-specific primers (SSP), Sanger sequencing (SBT), and next-generation sequencing (NGS). Most of the current work is being done using NGS methods. The HLA nomenclature can be used as a reference that makes it possible to compare results obtained via different methods. Data obtained by older methods tends to be ambiguous, leading to the use of probabilistic methods for its analysis. However, such ambiguity is not acceptable in a clinical setting, so, for example, confirmatory HLA typing is done as part of the process of selecting a donor for hematopoietic stem cell transplantation (HSCT). I'm not a HLA transplant clinician, but I don't think they are interested in sequence motifs and probability scores. The sequence details could be viewed as "primary data", but for purposes of HLA tissue typing the transplant clinician is mainly interested in the concepts of "match" and "mismatch" (resolved to a clinically acceptable level of certainty).

Other potentially distracting elements of the HLA story might include comparisons based on the antigen recognition domain (ARD) of HLA genes and the use of specialized amplicons for NGS sequencing.

We can talk about HLA and sequence data and where the sequence data makes the most sense. But for me the important question is this: Is the exploration of defining an intron, or exon, for use in defining regions of study in GenomicStudy?

@Bret Heale I am not trying to be evasive, but want to clarify that how the concept of an "exon" might be used (e.g., GenomicStudy) is (or should be) independent of its definition. Annotated regions of sequence that could be used in many different ways, including (but not limited to) defining a region of study.

I'll try to clarify. How it is to be used tells us what it is. A specific Intron has a base sequence at the core of its definition (Intron 12 of Gene X from transcript Y, is just a meaningless label for a sequence believed to have homology to a sequences that have a high degree of homology to a defined set of references. The definition is in the sequence homology, including branch-point and splice sites. And then the inference that the sequence results from splicing from a specific Genomic Region). Examples of where it is going to be used will inform us as to what data elements would come into play. Why do we need a FHIR definitional representation of an intron? What is a use case for that? is this exploration of defining an intron for use in defining regions of study in with GenomicStudy, for example?

I'm starting to wonder if we should have a channel for genomics/IM so we can move focused discussions into threads. Until then, I'll just keep rambling. I agree that "Intron 12 of Gene X" is relatively meaningless for many purposes, but it does represent a type of concept that is frequently used in clinical genomics. I do not think FHIR needs to create a model to define a given intron and all of its associated knowledge, but it is important for us to have a way to represent an annotated region of sequence in FHIR. From a very simple POV, the type of information we might need to capture are things like: contextualized location (seq + location), label ("intron 12"), type (code for "intron"), identifier (in a knowledge base), maybe things like related gene. It's a pretty simple model, but it provides a computable way to reference a given sequence feature as a concept, which may in turn be mapped to homologous regions in multiple contextual seqs.

Just as a reminder, there will be No Information Modelling Call for today as we usually do the week after WGMs. Please review the meeting minutes and the MolDef IG for feedback and recommendations. Last WGM minutes: https://confluence.hl7.org/spaces/CGW/pages/413241772/2026-01+CG+WGM+Agenda+Minutes+-+Virtual MolDef IG: https://build.fhir.org/ig/HL7/molecular-definition-data-types/

A specific Intron has a base sequence at the core of its definition (Intron 12 of Gene X from transcript Y, is just a meaningless label for a sequence believed to have homology to a sequences that have a high degree of homology to a defined set of references. The definition is in the sequence homology, including branch-point and splice sites. And then the inference that the sequence results from splicing from a specific Genomic Region). An intron is more that seq+location <-- what's the location of an excised piece of DNA? you really mean a location in a reference where the intron sequence could have been derived from. The intron could be in a pre-spliced RNA molecule or are you considering the DNA stretch that derives the intronic sequence? But it is important to keep in mind that this is all relative to a reference sequence (or maps of sequences). From your comment on annotated sequence region in FHIR - you appear to be focused on a DNA construct with some sequence information, as in a Reference. Examples of where intron is going to be used will inform us as to what data elements would come into play. These are questions to consider to help the discussion: Why do we need a FHIR definitional representation of an intron? What is a use case for that? is this exploration of defining an intron for use in defining regions of study in with GenomicStudy, for example? maybe the answers will better inform the model

Thanks Bret for raising these points. I hope you can join this Thursday IM call and we may discuss this more with the group.

Bret Heale said : A specific Intron has a base sequence at the core of its definition (Intron 12 of Gene X from transcript Y, is just a meaningless label for a sequence believed to have homology to a sequences that have a high degree of homology to a defined set of references. <snip> Perhaps I am missing something here, but I don't get the sense we are defining a model specific for an intron, but are ensuring our model allows the annotating (labeling?) of a region that is being described. If the annotation/label/name of the Intron is something our community is sending in some use cases, why would we not want the ability to send that annotation/label/name as we describe the sequence?

Nope, I thought it was about what is important in the concept to convey. You see, HLA-B exon 2 intron by itself is just a label - not a computable definition of HLA-B exon 2. I thought the goal was computable definitions? But the question that I am asked was "Is this exploration of defining an intron, or exon, for use in defining regions of study in with GenomicStudy?" Introns have components like branchpoints and splice sites that one would expect to see in a definition of an Intron, but those do not have meaning except with relation to some sequence that could be a descriptor of a pattern of sequences that share homology. This is not about hey I want to put a label on something, but I want to define something. My question is about why. Where would it be used as a definitional object? To me it makes the most sense in GenomicStudy under a declaration of what the GenomicStudy was or can look for. In the result of the GenomicStudy the R4 current paradigm would use Observation Variant Profile with various components and MolecularConsequence if relevant. If you are simply looking to label a sequence with some random string that happens to have 'i-n' followed by 't-r-o-n' go right ahead. But if you want computable meaning for that string then you need to do more than apply a label.

I've built plenty of implementations where we all we could do was label. We used terminology as best as we could to provide some hint as to the definition of the label (e.g. Sequence Ontology). Having a computable meaning is important for discoverability, retrievability, analysis and computer decision making (even an LLM builds an occurrence based model of the meaning of things). Please don't only use a string if the element is meant to be calculated with and explicitly understood.

From what I know, there is no question that the primary focus needs to be on the computable definition. But if a use case calls for it, some sort of annotation / label can be applied so us silly humans who sometimes like easy to read things can also understand the data?

You are describing the purpose of the narrative section of a Resource. And there are lots of places where 'display' is indicated, but always accompanied by the opportunity to provide terminology or more detail. There are additional places where 'description' is intended to be placed where human readable text goes without any computable expectation. I've built plenty of implementations where we all we could do was label. We used terminology as best as we could to provide some hint as to the definition of the label (e.g. Sequence Ontology). Having a computable meaning is important for discoverability, retrievability, analysis and computer decision making (even an LLM builds an occurrence based model of the meaning of things - they appreciate as much context as possible). Please don't only use a string if the element is meant to be calculated with and explicitly understood. My comments/questions are on the thread. If you'll look earlier you will also see Bob F talking about much more than a string. Given that he was talking about it in the context of a definition. I really want to: Where would it be used as a definitional object? To me it makes the most sense in GenomicStudy under a declaration of what the GenomicStudy was or can look for. If you're giving a human-readable 'Description' that is attached to something that is definitional - what should be relied upon by AI - since it bridges both computable and 'human-readable?' Is it safe to let the AI use the description instead of the computable fields?

Sounds like the IM group needs to decide if annotation is a first class computable data object or just a convenient label. Or both. In the past the CG WG went with something computable and has provided a way to bring annotations to a finding, including evidence for the annotation.

I'm very sorry for the late notice, but I need to cancel the IM call tomorrow. I just had a meeting come through that I cannot miss.

I'll be at the eMERGE meeting on Thursday, so no IM call this week