Electronic Health Record Data in Cancer Learning Health Systems: Challenges and Opportunities

INTRODUCTION

If electronic health records (EHRs)¹ are ubiquitous in health care, then why are EHR data so difficult to access and use? Since their inception in the 1970s, EHRs have been envisioned to transform how health systems generate and use knowledge,^2-6 including in oncology.^7,8 Federal investments from the 2010 Health Information Technology for Economic and Clinical Health (HITECH) Act^9-11 led to near-universal EHR adoption by 2017 in nonfederal acute care settings (96%) and high adoption in clinics (80%).^12-14 In parallel, the learning health system (LHS) model was born, which seeks to use EHR and other data on patients and patient care processes to increase quality at reduced cost.^15,16

CONTEXT

• Key Objective

• To provide a narrative review of challenges and opportunities with electronic health record (EHR) data, including interoperability and integration with other data sources, impacts on cancer research and cancer care, and promising directions for next-generation EHR technologies.

• Knowledge Generated

• Although federal EHR technology investments had disappointing results, they were necessary to start digitizing the nation's health care data and set the stage for a promising future. An architecture focused on application programming interfaces and data standards provides a flexible approach that is highly likely to accommodate precision oncology and enable a rapid learning health system.

• Relevance

• New EHR technologies promise to support all levels of the data-information-knowledge-wisdom pyramid through efficient capture of clinical and molecular data on individuals, visualization of longitudinal context of care (information), use of real-world data to enable new and rapid modes of cancer research (knowledge), and clinical decision support driven by near real-time analyses of patient populations (wisdom).

The reality of EHRs has been mixed. Early studies showed potential to optimize work processes; provide information gathering, summarization, reminders, and clinical decision support (CDS)¹⁷; improve quality; and lower costs.^18,19 However, recent studies have shown that EHRs require provider workarounds that negatively affect ability to access or write information reliably, leading to burnout^20-23 and inefficient and lower quality care delivery.^24,25

The LHS model has limited support from current EHRs. It needs readily available population data, but most EHRs only support querying a patient at a time. Pooling EHR data for regional and national LHS analyses is arduous. Oncology's precision medicine transformation from hundreds of diagnoses to thousands of distinct cancer subtypes driven by molecular testing^26-29 places unique burdens on EHRs,⁸ which were not designed for molecular data.³⁰ In addition, precision oncology requires synergy between the clinic and academic research that is ill supported by current EHRs.

This narrative review articulates how interoperability and other EHR technology issues have held back the oncology LHS, and it describes promising directions involving industry and academia for improving data and software integration and interoperability.

EHR LIMITATIONS

Incumbent EHR vendors in the United States used 1990s client-server software architecture^31,32 for their products. Although innovative compared with previous terminal-based systems, today, these EHRs often lack functionality found in consumer software, were not designed for the open data exchange needed in modern clinical practice, and put hospitals at the center of care not patients. In addition, their centralized information technology (IT) management model restricts provider customization and experimentation, which was commonplace in paper charts, and makes customization slow and expensive.^33-35 High purchase prices, disruption to health care operations from switching EHRs, vendor reluctance to implement interoperability with competing products, and complex regulations that new market entrants must implement have entrenched these technologies.

Furthermore, IT spending by US health care institutions has lagged other nations and other industries with complex needs,^18,36-39 limiting institutions' ability to augment vendor EHRs or even fully implement what vendors provide. Rigorous evaluation through implementation science⁴⁰ is needed to guide EHR implementations, but such evaluations can cost nearly as much as implementing the technology itself,⁴¹ which is likely part of why they are rarely done.⁴² Outsourcing EHR-related IT, as some health systems have attempted,⁴³ is puzzling because digital transformation cannot happen if executives view informatics as outside of their organization's core competencies. As a result, most EHR implementations have numerous clinical and research limitations.

Clinical Limitations of Current EHRs

