Query Health Concept-to-Codes (C2C) SWG

Summary of SME Presentations

3/19/2012

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 queries ofhealth 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. hQuery includes a graphical query composer.

hQuery operates on Codes/Code Sets in JavaScript libraries. A Graphical User Interface (GUI) facilitates building JavaScript libraries. These JavaScript libraries can easily be extracted and reused. Using the JavaScript libraries, hQuery 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 and the spreadsheets for MU stage 1 are available; however not able to re-distribute the outputs of the concepts due to licensing restrictions. Spreadsheets with codes / concepts can be found on www.projectpophealth.org

hQuery is intended for the responder level of Query Health.

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, the Global ontology used in a 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 an i2b2 metadata ontology table. This allows the latest SNOMED ontology to be pulled from the NCBO website.

The key to i2b2 is the hierarchical path and that the code/set of codes 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 specific coding systems and specific ontologies because ontologies can be built to support a particular organization’s database. To get a standard ontology into an i2b2 implementation, it is necessary to build from the 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 two terminologies simultaneously.

– For instance, 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 the standard ontology. There are often similar terms that are used differently at various hospitals. i2b2 does not map terms in a bi-directional fashion

PopMedNet (Jeff Brown)

PopMedNet (PMN) is an open source 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 the 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 projects 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 and 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.

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.

Convergent Medical Terminology (Kaiser)Peter Hendler

CMT is an ongoing initiative at Kaiser Permanente that began in1996 and is used to manage the standardization of clinical information. It is an Enterprise Terminology System structured as a hub and spoke model. The three different spokes: 1. Internal clinical terms that providers see and what populates in the eMR, 2. Patient friendly names easily understandable via patient portal, and 3. Administrative terms (ICD9-10, CPT etc). The hub that these connect to is the reference terminology SNOMED, but they also use LOINC for internal mappings

Kaiser donates the spreadsheets that contain mappings between core SNOMED terms and the 3 different types of terms mentioned above to the IHTSDO. CMT covers various domains such as Diagnosis, Lab Results, Immunizations, clinical Observations, Nursing Documentation, etc. No matter the changes that occur to standards or the codes (such as the change from ICD9 to ICD10) the clinicians or patients not see any changes in the EHR System that they use – the majority of changes are on the backend.

CMT is predominantly mapped to Standard Terminology (SNOMED/LOINC) and can be mapped to other terminology as needed. It can also leverage SNOMED’s structure, including its hierarchy and description logic (ie- the formal definition). It supports the requirements for standard terminology for Meaningful Use and Health Information Exchange. Their current infrastructure – A SNOMED name and code is 1. mapped to the appropriate ICD codes, 2. has descriptions of what the physicians display name, what the patients see, and synonyms and 3. a identifies the relationship. These ID’s and mappings are all sent to in the Epic (EHR) load file which links to a database called prodnam. The purpose of the prodnam is to then regionally distribute CMT mappings since Kaiser is quite a large network.

CMT query tool can pull information for a query in 3 different ways – Property based query (code or display name), Hierarchical based and Subsumption (role) based. This allows for the query to pull all the different possible results and increases the likelihood of accurate results. OWL (Web Ontology Language) is also another project that is currently underway at KP. Compared to EL+ used by SNOMED, the descriptive logic of OWL is more expressive and allows for negation and disjunction.

20

VALUE SETS

21

Jacob ReiderSenior Policy Advisor for ONC

Jacob Reider’s presentation and discussion mainly focused on ensuring that the C2C workgroup considers Value Sets as part of the series. His recommendations were to leverage currently ongoing work (NQF – Retooled Measures/Value Sets published in early 2010) as a starting point.

Clinical Decision Support (CDS) and Quality Management (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.”  Query Health should consider defining 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 long and is ideally harmonized with other such lists – so that all payer entities define it consistently.  If the definitions (lists) differ, then the context of the information will always vary.

– The term “Value Set” is sometimes used to refer to a “Convenience Set.”  Convenience sets are not comprehensive, but aim to constrain a list of codes to a given specialty for the convenience of a give type of provider.  Therefore, 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.

22

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

23

Value Sets – HIT Standards Committee Vocabulary Task Force Recommendations(Floyd Eisenberg - NQF)

Floyds presentation focused on the recommendations from the HIT Standards Committee Vocabulary

Task Force and Clinical Quality Workgroup. Reviewed descriptions of decisions that were made and what is

meant by the term “value sets” as well as what code systems are recommended for use.

When defining a quality measure or a query, the “element” within the query has to be very specific. The

concepts that are to be queried such as “Type II Diabetes” or “Coronary Artery Disease” usually have

corresponding codes and these groupings of codes are known as value sets. Smaller value sets can be

combined and link to a parent value set. The issue is that there are many different vocabulary sets to choose

from to define any particular concept within an EHR. What the Vocabulary Task Force Recommendations do

is suggest which appropriate vocabularies to use for the category of information within the Quality Data Model.

The primary recommended vocabulary are SNOMED CT, LOINC, RxNORM. Additionally, International

Classification of Function (limited use – some Rehab hospitals use this), Universal Classification of Units of

Measurement (UCUM), CVX (Vaccine Terminology) are also part of the recommendations. Transition

vocabularies have also been identified for EHR systems – ICD9, ICD 10 CM, ICD10 PCS, CPT, HCPCS are

allowable.

The Quality Data Model (QDM) is a information model that is used as a way to define concepts and

categories of information at NQF. It allows for the querying of the state or context of the concepts within the

query and how it is categorized (example. Ordered vs. Administered vs. Dispensed). Depending on what

category the concepts fall under, the Task Force recommended what Vocabularies should be used.

The rest of the presentation focused on walking through the recommendations. 1. recommended

vocabulary, 2. the associated concept and 3. how it is categorized in QDM24

Summaries of Questions for Considerations

Distributed Query Networks

25

Summary of Distributed Query Networks

26

Summaries of Questions for Considerations

Standards

27

Summary of Standards

28

Summary of Standards

29

Summaries of Questions for Considerations

Tools

30

31

Summary of Tools

32

Summary of Tools

APPENDIX

33

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

34

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

• 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)?

• 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)?

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?

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

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

Alignment to Query Health

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

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

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

Maintenance

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

• Who maintains your concept mapping tool?• Who maintains the mappings and how often are they released?• What is the associated cost with 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? 35