VP Thoughts

I was reading Presentation Zen, Garr Reynold’s new book (link is to his great blog). In there he has a side bar on Pecha Kucha (Japanese for chit-chat) — a night where architects get together and, if they present, they are only allowed to use 20 slides and each slide can only be on screen for 20 seconds.

That’s a 6:40 presentation run, no exceptions.

It is an interesting constraint to a presentation and one that would be very interesting for academic talks. We already present under time limits, but don’t have the slide restrictions.

I think having a restriction on slides to precisely 20 images, makes you become more explicitly aware of what you are going to do with each one rather than just stringing together a bunch of slides. 20 seems a reasonable number to get students or faculty to start experimenting with.

Some groups are apparently trying this. I might try and suggest this for our department. It is definitely something I would like to try. There is a group not far away - but my topics of medicine / informatics might not quite fit what they want…

PhD, Random Thoughts PhD, Random Thoughts

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

I received a package this week. Inside was the textbook:
Human, Social, and Organizational Aspects of Health Information Systems.

Turning to page 23, as I read the title to Chapter 2, I cannot help but grin. “A Bio-Psycho-Social Review of Usbility Methods and their Applications in Healthcare”

My first book chapter.

Very exciting for me to see - I even had the opportunity to draw my own figures. All in all, it came together fairly well for a first chapter. Writing has never been natural for me (as my dear mother - an English professor - will sigh about), but it did come together.

The key to the chapter is that usability has many forms and can work at many levels. Like medicine, a reductionist view is powerful but not sufficient. We do much better today if we understand the biology of a disease, the personal impact of the illness, and the impact it has on the social network around a patient. For healthcare information systems (e.g. Electronic Health Records), it is the same. First we need to understand the bio (mechanical) aspects of systems - where the computers are, how big buttons are, etc. Next, the design impacts how a user (e.g. RN, MD) makes decisions and need to consider and observe the psychological (cognitive) impacts of design. Finally, medicine is a team sport. At the smallest, the team is the patient:provider pair, and increasingly the team is getting larger including people over time and over distance. Information systems need to support the group work - for improved effectiveness. If we design and test at all three levels, our systems will be more usable and more functional. The chapter is a review of some tools and work at each of the three levels.

So that was my contribution. And the rest book has a great collection of authors. I have had the opportunity to learn and work with several of them over the past several years. I am also honoured that I had a chance to help establish an 18-month primary care informatics fellowship a few years through UBC (thank you Peter!) that supported several BC family doctors learn more about informatics, that grew in collaboration with CIHR’s fellowship to include a primary care stream. Several of the fellows are are contributing authors.

Finally a quick thank you to the editors, Drs. Kushniruk and Borycki for inviting me to contribute a chapter to this book and for not making any snide comments on why “psycho” ended up the title of my chapter.

Medicine, PhD, Software cognition, Medicine, PhD, Software

This past winter I discovered a relatively new little application called Flying Logic. It’s designed - specifically - to represent decision graphs. Gone is the tweaking with placement of boxes and shapes of arrows and you’re left with the ability (requirement) to focus on how to model the logic of your problem / solution / system. It’s based heavily on the Theory of Constraints and there is information on the web site describing how to use the tool using that paradigm. Basically the idea is that systems are finite. Some systems are more finite than they need to be because there are bottlenecks (constraints) that can be worked on and elevated / removed, making the system more efficient and productive.

One built-in model, the Prerequisite Tree, I find particularly useful (see diagram). Basically it provides a simple structure to document your goals and then map out the things you need to overcome to achieve those goals. Finally you document milestones that, if achieved, mean that what needs to be overcome is completed.

If you want to find out more about Flying Logic, it is best to see it in action and there are a couple of good videos on the site that are worth looking at.

Interestingly, the pro version allows you to create your own classes (the other versions can accept templates, but not create new ones). I have found that feature helpful in arranging thoughts, arguments, etc. in relation to my thesis. The diagram below (click for a bigger picture) was a draft to organize my thoughts in framing various potential research questions on diagrammatic reasoning.

I set up some research elements, based on a framework published by Weber and Wand, attached my questions to those elements and then built down my methods. Finally I mapped out phases for the research and “promoted” some questions to key questions as they were summations of several others.

In the end, we are focusing on the question “In what ways do physicians reason differently about EMR requirements when using conceptual diagrams as compared to textual requirements?” thanks, in part, to Flying Logic Pro.

Of course, we have gone through some more iterations since I sketched this out, but it gives people an idea of a more complex map.

PhD, Software PhD, Software

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

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.

PhD, Random Thoughts PhD, Random Thoughts