that is correct - URIs were an older way of thinking about how to ‘find’ the ref set. Now with IHTSDO / SNOMED CT, we can imagine ref sets identified by SNomed code (they are in SNOMED CT). The problem is that the whole industry is not yet converted to SNOMED CT, and as far as I can see today, there is no guarantee that it ever will. We just don’t know. So while we could potentially put SNOMED_CT::123456789 to refer to ref set 123456789 in the SCT concept space, what do we put for LOINC, ICDx or local terminologies?
What probably does make sense anyway is to relax the spec in ADL 1.5 to allow both forms (and one day, probably we get rid of the URI form). Does that seem reasonable?
this relates to the question of how SNOMED represents Ref set ids. In SCT concept space, all ‘concept’ ids are unique for the whole planet, with special bits being used to distinguish concepts and ref sets within national or other ‘extensions’ (i.e. outside the international release). So the question for the industry overall is: do we go to the SNOMED way of doing things (requires all other terminologies to be representable in SNOMED CT form) or do we have some more technologically neutral form? The URNs examples below raise the question: what is the internationally agreed namespacing scheme to use? WHat are the rules for establishing new URNs?
I don’t know what the answers are at this stage, because it requires some sort of global / standards agreement, and that does not yet exist.
indeed… the original idea was that we would use some scheme space like ‘terminology:xxxx’. We have use URL-like URIs in the past inn actual implementations, on the basis that we thought that one day IHTSDO or someone would finally get their act together and either decide to move to the SCT way of doing things in unison, or else define a URN scheme for everyone to use (i.e. not just SNOMED). This has not happened yet…
me too. If someone wants to come up with a simple clean little specification, we could put that into openEHR, and find ways to map from it to whatever turns up in the future…
What probably does make sense anyway is to relax the spec in ADL 1.5
to allow both forms (and one day, probably we get rid of the URI
form). Does that seem reasonable?
This would mean, then, a revision to section 8.3.1 of the AOM 1.5
spec. Currently it says that ARCHETYPE_ONTOLOGY.constraint_bindings
contains DV_URI objects.
I see this as an opportunity for some joint work on specification of terminology binding, in the intersection of interests between the openEHR community and for one: IHTSDO.
I hope the following notes are both helpful and true, corrections are most welcome!
[Specialists language from the SNOMED CT technical lexicon is in '' marks]
The identification of bindable 'components' from SNOMED CT is certainly via ReferenceSet IDs (not yet part of the standard but very soon will be) via SubsetIDs
For SubsetIDs I would expect the {URI/URN etc.} to include a 'Version'
For Concepts the 'ConceptID' should of itself be adequate
For query specifications - mentioned somewhere in this thread - the only way to identify these will in the future be via an 'intensional' ReferenceSet definition, but to be meaningful this may (in some cases must) be used in conjunction with the named Edition of SNOMED CT against which this will be run.
For enumerated ReferenceSet members (not the query but a results set of a query) then the ReferenceSetID would be needed.
In all the above cases it is necessary to consider if the named 'Edition' and 'Release' of that 'Edition' may need to be included. The proposed uses of 'Module' Identifiers is a further topic.
The 'Releases' are identified such as "UK Edition"
Releases are identified in ways that are decided by each SNOMED CT 'National Release Center' such as the effective date, but this is not a formal convention.
[Anyone wanting the finer points of detail for IHTSDO standards and common practice for issuance and use of : Namespaces, Editions, Release Centres, ModuleIDs and other such metadata are invited to join, say, the Special Interest Groups in IHTSDO.
Overall, in this intersection of interests between multiple information models (say HL7 and UK's LRA), and multiple terminology and classification schemes (say SNOMED CT and ICD and..) makes this topic one where working-up rather than handing-down a solution is most likely to happen and succeed.
most people consider ICD10 as simply a different terminology from ICD9. There are variants like ICD10AM, ICD9CM and so on… and in theory, there are no ‘versions’ of these terminologies, at least as far as I know - WHO issues once and that’s it (not sure about the AM and CM releases though).
‘proper’ URIs or URNs may be the correct approach. URLs almost certainly are not. So the spec might remain correct technically, just that the guidance for what URIs can be used should probably change.
Both ICD 10 and ICD 10-AM have yearly updates. Mapping tables are issued to show the changes: new codes are introduced, some are deleted, and some change their meaning...
It seems to me a terminology server for each terminology version is needed as a reference at the clinical archetype definition stage.
As the terminologies stabilise (apart from new discoveries), the responsibility will then be on each server to resolve changes, as the health record will not change.
I would disagree that the version of ICD-10 is “10”. Even terminology systems like ICD-10 are revised (for example in Sweden once a year) and released in different releases. I therefore think that is fair to handle ICD-9 and ICD-10 as different systems in the same way as SNOMED RT and SNOMED CT are.
Maybe we could think of CM/AM in ICD, and CT/CT-AU in Snomed like the “country/variant” in a locale, (en_UK or en_UK_v1) leaving the version alone (version = a number or date or id or whatever).
This is a great discussion. I think it would be good to make sure it doesn’t get lost. Is it worth setting up a page on the wiki and moving some of the discussion there?
