ARCHIVED - 2023/2024 minutes can be found here

GA4GH Clinical & Phenotypic Data Capture & Exchange Work Stream
Minutes and Actions 2021-2022

These are the minutes for the GA4GH Clinical & Phenotypic Data Capture Work Stream. For further information, please visit the GA4GH Work Stream page at www.ga4gh.org, or contact the Work Stream Manager.

• Clin/Pheno Landing Page
• Phenopackets Subgroup - Agenda & Minutes (ARCHIVED)
• Phenopackets Cancer Task Team Notes
• Cohort Representation Minutes
• GA4GH 2020 Overall Strategic Roadmap
• Clin/Pheno 2020 Strategic Roadmap
• 2019-2020 Meeting Minutes
• 2017-2018 Meeting Minutes
• Recordings

GA4GH Slack Workspace

• Clin/Pheno channels: #clin-pheno_ws, #cp-phenopackets, #cp-pedigree, #cp-cohort_rep

Table of Contents:

Meeting Protocols

List of Meetings

2022-12-07 - Clin/Pheno Year End Roundtable

2022-11-22 - Beacon v2 and Phenopackets v2 Integration

2022-11-21 - Pedigree Subgroup

2022-11-03 - Pedigree Subgroup

2022-10-20 - Pedigree Subgroup

2022-08-23 - Computable Cohort Representation - Summary Statistics

2022-08-11: Pedigree Subgroup

2022-08-04: Pedigree Subgroup

2022-06-23: Pedigree Subgroup

2022-06-09: Pedigree Subgroup

2022-05-26: Pedigree Subgroup

2022-05-25: Clin/Pheno Full WS

2022-05-xx - Computable Cohort Representation Hackathon

2022-04-28: Pedigree Subgroup

2022-04-20 - GA4GH Montreal Connect

2022-03-24 - Computable Cohort Representation Meeting

2022-03-23: Clin/Pheno Full WS

2022-03-17: Pedigree Subgroup

2022-03-15 - Computable Cohort Representation Meeting

2022-03-03: Pedigree Subgroup

2022-02-23: Clin/Pheno Full WS

2022-02-17: Pedigree Subgroup

2022-02-03: Pedigree Subgroup

2022-01-20: Pedigree Subgroup

2021-12-14 - Cohort Rep Report Back Meeting

2021-12-09: Pedigree Subgroup

2021-12-02: Computable Cohort Representation - PHENO Team

2021-12-02: Computable Cohort Representation - MIACC Team

2021-11-11: Pedigree Subgroup

2021-11-02: Computable Cohort Representation - PHENO Team

2021-10-28: Pedigree Subgroup

2021-10-19: Computable Cohort Representation

2021-10-12: GA4GH Connect

2021-10-05: Computable Cohort Representation

2021-09-30: Pedigree Subgroup

2021-09-21: Computable Cohort Representation

2021-09-16: Pedigree Subgroup

2021-08-19: Pedigree Subgroup

2021-08-05: Pedigree Subgroup

2021-07-28: Clin/Pheno Full WS

2021-07-27: Computable Cohort Representation

2021-07-22: Pedigree Subgroup

2021-07-13: Computable Cohort Representation

2021-07-08: Pedigree Subgroup

2021-06-29: Computable Cohort Representation

2021-06-15: Computable Cohort Representation

2021-06-10: Pedigree Subgroup

2021-05-27: Pedigree Subgroup

2021-05-26: Full Clin/Pheno WS

2021-05-13: Pedigree Subgroup

2021-05-13: Computable Cohort Representation

2021-04-29: Pedigree Subgroup

2021-04-22: Phenopackets Subgroup

2021-04-15: Pedigree Subgroup

2021-04-08: Phenopackets Subgroup

2021-04-01: Pedigree Connectathon

2021-03-25: Phenopackets Subgroup

2021-03-24: Clin/Pheno Full

2021-03-18: Pedigree Subgroup

2021-03-11: Phenopackets Subgroup

2021-03-01: Virtual GA4GH Connect 2021

2021-02-25: Phenopackets Subgroup

2021-02-18: Pedigree Connectathon

2021-02-11: Phenopackets Subgroup

2021-02-04: Pedigree Subgroup

2021-01-28: Phenopackets Subgroup

2021-01-21: Pedigree Subgroup

Meeting Protocols

• Please note that by participating in meetings, attendees agree to adhere to the GA4GH Standards for Professional Conduct.
• Meetings may be recorded for note-taking purposes. Recordings will be deleted within three months of the meeting taking place.

List of Meetings

2022-12-07 - Clin/Pheno Year End Roundtable

Chair: Melanie Courtot, David Hansen

Attendees “Name (Project Affiliation)”:  Moni Munoz-Torres, Oscar Pastor, Marion Shadbolt, Ian Green, Grant Wood, Joe Cody, Chen Chen, Vanessa Vogel-Farley, Kathy Reinold, Soichi Ogishima, Jeffery Shu, Victor Lin, Francis Jeanson, Aarthi Krishnan, Coline Thomas, Nebiyou petros, Jules Jacobsen, Zornitza Stark, Nicky Mulder, Ayhan Serkan SIK, Orion Buske, Adriana Malheiro, Mogomotsi Matshaba

Minutes:

A transcript has been captured using Otter.Ai.

Phenopackets Update:

MMT: We've created a standard within the GA4GH and this is a standard that literally allows you to pick up a packet of genotype data that can be used anywhere by anyone. And these packets are encoded using ontologies and can be used to develop a patient’s phenotypic profile or one for model organisms. And it helps to improve diagnostics mechanism discovery and an integration with the environmental health data. Phenopackets allow us to exchange information about the patient, including him about identifiers, information about age of collection, as well as details about each of the absurd phenotypes. And this includes whether or not the phenotype was observed when they were first observed, how they were first observed in how severe a phenotype is, and how each of the phenotypes is linked to a patient through their genomic information through the samples that were collected in when available even to the patient's parents and siblings. And so in the latest version of the standard, the latest updates include improvements for the representation of cancer in COVID-19 phenotypes. Phenopackets are going to benefit research biologists, physicians and patients alike and they can support a diverse diversity of use and use cases listed on the left in the context of biomedical ecosystem, right. So there are multiple providers of phenotypic data. This includes you as a patient you as a clinician, as well as a data that comes through a variety of mechanisms that include mobile health gadgets in the electronic health record, and the Phenopckets schema acts as a common model that can capture data from all of these different sources with a unified software representation. And in turn, it can be used by multiple receivers of the phenotypic information. And this includes journals, databases, registries, clinical laboratories, we're hoping that its implementation can help us to speed up the accuracy of the diagnosis, as well as the treatment effectiveness, and that it can facilitate cohort identification and patient matchmaking during the clinical trials, and just in general, improve the data landscape and facilitate the creation of all these tools and algorithms but as they find their way into databases in website and web based tools.

There's a lot of really good exciting things that have happened over the past few months. We have now a standard that it's both approved with the GA4GH as well as with the International Standards Organization. And there have been a few joint news releases with the standard Council of Canada that issued this celebration of being able to bring the first of the standards from our group. We have a paper that was published in June. Not quite the fall but we're still very excited about it. And the paper we just published in August, which is a practical introduction, basically a tutorial. We have work pending, we're working with generating a set of a validating tools, just working on an adjacent a validation tool that would allow you to basically recognize whether or not you have the correct information in the phenopacket as well as trying to do generate tools for a building where we have a new website that is not yet deployed but will be able for you to be able to transform your information into a phenopacket. And there's also of course, exciting work happening cross workstream with our partners in genomic knowledge standards as well as the ability to support the second version of Beacon so that we can accept queries with phenopackets and return a list of phenopackets as well. Of course, we're working with the rest of the Clin/pheno workstream to support pedigree.We basically started building an OMOP  phenopacket exporter. This runs as a web server on top of  OMOP and exports data into a phenopacket format for an individual. They started as a biohackathon work last year. We are also working with the HL seven organization. They work on interoperability for electronic health records and Phenopackets is one of the very select group of Vulcan accelerator projects, which are projects to foster growth and in the application of research standards.

Computation cohort still study group status. Spent lots of time exploring and defining queries for cohorts and phenotype for individuals in cohorts. 5 different breakouts during hackathon, eg Beacon, data access requests, FIHR & HL7…Overlap with other GA4GH groups - eg DURI group looking at standardizing Data Access Requests. Overlap with Beacon and PXF.

Hard to focus on one direction - too many interesting ideas!

Pedigree

LS: Working on resolving the last remaining comments for PRC approval, aiming for SC approval in January. In the agenda, you'll see I've linked the GitHub space in the documentation, and those two links will take you to everything you need to know about the pedigree standard. Through the PRC process, there has been quite a bit of changes. So if you haven't looked at the documentation in a while, I'd really recommend you take a look. One of the other big updates I'd like to share as we're working on, hopefully migrating our kin ontology to the OBO relations ontology.

Rare-X

VF: Starting coming into this space an build on what was out there. We are a little bit different in that we are patient-driven, spin out from Global Genes. We have a platform for collection patient and health centered data. We guide with advocacy partners and share equity across all diseases. Create collaborations with researchers and biopharma studies in the rare disease space.

There is so much overlap in disease, but we also see domain specific areas. Wanted to bring something together that can show cross domain findings. This overlap drives the use of standards and working with GA4GH. We want to approach infrastructure in a way that is patient-centric. The patient is reading a question that makes sense to them, but coded in a way that is structured and machine readable. Focus in on an integrated or federated data model, connect where it makes sense and not where it doesn’t. Everyone comes in the same door with data collection. We have a layered model that can be continually built upon. Mapping domains back to the standards to make them usable and identifiable. Make sure to do the landscape work and bring experts together.

Case study with Colorado Children’s genetics. Clinician reported data collected in REDCap.

Industry partnerships with Illumina, and Q-state biosciences.

Australia BioCommons

MS: We don’t have a national solution for data sharing and archiving. We needed something to bring everyone together to be able to query across them. Looked at Beacon, having systems where each institute can transform their data into the common Beacon model, and bring everything together in a Beacon network. Want to make this process as easy as possible. Within the Beacon network, looking at developing a better UI. Have developed a serverless Beacon (sBeacon). We have no active backend running 24/7, it’s also auto scaled. No data transformation needed, uses VCF as is. Still moving parts.

Improving language in the KIN Ontology

JC: Collecting family history that is accurate is essential. Knowing whether it’s donor, sperm, eggs, can change care. Want to change family history capture process through point of care or imputation. Want to work with stakeholders and promote conversations between patients and clinicians. Some of the comments we submitted had to do with the IVF example that was in the Pedigree documentation. Recommended changing that category to accommodate other forms of assistive technology. We had recommended some basic terminology to add to the ontology.

OB: We have some representation of this in the owl file.

VVF: How to describe self-reported things to be patient centric.

2022-11-22 - Beacon v2 and Phenopackets v2 Integration

The minutes/agenda for the Phenopackets / Beacon Integration meeting can be found here.

2022-11-21 - Pedigree Subgroup

Chair: Orion Buske, Grant Wood

Attendees “Name (Project Affiliation)”: Alex Tsai (GA4GH)

Minutes:

Walk through of actions and remaining to-dos.

Timelines: Send documentation to PRC either Dec.1st or Dec. 5th. Ask for thumbs-up before the holidays.

Documentation to SC by Jan. 12th.

Consider “implementathon” for post-approval - bringing together implementers to Connect

2022-11-03 - Pedigree Subgroup

Chair: Orion Buske, Grant Wood

Attendees “Name (Project Affiliation)”: Meen Chul Kim (CHOP/KF), Zornita Stark (AGHA), Arthur Hermann (Kaiser)

Minutes:

Worked through the PRC comment tracker and updated text and color-coding as appropriate. Main outstanding items are KIN Ontology Fixes, FHIR IG Updates to reflect a few changes to the model, and Phenopackets integration text. Next meeting will be a quick check-in scheduled for Monday Nov. 21st @ 4:30pm ET / 9:30pm GMT / 8:30am AEDT.

Link to class diagram: https://drive.google.com/file/d/15zESxFd6z17iKB2e68sRYbX1iDreWjTn/view?usp=sharing

XML export is on the Slack channel.

NOTE: The below transcript was auto-generated.

GA4GH Connect is coming up in just over a week from now.

There is as of right now. Put potentially one meeting coming from Clin/Pheno on related to Beacon and Phenopckets integration which couldn't be somewhat related to us if you know we get the the pedigree integration with Phenopckets going as well. Timing of that hasn't been scheduled, but I'll let you know when it has been.

And there's a couple of other sessions that might be of interest. Now. There's one on data access. There will be a data model and schema consensus group meeting on November 30 A little later this month was the other one.

It's not coming to me right now, but there's a couple of different vegan meetings and such as well.

And then other note, and I've linked this in the agenda as well. The variant summary statistics format is now open for comment. You can find that right on the GA4GH dot org main page. And so essentially this is a format for GWAS summary statistics originally developed outside of GA4GH, the version one and now they're they're hoping to bring it in and develop it further.

Are their own work stream or is that another work stream that has done that? No. So this is a new standard that's going to be put through in LSG large scale genomics, but the standard itself was developed kind of like outside of GA4GH but like Yasi if you know y'all see, he it was him and his team so he's he's kind of part of GA4GH already, but it's not a official standard of ours that that we had created. So they're hoping to bring it in and have us kind of adopt it.

So yeah, anyway, I think that open for comment is there until the end of the month, so you've got a bit of time to take a look at it. It's really short documentation. It's only about two pages. So should be should be a quick quick review.

Okay, and then I'm just going to go into a couple of updates from our meeting last week.

Big One is that the steering committee timing for January is now confirmed. So it's going to be Thursday, January 26 at 120 UTC, which I think is this time.

So pretty much at the timing of one of our regular meetings is the steering committee meeting in January.

So knowing that we have to have all documentation submitted to steering committee two weeks before that, so that would be January 12.

But you know, if we stick to our original plan of kind of having that final PRC checkmark in December we'll be in really good shape and have lots of buffer time there. So so just to make note of that, that that has been confirmed. And then typically, we do have to do a presentation at that meeting. So no grant or Orion if you wanted to take that on but we will have to make a presentation for that assuming the the PRC I'm assuming when you point that way, it doesn't go to Orion for me but that's not pointing at me. Yeah, there you go down.

Okay. Anyway, yeah. Orion is this direction on my screen.

So So yeah, so we will have to make a presentation for that. But I'll get you the details for that. Once I have more. Now, Lindsay, is that is that the very final step for us? For Approval? Yes. Yeah. Once we kind of get all this other stuff done. Then we do that presentation, the steering committee so when they receive the materials two weeks in advance, that will be their opportunity to kind of read it and decide, you know, how they might want to vote or any other comments they might have.

Then they'll vote at that steering committee. And so what we'll know by the end of that meeting, whether we get thumbs up or thumbs down hopefully it's a thumbs up. And then after that point, then there'll be like a little bit of implementation, outreach sort of stuff, like as your comms team will write some sort of article. And at that time, we'll also have that student who we are planning to have do a lot of the outreach and writing for us which is awesome. So we'll get lots of lots of communication out there.

Any other questions about that process?

Oh, good. Pretty straightforward.

All right.

One other update I had and I'll share my screen here.

So I've been working on a revision of the ecosystem diagram and I wanted to check with everyone that I've kind of got it. So are you seeing this slide here? Yes. Okay. So based on the conversations we had at our last meeting, I have moved the export import ingest arrows up to the implementation box.

I've split the family health history, data collection tools and pedigree management tools into two things, but I don't think these are split properly. Stephanie had done this originally added another box for risk analysis tools.

renamed this to the pedigree conceptual model.

Did I miss anything?

Yeah, because that's not a pedigree management tool. I think other than sorting out some of these things in the top left, everything else looks great. I like it. I think this is a huge improvement. Lindsey, and I think it'll be okay. Perfect, are really, really useful. Or and maybe I opened up a can of worms by suggesting that we split those two and maybe we should just group them back together again, depending on open to whatever people think but I think all of the other changes that we that, that you've gone ahead and made are great. And I think this will clear up so many of the confusions that people had and it'll, it'll work very well on that top. Okay, awesome. Yeah, and I mean, any. Oh, Grant, go ahead. Yeah, just a couple of questions. To help help me further understand what you've done. You're especially on the on that top left there. So you have the three data collection tools, and I don't have an opinion on this or not. I was just curious, did the three that you pick there or was that because they're most well known in the research world? No, this is what you're seeing on this screen are ones that either have implemented or will potentially implement. So it's an example of kind of our Oh, good ones in the room. Yeah.

Yeah, no. So hopefully we'll be adding more, you know, logos to that box.

scan that the GC chat box. Can you tell me a little bit about that? Because, yeah, so that was I know, maybe Zornitza. You know more about this one than I do, but I understand. So Zerah developed this kind of counseling chat box that can be used to kind of, you know, a patient or someone could talk with this chat box and it'll collect, you know, some of the information you share with it.

And they missed, but that's about as much as that's it. Yeah.

Has a name to it.

Did Alejandro start working on this? I can't, couldn't remember. I don't remember who did the work on it either. I feel like Ella hundra at least did something with it because I think that's how we originally heard about it. But okay, Edna Chatbot. That's good.

Great. Okay. Thank you. So yeah, um, so again, you know, I'll leave this up. I think it's open for editing. So feel free to play around with it and, you know, edit as needed, or let me know if something can be edited and I can, I can play around with it.

But again, yeah, if I missed anything, please do. Do let me know.

Okay.

Other updates.

Okay, so we heard back from Chris Mangal. about moving kin into the relations ontology. And so he suggested as a first step, either creating an issue in their ontology, kind of to get them start looking at all the relations ontology folks to start looking at kin.

Although Melanie had suggested, alternatively, to cross post some of the issues we had received in our repo over to aro as well.

There was never an immediate response of which one we should do.

But maybe, maybe both create an issue to say, hey, we're gonna move this thing over and then also cross post some of the other ones that we've received. So it's all in one spot.

I don't know if anyone has a preference of how that's moved forward or not. But or we can wait and see if Chris has any preferences that come back.

But that's good. We've all been moving forward on that.

I just want to make sure because I don't know if I heard a Ryan's direct opinion on this. I I know that Lindsey you originally sent out emails about this question. Orion, are you happy with this move or was there any concerns that you have?

I don't have any concerns about this one. Grant. I think it I guess. Yeah, I think we talked about that on the week when you weren't able to join a vote. I think my my general feedback on this was is that I think it from a sustainability and having having the ontology people invested in keeping it up to snuff over time. perspective, it seems like a really useful home for it, as well as from the perspective of in order to keep the ontology is on our side. Generally, the rule is don't create new ontologies if you don't need to, and so we want a new ontology, but we can get keep them happy by giving it a home. So I think that those all points in one direction for me and there aren't any particular concerns that I have about it. Are there any that you have, or thoughts that you want to share? Right? No, I didn't have any either. I, it sounded to me like it was the best idea that was on the table. And I just wanted to make sure that there wasn't some other issue that I wasn't aware of right about doing this. And so that's why I just want to ask you, but no, I'm happy to. Well, just I guess we'll just have some ongoing relationship with this group then. At the very least, it might sound like we want to help promote them in some way, because that would benefit us right if we did yeah, like by promote you mean relations, ontology, or well, both both their group and our kin ontology. But and when I say promote, I just mean more like get the word out. Let the world knows that this group exists. And that's where our kin ontology will live. Yeah, yeah. And I think we can, you know, once it's in place, we can update that in the documentation as well. Because we have that that kind of chunk of information about the kin ontology, so we'll just have to update where it can be found, essentially, right.

So yeah, yeah, I agree.

And Great, okay. The one last update I had is I did reach out to Jules about getting some instructions on how to use pedigree in the context of Phenopckets.

He said he'll make a PR for in the read the docs.

For what he's going to write. I asked if he could do it within the next two weeks at the latest when he seems to be no problem. So so we'll just wait until the PRS ready there and we can get that in. So that's fantastic.

Great fielding his questions. Yeah, no problem. It did. I answer, okay. Or did you? You're good. You're good. I

fell in between the one the one day each week where I let all of the GA4GH emails queue up before I can deal with them.

Okay. Any other updates? And we wanted to bring up before we dive into the two dues, or maybe they'll come up as part of the to dues? Yeah. Okay. All right.

So I'll take us over to the tracker here.

So I mentioned in the email previously, I've changed all the color coding in the track tracker. So green means it's resolved. It's done. We don't have to look at it. Yellow means we've resolved it. It's just PRC. This was one of the things PRC requested, so they'll just need to look at it. So from our point of view, we don't have to worry about yellows, and then reds are things that are to do although a lot of these I think we can change today.

And a lot of them are things that just we just need to resolve or I've kept it read because I have a question about it now and we can talk about those today as well.

So, before we get into things, one, I guess the main update that I'll give is that I've put forward a PR a pull request to try to handle some some subset of the to dues that were supposed to be done. Would you like me to merge it right now? And then maybe people can see it reflected on read the docs when we're going through these things?

Otherwise, we can just reference kind of the pull request and I can just use words to describe what was done.

I mean, I'm happy for you to merge it now. Does anyone else object?

No. Alright. Okay.

I need to Oh, no, I'm not allowed to purge my own pull request. Oh, really? Oh, it will need to be one of you. Let me approve, or approve it. Yeah. Okay. Oh, no, you can't even review your own pull request and say that it's okay. And then merge it, which is really the is that a setting that I have on the repo or is that just a it's a repo setting? Isn't it isn't my done? You've turned on the requirement for review, and require at least one review before merging which will make sense.

And yeah, okay. You know how I'll look at that later. But anyway, if approved me and approves it, then me.

Good to have friends.

in high places. Yes, I placed this Exactly.

Right. Okay. So that'll theoretically be reflected soon, thanks to means GitHub action. Thank you.

Okay, um, so why don't we just kind of start at the top and we'll roll down.

So the first unresolved item here was, again, just related to the documentation. So this was about

oh, so including some of the, you know, rationales behind the certain decisions we made. So, you know, why did we create a kin ontology instead of using you know, the fire set?

What else was there? Why didn't we use the family member history genetics profile? Why did we make a new IG?

So in terms of those rationale type questions, has that been added to the documentation yet?

There is some discussion of the alternatives that is now broken out into some of the different value sets and profiles and the limitations of them. It is

Present. Oh, yeah, you've got the updated one there. Lovely.

So yeah, so it talks about those existing standards for pedigree for family history, some of the rationale behind it.

And then what our goals were. So I guess this, this intro probably had the most textual changes out of other sections in terms of what was changed. And there was a fair bit of reorganizing at least that I did to try to make the documentation more coherent and kind of flow better with I think how people will come in and need want things presented to them. Perfect. No, that looks great. Okay, so that sounds like we can change that too. I hope so. Yeah. So there can always there can always be more and so what we'll probably want to do is make sure at least at a high level, that we've attempted to check these boxes, and then what we'll probably want to do is as we were going to send it out to stakeholders to read the actual human like the actual pros and see if it all makes sense still. And then see if it covers there. Okay. So I'll turn it to yellow for now. And then I'm also just going to flag that box in blue, so I have more text.

Great. That's good. That's good.

Oh, okay. So this was this one, I changed to red because I had a question about it.

So I was thinking about the move to the relations ontology. And so there was this comment from the PRC about, you know, adopting kin as part of the standard and CO evolving it. So now that if we're moving it to relations, ontology, like do we need to say anything about that relationship? Is that relationship going to change from what we had written earlier?

Like, I think we could still frame it as you know, we'll co evolve it and, you know, bring those issues to aro when we need to.

But I just wanted to double check that there wasn't anything I'm missing. There.

That's fine. I think that's okay. Yeah. The

Is there anything else there that we should probably be sure to do? I think that's okay. For now. Yeah. Okay, we're just saying and, and for sustainability sake, it's been incorporated into blah, blah, blah. And it will be Yeah, we'll take a request there.

So the the kinship ontology documentation page will need to be updated with all of this information. And these changes before we before we submit that good point, okay. So maybe, then maybe I will not change this to that and just add here

do see

okay, in that case, I'm just gonna turn that back to red for now. So remember to do that.

Okay, so this one is one that I don't think we can really deal with right now. But So expanding the kin ontology with terms to maps, those additional terms that were that had been listed by a gusto. I think this will kind of fall under the stuff to do for kin with aro so I don't know if there's anything we can really do about this right? Now. But so the plan last time, I think, was that we were going to kindly ask our O to do this. Is that right? Like the Chris Chris and the ARO maintainers to do this, if they're if they're so willing?

Yeah, yeah, so I think I mean, I'll leave it as read just so we still see it as a thing here, but I guess we can not not no action we can take right now on it. Okay, but we're gonna do it beforehand. And I did see that they had started making some pull requests to the terminology.

repo, so I don't know when that switch over, that they're planning on doing is they're probably just making sure that what is there is clean before pulling it in? Yeah, I think so. Those issues that were made, I think were the ones Melanie suggested cross posting over tomorrow.

So we could we could potentially do that.

Okay, so they already submitted pull requests that fixed though Oh, six. So therefore, I guess what they're, how many issues are there? There? are 22 2345677 are from the open for comment period. And of those seven, I think at least two two were fixed and then they made two other changes. Okay, whether that's great for context. Awesome. Thank you.

Um, okay, actually. So one more question I had as well. So, I suppose there is the potential that you know, moving the ontology to aro could take longer.

You know, I mean, I guess I don't know how long it could potentially take but we're kind of dependent on this. You know, external group to help move these things along. So I was thinking about the timelines to approval. And so I guess the question I have, can the conceptual like the conceptual model, theoretically can be used without the kin ontology, right.

