This wiki has undergone a migration to Confluence found Here

Difference between revisions of "Qualifier Notes"

From HL7Wiki
Jump to navigation Jump to search
Line 40: Line 40:
#### [ DIG] [ Format]
#### [ DIG] [ Format]
### Interface - should the interface look like the LQS specification?  Should it wrap [ DIG]?  Should it defer to DIG?
### Interface - should the interface look like the LQS specification?  Should it wrap [ DIG]?  Should it defer to DIG?
## Support for subsumption testing and transformation

Revision as of 19:39, 16 May 2005


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