VP Thoughts

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.

Informatics, Medicine, Random Thoughts, Software Medicine, Random Thoughts, Software

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.

EMR, Informatics, PhD cognition, Health Informatics, PhD, Visual Thinking

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.

EMR, Informatics, PhD PhD