Venous Access: National Guideline and Registry Development (VANGUARD): Advancing Patient-Centered Venous Access Care Through the Development of a National Coordinated Registry Network

There are over 8 million central venous access devices inserted each year, many in patients with chronic conditions who rely on central access for life-preserving therapies. Central venous access device-related complications can be life-threatening and add tens of billions of dollars to health care costs, while their incidence is most likely grossly mis- or underreported by medical institutions. In this communication, we review the challenges that impair retention, exchange, and analysis of data necessary for a meaningful understanding of critical events and outcomes in this clinical domain. The difficulty is not only with data extraction and harmonization from electronic health records, national surveillance systems, or other health information repositories where data might be stored. The problem is that reliable and appropriate data are not recorded, or falsely recorded, at least in part because policy, payment, penalties, proprietary concerns, and workflow burdens discourage completeness and accuracy. We provide a roadmap for the development of health care information systems and infrastructure that address these challenges, framed within the context of research studies that build a framework of standardized terminology, decision support, data capture, and information exchange necessary for the task. This roadmap is embedded in a broader Coordinated Registry Network Learning Community, and facilitated by the Medical Device Epidemiology Network, a Public-Private Partnership sponsored by the US Food and Drug Administration, with the scope of advancing methods, national and international infrastructure, and partnerships needed for the evaluation of medical devices throughout their total life cycle.

Computer clinical decision support that automates personalized clinical care: a challenging but needed healthcare delivery strategy

How to deliver best care in various clinical settings remains a vexing problem. All pertinent healthcare-related questions have not, cannot, and will not be addressable with costly time- and resource-consuming controlled clinical trials. At present, evidence-based guidelines can address only a small fraction of the types of care that clinicians deliver. Furthermore, underserved areas rarely can access state-of-the-art evidence-based guidelines in real-time, and often lack the wherewithal to implement advanced guidelines. Care providers in such settings frequently do not have sufficient training to undertake advanced guideline implementation. Nevertheless, in advanced modern healthcare delivery environments, use of eActions (validated clinical decision support systems) could help overcome the cognitive limitations of overburdened clinicians. Widespread use of eActions will require surmounting current healthcare technical and cultural barriers and installing clinical evidence/data curation systems. The authors expect that increased numbers of evidence-based guidelines will result from future comparative effectiveness clinical research carried out during routine healthcare delivery within learning healthcare systems.

Interoperable genetic lab test reports: mapping key data elements to HL7 FHIR specifications and professional reporting guidelines

OBJECTIVE

In many cases, genetic testing labs provide their test reports as portable document format files or scanned images, which limits the availability of the contained information to advanced informatics solutions, such as automated clinical decision support systems. One of the promising standards that aims to address this limitation is Health Level Seven International (HL7) Fast Healthcare Interoperability Resources Clinical Genomics Implementation Guide-Release 1 (FHIR CG IG STU1). This study aims to identify various data content of some genetic lab test reports and map them to FHIR CG IG specification to assess its coverage and to provide some suggestions for standard development and implementation.

MATERIALS AND METHODS

We analyzed sample reports of 4 genetic tests and relevant professional reporting guidelines to identify their key data elements (KDEs) that were then mapped to FHIR CG IG.

RESULTS

We identified 36 common KDEs among the analyzed genetic test reports, in addition to other unique KDEs for each genetic test. Relevant suggestions were made to guide the standard implementation and development.

DISCUSSION AND CONCLUSION

The FHIR CG IG covers the majority of the identified KDEs. However, we suggested some FHIR extensions that might better represent some KDEs. These extensions may be relevant to FHIR implementations or future FHIR updates.The FHIR CG IG is an excellent step toward the interoperability of genetic lab test reports. However, it is a work-in-progress that needs informative and continuous input from the clinical genetics' community, specifically professional organizations, systems implementers, and genetic knowledgebase providers.

Logical Observation Identifiers Names and Codes (LOINC®) Applied to Microbiology: A National Laboratory Mapping Experience in Taiwan

Background and Objective: Logical Observation Identifiers Names and Codes (LOINC) is a universal standard for identifying laboratory tests and clinical observations. It facilitates a smooth information exchange between hospitals, locally and internationally. Although it offers immense benefits for patient care, LOINC coding is complex, resource-intensive, and requires substantial domain expertise. Our objective was to provide training and evaluate the performance of LOINC mapping of 20 pathogens from 53 hospitals participating in the National Notifiable Disease Surveillance System (NNDSS). Methods: Complete mapping codes for 20 pathogens (nine bacteria and 11 viruses) were requested from all participating hospitals to review between January 2014 and December 2016. Participating hospitals mapped those pathogens to LOINC terminology, utilizing the Regenstrief LOINC mapping assistant (RELMA) and reported to the NNDSS, beginning in January 2014. The mapping problems were identified by expert panels that classified frequently asked questionnaires (FAQs) into seven LOINC categories. Finally, proper and meaningful suggestions were provided based on the error pattern in the FAQs. A general meeting was organized if the error pattern proved to be difficult to resolve. If the experts did not conclude the local issue’s error pattern, a request was sent to the LOINC committee for resolution. Results: A total of 53 hospitals participated in our study. Of these, 26 (49.05%) used homegrown and 27 (50.95%) used outsourced LOINC mapping. Hospitals who participated in 2015 had a greater improvement in LOINC mapping than those of 2016 (26.5% vs. 3.9%). Most FAQs were related to notification principles (47%), LOINC system (42%), and LOINC property (26%) in 2014, 2015, and 2016, respectively. Conclusions: The findings of our study show that multiple stage approaches improved LOINC mapping by up to 26.5%.

A qualitative investigation of biomedical informatics interoperability standards for genetic test reporting: benefits, challenges, and motivations from the testing laboratory's perspective

PURPOSE

