query health concept-to-codes (c2c) swg summary of sme presentations draft for review posted -...

Query Health Concept-to-Codes (C2C) SWG

Summary of SME Presentations

Draft for Review posted - 2/8/12

1

C2CPresentation Series

2

AHIMA – Data Mapping Principles (Rita Scichilone)

3

Concept mapping as defined by the ISO is “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 purposed.” Documentation about the rationale and intended purpose for map are essential before any type of mapping is attempted. Maps should be Understandable, Reproducible, and Useful.

Map development between coded data systems is designed for various purposes and can be expensive and challenging to maintain and/or update. The challenge in ongoing maintenance is that it requires some element of human interaction to ensure semantic interoperability. Use of local terminology for data capture in EHR is a major challenge for interoperability and health information exchange. Rita’s presentation focused on discussion around overview of mapping principles. Multiple data sources at the various targets for distributed queries pose a challenge for universal data mapping.

Critical Mapping Factors and Considerations for Best Practices

1. Mappings must be developed with this in mind - Have a (query) source and a (query) end target

2. Careful consideration is required in interpreting and using maps

3. Skilled resources and Subject Matter Experts (SMEs) are necessary to develop and test the validity and accuracy of the maps

4. Organizations must have a maintenance plans to keep current with changes in the standard codes. EHR Systems may or may not always be mapped to the most recent versions of standard codes released such as LOINC or SNOMED CT. This challenges semantic interoperability as mentioned above.

5. Confirm degree of equivalence there is between the source and target, for example, via Rating Scales and Cardinality of each maps (relationships between associated concepts) such as one to one, one to many etc.

6. Helpful to have a best match and a default map in – it specifics how “other” and “unspecified” are handled within the maps

7. Need a consensus management process in place via SMEs and quality assurance plan

8. Maintain a good data dictionary and ensuring data consistency

Value proposition of maps is to ensure meaningful reuse of the maps. This leads to efficiencies if the maps are completed accurately. However, data mapping can have its shortcomings as concepts may not always properly translate from a local system to a standard system.

hQuery (Andy Gregorowicz)

4

hQuery is an open-source implementation of a framework for distributed query of health data. It uses a simplified standard information model, based on nationally recognized data elements, to enable generic queries against and summarized responses from various clinical data sources. The query is expressed in JavaScript that interacts with a clinical EHR to extract information that is then aggregated using hQuery.

The Codes/Code Sets are placed in a JavaScript. A Graphical User Interface (GUI) allows building of a JavaScript. A JavaScript library houses codes that can be extracted and reused. hQuery would write a JavaScript (where codes/code sets are placed). This then runs through the clinical record and pulls any matching codes/code sets.

There are no special facilities in hQuery for any type of “concept mapping” to take place. popHealth has used spreadsheets released with MU stage 1 measures to generate concepts. The codes are available and the spreadsheets with MU stage 1 are available; however not able to re-distribute the outputs of the concepts. Spreadsheets with codes / concepts found on www.projectpophealth.org

http://www.projectpophealth.org/

i2b2/SHRINE (Shawn Murphy)

5

SHRINE is a research network for distributed queries. From a user interface perspective, he/she builds a query, launches it and waits to get an answer back. On the back end, the query is composed and goes through an aggregator that distributes it to SHRINE adaptors that support a type of mapping from standard ontology to local ontology. The query is then run against the Clinical Research Charts (CRC) in the local ontology terminology and the answers come back to the composer.

i2B2 allows the creation of formatted ontologies from the web services at National Center for Biomedical Ontology (NCBO). For example, Global ontology used in query may be SNOMED. To get SNOMED ontologies, i2B2 uses NCBO web services that bring down SNOMED terms into i2b2 ontology to a build tree. Within the SNOMED view, an extraction workflow program can be invoked that goes to NCBO, where it grabs ontology terms and places it in a database. The database processes these terms and translates into i2b2 metadata ontology table. This way latest SNOMED ontology can be pulled from NCBO website.

The key to i2b2 is the hierarchical path and that the code/set of codes are ultimately mapped to. i2B2 can be flexible to allow organizations to support and query multiple ontologies in their database based on the merging terminology process. Also, i2b2 can map from one ontology to another in order to support distributed queries on the fly. It is also agnostic to what coding systems are and what the ontologies are because ontologies can be built to support what is in the organization’s database. To get a standard ontology into i2b2 implementation, it is necessary to build those from NCBO web service or i2b2 has to distribute the appropriate demo version.

