1. Common Terminology Services 2 (CTS2)
Overview

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.