Yes. Okay. Because if that's the case, then I think it's fine for us to still go to January without necessarily having kin ready.

Because essentially, so I was having this conversation with Angela, but like, what do we do if the ontology is not ready?

And she said, you know, if the if we consider the ontology to kind of be the package piece to the model, then they should probably go together. However, if, you know if we just bring forward the model and the other associated pieces we have, it can be used without kin, than that is okay. And can can be added later.

Does that make sense?

Does the

the terminal like the conceptual model itself, theoretically works without like it?

The work is not meaningless without kin. But as a standard, it kind of doesn't make sense without having that reference to the ontology. Because even the basics of like, can you represent a trio requires kin? Yeah, so

the alternative here if we wanted to unblock it on the external party, would be that we make the improvements to kin. Like, at the very least we make it so that terms exist for the things that we want to collect that we need to collect for coverages sake, and then when we hand it off to the ontology lists, they actually make sure that everything makes sense.

Right? Okay. Um, for her for lack of a better word, other than just saying like, yeah, yeah, we can define terms and, and give them identifiers. And then the ontologies can come in and say that all of the markup and the way that you've structured this is all wrong and it needs to be done differently, and then they they can do that. Yeah, I don't think that is at all at odds with the way that we anticipate this, you know, feedback and improvement process going. So that's a way of checking goals with well keeping to the timeline. So all it means is that we shouldn't depend. We shouldn't wait on aro to incorporate those. We should just mass merge them and ourselves, which is work, but not Not, not really not huge work. Okay. Yeah, no, no, because I was just thinking about that. And I was like, I would hate to like that. One reason we might not make it is because we're dependent on that external piece. So this is how we do work around it, or we just wouldn't even incorporate those and it's not the end of the world. Yeah, okay. So, okay, so what do you think should we add

so, you know, we had said that this one we were going to put to our row for example, should we make this ours? Like our issue to solve or not?

If Auro is actively working on this, then let's have them do it. But if we're so So I guess the question is, is how quickly do things get incorporated? Yeah, that I don't know. I don't know how to first entirely Yeah, so we should just have even just a an email check in with. Okay, Chris, just to make sure that we're not that we're aligned with what their expectations are because they're in the middle of understanding incorporating reviewing Kenya, okay, are going to start incorporating it in the next couple of weeks. It would be it doesn't make sense for us to start the day the experts in for this and we should just create the issue in cross posted in both probably, and then they'll get to it in short order. It sounds like we should, at the very least posted in our own is the answer. So no matter what. So the first thing to do would be to create those issues. On our side. And then when, when it is incorporated in our row, then we cross post any that haven't been resolved, is probably the right way to do it. So we're just going to track them in our repo. We'll keep making changes in our repo if we need to. And Bill keep in you know, fixing, fixing, fixing issues with Well, we've done and then when they pull everything over then we won't be making any more changes on our side. So we'll post over everything that's still open. Okay, so just to confirm that I've got this correct. We're gonna post these issues in our repo.

Then I will also check in with Chris and even potentially, Melanie might know more about how all this works too. So email check in and then I guess once and just get a sense for timelines like when when would they when would they expect to pull it into aro like, Is this in a matter of weeks, or is this in a matter of months, and that'll really dictate what we do.

Okay, you can let them know about our steering committee deadline. Yeah. Oh, yeah, I definitely will. I guess I'll give them a sense of kind of where we're at and where we're trying to get to, and hopefully something will align in there. If that doesn't work for them, then I guess we can go back to the original planners who just didn't write. Okay, so it's just a question for them. Like, do if they're moving quick. They can incorporate these. You if they're not, then we'll do it and that'll be more stuff that they have to clean up before they pull it into arrow.

Sorry.

Okay, that sounds good. All righty. Um, great. Moving on.

Oh, okay. Use cases into the documentation.

I did a pass on cleaning up the use cases. When people have the chance they can go through and read it. I hope it is. So there are two things one, in the introduction, I reworked to kind of example use cases and I put tried to articulate the primary use case of both here and actually at the very, very beginning. And then two I pulled out the the well yeah, no, I guess this is really the main the main part of the point. I mean, they're basically the same as what was there. It's just cleaning them up and trying to make sure that they're consistent with what we've actually done. Okay, no, that's perfect. I will change that one to yellow for now. Great. And if upon reading it, anyone feels like it doesn't do a good job that please just let me know or make the change. Make a PR.

No, that's good. And then there was also the comment about kind of having that example continuity throughout the documentation. That's not there. Done.

That was a nice to have.

Okay, yeah, true. Um, so I'll leave the to do piece there then and just put continuity question if we get to it great. If not, at least the use cases are very good there.

This one I have is read but it's not really a huge thing. It was just please provide hyperlinks so I figured when the documentation is all done, we can just check everything that's linked should be linked.

So that's not a big one. I even I could do that one at the end.

That was good.

Oh, so improve the documentation. So it's clear how to link to Phenopckets and fire. Jewels is taking care of that Phenopckets piece so that's good for fire what do we have in there right now?

Um, I don't know. Is there anything additional we need to add here about kind of this HL seven fire implementation guide piece? I

mean, what else would someone a developer minded person or or otherwise coming in? Who wants to understand what this looks like? Like how to actually use it in the context of fire? Is there is there more more stuff here that they would want?

So I am assuming that person is already experienced in fire or implementation guide, How to Read implementation guide at least so I think it is pretty sufficient.

Okay, and we do say You know, if you want to learn more, yeah, Firebase Yes.

Okay, okay, that's the final to do. We'll be making sure that any of these last round of changes for additional fields that we've added here or there are fully reflected in that implementation guide.

Is it I don't think so, which they haven't been yet. Right. I think this draft this, this IG is from a brutal end of April. And I think there have been a few small changes that we've made to a few of the fields, your current like the the population descriptors and Yes, exactly, yes. Unless you are very, very quick on updating the chromosomal carrier.

Can I ask a question about that, please? Yeah.

Has actually are you could you go back and click on that link that was there for this

video, yeah. Okay. So this has not been validated. Is that correct? No, not yet. So I think that it's important for you to say that in your text, because it's not. It'd be like throwing something onto the GA4GH website that really nobody in G GA4GH has looked at or approved.

You guys have built this.

It's sitting in its own world. I'm not aware of it. It doesn't follow any of the processes that we use to get official HL seven fire artifacts built.

Okay.

Okay, yeah, we can certainly make that clear. It's not sitting on any HL seven space, though, right like this. Well, it's masquerading I don't mean this in a nasty way. But it's using the standard.

It looks like a fire implementation guide because somebody created it using the standard template. So it looks like an official fire implementation guide. And, you know, I forgot when it went to the top, which is where it would say anything about its maturity.

Okay, it's a local development bill, which is appropriate, meaning it's nowhere right? It's not really a valid HL seven artifact yet.

Okay, that should be easy enough to do to add, you know, a sentence or two that says it's not hasn't been validated yet. That's yeah. And then I got other questions about that at another time, but about how to proceed with this. And grant on. I would expect that something I would hope that something you've been thinking about or looking at, but definitely when we got to that point, yes. Yeah.

So this is still under development. So Right. And that's my point. I mean, I think we probably should say under development or something like that in your in your words. Okay, next. Okay. Thank you. So I just I changed the to do on this row to clarify the text that is not been validated.

Grant Oh, that's about the classes given that you have more context on the HL seven validation slash development process. Would you be up for putting together a couple of sentences that we can plopped into the docs that have the appropriate amount of hedging or caveats with the right language? If you like, what Yeah, I can certainly do that there. Is any specific, you know, HL seven required language here, you know, we have to follow but yeah, I'd be happy to do that. Okay. That'd be great. Thank you. I want to make sure that it's, it's clear to all communities right. Okay. Um, and we will we probably should put some description next to the link also, right.

onto this page. You mean? No, the the the page that has the link to oh, that's, yeah, that's what it was. here and we would put the sentences probably Yeah, right. Yeah. Right. Okay. Yeah, I'll do that.

All right.

Okay, skipping on down to Okay. So the key topic sex field. So we talked last meeting about adding it to the common data set, which I think we've done updating the IG in the documentation accordingly, and then provide implementation guidance or documentation on how to represent that. So this is another documentation piece.

Have we tackled that yet?

I added it here. I didn't go out and add it to any of the other link situations. And I don't see. And so it's it's not in the it's there. It isn't there or in the IG or in the UK stock yet. Oh, actually, I think it is in the use case, but it's not in the IP or in that diagram. I mean, do you have a nice way of regenerating that diagram? Oh, yeah, sure. Or do you is do you have like this training manual process, but I can do that. Okay, that would be do you have like a source file that's downloaded and uploaded somewhere that we could save to make it simpler? Yeah. Let me share is draw that IO on Oh, yeah. So if you, that'd be great. So if you can even just export the draw.io.

Then we can commit it to source code. And then we can kind of iterate on it.

Sure.

Okay. Oh, that'd be great. Thank you this. Yeah, because I actually on that topic, because I also noticed, although we've got population descriptors down here, it still says race, race, ethnicity ancestry in the diagram. So that'll need to be updated as well.

Okay, so Okay, so we've got it in common. Jade says in the documentation, but not the IG Correct.

To IG last diagram, those are the only two things correct to the IG and the class diagram. Those are the two spots it's missing.

And population descriptor probably.

Yes. Okay. So that's the next row here. Oh, yeah, update the concept map. Because although it's in the text, it's still says RA and that and those are that's not in the IG either. Right?

Not yet. Not yet. Okay.

And then, oh, so, this was a question I had. We had talked about adding, like a, potentially a second free text option to that are we still planning on doing that or have we abandoned that idea?

Because I remember when we yep, that's a question for the IGs because it the conceptual model is a little is generally pretty light on how defined they are.

We I think we say that it should be a free text option. But what that functionally means is that we are going to have to figure out how to support that in fire in the fire ag and then in the unit packet. And make sure that they connect.

Okay.

I mean, like, I don't think it's, I don't think we have to do it. To be honest, it's more of whether we want to or not, because I mean, now that we've changed the field to population descriptor.

I guess it would be if there was, you know, someone's trying to use I don't put an ontology in there or something and it doesn't have a term they want to use. So they want you maybe use the free text to fill in more detailed information. I don't know.

So yeah, are we adding that option or No? Should I delete this sentence is basically what I'm wondering.

The make sure there's a free text option.

I would just delete that. We, the conceptual model, has actually does say that free text must be supported. So we've got checked on that. And so now we have to make sure that the fire IG and the SR packet implementation guides both support that.

Okay, that's perfect.

Okay, I've updated that. Great. And I think the last thing we have, and this was again, just a question from me.

So it was this was a comment based on the common data set.

And, you know, if you were looking down the columns we had, you know, the pedigree IG and I think we had fire genetic pedigree in there as well. And then across the rows, we had the rows for race, ethnicity and ancestry, we have put not applicable, and I think one of the PRC members interpreted as like, we were saying that that couldn't be represented fire, and I think can just not in that specific profile that we have listed, I think so basically, I wanted to confirm that the text I have written there is correct.

It can be represented in fire however the common data set tables only representing the fields in fire genetic pedigree not.

Does that make sense? What I was trying to explain there

though those specific fields can't natively be represented in the fire genetic pedigree itself.

Yes, and I think we updated I mean

it's a bit of a because on one hand

what we're really saying is fire the fire core, and basically, only fire Core Plus genetic pedigree, right?

Because I think other sections in there do reference things in the fire core, like outside of just that one profile. Like patient dot gender, for example, or patient.id. But what we're saying here is that these are not also not natively. Yes, they're not natively supported. There. Okay. Everything can be represented in fire. So it's a little bit of a delicate Okay, so if they're happy with it, then I can just change it to yellow we're done. And Arthur, oh, Arthur's gone now. Ah, okay.

I was gonna put him on the spot and be like either. Does this make sense given the I'll tell you why. When we're done here, I'll tell you why he was had joined for a few minutes, but this person Yeah, well, but I guess for you, do you have any comments about the right way to toe the line here with what we're trying to say? Because you're in the best position, I think to speak to well, it's what we have here is true.

You know, it's not represented in phylogenetic pedigree.

Okay. All right.

That's good. Well, I'll mark that as result.

So that is that's everything.

So going back to our agenda here, so I guess the my follow up question is we had talked about you're kind of using Nov to do some outreach to, you know, some potential implementers or current implementers. And, you know, have them check the documentation. Make sure everything makes sense. You know, if they've never seen the documentation before, maybe get another set of eyes on it.

When would we like to start that? Because it sounds like there's still a couple of little things here or there. We need to fix in the documentation.

So what what would be a reasonable time to start that then? If we still want to make those couple of changes?

Do we want to wait for the thinner packet stuff that Jules is doing before sending it around? Or?

Yeah.

I mean, I, it's a good question. I lean towards maybe waiting those two weeks and then we have a more complete package to send, rather than them coming back and be like this. There's not enough information or whatever it might be represented or whatever else. Yeah. Yeah. Okay. Then okay. We should use them. Let's wait those two weeks and use that to make sure that the fire fire piece is IG is updated and referenced properly and things like that before we Okay, perfect.

So for do we want to meet in a couple of weeks, then where are we now? 31 to 24th is Thanksgiving that's not ideal.

On the 17th

Well, so, potentially, I gave I asked Jules to hand it to us by the 18th. So that's why there's a potential if just in case you waited till the very end of the deadline there. We might miss it.

Actually, for the day anyway, we don't have to do it Thursday. No, we don't. I guess it depends on you know, if we change the day will that you know, disrupt anyone's calendars like if we did earlier that week following Well, it seems from the people that have joined today that this final detailed stuff is not a big exciting thrill ride for the rest of the group, which is fair.

Okay, so why don't I mean, there's a Clin/Pheno leadership meeting scheduled.

On Monday, the 21st at our usual time, we could use like, I can even schedule the half hour after that if people are free, since we've kind of already got part of that block scheduled.

Yeah.

What works for me and would you have that half hour there? So 430 to five on Monday, the 21st. Monday, the 21st. Want me?

One second? Sure. Yeah. And then it's a two I don't know if you were planning on coming to that as well.

That half hour block right there.

The alternate should be available. We can just send it around that people are happy for it. If we can if we don't. Yeah, I mean, I can put it in the calendar. If we decide. We don't want to use that half hour. That's totally fine, but at least we've got something in there. I agree.

Okay, I'm just gonna, I'll get that done after.

Okay. So, with a couple of minutes we have left grant, did you want to You said you want to talk? I think I know what you're going to talk about a little bit because Bob had sent me a message as well. But take it away. Well, yeah, I hate to to do this because my brain is just thinking of different ideas of where what we might do next, and one of them is with genomics.

And you were thinking of something else. I was thinking of something else. But yeah, so So I was gonna have Arthur, you know, if there's going to be more people on the call that weren't aware of genome x, just do a very quick description of what it is but then I was going to then present some of my ideas and that would be that genome X could put as part of the different projects that they are lining up to do. I could envision a project that combines genomics and family health history we have in our common data set document in one in the appendix, where we have the HL seven variant reporting, pharmacogenomic reporting, somatic reporting, etc.

That's in there because there's this idea of a you know, a future use case where we take the pedigree model that we're working on and people create a family health history tool. And not only do they want to collect that data for for one particular proband and send it somewhere. They also want to attach some variant data or you know, some pharmaco genomic data or data to that family health history report that we're building. And so I wanted to talk with not only our group but then also Arthur, as that might be of interest for genome x because what we want to do is genome X is supposed to bring in people who are not working in HL seven who are not working at GA4GH who are not doing standards. There really are people who are building products right and they want the industry to adopt quickly adopt differences standards, including fire and GA4GH. And under g genome access where this could happen, that's the umbrella where this can happen. And so I was just gonna raise the idea that how about under genome x, we create some sort of a project, you know, get a lot of people interested, including those who are actually building products on the commercial side, where we can we can start adding genetic and genomic data to family health history reports. Anyway, so that was the reason why I invited Arthur. I think he just had to leave quicker than then he had time. But anyway.

2022-10-20 - Pedigree Subgroup

Chair: Orion Buske, Grant Wood

Attendees “Name (Project Affiliation)”: Meen Chul Kim (CHOP/KF), Chen Chen (GA4GH), David Hansen (CSIRO/AGHA), Alex Tsai (GA4GH), Zornitza Stark (AGHA)

Minutes:

Pedigree Ecosystem Diagram

Include risk models in the ecosystem diagram.

How to represent the GA4GH Pedigree Format circle, when we’re moving away from the standalone model. Soften to ‘conceptual model’.

AT: Having a core Pedigree model for the tools would be the best way moving forward. Wouldn’t be able to expand in the future otherwise.

OB: Do we allow exporting in the format other than those two.

Is it useful to distinguish the types tools - patient/FHH collection, vs management. Document could be improved by distinguishing these.

Move the arrows to the implementations.

Emphasize the analysis tool side to highlight genomic use cases.

Most important is the documentation. Tooling needs to be consistent and run locally. Phenopackets implementation in the docs. Aim for end of October with the green highlights - solicit feedback throughout November. While we solicit feedback on the other pieces, like FHIR IG and KIN.

Next meeting November 3rd.

Transcript (generated from Otter.Ai):

LS: The main thing to do today is regroup from our last meeting and confirm all of the main things we need to do over the next month. Few months or so until the next GA4GH steering committee approval. So what I wanted to first talk about in terms of housekeeping, GA4GH Connect, which as a reminder is our virtual working session meeting, is coming up on ONovember 14 to 16th as well as November 30. That extra date was just added because for a few contibutors, the 14-16 didn't work. The call for workshops closes tomorrow.  I wanted to get a sense of whether we wanted to submit anything for workshop. In my opinion, I think right now we're really going to be focused on getting things done that we need to do for approval. So I don't know if there's anything sort of connect cross work stream stuff we need to do at this time, but I wanted to throw it out there in case anyone had any strong opinions or thoughts on this.

OB: I don't have strong opinions. I'm fine to skip Connect. Unless someone feels like there's something that we should do during it.

LS: Perfect. Okay.

LS: All right. Next thing before we dive into some of the approval timelines is related to the new GA4GH website. I had received a question from our comms team about our ecosystem diagram that's currently living on the introduction page of our documentation. They were wondering if we wanted this to be the main image for the pedigree page. Eventually, when we're approved, they will create something more kind of like the cartoony style looking ones that they do for phenopackets. I wanted to, again, kind of open to the group one, are you okay with that? And two, is there anything we need to modify on this before it goes live?

OB: I have three questions for people about it. One is, so I was digging into that earlier today. To one would be does it make sense for us to add any other analysis tools that aren't yet part of the GA4GH quote unquote ecosystem but might make sense or do we ask people whether they want to be looped in like, some of the obvious ones? More like hereditary cancer risk side, like can risk or something like that Boadicea, one of those tools that I think would be useful to show here from the perspective of the user in terms of thinking about the ecosystem.

LS:  I wouldn't want to, I guess specifically name any group or thing if we haven't reached out or brought them in? If we could just put something kind of generically labeled in there, like risk models, that would apply to them.

OB: I think risk models might be a good way of dropping the hint of what those capabilities might be.

LS: Will forward edits to comms.

OB: The second question is, we highlight the pedigree format, pretty front and center. How do we feel about this? Given that we then mostly in the text hedge away from that as much as humanly possible?

LS: relabel it from pedigree format to conceptual model, and we can make the circle small. I don't know what do you think?

OB: I don't know at this point. The most important, from my perspective, the most important things that I think that we need to do before we submit are going to be getting the tooling. Like there's some documentation stuff, and then there's getting the tooling up to date with an appropriate version of the fire and fina pack and implementations in order to do that.  If I recall, right, that that when we get into some of the as basically if we're going to be building an adapter between these two different formats, a phenopacket version and a fire version, the code for the pedigree tooling is going to need its own internal format in order to support the switch between the two, at the end of the day, right? Or it's just going to use one of the two, it's just going to use fina packet and then we run with it, what is your thought on that? Because it to some extent, does impact this because then we could just export from that internal format to and then when we talk about it, downplay that component, but it's at least not inaccurate to say that there is this capability that makes sense.

AT: Having a pedigree own structure to store certain fields. I think it would be the best way going forward. That way, like if we want to incorporate something else we could do that. Whereas if we were only to support the specific phenopacket/FHIR stuff, we wouldn't be able to expand in the future.

OB: yeah, I guess the question is do we allow exporting these data in any format other than those two? Is there an intro or are we just opening up this whole can of worms.

Unknown Speaker  13:40  

so. Yeah. What the tooling would need to be able to do is basically say, you the tooling would need to be able to say import fire export fina packet, or import fino packet export fire or import from Boadicea ped for gedcom. Output, fire or import one of those three and outputs, output SR packet. I think those are the set of conversions that are needed, and it can either be done as importing any of the five and outputting, a common format and then inputting that common format and outputting whichever you know, at least the fire in the pheno packet, but potentially some of the other formats as well. So it can go through a central place or it can that doesn't need to be exposed in the way that we are, but it may make some things simpler. It's just about right now that whole right edge of ingesting it for analysis tools and things. It's what it really is, is those all get ingested from the implementations above. Right. Yeah. And that's really, so if that, especially the circle and the arrow to the right, is is where I think the most confusion is happening. Or would happen from a user's perspective, because that isn't really what is happening in the way that we've set things up. Right? Now. It's,

In theory the problem could be solved by having if that tooling that they have is able to support the what we're proposing in terms of the implementation guide in terms of fire and the improvements to the pedigree representation in the context of Fina packet, which I'm not sure it would, but if it did support that, then they would have that conversion already there. If there, if the scope of what they're talking about include the pedigree data in in this relational way then that would solve that problem. We wouldn't really, but if what we're thinking about is saying there is pedigree data that's coming in from these different formats. I guess maybe then the most important part of the tooling is supporting the conversion from existing structures like gedcom and ped and Boadicea into a GA4GH compliant version implementation like the phenol packet one that could be enough and then there's this other tooling that can get you from packet to fire. I knew that the lift of sort of natively supporting fire might be a little bit high, or to support that in terms of the tooling.

OB: 3rd question. This one's easier. I wonder whether it is useful to distinguish the two different types of tools, buckets of tools that we have on the left, especially if as we add more, which is that you have fundamentally like patient family health history, data collection, versus pedigree management. I think one of the ways that the documentation could probably be improved is by clarifying the distinction between what we talked about when we say a family history, or a family health history and what we talk about what we're saying when we talk about a pedigree. And that in the context of this standard, we're actually trying part of the challenges that we're trying to be ambitious and cover both of those. If we were just covering your regular genomic pedigree you might be doing then it for some use cases of ped is enough. But if you're incorporating family history and the consumers of family health history information, in a pedigree sense, which is where risk models and things come in, then you need a more comprehensive format. So that's the other idea that I had for this, but those are the three.

DH: we don't want to just make it look like an exchange pedigree exchange format, you know what I mean? So emphasizing maybe more on the analysis tool side, or analysis side. expanding it into being a little bit stronger in terms of highlighting the genomic use cases.

Lindsay to make the diagram edits.

LS: I just wanted to do a quick recap of the timelines that we have just so everyone's on the same page. So the next GA4GH steering committee hasn't been scheduled in the calendar yet, but it will be January of that we know. But the exact date, it's kind of up in the air. But roughly this gives us all of November, all of December. A little bit left of October and presumably a little bit of January at the end there. However, I realized this gets into holiday season near the end, so let's assume we've only got about the two months up until Christmas and we can try to finish by then. So roughly seven weeks or so.

LS: And then the one last thing, I wanted to give a quick update for anyone who hasn't heard of this discussion yet about moving the kin ontology into the relations ontology. Had an offer that we could potentially integrate the kin ontology into the relations ontology, they would support resolution of the open for public comment feedback. And from what I understand, it would still be appropriately attributed to GA4GH the work we're doing here. It would essentially almost be like a subcategory in RO. The added bonus of this is that they will maintain it so we don't have to take too much of the maintenance on ourselves. So since that point, there has been an email outreach to determine the next steps of how we might take this forward. I just sent a another ping earlier today about it.

OB: I think the only other change that we need to do is what is the list of critical to dues before we submit, and there are probably a you know, a few things on the ontology side that are on that list, but we'll get into that later.

LS: What I've listed here, I just quickly pulled from that comment tracker, just kind of in a more shorter, digestible way. So if you want to see more detail about all of these, again, just click this link here. So one of the big things I think we need to do and this comes largely from the PRC is all of the outstanding documentation updates we need to do. So this includes: we talked about doing some revised examples that kind of follow that go through the whole documentation. Related to that, we talked about addition of some content around the scope, the rationale and the use cases. This was suggested from the PRC, when they were kind of trying to understand the differences of, you know, like, what does the kin ontology do that the FHIR family member history value set cannot. What was the rationale of creating some of these things, which I think will also be really helpful for users and implementers when they're, you know, learning about the standard and wanting to understand some of the choices we made at the modeling. There was also a request just to clarify some of the fina packets and fire linkages. So I think this this is referring to right now in the documentation. I think we've only got maybe like a paragraph that kind of explains the Phenopckets integration right now. So I think we just maybe need to expand that a little bit more.

OB: Minimum form? We tweaked it. There's like, whatever the minimum is, and then there's probably more that can be done. I had gone ahead and adjusted the way in which it was talked about in order to meet the minimum needs of that PRC comment. And I'm sure that as we work and rework the documentation that will further adapt, but at least at a high level, that should be covered. Okay, excellent. So talks about kind of the choices that a data input that an implementer will have to make about how they want to serialize it and some guidelines for it, but it's no longer called a minimum form and it's now you know, softened significantly.

LS: Perfect. Okay. I'll add that response in the spreadsheet as well.

KaryotypicSex/REA Edirs