i2b2/SHRINE (Cont.)

6

Two possible Use Cases for i2b2 ontology services

1. Mapping a global to a local terminology for SHRINE queries2. Merging one terminology into another to enable queries using 2 terminologies simultaneously.

–i2b2 can automatically merge ICD9 terms with SNOMED ontology if the database has both terms. It can be queried selectively using i2b2. At this time all organizations have ICD9 and will soon have ICD10. Within i2b2, ICD9 can be merged into ICD10 so they can be queried together.

Each site is responsible for mapping the standard ontology to their local ontology so they are in control of how their local terms are represented in relation to standard ontology. There will always be issues where terms don’t match based on how general or specific they are or are similar but used differently at various hospitals. i2b2 does not map terms in a bi-directional fashion

PopMedNet (Jeff Brown)

PopMedNet (PMN) is a software designed to facilitate the creation, operation and governance of networks where each network decides how data and queries are standardized. It can be thought of as a “transport mechanism” via which a query can be sent and received from data partners. PMN typically standardizes formatting but for the most part avoids concept mapping as there is no internal concept mapping mechanism. Networks powered by PMN standardize the data and decide on querying approach where PMN facilitates. A data model plug-in is possible to translate queries between models.

PMN has a Web services API/ plug-in architecture. The architecture allows for the data partners (DPs) to be in control of participating in distributed query networks and the terms on how they participate. It minimizes the need for extensive database expertise and ongoing maintenance/management of complex data structures.

PMN querying tools are network specific (SAS, SQL, etc). Mappings are limited to industry standard terminologies (NDC, ICD9, HCPCS, LOINC). Currently, PMN is used in a variety of population health and public health surveillance reasons such as Mini-Sentinal (FDA), MDPHnet (ONC), AHRQ etc.

7

Intermountain Health (Stan Huff)

8

Concept mapping at Intermountain is done mainly to support data transformation/conversion from local code to standard codes. They mainly receive data from outside systems or from own system (owned by IM but purchased from different vendors). The data is pulled into a common repository and typically has hierarchical structure and associative relationship. In concept mapping it is important to know the concept and the information model because there are a lot of areas (outside of Lab) where knowing the code/set of codes does not always translate to appropriate concepts. At Intermountain, they normalize multiple streams of data that comes in to standard form by bringing the data to an interface engine and normalizing data to common structure and transform local codes to standard codes. For example local lab tests and results to LOINC and local problem lists to SNOMED-CT.

Concept mapping should occur at the query responder’s level (data source) level vs. the query requestors level because the query responder would understand their own data sets and be able to respond more accurately than the query requestor. Internally, they utilize Dice Coefficient to for lexical mapping; however also utilize RELMA (from Regenstrief) as an external tool for mapping. They can utilize terminology services such as Java and JavaScript as well. Ongoing model and terminology creation and internal maintenance of mappings requires approximately 4.5 FTEs (40% of 14 FTEs dedicated to this work).

Their mappings are currently not shared or used by other entities and maintained internally . Most local mappings have a 1:1 relationships; however, mappings from SNOMED to ICD-9 for example would have more general applicability on a large/national scale.

Data Oriented Quality SolutionsData Warehousing (Rick Biehl)

9

Clinical research data warehousing is made up of 26 key dimensions. Each dimension has the same 6 table database design that represent the logical sub-dimensions of the data warehouse: Context, Reference, Definition, Bridge, Group, and Hierarchy. Ontologies are mapped in the Hierarchy dimension. Regardless of how many dimensions there are, the 6-table database design a standard way of looking at each dimension. The key to building healthcare dimensions is to standardize the way dimensions are structured in order for them to be federated and shared on a large scale.

In terms of Concept Mapping, categorization of sub-dimensions within database into some standard form is key to making this model work. Three key elements are necessary for query creation and form the overarching data architecture:• Category, Role, and Perspective • For example – to answer “How many analgesics were administered?,” the query should be designed to

pull all facts where a drug (category) was administered (role) and Analgesic (perspective) was available in any higher perspective. If all data warehouses are designed with the same 3 constructs in mind, queries can be written against various data models

Biehl relies heavily on the Open Biomedical Ontology (OBO) Group for his work. His model is designed such that it makes it easier for query creators to search by concepts such as “heart disease” which on the back end are mapped to any and all relevant diagnosis codes and therefore yield accurate query responses. His model eliminates the need to perform searches by codes and allows for more terminology based searches.

Ibeza (Victor Beraja)