Genetic laboratory test reports can often be of limited computational utility to the receiving clinical information systems, such as clinical decision support systems. Many health-care interoperability (HC) standards aim to tackle this problem, but the perceived benefits, challenges, and motivations for implementing HC interoperability standards from the labs' perspective has not been systematically assessed.

METHODS

We surveyed genetic testing labs across the United States and conducted a semistructured interview with responding lab representatives. We conducted a thematic analysis of the interview transcripts to identify relevant themes. A panel of experts discussed and validated the identified themes.

RESULTS

Nine labs participated in the interview, and 24 relevant themes were identified within five domains. These themes included the challenge of complex and changing genetic knowledge, the motivation of competitive advantage, provided financial incentives, and the benefit of supporting the learning health system.

CONCLUSION

Our study identified the labs' perspective on various aspects of implementing HC interoperability standards in producing and communicating genetic test reports. Interviewees frequently reported that increased adoption of HC standards may be motivated by competition and programs incentivizing and regulating the incorporation of interoperability standards for genetic test data, which could benefit quality control, research, and other areas.

Enabling a learning healthcare system with automated computer protocols that produce replicable and personalized clinician actions

Clinical decision-making is based on knowledge, expertise, and authority, with clinicians approving almost every intervention-the starting point for delivery of "All the right care, but only the right care," an unachieved healthcare quality improvement goal. Unaided clinicians suffer from human cognitive limitations and biases when decisions are based only on their training, expertise, and experience. Electronic health records (EHRs) could improve healthcare with robust decision-support tools that reduce unwarranted variation of clinician decisions and actions. Current EHRs, focused on results review, documentation, and accounting, are awkward, time-consuming, and contribute to clinician stress and burnout. Decision-support tools could reduce clinician burden and enable replicable clinician decisions and actions that personalize patient care. Most current clinical decision-support tools or aids lack detail and neither reduce burden nor enable replicable actions. Clinicians must provide subjective interpretation and missing logic, thus introducing personal biases and mindless, unwarranted, variation from evidence-based practice. Replicability occurs when different clinicians, with the same patient information and context, come to the same decision and action. We propose a feasible subset of therapeutic decision-support tools based on credible clinical outcome evidence: computer protocols leading to replicable clinician actions (eActions). eActions enable different clinicians to make consistent decisions and actions when faced with the same patient input data. eActions embrace good everyday decision-making informed by evidence, experience, EHR data, and individual patient status. eActions can reduce unwarranted variation, increase quality of clinical care and research, reduce EHR noise, and could enable a learning healthcare system.

Logical Observation Identifiers Names and Codes for Laboratorians

CONTEXT.—

The Logical Observation Identifiers Names and Codes (LOINC) system is supposed to facilitate interoperability, and it is the federally required code for exchanging laboratory data.

OBJECTIVE.—

To provide an overview of LOINC, emerging issues related to its use, and areas relevant to the pathology laboratory, including the subtleties of test code selection and importance of mapping the correct codes to local test menus.

DATA SOURCES.—

This review is based on peer-reviewed literature, federal regulations, working group reports, the LOINC database (version 2.65), experience using LOINC in the laboratory at several large health care systems, and insight from laboratory information system vendors.

CONCLUSIONS.—

The current LOINC database contains more than 55 000 numeric codes specific for laboratory tests. Each record in the LOINC database includes 6 major axes/parts for the unique specification of each individual observation or measurement. Assigning LOINC codes to a laboratory's test menu should be a defined process. In some cases, LOINC can aid in distinguishing laboratory data among different information systems, whereby such benefits are not achievable by relying on the laboratory test name alone. Criticisms of LOINC include the complexity and resource-intensive process of selecting the most correct code for each laboratory test, the real-world experience that these codes are not uniformly assigned across laboratories, and that 2 tests that may have the same appropriately assigned LOINC code may not necessarily have equivalency to permit interoperability of their result data. The coding system's limitations, which subsequently reduce the potential utility of LOINC, are poorly understood outside of the laboratory.

Lessons Learned in Creating Interoperable Fast Healthcare Interoperability Resources Profiles for Large-Scale Public Health Programs

OBJECTIVE

This article describes lessons learned from the collaborative creation of logical models and standard Health Level Seven (HL7) Fast Healthcare Interoperability Resources (FHIR) profiles for family planning and reproductive health. The National Health Service delivery program will use the FHIR profiles to improve federal reporting, program monitoring, and quality improvement efforts.

MATERIALS AND METHODS

Organizational frameworks, work processes, and artifact testing to create FHIR profiles are described.

RESULTS

Logical models and FHIR profiles for the Family Planning Annual Report 2.0 dataset have been created and validated.

DISCUSSION

Using clinical element models and FHIR to meet the needs of a real-world use case has been accomplished but has also demonstrated the need for additional tooling, terminology services, and application sandbox development.

CONCLUSION

FHIR profiles may reduce the administrative burden for the reporting of federally mandated program data.

Profiling Fast Healthcare Interoperability Resources (FHIR) of Family Health History based on the Clinical Element Models

In this study we developed a Fast Healthcare Interoperability Resources (FHIR) profile to support exchanging a full pedigree based family health history (FHH) information across multiple systems and applications used by clinicians, patients, and researchers. We used previously developed clinical element models (CEMs) that are capable of representing the FHH information, and derived essential data elements including attributes, constraints, and value sets. We analyzed gaps between the FHH CEM elements and existing FHIR resources. Based on the analysis, we developed a profile that consists of 1) FHIR resources for essential FHH data elements, 2) extensions for additional elements that were not covered by the resources, and 3) a structured definition to integrate patient and family member information in a FHIR message. We implemented the profile using an open-source based FHIR framework and validated it using patient-entered FHH data that was captured through a locally developed FHH tool.

The Pluripotent Rendering of Clinical Data for Precision Medicine

