1. ITI Infrastructure - Wednesday November 7th, 20071 IHE IT infrastructure “Terminology Sharing” Christel Daniel (AP-HP, INSERM, Paris), Ana Esterlich (GIP-DMP), François Gareil (Thales), Charles Rica (GIP DMP), Karima Bourquard (GMSIH), Jean Delahousse (Mondeca), Pierre Zweigenbaum (LIMSI, CNRS) CNRSGIP-DMPINSERM

2. ITI Infrastructure - Wednesday November 7th, 20072 Context Existing de facto clinical information systems  Heterogeneous data, much of them still narrative information. “Systems that have to share and exploit clinical data have to share/understand also well defined and unambiguous knowledge of the meaning of these data”.  Accessing and utilizing shared terminological resources are a common and necessary function for many healthcare IT applications. New generation of Clinical Information Systems (HIS, EHR, personal EHR) have to make use of health informatics knowledge representation contributions  Biomedical ontologies (e.g OBO foundry, SNOMED-CT)  Domain content models (such as HL7 RIM or CDA r2 based models or CEN archetypes).

3. ITI Infrastructure - Wednesday November 7th, 20073 Goal Semantic interoperability  Structured clinical information Share and update pick lists for coded concepts  Narrative clinical information Share lexical resources for Natural Language Processing applications Connecting clinical data with medical knowledge (e.g. published medical literature and clinical guidelines and decision support systems Semantic mining

4. ITI Infrastructure - Wednesday November 7th, 20074 Terminology Server Terminology Provider IT applications e.g SNOMED CT IHT SDO Synchronization issues : between Terminology Provider/Terminology Server/Terminology User (terminology enabled IT applications) e.g APHP TS or national pEHR TS e.g APHP EHR

5. ITI Infrastructure - Wednesday November 7th, 20075 National TS International TS e.g NCI Thesaurus e.g UMLS Local TS e.g La Charité OpenSC TS National TS e.g French NCI TS National TS e.g French pEHR TS International Terminology Provider National Terminology Provider Local TS e.g APHP Paris TS Local TS e.g SNOMED CT IHT SDO e.g LOINC e.g Rennes TS e.g Strasbourg TS e.g ADICAP Synchronization issues : between Terminology Servers International TS e.g EURO-Telepath TS Regional TS e.g Castilla de la Mancha TS FRANCE SPAIN GERMANY

6. ITI Infrastructure - Wednesday November 7th, 20076 Objectives of the IHE working group 1 – State of the Art : Terminology Services  To evaluate how the relevancy of the Service Functional Model of the CTS version 2 could in the context of both EHR/HIS indexation and personal EHR indexation. 2 - To identify main business scenarios to be implemented at first within a IHE integration profile for 2008  Integration Profile “Value Sets Sharing” for Domain Content Model indexation 3 - Define further functionalities  Synchronizing local/regional/national Terminology Servers  Indexing narrative document of EHR  Taking into account local terms and/or interface terminologies,  White Paper : “Terminology Sharing”

7. ITI Infrastructure - Wednesday November 7th, 20077 CTS 2/ CTS 1: The reason why the service is necessary ? HL7 Common Terminology Services (CTS I) describes a set of API calls that represent the core functionality that will be needed by basic HL7 Version 3 applications to manage and access “ Code Systems” (terminologies).  Has begun to be adopted by organizations (Mayo Clinic). BUT  Avoid issues related to terminology distribution and versioning.  Value set, or sub-setting section of CTS : static value sets  CTS fails to address many of the issues that are required for a truly interoperable “semantics of terminology. It is often necessary to implement CTS 1 APIs specific to the target source terminology being accessed. CTS 2 : “will be a commonly accepted standard for terminology services : specification for sub-setting and mapping, terminology distribution, authoring, versioning, and classification.”

8. ITI Infrastructure - Wednesday November 7th, 20078 CTS 2 part of the Healthcare Services Specification Project (HSSP) Joint endeavor between HL7 & OMG  HL7 (HL7 Service Oriented Architecture group (SOA SIG) of the Electronic Health Record Technical Committee (EHR TC))  Object Management Group (OMG Healthcare Domain Task Force (HDTF). organizations. Objectives  facilitate the development of a set of implementable interface standards supporting agreed-upon services specifications  stimulate the adoption and use of standardized “plug-and-play” services by healthcare software product vendors. HL7 : identifying functional requirements, information needs, and conformance criteria -> Service Functional Model (SFM) for each HSSP service OMG : uses the SFM to develop a “Request for Proposal” (OMG RFPs) specify the technical requirements of a service (Service Technical Model (STM)).

9. ITI Infrastructure - Wednesday November 7th, 20079 CTS 2 Service Functional Model Business scenarios

10. ITI Infrastructure - Wednesday November 7th, 200710 White Paper TS : Objectives (1/2) Extends the Integration Profile “Sharing Value Sets" Distributing existing Terminology (Code Systems)  How existing terminological resources (Code Systems)are distributed to terminology enabled IT applications)  How Concept codes are distributed to IT applications for efficient use of Natural Processing Language (NLP) algorithms Terminology correction or authoring  How Terminology (Code Systems) users define and distribute local codes in addition to existing Code Systems  “How Terminology (Code Systems) users submit unambiguous requests for corrections and extensions to Terminology providers (e.g SNOMED CT IHT SDO)and how revisions to content are identified, distributed and integrated into running systems"

11. ITI Infrastructure - Wednesday November 7th, 200711 White Paper TS : Objectives (2/2) Extends the Integration Profile “Sharing Value Sets" Defining, updating and distributing Value Sets  How mapping between terminological resources (Code Systems) and data model (e.g. CDA r2-based templates or DICOM objects) are defined and revised Defining and distributing Terminology mappings  How mapping between existing terminological resources (Code Systems) are defined, distributed and revised

12. ITI Infrastructure - Wednesday November 7th, 200712 1) Integrating Terminology Providers and terminology servers A Terminology Provider (using a Terminology Creator Source) distribute terminological resources (Code Systems) to a Terminology Administrator in charge of terminology server (Terminology Repositories/Registries). Terminology Repository/Registry Terminology Creator Source Terminology Server e.g APHP TS or national pEHR TS Terminology Provider e.g SNOMED CT IHT SDO

13. ITI Infrastructure - Wednesday November 7th, 200713 Terminology servers Terminology « Expert » Users  Author and cure Terminologies  Author Value Sets  Author Mappings Terminology Repository/Registry Terminology Source Value Sets Source Mapping Source

14. ITI Infrastructure - Wednesday November 7th, 200714 2) Integrating terminology servers and terminology enabled IT applications Terminology Administrators of terminology servers (Terminology/Mapping/Value Sets Repositories/Registries) distribute updated inter-related Code Systems and Value Sets to Terminology Users using IT applications (Terminology Consumers). Terminology/ValueSets/ Mapping Repository/Registry Terminology Consumer Terminology Server e.g APHP TS or national pEHR TS IT application e.g APHP EHR

15. ITI Infrastructure - Wednesday November 7th, 200715 3) Integrating different terminology servers Terminology Administrators of terminology server A (Terminology Source, Mapping Source, Value Sets Source) distribute Value Sets, Mappings and other extension to existing Code Systems to Terminology Administrators of terminology server B (Terminology/Mapping/Value Sets Repositories/Registries) Terminology/ValueSets/ Mapping Repository/Registry Terminology Server B e.g APHP TS Terminology/ValueSets/ Mapping Repository/Registry Terminology Server A e.g national pEHR TS