Although somewhat less structured and consistent than the top-down model, the bottom-up model is more flexible and easier to adapt to changing source systems and end-user requirements. It is also much easier to build in stages. As soon as a given data mart has been defined and built, analytics can begin against that data mart even if others haven’t yet been built.
This very limited discussion is not intended to suggest that these 2 models are the only options in supporting an analytics program. Many hybrid variations exist, and the use of a combination of data marts and data repositories can support a broad array of CA activities.
Presenting and Using Data: Turning Data Into Information
The goal of any CA or BI program is to present timely, accurate, and actionable information to the clinicians and operational staff in a format that is easy to understand and interpret. Ideally, the presentation should be sufficiently flexible to allow end users with a variety of analytic skill sets to derive useful information from the analytics platform. The platform should also allow the users to conduct their own queries—to ask questions of the data that neither the report/dashboard writer nor the clinical or operating staff thought to ask when the tools were being written.
Data presentation can be broken down into 3 broad categories: static reports, scorecards, and dashboards. The static report is the simplest and most basic analytic tool. With a static report, a data repository, data mart, or set of data marts is queried to generate a preformatted set of answers to the query. The report can be scheduled to run at a particular time, or it can be run on an ad hoc basis. The query might be modified to specify a different time frame or patient population, but the format of the report cannot be modified by the end user. Although the lack of flexibility does impose significant limitations, static reports should not be discounted in any analytics program. They are the workhorse of any program.
Figure 6-2 is an example of a portion of a static report from the PICU at Children’s Hospital in Omaha, Nebraska. Each morning, this report is printed at 6 AM in anticipation of morning rounds. It displays each arterial and venous line, along with the number of days each line has been in place, for every patient in the unit. It is used as a prompt to remind the PICU team to remove these lines as soon as possible to reduce catheter-associated line infections.
Figure 6-2. PICU line report
From the perspective of clinical workflow, static reports are usually best viewed within the EHR. This is particularly true for reports that summarize a particular provider’s activities or some aspect of an individual patient’s care. Some EHR vendors embed hyperlinks inside static reports to facilitate navigation within the system. For example, a report that includes shift-based intake and output includes a link that takes the user to the flow sheet that is the source of those data. Well-designed static reports within the EHR allow the clinician to navigate intuitively from one element of the care of a patient or group of patients to another without ever leaving the EHR.
The terms scorecard and dashboard are often used interchangeably in descriptions of analytics tools. For the present purposes, a scorecard can be thought of as a summary report card usually indicating compliance with or progress toward a goal. Scorecards generally include simple graphic elements such a green light/red light indicators or gas gauges indicating percentage of compliance.
The PICU at Lucile Packard Children’s Hospital in Palo Alto, California, uses a scorecard display at the individual patient level to track compliance with CABSI and ventilator-associated pneumonia prevention bundles in addition to the rounding checklist (Figure 6-3). These same data are rolled up to the unit “white board” to ensure data transparency to the entire team (Figure 6-4).
Similar scorecards could be used to report on a variety of metrics including mechanical ventilation surveillance,12