Snapshot of the OMG LQS Specification

Snapshot of the OMG LQS Specification

Presentation to the HL7 Vocabulary Working Group 1/99

1/25/99 HL7 LQS Presentation 2

Presentation Outline

• Motivation for the specification• Requirements and constraints• Approach and process• Specification overview• Sections which may be directly useful to HL7• Current state of the specification and next steps• Q&A


First things first - just what are we talking about?

“Lexicon Query Services” (LQS) Specification• Interface specification for read only access to

medical coding schemes• Formally adopted by the Object Management

Group (OMG) 7/98• Describes an object-based API to accomplish

common tasks involving medical coding schemes Definitions, representations(terms), associations, etc.


First things first - what are we talking about?

“Lexicon Query Services” (LQS) Specification• Specification is publicly available at:

ftp://ftp.omg.org/pub/docs/corbamed/98-03-22.pdf


Motivation - why did we do it?

A group of companies and organizations had been investigating the possibility of specifying medical component behavior, with the purpose of arriving at a set of API’s which would enable component level interoperability within the medical domain.


Motivation

As always, one of the cornerstones of interoperability was the ability to agree on a common conceptual base and corresponding representational structure.


Motivation

Conceptual Base RepresentationalStructure

Letters, numerals andpunctuation characters

ASCII

Floating point numbers IEEE FP specification

Behavioral characteristics ofan 80x86 microprocessor

80x86 opcodes

Reportable diseases of thehuman body

ICD


Motivation

We determined that we wanted to arrive at a common means of representing and manipulating coded information before we got heavily involved in the specification task.Previous OMG specifications were inconsistent,

imprecise and incomplete when it came to the notion of coding.


Motivation

Possible approaches• Select one coding scheme to represent all codes

(UMLS, SNOMED-RT, GALEN, READ, ???)• Select a single structure into which any coding

scheme may be placed (KIF, KRSS, UMLS DB, ???)

• Specify a set of behavioral characteristics common to anything called a “coding scheme” - What can I ask of it and how should it respond?


Motivation

Stimulus Response

The notion of a black box


Requirements and Constraints

• Specification had to cover enough territory to be useful.

• Specification had to address a wide spectrum of coding schemes– From a simple table of code + term…– …to a terminology on the level of GALEN or

SNOMED-RT



• Specification had to cover a wide variety of uses:– From real-time vital signs interfaces on a

minimal platform…– … to a mainframe type of service doing

translation, lookup, normalization, inference, etc.



• Specification could not presume:– A specific database (e.g. Oracle) or even

storage type (e.g. relational, OODB)– A specific platform (e.g. Intel)– A specific programming language– A specific operating system



• Specification had to have buy-in (or at least input from):– Terminology specialists– Medical system vendors– Health Care Community


Approach and Process

• OMG RFP issued January 1997

• Formed “CORBAlex” working group April 1997

• Attempted to use the classic CEN approach - Scope/Use Cases/Model/Specification -

• But...


• … quickly discovered that Use Cases required precise definitions of terms (objects) and precise definition of objects required a model and a model required a notion of purpose and application.

• Resulting process was iterative:


Use Cases Model Definitions


• One of the final step was a rendering of the model in IDL.– Non-trivial process. The IDL specification was

an “Engineering” specification. Mapping had to be done manually by skilled CORBA people.



• Model transformation to IDL– Steps included:

• Transformation of lightweight classes into structs

• Elimination of classes representing collections

• Addition of “shortcuts” for anticipated frequent usages

• Partitioning of model into compliance groups:

LexExplorer, CodingSchemeLocator, etc.



Specification Overview

• Specification is at:

http://www.omg.org/docs/corbamed/98-03-22.pdf• IDL can be found at:

http://www.omg.org/docs/corbamed/98-03-18.idl


Specification Overview

• Chapters 1&2 - Overview and OMG conformance statements

• Chapter 3 - DEFINITIONS

• Chapter 4 - Use Scenarios

• Chapter 5 - Reference Model

• Chapter 6 - Engineering model

• Chapter 7 - Meta-Terminology


Portions with potential applicability to HL7

• NamingAuthority - Unique “global” identifiers for things (including concept codes)

• ValueDomain - Provides access sets of codes associated with data elements

• Code to Presentation translation• Code to Code translation• (parts of) Meta-Terminology - ‘bootstrap’ coding

scheme


NamingAuthority

RegistrationAuthorityvalue : enum {Other, DCE, IR, DNS, ISO}

NamingEntityvalue : string

AuthorityId

1

+authority

1 1

+naming_entity

1

QualifiedName

1

+authority_id

1 LocalNamevalue : string

1+local_name

1


NamingAuthority