Concepts codes don’t always tell what part of history or exam the information is coming from. This is why context of the codes being returned is very important. They run medical rules to inform patients and doctors at the point of care about clinical guidelines and insurance benefits so an informed decision can be made for what is best for the patient.

Clinical data concept is mapped to SNOMED and /or LOINC as available within the structure that provides context – this way the context of where this information was pulled from is also found. Query results for a particular question at hand are as good as how well the query has been formulated and whether the right concepts are being queried (in the right context).

Victor Beraja’s presentation focuses on the importance of context queries and how to execute accurate searches. For example, billing data (such as diagnosis code) may pull all information relevant to the number of tests conducted but not the findings from those tests. For instance, a query written to identify all diabetic patients with macular edema will pull results (based on Procedure / Diagnosis codes) for the total number of tests conducted; however, it will not factor in the results of those tests because that information isn't grounded in the Procedure or Diagnosis codes. This is why it is important to understand the (clinical) context of the queries to obtain the most accurate information possible.

10

CDISC SHARE (Rhonda Facile)

CDISC is a non profit organization that develop standards for clinical trials. The discussion will focus on metadata repositories and metadata that contains clinical data from clinical trials. Overarching purpose for CDISC SHARE project is to take the various CDISC standards developed to date and create a metadata repository that is easily accessible and appropriately linked / formatted. Some of the main goals of the CDISC Share Project• Provide a consistent approach to standard definition and Improve access to standards • Speed up new clinical research content development • Facilitate data reuse• Decrease costs - Downloadable metadata could reduce standards maintenance costs and enable

process improvement• Deliver all of CDISC’s existing and all new content in both human and machine-readable forms• Facilitate alignment of Clinical Research and Healthcare Standards

In order to achieve these goals, there must be semantic interoperability where all standards are using the same definitions. Also they must utlize the CDISC share model that links all CDISC Standards.

Their metadata model was derived by reviewing models by Intermountain, Open EHR, SDTM, and decided to come up with the CDISC SHARE model. The benefits of this model will be appropriately layered and structured, linked together with CDISC Standards, a single definitions that is consistently used, and machine readable.

11

UMLS and RxNorm National Library of Medicine – (Olivier Bodenreider)

12

National Library of Medicine (NLM) develops standards to support users of clinical standards and terminologies. NLM has developed normalization strategies that are specific to clinical text/terms. They go beyond string matching and do more linguistically based methods for normalizing strings into UMLS concepts.

What is UMLS ? – UMLS stands for Unified Medical Language System. It integrates clinical vocabularies such as SNOMED CT (clinical terms) and MeSH (information science) to name a few which make it easier to directly translate one terminology to another. There are a total 160 source vocabularies and a total of 21 languages that are housed in UMLS. The UMLS serves as a vehicle for the regulatory standards (HIPAA, HITSP, Meaningful Use). UMLS includes all major clinical terminologies such as LOINC, SNOMED CT. RxNorm. UMLS is released twice a year and RxNorm is released on a monthly basis. UMLS Terminology Services is available as a Graphical User Interface( GUI) for UMLS

What is RxNorm?RxNorm can be thought of as a mini UMLS specifically targeted towards drugs) that creates standardizes names for the drugs in addition to mappings. RxNorm integrates names and codes of a dozen vocabularies and normalizes the names. RxNav is the Graphical User Interface for RxNorm.

Variances between UMLS and RxNorm – •UMLS doesn’t create terms whereas RxNorm creates standardized terms for the drugs in addition to creating the mappings•RxNorm and UMLS are both terminology integration systems. They provide some level of source transparency which means that from UMLS, the original sources can be reconstructed (this cannot be done for RxNorm).

RELMA – Regenstrief Institute(Zeshan Rajput)

13

Zeshan Rajput is a member of the SDC Support team at Accenture and not representing Regenstrief for this presentation. RELMA does one off mappings – specifically to the LOINC standard. LOINC is used to code the questions a clinician may ask– for example: “what is my patient’s Translates local set of concepts into standard vocabulary. RELMA helps consume single vocabulary

RELMA is a tool distributed with LOINC that can be downloaded from the Regenstrief website. It is a free resource that also has a sample data that can be used to test out RELMA. Some tools are available for mapping of local test (or set of tests) to LOINC codesCommon Tests subset – Top 2000 LOINC codes can represent 95% of clinical care useGoogle like search function – search box functionality and manual identification of code when necessary.

