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.

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

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.

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.

A qualitative study of prevalent laboratory information systems and data communication patterns for genetic test reporting.

PURPOSE: The availability of genetic test data within the electronic health record (EHR) is a pillar of the US vision for an interoperable health IT infrastructure and a learning health system. Although EHRs have been highly investigated, evaluation of the information systems used by the genetic labs has received less attention-but is necessary for achieving optimal interoperability. This study aimed to characterize how US genetic testing labs handle their information processing tasks. METHODS: We followed a qualitative research method that included interviewing lab representatives and a panel discussion to characterize the information flow models. RESULTS: Ten labs participated in the study. We identified three generic lab system models and their relevant characteristics: a backbone system with additional specialized systems for interpreting genetic results, a brokering system that handles housekeeping and communication, and a single primary system for results interpretation and report generation. CONCLUSION: Labs have heterogeneous workflows and generally have a low adoption of standards when sending genetic test reports back to EHRs. Core interpretations are often delivered as free text, limiting their computational availability for clinical decision support tools. Increased provision of genetic test data in discrete and standard-based formats by labs will benefit individual and public health.

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.

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.

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.

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

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.

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.

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.

Quality metrics for detailed clinical models.

OBJECTIVE: To develop quality metrics for detailed clinical models (DCMs) and test their validity. METHODS: Based on existing quality criteria which did not include formal metrics, we developed quality metrics by applying the ISO/IEC 9126 software quality evaluation model. The face and content validity of the initial quality metrics were assessed by 9 international experts. Content validity was defined as agreement by over 70% of the panelists. For eliciting opinions and achieving consensus of the panelists, a two round Delphi survey was conducted. Valid quality metrics were considered reliable if agreement between two evaluators' assessments of two example DCMs was over 0.60 in terms of the kappa coefficient. After reliability and validity were tested, the final DCM quality metrics were selected. RESULTS: According to the results of the reliability test, the degree of agreement was high (a kappa coefficient of 0.73). Based on the results of the reliability test, 8 quality evaluation domains and 29 quality metrics were finalized as DCM quality metrics. CONCLUSION: Quality metrics were validated by a panel of international DCM experts. Therefore, we expect that the metrics, which constitute essential qualitative and quantitative quality requirements for DCMs, can be used to support rational decision-making by DCM developers and clinical users.

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.