HITECH defined basic and comprehensive EHRs. Basic EHRs, shown in Figure 1, essentially duplicate the paper chart in electronic form. Comprehensive EHRs add simple data interpretations like threshold checks on numerical observations without regard for context. A total white count of 100,000 in a patient with no known blood cancer, a patient with acute leukemia, and a chronic lymphocytic leukemia patient with a steady white count for half a decade have drastically different implications, yet EHRs will detect this finding as critical in all three patients. Oncologists need dynamic longitudinal views that contextualize findings.

FIG 1.

Depiction of current EHRs in a LHS. Although current EHRs provide longitudinal patient data storage, they typically visualize only snapshots of the state of individual patients. In addition, they provide little support for research uses of the data or stakeholder decision making to improve care quality at lower cost. This figure depicts a snapshot view of four patients' medical records, accessed by their providers (red arrows), with no patient population view. EHR, electronic health record; LHS, learning health system.

Comprehensive EHRs also provide alerting⁴⁴ that relies on clinical guideline development and manual curation of business rules that are triggered by patterns in laboratory test results, diagnosis codes, medications, and the like. This approach to authoring alerts cannot keep up with the pace of clinically actionable new knowledge.⁴⁵ Furthermore, the accuracy of such rules is frequently low, leading many providers to override CDS alerts habitually.⁴⁶

These visualizations and checks are limited partly because 80% of EHR data are in unstructured documents that EHRs cannot parse.^47,48 A provider signing off on a note detailing a patient with shortness of breath because of end-of-life lung cancer will be asked by the EHR to duplicate the chief complaint in a structured field and order a prostate-specific antigen test. Cancer stage, histopathologic biomarkers, smoking status, clinical genetic testing, and other pertinent cancer data and provider interpretations of it are typically found in text notes that are unavailable to CDS.

Physician burnout has arisen from using these EHRs. Causes include information overload,^49,50 increased complexity of cognitive work,⁵¹ excessive data entry driven by billing and administrative requirements, inefficient user interfaces, click fatigue,⁵² inadequate data exchange with other providers, and EHR-related workflows that interfere with the physician-patient relationship.²² Cancer is a complex set of diseases in which information overload in EHRs may be exacerbated.⁸ Patient safety measures like medication reconciliation, implemented through burdensome EHR workflows, have also contributed to burnout.¹⁹ The same problems result in information input and output errors and adversely affect care safety and efficiency.^53,54 This has been noted in studies worldwide and for different provider roles and levels of training.^55-57

Inadequate data exchange between providers is largely due to inadequate EHR data standardization. Most EHR implementations have site-specific codes that are ill documented. Where standards may be used, like Logical Observation Identifiers Names and Codes (LOINC) for clinical laboratory test results,⁵⁸ codes may be applied inconsistently from one institution to another. Cancer-specific data are complex and would especially benefit from structured data representation and standardization. Disease classification standards used in EHRs, like the Systematic Nomenclature of Medicine—Clinical Terms (SNOMED-CT) used in EHR problem lists⁵⁹ and structured pathology reporting,⁶⁰ frequently classify cancer types by histology and location but not molecular testing although clinical genetic testing has become routine.⁶¹

Furthermore, data quality has plagued EHRs. Administrative coding systems like International Classification of Diseases version 10 have too many codes for providers and coders to document accurately without substantial computer support,^62-64 and these codes document billing, not patient care. Problem lists, ostensibly a clinical representation of a patient's conditions, are frequently inaccurate, incomplete, and out-of-date because of burdensome data entry.⁶⁵ EHRs were recognized early in their history to potentially cause the recording of a greater quantity of bad data compared with paper, leading to the first law of informatics in 1991 stating that data shall be used only for the purpose for which they were collected.⁶⁶ In the decades since the first law, health care has found value in reusing EHR data, but the data's limitations are insufficiently understood.

Research Limitations of Current EHRs

