CIN Plus. Data Aggregation: A Case Study HEALTHCARE TECHNOLOGY USE BACKGROUND. Section Editor: Linda Q. Thede, PhD, RN-BC

Transcription

1 CIN Plus Section Editor: Linda Q. Thede, PhD, RN-BC Data Aggregation: A Case Study Audrey L. Roberts, BSN, RN, CLNC Jeanne P. Sewell, MSN, RN DOI: /NCN.0b013e3181fb5c0c Key Points: Database design Importing clinical data System interoperability issues The writing of this article and the case study discussed within were not supported by a grant or any other source. The article developed out of the problems encountered in the database construction project, as discussed in the case study. The transition to the use of electronic health records (EHRs) and other software to capture care has opened new opportunities for nursing to improve healthcare outcomes. Nursing care data that are captured using technology can be aggregated, analyzed, and benchmarked with desktop spreadsheet and database software to improve the healthcare delivery system. Nurses who document patient care electronically may be unaware that they are entering data into databases or the potential benefits from extracting and using these data to analyze and improve nursing care. The purpose of this article was to present the potential for improving care using the data that are created in an electronic record as well as provide an overview of some of the problems associated with using these data. A case study will be used to illustrate how noninteroperable systems create difficulties that require manual interventions before using the data. Additionally, the formatting difficulties caused by lack of knowledge about how data should be formatted when being imported into a database are discussed. This case study is not unique to a given healthcare agency. The experiences that are discussed are universal. The specifics of the study were intentionally not discussed because the focus of the article is to reveal the challenges and opportunities involved with secondary use of data to improve the quality of care we deliver to patients. HEALTHCARE TECHNOLOGY USE BACKGROUND It has become increasingly important that nurses develop competencies in healthcare technology, especially since the passing of the Health Information Technology for Economic and Clinical Health (HITECH) Act, which is part of the American Recovery and Reinvestment Act of The HITECH Act encourages widespread use of EHRs by the year Reimbursement will be affected, by either bonuses or penalties, based on whether facilities meet certain technology requirements. 1 Changes are coming, and it is vital that nurses know how to benefit from these changes. One aspect of healthcare technology that many nurses are not familiar with is information databases. All nurses, whether novice or expert, and no matter which specialty, CIN: Computers, Informatics, Nursing January/February

2 encounter information databases in their work when they use electronic records. Therefore, it is important that all nurses understand the basics of working with them. Databases serve many purposes. For example, research teams use databases to analyze data for improving care, nursing departments use them to keep track of nurses licensure and certification information, and quality departments use them to track data pertaining to quality indicators. A database consists of tables, which are nothing more than data in a structured format. There are rules about how these data must be structured. Each line of the table, called a record, must contain data pertinent to only the subject of that record. For example, if a patient is the subject of the record, the columns or fields must all contain data pertaining to that patient. Additionally, each column must contain the same piece of data, for example, first name, city, medical record number (MRN), and so on for each patient in the table. Any column (field) or piece of data for all the subjects in the table can be pulled out independent of the other fields and analyzed. For example, medical diagnoses for all the patients in the database can be pulled out to see which the most common diagnosis for. More than one field can also be used in analysis, for example, nursing diagnoses for each medical diagnosis can be pulled out of a database for analysis. Data used in this manner are called aggregated data. It is the rules for how data must be structured that differentiate a database from a spreadsheet and make it a powerful analytical tool. This structure is in contrast to a spreadsheet in which data can be put anywhere. THE CASE STUDY The purpose of the project was to analyze care that was provided for critical care patients with certain specific medical and nursing care regimens. The project was a quality improvement initiative and was a retrospective study design. Approval from the institutional review board was obtained to protect the rights of human subjects. The team members included physicians and nurses from clinical areas and nurses involved with quality improvement. It also included nurses who were database design specialists. Every effort was made to protect the privacy of patients. The files were all encrypted. Unnecessary data were shredded electronically. At the first research team meeting, the database designers received a list of the required research data elements, a listing of data sources, and copies of literature pertinent to the topic. Before starting on collecting data or building the database, the research database design team conducted a careful review of the literature to ensure that all of the requirements for the study had been identified. PROBLEMS WITH OBTAINING DATA Two problems that can complicate analyzing care data in electronic records are dirty data and a lack of interoperability among different information systems. Dirty data are data that contain errors. These errors can be caused by many different factors including duplicate records, incomplete data, lack of a unique identifier, and different data for the same piece of information. A lack of interoperability means that the computer systems are unable to exchange or understand data from each other. 2,3 Many of the problems associated with interoperable systems not only interfere with aggregating data, but also create problems in healthcare. When systems are interoperable, it improves healthcare s vital signs, as well as patient care, patient experience, physician and staff satisfaction, quality, continuum of care, and competitive advantage. 4 PROBLEMS DISCOVERED WITH INTEROPERABLE SYSTEMS Our project required data from four noninteroperable data systems: the electronic medical record, the critical care system, the central hospital patient database, and separate patient management database. One of the difficulties caused by a lack of interoperability is the need for multiple entries of the same data, a process that increases chances for different systems to contain different data for the same piece of information. For example, when looking at data from different systems, we found two different people assigned to one MRN. One particular patient monitoring computer system required the nurses to key in the 13-digit patient identifier. Although the number had to be entered twice as a quality check, a user entered it incorrectly. The system then automatically used the same number for two different patients. Because the MRN was already assigned to another patient, data from the two patients were contained in one record. Anyone requesting information about a patient using that particular MRN would receive confusing information, a potentially dangerous situation. If noninteroperable systems must be used in healthcare agencies, one way to prevent this type of error is to place the patient s identifying information on the wristband in a bar-coded format. The information could then be uploaded into the next system by scanning the wristband. We also discovered two MRNs assigned to the same patient; in one medical record, the patient s middle name was used as the first name; the other medical record had 4 CIN: Computers, Informatics, Nursing January/February 2011

