Stream: hapi
Topic: terminology service
Joel Schneider (Sep 20 2016 at 16:38):
Running an example HAPI 2.0 jpaserver in STU3 mode, it returns a conformance statement which includes "operation" entries for CodeSystem "lookup", and ValueSet "expand" and "validate-code". However, it doesn't include entries for CodeSystem "subsumes" or "infer", or ConceptMap "translate" or "closure".
Among the missing operations, for now I'm mainly interested in the ConceptMap/$translate operation.
Is there active development underway on terminology service operations currently missing from HAPI 2.0?
James Agnew (Sep 27 2016 at 21:50):
Hi @Joel Schneider ,
At this point, none of those operations are implemented. I am hoping to get them implemented in the long term, but we're not currently working on them (too many other things need our focus right now).
I do believe that all of the fundamental infrastructure is there in order to support these things, so certainly if anyone wanted to get involved and have a go at some of these things we would welcome it. :) Long term hopefully we'll get all of these things in either way.
Joel Schneider (Sep 28 2016 at 19:08):
Thanks for the status info, @James Agnew.
There is code implementing some terminology service operations in BaseJpaResourceProviderCodeSystemDstu3.java and BaseJpaResourceProviderValueSetDstu3.java. Following that pattern, I suppose a similar BaseJpaResourceProviderConceptMapDstu3.java class could be added to implement ConceptMap operations.
Meanwhile, the use case in which I'm most interested involves a code system which has new codes added to it every day. Because of the continuous churn, I think a one-time load process would not work well for this code system. To handle this situation, instead of attempting to continuously load new codes into a hapi-like server, I'm thinking of setting up an API gateway.
The API gateway would implement HL7 FHIR terminology service APIs by interacting with other (non-FHIR) services containing up-to-date information about the ever-growing code system. For a small number of code systems, the service could offer an authoritative HL7 FHIR terminology service API, but it might only support those few code systems for which it can be authoritative.
Exploring the terminology service story further in this direction may lead one to imagine an ecosystem involving a set of narrowly-focused authoritative terminology services and another set of more general-purpose terminology services which aggregate and cache results from the narrowly-focused services. An idea for the future, perhaps ...
James Agnew (Sep 28 2016 at 21:20):
That approach makes sense.
For what it's worth though- HAPI JPA's built-in terminology service probably could handle ever-growing code systems if you needed it to. For code systems that are defined as external, HAPI looks to separate database tables and those aren't bound to HAPI's resource versioning mechanisms. I mean, there would definitely be work to do to make this work (all of the existing code assumes a complete upload every time), but it's certainly possible.
Rob Hausam (Sep 28 2016 at 21:33):
I'm interested in helping flesh this out, as I would like to have it, too. Bandwidth to work on it has been the issue, of course - but hopefully I can spend some time on it between now and San Antonio.
Last updated: Apr 12 2022 at 19:14 UTC