Health care and biomedical research are awash in data. Traditional data warehouse methodologies do not scale to this challenge; nor do their schema match the variety of analytic use cases. An alternative model, which shreds data into well-formed constituent data elements, conformant with the emerging CIMI-FHIR standards and stored together with the complete, raw, source data using modern and scalable data utilities such as Hadoop and its derivatives, affords the creation of pluripotent data repositories. Such repositories can be leveraged to generate any number of data marts, registries, and analytic data sets, each of which "just in time" binds an appropriate use-case specific data model. We call this notion PiCaRD: Pluripotent Clinical Repository of Data. We believe such nimble biomedical data management strategies are crucial for Precision Medicine discovery and application.

Clinical element models in the SHARPn consortium

OBJECTIVE

The objective of the Strategic Health IT Advanced Research Project area four (SHARPn) was to develop open-source tools that could be used for the normalization of electronic health record (EHR) data for secondary use--specifically, for high throughput phenotyping. We describe the role of Intermountain Healthcare's Clinical Element Models ([CEMs] Intermountain Healthcare Health Services, Inc, Salt Lake City, Utah) as normalization "targets" within the project.

MATERIALS AND METHODS

Intermountain's CEMs were either repurposed or created for the SHARPn project. A CEM describes "valid" structure and semantics for a particular kind of clinical data. CEMs are expressed in a computable syntax that can be compiled into implementation artifacts. The modeling team and SHARPn colleagues agilely gathered requirements and developed and refined models.

RESULTS

Twenty-eight "statement" models (analogous to "classes") and numerous "component" CEMs and their associated terminology were repurposed or developed to satisfy SHARPn high throughput phenotyping requirements. Model (structural) mappings and terminology (semantic) mappings were also created. Source data instances were normalized to CEM-conformant data and stored in CEM instance databases. A model browser and request site were built to facilitate the development.

DISCUSSION

The modeling efforts demonstrated the need to address context differences and granularity choices and highlighted the inevitability of iso-semantic models. The need for content expertise and "intelligent" content tooling was also underscored. We discuss scalability and sustainability expectations for a CEM-based approach and describe the place of CEMs relative to other current efforts.

CONCLUSIONS

The SHARPn effort demonstrated the normalization and secondary use of EHR data. CEMs proved capable of capturing data originating from a variety of sources within the normalization pipeline and serving as suitable normalization targets.

Completing Death Certificates from an EMR: Analysis of a Novel Public-Private Partnership

With the objective of increasing electronic death registration, Intermountain Healthcare and the Utah Office of Vital Records and Statistics have developed a system enabling death certification from within Intermountain's electronic medical record (EMR), consisting of an EMR module and an HL7 interface. Comparison of post-intervention death certification at Intermountain Healthcare against a baseline study found a slight increase in the percentage of deaths certified electronically (73% pre vs. 77% post). Analysis of deaths certified using the EMR-module found that they were completed significantly sooner than those certified on paper or using the state's web-based electronic death registration system (EDRS) (Mean time: Paper = 114.72 hours, EDRS = 81.84 hours, EMR = 43.92 hours; p < 0.0001). EMR-certified deaths also contained significantly more causes of deaths than either alternative method (Mean number of causes: Paper = 3.9 causes, EDRS = 4.0 causes, EMR = 5.5 causes; p < 0.0001).

Harmonization of detailed clinical models with clinical study data standards

INTRODUCTION

This article is part of the Focus Theme of METHODS of Information in Medicine on "Managing Interoperability and Complexity in Health Systems".

BACKGROUND

Data sharing and integration between the clinical research data management system and the electronic health record system remains a challenging issue. To approach the issue, there is emerging interest in utilizing the Detailed Clinical Model (DCM) approach across a variety of contexts. The Intermountain Healthcare Clinical Element Models (CEMs) have been adopted by the Office of the National Coordinator awarded Strategic Health IT Advanced Research Projects for normalization (SHARPn) project for normalizing patient data from the electronic health records (EHR).

OBJECTIVE

The objective of the present study is to describe our preliminary efforts toward harmonization of the SHARPn CEMs with CDISC (Clinical Data Interchange Standards Consortium) clinical study data standards.

METHODS

We were focused on three generic domains: demographics, lab tests, and medications. We performed a panel review on each data element extracted from the CDISC templates and SHARPn CEMs.

RESULTS

We have identified a set of data elements that are common to the context of both clinical study and broad secondary use of EHR data and discussed outstanding harmonization issues.

CONCLUSIONS

We consider that the outcomes would be useful for defining new requirements for the DCM modeling community and ultimately facilitating the semantic interoperability between systems for both clinical study and broad secondary use domains.

Developing a section labeler for clinical documents

Natural language processing (NLP) technologies provide an opportunity to extract key patient data from free text documents within the electronic health record (EHR). We are developing a series of components from which to construct NLP pipelines. These pipelines typically begin with a component whose goal is to label sections within medical documents with codes indicating the anticipated semantics of their content. This Clinical Section Labeler prepares the document for further, focused information extraction. Below we describe the evaluation of six algorithms designed for use in a Clinical Section Labeler. These algorithms are trained with N-gram-based feature sets extracted from document sections and the document types. In the evaluation, 6 different Bayesian models were trained and used to assign one of 27 different topics to each section. A tree-augmented Bayesian network using the document type and N-grams derived from section headers proved most accurate in assigning individual sections appropriate section topics.

Lessons learned in detailed clinical modeling at Intermountain Healthcare

BACKGROUND AND OBJECTIVE

Intermountain Healthcare has a long history of using coded terminology and detailed clinical models (DCMs) to govern storage of clinical data to facilitate decision support and semantic interoperability. The latest iteration of DCMs at Intermountain is called the clinical element model (CEM). We describe the lessons learned from our CEM efforts with regard to subjective decisions a modeler frequently needs to make in creating a CEM. We present insights and guidelines, but also describe situations in which use cases conflict with the guidelines. We propose strategies that can help reconcile the conflicts. The hope is that these lessons will be helpful to others who are developing and maintaining DCMs in order to promote sharing and interoperability.

