Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • Data model built around RF2. Thus, it natively  
    • Natively handles SNOMED CT® and other
    terminologies that can be transformed to a ClaML or RF2 representation.
    • RF2 terminologies.
    • The data model
    also
    • includes “first class” representation of standard RF2 reference set patterns (such as Attribute Value and Complex Map).
  • Supports multiple terminologies and versions. This means the server is capable  
    • Includes support for loading of delta, full and snapshot RF2 data
    • Includes support for loading of ClaML data
    • Capable of handling non- SNOMED CT® based terminologies, such as ICD10, ICD10CM, ICD9CM, and ICPC.
    It also means the server is capable
    •  
    • Capable of handling and supporting SNOMED CT® extension use cases (such as the US Edition)
    • Includes support for delta, full and snapshot RF2 data
    • Includes support for ClaML data
  • Supports transitive closure computation and maintenance. 
    • Ancestor and descendant computations are simple lookups and do not require computationally expensive graph walking
    .Supports a classification handler for full or incremental classification with a default Snorocket implementation
    • .
  • Supports a customizable identifier management mechanism allowing solution
    • Allows various approaches to ID maintenance, including application managed identifiers, content hash-based UUID assignment, and SNOMED CT® identifier assignment based on sequences.
    This includes the ability
    •  
    • Ability to assign UUID identifiers during development to core components followed by SNOMED CT® identifier assignment at release time.
  • Supports a customizable authentication/authorization mechanism, including default implementations for native SNOMED
  • Supports a customizable “graph resolver” mechanism to define the depth into the graph that various read and write calls should support. The default  
    • Default implementation of this mechanism supports reading/writing a concept that includes descriptions, language refset members, and relationships.
    • Other data types are read/written through API calls.
  • Supports a customizable validation framework that allows testing of data states prior to persistence. The default  
    • Default implementation includes a few basic checks to demonstrate use.
  • Supports paging, filtering, and sorting at the API level. 
    • For example, a “find concepts” call can be combined with sorting and filtering and can also page results one page at a time with flexible page sizes.
  • Supports multiple, simultaneous editing of the same concepts for dual independent review, conflict identification, and conflict resolution.Supports a customizable “workflow listener” mechanism to interface with an external or third party workflow management system.
    • Workflow can be tracked at the concept, description, or
    description
    • relationship level but is not itself maintained by the system.
    Instead, any change
    •  
    • Changes to model objects triggers a callback to a custom handler to integrate with an external workflow management system
    .Supports REST API for batch changes
    • .
  • Includes a default release process for performing identifier assignment and delta RF2 generation.Includes complete administrative, technical, and user documentation, and a full swagger API with example values that yield legitimate results.
  • Flexible back-end data store. 
    • Default support for MySQL and uses Hibernate to facilitate connections to a variety of other database environments, including document-based and graph databases.

Next Features

  • Support a DL classification with default Snorocket implementation (full and incremental).
  • Support for "semantic search".
  • Support multiple, simultaneous editing of the same concepts for dual independent review, conflict identification, and conflict resolution.
  • Support branch-and-merge "project" based editing to isolate, modularize, and package sets of work.
  • Support REST API for batch changes.
  • Support default release process for performing identifier assignment and delta RF2 generation.

Emerging Features

  • Support for “dynamic” refset definitions and data.
  • Support for classifier concrete domains and other features (like GCIs).
  • Support for sharding and a synchronization service (to support shadowing or distributed editing). Such a mechanism could also be used to synchronize IHTSDO editing changes with an extension-editing environment.
  • Internationalization of error messages and labels. There’s a standard approach to this that will be undertaken once MVP is ready.
  • Javascript client library for wrapping REST API calls and allowing application developers consistent access to the services.
  • Support for post coordinated expression maintenance and resusability.
  • Support for expression-based searching.
  • Support for template-based authoring.