1 / 50

Common Terminology Services 2 (CTS 2)

Common Terminology Services 2 (CTS 2). Overview. CTS2 Overview. Why CTS2. Common Terminology Services 2 CTS 2. A standard for a shared semantic model and API for the query, interchange and update of terminological content.

dore
Download Presentation

Common Terminology Services 2 (CTS 2)

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Common Terminology Services 2 (CTS2) Overview

  2. CTS2 Overview Why CTS2

  3. Common Terminology Services 2CTS2 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. CTS2Why? 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. CTS2Why? … 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. CTS2Why? 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. CTS2Goals 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. CTS2Goals 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 SFM 4 2 1 4 5 3 SFM RFP Proposed Standard Beta Standard FTF HL7 Implementation Guide Corrections / Clarifications Final Standard

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

  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 - itis 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 ModelStatic 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 ModelBehavioral 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

  32. CTS2 Conformance PointsBehavioral 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 PointsRepresentational Perspective • XML • XML Schema • ISO 21090* • JSON • RDF* • POJO* * Not present in Beta 1.0 Specification

  34. CTS2 Overview CTS2 SDK

  35. CTS2What 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. CTS2 Overview Implementation Guides

  43. What the CTS2 Specificationdoes 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

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

  45. CTS2 Overview Current State and Next Steps

  46. Current StateCTS2 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)

  47. Current StateCTS2 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

  48. Current StateCTS2 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

  49. Current State • http://informatics.mayo.edu/cts2 - host web page, but needs a lot of work • Top priority for Mayo CTS2 team • Will include examples, more details, etc.

More Related