Presentation is loading. Please wait.

Presentation is loading. Please wait.

Common Terminology Services 2 (CTS 2) Overview. WHY CTS2 CTS2 Overview.

Similar presentations


Presentation on theme: "Common Terminology Services 2 (CTS 2) Overview. WHY CTS2 CTS2 Overview."— Presentation transcript:

1 Common Terminology Services 2 (CTS 2) Overview

2 WHY CTS2 CTS2 Overview

3 Common Terminology Services 2 CTS 2 A standard for a shared semantic model and API for the query, interchange and update of terminological content. Terminological content: code sets, value sets, lexicons, thesauri, classification systems, ontologies, …

4 CTS2 Why? Terminological Resources (Ontologies, classification systems, code sets, value sets…) are the “semantic backbone” of information exchange Examples: ICD-9, ICD-10, MEDRA, Gene Ontology, SNOMED-CT, LOINC, UNSPSC, FMA, Agrovoc, Dublin Core, SKOS, RDF, OWL, ISO Language Codes, ISO Country Codes,...

5 CTS2 Why? … thousands of institution / application specific enumerations, code sets and value sets. Resources published in different formats… … using different grammars …. … with different update and release cycles...

6 CTS2 Why? Interoperability requires that information source and sink have the same set of shared “meaning”… … especially as many of these resources become “logic based” (aka. Declarative Programming)

7 CTS2 Goals Specify a common model of what is common amongst these resources Include metadata about what the resources are for, who publishes them, how often they are released Create mechanisms for federation, distribution, incremental update and history

8 CTS2 Goals Provide a bridge between the emerging Semantic Web community (RDF, SKOS, OWL, SPARQL) and structured models of information

9 PROCESS CTS2 Overview

10 CTS 2 Developed through the Healthcare Services Specification Project (HSSP) - a collaboration between Health Level 7 (HL7) and the Object Management Group HL7 provides the requirements as a Service Functional Model OMG develops the formal specification HL7 adopts and validates via an HL7 Implementation Guide

11 Healthcare Services Specification Project (HSSP) Workflow SFM HL7OMG Proposed Standard Vendor Community SFM RFP Beta Standard FTFFTF Final Standard Corrections / Clarifications HL7 Implementation Guide 4

12 Healthcare Services Specification Project (HSSP) Workflow SFM HL7OMG Proposed Standard Vendor Community SFM RFP Beta Standard FTFFTF Final Standard Corrections / Clarifications HL7 Implementation Guide 4 We Are Here…

13 CTS2 Beta Standard CTS2 is an Application Programming Interface (API) specification. It defines the semantics, syntax and valid interactions that can occur CTS2 is not software - it is a “blueprint” for building and using software If everyone follows the blueprint (and the blueprint is sufficiently precise) then CTS2 clients and services can interoperate

14 CTS2 Standard as a Blueprint CTS2 Clients CTS2 Services

15 Key Points Based on Representational State Transfer Architectural Paradigm Modular Implementation – build/use only what you need Resources Functionality Representation

16 Key Points (continued) Designed for distribution and federation Generic – NOT healthcare specific (!) Supports Semantic Web – RDF and OWL2 Not intended to be constraining Extensions are ok – in fact encouraged! Purpose is not to say what can be done, but rather to say how common things can be done consistently

17 QUICK GUIDE TO THE SPEC CTS2 Overview

18 Specification Components Platform Independent Model (PIM) Static specification Behavioral specification Platform Specific Models (PSMs) Representation Method Signatures

19 Platform Independent Model Static Specification UML Class Diagrams – classes, attributes and associations (no methods) Textual Description – what each element means, where it came from, etc. Value Sets and Bindings – valid (or recommended) codes and URI’s that can be used (via CTS2!) to get their meanings Invariants – what is always true about a CTS2 resource

20 UML Model

21 Textual Description Invariants

22 Concept Domains

23 Platform Independent Model Behavioral Specification UML Method Signatures – inputs and outputs Textual Description – what the function does, what the inputs mean Preconditions – what must be true before for the function call to apply Postconditions – what must be true after the function call occurs Exceptions – how precondition failures are reported

