Use Cases:
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
The goals of this task force are manifold
- Harmonize the FHIR Terminology Service (TS) specification with the OMG CTS-2 standard, under some assumptions:
- The scope of the FHIR server is narrower, and more runtime and application oriented
- The scope of CTS-2 is to cover a full terminology management and runtime service
- The FHIR server specification can be implemented on top of a CTS-2 one
- Critique the underlying CTS-2 spec, furthering its next generation
- Making recommendations to the FHIR community
- Identify candidate implementations
Current action items / decisions
- Recommend FHIR TS as a runtime API for applications
- Reach out to major terminology service vendors for open source / public deployment of API endpoints
- Apelon
- 3M
- HLI
- ...
- Work with the terminology content WG to define the "endorsed" content, if any
Specifications
- Alignment of FHIR TS and CTS-2 APIs
- Recommended TS interaction scenarios and protocols
Material and reference
- An initial email thread discussing the topic (Oct 29, 2015)