Qualifier Notes

Background

Common Terminology Services

The CTS Messaging API defines an interface that supports Qualifiers, as specified in the HL7 Version 3 Data Types Specification

The HL7 Version 3 Concept Descriptor (CD) Data Type includes a Qualifier component, which can "..constrain the meaning of the primary code, but cannot negate it or change it's meaning to that of another value in the primary coding system". The qualifier field is a list of Concept Role elements, which carry a name/CD tuple.

The CD specification includes the ability to test for equality and subsumption.

The HL7 CTS Specification includes supporting functions for both of these requirements:

• equality/equivalence
• implies/subsumes
  • Note that these two methods don't define how equivalence and subsumption are determined - they simply define an interface that allows the question to be posed and an answer to be supplied

The CTS Specification, however, doesn't address compositional issues outside of the HL7 Messaging API space. Functions exist to determine whether two concept codes are related, and the code mapping API provides the ability to query the concept code in a target system that most closely approximates the source target, but again it only addresses a single concept code.

OMG Terminology Query Services (TQS)

The TQS Systemization interface supports a number of compositional related functions, including:

validate_concept_expression - Determines whether a supplied concept expression is syntactically and semantically sensible according to the rules of the particular coding scheme.

• get_simplest_form - Returns the expression in the simplest possible form
• expand_concept - returns the "canonical" representation of the concept expression
• are_expressions_equivalent - answers "yes", "no" or "unable to tell" whether two concept expressions are equivalent to each other
• expression_difference - returns an expression representing the difference between two expressions
• minimal_common_supertype - returns the closest concept expression that is the "closest" supertype of the two expressions
• maximal_common_subtype - returns the "closest" shared subtype of the two expressions

The TQS Concept Expression data type supports a set of constructs that are similar to RDF.

New Functionality

1. CTS2 Messaging API - the CD data type is going to be extended and tweaked to support "role groups", and corresponding functionality (may) have to be provided to support this. In addition, it is likely that input from the Java SIG will result in further and more detailed requirements involving composition. It is assumed that this sort of extension is non-controversial and just needs to be handled as it arises
2. CTS2 Vocabulary API
   1. IF the CTS2 Vocabulary API is to be extended to support subsumption, the following needs to be defined:
      1. Compositional structures - The Messaging API supports compositional queries because the CD data type supports a notion of composition. Were the VAPI to address composition related queries, it would need to address what a compositional structure looked like. Some options include:
         1. Resource Description Format (RDF) - RDF defines a model for defining information using nested triples and a variety of representatal formats.
         2. RDF Schema (RDFS) - RDFS describes how to use RDF to describe RDF vocabularies. This specification defines a vocabulary for this purpose and defines other built-in RDF vocabulary initially specified in the RDF Model and Syntax Specification.
         3. HL7 CD format - Described above
         4. Web Ontology Language (OWL) - OWL is based on RDF and defines a model for defining formal DL-based structures.
         5. DIG Format
      2. Interface - should the interface look like the LQS specification? Should it wrap DIG? Should it defer to DIG?
   2. Support for subsumption testing and transformation will have to address a number of issues:
      1. The formality of terminology content spans a broad spectrum - from thesaurus "BT" and "NT" terms to OWL DL Statements to First (and higher) predicate logicate statements. Should the specification attempt to remain "formality neutral" or should it assume some level of compexity.
      2. As opposed to 10 years ago, when the TQS authors had an "open playing field", there are now many different entities involved in different aspects of logic, ontologies and concept expressions. Should the CTS2 be one more player, simply attempt to provide a buffer layer or do nothing?
      3. There is a fine line between "post-coordinated" expressions and ontology definitions. Part of the DIG inteface includes the ability to define the existing ontology to the classifier and then to ask questions. Opening the CTS2 specification to compositional expressions takes it a long ways towards formal definitional structures.

Recommendations

1. Include support for extended CD data structure functions in CTS2
2. Consider CTS2 support for information model/terminology transformations
3. Include something similar to TQS in the CTS2 specification:
   1. ConceptExpressions will be defined to be semantically compatible with RDFS
   2. What constitutes a valid expression and how transformations occur will not be included in the spec
   3. Interface will borrow heavily from DIG and Protege Experience.