OB: We did make the change, at least in terms of the documentation, I think of updating it to be called Population descriptor.

How strong was the comments? I'm just noting, because I know there were some great updated guidelines around pedigree nomenclature and sex and gender representation and things like that. We've been digging into this a whole bunch on the phenotype side recently, too. And it's, I mean, it could be part of this

 Zornitza - Can I put you on the spot for a quick sec? Do you have any thoughts about the karyotypic sex comment, Have you ever encountered this? We're talking about the karyotype. XX and how much how often that is necessary from a pedigree representation perspective explicitly, as distinct from sex assigned at birth and gender.

ZS: Very occasionally. And, and I guess, we often find that out from the genomic data itself. Sometimes the referrer does know that there's a discrepancy. We do have a pathway for disorders of six differentiation. But it's a rare event. It's a small subset of patients that we test, but it's definitely a group of patients that we test.

OB: In terms of the representation of it. I could imagine there being two different approaches. For saying that we represent this. One would be saying this is less a property of the individual and therefore doesn't belong there, but is more something that would be represented through a disorder coding system like yeah, that's one of the which is already supported by fire and, and fina packet and we would just say, in these cases, here's how you represent it, which we could do. The alternative would be to say, we'll just make an explicit karyotype xx field it's a string, just text. And unless there's a more structured way which packet might actually have and could point us to, do you have a sense of which of those two routes might make the most sense to people who are looking at this?

ZS: I guess it is helpful for it to fade into genomic testing system as an explicit thing, because that it's an unpleasant surprise for us to find that the karyotypic sex is different to what the phenotypic sex was stated as usually causes a lot of panic.

OB: Okay, so in other words, having it be explicit as part of the pedigree individual, if known, may be a better way of making it apparent rather than just having it like nested within some clinical diagnosis somewhere.

Meen any concerns with us adding that and implemented in that way (same as Phenopackets)?

MCK: Not on my end.

KIN Ontology

Include Super set of the fire value set and the GEL list. And there's not really a reason it shouldn't be included based on the way that things have evolved and we made some original design decisions early on, that would have been a justification for it not to cover everything in the fire value set, but I don't think that applies anymore.

** possibly pass on to RO folks

Phenopackest

So there we need to delete the phenopacket pedigree repo that isn't needed anymore. And then basically I think we just need a set of instructions at the end of the day. For “I am a developer who is trying to use this. And I would like to use it in the context of a Phenopacket”. Explain it to me like on five sort of an approach.

And the problem like it will change as it gets incorporated or not, or like the relationship between what we've done and phenopacket evolves over time, but it has this certain relationship at this point in time which is I think that it is implemented on a branch and in a way that can be used in the context of phenopacket which is fine. We just need to tell a human who is trying to use it, what that means about how to actually use it. And I have a very vague, cloudy brain foggy version of a sense of what that might look like. But I think Jules is the person who really practically knows like, this is what you would do to do it.

LS: I'll make that an action item. For myself to reach out to Jules.

2022-08-23 - Computable Cohort Representation - Summary Statistics

The minutes for Computable Cohort Representation Summary Statistics meeting can be found here.

2022-08-11: Pedigree Subgroup

Chair: Orion Buske, Grant Wood

Attendees “Name (Project Affiliation)”: Meen Chul Kim (CHOP/KF), Melissa Cook (NCI), Grant Wood, Amanda Spurdle (BRCA), Alex Tsai (GA4GH), Hannah Calkins, Chen Chen (GA4GH), David Hansen (CSIRO/AGHA)

REA Feedback from REWS contributors:

This is a super important question. The answer is that this data structure should be able to hold as much data as is available for the individual when it comes to population descriptors.

The simplest would be a field "Population descriptor(s)". And then explain that this is to capture the info available in as much detail as possible about ethnicity, ancestry, race, tribe etc..., e.g. Don't put "Asian" put "Indian from Delhi" etc.

There are many other things that could be potentially useful, e.g. language spoken, genetically inferred ancestry, where the sample was taken.

[Do you think it would be important to distinguish whether the information was self-reported (vs. clinician or someone else reporting it)?

Yes, ideally! Maybe this could come in brackets. i.e. the description could read something like: "Capture as much detail as possible about the individual's ethnicity, ancestry, race, tribe etc, as well as indicating what information that is based on (self report, genetic inference, administratively assigned, language spoken, geographical area) e.g. Don't put "Asian" put "Jat Sikh (self report)" etc.

If the field needed to include as much information as possible, would you agree that it would be best to make the field free text rather than trying to adhere to ontology terms or other structured format? The downside to this is that it reduces computability if users can throw in anything they'd like. I suppose later down the road we could update the field constraints if someone decides to take on the herculean task of creating a truly globally representative ancestry/ethnicity ontology (Hancestro is currently abysmal for African populations).

Definitely free text, for two main reasons. a) If it becomes important to process this data later, useful information will have been lost, and b) if we can avoid putting people into boxes, we should -- humans don't come in distinct types.

I've just been taking another look at the paper that intros Hancestro. They go to quite extreme measures to go from starting data to one of their categories, pasted below. I hope this illustrates that getting to a nicely harmonized dataset is a huge undertaking, and that people who are accessioning samples should not be expected to do this. What enables others to do this at a later point is information that is as detailed as possible (now, whether others should even attempt to do this harmonization is another question...). So I would vote not to even mention Hancestro, and perhaps give more examples in the definition.

FYI, When it comes to variant interpretation, I've heard that a main use case to get population descriptor data is to identify whether two reports of a variant actually come from one and the same individual or not.

Hancestro excerpt:

"We relied heavily on data stated by authors in the GWAS publication, giving precedence to information inferred using genomic methods, such as principal component analysis (PCA; see Additional file 1: Box S1 for a list of methods commonly used to ascertain ancestry). In some cases, we considered other sources, but only when the information provided by authors was limited or ambiguous. We consulted peer-reviewed population genetics publications to obtain additional information on lesser-known groups that were not adequately characterized by authors or when samples were described using ethno-cultural terms (for example, “Punjabi Sikh”). When the only information provided in the publication was the location of recruitment, we consulted The United Nations M49 Standard of Geographic Regions [12] and The World Factbook [13]. The latter is a regularly updated compendium of worldwide demographic data, covering all countries and territories of the world. Additional file 2: Table S1 provides a list of countries of recruitment in the Catalog, together with the sources that were consulted and the inferred categories.

In rare instances, the ancestry information provided by authors was not detailed enough to allow the resolution of samples into ancestrally distinct sets. For these samples, we created complex, multi-ancestry detailed descriptions and selected multiple categories (for example, Catalog entry for Jiang R et al. [14, 15]). For admixed samples, we selected either one of the categories that includes individuals with well-defined admixture (“African American or Afro-Caribbean” and “Hispanic or Latin American”) or the category “other admixed ancestry”. We also captured additional information to describe the ancestral backgrounds that contribute to the admixture. No ancestry-informative detailed descriptions were generated in the absence of ancestry or recruitment data; for those samples, the category “Not Reported” was selected.

Where possible we also curated country of recruitment (Fig. 1; Additional file 1: Figure S2b) and country of origin as this provides additional and complementary demographic information. Country of origin was extracted when the country of origin of the study participant’s grandparents was stated or when the genealogy of the sample could be traced to a particular country.

The detailed extraction guidelines utilized by Catalog curators are included in Additional file 1: Supplementary Methods. A full list of Catalog detailed descriptions and categories is provided in Additional file 3: Table S2. Examples that illustrate application to specific samples can be found in Additional file 4: Table S3. All curated ancestry data are available from the GWAS Catalog website [4] (Fig. 1) and via download [16]."

Minutes:

The transcript of the meeting can be viewed here.

REA Field:

GW: Should we give this to the implementer, they can decide what ontology they want to use?

AS: Good idea. If people don’t know what to use we can provide recommendations.

GW: We don’t decide the ontology or term.

OB: Be clear in the implementation that when something is codable concept or ontology, there is some fall back, like having free text. Question of whether we need to include provenance, like self-reported information.

Make sure the standard reports free text. In Phenopackets, there is no fall back to free text, in FHIR there is.

To re-name field to “Population descriptor” and make sure there’s a free text option.

New KIN Ontology Terms:

Lindsay to email Hoa re: term additions.

Examples & Use Case

OB: Would it be useful to choose some, represent in Phenopackets and FHIR. Or choose one and go into depth.

Say we choose the first one, let's come up with a pedigree for a trio or quad and demonstrate how that works in the context of Phenopacket.

OB: I think we should choose a story that highlights a few, like a  patient is seen, information is sent for testing, then later a second family member comes in, etc.

GW: Choose an example that shows more than one condition.

Karyotypic sex

Add field to the common dataset, update the IG, and the documentation

2022-08-04: Pedigree Subgroup

Chair: Orion Buske, Lindsay Smith

Attendees “Name (Project Affiliation)”:  Zornitza Stark, Meen Chul Kim, David Hansen, Chen Chen, Amanda Spurdle

Minutes:

LS: I think one of the challenges and I think one of the reasons we're also going to be updating the GA4GH approval process, is that a lot of the questions they had were the kind of things that we've already discussed and made decisions on and now we're having to reexplain those decisions that we've made. Because we've had these discussions they should hopefully be easy comments for us to answer. We have to give the PRC a little bit more context and background to help them with some of their review. One of the big questions that we had and I highlighted it in red, was just about two things. One was this question of the standalone-ness of it,. And then from that there was also the question about FHIR and the family member history resource. I think they wanted a sense of why the new implementation guide what does this do that the other things can't. I think we can pull a lot of that from our use cases and even some of the folks that are using the FHIR implementation guide to help us explain this. There was a related question about the kin ontology about the FHIR valueset - what can KIN do that the valueset cannot. So a lot of it was just kind of wanting to know wanting to better understand some of the choices we made.

The sooner we can get back answers to some of the questions  like the rationale of why we made certain decisions, I think the sooner we can get the PRC on the same page. There was a question from the PRC about the strategy for GA4GH and HL7 interactions. I flagged that as something that I'll just take care of, we'll work on this, you know, kind of more from a GA4GH high level point, so don't worry about that for us.

LS: I think it's going to be part of my job to remind the PRC that that's not really the type of questions they should be asking, because that should already be something we've solved -  is this needed? Why did we do this? We've done that work already. And that question should really be answered when we first proposed it and showed all these groups that want to use it right. It’s my job to show the PRC they should be asking: does this do what it needs to do? Not necessarily the why.

So first comment here about how the pedigree is computable and how comprehensively it is able to represent any pedigree, and to what extent it's able to represent various disease situations such as risk factors, incomplete penetrance, multiple noncommissioned officers. So I think if there's something in the documentation we're missing that would clarify this. To me this isn't a model issue. This is just a communication issue.

OB: This is a taking of the examples and those example use cases that are outlined at the beginning and following them through to explain how it would be this to maybe give tangible examples that are specific to those use cases later on in the document.

LS: How do we want to address that? Can we work some of these into the examples we have later on?

OB: I think that's probably what we need to do.

LS: The priority question they had - is the pedigree standard expected as a standalone or will it need to go with a further standard that describes clinical and other individual level data? So of course, as we know, we've got FHIR and phenopackets, so maybe we just needed to make that a little bit more clear in the documentation.

There was additional comments on the call itself about thinking of GA4GH’s goal of interoperability and what it means for someone to might have to switch from one implementation to another to a standalone. There's a question also here about the a family member value set in FHIR. And so what can it or what can't do that our kin and ontology can do? And so a suggested action here is just to explain this a little bit more. If the problem is tooling? That's a separate conversation. So I think again, this is just something that we need to explain.

OB: I'm curious what other people's thoughts are. I mean, I think yes, we've gone down this path of state of not having a separate standalone standard. If they feel strongly that that is not the right choice. It will be helpful to get that feedback. But I mean, ultimately, the choice of presenting it in this way, and maybe that's just what we have to mitigate. People are focused on the translation between a  phenopacket versus a FHIR implementation of this rather than in reality if it were a standalone standard, then people are going to be focused on the translation from FHIR to it and from it to phenopacket and from phenopacket to it, etc, - having a third standard doesn't necessarily help either. Or introduces similar challenges around conversion, like having a totally separate standalone standard doesn't mean that there isn't conversion that's necessary then to get into and out of it. But it's a fair point. I mean, if there were four serializations that we were talking about, then it might have made sense at that point for us to have it be standardized separately, and then do the individual mappings to and from it. But I think that's sort of where we landed in terms of it. So it sounds like we just need to do a better job of explaining, clarifying that and the rationale and making sure that there is clear interoperability between those two implementations, which is hard. But not any harder than the interoperability between those two implementations and some third independent standard.

So that's sort of my sense in terms of the first one. In terms of the second, and related to the goal in terms of the FHIR family member history value set. I think there are a few things that we can talk about. One was part of the rationale for starting a new one, there was a subset and actually a different set of terms that were relevant to this use case originally. In terms of having it be, let's say, gender, or sex agnostic, and a few other attributes for the very first version. That philosophy then sort of changed as we have gone through this design implementation process. So we've adopted, I think, a much more inclusive approach in terms of adding terms that are, you know, adding additional terms and then linking them in logically so in the context of the there should probably not be things that are in the FHIR value set and not in ours. It shouldn't be a superset of it. There are already things within our terminology that are important to represent in this case. Around in particular, I think donors that were not at least at the time represented in that value set. The

DH: For me, just looking at the family member value set is that it's a value set, not an ontology. So what I think we set out and you can correct me is that it is to have an ontology with relationships so that we can do that reasoning across it. And that's not what the family value set does. And value sets in FHIR, necessarily part of the FHIR standard because they point to codes from other code systems. You can specify you have a value set which contains codes from SNOMED. I think we didn't find anything that met that requirement of reasoning across. We did have a demonstration with that, from Alejandro? Yeah. I think that's a really strong argument. OB: Thank you for bringing that up David. I think the value set is a taxonomy but not so so terms in it have parents and they can have multiple parents. The thing that I found is that it is quite Euro centric, in or at least Anglo, Anglo in its structuring rather than semantic in its structuring. And so for instance, there's a term for aunt and a term for uncle and not one for what that relationship regardless of sex, because English doesn't have a common word for it. And so it's not in the value set. Yeah, from any conceptual model, and you would have a term there.

DH: And I think that's a strong point too, but we have to be careful how we make it, because we could always have asked or written an extension to the family data set to add more codes or put in a request to HL seven to add more codes. Semantically it didn't give us what we needed. And so an example is the aunt and uncle, gender, those lack of relationship so you know what I mean? You should probably point out, Lindsay that, and I don't know how you do this, but, you know, Grant and Alejandro, or Grant for sure, were involved in developing this system.

LS: what about the implementation guide itself versus the family member resource? I mean, I think it might be a similar argument.

OB: Yeah, the critical reason around the family member history is it's all siloed in the context of a proband and like the entire use case for family member history in the context of this is that it's siloed. There, if we're talking about the family member history genetics profile. flashing back to what were the rationales there. Meen is that more top of mind for you? In terms of the reason for some of the gaps around the higher family member history genetics profile,

AS: Are you talking about the fact that if we wanted to do a genetic analysis, we would say the first person identified to have a variant might be a pro band? I think it's that's one of the fundamental limitations of the family member history like a family member history, pro, resource and the way that they behave in the context of fire is that they're reported. They're basically rows in a family member history statement from a person.

OB: and that makes sense but it is also restricted always in the scope of a single patient and their family member history. Yep, it also does not allow you to recenter or basically to do extended relationships. It's always radiating out from one person.

*The transcript below is voice to text and is unedited. Some of the discussions may not have translated perfectly.*

It comes back to what this is set up to be in health in the in the clinical versus what we're doing in research.

This is set out to be if you have a person, what is their family history, and then you have two people who are related. That's a separate question. In terms of genetics, as I said, right from the beginning, the only way to do it properly is to collect a proper pedigree. And then you can change who the proband is, or decide what the ascertainment criteria were. But you were the ones who pulled me up right in the beginning to say the purpose of this was only family history. So I think it's fine. Yeah,

absolutely. And so Thanks, Amanda. And I think I'll, oh,

you can quote me as being a person who was dissatisfied and had to be re satisfied what the purpose of this code was for. For the one in 100 time I join these calls.

Every time you join, it's perfect. So So that's for the so I think that is also true of the family member history genetics profile. That genetics profile allows you to, if I can try to explain my understanding of it in, in non technical languages, with with a family member history, resource, it's all radiating out from one person. And so the farther away you go, the more you lose words to describe the relationship. Like just like as if you were describing relatives of a person. The family member history genetics resource allows you to kind of recenter and describe relationships relative to other people within that family which is great because it allows you to get a larger, it allows you to collect a larger family history for one person. What it again does not allow you to do is to have a joint pedigree for a family

that maybe you should just just use those terms family history and pedigree because that's really the difference family it is, is a description in words. Yes. Whereas a pedigree is describing the relationship of each member relative to the people around them, because every person has a mother and father. And in fact, if you don't have a mother and father at the top of the pedigree, even if they're not provided to you pedigree analysis doesn't work. You have to make a mother and father you know how often a person will pitch on their own. And they and they will describe them. Well, I don't know if you know that. But we have this problem where we have to add people into false people into pedigree provided for us through analysis to work because everyone has to have a mother and a father with an ID. I.

Think the distinction between family history and pedigree as words is a very important. Thank you for nailing that down as a clear, clear point and we need to drive that home front and center beginning

well as long as you can start working on a real pedigree standard. Maybe that's the problem is that the term is called pedigree standard, not family history standard.

Sorry, I've just worked it up myself because when I came in here, I thought you mean pedigree,

right from the beginning, and I was getting well it's not good enough for me, because I talked about pedigrees. And I think what

we've ended up what we tried to end up with is something that can robustly be used to describe a pedigree, pedigree pedigree, but also in the context of fire or in the context of you know, packet, but also can be used to represent that family to to take the existing family history. Data and get it into that format.

So maybe that maybe the thing to say is remind people that this is if you want to stick with the word pedigree, because I think we'll probably be too late to change it. Now the family history standard is that it's version one and didn't we always say that it would be extended? The plan would be that we would extend it.

Yeah, I mean, I think every GA4GH version one typically is intended to be you know, the minimum viable product, right and then it can be built on to version two, version three, whatever from

and I think and I think it's fair to say my knowledge of what gets collected in the clinical setting, even for me where I demand that a pedigree is the perfect thing a real pedigree, not a family history report, by the way. Is that's how it's given. It's written as aren't affected, age 30, blah, blah, blah. And the other thing about a pedigree and that's an important thing is people only for family history. They generally only tell you about the affected. Family members are first and second degree. They might talk about the kids who are unaffected because they the people at risk, but it's not a full pedigree. It is just what people remember to tell you. And that's important because if for us if you're trying to see the veteran really is causal, if they've got 10 females, we've all reached 60. And they don't have breast cancer and they carry the variant that tells us something that they may not be in the family history report.

So I'm just watching the time to I want to make sure we have time to go through through all the comments we have. Are we happy with kind of at least the direction of response I think we want to give here and what we need to explain with regards to you know why we developed the new implementation guide and why we have the new ontology.

Yep, I think there's enough there. I think to some extent, we have to show that we've really thought about it not just we've done it

without Exactly, exactly, yeah. And this what I've written here doesn't have to be our response. These are just me scribbling notes. Of course, we can obviously make it much more comprehensive. Okay, so let's keep on rolling down here. So the next one was about the direction of relationships. So I'm wondering if the minimum standard form is sufficient to represent a pedigree, excuse me. I would like to think that the condition five and I wasn't sure what that was, but is not able to uniquely draw a pedigree with the kin ontology used. So comment more extensively about what the minimum standard is for. Any thoughts reactions to that one?

We need to know what condition five is.

Yeah, I wasn't sure what that was either.

So that one of the examples, it's under direction of relationships. There's a little bit of a note about some concept of minimum standard form. So what the basic gist here is that and this gets a little bit towards what you were I mean, what we were just talking about, it looks like there was a bit of a difference between restructured text and marked down. So it all got collapsed onto one line. Sorry about that. Um, the the way that we've set up this standard is pedigree slash family history standard is such that it can represent a family history, and but in a computable way that allows you to resolve it into a pedigree and can also describe a pedigree computationally in the context of because we're describing it as a graph, structure with nodes and edges that are directed edges that are relationships between people that say, this is this person is the mother of this person. There is a unique ID a unique sort of fully fleshed out representation in which every possible relationship between every pair of people is, is is shown as an edge or is communicated as an edge but that's an awful lot and not necessary. Because one person being someone's mother implies that the other is the first one's child. So we only needed to choose one of those two, and the other is logically implied. And so there's a notion that you could have a set of rules that would, you know, guide people towards sort of defining what the minimum standard is here kind of what the minimum amount of information that they need to have to have it be a connected, connected tree or connected structure is connected graph. In this context, there is still I would say, not a unique minimum form. I don't know whether or not that's a problem. I don't think of it as a problem. It would be a problem if we wanted to hash that structure in order to generate a unique ID or something like that, like happens in verse but I don't know if that's a problem in our case. That  is a structural problem, like it would it would require a structural change to fix it. In other words, to make it so that there was only a single unique solution and the reason is because of relationships at the same level. So in particular siblings, twins, partners, partners are like, which of the two partners do you put the relation the edge from or two? And because right now, all of those edges are directed you have to choose one. So unless we added to the structure undirected edges, then partnerships are there's always an you there's not a unique option. Sorry if this is way too technical for folks.

But I understand it because I learn every time I come on this call so you talking about say, if it says subs child has cancer age, whatever which said, because the subs Oh no,

it's more like if we say this person is if we say person one is the partner of person two. We could have equally said person two is the partner of person one, but we probably don't specify both. So both of them.

Yeah, well, but if everything's in relation to the program, then surely that's, that's okay. Because then if the proband is the pro band and they are person one, by definition I mean, that's not what we do. We call someone a probe and they have a one next to them. And so everything that would be the probands partner, the probands child, we don't even call about Person Number Two's child. It's all probands child. If they have two relationships, then it would then then you would have to show try and say that it was with you know, marriage one on marriage to I don't know how you the hell you

were. So So I think so. So then An example would be, let's say the proband has some siblings. And let's say those siblings, they're twins. They're a couple of a couple of twins. In the current way that this is structured, it's a graph model. So it's the twin is not a property of the person. It's that it's the relationship that those are huge twins have to each other. And there is an ambiguity about which twin has the relationship to which one, where do you define that in the way that it's structured right now? If it were important, important, and like, the basic answer is that it wasn't. I don't think we thought of it necessarily, or we didn't in terms of the implementation. I don't think have a hard requirement that there be a single unique representation of a given pedigree. If that is the case, then we should make some structural changes to support that, in particular in terms of in terms of relationships, that our

view ambiguous, ambiguous, yeah,

or or collective. Sorry. I don't think it's not symmetric.

I guess it comes back to back to the fact that this is called a pedigree standard and that if the idea was that the family history should be sufficient to make a mini pedigree, either you need to say, make those changes so that you really could be maybe not 100% Sure, but 99% sure you've got the pedigree, right. Or you have to just say this is deficiency.

I think this one, I hear what you're saying. Amanda, I think this is that's part of almost validating, pedigree representation and saying like, turn this into a pedophile or something right like you and we could do that. The what what I think this is getting at is if you take a given pedigree, you can represent it in this pedigree standard in a few equivalent ways. Yeah. And that's where they're saying like, I'm wondering if the minimum standard form is sufficient to represent a pedigree uniquely, and the answer is it isn't. It's enough to represent it more compactly but it

doesn't matter if the information that you would draw from nope, it doesn't it like that's definitely comment to me.

So so as long as we're not saying that it is required to be and then there's the question of what is why even talk about a minimum standard? And so maybe the or a minimum forum and so the answer might be we just removed that, because it's confusing the issue. I think I added it in because I felt like there was it might be useful for some guidance there for tools who are implementing this. Um, I'm in terms of saying well how of the many different ways that they might represent a pedigree using this structure, how to do that, but maybe it's just confusing the the issue.

Yeah, and I guess the only the only the only con of that is that if two people have the same pedigree, by chance and the same bloody program they'd have to have as well. It could look like two different pets like if you matched it on the basis of the family history report. It could look different ways it was the same.

It could look different in terms of the actual

the word, describe it.

Yes, there are lots of different equivalent family histories. And that's the problem. Like or that's the complexity here, right that you be honest

I think that's a minor problem compared to just knowing that it's the same one because you're more likely to have two different probands from two different centers representing the same family. That's that's a, that's a bigger problem that you will not solve in this FH. You'd have to have a pedigree to do that.

And even with the pedigree, you still need identifiers or

we are more Yeah, we did ourselves support

name, you know, enough enough demographic information in order to know

this old variant type. You know, that's what we use. Yeah.

Okay, so I'm just starting to color code some of these comments because they're very overlapping, because I was just looking down here on this one. Yeah, given the lack of unique tools will struggle implementing the standard in the same way. How do you envision that happening, which I think is very much related to what we're talking about now?

Okay, copies are there.

So there's roughly six to 10 plus we have about 11. Through the public comment, although I've realized this one here is the same as one of the ones the PRC gave us. So there are some overlapping pieces here. Which will hopefully make it a little bit easier.. So okay, let me have time we got left about 15 minutes. So do Sorry, I don't know if I captured it. correctly. But are we going to be removing this minimum form from the documentation? Did we come to an agreement on that? And does it sufficiently answered this one as well about implementation?

It's a minimum, it's a smaller form. It's a form that says, you don't need to include all directions of all relationships. You don't need to say that person one is the mother of person two and person two is the child of person one, what is

the term you would use to describe it? If it's not going to be a minimum standard? It's like, you know, it's a reduced form..