EHR data are typically available for academic and operational research through a relational database called an Enterprise Data Warehouse (EDW),^67-69 which may be refreshed daily to quarterly. Maintaining an EDW requires expertise that only larger health systems typically have, and even basic queries require substantial informatics support. EHR vendors increasingly provide self-service population query tools that are updated in near real time, but these tools often provide neither access to historical data before the EHR's implementation nor data stored in ancillary systems.

Data problems in EDWs affect the data's fitness for use in research.^70,71 They include infrequent refreshes, left censoring (the first instance of disease may not be when the disease first manifested), right censoring (the data may not cover a long enough time interval), missing data from other clinical and nonclinical settings, institutional and personal variation in practice and documentation styles, and inconsistent use of medical codes.⁷² Misunderstanding these challenges has led to multiple retractions in major journals.⁷³ Efforts to increase EDW data completeness and quality are frequently framed as a need for more structured data entry in EHRs, but research needs must be balanced with already-excessive provider documentation requirements.

Chart abstraction and harmonizing⁷⁴ EDWs to standards are resource-intensive but increasingly necessary to participate in clinical research networks. Ill-documented local codes and mappings to standards require extensive informatics support to understand. Local codes tend to change without warning to the research community, resulting in corrupted data.^15,75,76 Data located in text notes must be abstracted manually or parsed from the EHR's database using natural language processing (NLP).⁷⁷

Other informatics challenges in EDWs include complicated data models that appear markedly different from how the same data appear in the EHR. Data visible in the EHR as scanned image files, such as clinical genetic test results, are usually unavailable in EDWs. Even when genetic testing is available, its use in research is often hampered by the absence of linkages to sequencing data. Extracting clinical concepts, exposures, and outcomes for studies and applying inclusion and exclusion criteria are challenging even for the most experienced data analysts.

Policies also hamper EDW use in research. Budget limitations and governance conflicts between the research and clinical sides of academic institutions tend to result in research needs getting low priority.⁷⁸ When EHRs are outsourced as described above, the EHR vendor may charge for research access, thus increasing costs to researchers. In addition, although security and privacy concerns^29,79 rightly necessitate carefully crafted access policies, many institutions simply restrict access. Safe harbor deidentification defined by the Health Insurance Portability and Accountability Act may alleviate privacy concerns but removes critical information such as seasonality.⁸⁰ Furthermore, there is frequently an overlap between data capture forms used for patient care and research, but institutions may have separate clinical and research data capture policies, forcing investigators through a quagmire to get their work done and severely hampering integration between patient care and research needed to realize a LHS.⁸¹

THE LHS

The LHS encompasses infrastructure, governance, incentives, and shared values to harness data and analytics to learn from every patient, on the basis of real-world care process and outcomes data drawn primarily from EHRs.^16,82 The LHS aims to feed this knowledge back to clinicians, informaticians, data scientists, public health professionals, patients, and other stakeholders to create cycles of continuous improvement.^16,82,83 To realize this vision in oncology, EHRs must go beyond HITECH's comprehensive EHR requirements to improve patient care, better connect patients and their oncologists, and provide seamless data flows between clinical and research missions.⁷

The data-information-knowledge-wisdom pyramid,^84,85 shown in Figure 2, describes LHS data flows starting with capturing data on individuals (Fig 1); data cleaning, validation, and interpretation to form information, shown in Figure 3; developing insights that add to knowledge about similar patients, shown in Figure 4; and taking wise action, shown in Figure 5. EHR limitations create barriers at all levels of the pyramid, but with sufficient IT investments, opportunities exist to address them. Table 1 links topics in the research and clinical opportunities subsections below to each data-information-knowledge-wisdom level.

FIG 2.

Illustration of the DIKW pyramid. It provides a framework for understanding how future EHRs need to better support abstraction of data into information, and inference of knowledge from information, to help providers and other stakeholders gain wisdom to realize the learning health system's overall goal of improving care quality at lower cost. DIKW, Data-Information-Knowledge-Wisdom; EHR, electronic health record; LHS, learning health system.

