The FHIR specification has an incomplete canonical CodeSystem resource at http://build.fhir.org/codesystem-snomedct.html(or the earlier / published version: https://www.hl7.org/fhir/codesystem-snomedct.html )
This is something SNOMED International should really take ownership of, complete it, host it and keep it up to date...but obviously this group can help with all of that (except the hosting!).
I've included a table below which indicates the elements and their values in the current resource. The other thing to consider is the HTML rendering and what it should say, the current one you can see at https://www.hl7.org/fhir/codesystem-snomedct.html is in the current resource as generated text from the resource.
Ideally this should be hosted at http://snomed.info/sct and behave as a proper FHIR endpoint (e.g. respond appropriately to JSON and XML accept headers).
Please comment on the appropriateness of the current values and suggested changes.
Element | Value | Discussion | ||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
id | snomedct | Specified by individual server, so we could leave blank here. | ||||||||||||||||||||||||||||||||
url | http://snomed.info/sct | We'd expect this to redirect to the most recent international release. | ||||||||||||||||||||||||||||||||
version | This probably should be a specific URI to the particular edition/version but not defined in the Canonical form. Suggest we mandate this field if this document is specifying a template. RH had concerns about this since concepts couldn't then be referred between different versions. Note that the context here is an instance of a Code System resource from at Term Server perspective, not individual concepts as used a medical record where the SCTID plus description provides meaning. | |||||||||||||||||||||||||||||||||
identifier |
| This is the SNOMED OID used in other specifications eg CDA. | ||||||||||||||||||||||||||||||||
name | SNOMED CT | While this is the canonical value, each server would specify the particular edition they're making available. | ||||||||||||||||||||||||||||||||
title | SNOMED CT (all versions) | Not required? | ||||||||||||||||||||||||||||||||
status | active | |||||||||||||||||||||||||||||||||
experimental | false | |||||||||||||||||||||||||||||||||
publisher | IHTSDO | Change to SNOMED International | ||||||||||||||||||||||||||||||||
contact |
| Changes to snomed.org | ||||||||||||||||||||||||||||||||
description | SNOMED CT is the most comprehensive and precise clinical health terminology product in the world, owned and distributed around the world by The International Health Terminology Standards Development Organisation (IHTSDO). |
| ||||||||||||||||||||||||||||||||
copyright | © 2002-2018 International Health Terminology Standards Development Organisation (IHTSDO). All rights reserved. SNOMED CT®, was originally created by The College of American Pathologists. "SNOMED" and "SNOMED CT" are registered trademarks of the IHTSDO http://www.ihtsdo.org/snomed-ct/get-snomed-ct |
| ||||||||||||||||||||||||||||||||
caseSensitive | false | Definition of element here is "If code comparison is case sensitive" which because SCTIDs are numeric, it's not. | ||||||||||||||||||||||||||||||||
hierarchyMeaning | is-a | Suggest improving the documentation for this element, is somewhat ambiguous. "Properties of parent apply to child" is certainly true. | ||||||||||||||||||||||||||||||||
compositional | true | "True If code system defines a post-composition grammar." | ||||||||||||||||||||||||||||||||
versionNeeded | false | "This flag is used to signify that the code system has not (or does not) maintain the definitions, and a version must be specified when referencing this code system." | ||||||||||||||||||||||||||||||||
content | not-present | We're not expecting to include all of SNOMED-CT in this resource. | ||||||||||||||||||||||||||||||||
filter |
| RH notes that the distinction between plural and not is subtle in text and substantial in effect. Could use "constraint" for the first instance. However, is likely already in use. ML confirms and in fact this field was previously called "constraint". "PostCoordination" a suggested alternative for 2nd which is the more problematic of the two. ML: Is "expressions" more relevant to an expansion profile? PW: Changing "are" to "should be" would make intention clearer.
| ||||||||||||||||||||||||||||||||
property |
| We need URI values for parent / child and Normal Form here. If / when the URI standard is extended to include ECL then parent / child would arrive that. ML: parent and child are general properties that are not SNOMED specific, these are FHIR specified properties. Have inserted FHIR URIs here. Suggestion that normalFormTerse is changed to Canonical Normal Form, and normalForm changed to Necessary Long Normal Form (and use these terms in the description column also, with sufficient text to explain the difference between the two). URI is, also, optional. Noted the impact on implementers in changes here, so name changes noted above will not be recommended at this time.
However in any event, the description should be updated here.
| ||||||||||||||||||||||||||||||||
property (cont) | There is also listed the attributes used in SNOMED CT, a couple of examples to express the pattern are
| Code should be the SCTID rather than term.
Perhaps more relevant to use attributes currently in use in the International Edition. FSN should be populated in the description column. | ||||||||||||||||||||||||||||||||
<additional> | Additional elements worth considering populating are
| DM suggested date was worth populating to show when the resource last changed. Boiler plate text for purpose? "SNOMED CT (Systematized Nomenclature of Medicine -- Clinical Terms) is a standardized, multilingual vocabulary of clinical terminology that is used by physicians and other health care providers for the electronic exchange of clinical health information." https://searchhealthit.techtarget.com/definition/SNOMED-CT The URL for the entire code system is a notional valueset that contains all versions of all editions. It would not change from instance to instance and is immutable. | ||||||||||||||||||||||||||||||||
<additional> | Another thing to consider is whether the valueSet, if it can exist, if theoretically expanded would return all of SNOMED CT International Edition or the SNOMED CT "Universal" Edition - i.e. which does this CodeSystem resource represent? | To be defined for the individual code systems. Could state the implicit value set endpoint for the server. |
6 Comments
Michael Lawley
We should be careful with the values here. For example, the Resource should not be mandating the value of the
id
field since this is "owned" by the terminology service.Dion McMurtrie
I agree Michael Lawley, I've just copied here what was in the existing resource because I thought it may be more approachable for most for review as a table
Dion McMurtrie
There's an issue here to consider with extensions. Does this CodeSystem resource represent
It is maybe worth considering whether there should be CodeSystem resources for each of the extension editions, for example one at http://snomed.info/sct/32506021000036107 for SNOMED CT-AU, perhaps just proxying or redirecting to a CodeSystem hosted by the Australian Digital Health Agency. This difference may just be in the properties (additional attributes) and perhaps copyright statements, so perhaps that isn't worthwhile?
Peter G. Williams
Do you think this behaviour would be different if the concept had been promoted to the core?
Dion McMurtrie
As mentioned by Reuben Daniels in our London meeting, it would be great if SI could redirect requests to extensions.
For example HTTP requests for http://snomed.info/sct/32506021000036107 or any version specific URI like http://snomed.info/sct/32506021000036107/20180131 could redirect to somewhere like https://www.healthterminologies.gov.au/access?content=snomed
Peter G. Williams
I'll try to progress this. Please confirm desired endpoint for us to use.
Note to self: watch headers should be maintained.