3 the correct first name and last name. In situations like this, when a healthcare provider requests to look at the patient's old records, there will always be information missing because it is located in two separate files. This particular instance could be prevented with more specificity about what data to enter in what field (space) on the data-entry form. Another difficulty in using data from interoperable systems is differences in how fields are named. We found that one computer system named a patient's hospital admission date AdmitDate, while another identified it date admission. Such a small change makes a big difference. If there are two different names for the same data, when these data are imported into the database, it will believe they are two different pieces of data. Name differences must be resolved before creating database tables and importing the data. PROBLEMS ASSOCIATED WITH POOR SYSTEM DESIGN Even if data are obtained from only one information system, there may still be problems with using the data. We found that some of the birthdates were in the future, for example, 04/18/2022. Obviously, such a date is not accurate. This occurred when a two-digit year was used for entry instead of a four-digit year. The information system, using an algorithm that designates specified two-digit years as belonging to either the 20th or the 21st century, interpreted the year 22 as 2022 when it really was This should have been prevented by requiring a four-digit year as well as presenting the user with an error message if an obviously incorrect date is entered. CODING ISSUES In our research study, it was important to look at patients diagnoses to identify patients with a diagnosis of diabetes. For this, we received a query database file listing the International Statistical Classification of Diseases and Related Health Problems, Ninth Revision, Clinical Modification (ICD-9-CM) codes for each patient. We quickly realized that it would be more difficult than we had anticipated finding the ICD-9 codes that corresponded to the phenomena to be studied from the abbreviated table display of code descriptions. For example, diabetes was identified differently in the various associated diagnostic codes including categories 250.+, 249.3, 249.8, 648.0, and Diabetes was listed in the 250 code range descriptions as DMI or DMII. In the other ICD-9-CM code descriptions, diabetes was identified as diabetes, DM, DB, or Diab, to name a few, and each of these was assigned a different code number. Each diagnostic code represents a different and specific diagnosis related to diabetes; however, as previously mentioned, diabetes can be represented several different ways. Using the same terminology for diabetes in each code description, while retaining the individuality of each different diagnosis, would allow database software to identify ICD-9-CM codes pertaining to a specific phenomena. While ICD-9-CM consists of approximately 20,000 diagnostic codes, the newly developed ICD-10-CM consists of approximately 70,000 codes. 5 It may seem as if adding 50,000 more diagnosis codes would increase confusion and inconsistency in coding. However, adding more codes allows for more specificity in coding which results in a more accurate analysis of data. 5 Although the codes may be more specific, there must still be consistency in using the code description terminology so that it will be easier to identify codes related to specific conditions from among a list of 70,000 codes. USING RECEIVED EXTRACTED DATA The database designers had a listing of all of the data requirements. An unanticipated issue was that the data were redundant in the reports from the different database systems. The reason is that the data had to be extracted according to the hospital and critical care admission and discharge dates. The study sample had to be extracted from thousands of records. Because the patients were medically vulnerable, many of them had many readmissions for the defined study period. We kept a record of requests for and receipt of data. Oftentimes, two or three different people were gathering data for us, which we would later compile to create the database tables. Remembering who was in charge of what data, whether we had received it or not, and which file contained what data quickly became an impossible task. We resolved the problem by creating a chart to track the data needed, the person who was responsible, and when and how (the name of the file) it was received. See Table 1 for an example of how to create the chart. PROBLEMS RESULTING FROM LACK OF KNOWLEDGE REGARDING DATABASE FORMATTING In our project, the persons extracting the data from the various information systems did not understand database design and requirements. As a result, we received data CIN: Computers, Informatics, Nursing January/February