There are 4 basic ways to map local concepts to RELMA of which the best way is to load directly from HL7 V2.x messages which eliminates any manual loading errors.

Zeshan also provided a demonstration of the various ways to map local concepts to RELMA by sharing the LMOF file (Local Master Observation File). It contains all the information that an organization would need to represent the concept within their own information system. Zeshan did a demo of both the manual as well as the automated ways RELMA can be used for concept mapping. Successes in mapping within RELMA depend on a few tried and true best practices such as Expanding typical abbreviations, Standardizing terms that are referenced, Avoid administrative terms used to distinguish tests (Stick to clinical), Standardize time references, and lastly include units of measure to increase specificity of the automated mapping tool.

Mayo Clinic – LexEVS (Craig Stancl )

14

LexEVS 6.0 has been in development at Mayo Clinic for approximately the past 10 years. It is a comprehensive set of open source software and services to accomplish various tasks such as load, publish, and access vocabulary or ontological resources. It is built on common information model called the Lex Grid model that represents multiple vocabularies and ontologies in one model. LexEVS’s primary goal is to be able to utilize and provide access of common repositories (Oracle, DB2 etc.) software components, APIs, and tools. The LexEVS model is based on standards within HL7, specifically CTS 1 specs and model/definition provided by ISO 11179 (international standard for representing metadata for an organization in a metadata registry.)

The LexGrid Model represents the data and 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.

Mapping capabilities built into LexEVS for the most part have been based off experience with SNOMED CT. Mayo provides the API to do the mappings. The 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. The query can be based on the source or target text as well as the association type or qualifier. Also can specify how the results are sorted based on query type. Able to load maps from a wide range of formats – XML, OWL, RRF into LexEVS repository.

Mayo Clinic – Common Terminology Services 2.0(Kevin Peterson)

15

CTS 2 was developed by Mayo Clinic to provide a standard for a shared semantic model and API for the query, interchange and update of terminological content. (i.e. standard way to query and store vocabulary content). CTS2 is an API specification and it defines the semantics, syntax and valid interactions that can occur. It is not a software. Rather it is the blueprint for building and using software.

It is not specific to healthcare and can essentially support any terminology content from any discipline. There are some semantic web components built in - OWL and RDF. Extensions are encouraged within CTS 2 as it is not meant to limit what can be done with it. The purpose is to be able to show how common things can be consistently done

