CTS 2 Status Report Presentation to HL7 Vocab WG Jan 11, 2011 Harold Solbrig Mayo Clinic

Outline Background and Approach Specification outline via. Compliance points Status 1/10/20112© Copyright 2011, Mayo Clinic

Background and Approach 1/10/20113© Copyright 2011, Mayo Clinic

CTS 2 Background Common Terminology Services Edition 2 Evolved from: OMG LQS Specification (1999) – OO Model, read only, but laid most of the groundwork HL7 CTS Specification (2004) – ANSI and ISO Standard – SOA Model, read only, reduced scope from LQS 1/10/20114© Copyright 2011, Mayo Clinic

CTS 2 Brief History Working through the HSSP Process Issued by HL7 as a SFM Fall 2009 RFP issued by OMG 2010 Preliminary submissions June 2010 – Mayo – II4SM Final submissions (currently) due Feb 21, 2011 – For March OMG meeting 1/10/20115© Copyright 2011, Mayo Clinic

CTS 2 General Requirements CTS Functionality (but not signatures) Ontology versioning and incremental update “Authoring” Data binding model (HL7 value sets / ISO 11179) Reasoning and inference 1/10/20116© Copyright 2011, Mayo Clinic

CTS 2 Additional Drivers and Requirements NCI/Mayo LexEVS compatibility Semantic Web / Ontology community buy-in BioPortal compatibility – RESTful compatible architecture II4SM Model – Reasoning – Z representation OMV alignment API4KB Alignment IHTSDO Alignment Addl: Phin VADS, HL7 MIF, IHE Implementations and Profiles (SVS) 1/10/20117© Copyright 2011, Mayo Clinic

Approach PIM – “Platform Independent Model”, mapped to multiple Platform Specific Models (PSMS): REST SOA(p) iRDF Specification – combination of UML, text and Z 1/10/20118© Copyright 2011, Mayo Clinic

Challenges What, exactly is a PIM? How do we create one model that aligns with REST (our primary target), SOA(p), RDF minimalists and POJO? No easy answers, but Z specification seems to help considerably 1/10/20119© Copyright 2011, Mayo Clinic

Other Challenges LexEVS – built, runs and already incorporates a significant portion of what is in the requirements LexEVS (XML / POJO) to PIM is a non-trivial transformation Reproducible behavior is a non-trivial process Decision was made to build CTS2 implementation on top of LexEVS vs changing core API 1/10/201110© Copyright 2011, Mayo Clinic

Before we get started Specification approach UML / text / Z – UML provides structure – Z provides invariants, preconditions, postconditions (behavioral semantics) – Text describes structural components and restates Z in formal text Do I need to know Z to read it? – No, but the Z is normative and can be used when text is unclear 1/10/201111© Copyright 2011, Mayo Clinic

PDF Example 1/10/201112© Copyright 2011, Mayo Clinic

Compliance 1/10/201113© Copyright 2011, Mayo Clinic

Compliance Resource orientation provides fine-grained implementation / compliance points Resource Axis – Which resources are represented by the service Functional Axis - What functionality the service provides Representational Axis – How the resources are represented Structural Detail – Structured [+ “semi”-structured + [RDF]] 1/10/201114© Copyright 2011, Mayo Clinic

Compliance Resource Axis 1/10/201115© Copyright 2011, Mayo Clinic

Compliance Resource Axis Service provider can implement any combination of: Code System – metadata about code system (ontology) purpose, provider, release cycle, etc. (rdf:type skos:ConceptSystem or Owl:Ontology) Code System Version – metadata about a collection of statements (ontology). (rdf:type skos:ConceptSystem or Owl:Ontology) 1/10/201116© Copyright 2011, Mayo Clinic

Compliance Resource Axis (cont) Entity – structured assertions about classes / individuals and/or predicates. (rdf:type skos:Concept, owl:Class, owl:Individual, rdf:Predicate) Association – metadata about a collection of statements about Entities (rdf:type rdf:Statement where rdf:subject type Entity) 1/10/201117© Copyright 2011, Mayo Clinic

