Stream: terminology
Topic: Does FHIR support incremental imports for the content of ...
Lin Zhang (Sep 30 2020 at 16:31):
is it possible to import/upload the content of a CodeSystem just like using some other formats such as obo and owl? For example, import the basic description of the CodeSystem, all the codes and names of its concepts, all the synonyms, all the properties/relationships in each step. Or group these different kinds of contents as separate blocks/sections in a single import file. In such a way, there would be no need to construct a complete hierarchy/tree to be imported in a single step/batch as the structure of the CodeSystem resource shows.
Rob Hausam (Sep 30 2020 at 21:20):
I would say that is entirely up to the server. Each server (HAPI, Graham's, Ontoserver, etc.) has mechanism(s) for loading terminologies (particularly the large standard ones). With some servers the smaller terminologies can often be loaded by POSTing a CodeSystem resource containing the content.
Lin Zhang (Oct 01 2020 at 00:08):
@Rob Hausam Largely, directly based on SQL scripts for the physical db? In other words, the developer of the terminology-specific import has to be very familiar with the db structure of the server, right?
Rob Hausam (Oct 01 2020 at 00:32):
Yes, that is correct, Lin. It's not necessarily always SQL based, but it does require familiarity with the underlying db structures. So far we don't have anything like a standard terminology bulk load API in FHIR (although it would be possible to do quite a bit with ConceptMap itself, depending on what the server can support).
Lin Zhang (Oct 01 2020 at 00:50):
How large is a Terminology resource to be called so "large" that is has to be imported in a bulk way?
Rob Hausam (Oct 01 2020 at 01:32):
There isn't really a fixed answer to that. It depends primarily on the capabilities and capacity of the particular server. Making a (very) rough stab at it, I would say that many servers probably could fairly readily handle a CodeSystem resource with up to something like maybe 10,000 codes. POSTing a CodeSystem resource to a FHIR endpoint on a server, though, doesn't necessarily guarantee that the server will then actually support that code system in subsequent terminology service operations (e.g. $expand, $lookup, $validate-code, terminology-based search, etc.) - but depending on the specific server it might. But for code systems of > 10,000 codes, that is probably less likely, and I think that any server (that I know of) would use a bulk load process of some kind to support code systems with nearly 100,000 or more codes - including the standard large ones like SNOMED CT and LOINC.
Grahame Grieve (Oct 01 2020 at 01:39):
defining that many codes is a really large amount of work. There's just not that many code systems that large
Lin Zhang (Oct 01 2020 at 01:45):
Granular and incremental APIs for importing might help split the bulk job into smaller ones.
Michael Lawley (Oct 02 2020 at 02:54):
https://github.com/aehrc/fhir-owl is our mechanism for dealing with OWL. This classifies and then generates an FHIR CodeSystem from the result. It's how we load in things like HPO
Lin Zhang (Oct 02 2020 at 11:19):
@Michael Lawley Does FHIR ontologically support OWL individuals?
Lloyd McKenzie (Oct 02 2020 at 13:08):
@Grahame Grieve @Eric Prud'hommeaux
Eric Prud'hommeaux (Oct 02 2020 at 13:39):
That depends on what you want OWL to do with the individual. If you want OWL to perform some logic to e.g. stratify patients by some SNOMED description, sure (see https://github.com/BD2KOnFHIR/BLENDINGFHIRandRDF). If you want OWL to e.g. infer that two Patient records are the same record, I guess you could make Patient.identifier an inverse function property. I wouldn't advise it, though, as they are probably not the same record, but instead two records about the same person, and I'm not sure how you'd profit from that inference (maybe to clean some data, but SPARQL query would probably be more direct).
In net, I think the useful stuff is covered, as described in Harold's BLENDINGFHIRandRDF repo and presentations.
Lin Zhang (Oct 02 2020 at 15:18):
@LIoyd McKenzie@Eric Prud'hommeaux|192267 Interesting. Thanks.
Last updated: Apr 12 2022 at 19:14 UTC