FIG 3.

Longitudinal data abstraction on Patient 1's medical record (gold arrows) and interpretation of Patient 1's data to form information, the second level in the DIKW pyramid (Fig 2). Current EHRs typically display only snapshot views (thin gray arrows, Fig 1). With the ability to interpret longitudinal data, future EHRs could visualize a patient's cancer journey and provide basic support for correlating clinical features with genetic testing over time. DIKW, Data-Information-Knowledge-Wisdom; EHR, electronic health record.

FIG 4.

Future EHRs providing longitudinal individual information (Fig 3, gold arrows) and population information (light blue arrows) to better guide patient care and inform continuous quality improvement efforts. With such EHRs, providers, stakeholders, and researchers may more easily generate knowledge through insights gained from advanced visualizations and clinical decision support. Knowledge is the third level in the DIKW pyramid. DIKW, Data-Information-Knowledge-Wisdom; EHR, electronic health record.

FIG 5.

Implementation of new care processes in a LHS (blue arrow), in part through evolving the EHR (cyclic arrows) in response to knowledge about a patient population gained from advanced visualizations and clinical decision support (Fig 4). Transforming knowledge into action is the top level of the DIKW pyramid (Wisdom). DIKW, Data-Information-Knowledge-Wisdom; EHR, electronic health record; LHS, learning health system.

TABLE 1.

Electronic Health Record-Related Technologies Supporting the Cancer Learning Health System, Organized by Level in the Data-Information-Knowledge-Wisdom Pyramid

Clinical Opportunities

The Quality Oncology Practice Initiative¹¹³ took initial steps toward creating an oncology LHS by combining patient-reported surveys and manually abstracted EHR data from seven practice groups to study clinical practice variation. Improvements in compliance with practice benchmarks were highest when relevant information was in the EHR,¹¹⁴ but the heterogeneity of cancer cases limited the effectiveness of chart abstraction-based data capture.

A rapid LHS aims to replace manual chart abstraction with near-real-time data flow from EHRs. In this future vision, EHRs will automatically mine and render genotypic and phenotypic data⁸⁶ together with the latest evidence for clinical decision making.²⁷ Clinical outcomes will lead to iterative knowledge refinement and new research studies that may ultimately result in further practice changes.^8,29,115 This approach may be of particular value for patients with late-stage cancer for whom treatment benefits are less clear.

Early rapid LHS adopters developed a proof-of-concept iPad-based CDS system called Substitutable Medical Applications and Reusable Technologies (SMART) Precision Cancer Medicine (PCM).¹¹¹ SMART PCM supports providers and patients in collaboratively reviewing the patient's mutation status in the context of a continuously updated database of patients with similar mutations and linkages to other data and knowledge. CUSTOM-SEQ (Continuously Updating System for Tracking Outcome by Mutation to Support Evidence-based Querying) calculates and displays mutation-specific survival statistics.¹¹² Decision precision is a lung cancer screening application for shared decision making between patients and providers about screening.⁴¹ These applications are tightly integrated into EHRs, and they rely on availability of structured clinical genetic test results, which have begun to be supported by major EHR vendors, for example, Epic's genomics module.¹¹⁶ Similar technologies may allow automated capture of patient-reported data in EHRs, for example, Apple HealthKit, thus reducing provider data entry and potentially increasing patient engagement.^19,117,118

A prerequisite of this tight integration is shared data models between EHRs and apps.⁷⁸ Early oncology data models include electronic Clinical Oncology Treatment Plan and Summary, which builds upon a health care data exchange standard from Health Level Seven International¹¹⁹ called Clinical Document Architecture.¹⁰¹ Its successor, Minimal Common Oncology Data Elements (mCODE), is built upon a Clinical Document Architecture replacement called FHIR (Fast Healthcare Interoperability Resources) that is new but is already used by SMART PCM, HealthKit, and other apps.⁸⁸ As important as shared data models are, structured data are unlikely to replace all text notes as information sources for CDS. Thus, EHR vendors have begun introducing NLP-based document indexing that extracts clinical events and observations from text notes automatically.

