FHIR Chat · ibm as a fhir terminology server

Stream: terminology

Topic: ibm as a fhir terminology server

Nikola Tanjga (Mar 17 2021 at 05:58):

Hi guys, as the title suggests: has anyone experience with ibm fhir server as a terminology server?
We are right now deciding which open source fhir server we should use for our new Terminology Exchange server in Austria and would, if needed, expand the code with the implementation of some terminology operations we need (and of course give these implementations back to the open-source community).
I'm aware that there is an ibm stream here, but i wanted to choose this more neutral stream. I've seen many discussions here about the hapi as a terminology server, so this would be our other choice. Still wanted to give ibm a chance, they seem pretty active and seem to focus on performance. Whats your thoughts?

Lin Zhang (Mar 18 2021 at 14:06):

HAPI FHIR JPA Server support different relational databases.

Josh Mandel (Mar 18 2021 at 14:36):

@Lee Surprenant FYI

Josh Mandel (Mar 18 2021 at 14:37):

@Caitlin Voegele FYI

Lee Surprenant (Mar 18 2021 at 14:52):

IBM FHIR Server implements a light-weight version of the terminology services. It works well for "extensional" codesystems (ones that list all their codes), but its currently rather limited for large codesystems like SNOMED CT, LOINC, etc. However, there is a clear interface for extending it and documentation for that is at https://ibm.github.io/FHIR/guides/FHIRTerminologyGuide

Lee Surprenant (Mar 18 2021 at 14:56):

Additionally, @John Timm has been working on some interesting stuff here (in the open) which uses a graph db (janusgraph) to implement a more performant flavor and supports more advanced scenarios...definitely connect with us on #ibm if you're interested in discussing that or potentially collaborating

Michael Lawley (Mar 19 2021 at 06:30):

Interesting. Is there an implementation of the SPI (https://ibm.github.io/FHIR/guides/FHIRTerminologyGuide/#fhir-terminology-service-provider-interface-spi) that simply makes REST call to an external service?

Michael Lawley (Mar 19 2021 at 06:33):

Also, I don't understand the contract associated with $closure and the SPI Set<Concept> closure(Coding coding);
Normal use of $closure would involve passing in multiple Codings, and also a name parameter to allow for separate closure tables. It looks like the SPI only allows for a single closure table and (inefficiently) building it one Coding at a time?

John Timm (Mar 27 2021 at 22:09):

Yes, this is a limitation of the SPI. In the current design, different FHIRTermServiceProvider implementations might support different code systems and therefore we look at each coding individually. That said, if FHIRTermService determined that all code systems mentioned in the closure request could be serviced by the same service provider, then an optimization might be to send off all codings to that provider and let it handle things as efficiently as possible.

Also, we don’t have an implementation of FHIRTermServiceProvider that makes calls to an external REST API (though I suppose that it wouldn't be too hard to implement and we may even have an issue in our backlog to build it).
As it stands, we currently have two implementations of FHIRTermServiceProvider — one that is registry based for code systems with CodeSystem.content = complete and one that is graph-based for larger code systems where CodeSystem.content = not-present. The latter stores terminological content in a graph database (JanusGraph). @Michael Lawley I'd be happy to set up some time to give you a walk-through of what we have. The graph database support and really the terminology capabilities in general are pretty experimental and the documentation is lacking but we will continue to enhance / improve.