FHIR Chat · Connectathon 24 · genomics

Stream: genomics

Topic: Connectathon 24

Jamie Jones (May 12 2020 at 19:42):

Hi all, we will place important links and updates in this stream. Stay tuned!

Jamie Jones (May 13 2020 at 15:29):

We've got a google sheet with helpful links we'll update for those taking part in the genomics track here https://docs.google.com/spreadsheets/d/1ahPqAtcv8Kwfwwkeoulhi4HUilUPneXRi3pnD2fRPG4/
It has a tab "Participants" where everyone should write in their info and goals and a tab for "Attendance" outlining a few points when we're planning on widely meeting, including a "kick-off" meeting tomorrow at 9:30AM ET.

Patrick Werner (May 14 2020 at 11:24):

thanks. Added links to the molit testserver and our variant-viewer preview.

Kevin Power (May 14 2020 at 13:15):

Hello all Genomic Track connectathon attendees. We will be having our own kick off call in 15 minutes! Please see the spreadsheet on the Helpful Links tab for our Zoom room:
https://docs.google.com/spreadsheets/d/1ahPqAtcv8Kwfwwkeoulhi4HUilUPneXRi3pnD2fRPG4/

There is also a Participants tab for anyone planning on attending our track. So far I see @Jamie Jones @Bob Dolin @Patrick Werner @Alexander Mankovich signed up.

Talk soon!

Jamie Jones (May 14 2020 at 13:25):

@Patrick Werner Your server doesn't seem to support transaction bundles... what's the workaround for this? (i'm used to the examples in our build)

Patrick Werner (May 14 2020 at 13:26):

It does. How did you try? What was the error?

Patrick Werner (May 14 2020 at 13:27):

used transaction bundles against it yesterday

Jamie Jones (May 14 2020 at 13:27):

i may be a goof have the wrong headers/endpoint, "Unable to store a Bundle resource on this server with a Bundle.type value of: transaction"

Patrick Werner (May 14 2020 at 13:27):

ahhh! you want to persist a bundle?

Patrick Werner (May 14 2020 at 13:28):

to process transaction bundles you have to send it against the server base, in this case: https://fhir.molit.eu/fhir

Jamie Jones (May 14 2020 at 13:28):

Thanks! just want to save the entries :innocent:

Patrick Werner (May 14 2020 at 13:29):

ok, try it against base (thats why sending them to /bundle is disabled, to prevent unexpected behavior when trying to process bundles)

Patrick Werner (May 14 2020 at 13:30):

im already waiting for the zoom host :-)

Jamie Jones (May 14 2020 at 14:06):

(deleted)

Jamie Jones (May 14 2020 at 14:09):

(brief breakout for IM group at https://zoom.us/j/2980068716)

Bob Dolin (May 14 2020 at 14:22):

@Kevin Power @Jamie Jones I can open back up the connectathon zoom if someone could send me the credentials?

Bob Dolin (May 14 2020 at 14:38):

I added a couple tabs to spreadsheet

Bob Dolin (May 14 2020 at 14:38):

List of 300 patients in GACS server, including family relationships: https://docs.google.com/spreadsheets/d/1ahPqAtcv8Kwfwwkeoulhi4HUilUPneXRi3pnD2fRPG4/edit#gid=706561726

Bob Dolin (May 14 2020 at 14:39):

These are WGS data from 1000 Genomes, all public data.

Bob Dolin (May 14 2020 at 14:39):

and here's a list of LDLR pathogenic variants which can be used for ACMG screening: https://docs.google.com/spreadsheets/d/1ahPqAtcv8Kwfwwkeoulhi4HUilUPneXRi3pnD2fRPG4/edit#gid=1504996970

Kevin Power (May 14 2020 at 14:40):

Bob Dolin said:

Kevin Power Jamie Jones I can open back up the connectathon zoom if someone could send me the credentials?

Sent via email

Arthur Hermann (May 14 2020 at 15:02):

@Bret H I only see a few people signed up on the participants tab - I am registered as an observer... do you want everyone participating today to add their name to that participants tab.?
.. because few have

Jamie Jones (May 14 2020 at 15:04):

please do! helps to state goals. the line is open again now, we'll try to keep it open as much as possible

Bob Dolin (May 14 2020 at 15:04):

@Bret H Here is the call that lets you see our supported RefSeqs: https://api-gacs.elimuinformatics.com/gacs/refSeq/?build=37

Arthur Hermann (May 14 2020 at 15:05):

@Jamie Jones - which line do you mean a zoom line? if so - sorry can you put the link here (again)?

Jamie Jones (May 14 2020 at 15:06):

https://zoom.us/j/3176111369

Bret H (May 14 2020 at 15:08):

Bob Dolin said:

Bret H Here is the call that lets you see our supported RefSeqs: https://api-gacs.elimuinformatics.com/gacs/refSeq/?build=37

given a build get back which refseqs are supported by the server. very useful in carrying out FindSubject variant operation

Kevin Power (May 14 2020 at 15:24):

For anyone wanting to watch other tracks, see here:
https://confluence.hl7.org/display/FHIR/2020-05+Zoom+Info+for+Each+Track

Jamie Jones (May 14 2020 at 15:32):

and for anyone interested in a very dodgy and barebones ACMG screening result report, https://fhir.molit.eu/fhir/DiagnosticReport?_id=278783&_pretty=true was generated from https://api-gacs.elimuinformatics.com/gacs/refSeq/?build=37

Bret H (May 14 2020 at 15:33):

@Arthur Hermann Here's an example from NCBI of getting a Gene's position Gene: LDLR
URL: https://www.ncbi.nlm.nih.gov/gene/3949
Look for this information to see the Build 37 reference and position for querying LDLR variants GRCh37.p13 (GCF_000001405.25) 19 NC_000019.9 (11200037..11244506)

Bret H (May 14 2020 at 15:33):

this could also be done programmatically

Bob Dolin (May 14 2020 at 15:40):

@Arthur Hermann Here is the query we just ran: https://api-gacs.elimuinformatics.com/gacs/variants/HG00403/?start=100000&end=200000&refSeq=NC_000001.10

Kevin Power (May 14 2020 at 15:46):

@Patrick Werner -- Wow. I just looked at our qa file in the current build, and we only have 3 errors! Did you fix all the LOINC errors in the current build as well?

Patrick Werner (May 14 2020 at 15:46):

nopes (wish it had been me)

Patrick Werner (May 14 2020 at 15:49):

i think this was caused by the continous improvement of the validator?

Kevin Power (May 14 2020 at 15:51):

You should have totally taken credit for it :slight_smile:

Jamie Jones (May 14 2020 at 15:51):

i think he did log the request on their end :blush:

Bret H (May 14 2020 at 15:58):

@Arthur Hermann http://build.fhir.org/ig/HL7/genomics-reporting/find-subject-variants.html this is the findsubject operation

Bob Dolin (May 14 2020 at 16:08):

I added another tab, so that you could look up the build37 refSeq and start and end positions for your favorite gene: https://docs.google.com/spreadsheets/d/1ahPqAtcv8Kwfwwkeoulhi4HUilUPneXRi3pnD2fRPG4/edit#gid=1404529341

Jamie Jones (May 14 2020 at 16:09):

@Bob Dolin what do you think, how did my brute force query do finding the pathogenic variants planted in HG00403?

Bob Dolin (May 14 2020 at 16:11):

@Jamie Jones I can see I'm going to have to give you harder challenges next time :-)

Jamie Jones (May 14 2020 at 16:11):

@Patrick Werner !! it looks like https://fhir.molit.eu ate my extensions !?

Bob Dolin (May 14 2020 at 16:11):

maybe I should introduce an indel pathogenic variant.

Jamie Jones (May 14 2020 at 16:11):

there should be 2 related artifact instances on each implication, though it could very well be user error ;)