METHODS

We have used the Clinical Element Modeling Language (CEML) to author approximately 5000 CEMs.

RESULTS

Based on our experience, we have formulated guidelines to lead our modelers through the subjective decisions they need to make when authoring models. Reported here are guidelines regarding precoordination/postcoordination, dividing content between the model and the terminology, modeling logical attributes, and creating iso-semantic models. We place our lessons in context, exploring the potential benefits of an implementation layer, an iso-semantic modeling framework, and ontologic technologies.

CONCLUSIONS

We assert that detailed clinical models can advance interoperability and sharing, and that our guidelines, an implementation layer, and an iso-semantic framework will support our progress toward that goal.

Normalization and standardization of electronic health records for high-throughput phenotyping: the SHARPn consortium

RESEARCH OBJECTIVE

To develop scalable informatics infrastructure for normalization of both structured and unstructured electronic health record (EHR) data into a unified, concept-based model for high-throughput phenotype extraction.

MATERIALS AND METHODS

Software tools and applications were developed to extract information from EHRs. Representative and convenience samples of both structured and unstructured data from two EHR systems-Mayo Clinic and Intermountain Healthcare-were used for development and validation. Extracted information was standardized and normalized to meaningful use (MU) conformant terminology and value set standards using Clinical Element Models (CEMs). These resources were used to demonstrate semi-automatic execution of MU clinical-quality measures modeled using the Quality Data Model (QDM) and an open-source rules engine.

RESULTS

Using CEMs and open-source natural language processing and terminology services engines-namely, Apache clinical Text Analysis and Knowledge Extraction System (cTAKES) and Common Terminology Services (CTS2)-we developed a data-normalization platform that ensures data security, end-to-end connectivity, and reliable data flow within and across institutions. We demonstrated the applicability of this platform by executing a QDM-based MU quality measure that determines the percentage of patients between 18 and 75 years with diabetes whose most recent low-density lipoprotein cholesterol test result during the measurement year was <100 mg/dL on a randomly selected cohort of 273 Mayo Clinic patients. The platform identified 21 and 18 patients for the denominator and numerator of the quality measure, respectively. Validation results indicate that all identified patients meet the QDM-based criteria.

CONCLUSIONS

End-to-end automated systems for extracting clinical information from diverse EHR systems require extensive use of standardized vocabularies and terminologies, as well as robust information models for storing, discovering, and processing that information. This study demonstrates the application of modular and open-source resources for enabling secondary use of EHR data through normalization into standards-based, comparable, and consistent format for high-throughput phenotyping to identify patient cohorts.

A semantic-web oriented representation of the clinical element model for secondary use of electronic health records data

The clinical element model (CEM) is an information model designed for representing clinical information in electronic health records (EHR) systems across organizations. The current representation of CEMs does not support formal semantic definitions and therefore it is not possible to perform reasoning and consistency checking on derived models. This paper introduces our efforts to represent the CEM specification using the Web Ontology Language (OWL). The CEM-OWL representation connects the CEM content with the Semantic Web environment, which provides authoring, reasoning, and querying tools. This work may also facilitate the harmonization of the CEMs with domain knowledge represented in terminology models as well as other clinical information models such as the openEHR archetype model. We have created the CEM-OWL meta ontology based on the CEM specification. A convertor has been implemented in Java to automatically translate detailed CEMs from XML to OWL. A panel evaluation has been conducted, and the results show that the OWL modeling can faithfully represent the CEM specification and represent patient data.

Towards a semantic lexicon for clinical natural language processing

A semantic lexicon which associates words and phrases in text to concepts is critical for extracting and encoding clinical information in free text and therefore achieving semantic interoperability between structured and unstructured data in Electronic Health Records (EHRs). Directly using existing standard terminologies may have limited coverage with respect to concepts and their corresponding mentions in text. In this paper, we analyze how tokens and phrases in a large corpus distribute and how well the UMLS captures the semantics. A corpus-driven semantic lexicon, MedLex, has been constructed where the semantics is based on the UMLS assisted with variants mined and usage information gathered from clinical text. The detailed corpus analysis of tokens, chunks, and concept mentions shows the UMLS is an invaluable source for natural language processing. Increasing the semantic coverage of tokens provides a good foundation in capturing clinical information comprehensively. The study also yields some insights in developing practical NLP systems.

Modeling and executing electronic health records driven phenotyping algorithms using the NQF Quality Data Model and JBoss® Drools Engine

With increasing adoption of electronic health records (EHRs), the need for formal representations for EHR-driven phenotyping algorithms has been recognized for some time. The recently proposed Quality Data Model from the National Quality Forum (NQF) provides an information model and a grammar that is intended to represent data collected during routine clinical care in EHRs as well as the basic logic required to represent the algorithmic criteria for phenotype definitions. The QDM is further aligned with Meaningful Use standards to ensure that the clinical data and algorithmic criteria are represented in a consistent, unambiguous and reproducible manner. However, phenotype definitions represented in QDM, while structured, cannot be executed readily on existing EHRs. Rather, human interpretation, and subsequent implementation is a required step for this process. To address this need, the current study investigates open-source JBoss® Drools rules engine for automatic translation of QDM criteria into rules for execution over EHR data. In particular, using Apache Foundation's Unstructured Information Management Architecture (UIMA) platform, we developed a translator tool for converting QDM defined phenotyping algorithm criteria into executable Drools rules scripts, and demonstrated their execution on real patient data from Mayo Clinic to identify cases for Coronary Artery Disease and Diabetes. To the best of our knowledge, this is the first study illustrating a framework and an approach for executing phenotyping criteria modeled in QDM using the Drools business rules management system.

There are important reasons for delaying implementation of the new ICD-10 coding system

