Common Terminology Services Release 2 CTS 2

1
Common Terminology Services Release 2 (CTS 2)

• Russell Hamm
• Informatics Consultant
• Apelon, Inc.

2
Outline

• Background
• Why a CTS is needed
• Initial CTS Specification and Tools
• Specification
• Limitations
• Current work and Enhancements to CTS
• CTS2
• Next Steps

3
Basis for Communication

• Terminologies allow specialization (refinement)
  of information models to serve a particular
  purpose
• Standard terminologies provide the fundamental
  values to be used with encoded data (over 45 of
  health care data)
• Information Models coupled with Terminology
  provide the rules and semantics for expressing
  health care information

4
Meaningful Communication

• Being able to query against terminological
  content used in systems and information models is
  a fundamental necessity.
• Example
• Need to receive a NDF-RT drug code, and
• Validate the code against the NDF-RT vocabulary
• Query against properties of the code (what family
  of drug does this drug code belong to, is it
  generic or a brand name?)
• Query to see if the specified drug code is in our
  pharmacy inventory.
• Problem
• How do we ensure that our operations with
  vocabulary are consistent across domains?

5
Meaningful Communication

• External terminological resources vary
  considerably in both content and structure.
• User requirements of terminology differ (real
  time decision support, billing applications)
• Storage formats may differ (relational database,
  XML, MIF)
• Even using a standardized terminology (i.e.
  SNOMED) it is very likely that different service
  implementations into the same terminology will
  yield different results.
• This is where a Common Terminology Services (CTS)
  comes in.

6
What are Terminology Services?

• The means by which applications (clinical) can
• Utilize and interoperate among standard and local
  terminologies
• Benefit from terminology model knowledge
• Are provided by terminology server software,
  which
• Centralize or federate terminology content and
  represents it in a consistent format
• Communicates with other network applications
  (e.g., to translate and normalize data elements)
• Provides a common platform for terminology
  updates
• Provides tools to develop and maintain
  terminology content, including mappings that
  connect concepts in different terminologies,
  use-specific subsets, and local extensions to
  existing standards.
• Implement terminology as an asset of the
  organization (TAM)

7
HL7s Common Terminology Services (CTS)

• What is CTS?
• An HL7 and ISO Standard interface specification
  for querying and accessing terminological
  content.
• The CTS identifies the minimum set of functional
  characteristics a terminology resource must
  possess for use in HL7.
• The functional characteristics are described as a
  set of Application Programming Interfaces (APIs)
  that can be implemented to suit.

8
HL7s Common Terminology Services (CTS)

• Advantages to the CTS approach
• No need to force a common terminological
  structure on terminology developers.
• Decouples terminology from the terminology
  service.
• Terminology users can use whatever technology
  appropriate for their needs.
• Legacy database
• Institutional infrastructure
• Provides a common interface and reference model
  for understanding
• I know what you mean by Code System
• I know what to expect when I execute the
  validateCode() method
• Client software doesnt have to know about
  specific terminology data structures and/or how
  to access them.
• Server software can plug and play with many
  clients

9
CTS Modules

• There are two distinct layers between HL7 Version
  3 message processing applications and the target
  vocabularies.
• Upper layer, the Message API (MAPI), communicates
  with the messaging software.
• To allow a wide variety of message processing
  applications to create, validate and translate
  CD-derived data types in a consistent and
  reproducible fashion
• The lower layer, the Vocabulary API(VAPI),
  communicates with the terminology service
  software.
• Allows applications to query different
  terminologies in a consistent, well-defined
  fashion.

10
Common Terminology Services
11
Common Terminology Services API

• Allows Client Software to be Developed
  Independently from Service Server Software
• Allows Terminology Plug-and-Play
• Allows Client Plug-and-Play
• Defines a Functional Contract between
  terminology users and providers.

12
Common Terminology Service Benefits

• Benefits for designers and implementation
  developers
• Software can be written once and wont need to
  understand each terminology vendors database
  and/or API
• Hides much of the complexity inherent in modern
  terminology systems.

13
Common Terminology Service Benefits

• Benefits for terminology software developers
• Basic functional requirements clearly specified
• Implementation can be based on existing databases
  and software
• A common entry point you dont have to sell the
  idea you sell your enhancements, performance,
  etc.

14
Limitation of CTS

• Purposely limited functional scope
• read only
• terminology access APIs for HL7 (much carryover
  to other terminologies)
• basic terminology mapping
• no versioning support

15
CTS 2