• DCE– RegistrationAuthority: DCE

– NamingEntity: 6132A880-9A34-1182-A20A-AF30CF7A0000

– LocalName: /HL7/I9C

– Example:

DCE: 6132A880-9A34-1182-A20A-AF30CF7A0000/HL7/I9C


NamingAuthority

• ISO– RegistrationAuthority: ISO

– NamingEntity: iso member-body hl7

-or-

iso(1) member-body(2) hl7(26519)

-or-

1 2 26519

– LocalName: /I9C

– Example:

ISO: iso member-body hl7/I9C


NamingAuthority

• DNS– RegistrationAuthority: DNS

– NamingEntity: codingSchemes.hl7.org

– LocalName: /I9C

– Example:

DNS:codingschemes.hl7.org/I9C


NamingAuthority

• IDL– RegistrationAuthority: IDL

– NamingEntity: org.hl7

– LocalName: /codingScheme/I9C

– Example:

IDL:org.hl7/codingScheme/I9C


NamingAuthority

• Local– RegistrationAuthority:

– NamingEntity:

– LocalName: I9C

– Example:

I9C


NamingAuthority.idl

module NamingAuthority

{

enum RegistrationAuthority {

OTHER,

ISO,

DNS,

IDL,

DCE };

typedef string NamingEntity;

struct AuthorityId {

RegistrationAuthority authority;

NamingEntity naming_entity;

};


NamingAuthority.idl

typedef string AuthorityIdStr;

typedef string LocalName;

struct QualifiedName {

AuthorityId authority_id;

LocalName local_name;

};

typedef string QualifiedNameStr;

exception InvalidInput {};


NamingAuthority.idl

interface translation_library

{

AuthorityIdStr authority_to_str(in AuthorityId authority )

raises(InvalidInput );

AuthorityId str_to_authority(in AuthorityIdStr authority_str )


QualifiedNameStr qualified_name_to_str(in QualifiedName qualified_name )


QualifiedName str_to_qualified_name(in QualifiedNameStr qualified_name_str )


};

};


ConceptCodes

typedef NamingAuthority::LocalName ConceptCode;

typedef sequence<ConceptCode> ConceptCodeSeq;

typedef NamingAuthority::AuthorityId CodingSchemeId;

typedef sequence<CodingSchemeId> CodingSchemeIdSeq;

struct QualifiedCode {

CodingSchemeId coding_scheme_id;

ConceptCode a_code;

};


Value Domains

• Term borrowed from ISO 11179 and X3.285

• Represents the connection between concept codes and data

• An HL7 field is a classic value domain

• Identified by a qualified code: typedef QualifiedCode ValueDomainId;

typedef sequence<ValueDomainId> ValueDomainIdSeq;


Value Domain Interface