Federal authorities have recently signaled that they would consider delaying some aspects of implementation of the newest version of the International Classification of Diseases, known as ICD-10-CM, a coding system used to define health care charges and diagnoses. Some industry groups have reacted with dismay, and many providers with relief. We are concerned that adopting this new classification system for reimbursement will be disruptive and costly and will offer no material improvement over the current system. Because the health care community is also working to integrate health information technology and federal meaningful-use specifications that require the adoption of other complex coding standardization systems (such as the system called SNOMED CT), we recommend that the Centers for Medicare and Medicaid Services consider delaying the adoption of ICD-10-CM. Policy makers should also begin planning now for ways to make the coming transition to ICD-11 as tolerable as possible for the health care and payment community.

Building a robust, scalable and standards-driven infrastructure for secondary use of EHR data: the SHARPn project

The Strategic Health IT Advanced Research Projects (SHARP) Program, established by the Office of the National Coordinator for Health Information Technology in 2010 supports research findings that remove barriers for increased adoption of health IT. The improvements envisioned by the SHARP Area 4 Consortium (SHARPn) will enable the use of the electronic health record (EHR) for secondary purposes, such as care process and outcomes improvement, biomedical research and epidemiologic monitoring of the nation's health. One of the primary informatics problem areas in this endeavor is the standardization of disparate health data from the nation's many health care organizations and providers. The SHARPn team is developing open source services and components to support the ubiquitous exchange, sharing and reuse or 'liquidity' of operational clinical data stored in electronic health records. One year into the design and development of the SHARPn framework, we demonstrated end to end data flow and a prototype SHARPn platform, using thousands of patient electronic records sourced from two large healthcare organizations: Mayo Clinic and Intermountain Healthcare. The platform was deployed to (1) receive source EHR data in several formats, (2) generate structured data from EHR narrative text, and (3) normalize the EHR data using common detailed clinical models and Consolidated Health Informatics standard terminologies, which were (4) accessed by a phenotyping service using normalized data specifications. The architecture of this prototype SHARPn platform is presented. The EHR data throughput demonstration showed success in normalizing native EHR data, both structured and narrative, from two independent organizations and EHR systems. Based on the demonstration, observed challenges for standardization of EHR data for interoperable secondary use are discussed.

The SHARPn project on secondary use of Electronic Medical Record data: progress, plans, and possibilities

SHARPn is a collaboration among 16 academic and industry partners committed to the production and distribution of high-quality software artifacts that support the secondary use of EMR data. Areas of emphasis are data normalization, natural language processing, high-throughput phenotyping, and data quality metrics. Our work avails the industrial scalability afforded by the Unstructured Information Management Architecture (UIMA) from IBM Watson Research labs, the same framework which underpins the Watson Jeopardy demonstration. This descriptive paper outlines our present work and achievements, and presages our trajectory for the remainder of the funding period. The project is one of the four Strategic Health IT Advanced Research Projects (SHARP) projects funded by the Office of the National Coordinator in 2010.

An OWL meta-ontology for representing the Clinical Element Model

The Clinical Element Model (CEM) is a strategy designed to represent logical models for clinical data elements to ensure unambiguous data representation, interpretation, and exchange within and across heterogeneous sources and applications. The current representations of CEMs have limitations on expressing semantics and formal definitions of the structure and the semantics. Here we introduce our initial efforts on representing the CEM in OWL, so that the enrichment with OWL semantics and further semantic processing can be achieved in CEM. The focus of this paper is the CEM meta-ontology where the basic structures, the properties and their relationships, and the constraints are defined. These OWL representation specifications have been reviewed by CEM experts to ensure they capture the intended meaning of the model faithfully.

Investigating the semantic interoperability of laboratory data exchanged using LOINC codes in three large institutions

LOINC codes are seeing increased use in many organizations. In this study, we examined the barriers to semantic interoperability that still exist in electronic data exchange of laboratory results even when LOINC codes are being used as the observation identifiers. We analyzed semantic interoperability of laboratory data exchanged using LOINC codes in three large institutions. To simplify the analytic process, we divided the laboratory data into quantitative and non-quantitative tests. The analysis revealed many inconsistencies even when LOINC codes are used to exchange laboratory data. For quantitative tests, the most frequent problems were inconsistencies in the use of units of measure: variations in the strings used to represent units (unrecognized synonyms), use of units that result in different magnitudes of the numeric quantity, and missing units of measure. For non-quantitative tests, the most frequent problems were acronyms/synonyms, different classes of elements in enumerated lists, and the use of free text. Our findings highlight the limitations of interoperability in current laboratory reporting.

LOINC® - A Universal Catalog of Individual Clinical Observations and Uniform Representation of Enumerated Collections

In many areas of practice and research, clinical observations are recorded on data collection forms by asking and answering questions, yet without being represented in accepted terminology standards these results cannot be easily shared among clinical care and research systems. LOINC contains a well-developed model for representing variables, answer lists, and the collections that contain them. We have successfully added many assessments and other collections of variables to LOINC in this model. By creating a uniform representation and distributing it worldwide at no cost, LOINC aims to lower the barriers to interoperability among systems and make this valuable data available across settings when and where it is needed.

Cohort amplification: an associative classification framework for identification of disease cohorts in the electronic health record

With the growing national dissemination of the electronic health record (EHR), there are expectations that algorithms to identify disease-based cohorts for health services research will be deployable across health care organizations. Toward that goal, a novel associative classification framework was designed to generate prediction rules to identify cases similar to the exemplar cases on which it was trained. It processes exemplars for any medical condition without modification. The framework is distinguished by core candidate data attributes based on common EHR observation categories, application of associative classification methods to cull disease-specific attributes and predictive rules from the core attributes, and support for attribute concept hierarchies to manage the various layers of granularity in native EHR data. The framework processes and an evaluation of prediction rules generated to identify diabetes mellitus are presented.

Correctness of Voluntary LOINC Mapping for Laboratory Tests in Three Large Institutions

