Stream: hapi
Topic: What about using a common format to bulk import custom t...
Lin Zhang (Oct 19 2020 at 09:41):
For example, using HAPI FHIR CLI to upload a large custom CodeSystem in a common format such as obo, owl, or even FHIR-native format. Currently, there is a module for uploading a custom terminology in addition to the modules specific to IMGTHLA, LOINC and SCT. But its current format is pretty simple and lack of documentation. It's not that easy for Implementers to build a little bit richer or more complex content, such as various properties (including relationships).
Jens Villadsen (Oct 19 2020 at 09:43):
hapi currently supports that you can upload entire FHIR IG's - does that fit your need?
Lin Zhang (Oct 19 2020 at 09:50):
@Jens Villadsen Thanks a lot. Such a big capability would be far more beyond my understanding.:big_smile: For now, I'd like to focus on a granular/concrete function for that purpose exactly.
Lin Zhang (Oct 19 2020 at 09:54):
A widely recognized format would provide benefits for both HAPI's developer community and adopters/users.
Jens Villadsen (Oct 19 2020 at 10:33):
@Lin Zhang FHIR IG's conform to. a subclass of NPM ... so it is sort of a reckonized format already ;) - that said, I have no experience in working with OBO or OWL
Jens Villadsen (Oct 19 2020 at 10:38):
Do you have an example of a codesystem expressed in OWL/OBO?
Lin Zhang (Oct 19 2020 at 11:03):
There are numerous code systems in such formats on the internet.
Lin Zhang (Oct 19 2020 at 11:03):
Say, HPO in obo format.
Lin Zhang (Oct 19 2020 at 11:04):
I'm newbie to NPM, just going to learn it.
Lin Zhang (Oct 19 2020 at 11:07):
Human Phenotype Ontology - OBO Foundry
www.obofoundry.org/ontology/hp.html
Jens Villadsen (Oct 19 2020 at 14:21):
I would suggest to have a look at https://github.com/aehrc/fhir-owl then - that seems to be able to convert OWL to FHIR and then you can upload it
Lin Zhang (Oct 19 2020 at 15:55):
Thanks, Jens. And is there any tool to upload the fhir output into the hapi fhir jpa server?
Lin Zhang (Oct 19 2020 at 15:59):
I mean uploading such a output as an external CodeSystem in the same way as uploading LOINC and SCT.
Jens Villadsen (Oct 19 2020 at 20:30):
well I assume that you can just post the resulting codesystems to any FHIR server that accept such use - thats not HAPI specific
Jens Villadsen (Oct 19 2020 at 20:31):
@Lin Zhang if you are using HAPI FHIR and you need custom support I suggest that you have a look at https://github.com/jamesagnew/hapi-fhir/blob/9e8e98b6fbe9a05afc87df324cd67302e137aab9/hapi-fhir-jpaserver-base/src/main/java/ca/uhn/fhir/jpa/provider/TerminologyUploaderProvider.java#L128 and branch of from there
Lin Zhang (Oct 19 2020 at 23:27):
Appreciate that. I mean such terminologies are so large that the routine POST operation would not be suitable. Yes, you are right: branching from there is what I'm considering.
Lin Zhang (Oct 20 2020 at 04:38):
@Jim Steel It would be desirable to make FHIR-CLaML as a component of HAPI FHIR CLI's Terminology Uploader? Thanks, anyway.
Jim Steel (Oct 20 2020 at 04:39):
That may be possible, by having a library build. We would want it to also continue standalone, too, though
Jim Steel (Oct 20 2020 at 04:41):
We certainly just use POST to send the output of FHIR-OWL and FHIR-ClaML into our server, even for very large CodeSystems like HPO
Lin Zhang (Oct 20 2020 at 04:45):
Absolutely, standalone would be fine. I'm wondering how long such large imports would take approximately.
Lin Zhang (Oct 20 2020 at 04:51):
And how to refuse GETTing/reading the full resource by the clients?
Jim Steel (Oct 20 2020 at 04:52):
We don't refuse GETting. Although we do sometimes employ an implementation trick of allowing a POST/PUT of a CodeSystem with content=not-present, which we take to mean "index all the concepts so the CodeSystem works normally, but never return concepts in a read, vread or search"
Jim Steel (Oct 20 2020 at 04:54):
I can't remember how long the imports take. A little while, but no more than a few minutes, I don't think. But our import isn't using HAPI's serialization, so YMMV
Lin Zhang (Oct 20 2020 at 04:54):
Yeah, that's exactly what I expect.
Jim Steel (Oct 20 2020 at 04:55):
(To be clear, that not-present trick isn't something you'll find in the spec. It's non-standard)
Lin Zhang (Oct 20 2020 at 04:55):
Okay, roger that.
Last updated: Apr 12 2022 at 19:14 UTC
