Page Comparison

...

• Lightweight and easy to build, configure, and deploy.
• MobileWeb-based and mobile-friendly user interface (e.g. responsive design)
• Data model built around the UMLS data NLM Unified Medical Language System (UMLS) data model
  • Natively handles RRF, some of the unusual and not-very-useful complexity of the UMLS is removed.
  • Natively handles SNOMED RF2 format
  • Natively handles a simple code list with parent/child relationships file format
  • Natively handles loading from ClaML
  • Natively handles loading from OWL (given the DL semantic supported by SNOMED)
  • Capable of simultaneous representation of Metathesaurus data structures (e.g. CUI) and terminology-specific data structures (e.g SNOMEDCT_US concpet or concept and MSH descriptor)
• Capable of simultaneously supporting multple Metathesaurus views (e.g. UMLS, NCI-META, RXNORM, etc.)
• Fully authenticated REST APIs with Java client classes included.
  • Examples also provided for commonly used/needed calls
• Supports multiple terminologies and versions. 
  
  • Capable of handling any UMLS-based terminology terminologies of any level of complexit (e.g. MeSH, SNOMEDCT_US, ICD10CM, etc.)
  • Simple code lists
  • Taxonomies
  • Thesauri
  • Ontologies with DL features (supports EL++) and classification (via OwlAPI)
• Supports transitive closure computation and maintenance. 
  • Ancestor/descendant (and parent/child) computations are simple lookups and do not require computationally expensive graph walking.
  • Also supports individual tree-position representation of hierarchy (for terminologies that assign codes to individual tree positions).
• Supports both lexical and semantic querying
  • Handles complex field-based Lucene queries
  • Handles queries like "find all concepts with associated_morphology relationships to Kidney or any of its descendants" via a syntax like the SNOMED expression constraint language (ECL)
  • Handles generalized Lucene+SQL queries against the underlying persistence model (formulated as combination Lucene/JQL queries)
• 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.
• Includes administrative, technical, and user documentation, and a REST API documented online with sample parameters.
• Supports description logic constructs within the metadata model to allow interoperation with Owl and integration with classifiers.
• Farily comprehensive unit, functional, and integration testing across all layers of tech stack.
• 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.
• Full auditing, logging, and tracability framework to support arbitrary levels of undo/redo, full accountability for all changes made to the persistence layer ("last modified" and "last modified by").
• Supports flexible query-driven workflow engine to allow partitioning of all content into "bins" which can be divided into "worklists" which are assigned to users and follow a configured workflow.

Extensibility

• Supports customizeable "metadata" handlers to allow for both individual terminology and metathesaurus-specific views into the metadata model.
• Supports customizeable preferred name computation to support different algorithms for different terminologies.
  • Can be used to allow different users to work with different preferred name algorithms for the same terminologies as well (useful for when editing a particular terminology within a Metathesaurus that is not highly ranked).
• Supports customizeable lexical normalization handler with default implementations based on NLM's LVG and the Lucene "standard analyzer"
• Supports a customizable authentication/authorization mechanism
  • Default implementations for UTS (http://uts.nlm.nih.gov), and "default" security (for development mode).
• Supports a customizable “graph resolver” mechanism to define the depth into the graph that various read and write calls should support. 
  • 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 “workflow listener” mechanism to interface with an external or third party workflow management system.
  • Workflow can be tracked at the concept, description, or relationship level but is not itself maintained by the system. 
  • Changes to model objects triggers a callback to a custom handler to integrate with an external workflow management system.
• Supports a customizable identifier management solution
  • Allows various approaches to ID maintenance, including application managed identifiers, content hash-based UUID assignment, and SNOMED CT® identifier assignment based on sequences. 
  • Ability to assign UUID identifiers during development to core components followed by SNOMED CT® identifier assignment at release time.
• Supports a customizable validation framework that allows testing of data states prior to persistence. Default implementation includes a few basic checks to demonstrate use(in unit or batch modes)
  • For example, prevent synonyms from being added to a concept that contain leading, trailing, or duplicate whitespace.
• Supports a "processing" layer that allows users to define and configure "algorithms" into fully-fledged processes to support insertion of new data, maintenance activities during editing cycles, and a flexible release process.
  • This mechanism can also be used to support batch changes
• Supports a flexible workflow framework allowing for simple authoring, authorign plus review, dual authoring with conflict resolution, or other modes.

Upcoming Features

• Support multiple, simultaneous editing of the same concepts for dual independent review, conflict identification, and conflict resolution.
• REST API for batch changes.
• Default export/release process for performing identifier assignment and delta RRF generation.
• Additional loaders
  • SNOMED RF2 loader
  • ClaML loader
  • Generalized OWL loader
• Export to Owl for "description logic" based terminologiesgenerating releases in supported input formats.

Future Development