With IRB approval, we obtained de-identified laboratory test data from 3 large institutions (ARUP, Intermountain, and Regenstrief). In this study we evaluated correctness of mapping local laboratory result codes to Logical Observation Identifier Names and Codes (LOINC®). We received 9,027 laboratory tests mapped to 3,669 unique LOINC codes. A one tenth sample (884 tests) was manually reviewed for correctness of the mappings. After review, there were 4 tests mapped to totally unrelated LOINC codes and there were 36 tests containing at least one error in mapping to the 6 axes of LOINC. The errors of LOINC mapping could be categorized into 4 systematic errors: 1) human errors, 2) mapping to different granularity, 3) lack of knowledge of the meaning of laboratory tests and 4) lack of knowledge of LOINC naming rules. Finally, we discuss how these systematic mapping errors might be avoided in the future.

Representing Patient Assessments in LOINC®

Without being included in accepted vocabulary standards, the results of completed patient assessment instruments cannot be easily shared in health information exchanges. To address this important barrier, we have developed a robust model to represent assessments in LOINC through iterative refinement and collaborative development. To capture the essential aspects of the assessment, the LOINC model represents the hierarchical panel structure, global item attributes, panel-specific item attributes, and structured answer lists. All assessments are available in a uniform format within the freely available LOINC distribution. We have successfully added many assessments to LOINC in this model, including several federally required assessments that contain functioning and disability content. We continue adding to this "master question file" to further enable interoperable exchange, storage, and processing of assessment data.

A characterization of local LOINC mapping for laboratory tests in three large institutions

OBJECTIVES

We characterized the use of laboratory LOINC® codes in three large institutions, focused on the following questions: 1) How many local codes had been voluntarily mapped to LOINC codes by each institution? 2) Could additional mappings be found by expert manual review for any local codes that were not initially mapped to LOINC codes by the local institution? and 3) Are there any common characteristics of unmapped local codes that might explain why some local codes were not mapped to LOINC codes by the local institution?

METHODS

With Institutional Review Board (IRB) approval, we obtained deidentified data from three large institutions. We calculated the percentage of local codes that have been mapped to LOINC by personnel at each of the institutions. We also analyzed a sample of unmapped local codes to determine whether any additional LOINC mappings could be made and identify common characteristics that might explain why some local codes did not have mappings.

RESULTS

Concept type coverage and concept token coverage (volume of instance data covered) of local codes mapped to LOINC codes were 0.44/0.59, 0.78/0.78 and 0.79/0.88 for ARUP, Intermountain, and Regenstrief, respectively. After additional expert manual mapping, the results showed mapping rates of 0.63/0.72, 0.83/0.80 and 0.88/0.90, respectively. After excluding local codes which were not useful for inter-institutional data exchange, the mapping rates became 0.73/0.79, 0.90/0.99 and 0.93/0.997, respectively.

CONCLUSIONS

Local codes for two institutions could be mapped to LOINC codes with 99% or better concept token coverage, but mapping for a third institution (a reference laboratory) only achieved 79% concept token coverage. Our research supports the conclusions of others that not all local codes should be assigned LOINC codes. There should also be public discussions to develop more precise rules for when LOINC codes should be assigned.

Development of an electronic public health case report using HL7 v2.5 to meet public health needs

Clinicians are required to report selected conditions to public health authorities within a stipulated amount of time. The current reporting process is mostly paper-based and inefficient and may lead to delays in case investigation. As electronic medical records become more prevalent, electronic case reporting is becoming increasingly feasible. However, there is no existing standard for the electronic transmission of case reports from healthcare to public health entities. We identified the major requirements of electronic case reports and verified that the requirements support the work processes of the local health departments. We propose an extendable standards-based model to electronically transmit case information and associated laboratory information from healthcare to public health entities. The HL7 v2.5 message model is currently being implemented to transmit electronic case reports from Intermountain Healthcare to the Utah Department of Health.

Evaluation of LOINC for representing constitutional cytogenetic test result reports

Genetic testing is becoming increasingly important to medical practice. Integrating genetics and genomics data into electronic medical records is crucial in translating genetic discoveries into improved patient care. Information technology, especially Clinical Decision Support Systems, holds great potential to help clinical professionals take full advantage of genomic advances in their daily medical practice. However, issues relating to standard terminology and information models for exchanging genetic testing results remain relatively unexplored. This study evaluates whether the current LOINC standard is adequate to represent constitutional cytogenetic test result reports using sample result reports from ARUP Laboratories. The results demonstrate that current standard terminology is insufficient to support the needs of coding cytogenetic test results. The terminology infrastructure must be developed before clinical information systems will be able to handle the high volumes of genetic data expected in the near future.

Evaluating the accuracy of existing EMR data as predictors of follow-up providers

In order to evaluate the accuracy of existing EMR data in predicting follow-up providers, a retrospective analysis was performed on six months of data for inpatient and ED encounters occurring at two hospitals, and on related outpatient data. Sensitivity and Positive Predictive Value (PPV) were calculated for each of eight predictors, to determine their effectiveness in predicting follow-up providers. Our findings indicate that access to longitudinal patient care records can improve prediction of which providers a patient is likely to see post-discharge compared to simply using Primary Care Provider data from admissions records. Of the predictors evaluated, a patient's past appointment history was the best predictor of which providers they would see in the future (PPV = 48% following inpatient visits, 35% following emergency department visits). However, even the best performing predictors failed to predict more than half of the follow-up providers and might generate many "false" alerts.

Computerized alerts improve outpatient laboratory monitoring of transplant patients