4 Table 1 Sample data tracking chart in list format Data Information Requested Date Date Filename Needed System From Requested Received Patient name Medipac Jane 2/11/10 2/12/10 DemoData.xls DOB Medipac Jane 2/11/10 2/12/10 DemoData.xls Admit date Cerner Tim 2/11/10 2/15/10 VisitInfo.xls Discharge date Cerner Tim 2/11/10 2/15/10 VisitInfo.xls No. of days on ventilator APACHE Amy 2/13/10 2/16/10 VentReport.xls that needed reformatting. For example, we received an Excel file with special formatting that made the information easier for users to read, but not useful in a database. Figure 1 shows an example of an Excel file that we received. Additionally, data that belonged in two columns, such as the first name and last name, were in one field (Figure 1). To import data into a database, each field of data must contain only one type of information; that is, the data must be at what is termed the atomic level, or the lowest level with any meaning. A spreadsheet table that can be imported into a database needs to have each piece of data in one column. For example, the MRN belongs in one column, the last name in another, and the first name in still another (Figure 2). Additionally, the information for each subject must be on one line (called a record in a database) as in Figure 2, not formatted in columns and sections as in Figure 1. In our agency, the patient s MRN is a combination of the MRN and the admission or financial number. Some data extracted for our research study included only the MRN, and others used the hospital admission identifier, a combination of the MRN and the admission/financial identifier. The admission/financial number had to be parsed away from the MRN to link patient data correctly. We also received unneeded data, again a result of not being specific enough about exactly what data were needed and what was unnecessary. Thus, the data required much effort to clean and format. RESULTS OF THE DATA ANALYSIS We did succeed in importing and analyzing the data. The database allowed the researchers to view aggregated data from the different databases, providing a rich and meaningful understanding of the patient care regimens. Like other quality improvement databases, we were able to drill down to look at various views of specific events. The database design provided a means to export the data to a statistical analysis program so that the outcomes can be compared with other published research. Many of the benefits included the lessons learned, which are discussed next. LESSONS LEARNED We learned several valuable lessons that we will do differently next time. First, we would do a better evaluation of the staff s knowledge of database requirements. Instead of making assumptions about how the extracted data will be formatted, we will specify how the exported data need to look. If we had provided simple training and specified the data format we needed, it would have expedited the process. We highly recommend making a chart to track the data needed. The chart should identify all of the data requirements, the person responsible for gathering FIGURE 1. Microsoft Excel report with special formatting. FIGURE 2. Microsoft Excel report in appropriate database format. 6 CIN: Computers, Informatics, Nursing January/February 2011

5 which pieces of data, when the data were requested, when it was received, and the name of the file containing the data. CONCLUSION The use of healthcare information systems opens new opportunities to aggregate, extract, and analyze data for use in improving patient care. Nurses, who have competencies with the use of spreadsheets and databases, can take an active role in the research process to define best practices. The challenges and solutions associated with the design of our research database have implications for other nurses and healthcare workers who extract and analyze data from information systems. While we hope that healthcare data are accurate, we must recognize that unintentional errors occur from data-entry errors as well as systems that are not interoperable. Not only do these errors create problems in using the data, but also, more importantly, they create dangerous situations in patient care. It is hoped that in the future, healthcare agencies will have enterprise-wide systems so that problems with interoperability will disappear. Other data problems caused by human error, and systems that permit avoidable errors, will still require vigilance to prevent. REFERENCES 1. Detmer DE. Electronic health records: their time has come. Issues Sci Technol. 2009;25(4): Halley EC, Sensmeier J, Brokel JM. Nurses exchanging information: understanding electronic health record standards and interoperability. Urol Nurs. 2009;29(5): Thede LQ, Sewell JP. Informatics and Nursing: Competencies and Applications. 3rd ed. Philadelphia, PA: Lippincott Williams & Wilkins; Gides G, Rivera P. A roadmap to interoperability. Healthc Inform. 2008;25(5): Jellish A, Zenner P, Goetsch E. Elevating to ICD-10. Manag Healthc Exec. 2007;17(12): 19 20, 23. Audrey L. Roberts, BSN, RN, CLNC, Graduate Student, Georgia College and State University, Milledgeville. Jeanne P. Sewell, MSN, RN, Assistant Professor, School of Nursing, Georgia College and State University, Milledgeville. Database Management Systems Their Place in Nursing Informatics Education KAREN L. COURTNEY, PhD, RN LINDA K. GOODWIN, PhD, RN JILL AUBRECHT, MSN, MBA, RN DOI: /NCN.0b013e3181fb5be0 Key Points: Nursing informatics requires understanding of data structures Database knowledge and skills in nursing informatics curricula should be included There should be models for teaching As noted in the American Nurses Association (ANA) Nursing Informatics Scope and Standards of Practice, 1 principles and concepts of database structures are an inherent component of nursing informatics practice. Many of the standards assume an understanding of data structures, management, and evaluation. While database management systems (DBMSs) are not specifically mentioned within the standards, it is hard to imagine accomplishing many of the standards without the direct use of databases or information systems that are built upon databases such as electronic health records. Even within the ANA Informatics Scope and Standards ethics (12) and advocacy (15) standards of practice, knowledge of data structures and management is implicit. For example, to meet standard 15 (advocacy), the nurse informaticist must understand how the data are structured as well as understand the technical and organizational protocols regarding the sharing of data. This knowledge forms the foundation for assertions regarding the degree of data security and ease of data sharing. The standards that are most likely to require database management knowledge include 1, assessment; 3, outcomes identification; 4, planning; 5, implementation; 6, evaluation; 9, quality of practice; 12, ethics; 13, research; and 15, advocacy. Practicing nurse informaticists may be expected to create and maintain databases, develop and revise interfaces, and develop data-entry forms. Additionally, some nurse informaticists are responsible for creating complex queries and reports of quality or performance information from existing databases. Course work in CIN: Computers, Informatics, Nursing January/February