CTS 2 is plug in based meaning that functionality deemed necessary can be implemented - Not all components have to be implemented. The Model View Controller (MVC) architecture pattern of development provides a REST based framework for CTS 2. REST implementation was one of OMG standards platform specific models of CTS 2 (http://www.omg.org/spec/CTS2/1.0/Beta1/20120906 ).

Integration points between LexEVS and CTS 2 – •CTS2 interfaces could be implemented using LexEVS 6.0.•Provide a Standards-Based ontology mapping tool. •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.

http://www.omg.org/spec/CTS2/1.0/Beta1/20120906

3M - Healthcare Data Dictionary(Shaun Shakib)

16

Healthcare Data Dictionary is the vocabulary server utilized at 3M. Components of the system are - Enterprise Master Person Index, Clinical Data Repository for storing pt data, HDD (responsible for all structuring and encoding of data stored in CDR). HDD is a system that organizes, defines, and encodes concepts. It can be thought of as a metadata repository that defines the logical structure of instance data to make it computable.

- Medical Information Model – supplies structural definitions of what is stored in CDR, - Knowledge Base – Semantic network – relationships between concepts

- Controlled Medical Vocabularies.

The approach is to centralize mapping vs. a network of point to point mappings. Main reason for this is that it is easier to maintain additions of new sources and updates. They have concept based controlled medical vocabulary and 3M integrate both source standard terminology and local interface terminology through process of concept mapping. HDD has roughly 2.4 million concepts (both global, local (single enterprise) and shared concepts)

In terms of the actual mapping process, 3M utilizes some tooling / matching technology. They have SMEs who are clinical experts with domain knowledge and formal informatics training to develop and maintain mappings. They use in-house tools developed for mappings. They also perform Semantic Mapping for Drugs and have an internal terminology model for drugs/lab results. This internal terminology model breaks lab results concept down into component attributes by following LOINC model . They can then look to see if these concepts are in HDD that are defined in the same way. Lastly, the creation of new concepts requires inerator (?) agreement and validation of all mappings.

3M - Healthcare Data Dictionary(Shaun Shakib)

17

The combination of all these various pieces is a concept based controlled medical vocabulary that has various source systems mapped to them. All mappings in HDD are concept equivalent level. This means that if an incoming source has a different level of granularity/specificity than any concept in HDD, their approach is to create that concept at the appropriate level of granularity and then use semantic network to go from that concept to the closest concept that might have standard code associated with it (i.e. – Identify the best match and then have the next best alternative mapping).

Currently, HDD utilizes CTS V 1.2 which provides functional specs to query terminology servers in a standard way. Concepts that have changed in meaning or updated codes are not deleted; however, they are inactivated. Having HDD as a tool for mapping allows 3M to code data and once a standard code becomes available, they associate that code with the concept in HDD. As far as handling any overlaps with concepts, there is always a chance that observations in LOINC and SNOMED CT could overlap. A single concept in HDD can have multiple source codes associated with it. So if there is overlap, they just associated all codes to that same concept.

NY Presbyterian Terminology Service(David Baorto)

18

What started as terminology management at NY Presbyterian hospital with the development of the Medical Entities Dictionary (MED) approximately 20 years ago has now expanded into a Terminology Service at NYP (both Cornell and Columbia hospitals).

Concept mapping can be defined in various ways – local to local, local to standard, and standard to standard codes. There are Hierarchical types of maps (i.e. information residing as a subclass or at a more granular level) and Relational maps which are mappings in between the various standards. As we’ve seen in other presentations, concept mapping is goal specific and the type of mapping necessary will vary based on what requirements or results an information requestor is looking for. For this reason, concept mapping also needs to be flexible and support changes to evolving standards.

Integrity of the original data is retained at the granularity of the source system. Semantics about the data are maintained in the central terminology system. As data flows from source systems to various downstream systems, the central terminology can be leveraged by the system in order to infer information from that data and obtain terminological knowledge. The MED Connects in real time for production queries to certain systems and provides batch interval results for other vendor systems.

The mapping process – All codes (subclasses) are assigned to a class based on the hierarchy system. When a new code needs to be added, it is created in the MED and assigned to a class in the appropriate hierarchy. The mapping does not occur at the data source or the information requestor level, but rather it occurs at the level of the terminology server.

NY Presbyterian Terminology ServiceDavid Baorto – (Cont.)

19

As far as internal tools, they use lexical approaches, hierarchy and semantics. The terminology team does build some tools in Perl however most of their work is centered around “service” rather than actual tools. For external tools, there are available crosswalks between ICD 9 and CPT that helps build procedure hierarchy in MED and they also utilize RELMA for LOINC.

Content provision tools - how do downstream systems speak to the central terminology?There is a Web Based MED Browser where searches can be conducted. Also, you can view concepts within the MED (one by one) and also drill down by hierarchy. Most of their tools are created internally at NYP. The MED used to be directly connected to clinical information system for real time interactions. Use the Perl scripts for regular pre-determined queries.

In terms of maintenance, once the terminology has been incorporated, the maintenance process is relatively easy with regular weekly/monthly updates. For the new terminologies that are incorporated the maintenance and updating process is more challenging. Currently a lot of ongoing work is managed by 3 FTEs and they utilize 2 Unix Servers.

S&I Repository(Kevin Puscas)

The S&I Repository is a Web-based platform and consists of three components: Artifact Manager, Category

Manager, and Information Browser. The architecture is an alfresco application linking external sources. It requires a

link with the NML UMLS to formulate searches based on accepted standard terms. The Repository has the capability

to: 1. manage artifacts (documents, models, links, etc.), 2. facilitate artifact lifecycles (publishing and versioning), 3.

establish contextual relationship and taxonomy of tags between artifacts, and 4. search both content and metadata. It

uses a “shopping cart” model similar to Amazon.com for reporting results and can manage links to web sources. The

Browser allows user to search artifacts after Wiki collaboration. Artifact Manager allows searches.

The artifacts can range from documents (PDF, Word, XML etc.), Media (audio/visual, JPEG,TIFF,MP3.

MOV etc), Links (URL, value sets), and Models. The Category Manager allows category groupings and application of

official meta-tags. Vocabulary Value Sets are in a computable format defined by HITSC. They use the NLM’s UMLS

system, which has been defined by ONC as the source vocabulary. Value Sets are composed of the information

needed and how those values are defined. The vocabulary is not stored by S&I Framework, but retrieved from UMLS

as needed. Once value Sets are returned to the repository by UMLS, identifiers are attached and the results reported in

XML.

This version of S&I framework is a work in progress and not the finalized product. One of the major

constraints is that S&I Repository handles only enumerated value set definitions and not intentional value set definitions

(values that change by criteria such as age and date). Only 14 of 160 available vocabularies are included, although

others can be easily added. Users must have a UMLS account to use it, but this prevents copyright violations. It is

limited to current UMLS version. Future capabilities are expected to be a full SVS profile to allow access to the public,

intentional value set definitions, access to non-UMLS vocabularies, and alternative authoring mechanisms (ex csv).

20

DISTRIBUTED QUERY NETWORKS

21

Summary of Distributed Query NetworksQuestions PopMedNet i2B2/SHRINE hQuery

Overview and

Current

Status

• How do you define concept mapping within your system (e.g. are you mapping in between standards, or are you mapping from standards to your local data dictionary)?• Are there any internal mechanism?• Do you use any external tools?• Are you able to maintain the integrity of the original data in its native form (i.e. data as collected and not modified)?

•Facilitates creation, operation, and governance of networks, each network decides how to standardize data and queries•PMN networks typically standardize formatting but avoid concept mapping, with some exceptions•Maintaining integrity - Networks determine how to store data. Most data models maintain local codes even if the code is mapped

•The standard SHRINE vocabulary is mapped to the local data dictionary within each site’s adaptor cell. Internal tools are used. Data is maintained in its original form and then mapped to various terminologies.

•Concept mappings (if any) are created in the JavaScript passed in the query. There is no special support for this.

•The codes and code systems of the underlying data are preserved

Integratio

n and Infrastructure

• How can you integrate with external tools for mapping? JavaScript library? Java? Web Services API?• How do you see your framework integrating with the QH Reference Implementation solution?

•Has a Web services API/ plug-in architecture•Does NOT include any mapping capability•PMN querying tools are network specific (SAS, SQL, etc)•Mappings are limited to industry standard terminologies (NDC, ICD9, HCPCS, LOINC)

•External mapping tools could be used to build the mapping tables.

•JavaScript library

Alignment

to QH

• Where does the mapping occur? Is it at the Data Source level? Or at the Information Requestor level? Or Both?• Can it be easily implemented elsewhere?

•It is the transport mechanism and governance tool and is agnostic to the implementation decisions. •Networks will develop unique solutions for querying

•Mapping is performed at each site at the data source level. It could also be performed by a designated intermediary.

•Information Requestor Level

Maintenance

Who maintains your concept mapping tool?• Who maintains the mappings and how often are they released?• What is the associated cost with maintenance?

•All network implementations use a dedicated coordinating center to oversee the integrity of the data and use of the network•Requires substantial resources to ensure appropriate use

•I2b2/SHRINE personnel maintain our mapping tools. Local teams maintain the mappings. Cost depends on number of mappings, most sites have at least ½ FTE to maintain i2b2 software, mappings, and database for SHRINE.

•NA

22

STANDARDS

23

Summary of StandardsQuestions Intermountain Health Data Oriented Quality

Solution (DOQS)NYP Terminology Services

Overview and

Current Status

• How do your standards relate to 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)?

