Presentation is loading. Please wait.

Presentation is loading. Please wait.

Common Terminology Services 2 (CTS2)

Similar presentations

Presentation on theme: "Common Terminology Services 2 (CTS2)"— Presentation transcript:

1 Common Terminology Services 2 (CTS2)

2 CTS2 Overview Why CTS2

3 Common Terminology Services 2 CTS2
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 CTS2 Overview Process

10 CTS2 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
HL7 OMG Vendor Community 1 SFM SFM 2 RFP Proposed Standard 3 Beta Standard FTF 4 4 HL7 Implementation Guide Corrections / Clarifications Final Standard 5

12 Healthcare Services Specification Project (HSSP) Workflow
HL7 OMG Vendor Community 1 We Are Here… SFM SFM 2 RFP Proposed Standard 3 Beta Standard FTF 4 4 HL7 Implementation Guide Corrections / Clarifications Final Standard 5

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 CTS2 Overview Quick Guide to the Spec

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 CTS2 Overview Conformance Points

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 CTS2 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 There are no dependencies between the various resources named above. Code System Version contains the URI of the Code System that it is a version of and, if the service supports it or is aware of a service that supports it, the URL of the catalog that it is a member of, but has no knowledge of code system catalog entries beyond that. Each resource can be implemented independently as needed.

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 While there are minor dependencies – Maintenance, for instance, would be of little use without Update, the functions above can be implemented as needed. A service might provide read access to a code system catalog, read and query to entities and import/export/update/history for map versions.

33 CTS2 Conformance Points Representational Perspective
XML XML Schema ISO 21090* JSON RDF* POJO* Services can interchange resource data in a variety of different formats – again, as needed. The PIM invariants determine what must be present in any resource rendering – the formats can vary as needed. * Not present in Beta 1.0 Specification

34 CTS2 Overview CTS2 SDK

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 (!!!) CTS2 is language and platform neutral.

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


43 Implementation Guides
CTS2 Overview Implementation Guides

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 Current State and Next Steps

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 (CTS2)"

Similar presentations

Ads by Google