Machine learning may further accelerate creating apps that reason with continuously updated knowledge inferred from EHRs.^102,103 Potential applications include cohort identification¹²⁰ and prediction of future events, prognosis, and outcomes.¹⁰² In addition, machine learning may simplify provider interactions with EHRs through speech recognition^102,121 and reducing data entry through improved NLP.¹²² Unsolved challenges include burdensome provider time to label cases, trained algorithms' lack of generalizability from one disease condition to another, no way to run clinical trials of trained models in the clinical environment, and no way to incorporate validated models into EHRs. Newer machine learning methods like deep learning require less data preprocessing and training than prior techniques,¹⁰⁴ but more work is needed. Integrated academic and clinical missions are required to support algorithm development, evaluation, and implementation.

Research Opportunities

Clinical practice knowledge inferred from EHRs may complement traditional scientific discovery, embodied by the clinical trial.¹²³ Two to three percent of patients participate in trials.²⁹ Although the participation rate in cancer trials may be somewhat higher,¹²⁴ such low participation may result in under-representing older patients, racial and ethnic minorities, comorbidities, and low socioeconomic status, which are present in real-world EHR data.^125,126 In addition, data collection in clinical trials is expensive, and trials are slow to yield results and affect patient care.⁹⁷ Real-world evidence-based studies will not fully replace clinical trials, and careful attention to established guidelines in using such data is needed,⁷³ but appropriate use of EHR data may yield results faster and at lower cost.

Potential studies include comparing anticancer drug combinations and their timing and identifying unexpected associations between clinical events, prognoses, and outcomes, for example, comorbidities associated with poorer chemotherapeutic response.¹¹⁵ Population-based disparities such as geographic differences in cancer outcomes could point toward epidemiologic and performance hypotheses. Such associations can support predictive modeling of individual prognosis and outcomes.

Furthermore, integrating EHR data with health department, social media, and other data could increase statistical power and increase the likelihood of new genetic variant associations and other discoveries.^127,128 EHR data could boost cancer registries¹⁰⁵ such as the SEER program¹⁰⁶ and the National Program for Cancer Registries¹⁰⁷ through enhanced data capture and linkage. Early examples include CancerLinQ, which harmonizes EHR and SEER data for quality improvement and research,⁹⁷ and the National Childhood Cancer Registry,¹⁰⁸ which links tumor registry data with EHR data from National Cancer Institute (NCI)–designated cancer centers.

Integrating regional and national data from many EHRs also shows promise. Examples that support oncology research include the Oncology Research Information Exchange Network,⁹⁴ the Patient-Centered Outcomes Research Network,⁸⁷ the Observational Health Data Sciences and Informatics (OHDSI) initiative,⁷⁶ the All of Us Research Program,¹²⁹ and the Genomics Evidence Neoplasia Information Exchange (GENIE) network.⁹⁸ Oncology Research Information Exchange Network, All of Us, and GENIE capture genetic data and link them with clinical data. OHDSI provides an open-source repository of statistical analysis scripts that make correct use of multisite EHR data.^130,131

Research networks use many of the same vocabularies as CDS, but more work is needed to expand and augment them. For example, like SNOMED-CT, the International Classification of Diseases for Oncology used by tumor registries⁹⁰ classifies cancer types by histology and location but not molecular testing. OncoTree, used by GENIE, shows promise for additionally classifying cancers by genotype.⁹¹ The NCI Thesaurus aims to provide broad coverage of clinical and molecular concepts in oncology and relationships between them⁹³ and is used by the National Childhood Cancer Registry for annotating data contributions. HemOnc aims to represent chemotherapeutic regimens at OHDSI sites,⁹² expanding upon SNOMED-CT and the NCI Thesaurus. Continuous development of vocabularies for both patient care and research is needed to move data through capture, interpretation, knowledge generation, and CDS (wisdom) steps of the LHS.

