Virtually Priceless Thoughts

I have been diving more into visual thinking and visual story telling.

I have often used stories in design and evaluation of clinical information systems – I call them storyboards or clinical cases. Clinical stories help to bridge the technical requirements and clinical needs. It also is an excuse to have some fun, add some color to dry requirements and come up with great names (how about Eara Weatherwax – look at the chart summary here – how can you NOT love a name like that?). They work to focus the clinical audience on a common picture, clear needs, and benefits. Clinicians are patient centric and we all have seen cases like the one’s presented. Cases can also highlight workflow and find gaps in design.

If the story is right.

And that is the tricky part — getting the right story (or stories) to highlight the needs without sounding like you have the worst possible patient in history. Doing that makes the story unbelievable. It has to be honest and completely apparent why a requirement needs to be met. It has to be pitched to the audience at the right complexity. If it is too simple, then the story doesn’t engage and it doesn’t test / stress a system. Too complex and you lose people.

So it is a balance and I have found a few things helpful to get that balance:

1. Carefully adding clinical twists to stories is useful, but only to a degree. They need to fit the scenario. They need engage people in the story line and test the system. Avoid “now this time put in a diagnosis of X” type of scenarios.
2. Making the stories longer is very helpful to enhancing understanding. It provides more context, gives the story duration, and stresses the system. Diagnose a patient with a cough in a visit and any EMR can document that. Now have the story continue with the patient going to get an X-ray and having to update the diagnosis to pneumonia. Shows the process and functionality in a whole different light.
3. Sweat the details. Making sure the story is believable is important. Clinicians will be more engaged the more realistic the story is. I had one colleague dream about our “patients” from a testing session because they were vivid. If there are gaps, errors, it is really REALLY hard to get past them. In one example, I had gone to the point of making up a paper discharge summary of a fictitious patient who was discharged from a fictitious hospital. The page was to be used as back up material in a case. On the list of discharge medications I forgot to add a statin. The doctor who runs the lipid clinic could let that go. So details are important.
4. Pick your values and tests carefully. If you want to show that a flag displays when a lab test is abnormal, don’t make it critical. Unless you intend to (in your story) act on that lab quickly. The doctors in testing will want to — that is what we’ve been trained to do. Better to show something that is slightly abnormal that doesn’t need to be acted on (e.g., a slightly low Hb) and try and impress me with a really high INR or really low potassium. I’ll respond clinically to the value, which isn’t necessarily what your want.

The clinical scenarios engage us in ways that tie us back to what we do as clinicians and that locks in more of our brain as we tie in clinical experience, link to previous cases, etc. This is similar to some of the work on visual thinking that activates more of the whole brain than just narrative.

We use teaching cases with students, but we tend not to use them as well for defining how our systems work.

We also need to look at how to better use clinical stories to teach leadership and the technical folk about the requirements. These require some simpler stories, perhaps, as they don’t need to learn all the details about how to work out pediatric dosing for an antibiotic. But they do need to understand the benefits of a system that supports me and calculates that dose quickly and safely. A system that prompts if there is a drug interaction / allergy. A system that allows me to attend to my patient while not having to think about every detail. Something that helps me treat Eara Weatherwax’s otitis media and makes sure she comes back for her immunizations when she’s feeling better.

I love this idea – tying together smoking cessation and social networking. It reminds me of the awe when I saw the marrying of videogames and maintaining good glucose control in glucoboy.

Qwitter, from tobacco free Florida, leverages the existing Twitter network to link people together and to monitor your own progress towards quitting smoking. Check out Qwitter. There is also a quick (qwick?) video on the site (although the connection does seem to be slow) that outlines how it works.

I had the luxury of spending a couple of years as a Visiting Worker for the National Research Council in Canada. I was working in their eHealth Group with Dr. Harrop. These were exciting times where some amazing ground work was done on Personal Health Records and how to use it integrate health behaviour change into people’s lives. Really, Qwitter is a very simple, targeted Personal Health Record that provides two of the key foundations of success for sustained change in behaviour that Dr. Harrop liked to quote:

1. Engagement in a person’s own health information – by using Qwitter, you will log your smoking habits and can watch them change over time. That is a key base to change, is to understand baseline and to receive feedback.
2. Community Support – by posting and inviting friends and family to participate through the Twitter Network, you are sharing your journey with them and they can support you in your process.