• Identificationinterface ValueDomainVersion {

readonly attribute ValueDomainId value_domain_id;

readonly attribute VersionId value_domain_version_id;

readonly attribute boolean is_default_version;

.

.

.



• IdentificationExample:

ValueDomainId - ISO:iso member hl7/Patient/Gender

VersionId - 3.0

is_default_version - TRUE

.

.

.



• List all coding schemes which have one or more valid codes in this domain:

CodingSchemeIdSeq get_schemes_with_extensions();

• For HL7, might return:ISO:iso hl7 member/HL7/HL70001

ISO:iso hl7 member/UMLS/



• List all concept codes from the given coding scheme which are valid in this domain:ConceptInfoSeq get_extension_for_scheme(

in CodingSchemeId coding_scheme_id)

raises ( UnknownCodingScheme );

• Exampleget_extension_for_scheme(ISO:iso hl7 member/HL7/HL70001)

{M, “Male”}, {F, “Female”}, {O, “Other”}, {U, “Unknown”}

get_extension_for_scheme(ISO:iso hl7 member/UMLS/)

{C0024554, “male”}, { C0015780, “female}



• List all concept codes which are valid in this domain

QualifiedCodeInfoSeq get_all_extensions();

example:get_all_extensions()(ISO:iso hl7 member/HL7/HL70001)

{ISO:iso hl7 member/HL7/HL70001/M, “Male”},

{ISO:iso hl7 member/HL7/HL70001/F, “Female”},

{ISO:iso hl7 member/HL7/HL70001/O, “Other”},

{ISO:iso hl7 member/HL7/HL70001/U, “Unknown”}

{ISO:iso hl7 member/UMLS/C0024554, “male”},

{ISO:iso hl7 member/UMLS/C0015780, “female}



• Determine whether the given code is valid within the value domain:

boolean is_code_in_domain(in QualifiedCode qualified_code);

Example:

is_code_in_domain(ISO:iso hl7 member/HL7/HL70001/M)

returns TRUE


Translation

• Translate a code into text for a given context

IntlString get_preferred_text(in QualifiedCode a_qualified_code,

in UsageContextIdSeq context_ids

) raises ( UnknownCodingScheme, UnknownCode );

• Example:

get_preferred_text(“ISO:iso hl7 member/HL7/HL70001/M”, NULL)

would yield:

“Male”


Translation

• Find matching concept(s) for text

ConceptCodeSeq get_concepts_by_text( in string text);

Example:

get_concepts_by_text(“Male”)

would yield:

“M” (in the HL7 table 1 coding scheme)


Translation

• Quick aside - weighted resulttypedef float Weight;

struct WeightedResult {

ConceptInfo the_concept;

IntlString matching_text;

Weight the_weight;

};


Translation

• Match concepts by a regular expression stringvoid match_concepts_by_string(in IntlString match_string,

in unsigned long how_many,

out WeightedResultSeq weighted_results,

out WeightedResultsIter weighted_result_iter

) raises ( NotImplemented);


Translation

• Match concepts by ordered list of keywordsvoid match_concepts_by_keywords(

in OrderedIntlStringSeq keywords,

in unsigned long how_many,

out WeightedResultSeq weighted_results,

out WeightedResultsIter weighted_results_iter

) raises( NotImplemented);


Translation

• Translate concept codes between coding schemes

ConceptInfoSeq translate_code(in QualifiedCode from_qualified_code,

in CodingSchemeId to_coding_schemeId

) raises (UnknownCode,

UnknownCodingScheme,

TranslationNotAvailable);


“Meta”Terminology

• Value domains within LQSconst ValueDomainIdStr ASSOCIATION_VALUE_DOMAIN =

"IDL:omg.org/TerminologyService/AssociationId";

const ValueDomainIdStr ASSOCIATION_QUALIFIER_VALUE_DOMAIN =

"IDL:omg.org/TerminologyService/AssociationQualifierId";

const ValueDomainIdStr ASSOCIATION_BASE_TYPE_DOMAIN =

"IDL:omg.org/TerminologyService/AssociationBaseTypeId";

const ValueDomainIdStr LANGUAGE_VALUE_DOMAIN =

"IDL:omg.org/TerminologyService/LanguageId";

const ValueDomainIdStr LEXICAL_TYPE_VALUE_DOMAIN =

"IDL:omg.org/TerminologyService/LexicalTypeId";

const ValueDomainIdStr PRESENTATION_FORMAT_VALUE_DOMAIN =

"IDL:omg.org/TerminologyService/PresentationFormatId";


“Meta”Terminology

• Value domains within LQSconst ValueDomainIdStr SOURCE_VALUE_DOMAIN =

"IDL:omg.org/TerminologyService/SourceId";

const ValueDomainIdStr SOURCE_USAGE_DOMAIN =

"IDL:omg.org/TerminologyService/SourceUsageId";

const ValueDomainIdStr SYNTACTIC_TYPE_VALUE_DOMAIN =

"IDL:omg.org/TerminologyService/SyntacticTypeId";

const ValueDomainIdStr USAGE_CONTEXT_VALUE_DOMAIN =

"IDL:omg.org/TerminologyService/UsageContextId";


MetaTerminologyBootstrap problem

Interoperability entails using the same or at least compatible names for things

The first thing we nave to do is arrive at common names for coding schemes:

ICD-9? I9? IC9? UMLS SNOMED SMD

HL7 2.3 Table 1? USMarc Country Codes



• Looked at CEN ENV 1068 (Registration of Coding Schemes) - replaced by ISO 7826-1 & 7826-2

• Looked at ISO 7826 (Identification and Registration of Coding Schemes) - nice spec, but not funded



• Looked at ISO X3/L8 - Metadata registry

- Specification on the how and what of registration, but not actual registrar is (currently) outside of the scope

• ISO/TC154 - basic semantics registrar

• HL7? HISB? - Scope issues.


MetaTerminologyBootstrap Problem

Interim Solution: As there IS no formal registry, we will:

• Defer to HL7 codes when possible (IC9, UMLS)

• Use the OMG Interface Repository (IR) as the root: DNS:omg.org



• The HL7 Coding scheme is represented as:

DNS:hl7.omg.org

• We defer to HL7 when the coding scheme code is defined

DNS:ic9.hl7.omg.org

DNS:umls.hl7.omg.org



• And use OMG when it isn’t

DNS:usmarc.omg.org


Current State of Specification

• Published

• RTF is in place (but not active at the moment)

• Implementations occurring


Questions?

Snapshot of the OMG LQS Specification

Documents

Transcript of Snapshot of the OMG LQS Specification