Bob Dolin (May 14 2020 at 16:13):

You won't necessarily be able to directly compare an indel against ClinVar without some type of normalization.

Jamie Jones (May 14 2020 at 16:13):

i would 100% miss those :)

Kevin Power (May 14 2020 at 16:17):

I have started a barebones report out slide deck. As everyone does their thing, it might be good to collect some thoughts and evidence here:
https://docs.google.com/presentation/d/1FuuYfZEQNSnXYhf-bnnuYEpap4vMaPfzApbxBafZ6jk/edit?usp=sharing

Bob Dolin (May 14 2020 at 16:18):

@Jamie Jones Have you played around with NCBI SPDI services? https://api.ncbi.nlm.nih.gov/variation/v0/

Bob Dolin (May 14 2020 at 16:18):

I haven't felt the need to add a SPDI component into the IG (yet another representation of a variant), but I do find it to be a very useful normalization format.

Jamie Jones (May 14 2020 at 16:23):

I like SPDI, wonder if we could use it in component:variation-code (system ~ SPDI) it seems just as calculable as HGVS to me

Patrick Werner (May 14 2020 at 16:24):

Jamie Jones said:

Patrick Werner !! it looks like https://fhir.molit.eu ate my extensions !?

really?

Jamie Jones (May 14 2020 at 16:24):

my python spaghetti-code probably formulated them wrong, inspecting the output json...

Sandy Vance (May 14 2020 at 16:25):

Kevin Power said:

I have started a barebones report out slide deck. As everyone does their thing, it might be good to collect some thoughts and evidence here:
https://docs.google.com/presentation/d/1FuuYfZEQNSnXYhf-bnnuYEpap4vMaPfzApbxBafZ6jk/edit?usp=sharing

Be sure to also fill out your track report here: https://docs.google.com/document/d/1B6FvP5IP83tuUPvOMQjZIR5jYyw4OSbahgRqnbkPZZ8/edit

Bret H (May 14 2020 at 16:25):

technically, SPDI could go into variation-code. The calling out of HGVS is historical and due to common use. ... perhaps we should open the HGVS compoenents to SPDI. But aren't SPDI expressed as HGVS just HGVS?

Patrick Werner (May 14 2020 at 16:28):

i would put all syntax based codings in one comonent, having a seperate one variants defined by ID

Bret H (May 14 2020 at 16:29):

As long as there is a code system

Patrick Werner (May 14 2020 at 16:29):

technically this would mean a VS constiting of HGVS, SPDI and maybe ISCN

Jamie Jones (May 14 2020 at 16:29):

could that even BE a VS though?

Kevin Power (May 14 2020 at 16:29):

We were just talking about this on the call :slight_smile: and I agree with @Patrick Werner

Patrick Werner (May 14 2020 at 16:30):

Jamie Jones said:

could that even BE a VS though?

BE ? (sorry for my ignorance)

Bret H (May 14 2020 at 16:30):

ISCN Is a special use case

Patrick Werner (May 14 2020 at 16:30):

ah

Patrick Werner (May 14 2020 at 16:30):

be like beeing, thought thats another CS :D

Patrick Werner (May 14 2020 at 16:31):

Jamie Jones said:

could that even BE a VS though?

sure. Add it here: http://build.fhir.org/ig/HL7/genomics-reporting/valueset-hgvs.html

Patrick Werner (May 14 2020 at 16:31):

(and rename the VS ofc)

