Data Management

Published on 27/03/2015 by admin

Filed under Neurosurgery

Last modified 27/03/2015

Print this page

rate 1 star rate 2 star rate 3 star rate 4 star rate 5 star
Your rating: none, Average: 0 (0 votes)

This article have been viewed 1215 times

Chapter 29 Data Management

Micheal J. Speck, Irene Katzan, Ajit A. Krishnaney

The incorporation of true evidence-based models into the care for spinal disorders necessitates the collection of outcomes metrics throughout the continuum of patient care. Until this is realized, the clinical decision process will continue to rely on subjective, anecdotal evidence, with a risk that ineffective treatments will continue to be performed at both high financial and patient expense. Although this is not a problem among skilled practitioners, this subjective model does nothing to promote improved outcomes at a macro level and does not translate well across health systems.

Ultimately, significant barriers pose a challenge to create a system to capture and evaluate outcome measures consistently. At a very fundamental level, the data collection process has a negative effect on the bottom line. Any system designed to capture outcomes data requires human resources, hardware, and software. At its outset, even the most basic system adds to the cost per visit or admission. Worse yet, the data collection process has the potential to disrupt clinical work flows, and the information collected may not always be immediately useful (some data elements will be clinically relevant, but many will not prove their significance until much later).

All of these factors serve as disincentives to implement a system for collecting information about outcomes of care. However, external forces, such as public reporting of outcomes data and value-based purchasing, are starting to drive demand and will eventually overcome the barriers. In the long term, ignoring the call for objective clinical outcomes will prove to be incredibly costly. Appropriately designed systems will allow practitioners to measure the effectiveness of available treatments against the relative cost. Once this type of analysis is available at the point of clinical decision, physicians can finally apply their clinical expertise for the exceptions and depend on evidence for the “regular” cases. This outcome will allow the provider and the health care delivery system to contain cost while maintaining high standards of care.

Most importantly, a patient-centric approach to spine surgery means that specific clinical characteristics, interventions, and outcomes should be considered in context. Data management for such a varied and distributed dataset is extremely complex. It will require a thoughtful and intentional plan that is executed by a strong team with a wide array of skills, from the clinical through the technologic.

Building a Successful Outcomes Information System

The database itself is but one component of an efficient scheme for data collection, storage, and retrieval. At this point it is necessary to highlight a crucial aspect of understanding outcomes information systems (outcomes systems). The word system is used here to accent the simple distinction between the data “store,” or database (i.e., the electronic data storage mechanism), and its functional environment. Although each system typically has a database at its core that is responsible for data storage, the overall system is much broader, including database management software, data processing software, presentation applications (i.e., browsers), user interfaces (i.e., input and output screens), and the hardware on which it operates (Fig. 29-1). The term database simply refers to the data storage mechanism. Within the context of an overall information system, the database can perform properly, but the database is entirely useless outside of the system. Ideally, a well-designed database drives the development of its interrelated technical components (i.e., hardware and software), resulting in an efficient and elegant solution for outcomes research.

image

FIGURE 29-1. Schematic of database management.

Too often, the term database is used to describe not only the database but also the database management software used to create and administer it. Although the difference is subtle, it is important. Database management software has drastically simplified the database administration process (maintenance and data management) in recent years, and this has fostered the idea that the underlying databases are simple as well. This is a common and costly misconception. A poorly designed database that is at the heart of an outcomes system invariably leads to faulty data processing and an unsuccessful project. Unfortunately, poor database design is not always immediately evident, and a substantial amount of time, effort, and resources can be wasted before the inherent problems manifest themselves.

This discussion is intended to help bridge the divide between individuals who desire a medical outcomes information system and those who possess the knowledge and skills to build and maintain it. There is often a significant gap between the perceived resource requirements, in terms of time, technology, and human resources, the creation of such a system, and the actual requirements. This is especially true with respect to the time necessary for design and development. However, effective communication between the users and the technical staff (i.e., the individuals commissioned to build and maintain a system) can drastically shorten the development cycle. Therefore, here this relationship is analyzed throughout all of the system development stages, beginning with the initial conceptual development and finishing with implementation. The system development process is deconstructed into three key stages: definition, design, and deployment.

