Hl7 common terminology services


Published on

Published in: Technology, Business
1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • 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.
  • Hl7 common terminology services

    1. 1. By Syed Ali Raza, Software Engineer, SEECS, NUST Terminology Services in Support of Healthcare Interoperability
    2. 2.  WhyTerminology  Importance ofTerminologies  Terminologies in Healthcare  Semantics of HealthcareTerminologies  Terminology Services  Intent  HL7 CTS / CTS 2
    3. 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. 4.  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
    5. 5.  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)
    6. 6.  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
    7. 7.  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
    8. 8.  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
    9. 9.  Structured terminologies are needed in healthcare for  Data integration  Decision support  Clinical guidelines  Medical error reduction
    10. 10.  Clinical (SNOMED CT)  Reimbursement (ICD, CPT, HCPCS)  Pharmaceuticals (FDB, RxNorm, NDF-RT, …)  Labs (LOINC)  Nursing (ICNP, NIC, NOC, NANDA)  Adverse events (MedDRA, COSTART, WHOART)  Genetics (GO)  …
    11. 11. 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
    12. 12.  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).
    13. 13.  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?
    14. 14.  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.
    15. 15. 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
    16. 16.  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
    17. 17.  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)
    18. 18.  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
    19. 19. 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
    20. 20.  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
    21. 21.  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
    22. 22.  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
    23. 23.  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.
    24. 24.  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
    25. 25.  The MessageAPI utilizes theVocabularyAPI
    26. 26.  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.
    27. 27.  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
    28. 28.  Purposely limited functional scope:  read only  terminology access APIs for HL7 (much carryover to other terminologies)  basic terminology mapping  no versioning support
    29. 29.  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
    30. 30.  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.
    31. 31.  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.
    32. 32.  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
    33. 33.  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.
    34. 34.  Administration  Search  Query  Authoring  Maintenance  Associations
    35. 35.  Set of functionality that provides the ability to manage content  ability to load terminologies  export terminologies  management of notifications  Accessible by service administrators
    36. 36.  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.
    37. 37.  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.
    38. 38.  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.
    39. 39.  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.
    40. 40.  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.
    41. 41.  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.
    42. 42.  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.
    43. 43.  Interface Interoperability Considerations  Terminology Structure Considerations
    44. 44.  CTS 2 Service Accessed by a Single Organization
    45. 45.  Multi Organizational access to a CTS 2 Service
    46. 46. 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.
    47. 47.  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
    48. 48.  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.
    49. 49.  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
    50. 50.  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.
    51. 51.  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
    52. 52.  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.
    53. 53.  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.
    54. 54.  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