3. Control of Health Care Costs ...
Improved Quality of Care ...
Improved Health Outcomes ...
Appropriate Use of HealthTechnology...
Compassionate Resource Management...
> ... depend upon information
> … ultimately Patient Data
4.
5. Terminologies (and ontologies, sort of…)
have been around for a long time in the
healthcare domain.
Coding / classification / query is an integral part of
the practice of medicine
Shared electronic records is an emerging need
▪ PMR
Defines the meaning of data
i.e. changes data to information through
instantiation of semantic rules
6. A structured terminology is
composed of concepts along
with synonymous terms,
properties and various
relationships, especially a
taxonomy
Relationships
Taxonomy (is-a)
Partonomy (part-of)
Etiology (caused-by)
Therapy (treated-by)
Position (located-in)
7. Concepts represent unique ideas
Codes uniquely identify concepts
Terms refer to concepts
Typically
Humans communicate concepts using terms
Computers communicate concepts using codes
Concepts are language independent; terms are dependent
8. Humans and computers
select, apply and transform concepts, codes and terms
Across human languages
Across contexts (geographic, medical specialty, etc.)
Across applications
Example scenario
English term entered by clinician
Term is encoded in SNOMED
Code is recorded in Electronic Health Record
Record is retrieved
Record is transmitted to another application in another institution
Code is extracted
Term is requested e.g.,
▪ Spanish term
▪ Consumer term
9. Provide consistent meaning
Promote shared understanding
Facilitate communication with humans
Enable comparison and integration of data
Essential for interoperation among systems,
applications and institutions
Crucial for Electronic Health Record (EHR) sharing
and portability
10. Structured terminologies are needed in
healthcare for
Data integration
Decision support
Clinical guidelines
Medical error reduction
12. WithoutTerminology Standards...
Health Data is non-comparable
Aggregation is difficult if not impossible
Health Systems cannot Interchange Data
Linkage to Decision Support Resources not Possible
13. One of the fundamental goals of computerized
medical information is that of precise, accurate and
unambiguous communication.
Structured terminologies provide the semantics of
the concepts being conveyed in an electronic message
or record (syntax is another discussion altogether).
14. Being able to predictably access terminological
content is still necessary.
Example
Need to receive a SNOMED-CT disorder code, and
▪ Validate the code against the SNOMED-CT vocabulary
▪ Query against properties of the code (determine the grouping or
aggregation of the code, e.g.What type of disorder is this?)
▪ What drugs can be used to treat this disorder
▪ Translate this code for our insurance systems.
Problem
How do we ensure that our operations with vocabulary are
consistent across domains?
15. 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, RDF, MIF…)
This is whereTerminology Services comes in.
16. A terminology server is
a (networked) software component
centralizes terminology content access and
reasoning
provides (complete, consistent and effective)
terminology services for other network applications
17. By informaticists
to create, maintain, localize and map
terminologies
By clinical applications and their users
to select and record standardized data
By integration engines
to facilitate mapping terminology elements
between applications
18. The means by which applications (clinical) can
Define the common business functions for
terminology applications
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)
19. 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
20. Term/name normalization:
What is the SNOMED CT name for heart attack?
Myocardial
Infarction
Code translation:
What is the ICD-9 code for Myocardial Infarction?
410.9
Grouping and aggregation:
Is Myocardial Infarction a Cardiac Disease?
Yes
Clinical knowledge:
What drug treats Myocardial Infarction?
Streptokinase
Local information:
Add L227 as the local code for Serum Calcium.
OK
21. YATN: yet another terminology service 1996
Mayo, Kaiser, LexicalTechnology
MetaPhrase – LexicalTechnology 1998
UC Davis JTermTerminolgy service 1998
LQS: Lexicon Query Services; 3M 1998
Apelon DTS
Mayo Autocoder: UI toYATN suite 2000
CTS: CommonTerminology Services 2003
LexGrid: superset CTS, ref. implementation – 04
CTS 2 – DSTU Ballot March 2009
22. An HL7 ANSI 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.
Each terminology developer is free to implement this
API call in whatever way is most appropriate for them
23. Advantages to this functional 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
24. Client software doesn’t have to know about specific
terminology data structures and/or how to access
them.
Server software can plug and play with many
clients.
25. The MessageAPI
allow a wide variety of
message processing
applications to create,
validate and translate CD-
derived data types
TheVocabularyAPI
allows applications to query
different terminologies
27. Message Creation Software – Software that is involved in the
creation of HL7 messages.
Message Processing Software – Software that receives, decodes
and acts on the content of standard HL7Version 3 messages.This
process may include validation, translation and inferencing steps.
RIM Modelers –The combination of people and tools that create
and define HL7 Message content.
Software Developers –The people who build the software that
creates, validates and processes HL7Version 3 messages.
VocabularyTranslators – A combination of tools and people that
translate the abstract HL7Version 3 specification into the structure
and terms of actual data processing applications.
28.
29.
30. Allows Client Software to be Developed
Independently from Service Server Software
AllowsTerminology Plug-and-Play
Allows Client Plug-and-Play
Defines a “Functional Contract” between
terminology users and providers
31. Purposely limited functional scope:
read only
terminology access APIs for HL7 (much carryover
to other terminologies)
basic terminology mapping
no versioning support
32.
33. Project of the HL7VocabularyWorkgroup
Developed under the Service OrientedArchitectures
(SOA) and Healthcare Service Specification Project
(HSSP) framework
Expand the scope of functionality to include
▪ Administrative functions
▪ Expanded search capability
▪ Mapping functionality
▪ Authoring / Maintenance
▪ Conceptual model for terminology
34. the purpose of an HL7 SFM is to identify and document the
functional requirements of services considered important to
healthcare.
Accordingly, the CTS 2 service provides a critical component
within the larger context of service specifications in that it
defines
The expected behaviors of a terminology service
A standardized method of accessing terminology content.
35. The major goal of the CTS 2 specification stack is to
provide a standardized interface for the usage and
management of terminologies.
CTS 2 defines the functional requirements of a set of
service interfaces to allow the representation, access,
and maintenance of terminology content either locally,
or across a federation of terminology service nodes.
36. Establish the minimal common structural model for
terminology behavior independent from any specific
terminology implementation
Integrate into CTS 2 the functional coverage outlined in the
existing CTS specification.
Specify both an information and functional model that
addresses the relationships and use of terminology.
Specify the interactions between terminology providers and
consumers
37. Specify how mapping between compatible terminologies
and data models is defined, exchanged and revised.
Specify how logic-based terminologies can be queried about
sub-sumption and inferred relationships.
Engage broad community participation to describe the
dimensions of use and purpose for vocabularies and value
sets.
39. Set of functionality that provides the ability to manage
content
ability to load terminologies
export terminologies
management of notifications
Accessible by service administrators
40. Set of functionality that provides the ability to find concepts
based on some search criteria.
Includes:
capabilities for searching.
querying terminology content .
representing terminology content in the appropriate
formats.
41. Set of functionality that provides the ability to create
and maintain content.
This would include the appropriateAPIs to add, change,
or delete concepts and associations.
42. Set of functionality that provides the ability to map
concepts and the concept's associated attributes
from a source terminology to a concept in a target
terminology.
OR
Create relationships between concepts within a
single code system.
43. 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.
44. Specifies the minimal functional coverage necessary for
a service to declare itself as being a conformant CTS 2
service.
Includes capabilities for
searching and query terminology content
representing terminology content in interoperable data
types and structuring terminology content.
45. Provides 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
withTerminology Provider systems in order to:
obtain the terminology content, then load that
terminology content on localTerminology Servers.
46. Terminology authors require the capability to robustly
query and access terminology content, as well as directly
modify the terminology content.
Intended to provide the functional operations necessary
for terminology authors to analyze and directly edit the
existing terminology content.
50. Problems:
Controlled terminologies are developed with specific
purposes and use cases in mind, and as such are
structured very differently.
The format of any given terminology may range from
a simple flat list of concepts, to more complex poly-
hierarchies. The variety of attributes of the entities of
code systems vary as well.
Even the formats of the identifiers are different
Some concept identifiers being meaningless identifiers,
Others which have explicit or implied meaning.
51. CTS 2 specifies a concept based terminology model
that is capable of representing most varieties of
structured terminologies.
Basic requirements of the CTS 2 terminology model
are illustrated in the CTS 2 Conceptual Model
52.
53. CodeSystem
a resource that makes assertions about a collection of
terminological entities.
described by a collection of uniquely identifiable concepts with
associated, representations, designations, associations, and
meanings
ICD-9 CM, SNOMED CT, LOINC, and CPT
CodeSystemVersion
Generally not static entities and change over time
Enables identification of the versions of the code system
CodeSystemConcept
A Code System Concept defines a unitary representation of a real
or abstract thing within the context of a specific Code System; an
atomic unit of thought.
54. CodeSystemNode:
Represents an individual "node" within a Code System, which is
either a Code System Concept or a Code System Concept Code
CodeSystemConceptCode:
defines a single "code value" that is used to represent
(symbolize) a Code system Concept
There may be more than one Code for a single concept in a
single code system
AssociationType:
In the terminology model, allowable relationship types are
represented by the AssociationType class.
Enables identification of the versions of the code system
55. Designation :
Concept designations are representations of concepts
For example, in SNOMED CT the concept of “fever” has:
▪ the fully specified name of “fever (finding),”
▪ A preferred name of “fever,”
▪ synonyms of “febrile” and “pyrexia.”
These are all designations for the concept of “fever.”
Value Set :
Represents a uniquely identifiable set of concept codes grouped
for a specific purpose.
May range from a simple flat list of concept codes drawn from a
single code system, to an unbounded hierarchical set of possibly
post-coordinated expressions drawn from multiple code systems.
56.
57. 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
▪ Administrative functions
▪ Expanded search capability
▪ Mapping functionality
▪ Authoring / Maintenance
58. CTS-1 deliberately avoided issues related to
terminology distribution, versioning and authoring.
CTS-1 focused on static value sets and didn’t fully
address the definition or resolution of value sets that
define post-coordinated expressions.
CTS-1 fails to address many of the maintenance,
versioning and representation requirements
necessary for a truly interoperable terminology
service.
59. CTS-1 was deliberately silent on how the vocabulary
content should be structured.
CTS-2 will enhance the capabilities of the original CTS
specification for sub-setting, mapping and extending
the specification into domains such as terminology
distribution, authoring, and versioning.
60. Terminologies play a crucial role in enabling
semantic interoperability by defining the
meaning of data being communicates
Healthcare has been a leader in the
development of terminologies for use in
classifying and aggregating clinical data.
Terminology Services can be deployed to
provide consistent access to terminology
resources across organizations
Notas del editor
Instead of specifying what an external terminology must look like, HL7 has chosen to identify the common functional characteristics that an external terminology must be able to provide.the CTS specification describes an Application Programming Interface (API) call that takes a resource identifier and concept code as input and returns a true/false value
There are two distinct layers between HL7 Version 3 message processing applications and the target vocabularies. The upper layer, the Message API, communicates with the messaging software, and does so in terms of vocabulary domains, contexts, value sets, coded attributes and other artifacts of the HL7 message model. The lower layer, the Vocabulary API, communicates with the terminology service software, and does so in terms of code systems, concept codes, designations, relationships and other terminology specific entities.
Message Runtime Service fill out the details of a CD-derived attribute. The service, in turn, makes multiple calls to the Vocabulary API service in order to get concept code designations, code system names, release versions, etc.
Each Service’s Functional Model defines the interfaces that the service exposes to its environment, and the service’s dependencies on services provided by other components in its environmentThe manner in which services and interfaces are deployed, discovered, and so forth is outside the scope of the Functional Model
Collection of similar service under one profile
CTS 2 is an interface specification, not an implementation specification. As such, it is intended to facilitate the development of an implementable interoperability mechanism for terminology resources
CTS2 provides for terminology interoperability between organizations. While coded concepts from structuredterminology can unambiguously identify the concept(s) being communicated, a standard way of structuring and communicating those coded entries is required.CTS 2 can be used in an inter-organizational setting where each organization maintains its own security and application specific provisions. CTS 2 will enable consistent access to a high availability or international standard terminology resource, made available to subscribers via a CTS 2 interface.
CTS 2 Conceptual Model describes a logical (analysis level) model with the intent that most - if not all - key attributes that affect terminology behavior have been describedIt is the intent of this model to support both well behaved and more arbitrarily defined code systems.
Code Systems, Concepts and Value Sets have specific version classesAdditionally curation has been supported explicitly byinclusion of a number of classes that permit the versioning of key terminology entitiesIt is a conceptual model derived from business requirements, and as such is rather meant to reflect these requirements and not intended to explicitly provide implementation level detail.Technical specifications must define minimum explicit state models for the purposes of interoperabilityThebasic “default” minimum assumption is that the concept of “active” and “inactive” states is covered, wherebyinactive instances would not show up in normal searchesSeveral classes in the model include an attribute for provenance information, named "provenanceDetails".Technical Specs should include such information as:author, copyright, generation type, source and source type, approval information, whether it is modifiable, and so on.
At a minimum, Code Systems have the following attributes:• An identifier (id) that uniquely identified the Code System. In HL7, this ID is in the form of an ISO OID.• A description (description) that describes the Code System. This may include the code system uses and intent.• Administrative information (administrativeInfo) which is a placeholder to allow for additional information relating to the overall Code System, that is separate from any specific version of the Code System.
AssociationType:It is not a part of a code system, but a separate entity which is used to further characterize associationsAn example for an association type is “subsumption association”.
AssociationType:It is not a part of a code system, but a separate entity which is used to further characterize associationsAn example for an association type is “subsumption association”.
CTS 2 Service: The CTS 2 Service is a specific implementation of the CTS 2 Terminology ServerTerminology User: Subject matter expert, terminologist or terminology enabled application.Terminology Administrator: an actor responsible for ensuring the availability and overall maintenance of the terminology server.Terminology Enabled Application Developer: an actor who is responsible for the development of software applications that make explicit use of controlled terminologiesTerminology Author / Curator:an actor who is responsible maintaining terminology content, including but not limited to, the development of new concepts and associations that may be submitted to the Terminology Provider or the extension of an existing terminology with local conceptsTerminology Human Language Translator: an actor with domain knowledge who is also familiar with the languages and dialects which they are responsible for translatingTerminology Mapper: an actor (human or system) that is responsible for creating or maintaining specialized associations, or "mappings" between concepts from different code systems.Terminology Provider: the individuals or organization that is responsible for the development of Terminology Content.Terminology Value Set Developer:an actor with specific domain knowledge, as well as expertise in controlled terminologies who develop s and maintains domain-or application-specific terminology value sets
HL7 CTS-1 standard serves an important role in defining the common functional characteristics that a terminology service must be able to provide.
HL7 CTS-1 standard serves an important role in defining the common functional characteristics that a terminology service must be able to provide. CTS2 provides the terminology community with a defined set of standards interfaces that can be used to evaluate terminology source structure, terminology source content, and terminology tools.