Page Comparison

...

• Data model built around RF2. Thus, so it natively handles SNOMED CT® and other terminologies that can be transformed to an a ClaML or RF2 representation (including ClaML).   The data model also includes “first class” representation of standard RF2 reference set patterns (such as Attribute Value and Complex Map).
Support for
• Supports multiple terminologies and versions.
 
• This means the server is capable of handling non- SNOMED CT® based terminologies, such as ICD10, ICD10CM, ICD9CM, and ICPC.
 
• It also means the server is 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.   This means ancestor Ancestor and descendant computations are simple lookups and do not require any computationally expensive graph walking.
• Supports classification via SnoRocket, including incremental classification (if needed)a classification handler for full or incremental classification with a default Snorocket implementation.
• Supports a customizable identifier management mechanism allowing various approaches to ID maintenance to be used, including application managed identifiers, content hash-based UUID assignment, and SNOMEDCT SNOMED CT® identifier assignment based on sequences.   This includes the 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 CT® security architecture, and “no” guest-only security.
• Supports a customizable “graph resolver” mechanism to define the depth into the graph that various read and write calls should support.   The default implementation of this mechanism supports reading/writing a concept that includes descriptions, language refset members, and relationships.
• Supports a customizable validation framework that allows testing of data states prior to serializationpersistence.   The 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 supported.
• Supports multiple, simultaneous editing of the same concepts for dual independent review, conflict identification, and conflict resolution.
• Supports a customizeable customizable “workflow listener” mechanism to interface with an external or third party workflow management system.   Workflow can be tracked at the concept or description level but is not itself maintained by the system. Instead, any “change” to the system can facilitate change to model objects triggers a callback to a custom handler that respond in any way desiredto 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 but and uses hibernate Hibernate to facilitate connections to a variety of other database environments, including MongoDB and Oracledocument-based and graph databases.

Emerging Features