Stream: IG creation
Topic: Referencing PHINVads Value sets
Grahame Grieve (Aug 21 2020 at 23:25):
from the next release of the IG publisher, this is the correct way to reference PHINVads value sets:
- figure out the OID for the value set you wish to reference
- Add a dependency to your IG:
uri = http://fhir.org/packages/us.cdc.phinvads
packageId = us.cdc.phinvads
version = 0.2.0
- the version will be at least 0.2.0, but I will release new versions of the package as phinvads updates by request
- When you want to reference the value set (e.g. in a profile binding), just use the canonical URL http://phinvads.cdc.gov/fhir/ValueSet/{oid}
Grahame Grieve (Aug 21 2020 at 23:28):
I'm not sure where I should document that...
Grahame Grieve (Aug 21 2020 at 23:31):
@Sarah Gaunt you can update yours without waiting for the new release, but the html references will be to the wrong place until I get the next version out. But they will work for validation purposes.
Sarah Gaunt (Aug 22 2020 at 01:03):
Oooo, exciting! Thanks @Grahame Grieve
Sarah Gaunt (Aug 24 2020 at 02:13):
I've added this:
<dependsOn>
<uri value="http://fhir.org/packages/us.cdc.phinvads"/>
<packageId value="us.cdc.phinvads"/>
<version value="0.2.0"/>
</dependsOn>
And am now getting this warning: The canonical URL for an Implementation Guide must point directly to the implementation guide resource, not to the Implementation Guide as a whole
Grahame Grieve (Aug 24 2020 at 02:14):
hmm. I'll investigate that. it shouldn't matter for the validation process
Sarah Gaunt (Aug 24 2020 at 02:19):
Also now getting a bunch of Unable to provide support for code system http://snomed.info/sct version 20200301 (from http://tx.fhir.org/r4) (see Tx log) that weren't there before. Looks to be everywhere I've used a SNOMED code. Not sure if it's related or not.
Sarah Gaunt (Aug 24 2020 at 02:22):
Plus for all PHINvads value sets (I think all anyway): [Unable to determine whether the provided codes are in the value set http://phinvads.cdc.gov/fhir/ValueSet/2.16.840.1.114222.4.11.6070 because the value set or code system is not known to the validator]
Grahame Grieve (Aug 24 2020 at 02:31):
some of the phinvads value sets depend on internal code systems that we don't know. See thread on #terminology about that
Sarah Gaunt (Aug 24 2020 at 02:36):
Ok.
The value set fhir/ValueSet/2.16.840.1.114222.4.11.6070 is all SNOMED plus an HL7 nullFlavor. https://phinvads.cdc.gov/vads/ViewValueSet.action?oid=2.16.840.1.114222.4.11.6070
Sarah Gaunt (Aug 24 2020 at 02:37):
And just to keep it simple - this one is just 2 SNOMED codes: https://phinvads.cdc.gov/vads/ViewValueSet.action?oid=2.16.840.1.114222.4.11.7116 (and is still getting that error)
Grahame Grieve (Aug 24 2020 at 02:57):
this is all committed?
Sarah Gaunt (Aug 24 2020 at 03:56):
Yes
Sarah Gaunt (Aug 24 2020 at 03:56):
http://build.fhir.org/ig/HL7/fhir-bfdr/branches/master/qa.html#_scratch_ig-build-temp-E24RS1_repo_input_resources_composition_composition-jurisdiction-fetal-death-not-named
https://github.com/HL7/fhir-bfdr/tree/master
Grahame Grieve (Aug 24 2020 at 04:51):
all the ones I see are US specific concepts
Sarah Gaunt (Aug 24 2020 at 06:05):
Ah, ok. I still haven't had a chance to figure out how to reference SNOMED US. I guess that's my next task...
Grahame Grieve (Aug 24 2020 at 06:06):
I'll commit that shortly
Grahame Grieve (Aug 24 2020 at 07:00):
committed and pushed for you to look at
Grahame Grieve (Aug 24 2020 at 07:02):
@Rob Hausam what version of US SCT is running on tx.fhir.org?
Rob Hausam (Aug 24 2020 at 12:25):
@Grahame Grieve We're on 20200301 - the latest version. We should have the 20200901 version available in just over a week.
Grahame Grieve (Aug 24 2020 at 19:00):
ok thanks
Grahame Grieve (Aug 24 2020 at 23:40):
ok @Sarah Gaunt I sorted out the phinvads issues. You have one issue left: there's 2 sets of Y/N codes in v2, and you could have chosen either set. PHINVaads chose the other set, based on tracing the OIDs down.
Sarah Gaunt (Aug 24 2020 at 23:41):
Wow - thanks! Will fix that y/n thing shortly and test...
Grahame Grieve (Aug 24 2020 at 23:43):
y they used http://terminology.hl7.org/CodeSystem/v2-0532
Craig Newman (Aug 26 2020 at 16:51):
I've updated my birth defects reporting IG (just on my local machine for now) to use the new PHINVADS references and now the value sets aren't available when I try to open them. I get this error:
image.png
And I also have new QA errors for my examples saying:
None of the codes provided are in the value set http://phinvads.cdc.gov/fhir/ValueSet/2.16.840.1.114222.4.11.7582 (http://phinvads.cdc.gov/fhir/ValueSet/2.16.840.1.114222.4.11.7582), and a code from this value set is required) (codes = http://terminology.hl7.org/CodeSystem/v3-EducationLevel#SCOL)
It looks like Sarah's IG has the same sort of issues. Any suggestions on what might be going wrong?
Craig Newman (Aug 26 2020 at 19:57):
I tried running uploading to the current build and it failed to download the PHINVADS package. I also tried running sushi on a different local machine and it's also failing to download the package.
image.png
Grahame Grieve (Aug 26 2020 at 20:12):
ah. There's a problem here.
- @Ward Weistra this is one of those packages that packages.fhir.org refuses to process
- @Nick Freiter because packages.fhir.org refuses to process this package, even though it's a valid package, it only lives on packages2.fhir.org. All my tools fail over to packages2.fhir.org if they don't find the package on packages.fhir.org
& @Craig Newman you need to update the version in the dependency to 0.7.0
Ward Weistra (Aug 27 2020 at 09:21):
@Grahame Grieve Oops, we didn't pick up that feed yet. Will make sure that happens and automate feed discovery.
Martijn Harthoorn (Aug 27 2020 at 12:00):
Latest feed ingestion log:
Processing: HL7.org Publications: http://hl7.org/fhir/package-feed.xml
Skipping hl7.fhir.core-4.2.0. The Fhir version was not recognized: 4.2.0.
Skipping hl7.fhir.core-4.4.0. The Fhir version was not recognized: 4.4.0.
Skipping hl7.fhir.core-4.5.0. The Fhir version was not recognized: 4.5.0.
Skipping hl7.fhir.r5.core-4.2.0. The Fhir version was not recognized: 4.2.0.
Skipping hl7.fhir.r5.core-4.4.0. The Fhir version was not recognized: 4.4.0.
Skipping hl7.fhir.r5.core-4.5.0. The Fhir version was not recognized: 4.5.0.
Skipping hl7.fhir.r5.examples-4.5.0. The Fhir version was not recognized: 4.5.0.
Skipping hl7.fhir.r5.expansions-4.2.0. The Fhir version was not recognized: 4.2.0.
Skipping hl7.fhir.r5.expansions-4.4.0. The Fhir version was not recognized: 4.4.0.
Skipping hl7.fhir.r5.expansions-4.5.0. The Fhir version was not recognized: 4.5.0.
Skipping hl7.fhir.us.davinci-deqm-0.1.0. The Fhir version was not recognized: 3.0.1|3.5.0.
Skipping hl7.fhir.us.phcp-0.1.0. The Fhir version was not recognized: 3.1.0.
Downloading package: hl7.fhir.uv.bulkdata-0.1.0
Publishing to: https://packages.simplifier.net
400 BadRequest -- Package version '0.1.0' already exists for package 'hl7.fhir.us.bulkdata'
Processing: Common HL7 Terminology: http://terminology.hl7.org/package-feed.xml
Skipping hl7.terminology.r5-1.0.0. The Fhir version was not recognized: 4.4.0.
Processing: FHIR Foundation Guides: http://fhir.org/guides/package-feed.xml
Skipping fhir.argonaut.pd-0.1.0. The Fhir version was not recognized: 1.9.0.
Skipping fhir.hspc.core-0.1.0. The Fhir version was not recognized: 1.9.0.
Processing: FHIR Foundation Support Packages: http://fhir.org/packages/package-feed.xml
us.nlm.vsac#0.1.0 misses a fhirVersion
us.cdc.phinvads#0.7.0 misses a fhirVersion
us.cdc.phinvads#0.6.0 misses a fhirVersion
us.cdc.phinvads#0.5.0 misses a fhirVersion
us.cdc.phinvads#0.4.0 misses a fhirVersion
us.cdc.phinvads#0.3.0 misses a fhirVersion
us.cdc.phinvads#0.2.0 misses a fhirVersion
us.cdc.phinvads#0.1.2 misses a fhirVersion
us.cdc.phinvads#0.1.1 misses a fhirVersion
us.cdc.phinvads#0.1.0 misses a fhirVersion
fhir.tx.support.r3#0.4.0 misses a fhirVersion
fhir.tx.support.r4#0.4.0 misses a fhirVersion
hl7.fhir.pubpack#0.0.7 misses a fhirVersion
hl7.fhir.pubpack#0.0.6 misses a fhirVersion
hl7.fhir.pubpack#0.0.5 misses a fhirVersion
fhir.test.data.r4#0.2.1 misses a fhirVersion
fhir.test.data.r3#0.2.1 misses a fhirVersion
fhir.tx.support.r3#0.3.2 misses a fhirVersion
fhir.tx.support.r2#0.2.1 misses a fhirVersion
fhir.test.data.r2#0.2.1 misses a fhirVersion
fhir.tx.support.r4#0.3.1 misses a fhirVersion
fhir.tx.support.r3#0.3.1 misses a fhirVersion
hl7.fhir.xver.r3#1.2.1 misses a fhirVersion
fhir.test.data.r4#0.2.0 misses a fhirVersion
fhir.test.data.r3#0.2.0 misses a fhirVersion
fhir.tx.support.r3#0.3.0 misses a fhirVersion
fhir.tx.support.r2#0.2.0 misses a fhirVersion
fhir.test.data.r2#0.2.0 misses a fhirVersion
fhir.tx.support.r4#0.3.0 misses a fhirVersion
hl7.fhir.xver-extensions#0.0.4 misses a fhirVersion
fhir.tx.support.r3#0.2.0 misses a fhirVersion
fhir.tx.support.r4#0.2.0 misses a fhirVersion
hl7.fhir.pubpack#0.0.4 misses a fhirVersion
hl7.fhir.xver-extensions#0.0.3 misses a fhirVersion
hl7.fhir.xver.r4#1.2.0 misses a fhirVersion
hl7.fhir.xver.r3#1.1.0 misses a fhirVersion
hl7.fhir.xver.r4#1.1.0 misses a fhirVersion
hl7.fhir.xver-extensions#0.0.2 misses a fhirVersion
fhir.test.data.r4#0.1.0 misses a fhirVersion
fhir.test.data.r3#0.1.0 misses a fhirVersion
fhir.tx.support.r3#0.1.0 misses a fhirVersion
fhir.tx.support.r2#0.1.0 misses a fhirVersion
fhir.test.data.r2#0.1.0 misses a fhirVersion
hl7.fhir.xver.r3#1.0.0 misses a fhirVersion
hl7.fhir.xver.r4#1.0.0 misses a fhirVersion
fhir.tx.support.r4#0.1.0 misses a fhirVersion
Skipping hl7.fhir.pubpack-0.0.2. The Fhir version was not recognized: 4.1.
Skipping hl7.fhir.pubpack-0.0.3. The Fhir version was not recognized: 4.1.
Skipping hl7.fhir.xver-extensions-0.0.1. The Fhir version was not recognized: 4.0.
Grahame Grieve (Aug 27 2020 at 12:02):
us.cdc.phinvads#0.7.0 misses a fhirVersion
None of those errors are right
Martijn Harthoorn (Aug 27 2020 at 12:06):
These errors are about the feed
http://hl7.org/fhir/package-feed.xml has these fields:
<dc:creator>HL7, Inc</dc:creator>
<fhir:version>4.0.1</fhir:version>
<fhir:kind>fhir.ig</fhir:kind>
<pubDate>Tue, 25 Aug 2020 12:00:00 GMT</pubDate>
While this feed does not:
http://fhir.org/packages/package-feed.xml
Grahame Grieve (Aug 27 2020 at 12:06):
oh. I thought you'd look in the package
Martijn Harthoorn (Aug 27 2020 at 12:07):
Also
Martijn Harthoorn (Aug 27 2020 at 12:07):
But that's done by the server.
Martijn Harthoorn (Aug 27 2020 at 12:07):
We have different package server (endpoints) per Fhir (major) Version.
So I use the feed data to know where to talk to.
Grahame Grieve (Aug 27 2020 at 13:08):
ok fixed
Martijn Harthoorn (Aug 27 2020 at 13:23):
All packages from http://fhir.org/packages/package-feed.xml have now passed.
Craig Newman (Aug 27 2020 at 16:08):
Sushi is now working for the PHINVADS package, but I've been trying to set up Sushi/IG Publisher on a new laptop and while the IG publisher works fine on my old machine for my IG, it's failing on the new one with a Java Heap space error where it seems to be loading the PHINVADS package (don't know if that's a coincidence or not). I've tried increasing the memory per previous Zulip posts ( https://www.google.com/search?q=make+more+memory+available+to+java) but publisher still seems to only have access to 247MB (Detected Java version: 1.8.0_261 from C:\Program Files (x86)\Java\jre1.8.0_261 on x86 (32bit). 247MB available). Is there a trick to allocating more memory that I'm missing? I have checked the old machine that is working, and it doesn't seem like I ever changed anything there.
Sarah Gaunt (Aug 27 2020 at 19:56):
I have the exact same issue on my new(ish) machine. Haven't been able to run locally for a month or so now (been too lazybusy to dig further tbh). Would love to know the trick also!
Vassil Peytchev (Aug 27 2020 at 20:18):
Which java version and distribution are you using? java -version usually tells you.
Craig Newman (Aug 28 2020 at 12:54):
java version "1.8.0_261"
Java(TM) SE Runtime Environment (build 1.8.0_261-b12)
Java HotSpot(TM) Client VM (build 25.261-b12, mixed mode)
Craig Newman (Aug 28 2020 at 12:56):
My old laptop (where it is running) is on version 1.8.0_231-b11 (so a little behind presumably)
Craig Newman (Sep 01 2020 at 12:29):
I'm still hoping to get some advice on how to resolve the java heap space error. I have upped the memory but it doesn't seem to be respected (IG Publisher is still reporting that only 247MB is available). Did I make the Java config change incorrectly? Thanks
image.png
Craig Newman (Sep 01 2020 at 12:30):
Since I made the change above, I have restarted but it seems not to make a difference
Vassil Peytchev (Sep 01 2020 at 13:28):
Have you tried setting the _JAVA_OPTIONS system environment variable? Some discussions here and here
Craig Newman (Sep 01 2020 at 16:03):
I set them based on the references you provided but IG Publisher is still reporting only 247MB available
image.png
Vassil Peytchev (Sep 01 2020 at 16:07):
Not JAVA_OPTS, _JAVA_OPTIONS - here is why
Craig Newman (Sep 01 2020 at 17:05):
No luck with JAVA_OPTIONS either (assuming I did it right). Still stuck at 247MB
image.png
Vassil Peytchev (Sep 01 2020 at 17:24):
It is _JAVA_OPTIONS - starts with underscore :-)
Also, make sure it is a SYSTEM variable, and therefore, reboot...
Craig Newman (Sep 01 2020 at 18:00):
I upped it to -Xmx1024m and it got almost to the end before it runs out of memory, but when I went to 2048, it errors immediately saying it can't allocate that much memory. Can I go somewhere in between?
Craig Newman (Sep 01 2020 at 18:02):
Checking internet connection...
Reply from 104.196.166.17: bytes=32 time=70ms TTL=116
We're online
Picked up JAVA_TOOL_OPTIONS: -Dfile.encoding=UTF-8
Picked up _JAVA_OPTIONS: -Xms256m -Xmx2048m
Error occurred during initialization of VM
Could not reserve enough space for 2097152KB object heap
Press any key to continue . . .
Vassil Peytchev (Sep 01 2020 at 18:03):
try 1536?
Craig Newman (Sep 01 2020 at 19:03):
That seems to be the magic number. The publisher ran successfully. Thanks for the guidance. I appreciate the help
Vassil Peytchev (Sep 01 2020 at 19:05):
I can't quite imagine why you couldn't get 2GB for heap memory, but if it works... :tada:
Sarah Gaunt (Sep 04 2020 at 00:45):
I was having this exact same issue with my new machine. I did the above and thought it was working. Until it wasn't.
What seems to have permanently fixed it for me (without having to set any environment vars etc.) was to install the 64 bit version of Java. I have no clue how/why I installed the 32bit in the first place. This also seems to have made my IG run way faster and right at the get go says: "7239MB available".
Sarah Gaunt (Sep 04 2020 at 01:07):
And watching memory usage - the highest I noticed it getting was 5023, so 1536 was never going to cut it for my IG! I think there is possibly some limit of memory that the 32 bit java can use?
Lloyd McKenzie (Sep 04 2020 at 01:33):
@Grahame Grieve Is there a way for the IGPublisher to check whether it's running on 32-bit Java and automatically blow up with an appropriate error message - because I don't think it's possible to make it run in the memory space the 32-bit version has access to?
Grahame Grieve (Sep 04 2020 at 02:08):
I won't make it blow up but I will make a specific note during start up to that effect
Last updated: Apr 12 2022 at 19:14 UTC
