“Motivating behavioral change through data visualization can be very powerful, but it is more of an art than a science. We will need far more artists, user interface experts and psychologists to help make our data work harder to motivate better health.”
Designing for Health: A Pediatric Prototype focused on Allergies
It’s been a while since I posted design solutions to food allergies. The last highlights were the participatory educational videos that B made for his teachers and caregivers about how to use his medications and how to handle his food. But there are other design problems in day to day life that need to be fixed as well.
At the beginning of the year, I needed to have some essential information about my kids (list of allergens, phone numbers) to be physically in their backpacks side by side with their allergy medications in case something happened while they were on the bus or away from campus (since this info was locked in the school nurse’s office). This was my original prototype when we started school.
But as you can see it was a less than ideal solution in terms of lack of comprehensive information and horrible design (hastily written information on an index card with a Sharpie: the definition of design “suckiness”?).
Therefore, I created nametags inspired by the amazing ones that Larry Chu makes for attendees of Medicine X every year.
The nametag booklet contains vital information on the front, including pictures of each kid, name and birthdate, a listing of their allergens, and QR code links to B’s videos. On the back are the emergency numbers for both parents, which also can be accessed by QR code links as well as instructions about where to take them in case of an emergency. Finally, inside the nametag is a booklet which contains instructions (with the illustrations from B’s video) on how to give an antihistamine, how to use the Epi Pen Jr, and how to use the Auvi-Q, as well as a comprehensive list of tricky and bad allergens (thanks to foodallergy.com for the lists; I even learned about some new allergens from this design exercise). This is a great tool for school, for aftercare, and for the babysitter too.
Again, I went with the notion that pictures are better than words, there is color coding and use of icons from the noun project for the different allergens, and you can easily get to the videos and phone numbers as needed using a QR reader on your mobile phone.
What if we had prototypes like this for other childhood chronic diseases like diabetes, asthma, or other conditions that require special preparation for the caregiver? I would love to see variations on this theme.
(Here are prototypes of the front and inside of the booklet (in illustrator) as well as a pdf of the inner booklet that you could use to make your own.) Icons from the Noun Project from Rodrigo Bruno, James Keuning, Sergi Delgado & Jong Hyuk Kwon.
High-res
The Safety Net for Children with Diabetes in the US: Another #diabetes + #dataviz Prototype
Why did I take the time to create this visualization?
First, because I think this information could be useful for families and providers of children with diabetes, given how difficult it can be to navigate our current system of health care coverage.
Second, because I believe strongly that we as scientists/researchers have an obligation to communicate our work to the public. I expound on this here in greater detail in a response to a post by Susannah Fox.
Finally, because I believe that visual communication is a much more effective way of disseminating information and knowledge. I have been following the new trend of datajournalism that we are seeing from news outlets like New York Times and the Guardian, using digital and interactive representations of data to engage readers beyond the simple text format. I hope that this will be the first of many data visualizations to come!
Here are the findings:
Any family with diabetes will tell you how expensive it can be to live with the disease. Children in particular, need to have frequent visits with the medical team (up to 4 times a year at a minimum), medications like insulin), and supplies for monitoring blood sugars (test strips), and glucose monitoring systems. Children often receive coverage from a parent through health insurance provided by the parent’s employer, but if they don’t have this option, there are programs that provide coverage based on your income, usually Medicaid (if you fall below a certain percentage of the poverty line, or State Children’s Health Insurance Program (SCHIP), which is a program that allows for higher income families to get coverage if they are not poor enough to qualify for Medicaid but can’t afford to pay for private insurance.
Title V programs are a potential safety net system of coverage for children with diabetes. These programs are different from Medicaid and or SCHIP because eligibility for the program depends on having a specific diagnosis; i.e. kids with specific chronic diseases (sickle cell, cystic fibrosis, asthma, diabetes) can qualify. Each state administers its own Title V program, which could lead to variability in coverage across states. Therefore, my colleagues and I looked at variation in eligibility and coverage specifically for children with diabetes, by interviewing programs in all 50 states, which was recently published.
We created an interactive map to show our findings, so head over to diabetessafety.net. We found that children with diabetes were eligible for Title V programs in just 32 states. At a minimum, these states would provide assistance with coordination of care for these children, which generally means that provide personnel or services to help the family coordinate care between medical teams (i.e. improving communication between providers), but not providing actual coverage for medical visits, or medications/supplies.
However, only 25 states (only half of states!) provided medical coverage to pay for visits with health care professionals and medications like insulin, and only 24 states also covered diabetes supplies.
Keep in mind, the interviews were conducted in 2006 so some of this data could have changed since it’s now 2013. However, the bottom line is that children with diabetes have a 50/50 chance of having access to the safety net, and it depends on geography as well as income (there is an income eligibility requirement for title V programs in addition to having the diagnosis, although the thresholds tend to be higher than those for Medicaid or SCHIP). The results are not surprising, but are disappointing. You can mouse over each state to find out what kind of coverage is provided in a given state.
High-res
I have been privileged to give a number of talks for colleagues at Stanford and UCSF while on sabbatical. One of the topics that I have been talking about is physicians and social media. Here is a version of my social media talk, adapted for the internet and housed in Speakerdeck, in which I talk about why it’s important for physicians and researchers to be on social media. I think it’s a nice complement to David Shaywitz’s excellent article titled “Four Reasons Doctors Worry About Social Media - #GetOverIt” which came out in Forbes a few weeks ago.
#dataviz + #design + #diabetes: The beginning
I love interactive data visualization (#dataviz). It is one of the things that I definitely wanted to explore when I came out to the Bay Area on sabbatical, because I believe that it has great potential for helping both patients and clinicians with diabetes management. The sheer volume of numbers available for this disease is overwhelming; we need #dataviz tools that can help us achieve greater understanding and make actionable clinical decisions to improve health.
This is what we usually see in clinic: numbers written down on a piece of paper.
Yes there are computer systems that link to blood glucose meters, but there are a number of complexities with the downloading of blood sugar numbers in clinic (which deserves an entire blog post sometime in the future).
You can see there is some visual analysis and annotation that we do perform, albeit primitive. The circles represent high blood sugars (>150 mg/dl)and the triangles represent low blood sugars (<70 mg/dl). This is almost better than the cave painters don’t you think?
But even the minority of patients who download their BS to the computer, are viewing dashboards like this.
Pie charts, need I say more? I can extract some useful insights from these charts, which improve over the previous one I showed, but a few things strike me: (1) some of the scatter plots overlay weeks of data, which I don’t find helpful because you can’t tell how BS on a given day are responding and relate them to life events; (2) some visualizations show a lot of numbers in many of the sections, and it just becomes onerous to go through them and find trends; (3) many provide statistics (area under the curve, MAD%) which I think only a minority of families and children really understand; (4) although some of the software programs do provide interactivity and let you see the data at different time scales (day, week, month), if you change to a different view, you are stuck trying to remember in your head what you saw on a previous screen because you can’t see the multiple levels at once; (4) finally, I find that the user interface and design could use major improvement.
When I arrived to the Bay Area in the fall, I went to a meetup that I thought was a general #dataviz meetup, but it turns it actually was a d3 meetup. I couldn’t understand a word of what people were saying (all codese) but I did get some feedback from the group on the pros and cons of different visualization software like tableau, processing, and d3, and after this chance encounter, I began thinking about how I might use d3 for my research projects.
It turns out that in the fall, Jeff Heer was teaching a class at Stanford about #dataviz, and I was fortunate to have the opportunity to have his students (Ben Rudolph and Reno Bowen) work on a diabetes visualization for their class project, and to find a trusted collaborator who was willing to share personal blood sugar data.
This is the prototype, inspired in part by a Trulia heatmap, which shows blood glucose data from a continuous glucose monitoring system (CGM). You can link to the actual dynamic visualization here.
CGM gives a readout of interstitial blood glucose (BG) every 5 minutes. The dashboard displays day, week, and month views of BG as a heatmap. Red represents a high BG and blue represents a low (BG) sugar. The more intensely red it is, the higher the BG, the more intensely blue it is, the lower the BG. White represents a normal BG, and grey represents missing data. Finally, the three small boxes at the top of the day view represent the % of time that individuals are high, low or normal for the month, week, or day.
I really love this prototype for a number of reasons:
1) You can see all of the data, not just pieces of it; you can scroll up and down the month view to see data that spans years.
2) It’s visual. The colors tell the story Numbers alone can be totally overwhelming, so the color gives it some visual order.
3) There is a day panel, a week panel, and a month panel that all can be viewed simultaneously, to give a greater sense of perspective. For the month display, we purposely went with 3 months at a time on the right hand side since that is the interval at which we see our patients.
For the week display, we went with 2-3 weeks as we often will make changes in the insulin regimen using the last 2 weeks of data.
For the day display, I did want to be able to see the actual numbers because I as a clinician might not feel totally comfortable recommending changes in insulin doses based on a color shade, but the nice thing is that it’s a number on demand: it hides, but then only appears if you hover over the line with your mouse.
4) The interactivity is really smooth and all of the displays are connected. When you click on a given day in the week view, the day view panel changes to match it and the black arrow on the right of the month view also moves to the corresponding week. Likewise, when you click a day on the month view, the corresponding week is highlighted on the week view, and the day view changes to the corresponding day.
5) Customizability for the user. You can click the bottom arrow of the week view, and the 3 week view shrinks to a 1 week view, allowing the viewer to simplify the visual space as needed. Also the user can turn date labels on and off.
6) Finally, it has a great minimalist design and doesn’t have the notorious chartjunk.
Ben and Reno wrote up a summary paper of their project for the class. They quote my effusive reaction in their paper:
Note to self: Stop using so many exclamation marks in a row. But seriously, this is how passionate I am about #dataviz + #design + #diabetes.
This is just the first prototype. There is much more that I want to do with this visualization (adding additional datastreams like insulin data, location, physical activity, mood data). I see this visualization as the starting point for the front end of a mobile technology web-based platform for helping clinicians and patients manage diabetes. But even more importantly I am interested in talking with patients and families about what they want to see or use, given that they are the real experts with this disease (either through interviews and through crowdsourced initiatives check out medevice-users and this flickr page) If you have feedback on this first prototype, please share it! Hopefully there will be more to come soon!
High-res
The difference between small data and big data in mobile health.
If an app transmits data on a deserted island and no one is around to hear it, see it, or accept data from it, does it really exist?
I was giving a talk at a diabetes conference this weekend and someone asked me: “What diabetes apps would you prescribe to your patient? “
It turns out that I just recently wrote a review about diabetes and endocrinology apps for an academic journal with one of my fellows. Although the list was fresh in my mind, I couldn’t think of a single app that I would prescribe. Now, mind you, that doesn’t mean that there aren’t useful apps out there that I could recommend and that my patients would find helpful for managing their diabetes. So maybe it was the word “prescribe” that made my mind go blank. As far as I can tell, there are potentially 3 apps to prescribe. Welldoc which is a patient management system that helps manage adults with type 2 diabetes, but most of my patients are pediatric so let’s put that one aside. What’s left is Glooko and iBGstar. They are glucometers so I could technically prescribe them, but usually we don’t prescribe a specific glucometer; we write glucometer on the script and the insurance dictates what meter they get, regardless of patient or provider preference.
Unfortunately, these FDA approved apps, as well as additional diabetes apps (apps that have individuals manually input their blood sugars, carbohydrates, and insulin doses), leave me wanting for more, because they represent stand alone systems. They don’t connect with the EMR systems at my hospital, and in many cases the only method for transmitting the data to the health care team is through email. But email is not secure, and our institution therefore discourages its use for communication of medical results with our patients. Although data is continually being generated, I have no way of seeing it.
It’s like an iPhone app on a deserted island. If no one is there to hear it, see it, or download data from it, does it exist?
Mark Wilson, of Co.Design wrote an interesting piece about the future of interactive design which I think holds true for the arena of #mHealth:
“You shouldn’t just try to understand a product. You should try to understand its connected network.”
So listen #mhealth designers and start-ups. If you want to achieve widespread adoption and not just small scale consumer uptake, it’s not about the app alone. It starts with an app, which can connect with a much larger digital healthcare ecosystem, that can seamlessly, painlessly, and securely (in a HIPAA compliant manner) transmit data and meaningfully connect individuals with chronic disease with their healthcare teams. Check out this post as well by Halle Tecco.
Icons from Athena Manolopoulos, Roderick Chow, The Noun Project
This graph shows the link between mobile application design and clinical utility. Good #design thinks not only about the consumer, but also the larger healthcare ecosystem.
The ALiveCor iPhone ECG monitor in the hands of an E-patient: Peril or Promise for the Future of Medicine?
This is probably one of the most exciting social media feeds that I have ever read on Twitter. Last night, Hugo Campos, an e-patient advocate for access to his own medical data and who wears a Medtronic defibrillator for his heart condition, felt a fluttering sensation in his chest. So he grabbed his iPhone ECG recorder, licked the electrodes, put it against his chest, got an ECG recording and shared it on Twitter.
He noticed what looked like atrial fibrillation on the reading, but a debate started among some of the doctors to whom he tweeted.
Was it atrial fibrillation which is a life-threatening condition, or was it artifact?
Dr. Wes suggested that it was artifact, but Hugo brought up a good point: he did the recording because he was symptomatic, which is a valid clinical reason to do a heart ryhthm recording. 
Before the advent of the AliveCor, the pattern might have gone unnoticed, because he would not have had the tools for recording his own EKG on a Wednesday night at home; nor does he have access to his own data from his defibrillator, as noted so astutely by Gene Moy.
Dr. Wes and Dr. Albert (the inventor of the ALiveCor) suggested that he send the tracing to his physician.
Hugo took 2 aspirins in case it was atrial fibrillation.
Dr. Wes retweeted and commented: “A new world indeed: self rx?”
A heart monitor in the hands of the patient: Is it a perilous journey with an uncertain outcome, or is a promising act of liberation for the patient?
In the last few days, there has been a lot of debate on this topic (see this post and this post), reflecting the two sides represented in these tweets.
On one hand:
Peril: It’s dangerous and irresponsible to give the patient too much of their own data.
To date, EKG interpretation has been solely in the control of the physician, rather than the patient. Because of this, patients aren’t formally trained to read EKGs, and there are concerns about whether they might interpret artifact as disease activity, potentially leading to additional self-administered treatments that might endanger their health, increase their anxiety and worry unnecessarily, and increase costs to the health care system.
On the other hand,
Promise: It’s liberating and it’s the right of every patient to have access to their own data.
The patient is the expert of his own disease. He knows better than anyone else when the symptoms begin, and when to check a heart rhythm. If he can measure his heart rhythm in real-time, he now has data that he can use to make decisions about his health. For example, Hugo has previously described how he was able to correlate the onset of his arrhythmias with drinking scotch, so he gave up scotch. As Hugo writes, “I believe we all have the right to access any and all health data collected from our bodies, whether or not we are capable of understanding it.”
Are EKGs in the hands of patients a new frontier for American medicine? Maybe, but maybe not. Let’s think about other diseases, like diabetes. Endocrinology used to be like cardiology; in the absence of any tools for home monitoring, glucose could only be measured and interpreted by the doctors. But then technology for monitoring the condition at home was developed. We first sent patients home with crude tools like urine strips, then home glucometers, and finally continuous glucose monitoring (CGM) systems, all versions of the portable modern-day EKG for the diabetes patient. Would we ever say that it’s dangerous to give a patient with diabetes a glucometer or CGM device? I don’t think so; those devices are the cornerstone of self-management to achieve the best outcomes possible.
Whenever new technology enters the medical landscape, there is a steep learning curve, for providers, for patients, and for the health care system (see Dr. Wes’ post here which brings up some legitimate concerns). We are at the beginning of that learning curve now, but I predict that the AliveCor, in the hands of one motivated e-patient, will be just one of many mobile health monitoring tools that will transform how we define “self-management” of disease for the future.
Hugo sums it up nicely in this tweet:
Learning from the Design of a Weather Mobile Application?
The design of currently available medical mobile applications for management of chronic conditions like diabetes leaves much to be desired. Why is it that a weather app is so much more compelling in its user interface than a medical app I might recommend to my patients?
I was really excited to read about, Haze, a new weather app that challenges current mobile app design and communicates data through the interface itself. Instead of relying just on numbers, it communicates information through animation, color, and placement.
For example, when you look at the temperature, there is a rippling animation in the background. If it ripples upward, it means it will be warmer tomorrow. If it ripples downward, it means it will be colder tomorrow. A display at the top shows the temperature for each day of the week. Higher temperatures sit higher and lower temperatures sit lower, and are color coded as well. There are screenshots for hours of daylight left and chance of precipitation as well, which follow a similar design.
It would be really interesting to see apps for chronic disease management take a similar approach. For example, diabetes is a disease of data points that are too numerous to count, and studies have shown that individuals with low numeracy (the ability to understand and use numbers) have worse glycemic control. What if we could create a diabetes app like Haze which would uses “spatial, color-coded, and animated information” to help individuals and providers make optimized clinical decisions? Although it is very cool, Haze in its current form would have limitations as a diabetes app. It only displays 1 number per day, and only 5 day trends. It also would be difficult to compare how different types of data relate to each other, because you would have to flip to a different screen for each data stream. But I am really impressed by the design and user interface, and look forward to seeing more apps like this, hopefully in the health arena.
