Query Health Concept-to-Codes (C2C) SWG Meeting #7 January 24,

Today’s Agenda TopicTime Allotted Quick Review of Updated Timeline and Future Meeting Times 2:30 – 2:35 Presentation by Subject Matter Experts Rita Scichilone - AHIMA 2:35 - 3:00 Craig Stancl / Kevin Peterson – LexEVS and CTS 2 3:00 – 3:30 Jacob Reider – ONC 3:30 - 4:00 2

Proposed Timeline 3 TODAY Coordinate offline activities to summarize approaches and develop draft deliverable from presentations Meeting 1 – Dec 6 Meeting 2 – Dec 13 Meeting 3 – Dec 20 Meeting 4 – Jan 03 Meeting 5 – Jan 10 Meeting 6 – Jan 17 Meeting 7 – Jan 24 Meeting 8 – Jan 31 Meeting 9 – Feb 7 Meeting 10 – Feb 14 Tasks Constrains and Criteria Preliminary review of presentation summaries and Draft Deliverable Presentation I2b2 (Cont.) Intermountain Health DOQS (Data Warehousing / Mapping) Tasks Introductions Scope Proposed Approach Identify SME and presentation timeline for next few meetings Meeting times extended from 2:30-4:00pm Presentation hQuery i2b2 Presentation DOQS (Data Warehousing / Mapping) Cont. PopMedNet NLM Presentation Ibeza CDISC SHARE Tasks Review of presented concept mapping frameworks to select a proposed approach Begin Consensus Voting process Presentation RELMA (LOINC) 3M NY Presbyterian Hospital Vocab Team Presentation AHIMA LexEVS and CTS2 Jacob Reider - ONC Presentation NQF Kevin Puscas

Mapping Principles Rita A. Scichilone MHSA, RHIA, CCS, CCS-P

Overview Encoded data is a rich source of information Maps between terminological systems can be useful for translating the meaning of one coded value to its equivalent in another Query health initiatives disseminates queries to multiple data sources Sources may not understand what the query wants Mapping principles support reliable maps

Maps are Use Case Specific Maps between standardized code sets are expensive to create and maintain due to high requirements for human interpretation to ensure semantic interoperability Machines are unable to return “deafness” when the query asks for patients with a single target of presbycusis, anakusis, or even “hard of hearing” without an equivalence map

Principles of Mapping Map development requires judgments or decisions about the shared meaning of concepts Is “anakusis” and “deafness” the same concept? Maps between standards are context free

Mapping Defined ISO DTR defines mapping as “a process of defining a relationship between concepts in one coding system to concepts in another coding system in accordance with a documented rationale, for a given purpose” The progress of this report which is still in development can be followed on the catalogue page.

Map Facts Maps have a source and a target Maps are usually designed to run “one way” Care required in interpreting and using maps Skilled personnel are required to develop and test map validity of the use case

Value Proposition for Maps Meaningful re-use – data captured in one type of representation is linked to or translated into another for efficiency Data maps have the same shortcomings as language translations – not always possible to express the meaning exactly from one to another

Critical Factors Coding systems change frequently so maps must be maintained to keep current with the source/target changes Maps must demonstrate the degree of equivalence QA requirements and consensus management

Critical Factors Local terms to standards – Sharing information or comparing data content requires maps for migration from local terms or codes – Example: “Navajo Syndrome” ( acute respiratory distress syndrome) – Example: Linking service codes from a hospital chargemaster to CPT or LOINC Implementing Mappings

Critical Factors Data Mapping Best Practices Overview New AHIMA practice brief “ Managing a Data Dictionary” now availableManaging a Data Dictionary” The way forward using maps ………………………

Concept to Concept Mapping Craig Stancl, Kevin Peterson Mayo Clinic

Agenda LexEVS 6.0 Concept Mapping Common Terminology Services Release 2 (CTS2) Concept Mapping LexEVS and CTS2 Integration 01/201215© Copyright 2012, Mayo Clinic

LEXEVS 6.0 Concept to Concept Mapping

What is LexEVS? A comprehensive set of open source software and services to load, publish, and access vocabulary or ontological resources. Built on common information model representing multiple vocabularies Utilize common repositories, software components, APIs, and tools Ground in standards (e.g. HL7 CTS, ISO 11179) 01/201217© Copyright 2012, Mayo Clinic

What is LexGrid Model? The LexGrid Model provides a mechanism for standard storage of controlled vocabularies and ontologies: Defines HOW vocabularies can be commonly formatted and represented Provides the core representation for all data managed and retrieved through the LexEVS system Provides ability to build common repositories to store vocabulary content and common programming interfaces and tools to access and manipulate that content. Terminologies from widely varying resources such as RRF, OWL, and OBO can be loaded to a single data base management system and accessed with an single API. 01/201218© Copyright 2012, Mayo Clinic

