...
- Data model built around RF2. Thus, it natively
- Natively handles SNOMED CT® and other
- RF2 terminologies.
- The data model
- 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.
- 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 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.
- 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
- Default implementations for UTS (http://uts.nlm.nih.gov), SNOMED CT® security architecture, and 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
- 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
- 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
- .
- 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.
References/Links