6 data structures, management, and evaluation along with structured experiences applying theoretical knowledge in real-world situations is important in preparing nurses to work competently in a variety of technology environments. Competency in data structures and management is also recognized in ANA nursing informatics certification. For certification, nurse informaticists are tested on their ability to apply the principles of data structures, management, and evaluation. Databases and data concepts are integrated throughout the American Nurses Credentialing Center (ANCC) test plan. 2 The test plan specifically mentions skills in the logical and physical design of databases as well as underlying knowledge of data representation, data sets, classifications, and data integrity among other things. Despite an acknowledgment of the importance of database management skills and understanding of data structures, management, and evaluation in nursing informatics practice, there remains little description in the literature of the minimal requirements, let alone ideal requirements for DBMS concepts to be incorporated into nursing informatics educational programs. This article makes recommendations for minimal content necessary to meet the standards of practice and certification for nursing informatics and review two models for including DBMS knowledge into nursing informatics curricula. MINIMAL REQUIREMENTS FOR EDUCATIONAL PREPARATION Based on the ANA Scope and Standards for Nursing Informatics 1 and the ANCC nursing informatics certification test plan, 2 we suggest that at least the following concepts and experiences (Table 1) be presented in nursing informatics educational programs. In this table, we cross-match these concepts with a sample activity. Each of these concept areas is described below. LOGICAL DESIGN Logical design can be classified as the planning processes for a database. These processes typically include user needs assessment (requirements analysis), modeling of the proposed systems, and optimization of the proposed database through normalization. As part of the requirements analysis, students should be able to demonstrate skills in collecting information from users, understanding the database project requirements, classifying and prioritizing the requirements, resolving conflicts in requirements, and validating requirements with users. Gathering the requirements for a database project is similar to other information technology projects but requires students to think about the structure and relationships of the data within the database. If the proposed database is to interact with other systems, students should discuss the challenges of interoperability between information systems. Once students have an understanding of the requirements, they need to know how to model the required data, the information and control flow, and operational behaviors. There are many different modeling standards. We would recommend students be exposed to some of the more common models (Table 2), which they might encounter in the workplace such as Entity- Relationship Diagrams 3 or Unified Modeling Language (UML) models, 4 such as the Activity Diagram, the Use Table 1 Recommended DBMS Content for Nursing Informatics Programs Concept Logical design Requirements analysis Logical design Modeling Logical design Normalization Physical design Create simple database Physical design Build and execute queries Physical design Design report Standard terminologies Data warehouses Interoperability Sample Activity Analyze a current clinical domain problem with user(s) Use appropriate standard models, such as UML, with user input to model the above domain problem and potential solutions Create paper-based normalized tables (to at least third normal form) with faculty guidance for the proposed database Build a simple database that reflects the logical design proposed earlier (PC based and/or PDA based) Create and run appropriate queries on database based on user requests (PC based) Design and present appropriate reports from database based on user needs (PC based) Identify appropriate standard terminologies for use in the proposed database Discuss with expert guest speaker(s) the design, development, maintenance of existing clinical data warehouse(s) Discuss with expert guest speaker(s) the design, development, and management of interoperability projects 8 CIN: Computers, Informatics, Nursing January/February 2011