Authors evaluated the impact of computerized alerts on the quality of outpatient laboratory monitoring for transplant patients. For 356 outpatient liver transplant patients managed at LDS Hospital, Salt Lake City, this observational study compared traditional laboratory result reporting, using faxes and printouts, to computerized alerts implemented in 2004. Study alerts within the electronic health record notified clinicians of new results and overdue new orders for creatinine tests and immunosuppression drug levels. After implementing alerts, completeness of reporting increased from 66 to >99 %, as did positive predictive value that a report included new information (from 46 to >99 %). Timeliness of reporting and clinicians' responses improved after implementing alerts (p <0.001): median times for clinicians to receive and complete actions decreased to 9 hours from 33 hours using the prior traditional reporting system. Computerized alerts led to more efficient, complete, and timely management of laboratory information.

System analysis and improvement in the process of transplant patient care

Clinical information concerning transplant patients is voluminous and difficult to manage using paper records. A system analysis was performed to assess information system needs of the liver, kidney, and pancreas transplant program at LDS Hospital in Salt Lake City, Utah. After evaluating workflow, decision support needs, and requirements, we designed and implemented an extendable information system to support care following liver transplantation. We developed and implemented a standardized operative note, forms to enter external laboratory results and transplant-related information into the electronic health record, and computerized alerts to notify the transplant nurses when liver transplant patients had new, abnormal, or overdue laboratory results. The information system has improved the quality of clinical data available in the EHR, clinician satisfaction, and efficiency with management of laboratory results. The components developed for this project can be extended to meet other transplant program needs.

A case for manual entry of structured, coded laboratory data from multiple sources into an ambulatory electronic health record

Laboratory results provide necessary information for the management of ambulatory patients. To realize the benefits of an electronic health record (EHR) and coded laboratory data (e.g., decision support and improved data access and display), results from laboratories that are external to the health care enterprise need to be integrated with internal results. We describe the development and clinical impact of integrating external results into the EHR at Intermountain Health Care (IHC). During 2004, over 14,000 external laboratory results for 128 liver transplant patients were added to the EHR. The results were used to generate computerized alerts that assisted clinicians with managing laboratory tests in the ambulatory setting. The external results were sent from 85 different facilities and can now be viewed in the EHR integrated with IHC results. We encountered regulatory, logistic, economic, and data quality issues that should be of interest to others developing similar applications.

Development of an information model for storing organ donor data within an electronic medical record

OBJECTIVE

To develop a model to store information in an electronic medical record (EMR) for the management of transplant patients. The model for storing donor information must be designed to allow clinicians to access donor information from the transplant recipient's record and to allow donor data to be stored without needlessly proliferating new Logical Observation Identifier Names and Codes (LOINC) codes for already-coded laboratory tests.

DESIGN

Information required to manage transplant patients requires the use of a donor's medical information while caring for the transplant patient. Three strategies were considered: (1) link the transplant patient's EMR to the donor's EMR; (2) use pre-coordinated observation identifiers (i.e., LOINC codes with *(wedge)DONOR specified in the system axes) to identify donor data stored in the transplant patient's EMR; and (3) use an information model that allows donor information to be stored in the transplant patient's record by allowing the "source" of the data (donor) and the "name" of the result (e.g., blood type) to be post-coordinated in the transplant patient's EMR.

RESULTS

We selected the third strategy and implemented a flexible post-coordinated information model. There was no need to create new LOINC codes for already-coded laboratory tests. The model required that the data structure in the EMR allow for the storage of the "subject" of the test.

CONCLUSION

The selected strategy met our design requirements and provided an extendable information model to store donor data. This model can be used whenever it is necessary to refer to one patient's data from another patient's EMR.

Detailed clinical models for sharable, executable guidelines

The goal of shareable, executable clinical guidelines is both worthwhile and challenging. One of the largest hurdles is that of representing the necessary clinical information in a precise and shareable manner. Standard terminologies and common information models, such as the HL7 RIM, are necessary, they are not sufficient. In addition, common detailed clinical models are needed to give precise semantics and to make the task of mapping between models manageable. We discuss the experience of the SAGE project related to detailed clinical models.

Medical data abstractionism: fitting an EMR to radically evolving medical information systems

Growing and maintaining a simple and flexible EMR (Electronic Medical Record) becomes a complicated task in light of diverse and distributed legacy data representation, advancing technologies, changes in medical practice and procedure, and changes in data regulation. Utilizing several abstraction mechanisms can simplify application development and maintenance, and provide flexibility for data evolution and migration. Newer applications built on these abstractions can be the beneficiary of slower obsolescence and lower maintenance costs.

Integrating detailed clinical models into application development tools

Several groups are currently working on defining detailed clinical models (also called templates or archetypes) that are refinements of abstract medical models like the HL7 (Health Level Seven) Reference Information Model. At IHC, we have created over 3,000 detailed clinical models in the last five years. These models have become an essential part of the architecture of our electronic medical record (EMR) system. As a result, we have created an increasingly sophisticated set of tools that allow the models to be searched, viewed, and ultimately incorporated into medical applications. These browsers have some commonality with terminology browsers, but are distinct in that the explicit structure of the information models must be accommodated. In this paper we report our experience in making browsers for detailed clinical models that are integrated with application authoring tools.

Modeling guidelines for integration into clinical workflow

The success of clinical decision-support systems requires that they are seamlessly integrated into clinical workflow. In the SAGE project, which aims to create the technological infra-structure for implementing computable clinical practice guide-lines in enterprise settings, we created a deployment-driven methodology for developing guideline knowledge bases. It involves (1) identification of usage scenarios of guideline-based care in clinical workflow, (2) distillation and disambiguation of guideline knowledge relevant to these usage scenarios, (3) formalization of data elements and vocabulary used in the guideline, and (4) encoding of usage scenarios and guideline knowledge using an executable guideline model. This methodology makes explicit the points in the care process where guideline-based decision aids are appropriate and the roles of clinicians for whom the guideline-based assistance is intended. We have evaluated the methodology by simulating the deployment of an immunization guideline in a real clinical information system and by reconstructing the workflow context of a deployed decision-support system for guideline-based care. We discuss the implication of deployment-driven guideline encoding for sharability of executable guidelines.