REIMAGINING THE EHR

The above EHR opportunities represent substantial changes and are unlikely to be realized through purely incremental improvement of existing EHRs. The American Medical Informatics Association EHR-2020 Task Force¹⁹ and the JASON advisory group report¹²⁷ proposed similar visions for next-generation EHRs that advance the state-of-the-art by enabling new market entrants to invent advanced functionality that integrates seamlessly with hospital and clinic databases.

Their recommendations focus on reducing manual data entry through multiple approaches, including NLP⁴⁷; alternative data entry modes like voice and handwriting recognition; patient portal and mobile device integration with EHRs; interoperability between EHRs and ancillary systems¹³²; and broadening the settings in which EHRs operate to home health, pharmacy, population health, long-term care, and physical and behavioral therapy centers. With these changes, providers could refocus manual documentation on data elements that contribute to patient outcomes rather than billing and administration.

EHR data are among the most granular available, and sequencing data are even more so.¹²⁸ Patient privacy concerns with health care big data²⁹ legitimately increase as the volume of data held in EHRs increases, as do security concerns when a breach could affect so many patients. Such detailed data could be nearly impossible to deidentify because of unique data patterns that only one individual has.¹²⁷ Next-generation EHRs will require advanced encryption to ensure security, privacy, and patients' trust in the clinical and research communities.

Additional recommendations include restoring the academic informatics community's role in EHR technology advancement, which was common in early EHR implementations but lost when academic centers adopted vendor systems. Many promising CDS and other methods from the informatics community remain unimplemented by vendors, and site-specific customization requests to vendors tend to receive low priority, creating suboptimal fit with local operational processes.

Both reports propose an open EHR architecture composed of third-party best-of-breed applications, available in an app store for health systems to purchase in different combinations. Health systems would also purchase a software foundation that provides apps with authentication, authorization, encryption, databases, protocols for reading and writing data, terminologies, and patient and encounter data models. The foundation would have application programming interfaces (APIs) for apps to access its capabilities, connect to other apps and comprise a cohesive system. Like how the Apple app store catalyzed the popularity of the iPhone on the basis of its iOS foundation, EHR APIs would allow a software marketplace to form. If all software foundation vendors shared the same APIs, new market entrants could write apps once for use anywhere with a standards-compliant foundation.

Early versions of this architecture extended current EHRs with sidecar¹³³ software that connects to any EHR's database and presents standardized data views on the basis of a common data model (CDM),⁹⁶ primarily in support of research. Sidecars include i2b2, using a flexible star schema¹³⁴; OHDSI, using the Observational Medical Outcomes Partnership (OMOP) CDM¹³⁵; Patient-Centered Outcomes Research Network, using the Patient-Centered Outcomes Research Institute CDM⁸⁷; and TriNetX, using a proprietary CDM.⁹⁶ Sidecars access data the same way as EDWs and require similar levels of provider resourcing. Data movement is typically one way from EHRs into the sidecar, limiting support for patient care. Services like CancerLinQ,⁹⁷ Flatiron,⁹⁵ and Health Catalyst Data Operating System¹³⁶ moved the sidecar into the cloud but similarly rely on one-way EDW-style data movement from EHRs into the services.

The SMART project¹⁰⁹ went a step further by creating a standardized API on top of these sidecars for building apps.¹³⁷ SMART apps use FHIR for data exchange,^99,100 and existing EHRs can eliminate the sidecar and implement the API directly. Cerner, Epic, Athenahealth, and others support SMART on FHIR to some degree, and more than 500 hospitals have begun using SMART on FHIR apps,¹¹⁰ including ours.⁴¹