7 Table 2 Overview of Common Database Models Model Entity-Relationship Diagrams UML: Activity Diagrams UML: Use Case Models UML: Class Diagrams Description A graphical representation of the relationships between important concepts (these will later become tables in the database). Each entity can be described by attributes or properties. For example, a student (entity) registers (relationship) for classes (entity). The student entity may contain the attributes of last name, first name, and student identification number. The class entity contains attributes such as class identification number, subject, and class title. These diagrams are useful for capturing how tables will be linked to each other in the database being built. A graphical representation of the dynamic behavior of a system. These are similar to flow charts. For example, a student initiates the registration process by entering in a user ID and password (activity); the database then checks to see if this is a valid user (activity); a message regarding authorization to register is then returned to the student (activity). These diagrams are particularly useful for understanding workflow or how the database will control information flow between tables, processes, or even outside systems. A graphical and textual representation of the systems behavior from the user s perspective. For example, the Use Case Model specifies the types of interactions people will have with the University Registrar s database. Students (user) may check their current schedule (one use) or may add an additional class (another use). Faculty (another type of user) may check their class roster (use). Deans (user) may assign a class to be taught by a faculty member. These models are useful for understanding how different users will interact with the developed systems and can assist with planning security controls and/or user-specific views of the database. A graphical representation of the relationships between important concepts as well as functions. Class diagrams are similar to Entity-Relationship Diagrams in that both describe the relationships between tables and include a list of attributes for each entity. The main difference between the two is that the class diagrams also include methods or the types of functions that the class can perform. For example, a student (class) registers (association) for courses (class). The student class may contain the attributes of last name, first name, and student identification number. The course class contains attributes such as course identification number, subject, and course title. The methods listed for the student class might be to add a course (method) or drop a course (method). These diagrams are useful for capturing how tables will be linked to each other in the database being built. Case Model, and Class Diagrams. Students should be able to accurately model the database system based on their requirement analysis. Each of these steps in the logical design is iterative and requires validation with the users. Students should have the opportunity to interact with users and practice user needs assessment skills. Once students have identified and validated the requirements and the desired system responses, students need to know how to optimize the efficiency of the database through normalization. Using a step-by-step approach to normalization, students should be able to modify the database structure to at least third normal form, 5 meaning that all attributes (or columns) in the record (or row) are defined by the primary key, the whole key and nothing but the key. Additionally, students would be expected to describe situations in which denormalization might increase the efficiency of a specific database application. Special topics in this area might also include how data warehouses can be used for specialized applications. PHYSICAL DESIGN The physical database design phase is the construction of the database along with development of queries, forms, and reports. This phase is often what students think of first when anticipating a database course. The logical design serves as the foundation of the physical database. By using an iterative process in the logical design, less time and fewer revisions are needed when building the physical database. In addition to creating the table structure, students should also know how to design data-entry forms, queries, and reports. Students should be able to apply their knowledge of normalization to enhance the efficiency of the database and create the necessary tables and relations to support this. One area of contention in the physical design of databases is which DBMS students will use. Arguments can be made for many of the common systems such as Microsoft Access, MySQL, or Oracle. However, no matter which system is used, invariably some graduates CIN: Computers, Informatics, Nursing January/February

8 will work on a different DBMS than the one they used in their course work. Important issues to consider when choosing a DBMS system for course work are the availability to students, cost, available support resources, and the complexity of the database project being built. Depending on the DBMS used, students may also demonstrate that they can create easy dataentry interfaces. Additional topics in this area would include security issues, distributed databases, data sharing, and interoperability among databases. STANDARDIZED TERMINOLOGIES Standardized terminology is one area that is substantially different from the content acquired within a computer science database management course. The area speaks to the foundation of nursing informatics practice. Students should understand common nursing and biomedical data sets and terminologies and the relationship between these and facility-based databases such as the electronic health record. If possible, students should have a hands-on experience in querying a nursing data set created using a standardized terminology and presenting their results. DATA WAREHOUSES Data warehouses address the longitudinal uses of data and represent a special use of databases. Topics in this area may also include data cleaning, data aggregation, and data mining. Patient privacy issues arise even in deidentified databases used for data mining; students should be introduced to procedures for data security, as well as deidentification and protecting personally identifiable health information. INTEROPERABILITY Interoperability stresses the complexity and challenges of the integration of information systems. Topics may include common terminologies, identification of barriers, and tools and application of relevant privacy and security regulations. If possible, students should have the opportunity to discuss these challenges with practicing nursing informatics specialists in the context of their database projects. MODEL CURRICULA These educational needs could be met in a number of different ways. In this article, we describe two different methods of incorporating database management content into a nursing informatics curriculum. Both programs use a real-world project-centric approach for teaching this content. Alumni report enjoying the opportunity to interact with actual end users and to create projects that are meaningful to an audience outside class. Sample project assessment rubrics from both programs are available upon request. UNIVERSITY OF PITTSBURGH In the MSN Nursing Informatics program at the University of Pittsburgh, DBMS content is covered in a dedicated nursing informatics DBMS course. The benefits of this approach are that the content and experiences are tailored for nursing informatics practice, the course can be structured without extensive programming prerequisites, and students can have a start-to-finish experience with DBMS, leading to an understanding of the entire process. The disadvantage to this approach may be a lack of qualified faculty to teach the course and a potential lack of integration of DBMS content and experience with other nursing informatics content. Table 3 Weekl University of Pittsburgh DBMS Content Topic 1 Introduction to course software and resources Introduction to course project Introduction to databases History of database design Flat file versus relational databases Relational versus object-oriented databases Data dictionaries 2 Requirements analysis/functional specifications Introduction to access Introduction to Palm emulator 3 Data modeling Entity-Relationship Diagrams Ask the Client (45 minutes) 4 Data modeling UML Ask the Client (45 minutes) 5 Normalization Joins, etc 6 Introduction to Pendragon Forms 7 Advanced Pendragon Features Algorithms and scripting Access queries and reports 8 Assisted project development 9 Assisted project development 10 Assisted project development 11 Independent project development 12 Introduction to SQL Data warehouses and data mining 13 Final project presentations 10 CIN: Computers, Informatics, Nursing January/February 2011