System (Project) Definition

Defining the Research Focus

Defining the research focus of the outcomes information system must be a thoughtful, deliberate exercise by the principal investigator, coinvestigators, and clinical project leadership. Carefully defining the question(s) to be answered by the data collected, stored, and ultimately retrieved from the outcomes system is both necessary and critical. A clear vision of the questions at hand, the statistical analysis, and hence the system purpose establishes a solid platform on which the entire system can be built. The result of the definitional phase is the determination of the system/project size and scope from a clinical, technologic, and operational standpoint. Once defined, the ability to obtain answers to the proposed questions serves as the benchmark against which the final system will be evaluated.

A common mistake with system development is to postpone the process of defining the goals, consciously or unconsciously. Individuals who adopt this approach view the definitional phase of the outcomes information system as an evolutionary process in which the defining elements theoretically become evident as the project takes shape, rather than take specific steps to determine them. This inevitably leads to a poorly designed database at the heart of the outcomes system, which functions neither efficiently nor appropriately. Conversely, thorough investigation and due diligence during the definitional phase of the project foster the establishment of a blueprint from which the entire system can be built, thus maximizing the system’s efficiency and its ability to achieve the stated objectives.

Understanding the Clinical and Operational Environment

It is impossible to design an appropriate model for data management without a clear understanding of a physician’s working environment. This includes cataloging the types of disorders that are treated, the available treatment options, and the factors that influence treatment decisions (i.e., patient age, comorbidities, and medical history), the myriad of possible outcome patterns, the nature and impetus of patient-physician interactions, and measures by which treatments are validated. Clearly, it is the clinician who can best describe this environment, and the transfer of this information to the information technology personnel on the project team is critical. Any disconnect between the clinician and the analyst is most damaging during this phase. However, if this divide can be overcome in the early stages of the process, subsequent tasks become increasingly more manageable.

The establishment of clear project objectives primarily provides a blueprint for the information system and also delivers a number of secondary benefits. It is during this phase that the original concept is validated. Participants (e.g., clinicians, nurses, administrators, analysts) have the opportunity to consider every aspect of the project, and most importantly, the outcomes information system has a distinct model for comparison. Without this objective model, there is no clear way to determine whether the overall project goals have been satisfied.

Describing the Patient Population

The first definitional requirement relates to the description of the patient population. A method by which individual patients and their associated treatments can be compared as a subset of a heterogeneous patient population needs to be established. Some of the critical metrics such as age and gender are universal and relatively straightforward, whereas others such as education level and workers compensation status are more directed and often relate to specific research questions. Core elements that indicate the patient’s medical profile include diagnoses, symptoms, and physical signs.

Determining Data Elements

Pursuant to the definition of the outcomes model, difficult decisions surrounding the inclusion of data elements need to be made. The natural tendency is to attempt to collect enough data to potentially answer any question that may surface. This, however, becomes very onerous for both clinician and patient. In this arena, considering patient and provider burden, parsimony is essential.

Input from multiple participants is important during this phase of the process so that critical data elements are not overlooked. However, it is equally important to exclude data elements that do not contribute significantly to the overall goals of the project. Great attention to detail is a requirement in the definitional phase to achieve a proper balance in the data model; the inclusion of too many data elements adds unnecessary strain on the systems resources (both human and technologic), and the exclusion of critical data elements renders the system ineffective.

Beyond the selection process, all of the data elements must be presented in a standardized and concise manner that can be readily adopted by all of the system participants (patients and health care providers). For provider-entered data elements, standardizing the terms used to describe spinal disorders and their manifestations is necessary to allow accurate categorization of patients within each specific disorder. This standardization process is essentially the process of establishing the common language that is subsequently used by all participants. Health care providers will use it to describe their patients, patient symptoms, pathologies, treatment options, and the course of therapy. For patient-reported data, using validated scales and questions that are at the appropriate education level is good practice and optimizes the accuracy of the information.

