Page tree

Goals

  • Provide an online, browser based translation tool for IHTSDO Member National Release Centres (NRCs) to translate SNOMED CT into local languages

Background and strategic fit

IHTSDO sees the development of translations of SNOMED CT as key to driving the adoption of SNOMED CT globally with the consequent improvement in interoperability and healthcare delivery within and between Member countries.

For some countries the need for translation may be a barrier to adopting SNOMED CT and becoming a Member of the IHTSDO. Therefore a Translation Policy have been agreed upon stating the level of support available from the IHTSDO for the development of translations of SNOMED CT from English into other languages, as well as the expectations and obligations on those Members undertaking translations.

Assumptions

  • The solution will be browser based, online.
  • IHTSDO Terminology Server (TS) platform to retrieve the International Edition of SNOMED CT. 
  • IHTSDO Identity Management Server (IMS) for user accounts and authentication - IHTSDO Identity Management Service Documentation
  • IHTSDO Component Identifier Service (CIS) for assigning identifiers where/if necessary (within the correct namespace) - IHTSDO Component Identifier Service - (this is still in beta/testing)

Functional Requirements

  Title Description SNOMED CT Translation Specifics
1 Import Functions The solution contains import features that allows a user to import a file in a number of formats containing the content which should be translated or related content.

Import functions are important in several cases. First of all for being able to import the SNOMED CT concepts which needs to be translated. As a minimum this would expect to be in RF2 format, but other, human readable, formats would also be accepted.

Import functions are also important when related materials needs to be imported such as:

    • Medical dictionaries

    • linguistic guidelines

    • Editorial guidelines and policies

    • other SNOMED CT extension's language reference sets and descriptions files which have similarities to the target translation language
2 Export Functions  The solution contains export features that allows a user to export a file in relevant formats containing the content translated in the solution. Export functions is important for being able to export the translated SNOMED CT terms, in RF2 format with the language reference set and the relevant description file, but also added linguistic and editorial guidelines if such have been gathered in the tool during the translation process.
3 Text Format Description of which text formats are supported in the solution

Pervasive Unicode support for all input and output text, with rich conversion support in both directions. Unicode is a “superset” character encoding, with the ability to store any language or character set. Many existing tools are not Unicode-aware, creating limitations and interoperability problems.

4 Description Length Limitations Description of translation length limitation, if such exists.

The SNOMED CT Description Format Refset specifies the description limits and whether mark up is permitted.  The maximum length for terms in fully-specified names and synonyms is 255 characters but for definitions it is 4096 characters.