9 Table 4 Duke University s Informatics Curriculum Model for DBMS Content ( ) Concept 1 st Semester 2 st Semester 3 st Semester 4 st Semester Basic database Field, record, User interface Usability concepts structure, query, report Basic clinical Clinical database Interaction of people, Interfaces information system applications, informatics technology, systems concepts standards; health information exchange Project management Systems thinking, Sociopolitical, ethical, Structures, systems, and systems life cycles teamwork legal, and economic processes, QI, considerations patient safety Logical design Fundamentals of analysis Systems analysis Requirements analysis Requirements analysis (document) Logical design The value of clinical The impact of clinical Domain modeling- Modeling expertise in health expertise in information UML diagrams information technology technology tool development Logical design Build PC database Normalization Physical design Build PDA forms for Build PC database Create simple database clinical data collection Physical design Build Define underlying MS Build queries and execute queries Access structures Physical design Build simple reports Build complex reports Design report Nursing data sets ANA-recognized Tower of Babel exercise Define data set for project vocabularies Data warehouses Data warehouse defined Tower of Babel exercise Data mining lecture Relevant theories Change cybernetics Diffusion of innovation Participative design Chaos/complexity and systems information processing usability theories previous knowledge with new learning Final semester is a hands-on practicum experience that synthesizes At the University of Pittsburgh, the DBMS course is taught in an incremental and sequential method. Each new concept builds on the previous content and is simultaneously applied to a semester-long course project (Table 3 for content). Throughout the course, students progress from experience with the logical design of databases (DBMS designs, requirements analysis, modeling, and normalization) to physical design of the database (building, testing, querying, and generating reports). By the end of the course, students have produced a fully functional prototype database based on a user s request. Data warehouses are a special topic included within the DBMS course; standardized terminologies and interoperability are currently reviewed in another course in the Nursing Informatics program. Students are assessed using periodic content quizzes (30%) and a rubric-based evaluation of the course-long database project (70%). The database course includes practice exercises and homework assignments, which are reviewed but not graded. Additionally students can provide a rough draft of several of their project components (modeling, normalization, and queries) for ungraded feedback early in the semester. Peer evaluation of the final products is also an important component in the final project assessment. This allows students to see how others approached the same problem and provides an opportunity for discussion about strengths and weaknesses of design choices. Depending on the database project for the course, students learn how to use additional software such as Microsoft Access, MySQL, Visio, and/or Pendragon Forms. Appropriate software is provided in the school s computer laboratories for easy access. If home access is desired by the student, software programs can be purchased through the University at a substantially discounted rate. Brief software tutorials are provided within the course, and additional software training resources (such as books, Web sites, or classes) are listed for students within the syllabus. DUKE UNIVERSITY In the Nursing Informatics program at Duke University, DBMS content is taught in a modularized and CIN: Computers, Informatics, Nursing January/February

10 threaded fashion throughout three of the four informatics specialty semesters (Table 4). Content builds each semester and emphasizes foundations and issues (semester 1), project management (semester 2), and information infrastructure and patient safety (semester 3), and the final (fourth) semester is a hands-on synthesis and practicum experience with a qualified mentor. The advantage to this approach is that DBMS concepts are embedded within an applied teaching strategy that helps prepare students for the real world of informatics practice. But a disadvantage is that content becomes blurred, and students sometimes have difficulty retaining important details when they are merged with so many other important content threads. Like with the stand-alone DBMS course, by the end of the program, students have produced a fully functional database project based on a user request. Student progress is assessed using rubrics that are designed to evaluate mastery of DBMS content and hands-on skills, ANA Nursing Informatics standards, 1 and overall course and curricular program objectives, through both individual and team project deliverables. OTHER POTENTIAL MODELS Students could take a DBMS course within another discipline such as computer science to meet most of these needs. However, DBMS courses in other disciplines may not adequately match the practice needs for nursing informaticists and may require additional prerequisites such as programming courses. The level of content within a computer science course for database administrators may not be an ideal match for the practice needs of nursing informatics specialists. CURRICULAR RECOMMENDATIONS Based on our alumni experiences, the ANA Scope and Standards of Nursing Informatics, 1 and ANCC nursing informatics certification test plan, 2 we recommend at least the following database content be included within the nursing informatics curricula: logical and physical database design, standard terminologies, domain modeling, data warehouses, and interoperability. Although a DBMS course within other disciplines such as computer science may cover much of this content, we believe that content inclusion from within the nursing informatics discipline is preferable when available. REFERENCES 1. American Nurses Association. Scope and Standards of Nursing Informatics Practice. Washington, DC: American Nurses Publishing; American Nurses Credentialing Center. Informatics Nurse org/nursespecialties/informatics.aspx. Accessed April 15, Garcia-Molina H, Ullman JD, Widom J. Database Systems The Complete Book. 2nd ed. Upper Saddle River, NJ: Pearson Prentice Hall; Fowler M. UML Distilled: A Brief Guide to the Standard Object Modeling Language. 3rd ed. Boston, MA: Addison-Wesley Professional; Kent W. A simple guide to five normal forms in relational database theory. Commun ACM. 1983;26(2): Doc/simple5.htm. Accessed May 18, Karen L. Courtney, RN, PhD, Assistant Professor, School of Nursing, University of Pittsburgh. Linda K. Googwin, RN, PhD, Dean, College of Human and Health Sciences, California State University, Stanislaus. Jill Aubrecht, RN, MSN, MBA, Project Coordinator, School of Nursing, University of Pittsburgh. Creating an Excel Chart With a Double Axis to Compare Two Data Types Tracy Johns, BSN, RN, CPHQ Jeanne P. Sewell, MSN, RN DOI: /NCN.0b013e3181fb5bf5 Key Points: Effective chart design Chart with a double axis to compare two data types Creating a combination bar/line chart Nurses want to deliver safe, quality care and improve patient outcomes. To effectively do this, the performance of patient care processes must be measured, and the data then used for improvement. This requires 12 CIN: Computers, Informatics, Nursing January/February 2011