It's recommendations for a reduced form is really what it is and we can decide whether or not but the reality is from an implementation perspective, you're not going to want to include the full graph of relationships that doesn't make sense. You're going to want to basically have a pedigree, like what you're saying, Amanda, you're going to want parent child relationships, right? Like you're just that's and the intent of that section was to say basically Hey, you know, when communicating, if you're communicating a pedigree rather than a family history, you should probably communicate it as parent child relationships, if you can reduce it into that for him. That's that's all that section says. But they can because our use cases included family history use cases like risk, cancer risk assessments that are not based on the pedigree but are based on knowing that the proband has an aunt some aunt who tested positive for BRCA that that needs to be representable that was the notion okay.

So again, this is mostly a documentation clarification. Again, I think

this is documentation verification, if we're okay with it not being unique, which unless someone else has something to say about that, like adding that as a constraint will involve, I would say considerable changes at this point. If that's a requirement, then we would want to make a whole bunch of changes, but it doesn't sound like they're asking for that to be a requirement. It just sounds like they're asking for guidance given that and so we can provide that. Okay, um, it's just about adding a little bit to the tooling. To help with reducing that form maybe. Or,

okay. All right, we have a 10 minutes left. So really, briefly to go through some of these last ones here.. And so this one, number six here, actually talked about with the PRC for a little bit, because the suggestion was to adopt kin as part of the standard and CO evolve. I think what was happening was, because kin is in its own separate repo, they saw it as like a separate standard or a separate thing. But I think this is mostly resolved because I just kind of explained like, we do intend, it's part of the pedigree ecosystem, and it's kind of a piece of our standard. So I mean, correct me if I'm wrong, but I think it would co evolve and it's something we would maintain as part of the standard. So I think that was resolved. There's nothing we need to do there. So continuing with the ontology, so this one augusto provided a list of some of the enumerations they have used. So this gets back to the uniqueness point again. So and I think also some of the earlier points about why the ontology and not the the code set. So quite complicated but they need to be specified to have uniqueness here as examples we use either add or abandon expectations of uniqueness and reflect. So I think we abandoned unique this based on our last discussion of Yeah, okay.

So I would say that, given this feedback, what we might want to do is update and expand the kin ontology with either terms that map to these, you know, add these as, let's say synonyms for additional terms that are logically defined in that space.

Yep, that makes sense. Okay, um, okay. Please provide hyperlinks to the terminologies used across the document. Where do we reference the terminologies if any. Because when I first read that I couldn't immediately

we referenced the kinship terminology, I'll be working with the pedigree model, oh, there. If there are other places, we also reference it for the actual property that it's defined under, which is the relation property under the relationship class.

Okay, hancestro. We did leave that one there.

Right, if there other Yeah. So usually, we're doing it in the classes for the property that it was scoped under, but it sounds like they would like it maybe at the top level.

Yeah, I think so. That's what I'm getting

at is provide hyperlinks to the terminologies used across the

whole document. So I'm thinking like, you know, if we look at the pedigree model page, we we say ancestor here and it's certainly do

Oh, yeah, we should probably the pedigree model page probably should be lightened and instead we should we, I thought I had a PR that did that. Um, what what triggers the rebuild of the the republication of the documentation, does that happen automatically,

ah, mean has to rebuild it right.

So, in order to set the automatic build, you should meet it you should add me as an administrator to the repo. So,

the action the pages build deployment action does not auto push to GitHub Pages.

No, so I have to rebuild by clicking a button because I did it that way because I am not an administrator of the repo so I don't have the access to the web hook.

Okay, I can probably do that right now.

Yeah, great. If we could just set it up as an action so that then we can make sure that nothing is

then I can change the activity, so that whatever we merged into master, then we will be rebuilt. Right? Okay. Okay.

Yeah, I will. I'll make an action for myself to add you as a as an admin.

Yeah, sounds good. Okay. And I think yeah, we should just replace on the pedigree model page. Basically just replace things with a definition of that concept, and none of the information about the individual and instead just point to the classes. So you have to now that the I think we have stuff a little out of sync in two places, so we don't need it written classes is a better representation. Than

Yeah, which I think gets out this next comment pedigree model does not agree with classes,

right? Yeah, yeah, I think

okay, um, so classes I'm struggling with how to link to affected status, particularly for more complicated situations, such as potentially incomplete penetrance. CO segregating conditions affected is zero to one and there is not a disease description class, you clarify. Take us back to the classes page here.

Yeah, so we only have in terms of effected we only can do a single condition that's sort of built in everything else would be expected to be done under fino packet or fire, because

I don't understand how you can how you can represent incomplete penetrance someone's either affected at the time you see them or not the only way to do that would be to build in an age related thing. Because the only way you can see that someone something's you know, there are two things you need to have. If you're talking about penetrance the relationship is to the age at presentation and the genotype.

So, I think what, what the comment is getting at, if I can is that they looked at the model and they see from the explicit part of the model that only a single condition can be defined when what they care about is the fact that there are multiple conditions going on in this family at once. And maybe multiple feature clinical, you know, phenotypic features or clinical signs that they want to track across the family at once. And that individuals might be affected or not for any one of those things

that I can get, but I don't understand how you can how you can ever capture potentially incomplete penetrance without knowing a genotype for the disease and the age of presentation. I think this is really coming at it from a you know, like, it sounds like this person's coming in from a rare disease model,

a rare disease model perspective where they're looking at having features HPO terms across multiple individuals

and they expect that person to be have a nasty disease and they don't and they're surprised by it. We are never surprised by incomplete penetrance that's what we deal with. You know, if you have a 50 to 80% risk, only half of the people are going to get the disease. Right. That's not complete penetrance

but they're thinking about in terms of certain signs or symptoms potentially manifesting and some individuals Yeah, this is the quick answer to this is that descriptive power that Augusto is looking for is when the standard is used in the context of FHIR or phenopackets.

Yes, I agree. Yeah. Basically, you need to have multiple conditions

Exactly. Which, which both fire and fino packet have natively and we just we don't we didn't do it in this because we wanted to keep it as bare bones as possible and that supported by the carrying standards. We only included one in order to make sure that we were covering basically a peds sort of standalone use case.

So that would be an extension of this where you allow for more than one phenotype and it could be more than one phenotype related to the genetic condition, actually. And it could be more of more than one phenotype. unrelated to that genetic, so you could have two diseases one was explained by the genetic variant and another that's not or you could have a range of presentations for that genotype, like polyposis. And cancer, for instance, is a good example. If you have an APC variant, you have the precondition and the condition that's a I would call that

there's not a disease description plus so well. Could be so isn't that what Bing was saying? Is that you you describe your disease in a different way. And then you decide on what's not one later. Maybe? Almost because what's not in one will change over time as you get more information about the gene disease relationships.

I think it's that we didn't say what terminology we give no pointers in terms of the terminology that a disease would be recorded. To the extent that we even allow recording that which is slightly, you know, at the edge, I would say of the scope of what we've been doing because that's supported by feedback and

fire. Yeah, so it all comes back to you know what people see this as the term minimum standard implies that it will carry on working in the future you can add on to it and if not one right now. doesn't do it. What you need to have is a normal one. And then allow for a column that says what the disease description classes

and how much are we focused on I mean, the unique challenge that we're in is if we're not a separate standard, really like we are but it's both fina packet and fire are I would say very much at the edge have a format and into a modeling language. And so they're both very, very happy to expand. You know, sort of as as the need and use cases arise. So unclear whether or not that's

Yeah, but I think I think at the moment if this person's right that if you're saying node one, you're not actually aligned for node 12345. For different for different disease descriptions, and less you, you make it clear that node one is just the way let's go back to the word minimum. And you'll have another column that allows you to fill in different versions of one. They're wanting this to be more than more, more electable

even exactly, they're wanting us to include capabilities into it directly that are that are supported by fina packet

fire. And how would you do that? Why Why would we do that? Because at the moment, it would not be this person is saying it wouldn't meet. What is the minimum standard?

That's because they don't understand they're not seeing it in the context of pheno packet or fire?

Yeah, they're seeing it as a standalone,

I think. Exactly. And very much doesn't support what they're looking for. As

I just I guess I'm trying to say is a right now, I wouldn't know how you would link that to Phenopckets where there will be multiple conditions when you've only got an alternate one.

Okay, then it sounds like we could improve our comp are documentation so that that's really clear to to initially you Amanda, not clear to you that you know, our, our PRC doesn't stand a chance.

So cool. I do see we're at time here. Does anyone have like five minutes to stay on and we'll quickly burn through these last? I think there's mostly two or three. I just wanted to quickly check with you guys. Sure. Okay, let's go really quick. So, I want to talk about this one because it came up in the PRC. And through public comment as well. So the question of differentiating between sex at birth carrier topic, sex and gender. So right now our model includes gender and sex at birth, but not carrier topic sets. And through the public comment. Someone had provided an example where they have for example, sex reversal cases where the phenotypic sex was different from the XY karyotype. And so they explain how an adjustment of wording to account for molecular sex or carrier type or adding they said adding a field like gender I did respond saying we do have a gender field. And then, so right now they're adjusting sex in the pedophile to resolve XY karyotype mismatch warning. So my take on this is, I think from both of these comments is maybe we should think about adding a carrier topic sex feels like an optional one if that's possible. I don't know what it was the reactions to that.

Lindy Let me chime in. Okay, I know we should decouple our pedigree tender from fire but in terms of Fire, fire actually, highly recommends to represent karyotype effects in observation as an observation because that requires clinical observation for sure. So if we include coyote presets in our individual profile then there are some sad when someone submits the pedigree information that one should know the carrier to pick sacks which will not be required of course, in our class, but I will say it is not very likely for data submitted centimeters to submit carrier to pick sacks on their own. So I am not very down for the adding chaotropic sec store profiles class.

So I wonder if those because I'm pretty sure. So fire can represent it as an observation, I think helps to double check. I think Phenopckets you can represent carrier to big sex directly represent a yes, yeah. So I don't know. Do we just say this, depending on your implementation context. represent those things,

and we just give them guidance on it. Yeah, and

actually, if I remember correctly, including the inclusion okay with typic sets was version one. Because I remember show him the version two revamping and then they actually made it as an observation, not as a part of individual like a person.

Okay. So so it sounds like what we need to provide here is the guidance implementation guide guidance or at least like documentation, guidance about the fact that we're not really helping, let's say around the interoperability then of it. We're just saying well, we're saying if you have this information, here's how you should represent it in fire and here's how you should represent it, you know, packet and then maybe it's on us in terms of the tooling to make sure that those are interoperable? Yeah, maybe the reality though, is that and okay, I can keep talking about this at length, but we're over time so carry on, Lindsay.

Okay, we can continue on this further. No worries. Okay, so there was a one here. I've assigned this to myself to connect with REWSt, this but you're just kind of a inquiry about for race, ethnicity, ancestry, we're still using the term race. So they suggested just checking with rules about any best practices here so I can do that. And they might have some some guidance for us.

Yeah, we weren't sure about whether to split them out or only use ancestry because that's the most relevant one, even though existing data is going to be from all three categories. Yeah.

So I can I'll ask them about that. The next one is just consider how the tools we expect that they evolve with the standard. Oops, I put that in the wrong one. And I put Yes, we do. So they can until it we've already answered this one. This is a related question to kind of that race, ethnicity ancestry one, and there's just a, there's a general conversation on the PRC about, you know, are we representing some of these things as best as we can in terms of gender? Some of this I think, went a little bit off track. In the sense that one of the PRC members thought that this standard would have a role in the actual like drawing of pedigrees and how you might represent, say, certain gender transgender, for example, in a pedigree, which we that's not that's out of our scope. So I included this year anyway, just to say just for us to maybe think about if there's, you know, any way we could improve or provide guidance on some of these things, we could think about putting that into the documentation. So that's that and then lastly, there was just the public comments this last one we've already addressed. This one here, I put a suggestion, and there was a group from Yeah, from Argentina, that just kind of they weren't techy people in terms of software devs. And so we're having trouble trying to understand aspects of the documentation. So I thought, you know, if there's a way we could think about adding some sort of more laid description, or even a thing that says this is geared towards mostly software developers who are implementing that just might help some of the confusion people are having there. Then we have a whole bunch of great comments that Chris had caught about our ontology. So subtle issues, like the direction is reversed, or you might need to distinguish things better. I've linked to all of the GitHub issues he raised about them where he describes these in a little more detail. So I think what we can do here is, is maybe comment rate on those threads rather than going through this spreadsheet. And then lastly, there was the one question comment here from Tony. With regards to the again this Do we want a standalone or this conceptual version that we've created? And so I just copied his sort of comment here thinking that we need we need both we need a standalone in addition to the conceptual that we have, but in my opinion, you know, I guess Yeah, something to think about if we decide we want to do something standalone and correct me if I'm wrong, I don't think they're mutually exclusive. Right? We could create a series usually, if we wanted to. So yeah,

the nasty detail is that we may end up having done so implicitly, in order to actually have the tooling fully convert between, you know, packet and fire, you have to have a common way to move them between them. So you may end up with it. But it's about whether or not we want to publicize and standardize that

or not. Yeah, okay. Something to think about. Anyway, we are way off time and I want to be respectful of everyone's everyone's time. So I'll open the floor quickly. Any last comments, thoughts about all of this? What I can do after this call is start to organize some of our responses here maybe even get some up on up as issues. I can start tagging people where, you know, we need attention on things. We can start working through these in terms of the timeline for resolving some of these comments. So the next PRC meeting isn't until the end of August, I think it's August 28. So there's quite a couple of weeks here. However, I think the sooner if we could set a priority particularly to just some of this description. I think that would be good. We can get that back to the PRC sooner. And I think that will then help with working through the resolution of some of these other comments as well if they have that additional context.

So, about Angela Solanas comments. I know Angela. Oh, yeah. And so I think even for someone like me, I struggled to understand what the purpose of this was. And so if you want to write something for Angela, and I can understand it might be good, right. And if you go back to the version two comments for the PRC it's it's almost like you need that general introduction. The same lay speak would actually be the thing that you would include it the introduction as to what, what, what the purpose of this model was be and how and also some future proofing like it. The point is that it will interact with Phenopckets To do this, or it will interact with whatever

what's the best way to get feedback on these things. So one of the things that I'm so I don't know, I mean, like, can we have a staging site where the the changes to the readme like we can merge them in to a dev version, or is it should we be doing this in Google Docs or something so that humans can read it before it goes off on the dev side? I'm just trying to think about what's the right way. Lindsay? Have you? What have you seen in other working groups where the documentation is in GitHub, but you want feedback from non technical people? Their markdown, because then you can just pre pretty preview. Yeah, we're in restructured text land with read the docs. And so you can

Yeah, I mean, I've seen it in both ways. We have had some GA4GH public comments where the documentation is in GitHub. And what we've done is provided like pictures and comments of how someone could add comments and error create issues. I think for simplicity's sake, we could just do this in a Google doc because everyone knows how to do it, and we wouldn't have to kind of write an explainer. And that's typically much more easier to share doesn't require someone to sign up for GitHub if they want to get into the stuff. So I think it'd be easier if we just did a google doc okay. There are some groups that do that have used, like docs or some version like that, for these sorts of things.

So then once we're happy with it, then we can copy we can throw it

into the docs. Yeah, yeah. Cool. That's fine. Let's do that. Thanks. Perfect. Do you want me to like guess, copy everything we have in the read the docs into a Google doc first or it's not

too much. It's not too much to ask Lindsey. No, no, not, not at all. Anything at least that we're going to need to change? Yeah.

Yeah. And I can do that. Thank you. Yeah, I can definitely do that. Perfect. Okay, um, so I guess one last question for everyone. Do we want to check in again, in like, two weeks or so because I think their meeting is on.

It'd be good to have make sure we can get granted the next meeting. I think it's the only thing I'd say about that. Right? Yeah. Two weeks is fine. Be good. If Grant was there?

Okay. Yeah, they're the next PRC is on the 26th.

2022-06-23: Pedigree Subgroup

Chair: Orion Buske, Grant Wood

Attendees “Name (Project Affiliation)”: Melissa Cook (NCI), Meen Chul Kim (KF/CHOP), Alex Tsai (GA4GH), Chen Chen (GA4GH), Moni Munoz-Torres (Monarch)

Minutes:

AT: So you mentioned that it was the terminology that was updated. I remember it was like two weeks ago or something like that. And there were there were a lot of lines that got updated so I wasn't too sure what mattered or if I was supposed to manually map out everything ontology.js

OB: I think what's going on here is that the code in it, it has a map for just convenience purposes. Right? It's just so that then we can refer in the code to terms like you can say is biological mother in the actual code rather than having to say like KIN 27. And so I think the way it was implemented originally is that it throws an error if one isn't there. But I think that's kind of just optional. In reality, I think we could just only list the ones that are actually used by the converter tooling, which I think is just those two at this point right now in terms of the structure because it's all just dealing with direct family trees. So I have a commit I can either push it or I can turn it into a branch and I can push that even right now which gets rid of that error. If that wouldn be helpful.

AT: Yeah, as a branch, it would be good. And there is this other issue where the tool itself wasn't storing, like every single thing. If you were to import a Boadicea, do you prefer to have those Boadicea inputs stored in the properties?

OB: It's a great question. It is one that I think is the tip of the iceberg for the conversation that we should probably have today. If that's okay, can I build on your question and then loop in everyone else on the call to try to get this feedback for that?

So the basic challenge we're running into is in a few different flavors all right here. I think this is a critical question for the people on the call, which is the pedigree standard as we have it is a conceptual model, and it is distilled down to only those kinds of those pieces that are the most essential. And we haven't even really structured those pieces, but instead have provided guidance for now what that looks like when implemented within a phenopacket model or within a FHIR model. And then there's sort of those that are connected into all of the different data that can be collected there. One of the challenges that we've run into is maybe lack of consistency between all of those and in terms of that standard conceptual model. We can't have full alignment between the property names in the document. And so because we've gone down the route of not having a separate, actual standard that you can actually put actual data into. Instead you have FHIR and what it looks like in FHIR for a Phenopacket, what it looks like in your packet, you can put data into one of those two things. I think we're running into some meshing difficulties. And those are coming to bear I guess with the TrakGene implementation, which was right now, I think based on some of the early documentation that we've had for what it would look like if there were a separate standard.

If we're truly going to implement a converter to link , the question for the inverter to link basically is if we want to use risk models. If we want to run a risk model, a risk model depends on it an awful lot more than what's at the core of the conceptual model. It requires some of this richer data that we're leaning on phenopackets, or we're leaning on FHIR for, like cancer diagnosis. We haven't given any specification for the structure in which a cancer diagnosis details would be specified. But that is implemented in one way and in a packet that's implemented in a different way and FHIR and in theory that can be gathered from either of those two models. Our question then, I guess the question for us now is in terms of the converter tooling, to talk specifically about Alex's situation, or for someone else who's coming in and trying to implement this standard. How far into those weeds do we want? Now it’s not just the Pedigree standard, but also into FHIR land and other fields.

MC: Is there a framework you’re working with? Guidelines on number of transformations? Be crisp about the scope and also minimize scope.

OB: Tried to minimize this by talking about data elements in a theoretical sense and leaving the specific implementations up to the user. Where those disagree is where there is friction.

MC: Even just being clear about the content specification definition before you get a string, middle ground between the implementation and then there is the instantiation of it in someone’s system. Where those systems don’t align, there needs to be some acknowledgement. Where does this end and Phenopackets pick up, same with FHIR.

OB: Led us down to the path that we're on and where we're at in it, I guess which is where we're saying, this is a statement of data elements. Here is a specification for or here's a description of what that looks like. Here's an implementation that meets certain criteria, perhaps within these two different standards. But, then the question is, how deep into the interoperability then do we go? Which is sort of related to what Alex is ultimately asking because right now there are a whole bunch of things that is part of like supporting a certain amount of pedigree interoperability would make sense to have be there in the tooling, but then that should be there in that data model, too.

OB: Even if we ignore BODICEA, the tooling will allow you to convert with Phenopackets and FHIR. So much overlap with all of these things.

MC: Why have two, why not align them.

MMT: Trying to come into things that help us integrate more. If, because we're doing this off representing the pedigree inside of the phenopacket, then the fact that there exists an implementation guide for the Phenopackets itself, are the people who worked on that implementation guide able to incorporate the element of the pedigree in that so that there doesn't need to be an additional transformation.

OB: The things leveraged in those two systems are very different. Physical structure looks different in these two worlds. Can convert them, but where it gets hard - looking at the common dataset, we have elements that include rich data models. Unbounded if we want to include all of these.

MC: It sounds like there’s overlap but different for those use case. Think about when those wrappers are different. Containers are still holding a core of the same information even though some of the other bits around need to be different.

GW: When Melissa said we need to unify everything, in my mind, I thought our goal was to create a unified standard that everyone would follow and that standard needs to be somewhat universal. Pick and choose what they need to do for their use case. Whatever people read that we publish, it should argue for what exactly that solution is. Should be clear that it is our universally recommended standard. Are we getting to that goal.

OB: I felt like the goal would be - here are the data elements we think are important, here is what is or isn't support in ped or FHIR, and here is a much richer set of things that are supported if you use the GA4GH Pedigree. In other words, I didn’t think we were trying to use 1.

MC: Confusing as an end user, which to use. Too many choices and too many paths doesn’t help the community come together.

MMT: I wonder if one of the thoughts that led to this point - what each of those platforms allow you to do? When you are thinking about conducting, just exchanging information about a pedigree, you can think about a FHIR server allowing you to exchange that and maybe that's how that conclusion was reached. It would be good to represent it in a FHIR format so that it can be utilized and exchanged. But when you're thinking about conducting analysis over the information, then we're not talking about FHIR because FHIR is not going to allow you to do that. If you are thinking about the analytics that you can do by utilizing the information about your pedigree would have to be done in a different environment, which is I believe what all of this documentation that you've produced about what ped can and cannot do and how feedback and support in a more robust representation of the pedigree is also allowing you for that part of the of the empowering the analytics. I don't know how we arrive at the fork. But I wonder if those are some of the thoughts that led to people believing that this was an option to be at this work and to have both options. And then if you choose to represent both of them, then I think if there's a case to be noted for the user - if this is about exchanging information, here it is, if this is about analytics, over the pedigree, here it is.

MC: Brilliant to clarify it for these different use cases because collecting and exchanging data is one type of use case and then taking that collected stored data and analyzing it as a different use case.

GW: Right, FHIR is just to transmit one to another. But can transmit to an analytics tool that can read a FHIR format. So if your data in FHIR, it doesn’t preclude you from using an analytics tools.

MC: Clarifying each one of those things is whats needed here.

OB: Real world feedback on the lack of direction, and we haven’t made the data more directly interoperable. We gave a structure to it, but not really connecting the ecosystems.

What’s next?

MC: Be explicit and document, which hopefully shouldn’t be a huge lift.

OB: Clarity is not quite there in terms of implementations. Question is, can we wrap this up with a bow. How to resolve the FHIR Phenopacket friction.

MC: Document the friction points to help get them resolved. What to accomplish now and get on the roadmap for later.

GW: Do have the phenopackets column added to the common dataset column, is that helpful?

OB: want to make sure we’re clear to implementers what they want to do, last things I want is to make a problem worse or have it not be used. Need to tighten this up.

GW: Still go forward, helpful to get the feedback and fresh eyes.

MC: Public review will be a great way to hone this deliverable.

OB: Back to Alex’s question - yes, the internal model needs to support those things for the common dataset document. Your placeholders are probably good enough. What we can say is even import from PED for Bodicea into a common model, you can then take that and export into ped, Bodicea or others out of that common model, and as long as that kind of common model is compliant, which might require a few tweaks here or there based on some of the changes recently, then we should be good.

2022-06-09: Pedigree Subgroup

Chair: Orion Buske, Grant Wood

Attendees “Name (Project Affiliation)”:  Bing Feng, David Hansen, Meen Chul Kim

Minutes:

Decision on meeting scheduling during PRC process:

Keep the upcoming 23rd meeting just in case we need a last minute check in, cancel the rest. We can schedule meetings during the PRC process ad hoc.

[From Otter.Ai]

LS: First, what we could do is just go through all of these actions. Some of these can actually be crossed off, which is great. And then I've got some questions on the documentation to go through and then if anyone else has something they'd like to chat about, feel free to jump in. So starting up first, Meen had an action to create a PR for the outstanding changes for the classes section. He has done that today. So I'm going to cross that one off but the issue is not yet merged. Orion - Meen has tagged us both as reviewers on this. We can come back to this once he's here. Next, maternal/paternal terms being added. That's done. And then Orion today you had updated to move those classes into properties, correct?

OB: Yep. There are a few oddities, sort of the way that it's set up right now. There are a few more things that we might want to do as part of this first version, but that was just digging into the sort of current state of that when merging those in but yes, that part is probably done now.

LS: Is that something we'll want to come back to in this call like ontology tasks?

OB: Maybe if there's time it's not a high priority.

LS: Orion reviewing track genes JSON export?

OB: So I followed up with Tim, I might have been too long to follow up with him, I did follow up with him again today.

LS: Okay, sounds good. Some tasks that were in the approval Docs. So this mostly has to do with the implementation details. So David, I saw you had had other David add in some details. That is fantastic. Thank you for that. And then Orion you've got the not yet fully implemented details in. I did reach out to Tim, I'll have to follow up with him as well. Meen, we can ask him again when he gets here, but I know he said he was re formatting. Jules, I'll need to follow up with again. I did briefly talk to Soichi this week at an ISO meeting. He's seen my email and he says he'll get back to me as soon as he can. Bing’s implementation is currently blocked by the tech team. One thing I did want to note there is this new section here called interoperability notes. It hasn't been in past versions when I've taken products through. And so I was looking at the Beacon documentation to see how they filled it in and they talked about a validator tool that they had put together and they run centrally. So I figured we could use this as a place to share, for example, some detail on the ontology and our validator tool, unless you think there's something else we should be doing here.

