1. CTS 2 Status Report Presentation to Ontology PSIG Dec 9, 2010

2. Outline Background and Approach Specification outline via. Compliance points Status

3. Background and Approach

4. CTS 2 Background Common Terminology Services Edition 2 Derived 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

5. 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 due Feb 21, 2011 – For March OMG meeting

6. CTS 2 General Requirements CTS Functionality (but not signatures) Ontology versioning and incremental update “Authoring” Data binding model (value sets / ISO 11179) Reasoning and inference

7. CTS 2 Additional Drivers and Requirements NCI/Mayo LexEVS compatibility Semantic Web / Ontology community buy-in BioPortal compatibility – RESTful compatible architecture Alignment w/ II4SM model – Reasoning – Z representation OMV alignment API4KB Alignment Addl: Phin VADS, HL7 MIF, IHE Implementations and Profiles (SVS)

8. Approach PIM – “Platform Independent Model”, mapped to multiple Platform Specific Models (PSMS): REST SOA(p) iRDF Specification – combination of UML, text and Z

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

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 process Decision was made to build CTS2 implementation on top of LexEVS vs changing core API RDF implementation pending in 2011 for NCBO

11. Before we get started Specification approach UML / text / Z (At the moment, Z is most current) Text and UML follow (or not) at varying rates Do I need to know Z to read it? – At the moment, it would help a lot but… – … the intent is that the text faithfully, clearly and accurately reflects what is said in the Z

12. Other details Z means LaTeX (more or less) Your faithful narrator is not a LaTeX expert, meaning that it tends to be odd, clumsy, etc. … any assistance would be greatly appreciated Browsing and authoring access is available online (!)

13. Compliance

14. 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]]

15. Compliance Resource Axis

16. 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)

17. 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)

18. 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 ???)

19. 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)

20. 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 (a)Need examples (b)Need mapping and mapping version for public health reporting (CDC notifiable conditions) – Anthrax  Lab tests (LOINC) and SCT Microorganism codes

21. Compliance Functional Axis

22. For a given resource: Get - return resource by identifier Search / Filter – directories w/ constraints Load / Export - from external sources and formats Incremental Update – change sets Authoring – construct change sets History – change history of a resource Service State – state of service at point in time Resource Specific

23. Compliance Functional Axis (cont) Resource Specific: Code System Version – Latest / tagged version for code system – Lookup by entity Association – Reasoning Service – Graph retrieval and navigation

24. Compliance Functional Axis (cont) Resource Specific: Value Set Definition – Latest / tagged definition for given value set – Resolve Value Set – Membership Inquiry

25. Compliance Functional Axis (cont) Resource Specific: Mapping Version – What is mapped / not mapped – (Beginning of) rule based mapping

26. Compliance Representation Axis

27. Resource Representation: XML JSON RDF (i)RDF Functional Representation: REST SOAP POJO

28. 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?

29. Compliance Structural Detail

30. Structural Detail 1)Traditional UML / XML Structure 2)Collection of Structured Statements -provenance, history, statement origin 3) (i)RDF - “cannonical” RDF rendering of statements w/o provenance, history

31. Status

32. Current Status Specification is still undergoing significant change Remaining faithful in spirit to the June submission Beginning to incorporate II4SM functionality (but not yet complete) Feb 21 deadline is still doable but very tight

33. 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 For next 2-3 weeks, online resource will be a “sausage factory”… then settling.

34. Notes Meaningful Use Vocabulary Task Force USHIK – contact (who?) DOA (Department of Agriculture) UMLS services – check w/ Jim Case VA DoD http://informatics.mayo.edu/cts2