Stream: genomics/committers
Topic: Publication Prep 2019
Jamie Jones (Jun 12 2019 at 16:33):
Hi all, it seems we have 22 trackers to apply from January, 6 from May, and an extra 10 that or so logged towards the IG but not in a ballot. There may be a few more that weren't logged properly.
Some of these decided changes were pretty vague or need a decent amount of textual guidance to be added. I think we'll definitely want topics in this stream for hashing out the more tricky ones, and I'm wondering if we should put them into groups or just use the 'assignee' field. Thoughts?
Jamie Jones (Jun 12 2019 at 16:35):
I'm inclined to go through and start topics here for each tracker that I'm personally not sure how to apply in full, it seems easier to track progress here than using the gForge follow-up thread.
Kevin Power (Jun 12 2019 at 19:57):
I like using Zulip to hash out details. We can move those details to the tracker once we land on a resolution.
Jamie Jones (Jun 25 2019 at 16:15):
We've got 15 "TBD" Loinc codes, each creating an Error. I will double check a few of these have been added into LOINC now so can update, but are the rest something we need to resolve before publication?
Kevin Power (Jun 25 2019 at 17:13):
It's not all 15 I'm afraid, but here are the ones that were requested that should have been in the latest release (just came out this week). 2019-04-16-LOINC-code-requests-for-sample-and-poulation-allelic-frequency-and-for-coordinant-systems-FINAL.docx
Jamie Jones (Jun 26 2019 at 20:24):
Anybody know what the new errors are? Seems to be 49 of them, looking like:
ImplementationGuide/genomics-reporting: ImplementationGuide.definition.resource[1].extension error The extension http://tools.fhir.org/StructureDefinition/resource-information is unknown, and not allowed here
Publisher change?
Kevin Power (Jun 26 2019 at 20:44):
Interesting - when I built locally yesterday I never got those error, and thought I downloaded the latest publisher first.
Kevin Power (Jun 26 2019 at 20:49):
Might want to post on #IG creation perhaps?
Kevin Power (Jun 26 2019 at 20:50):
As an aside, when I try the _genUpdatePublisher option, it errors out:
local-downloads:
[get] Getting: https://oss.sonatype.org/service/local/artifact/maven/redirect?r=snapshots&g=org.hl7.fhir.publisher&a=org.hl7.fhir.publisher.cli&v=LATEST&e=jar
[get] To: /Users/cerkyp/Documents/GitHub/genomics-reporting/src-generated/org.hl7.fhir.igpublisher.jar
[get] Error opening connection java.io.IOException: Server returned HTTP response code: 403 for URL: https://oss.sonatype.org/service/local/artifact/maven/redirect?r=snapshots&g=org.hl7.fhir.publisher&a=org.hl7.fhir.publisher.cli&v=LATEST&e=jar
[get] Error opening connection java.io.IOException: Server returned HTTP response code: 403 for URL: https://oss.sonatype.org/service/local/artifact/maven/redirect?r=snapshots&g=org.hl7.fhir.publisher&a=org.hl7.fhir.publisher.cli&v=LATEST&e=jar
[get] Error opening connection java.io.IOException: Server returned HTTP response code: 403 for URL: https://oss.sonatype.org/service/local/artifact/maven/redirect?r=snapshots&g=org.hl7.fhir.publisher&a=org.hl7.fhir.publisher.cli&v=LATEST&e=jar
[get] Can't get https://oss.sonatype.org/service/local/artifact/maven/redirect?r=snapshots&g=org.hl7.fhir.publisher&a=org.hl7.fhir.publisher.cli&v=LATEST&e=jar to /Users/cerkyp/Documents/GitHub/genomics-reporting/src-generated/org.hl7.fhir.igpublisher.jar
BUILD FAILED
/Users/cerkyp/Documents/GitHub/genomics-reporting/framework/build.xml:57: Can't get https://oss.sonatype.org/service/local/artifact/maven/redirect?r=snapshots&g=org.hl7.fhir.publisher&a=org.hl7.fhir.publisher.cli&v=LATEST&e=jar to /Users/cerkyp/Documents/GitHub/genomics-reporting/src-generated/org.hl7.fhir.igpublisher.jar
Kevin Power (Jun 26 2019 at 20:52):
Actually, looks like someone else reported it: https://chat.fhir.org/#narrow/stream/179252-IG-creation/topic/Unexpected.20error.20with.20ig.2Exml
Jamie Jones (Jun 27 2019 at 18:02):
Looks like Grahame et al will address the new errors, thanks for finding the thread.
Current _genUpdatePublisher seems to build fine for me on mac. I often have trouble finding the publisher on windows through my intranet though, and get similar errors. Tethering to my phone/wifi fixes it
Jamie Jones (Jul 26 2019 at 22:30):
Trying to fit that high level diagram in enterprise architect...
pasted image
Jamie Jones (Jul 26 2019 at 22:32):
other ones needed some updating as well, can go over these and a few (not fully) proposed texts next week
Kevin Power (Jul 29 2019 at 13:07):
Looks good to me @James Jones
Jamie Jones (Jul 29 2019 at 21:27):
Updated inheritance diagram for genetic profiles, may be more useful? pasted image
Jamie Jones (Jul 29 2019 at 21:28):
I realized just changing the red label to "represents multiple profiles" wasn't correct either, I think labeling abstract profiles explicitly will help a lot
Jamie Jones (Aug 02 2019 at 21:25):
I'm glad I wasn't the one to add 1200 build errors from the publisher updating, should have some time next week to help resolve them ;)
Jamie Jones (Aug 02 2019 at 21:27):
1104 seem to be from "icon_fixed.gif" not resolving, so hopefully that isn't something we should be Too Concerned With
Kevin Power (Aug 02 2019 at 21:31):
AHH CRAP! I saw it was successful and didn't even look at the QA :radioactive: :radioactive: :radioactive:
Oddly, I don't see those same errors locally, even though I did use the latest publisher locally before my commit.
Jamie Jones (Aug 02 2019 at 21:34):
i don't recall I've ever seen this "fixed" icon? It seems to be displaying each of our codings in a new way
Kevin Power (Aug 02 2019 at 21:36):
Mentioned here ==> https://chat.fhir.org/#narrow/stream/179252-IG-creation/topic/new.20build.20error
Jamie Jones (Aug 02 2019 at 21:41):
Okay cool, the icon should be okay eventually but still leaves about a hundred other items to possibly consider... I'm glad Sunday isn't our deadline (looks like it is for submitting to ballot)!
Kevin Power (Aug 02 2019 at 21:42):
I am fixing the icon issue now.
Kevin Power (Aug 02 2019 at 22:06):
Icon issue fixed, taking a quick look at the other errors.
Kevin Power (Aug 02 2019 at 23:00):
Took a stab at resolving the build errors on Genomics Report. However, not sure what I did is right. We should probably discuss, so if someone wants to take a look, I welcome another set of eyes.
Jamie Jones (Aug 05 2019 at 01:49):
on Observation, it looks like we can't resolve our component.value[x]s as codeableConcepts. Of note, ...component.value[x] is listed as a valid target instead but none of the polymorphic property types resolve as they are being built... will have to do some digging into what changed
Jamie Jones (Aug 05 2019 at 01:50):
looks like the same issues you were addressing on DR and your solution there seemed to work well
Kevin Power (Aug 05 2019 at 11:34):
My solution did resolve the build failure but I am still not sure it is the right answer. This is another place where using the spreadsheets seems a bit awkward.
I can show what I did on the call today perhaps, or if anyone else has a chance to review it feel free to comment back here
Kevin Power (Aug 05 2019 at 14:51):
Quick summary of what this fix looks like for one of the components on Computable Genetic Findings:
Here is what Lloyd said on Zulip to someone else who (I think) was seeing a similar error:
“The rules for handling polymorphic types have changed a bit. Asserting valueCodeableConcept no longer constrains the type. To constrain the type you have to do it using value[x]. Not sure if that's your problem or not”
How it looks in the spreadsheet – note the ‘gene-studied’ is “fixed”, the ‘cytogenetic-location’ is not:
pasted image
This makes the HTML view look the same:
pasted image
But without the fix, the link behind the ‘valueCodeableConcept’ was not correct:
Before “fix” (link is not valid):
<path> obs-comp-gen-finding-definitions.html#Observation.component:gene-studied.valueCodeableConcept
After “fix” (link is valid):
<path> obs-comp-gen-finding-definitions.html#Observation.component:gene-studied.value[x]:valueCodeableConcept
StructureDefinition before the “fix”:
pasted image
StructureDefinition after the “fix”:
pasted image
It changed the id, path, and added a sliceName.
Kevin Power (Aug 05 2019 at 14:55):
I used the sliceName of "valueCodeableConcept" to make the type more obvious on the rendered view. But, it doesn't have to be. Here is an example of where I used a different slice name, and everything still seemed to work (no build failure, link still works):
pasted image
Jamie Jones (Aug 05 2019 at 14:56):
I like having the name there, I think the last picture is better if it still builds properly
Kevin Power (Aug 05 2019 at 15:00):
It seems to, and it doesn't cause any validation errors on the examples - but would probably have to apply this change to all of our Observations profiles to know for sure.
Lastly, if we don't define a slice name at all, still no error and it looks like this:
pasted image
Patrick Werner (Aug 05 2019 at 15:06):
sorry for being so quiet the last time. We a currently having a release of our tumor board software.
Kevin Power (Aug 05 2019 at 16:21):
So, hearing what Lloyd says gives me additional confidence that this will bring us up to date with the latest publisher in a reasonable manner. The real question is - what do we name the slice? I don't think it has many technical ramifications (well, maybe one for duplicate names - see option #1 below), but honest I feel like it is more of a visual representation question (but I might be wrong there as well?):
1. "valueCodeableConcept" - Not sure we can do this, as we end up with the same slice name multiple times on a profile, which doesn't fail a build but seems weird.
https://chat.fhir.org/user_uploads/10155/4Y1c6kk7nTMIuz5zPgoJVOzK/pasted_image.png
2. Unique name for each, so in the case of 'gene-studied' we use something like 'gene-studied-value' or other suggestions welcome
https://chat.fhir.org/user_uploads/10155/7itwixSwyWjKJAN-xOTzhPVk/pasted_image.png
3. No name, which then shows 'value[x]':
https://chat.fhir.org/user_uploads/10155/rwJEAOrgKN2FIHasdW1lizs4/pasted_image.png
Thoughts?
Patrick Werner (Aug 05 2019 at 19:03):
i would go with 1. as this would be the most intuitive for implementers. Most FHIR Muggles i know are looking at the structures and writing down what they see as element name in the tree view into their json objects.
Patrick Werner (Aug 05 2019 at 19:05):
2. duplicates the component slice name, 3. has no benefit
Patrick Werner (Aug 05 2019 at 19:05):
duplicating slice names seems weird, as these all are independent slicings on value[x] this shouldn't be a problem.
Kevin Power (Aug 05 2019 at 19:32):
I am OK with #1 as long as the duplicate slice names is not a concern. I would like @Lloyd McKenzie to review, though I feel bad as I think I read somewhere that he is actually on vacation. I will plan to go forward with #1 by tomorrow unless someone voices an objection.
Kevin Power (Aug 05 2019 at 23:09):
BTW - having trouble figuring out how to define slices on things like ...value[x]:valueQuantity.system ? I have tried lots of different options on the spreadsheet, but none seem to work.
Lloyd McKenzie (Aug 06 2019 at 01:27):
Why would you slice system? It doesn't repeat and isn't polymorphic
Kevin Power (Aug 06 2019 at 01:42):
We make it 1..1 and Must Support
Lloyd McKenzie (Aug 06 2019 at 02:18):
Sure - but that's as part of a slice - you don't slice that element itself, correct?
Kevin Power (Aug 06 2019 at 02:20):
I tried not giving it a Profile Name in the spreadsheet which I think makes it a slice. But I was continuing to get a variety of errors. I will try more options tomorrow
Lloyd McKenzie (Aug 06 2019 at 03:36):
When you're constraining the value element, it's now necessary to explicitly declare that value[x] is constrained to a type of CodeableConcept. Simply declaring valueCodeableConcept no longer automatically constrains value[x] to only one type. After you've done that, if you want to further constrain the type, the proper element name is Observation.value[x]:valueCodeableConcept - so that should be the base if you want to refer to .coding i.e. Observation.value[x]:valueCodeableConcept.coding
Kevin Power (Aug 06 2019 at 03:42):
Yup tried that (but on value[x]:valueQuantity.system). It worked well on CodeableConcept but haven’t found the trick on Quantity. But I will figure it out tomorrow (enjoy you vacation please 😀)
Lloyd McKenzie (Aug 06 2019 at 04:07):
Did you define a row for value[x] that constrains to Quantity?
Kevin Power (Aug 06 2019 at 04:12):
Sure did, then added rows for value and system as well. Likely I missed something. Sorry, I am not at my laptop to share what all I tried. I only had a few minutes before a family function.
Kevin Power (Aug 06 2019 at 17:11):
Thanks for all the realtime guidance from @Lloyd McKenzie and some more playing around, I have resolved all the new build failures [HAVE NOT BUILT YET BUT WILL SHORTLY]. The new way slices are repsented is interesting, but growing on me. Welcome any feedback.
For anyone else watching, the one thing that Lloyd said above that I found to be different is how to profile elements inside a polymorphic element (value[x]). I tried to reference the attribute (in this case on Quantity) it this way to no avail:
Observation.component.value[x]:valueQuantity.value
I instead found this worked (after reading through the build error and realizing I had already constrained this particular 'Observation.component.value[x]' to Quantity):
Observation.component.value[x].value
Jamie Jones (Aug 08 2019 at 15:39):
Looks good! Thanks for putting in the leg-work :)
Jamie Jones (Aug 16 2019 at 19:13):
@Patrick Werner Is there any chance you'll be able to create the HL7 codes for us to fill in for the remaining TBD Loinc codes? I'm not fully read up on the process and have been focusing on other updates
Kevin Power (Aug 16 2019 at 21:01):
@James Jones - are you working on trackers assigned to you I guess?
Jamie Jones (Aug 16 2019 at 21:03):
Just updated the diagrams per recent changes, and will definitely finish the ones I assigned before our deadline (8/26). Miiight be able to take on a few others too
Kevin Power (Aug 16 2019 at 22:30):
FYI @James Jones - Looks like you introduced some broken links? Interestingly, I didn't see it when I just built locally, but I do see it here: http://build.fhir.org/ig/HL7/genomics-reporting/branches/master/qa.html
Kevin Power (Aug 16 2019 at 22:31):
artifacts.html#/html/body/div/div/div/div/div/div/p/table/tbody/tr/td/a at Line 463, column 2 error The link 'compound-heterozygote.html' for " • Example - Complex Variant" cannot be resolved
sequencing.html#/html/body/div/div/div/div/div/div/p/a at Line 197, column 348 error The link 'compound-heterozygote.html' for "compound heterozygote" cannot be resolved
Kevin Power (Aug 16 2019 at 22:33):
Just FYI for @ Bob Milius and/or @Joel Schneider - Bob M has 3 trackers assigned to him currently.
Kevin Power (Aug 16 2019 at 22:34):
If I am doing this query right, we have 25 trackers yet to apply, most of which the ambitious @James Jones has assigned to himself:
Jamie Jones (Aug 16 2019 at 22:37):
Yeah I think I know what's up with those links, there are 2 ig.xml files in Source right now and think I added the example to the wrong one (and/or it needs to be linked in both)
Jamie Jones (Aug 16 2019 at 22:38):
It builds fine locally so the live version must generate links differently
Kevin Power (Aug 16 2019 at 22:42):
Yea, I think the two ig.xml files is my bad.
Working on fixing it now.
Kevin Power (Aug 16 2019 at 23:38):
OK - last commit/build fixed (for now) the multiple ig.xml problem, and also resolved the new build link build issue. Sorry about that @James Jones
Patrick Werner (Aug 18 2019 at 19:41):
@James Jones sure! Im currently on holiday in the alps, but rain will start tomorrow at noon, so no more climbing. will have a look and update here
Patrick Werner (Aug 19 2019 at 19:34):
hi, just started on it and got a question: during the last call it was discussed to not name the TBD codesystem something with "LOINC"
Patrick Werner (Aug 19 2019 at 19:34):
i kind of having second thoughts on this. Loinc TBD would clearly state these are temporary, and we will switch to LOINC in the future.
Patrick Werner (Aug 19 2019 at 19:35):
If we just call them TBD, this information gets lost.
Patrick Werner (Aug 19 2019 at 19:36):
Independent from the name would be the structure: LOINC has 1 CodeSystem for all concepts. I would create a single CodeSystem for all the missing concepts.
Patrick Werner (Aug 19 2019 at 19:37):
So the uri for the CS would be: http://hl7.org/fhir/uv/genomics-reporting/CodeSystem/TBD without LOINC
Patrick Werner (Aug 19 2019 at 19:37):
would this be ok with you?
Jamie Jones (Aug 19 2019 at 19:42):
I agreed with the concerns that we may be in trouble using the term "LOINC" for things that aren't coming from them.
Jamie Jones (Aug 19 2019 at 19:42):
or at least that aren't yet approved by LOINC
Patrick Werner (Aug 19 2019 at 19:43):
ok, i can also see that. So http://hl7.org/fhir/uv/genomics-reporting/CodeSystem/TBD `?
Jamie Jones (Aug 19 2019 at 19:45):
could have a note about concepts "submitted to LOINC" maybe on the appendix
Jamie Jones (Aug 19 2019 at 19:45):
or concepts we are looking for feedback on in terms of a call to action before we finalize them with LOINC
Patrick Werner (Aug 20 2019 at 11:54):
I started the work on the TBD stuff, tested it with grouper -> works.
Will continue later today.
Jamie Jones (Aug 20 2019 at 16:11):
Thanks Patrick
Jamie Jones (Aug 20 2019 at 16:11):
We went over the grouper code on call, looks good
Kevin Power (Aug 20 2019 at 16:14):
It was requested that we add a note somewhere to call out that these codes are not yet clearly defined and may be changed/removed in the future. Anyone have suggestions on where that should go and what it should say?
CC: @Bob Dolin @Bret H @Liz Amos (since I can't find Clem on Zulip, adding Liz).
Jamie Jones (Aug 20 2019 at 16:22):
@Patrick Werner currenty seeing related errors,
StructureDefinition/obs-gen-grouper: StructureDefinition.differential.element[2].pattern.ofType(CodeableConcept).coding[0] error Unknown Code System http://hl7.org/fhir/uv/genomics-reporting/CodeSystem/TBD-codes
StructureDefinition/obs-gen-grouper: StructureDefinition.differential.element[2].pattern.ofType(CodeableConcept).coding[0].system error URL value 'http://hl7.org/fhir/uv/genomics-reporting/CodeSystem/TBD-codes' does not resolve
Not sure if your local build had these
Patrick Werner (Aug 20 2019 at 16:23):
Oh. Nope i hadn‘t this issue. Will investigate later today
Jamie Jones (Aug 20 2019 at 16:30):
@Kevin Power http://build.fhir.org/ig/HL7/genomics-reporting/codings.html
Bob Dolin (Aug 20 2019 at 16:55):
@Kevin Power Hi Kevin, I was thinking about a simple note at the Profile level, which I kinda recall we've done before with Sequence, something like "The committee is looking for user experience with this profile. Codes at this time are 'TBD', and we will be requesting formal LOINC codes as we gain a better understanding of use cases around this profile".
Kevin Power (Aug 20 2019 at 17:25):
I feel like we could put a comment like that on EVERY profile, but I could see making the case to put a comment like that on every profile where Observation.code is a TBD code, as well as calling it out on the Coding Systems page that @James Jones referenced. Is that what you were thinking @Bob Dolin ?
Jamie Jones (Aug 20 2019 at 17:32):
TBD Table for reference:
pasted image
https://docs.google.com/document/d/1E-nal_OPhJ8SSaIN_f9XqiLI5lyuGyhTIbUae8MWLMU/edit
Bob Dolin (Aug 20 2019 at 17:33):
@Kevin Power I was kinda thinking that we'd apply something like this to any profile that has TBD codes, either as observation.code or for answer lists. (I agree with you that we could put this on other profiles too, but I thought adding it to the profiles with TBD codes might be a reasonable compromise)
Jamie Jones (Aug 20 2019 at 17:37):
I'm currently looking at prototyping somatic implications (diagnostic and predictive) using a new meta-KB to slot into the SMART Cancer Nav app so being able to validate examples generated using those last 6 codes in the cancer space would be really helpful
Kevin Power (Aug 20 2019 at 17:45):
OK, I think I am good with what @Bob Dolin suggested. @Patrick Werner - Can you do that as part of apply your changes for the TBD codes?
Patrick Werner (Aug 20 2019 at 19:29):
sure. Will do. At the moment still struggling with code lists defined in the spreadsheet. If i can't get it working in the spreadsheet i will add CS and VS externally like i did with HGNC and HGVS
Kevin Power (Aug 20 2019 at 19:35):
Can you do it like I did SeqPhaseRelationship?
Jamie Jones (Aug 20 2019 at 19:37):
re: seqPhaseRel, looks like we have to set a "publisher" somewhere:
Profile http://hl7.org/fhir/StructureDefinition/shareablevalueset, Element 'ValueSet.publisher': minimum required = 1, but only found 0
Patrick Werner (Aug 20 2019 at 19:49):
Can you do it like I did SeqPhaseRelationship?
i tried it, but it seems it is not working with patterns..
Patrick Werner (Aug 20 2019 at 19:53):
re: seqPhaseRel, looks like we have to set a "publisher" somewhere:
Profile http://hl7.org/fhir/StructureDefinition/shareablevalueset, Element 'ValueSet.publisher': minimum required = 1, but only found 0
The IG Publisher seems to enforce shareable VS and CS profiles on all VS/CS resources, which absolute makes sense. But: if you define a CS/VS as codelist like @Kevin Power did the IG publisher doesn't set publisher. So its a bug in the publisher
Patrick Werner (Aug 20 2019 at 19:53):
we could work around by creating seqphase vs manually
Kevin Power (Aug 20 2019 at 19:56):
I thought about creating it manually, but it seems like I ran into a problem when trying to replicate what we did for HGVS and HGNC, so gave up and went back to the spreadsheet tab route. But yes, I am fairly sure I put the publisher on the tab, but it didn't work. So does seem to be an issue with the IG Publisher as Patrick said.
Patrick Werner (Aug 20 2019 at 20:04):
I thought about creating it manually, but it seems like I ran into a problem when trying to replicate what we did for HGVS and HGNC, so gave up and went back to the spreadsheet tab route.
Asked about it in the IG creation stream:
https://chat.fhir.org/#narrow/stream/179252-IG-creation/topic/CodeSystem.20and.20ValueSets/near/173690962
Kevin Power (Aug 20 2019 at 20:05):
Dang @Patrick Werner - you sure know how to spend time on a vacation ;)
Patrick Werner (Aug 20 2019 at 20:05):
:smile: work-life-balance
Kevin Power (Aug 20 2019 at 20:06):
I think you messed up your equation : work > life !balance
Bret H (Aug 21 2019 at 03:28):
With the resource that has the list of codes?
Kevin Power (Aug 21 2019 at 03:33):
@Patrick Werner is still working on it.
Patrick Werner (Aug 21 2019 at 11:06):
got it working!
Had to do the CS/VS manually, and add them to the ImplementationGuide.xml
Patrick Werner (Aug 21 2019 at 11:06):
will finish the work on TBD stuff later today
Jamie Jones (Aug 21 2019 at 15:46):
Seems to be another build error on the live version (really wish it were consistent with local builds...)
java.lang.Exception: Unable to find the source file for CodeSystem/TBD-codes: not specified, so tried codesystem-TBD-codes.xml, TBD-codes.codesystem.xml, codesystem-TBD-codes.json, codesystem/TBD-codes.xml, codesystem/TBD-codes.json, TBD-codes.xml, and TBD-codes.json in dirs [/scratch/ig-build-temp-FQSXIS/repo/src-generated/resources, /scratch/ig-build-temp-FQSXIS/repo/src-generated/resources, /scratch/ig-build-temp-FQSXIS/repo/src/resources, /scratch/ig-build-temp-FQSXIS/repo/src/vocabulary, /scratch/ig-build-temp-FQSXIS/repo/src/examples]
Kevin Power (Aug 21 2019 at 16:07):
Not sure if @Patrick Werner pushes up his final working version yet?
Patrick Werner (Aug 21 2019 at 16:28):
oh!
Patrick Werner (Aug 21 2019 at 16:29):
it worked locally so i pushed the version.
Patrick Werner (Aug 21 2019 at 16:29):
i have a look now
Jamie Jones (Aug 21 2019 at 16:34):
it worked locally so i pushed the version.
Not sure how we can be expected to do much more than that...
Kevin Power (Aug 21 2019 at 16:41):
Yea, we have to check for build errors in the local QA file. There is a section called "Build Failures" and that same error shows up there.
Kevin Power (Aug 21 2019 at 16:42):
Likely some config that will trigger these to fail the publisher that isn't set locally.
Kevin Power (Aug 21 2019 at 16:44):
oh wait, never mind - I am actually seeing different errors in my local QA file - they are a set of invalid links, which might be related:
obs-gen-grouper.html#/html/body/div/div/div/div/div/table/tr/td/a at Line 932, column 180
error
The link 'TBD-codes.html#grouper' for "grouper" cannot be resolved (valid targets: [TBD-codes-region-scope, publish-box, TBD-codes-somatic-prognostic, segment-post-footer, TBD-codes-somatic-predictive-medication, hl7-search, hl7-search-lnk, TBD-codes-somatic-diagnostic, hl7-status, root, stripe, segment-footer, logo, TBD-codes-somatic-predictive, TBD-codes-somatic-prognostic-treatment, segment-content, TBD-codes-grouper, TBD-codes-region-coverage, TBD-codes-effect-transporter-function, segment-header, TBD-codes-associated-cancer, hl7-logo, hl7-nav, TBD-codes-somatic-prognostic-medication, segment-navbar, segment-breadcrumb, TBD-codes-mode-of-inheritance])
Patrick Werner (Aug 21 2019 at 16:45):
seems like some cached old stuff.
Patrick Werner (Aug 21 2019 at 16:45):
seeing the same stuff.
Kevin Power (Aug 21 2019 at 16:46):
I will remove my local genomics-reporting package and try again
Patrick Werner (Aug 21 2019 at 16:53):
deleted my txcache and local package... same errors
Kevin Power (Aug 21 2019 at 16:53):
was about to report the same
Patrick Werner (Aug 21 2019 at 16:54):
:cold_sweat:
Kevin Power (Aug 21 2019 at 16:58):
the Publisher seems to be using the name of the slice (I think) to know how to build the link to the HTML anchor for the code? When the error says "valid targets" - those are the anchors in the CodeSystem HTML page. So, I think maybe we have to define our slice names to match those? Have meetings now and can't even test my theory - but wanted to share.
Patrick Werner (Aug 21 2019 at 16:59):
wait, why is url on the TBD ValueSet missing... checking...
Patrick Werner (Aug 21 2019 at 16:59):
thanks @Kevin Power
Patrick Werner (Aug 21 2019 at 17:50):
the CI shows this error: Publishing Content Failed: Unable to find the source file for CodeSystem/TBD-codes: not specified, so tried codesystem-TBD-codes.xml
Patrick Werner (Aug 21 2019 at 17:51):
but codesystem-TBD-codes.xml is the correct file name
Patrick Werner (Aug 21 2019 at 17:52):
@Lloyd McKenzie do you have a clue?
In the local build we are also running in a lot of:
The link 'TBD-codes.html#grouper' for "grouper" cannot be resolved (valid targets: [TBD-codes-region-scope, publish-box, TBD-codes-somatic-prognostic, segment-post-footer, TBD-codes-somatic-predictive-medication, hl7-search, hl7-search-lnk, TBD-codes-somatic-diagnostic, hl7-status, root, stripe, segment-footer, logo, TBD-codes-somatic-predictive, TBD-codes-somatic-prognostic-treatment, segment-content, TBD-codes-grouper, TBD-codes-region-coverage, TBD-codes-effect-transporter-function, segment-header, TBD-codes-associated-cancer, hl7-logo, hl7-nav, TBD-codes-somatic-prognostic-medication, segment-navbar, segment-breadcrumb, TBD-codes-mode-of-inheritance])
errors.
Lloyd McKenzie (Aug 21 2019 at 17:59):
Is the id of the code system consistent with the name of the file?
Lloyd McKenzie (Aug 21 2019 at 17:59):
(including capitalization)
Jamie Jones (Aug 21 2019 at 20:30):
Anything else I can do to help troubleshoot this? (For the record this is why I tried to assign so many other trackers to myself so I wouldn't get stuck with this one haha)
Patrick Werner (Aug 21 2019 at 20:59):
Is the id of the code system consistent with the name of the file?
:thumbs_up: the CI build now works again. But still getting the cannot be resolved errors
Patrick Werner (Aug 21 2019 at 20:59):
http://build.fhir.org/ig/HL7/genomics-reporting/branches/master/qa.html#internal
Kevin Power (Aug 21 2019 at 21:02):
Still feels like the Publisher is building the link using the HTML page name (which looks right?) and an anchor. And it seems to get the anchor from the slice name we provide (column A) for our slices. Did you try to change the slice name? So for 'grouper', did you try naming the slice 'codesystem-tbd-codes-grouper' ?
Patrick Werner (Aug 21 2019 at 21:37):
the code isn't sliced as it is a non repeated element. But i found the cause of the other errors, also capitalization related.
Patrick Werner (Aug 21 2019 at 21:38):
currently fixing all the errors
THANKS @Lloyd McKenzie
Kevin Power (Aug 21 2019 at 21:45):
My suggestion was an absolute stab in the dark - glad you found the real problem ...
Patrick Werner (Aug 21 2019 at 22:50):
have to stop for today, it is getting late. Pushed my latest version.
It was a nightmare of deleting: txcache, temp, local package and trying different capitalizations (got errors when not using all small uris and Ids)
Patrick Werner (Aug 21 2019 at 22:50):
Will finish up tomorrow
Patrick Werner (Aug 21 2019 at 22:51):
i managed to get rid of the html: "cannot be resolved" errors at one point. But i introduced them back when fixing Observation errors
Kevin Power (Aug 21 2019 at 22:59):
Yikes. Good luck
Patrick Werner (Aug 22 2019 at 08:39):
after spending another 1.5h on the problem i'm fairly convinced that this is a bug:
https://chat.fhir.org/#narrow/stream/179252-IG-creation/topic/build.20error.3A.20The.20link.20'tbd-codes.2Ehtml.23grouper'.20for.20.22grouper.22/near/173863144
Kevin Power (Aug 22 2019 at 13:14):
So do we just ignore those build errors for now then I guess?
Bob Dolin (Aug 22 2019 at 13:59):
@Kevin Power Sorry I don't know enough about the build process to be more helpful here, but I'm wondering - if we ignore some build errors, will we be able to also state, when we go to validate instances against the IG, which conformance testing errors we can ignore?
Lloyd McKenzie (Aug 22 2019 at 14:03):
Ignoring build errors means "ignore them until Grahame/Lloyd/someone has a chance to fix the tool". Ignoring validation issues would be done on the same premise. If you can show that the tool is wrong, you can ignore the error.
Kevin Power (Aug 22 2019 at 14:17):
Part of the IG validation process is to ensure that all links resolve. For this error, it seems to be a problem with the IG Publisher generating our HTML pages and it builds a link to our new TBD CodeSystem page from our profile pages, but the link doesn't work since the HTML anchors don't match up.
It shouldn't affect how we validate the profiles, and just as important, how we validate our examples against our profiles.
@Patrick Werner - please correct me if I am wrong.
Kevin Power (Aug 22 2019 at 14:57):
I should add, the links "work" from a browser, meaning you get directed to our TBD CodeSystem page, but you get directed to the top of the page, when it seems the intention is to direct you to the specific code we have referenced.
To see it, go to our Group profile page in the Terminology Binding section here - the link from Observation.code that shows as is what the build process is complaining about:
Pattern: grouper
However, while putting this together, I noticed that Observation.category (Pattern: laboratory has the same problem - the anchor of "laboratory" doesn't exist in the observation category codesystem page either? Its real anchor name is "observation-category-laboratory". Of course, this doesn't generate a build error.
So, not to make us revisit this again - but is it possible the error we are seeing is really because of some other underlying issue? Or is it possible the Publisher validates against local code systems differently?
Lloyd McKenzie (Aug 22 2019 at 15:31):
It definitely seems like a publishing issue to me - I'm not sure how you would fix it with the levers you have when authoring
Patrick Werner (Aug 22 2019 at 15:34):
Kevin is 100% right. This bug appears only if you are using ElementDefinition.pattern with a fixed CodeSystem and code. As this is only a html anchor problem validation is fine. It is only a minor convenience problem.
Patrick Werner (Aug 22 2019 at 15:51):
GF Issue created:
GF#23736
Jamie Jones (Aug 25 2019 at 20:27):
In terms of a local workaround, we can say the code is fixed to "TBD-codes-grouper" instead of "grouper" and that passes QA, for example
Kevin Power (Aug 25 2019 at 21:30):
That works? I can see how that would make that build error go away, but does it cause others to come up?
Kevin Power (Aug 25 2019 at 21:31):
Yea, I am seeing errors like this now:
Could not match discriminator ([resolve().code]) for slice DiagnosticReport.result:som-diagnostic in profile http://hl7.org/fhir/uv/genomics-reporting/StructureDefinition/diagnosticreport - the discriminator [resolve().code] does not have fixed value, binding or existence assertions
Jamie Jones (Aug 25 2019 at 21:43):
Yep looks like a worse error, I'd rather have the broken/incorrectly generated link than an unknown code, I'll revert that bit
Jamie Jones (Aug 26 2019 at 16:08):
Update on this, Lloyd/Grahame will address the build errors and we can move on (but do have to put text in the definition column)
Patrick Werner (Aug 26 2019 at 19:07):
Yep looks like a worse error, I'd rather have the broken/incorrectly generated link than an unknown code, I'll revert that bit
tried that before, broke the whole build for me.
Jamie Jones (Sep 11 2019 at 03:05):
More build errors in the icons, is there a recent change to these I'm unaware of?
icon_fixed.gif error The html source does not contain the publish box <!--ReleaseHeader--><p id="publish-box">Publish Box goes here</p><!--EndReleaseHeader--> (see note at http://wiki.hl7.org/index.php?title=FHIR_Implementation_Guide_Publishing_Requirements#HL7_HTML_Standards_considerations)
icon_slice_item.png error The html source does not contain the publish box
Kevin Power (Sep 11 2019 at 03:23):
Might want to review: https://chat.fhir.org/#narrow/stream/179252-IG-creation/topic/Publisher.20error.20regarding.20publish-box
Jamie Jones (Sep 12 2019 at 19:24):
update: icon errors were fixed by Grahame :)
Kevin Power (Sep 16 2019 at 15:02):
I saw where @James Jones resolved some additional warnings around the names of extensions. I was going to look at something this morning, but when I do a local build, I get the following:
[java] org.hl7.fhir.exceptions.DefinitionException: unknown extension http://hl7.org/fhir/uv/genomics-reporting/StructureDefinition/recommendedAction
[java] at org.hl7.fhir.r5.utils.NarrativeGenerator.splitExtensions(NarrativeGenerator.java:1260)
[java] at org.hl7.fhir.r5.utils.NarrativeGenerator.generateByProfile(NarrativeGenerator.java:1157)
[java] at org.hl7.fhir.r5.utils.NarrativeGenerator.generate(NarrativeGenerator.java:1104)
[java] at org.hl7.fhir.igtools.publisher.Publisher.generateNarratives(Publisher.java:840)
[java] at org.hl7.fhir.igtools.publisher.Publisher.loadConformance(Publisher.java:3077)
[java] at org.hl7.fhir.igtools.publisher.Publisher.createIg(Publisher.java:724)
[java] at org.hl7.fhir.igtools.publisher.Publisher.execute(Publisher.java:612)
[java] at org.hl7.fhir.igtools.publisher.Publisher.main(Publisher.java:6451)
[java] Generating Narratives (00:18.0162)
[java] Validating Resources (00:18.0163)org.hl7.fhir.exceptions.DefinitionException: unknown extension http://hl7.org/fhir/uv/genomics-reporting/StructureDefinition/relatedArtifact
[java]
[java] at org.hl7.fhir.r5.utils.NarrativeGenerator.splitExtensions(NarrativeGenerator.java:1260)
[java] at org.hl7.fhir.r5.utils.NarrativeGenerator.generateByProfile(NarrativeGenerator.java:1157)
[java] at org.hl7.fhir.r5.utils.NarrativeGenerator.generate(NarrativeGenerator.java:1104)
[java] at org.hl7.fhir.r5.utils.NarrativeGenerator.generate(NarrativeGenerator.java:1090)
[java] at org.hl7.fhir.igtools.publisher.Publisher.generateNarratives(Publisher.java:835)
[java] at org.hl7.fhir.igtools.publisher.Publisher.loadConformance(Publisher.java:3077)
[java] at org.hl7.fhir.igtools.publisher.Publisher.createIg(Publisher.java:724)
[java] at org.hl7.fhir.igtools.publisher.Publisher.execute(Publisher.java:612)
[java] at org.hl7.fhir.igtools.publisher.Publisher.main(Publisher.java:6451)
Jamie Jones (Sep 16 2019 at 15:03):
you may have to remove your temp folder
Kevin Power (Sep 16 2019 at 15:03):
I can probably take a look, but wanted to see if anyone else was aware and is fixing/has fixed?
Jamie Jones (Sep 16 2019 at 15:04):
I'll try a local build to confirm it works on mine
Kevin Power (Sep 16 2019 at 15:04):
Yup, without removing temp is was a complete build failure. I removed temp, and still get this message, but build succeeds.
Kevin Power (Sep 16 2019 at 15:06):
trying to remove my local fhir package for genomics reporting, and building again
Kevin Power (Sep 16 2019 at 15:09):
Still seeing the exceptions. Typically, any exception results in a build failure. But this one doesn't for some reason. After removing temp and the local fhir package for genomics reporting, I still see the exceptions during the build, but the build is still 'successful'
Jamie Jones (Sep 16 2019 at 15:09):
I see that exception locally as well... I don't usually check the log for errors that don't show up on the output/qa.html...
Jamie Jones (Sep 16 2019 at 15:10):
it goes by very fast and is quite noisy
Kevin Power (Sep 16 2019 at 15:13):
Yes to both. Just happened to see this one. I think this is the first time I have seen an exception not cause a build failure. Maybe, or maybe I have missed others :slight_smile:
Jamie Jones (Sep 16 2019 at 15:18):
obs-inh-dis example has the wrong case still, updating that locally to see if it goes away ;)
Jamie Jones (Sep 16 2019 at 15:23):
and 2 of the DR examples had the other one, they were showing up in the deluge of errors on the examples
Kevin Power (Sep 16 2019 at 15:25):
Did you fix for both extensions (relatedArtifact and recommendedAction)?
Jamie Jones (Sep 16 2019 at 16:00):
yes you can ignore those errors, I can push if it helps
Jamie Jones (Sep 16 2019 at 16:00):
we're still playing around with queryability
Kevin Power (Sep 16 2019 at 16:24):
Queryability by the extensions? Or in general?
Patrick Werner (Sep 16 2019 at 17:35):
in general. For the usage page of the IG
Kevin Power (Sep 16 2019 at 17:42):
ok, thanks.
Bob Milius (Sep 19 2019 at 15:58):
fyi, I fixed the HLA examples to use http://example.org/r4 for references to resources
Kevin Power (Sep 24 2019 at 17:57):
Calling all #genomics/committers -- I am working on the name/title updates. I will be touching a lot of files, but I hope to wrap it up this afternoon.
Kevin Power (Sep 24 2019 at 19:41):
Just pushed up the name/title changes. I would ask that everyone take a peek when you get a chance and provide feedback.
Kevin Power (Sep 24 2019 at 21:03):
@Patrick Werner - We are getting this set of errors repeated numerous times:
Bundle/oncology-report-example: Bundle.entry[3].resource.component[1].code.coding[0] error Unknown Code http://hl7.org/fhir/uv/genomics-reporting/CodeSystem/tbd-codes#variant-type in http://hl7.org/fhir/uv/genomics-reporting/CodeSystem/tbd-codes for 'http://hl7.org/fhir/uv/genomics-reporting/CodeSystem/tbd-codes#variant-type' Bundle/oncology-report-example: Bundle.entry[3].resource.component[1].value.ofType(CodeableConcept).coding[0] error Unknown Code System http://hl7.org/fhir/uv/genomics-reporting/ValueSet/LOINC-LL-TBD-variant-types Bundle/oncology-report-example: Bundle.entry[3].resource.component[1].value.ofType(CodeableConcept).coding[0].system error URL value 'http://hl7.org/fhir/uv/genomics-reporting/ValueSet/LOINC-LL-TBD-variant-types' does not resolve
This just looks weird. I don't see variant-type in our tbd-codes, so is this example just wrong and should it be sending something else?
Kevin Power (Sep 24 2019 at 23:02):
BTW - I did a few more cleanup things, but I am probably done with changes for a while.
I will also add that I do believe there are more example validation issues that are our problem than my earlier reviews discovered. So I would suggest that everyone who worked on examples review the QA output and see what they can do about resolve the validation failures.
@Patrick Werner @James Jones @ Bob Milius @Alexander Mankovich
Patrick Werner (Sep 25 2019 at 11:46):
will fix my example, @James Jones volunteered to fix @Alexander Mankovich 's Example.
Kevin Power (Sep 25 2019 at 14:11):
I will work on GF#22816 today.
Patrick Werner (Sep 25 2019 at 14:46):
the tbd codes for the components are still missing in the tbd codesystem/valueSet
Patrick Werner (Sep 25 2019 at 14:46):
adding them right now
Kevin Power (Sep 25 2019 at 14:47):
I just added new codes for variant exact/inner/outer start-end in the CodeSystem file
Kevin Power (Sep 25 2019 at 14:47):
Just FYI, in case we might conflict
Patrick Werner (Sep 25 2019 at 14:49):
oh ok, then i'll stop with my work on that.
Kevin Power (Sep 25 2019 at 14:50):
What codes are missing?
Patrick Werner (Sep 25 2019 at 14:56):
The three codes in tbd for:
exact/inner/outer start-end
Kevin Power (Sep 25 2019 at 14:57):
Ahh, OK. I thought you were talking about different codes. But yea, I have them added and am fixing up profiles and examples. Hope to commit soon.
Kevin Power (Sep 25 2019 at 15:17):
And then there were 8. GF#22816 has been applied.
Patrick Werner (Sep 25 2019 at 15:27):
should we leave the tracker open until the new LOINC concepts are created.
Kevin Power (Sep 25 2019 at 15:30):
I don't think so. I say we create new trackers for our requests to LOINC.
Patrick Werner (Sep 25 2019 at 15:30):
I think this process hasn't started yet (i thought there was already some work done, but couldn't find any mails)
Patrick Werner (Sep 25 2019 at 15:30):
I don't think so. I say we create new trackers for our requests to LOINC.
even better!
Bret H (Sep 26 2019 at 13:30):
On textual guidance for each profile (the thing I volunteered to work on). I've been sick this week but still on track. We talked about a 0.9 version and then quickly following with a 1.0 version that had the text.
Patrick Werner (Sep 26 2019 at 14:42):
Completed analysis on all pages in FHIR core needing a deprecation label:
https://chat.fhir.org/#narrow/stream/179256-Orders-and.20Observation.20WG/topic/deprecated.20Examples.20and.20Extensions
Patrick Werner (Sep 26 2019 at 14:42):
hope this still can make it into the technical corrections..
Kevin Power (Sep 26 2019 at 15:09):
@Patrick Werner / @James Jones / @ Bob Milius - Any updates on your progress on pending trackers?
Bob Milius (Sep 26 2019 at 15:16):
@Patrick Werner I'm working on GF#19947, GF#16387, and GF#16510. I should have those finished by end of day Fri (tomorrow)
Alexander Mankovich (Sep 26 2019 at 18:18):
@James Jones thanks for handling the oncology example! let me know if you need any of my input there
Bret H (Sep 27 2019 at 04:42):
@Alexander Mankovich I asked you about somatic pharmacogneomics during the WG meeting. @Kevin Power reminded me that I was one who balked at getting rid of the profile in the past. Thinking about it, the main problem I see is that a PGx recommendation based on the Tumor's genetics (often called somatic) is different than a PGx recommendation based on the patient's germline genetics. Having the two profiles keeps the distinction, but it is an artificial means. When you look at the structures in FHIR do you see a way that one can indicate that the PGx recommendation is based on somatic sequencing AND that the target of the recommendation is Tumor response to treatment? am I drawing too much of line between patient and tumor? E.g. when I think about treating an organ like the heart. I have treatments which act on cardiac muscles and could have genetic variants that speak to predicted efficacy. And I also could have variants that speak to the ability of the patient to produce the active compound for a treatment. @Alexander Mankovich sorry to ask you for a definitive, but what do you think? do you see a need for a computer system to make a distinction for medications intended to treat Cancer Tumors? If so, should we also push for medications that have a drug target on a specific cell type as somatic PGx too? I am so turned around that I can see through the back of my head. Help : ^ )
Bret H (Sep 27 2019 at 04:44):
so, I am thinking to leave it alone with the TBD-LOINC. We might be adding an artificial, use-case specific profile that is unnecessary (in a minimalist sense) but could this be the lesser evil?
Kevin Power (Sep 27 2019 at 15:34):
@Patrick Werner or @James Jones -- Are either of you able to work on this tracker? https://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=22814
Kevin Power (Sep 27 2019 at 15:35):
and @Patrick Werner - Can you provide an update on this one? https://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=16876
Jamie Jones (Sep 27 2019 at 15:41):
for 22814, the component is in and has a value set, only work remaining is the concept map which I think Patrick volunteered to do ;)
Jamie Jones (Sep 27 2019 at 15:42):
For 16876, we got an updated version of the doc from Liz/Clem, I can attach it to the agenda going out today for the group to review before inclusion, in case any changes need to be made.
Patrick Werner (Sep 27 2019 at 15:48):
16876 needs a new column (will add it tonight)
Patrick Werner (Sep 27 2019 at 15:49):
22814 ConceptMap will be created tonight/tomorrow
Kevin Power (Sep 27 2019 at 15:54):
16876 needs a new column (will add it tonight)
Not sure I know what that means actually?
Kevin Power (Sep 27 2019 at 15:57):
And RE: 22814 - I have been assuming what we do would fix these QA errors, but not sure now?
Bundle/oncology-report-example: Bundle.entry[4].resource.component[1].code.coding[0] error Unknown Code http://hl7.org/fhir/uv/genomics-reporting/CodeSystem/tbd-codes#variant-type in http://hl7.org/fhir/uv/genomics-reporting/CodeSystem/tbd-codes for 'http://hl7.org/fhir/uv/genomics-reporting/CodeSystem/tbd-codes#variant-type' Bundle/oncology-report-example: Bundle.entry[4].resource.component[1].value.ofType(CodeableConcept).coding[0] error Unknown Code System http://hl7.org/fhir/uv/genomics-reporting/ValueSet/LOINC-LL-TBD-variant-types Bundle/oncology-report-example: Bundle.entry[4].resource.component[1].value.ofType(CodeableConcept).coding[0].system error URL value 'http://hl7.org/fhir/uv/genomics-reporting/ValueSet/LOINC-LL-TBD-variant-types' does not resolve
Jamie Jones (Sep 27 2019 at 16:16):
this is Patrick briefly deciding to use a component we didn't agree to define yet
Jamie Jones (Sep 27 2019 at 16:18):
the error is arising because the example is saying it is defined somewhere locally but it is not. If we want to show the ability to use local codes we should be using example.org and adding a comment IMO
Kevin Power (Sep 27 2019 at 16:21):
OK
Jamie Jones (Sep 27 2019 at 16:21):
though really the example should just be using an SO value and the component we defined in the tracker
Jamie Jones (Sep 27 2019 at 16:22):
(which will also throw an error because I don't think the validator can validate SO yet, but we have it on Grahame/Lloyd's word that that error should be downgraded to a warning and we can ignore it)
Bob Milius (Sep 27 2019 at 18:39):
Kevin Power (Sep 27 2019 at 18:44):
@ Bob Milius -- Do you mind updating the trackers to a status of Applied? Also, add a comment referencing the GitHub commit on the tracker.
Bob Milius (Sep 27 2019 at 18:51):
trackers marked as applied. I did add the GF #s in the commit comment.
Kevin Power (Sep 27 2019 at 19:21):
Thanks @ Bob Milius
Alexander Mankovich (Sep 30 2019 at 14:14):
@Bret H I do think it's important to make this distinction in part because both the genetics of the patient and tumor can be used to indicate efficacy and resistance to treatment for cancer. Let me think about this a bit more and get back to you. I do think it's possible a single model with some modification can work here...
Patrick Werner (Sep 30 2019 at 14:20):
this could be done through a component in the profile which states: tumor/patient origin of the specimen. Theoretically this could be also be described in the Specimen, but i think it would be easier to code this in the Observation profile.
Kevin Power (Sep 30 2019 at 14:33):
@Bret H / @Alexander Mankovich / @Patrick Werner - I might ask that you break this conversation into its own Topic if that is OK? The "Publication Prep 2019" topic has been more for 'how are are we doing to get published' and I don't want to lose a good discussion like this with all the other back and forth here.
Bret H (Sep 30 2019 at 14:34):
The question is weather we should handle it now or after publication.
Kevin Power (Sep 30 2019 at 14:36):
@Bret H - Sorry, I didn't get that vibe from the latest comments.
Bret H (Sep 30 2019 at 15:02):
The motivation for the conversation here is to determine if we can remove the somatic profile to reduce the number of TBD-LOINC codes and decrease the number of profiles (overlap). @Alexander Mankovich was asked as he has been implementing the somatic profile. I am not sure if it is understood weather or not the somatic profile covers patient germline PGx?
Kevin Power (Sep 30 2019 at 16:13):
FWIW - This is not a new issue/question - it has been brought up numerous times. Each time it is discussed, it starts with a notion that something should be / could be done better, and someone takes the todo to make a firm proposal, but to my knowledge we haven't seen a firm proposal yet. If a new proposal comes up from this discussion, that is fantastic. Just not sure we can take the time to discuss such a proposal if we all still want to publish ASAP.
Kevin Power (Sep 30 2019 at 16:14):
I would still suggest breaking this into a new topic, continue the discussion and brainstorming, and then once a firm proposal can be made, log a tracker that we can discuss before our next publication.
Jamie Jones (Oct 03 2019 at 18:50):
adding/upgrading tables shortly, please review the CSS for readability
Kevin Power (Oct 03 2019 at 19:00):
Trackers still pending. Updates from the Assignee's welcome (doesn't paste very well, but current assignees are @Patrick Werner / @James Jones @ Bob Milius ) :
ID Summary Assignee Resolution
22814 Variant needs a component for variant type Patrick Werner Updated proposal from FHIR subgroup discussion 7/22: 1. Update DNA-change type (48019-4)...
24685 Reassess must supports as they are inherited by profiles James Jones persuasive with mod - remove all “must support” flags on profiles and add text to IG scope...
24880 Split HGNC CodeSystem into two Codesy Patrick Werner persuasive: The pattern for "gene studied ID" has to be updated to allow all three SystemUris-...
24853 need data element for Variant Inherited From Patrick Werner Persuasive: FINAL proposal is to Define a new component on the Variant profile. * New code...
16876 Use of publically available external coding systems and autocomplete lookup tables - 2018-May Genomics #58 Patrick Werner Deferred - Needs more work?
19876 many examples do not validate against an IG profile using the FHIR Validator Nobody persuasive with mod - fix examples, create textual guidance in the IG for where and how to...
16510 Need more examples Bob Milius Persuasive: See signup...
Jamie Jones (Oct 03 2019 at 19:14):
Just pushed code table to the appendix for GF#16876 (someone on windows please review the table for readability once it updates, I may need to add some -webkit nonsense). It doens't reflect the changes we mentioned on Tuesday yet however. (inclusion of GLString, concerns over COSMIC oid). Happy to apply those updates to the IG once they are reflected on https://docs.google.com/spreadsheets/d/1XeXVPZ2DLf69Uohhzl0b-XQOTF3-91CQ0l2Hvn_Uvi4/edit
Kevin Power (Oct 03 2019 at 19:22):
When I look at the page on my Windows VM, it does show a little wonky:
Kevin Power (Oct 03 2019 at 19:23):
It does scroll OK.
Jamie Jones (Oct 03 2019 at 20:12):
Yep, the scrollbar generates inside the div instead of on top of it. Should be an easy fix, thanks
Jamie Jones (Oct 03 2019 at 22:01):
Okay, I guess cross-browser-compatible aesthetic scrolling tables is a rabbit hole I am unprepared to tackle in this timeline... I can remove the vertical borders in the header so it isn't obvious that windows pushes the rows to the left 16pixels at least
Jamie Jones (Oct 03 2019 at 22:02):
fix should be up soon to review
Jamie Jones (Oct 03 2019 at 22:31):
(actually, pushing later with text updates)
Jamie Jones (Oct 04 2019 at 02:15):
I lost the thread but I can update dna-change type in the glossary (binding is already updated, just need that concept map ;))
Kevin Power (Oct 04 2019 at 12:07):
@Patrick Werner - Any update on your trackers?
Kevin Power (Oct 04 2019 at 13:56):
BTW @James Jones - On a Windows IE browser, the Glossary looks good. The Code Systems pages is probably good enough, but honestly not sure the "freeze header row" requirement is worth the wonky display?
Jamie Jones (Oct 04 2019 at 16:52):
I can apply 24853 - the variant inherited tracker
Jamie Jones (Oct 04 2019 at 16:52):
and will finish must supports shortly
Kevin Power (Oct 04 2019 at 18:53):
I just pushed up a small handful of QA fixes for ValueSets and CodeSystems.
Kevin Power (Oct 04 2019 at 20:40):
Just pushed up finishing GF#22814 (added concept map), and additional QA fixes.
Jamie Jones (Oct 04 2019 at 20:51):
great, pushing must supports and some QA shortly
Kevin Power (Oct 04 2019 at 20:56):
@ Bob Milius - You are listed as the Assignee on GF#19876 (examples validating) and GF#16510 (need more examples). On the first, will you get a chance to review the HLA examples and see what validation errors can be resolved? On the second, if you feel we have enough examples, are you OK marking that one as applied?
Kevin Power (Oct 04 2019 at 20:57):
@James Jones - For GF#16876 (coding systems page), I think we can mark that one as applied, agreed?
Kevin Power (Oct 04 2019 at 21:40):
Looks like GF#24685 (must supports) is done and can be marked as applied (@James Jones )
Kevin Power (Oct 04 2019 at 21:42):
Looks like GF#24880 (HGNC code systems) and GF#24853 (variant inherited from) are still left. Perhaps @Patrick Werner will feel better soon and be able to knock them out. If they are still todo by Monday, I will hopefully have some time to knock them out. Unless someone else (@James Jones / @Bret H ?) gets to them first.
Jamie Jones (Oct 04 2019 at 21:45):
I can do 24853 I think, and will update the trackers in GForge
Bret H (Oct 04 2019 at 22:20):
nver mind
Jamie Jones (Oct 05 2019 at 03:02):
For a check in, after hacking past the "multiple profiles matched" and "unable to confirm LA codes" errors, we've got Screen-Shot-2019-10-04-at-10.58.39-PM.png
Jamie Jones (Oct 05 2019 at 03:05):
There were a lot of dummy references and incorrect displays to clean up but things are looking pretty good!
Jamie Jones (Oct 05 2019 at 03:05):
I'll put the 'required' LOINC lists back on before I push
Kevin Power (Oct 05 2019 at 03:09):
Wowzers! Nice job @James Jones !
Jamie Jones (Oct 05 2019 at 03:10):
Just leaves the "broken" dummy links in the narrative from the tbd-codes set and the "Unable to provide support for code system..." errors
Jamie Jones (Oct 05 2019 at 03:11):
(and the "I can't read LOINC lists" errors, which will bring us back up a lot on the larger examples)
Kevin Power (Oct 05 2019 at 03:29):
If that is all we have that feels pretty good
Patrick Werner (Oct 07 2019 at 13:24):
still sick, but feeling slowly better. Started working on: https://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=24880
Jamie Jones (Oct 07 2019 at 14:11):
great, thanks!
Patrick Werner (Oct 07 2019 at 14:21):
just realized, that the binding is VS binding (extensible) and there are no patterns involved.
Patrick Werner (Oct 07 2019 at 14:22):
So just change the binding to HGNC genenames?
Jamie Jones (Oct 07 2019 at 14:26):
I'd be okay with that, we can go over it on call today, unless Kevin has other plans
Kevin Power (Oct 07 2019 at 14:28):
That is fine. I might also need some help with how to define the discriminator by type then by code to resolve our other problem as well. I have tried a few different ways, but am failing.
Jamie Jones (Oct 07 2019 at 14:28):
yeah I was looking at the documentation and couldn't figure out how to do it locally
Jamie Jones (Oct 07 2019 at 14:28):
well, my first 2 attempts didn't work at least
Kevin Power (Oct 07 2019 at 14:29):
I am up to about 7 attempts :slight_smile:
Patrick Werner (Oct 07 2019 at 14:30):
i won't make it into the call. Still too sick :-(
Proposal:
- HGNC ValueSet change: http://hl7.org/fhir/uv/genomics-reporting/ValueSet/hgnc --> http://hl7.org/fhir/uv/genomics-reporting/ValueSet/hgnc-genename
- This VS includes everything from CS: http://www.genenames.org/geneId
Patrick Werner (Oct 07 2019 at 14:30):
So for geneFamily we would need another slice of component.
Patrick Werner (Oct 07 2019 at 14:31):
Or: leave the HGNC VS URI as is, the VS includes all concepts from http://www.genenames.org/geneId and http://www.genenames.org/genegroup
Patrick Werner (Oct 07 2019 at 14:31):
Thinks the second approach will be easier.
Jamie Jones (Oct 07 2019 at 14:32):
i think we voted specifically to split the valuesets in consideration of patient safety
Patrick Werner (Oct 07 2019 at 14:32):
yes on the CodeSystem side. But the binding could be to the same VS
Jamie Jones (Oct 07 2019 at 14:33):
oh, I see what you mean
Kevin Power (Oct 07 2019 at 14:34):
I think 2 code systems, 1 value set is OK?
Patrick Werner (Oct 07 2019 at 14:50):
just pushed:
Changed HGNC VS to explicitly include geneID and geneFamily CS
changed hgnc system in examples to geneID URI
removed trailing slashes from all systems in examples
changed codeSystem Strings in examples https: -> http:
Jamie Jones (Oct 07 2019 at 16:05):
I will draft/add some text to the genegroup cell on the codesystems appendix to differentiate and then this one should be good, thanks
Kevin Power (Oct 07 2019 at 20:01):
@Patrick Werner - With your change, can we mark https://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=24880 as Applied?
Jamie Jones (Oct 07 2019 at 20:08):
Still have to add a bit of text to the codesystem table. The structures look good to me though.
Jamie Jones (Oct 07 2019 at 20:28):
looking more closely at the code systems spreadsheet, it talks about tables such as https://clinicaltables.nlm.nih.gov/apidoc/genes/v3/doc.html but does not actually say where to find them??
Jamie Jones (Oct 07 2019 at 20:29):
were we specifically not allowed to include them here? the links are in the LRI and I think these are the resources Clem wanted to point implementers to
Kevin Power (Oct 07 2019 at 20:34):
I don't know why we couldn't reference them? Maybe @Liz Amos can confirm?
Jamie Jones (Oct 07 2019 at 20:40):
https://clinicaltables.nlm.nih.gov/valueSetExpand.html seems like a great resource
Jamie Jones (Oct 07 2019 at 21:22):
I did a quick go through to cleanup some bits from the translation and added a light entry on GLString per Bob's request
Liz Amos (Oct 07 2019 at 21:39):
@James Jones I might be missing some context... Yes, I think the intention was always to include the link to the specific Clinical Table Search Service link as a place to "go check out the coding system". What is not referenced exactly? The link to the table? (What part of the spreadsheet should I be reading to orient myself to your question?)
Jamie Jones (Oct 07 2019 at 21:47):
@Liz Amos everything in the spreadsheet I had is now on http://build.fhir.org/ig/HL7/genomics-reporting/codings.html I didn't see the links to the services in the spreadsheets, until I looked up the LRI PDF itself
Patrick Werner (Oct 08 2019 at 14:00):
The links to the table services were lost at some point of the transformation PDF -> Spreadsheet
Patrick Werner (Oct 08 2019 at 14:01):
I think we shouldn't include them. For v2 they are very handy, as V2 hadn't terminology support. FHIR has terminology capability included. So pointing to the table service could confuse people.
We are providing the System URI, and ValueSets as part of the IG, i think that is sufficient.
Patrick Werner (Oct 08 2019 at 14:02):
I already saw people using system uris beginning with https://clinicaltables.nlm.nih.gov/.....
Kevin Power (Oct 08 2019 at 14:07):
If we provide it, it would be for reference purposes - probably for a user to have a way to browse most of the data in a single place.
Patrick Werner (Oct 08 2019 at 14:22):
As a general link to: https://clinicaltables.nlm.nih.gov/ i assume.
Kevin Power (Oct 08 2019 at 14:22):
Seems like a good start to me?
Patrick Werner (Oct 08 2019 at 14:22):
@Liz Amos would be nice to include the FHIR System URIs of these CS into clinical tables.
Jamie Jones (Oct 08 2019 at 16:26):
Looks like 'exampleCanonical' is part of the 'example[x]' element on ImplementationGuide.resource, which is 0..1 (http://build.fhir.org/implementationguide.html) so declaring one example as representative of multiple profiles is not going to work. Will have to break apart bundles for additional canonicals...
Patrick Werner (Oct 08 2019 at 16:36):
just pushed an update variant-inheritance now includes asked-unknown as a concept
Jamie Jones (Oct 08 2019 at 16:40):
might be a good tracker to place, but also I guess each profile may deserve its own focused example
Kevin Power (Oct 08 2019 at 16:49):
Yea, at least we have examples - we can log a tracker to get them to display as the canonical example.
Kevin Power (Oct 08 2019 at 16:53):
Also, question - Would anyone mind if we mark the remaining 3 trackers as Applied now, then I can go ahead and get started on Ballot Reconciliation?
Kevin Power (Oct 08 2019 at 16:54):
We can still update the last three with additional comments, references to the commit, etc. And even if we run into an issue, we can undo the change. Since I don't expect a reason to undo, I am OK with marking as applied now - anyone disagree?
Kevin Power (Oct 08 2019 at 16:54):
Again, my thinking is that when I send out the reconciliation, I want the statuses of the trackers to be up to date.
Jamie Jones (Oct 08 2019 at 17:01):
sounds good to me
Kevin Power (Oct 08 2019 at 20:33):
Ballot reconciliation is done (I think).
Bret H (Oct 08 2019 at 21:12):
almost got the final text for the guidance on validation. @Kevin Power can I run it past you for a final check?
Kevin Power (Oct 08 2019 at 21:31):
you bet.
Last updated: Apr 12 2022 at 19:14 UTC