OB: It seems like this would be a situation where we would want to demonstrate a producer consumer case, validated on fire, and on Phenopackets like looking at it from sort of a high level as I think what's the project we're trying to achieve here? That would be what I would think would be kind of a minimum that we would want to have going into the approval process. Okay. Yeah. That would be kind of ideal, unless we want to, I mean, we can tie the tooling in either the validator or the converter tooling into it as part of that story in order to weave a little bit more in terms of connections. But ideally, it would be communication between more than direct pairs.

OB: Are we able to consider doing ingestion from one source? Might be able to demonstrate Meen’s that way. The other ways would be between either a pair of different or sets of different pedigree tools. So like, if we were to take a pedigree from the REDCap plugin, and show that, you know, you can serialize it and pull it into a different pedigree tool, whether it's tracking or phenotypes is something that would be compelling for the team, the other any other pairs, or taking a pedigree, or pedigree data from any of the tools that can export it, and pulling it into, like exomiser, or for the or being coseg analysis tool like from I feel like that that would be the most compelling if we can, I don't know how close to that we can get in this timeframe, but that would be ideal.

LS: I know we kind of touched on some of this with the implementation demo we had done while ago. Right? So I did link in the slides, but we might have to fill out. Maybe what I could do is find the old recording for this if it's still existing somewhere and even add some screenshots or something to help fill it out.

OB: I think I was supposed to update the example in the documentation to cover explicitly the phenopacket and the FHIR representation. And I don't think I've done that yet. So right now they're basically in a lightweight, just Yaml format we need to give people actual tangible JSON representation. I think we need to connect with Jules and if he can tell us what we should do in order to make that be part of phenopackets, either this or the next version or whatever.

LS: Yeah, okay, I will. I'll start a new email thread on it. So a bit of an update on our PRC. We have two or three members already confirmed, which is great. We are just waiting to hear back from Bob, I'll follow up with him.

I did ask Meen about being added as a product maintainer and he agreed. So that has now been added to the docs.  We added a GA4GH logo to the docks.

I added this action about the readme for myself today. So back in our repo, we have this readme page that was kind of our holder before the docs. What I might do is kind of shave some of this down and basically point it to the read the docs.

OB: Agreed. I think that readme should have very little for even just technical information. And then the link at the top right, where you configure the actual link for that is what people will go to, so we're good.

LS: Anything else task list wise that we want to talk about.

GW: I just wanted to confirm Orion when you felt like you were ready to go back to the the document and fill in the column where we have the GA4GH pedigree standard, fill in information for the new data elements that you're adding to the model

LS: You mean for the common data set?

GW: Yes, yeah.

OB: So Meen updated the classes to accommodate the common dataset document [lost connection]

I don't think anything needs to be updated in the documentation more is that wrong?

Meen is everything in this document now represented in the classes? Or is it just harmonized with it?

Are there rows in a table that are not supported? By the classes, the updated classes?

MCK: So I will say most all of them are reflected in the updated class documentation.

OB: That's awesome. Perfect. Because so I think that is the big improvement that I think we were hoping for. So I don't think we need, I mean, we can discuss whether or not we need a column here to represent the specific property within the standard. It isn't clear to me that we do, grant if you feel otherwise then we could certainly add it. The piece that might be missing is having phenopacket as a column.

It's only for all of the stuff that is covered by things that are already there. Take gender as an example. This is already supported within fire. And this is also already supported within phenopacket and so it just needs to be the equivalent phenopacket of family.pedigree or is it .GA4GHpedigree.

GW: Let’s keep it simple at least in this first draft.

OB: Meen the question was just whether there are specific things that you would like for us to review in the issue.

MCK: Yeah, since the deadline is approaching, I guess we can do a very simple quick review and then merge because what I did was revamping the unclassified section against the common data set using the field name cardinality and simple description, so that's it.

LS: Okay, action on myself and Orion to do a quick review and then just merge this.

LS: I had some questions about the REWS security documentation. I took a first stab at filling this out for us over the past two weeks or so. There's a lot of questions in here about data use, you know, have we thought about security risks, what regulatory ethics concerns? A lot of my answers, I just kind of put, you know, we're a model so we don't store data. Uses are dependent on the implementer and their use case. So a lot of these answers are kind of along that theme. If anyone has time and can go through these answers, and make sure that I didn't say anything totally incorrect, please do.

There's a question here about listing any security standards, papers, threat model, attack papers or best practice documents specific to the domain of your product. Does anyone know off the top of your head? So I guess, maybe just as a bit of context, a lot of these apply to API's not models, so they don't apply to us. But I still kind of took a stab at filling some of this out anyway.

GW:  I haven't heard of an attack paper on a data model.

LS: We'll just say this one is not applicable. Second question lists the risks and threats that apply to your product.

OB: I think even that is inviting. I hear what you're saying. I think it's a great way of trying to give them something. A stronger statement and one that we can make here, where it's like it's the security risks of this are the exact same as the security risks of a text file.I think we could be similar to Phenopackets I would frame it as the information that we're representing is identifiable sensitive information. And therefore, like the way that people handle that information, they need to handle that information appropriately. And they need to treat data represented in this format, as though it is containing sensitive, identifiable patient information. It's a higher risk version of what phenopacket is doing because being a packet is designed to be de identified by nature. And ours has name and date of birth. We just need to build on it. And maybe tweak it so that it's less about privacy, per se and more like just the risk is people put data in this format, and then there is a leak or something like that around it. Are they mishandling.

LS: Okay, the questions following ask you to estimate like risk likelihood. And I really struggled with this one. Because, you know, it's asking us what is the skill level? Is it a good attacker, a medium attacker, I have no gauge.

GW: Attackers aren't relevant in this particular case,

OB: Accidental disclosure is the real risk.

LS: if  we feel the question doesn't apply to us, and we can't really answer it, that's okay. We can just kind of say that. You know, as you saw above, I had answered a lot of them being like, this doesn't really apply to us. And that's totally okay.

I think I'll have to rewrite this one now, but this kind of again, goes off the same theme.

This is one I had a little bit of a struggle with. So you know, what risks are there that uncertainty or misunderstanding of results could be exacerbated due to the product, have you referred to the return of results policy? And so I took a stab at kind of saying, you know, if the information contained in is fed directly back to a patient with any interpretation or counseling, then it's possible the patient could mistinterpret.

GW: Our model does not produce an interpretation or a risk assessment. implementers will do that. And so also here it says, Have you referred to the return results policy? We’re not in that field. We're not in the field of doing genomic research, where you have a study participant who you might have a return results.

The last section here is, this is a new section, it's on equity, diversity inclusion.

I added a brief blurb here. But I think this is actually no longer true because we can include race, ethnicity, ancestry now, right? Yeah. Okay, I need to update that.

So the question is, what assumptions about resource availability have been made in the product's design and development? So computing power students and technologies time and money? How are these weighed against competing concerns such as moving the field forward responding to cutting edge cutting edge use cases, etc?

GW: Well, that's actually an interesting question, but I'm not sure that that should be asked here. You know what I mean? I don't think it should be asked of our subgroup, it's a question that lives higher than our subgroup, I guess I could try to throw something in there. There are groups that are thinking about that stuff, and are doing pilots and we're learning but I don't think a data model affects any of those issues.

The last two Qs here, do it require significant time resources or deep GA4GH knowledge that could present a barrier to lower resource projects. So I'd written because it's intended to be used in the context of Phenopackets or FHIR, it does require knowledge of those. And then I was gonna write something like you know, is it it's feasible for one software developer to do it? I don't know. That'd be a question for you guys. I don't know.

GW: I hope the answer to that is yes.

MCK: I'll say yes

OB: I have one quick question. Meen were there any additions that you made that should be reflected in the FHIR IG?

MCK: I don't think so, but let me check again

OB: Good. I wasn't sure if like the race, ethnicity ancestry or something like that we need to make sure are covered. I can send you a Slack message and we can chat a little more about it.

2022-05-26: Pedigree Subgroup

Chair: Orion Buske, Grant Wood

Attendees “Name (Project Affiliation)”:  Zornitza Stark (AGHA), Bing Feng (UUtah), Chen Chen (GA4GH), David Hansen (AGHA/CSIRO), Melissa Cook (NIH), Alex Tsai (GA4GH)

Minutes:

(from Otter.Ai)

 LSHello, everyone and welcome. This is our second last meeting before approval! Just a few really quick things before we get into the main agenda. I've added some housekeeping items to the agenda. I won't go over them all right now because I did talk about all of these things yesterday in the full meeting. But very, very briefly, if you haven't seen it, the Montreal Connect meeting report is linked, also linked to save the date for the upcoming GA4GH puneri in September. And lastly, I've also put in a bit of information about the GA4GH hackathon that will be coming up in July. So these are also known as the FASP hackathon for anyone who's familiar with FASP where essentially you can propose some ideas for interoperability or standards improvements via this hackathon structure that we've been working on. And so if you want to learn more about that you can email Neerjah. Anything anyone else has housekeeping wise before we dive in?

I thought the first thing we could do is just go through some of the tasks that we have assigned ourselves from the last meeting. I'll share my screen. So I'll just walk through these and have a couple of comments about some of these things as well. The first was about some of the outstanding changes in the documentation for Meen, he did send me a note yesterday. He's still working on it will send it to us when it's ready. Related to the kin ontology. Thank you David for connecting me with Hoa. He's made some wonderful edits to the ontology, the new version is now up in our repo. The one thing I wasn't sure how to do was generate the Purl link for it. If someone knows how to do that. That would be fantastic.

OB: Should it just be a matter of updating the main owl file, so that then the Perl link keeps going rather than adding an additional file alongside? Does it contain just the differences or does it contain everything but does it just contain everything? Everything?

LS: I think it has everything.

OB: So then it's just merging.

LS: We could also just delete this old one, and add this one and rename it.

OB: Just rename it Yeah, either way.

LS: So there's an action item for myself to update the pedigree ecosystem diagram we have that has been done however, I did also send it to our comms team to see if it can be beautified. Stephanie knows of our June 21 deadline and she'll get a version back which is also fantastic. There was an item for everyone to add PRC member suggestions to the timeline document. I'll come back to this because it's a little bit later in our agenda. I did reach out to our tech team and I know Chen's here and Alex as well. About whether we can get that Bodicea export into our tooling. They do have some priorities with an upcoming ISMB conference. However, they have offered to try to fit this in around some of that work for our June deadline, which is amazing. Thank you so much, Chen. I also added this in a comment here just so everyone knows. And then lastly, for myself to work on the first draft of the submission documentation. I'll get to that again in our next item. And then this one I actually just added today for you Orion on if you saw the email from Tim he forwarded TrakGene’s JSON export for you to take a look at

OB: I will look into that. Thanks.

LS: Okay, perfect. So, what I'm hoping we can do a little bit today is work through some of this documentation because I have some questions for everyone here. And maybe the first place to start off is our related back to that action item about PRC members. As a brief recap, we had put together this list of eligible PRC members here in this document was added to the chat here and so, what I would like to do is ideally, before we even submit our documentation, have started the outreach on this because depending on whether people are available or not, especially because we're getting into the summer, the sooner we can, you know, confirm some of our PRC members the smoother it will be. So I know we had highlighted a couple of name. Any preference on order of who I could reach out to First or are there any thoughts on any other potential leads we’d prefer to have? Otherwise, I'll just start all over and work down.

GW: I just would like to consider Bob because Bob does work with HL seven HL seven, you know, has had pedigree standards in the past. They're going to be really interested in what we're doing here.

LS: Second would be our driver project representative. And so we had highlighted again, a couple of different initiatives here. In my opinion, I would propose to prioritize genomics England because once James left we've kind of lost that genomics England representation there and I would I would love to get them to take a look at the standard

GW: Well, I wondered about BRCA challenge, you know. In the world of breast cancer, family health history is huge. It's, it's critical. It's a critical tool that they use in the world of well all cancers, but specifically definitely breast cancer. And I don't know if that's an argument that means that somebody should be from BRCA challenge should be invited or not. Just throwing that out there.

LS: Very true. I think the thought process behind not including them as a representative is because they have been involved throughout the development. So it might be to our benefit to have someone who could adopt the standard but isn't already part of this work to have a chance to review it and take a look at it. But otherwise, yeah either Mandy or Melissa would make great reviewers as well.

DH:I wondered about h3 Africa

LS: Yeah. Same thing as BRCA because we do have Katherine in the group

OB: Okay, so I guess Yeah, it's a question of how for the people who have been participating. Do we want to hold strong in terms of excluding them from this aspect of it? And we're really looking for people who aren't who haven't been, you know, relatively actively involved in the development process? Or can we have someone who's more, you know, who represents a very, very good use case for the adoption of this?

LS: Either way is fine. It's kind of up to us to make that choice. As long as it's a representative of a driver project, that's really the only criteria. We have had approval processes in the past where it has been kind of either case, and it's been fine.

DH: I think you're right. I think genomics England should be interested in what we're doing. How many do we need?

LS: So we just need one from each category. One work stream lead, one driver project representative and a third member, which can is very flexible can be pretty much anyone but we generally encourage it to be someone outside of GA4GH.

We don't have the third member yet. Could be anyone who's an active member of a work stream, not from Clin/Pheno, though, or you know, anyone with expertise in the field recommended this person is outside of GA4GH. And so grant I know you had suggested Lori in the past. And then there's also the suggestion of Raymond who lead OCHRN, which is a hereditary cancer network in Ontario, and has looked at our standard in the past so he's not part of GA4GH per se, but he's somewhat in the loop with what we've been doing. Are there any other suggestions or thoughts on a third member?

GW: , I don't know Raymond. But obviously I do know Laurie and she's an MD doctor, who is deeply involved in the world of family health history has published papers on the subject. So that's why she just she would just be excellent. She'd be perfect for this. I think now, obviously, I'm, I'm sharing for my candidate here, but but I think yeah, I think she'd be great.

LS: Are there any objections to if we reach out to Lori first? All right. So I'll make an action item for myself to start reaching out to these folks. So if they aren't available, this will kind of give us a nice window to do some follow up with other candidates. If needed. Fabulous. All right. Okay, so the approval documentation. So there was the action item for me to start putting this together for us. And this is linked from the agenda. So where are we here? I have started to link in our GitHub spaces, destination URLs, product backgrounds for the read the docs. I think the two main spots that we still need to fill out here are one the product maintainers - Orion, I'm guessing you might be one of those. But anyone else we can put up to three people. So these are just you know, who will be the point of contact for if there's maintenance issues or people have requests, comments, that sort of thing. And then the second thing we need to fill out is the implementation details. This would be all of the work that has been done setting up implementation so far. So like the track gene one for example, the work Alenjandro has done with like the red cap and open pedigree and such these would all need to be filled in here. It's not a ton of information, we need to put in here. Essentially, we just need to explain to the PRC these are the implementations we've set up and here it is working in the wild, and then should provide a link so they can see that it's functional. If you need an example of the type of information to put in there I did link the Phenopackets approval documentation at the top. What I'm going to propose and let me know if anyone objects to this. I'll make a section for each of the implementers and tag our point of contact there to add a couple sentences. I think that's probably the easiest way for us to go through it. But does anyone object to that? Okay, perfect. Okay. So I'll make that listing there. We can start filling it out. Product Review Committee, I'll fill that out once I've reached out.

The other kind of new piece of news is about this REWS / security documentation. So, normally, the REWS and security questionnaire is done at the beginning of the standards proposal process. So, you know, roughly two years ago is when we maybe should have done it. Long story short, there is a new rews and data security questionnaire. It's very similar to the past one; it just essentially merges it all into one document. And there's also a couple of extra questions they've added in about EDI. But I think that section is still actually under development, so we might actually not even need to fill it out. We will be the first group to test it out. Which sounds scary, but I promise it's a lot of the same questions that were in the previous one. As we work through this, if we can capture some feedback, you know, it takes too long to complete it or this question doesn't make sense or or anything like that. l.

So I had a couple questions as I started to work through this for us. There's a section here on product information. So this would have been stuff we would have filled out at the beginning. You know, what's the product name? What are our milestones? I just put in the ones we had written way back when product type, that sort of thing. Is this the name that we're gonna go with? Is it GA4GH pedigree? Is it just a pedigree standard? I don't know if we ever fully decided on the name we wanted to officially go with

OB: what is the common format? Is there a common convention within the GA4GH for this Lindsay?

LS:Some of our standards have GA4GH in front of it. Some of them don't

OB: It seems like it's the sort of thing where if you were to Google it, whether or not you would need to add GA4GH in front in order to find it.

GW: You Well, let me let me run through my previous thought once again and see what the group thinks I know I was trying to think in terms of how do we present this to the world in such a way that it's very marketable where people outside of GA4GH understand what we're talking about what this is about. People outside of the standards world, right. would see this name and know what we're about. And so that, you know, that's why I had thought about the idea of using the term that you know, common data set for family health history. Because I thought that was like a really good generic term that everybody could relate to. Now, if you feel like it's too generic, you know, I could understand that but you know, let me know what your thoughts

LS: So you're thinking of just the naming of the Common Data Set document itself?

GW: Well, you know, and that, that could be something that we need to distinguish I mean, does does our product with our product name benefit from saying the common data set? Or do you think just the document would benefit from just saying, saying common data set, you know, I mean, or do we use common data set for universally for

LS: apologies if I'm misunderstanding grant, but so I know in the past, when we talked about the naming of that document, we I remember, we went back and forth about minimal data set, common data set and so on. And I think we had agreed on common data set for that document. I'm happy with leaving that name as it is, if everyone else is. And so, to me that would if we think of GA4GH pedigree standard. I think this name would apply to, I guess, the conceptual model, and then then everything else would kind of be you know, deliverables almost under that umbrella in some way.

GW: Okay, then that that makes sense to me.

LS: Okay, I will resolve that then. What else did we have in here? It looks like a daunting sheet, I'll admit, but having worked through something very similar in the past, it doesn't take as long as you think it does. Usually, each question just needs a couple of sentences. There's some regulatory ethics questions, you know, how does it relate to these policies?  There are a lot of questions here that are specific to API's. So a lot of those we can just write “not an API”.

Any questions about any of the approval process or documentation so far?

GW: So just so my mind understands the approval documentation and the Roos documentation are two different things.

LS: There are two different documents but part of the same process so if you were to click the approval documentation here and go all the way to the bottom there, foundations are workstream questionnaires. So there's the rews  and data security one within that sort of overall. Yep, there's also a partner engagement questionnaire. We don't have to worry about this yet. That's just once approved and provides the communications team with some information to help formulate the outreach they're going to do. So they are separate documents, but still all part of the same process.

GW: So were you going to do the first draft of both of these then, or

LS: I can if that would be helpful. Well, most of the main approval one here is done except for the implementation details which we'll need our implementers to fill out.

Why don't we review it now? So we've got the work Alejandro did which includes got the REDCap open pedigree. David, do you know much about how the FHIR implementation guide is being used, if at all?

DH: I don't, but I can ask Dave Conlan who worked with alejandro on it.

LS: Okay, perfect. So I'll add that to the list. There. We've got Orion and PhenoTips. TrakGene. Bing’s tool but we need that bodicea output first, let's put it in progress for now. I don't know if h3 Africa has anything concrete yet.

OB: Other than potentially via the REDCap.

LS: Would we want to put about Phenopckets? Would we put that as a implementation? But it's not the same implementation as this listing?  I'm going to list it here. And I'll reach out to Jules about maybe what we

OB: Exomiser, via phenopacket has been a thing for Jules. And that would be if it's supported by phenopacket, then in theory, it'll be and so I guess it's a question of timelines. Add GEM-Japan as well.

GW: Now, this list is just for the approval right? We will still working work on getting other implementers over time, when they need to be added to this list, or is this list just a snapshot in time?

LS: Just just a snapshot just for approval. Yeah. And we need two at a minimum, right. Yeah. Which we have which is great.

GW: Quick question to have this supported on a fire server. Is that important for what we want to accomplish here to have that as an implementation somewhere by somebody?

OB: So this is Meen, we should probably add that right. Kids First. Yep, that's another one.

LS: So we've got this listing here is essentially who would be point of contact for maintenance issues for question issues if someone you know will be requesting updates for example. Of course, there will be GA4GH staff who will kind of be maintainers in some way as well. But usually we try to keep at least one to two of our volunteer community that actually helped develop the standard be a point of contact after it's approved. So for example, for phenopackets, Peter and Jules are our maintainers. So we need at least two for pedigree as well.

OB: I'm happy to be one. There's anyone else who would be interested, I guess in terms of support - grant. I don't know if that's something that you would like to be

GW: My question is, am I the right person? Because you know, I'm not deep into the modeling part of what was done here. And is that type of maintaining that, that people will want to talk to people about or or is my knowledge my I'm you know, I'm just sort of like a high level, subject matter expert type person. Will that help people? If that will, I'm happy to do it. I just I'm trying to think of what what type of questions will come to the maintainers

OB: is it I guess, and Lindsay to the extent that you have visibility into that for other projects, how much is it? You know, questions like, why we you know, can it be can it do x rather than Y or can we have it also do Z or is it questions like, you know, we're interested in this as a thing, like, how do we get started with it? What is it? How does it fit in those sorts of questions, or is it both?

LS: It's both

GW: put me down. Okay. I would say,

OB: It'd be helpful to know whether or not Meen could be listed here, has some dedicated cycles through kids first, it would be helpful to know if he's interested in taking on that more technical

LS: Okay. Yeah, I'll reach out to hi.

GW: Lindsay, I see as you start going through the first draft. So these if there's something that you'd like me to think that I could do just as well, please just make the ad assignment. Just shoot me an email and say, Grant do this.

LS: For sure. Will do. I have a feeling once we get into some of the rews, actually more so the data security questions, I'll probably have to tag some people in it. Okay, if there is nothing else, so looking at our timeline here, we've got a meeting in two weeks, which is June 9. And then roughly, just under two weeks from that is our submission deadline. So our next meeting will be our last before submission. So I would really encourage everyone to take a look at the documentation. Get through any of those tasks you need to do prior to our next meeting so we can talk about it then while we're all together in a room for last time, if needed. And again, Slack channel, GitHub issues, whatever there is, please put them out on there and so we can follow them as well.

2022-05-25: Clin/Pheno Full WS

Chair: Melanie Courtot, David Hansen

Attendees “Name (Project Affiliation)”:  Ian Green (SNOMED), Philip van Damme (Amsterdam UMC), Chen Chen (GA4GH), Orion Buske (PhenoTips), Meen Chul Kim (KF, CHOP), Grant Wood, Brandon Wright, Francis Jeanson, Alex Tsai (GA4GH), Jules Jacobsen (QMUL/Monarch), Ayhan Serkan ŞIK, Steve Laurie (RD-Connect/Solve-RD)

Materials of Interest (Publications, Webinars, etc.):

1. (PRE PRINT) The GA4GH Phenopacket schema: A computable representation of clinical data for precision medicine

Julius O. B. Jacobsen, Michael Baudis, Gareth S. Baynam, Jacques S. Beckmann, Sergi Beltran, Tiffany J. Callahan, Christopher G. Chute, Mélanie Courtot, Daniel Danis, Olivier Elemento, Robert R. Freimuth, Michael A. Gargano, Tudor Groza, Ada Hamosh, Nomi L. Harris, Rajaram Kaliyaperumal, Aly Khalifa, Peter M. Krawitz, Sebastian Köhler, Brian J. Laraway, Heikki Lehväslaiho, Kent C. Lloyd, Leslie Matalonga, Julie A. McMurry, Alejandro Metke-Jimenez, Christopher J. Mungall, Monica C. Munoz-Torres, Soichi Ogishima, Anastasios Papakonstantinou, Davide Piscia, Nikolas Pontikos, Núria Queralt-Rosinach, Marco Roos, Paul N. Schofield, Anastasios Siapos, Damian Smedley, Lindsay D. Smith, Robin Steinhaus, Jagadish Chandrabose Sundaramurthi, Emilia M. Swietlik, Sylvia Thun, Nicole A. Vasilevsky, Alex H. Wagner, Jeremy L. Warner, Claus Weiland, Melissa A. Haendel, Peter N. Robinson. medRxiv 2021.11.27.21266944; doi: https://doi.org/10.1101/2021.11.27.21266944

Minutes:

(Otter.ai transcript)

