- Created by Peter G. Williams, last modified on 2021-May-19
Background
The FHIR API necessarily assumes that any given SNOMED CT concept has been published and appears in a specific CodeSystem instance, ie that it actually officially exists. In practice, however, a SNOMED Terminology Server used for the creation of SNOMED CT concepts will feature some sort of workflow of "work in progress", unpublished concepts. In this situation there will be a requirement to access this unpublished content.
As an example, in the specific situation of the Snowstorm implementation, terminology author's work is organised into branches much like a developer's code repository with official releases being held on a branch off the "root" like MAIN/20210131, and the "daily build" existing on the root itself. By default any FHIR API request will run against a particular release branch (or the most recent published version if not otherwise specified) and so we need a way to indicate that the request should run against the work-in-progress, root, daily-build branch.
This FHIR based requirement and solution has a very narrow focus. Unfortunately, the implications of such a proposal are much broader.
Reusing "xsct"
SNOMED International already uses the X (eXperimental) indicator for alpha & beta releases of International and Country Editions of SNOMED CT eg xSnomedCT_BelgiumExtensionRF2_PREPRODUCTION_20210315T120000Z/Snapshot/Terminology/xsct2_Concept_Snapshot_BE1000172_20210315.txt this additional letter is added to make clear that the contents have not been "officially" published, and components are often marked with a (future) effective time.
Other Use Cases
There is a use case for making content available externally before it can be officially published with COVID-19 Vaccines being a real-world example of this.
Context(s) of use
There are a number of places in which an 'x' modified URI could be used:
- Referring to the unpublished content (ie daily build, work-in-progress)
- Referring to a complete 'Member release' or 'Alpha/beta release' loaded into a terminology server.
What's quite fortunate between these two use cases is that - as understood within SNOMED International - an alpha or beta package looks just like an officially published release. The effective time is populated where required, and will be the intended effective time of the eventual finished product. In the SI release process, this may be produced from the daily build / work-in-progress .
In the context of FHIR, most operations specify a URI for the code system itself. This would usually be http://snomed.info/sct and so an "unversioned" variant of that would be http://snomed.info/xsct However we should also consider if the 'x' could be applied to component URIs eg http://snomed.info/xid/288804006 ( see 2.2 URIs for Components and Reference Set Members ) and with the module and version also specified http://snomed.info/xsct/900000000000207008/version/20210131/id/288804006
Note that - as far as FHIR is concerned for example - a SNOMED concept is a SNOMED concept. It would be quite acceptable to refer to http://snomed.info/id/65781000052101 a concept in the Swedish edition without the module - http://snomed.info/sct/45991000052106/id/65781000052101
Implications
Given that Alpha/Beta/Preview releases are populated with an effective time, it should normally be quite possible to refer to them using a normal URI, even if the effective time is in the future.
If possible, any response returned from a query that includes this 'unpublished' indicator should include a warning that the SCTIDs are subject to change until the point were they have been officially published. They are for testing and evaluation purposes only, and should on no account be used in any Patient Medical Record.
Alternative Solutions
Previous suggestions for accessing unpublished content included using the string "UNVERSIONED" in place of an effective time in the version URI:
http://snomed.info/sct/900000000000207008/version/UNVERSIONED
This visually clunky solution is at least unambiguous and not easy to miss.
- No labels
3 Comments
Michael Lawley
It is not clear to me what the "xsct" URI(s) being proposed here are intended to identify.
For example,
In FHIR, the CodeSystem URI MUST always be http://snomed.info/sct - if it is anything else, then it is referring to a different CodeSystem.
CodeSystem versions are another matter. The FHIR SNOMED spec (Snomedct - FHIR v4.0.1 (hl7.org)) states that versions must be referred to as per the SNOMED CT URI specification. This is where it is desirable to be able to refer to alpha / beta / "unpublished" versions.
Hence, I would see that http://snomed.info/xsct/900000000000207008/version/20210131 and http://snomed.info/xsct/900000000000207008 would be useful additional URIs for Editions and Versions of SNOMED CT. That is, adding:
http://snomed.info/xsct/{sctid}
http://snomed.info/xsct/{sctid}/version/{timestamp}
to section 2.1 of the spec (and then flowing these through to 2.3).
However, http://snomed.info/xsct on its own should not be used to identify anything.
Also, what is the relevance of the following to "xsct" or FHIR (http://snomed.info/id/{sctid} URIs are not used in FHIR).
Dion McMurtrie
I think it would be best to bring this back to a specific set of use cases that we could then challenge possible solutions against. I think the main one articulated above (which is a good one) is how to refer to not officially released content in SNOMED CT using FHIR, and the extension of that might be that there could be multiple parallel unreleased states and you'd like to be able to reference a specific one.
Taking that use case, Michael is right, the CodeSystem URI isn't the thing to mess will - this is http://snomed.info/sct. The CodeSystem version URI however could achieve this sort of thing and is the right place for it.
Really that version URI is identifying two optional things
From these two things the module dependencies can be determined to calculate the content that's "in scope" of that version of that edition, and the state of the components determined to craft responses. They are optional in the sense that if the version isn't specified the server can autoresolve that to the most recent version, and if the module is absent...well the whole version URI is absent at that point and the server can resolve to whatever is the latest version of it's "default" edition.
So of the form
http://snomed.info/sct/{sctid}
http://snomed.info/sct/{sctid}/version/{timestamp}
you've got the sct, {sctid}, version, and {timestamp} to play with. I think xsct is probably the best candidate because I don't think you really want to mess with the datatypes of {sctid} and {timestamp} ?
So maybe that lets you refer to the
That last one is interesting because it lets you distinguish between "latest unreleased state" and "latest unreleased state staged for 20210731". But what it doesn't do is let you refer to a particular "branch" of unreleased development other than that known by a timestamp because that's the datatype in that part of the URI.
Maybe we could create a new path form to deal with that edge case to draw the distinction between a "release version" or "impending release version" and a branch of activity in the form:
http://snomed.info/xsct/{sctid}/branch/{branch_name}
Where "branch" is only valid as a subpath of xsct, and {branch_name} doesn't need to be a timestamp.
Or we can just agree that the "version" value in an xsct path isn't required to be a timestamp. That's less explicit but perhaps that's simpler...
Are there other use cases you were thinking of Peter G. Williams that we're not thinking of?
Michael Lawley
Hmm, is the (proprietary tool-specific) notion of a "branch" relevant here? Perhaps this would be better generalised to "tag"? I would suggest:
where tag is any sequence of characters not including an (unencoded) semi-colon (;), question mark (?) or hash (#) symbol