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

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

Embed Size (px)

Citation preview

CTS2

Status ReportPresentation to HL7 Vocab WG

Jan 11, 2011Harold Solbrig

Mayo Clinic

© Copyright 2011, Mayo Clinic 2

Outline

• Background and Approach• Specification outline via. Compliance points• Status

1/10/2011

© Copyright 2011, Mayo Clinic 3

Background and Approach

1/10/2011

© Copyright 2011, Mayo Clinic 4

CTS2

BackgroundCommon Terminology Services Edition 2Evolved 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/2011

© Copyright 2011, Mayo Clinic 5

CTS2

Brief HistoryWorking 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/2011

© Copyright 2011, Mayo Clinic 6

CTS2

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/2011

© Copyright 2011, Mayo Clinic 7

CTS2

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/2011

© Copyright 2011, Mayo Clinic 8

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/2011

© Copyright 2011, Mayo Clinic 9

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/2011

© Copyright 2011, Mayo Clinic 10

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 processDecision was made to build CTS2

implementation on top of LexEVS vs changing core API

1/10/2011

© Copyright 2011, Mayo Clinic 11

Before we get started

Specification approachUML / 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/2011

© Copyright 2011, Mayo Clinic 12

PDF Example

1/10/2011

© Copyright 2011, Mayo Clinic 13

Compliance

1/10/2011

© Copyright 2011, Mayo Clinic 14

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/2011

© Copyright 2011, Mayo Clinic 15

ComplianceResource Axis

1/10/2011

© Copyright 2011, Mayo Clinic 16

ComplianceResource 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/2011

© Copyright 2011, Mayo Clinic 17

ComplianceResource 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/2011

© Copyright 2011, Mayo Clinic 18

ComplianceResource 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/2011

© Copyright 2011, Mayo Clinic 19

ComplianceResource 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/2011

© Copyright 2011, Mayo Clinic 20

ComplianceResource 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

Zed.sty

1/10/2011

© Copyright 2011, Mayo Clinic 21

ComplianceFunctional Axis

1/10/2011

© Copyright 2011, Mayo Clinic 22

ComplianceFunctional 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/2011

© Copyright 2011, Mayo Clinic 23

ComplianceRepresentation Axis

1/10/2011

© Copyright 2011, Mayo Clinic 24

ComplianceRepresentation Axis

Resource Representation:• XML• JSON• RDF• (i)RDFTarget Functional Representations:• Web XML (aka. “REST”)• SOAP – interesting question of service (verbs) vs. REST via

Web Services• POJO

1/10/2011

© Copyright 2011, Mayo Clinic 25

ComplianceRepresentation 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/2011

© Copyright 2011, Mayo Clinic 26

ComplianceStructural Detail

1/10/2011

© Copyright 2011, Mayo Clinic 27

Structural Detail

1) Traditional UML / XML Structure2) Collection of Structured Statements

- Resource predicate target- Provenance, modifiers, …

3) (i)RDF- “cannonical” RDF rendering of statements w/o provenance, history

1/10/2011

© Copyright 2011, Mayo Clinic 28

Status

1/10/2011

© Copyright 2011, Mayo Clinic 29

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/2011

© Copyright 2011, Mayo Clinic 30

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/2011

© Copyright 2011, Mayo Clinic 31

Some Notes on Process

• OMG process is “pay to contribute”• Submitters ok w/ external review, tire-kicking,

trial implementation, etc.

1/10/2011

© Copyright 2011, Mayo Clinic 32

Model Walkthrough

1/10/2011

© Copyright 2011, Mayo Clinic 33

RESTful Implementation

1/10/2011

© Copyright 2011, Mayo Clinic 341/10/2011

© Copyright 2011, Mayo Clinic 351/10/2011

© Copyright 2011, Mayo Clinic 361/10/2011

© Copyright 2011, Mayo Clinic 371/10/2011