LS: Welcome everyone. Glad you could join today. So this will be a relatively quick meeting today. Just 30 minutes but we're gonna go through quite a number of topics today. So first up some housekeeping. Everything we're going to talk about right now is linked in the agenda. So first up, so we had the Montreal Connect meeting in April about roughly a month ago, we haven't had a full work workstream meeting since then. So if you haven't seen the meeting report, I've now linked that in the agenda. As a reminder, we just hosted one meeting which was on the computable cohort hackathon kickoff, which we'll get to a little bit later in the agenda. There's all the reports, recordings, minutes for all of the other meetings as well in case you haven't had a chance to see it. Second up. As a reminder, our GA4GH 10th Plenary is coming up September 22 and 23rd that will be in Barcelona. However it will be hybrid in case you can't make it. I've linked to save the date. One thing to note that's going to be a little bit different this year, we will be separating the plenary events from the working meetings. So normally our plenary events are you know, roughly four to five days long. There's the public facing events and then all the working meetings. Those working meetings are going to be virtually a month later. So we're going to be separating it a little bit. Plenary will be just those two days but should be a great program. I'm looking forward to seeing some of you in person again. Other events to be aware of coming up soon, the general GA4GH hackathon. And so for those who haven't heard of these events before, it's under the umbrella of FASP or the federated analysis systems project, which is essentially a project that works to enable interoperability of GA4GH standards or very specific, you know, working meetings on standards improvement. And so these hackathons are very self driven, it's our volunteers and contributors that come up with the ideas and help organize these hackathons. But we as staff helped provide the structure to make these things happen. So right now there's an open call for volunteers or topic coordinators. And so you can reach out to Neerjah, heremail in the agenda. And these topics can be anything GA4GH related to say you wanted to hold a hackathon on I don't know connecting pedigree and beacon that could be a hackathon topic meeting for example. And I've also linked just a document there that kind of gives an overview of this, this whole process. And then lastly, I just wanted to add, I started our I'm going to start adding a new section to our agenda which I'm just calling right now materials of interest. So before all of our full workstream meetings, I'll send out a call for any, publications, meetings of interest, anything, you'd like to share about the CLIN pheno space with the work stream let me know and I can add that in the agenda so we can really use it as a way to build community within clin pheno. And so right now I just linked one of the preprints for the phenopackets schema publications. Alrighty, so that's all I had for housekeeping. Next up, we did have Peter who was going to talk about Phenopackets But I don't see him here. Jules, do you know much about the topics Peter was going to talk about? It was about the supplement to work with Broad and Terra, he asked for a couple minutes. Do you know much about that?

JJ: Oh, no, I don't. I'd like to know.

LS: no worries. We'll skip to the next one. I'll  follow up and add some content maybe after the meetings done there. Okay. I guess the two things we can mention though is there are two Phenopckets publications that will be coming down the pipeline soon. One of them is essentially a Phenopackets ecosystem. Overview. So that one is titled, The GA4GH Phenopckets schema defines a computable representation of clinical data. I think many of you were authors on that. It has been accepted into Nature Biotechnology, and that will hopefully be coming up soon. And then there is a second one that was recently submitted to advanced genetics, which is an example case where you could take a say a rare disease patient and show how you would fit it into a pheno packet. So that one's been submitted. And I think we're working on some review comments on that now. Okay, pedigree updates. We've the pedigree subgroup is preparing to submit version one to steering committee on the 21st of June. So it's roughly a month from now. In the agenda. I've linked to the GitHub space. Here. Let me share my screen so everyone can see as I walk through this year. Okay, you're seeing the agenda?

Speaker: Yep, yes. Thank you.

LS: Okay, so in the in the agenda, I've linked the GitHub space here. So this first repo here pedigree is where you will find the conceptual model itself. The family history terminology, you'll find the kin ontology which is an ontology we developed to help support the pedigree. You also see a link to the FHIR Implementation Guide, as well as some tools here. So what I would really appreciate from everyone here is if you have a chance to look through add issues, add comments, you know, ideally, the sooner the better before we get to approval in June. That would be fantastic. We do also have some read the docs documentation. That is currently in progress. There's still a couple of pages we're finalizing. But again, if you want to take a look at that, let us know if there's anything that's unclear, maybe something we need to expand on please let us know that would be really, really helpful. And so we'll be working on finalizing some of these things, the documentation and then we have a series of your documentation we have to fill out for GA4GH for approval as well. Grant Orion anything you wanted to add to that?r

GW: Nothing for me. We're just really excited for this June 21 date we've been working on for a very long time. So we're getting very close.

OB: Second that yeah, fantastic

PvD: just a quick question. If we want to give feedback on this, do we do that through GitHub create an issue or

how?

LS: Yeah, so if you can create an issue just on the appropriate repo, that would probably be best. We'll see it there. However, if you prefer to send it through us, we have a Slack channel. It's in the GA4GH organization. It's hashtag CP dash pedigree. You could do there. Or also if you want to email it to me, and I can make sure it comes up in our next meeting, which is tomorrow, actually. So either route whatever works best for you. Okay, perfect. Thank you. Any other questions on that? Okay, I'll make sure I send an email to the full workstream once we kind of have everything together and it's ready for submission just so everyone can take a look again as well. Okay, and the last update I had here before we dive into some of the roadmap stuff is just about the computable cohort representation group. As a bit of a bit of background, so computable court representation we're hoping is going to be you know, one of the new subgroups within clin/pheno, although it has not been formally proposed as, you know, a standard or we haven't officially defined that one output yet. So in at the GA4GH April connect, we had this computable court representation kickoff, which was kind of part planning of the meeting and deciding you know, how we're going to organize this hackathon. So we ended up coming up with five different topics, essentially one topic per week, over a couple of weeks. And you can find all of these listed in the master doc, which is also linked in the agenda here. Scroll down a little bit and you'll see the topic sessions here. So we had one about access and a darathon, and ones about beacon and data Connect. There was supposed to be one this week on phenotype matching tools, but we have postponed that one just because it's some conflicts that arose. And then next week, we're going to dive into CQL. And use of fire as well as terminology servers and mappings. And so if you haven't had a chance to attend any of these meetings, we have the action items, the recordings and the minutes all within this document. And then I do have an extra time for myself to put all of these action items in our Slack channel as well so that they'll all be kind of together in one spot. And so what we're hoping at the end of this is having explored all of these different tools and standards and things available to us, we can better define, what an output might look like. And yeah, what else did I want to say about that? Oh, if you haven't, you don't have immediate an invitation to one of these meetings, please let me know and I can forward that and I think the plan is after this last meeting next week, we'll get a report back or a retro that I'll invite everyone to we can explore some of the topics and findings from that and any questions about that before we dive into the roadmap? Good, okay. We are flying through here.

Okay, so the last thing I wanted to spend some time on today is about our draft roadmap. So I introduced this at our last meeting, but it's significantly more filled out than it was the last time. The structure is still essentially the same. You've got this motivation and mandate up at the front proposed solution and then these blue boxes which represent the different standards that we have in the work stream. We've got one for pedigree one for phenopackets, if you scroll down a little bit. And then a little bit further, we have the computable cohort representation one however, this one is still as you can see, got some gaps in it. And that's partially because as mentioned, we were still kind of working out what is exactly going to be. So right now I've kind of just put this in a to be iterated on section and not in the official roadmap per se that we will submit. These roadmaps are to be considered working documents. Just because we're putting in the two standards now does not mean we can't add anything at any time and in fact, I'd welcome anyone if you have ideas or projects you want to run, please don't hesitate to approach me or Melanie or David. If you can see if we can get something up and running in the work stream. I would say our biggest limiting factor in clin/pheno is just

having volunteer support to do some of these projects. But of course I'm happy to help with outreach and you know, any sort of project you're interested in. So, if you go right down to the bottom, I have a little spot for future roadmap items for discussion. Feel free to add ideas here or again to send me a note as well and after I run through this little bit, I can save some time if we want to have some open open floor space to talk about that. What I would really appreciate from everyone here is feedback on whether everyone agrees with this statement. So this is essentially our work stream statement - what we do this will be put on a lot of our you know, workstream pages and outreach documents. So if there is something you don't agree with in the statement, please let me know as soon as possible. Or add again, add your comments right in here. And then I don't want to go through all of the details of you know, every single standard here, but mostly to say, you know, if there's something you wanted the Phenopckets team to do, for example, we would love to know and maybe think about how we can incorporate that into our roadmap. Jules - about the journal interactions. Has there been any progress on that? I know we were talking about it being a potential goal, but I'm not sure where where that's gotten to.

JJ: We've had I think some sort of vague interest from one or two journals but nothing sort of concrete that they've actually said, oh, we'll definitely adopt these and start using them.

LS: Okay. So, do you think this is still a goal we would want to keep on the roadmap is something to pursue?

JJ: Yeah, I think so. Because it's really valuable part of you know, capturing the data that sort of that level but that that place but we didn't need sort of, I guess, I don't know, outreach, some some way of reaching the journals and convincing them that that's a good thing.

LS: Okay, so maybe we can talk about how we can plan for getting that to happen. Okay, that sounds great.

JJ: We'll have more things we need, you know, easier JavaScript tooling, maybe to embed into websites so that people can create feedback. It's easier than out of that rather than sort of expecting them to hack together a Yaml file.

LS: Yeah, that sounds great. I think we've got something about that web interface here. I got that from Peter. So I'm assuming that's probably what you're talking about. Yeah. Yeah. Okay. Great. So just as a bit of a heads up, I suppose. We will have to present this roadmap to the GA4GH steering committee by June 22 is the next steering committee. We've got just under a month to finalize our current roadmap. And so again, this is a roadmap that we will publish on our webpage do some outreach with so if there is anything, any comments, you know, put them in now. So I'm just going to pause here because I feel like I've been talking for a while. Are there any questions about the roadmap or expectations for it? Thoughts you have on other project directions we could take or if I hear silence, I'm gonna assume everyone is happy.

Speaker: I think we just want to sort of push adoption

LS: Whole section here for implementation support. Which I think is a theme we're gonna see with a lot of GA4GH deliverables that have already been published. It's, you know, how do we get people actually using them? What tools do they need to support them? Looking at interoperability with things like FHIR do we create fire implementation guides, that sort of thing. I think yeah, that's gonna be a common theme, as well as the more dissemination type stuff like doing publications doing webinars.

JJ: Yeah, those sorts of outreach materials. So I think definitely, we're just talking to people about it, because not everybody's heard of them. And, you know, there's there was what's interesting, the opposite. Pediatric clinical trials, I think they were interested in.

LS: I'm curious from everyone else on the call, you know, whether you're a Clin Pheno standards implementer or not, is there anything you think we need here that we haven't done yet? In terms of whether it's implementation support, you know, additions to standards, anything like that? If you don't have an answer now, that's totally okay. You can think about it and send us a note after mostly I just wanted to use this meeting to raise awareness that this is something that we have ongoing.

GW: Lindsay, one quick comment about the pedigrees section of the roadmap. Obviously, what we have in there right now, was something that we wrote a couple of years ago. Do you feel like we need to update this? So it also stalks talks about adoption?

LS: Yeah, this version that's here now does include some new content. It's not just a direct copy from the previous version that we had. So there is a little bit there is a section here about outreach implementation support, so things like a webinar from a publication, maybe a Connectathon. I've just put kind of guesses on dates here. So I'd welcome any sort of revision on that. But some of the proposed ideas are a webinar so once it's approved, introducing the broader genomics community to what it is and what it does. A publication I know in the group we've talked about turning that common dataset into a publication. So it could be something there as well as one on the standard itself. There was the idea about proposing a FHIR Connectathon to support the implementation guide, as well as just generally collecting use cases for a potential future version there as well.

OB: Lindsay, if there comments on this, or should people be making edits right here or in the working doc that's linked from the header of that?

LS: Yeah, good point. So what's in here now is a direct copy from that working doc. So maybe I would say just make it edits on this.  I'll remove that link.

GW: I made that comment, Lindsay because I looked at the description there and the description looked like we had changed that much but that's no problem. The rest of it is updated and that looks great.

LS: If there is some of this description we need to change, please feel free to add the comments or suggestions right into the description.  We've got for both phenopackets and pedigree here we've got listings of proposed in the case of pedigree or current implementations. If you in your initiative or you know of an initiative that is going to be implementing or hoping to, please feel free to add them to this list here. So we can keep a good tracking where our standards are being adopted and where they might eventually be so we can provide that support if needed. So you'll see it here. Pretty much right before the milestone section. Okay.

IG: So we were doing some work with biobanks and certainly, the bio banks that I'm working with in Europe have started to expand their data collection into collecting phenotypes from directly from patient records. So one, they're a potential user for Phenopackets But I'm wondering with and isn't just one country, so this is all across Europe. I'm wondering whether on the roadmap, a focus on biobanks atleast in some form or another might be a good idea. But I'm throwing that out as a suggestion.

LS: Yeah. Are you thinking so this would be something specific to the Phenopckets roadmap or just kind of the work stream ingeneral?

IG: So I think it's the work stream in general, I think there is a link to Phenopckets so potential implementation sites for Phenopckets. Yes, but I'm thinking more in general terms about really about the way bio banks are using data potentially using GA4GH standards and having a big focus on where you're on phenotypes and on the clinical side and on the terminology that goes with it.

LS: Okay, I've added a comment here to our proposed solution. Do you have any comments about sort of the Phenopckets approach? I know we have biosamples, for example, that uses it as well as the gem Japan, biobank and it uses Phenopckets. Because I'm thinking, so the way the roadmap is structured is it's by deliverable. So we could put a general comment, you know, in the proposed solution, like what we'll focus on biobanks, or you know, clinical systems or whatever makes sense there. But I think where we can add, some of this is actually for in the specific deliverable sections. You know, whether it's a specific webinar or for biobank audiences, for example.

JJ: Yeah, we'd love to talk to some the UK Biobank people and it could be useful for them.

MC: We had talked a little bit with BBMRI Eric on the cohort front that maybe I'm always interested.

GW: Okay. Quickly, I just want to share quickly that since we're talking about this idea, which I think gain is a great idea. I know Intermountain Healthcare has a great biobank and they're actually moving to try to generate some some revenue from you know, selling access to that biobank from outside organizations. And so I would think, if they're gonna do that, to have the capability to attach fino packets to it would greatly enhance the value of their service. So please include me in any discussion. If you want me to help approach the inner mountain commercial biobank about fina packets and a pilot I'd be happy to do that.

IG: I was gonna say the the other group that I'm dealing with directly use the Catalan biobank network. So it's a network of a number of buybacks and they've set up a fire terminology server to serve the network. So they're building up connectivity between a number a large number of buybacks.

LS: That's great. And considering we've got our plenary in Spain, there's maybe some connection we can make there. Okay, thanks, everyone. So I'm just noting we're at our 30 minute time here. Any other comments questions from anyone otherwise, action item for everyone is to take a look at this roadmap and add your comments, suggestions and so on as well as to the pedigree standard. That's preparing for approval. So I'll pause here for any last questions comments.

MC: Quickly for Ian. I was just trying to find the Catalan biobank, do you have a direct linking

IG:I'll send you via email

JJ: If you want to put them right in my direction or ask if they want to have some kind of an introduction to Phenopckets as to what they are then. I'd be happy to do that.

2022-05-xx - Computable Cohort Representation Hackathon

Following on from the Computable Cohort Hackathon Kick-off at Connect, 5 topic meetings are taking place throughout May to dive deeper into the standards/tools/strategies that could support this effort. This master doc can be found here.

Please reach out to lindsay.smith@ga4gh.org to learn more.

2022-04-28: Pedigree Subgroup

Chair: Orion Buske, Grant Wood

Attendees “Name (Project Affiliation)”: Chen Chen (GA4GH), Meen Chul Kim (KF/CHOP), Bing Feng (UUtah/BRCA), Katherine Johnston (H3Africa), Steve Laurie (CNAG, EJP-RD)

Minutes:

Documentation Updates

OB: Outstanding PR to merge and the docs will be more representative.

MCK to rebuild (done!)

Docs -Classes Page

MCK:Will create a PR for outstanding changes. At our last technical meeting we decided on a few changes

OB: Great feedback from TrakGene about adding some more detail and additional examples. The way the terminology is set up, we have terms for aunts and uncles, but not maternal or paternal aunts and uncles. They have questionnaires where it is possible to have information about the grandparents but not the parents. Questioning whether we’re sure if we want these, whether to have a node. Small change either way. As a consumer, fewer ways of representing things.

GW: What we have done is optimized that design, removal of certain relationships where it’s fully known how they would be related. Do we want to tell the world to go forward and follow what we’ve done as opposed to use being backward compatible?

OB: How much we meet people 100% where they are. We’re somewhere in between the spectrum.

SL: In the example where you have the information with the child and the grandparent, do you make a ghost mother?

OB: Yes, create an individual there you would have not other info on

GW: What would be the most strategic decision here?

OB: It causes a bit of friction with people who have the data already. Creates a little less friction for those on the consuming side. I can see both sides really clearly. There’s a rationale behind saying it’s intended for this reason. We will be presenting in a world where it aligns with the FHIR valueset.

SL: What do you do when you don’t know what side the grandmother is on?

OB: There are terms for ambiguity. It has grandparent, but not sex, or maternal.

GW: Is it possible for us to develop something that allows for both paths. Can we allow them to follow that maternal path?

OB: Lowest friction option is to just add terms, but it adds more options for the way things can be represented

SL: What about incestuous relationships?

OB: Can just add more edges with the graph structure.

GW: Easiest thing is to add the terms.

Lindsay to reach out to Melanie about protege ontology editing. Also check in with David re: folks at CSIRO.

Lindsay to re-add ecosystem diagram to docs.

Common Dataset Updates

OB: Relates to what Meen was talking about with updating classes,we discussed this at the technical meeting. Make sure everything is synced up.

Timelines for Submission

June 21st seems reasonable for submission. Need to have all docs, model and PRC ready for this date.

PRC member brainstorming in the timeline doc - please add any suggestions for members in the doc.

If we can reproduce the hounding we have with in-person meetings, let’s cancel next meeting.

2022-04-20 - GA4GH Montreal Connect

Please find the meeting report here.

2022-03-24 - Computable Cohort Representation Meeting

The minutes for Computable Cohort Representation can be found here.

2022-03-23: Clin/Pheno Full WS

Chair: David Hansen, Melissa Haendel

Attendees “Name (Project Affiliation)”: Grant Wood, Lyndon Zass (H3Africa), Marion Shadbolt (Australian BioCommons), Chen Chen (GA4GH), Orion Buske (PhenoTips), Alex Tsai (GA4GH), Peter Robinson (Jax/Monarch), Ian Green (SNOMED), Jordi Rambla (CRG-EGA), Ada Hamosh (MME), Ron Miller, Brandon Wright, Nicky Mulder (H3Africa), Melissa Cook (NIH), Shahim Essaid (Monarch), Katherine Johnston (H3Africa), José F. Reyes, Nebiyou Petros, Freddie, Mogomotsi Matshaba (H3Africa)

Minutes:

H3Africa Cohort Representation

Lz: H3africa is one of GA4GH’s driver projects. Several genomics projects running across H3Africa. Compelte cohort over 100k research participants. H3ABionet ensures African data is FAIR, implementing standards within the consortium. We’re using GECKO to describe the depth and breadth of H3Africa cohort, make the data more findable. Aiming to map metadata (cohort descriptors). Mapped in two ways - automated and manual. Successes: mapped all of the phenotype to GECKO, the standard CRF was used. GECKO mapping completed for half of the H3Africa projects. For the most part, automated mapping was successful. Challenges: some minor gaps identified in the ontology itself. Challenges with sharing of data dictionaries and case report forms across H3Africa projects, incomplete mapping for some projects. Next steps: get a broader view of where things have been done.

NM: H3Africa is reluctant to share a lot of their phenotypes. We’d like to demonstrate to the public that the cohorts are much richer than the datasets in EGA. Want to search the data in the EGA, and also have a broader view of what else is collected and sitting with the PIs. Trying to show in a summary way, this the number of projects HIV status, or other phenotypes.

GW: How are you collected the FHH information and what analysis do you use it for?

LZ: Being collecting by some projects, not all. DDD-Africa and a rare diseases group. Collected a bit differently, the rare disease group is limited in what they capture. Can’t speak much to what they do in the analysis piece.

MS: The automated approach, are there’s scripts available?

LZ: Yes, though I don’t have the script, but will share that.

JR: How many terms have you been able to map?

LZ: Phenotype data is quite broad. Have been able to map most lifestyle factors. With project metadata its’ more limited, but gecko allows us to map the type of experient that was conducted. Don’t have specific numbers.

JR: How many rows in the master spreadsheet?

NM: GECKO doesn’t have that many terms, so maybe under 100.

LZ: 143 rows, but only looked at a subset of codes. Will look at variables to group things together.

JJ: With the codes, did you link to the cohorts themselves?

LZ: Haven’t done yet, will be looking at that next.

JJ: Might be useful to take aggregate codes at a certain level, know about useful groupings.

NM: With using an ontology, can go to the different levels in the branches. It’s metadata, so it’s less identifiable at an individual level rather than a cohort level. Don’t have the values of each.

Cohort representation will help, because it will have those study levels and how to get to that next level of granularly.

Roadmap Planning

[Lindsay shared screen and walked through the roadmap]

Please review the roadmap document and add your thoughts, comments, things you like/dislike, etc. There is a section near the bottom to add in thoughts about future roadmap ideas.

OB: Does it make sense to make implementation more general, and where do we want to put actual implementations.

LS: Generally, implementations that are not done by the workstream (eg. an initiative’s implementation) are not included in the roadmap. They are listed in the planned implementations section. We can add implementation support content like webinars/workshops, publications,etc.

PR: The IG itself is complete, and what we’re doing now is writing HAPI FHIR Java code that provides a Java equivalent for the classes. The purpose is to use FHIR to transmit and translate that back into a native GA4GH phenopacket. Can leave this on the roadmap as something completed in Oct of this year.

Implementation support for Phenopackets?

PR: Had a great conversation with GA4GH staff on implementation support, waiting to hear back. Working on phenopacket creation tools that use text mining and quality control to create phenopackets. Have some good desktop tools and are now working on a REST API frontend that might be useful.

Have had a great conversation with the Beacon team. Idea to have Beacon v.2 accept queries that include phenopacket bits and optionally return a list of phenopackets that match that query or a yes/no. Looks like we will be getting a supplement to implement code that would support that API. Would be interesting to include Pedigree. Would be great to have a call with Beacon and Clin/Pheno.

JR: What Peter is referring to is Beacon query by example, where you provide an example of a record then you look for records that match these kinds of examples.

One thing I’m missing in this roadmap is where the implementations from Driver Projects go in the roadmap. Not a deliverable from the WS itself but it’s very important. If not in the roadmap it should be somewhere.

LS: Agree, we need these listed somewhere. Some are listed in the implementation’s section of the roadmap, and I think the tech team has been working on some kind of repository to track implementations.

JR: Gathering feedback from implementations so we can focus on the next version. Some kind of outreach or report.

JJ: Mostly have Github for feedback, might be the easiest thing

LS: I’ll have more of a think about that. Github issues are great but there could be a more accessible way of doing things

2022-03-17: Pedigree Subgroup

Chair: Orion Buske, Grant Wood

Attendees “Name (Project Affiliation)”: Zornitza Stark (AGHA), Chen Chen (GA4GH), Alejandro Metke (CSIRO/AGHA), David Hansen (CSIRO/AGHA), Melissa Cook, Steve Laurie (late and lurking for RD-Connect), Katherine Johnston (H3Africa), Alex Tsai (GA4GH), Meen Chul Kim (CHOP)

Past Tasks:

• Merge PRs 18 and 19. Once complete, rebuild doc site

• Lindsay, Meen

• Interested in participating in the proposed Testbed Session at Connect? Please let Lindsay know

• All

• Confirm with Grant that we’ll use “recommended” instead of “common” moving forward (for this doc)

• Lindsay

• Add additional field for relationships in the Phenopackets Family message

• Jules

• Take a stab at including REA information in the conceptual model

• Orion

• Circulate a comment box/table for roadmap updates prior to next meeting

• Lindsay

• Share updates on developing an RDF, when ready

• Soichi

• Plan for submission to GA4GH PRC by MAY

• ALL

Minutes:

MCK: Going to update the classes page about updating the type and adding more elements on the common dataset

OB: Sounds great, happy to help coordinate on that. Just pulling from the doc and looking at how that might map

AM: +1

