Stream: implementers
Topic: Validator problem with terminology server
Eizen Kimura (Dec 03 2019 at 06:26):
Hello,
I tried to validate my custom CodeSystem/Valueset with some resources.
I have setup HAPI server and tried with the following validator parameters.
java -jar org.hl7.fhir.validator.jar -tx http://localhost:8080/hapi-fhir-jpaserver/fhir/ -txLog term.txt -debug -version 4.0 Sample_CKUP_Observation.json -ig CKUP_Observation.StructureDefinition.xml
Even if I explicitly specified parameters to use FHIR R4, however, validator seems to access with FHIR R5 Specs.
How to workarounds? And if the source code of validator is hosted in GitHub etc, I may be able to contribute something.
Thank you.
.. FHIR Version 4.0, definitions from hl7.fhir.r4.core#4.0.1
.. connect to tx server @ http://localhost:8080/hapi-fhir-jpaserver/fhir/
(v4.0.1)
+ .. load IG from CKUP_Observation.StructureDefinition.xml
- load file: CKUP_Observation.StructureDefinition.xml .. success
.. validate [Sample_CKUP_Observation.json]
Terminology server: Check for supported code systems for http://loinc.org
FAILURE validating Sample_CKUP_Observation.json: error:1 warn:0 info:0
Error @ Observation.code.coding[0] (line 6, col8) : Error java.lang.ClassCastException: class org.hl7.fhir.r5.model.CapabilityStatement cannot be cast to class org.hl7.fhir.r5.model.TerminologyCapabilities (org.hl7.fhir.r5.model.CapabilityStatement and org.hl7.fhir.r5.model.TerminologyCapabilities are in unnamed module of loader 'app') validating Coding: org.hl7.fhir.exceptions.TerminologyServiceException: java.lang.ClassCastException: class org.hl7.fhir.r5.model.CapabilityStatement cannot be cast to class org.hl7.fhir.r5.model.TerminologyCapabilities (org.hl7.fhir.r5.model.CapabilityStatement and org.hl7.fhir.r5.model.TerminologyCapabilities are in unnamed module of loader 'app')
Grahame Grieve (Dec 03 2019 at 08:36):
the validator uses the R5 code base internally. The problem isn't the version thing, it's that API hasn't implemented the TerminologyCapabilities Resource yet, and so doesn't support the validator
Eizen Kimura (Dec 03 2019 at 22:12):
Thank you for your comment. If a Terminology Server that supports R5 comes out, I'll try again.
the validator uses the R5 code base internally. The problem isn't the version thing, it's that API hasn't implemented the TerminologyCapabilities Resource yet, and so doesn't support the validator
Grahame Grieve (Dec 03 2019 at 22:12):
tx.fhir.org and ontoserver support the validator for R4.
Grahame Grieve (Dec 03 2019 at 22:13):
@James Agnew are you planning to add support for TerminologyCapabilities.
Grahame Grieve (Dec 03 2019 at 22:13):
the issue is not R5
David Simons (Sep 06 2021 at 15:31):
Our team also ran into challenges using HAPI as a TX server with hl7validator...
The metadata?_summary=true, and metadata?mode=terminology calls seem to work fine - but are followed by an exception. Let me collect some more detail, maybe a next layer of the onion...
David Simons (Sep 07 2021 at 07:28):
With a current hl7-validator it get's the CapabilityStatement from HAPI as TX, but cannot read it:
Caused by: java.lang.ClassCastException: class org.hl7.fhir.r5.model.CapabilityStatement cannot be cast to class org.hl7.fhir.r5.model.TerminologyCapabilities (org.hl7.fhir.r5.model.CapabilityStatement and org.hl7.fhir.r5.model.TerminologyCapabilities are in unnamed module of loader 'app')
which seems to be the same as @Eizen Kimura got back in 2019.. see above
Looks like hl7-validator expects, when it asks for "metadata?mode=terminology", only the <TerminologyCapabilities> part. HAPI returns that embedded in the overall <CapabilityStatement>, while tx.fhir.org and r4.ontoserver.csiro.au return only the <TerminologyCapabilities> part, which then _is_ accepted by hl7-validator.
- HAPI FHIR Server - 5.4.2
- FHIR Validation tool Version 5.4.9 and 5.5.1
Has anyone been using the hl7validator with HAPI as TX succesfully? @Grahame Grieve @James Agnew
Thank you for all your support!
PS: will want to use with both STU3 and R4 - and corresponding hl7validator TerminologyClients.
PS: we're in part forced to look into this - alternative tx - because tx.fhir.org being down so often...
Grahame Grieve (Sep 07 2021 at 19:49):
tx.fhir.org is down extremely rarely. So you should investigate why you wrongly think it is
Lloyd McKenzie (Sep 07 2021 at 20:14):
That wasn't our experience over the summer Grahame. I agree that it's gotten much better the last month or so, but those issues are recent enough that there's certainly not going to be an impression of "high reliability".
Grahame Grieve (Sep 07 2021 at 20:22):
well, I was absent, and the system went through some major disaster who's source I still haven't figured out, and the patch arrangements put in place while I was gone locked the server into instability. However I've invested deeply in stability in the last few weeks since I got back - my main priority. And it's much more stable now, though I'm still not there yet
Grahame Grieve (Sep 07 2021 at 20:24):
and @David Simons issues are extremely recent, and described while the server is actually up
David Simons (Sep 08 2021 at 11:14):
Thanks - and sorry to mix up topics.
Let's keep this thread on HL7Validator+HAPI,
and discuss tx.fhir.org availability here: https://chat.fhir.org/#narrow/stream/179252-IG-creation/topic/Term.20server.20is.20down.2E.2E.2E .
Last updated: Apr 12 2022 at 19:14 UTC