LexEVS /201219© Copyright 2012, Mayo Clinic The LexGrid package represents a comprehensive set of software and services to load, publish, and access vocabulary or ontological resources. Built on common information model representing multiple vocabularies Utilize common repositories, software components, APIs, and tools Ground in standards (e.g. HL7 CTS, ISO 11179) Source OMG LQS … OWL Standards ISO XML HL7 CTS OtherOBO Content Represent LexGrid Model Data Index Export Import OWL XML OBO Text Protégé RRF XML Tools Access SERVICESSERVICES Java API Lex* Embed.NET Web Clients Grid Clients Documentation Examples Open

LexEVS 6.0 Mapping Capabilities Mapping functionality in LexEVS API provides ability to: Create Mapping - Relates a coded concept within a specified code system (source) to a corresponding coded concept (target) within the same or another code system, including identification of a specified association type. 01/201220© Copyright 2012, Mayo Clinic

LexEVS 6.0 Mapping Capabilities Continued functionality: Query Based on Source or Target Text Based on Association Type or Qualifier Sort Results Load maps from diverse set of formats (XML, OWL, RRF) into LexEVS. 01/201221© Copyright 2012, Mayo Clinic

LexEVS 6.0 Questions for Consideration How does your tool function? LexEVS 6.0 provides a set of APIs that can be used by an application to create, query and maintain concept mapping. Are you able to maintain the integrity of the original data in its native form (i.e. data as collected and not modified)? All data must be transformed into LexEVS compliant Data Objects. How can your tool be leveraged? Are there any external APIs or other interfaces External APIs are provided. How do you see your tool integrating with the QH Reference Implementation solution LexEVS would provide a set of APIs to enable the creation, query and maintenance of concept mapping. 01/201222© Copyright 2012, Mayo Clinic

LexEVS 6.0 Questions for Considerations Where does the mapping occur? Is it at the Data Source level? Or at the Information Requestor level? Or Both? LexEVS can consume pre-mapped data from arbitrary data sources (OWL, RRF, LexGrid XML). It also be used to create and incrementally modify new mapping data. Can it be easily implemented elsewhere? LexEVS is an implementation and it can be easily deployed elsewhere. Who maintains your concept mapping tool? Mayo Clinic maintains the LexEVS code, but it is open source and freely available to the community. Who maintains the mappings and how often are they released? LexEVS does not specify where mappings come from, how they are released, or what release cycle they follow. What is the associated cost with maintenance and periodic releases? New releases would require a new load of the source content, or an incremental load of the change set. 01/201223© Copyright 2012, Mayo Clinic

LexEVS Adopters LexEVS is used in various projects within the caBIG community. NCI Term Browser NCI Term Browser provides a consistent, user-friendly tool to browse and search all of the biomedical terminologies hosted by NCI EVS, including both NCI Thesaurus (NCIt) and the NCI Metathesaurus (NCIm), which itself includes more than 70 terminologies. 01/201224© Copyright 2012, Mayo Clinic

LexEVS Adopters NCI Metathesaurus (NCIm) Browser The NCIm Browser is for the retrieval of concepts from the NCI Metathesaurus, and for viewing the contents, structure, and cross mappings of individual source terminologies. It is designed for ease of use by a diverse user community. 01/201225© Copyright 2012, Mayo Clinic

LexEVS Adopters NCBO BioPortal BioPortal is a Web-based application for accessing and sharing biomedical ontologies. BioPortal allows users to browse, upload, download, search, comment on, and create mappings for ontologies. 01/201226© Copyright 2012, Mayo Clinic

LexEVS Resources LexEVS Project caBIG® Vocabulary Knowledge Center Wiki (LexEVS 6.0) kc.nci.nih.gov/Vocab/KC/index.php/LexEVS_Version_ kc.nci.nih.gov/Vocab/KC/index.php/LexEVS_Version_6. 0 caBIG® Vocabulary Knowledge Center Forums Provides ability to ask LexEVS questions and find answers 01/201227© Copyright 2012, Mayo Clinic

COMMON TERMINOLOGY SERVICES RELEASE 2 (CTS2) Concept to Concept Mapping

Common Terminology Services Release 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, … 01/201229© Copyright 2012, Mayo Clinic

CTS2 Goals 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 01/201230© Copyright 2012, Mayo Clinic

OMG 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 - it is 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 01/201231© Copyright 2012, Mayo Clinic

