LOINC, SNOMED CT, and HL7® CodeSystems are examples of such code systems.
The updating of code systems and their timing or frequency is the responsibility of the creators and thus mostly beyond the control of ELGA. Code systems can only be corrected outside the responsibility of the creators if there is a technical problem.
A code system is uniquely identified not only by a unique name but also by an OID. The meaning of a code can only be deciphered together with the name/URI or OID of the code system.
A principle of terminology development is that codes must not be deleted, nor must the meaning of a code be changed 1. Such changes create an inconsistency in the use of older coded data with the current version of the code system. Typically, such “incompatible” version states of the code system are given different names/URI and OIDs to keep them apart (e.g., the annual versions of ICD-10). Not all code systems adhere to this requirement in practice. ELGA GmbH specifically highlights these updates, and we ask you to note the update messages at https://confluence.elga.gv.at/display/SCCTERM/ for this purpose. When adopting updates from such code systems, proceed with caution.
Wherever a value selection is made by e.g. ELGA CDA implementation guides, a suitable Value Set is defined and specified with its unique name. ELGA Value Sets refer, with a few exceptions, to a specific “version” of one or more code systems, which can be identified by the unique name/URI of the code system. This makes the Value Sets independent of changes in the code systems. In addition, Value Sets can contain their own sequence and tree structure (hierarchy).
All Value Sets used in the implementation guides are published here at the Austrian Terminology Browser. It applies to all Austrian e-Health terminologies that the Value Sets are kept extensional, which means that the concepts are explicitly listed in the Value Set and are not dynamically linked with e.g. filters via the code system. Furthermore, the expansion of the ValueSet is always present.
How often Value Sets are changed depends on the respective application. Value Sets that are needed for “structural” elements (e.g. in the CDA header, XDS metadata) will rarely change. “Content” Value Sets (e.g. for drug lists, laboratory analyses, diagnosis codes) will have to change correspondingly frequently, here annual to weekly changes are to be expected. In exceptional cases, it is possible to specify when defining a value set that it must not be changed or versioned (ValueSet.immutable is set to true).
In the case of ELGA Value Sets that are subject to a regular maintenance and update cycle, extensions and changes can be made after technical review by the responsible content administrator (e.g. ELGA laboratory parameters, ASP list). In the case of other corrections to the content of ELGA Value Sets, the technical decision of the working group 2 which developed the corresponding guideline within the framework of which the Value Set was defined may have to be obtained.
Contents of Value Sets may change, but the name and OID of a Value Set remain the same. For new versions, version number with release date (in ValueSet.version with e.g.: 2.3.1+20220618) and modification date (ValueSet.date) are specified. This allows to reconstruct the validity at a certain time.
Value Sets are valid until the date of a newer version of this Value Set is reached - then the newer version is valid. As long as no newer version exists, a Value Set remains valid (for exception “static” see also chapter Value Set Binding). If codes are not allowed to be used any more, a new version of the Value Set is created, in which the codes not to be used any more are set to inactive=true. These codes are kept in the ValueSet only for historical reasons. The new version is valid from the upload unless the status of the Value Set has been set to draft and the date is in the future.
For ELGA and the Austrian eHealth systems, a DYNAMIC binding to Value Sets applies in principle. This means that the version of a Value Set currently published on the terminology server must always be used. (The explicit setting of the corresponding keyword ‘DYNAMIC’ is therefore not required in the guidelines).
Value Sets can also be STATICALLY bound to a code element. This is indicated by specifying the Value Set with name/URI, OID, version and date (ValueSet.date) and the keyword
The following versioning is implemented only after the end of parallel operation. As long as the old terminology server is maintained, it must be ensured that the versioning on the old and new terminology servers match.
The following versioning scheme applies to the versioning of terminologies such as code systems or value sets:
For individual terminologies such as CodeSystems or ValueSets the following applies:
MAJORis incremented if, for example.
MINORis incremented if, e.g.
PATCHis increased, if e.g.
YYYMMDDcorresponds to the date from which the terminology applies.
The following status transition diagram applies to all concepts in code systems or value sets:
Here, the mapping between LOINC® and FHIR® R4 is as follows:
|LOINC↓ FHIR Code System →|
The mapping between SNOMED CT® and FHIR® R4 is as follows:
|SNOMED CT↓ FHIR code system →|
The content of the Austrian e-Health Terminology Browser is based on the following two GitLab projects:
| Project Name | Description | Repository URL | GitLab Project ID | GitLab Pages URL | | — | — | — | — | — | | TerminoloGit | https://gitlab.com/elga-gmbh/termgit | Repository for published, up-to-date terminologies (download formats).
Note: The contents of the last successful pipeline of any Git branch of this repository are displayed under the specified GitLab Pages URL. | 33179072 | https://elga-gmbh.gitlab.io/termgit | | TerminoloGit HTML | https://gitlab.com/elga-gmbh/termgit-html | Repository for the static HTML pages created by the HL7® FHIR® IG Publisher based on the
main branch of https://gitlab.com/elga-gmbh/termgit. | 33179017 | https://termgit.elga.gv.at |
The Terminology Server is primarily a system for providing code lists and value sets; it is not intended to provide real-time access for processing by information systems. The Terminology Server is not currently used as an online resource (for checking individual values), but as a source for new terminologies to be stored locally. The terminology server is used by the following user groups:
|user group||task||GitLab.com role||description|
|Terminology Consumer||reading access||none, not required||As a terminology consumer, no self-registration is required for viewing and exporting terminologies or checking for new versions.|
|Terminology Manager||Terminology Maintenance||Developer||The creation or update of terminologies is done by the Terminology Manager. It is not possible to assign a responsible user to each terminology.|
|Terminology Administrator||Release and Publication||Maintainer||Before terminologies become publicly available, they are released by a terminology administrator.|
The following process is defined for the publication of terminologies created by ELGA-external terminology manager for the Austrian e-Health Terminology Server.
Concept Permanence, described in “Cimino’s Desiderata” (Desiderata for Controlled Medical Vocabularies in the TwentyFirst Century; 1998; http://www.ncbi.nlm.nih.gov/pmc/articles/PMC3415631/) ↩
A “CDA Advisory Board” that makes decisions by circular resolution (qui tacet consentit). The decisions made can be made public by mail distribution list. ↩