The above SMART PCM application is an example of SMART on FHIR in oncology. Compass linked mCODE data elements in an EHR with data from similar patients extracted from CancerLinQ.¹³⁸ The Integrating Clinical Trials and Real-World Endpoints app supported an Alliance for Clinical Trials in Oncology study using real-world data.¹³⁸ Compass and Integrating Clinical Trials and Real-World Endpoints were pilot projects leading to the development of mCODE, which future SMART apps in oncology will likely rely upon. Epic's App Orchard effectively provides an app store in the health care space.

Over time, a new software foundation would replace current EHRs and EDWs. Functionality would include a fully encrypted database permitting selective data decryption according to fine-grained access granted by patients together with their providers. Flexible data storage would permit high-performance query, extraction, and visualization of patient and population data in a variety of clinical and research contexts. Existing apps would continue to function as before because the new foundation would implement extensions of existing APIs that add functionality without breaking current capabilities. Cost-effective means of formally evaluating these technologies are needed to ensure that they have the desired impact on patient care and research.

In summary, EHRs began as highly customized tools developed by academic medical centers.¹³⁹ Initial systems were replaced by one-size-fits-all vendor EHRs that are deployed widely but have limited support for oncology. The informatics community has envisioned a new architecture that returns to permitting the innovation and customization required to realize the LHS. The adoption of SMART on FHIR by vendor EHRs will allow this new architecture to be studied and fine-tuned in the real world before ultimately replacing current EHRs with new technologies.

Challenges include scaling SMART to a vision of EHRs as a collection of applications that providers compose according to need. Apps are envisioned as independent and connected to a foundation. However, it is easy to imagine a CDS app needing to connect directly to a data visualization app because the foundation does not yet support the necessary integrations. Unless informatics architectures and governance support interoperability between apps in an organized fashion, chaos could ensue as many-to-many relationships form between apps.

Before one-size-fits-all EHRs, many institutions mixed paper charts with best-of-breed applications, typically for billing and pathology and radiology reports.⁴ Institutions migrated to legacy EHRs in part to simplify purchasing and obtain vendor support for integrations between EHR components.¹⁴⁰ Perhaps vendors will emerge who package and support sets of interoperable SMART on FHIR apps for oncology and other subspecialties.

The SMART and FHIR standards need performant population query capability to realize the LHS. FHIR was recently extended with EDW-style bulk query,¹⁴¹ but EHR vendors have yet to implement it. EHRs have data gaps and performance bottlenecks when querying large data volumes using FHIR, and thus, the sidecar remains the only working solution for bulk queries. Interoperability between EHR data and high-value oncology data like SEER and National Program for Cancer Registries is also needed.

Despite these challenges, this new API-centric and interoperability-focused architecture is a flexible approach that is highly likely to accommodate the needs of precision oncology. Results from HITECH have been disappointing, but HITECH was a necessary step toward digitizing the nation's health care data and setting the stage for a promising future.

AUTHOR CONTRIBUTIONS

Conception and design: All authors

Financial support: Andrew R. Post

Administrative support: Andrew R. Post

Provision of study material or patients: Andrew R. Post

Collection and assembly of data: All authors

Data analysis and interpretation: All authors

Manuscript writing: All authors

Final approval of manuscript: All authors

Accountable for all aspects of the work: All authors

AUTHORS' DISCLOSURES OF POTENTIAL CONFLICTS OF INTEREST

The following represents disclosure information provided by authors of this manuscript. All relationships are considered compensated unless otherwise noted. Relationships are self-held unless noted. I = Immediate Family Member, Inst = My Institution. Relationships may not relate to the subject matter of this manuscript. For more information about ASCO's conflict of interest policy, please refer to www.asco.org/rwc or ascopubs.org/cci/author-center.

Open Payments is a public database containing information reported by companies about payments made to US-licensed physicians (Open Payments).