•Most data can be preserved in original (log files will eventually be deleted)•Preservation of data is the responsibility of the sending system

•Standardizes data warehousing into dimensions and sub dimensions that can be easily stored, retrieved, managed and queried

•Defined by the tasks (local to local, local to standard etc) and types (equivalency, hierarchical, Relational) of mappings•Integrity of data is maintained by retrieving results according the class or semantics

Integration and

Infrastructure

• What infrastructure is necessary to implement / utilize your standard?• How do you see your standard integrating with the QH Reference Implementation solution?

•Internal tools - Lexical matching using Dice Coefficient•External tools - RELMA

•Overarching data architecture should be categorized by Category, Role, and Perspective within each dimension

Alignment to QH


•Query Requestors level is where mapping should occur because the query responder would understand their own data sets and be able to respond more accurately than the query requestor

•The standard refers to how data should be organized for querying so can be implemented elsewhere if they follow the particular pathway

Maintenance

• Who maintains the development of standards?• Who maintains the mappings and how often are they released?• What is the associated cost with maintenance and periodic releases?

•Maintain their own mappings and are all internal to IM•Cost - 14 FTEs that create models, terminology, and mappings

•1,200 HL7 interfaces•3 million patients•31,000 employees

•NA •Once a terminology has been incorporated, maintenance consists of regular updates•New terminology -> difficult. (example – Two independent laboratories merged into single laboratory information system).•3 FTEs and 2 Unix Servers

