Virtually Priceless Thoughts

I scanned an article this morning on MacWorld about Jonathan Ive and his recent honorary doctorate. He’s the Senior VP for industrial design at Apple and has won many awards for his work and the work of his teams. Here is the quote that stands out for me:

“I love making prototypes. We go right from idea to prototypes. I just love making objects. Prototypes create this dramatic shift in the conversation—suddenly it becomes tangible and the silence goes away.” – Jonathan Ives

This is so true in my experience as well. Although there can often be a form of discussion / debate where people are clearly are speaking about completely different things. Prototypes bring a level of focused discussion and tangible feedback that is key. They don’t have to be physical, they can be software and / or paper prototypes.

Prototypes are the tangible artifacts that can be commonly experienced rather than simply discussed.

My grandmother built models of her larger sculptures for this reason as well.

I spent the day at Oregon Health Science University with Dr. Joan Ash and her team today.

I was invited to spend the day there and was able to present on my current research for my first time to a surprisingly large audience (thank you all for attending). I also spent time with some great people learning and getting feedback. They have a productive and energized group there. I think that is what most impressed me. There was play in the rooms as they discussed dreadfully dull (to most people) topics like CDSS taxonomies, thematic coding and findings from months of qualitative analysis review.

Yes, I was thrilled to find some like minded folks on my trip.

I was also excited by the exchanges I was able to have, even in the short period of time. There were several people working on, or had worked on ideas that very much compliment the work I am doing now on Circles of Care and Continuity of Care.

The discussions will, I have no doubt, add to the richness of my evaluation, both from the perspective of adding some new ideas but also from the simple energizing from this visit. Thank you for that.

Nine years ago I started a little research / development project on the palm PDA called Palm Prevention. This was my resident research project in family medicine and I eventually did a “pilot” study (forgive the pun) and was published. In the nineties I was very interested in PDAs in healthcare and had several projects looking at clinical education, decision making, access to reference materials, and creating tools that took simple context into account.

Palm Prevention was a quick, patient specific screening tool that essentially took 50 or so evidence-based clinical practice guidelines and presented them to the user, filtered based on a few key criteria that fit on a single palm OS screen. Here are a couple of screen shots. The first screen is the start screen where the user provided a few key elements of patient history. The second is the filtered list of guidelines ranked in order based on evidence level (A being the strongest for). From there, tapping on any line brought you details of that guideline.

I released it free on the Internet PDAGuidelines.com. (now deunct, but had several of my projects on it)

Today, I was on the AHRQ site and rediscovered their ePSS. Using the USPSTF guidelines, that have a similar approach and a tool that is available on multiple platforms, including the iPhone:

More slick GUI thanks to the more advanced platform, but similar approach to what I was working on nine years ago. I do not have anything to do with the AHRQ or their tool, but I am happy to see that the idea is still alive and people are finding it useful enough to have a very similar design 9 years later.

We had our second Engineering 4 Health Challenge at UVic yesterday and it was another success! Some great students who participated and some really fantastic ideas that were generated. The topic for this challenge was the same — use the OLPC (One laptop per Child) as the design platform for creating health applications for students in developing countries. One project was focusing on engaging the whole family in their health through the OLPC and the other was a health oriented game that provided health education in the form of game challenges. Really interesting approaches.

The paper storyboarding design for the event seems to be quite manageable and has generated some good results. We managed to squeeze it into a 1/2 day.

We started by having a group brainstorming session – timed, with two facilitators. Facilitators helped clarify ideas from the participants and encouraged students to speak out their ideas, often using one initial idea “build a game” to create several specific ideas about games. On of our facilitators (not me!) started concept mapping ideas, to show the linkages.

Students were then broken into small groups and encouraged to choose and idea. The small groups (4-5 students plus 2-3 facilitators) often found as they selected ideas, they not only drew out more detail, but some also merged several ideas into one package.

The next step for the students was to begin to work out the details of the design and a high level flow. We did this with the students through paper prototyping and pasting together a high level storyboard on 4′x6′ paper. We used paper mock-ups of the OLPC laptops (below) so the students could draw their rough screen sketches on them and describe some of the functional activities on the pages. This really helped quickly make ideas real and also was accessible to students — some focused more on GUI design and others more on functional description.

All the individual pictures were placed on the paper with arrows used to denote typical screen flows for users. Not everything was on the storyboard, obviously. Many of the ideas they had were quite complex and would require a fair amount of content, but the pages really did give a good idea about how the systems might work, following along a specific scenario or giving an overview of the path of a game.

At the end of the morning, each group was able to present their idea to the rest of the students.

I definitely enjoyed this project and wanted to thank all the students, volunteers, faculty, staff and teachers who made this happen.

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.

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.