3Common 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, …
4CTS2 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, ...
5CTS2 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...
6CTS2 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)
7CTS2 GoalsSpecify 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
8CTS2 GoalsProvide a bridge between the emerging Semantic Web community (RDF, SKOS, OWL, SPARQL) and structured models of information
10CTS2Developed through the Healthcare Services Specification Project (HSSP) - a collaboration between Health Level 7 (HL7) and the Object Management GroupHL7 provides the requirements as a Service Functional ModelOMG develops the formal specificationHL7 adopts and validates via an HL7 Implementation Guide
13CTS2 Beta StandardCTS2 is an Application Programming Interface (API) specification.It defines the semantics, syntax and valid interactions that can occurCTS2 is not software - it is a “blueprint” for building and using softwareIf everyone follows the blueprint (and the blueprint is sufficiently precise) then CTS2 clients and services can interoperate
14CTS2 Standard as a Blueprint CTS2 ClientsCTS2 Services
15Key PointsBased on Representational State Transfer Architectural ParadigmModular Implementation – build/use only what you needResourcesFunctionalityRepresentation
16Key Points (continued) Designed for distribution and federationGeneric – NOT healthcare specific (!)Supports Semantic Web – RDF and OWL2Not intended to be constrainingExtensions 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
18Specification Components Platform Independent Model (PIM)Static specificationBehavioral specificationPlatform Specific Models (PSMs)RepresentationMethod Signatures
19Platform 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 meaningsInvariants – what is always true about a CTS2 resource
23Platform Independent Model Behavioral Specification UML Method Signatures – inputs and outputsTextual Description – what the function does, what the inputs meanPreconditions – what must be true before for the function call to applyPostconditions – what must be true after the function call occursExceptions – how precondition failures are reported
25Description, pre and post conditions And exceptions
26Platform Specific Models Consist of platform specific mapping ofInformation Model – example, HTTP REST and SOAP both use XML SchemaComputational Model – HTTP REST uses URI rules, SOAP uses interface signatures
30CTS2 Conformance Philosophy “Linear Value Proposition” (as described by Charlie Meade) – easy things are easy and complexity is proportional to gainImplement (or use) exactly what is neededResourcesFunctionalityRepresentation
31CTS2 Resource profiles Code System Catalog Entry Code System Version Entity DescriptionAssociationMap Catalog EntryMap VersionValue Set Catalog EntryValue Set DefinitionConcept Domain CatalogConcept Domain BindingStatementThere 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.
32CTS2 Conformance Points Behavioral Perspective Read – direct accessQuery – search and discoveryImport/Export – external formatsUpdate – incremental updateHistory – change historyTemporal – state of service at point in timeMaintenance – construct incremental updatesWhile 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.
33CTS2 Conformance Points Representational Perspective XMLXML SchemaISO 21090*JSONRDF*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
35CTS2 What Isn’t Specified The programming language and platform.What sort of database(s) and storage CTS2 is implemented againstHow existing terminological resources are represented in CTS2 (!!!)CTS2 is language and platform neutral.
36CTS2 SDK Under development by Mayo Clinic Uses Model View Controller (MVC) architectural pattern
37CTS2 SDK “View” Component Implements the static portion of the CTS2 modelCodeSystemCatalogEntry, …(Indirectly) enforces some invariants
38CTS2 SDK “Controller” Component Implements the behavioral portion of the CTS2 modelAccepts eventsValidates invariantsEnforces preconditions
39CTS2 SDK “Model” Component Transforms View (CTS2 PIM) structures into state (aka “backing store”)Enforces post-conditionsMay also enforce some invariants
40CTS2 SDKA MVC architecture that is compliant with the CTS2 API specificationCan be used toImplement 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, …)
41CTS2 SDK Can be used to (continued) Implement new views (21090, cRDF, …)Extend the controller with business rules and workflow constraints
44What the CTS2 Specification does NOT do Specify how CTS2 content will be represented in a backing storeSpecify how various terminology models and formats are imported and exportedSpecify how specific terminology workflow and business rules are realized in a CTS2 service
45CTS2 Implementation Guide States how content and structure of a terminological resource maps to the CTS2 information modelCould be for import/exportCould also appy to backing storeIdentifies terminology specific business rules that services must enforceAligns CTS2 w/ organiation workflowIdentifies any extensions to CTS2 specific to the given terminology
46Current State and Next Steps CTS2 OverviewCurrent State and Next Steps
47Current State CTS2 Specification CTS2 PIM / HTTP REST PSM and SOAP PSM voted in as standardOMG FTF - Finalization Task Force PendingWaiting on OMG Technical IssuesFocus will be on errors and clarification (finish Z, much more documentation)
48Current State CTS2 SDKFirst version of CTS2 SDK is written and runningDoesn’t cover all of the specSections prototyped against BioPortal, eXist and (pending) LexEVSFirst public release targeted for week of September 12
49Current State CTS2 Implementation Guides IHTSDO (SNOMED-CT) has formed a group to develop the SNOMED-CT CTS2 Implementation GuideTarget draft document Mar 2012Talking to HL7 about a HL7 CTS2 Implementation GuideTargeting RDF/OWL implementation guide middle of 2012
50Current State- host web page, but needs a lot of workTop priority for Mayo CTS2 teamWill include examples, more details, etc.