1. HL7 Central Terminology Services

2. Agenda Design Principles Proposal for Generic API Follow-up Plan

3. 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

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

5. 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.

6. 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

7. The design of HL7 CTS shall be formal and concise No Comments

8. 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.

9. 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

10. 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

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

12. 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

13. Initial Proposal Concept Descriptor Attribute Set Get Concepts Query Search Concepts Query Get Values Query Concept Result Set Value Result Set

14. Concept Descriptor Terminology System ID Terminology System Version Concept ID Optionally, Terminology System ID or Terminology System Version can be set to a wildcard

15. 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

16. 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 –...

17. Search Concepts Query Paramaters –TerminologySystemID[] terminologiesToSearch –AttributeSet attributesToSearch –AttributeSet attributesToFetch –String searchString

18. Get Values Query Paramaters –ConceptDescriptor conceptToQuery –Attribute valuesToReturn Note, this query also can perfom –getParents –getChildren –...

19. Concept Result Set …... …...

20. Value Result Set … … … … …...

21. Next Steps?