Virtually Priceless Thoughts

Amongst my work friends, we like to “fail fast” – that is to put up something for feedback quickly so that it can rapidly evolve with group input rather than polishing something on your own until you think it is “done” only to find out your second step led you in a direction you didn’t need to go.

So here is an early version of a goal map for a PCRN – this is based on the i* notation and does take a few sentences to describe. First, there are actors, represented by circles. These actors have goals, the pill shaped icons. Actors in a network are typically dependent on others to achieve certain goals. The arrows represent the dependencies. You can read it like this:

“ACTOR X wants to achieve GOAL A and is dependent on ACTOR B to achieve GOAL A”

or less abstractly:

“A PATIENT wants to have GOOD QUALITY CARE and is dependent on a FAMILY DOCTOR to receive GOOD QUALITY CARE.”

Hopefully that helps understand the image below (click for a larger version) and do provide comments – I would like to use this post to solicit public feedback and revise the map to help support our local design thinking.

(click for larger version)

Jess McMullin has a good slide deck where he describes (slide 9) five levels of Design Maturity. (1)

Those levels are (paraphrased):

1. Default – Status quo determines design.
2. Style – Changes to look and feel
3. Function – Design improves use
4. Problem Solving – Seeks current problems and changes
5. Framing – Redefinition of the problem itself.

This is a good list to remember in healthcare.

The potential for improvement (and some types of risk) increase as you move from default to framing. Also, it is harder for users to conceptualize the changes as you move through. It’s easy for people to visualize “we are going to put this paper form on the computer”. It’s harder for them to consistently visualize “where we’re going you won’t need to document”, or large lists of requirements… As you move along the levels of design you need to rely on more iterative and visual tools to support shared and common understandings of the changes that are being considered.

1. I found a similarity to a list of maturity for Business Analysts that was on Better Projects. If you are a BA or work with BA, think about where you fit in this list of maturity for the various kinds of activities / projects you work on.

I came across this little slide show that I quite liked this morning on visual thinking. I like the 4 Ms and 6 steps of visual thinking (starting on slide 21).

Right now I’m in the deep, dark part of the PhD – the dissertation writing. Having cleared away everything else, but the blank papers in front of me, I have no excuses but to write.

Well I have actually discovered plenty of excuses… that is the nature of writing, isn’t it?

I am moving steadily along and feel like I have a handle on where I need to go. I have done enough of the analysis work before now that this is mostly about writing, instead of doing the conceptualizing / analysis in parallel with the writing. That definitely seems to help.

I have my daily and weekly goals and that’s good.

