Stream: terminology
Topic: Available FHIR terminology servers
Robert McClure (Aug 17 2018 at 18:17):
Folks, I know many of you are eyebrow-deep in the IG but I'm looking for a FHIR terminology server (v3 or even better v4) that accepts PUTs, has international and US SCT, LOINC, ICD-10-CM, and supports the standard filters. I'd like to make some value sets and they need to stick around through the next ballot cycle (perhaps less if I move them.) Can anyone direct me to a site?
Rob Hausam (Aug 17 2018 at 18:39):
Mine is close to that - it's R4 and it could be fully there by sometime next week. For one thing I haven't gotten to updating to the latest SNOMED and LOINC yet, but I need to. In the meantime you can try it at http://fhir.hausamconsulting.com/ if you want.
Rob Hausam (Aug 17 2018 at 18:40):
the endpoint is http://fhir.hausamconsulting.com/baseR4
Rob Hausam (Aug 17 2018 at 18:42):
it's based on standard HAPI functionality (which I'll update soon to the latest)
it's otherwise not very fancy (at least not yet) but has the basics
Grahame Grieve (Aug 17 2018 at 20:31):
ok you can use test.fhir.org/r3 or /r4
Robert McClure (Aug 17 2018 at 20:48):
@Grahame Grieve if I want to specify use of the latest us extension for sct, would I put http://snomed.info/sct/731000124108 into the system element? And that works on your test server?
Grahame Grieve (Aug 17 2018 at 20:53):
no. this is explained on the http://hl7.org/fhir/snomedct.html page:
The URI http://snomed.info/sct identifies the SNOMED CT code system
and
The SNOMED CT URI Specification describes how to unambiguously reference a particular version of a SNOMED CT edition:
http://snomed.info/sct/[sctid]/version/[YYYYMMDD]where [sctid] is the concept id that identifies the given SNOMED CT edition (based on the identifier of the most dependent module), and "YYYYMMDD" is the date of release.
Grahame Grieve (Aug 17 2018 at 20:53):
tx.fhir.org has the latest version of US snomed, but I haven't got around to putting it on test.fhir.org yet - that'll be getting some love next week
Robert McClure (Aug 17 2018 at 22:45):
duh. how could I have forgotten that...
But then to confirm, http://snomed.info/sct/731000124108 is a valid version identifier for "latest us edition" which means, I've just realized, that for all other code systems if version is specified, you are to use a specific version, but for SCT it could mean, go find the latest one with this [sctid] or a specific version with the YYYMMDD on it. Kind of a pain for TS implementers
Grahame Grieve (Aug 17 2018 at 22:55):
I didn't follow that. if you don't specify a version.. use the latest... what's the issue?
Robert McClure (Aug 17 2018 at 23:16):
I indicate us edition in the "version" element of the value set compose but that means the $expand must use the latest available us edition. That is not how other code systems work where if there is a version specified in the "version" element, you don't need to figure out which is the latest of that version.
Grahame Grieve (Aug 17 2018 at 23:38):
ok, that's true. but it's analagous to not specifying a version at all - then you must figure out which is the latest version (though I haven't found that to be a handicap so far). SCT is more complicated, you must track which is latest, per edition. That's baked into how SCT works. You could, perhaps, require that for some contexts, a full version uri is required always .
Jack Bowie (Aug 18 2018 at 16:53):
I've really tried to be silent on this issue, but I just have to get it off my chest. I do not agree with the location of the uri/version split that has been specified for SCT. In my mind, SCT US is a separate CodeSystem from SCT Canada, SCT International, etc. And versions are time-based "snapshots" of CodeSystems. Thus the 'system' uri for SCT US should be "http://snomed.info/sct/731000124108", and a version would be designated by YYYMMDD (or the full string as Graham cited above if required). Specifying edition in the version string rather than the system uri seems very inconsistent to me. It results in the confusion with regard to "latest version" semantics that Rob describes. Sigh, that feels better ;-)
Grahame Grieve (Aug 18 2018 at 20:04):
so you you claim that the concept 160245001 (No current problems or disability) means something different in US Snomed than it does in any other snomed?
Jack Bowie (Aug 18 2018 at 20:31):
Not necessarily. Just that 160245001 has a meaning in every edition (in which it is defined) that is appropriate for that edition. And could have different attributes/properties. Editions aren't "extensions" or supplements. They are complete CodeSystems unto themselves. Am I missing something (I appreciate that I am coming in late to this discussion.)
Lloyd McKenzie (Aug 18 2018 at 20:40):
Code system is a names pace in which each code has a semi-fixed meaning. Snomed is a single namespace across all editions. Changing attributes and properties is fine across versions of a single code system.
Jack Bowie (Aug 18 2018 at 20:59):
Thanks, that's what I was looking for. "Snomed is a single namespace across all editions." If that's the way we choose to define it, okay. But then putting edition into version seems to me to break the normal understanding of "version". Seems fairly arbitrary. I could argue that SCT US is by your definition also a well-defined CodeSystem. "Editions" of ICD-10 aren't treated this way. So another special case for SNOMED? Thanks again. I got my minute on the soapbox.
Grahame Grieve (Aug 18 2018 at 22:25):
ICD-10 would be treated that way if it had concept permanence.
Grahame Grieve (Aug 18 2018 at 23:08):
This is a compromise. we could have gone either way, and perhaps the way we chose is less convenient for terminology servers. but that's consistent with the overall approach: move as much work and complexity to the server as possible
Michael Lawley (Aug 18 2018 at 23:15):
If there was a separate CodeSystem URI per Edition, then a ValueSet like "all descendants of limb fracture" would need to be (re-)defined for every Edition.
By having a single CodeSystem for all Editions of SNOMED CT, there can be a single ValueSet definition, and then you can specify either a specific Edition or Version URI as desired when performing the expansion. [edited to make meaning more explicit]
Jack Bowie (Aug 18 2018 at 23:28):
Oh. This is a subtlety I was not aware of. But understandable given the decision. Thanks. We'll need to look into this.
Jack Bowie (Aug 19 2018 at 15:37):
One more question. Say I have an intentional ValueSet, like all descendants of "Heart Disease", based on snomed.info/sct (no version). I expand this ValueSet on a server in the US and a server in Australia. Could the expansions be different (because they have different "defaults" for version/edition) or will they always be the same (i.e., based on SCT International)?
Lloyd McKenzie (Aug 19 2018 at 16:51):
They can be different
Michael Lawley (Aug 19 2018 at 22:27):
Just as they could be different with different servers in the US (because one has an older release). However, the expansion result should include the actual SNOMED version used in the expansion.parameter section
Robert McClure (Aug 20 2018 at 14:47):
Agree that expansion.parameter should be populated, but what I'd like to see is that the minimum good practice is to include the code system and code system version with every code in the expansion, and description as an optional item.
Last updated: Apr 12 2022 at 19:14 UTC