Bret H (May 14 2020 at 16:31):

but yeah, i agree that ISCN is another 'syntactic based coding'...oh and GLstrings got placed into component:variation-code by Bob M I think

Patrick Werner (May 14 2020 at 16:32):

@ Bob Milius had to do it that way because the other is required bound to hgvs only atm

Bret H (May 14 2020 at 16:33):

so we're talking about removing the limitation on the HGVS component. Which does make sense. However, LOINC Is historic

Patrick Werner (May 14 2020 at 16:33):

Bret H said:

ISCN Is a special use case

i agree, but we are only having a single variant profile (which i like), so enabling special use-cases should be on our agenda

Bret H (May 14 2020 at 16:34):

and was precoordinated with HGVS

Kevin Power (May 14 2020 at 16:35):

Grouping all the HGVS's and even extending it to be 'syntax representations' would need a new LOINC code.

Kevin Power (May 14 2020 at 16:35):

However, on the call, @Bob Dolin had some interesting points that he will be weighing in with shortly.

Kevin Power (May 14 2020 at 16:48):

RE: Connectathon report out. I have removed the slides presentation I referred to earlier, and will now refer everyone to this page, which seems to be the document for the entire Connectathon:
https://docs.google.com/document/d/1B6FvP5IP83tuUPvOMQjZIR5jYyw4OSbahgRqnbkPZZ8/edit

Kevin Power (May 14 2020 at 16:49):

Ha, and now I see @Sandra Vance referred to this above (sorry, am getting swamped in all the Zulip updates :slight_smile:)

Jamie Jones (May 14 2020 at 17:01):

@Patrick Werner issue was my end with the polymorphic types--i supplied the relatedArtifacts as 'value' instead of valueRelatedArtifact. Is there any way to update the instances through base? (or do I have to go through /Observation?)

Patrick Werner (May 14 2020 at 17:03):

easiest would be to just reapply a bundle

Patrick Werner (May 14 2020 at 17:03):

which results in a new DR

Jamie Jones (May 14 2020 at 17:04):

...but then my mistakes will be immortalized...

Patrick Werner (May 14 2020 at 17:04):

or you have to (conditionallly) update the resources (in a update transaction bundle)

Patrick Werner (May 14 2020 at 17:05):

you can delete the obsolete DR? To cover up your mistake alittle

Kevin Power (May 14 2020 at 17:07):

I think Patrick could just:

drop database;
commit;

:slight_smile:

Patrick Werner (May 14 2020 at 17:13):

no i can't, then i would have to reupload everything :explosion:

Kevin Power (May 14 2020 at 17:14):

heh heh, yea, snarky comment withdrawn :slight_smile:

Patrick Werner (May 14 2020 at 17:14):

loinc alone took ages to process (to be fair it is all of loinc, with every conceptmap and anwer VS)

Patrick Werner (May 14 2020 at 17:14):

:party_ball:

Kevin Power (May 14 2020 at 17:16):

RE: report out - Here is a link to the skeleton about the Genomics track: https://docs.google.com/document/d/1B6FvP5IP83tuUPvOMQjZIR5jYyw4OSbahgRqnbkPZZ8/edit#heading=h.21khfxwu0l6n

Jamie Jones (May 14 2020 at 17:19):

@Patrick Werner
I'm getting
{ "severity": "error", "code": "processing", "diagnostics": "The Extension 'http://hl7.org/fhir/uv/genomics-reporting/StructureDefinition/RelatedArtifact' definition is for a simple extension, so it must contain a value, not extensions", "location": [ "Bundle.entry[0].resource.extension[0][url='http://hl7.org/fhir/uv/genomics-reporting/StructureDefinition/RelatedArtifact']", "Line 1, Col 223" ] }, { "severity": "error", "code": "processing", "diagnostics": "ext-1: Must have either extensions or value[x], not both [extension.exists() != value.exists()]", "location": [ "Bundle.entry[0].resource.extension[0]", "Line 1, Col 223" ] },
for
{ "url": "http://hl7.org/fhir/uv/genomics-reporting/StructureDefinition/RelatedArtifact", "valueRelatedArtifact": { "type": "citation", "url": "https://www.ncbi.nlm.nih.gov/medgen/C2713442" } }
Any thoughts?

Patrick Werner (May 14 2020 at 17:22):

looks good to me..

Patrick Werner (May 14 2020 at 17:24):

do you have multiple extensions wrapping each other? thats what the error suggests

Jamie Jones (May 14 2020 at 17:24):

"resource": { "id": "ebc4f401-5754-4da3-a1f8-99a4beac954a", "extension": [ { "url": "http://hl7.org/fhir/uv/genomics-reporting/StructureDefinition/RelatedArtifact", "valueRelatedArtifact": { "type": "citation", "url": "https://www.ncbi.nlm.nih.gov/medgen/C2713442" } }, { "url": "http://hl7.org/fhir/uv/genomics-reporting/StructureDefinition/RelatedArtifact", "valueRelatedArtifact": { "type": "derived-from", "url": "https://www.ncbi.nlm.nih.gov/clinvar/variation/265415" } } ], "code": { "coding": [ { "code": "diagnostic-implication", "system": "http://hl7.org/fhir/uv/genomics-reporting/CodeSystem/tbd-codes" } ] }, "component": [ { "code": { "coding": [ { "code": "93044-6", "system": "http://loinc.org" } ] }, "valueCodeableConcept": { "text": "criteria provided, single submitter" } }, { "code": { "coding": [ { "code": "53037-8", "system": "http://loinc.org" } ] }, "valueCodeableConcept": { "coding": [ { "code": "LA26332-9", "display": "Likely pathogenic", "system": "http://loinc.org" } ] } }, { "code": { "coding": [ { "code": "81259-4", "system": "http://loinc.org" } ] }, "valueCodeableConcept": { "coding": [ { "code": "175100", "display": "Adenomatous polyposis coli ", "system": "http://omim.org" } ] } }, { "code": { "coding": [ { "code": "79742-3", "system": "http://loinc.org" } ] }, "valueCodeableConcept": { "coding": [ { "code": "LA24640-7", "display": "Autosomal dominant", "system": "http://loinc.org" } ] } } ], "derivedFrom": [ { "reference": "Observation/0fd6858a-b97c-43ba-9d25-5338ad732380" } ], "status": "final", "subject": { "reference": "Patient/388fe40d-f37a-457e-bbc1-a3e4f385c578" }, "resourceType": "Observation" } }

