HL7 Central Terminology Services. Agenda Design Principles Proposal for Generic API Follow-up Plan.

HL7 Central Terminology Services

Agenda

• Design Principles

• Proposal for Generic API

• Follow-up Plan

Design Principles

• Sent to the Vocabulary Listserver

• Gunther had general comments and questions, but no specific suggestions for revision

• Others sent specific suggestions for revision to me, but not to the list

HL7 CTS shall be straightforwardly usable within HL7 version 3 XML environments.

• No Comments

It shall be easy to write programs which use HL7 CTS.

• Easy to use? Sort of a nice way of saying that the TQS design was less than optimal, ease of use should follow from good design.

The number of optional features in HL7 CTS is to be kept to the

absolute minimum, ideally zero.

• Replace the design point regarding optional features with a statement that the intent of the CTS spec is to specify core services

The design of HL7 CTS shall be formal and concise

• No Comments

HL7 CTS queries and results must be expressible as XML documents.

• Reposition the XML design points as another layer of the architecture... Use of XML is more an implementation issue. Nice to address this, but will certainly flow out of the core model and core services.

HL7 CTS shall be compatible with the nomenclature, model and approach expressed in the HL7 Vocabulary document, the version 3 RIM and its derivative structures.

• No Comments

Whenever possible, the HL7 CTS shall remain a consistent subset of the CorbaMed Terminology Query Services (TQS) provided that the TQS terminology model does not conflict with other HL7 CTS design principles. If it is discovered that the TQS model is conflicting with HL7 CTS design principles or is incomplete, or incorrect, good faith efforts should be made to notify the appropriate OMG Revision Task Force.

• No Comments

HL7 CTS should limit the assumptions about the form and structure of a terminology to those necessary to support HL7 implementations.

• No Comments

API Requests

• The query should specify whether the return set is merely concept id's, partial or complete concepts, etc.

• Should query along any attribute of the concept model

• All queries return a set of concepts

• Support logical combinations and expressions

Initial Proposal

• Concept Descriptor

• Attribute Set

• Get Concepts Query

• Search Concepts Query

• Get Values Query

• Concept Result Set

• Value Result Set

Concept Descriptor

• Terminology System ID

• Terminology System Version

• Concept ID

• Optionally, Terminology System ID or Terminology System Version can be set to a wildcard

Attribute Set

• Predefined Attributes– SuperConcepts

– DirectSuperConcepts

– SubConcepts

– DirectSubConcepts

– PreferredName

• Terminology specific attributes– Fully Specified Name

– Scope Note

– Exact ICD Map

– Narrow to Broad Map

– Broad to Narrow Map

Get Concepts Query

• Paramaters– AttributeSet attributesToFetch– ConceptDescriptor[] conceptsToFetch

• This query can be optimized for particular functions (e.g. populating a browser) and replaces the need for functions such as:– getParents– getChildren– ...

Search Concepts Query

• Paramaters– TerminologySystemID[] terminologiesToSearch– AttributeSet attributesToSearch– AttributeSet attributesToFetch– String searchString

Get Values Query

• Paramaters– ConceptDescriptor conceptToQuery– Attribute valuesToReturn

• Note, this query also can perfom– getParents– getChildren– ...

Concept Result Set<ConceptResultSet>

<TerminologySystem ID=123><version>

<concept ID=abc><attribute><value>…<concept ID=def><attribute><value>...

<\version><\TerminologySystem><TerminologySystem ID=234>

<version><concept ID=hij><attribute><value>…

...</ConceptResultSet>

Value Result Set

<ValueResultSet><value>…<\value><value>…<\value><value>…<\value><value>…<\value><value>…<\value>

...</ValueResultSet>

Next Steps?