As I was writing this post, into my RSS feed came a great post on Zen Habits about health and balance where the guest poster talked about how he used his blog to publicly lose weight. He said it very well:

How am I healthier you ask? It’s simple really. I blogged. I read. People read. I felt accountable for my weight loss and health. We formed a community. I felt inspired. They felt inspired. I lost weight. I got healthier. I blogged some more. Repeat. It’s a no-brainer really.

The whole Qwitter site is public (you can, of course make up a great alias so nobody can figure out who you are, but everything you post is online. This is good to share publicly your thoughts and actions.

The Qwitter site also provides you with feedback in the form of graphs (see right).

Seems like a great idea, but I found it hard to find many people who had logged in and used it for more than a few days. I wonder if it would be more powerful if Qwitter is more integrated with community support locally. Perhaps providers and local programs could leverage a tool like this? I think this might be something to bring up with a couple of my patients.

One of the things that I seem to do a fair amount is make decisions. Also, I try to engage others in making decisions. Be it deciding on a treatment option with a patient or developing a strategy for an organization or deciding on a research project for my PhD – coming to a collective decision is a key piece for me.

And it is not easy.

I am regularly looking for tools and methods to use to help make a variety of types of decisions.

With patients, I sometimes find showing them graphs works some things. (Note a lot of qualifications) An engaged patient with a chronic disease, for example, can benefit from a graph of their blood work getting better (e.g. A1c in the picture), but it is key to tie the graph to their actions. “Since last December when you started losing that weight – look at how much better you are controlling your diabetes.”

During my PhD candidacy exam, I posted the diagram below on a slide. I have been meaning to post about it as it made for some interesting conversation.

During the exam, I had the luxury of using gratuitous animation to reveal the six words as topics from the top down. I talked around the typical level of understanding of requirements for Clinical Information Systems in projects.

I argued that the further down the arrow you go (i.e. the more into the red) the more challenging it is for projects to determine requirements or that level. Indeed, the further into the red you move, more unaware people are of the importance of requirements at that level.

It seems we have strong tools for determining and describing the HOW to technically develop the software. These are “late stage” requirements, various UML diagrams, software design patterns, off the shelf components and the like. This is developer speak.

The WHAT starts moving into “early stage” user requirements — it is what the user is going to perform. What they do. They open a patient’s record. They dictate a consult letter… This level of granularity is something that gets captured fairly well too (you can see use cases spilling out of each what that people do). Still the granularity is challenging for complex systems. How many hundreds of pages of use cases are needed to fully capture functions for a hospital information system?

WHO refers to the user, of course. Often this is simply a list of “roles” that can do certain things (e.g. physicians prescribe, office assistants do not). But surely understanding the user is more than listing role types and making tables stating which use cases pertain to which users? Understanding who a user is is also important – what are their skills: can they type, how old are they, what are their background, their training, etc.

Understanding the user requires more physical contextual understanding of work. User personas are helpful here.

WHEN for me refers to when in the user’s workflow they do the things that they do, not so much the time of day. When also talks to the need to understand the interconnectedness of Whats (and Whos) — when do I diagnose a patient? Is it at the beginning of the visit when I pick my template or is it at the end, after I have documented my findings? It’s surprising that many systems provide you with fixed templates based on diagnoses that you won’t know until you’ve assessed a patient.

WHERE is actually easier to define and some might argue that it should be much higher up the chain. I’ve placed it lower on the list primarily because it is becoming very easy for the technical teams to fall back on “it’s a web app” so it can be “accessed from anywhere” and that is the end of the requirements for where. Clearly, though, there are differing requirements for if I am at home on call vs in the exam room with a patient.

Who / When / Where cluster together into a physical context – and this is important to understand how well a system fits.

That leaves WHY. The why are the underlying motivators for action. They are, to me, the important sub-(con)text. Why do people do what they do? Why do we need to the system? These are the earliest requirements.

What I hope can be done is to focus on the WHY early on and develop a more detailed understanding of that level of motivation before developing the other five. The Whys are less transient and the right whys can help us reason about options for the whats and hows in later stages of requirements engineering and into design.