24

Summary of StandardsQuestions Common Terminology Services 2 Ibeza

Overview and

Current

Status


• CTS2 is an Official OMG Standard (Beta 1)• OMG Concept Mapping Specification Document

• http://www.omg.org/spec/CTS2/1.0/Beta1/20120906 • All data must be transformed into CTS2 compliant Data

Objects. For many formats (such as SNOMEDCT and HL7), the transformation itself will be standardized.

• Each clinical data concept is mapped to SNOMED and/or LOINC

• The integrity of the original data is preserved by creating a dictionary of clinical terms offered to the public so everyone can use the same terms in their clinical forms. New terminology submitted is then revised by a team of experts. These determine if the “new” term is added as “new” or as an “alternate wording” of an existing clinical term.

Integratio

n and Infrastructure


• Implementation are independent of any type of technology infrastructure, but significant tooling around facilitating implementation has been done (http://informatics.mayo.edu/cts2/framework/)

• CTS2 would provide a common set of APIs to enable the creation, query and maintenance of concept mapping.

• The standards allow Context Queries of specific Clinical Data. For example you will be able to query number of patients who had a dilated fundus exam with an exam of the macula for diabetic maculopathy.

Alignment

to QH


• CTS2 can consume pre-mapped data from an arbitrary data source. It also be used to create and incrementally modify new mapping data.

• Yes, implementation is modular – CTS2 is a large specification but only parts of it need to be implemented.

• Both. At the creation of the glossary of concepts mapped to SNOMED and LOINC.

• And it can be easily implemented

Maintenance


• OMG, HL7, Mayo Clinic maintain development of standards

• CTS2 does not specify where mappings come from, how they are released, or what release cycle they follow.

• Depending on CTS2 implementation, new releases would require a new load of the source content, or an incremental load of the change set.

• A dedicated group of medical experts and engineers oversees the integrity and development of the standard.

• Mappings are maintained by a dedicated group of medical experts on a quarterly basis

25

http://www.omg.org/spec/CTS2/1.0/Beta1/20110906

http://informatics.mayo.edu/cts2/framework/

TOOLS

26

Questions Resources and Tools(UMLS/UTS, RxNorm/RxNav)

RELMA

Overview and

Current

Status

• How does your tool function?• Are you able to maintain the integrity of the original data in its native form (i.e. data as collected and not modified)?

• Terminology integration system• Source transparency (most original

terminologies can be recreated from the UMLS; generally not the case for RxNorm)

• Take any of four sources of local observations and map them to LOINC using automated or manual (facilitated) approaches

• Since you have to get your information into LMOF format (in one way or another), the mapping would not affect the original data as long as you don’t delete your original data after conversion to LMOF

Integration and

Infrastructu

re

• How can your tool be leveraged? Are there any external APIs or other interfaces?• How do you see your tool integrating with the QH Reference Implementation solution?

• UMLS: - GUI: UTS - API: SOAP-based• RxNorm

- GUI: RxNav- API: SOAP-based + RESTful

• No API or interface• Representative of tools (another is RxNav) that

facilitate adoption of a single standard• LOINC also distributed with .mdb and could be

directly imported into another interface and used to facilitate query composition, interpretation, or response

Alignment

to Query Healt

h


• Includes all major clinical terminologies

• Bridges between query (text, code) and data source (standard code)

• Most likely at both the query composer and data source

• Query composer – makes sure the right question is being asked

• Data source – makes sure the question is translated into local terms

• RELMA is specific to LOINC

Maintenanc

e

• Who maintains your concept mapping tool?• Who maintains the mappings and how often are they released?• What is the associated cost with maintenance?

• NLM develops the UMLS and RxNorm (data + tooling)

• Release schedule - UMLS: twice yearly - RxNorm: monthly• No fee to the end user (but license

agreement required*)

• Regenstrief Institute and multiple partners around the world maintain tool

• The mappings are created by each user of RELMA• The tool is updated with LOINC, twice yearly

27

Summary of Tools

Questions LexEVS 6.0 3M – Healthcare Data Dictionary

Overview and

Current

Status


• LexEVS 6.0 provides a set of APIs that can be used by an application to create, query and maintain concept mapping.

• All data must be transformed into LexEVS compliant Data Objects.

• Mapping to local data dictionary = centralized concept mapping; not point-to-point

• Can maintain integrity original data

Integration and

Infrastructu

re


• External APIs are provided.• LexEVS would provide a set of APIs to enable the

creation, query and maintenance of concept mapping.

• Internal Tools - Quality Control? – Inter-rator agreement; internal terminology models; db triggers and constraints; business logic in domain specific tools

• External technologies, but all our tooling is in-house

• Web services API = CTS v1.2• Alignment with QH RI - Native integration or

through the API

Alignment

to Query Healt

h


• 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.

• LexEVS is an implementation and it can be easily deployed elsewhere.

• Both; Local terminologies (terms and codes) are integrated with standards through concept mapping

• Can be easily implemented

Maintenanc

e


• Mayo Clinic maintains the LexEVS code, but it is open source and freely available to the community.

• LexEVS does not specify where mappings come from, how they are released, or what release cycle they follow.

• New releases would require a new load of the source content, or an incremental load of the change set.

• Domain specific mapping tools maintained by a Development team

• A team of nearly 30 SMEs with domain specific clinical expertise and informatics training

28

Summary of Tools

Questions Ibeza

Overview and

Current

Status


• Each clinical data concept is mapped to SNOMED and/or LOINC

• The integrity of the original data is preserved by creating a dictionary of clinical terms offered to the public so everyone can use the same terms in their clinical forms. New terminology submitted is then revised by a team of experts. These determine if the “new” term is added as “new” or as an “alternate wording” of an existing clinical term.

Integration and

Infrastructu

re


• Our standards allow Context Queries of specific Clinical Data. For example you will be able to query number of patients who had a dilated fundus exam with an exam of the macula for diabetic maculopathy.

Alignment

to Query Healt

h


• Both. At the creation of the glossary of concepts mapped to SNOMED and LOINC.

• And it can be easily implemented

Maintenanc

e


• A dedicated group of medical experts and engineers oversees the integrity and development of the standard.

• Mappings are maintained by a dedicated group of medical experts on a quarterly basis

29

Summary of Tools

APPENDIX

30

1. Presentation Schedule 2011-2012 Presentation Date Presenter Framework/Tool/Standard Category

1 12/13/11 Andy Gregorowicz hQuery Distributed Network

2 12/13/11 (cont. 12/20/11) Shawn Murphy i2b2 / SHRINE Distributed Network

3 12/20/11 Stan Huff Intermountain Health Standard

4 12/20/11 (cont. 1/3/12) Rick Biehl DOQS - Data Warehousing and Concept Mapping Standard

5 1/3/12 Jeff Brown PopMedNet Distributed Network

6 1/3/12 Olivier Bodenreider National Library of Medicine Tools

7 1/10/12 Victor Beraja Ibeza Standard

8 1/10/12 Rhonda Facile CDISC SHARE Standard

9 1/17/12 Shaun Shakib 3M - Healthcare Data Dictionary Tool

10 1/17/12 David Baorto NYP Terminology Services Tools

11 1/17/12 Zeshan Rajput RELMA (Regenstrief) Tool

12 1/24/12 Rita Scichilone AHIMA Concept Mapping Principles

13 - 14 1/24/12 Craig Stancl and Kevin Peterson Lex EVS – CTS 2 Tools

16 1/24/12 Jacob Reider ONC Senior Policy Advisor NA

17 1/31/12 Kevin Puscas S&I Repository Value Set Definition Mgmt

18 2/7/12 Floyd Isenberg NQF Value Sets

19 2/14/12 Keith Boone IHE SVS Profiles Standard

31

2. Questions for ConsiderationsFrameworks

(Ex. - i2B2, PMN, hQuery)Tools

(Ex. RxNav, RELMA, LexEVS)Standards

Overview and Current Status

• How do you define concept mapping within your system (e.g. are you mapping in between standards, or are you mapping from standards to your local data dictionary)?• Are there any internal mechanism?• Do you use any external tools?• Are you able to maintain the integrity of the original data in its native form (i.e. data as collected and not modified)?



Integration and

Infrastructure

• How can you integrate with external tools for mapping? JavaScript library? Java? Web Services API?• How do you see your framework integrating with the QH Reference Implementation solution?



Alignment to Query Health




Maintenance

Who maintains your concept mapping tool?• Who maintains the mappings and how often are they released?• What is the associated cost with maintenance?



32

query health concept-to-codes (c2c) swg summary of sme presentations draft for review posted -...

Documents

universal data mapping

data capture

multiple data sources

coded data systems

various clinical data

good data dictionary

recognized data elements

query source