Jamie Jones (May 14 2020 at 17:28):

do you have any examples on there with extensions implemented?

Patrick Werner (May 14 2020 at 17:29):

nope

Patrick Werner (May 14 2020 at 17:29):

you are missing "resourceType" : "Observation" in the entry, right?

Patrick Werner (May 14 2020 at 17:29):

ah no, at the bottom

Jamie Jones (May 14 2020 at 17:30):

no, it was fine with it coming at the end. we resolved the reference issues, last on my list is extension.value

Jamie Jones (May 14 2020 at 17:30):

i wonder if it still wants .value instead of .valueRelatedArtifact

Bret H (May 14 2020 at 17:30):

"The Extension 'http://hl7.org/fhir/uv/genomics-reporting/StructureDefinition/RelatedArtifact' definition is for a simple extension, so it must contain a value, not extensions""

Bret H (May 14 2020 at 17:31):

what does the definition say?

Bret H (May 14 2020 at 17:31):

@Patrick Werner @Jamie Jones notice that it points to UV genomics

Bret H (May 14 2020 at 17:31):

is that correct?

Patrick Werner (May 14 2020 at 17:32):

yeah sure. The extension profile is fine, it is a simple Extension, Jamie is using it as a simple extension

Patrick Werner (May 14 2020 at 17:32):

Success...validating /Users/patrickwerner/Downloads/testrr.json:  error:0 warn:1 info:1
  Information @ Observation.component[2].value.ofType(CodeableConcept).coding[0] (line 71, col14) : Code System URI "http://omim.org" is unknown so the code cannot be validated
  Warning @ Observation.component[2].value.ofType(CodeableConcept).coding[0].display (line 73, col56) : value should not start or finish with whitespace

Patrick Werner (May 14 2020 at 17:32):

did a local validation with the java validator against our ig

Jamie Jones (May 14 2020 at 17:33):

no issue on the extensions there, right? might be a hapi bug

Jamie Jones (May 14 2020 at 17:33):

let me try forcing in '.value'

Patrick Werner (May 14 2020 at 17:33):

hapi 5.0.0 was released yesterday, this is still a hapi 2.4 server (previous version) wich uses an older validator version

Jamie Jones (May 14 2020 at 17:35):

"Unrecognised property '@value'", so not that... (same for '.value[x]')

Patrick Werner (May 14 2020 at 17:35):

https://chat.fhir.org/#narrow/stream/179252-IG-creation/topic/Issue.20with.20extension.20differentials.20and.20rendering

Patrick Werner (May 14 2020 at 17:36):

Grahame Grieve21:59
as for

The Extension 'http://hl7.org/fhir/us/core/StructureDefinition/us-core-race' definition is for a simple extension, so it must contain a value, not extensions

I could revise that, since it's extension specific logic, but what should that code do when the extension definition allows for both value[x] and extension? How does that code decide what you actually mean? The base extension allows both, and says, choose one. That means you actually have to choose, and you do that by setting the cardinality one of them to 0. All the extension processing logic works that way. So just set it to 0.

As for where this is documented.... I don't know. It's obvious to me. But I'm ok to make it explicit somewhere if you can identify the most logical place

Patrick Werner (May 14 2020 at 17:36):

checking right now

Patrick Werner (May 14 2020 at 17:39):

where is this extension defined? :)

Kevin Power (May 14 2020 at 17:40):

http://build.fhir.org/ig/HL7/genomics-reporting/extension-RelatedArtifact.html

Jamie Jones (May 14 2020 at 17:41):

we may be declaring it incorrectly in the spreadsheet, there was some ambiguity when they introduced polymorphic types, and some artifacts may have been missed

Kevin Power (May 14 2020 at 17:42):

Yup, thinking the same thing.

Jamie Jones (May 14 2020 at 17:42):

yay testing!

Kevin Power (May 14 2020 at 17:42):

What a CRAZY concept

Patrick Werner (May 14 2020 at 17:43):

its in the DiagnosticReport Spreadsheet ok

Jamie Jones (May 14 2020 at 17:44):

the obs spreadsheet has a seemingly correct representation of the polymorphic values

Patrick Werner (May 14 2020 at 17:44):

looking good. Probably a validator bug which was resolved since

Jamie Jones (May 14 2020 at 17:46):

the updated validator passing it does seem to imply that...

Kevin Power (May 14 2020 at 17:47):

Wait, what? I am only 1/2 following along here, but if this is a bug that 'was resolved since' - what is causing the error?

Jamie Jones (May 14 2020 at 17:49):

Patrick Werner said:

hapi 5.0.0 was released yesterday, this is still a hapi 2.4 server (previous version) wich uses an older validator version

Kevin Power (May 14 2020 at 17:51):

Anything we can do to make it work now and in the future? I hate being tied to new versions of things like HAPI if there is some way we can fix this within our IG.