System Design

Data Mapping and Modeling

Once the nature of the data to be gathered has been defined, the source of the data must be determined. Primary data collection (i.e., patients and clinicians) and electronic sources (i.e., cost and procedure-related data from the operating room and financial systems) must both be considered. The availability and accessibility of these resources varies among institutions. Hence, data acquisition must be tailored to fit. Efficient data acquisitions can be realized through the automation of the data collection process, and automated processes should be introduced to the model wherever and whenever possible. This, of course, is dependent on the availability of data “feeds” from alternate information systems (i.e., patient demographic data retrieved from a patient scheduling system). However, some information will need to be collected directly from clinicians, patients, or both. Outcomes systems must merge all of the data sources gracefully to succeed.

Data sources are not nearly as important, however, as the data destinations. The most critical aspect of system design is found in the modeling of data. Because the components of a clinician’s environment have been clearly outlined during the initial (definitional) phase of the project, the definitions are now readily available for use while designing the outcomes information system. Most effective information systems are merely reflections of real-world models. The outcomes information system is no exception. The entire process shifts from a definitional into a translational role as the descriptions of real-world entities become definitions used in the construction of a virtual model. This process is not academic, but accurate descriptions of the data, the environment, and the relationships among them can markedly simplify the process.

In the initial phase, definitions of the patients and their diagnoses, symptoms, and treatments directly describe the observable aspects of the clinician’s environment. In the design phase, these definitions are abstracted, assuming a role of data description within the database. Hence, the definitional phase determines what data should be stored, and the design phase determines how it should be stored. The design phase is also the stage at which the primary responsibility shifts from the clinician to the system analyst. The system analyst, working from the model constructed by the medical and administrative staff, must develop a database model suitable for accurate, meaningful data processing. The data elements selected and defined earlier must now be organized logically into an overall data design that facilitates consistent data storage and retrieval. New questions will be considered for the same data elements determined in the definitional phase. These are directed at defining the nature of the data.

For instance, if a patient’s medical record number is to be used as the main form of identification, a series of questions about the data element itself need to be addressed. First and foremost, is the medical record number an appropriate identifier? Is it truly unique, or are there circumstances in which multiple patients can share a medical record number? Will the medical record number be readily available at the time the information is collected? Are there any legal or business constraints on the use of a medical record number as a tracking measure within the information system? In this example, although medical record numbers are generally suitable for identifying specific patients, a number of privacy issues concern their use. Current law requires the use of a separate, unique identifier for each patient that is independent of the medical record number. As a result, sensitive information cannot be directly linked back to a given patient outside of the outcomes system itself. Consequently, even though the medical record number is an effective identification technique for patients (and patient records), it may not be an appropriate identifier in the overall data model.

Additional questions regarding the information pertain to the type of the data to be acquired. Drawing from the previous example, is the medical record number numeric, or can alphabetic characters be included? If character data can be used, the medical record number must be stored in a character format. Otherwise, it could make sense to store the data numerically (character formats can include numeric data, but numeric formats cannot accommodate alphabetic characters; for example, “123456” can be stored numerically, whereas “4B3R589” cannot). Once this distinction has been made, it is still necessary to decide which character or numeric format should be implemented. For instance, if a data element is to be used in any mathematical calculations, a numeric data type is necessary. However, numeric data types can be further subdivided into integer, long, float, and double, each with its own range of values, storage space requirements, and functionality (i.e., the float data type typically requires more storage space than an integer data type but permits the use of decimal places, whereas integers do not).

Buy Membership for Neurosurgery Category to continue reading. Learn more here

Related posts:

Default ThumbnailMuscular Support of the Spine The Obese Patient Recurrent Lumbar Disc Herniation Minimally Invasive Spinal Decompression and Stabilization Techniques II: Thoracic and Lumbar Endoscopic Approaches Thoracic Discectomy Electrodiagnostic Studies