Stream: terminology
Topic: Source of ValueSets for tx.fhir.org/r4?
Paul Lynch (Jun 27 2019 at 13:38):
tx.fhir.org/r4 says it has 2,411 ValueSets. When I download the fhir definitions JSON zip I find only 1,316 (v2-tables.json:428, v3-codesystems.json:216, valuesets.json:672).
Where do the rest of the ValueSets come from?
Rob Hausam (Jun 27 2019 at 16:33):
The tx server has additional sources beyond the FHIR spec - there are separate import capabilities for SNOMED CT editions, LOINC, RxNorm, ICD variants and a few others, plus support for additional code systems and value sets in the separate fhir.tx.support package. I haven't tallied it up, but I expect that would account for the difference.
Paul Lynch (Jun 27 2019 at 18:33):
SNOMED CT? I would not have thought any data from SNOMED CT could be public. (Here at NLM, we wanted to make a small subset of just the codes public, and couldn't get permission.)
Paul Lynch (Jun 27 2019 at 18:35):
SNOMED CT aside, would there be any objection to our copying the rest of the data to our own public (HAPI) server, which runs over https?
Rob Hausam (Jun 27 2019 at 18:59):
One answer is that the end user is responsible to have the proper license(s) in place, and there's not a general easy way to copy the content wholesale (at least for larger terminologies). I'm sure that at least a significant part of the content can be copied, but I'm not sure exactly what licensing agreements/arrangements @Grahame Grieve has in place. It's probably best to ask him directly about that, depending on exactly what you want to do. Another question is how would you intend to do the copying? Besides the general REST capabilities for CodeSystem and ValueSet resources, HAPI has a limited set of specific terminology loaders (different from the tx.fhir.org set) for a few well-known terminologies.
Grahame Grieve (Jun 27 2019 at 20:30):
I'm not exactly sure why tx.fhir.org has that many more value sets than the core spec. I upload a few value sets as well (e.g. out the package fhir.support.tx) and from a numebr of IGs, but I'm sure that's not 900 or so.
Grahame Grieve (Jun 27 2019 at 20:30):
mostly it has additional code systems
Yunwei Wang (Jun 28 2019 at 14:22):
and there's not a general easy way to copy the content wholesale (at least for larger terminologies).
A solution would be support bulk export of value sets. That was on my list for connectathon.
Michael Lawley (Jun 28 2019 at 22:48):
@Yunwei Wang do you need something other than _search and the resulting Bundle?
Grahame Grieve (Jun 29 2019 at 03:28):
I realised what the gap is - the. V2 and v3 value sets are not in the definitions
Grahame Grieve (Jun 29 2019 at 03:28):
I recommend you use the package instead - much simpler
Yunwei Wang (Jun 30 2019 at 22:22):
@Michael Lawley This is to use bulk data export to get big chunk of value sets from one server. The request would look like
GET [base]/$export?_type=ValueSet&_typeFilter=[value set search criteria]
In stead of one Bundle, the output is an array of value set in ndjson format.
This is just my thought. It WAS on my connectathon to-do list.
One drawback for the current bulk data export is it does NOT provide a way to run $expand operation. I raised that issued on May ballot.
Last updated: Apr 12 2022 at 19:14 UTC