Patrick Werner (May 14 2020 at 17:55):

I don't think we can fix something in the IG. The issue is in the validator and already resolved (in the current validator)

Patrick Werner (May 14 2020 at 17:56):

but yes, validation is painful a lot of times, the good thing is that i have the impression that things are getting more and more stable in the validator

Kevin Power (May 14 2020 at 17:58):

Yup, figured that was the answer. But wanted to double check.

Patrick Werner (May 14 2020 at 17:58):

i just uploaded the whole IG to: http://hapi.fhir.org/baseR4 which runs hapi 5.0.0

Patrick Werner (May 14 2020 at 17:58):

@Jamie Jones can you check against that server?

Bret H (May 14 2020 at 17:59):

again does the difference between http://build.fhir.org/ig/HL7/genomics-reporting/extension-RelatedArtifact.html AND "url": "http://hl7.org/fhir/uv/genomics-reporting/StructureDefinition/RelatedArtifact" declared in the profile matter?

Patrick Werner (May 14 2020 at 18:02):

the url for the extension is: http://hl7.org/fhir/uv/genomics-reporting/StructureDefinition/RelatedArtifact

Patrick Werner (May 14 2020 at 18:03):

ah in the profile!

Bret H (May 14 2020 at 18:03):

yep. image.png

Patrick Werner (May 14 2020 at 18:03):

ah ok. No the canonical url is always: http://hl7.org/fhir/uv/genomics-reporting/StructureDefinition/RelatedArtifact

Bret H (May 14 2020 at 18:04):

got. it so as long as the server loaded the extension with that url then use of the extension with that url declared as the url should validate. right?

Patrick Werner (May 14 2020 at 18:04):

http://build.fhir.org/ig/HL7/genomics-reporting/extension-RelatedArtifact.html is the url to the place in our IG (current build) on which also the correct canonical is declared.

Kevin Power (May 14 2020 at 18:05):

I wish all canonical's resolved :frown:

Bob Dolin (May 14 2020 at 18:08):

sorry, I had to step away a bit. Wanted to get back to SPDI - for me, SPDI is not the same as, say, a ClinVar ID, so we wouldn't want to mix those both into one component. But beyond that, I wonder if we really want to even add a component for SPDI. I mean, I use it all the time, it's a great normalization syntax. But do we want to allow for yet another way to represent variants in the IG? At least perhaps we might wait until someone comes along who thinks they need it?

Patrick Werner (May 14 2020 at 18:08):

agree. Should ask Grahame, its an easy forward

Patrick Werner (May 14 2020 at 18:10):

@Bob Dolin i think it is a design decision at the moment. Do we want to have one component for grammar based identification (hgvs, spdi, iscn) and one for a id based identification.

Patrick Werner (May 14 2020 at 18:11):

Or do we want a component for hgvs, one for spdi, one for ......

Patrick Werner (May 14 2020 at 18:13):

the first approach would be more stable. If a new syntax/idSystem has to be added. We just extend the VS which is used in the component. All codes and uris stay the same.

Patrick Werner (May 14 2020 at 18:15):

one component per CodeSystem would introduce more components with new codes over time (which is still backwards compatible i just realised)

Jamie Jones (May 14 2020 at 18:16):

if a system is hardcoded to expect a certain nomenclature on one component and the VS is extended to send another, is that not "breaking?"

Kevin Power (May 14 2020 at 18:17):

Our one component per CodeSystem is as much about validation of instances as anything else. A more generic component wouldn't actually how a real instance looks, it would just make it more difficult to do really good validation. I think.

Bret H (May 14 2020 at 18:17):

Yep. However, need to make it really clear to the community where/how to find/query for HGVS. The other soft point is 'are all syntax based nomenclatures equal?' that is do they convey the same information or is it buyer beware. For example, a dbSNP id and a clinvar id have different levels of specificity for variant change.

Bret H (May 14 2020 at 18:17):

by precoordinating HGVS to the component, the recipient can be terminologically lazy

Jamie Jones (May 14 2020 at 18:18):

as far as i can tell, spdi and hgvs are equivalent except for edge cases... would love an enumeration of where they differ

Bret H (May 14 2020 at 18:18):

or to put it another way, a stronger dependency on terminology resolutions moves complexity to the recipient system

Patrick Werner (May 14 2020 at 18:18):

Jamie Jones said:

if a system is hardcoded to expect a certain nomenclature on one component and the VS is extended to send another, is that not "breaking?"

it is, but only in one direction. But the same as separate component.

Patrick Werner (May 14 2020 at 18:20):

Kevin Power said:

Our one component per CodeSystem is as much about validation of instances as anything else. A more generic component wouldn't actually how a real instance looks, it would just make it more difficult to do really good validation. I think.

It will still validate the same. Downstream usecases can restrict the VS narrower for their specific use-case/implementation

Bret H (May 14 2020 at 18:21):

more generic components mean that the recipient must work harder to use the component, as the recipient will need to understand what to do with the codesystem. I.e. the codesystem is part of the context of the meaning of the value

Bret H (May 14 2020 at 18:21):

this is not a problem

Bret H (May 14 2020 at 18:21):

just a comment

Kevin Power (May 14 2020 at 18:22):

Patrick Werner said:

Kevin Power said:

Our one component per CodeSystem is as much about validation of instances as anything else. A more generic component wouldn't actually how a real instance looks, it would just make it more difficult to do really good validation. I think.

It will still validate the same. Downstream usecases can restrict the VS narrower for their specific use-case/implementation

How can it validate the same? If we do a single component, can we define a rule which says 'component[].code' must be from 1 of X CodeSystems' ?

