The 5 W's of dashboard development are presented and reviewed with a COVID-19 Tableau dashboard case study.
Working in analytics in the healthcare industry is an incredibly rewarding experience. No other industry provides analysts the same ability to positively change lives of people and patients like healthcare. Over the last several years I’ve been fortunate to work in this space and developed countless Tableau dashboards. The more dashboards I’ve built, projects I’ve been involved with, workgroups I’ve been a part of, and road bumps encountered along the way, the more I've tried to refine my dashboard development process. I expect that analysts in other industries have similar processes but there is something unique to healthcare. I’m convinced healthcare data is some of the most complicated data to work with and the moving pieces within a health system make it a challenge to navigate for analysts starting in this field.
Looking back on some of lessons learned, I thought it’d be helpful to write this post about the 5 W’s of Developing Healthcare Dashboards. The 5 W’s are Who, What, Why, When, and Where. These 5 W’s are questions I ask when beginning any new request for a dashboard. They provide a foundation for me to build from that helps me (and hopefully you in the future) best meet the needs of the various individuals and workgroups that I work with.
Analysts working in healthcare (hospitals, health systems, payors, consultants, biotech etc) are the primary audience for this post but there is also valuable insight for those who are dashboard consumers and requestors within a healthcare organization as well. To make things a little more tangible for everyone reading, I will breakdown a recently created and real-life example of a COVID-19 dashboard as our case study of how these W's applied during that dashboard development process as we go along.
Who is up first!
Who
Who is calling the shots? Who needs to be included? Who do you need to work with? Don't forget who is behind your data.
Healthcare is all about collaboration. I’ve seen the amazing outcomes and improvements to the quality of care patients receive as a direct result from collaboration across non-clinical and clinical teams in a hospital. There are likely workgroups and taskforces across your health system that are running with a specific focus and goal like reducing readmissions, hospital acquired infections, or new patient wait times. These groups are the ones who are likely reaching out to you to build dashboards, so they can analyze and monitor the impact of their work.
While this collaboration within the hospital is great, it also presents a challenge in development that analysts starting in healthcare might not be ready for. Too many cooks in your dashboard kitchen can become a common issue if you don’t add the proper guardrails and expectations in your development process. You should identify who needs to be involved during development but it’s even more critical that you identify who the key decision maker is. This might not necessarily be the person with the highest organizational title touching the work – it might be the person running point for the workgroup, or the person running point for this specific project. It’s part of you and your team’s responsibility to help identify that final decision maker and ensure that it’s clear to all involved with your dashboard development. This will be who you’re able go to for direction when potential conflicts of asks or suggestions from the workgroup come up. This happens all the time during dashboard development and you’ll be thankful having a key decision maker identified from the get go.
Key stakeholders and that key decision maker might not be the only people who will view your final dashboard though – they might not even view the final dashboard themselves. You’ll want to identify who is expected to be the primary audience for your work and can’t assume it’s just the person or workgroup asking for it to be built. I’ve built several dashboards through a workgroup that they themselves weren’t the actual primary audience of the produced dashboard – like a physician specific dashboard where the requirements and development was led by the Medical Staff Office but the primary audience was the actual physicians. Knowing your end audience is a critical piece of information needed before you even begin any kind of development.
Knowing your end audience is a critical piece of information needed before you even begin any kind of development.
Beyond who makes up the audience, I also like to gauge experience with Tableau and dashboards in general. I wouldn’t assume that just because someone has a MD or RN or PharmD that they’re savvy with the latest and greatest functionality in Tableau. I often see examples of technically impressive dashboards from a developer standpoint that are lost on the final end users. I try to make a concentrated effort to slowly sneak in new functionality and tools with groups as I see their experience and engagement with dashboards I’ve built build over time versus throwing the whole kitchen sink at them from the word go. Most often if you don’t have a dedicated training program or team and immediate engagement from end users, I try to start with the basics – report with a KPI (or three), a trend, and a bar graph, and maybe a text table with a few filters. While filtering data might seem like an out of the box feature to you the analyst, the ability for an end user to filter something like patient quality outcomes by different patient populations or operational groups within your health system in seconds is incredible.
You also need to figure out who you might need to collaborate with behind the scenes. Do you need to connect with someone else on your team who knows a little bit more about the required elements within your EHR? Do you need to connect with your Tableau site admin to set permissions up for each stage of development? Do you need to another project to finish first or get reprioritized? There’s a lot that often happens behind the scenes and it’ll be important that you identify all the potential people you can collaborate with to meet development milestones in a timely fashion and give you confidence that your dashboard reflects the most accurate data possible.
Finally and most importantly - don't forget about who is behind the data you're reporting on.
Finally and most importantly - don't forget about who is behind the data you're reporting on. We work in healthcare to improve the lives of all the patients coming to our health system, using our medical devices or medications. Often times working in healthcare analytics and the constant need for new dashboards, you can forget that these are real people you're reporting on - sometimes on things that would be life changing if they happened to your own family. While the focus of this post is centered on things to ask and do when building a dashboard for healthcare, this paragraph is meant to be a reminder. Additionally - consider incorporating disaggregation and comparisons of different patient populations to evaluate equity of care and service (a topic that deserves it's own blog series).
COVID-19 Dashboard Case Study Breakdown: Many healthcare organizations and systems were flooded with urgent COVID-19 related needs when cases started within the United States in early 2020. To ensure we were prioritizing the right needs, we looked to hospital leaders to help provide direction to what they needed first. From this, we set up a recurring call with an identified project manager working closely with our hospital command center to stay connected to any changes and other staff who needed to be involved during development. We also later identified the need to work with our IT team to set up a real-time feed for a few data elements. Being able to identify the various who's to this work paved the way for an ultimately successful project and dashboard.
What
What is this workgroup looking to do with this new dashboard? What functionality is going to be needed and what would be a nice to have? Are there specs? Are those specs defined internally or by an external body like CMS, The Joint Commission, or Payor Contracts?
There are so many what related questions to dashboard development. These questions are how you help define the scope of the work before you begin. I’ve had several projects that just continued to iterate and evolve because of scope creep. Outlining with the group requesting the work will help protect you and make it more likely people have appropriate expectations of what you’ll be providing.
When I ask what the workgroup is looking to do with the dashboard, it’s partially to ensure I build the report to meet that need but it’s also partially to evaluate if Tableau is the appropriate tool for their need to begin with. If it’s an external requirement to print out performance and patient charts for an external audit from the Joint Commission, Tableau might not be the best tool and as much as I love the product, I’ll recommend a different approach. It’s okay to recommend different avenues for data related needs. Doing so will ensure you’re protecting bandwidth and providing the most value possible when developing dashboards.
It’s okay to recommend different avenues for data related needs.
Once I know that a dashboard is appropriate for this need, I’ll try to identify what pieces of functionality in my Tableau Dashboard will be appropriate. Is this group trying to investigate and compare performance across different patient populations? Do they just want to quickly track outcomes? Do they want to be able to send emails directly from the report? Investigating what they’re intending on doing with the dashboard and bringing in experience using Tableau can set your next dashboard up to become an integral part of the process to improving care within healthcare.
Beyond the Tableau components alone, I also need to know if there are specifications outlined by an external body or if we’re managing them internally. Those new to the field might be blown away at how many external specifications and reporting requirements exist in healthcare. Things that seem as straight forward as “we’d like the volume of patients with hypertension” are loaded questions to an experienced analysts and dashboard developers. We typically and quickly have follow ups like how are you defining hypertension, where are you documenting that a patient has hypertension, is it a one time or long term diagnosis, are there specific events that need to occur for it to be considered a patient you want to track, and while we’re at it do you actually mean patients or visits from patients? The list goes on, but the point here is that you’ll want to identify specifications and work with the key stakeholders and decision maker to define your scope of work. Once the scope and specs are agreed upon, you’ll want to add appropriate definitions throughout your final dashboard. Many people are not going to be up to date on the specifications for All-Cause Readmission Rates as defined by CMS so having a quick couple of lines snuck into the dashboard will go a long way in helping end users.
COVID-19 Dashboard Case Study Breakdown: After identifying who we needed to connect with around all of these COVID-19 data and dashboard requests, we were able to appropriately prioritize the immediate key needs for the organization. For us it was real-time counts of our COVID-19 confirmed patients as well as testing volumes and results. Identifying the real-time need, we then needed to connect with IT to develop the necessary data structure (and learn a little bit about HL7) and determine what was technically possible for us. While doing preliminary work with IT, we were also connected with clinical staff in Infection Control and Infectious Disease which provided us a tremendous guidance on the operational definitions of what a COVID-19 Confirmed patient actually was, which in turn, helped us identify which data elements were required with IT to meet this initial need. After getting this operational definition and learning what was possible from a real-time stand point we were able to mock up a version of the dashboard that would hone in on quick KPIs around patient and testing volumes with several filters available for those needing to dive further.
Why
Why do we need this dashboard and data?
This is a critical question. From first hand experience, I know it can be difficult to ask why but it’s absolutely crucial. When I first started working in healthcare analytics, I was intimidated and worried too much about the clinicians thinking I wasn’t smart enough to keep up – don’t think that. Yes, these are some brilliant people you’re working with but don’t forget you’re the dashboard expert and asking why will help you ensure your dashboards really provide value.
Asking why is different than asking what.
Asking why is different than asking what. It’s often pretty easy for a group or individual to tell you what they’re wanting in a dashboard but asking why helps refine that ask for all involved. I often run into situations where the asks are for everything under the moon about a specific topic. It’s true there’s so much data available – even just out of the EHR – but throwing all of it into a dashboard won’t provide tremendous insight. Knowing that why behind it can help you focus on what data you need to pull, what data should be quick KPIs, which can be more detailed analysis, etc.
I typically ask the why behind the ask at a high level if I’m not already aware from various work emails or meetings but then I will also ask the why behind some of the secondary and tertiary asks of a new dashboard. It’s in these questions I’ll find out about interdependencies between asks and the data I may need to pull in and present. This is also where I really lean on the various subject matter experts that are involved. There’s no sense in pretending to be a doctor, nurse, pharmacist, or other clinical worker. Let those who are the experts help you get the understanding required to make your dashboard as relevant as possible. I often schedule meetings with specific individuals involved in the work to walk through their workflow on the front end of our EHR or to discuss a topic related to the dashboard I’m developing. Seeing this front end view and hearing first hand what’s going on in practice is an invaluable resource in the dashboard development process in healthcare. Don’t forget about the bevy of experts you have the opportunity to work with (plus it’s not as fun just developing something all alone anyway).
Asking the why and checking that against the originally defined what questions and answers mentioned above will set your dashboard development up for success.
COVID-19 Dashboard Case Study Breakdown: This one wasn't as much a question of why we needed a Tableau dashboard of our COVID-19 patient and testing volume (it was admittedly self-explanatory) but more why were we defining our patient population the way we were. Things were being done on the operational side of the hospital to ensure we could appropriately identify COVID-19 patients independent of how they made it into our health system. Learning this and the various ways things could happen from a workflow perspective was incredibly valuable for us to ensure we could provide numbers and data that aligned best with what was going on in practice - adding trust to the final product.
When
When do you need this by?
This is a staple question when first beginning your dashboard development. If you haven’t already, you’ll find this question gets a predictable response somewhere along the lines of “three weeks ago, but when can you get this done for us?”. There’s typically a tremendous amount of data asks in any data-driven healthcare organization (which is great), but these often create backlogs in analytics that complicate your ability to set timelines for deliverables around your dashboard.
The more you develop and work within an organization, the better your ability to estimate timelines for workgroups and new dashboards will become. You can cut the experience required to become a strong time estimator by being analytical about this though! I recommend doing a time-series analysis while developing your next several dashboards to refine your timeline estimating ability. A future post will dive into this in more detail but you can break timing down by different variables and steps such as: information gathering/pre-meetings required, data preparation (with different indicators of if the data are new or familiar for you), dashboard development, teams/individuals required (collaboration associated lags are real), prioritization/time allocated per week or day. Tracking this will give you an internal clock for new work and improve your response to the when can you get this done question as well as identify potential areas for improvement in the dashboard development process (either due to your organization, team, or self). Whatever your average timing looks like, I recommend then adding a buffer as things always seem to come up – be it a new urgent request, data prep challenges, stakeholder availability changes etc. I personally add about a 1.5x multiplier on my externally communicated timelines but know others might want even more buffer while first beginning work. Whatever timeline buffer you have and timelines you set externally, I do recommend consistently checking your progress along the development process and raising flags earlier rather than later if your dashboard development is lagging behind what you expect internally. Just as it’s easier to provide dashboards earlier than promised, it’s also easier for all involved to adjust and respond to changes to your timeline when those changes are communicated as soon as it’s apparent things are no longer on track.
I recommend doing a time-series analysis while developing your next several dashboards to refine your timeline estimating ability.
Another critical when related ask is when do you need this updated? Depending on your organization and tools available, you’ll need to know when jobs need to be scheduled (or worse, manually accomplished – side note, you should be able to automate most things when it comes to Tableau dashboards, even quality controls). Many organizations do not have real-time feeds hitting their Tableau dashboards (it’s possible but not the default for most) so you’ll need to figure out if the group is comfortable with the data and dashboard being updated on a daily, weekly, or monthly cadence. Knowing the What and Why behind the dashboard can help define this requirement for you. We find most that are being used to monitor processes are daily but those dashboards that are tracking outcomes are on less regular updates to avoid overreactions that could occur after an outcome one day that is within normal day-to-day variation.
A third when related ask is when does this need to be re-visited? Over time, you’ll develop more and more dashboards. Even with all the proper quality checks and automated processes, the more dashboards you develop, the more you need to maintain and become responsible for. It can eat into your ability to create new content and address new needs for your hospital or healthcare organization. By establishing a review process to clean up dashboards you can add additional bandwidth. My recommendation would be an annual review and establishing data-driven thresholds to identify that dashboards are still being used. An annual review or spring cleaning may help you retire dashboards entirely or even better identify minor enhancements needed that’ll take the dashboard to the next level in the upcoming year – either way doing a review is a recommended step not to forget about.
COVID-19 Dashboard Case Study Breakdown: This dashboard was an immediate and urgent need for the hospital. Knowing we couldn't get everything right away, we established many small timelines and communicated that iterations would be released as new data became available and the dashboard became more refined. This helped us get data out as soon as possible (within about a week and a half) but the dashboard itself continued to have new versions released every week for about another month after the initial version was shared.
Where
Where do most of your dashboard consumers view your dashboard?
I find in healthcare many are viewing dashboards I’ve developed on their desktop workstations but there’s been a recent push to make more mobile friendly layouts to improve the value of subscriptions from Tableau Server. Healthcare doesn’t stop and many of the main consumers of your dashboards are constantly on the move and dealing with competing priorities and knowing where they’re most likely to view your dashboard has a big impact on your design.
If it’s a dashboard that’s really meant to be a pushed report via subscriptions, you’ll want to have it built in a way that quickly calls the KPIs and identifies if performance is moving in a positive or negative direction. Think – when my key audience is in the elevator running to their next meeting and glances at their email, how quickly can I provide insight? If it’s more of a dashboard meant for exploratory analysis and interaction, you have more flexibility in how you develop. Knowing these questions helps a ton and will drive appropriate engagement with your final dashboard.
There’s also the physical location that people are viewing your work. Are people likely to view these dashboards on campus or at home? Are there things you need to work with your Tableau Server Administrator on around firewalls or VPN to ensure everyone is able to safely connect to the data they need.
COVID-19 Dashboard Case Study Breakdown: The majority of staff were going to connect with this dashboard on their desktop. Knowing that, the amount of data, and future updates in the pipeline, we were able to make design decisions that were similar to how we've built other dashboards in the past.
Bringing it all together
There are so many moving parts and questions along the dashboard development process and it can be hard to keep it all together. The below breaks the above down quickly as a future reference.
Who: Identify who is the final decision maker and who else needs to be involved in this development? Collaboration is critical in healthcare and you’ll need to identify these roles early in the development process.
What: What is the original ask and what is this workgroup or team looking to do with your dashboard? Are there specifications you can follow? This helps define scope for your work.
Why: Why is this even an ask in the first place? Asking why after what helps refine the scope of your work.
When: Provide timelines and track progress internally to help provide appropriate expectations on delivery dates.
Where: Where are people most likely to view your work? Is it on the run or sitting down in their office? This will vary by project and organization but is a critical question before beginning work.
COVID-19 Dashboard Case Study Breakdown By The W's Who: Hospital leadership with a project management point person for prioritization, Infection Control and Infectious Disease for operational knowledge, and IT for technical support. What: A Tableau dashboard was needed to provide real-time COVID-19 patient and testing volumes for the hospital. Why: COVID-19 has had a massive impact on healthcare (and the world). Knowing what volumes of patients were admitted with COVID-19 is critical for hospitals as they assess their staffing, PPE, ventilators, and other resources. When: This was an urgent need but through planned rapid iterations we looked to get the dashboard out as soon as possible. Where: Staff primarily access dashboards through desktop.
The 5 W’s of hospital and healthcare dashboard development are great questions to ask when beginning a new assignment. They’re only the beginning, it’ll be up to you to execute next but feel free to connect through this site or LinkedIn to share your own lessons learned!