openEHR Terminology

Introduction

The openEHR Terminology is a simple terminology that includes all the terms found in the terminology specification. The openEHR terminology is being used by the Java project, by the Archetype Editor, and by various other tools.
See here for the current computable version of this. The associated schema is here.  The schema is an XML schema.

The terminology file now in widest use is probably the Java project one, which can be found here .

Note that in the openEHR terminology specification, there are two kinds of vocabularies - code-sets, where the codes stand for themselves (includes ISO 3166 & ISO 639 codes, IANA MME types etc), and term sets, where each term has a numeric code, and has a description that can be translated into multiple languages.

Current Status

There are various problems that have been observed with the terminologym including:

  • the current 'official' terminology XML file is not conveniently structured
  • some codes are missing, e.g. the IANA MIME types

Future

The Java project currently has a better version of the terminology, both structurally and content-wise, which can be found here. The only drawback of this file is that it is only in English so far. This file, if translated would probably be a better candidate for the openEHR Terminology than the current one. Questions to consider:

  • would each translation belong in a separate file?
  • what is the XSD of the file?
  • what tools would be needed to maintain this terminology (at a minumum, they need to know how to work with the translations)

Another possible solution might be to define the terminology in the same format as SNOMED, which would make it palatable to SNOMED tools. This may provide useful answers for translation representation.

Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.

Comments (4)

 

  1. 22-Jul-2009

    Rong Chen says:

    Thanks for putting this up, Tom! Regarding your questions: 1. I would pref...

    Thanks for putting this up, Tom!

    Regarding your questions:

    1. I would prefer to have separate files for each translations. Part of the reason is for easy maintenance, so the stable ones like the English translation won't get changed accidentally when new translations are introduced.

    2. The XSD file of the current terminology XML is attached here: http://www.openehr.org/wiki/download/attachments/5996909/openehr_terminology.xsd

    3. Any XML editor would suffice. The ones I am using now are the Altova XMLSpy 2007 and the built-in XML editor in Eclipse 3.4.

  2. 28-Jul-2009

    Shinji KOBAYASHI says:

    I have developed a simple and RESTful terminology server with Ruby on Rails. If ...

    I have developed a simple and RESTful terminology server with Ruby on Rails.
    If you would like to get a terminology value with terminology name,language, and ID, access with this format with HTTP get method, returns simple XML

    http://server address/terminology/name/lang/id

    For example,
    http://ts.openehr.jp/terminology/openehr/en/0

    returns:
    <terminology>
    <openehr-id>0</openehr-id>
    <rubric>"self"</rubric>
    </terminology>

    Notice:
    Since this is a experimental implementation, you can query only by id with 'openehr terminology' in 'en language'.
    Please comment this simple terminology server.

  3. 04-Dec-2009

    Pablo Pazos Gutierrez says:

    Here are some thoughts to make an usable multilanguage openehr terminology serve...

    Here are some thoughts to make an usable multilanguage openehr terminology server:
    - If we need codes it is important to define the domain of the codes (like the actual groups or codesets in openehr_terminology_en), the codesystem of the codes (like the actual external_id in code sets), but the description must be a code, so you can specify the translation of the descriptions on other files, and we can reuse the main terminology files in all our systems.
    - If we have concepts in groups, the rubric also must be a code, so we can define the translations of the rubrics on other files, and we can define sinonims to these rubrics in the same translation file. Attached to the rubric we can also have transated descriptions.

    I'd know what you think.

    Example of the ideas:
    openehr_terminology.xml

    <terminology version="1.0" status="stable">
       <codeset domain="ISO_3166-1" issuer="ISO" description_id="cd00000">
          <code value="AF" description_id="cd00001"/>
          <code value="AX" description_id="cd00002"/>
          <code value="AL" description_id="cd00003"/>
          ...
       </codeset>
       <group description_id="cd10000>
          <concept code="249" description_id="cd10001>
          <concept code="250" description_id="cd10002>
          <concept code="251" description_id="cd10003>
          ...
       </group>
    </terminology>

    openehr_terminology_description_en.xml

    <descriptions language="en">
       <description id="cd00000" value="ISO country codes" />
       <description id="cd00001" value="AFGHANISTAN" />
       <description id="cd00002" value="Ã...LAND ISLANDS" />
       <description id="cd00003" value="ALBANIA" />
       ...
       <description id="cd10000" value="audit change type" />
       <description id="cd10001" value="creation">
          <term code="249.1" value="creation type" /> <!- terminology sinonim to the concept with id 249 ->
          ...
       </description>
       <description id="cd10002" value="amendment">
          <term code="250.1" value="amendment type" />
          ...
       </description>
       <description id="cd10003" value="modification">
          <term code="251.1" value="modification type" />
          ...
       </description>
       ...
    </description>

  4. 28-Apr-2010

    Sebastian Garde says:

    I would also prefer to separate translations into separate files. As Rong says,...

    I would also prefer to separate translations into separate files.

    As Rong says, there is the variety of XML Editors which can be used to maintain this.

    As for the missing translations for the approach used by the Java project, I am happy to provide the German one, if this is to become the standard structure.

    What is clear is that we need to move to a single source of truth that

    • can be maintained easily,
    • can be translated easily and safely and
    • is either usable directly by tools in different programming languages or can be converted to a format usable for that language more or less automatically.

    At the moment, the process to include new codes is via making a Jira request to include a new code in a new release, see e.g. http://www.openehr.org/issues/browse/SPECPR-39
    This may simply be too slow in practice.

    I see that the Archetype Editor uses a terminology file that includes not only the official openEHR codes, but also codes only relevant for the Archetype Editor tool and codes that probably should be official codes (see e.g. the Jira issue above), but didn't make it into the official openEHR terminology (so far). Not sure this mixture is desirable.