Patrick Werner (May 14 2020 at 18:22):

Bret H said:

just a comment

a good one! But yes if this will introduce a problem in your IT system, derive a narrower profile for the single CS you need.

Kevin Power (May 14 2020 at 18:23):

Am I wrong, or do the actual instances look the same no matter what?

Bret H (May 14 2020 at 18:23):

@Kevin Power do you mean compoenent.code from a list of codes?

Bret H (May 14 2020 at 18:23):

doesn't that mean different components?

Patrick Werner (May 14 2020 at 18:23):

Kevin Power said:

Patrick Werner said:

Kevin Power said:

Our one component per CodeSystem is as much about validation of instances as anything else. A more generic component wouldn't actually how a real instance looks, it would just make it more difficult to do really good validation. I think.

It will still validate the same. Downstream usecases can restrict the VS narrower for their specific use-case/implementation

How can it validate the same? If we do a single component, can we define a rule which says 'component[].code' must be from 1 of X CodeSystems' ?

Yes. We already have a required binding to a VS. This VS points to a single CS, but can point to *. So we can say valid are these CodeSystems:

Bret H (May 14 2020 at 18:24):

you can use mapping to provide mappings of code to other codesystems but the meaning better be the same

Bret H (May 14 2020 at 18:24):

@Patrick Werner i think he is talking about .code not value

Patrick Werner (May 14 2020 at 18:24):

Kevin Power said:

Am I wrong, or do the actual instances look the same no matter what?

In a Instance you use the system.uri of a CS, so they look different (Coding.system is different)

Kevin Power (May 14 2020 at 18:25):

Patrick Werner said:

Kevin Power said:

Am I wrong, or do the actual instances look the same no matter what?

In a Instance you use the system.uri of a CS, so they look different (Coding.system is different)

OK, I guess I need some lunch or something - I don't get that :slight_smile:

Patrick Werner (May 14 2020 at 18:27):

Hmm potential problem (might want to ask vocab here):

Best Practice Note: Mixing definitional systems offers the potential for confusing, overlapping, and inconsistent definitions. Creating value sets that cross code systems should be done with care to avoid creating definitional confusion.

Value sets should only include well differentiated concepts, but many value sets and code systems do not have well differentiated concepts because of various real world constraints.

Kevin Power (May 14 2020 at 18:27):

I am going to get my lunch, and will restart our connectathon zoom call for anyone who wants to join. Give me about 10 mins.

Bret H (May 14 2020 at 18:27):

Patrick Werner said:

Bret H said:

just a comment

a good one! But yes if this will introduce a problem in your IT system, derive a narrower profile for the single CS you need.

AND define it on your server's conformance statement! maybe even as an IG

Patrick Werner (May 14 2020 at 18:28):

Kevin Power said:

I am going to get my lunch, and will restart our connectathon zoom call for anyone who wants to join. Give me about 10 mins.

can join a little later. Dinner is ready.

Bret H (May 14 2020 at 18:32):

but the question remains, if the codesystems which can be used for the value of a component are wildly different meanings should that be allowed. That is if identifiers in one system convey only partial information compared to another code system are the messages safe? Again, you could specify that your hospital system only accepts specific codesystems to help ensure consistency in the information conveyed by the code. As we go down this route be careful not to have have the extreme of ONE component for everything - where the codesystem becomes the only way to understand the component. The components should have some level of specific meaning to be reliable. @Patrick Werner @Kevin Power @Jamie Jones

Bret H (May 14 2020 at 18:36):

(deleted)

Kevin Power (May 14 2020 at 18:45):

OK - Zoom meeting is going again for anyone who wants to join and discuss any of the great topics we are hitting on here :slight_smile:

Bob Dolin (May 14 2020 at 19:15):

Jamie Jones said:

as far as i can tell, spdi and hgvs are equivalent except for edge cases... would love an enumeration of where they differ

Jamie, the main difference I'm aware of is that SPDI is strictly limited to variants with known breakpoints, whereas that is not the case for HGVS. Presumably as a result, we can validate any SPDI, whereas not all validators will validate all possibly HGVS expressions.

Bob Dolin (May 14 2020 at 23:52):

@Bret H I added a set of BRCA1 and MYH7 pathogenic SNVs into the connectathon spreadsheet for you.

Bob Dolin (May 15 2020 at 14:27):

Based on our discussion, I added a tracker 'Clarify the representation of wild type in variant profile' https://jira.hl7.org/browse/FHIR-27137

Jamie Jones (May 15 2020 at 15:00):