24 Signatures

25 Description, pre and post conditions And exceptions

26 Platform Specific Models Consist of platform specific mapping of Information Model – example, HTTP REST and SOAP both use XML Schema Computational Model – HTTP REST uses URI rules, SOAP uses interface signatures

27 XML Schema

28 WADL (for REST)

29 CONFORMANCE POINTS CTS2 Overview

30 CTS2 Conformance Philosophy “Linear Value Proposition” (as described by Charlie Meade) – easy things are easy and complexity is proportional to gain Implement (or use) exactly what is needed Resources Functionality Representation

31 CTS 2 Resource profiles Code System Catalog Entry Code System Version Entity Description Association Map Catalog Entry Map Version Value Set Catalog Entry Value Set Definition Concept Domain Catalog Concept Domain Binding Statement

32 CTS2 Conformance Points Behavioral Perspective Read – direct access Query – search and discovery Import/Export – external formats Update – incremental update History – change history Temporal – state of service at point in time Maintenance – construct incremental updates

33 CTS2 Conformance Points Representational Perspective XML XML Schema ISO * JSON RDF * POJO * * Not present in Beta 1.0 Specification

34 CTS2 SDK CTS2 Overview

35 CTS2 What Isn’t Specified The programming language and platform. What sort of database(s) and storage CTS2 is implemented against How existing terminological resources are represented in CTS2 (!!!)

36 CTS2 SDK Under development by Mayo Clinic Uses Model View Controller (MVC) architectural pattern

37 CTS2 SDK “View” Component Implements the static portion of the CTS2 model CodeSystemCatalogEntry, … (Indirectly) enforces some invariants

38 CTS2 SDK “Controller” Component Implements the behavioral portion of the CTS2 model Accepts events Validates invariants Enforces preconditions

39 CTS2 SDK “Model” Component Transforms View (CTS2 PIM) structures into state (aka “backing store”) Enforces post-conditions May also enforce some invariants

40 CTS2 SDK A MVC architecture that is compliant with the CTS2 API specification Can be used to Implement against different back ends (e.g. RDF, SQL, existing terminology structures or API’s) Specify and/or create different import and export maps (IHTSDO, OWL, …)

41 CTS2 SDK Can be used to (continued) Implement new views (21090, cRDF, …) Extend the controller with business rules and workflow constraints

42

43 IMPLEMENTATION GUIDES CTS2 Overview

44 What the CTS2 Specification does NOT do Specify how CTS2 content will be represented in a backing store Specify how various terminology models and formats are imported and exported Specify how specific terminology workflow and business rules are realized in a CTS2 service

45 CTS2 Implementation Guide States how content and structure of a terminological resource maps to the CTS2 information model Could be for import/export Could also appy to backing store Identifies terminology specific business rules that services must enforce Aligns CTS2 w/ organiation workflow Identifies any extensions to CTS2 specific to the given terminology

46 CURRENT STATE AND NEXT STEPS CTS2 Overview

47 Current State CTS2 Specification CTS2 PIM / HTTP REST PSM and SOAP PSM voted in as standard OMG FTF - Finalization Task Force Pending Waiting on OMG Technical Issues Focus will be on errors and clarification (finish Z, much more documentation)

48 Current State CTS2 SDK First version of CTS2 SDK is written and running Doesn’t cover all of the spec Sections prototyped against BioPortal, eXist and (pending) LexEVS First public release targeted for week of September 12

49 Current State CTS2 Implementation Guides IHTSDO (SNOMED-CT) has formed a group to develop the SNOMED-CT CTS2 Implementation Guide Target draft document Mar 2012 Talking to HL7 about a HL7 CTS2 Implementation Guide Targeting RDF/OWL implementation guide middle of 2012

50 Current State - host web page, but needs a lot of work Top priority for Mayo CTS2 team Will include examples, more details, etc.


Download ppt "Common Terminology Services 2 (CTS 2) Overview. WHY CTS2 CTS2 Overview."

Similar presentations


Ads by Google