The following are types of data stored in electronic health record except.

Introduction

Electronic medical record data, administrative claims, registries, and other automated health data are increasingly being utilized by researchers and government regulatory agencies to evaluate the effectiveness and safety of medical products in real-world settings [1–3]. These data sources can generate large samples of patients that may be representative of populations of interest and can be followed over time for the development of important health outcomes [4,5]. Other chapters have discussed how such data sources can be used for pragmatic randomized clinical trials (pRCTs) (see Chapters 24-30).

To identify clinically relevant endpoints within healthcare databases, researchers typically develop electronic algorithms based on hospital and/or outpatient diagnosis codes, diagnostic tests or their results, procedures, drug therapies, patient-reported symptoms or diagnoses, or some combination of these parameters [6]. However, case-identifying algorithms may not accurately identify the endpoint of interest, and this could lead to misclassification of these outcomes in future studies [7]. In analyses evaluating associations between a medical product and intended or unintended events, outcome misclassification can lead to biased treatment effect estimates [8]. Outcome misclassification therefore represents an important source of error in epidemiologic research, particularly in comparative effectiveness research (CER) or pRCTs conducted in administrative insurance claims or electronic health record databases.

Although numerous case-identifying algorithms have been published in the medical literature, information regarding the basis and performance of these algorithms is often missing [9,10]. Researchers frequently do not test the algorithms that they have developed against a reference standard (e.g., manual review of the medical record, presence of a disease in a registry, or report of the disease by healthcare practitioners or patients) [9]. It is therefore difficult to determine the accuracy of the algorithm, its potential impact on study results, and whether to use the algorithm in future analyses [11].

Given the potential for misclassification of outcomes in healthcare database studies, researchers should seek to validate the case-identifying algorithms that they have developed against some reference standard to ensure that the algorithm is accurately ascertaining the health outcome of interest [12]. Validation of a case-identifying algorithm can help determine the degree of outcome misclassification and is crucial to drawing valid inferences from studies evaluating the endpoint within a given database [13].

This chapter describes an overall approach to develop and validate health outcomes of interest within healthcare databases (Fig. 15.1). We first discuss ways to construct algorithms for identifying these outcomes using parameters available within these databases. Next, we discuss the difference between internal and external validation of case-identifying algorithms and the methods involved with each approach. We then review how to assess an algorithm's performance. We conclude with considerations about the transportability of case-identifying algorithms to different databases and the need for re-evaluation of their validity within different populations, health care settings, medical coding systems, and calendar time periods.

Definitions of EMR and EHR

Electronic medical record (EMR): An electronic record of healthcare information of an individual that is created, gathered, managed, and consulted by authorized clinicians and staff within one healthcare organization.

Electronic health record (EHR): An electronic record of healthcare information of an individual that conforms to recommended interoperability standards for HIT and that are created, managed, and consulted by authorized clinicians and staff across multiple healthcare organizations. It represents the concept of a longitudinal health record of the individual.

Basically an EHR collates multiple EMRs across multiple healthcare organizations into a single comprehensive longitudinal or lifetime record for an individual patient. For this to materialize, multiple EMRs need to be capable of exchanging data with each other, a term called interoperability. Interoperability is obtained through following certain standardized coding. Examples include ICD-10 for diagnosis, LOINC for lab results, and HL7 for messaging. These are detailed in a subsequent chapter.

Cloud-based secure solution

The EMRs are stored as ciphertext in the cloud, and the encryption keys are shared with the involved teams only during their involvement in the emergency treatment. Fig. 4 illustrates the components of the secure EMR system. The system protects patients’ privacy by only storing health data in the cloud in encrypted form and by making encryption keys accessible only to healthcare professionals during their involvement in emergency treatment. Patients and healthcare professionals organised in acute care teams are the system users, who interact with the EMR system through a web application. The registration authority assigns attributes to users, and these are used to authorise (or not) access to patient data. A user receives an attribute-based encryption (ABE) key based on his/her own attributes from the master authority.

The patient generates a symmetric searchable encryption (SSE) key and encrypts the key using the ABE scheme containing access control policies that grant access to specific healthcare professionals. Then, the patient sends the ciphertext of the SSE key to the key tray for storage. Only a user in possession of an ABE key that contains matching attributes can recover the SSE key and decrypt and encrypt data locally. The ABAC service provides an additional layer of access control to the EMR system on top of ABE, ensuring that only a health professional (e.g. ambulance team member) that is currently treating a patient gets access to patient data.