@Patrick Werner any chance you can send the list of component.codes you are rendering? (I won't likely be able to swap from g. to c. immediately since my app is bioinformatically naive but this is a great takeaway)

Jamie Jones (May 15 2020 at 15:40):

public Hapi is fine with the extensions but throws full errors for not validating loincs (even though the build validator properly lists them as warnings now)

Jamie Jones (May 15 2020 at 15:42):

You can see e.g. http://hapi.fhir.org/baseR4/Observation/1167323 for persistent example with extensions

Kevin Power (May 15 2020 at 15:43):

:musical_notes: one step forward :music: and two steps back :musical_notes:

Jamie Jones (May 15 2020 at 15:46):

if it's an example for the IG i ought to populate coding.display, huh

Patrick Werner (May 15 2020 at 15:54):

currently extracting

Bob Dolin (May 15 2020 at 16:09):

@Jamie Jones I've created a couple PGx scenarios for you.

Bob Dolin (May 15 2020 at 16:11):

The first one is pretty easy - look to see if patient HG00403 has a pathogenic variant in CACNA1S (which affects use of halogenated anesthetics; https://www.pharmgkb.org/chemical/PA449845/guidelineAnnotation/PA166180457).

Bob Dolin (May 15 2020 at 16:11):

I added a list of pathogenic variants here: https://docs.google.com/spreadsheets/d/1ahPqAtcv8Kwfwwkeoulhi4HUilUPneXRi3pnD2fRPG4/edit#gid=660016315

Bob Dolin (May 15 2020 at 16:12):

The second scenario is a little harder, looking at CYP2C19 and determining if clopidogrel or citalopram can be prescribed or if dose should be adjusted.

Bob Dolin (May 15 2020 at 16:13):

I put a excerpt of the PharmGKB CYP2C19 core allele table here: https://docs.google.com/spreadsheets/d/1ahPqAtcv8Kwfwwkeoulhi4HUilUPneXRi3pnD2fRPG4/edit#gid=548798137

Bob Dolin (May 15 2020 at 16:14):

Three patients to look at: HG00407, HG00463, HG00559.

Bob Dolin (May 15 2020 at 16:15):

One of these patients is a normal metabolizer, can receive either drug. One patient is an intermediate metabolizer, so should not get clopidogrel. One patient is a poor metabolizer, so should not get clopidogrel and should have a citalopram dose reduction.

Patrick Werner (May 15 2020 at 16:16):

http://hapi.fhir.org/baseR4/Observation/1167323/$validate
looking good (apart from the validation errors on loinc which should be warnings) i already started this issue with grahame and mark from smile.

Patrick Werner (May 15 2020 at 16:17):

.. hotfixing the varviewer while extracting

Patrick Werner (May 15 2020 at 16:22):

@Jamie Jones
gene name (symbol not id, still need to finish the lookup in hapi): 48018-6
reference: 62374-4
type: 48019-4
source class: 48002-0
functional class: functional-annotation
dna change (c.HGVS): 48004-6
aa change: 48005-3
refseq: 51958-7
NAF: 81258-6
read depth: 82121-5

Patrick Werner (May 15 2020 at 16:23):

will redeploy in a minute

Patrick Werner (May 15 2020 at 16:29):

oh i have duplicats in the list above sorry!

Patrick Werner (May 15 2020 at 16:32):

compiling!

Patrick Werner (May 15 2020 at 17:02):

fixed another bug, compiling again..

Patrick Werner (May 15 2020 at 17:07):

https://molit.eu/variant-viewer/

Patrick Werner (May 15 2020 at 17:08):

you have to delete your browser cache

Patrick Werner (May 15 2020 at 17:08):

then the new english! version should appear :-)

Patrick Werner (May 15 2020 at 17:14):

you have to use https in the base url

Patrick Werner (May 15 2020 at 17:14):

the "ID" is the id of the DiagnosticReport

Jamie Jones (May 15 2020 at 17:19):

what would be really great is a list of all components to add instead of checkboxes ;)

Jamie Jones (May 15 2020 at 17:19):

if i want to show g.HGVS instead for example

Jamie Jones (May 15 2020 at 17:20):

submits enhancement request ticket

Patrick Werner (May 15 2020 at 17:25):