Compliance Resource Axis (cont) Value Set – metadata about set of entity references. (rdf:type iso11179:EnumeratedConceptDomain) Value Set Definition – rules for constructing a value set. (rdf:type ???) Value Set Resolution Rule - rules for applying a value set definition in a particular context. (rdf:type ???) 1/10/201118© Copyright 2011, Mayo Clinic

Compliance Resource Axis (cont) Concept Domain – metadata about the scope, purpose, etc. of a data element concept (rdf:type iso11179:DataElementConcept) Concept Domain Binding – contextual association between a concept domain and a value set. (rdf:type iso11179:DataElement) 1/10/201119© Copyright 2011, Mayo Clinic

Compliance Resource Axis (cont) Mapping – metadata about a set of relationships between classes, roles and/or individuals in two or more ontologies Mapping Version – collection of relationships for a mapping at a given point in time Mapping Entry – an assertion about how a source entity maps to one or more targets 1/10/201120© Copyright 2011, Mayo Clinic

Compliance Functional Axis 1/10/201121© Copyright 2011, Mayo Clinic

Compliance Functional Axis For a given resource: Read - return resource by identifier Query – directories w/ constraints Authoring – construct change sets Import / Export - from external sources and formats Incremental Update – load change sets History – change history of a resource Temporal – state of service at point in time Resource Specific – advanced association services, etc. 1/10/201122© Copyright 2011, Mayo Clinic

Compliance Representation Axis 1/10/201123© Copyright 2011, Mayo Clinic

Compliance Representation Axis Resource Representation: XML JSON RDF (i)RDF Target Functional Representations: Web XML (aka. “REST”) SOAP – interesting question of service (verbs) vs. REST via Web Services POJO 1/10/201124© Copyright 2011, Mayo Clinic

Compliance Representation Axis Still an outstanding issue on granularity PIM is (more or less) agnostic when it comes to granularity… … invariants / preconditions / postconditions are the same whether you lump or split the operations SOA / REST granularity can be choreographed … so how far do we need to go? 1/10/201125© Copyright 2011, Mayo Clinic

Compliance Structural Detail 1/10/201126© Copyright 2011, Mayo Clinic

Structural Detail 1)Traditional UML / XML Structure 2)Collection of Structured Statements -Resource predicate target -Provenance, modifiers, … 3) (i)RDF - “cannonical” RDF rendering of statements w/o provenance, history 1/10/201127© Copyright 2011, Mayo Clinic

Status 1/10/201128© Copyright 2011, Mayo Clinic

Current Status Specification is still undergoing significant change Remaining faithful in spirit to the June submission UML model is approaching a (relative) steady state Z and document are undergoing a major restructuring – targeting week of Jan 17 for new publication available Will be discussing Feb 21 deliverable w/ external drivers Feedback vs. Availability There may be a workable compromise 1/10/201129© Copyright 2011, Mayo Clinic

Status Fundamental Model and Functionality remains consistent with first submission(s) Work continues on: – Refactoring and refinement: each community has its own needs and “non-negotiables” – Naming: each community has its own names – Formal semantics: a precise specification is a lot of work. 1/10/201130© Copyright 2011, Mayo Clinic

Some Notes on Process OMG process is “pay to contribute” Submitters ok w/ external review, tire-kicking, trial implementation, etc. 1/10/201131© Copyright 2011, Mayo Clinic

Model Walkthrough 1/10/201132© Copyright 2011, Mayo Clinic

RESTful Implementation 1/10/201133© Copyright 2011, Mayo Clinic

1/10/201134© Copyright 2011, Mayo Clinic

1/10/201135© Copyright 2011, Mayo Clinic

1/10/201136© Copyright 2011, Mayo Clinic

1/10/201137© Copyright 2011, Mayo Clinic