Features

Overview

Documents features of the system based on the proposal submitted for design/development.

Non-functional Features

Refset Features

• Create extensional reference sets through any of these mechanisms:

  • Loading an initial set of members from an RF2 (simple reference set) file.

  • Computing an initial set of members from a query (or combination of queries)

  • Manual entry based on known codes, text-based searches, or hierarchical searches (e.g. via the IHTSDO browser).

  • Loading directly from the IHTSDO terminology server (to the extent that this capability is supported).  This is important because it allows previously developed referenced sets to automatically be pulled into the tool for maintenance.

• Maintain extensional reference sets.  This mostly includes the ability to identify individual members of the reference set that have become obsolete with an update to the underlying SNOMED CT® edition used to create it.  It also includes the ability to manually remove entries or to add them using any of the mechanisms described in the previous bullet.

  • The tool will provide an on-demand feature for migrating a reference set to the new version.  The author will choose the new edition of SNOMED CT® to update to – which may be a newer version, or may be an entirely different edition (to handle the case of say moving a maintained reference set from an NRC to the core, or vice versa).

  • The validation framework (described below) will be employed at this time to perform validation checks on all members against the updated SNOMED CT® version.  Things like members now obsolete will be flagged and the author given an opportunity to make relevant changes.

  • At any time during this process

• Create intensional reference sets by defining a set of queries (in the grammar of the expression constraint language supported by the terminology server) that produce results from the IHTSDO terminology server.  Also support manual override with “include” and “exclude” lists for outlier codes. 

  • Ideally, in the long run, the grammar used to support this tool would converge with the emerging “Expression Constraint Grammar” being developed by IHTSDO.

• Maintain intensional reference sets.  This includes both the ability to materialize the definition against the new version of SNOMED CT® as well as to identify manually edited members that are no longer valid. 

  • As with extensional refset maintenance, this will be an on-demand feature that will include running validation checks against all individual members of the refset.

  • It will also include the ability to visualize changes in members based on evaluating the definition against a different edition of SNOMED CT®.  Authors will be able see potential new members, potential deprecated members, and be able to accept or reject these changes.

• Clone an intensional or extensional refset.  An important use case is starting with an existing reference maintained by another organization or SNOMED CT® edition and tailoring it to work for yours.  For example, the US may want to start with a UK reference set and then customize it for use with the US edition of SNOMED CT®.

• Convert an extensional reference set to an intensional one by extrapolating a minimum-spanning query that covers the content involved (based on “isa” hierarchies with boolean AND expressions to include outliers and NOT expressions to exclude outliers).

  • Internally, this means that all reference sets can be inherently maintained as “intensional”, which likely will lead to better maintenance of otherwise extensional reference sets and also highlight areas of SNOMED CT® content that may need improvement.

• Import and export of extensional reference set definitions (in the form of an RF2 reference set itself).

• Remove an intensional or extensional reference set when no longer desired or needed.

• Tracking of reference set metadata, including its version, type, the edition of SNOMED CT® that was used to create it, an indicator of whether it has been published, an indicator of its workflow status if still in development, and the authors who are currently associated with its development and maintenance (and their corresponding roles). 

  • Also includes the ability to define an “external” reference set that is simply a pointer to an external URI and does not have any materialization in this tool.

• Generalized facility for comparing two reference sets. This would involve a user interface that presented a “diff” style report in which members in common, members added, and members removed were all clearly shown with the ability to refine the reference set metadata on either side of the comparison to iterate through comparisons to converge on a solution.  This feature is intended to support these use cases (among others):

  • Comparison of a published reference set against a particular version of SNOMED CT® against a future version (e.g. the next version).

  • Comparison of a published reference set of a particular edition of SNOMED CT® against a different edition (e.g. the international version of a reference set vs. the US version).

  • Comparison of an unpublished reference set against a prior version of that reference set (e.g. to understand the implication of changes in an intensional reference set definition on the overall result).

  • NOTE: this relies on the ability of the underlying terminology server to support the ability to view different forms of the reference set at different times in its history.  If this is not supported, then these features will have to be managed and persisted locally by the application.

• Simple workflow mechanism to track reference sets that are being developed, are ready for review, are reviewed, are ready for preview by a wider (and possibly public) community, are ready for publication, and finally are actually published.

  • Overall workflow state of a reference set is tracked in its metadata.  Behaviour regarding the visibility of this reference set to users with different roles can be controlled (e.g. to only show publicly a reference set that is intended for preview).

  • Role-based access to changing of the workflow state of a reference set.

  • Support for a simple reviewer (non dual independent review) workflow.

  • Track history of official releases of the refset (so they can be easily referenced)

• Configurable email address for feedback on a reference set during preview and publication modes.

  • Sophisticated within-application feedback features are not included at this time.

  • This mechanism allows individual organizations to set the feedback email for their organization to support a local ticketing system (e.g. Freshdesk, Siebel, or just a basic email account checked on a regular basis).

• Facility for search and retrieval of the entire catalog of available reference sets.  Role-based access is included so that reference sets can be made private, or only accessible to users with particular roles for a particular reference set (or project for multiple reference sets).

  • All reference set metadata is searchable.

  • Individual computed reference set members are searchable.

  • Retrieval can support visualizations of past versions of the reference set (and/or comparisons to current ones).

  • Search results separate reference sets that a particular user has a non-viewer role on, reference sets available for preview, and reference sets that have been published.

• Support for attaching related artifacts to a “published” reference set to allow the tool to be used as a distribution portal (if desired).  This would include:

  • Documentation

  • Release files representing publication state (in RF2).

  • Release files representing intensional reference set definitions (in RF2).

  • Ancillary or auxiliary attachments.

  • Human readable form of the reference set will be a URL that directs a user into the tool where the reference set itself can be visualized, browsed, and searched.

• Clear division between the “information portal” and “development” aspects of this tool.  Users who are interested in discovering, searching, or browsing publicly available and published or preview reference sets can interact exactly in that way.  They can learn about, download, visualize, and provide feedback on these various things.   Authors who are actively developing and maintaining reference sets will have access to different features of the tool that allow for testing of variations in intensional reference set definitions, manual including or excluding of specific codes, comparison of reference sets in a variety of ways, and access to the underlying reference set workflow.

• Project-based mechanism to allow for grouping the maintenance of multiple reference sets under the same “organization”.   This streamlines user-role management and binds together various reference sets that may belong to or be maintained by the same organization.

• Validation framework for identifying and preventing undesirable data conditions (such as publication of a reference set that has members that are inactive in the SNOMED CT® edition backing the reference set).

  • Supports errors to prevent moving forward in workflow.

  • Supports warnings that allow editors to “click through” if they know the data condition to be correct.

Translation Features