The proposed EMR system enables granting and revoking access on demand. This solution is expected to alleviate security and privacy concerns associated with cross-institutional data sharing that has been a barrier for collaborative care in the Netherlands and many other countries.

AIMS Redundancy Infrastructure and Failover

As electronic medical records evolve from helpful software applications to mission-critical “medical devices,” providers and processes become increasingly dependent upon them. Outside the perioperative environment, the “point of care” is a flexible concept that is capable of moving from patient bedside to nursing station to hallway to conference room. However, the anesthesiologist’s clinical role demands continuous physical presence at a very specific place—the anesthesia cockpit. As a result, workstation failure at this point of care is a challenging IT event. If a specific workstation is disabled due to device or software issues, it must be evaluated and repaired immediately. Momentary failures lasting less than 10 or 15 minutes can be handled via patience and temporary paper charting that is then transcribed into the AIMS. Longer workstation failures may require the transition to a paper record for the remainder of the case, a challenging medical record result.

Beyond the individual workstation, networking or database server failure results in a systemwide failure that can have significant impact. Generalized cross-industry IT redundancy improvements have resulted in significant gains for AIMS vendors: hot-swap clustered database servers, storage area networks, redundant power supplies, and dual network interface cards virtually eliminate susceptibility to single-point failure at the database server level. Network uptime is maximized using advanced diagnostic tools detecting packet loss before failure, redundant routers and bridges, and prophylactic hardware upgrades. As a result, network outages are typically rare and ephemeral at most modern hospitals sophisticated enough to implement an AIMS. However, network and database failures are still possible. Various vendors have implemented variant strategies to deal with these system or workstation level failures. They range from focusing on preventing failure to creating complete local and remote redundancy (Figure 21–9). Clearly, an optimal solution leverages the network when it is available, yet allows the user to continue documenting and accessing information when the network or database server fails. However, the infrequency of this scenario combined with the software development costs for vendors allow other less redundant options to be feasible or even desirable.

Missing drug information in electronic medical records

Medications recorded in EMR data include two types: medication history and prescribed medications. The medication history list generally does not include dates of exposure, but rather just a marker of use. This information may be carried over from visit to visit and is often missing entirely [20]. Medications prescribed during a visit may be a more valid data element to use in pragmatic trial research. This information should include important drug information including route, dose, and day supply. One limitation of using prescribed medications found in an EMR is that it is unknown whether the patient filled the prescription. Rates of prescription abandonment vary by location and medication type [21,22]. For some medications (e.g., antibiotics to treat ear infections), it is routine practice for physicians to prescribe a medication but recommend a “watchful waiting” period before the patient fills and initiates the medication [23]. Finally, medication information may be missing if the treatment is prescribed outside of the EMR system. For example, behavioral health visits can occur at a separate location from primary care. Prescriptions for mental health medications have been shown to be missing at high levels in EMR data [24].

Identify and Schedule Patients

Within the electronic medical record and scheduling systems being used, TR providers need to identify and appropriately set up a scheduling system specific to TR. Initially, a provider may need to identify a group of persons with disabilities who have easy access to and who are familiar with using digital technologies to initiate TR programs. Providers should also consider appropriateness of TR encounters versus in-person visits prior to scheduling visits because certain disorders, like musculoskeletal conditions or spasticity, may be better assessed in person. It may also be helpful to have a factsheet available for patients to read regarding how their TR visit will be conducted.32

While most return TR visits may be completed within 30 minutes,33 considering potential technical difficulties and additional time needed to complete documentation etc., additional time may need to be set aside. Many hospital centers will have a practice call for the patient’s first visit or have staff assist with patient technical difficulties before the first scheduled appointment to streamline physician visits. Unlike in-person visits, TR visits should be initiated exactly on time, and multiple patients cannot be scheduled during the same time period unless you are having a group visit.

2.2 Other Data Sources

Other than the information stored in the EMRs, there is a huge amount of available complementary information related to diseases and other medical conditions, genetics (omics data such as genome sequences, RNA and microRNA, or proteomics), and drugs and therapies, among others (Ross et al., 2014). In addition, the improvement of connectivity and patient empowerment have stimulated the creation of new data sources, such as social networks, wearable devices, environmental sensors, or patient-reported outcomes (Weng and Kahn, 2016).

Furthermore, a health system implies the existence of a health cluster as a result of the interaction or collaboration of several public and private entities, such as central or federal governments, regional or local authorities, hospitals, primary care centers, health professionals, public health services, insurance companies and other healthcare financers, universities for the education and training of clinicians, research centers, patients’ associations, pharmaceutical companies, and the health technology industry (Rojas and Carnicero, 2015).