OB: Made a new PR for the docs (https://github.com/GA4GH-Pedigree-Standard/pedigree/pull/23). A lot of it is the minimum amount of information, getting to the root of what we’re talking about. Summaries of key concepts, will replace with links to classes. A bit of a description of relationships. Alejandro, if you have more information on the IG you’d like to add, let me know.

AM: Sure, I’ll have a look and add something

OB: Once we’ve updated the model, we can update this and potentially add the phenopacket and FHIR version. Does it make sense to add them all, tiptoeing the line between how concrete we are making it or not. There are a few pieces I’ll want to coordinate with Meen and Alejandro on. Give people a realistic sense of what this look likes.

AM: For example, would be great to have something like those tutorials with tabs for multiple languages.

OB: Is that possible in readthedocs?

AM: Could imbed html. We can take a look.

GW: You can spend time creating the standard and then there’s the marketing of getting that standard know. Common - was thinking about giving it that marketing name, this is a particular product. The recommendation part was to think that the outside world doesn’t incorrectly interpret what the document is about. Meant for a wide range of stakeholders.

Because we went though the tables and pointed out that some elements were not part of the conceptual model, and we highlight ped, hl7, the text in the introduction need to be revised to fit that structure.

OB: Seemed like there were two different approaches to REA I wanted to run by everyone. Given there isn’t an overall appropriate ontology, treat it as an ontology and recommend hancestro as a first step. There were a few competing options for REA ontologies, on that last call we decided it still makes sense to put a placeholder in there. As long as it encourages someone to take a term, or allow a free text to allow a variety of census data use cases.

GW: When we were working through this question, there were many out, and there were conversations that people preferred different ontologies. Have a code for the different ontologies?

OB: We’re not going to force people to use Hancestro

KJ: the H3Africa Ethno-Linguistic Ontology is in the final process of stepping through the OWL requirements and have website (just struggling to find link at present) but it promises to be a vastly superior way to identify African ethnicities

AM: In the FHIR implementation, FHIR is very explicit with this through bindings. There are different categories of strength for bindings. Required closes the door to anything else. Start with a recommended.

OB: Is it possible to have multiple recommended?

AM: Haven’t seen it. Could include a value from multiple codesystems, just not as clean. Hancestro already in FHIR.

KJ: can you set up front your choice of ontologies and that gets ported out as description of the flexible components you have used in your pedigree dataset? If there are these removable components such as choosing a different ontology, if you implement the pedigree common dataset, is there something that goes along with it like the metadata?

OB: When you define a term in the pedigree, it would say “this concept from this ontology as laid out by this identifier”.

KJ: Imagining implementing in redcap where you have an upfront setting. If you’re just going to associate with individual ontology code in every instance it doesn’t really matter

OB: functionality of the tool doing the collection. When the data is actually transferred, then just use the codes.

OB: Aim to have a work session prior to next meeting to see if bumping back or forward. Make a decision based on this.

2022-03-15 - Computable Cohort Representation Meeting

The minutes for Computable Cohort Representation can be found here.

2022-03-03: Pedigree Subgroup

Chair: Orion Buske, Grant Wood

Attendees “Name (Project Affiliation)”: Chen Chen (GA4GH), Alex Tsai (GA4GH), Bing Feng (UUtah), Alejandro Metke (AGHA/CSIRO), Jules Jacobsen (QMUL/Monarch), Mamana Mbiyavanga (H3Africa), Soichi Ogishima (Tohoku, GEM-Japan)

Past Tasks:

• Send reminder to the Pedigree mailing list to review acknowledgements/affiliations

• Lindsay

• Update the ‘Classes’ Section of the documentation and send a ping when ready for review

• Meen

• Review PRs #18 and #19 and add any comments/suggestions prior to next meeting

• ALL

• Follow up with Jules about Phenopackets implementation

• Lindsay

• Extend the conceptual model with elements from the common dataset

• Orion, Alejandro

• Revise the pedigree ecosystem diagrams to remove ambiguity about the “third model”

Minutes:

Doc Updates

OB: Started a skeleton of the pages I’ve been working on. Fleshed out the example in one of them. Start them as draft PRs, but as always, feel free to add comments. One placeholder is what makes sense to add around the use of this within Phenopackets.

JJ: For things like concepts and identifier, will just say its a thing to map to Phenopackets?

OB: Yes, use native phenopackets.

JJ: Some concepts in phenopackets - we have enumerations, that have been mapped to actual concepts in NCIt. FHIR I don’t think has the same mappings. We went with phenotypic sex description, gender was moer self-identification. Other difference was with life status, we’ve mapped that to an enum in a class as well.

OB: Question is there a more native way of representing in pregnancies or fetuses. We’re going to back out of a few specifics for Meen’s PR, the implementation of the concept would not be within the scope of the conceptual model.

JJ: Would be helpful for Pedigree model to say, when we mean male, this maps to this FHIR and this in Phenopackets.

OB: Put that as the description in Meen’s class file. Lighter on specific of string or int, and more on definition.

JJ: Still need to go to string to int

OB: As long as there’s another entity in phenopackets or FHIR that handles it.

JJ: FHIR doesn’t map sex as a concept?

OB: Either way, in the context of this, can’t assert representation in FHIR, but can we say they’re good for interoperability purposes.

JJ: If you look at the sex documentation (https://phenopacket-schema.readthedocs.io/en/latest/sex.html), that can be mapped to the NCIt ones.

I was thinking implementing with the org.ga4gh namespace for pedigree, so can include in the phenopackets schema with a separate namespace. Work with the objects as they come in. Should we be replacing or adding as an optional one or the other as a Family message.

OB: Ideal to be it have one or the other

JJ: No drawback really.

OB: In ideal world wouldn’t need a separate representation in the context of an individual. Individual model in phenopacket is quite robust, only thing is can you represent fetus or pregnancy through it.

JJ: yes we can, we have gestational ages

OB: Any placeholder for REA? Codeable concept but attached to an individual?

JJ: Didn’t end up including it. Could record in the pedigree field, but not individual. Would be a point update to take from pedigree model and add into individual.

OB: Replace ped row approach with a list of relationships and slightly more fields at the family level. Won’t work in the context of the pedigree person. Needs to replace existing pedigree model completely.

JJ: would then get cycles? Family has a pedigree and a list of phenopackets as individuals. Could still do this, they just might get out of sync

OB: As long as we don’t mess with a Phenopacket. We need to make sure a sufficient amount of the pedigree as a whole is in the Family model. Really just replacing Family pedigree type with a different type. Gets us 95% there, for a first version that’s great.

JJ: Nice way of keeping them together in a separate way. Don’t need to replace, just have an additional field with relationships, alongside pedigree.

OB: Sounds like we need more discussion here. Two options: 1) making the family pedigree support an option for a non-ped pedigree, 2) adding something like family.relationships in which case the way in which that interacts with the pedigree field might need to be clarified somehow

JJ: Probably easiest to say GA4GH pedigree or ped pedigree. Affected is the only one that doesn’t really map.

OB: Almost all use cases are being more explicit about this anyway. If there’s a particular concept that is affected in some terminology, is there a parent one in ORDO or somewhere like that?

JJ: Not sure

OB: Where should this guidance live? What needs to happen?

JJ: I’m fairly certain I had a good play with this already. Sitting in a branch somewhere but have not merged it. Might be on a stale version.

JJ: Could create exactly what you’ve done in the conceptual model

OB: Probably adds enough additional complexity to what a phenopackest looks like because it already has a lot of that natively. May be a gap here or there that we can improve over time.

JJ: Interesting to see how that will work with the Phenopackets FHIR IG.

OB: Goal here is to use all of the native Phenopacket entities wherever possible and add value in bringing relationships in.

JJ: really only need to add one new class in that case

Aim for end of April early May for documentation/ready for approval.

Stick with ‘recommended’ for document naming - run by Grant.

OB: Taking a stab at updating this extensions. Trying to understand at what level of resolution would be helpful to share with people. Balancing between two pressure - one making it mean something beyond the document, but also not trying to give it the same level of specification as a format. Want that sway in terms of the implementation of that model. Get feedback on what level people think would be best?

JJ: The layout with field names was useful, but didn’t know how conceptual this needed to be. Has to be some limit to these things.

OB: Having a minimum data about these entities and relationships between them. Would love to get clarity if REA is something to bring into the conceptual model now. I see options as either elaborating the description to justify it not being part of the model, but leaving it in the table. Or, removing it from the table but leave the paragraph that explains why we’re not making recommendations at this time. Used by a lot of risk analysis tool. Probably something we should have. Important enough to take stab.

JJ: Hard part was defining all of the different things that can be put in there. For interop purposes, would have to do mappings with local REA fields.

RDF Model

SO: Work on the representation of our cohort family relationships in RDF. We need an ontology so would like to use the GA4GH terminology to represent family relationships.

AM: Almost done with all of your comments.

OB: Would love to hear feedback as you start using the ontology, if there are any other pieces of feedback that you end up with.

SO: I think we finish in 3 months or so

OB: Anything else you’d like to see from us to assist?

SO: Nothing at this time

OB: Would it be worth adding to the documentation the use with RDF? Can we highlight this project in any way?

SO: Would like to feedback our experiences

OB: It sounds like we could potentially include in implementations in documentation

SO: Yes, would like to contribute

AM: FHIR also has an RDF rendering, so would be interesting to compare with what Soichi develops.

OB: You are planning to use the kinship ontology in a larger RDF model. It would be interesting to see what that RDF model looks like. Is it based on FHIR RDF? Or separate mode?

SO: Making a separate model, but need to harmonize. I would like to share my ongoing RDF model development work with you to get feedback. It would be very helpful for us.

OB: Sounds like a third ecosystem to align pedigree information, in addition to FHIR and Phenopacket. Another place to guide people with interoperable alignment. Please share the models when they are developed, we would love to take a look.

2022-02-23: Clin/Pheno Full WS

Chair: David Hansen, Melissa Haendel

Attendees “Name (Project Affiliation)”: Orion Buske (PhenoTips), Ian Fore (NCI, NIH), Jordi Rambla (CRG), Marion Shadbolt (Australian BioCommons), Grant Wood, Alex Tsai, Chen Chen (GA4GH), Alejandro Metke (AGHA/CSIRO), Steven Laurie (CNAG-CRG, RD-Connect), Mette Peters (Sage Bionetworks), Francesca Frexia (CRS4/BBMRI-ERIC), Melissa Cook (NCI), Brandon, Anita Rauch (MedGen, UZH), Mogomotsi Matshaba (H3Africa), Shahim Essaid (Monarch), Peter Robinson (Monarch/Jax), Aly Khalifa (Mayo), Jules Jacobsen (QMUL), Bimal Chaudhari, Jose Reyes, David Hansen (AGHA/CSIRO)

Minutes:

Phenopackets IG

PR: Phenopackets manuscript has been submitted to Nature Biotechnology - https://www.medrxiv.org/content/10.1101/2021.11.27.21266944v1, will be resubmitted as a Correspondence. One of our goals is to integrate rare disease clinical care into EHR. The implementation guide of Phenopackets is not yet to cover all aspects of the Phenopacket but to cover phenotype driven diagnostic exome or genome sequencing. If ordering an exome can provide a description of phenotypic features, most people use HPO for that. Most programmes for that are manual so it would be great to have something to extract from the EHR, send that over to the lab in a structured form so they can run a program like Exomiser with a phenopacket.

Exomiser and other similar tools can ingest phenopackets.

