Presentation on theme: "Query Health Concept-to-Codes (C2C) SWG Summary Outputs Consensus Approved on 3/19/2012 1."— Presentation transcript:
Query Health Concept-to-Codes (C2C) SWG Summary Outputs Consensus Approved on 3/19/2012 1
Summary of Concept to Codes (C2C) Content in this presentation #ItemSlides 1Final Recommendations from C2C3-5 2Key Themes Across all presentations6-9 3Presentation Summaries
FINAL RECOMMENDATIONS 3
Summary of Decisions and Suggested Next steps 1.Healthcare Industry has a significant gap in creating, managing and publishing Value Sets mapped to common concepts. –Community recommends to the HITSC to work with organizations such as NLM, NQF and others to set up the above capability. 2.For Query Health, one suggestion was to start with NQF CQM based Value Sets and improve from there. –This is a very good source as evidenced by the community and Query Health will start from these value sets. 3.In order to share value sets in a standard way, Query Health will adopt the IHE SVS Restful web service approach and will pilot that using the NQF Value Sets. 4.The CEDD is a significant specification to promote common definitions of queries across multiple Data Sources –Enhance the CEDD to include the vocabulary mapping, value sets for elements where applicable and map to the reference implementation frameworks of i2B2, hQuery and PopMedNet to ensure completeness 5.Multiple tools and interfaces can be used for Query Composition, but simple intuitive ways are necessary and the concept hierarchy representation of i2B2 has been proven to work in the real world. –Adopt i2B2 approach and create the hierarchy for Query Health pilots. 4
Next Steps Activity 1 will be performed by the Initiative Coordinator / ONC as part of their regular briefing to HITSC Activities 2 (NQF VS) and 4 (CEDD enhancement) will be part of the CEDD work stream in the Clinical WG Activities 3 (IHE SVS Profile) and 5 (i2B2) will be part of the Technical WG 5
RECURRING KEY THEMES 6
All Recurring Key Themes The below list includes themes across many of the different presentations to date. The next 2 slides address how these may be incorporated into the Technical Expression. 1.All mappings are Purpose and Goal Specific 2.Hierarchy within mappings is important to ensure the concepts are appropriately mapped and can be drilled down to a granular level 3.A centralized Data Dictionary or central Terminology System is used to store mappings and is common practice in many healthcare organizations 4.As Standards such as ICD9, SNOMED CT, LOINC etc. are modified and updated, ongoing maintenance of mappings can be challenging 5.Identifying a Best Match OR Alternate/Default Map is necessary since concepts may not always have an exact map 6.It is important to identify the context of the queries to understand what information is being requested (example - Ordered drug vs. Administered drug) 7.Ongoing maintenance of mappings is very resource intensive and requires dedicated skilled resources such as Clinicians/ Informaticists 8.Many mapping tools and resources are publicly available or accessible that can be leveraged by organizations and further developed, refined, and maintained for use 9.Most Concept Mapping tools maintain data in its original form 7
Recurring Key Themes – Direct impact to Technical Framework The below list includes themes across many of the different presentations to date. The key themes in blue below directly impact the Technical Framework of QH. All others are addressed on the next slide. 1.All mappings are Purpose and Goal Specific 2.Hierarchy within mappings is important to ensure the concepts are appropriately mapped and can be drilled down to a granular level 3.A centralized Data Dictionary or central Terminology System is used to store mappings and is common practice in many healthcare organizations 4.As Standards such as ICD9, SNOMED CT, LOINC etc. are modified and updated, ongoing maintenance of mappings can be challenging 5.Identifying a Best Match OR Alternate/Default Map is necessary since concepts may not always have an exact map 6.It is important to identify the context of the queries to understand what information is being requested (example - Ordered drug vs. Administered drug) 7.Ongoing maintenance of mappings is very resource intensive and requires dedicated skilled resources such as Clinicians/ Informaticists 8.Many mapping tools and resources are publicly available or accessible that can be leveraged by organizations and further developed, refined, and maintained for use 9.Most Concept Mapping tools maintain data in its original form 8
Recurring Key Themes Do not directly impact Technical Framework However, Important to consider While not all key themes on the last slide may directly impact the Technical Framework, it is important to consider some of the key themes seen in the C2C presentation series (in green below) 1.All mappings are Purpose and Goal Specific 2.Hierarchy within mappings is important to ensure the concepts are appropriately mapped and can be drilled down to a granular level 3.A centralized Data Dictionary or central Terminology System is used to store mappings and is common practice in many healthcare organizations 4.As Standards such as ICD9, SNOMED CT, LOINC etc. are modified and updated, ongoing maintenance of mappings can be challenging 5.Identifying a Best Match OR Alternate/Default Map is necessary since concepts may not always have an exact map 6.It is important to identify the context of the queries to understand what information is being requested (example - Ordered drug vs. Administered drug) 7.Ongoing maintenance of mappings is very resource intensive and requires dedicated skilled resources such as Clinicians/ Informaticists 8.Many mapping tools and resources are publicly available or accessible that can be leveraged by organizations and further developed, refined, and maintained for use 9.Most Concept Mapping tools maintain data in its original form 9
PRESENTATION SUMMARIES 10
C2CPresentation Series 11
Presentation Schedule Presentation DatePresenterFramework/Tool/StandardCategory 112/13/11Andy Gregorowicz hQuery Distributed Network 212/13/11 (cont. 12/20/11)Shawn Murphyi2b2 / SHRINEDistributed Network 312/20/11Stan HuffIntermountain HealthStandard 412/20/11 (cont. 1/3/12)Rick Biehl DOQS - Data Warehousing and Concept Mapping Standard 51/3/12Jeff BrownPopMedNetDistributed Network 61/3/12Olivier BodenreiderNational Library of MedicineTool 71/10/12Victor BerajaIbezaStandard 81/10/12Rhonda FacileCDISC SHAREStandard 91/17/12Shaun Shakib3M - Healthcare Data DictionaryTool 101/17/12David BaortoNYP Terminology ServicesTool 111/17/12Zeshan RajputRELMA (Regenstrief)Tool 121/24/12Rita ScichiloneAHIMAConcept Mapping Principles /24/12Craig Stancl and Kevin PetersonLex EVS – CTS 2Tools 161/24/12Jacob ReiderONC Senior Policy AdvisorNA 171/31/12Kevin PuscasS&I RepositoryValue Set Definition Mgmt 182/7/12Floyd IsenbergNQFValue Sets 192/14/12Peter HendlerConvergent Medical TerminologyTool 12
AHIMA – Data Mapping Principles (Rita Scichilone) 14 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. Ritas 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.
i2b2/SHRINE (Shawn Murphy) 16 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 organizations 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.) 17 Two possible Use Cases for i2b2 ontology services 1. Mapping a global to a local terminology for SHRINE queries 2. 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. 18
Data Oriented Quality Solutions Data Warehousing (Rick Biehl) 20 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 dont 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 Berajas 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. 21
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 CDISCs 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. 22
UMLS and RxNorm National Library of Medicine – (Olivier Bodenreider) 23 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 doesnt 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) 24 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 patients 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 codes Common Tests subset – Top 2000 LOINC codes can represent 95% of clinical care use Google 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 ) 25 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. LexEVSs 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 (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) 26 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/ ).http://www.omg.org/spec/CTS2/1.0/Beta1/ 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) 27 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) 28 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) 29 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 weve 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 Service David Baorto – (Cont.) 30 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 SNOMEDs 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 IDs 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. 31
VALUE SETS 32
Jacob Reider Senior Policy Advisor for ONC Jacob Reiders 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. 33
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 NLMs 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). 34
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 QDM 35
Summaries of Questions for Considerations Distributed Query Networks 36
Summaries of Questions for Considerations Standards 38
Summary of Standards QuestionsIntermountain HealthData 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 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? 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 39
Summary of Standards QuestionsCommon Terminology Services 2 Ibeza 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)? CTS2 is an Official OMG Standard (Beta 1) OMG Concept Mapping Specification Document 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. 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? Implementation are independent of any type of technology infrastructure, but significant tooling around facilitating implementation has been done (http://informatics.mayo.edu/cts2/framework/)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 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? 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 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? 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 40
Summaries of Questions for Considerations Tools 41
QuestionsResources 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 dont delete your original data after conversion to LMOF Integration and Infrastructure 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 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? 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 Maintenance 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 42 Summary of Tools
QuestionsLexEVS 6.03M – Healthcare Data Dictionary 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)? 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 Infrastructure 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? 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 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? 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 Maintenance Who maintains your concept mapping tool? Who maintains the mappings and how often are they released? What is the associated cost with maintenance? 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 43 Summary of Tools