Representing nursing assessments in clinical information systems using the logical observation identifiers, names, and codes database

In recent years, the Logical Observation Identifiers, Names, and Codes (LOINC) Database has been expanded to include assessment items of relevance to nursing and in 2002 met the criteria for "recognition" by the American Nurses Association. Assessment measures in LOINC include those related to vital signs, obstetric measurements, clinical assessment scales, assessments from standardized nursing terminologies, and research instruments. In order for LOINC to be of greater use in implementing information systems that support nursing practice, additional content is needed. Moreover, those implementing systems for nursing practice must be aware of the manner in which LOINC codes for assessments can be appropriately linked with other aspects of the nursing process such as diagnoses and interventions. Such linkages are necessary to document nursing contributions to healthcare outcomes within the context of a multidisciplinary care environment and to facilitate building of nursing knowledge from clinical practice. The purposes of this paper are to provide an overview of the LOINC database, to describe examples of assessments of relevance to nursing contained in LOINC, and to illustrate linkages of LOINC assessments with other nursing concepts.

Building a comprehensive clinical information system from components. The approach at Intermountain Health Care

OBJECTIVES

To discuss the advantages and disadvantages of an interfaced approach to clinical information systems architecture.

METHODS

After many years of internally building almost all components of a hospital clinical information system (HELP) at Intermountain Health Care, we changed our architectural approach as we chose to encompass ambulatory as well as acute care. We now seek to interface applications from a variety of sources (including some that we build ourselves) to a clinical data repository that contains a longitudinal electronic patient record.

RESULTS

We have a total of 820 instances of interfaces to 51 different applications. We process nearly 2 million transactions per day via our interface engine and feel that the reliability of the approach is acceptable. Interface costs constitute about four percent of our total information systems budget. The clinical database currently contains records for 1.45 m patients and the response time for a query is 0.19 sec.

DISCUSSION

Based upon our experience with both integrated (monolithic) and interfaced approaches, we conclude that for those with the expertise and resources to do so, the interfaced approach offers an attractive alternative to systems provided by a single vendor. We expect the advantages of this approach to increase as the costs of interfaces are reduced in the future as standards for vocabulary and messaging become increasingly mature and functional.

LOINC, a universal standard for identifying laboratory observations: a 5-year update

The Logical Observation Identifier Names and Codes (LOINC) database provides a universal code system for reporting laboratory and other clinical observations. Its purpose is to identify observations in electronic messages such as Health Level Seven (HL7) observation messages, so that when hospitals, health maintenance organizations, pharmaceutical manufacturers, researchers, and public health departments receive such messages from multiple sources, they can automatically file the results in the right slots of their medical records, research, and/or public health systems. For each observation, the database includes a code (of which 25 000 are laboratory test observations), a long formal name, a "short" 30-character name, and synonyms. The database comes with a mapping program called Regenstrief LOINC Mapping Assistant (RELMA(TM)) to assist the mapping of local test codes to LOINC codes and to facilitate browsing of the LOINC results. Both LOINC and RELMA are available at no cost from http://www.regenstrief.org/loinc/. The LOINC medical database carries records for >30 000 different observations. LOINC codes are being used by large reference laboratories and federal agencies, e.g., the CDC and the Department of Veterans Affairs, and are part of the Health Insurance Portability and Accountability Act (HIPAA) attachment proposal. Internationally, they have been adopted in Switzerland, Hong Kong, Australia, and Canada, and by the German national standards organization, the Deutsches Instituts für Normung. Laboratories should include LOINC codes in their outbound HL7 messages so that clinical and research clients can easily integrate these results into their clinical and research repositories. Laboratories should also encourage instrument vendors to deliver LOINC codes in their instrument outputs and demand LOINC codes in HL7 messages they get from reference laboratories to avoid the need to lump so many referral tests under the "send out lab" code.

Standards for detailed clinical models as the basis for medical data exchange and decision support

INTRODUCTION

Detailed clinical models are necessary to exchange medical data between heterogeneous computer systems and to maintain consistency in a longitudinal electronic medical record system. At Intermountain Health Care (IHC), we have a history of designing detailed clinical models. The purpose of this paper is to share our experience and the lessons we have learned over the last 5 years.

DESIGN

IHC's newest model is implemented using eXtensible Markup Language (XML) Schema as the formalism, and conforms to the Health Level Seven (HL7) version 3 data types. The centerpiece of the new strategy is the Clinical Event Model, which is a flexible name-value pair data structure that is tightly linked to a coded terminology.

DISCUSSION

We describe IHC's third-generation strategy for representing and implementing detailed clinical models, and discuss the reasons for this design.

Development of an information model for solid organ transplantation

Information required to manage transplant patients and donors is complex, voluminous and requires the reporting and use of one person's medical information within another person's record. One strategy using a vocabulary model (i.e., LOINC codes with *DONOR specified in the system axes) will lead to problems with combinatorial explosion. After evaluating workflow processes, data collection forms, decision support and functional requirements, we designed and implemented an extendable information model to support the process of care following liver transplantation.

The design and implementation of a picklist authoring tool

It is well recognized that controlled medical terminologies play a critical role in Health Information Systems and Clinical Patient Record systems, but the creation and management of customized lists of terms ("picklists") remains a potential obstacle. We have been developing a sophisticated authoring tool that is fully integrated with our terminology server and that will be made available to our system analysts and clinicians.

Development of a template model to represent the information content of chest radiology reports

The authors describe the application of a methodology for developing representational models for loosely structured medical domains. The methodology is subdivided in two interrelated tasks: terminology acquisition and template generation. The methodology is applied to the domain of chest radiology, producing a domain-specific lexicon and a series of templates to represent all the relevant clinical information stated on a chest x-ray report. Details about the successive application of the methodology and the resulting versions of the lexicon and templates are presented. The most relevant aspects of the methodology utilization are discussed and compared with evidence from other authors.