11 the ability to create reports with aggregated data that allow people to visualize and analyze the events that affect patient care. By summarizing large sets of numbers, a well-designed chart (graph) can allow people to easily visualize the relationships in quantitative data and support effective decision making. Charts have numerous uses in nursing. For example, to plan staffing levels, nursing administrators use charts to review the nursing unit occupancy rates. By graphing medication errors, nursing, pharmacy and safety personnel can analyze patterns and trends to use for decreasing the number and severity of errors. In many of these situations such as showing falls and pressure ulcers over a given period, a simple bar or line chart will suffice. In these cases, the x-axis (horizontal scale) will show the category such as falls and pressure ulcers, whereas the y-axis (vertical scale) will show the quantity of each. However, if one wishes to show how RN staffing affects the number of falls and pressure ulcers, because this is measured in different units, it is necessary to add a second y- axis. This article will explain how to create a doubleaxis chart that uses data measured in two different measurement units to show a cause-and-effect relationship. Elements of effective chart design will be discussed first. ELEMENTS OF EFFECTIVE CHART DESIGN Few, 2 a well-known information design expert once wrote, Numbers are not intrinsically boring. Neither are they intrinsically interesting. (p15). A chart is both an artistic and scientific way to make numbers appealing and engage an audience. However, given all the bells and whistles current spreadsheets offer for charts, it is important to keep in mind that the real purpose of a chart is to show the data, 1, 2 not demonstrate artistic ability. The key to focusing on the data is to know the target audience and to emphasize the most important results or conclusions of the data. Explain your data in ways tailored to your audience, the goal being to increase their interest in the information on the graph. When creating a chart, evaluate your data carefully. The chart should include only the most important data and emphasize the key points. Because charts represent data as visual objects, several design practices should be followed. Overall, it is best to keep the design clean and simple. This means removing anything that is not essential to the message of the data and summarizing detail that is not vital. Table 1 is a guide for effective chart design practices. Table 1 Guide for Effective Chart Design Practices Scale Display Color Page information Sequence/orientation Bars Text Data range Miscellaneous Adapted from Few. 2 Try to use a zero-based scale; however, the best display is not always zero based. Excel has a default autoformat feature to create a secondary scale for best display purposes. Avoid three-dimensional display of quantitative data. It is hard to read and is misleading. Use bright, vivid colors. What: Make sure the title reflects type of information When: Identify the range of data Who: Include who produced graph Where: Include data source and page number Use left-to-right, top-to-bottom positioning, and word orientation whenever possible Use clearly distinct fill colors Increase intensity of fill color to highlight particular values Avoid use of patterns; they divert attention Font should be as legible as possible. For screen viewing, use a nonserif font such as Arial or Helvetica. For print, use a serif font such as Times New Roman Use the same font everywhere Identify the data range for the data included in the graph Keep tick marks outside the data region and mute in color in comparison to the data objects Use grid lines (thin/light), only if they enhance: Look-up values Comparison of values Perception of data patterns Place titles and notes near the data values that they complement without interfering with values Place legend under the graph to allow more room for the data display Include no more than three to four data sets in a single graph. CIN: Computers, Informatics, Nursing January/February