Not following this rule has resulted in terms not being displayed correctly in tools where there is a length limitation in a term field or translation field shorter than stated in the SNOMED CT rules.
5 Workflow Support Support of role-based translation quality assurance (QA) process containing role-based user workflows features, either with different feature sets for different types of users in the translation process, but as a minimum with identical feature sets for different types of users in the translation process. As stated in the “Guidelines for Management of Translation of SNOMED CT” the aim of the translation process is to provide a high-quality translation, even in the narrowest specialist fields. Several workflow steps are found crucial to achieve the anticipated quality of the translation.
6 1-2 Workflow Stages Support of a 1-2 step QA translation process containing Role-based user workflows features, either with different feature sets for different types of users in the translation process, but as a minimum with identical feature sets for different types of users in the translation process. As stated in the “Guidelines for Translation of SNOMED CT” there should always be at least two persons involved in the initial translation – a translator and a “proof-reader” (to verify the initial translation). A “proof-reader” is in SNOMED CT translation projects also references as a 1. reviewer. The translator makes the initial translation with support of the available features. The reviewer review the translation and approves (with a clear sign-of) the translation if the translation is qualitative correct. Or edit the translation prior an approval if needed. In some SNOMED CT translation project this has been references as quick translation.
7 3-n Workflow Stages Support of a 3-n step QA translation process containing Role-based user workflows features, either with different feature sets for different types of users in the translation process, but as a minimum with identical feature sets for different types of users in the translation process. As stated in the “Guidelines for Management of Translation of SNOMED CT” three step workflows are found crucial to achieve the anticipated quality of the translation – particularly the two-step review process. Experience from existing translation projects indicates that a two-step review improves the quality of the translation. The translator makes the initial translation with support of the available features (normally a translator from a translation service provider. The first review is a kind of internal quality check performed by the translation service provider. The second review is an external review arranged by the translation project owner.In some cases an Editorial board is also supported in the workflow as a 4.step.
8 Configurable Workflow Support of a configurable workflow supporting QA translation process containing Role-based user workflows features, either with different feature sets for different types of users in the translation process, but as a minimum with identical feature sets for different types of users in the translation process. As stated in Experience of the Danish, Swedish and Canadian Release Centres Translating SNOMED CT® - Approaches, Challenges and Lessons Learned several workflow types have been used to translate SNOMED CT concepts. Based on those experiences there seem to be a need for configurable workflows so the Member NRC’s is able to adjust the workflow in the CAT tool to the individual Member NRC translation organization.
9 Workflow History Logs Translations go through a number of versions, both in translation as well as during subsequent editing and proofreading. The solution must support history/audit logs of which user incl. role performed which action in the translation process. Access to audit logs for all roles in a translation workflow is important in order to give roles traceability during the translation process. Also from a administrative point of view related to productivity tracking and error statistics.
10 1 Source Translation Support of translation of single sources in a translation project e.g 1 description type per translation step. SNOMED CT concepts have several descriptions per concept. It differs if members wish to translate either the description type: Fully specified name or the  Preferred term. Experience shows that most select to translate Preferred term since it is the term which most normally is used to be displayed in EHR systems (it does not bring any added value for a clinician to have a hierarchy description of a terminology they should not take into account shown in a suffix).
11 2-n Source Translation Support of simultaneously translations of multiple sources in a translation project e.g. 2 descriptions type translation per translation step. SNOMED CT concepts have several descriptions per concept. It differs if members wish to simultaneously translate several of the descriptions linked to the same concepts during in the same process, meaning both the description type: Fully specified name and Preferred term. Other wish to translate Preferred term and add synonyms in the same process.
12 Version Control Translations go through a number of versions, both in translation as well as during subsequent editing and proofreading. The solution would archive all versions of each translation version, and then provide the ability to compare any two versions to see differences and changes.

When translation is transforming during steps it is important that e.g. a 2.reviewer see both the translators translation but also any corrections a 1.reviewer has performed on a translation. Experiences have shown to be very useful when translation are performed which not follows a editorial guideline or is a translation should be changed according to a newly linguistic- or editorial guideline.

But also when 2 translation of same concept is performed then comparison is important in order to make QA.
13 SCT Version Control Each new version of the SNOMED CT International edition may have an impact on the already translated terms. The solution must show where there have been changes to that content already translated. This is needed to ensure that a translated language reference set is kep up to date with the most the recent version of SNOMED CT International edition.
14 Spell Checker Support for spell checking features during the translation process, both standard types (e.g. google spell checker) or customizable where a user can add corrections themselves. This is not a specific SNOMED CT feature but seen as a feature to catch typos and spelling errors incl. very specific spellings when customizable spell checkers are supported.
15 Browser Support for a user to access a browser containing all the content to be translated, and/or additional code systems uploaded into the solution shown in a flat structure or and hierarchical structure. SNOMED CT concepts have no textual definition. A SNOMED CT concept is defined through its relationships. Therefore is a browser important  in order understand which type of concepts is it that one is about to translate/review. Flat list browser is useful for medical dictionaries with no relationships whereas SNOMED CT and additional code systems makes most sense for a human to browse if it is done in a browser showing the hierarchical structure of the code system.
16 Translation Suggestions Support for translating suggestions of similar terms from dynamic translation memory throughout several translation project within the solution.

There are several key terms that are used in connection with translation memories. Some of the more common terms include:

  • Full Matches

  • Fuzzy Matches

  • No Matches

When a translator applies the translation memory with loaded SNOMED CT translation in the same target language to not translated terms, there are several possible outcomes. One possible outcome is a “No Match”, which simply means that there are no matching segments in the memory. This phrase needs to be translated from scratch by the translator. Another outcome is a “Full Match” (i.e., “100 percent” match) which predictably means the term to be translated is identical to an already translated term in the translation memory. These cases happens if a SNOMED CT concepts have already been translated with an identical term (synonyms) but from different hierarchies/other contexts. In this case, the translator needs to verify the segment is correctly used within the context of the new translation, and simply approve if correct.


“Fuzzy match” is when a phrase or segment in the term which needs translation is similar, but not identical, to a segment stored in the translation memory. The translator in all cases needs to review the results to either verify they are correct or to modify them in order to translate accurately the phrase.
17 Other Code Systems Ability to view alternate codesystems, in situations where the source has already been translated to another target language. In these situations, the solution would enable translators to view and utilize prior translations of another code system as secondary “source” for clarifying meaning and keeping translations consistent. Ability to view alternate source text, e.g. another code system or medical dictionary has in earlier SNOMED CT projects shown to be very useful in order to enable translators to view and utilize prior translations of code system from the Healthcare domain as secondary “source” for clarifying meaning and keeping translations consistent in the clinical reference language e.g ICD-10 translations.
18 Document Reference Support of Users being able to make document reference annotations to a specific translation, by support upload of relevant documents in the broadest range of document formats.

Import of source documents have shown to be valuable in as a reference during SNOMED CT translation projects. Where both linguistic- and editorial guidelines have been made available to reference and make reference annotations to related to specific translations as an argument for a certain translation.

There have been a need for the tools  to be able to handle the broadest range of document formats and encodings, allowing easy import of source texts from Open Office and other suites, HTML, PDF etc.
19 Internet Reference Support of Users being able to make web reference annotations to a specific translation. Web references have shown to be valuable as a reference type during earlier SNOMED CT translation projects e.g. reference to IHTSDO standards/publications from the IHTSDO website or organization policies available on an organization website.
20 Online Help Support of Users being able to access an online user manual/help guide containing the functionalities in the system and being able to be educated in the functionalities of the system based on educational tutorials.  
21 Collaborative Translating

Support for Users to be able to make annotations – e.g., "I had a problem with this translation"– at  any level of detail or scope in a comment field or similar.

 
22 Task Notification Support Support of notification of project members in changes in the status of translations in order to be notified of the arrival of new translation tasks into the system. Notification could be done via email or RSS (Rich Site Syndication).  
23 Splitting Translation Tasks Large amount of translations to be performed often need to be broken down into smaller units in order to be delegated to different translators or parcelled out in manageable units. Segmentation support would allow breaking large amount of concepts into such units and enable eventual re-assembly of the translated segments into a final unified file. As stated in Experience of the Danish, Swedish and Canadian Release Centres Translating SNOMED CT® - Approaches, Challenges and Lessons Learned several administrative methods have been used. And experience has shown that segmentation support should take hierarchical context into account why some visual representation during segmentation would be valuable. Then it is possible to prevent concept from same sub hierarchy being split into different units (e.g. ref sets).
24 Statistics & reporting The solution would be able to track translation project progress in forms of hours and completed tasks for each project member, allowing managers to both assess productivity and track compensation.

In earlier SNOMED CT translation projects statistics have been used to allowing managers to both assess productivity and track compensation. Different reimbursement models have been used in earlier projects.

The progress and state statistics have shown to identify percentage of errors based on rejection in workflows. This have help in identifying needs in either extra training, selection of concepts based on competencies etc.
25 SNOMED CT Namespace Support Support of SNOMED CT Namespace in the SCTID and UUID of completed of translations. An Extension mechanism allows authorized organizations to add locally valid content (translations) without compromising the main body of SNOMED CT. The components of an Extension have Identifiers (SCTIDs) which have the same structure as those used in the SNOMED CT International Release. However, these Identifiers include a partition-identifier indicating that the component is part of an Extension and a namespace identifier specific to the responsible organization. Before generating SCTIDs, an organization must own a namespace. If supported the translator owner organization’s NamespaceID must be part of the translations UID.
26 SNOMED CT UID Support Support of SNOMED CT SCTID and UUID in the completion of translations. The components of an Extension have Identifiers (SCTIDs) which have the same structure as those used in the SNOMED CT International Release. However, these Identifiers include a partition-identifier indicating that the component is part of an Extension and a namespace identifier specific to the responsible organization. If supported the translations UID must be according to the IHTSDO technical rules for generating UID.

Non-Functional Requirements

  Title Description Notes
1 Browser based

 The solution must be an online, browser based solution.

 

2 Customization

Any solution must be customizable to be re-branded for the IHTSDO and its Members.

 
3 Integration

Integration with existing IHTSDO components including the following would be expected:

  1. IHTSDO Identity Management Service (for user management and log in)
  2. IHTSDO Component Identifier Service (to assign component identifiers where necessary)

 

 
4 Integration The IHTSDO Terminology Server should be used where possible and feasible for storing translations. This may involve integration with the Terminology Server.  
5 Open Source

IHTSDO always prefers to make any solution available to IHTSDO Members and the community of practice under the Apache v2 open source license. This will be an advantage for any proposal offering the final solution under the Apache v2, or equivalent, open source license.

 
6 Open Source Any external software used as part of the solution is expected to be under an appropriate open source license (e.g. the database or OS).