• Project of the HL7 Vocabulary Workgroup
• Developed under the Service Oriented
  Architectures (SOA) Healthcare Service
  Specification Project (HSSP) framework
• Expand the scope of functionality to include
• Administrative functions
• Expanded search capability
• Mapping functionality
• Authoring / Maintenance
• Generic behavioral model for terminology

16
What is the Healthcare Service Specification
Project?

• A joint standards development activity occurring
  in multiple organizations, including Health Level
  7 (HL7), the Object Management Group (OMG), Open
  Health Tools, IHE, and others
• An effort to create common service interface
  specifications tractable within Health IT
• Its objectives are
• To create useful, usable healthcare standards
  that address business functions, semantics and
  technologies
• To complement existing work and leverage existing
  standards
• To focus on practical needs and not perfection
• To capitalize on industry talent through open
  community participation

17
CTS 2 Process

• Formalize Actors
• Behavioral Model
• Business Scenarios (Use Cases)
• Detailed Models
• Profiles
• Functional
• Semantic
• Conformance

18
Formalize Actors
19
Behavioral Model

• Terminologies are created for many purposes, and
  as such are often structured very differently
• flat list of concepts,
• complex poly-hierarchies.
• The attributes of the entities of code systems
  vary as well.
• formats of the identifiers are different,
  meaningless identifiers/implied meaning.)
• The functional components of CTS 2 must be able
  to operate on this broad spectrum of terminology
  sources.
• Specify a concept based terminology model that is
  capable of representing most varieties of
  structured terminologies.
• Minimal necessary behavioral model for
  terminologies
• Look to standards communities, industry, and
  academia

20
Behavioral Model - Scope
21
Business Scenarios (Use Cases)

• Based on the discussed terminology service
  criteria, define high level business scenarios
  that
• Cover the existing CTS functional capabilities
• Extend the CTS functionality into other domains
• Develop detailed interfaces that outlines the
  expected inputs/outputs of to each use case
• 1 to use case to detailed model associations

22
Profiles

• A profile is a named set of cohesive capabilities
  that enables a service to be used at different
  levels, and allow implementers to provide
  different levels of capabilities in differing
  contexts.
• Service-to-service interoperability will be
  judged at the profile level and not the service
  level.
• A set of profiles may be defined that cover
  specific functions, semantic information and
  overall conformance.

23
Minimal CTS 2 Profile

• The Minimal CTS 2 Profile specifies the minimal
  functional coverage necessary for a service to
  declare itself as being a conformant CTS 2
  service.
• The minimal CTS 2 includes capabilities for
  searching and query terminology content,
  representing terminology content in the
  appropriate HL7 Datatypes, and structuring
  terminology content appropriately when HL7
  Datatypes are not available.

24
CTS 2 Query Profile

• The CTS 2 Query Profile specifies basic query
  only functional coverage necessary for a service
  to declare itself as being a minimally conformant
  CTS 2 service.
• The CTS 2 Query Profile includes capabilities for
  searching and query terminology content.

25
CTS 2 Terminology Administration Profile

• The Terminology Administration profile is
  intended to provide the functional operations
  necessary for terminology administrators to be
  able to access and make available terminology
  content obtained from a Terminology Provider.
• Terminology Administrators are required to
  interface with Terminology Provider systems in
  order to obtain the terminology content, then
  load that terminology content on local
  Terminology Servers.

26
CTS 2 Terminology Authoring Profile

• Terminology authors require the capability to
  robustly query and access terminology content, as
  well as directly modify the terminology content.
• The Terminology Authoring profile is intended to
  provide the functional operations necessary for
  terminology authors to analyze and directly edit
  the existing terminology content.

27
Status

• The CTS 2 SFM went to ballot as Draft Standard
  for Trial Use (DSTU) for the May 2009 ballot
  cycle at HL7
• Passed with more than 60 required votes
• Resolve and integrate comments into CTS 2 SFM
• Meet with OMG to begin drafting a RFP

28
Summary

• Standardized terminology services seek to provide
  interoperable terminology service interfaces
  regardless of the terminology being served.
• Terminologies vary in structure and purpose
• CTS provides a standard read only terminology
  service interface
• CTS 2 seeks to expand on this standard interface,
  moving into the terminology authoring and
  versioning domains

29
Links

• CTS
• www.hl7.org
• CTS 2 SFM
• http//biomedgt.org/apelcore/index.php/HL7_Common_
  Terminology_Services_2_Service_Functional_Model_(S
  FM)
• HSSP Project
• http//hssp.wikispaces.com/
• CTS 2 Project Lead
• rhamm_at_apelon.com

30
Questions