One of my touch points is volume of words. The target is at least 1,000 words a day. I feel like I have accomplished something if, among the other pieces (e.g. editing, etc) that I have generated 1,000 words. It’s not the only measure, but it is one metric to work against (to quote Monty Python:

Sir Edwin: Ah, well, I don’t want you to get the impression it’s just a question of the number of words… um… I mean, getting them in the right order is just as important. Old Peter Hall used to say to me, “They’re all there already– now we’ve got to get them in the right order.”

But number of words is a good metric. It’s clear and measurable. And I start to create a chain of activity that I don’t want to break — every day, 1000 words. What if I miss a day? Can’t do that, I’ve had 9 1000 word days in a row. Gotta make it ten. That works well.

In a break today I started thinking about ways to keep the chain and slack off (the human mind never ceases to amaze me). “Never fear, I can count my pictures… that’s right. A pictures worth a thousand words, isn’t it? If I miss a day, I’ll count one of those…” My dissertation is full of pictures. Excellent! My brain has found a way around my own self imposed productivity standards… but maybe pictures are really worth a 1,000 words.

So I surfed and – even better – I came across this image:

It appears there was an error in translation – 10,000 words! I can take off the whole week and still make quota! Ah, I love August by the lake… but alas, no matter how I count my actions, I still have to reach “done” as defined by my supervisor and my committee in fairly short order and cannot bask in the warm shade much.

Also, it turns out that there were a couple of errors in the translation of the chinese proverb, actually. As Paul Lester explains:

In fact, the literal translation is: A Picture’s Meaning Can Express Ten Thousand Words.

He goes on to explain that:

With the correct interpretation of the proverb, words and pictures live in harmony as they are both used equally in order to understand the meaning of any work that uses them both.

This is a wonderful interpretation that works well with my dissertation. I’m sure to find a use for it somewhere as much of the work in the study relies on visual communication of findings through pictures and (visual) models.

Until then, however, I am either going to have to change my metrics (1000 words, and 1 picture) or I am going to have to up my daily quota for words, otherwise I am sure I am going to find myself slacking off, counting pictures as 10,000 words each.

Last summer, after some months working on a proposal, I slowly came to the realization that I needed a more clinical topic. After some deep thinking, I decided to change direction.

Now, several months later, I have successfully defended my PhD Proposal. I am developing a model to analyze and improve Continuity of Care. Care Continuity is not a new interest (I posted about it in June) and is a topic that keeps me grounded in the clinical aspects of health information science.

It has been a busy ride since I have made the decision – I have had to re-develop knowledge in several new theoretical foundations and methods, but I am excited about the study that I have developed and think that it will have a positive impact in the communities that I will be working with. Stay tuned for more details on my approach in the future.

I have been listening to some great stuff by Dave Gray and others on thinking visually. Not about clinical information systems design, but about approaching complex situations through visuals. Dan Roam’s book The Back of the Napkin is an excellent introduction to visual thinking and how to design sketches to help think and present ideas.

Definitely regretting not having gone to Viz Think ’08 this last year, but thankfully they have shared several pieces online (check the blog in particular).

Much of the discussion is around making a complex and chaotic world make sense. Distilling the complex whirl of information into something that can be engaged and reasoned about. A story given a sense of time and knowing that stats don’t give people. Visuals engage the right side of the brain in a way words don’t, helping to process information in a different, more holistic way. The two help make sense out of the utterly complex.

(Note the irony that this post is the first without a visual.)

Well, Henson, once again, was ahead of his time.

Kermit Learns Visual Thinking

Right now my research is focusing on creating activity diagrams to describe functionality of EMR systems. Specifically, I’m “reverse engineering” the activity diagrams from an already published list of EMR functional requirements. Several provinces have published EMR requirements as part of various RFPs over the past year. There appears to be overlap between a lot of them and I understand that is by design and re-using the standard set of requirements.

After spending some time coding a set of EMR requirements to see what format might make sense, it was clear that activity diagrams were a good choice. My reasons include:

• Content mapping confirmed that the published functional requirements covered most “processes” or “things,” which is as expected for functional requirements.
• The “things” were not well defined. That is it would be difficult to create a data model from the content within the functional requirements (some groups have defined data elements separately, which is a good start for interoperability).
• In my research, physicians will be reviewing activity diagrams. They are somewhat familiar with activity diagrams as they are similar enough to care flow decision trees. They won’t require a weekend course on how to read the diagrams to be able to interpret them.
• They are commonly used and part of the UML standard, so many requirements engineers will be familiar with them (good for future application)
• My learning curve is not as great and I can focus on content development.

Interestingly, how the requirements are written (see Saskatchewan Ministry of Government Services website – Competition Number 2462), have made swim lanes difficult to create the requirements do not typically specify which user can do what — see the example below from Saskatchewan.

The Solution should provide standard clinical tools that support clinical documentation and decision making and can be accessed when doing clinical notes.

e.g. Framingham risk calculator, BMI calculator automatically placed next to height and weight fields.

Other than the swim-lane issue; however, the development of activity diagrams is proving to be achievable. In fact, I think not having the swim-lanes will likely make it easier for doctors to review them as they are more like the flow diagrams we are used to in clinical practice diagrams. As you can see from this BC Asthma Guideline (pic below)

Once the diagrams are complete they will be validated and compared to a set of published text requirements to ensure that they contain equivalent information. Then the experiments begin!

We are going to compare physician comprehension and reasoning using requirements in diagram form with the published requirements in text form. We’ll be asking the physicians to validate the requirements and describe any gaps.

What we are hoping to find is that one method proves to be a clearly better way of getting feedback from physicians for requirements than the other. Which method does not matter as much as discovering if one way is more impactful than the other.