12 FIGURE 1. Finished graph. Creating a bar chart in Microsoft Excel (Microsoft, Redmond, WA) is relatively easy. Adding comparative data with another unit of measure (a second y-axis) and line chart type requires only a few extra steps. This combination of bar/line chart with a double-axis feature is not available in other spreadsheet software, such as Google Docs Spreadsheets or OpenOffice.org Calc. The chart created for this example uses Excel 2007 and displays 2008 falls and pressure ulcers in comparison to percentage of RN hours. The data source used for this demonstration was from the National Database of Nursing Quality Indicators. CREATING THE CHART When you open Excel, you will see a grid with columns and rows. Each rectangle in the grid is called a cell. 3 The columns are labeled using letters, and the rows are numbered, resembling the organization of a geographical map. A tabbed menu is located at the top of the work screen. (For help with Excel, see net/informatics/chap09spreadsheets/chap09.html# Tutorial). For information about chart terminology, use the Excel Help by tapping the F1 key and typing overview of charting. Additional learning resources for creating charts with Excel are available at office.microsoft.com/en-us/excel-help/overview-of-charting-hp aspx#bmcreatingchartexcel. 4 To follow along with the text, enter into the worksheet the table data from cell A1 through 4E as shown in Table 2. Note that the table in Figure 1 includes two data types and two different units of measurement. The falls and pressure ulcers are the actual numbers per quarter, while the RN hours are in percentage per quarter (Table 2). Once you have entered the data, click anywhere in the table (you do not have to highlight the table data), then click on the Insert tab from the menu. Under the subcategory, Charts, click on the Column icon, and then 2-D Column >Clustered Column (first icon on the left in the first row). A Chart Object displaying the table data will appear on the spreadsheet. To add the second y-axis, right-click on any one of the bars in the chart representing % RN hours. A pop-up menu will appear. Click on Format Data Series located at the bottom of the menu. The Format Data Series pop-up will appear with Series Options as the default. Under Plot Series On at the bottom of the menu, click the radio button by Secondary Axis. Click the Close button to close the menu. A second y-axis scale should be visible for % of RN hours. To change % of RN hours from a bar to a line, right-click on any of the bars for RN hours and select Change Series Chart Type from the pop-up menu. Select Line with Markers, the fourth chart under Line. Click the OK button to close the menu. The % RN hours should now be depicted with a line, instead of a bar. Note that the primary axis uses a zero-based scale; however, the secondary axis does not because the data type is different. Effective chart design dictates that only the essential elements needed to communicate the data are included. Some ways to improve data communication include widening the plot area and moving the legend to the bottom of the graph. The legend describes the data categories used in the chart; in this graph, that is the color bars next to Falls etc. To move the legend, right-click on the legend area, click on Format Legend from the bottom of the pop-up menu. Click the radio button for Bottom legend position. The legend will now appear below the chart. Place the Legend Box as close as possible to the data while not obscuring it. Table 2 Numbers to Enter Quarter 1 Quarter 2 Quarter 3 Quarter 4 No. of falls No. of pressure ulcers RN hours 80% 75% 76% 81% 14 CIN: Computers, Informatics, Nursing January/February 2011

13 SUMMARY FIGURE 2. Creating titles. INSERTING CHART AND AXES TITLES The final step is to communicate the purpose with chart and axes titles. The chart title offers a short explanation of what is in the chart. The axes titles describe how the categories are measured. To add a chart title, click anywhere on the chart. From the Chart Tools menu at the top of the screen, choose the Layout tab (Figure 2). Next, click on the subsection Chart Titles, in the Labels section (third from left). Select Above Chart. The words Chart Title will appear on the chart. Without moving the insertion point, type Number of Falls & Pressure Ulcers. Tap the Enter key. To enter the next line, right click on the title and select Edit Text. Place your insertion point after the word ulcers, tap enter and type Compared with Percentage of RN Hours on the second line. Tap the Enter key for a third line and enter FY 2008, then tap the Enter key. If the title obscures the graph, you can lengthen the chart by placing the mouse pointer on the center of the bottom line where the four dots are until it is a double-edged arrow. Then drag the bottom line to the size you want the graph section to be. To give a title to the axes, click in the chart, and again open the Layout tab from the Chart Tools (Figure 2). Select Axes Titles > Primary Vertical Axis Title > Rotated Title. Type Number of Fall/Pressure Ulcers and tap Enter. The title will appear on the left side of the graph. To name the other axis, again select Axis Titles in the Layout tab menu, but this time select Secondary Vertical Axis Title and Rotated Title. Type Percent RN Hours for the secondary axis title and tap Enter. The chart should now look like Figure 1. The purpose for charts is to display the relationships of data. A chart with a double axis and two chart types allows for comparison of two different data types. Using Excel spreadsheet software, a combination of a clustered bar and a line chart was used to depict a comparison of number of patient falls and pressure ulcers with the percentage of RN hours. Although the percent of RN hours varied by only 6%, the chart showed that the small variation appeared to make difference in patient outcomes for the year Application of effective information design techniques provides a rich medium to communicate aggregated data for informed decision making in nursing. Acknowledgement Ms Johns thanks her informatics professor, Ms Sewell, for her dedication to informatics and education. REFERENCES 1. Koomey J. Turning Numbers Into Knowledge: Mastering the Art of Problem Solving. 2nd ed. Oakland, CA: Analytics Press; Few S. Show Me the Numbers: Designing Tables and Graphs to Enlighten. 1st ed. Oakland, CA: Analytics Press; Wallenbach J. Introducing Excel chart. office.microsoft.com/en-us/excel/ha aspx?pid=ch Accessed April 18, Microsoft. Overview of charting. microsoft.com/en-us/powerpoint/hp aspx. Accessed April 18, Tracy Johns, BSN, RN, CPHQ, Critical Care Quality Coordinator, Medical Center of Central Georgia. Jeanne P. Sewell, MSN, RN, Assistant Professor, School of Nursing, Georgia College & State University. CIN: Computers, Informatics, Nursing January/February