Use Cases - derived Basic Functionalities:
Almost every clinical application leverages (coded) concepts from both standard, national and local terminology systems.
The ability to look up concepts in a terminology system, to resolve the relationships between two or more concepts, the
expansion of a valueset definition, their maintenance across versions over time are but some of the basic operations that
would be beneficial to the components and services supporting an application.
Candidate components include, but are not limited to:
- Terminology system curation tools
- Knowledge artifact authoring tools (e.g. rules, quality measures, etc..)
- (Synthetic) Data curation tools
- Data repositories implementing "semantic" queries (e.g. FHIR servers)
- Knowledge execution runtime (e.g. CDS engines)
- Data validation and conformance implementations (e.g. FHIR validation based on profiles)
- Data Aggregation systems e.g. supporting dashboard-like applications
- Data normalization / alignment / transreption, both offline and online
Requirements:
High level functional requirements for a terminology service include:
- Resolving codes into concept (descriptions)
- Resolving subsumption and other "semantic" queries between concepts
- Resolving and expanding valuesets, supporting operations between them
- Maintaining terminology systems, with provenance and versioning
- Supporting mappings between terminology systems
From an integration perspective, several patterns have emerged as desirable, which
result in a variety of non-functional requirements:
- Terminology resolution as a centralized (web) service in a SOA
- Terminology as a component in a tightly coupled architecture
- Terminology as an in-memory application feature
- Hybrid combinations of the above
- High-throughput online systems, mostly focused on resolving relationships
between coded concepts and valuesets (e.g. to support semantic queries or CDS) - Low-throughput online systems, mostly focused on lookups (e.g. to support CDS authoring tools)
- Low-throughput offline systems, mostly focused on maintenance (e.g. to support maintenance tools)
Candidate Specifications:
- FHIR terminology service - HL7 FHIR TS
- CTS-2 v1.1 specification - OMG CTS-2
- Recommended TS interaction scenarios and protocols
Known Service Implementations :
- Apelon : TBD - wiki http://apelon-dts.sourceforge.net/
- 3M : both proprietary (on CTS-2 and 3M APIs) and open source (on CTS 1.2 and 3M) versions of the HDD service exist.
HDD Access website: https://www.hddaccess.com/
Software (binary and source) downloads: https://www.hddaccess.com/hdd-access-products/download-hdd-access
Content and documentation downloads: https://www.hddaccess.com/current-content-documentation/
Online search and browser: https://www.hddaccess.com/hddbrowser/search
Online API WADL endpoint: https://www.hddaccess.com/hddbrowser/api/application.wadl
Online API documentation: http://apps.3mhis.com/docs/Care_Innovation/HDD/HDD_Access/HDD_Access_Library/index.htm#144905.htm
Uploading contributions: https://www.hddaccess.com/hdd-access-community/open-exchange - HLI : TBD
- LexVS : TBD - wiki https://wiki.nci.nih.gov/display/LexEVS/LexEVS
- OntoServer - http://ontoserver.csiro.au:8080/
- Provides support for FHIR TS API – http://ontoserver.csiro.au/fhir
Content:
Current action items:
- Evaluate FHIR TS as a runtime API for applications
- Evaluate candidate implementations
- Work with the terminology content WG to define the "endorsed" content, if any
- Evaluate, provide feedback and assist with the evolution of the candidate specifications
- CTS-2 consolidation roadmap
- Define a test framework to validate the functionality of a candidate implementation for the purpose of use by an application
References and Links:
An initial email thread discussing the topic (Oct 29, 2015)