Overview
This is a table of requirements and an explanation of how they were met for phase 1 of the development of this tool. The table is taken from the original RFP.
Matrix
Refset Requirements
ID | Requirement | Solution Meets / Partially Meets / Does Not Meet the requirement | Notes / Explanation |
1 | The creation and maintenance of both extensional and intensional reference sets including version management of these reference sets | Meets | Initial extensional refsets can be loaded and then members added/removed. Intensional refset definitions based on expression constraint grammar supported by the terminology server (with explicit code “include” and “exclude” features). |
2 | Version management of reference sets including draft and published reference sets | Meets | Handled through reference sets version and workflow status metadata. |
3 | Import of existing reference sets as content | Meets | Import from RF2 (Simple pattern), Import from RF1 (SUBSETMEMBERS file) |
4 | Distribution of any reference set products (including documentation, rf2 and human-readable versions) | Meets | Attachments can be associated with a published reference set. The “human readable” form of the refset will be a link into the tool itself. Currently attachements are created at release time but there is not yet an explicit front-end mechanism to support attaching arbitrary documents to a release (though this would be fairly straightforward and the back-end supports it) |
5 | Role based access control to the maintenance of reference sets (Admin / Author / Reviewer / Public) | Meets | Role based access (VIEWER, AUTHOR, REVIEWER, ADMIN). API calls and application access is validated by role. |
6 | The computation of the effect of a related SNOMED CT version on a reference set | Meets | Tool will terminology server to obtain identifier lists from adjacent versions and compute changes in active concepts and enable author to visualize the changes (additions, deletions) and accept/reject them is supported. See "MemberDiffReport" and the API calls related to it. |
7 | Workflow for approval before publishing but also to provide a facility for external feedback | Meets | Simple workflow for authoring then handing off to a reviewer, then declaring a beta version, and then formal versioning and publishing. During beta phase, broader (or even public) feedback can be solicited. |
8 | A searchable, and publicly available, directory containing existing reference sets, as well as entries about reference sets that may be available elsewhere | Meets | VIEWER based access to available reference sets (including all prior versions). Features for discovery, searching, etc. This is called the "directory" and hosts published and beta forms of refsets. |
9 | The ability to host SNOMED CT extensions in the same instance as International editions | Meets | Hosting of terminology is done via terminology server not directly by this tool. Whatever terminologies hosted by that server are available for use. Reference sets within the system can reference any edition of SNOMED CT available to the underlying terminology server. |
10 | Separation between a tool for ‘sub-setting’ SNOMED CT components and a tool for managing releasable SNOMED CT reference sets | Meets | The tool supports refset development processes in which subsetting and analyzing changes in what would be the computed refset are supported. It also supports a publication process for releasing a refset (and its membership) at a particular point in time. Features for search and discover among published refsets will be available. |
Translation Requirements
ID | Title | Description | Solution Meets / Partially Meets / Does Not Meet the requirement |
1 | Import Functions | The solution contains import features that allow a user to import a file in a number of formats containing the content which should be translated or related content. | Partially Meets – Import functionality will be handler-based with a default RF2 implementation. Other handlers for import can be easily created at a later time. |
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. | Meets. RF2, RF2 with a name, and RF2 with a name and with .xls extension are supported. |
3 | Text Format | Description of which text formats are supported in the solution | Meets. The system natively understands "description type", includes defaults that are part of international release and the back-end supports new ones if needed. |
4 | Description Length Limitations | Description of translation length limitation, if such exists. | Meets, via description types and validation checks. |
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. | Meets with a basic AUTHOR, REVIEWER, PUBLISH life-cycle. |
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. | Meets |
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. | Work remains to be done to coordinate the tool with the IHTSDO recommendations for translation tooling workflow. |
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. | Partially meets – Only a single workflow will is supported by this tool that is mostly linear (with a feedback loop for fixing errors and sending back to an author) and does not support dual-independent-review. However, it will be implemented in a flexible/configurable way that allows for additional, more complicated workflow paths to be implemented in the future. |
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. | Meets. There is a robust auditing framework that allows recovery of the state of a refset or translation at any point in the past. In fact, an "undo" feature could be supported if needed. |
10 | 1 Source Translation | Support of translation of single sources in a translation project e.g 1 description type per translation step. | Meets. |
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. | Meets. Arbitrary numbers of descriptions can be created during translation step. |
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. | Meets. Back-end supports the ability to compare arbitrary translations (See ConceptDiffReport) though there is currently no user interface for this. |
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. | Meets, in a sense. Migration supports capturing changes in SNOMED related to retired and new content. In practice, this largely does not affect translations as inactive concepts still maintain active descriptions. One area to consider is whether a new description shoudl prompt further translation - however given that translation is officially done at the "concept" level and not description level, this should not be an issue. |
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. | Meets, supports loading, copying, exporting, etc. of spell check dictionaries. |
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. | There is a small terminology browser in the tool itself, and of course it can be linked to the standard IHTSDO browser. |
16 | Translation Suggestions | Support for translating suggestions of similar terms from dynamic translation memory throughout several translation project within the solution. | Meets. This one needs more work, proposed future development will "pre-translate" FSN, PN and SY descriptions based on a replacement of longest-phrase within the en string with the corresponding translated phrase. Other ideas for how to best leverage translation memory can and will be considered. Please suggest your ideas. |
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. | Subject to terminology server integration |
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. | Notes can be added to translated concepts, including URLs. |
19 | Internet Reference | Support of Users being able to make web reference annotations to a specific translation. | Notes can be added to translated concepts, including URLs. |
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. | Links to conflucence wiki (and training videos) |
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. | Translations, concepts support shared annotations. |
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). | Meets. Notification hooks exist, but exactly how and when to wire them hasn't been decided. |
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. | Meets, work can be batched, and tie-in to refsets supports a flexible "scope definition" model that can serve to allow portions of the terminology to be translated at a time. |
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. | Partially meets – The tool will track progress in terms of number of concepts translated (and/or number of words or batches). The tool will have a simple report for this (by translation project) |
25 | SNOMED CT Namespace Support | Support of SNOMED CT Namespace in the SCTID and UUID of completed of translations. | Meets via integration with CIS. |
26 | SNOMED CT UID Support | Support of SNOMED CT SCTID and UUID in the completion of translations. | Meets via integration with CIS. |