Virtually Priceless Thoughts

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.

Had my PhD comprehensives yesterday. I was deemed “sufficiently comprehensive”, and so I move forward towards my own research. I thought the exam went well – parts of it felt like a conversation rather than an interrogation so that must have been a good sign.

BTW – I even managed to reference Malcom Gladwell’s TED Talk presentation (below) when being asked about health informatics standards — “there is no such thing as a perfect pickle only perfect pickles”. I definitely find Malcolm’s talk worth watching.

I enjoyed Malcolm’s talk on choice, although clearly too many choices are detrimental as well. Tying Malcolm’s talk back to HINF. We do not know the natural break down, or categories, for clinical information systems — is there an “extra chunky” EMR flavor that we should be designing? Much work ahead, I think.