The phenopacket-schema repository in Github is the official repo for the shema. The schema is written in protobuf but think of it as a JSON schema. The core IG repo is the FHIR IG (http://phenopackets.org/core-ig). It’s written using FHIR shorthand (FSH). The published version shows all of the artifacts. An IG is a way of specifying how to use FHIR to achieve a certain goal. In most cases, you want to restrict the elements used in an existing FHIR resource. For the GA4GH individual element, this matches well with the FHIR patient resource, but is missing KaryotypicSex.

Have developed some Java packets that will create a FHIR phenopacket, send it to a server, perform searches on the server, retrieve that back and reformulated as GA4GH phenopacket that can be used for research.

Pedigree IG

OB: https://github.com/GA4GH-Pedigree-Standard/. The documentation is not too far along yet. The pedigree standard is intended to build upon ped and other file formats in terms of exchanging family health history and pedigree information. Graph based model with relationships modeled independently. Works in the context of both FHIR and Phenopackets. Built tooling to support interoperability between pedigree and other formats.

AM: The IG is a mapping of the conceptual model in FHIR. FHIR already had some resources dedicated to representing family health history information but they didn’t quite map the graph model we’re proposing. In the documentation you’ll see a description of all of the resources we’ve profiled, as well as some simple examples using the Simpsons family. One of the key artifacts was how to represent relationships in the graph. Ended up repurposing the family member history resource. Key thing was using an existing extension to represent a patient. Finalizing a recommended data set. In the appendix there is a graphical representation of the existing family member history. After some discussion we decided it would be best to come up with our own ontology for relationships. Binding the relationships in the family member history profile. Idea is that we can use logic reasoners for validation and infer new knowledge. The ontology in OWL can be transformed into a FHIR codesystem and tie in with the IG.

AR: Wondering about the concept of AffectedStatus under investigation. Can only use for one clear disorder? Can there be different HPO terms?

AM: The reason is to have backwards compatibility of ped. The idea of having this in FHIR is that you can add any number of additional information but it’s not covered in the implementation guide. Phenotypes would need to come from some other resource or IG (Phenopackets).

IF: As we put together a hackathon for cohort representation, I went in search of some asthma studies. At Least some datasets had pedigree information. Is there a potential here? Use as a test for whether this standard works with real data.

AM: That would be great, always trying to test out with real data.

IF: link here: https://github.com/ga4gh/fasp-scripts/blob/master/notebooks/search/Asthma%20tables.ipynb

Vulcan Project

SE: The Vulcan effort is about acceleration the use of FHIR in medical research and other new environments. Phenopackets was proposed as an use case two years. A year ago we participated in a connectathon where we demonstrated a simple use case where we took existing LOINC laboratory data, a LOINC-HPO library and a simple user interface to curate existing LOINC medical results into HPO base phenotypes. We sent them to a FHIR server and had a simple UI to read them back and review them. The representation of the LOINC information as HPO phenotypes were based on an earlier version of the Phenopackets IG, so we need to re-review. We’re trying to implement a more realistic use case where we have existing clinical information already in the EHR, and EHR apps collecting data (like PhenoTips), have that information represented in FHIR, sent to a central FHIR server. A lab will be able to read the request along with the phenotypic features collected in order to perform an analysis, write whatever can be represented in FHIR back to the server, and then bioinformatics tools can have access to the information. TIMS (terminology service) is a new group trying to understand what additional requirements you need to support this efforts, you need HPO in a production manner for example.

The idea is to implement this in a future connectathon.

JJ: (Sarah): Trying to make it that phenotype data can travel test orders for genomic sequencing and be shared downstream in a repo for cohort analysis, etc. In the NHS there is a lot of concern over information governance. How do you see access and information control?
SE: Not addressing that right now, mostly focusing on how to take the information we’re interested in and represent in FHIR. With the data, looking at a bottom up approach rather than start with an IG and decide what is the right profile. Just take the existing data and fit it in the base spec and write examples. Won’t get validation without an IG, but starting to understand what data elements we have and where to place them. The hope with the FHIR server is that it will be a stable place to share/review JSON representation of data. Can think gradually about what is in PHI and where. That is likely well addressed in the clinical FHIR world and we need to learn from them. Security is a real concern in the clinical world.

SJ: A clinician is going to order a test, and the data is captured when the test is ordered. I see that it could be a possibility to pull it as late as possible, info is being added to that record continuously.

SE: Yes, all issues to address. I understand that there is a need from lab folks to collect info on their, but also for the clinician to assert the request. Everyone has to be independent and put a line around what they’re responsible for, and that’s where documentation and FHIR composition is important. Many aspects, and not any one is the only way of doing things. Need for a packet from whatever system or clinician. Use case is a one direction - initial intake that gets collected and sent to a FHIR based repo, with the lab sending information back.

OB: Sarah, is the workflow you’re talking about in the context of clinical care, like doing another analysis separate from the test order, or in the context of a research reanalysis?

SJ: mainly thinking of the former, a clinician orders a test, they don’t get a result, time passes and maybe some research project has gone on and new variants of significance have been found. Don’t want to re-send the sample for sequencing, just want to reanalyze the data already there, but also want to make sure patient data is up to date. Want a fresh look at the data, theoretically should be the same mechanism.

OB: depends on whether it's triggered by some upstream or downstream process. As long as it’s being synced to a lab that has access to a repo it’s okay.

SJ: My assumption is that a clinical thing will always be driven by a clinician, but a research thing may not be

AR: If the updated clinical information is then noted with a timestamp? Or is it all one input?

SE: In the clinical world, information doesn’t get updated in that sense. A note is done during the visit and that is permanent. The information doesn’t get revised, just additional information that accumulates.

AR: If there is a disorder developing over time

SE: The medical records will have snapshots

PR: The purpose of the phenopacket is really to be a bioinformatics representation. The raw FHIR is not arranged in a way to immediately use for analysis. Have to make some decision for analysis whether something is present or not if mentioned previously.

SE: What is the packet. It spans time and the individual in some cases. A layer that is somewhat abstracted. The packet has to be asserted by someone, that’s a clinical decision if someone has a feature. Depends on how records are maintained, it’s not straightforward. There are all of the modeling issues we need to try and understand. The OHDSI piece is a reference from the TIMS group.

AM: Question about terminology - you want to be able to access HPO via FHIR. What’s the status of that? We’ve been using HPO in FHIR through some infrastructure that generically transform, but would prefer the official release.

PR: Working with Shahim’s group to determine the best way of putting HPO in place. Also working on a HAPI FHIR model of the phenopacket. Essentially have to write a Java class that derives from the patient class. Going to need another month or two to finish it up, but welcome your involvement or comments.

SE: One piece I'm working on is trying to figure out how to use HAPI server. There is some coding and understanding to do there. Goal is to stand up a HAPI instances that behaves in a similar way to the default HL7 FHIR one.

IF: On that last point, is there a FHIR HL7 position on who else might stand up terminology servers and why? One thing we run into is when to extend the model. There is a reluctance to allow extension of the model, and does the same apply to terminologies.

SE: There is a need to stand up the server, and HAPI does not do it by default. In terms of thinking about new resources from scratch, that’s a major effort and they don’t want folks doing that. The TIMS group is trying to understand code mappings in FHIR. R5 has a new model called conceptmap2. At least two different ways to represent mapping.

DH: There are a bunch of FHIR servers are available - https://confluence.ihtsdotools.org/display/FHIR/Features+of+Known+Servers

Tells you what features, APIs, etc. that they implement. R5 version almost ready.

IF: This is service software, not individual servers?

DH: There’s links to where some of them stand up. HAPI doesn’t really have a separate FHIR server, as Shahim mentioned.

SE: Needs some customization.

SE: How to start collaborating across these different efforts moving forward? How to regroup and have a bigger community around it? Make sure we’re aware of everything out there.

PR: Be good to think about a common Github software implementation of a lot of these things.Each project has mixed rules and hard to see where they interface. Figure out core software artifacts that need to be developed, make is easier to do pull requests.

SE: In another call, talk about who is using what and where

JR: Coming to you with a request! Given that Beacon v2.0 is using standards from GA4GH, want confirmation that the developers of these standards are happy with their use. Tried to be agnostic to standards, and allow them to be plucked. In this case, involves Phenopackets. What are the considerations?

PR: Be good to have more practical use cases. Would love to hear more about that?

IF: Is there a timeline for this?

JR: We should have recommendations addressed by the end of March.

JJ: Could we have a meet up about the implementation and you can demonstrate? Probably the quickest way.

PR: +1. Would be good to discuss with Connect API.

IF: Could go into the hackathon!

JR: Shall I organize the hour meeting?

[yes!]

IF: And extend to Search.

2022-02-17: Pedigree Subgroup

Chair: Orion Buske, Grant Wood

Attendees “Name (Project Affiliation)”: Alejandro Metke (CSIRO/AGHA), Chen Chen (GA4GH), Meen Chul Kim (CHOP), Tim Jackson (TrakGene), Soichi Ogishima (GEM-Japan), Amanda Spurdle (BRCA), Bing Feng (UUTAH, BRCA), Zornitza Stark (AGHA), David Hansen (CSIRO/AGHA)

Past Tasks:

• Confirm affiliations with pedigree contributors (send email)

• Lindsay

• Add protobuf, Json, FHIR explainer to introduction.rst

• Lindsay

• Work on the minimal dataset doc

• Alejandro, Grant

• Put roadmap document together

• Lindsay

• TrakGene proof of concept (present experience when ready)

• Tim

• Add ERD to the Classes page

• Meen

• For future agenda: outreach push with Redcap

Minutes:

Lindsay to send a reminder to review acknowledgements.

MCK: Will re-arrange and send a ping to merge section by the next meeting.

OB: Working on the two sections for the technical component and the pedigree model. Will flesh those out more. Alejandro, will need your help with the ontology section.

LS: I’ll follow up with Jules about documentation.

Recommended Dataset Document

GW: AM went through this document and brought some great questions forward. The FHIR (GA4GH) column makes so much sense, we didn’t have our own model in there. Going to remove the FHIR (plain). Few cases where we have an element on the left but not in the pedigree model. Might need to make a comment about putting those in in the future. I will add some text to the intro section about the appendix and new section of **

AM: Need to decide whether we be explicit about whether to extend or not.

GW: Would it be easy to extend our model to match these ones?

OB: I think so. Especially for the things that are optional. Goal was always to create the minimum model. Ensure we’re being consistent in messaging, but the trade off is in complexity.

GW: Should we delete element rows? I don’t think we should, it's more of an inspirational document to create a robust tool and repository. Have replaced “minimum” with “common”.

AS: To me, age, DOB and age range are not even optional. Some element of age in the pedigree is important.

OB: In these contexts, we didn't include those because they can be represented in FHIR and Phenopacket environment. Comes back to the line about where we draw the boundary for information about people.

AM: Could call them out explicitly and say this is represented by ‘x’ class in FHIR.

OB: We have a conceptual model of an individual, and this is x /y in FHIR /z in phenopackets. Either we have a third to interoperate, or say we conceptually have this information. Or we leave it out and say it’s handled by these other things. If we call it out, are we saying it’s a separate class. If we were to say use the existing implementation, there’s no mechanism to add additional properties that aren’t handled by Phenopacket or FHIR. Concept of a node that points to an individual rather than an actual individual.

GW: With FHIR you can mix and match resources. Had always thought that’s what we would do with our conceptual model.

OB: My understanding is that’s correct, but the way in which amending or adding on to what’s already there does still define another concept related to an individual, but doesn’t have age because the main individual that would be able to be referenced could have that information in FHIR.

AM: We don’t have an extra individual, just extend the patient. Highlights the complexity of different implementations with different strategies and having to map.

GW: Would suggest, why not come up with a new solution?

AM: Sure, and compare and contrast with Phenopackets.

AS: Getting stuff from one pedigree tool to another is the bane of my life. Anything that can help us is great.

GW: Don’t want to add just another new standard, but a universally accepted one. Break those barriers and come to a technical solution that will share data easily.

OB: There are a few Qs here: how conceptual do we want the conceptual model to be. Do we want it to be usable on it’s own. Hope was that there as a coherent core kernel independent of and could be used to define something that represents a ped file and could be implemented in FHIR or phenopackets. But could also work on its own to a lower degree. Anything that can be shared in Phenopackets and FHIR would not be shared in that core kernel. The other way is looking at it as a true conceptual model and not using it all, then we have an implementation guide for the recommended fields in FHIR and for Phenopackets. Bigger departure than directly implementing the implementation in either of those environments. Loosening the constraints on those two.

AM: I don’t see us having a third implementation. I always thought the protobuf version would be the independent but it became part of Phenopackets.

OB: I think we had meant for it be separate and independent but not Phenopackest in the beginning, just protobuf. Is there a third is the question to some extent, and does it need to handle all of the other things we care about (like age), which is separately structured in FHIR and Phenopackets already. Let’s use diagnosis as an example, do we want to define yet another standard for defining diagnoses so that we can have diagnoses for individuals in a pedigree. We can all agree that’s important information to have in a pedigree. But, if you’re using in FHIR or Phenopackets, that work has already been done. Either going to choose the FHIR or Phenopacket version, or create another that sits in the middle. Would have to do the work Phenopackets-FHIR did twice.

AM: I agree, but in some cases, if we keep at the conceptual level it might reveal gaps. Patient resource in FHIR doesn’t have some of things called out in this document.

OB: So there isn’t a third. Conceptual model is a conceptual model

AM: Would it be useful? What would be gained by the third implementation?

OB: Mixed feelings. Do we go beyond and say here is this file that works on its own, pedigree file that is not a ped file. Piece that you don’t get is a full reduction in mapping complexity, because there’s not one model per se, but you’re always going to have to handle the mapping between a phenopacket and FHIR on the tooling side.

AM: Inherited this problem from discussions in Clin/Pheno when decision was made that the probuf would be a thing that lives outside of FHIR

OB: Back out of the conceptual model to be less technical, less grounded on implementation. Focus less on saying there is any particular implementation in that conceptual model.

AM: Doesn’t mean we can’t eventually work on a third. If there is a need it might help transformations to other models.

OB: Dramatically simplify the process of extending for all of these things in the common data model because we’re not defining them.

GW: The more conceptual you keep it, the more adoption we’ll find.

LS: Do we know of any DPs or initiatives that won’t use in the context of FHIR or Phenopackets? Suggest we go by community needs - if no one needs that third implementation then we don’t need to go there.

OB: No. Agree, I don’t we planned to ever really implement. If we can back that conceptual model into anything that looks like protobuf will be helpful.

OB: There are a number of high level diagrams that we constructed historically and might be still be used that paint that concept in a way that is no longer the way we want to communicate that. Better ways of framing the blue sky architecture. Make the pedigree model less concrete, don’t leave any ambiguity about whether there is another format or not.

Connect Breakout Ideas

OB: Whether or not having a conversation with Discovery/Search. Digging into retrieving more information. Priority of having a conversation with Jules and get his feedback down with incorporating into phenopackets.

GW: Could be something with GKS? Looking long term about connecting with variant data, having a “fun” conversation about the next phase.

2022-02-03: Pedigree Subgroup

Chair: Orion Buske, Grant Wood

Attendees “Name (Project Affiliation)”: Alex Tsai (GA4GH), Chen Chen (GA4GH), Tim Jackson (TrakGene), Alejandro Metke (CSIRO/AGHA), Melissa Cook (NCI), Amanda Spurdle (BRCA), Zornitza Stark (AGHA)

Past Tasks:

• Introduction Page in Docs - add link outs to technical descriptions of protobuf, json, FHIR

• Lindsay

• Revise acknowledgements page, prep an email to contributors to confirm affiliations and “opt-in”

• Lindsay

• Work with Alejandro on completion of the recommended dataset doc

• Grant

• Add ERD to the Classes page

• Meen

• For future agenda: outreach push with Redcap

Minutes:

Documentation Updates

LS: Revised the acknowledgement section to include contributors who did a minimum of one “thing” (eg. attended a meeting, commented on a doc, raised an issue). Made a separate section for those who completed the pedigree driver project survey at the start of the project. I will send around an email next week to confirm affiliations, let me know which ones you want represented, and if you have any funding you want to acknowledge. I also need to add to the “brief explainer” section on the intro page.

General Updates

AM: Will take a look at the minimal dataset document today. Some outstanding tasks on the ontology work. The IG is in pretty good shape, not much to do for an initial release.

https://github.com/phenopackets/phenopacket-schema/blob/pedigree/src/main/proto/pedigree.proto → updated Phenopackets pedigree integration

Implementation Updates

OB: Saw update from David Conlan for open pedigree import/export. Issue now in open pedigree repo.

AM: Working on optional with some working examples. Fixing some functionality plugs.

TJ: Taken one of our families and have a test case. Run it through the conversion tool. Developed a family history questionnaire webapp, patients fill out survey before they come to clinic that auto generates a pedigree.

OB: Proof of concept would be awesome

GW: Share back with us the experience and any issues you come across.

OB: W^[d][e]e wanted to talk about the conversion tooling and Bing’s analysis. There are few different options here but opportunity to get staff support around software dev needs. Where it seemed like their efforts might be most beneficial is around conversion tooling. Updating the tooling to allow export in BODICEA. Beyond that, updated any of the open source resources if valuable, like pedigree validation.

Some sort of CI automated testing would be valuable. Expand those formats to support FHIR and Phenopackets implementations of pedigree.

GW: Is there something we could consider that we can develop some simple tool that could take the ped apps that these Driver Projects use, and convert into our standard? Starting down the path of providing some solution.

OB: Question is what is the best way for the driver projects to deliver this. Goal of the tools repo. We could go further and offer a library but there are so many languages we would want to do this in. Could have a front end app to do conversions

GW: Both great places to start, library and web page.

OB: Chen and Alex could take what is currently there and set up to release as a node module. Now it’s just a repo with command line access. Provide value for web based pedigree solutions.

TJ: Second the idea of a web interface because you’ll get more buy in. Follow the same train of thought of implementing a library you can imbed in something.  

AS: From analysis POV, one has a bunch of data we can’t access. In AUS, family cancer clinics are using a bunch of different tools. Often have to re-enter the pedigree. Sometimes the pedigree is set up for a specific tool.

OB: Benefit perhaps, if we do the client side.. If we leave it as node and release as a module, we could do it as a client side browser plug in. Batch analysis, having a web interface makes it a lot more tangible.

AM: Potential scope down the road for help with the validation stuff.

Roadmap Note

GW: Add note^[f] about doing an HL7 accelerator. Promote the standard outside of the GA4GH community.

2022-01-20: Pedigree Subgroup

Chair: Orion Buske, Grant Wood

Attendees “Name (Project Affiliation)”: Bing Feng (UUtah), Meen Chul Kim (CHOP), Melissa Cook, Zornitza Stark (AGHA), Amanda Spurdle (BRCA), David Hansen (AGHA/CSIRO)

Minutes:

GA4GH Software Dev Projects - please let Lindsay know if you have any other ideas!

Docs

• Acknowledgements: update list with names who have attended at least one call, commented on a document, etc. Lindsay to send an email to confirm affiliations
• Intro: For the intro to protobuf/json/fhir, add a very brief description of each, with a link out to the technical details

MCK: Created a PR with the classes section. Set it as a draft so I have your feedback and thoughts. Not a lot of descriptions per class.

Reflected was I did with the FHIR IG.

OB: Is there a standard or best practice when documenting conceptual models, whether to do it in a hierarchical view?

MCK: Why don’t I add an ERD?

OB: I think that might help people see how they’re related. Make explicit how it would be handled over the wire.

GW: At HL7, different groups would create different classes that would overlap. Had to do some sort of harmonization later.

GW: Concerning the recommended dataset doc, I need to work with AM to get that completed [Action]

Implementations?

OB: We targeted implementations involving tooling and supporting connections. Is that still reasonable? We’ll have Redcap Plugin, a connection between one system to another that runs things off of Phenopackets or FHIR would be the second.  If there was a way to loop in Bing’s implementation either via Bodicea or not, than that is a well rounded set. Is there a group or other tool that people use yours in conjunction with?

BF: There is a group in France that uses my tool with BODICEA.

OB: The canrisk developers, I know they just came out with a new file format. Maybe looping them in might help.

BF: The BODICEA format has been changing, they have one format for each gene.

OB: On our side, can do a Phenotips to Exomiser push.

GW: For redcap, as a lot of research organizations use redcap. Can we consider doing some promotion where we approach research groups and ask if they want to do a pilot.

ZS: I think it’s freely available. We’ve been approached by a lot of other research projects in Australia wanting it. H3Africa uses redcap heavily.

GW: Let’s discuss this further. Put on future agendas [Action]

OB: Can also put pressure on TrakGene and us!

GW: Focus on implementation and adoption for 2022 roadmap.

2021-12-14 - Cohort Rep Report Back Meeting

The minutes for Computable Cohort Representation can be found here.

2021-12-09: Pedigree Subgroup

Chair: Orion Buske, Grant Wood

Attendees “Name (Project Affiliation)”: Alejandro Metke, Meen Chul Kim, Bing Feng, Melissa Cook

Minutes:

Filling out the docs

OB: Happy to do the overview and classes section. Meen and Alejandro, would appreciate your help with the tools and ontology sections

MCK: I volunteer for classes

OB: readthedocs has good support for versioning. Probably want to create a branch and have the community review.

GW: When to connect with HL7? Want to keep the group informed but don’t want them to slow us down.

LS: Can share after GA4GH approval, or via the public open for comment process.

AM: Agreed, public consultation

OB: Getting phenopackets fleshed out. How to get that done. Might need to rope in Jules if he is willing. I could give it a shot.

LS: I can reach out to Jules and lay out a skeleton in terms of communicating that. Get an up to date sense with the recent conversations.

Minimal Dataset Mapping

AM: Made a copy of the doc, made some changes to the table and the appendix. The bit I found a bit confusing is that these data elements seem to be coming from the FHIR family member history resource, and another column about ped and FHIR. But FHIR has three pedigree models. Have a column for each FHIR model for how it will look like. In the FHIR spec, there isn’t any models for reference so I thought it would be useful to compare the three models.

Nodes of the graph are the resources. This is different from the model we’ve proposed. Major differences is that the family member history is not allowed to contain patient information. Also have a composition resource. I think this is helpful to show the different ways to use FHIR.

In the tables, have added additional columns for FHIR, FHIR pedigree and FHIR GA4GH. Can have more meaningful conversations about the gaps.

There are some things here that are not in the conceptual model, so I’m wondering whether they should be here.

GW: Why would the source metadata not be in the conceptual model?

OB: Kept things as simple as possible, but no reason we can’t add it now.  Maybe the thing is to add and move on.

AM: Exactly

OB: The title is minimal dataset, but many things listed here are optional. Should we split these things out. Goal was to be permissive, whereas if we put things here, it could lead to questions about mismatch.

GW: Minimum or Minimal might need to be deprecated. Started with that original work that we called minimal, but what we’ve achieved here is a bit different. Maybe just call it recommended dataset.

AM: Also add a column for saying explicitly, this is part of version 1.0 of the model.

GW: My preference would be to add to the conceptual model. We want to add to the conceptual model to make it more robust and capture more use cases. If it’s not a problem to add, let’s do it.

AM: Could quickly go through the table. Some of these things appear to have come from very FHIR specific things. It’s easy for me to implement in the FHIR IG, but will be more work for Jules.

GW: If you feel like it doesn’t belong in the table part, we can move it. Thinking was to not only include the ped columns but also all of the FHIR resources that were linked. Need to decide what needs to be in the conceptual model. If a particular resources doesn’t help, let's move to the appendix.

OB: There are a lot of different ways we can do this. The data depends on which specific use cases we’re talking about. Happy to review your recommendations Alejandro.

AM: Happy to have a go and set some for review.

Most of the extra comments are around that.

Intention of the extensions was to connect each node to those closest.

OB: But can also re-base that. Can do the parent-child relationships and sibling-siblings.

AM: Still need to point at the proband. So if you go mult generation, still need that node with the patient. One hop type relationships. That’s why I think our approach works better.

GW: As we talk to people like HL7, that will be a major point to share with them.

AM: ped had maternal and paternal id, but those don’t fill well in the individual table because they’re nodes in the graph

OB: have a relationship table?

AM: In the conceptual model, sex at birth and the HL7 defiintion is a bit wider. At this level, maybe adopt a higher level. Should match whatever is in the conceptual model. Most of the other comments are about stuff not in the conceptual model, but we’ve already discussed this.

Work off of the new doc.

Lindsay will add link to the new doc from the old one.

https://docs.google.com/document/d/1GQRd5jeZeB5qhHclLZxDe6kPD173bXWGYlTsmCbTeuI/edit

AM: Made a pull request, Orion to review. Five issues outstanding. Might review offline. 1 PR, 2 comments, and two more to go.

Feedback from Soichi - feels uncomfortable with the term gestational carrier. I looked at the definitions. Really depends on the definition that we want to give to gestational carrier. Found one definition that implies IVF. The current hierarchy we have is wrong if we follow that definition.

OB: Was trying to get at the concept of being explicit about the ways people are biologically and environmentally related to offspring. Sounds like it needs to be pulled down and we need a different term for that parent.

AM: I’ll have a look and open a PR. Other ones are pretty straightforward.

OB: Gestational parent?

AM: Yes, might just be avoiding a term with social implications.

GW: Maybe ask a genetic counselor.  

2021-12-02: Computable Cohort Representation - PHENO Team

Minutes: The minutes for Computable Cohort Representation can be found here.

2021-12-02: Computable Cohort Representation - MIACC Team

Minutes: The minutes for Computable Cohort Representation can be found here.

2021-11-11: Pedigree Subgroup

Chair: Orion Buske, Grant Wood

Attendees “Name (Project Affiliation)”: Meen Chul Kim, Katherine Johnston, Zornitza Stark, Alejandro Metke, Bing Feng, David Hansen

Minutes:

KJ: Dug into the project’s collecting pedigree data, disappointed to find so little pedigree data in it. Haven’t heard back from Guida yet. Next step is to communicate with all of the projects about the standards. In terms of implementation, play around with the redcap component and get the projects who are collecting to try it out. Mamana mentioned he heard about a group in Ethiopia interested in collecting pedigree data and were working on something.

GW: I’m aware of a project being done in Ethiopia with U of Michigan who have developed a mobile based family history collection app. Data gets stored on a server back in Michigan, but they provide the data back to doctors in Ethiopia.

KJ: Potentially, Manana mentioned a software group.

[Lindsay to check in with TrakGene]

[Lindsay to send slides about Pedigree to Katherine]

Validator Repo

AM: Command line to validate an instance of a pedigree. Java app using Hapi libraries. Read a pedigree JSON in FHIR and shows anything non compliant. Make sure codes align with the right ontology. Shows how to include validation from ontology reasoner. Instructions on how to run are included. Let me know about any feedback.

OB: Is the scope of the repo is that it will validate in multiple formats, or is it mostly focused on FHIR?

AM: No reason we couldn’t include other formats in there. Original scope was just the IG. No need to create new repo.

Ontology Comments

AM: Got additional comments from Chris Mungall. Took a bit of time like adding natural language. Five things outstanding, should be able to quickly go through.

Documentation

OB: Maybe merge Model and Classes together? Or expand classes

MCK: Happy to help set up the skeleton.

Just created an empty ticket: https://github.com/GA4GH-Pedigree-Standard/pedigree/issues/14 will fill out descriptions.

Minimal Dataset Doc

GW: Want this group to happy with a good version 1.0. In the documentation we explain that it’s a living doc and we’ll review over time. Went through and cleaned up some sentences that weren’t very clear. Made a few formatting changes as well. Is at the point where we’d like to subgroup to approve.

OB: Can we resolve the red text in one way or another?
GW: Yes, I don’t describe that well in the document. My intend it to highlight the gaps.

LS: Move the red text to the notes?

OB: Depends on the framing as well. From the perspective of us putting this out, it isn’t on us to make this change to FHIR, nor is it on use to say FHIR needs this change, but we can say that there is a gap.

AM: Descriptions are not aligned with choices made in the model. We should highlight gaps, and moving forward, we really can’t modify the base FHIR resources.

GW: First point is critical, seeing things that aren’t matching the model. Since you have that knowledge of the model, could you help with this?

AM: Can add comments to the doc.

GW: Go right in and make the correct change.

GW: If anyone wants to add in a paragraph that describes the best method please do that.

2021-11-02: Computable Cohort Representation - PHENO Team

Minutes: The minutes for Computable Cohort Representation can be found here.

2021-10-28: Pedigree Subgroup

Chair: Orion Buske, Grant Wood

Attendees “Name (Project Affiliation)”: Zornitza Stark (AGHA), Bing Feng (UUtah), Melissa Cook (NCI), Meen Chul Kim (CHOP)

Minutes:

Updates from AM (via email):

• The REDCap pedigree plugin has been updated based on the FHIR IG, so it should be ready for the approval process. We are adding some more features at the moment and we will release a new version in the next couple of weeks.
• I am happy to contribute the command line validator tool that I showed during Connect. If you create a GitHub repo for me I can upload it there (you can call it pedigree-validator).
• I have no strong preference regarding the way we write documentation.
• I have been going through the different issues in the KIN ontology and solved most of them. There is a bit more work to do but I think it is stable enough to be usable.

Connect Feedback

GW: Everything went well! What do people think if we did a demo again in the near future? What would we want to add?

OB: Having more examples of direct support of the standard. Tooling that patched some of that. Would be compelling to have the standard used directly.

GW: What the group needs to focus on next.

OB: Redcap - getting cross talk between the different tools.

GW: G2MC - had a presentation from Brazil using the Redcap pedigree plugin. Would it be helpful to have these people talk about it?

ZS: Would be interested to hear how others are using it

GW: Use case was general practice/primary care type stuff. Had a focus on cancer. I think he was a physician from Sao Paulo.

OB: GA4GH Staff software dev support?

LS: Will follow up after this call with Yash and Jeremy

OB: BODICEA support, is there a way we can support you to import this data through Phenopacket.

BF: Yes, decided to use Phenopacket. Need guidance and documentation. Use the modules from Phenopackets to integrate, using C++. Haven’t connected with Jules about C++.

MCK: When we first modelled in FHIR, discussion about family member history vs observation. We’re now discussing implemented our model into the KF FHIR server. What we implemented before was just the relationships between patients. No deadline yet. We released our FHIR server as open access.

Need to check in with H3Africa & TrakGene on implementation/testing.

OB: Putting the documentation into place for how we see and expect people to use this with FHIR or Phenopackets. Can leverage Phenopackets docs. Align with Jules on

Doc preferences?

• Question of the extra work to implement in a form with usability on readthedocs
• Aim for more lay language, but making the techy information available

MCK: How to integrate with the Phenopackets FHIR IG?

LS: I will connect with the Phenopackets IG team, plan for an update session in November.

Lindsay to draft a documentation outline for next meeting.

MCK: I like to readthedocs website, can help with the deployment

OB: AM added definitions to all of the terms, incorporated additional terms based on the open pedigree.

Let’s follow up with AM on Soichi’s comments - go through them on the next call.

OB: Would it be helpful to give a visual summary of the ontology representation?

ZS: Visual always helps.

MC: Agree

OB: Get the Shrimp reference for KIN

Minimal Dataset Document

GW: Go through one more time, create a final version (formatting, final errors).

LS -> check process for minimal dataset approval

GW: Not a companion for the schema itself. Want people to know the document is separate. Talks about high level issues. I will finish this up.

Lindsay to move the full WS meeting to the following week - Dec 1st.

2021-10-19: Computable Cohort Representation

Minutes: The minutes for Computable Cohort Representation can be found here.

2021-10-12: GA4GH Connect

Minutes for each breakout can be found below:

Pedigree Implementation Demo

Computable Cohort Representation

Clin/Pheno Roundtable

2021-10-05: Computable Cohort Representation

Minutes: The minutes for Computable Cohort Representation can be found here.

2021-09-30: Pedigree Subgroup

Chair: Orion Buske, Grant Wood

Attendees “Name (Project Affiliation)”: Moni Munoz-Torres (Monarch), Meen Chul Kim (CHOP), Bing Feng (UUtah), Alejandro Metke (CSIRO/AGHA), David Hansen (CSIRO/AGHA), Guida Landoure (H3Africa)

Minutes:

Planning for Connect:

OB: Draft agenda, feedback welcome. Kicking it off with Lindsay - welcome + intros (depending on the number of people the room. Orion to do the intro, Grant the talking about the minimal dataset.

Hand off to Alejandro to talk about the terminology and FHIR IG, and start off the demos with the data collection demo with the REDcap integration.

Then to data management and data analysis. DO we want more guidance on what we’d like to solicit from the crowd.

GW: Be prepared with some questions if people are shy. First thought is to allow everyone to see the whole picture, and then comment on the whole picture.

[Lindsay to check registration]

GW: Would be nice to learn if they are using pedigree and if anything is helpful to them.

LS: Community input, getting interest in engagement

MMT: Hopefully we’ll talk to some people we don’t usually interact with, do some use case collection from the crowd.

DH: Requirements as well. Also interested in analytics they want to do on top of pedigrees.

AM: Missing a section that might correspond to the native implementation of the pedigree.

OB: Split out the terminology from the IG. Branch in the phenopackets github that has pedigree implemented in it.  Ask Jules if it makes sense to share this [Moni to reach out to Jules about this + Exomiser].

MMT: Important to highlight it’s not implemented on the main branch. Important to get from the community what they would need from such a connection.

GW: Want to go through fairly quickly. 5 minutes max on the minimal dataset doc.

OB: How people can use the doc and any findings we had.

Presenting terminology - what to share?

AM: Could add slides or just use the github, have a live instance. Talk about the process and how the current output was organized.

OB: DO you feel comfortable for the motivation of it being an ontology?
AM: Yes

MCK: Given 10 min, I’m ready to go over demo, implementation and live query. Concerned about the selling point.

OB: Happy to talk through this now. One of the ways of talking about this is that it provides a way of recording robust FHH information in the context of FHIR, which ped does not have. That is valuable from a data management perspective that KF can talk to.

MCK: I agree with that. Will demo in FHIR. Based on my prior experience, wasn’t able to come up with a good selling point.

OB: Might be that we’re not quite there, and that’s ok. Still in early days of some of this. When contextualizing with the KIN terminology and FHIR, that works.

GW: Test environment for the pedigree work we’re doing. Could be a goal or next step. Not thinking as far as a starter kit.

AM: We have multiple FHIR servers we use - HAPI, our own version of HAPI, SMILE for some projects. If I have the time I might show how validation will work, but it might not be ready. Basis of some sort of test environment. Command-line application where you could consume the IG.

BF: Still don’t see the export to BODICEA

OB: Will make sure we get that done. If you have any cycles, it’s just about adding support for a new export type in the tool repo. I think it can import almost all of the columns. Some of the columns are outside of the existing conceptual model.

BF: Run with the example sent to Alejandro

OB: What’s the best way to show what this looks like?

BF: Need to describe cosegregation analysis, how it is used, then run the analysis within the website.

MMT: I’m less familiar with the inner workings of EXOMISER, but could potentially present in Jules’ place.

2021-09-21: Computable Cohort Representation

Minutes: The minutes for Computable Cohort Representation can be found here.

2021-09-16: Pedigree Subgroup

Chair: Orion Buske, Grant Wood

Attendees “Name (Project Affiliation)”: Bing Feng (UUtah), Alejandro Metke (CSIRO/AGHA), David Hansen (CSIRO/AHGA), Kathryn Van Diemen (TrakGene),

Update from Meen:

RE FHIR, I found another KFDRC project (also released on dbGaP) having more complex pedigree examples. Details:

• Study: GMKF: Congenital Cranial Dysinnervation Disorders (CCDD) and Related Conditions
• PI: Elizabeth Engle
• dbGaP URL: https://www.ncbi.nlm.nih.gov/projects/gap/cgi-bin/study.cgi?study_id=phs001247.v1.p1
• FHIR resources:

• Individuals (FHIR Patient resources): 899 (270 probands)
• Relationships (FHIR FamilyMemberHistory resources): 772 (uni-directional, 27 types)

• Aunt-in-Law: 1 (REL:019)
• Brother: 29 (REL:007)
• Cousin: 1 (REL:014)
• Daughter: 5 (REL:032)
• Father: 327 (REL:028)
• Husband: 1 (REL:026)
• Maternal Aunt: 3 (REL:013)
• Maternal Cousin: 10 (REL:015)
• Maternal Grandfather: 4 (REL:017)
• Maternal Grandmother: 6 (REL:017)
• Maternal Granduncle: 3 (REL:002)
• Maternal Great-Grandmother: 1 (REL:018)
• Maternal Half-Sister: 2 (REL:013)
• Maternal Uncle: 2 (REL:013)
• Mother: 334 (REL:027)
• Nephew: 2 (REL:002)
• Other: 1
• Paternal Aunt: 3 (REL:013)
• Paternal Grandfather: 1 (REL:017)
• Paternal Grandmother: 1 (REL:017)
• Paternal Uncle: 1 (REL:013)
• Sister: 24 (REL:007)
• Son: 3 (REL:032)
• Spouse: 4 (REL:026)
• Twin Brother: 1 (REL:010)
• Uncle-in-Law: 1 (REL:019)
• Wife: 1 (REL:026)

• Diseases (FHIR Condition resources): 359 (5 kinds)

• CFEOM
• CFP
• DRS-HGP
• Moebius
• Ptosis

• Pedigrees (FHIR Composition resources): 270 (23 families with more than trios)

Query results against one proband patient here:

Individual (Patient) 

Relationship (FamilyMemberHistory)

Condition

Pedigree (Composition) resources

This family is one of the pedigrees having the most complex relationships:

• There are 8 family members (including the proband)
• They have 12 one-directional relationships between them (among them, the attached Relationship resource below contains 7 relationships regarding the proband)

Minutes:

Preparing the minimal dataset doc for the toolkit. Next steps involve:

• Finalizing the doc and making sure the Pedigree subgroup & Clin/Pheno WS overall are supportive
• Post it for public open comment
• Resolve any comments that come in. If there are significant changes, we may need a second Pedigree Subgroup/ full WS approva.
• Presentation at Steering Committee, with SC vote/approval

GW: Add in a slide for the minimal dataset document

How should we organize the demo?

AM: Spin up a redcap instance and show how to collect a pedigree. Would show the graphical representation, go back into the form. How the conversion tooling will interact with that component. The way that the plugin works, if you interact manually, should store the FHIR representation. Not sure how to show the demo because this happens on the backend.

OB: Manually download or export for visual purposes.

AM: Yes. Redcap has some licensing constraints, not sure if it’s a problem and we should check. Make sure that we’re not in violation of any constraints.

GW: The licensing shouldn’t restrict anyone from doing a demo? Are you going to be the person to do this part of the demo?

AM: I’m happy to participate in the ingestion bit. Show how sample pedigrees are collected, then hand over to Orion and Grant.

OB: I don’t there should much of the demo on conversion tooling. Bing - we’ll be doing everything to ad BODICEA v4 export support between now and the next few weeks. Would be great if you could then take one of these files and run cosegregation analysis on this. Focus on look, we have pedigree data going from collection to interoperability to all of these different tools.

BF: Definitely.

OB: Trakgene has been poking at the pooling and found a bug already with import functionality.

AM: Need an example that makes sense for the analysis tool. Bing, if you can send a pedigree along I can get things pre-populated.

BF: Yes, I’ll create an example pedigree and send out.

GW: How do we fit in Trakgene and FHIR in.

OB: Might be this bit of taking input to analysis. Could have research systems and their angle.

GW: I think that makes the most sense.

OB: Meen would be serving this data via FHIR, is there a consumer of that we could pair it up with.

AM: Exomiser could be one of the candidates? It would have to go back through ped.

OB: Weak flex of various functionality to take rich representation in FHIR and cut it down to ped. Anything in terms of terminology that you’d like to show off?

AM: I just made some changes, this prefix is now different (KIN). ** Would be good to try and do some validation. Not hard to implement.

OB: Something obvious like a logically inconsistent family.

AM: Only concern is that because if we’re using OpenPedigree there are limitations on creating the families. Might have to show a drawn pedigree or some hypothetical.

OB: Maybe Meen has an example where his QC caught something.

AM: If Meen can provide an interesting example I can take a look. I can have a go at having a component that takes in a pedigree an outputs validation results.

OB: Yes, almost a proof of concept to get people thinking about capabilities.

Lindsay - Send Soichi a copy of slide 12 and see where he might fit in.

For Trakgene, is everything moving forward to be able to show something or fit into this story?

KVD: Realistically we might not get to the import side in time. Probably the bit we can show is similar to the redcap story. Perhaps have AM take the lead and note that there are other systems doing similar things.

OB: PhenoTips would be in a similar perspective as well. Happy to share a slide or add in some videos. Would prefer RedCap is demo’d, then talk about other support for other systems.

Lindsay to reach out to Jules about Phenopackets piece of demo.

OB: If we can do an import and either map to phenopacket or ped with the tooling. If there’s something else he had in mind it would be great to get his feedback.

AM: Two use cases - inferring higher order relatedness, kind of what I’m already doing the test cases. Just need more examples. Want to follow up on the second use to see if we can get more details. Never thought we’d get into the problem of figuring out who someone is, might not be something we can solve with the reasoner. Get a concrete example of where that happens.

Worth having a slide on calling for use cases. Frame in a way that already have a core set of use cases.

OB: A slide about how to be engaged - show that it exists in the Github and where user stories are,

GW: Have we reached out to Driver Projects?

LS: Yes, I can reach out to the folks that originally filled out the survey

GW: I can take a look through the use case document and pull some pieces out.

AM: Initially I had a quick look and there are interesting changes but not too difficult. I think some of those are good for getting started with.

OB: Meen and KF might have some additional cycles as well.

2021-08-19: Pedigree Subgroup

Chair: Orion Buske, Grant Wood

Attendees “Name (Project Affiliation)”: Alice Mann (GA4GH), Elizabeth Janes (GA4GH) , Katherine Johnston (H3Africa/H3ABioNet), David Hansen, Moni Munoz-Torres (Monarch Initiative), Melissa Cook (NCI/CRDC), Meen Chul Kim, Bing-Jian Feng