Presentation on theme: "HL7 Central Terminology Services. Agenda Design Principles Proposal for Generic API Follow-up Plan."— Presentation transcript:
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 –...