Provider Institutions (hospitals, medical centers and other health systems) are currently at a crossroads when considering how to best represent clinical and business information in a meaningful way that can be understood by all levels of the organization. We find increasing awareness and use of “digital dashboard technology” to provide relevant information to clinicians and hospital administrative staff in a visually rich, easy to understand format to improve the quality of patient care, as well as develop strategies to reduce cost in the delivery of improved patient care.
Designing and using clinical dashboards requires substantial clinical (physician and nursing) involvement and a well-defined process. The criteria for developing a model for a Data Store, a data warehouse and series of individual dashboards, may be of use to you and your organization as you move forward in the world of healthcare analytics dashboards. After all, Information Technology (IT) is not useful if it is not meaningful to the user. Here are the 8 steps that can ease your transition into healthcare analytical dashboards:
- Meet with users to determine data needs
- Design the appearance or presentation layer
- Design the semantic layer
- Design the physical layer
- Develop and test all 3 layers
- Perform QA
- Conduct a Pilot
- Begin general rollout
The Future of Big Data
With some guidance, you can craft a data platform that is right for your organization’s needs and gets the most return from your data capital.
Here are basics for these steps:
- Meet with clinical and business users to determine major data needs. Many users and potential users of dashboards aren’t familiar with the systems’ power and capabilities. They typically use non-interactive spreadsheets and graphs that present data in fixed rows and columns and lack the flexibility of Web-based tools. The first step in this phase is to inform clinicians of the many additional possibilities that a more powerful tool offers, with examples that are clinically based. First, build sample dashboards to demonstrate the tool’s capabilities and how having these dashboards added value to the work being done by the user. Then ask clinicians to identify several key measures, dimensions and filtering criteria for the dashboards they were interested in.
- Design the appearance or presentation layer. For dashboards to deliver the most benefit, users must agree on appearance and presentation standards before the design phase begins. It’s crucial to achieve agreement on items such as color schemes, graphical objects and navigation standards so future dashboards will look, feel and behave consistently. This will improve user satisfaction and reduce training demands for each new dashboard. This also is very important in separating specialty and sub-specialty areas. Design of these dashboards requires that we think carefully about the hierarchy of the data they want depicted in the dashboards and what levels of the hierarchy will be visible to the user. In our example, the hierarchy is Specialty-Practice, Physician, and Patient. Depending on a user’s security status, he or she may or may not be able to see the patient data. Once the hierarchy and associated measures were grouped into a dashboard page, select the graphical elements. Histograms, line graphs, pie charts and simple tables present the data in an intuitive fashion that meet users needs and simplify navigation throughout the dashboard pages.
- Design the semantic layer. The semantic layer maps the presentation layer to the physical layer. Developers prove their worth in the design of this layer. Defining patient populations by disease categories, grouping drugs hierarchically by therapeutic area and organizing physical locations are examples of the challenges that the semantic layer’s designer faces. Users play a key role in formulating those definitions. In-depth knowledge of both the presentation layer design and the physical data models is essential.
- Design the physical layer. As mentioned, try not to change the design of the physical layer. Whenever possible, avoid creating an entire new physical data structure, because doing so generates the need for additional extract, transform and load (ETL) steps each time the clinical data warehouse is updated. Redundantly storing data produces additional storage, backup and maintenance costs and opens up the risk that duplicate copies of data won’t be updated with the same frequency as the original.
- Develop and test all three layers. Users who are new to the dashboard development process will likely need to see how the systems operate with real data. It is useful to introduce clinicians to a working prototype to gain early feedback on the design. Regularly scheduled demo and review sessions (biweekly was noted to be best) help developers refine and test the design. When you’re engaged in this phase of the project, take care to manage scope creep, since the clinical user and business key stakeholders and/or participants might be tempted to request new capabilities or data that weren’t in the original design. Put off responding to such requests until a subsequent release of the dashboard has been completed.
- Perform quality assurance. Here are several quality-assurance requirements developed during deployment activity:
- Use data from the actual data warehouse, rather than simulated or test data.
- Include weekly, monthly and quarterly data warehouse updates during the QA process, especially when the data being used in dashboards will cross calendar months, quarters and years. A year-end data update would be ideal, but most projects can’t wait that long.
- Compare dashboard data to the original source systems, to ensure that no translation or presentation errors were introduced during development.
- Test system performance and response times with large amounts of data to ensure that the dashboard responds effectively to users’ needs.
- Conduct pilot tests. Before making a dashboard available to the general clinical and business population, ask a small group of users to pilot-test it for a few weeks as a short extension of the QA phase. This provides additional information on usability, performance and quality.If the pilot group (users from the clinical and business setting) recommends moving forward, proceed to roll out completed specialty department dashboards to “key users” within the general population of that specialty. If the pilot group identifies problems, the development team resolves them in as much of a “real time environment” as possible to decrease the development cycle time.
- Begin general roll-out – This phase involves these major components:
- User orientation: New clinical and business users may need a brief training session on how to set up “My Dashboard” views and reports. Those who have used dashboards in the past should be able to use the new dashboard with no assistance, as long as the presentation layer was designed well. These users can also act as trainers to those needing assistance. “Users training users” works better when dealing with the clinical end user.
- Support documentation: Gather design and operational specifications and post them on support sites. Also, develop a “one page” data sheet on how to use the system and post this to the organizational training web site, as well as How To documents with screen shots of the tools in use.
- Help-desk hand-off: Write scripts and give them to the help desk for guidance in responding to support calls. Having staff that are better suited to communicate with clinical staff may prove very helpful as well. This could be an RN who has the technical expertise to demonstrate how the tools work and show users how to best exploit the technology.
So, there you have it, follow these eight steps and your organization will save development time, insure that the dashboards will be used by those who requested them, and most importantly, you will give meaning to the data, which in turn makes the data useful!
Has your organization implemented healthcare analytic dashboards? How have these 8 steps helped?