just discussed that with the dev. (the project didn't get much love recently)
So this is a web-component, we will change the component to accept a list of system/code pairs to define the columns

Patrick Werner (May 15 2020 at 17:26):

even thinking about getting the column header from a terminology server

Patrick Werner (May 15 2020 at 17:28):

Having this parameterized enables you to embed it static or dynamically.

Jamie Jones (May 15 2020 at 17:30):

:>

Jamie Jones (May 15 2020 at 17:37):

I added displays for my components and a text blurb on method, so http://hapi.fhir.org/baseR4/Observation/1167450 is approaching a canonical example for http://build.fhir.org/ig/HL7/genomics-reporting/diagnostic-implication.html

Bret H (May 15 2020 at 17:43):

add information to outcomes @Kevin Power @Patrick Werner @Jamie Jones whose putting the presentation from our group together?

Kevin Power (May 15 2020 at 17:48):

If everyone adds to the spreadsheet, I will make sure to get it rolled up into the connectathon document.

Kevin Power (May 15 2020 at 18:10):

Still waiting on updates from @Patrick Werner @Bob Dolin @Alexander Mankovich

Alexander Mankovich (May 15 2020 at 18:11):

working on it... last minute validation issues (par for the course)

Alexander Mankovich (May 15 2020 at 18:12):

@Jamie Jones not sure if ill have time to run your example through before reporting

Patrick Werner (May 15 2020 at 18:16):

Had dinner :neutral:

Patrick Werner (May 15 2020 at 18:17):

Will update in a minute

Kevin Power (May 15 2020 at 18:17):

Patrick Werner said:

Had dinner :neutral:

That is acceptable :slight_smile:

Patrick Werner (May 15 2020 at 18:38):

done.

Patrick Werner (May 15 2020 at 18:38):

i think i mixed up timezones.

Jamie Jones (May 15 2020 at 19:08):

I suggest we have a bulleted list of notable achievements for the track overall rather than listing them personally. Seems to be the norm in the doc, any objections?

Alexander Mankovich (May 15 2020 at 19:15):

fine with me. wish I could add more but going to need more time to resolve validation issues.

Kevin Power (May 15 2020 at 19:23):

I have updated/tweaked our section, take a look: https://docs.google.com/document/d/1B6FvP5IP83tuUPvOMQjZIR5jYyw4OSbahgRqnbkPZZ8/edit#heading=h.lgwdpo5z3xsj

Bret H (May 15 2020 at 19:28):

thanks for that Kevin. I tried to condense. I'm a bit wordy.

Kevin Power (May 15 2020 at 19:28):

I hope I split everything up ok :slight_smile:

Patrick Werner (May 15 2020 at 19:46):

Looking great! Thanks

Jamie Jones (May 15 2020 at 20:06):

http://hapi.fhir.org/baseR4/Observation/?component-code-value-concept=http://loinc.org|81252-9$https://www.ncbi.nlm.nih.gov/clinvar|653974&_revinclude=Observation:derived-from

Jamie Jones (May 15 2020 at 20:07):

one of the ACMG clinvar variants is also a CPIC hit - this example shows both a diagnostic implication and a therapeutic implication deriving from the same variant observation

Bret H (May 15 2020 at 20:09):

Jamie Jones said:

http://hapi.fhir.org/baseR4/Observation/?component-code-value-concept=http://loinc.org|81252-9$https://www.ncbi.nlm.nih.gov/clinvar|653974&_revinclude=Observation:derived-from

This is great! A very good example of what might happen in a report where a variant has both types of implications, and use of associated phenotype. Note the use of High Risk to communicate adverse event risk. a very nice example.

Jamie Jones (May 15 2020 at 20:11):

the context for 'asssociated-phenotype' is different--on the diagnostic implication it is implying there is a familial risk of Malignant hyperthermia, but in the therapeutic case, it is stating that phenotype as a concern for giving a (class of) medication.

Kevin Power (May 15 2020 at 20:16):

Nice! So the difference in context is interesting. "It's the same ... :thinking: ... but it's different" :slight_smile:

Jamie Jones (May 15 2020 at 20:17):

a phenotype of 'familial ...' or 'predisposition for ...' may be more appropriate for diagnostic cases. (The free table I pulled just had the risky phenotypes listed so that's what the example has)

Kevin Power (May 15 2020 at 20:19):

But on the Theraputic -Could it be misinterpreted as a treatment for Malignant Hyperthermia, instead of something that the patient is at risk of by taking the medication?

Kevin Power (May 15 2020 at 20:21):

The LOINC term description is pretty vague (as we have discussed):
The possible phenotype associated with the genetic variant found in this study.

Jamie Jones (May 15 2020 at 20:23):

yes--I'd like something more explicit for therapeutic.

Bret H (May 15 2020 at 20:24):

Yes. But we do not have a construct in our IG to make it explicit. There are several options. However the HIGH RISK

Bret H (May 15 2020 at 20:24):

is supposed to convey that there is a risk

Bret H (May 15 2020 at 20:25):

there should also be a recommendatiion. I'll dig up my notes. I provided some options in the past

Bret H (May 15 2020 at 20:25):

from other WGs

Kevin Power (May 15 2020 at 20:25):

Here is a test - How would each of us word what those implications are saying in a sentence?

Jamie Jones (May 15 2020 at 20:25):

i could have used "prognosis" instead of high-risk but i don't like it

Bret H (May 15 2020 at 20:26):

Is this better to cotinue in : https://chat.fhir.org/#narrow/stream/179197-genomics/topic/Stress.20Testing.20IG.20Implications.20with.20Examples

Jamie Jones (May 15 2020 at 20:27):

folks are probably ignoring the spam we are creating in this stream, good call

Bret H (May 15 2020 at 20:29):

thx. I would not want to lose your comments Kevin and Jamie on that topic for sure!

Bob Dolin (May 15 2020 at 21:30):

@Jamie Jones @Bret H I added in a normalization scenario. If you run this query on patient HG00407 and HG00406, you'll get back two representations of the same variant:

Bob Dolin (May 15 2020 at 21:30):

https://api-gacs.elimuinformatics.com/gacs/variants/HG00406/?start=11200220&end=11200240&refSeq=NC_000019.9

Bob Dolin (May 15 2020 at 21:31):

https://api-gacs.elimuinformatics.com/gacs/variants/HG00407/?start=11200220&end=11200240&refSeq=NC_000019.9

Bob Dolin (May 15 2020 at 21:31):

You can use NCBI services to see that they both resolve to the same canonical SPDI

Jamie Jones (May 15 2020 at 21:32):

that's not even considering any differences in reference sequence!

Jamie Jones (May 15 2020 at 21:33):

(which is the only downside i view in pushing for SPDI as a variation identifier)

Bob Dolin (May 15 2020 at 21:33):

Anyhow, this is where I think SPDI really shines - normalize the variants you get back (from whatever format), before comparing them against (normalized) ClinVar variants.

Bob Dolin (May 15 2020 at 21:35):

(deleted)

Jamie Jones (May 15 2020 at 21:56):

Great work this week folks! Look forward to a jira review next week of detected issues :)

Patrick Werner (May 16 2020 at 10:34):

Bob Dolin said:

Jamie Jones Bret H I added in a normalization scenario. If you run this query on patient HG00407 and HG00406, you'll get back two representations of the same variant:

thanks! A nice example showing the normalization problem.
I think this could be added to our ig in the context of a normalization page/paragraph?

Bob Dolin (May 18 2020 at 16:40):

@Patrick Werner Should we break out the normalization topic into its own zulip thread? I'd like to help with this. In addition to variants with precise endpoints (where, for instance, we can use SPDI normalization), I think we can also describe a strategy for 'normalizing' variants with imprecise endpoints, where, rather than normalizing to a common canonical form, we normalize to criteria that subsumes the variant. For instance, we can normalize CYP2D6*5 (whole gene deletion) to:

(outer-start<NC_000022.10:42522500 AND outer-end>NC_000022.10:42526883) AND ((dna-chg-type=DEL) OR (dna-chg-type=CNV AND copy-number<2))

Last updated: Apr 12 2022 at 19:14 UTC