| Literature DB >> 33385224 |
Meredith C McCormack, Rebecca Bascom, Michael Brandt, Felip Burgos, Sam Butler, Christopher Caggiano, Anne E F Dimmock, Adrian Fineberg, Jeffrey Goldstein, Francisco C Guzman, Cara N Halldin, J D Johnson, Gwendolyn S Kerby, Jerry A Krishnan, Laura Kurth, Gareth Morgan, Richard A Mularski, Cara B Pasquale, Julie Ryu, Tom Sinclair, Nadia F Stachowicz, Ann Taite, Jacob Tilles, Jennifer R Truta, David N Weissman, Tianshi David Wu, Barbara P Yawn, M Bradley Drummond.
Abstract
A workshop "Electronic Health Records and Pulmonary Function Data: Developing an Interoperability Roadmap" was held at the American Thoracic Society 2019 International Conference. "Interoperability" is defined as is the ability of different information-technology systems and software applications to directly communicate, exchange data, and use the information that has been exchanged. At present, pulmonary function test (PFT) equipment is not required to be interoperable with other clinical data systems, including electronic health records (EHRs). For this workshop, we assembled a diverse group of experts and stakeholders, including representatives from patient-advocacy groups, adult and pediatric general and pulmonary medicine, informatics, government and healthcare organizations, pulmonary function laboratories, and EHR and PFT equipment and software companies. The participants were tasked with two overarching Aobjectives: 1) identifying the key obstacles to achieving interoperability of PFT systems and the EHR and 2) recommending solutions to the identified obstacles. Successful interoperability of PFT data with the EHR impacts the full scope of individual patient health and clinical care, population health, and research. The existing EHR-PFT device platforms lack sufficient data standardization to promote interoperability. Cost is a major obstacle to PFT-EHR interoperability, and incentives are insufficient to justify the needed investment. The current vendor-EHR system lacks sufficient flexibility, thereby impeding interoperability. To advance the goal of achieving interoperability, next steps include identifying and standardizing priority PFT data elements. To increase the motivation of stakeholders to invest in this effort, it is necessary to demonstrate the benefits of PFT interoperability across patient care and population health.Entities:
Keywords: electronic health record; interoperability; pulmonary function testing
Mesh:
Year: 2021 PMID: 33385224 PMCID: PMC7780974 DOI: 10.1513/AnnalsATS.202010-1318ST
Source DB: PubMed Journal: Ann Am Thorac Soc ISSN: 2325-6621
Glossary of terms relevant to PFT–EHR interoperability
| APIs ( | An API is an interface that allows unrelated software programs to communicate with one another. They act as bridges between two applications, allowing data to flow regardless of how each application was originally designed. |
| Connectivity ( | The ability to connect to or communicate with another computer or computer system. |
| EHR ( | An electronic record of health-related information on an individual that conforms to nationally recognized interoperability standards and that can be created, managed, and consulted by authorized clinicians and staff across more than one healthcare organization. |
| FHIR ( | FHIR (pronounced “fire”) is a standard for exchanging healthcare information electronically, describing data formats and elements (known as "resources"). The standard was created by the HL7 healthcare standards organization. |
| HEDIS ( | HEDIS is one of health care’s most widely used performance-improvement tools. HEDIS includes more than 90 measures across 6 domains of care. Health plans collect data about their performance on certain services and types of care. They report the data to the NCQA, which rates health plans. Health plans use HEDIS to see where they are performing well and where they need to improve. Employers and consumers can also use HEDIS measures when deciding what health plan to choose. |
| HL7 International ( | The HL7 standards are produced by HL7 International, an international standards organization. HL7 and its members provide a framework (and related standards) for the exchange, integration, sharing, and retrieval of electronic health information. These standards define how information is packaged and communicated from one party to another, setting the language, structure, and data types required for seamless integration between systems. HL7 standards support clinical practice and the management, delivery, and evaluation of health services and are recognized as the most commonly used in the world. |
| Interoperability ( | In health care, interoperability is the ability of different information-technology systems and software applications to communicate; to exchange data accurately, effectively, and consistently; and to use the information that has been exchanged. |
| Integration ( | Integration is the process of combining multiple different, often disparate, subsystems to function together as a unified whole. This often includes building of customized architecture or structure of applications (“middleware”). Conceptually, the difference between interoperability and integration can be likened to the difference between having a conversation in a common language (interoperability) and having a conversation through an interpreter (integration). |
| LOINC ( | LOINC were developed to provide a definitive standard for identifying clinical information in electronic reports. The LOINC database provides a set of universal names and ID codes for identifying laboratory and clinical test results. LOINC are intended to identify the test result or clinical observation. |
| NCQA ( | The NCQA is an independent U.S. nonprofit organization that works to improve the quality of health care through standardized measures and accreditation. |
| SNOMED ( | SNOMED is a not-for-profit organization with a mission to produce and enhance the vocabulary that enables the clear exchange of health information for all. SNOMED owns and operates SNOMED CT, a systematically organized collection of medical terms standardized for use in the electronic exchange of medical information. SNOMED CT provides codes, terms, synonyms, and definitions used in clinical documentation and reporting. |
| SQL ( | SQL (pronounced “sequel”) is a standardized programming language that is used to operate databases. SQL is a standard language that facilitates management of relational databases and performance of various operations (deletion, fetching, modifying) on the data in databases. |
Definition of abbreviations: API = application-programming interface; CT = Clinical Terms; EHR = electronic health record; FHIR = Fast Healthcare Interoperability Resources; HEDIS = Healthcare Effectiveness Data and Information Set; HL7 = Health Level 7; ID = identifier; LOINC = Logical Observation Identifiers Names and Codes; NCQA = National Committee for Quality Assurance; PFT = pulmonary function test; SNOMED = Systematized Nomenclature of Medicine; SQL = Structured Query Language.
Key obstacles to PFT–EHR interoperability by stakeholder group
| Stakeholder Group | Identified Obstacles |
|---|---|
| The patient | • Evolving technologies require evolving integration |
| • Limited approaches to address home data collection and desire for an app | |
| • Lack of seamless information connectivity across time and geography | |
| The clinician or researcher | • Complex steps to extract data from EHR into clinical notes |
| • Heterogeneous PFT data types and sites of data storage preclude monitoring trends over time for an individual patient from childhood through adult life | |
| • Limitations of EHRs in primary care and limited information exchange between primary care providers and specialists impairs continuity of care | |
| • PFT data are often sequestered. For example, PFT data obtained on a person as part of their workplace screening is not incorporated into their health record and is therefore unavailable when they develop a health problem later in life | |
| • Inability to integrate images into the EHR limits ability to assess flow-volume loops and other quality metrics | |
| • Lack of metadata to indicate quality of testing | |
| • Interfacing costs and lack of clear value to reimbursement and healthcare outcomes | |
| • Clinically generated PFT data lacks uniform, discrete, structured data elements | |
| • Inability to retrofit existing PFT data because of cost and person-hour limitations | |
| • Inability to integrate PFT data with data regarding underlying disease type and severity | |
| • Raw data underlying flow-volume curves needed to assess technical errors with greater precision are generally not provided | |
| The device manufacturers | • Lack of IT resources from purchasers |
| • Lack of open application-programming interfaces for clinical data | |
| • Lack of consensus on which discrete variables should be sent to the EHR. Decisions on variables sent from vendors to EHRs are usually left up to the lead physician, with high variation between interfaces | |
| • Electronic PFT forms represent a streamlined version of a full report, potentially losing crucial data if certain variables are selected. However, more data fields (particularly if manual entry or curation is required) can lead to more errors | |
| • Poor interoperability at the health system level | |
| • Need for adequate connectivity to support data transfer from devices to EHRs | |
| • Lack of incentives by customer to link PFT data to the EHR (i.e., lack of incorporation of interoperability into laboratory certification) | |
| • Lack of variable-naming conventions, including multiple LOINC depending on the context of data acquisition | |
| • Lack of subject-matter expertise among clients. PFT directors often do not possess the IT knowledge needed for pre–interoperability-assessment needs, and IT departments do not possess the intimate knowledge needed to understand the needs of the PFT laboratory and/or healthcare stakeholders | |
| • Lack of common data model and interoperability standard by societies | |
| The EHR companies | • Data-output formats and fields vary across devices inputting into the EHR |
| • Compatibility with the EHR varies across devices | |
| • Variation in PFT orders linked to testing | |
| • Multiple PFT devices/vendors within single customer base | |
| • Lack of willingness of PFT vendors to interface discrete data with EHRs | |
| • Lack of variable-naming conventions and incomplete or duplicate LOINC | |
| • PFT data not prioritized for standardization by organizational bodies (FHIR) | |
| • Lack of common data model and interoperability standard by societies |
Definition of abbreviations: EHR = electronic health record; FHIR = Fast Healthcare Interoperability Resources; IT = information technology; LOINC = Logical Observation Identifiers Names and Codes; PFT = pulmonary function test.
Solutions by theme
| Lack of common data elements and definitions | 1. Creation of a standard library of terms |
| 2. Standard format | |
| 3. Identification of common data elements endorsed by ATS and academic thought leaders/societies | |
| 4. Standard application-programming interfaces in the future | |
| Lack of institutional priority and cost considerations and lack of motivators to influence stakeholders | 1. Patient groups as advocates |
| 2. Meaningful use metrics | |
| 3. Endorsement of medical societies | |
| 4. Demonstration that investment increases efficiency and reduces costs over long term | |
| 5. PFT data are recognized as a priority, similar to blood pressure or HbA1C | |
| Lack of flexible implementation | 1. Standard API |
| 2. Lower costs | |
| 3. Solutions to communicating quality | |
| 4. Consideration of legacy systems and retrofitting | |
| 5. Education and dissemination |
Definition of abbreviations: API = application-programming interface; ATS = American Thoracic Society; HbA1c = hemoglobin A1c; PFT = pulmonary function test.
Figure 1.An overview of the flow of PFT–electronic health record (EHR) interoperability and integration. *The three EHRs represent large-healthcare-system, small-single-hospital, and outpatient-office relationships. PFT = pulmonary function test.
Examples of value of successful interoperability by stakeholder group
| The patient | • The patient is able to track PFT data from early childhood to adulthood with integration of data across healthcare systems throughout the lifetime. |
| • Results are accessible to providers in general and specialty care and in different geographic regions. | |
| The clinician | • Physicians have access to historical lung function information for a given patient who has been evaluated in different health systems to diagnose the onset of disease. |
| • Enhanced ability to observe trends in lung function over time to monitor patients with chronic disease. | |
| • Quality metrics provide a greater ability to factor in data quality. | |
| The clinician–researcher | • Data would be easily extractable within a healthcare system to foster discovery. |
| • Quality metrics would be more uniform to increase data quality and reduce bias. | |
| Device manufacturers | • Standard output would make output uniform between clients so that interfacing with EHR companies would be uniform. |
| • Enhanced efficiency. | |
| EHR | • Inputs would be standard so that interfacing data from PFT vendors would be uniform. Output of data to end-users’ healthcare providers and patients would be standardized, with minor customizations based on patient complexity. |
| • Enhanced efficiency. | |
| Population health/all stakeholders | • Population health research can be amplified using data analytics and big data. This will facilitate study of risk factors, protective factors to promote optimal lung development and lung health, and interventions. |
Definition of abbreviations: EHR = electronic health record; PFT = pulmonary function test.