Stream: terminology
Topic: Terminology Capabilities and defaults
Michael Lawley (Aug 13 2020 at 07:01):
The current structure of TerminologyCapabilities appears to be skewed to statements about (logical) instances of CodeSystems with respect to a URI and version.
Due to the optionality of most elements, though, it appears possible to make more general statements about behaviour by omitting the version and/or URI.
However, it is not clear how to interpret multiple statements that effectively overlap.
For example, the following is legal:
{
"resourceType": "TerminologyCapabilities",
...
"codeSystem": [{
"version": [{
"property": ["parent", "child", "status"]
}]
}, {
"uri": "http://snomed.info/sct",
"version": [{
"property": ["moduleId", "effectiveTime", "active"]
}]
}, {
"uri": "http://snomed.info/sct",
"version": [{
"code": "http://snomed.info/sct/32506021000036107",
"property": ["hasArtgId"]
}]
}]
and could be considered as a way to say that the properties "parent", "child", and "status" are supported for _all_ CodeSystems, with "moduleId", "effectiveTime", and "active" being _additionally_ supported for SNOMED CT, and "hasArtgId" further supported for SNOMED CT-AU.
It is not clear if this strategy (to avoid repeatedly and redundantly say the same thing for many instances) is a legitimate strategy, nor whether we would want to push such a semantics onto the consumers of the TerminologyCapabilities resource?
Grahame Grieve (Aug 13 2020 at 11:19):
I'm not sure
Last updated: Apr 12 2022 at 19:14 UTC