OMG CTS2 Specification Other Key Points 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 01/201232© Copyright 2012, Mayo Clinic

CTS2 Development Framework Under development by Mayo Clinic Allows for rapid creation of CTS2 compliant applications. Plug-in based – only implement the functionality that is required. Uses Model View Controller (MVC) architectural pattern 01/201233© Copyright 2012, Mayo Clinic

CTS2 Development Framework 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, …) 01/201234© Copyright 2012, Mayo Clinic

Using CTS2 Services CTS2 REST Implementation OMG Beta 1 Specification for CTS2 Map Services /Beta1/ /Beta1/ Demonstrate capabilities of CTS2 REST mapping implementation using NCBO BioPortal. 01/201235© Copyright 2012, Mayo Clinic

CTS2 REST Implementation Mapping (Query and Creation) 01/201236© Copyright 2012, Mayo Clinic

Using CTS2 Services Resources Wiki: amework/ (In Action Section) amework/ 01/201237© Copyright 2012, Mayo Clinic

CTS2 Questions for Considerations How do your standards relate to concept mapping? CTS2 is an Official OMG Standard (Beta 1) OMG Concept Mapping Specification Document Are you able to maintain the integrity of the original data in its native form (i.e. data as collected and not modified)? All data must be transformed into CTS2 compliant Data Objects. For many formats (such as SNOMEDCT and HL7), the transformation itself will be standardized. What infrastructure is necessary to implement / utilize your standard? Implementation are independent of any type of technology infrastructure, but significant tooling around facilitating implementation has been done ( How do you see your standard integrating with the QH Reference Implementation solution? CTS2 would provide a common set of APIs to enable the creation, query and maintenance of concept mapping. 01/201238© Copyright 2012, Mayo Clinic

CTS2 Questions for Considerations Where does the mapping occur? Is it at the Data Source level? Or at the Information Requestor level? Or Both? CTS2 can consume pre-mapped data from an arbitrary data source. It also be used to create and incrementally modify new mapping data. Can it be easily implemented elsewhere? Yes, implementation is modular – CTS2 is a large specification but only parts of it need to be implemented. Who maintains the development of standards? OMG, HL7, Mayo Clinic Who maintains the mappings and how often are they released? CTS2 does not specify where mappings come from, how they are released, or what release cycle they follow. What is the associated cost with maintenance and periodic releases? Depending on CTS2 implementation, new releases would require a new load of the source content, or an incremental load of the change set. 01/201239© Copyright 2012, Mayo Clinic

LEXEVS AND CTS2 INTEGRATION Concept to Concept Mapping

LexEVS Integration CTS2 interfaces could be implemented using LexEVS 6.0. Provide a Standards-Based ontology mapping tool. 01/201241© Copyright 2012, Mayo Clinic

Conclusion CTS2 is an accepted OMG and HL7 Standard. LexEVS is proven and used by NCI and NCBO. LexEVS and CTS2 provide an open source solution. 01/201242© Copyright 2012, Mayo Clinic

Jacob Reider ONC Senior Policy Advisor

Jacob Reider - ONC CDS and QM activities will both rely heavily on the creation, maintenance and sharing of value sets. These needs seem identical to the needs of the QH project in the domain of “concepts to codes.” We need to define a list of CODES that qualify a patient for inclusion or exclusion in a given query/quality measure/CDS intervention. Has this patient with DIABETES had an A1C TEST? How is “diabetes” defined? What is an A1C test? – A value set is a list of ALL possible codes that would exist in the system that would “count.” Such a list may be very long – and is ideally harmonized with other such lists – so that CMS’ “diabetes” list is the same as Humana’s.. etc. If the definitions (lists) differ – then we’re never talking about the same thing. 44

Jacob Reider (Con’t) As we Query Health’s needs for “concepts to codes” – is there something inherently different from “value sets” here? Would this project benefit from aligning the nomenclature – abandoning the term “concepts to codes” in favor of “value set?” Why would we do this? Why not? Note that the term “value set” is sometimes used to refer to a “convenience set” – which is a different beast. Convenience sets are not comprehensive – but actually aim to constrain a list of codes to a given specialty for the convenience of a give type of provider. So there may be a “cardiology convenience set” which is a list of the most common terms a cardiologist may use. This would presumably make “lookup” easier for a cardiologist. Some argue that as computers get better/stronger/faster, such convenience sets are no longer relevant. 45

Jacob Reider (Con’t). What are the hurdles ahead for “concepts to codes/value sets? How does this group see collaborating with other initiatives? What are the near-term and long-term opportunities? Where can this group help? 46