Gwyn Saylor

Electronic clinical laboratory test results data tables: lessons from Mini-Sentinel

Developing electronic clinical data into a common data model posed substantial challenges unique from those encountered with administrative data. We present here the design, implementation, and use of the Mini‐Sentinel Distributed Database laboratory results table (LRT).

Increasingly restrictive definitions of hyperkalemia outcomes in a database study: effect on incidence estimates.

To determine the incidence of hyperkalemia‐associated adverse outcomes among ambulatory patients with diabetes newly initiating renin‐angiotensin‐aldosterone system (RAAS) inhibitor therapy and to examine to what extent increasingly restrictive definitions of hyperkalemia‐associated outcomes influenced incidence estimates.

The Positive Predictive Value of a Hyperkalemia Diagnosis in Automated Health Care Data

Our objectives were to determine performance of coded hyperkalemia diagnosis at identifying (1) clinically evident hyperkalemia and (2) serum potassium>6 mmol/L.

Managing personal health information in distributed research network environments

BackgroundStudying rare outcomes, new interventions and diverse populations often requires collaborations across multiple health research partners. However, transferring healthcare research data from one institution to another can increase the risk of data privacy and security breaches.MethodsA working group of multi-site research programmers evaluated the need for tools to support data security and data privacy. The group determined that data privacy support tools should: 1) allow for a range of allowable Protected Health Information (PHI); 2) clearly identify what type of data should be protected under the Health Insurance Portability and Accountability Act (HIPAA); and 3) help analysts identify which protected health information data elements are allowable in a given project and how they should be protected during data transfer. Based on these requirements we developed two performance support tools to support data programmers and site analysts in exchanging research data.ResultsThe first tool, a workplan template, guides the lead programmer through effectively communicating the details of multi-site programming, including how to run the program, what output the program will create, and whether the output is expected to contain protected health information. The second performance support tool is a checklist that site analysts can use to ensure that multi-site program output conforms to expectations and does not contain protected health information beyond what is allowed under the multi-site research agreements.ConclusionsTogether the two tools create a formal multi-site programming workflow designed to reduce the chance of accidental PHI disclosure.

PS2-42: Developing High-Quality Laboratory Results for the Virtual Data Warehouse: The Importance of Single-site Quality Assessment

Background/Aims Assessment of data incorporated into the Virtual Data Warehouse (VDW) is crucially important when building a new content area such as laboratory results. At KPCO, we identified two main challenges while constructing tables of laboratory results for the VDW. The first was ensuring that we constructed clinically meaningful laboratory test types. The second was confirming that we identified and classified the correct set of records from source data repositories. The aim of our work was therefore to ensure that these two challenges were successfully met Methods Initial priority tests were broadly categorized as chemistry, hematology, microbiology, or challenge tests. Many laboratory results could be characterized into a single test type. Other laboratory results required one or more of the following characteristics to differentiate subtypes: assay method; test subtypes such as isoenzymes; result type; fasting status; specimen site; and challenge dose and time since dose. Laboratory results were extracted from two data repositories. The first database includes records from 1999–2004. The second database stores records since 2005 with partial backfill of records from 2004 and earlier. Variable names and values did not follow a common naming convention between the two data sources. Extraction and classification rules were based on Logical Observation Identifiers Names and Codes (LOINCs), test names, result units, and Current Procedural Terminology (CPT) codes. Results We identified numerous issues while developing the VDW laboratory content area: incomplete clinical information; distinct laboratory types with similar names; missing, incorrect, obsolete, or site-specific component codes; incorrect sample collection times; changes in source data streams; clinical practices that differ from guidelines; and little background knowledge of laboratory tests among those processing the data. Each challenge and the approach to addressing each issue will be illustrated with an example. Conclusions A systematic approach to collection and processing of laboratory results can yield high-quality, clinically useful data. Key elements of this systematic approach include a logical and flexible taxonomy of laboratory types and careful consideration of identifier codes and supplemental information to categorize laboratory results. Developers should expect a variety of deviations in the data from expected patterns.

PS1-05: Feasibility of Extracting Oncology Treatment Data from on Electronic Health Record

Background/Aims New source data systems almost always cause angst among programmers. Source data systems usually are built for user ease of use and are not built for ease of getting data out. A new Electronic Health Record (EHR) module designed specifically for Oncology treatment was no different. Having access to data that was previously unavailable caused excitement among researchers, so we conducted a project to explore extracting Oncology protocols, treatment plans and medications from this new module in order to: determine the process needed to identify protocols, treatment plans and medications from the EHR, validate the process with medical record review, and build VDW tables that could logically hold this data and accommodate data from other HMOs. Methods The study team: identified EHR tables and fields that contained medication data, protocols and treatment plans specific to Oncology, completed multiple rounds of validation through chart review, and 3) identified the structure and key variables needed to construct VDW tables of Encounters, Treatment Plans, and Medications. These three steps were then used to identify patients currently receiving cancer treatment in the Oncology department and data is being pulled to populate these VDW tables. Results Multiple challenges were encountered and solutions identified. First, the EHR tables, fields and linkages required significant exploration to discern useful data elements and correct joins. For example, oral and infused medications are kept in separate tables and each table contains multiple and different date fields and status codes to determine if the drug was actually given to the patient. Other factors complicating identifying Oncology treatment included determining work flows and matching those work flows to data that was extractable from the EHR and poor documentation not specific to our HMO. An iterative process was used to validate each data pull. Conclusion Identifying Oncology treatment data in the EHR was a process fraught with multiple challenges. We believe, however, that we have developed code that identifies protocols, treatment plans and medications used to treat cancer patients. This is an important first step in compiling data needed for future research on the treatment of various cancers.