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

I have been working with a friend and colleague over the past month sketching out an idea to develop software for the XO laptop, which is part of the one laptop per child
(OLPC) project. The idea is more about how to get others to design and build software for OLPC and we can help facilitate.

We are exploring how to engage students in BC to design and develop health and health education materials with partner communities in developing countries who are part of the OLPC. It is an exciting idea to get students, both high school and university students, to get together and learn about computer science and about healthcare while flexing their creative design muscles in coming up with tools to help children thousands of miles away.

Seems like we are not the only group who has thought of this, of course. There are several projects proposed and in development through the OLPC and can be found on the OLPC Wiki.

We are piloting our OLPC-Health Design Fest this month - it’s a half day paper prototyping event. I am very excited to see how it works.

Medicine, Software Health Informatics, Medicine, Software, Visual

I came across an article today in the BML, Continuity of Care: a multidisciplinary review. This was a good summary of some of the Canadian work and use of the continuity of care term. Their redefinition of Continuity of Care in to three broad categories is a useful way to organize my thinking as it relates to Clinical Information Systems. Starting from the bottom of the figure:

1. Informational Continuity – links patient specific clinical information between providers and between events. This is related to past information. A provider can review previous blood work, etc.
2. Management Continuity – Describes sharing and modifying future goals and care plans for a specific patient.
3. Relational Continuity – Bridges past, present and future care through on going human relationships. This includes relationships to a group practice. Relational continuity can, I suppose, also include proxy relationships to extend a sense of continuity (which I use in my practice, e.g. “I’ve known Sandra for over 20 years, she’s excellent”).

I have mapped examples of tools to each level of continuity in the figure.

1. Informational Continuity – Includes paper charts and records stored electronically in EMRs, EHRs, etc. This is what we typically think of when we talk about interconnected records. Our standards are focused on information - labs, medications, DI reports, etc.
   Are there tools that can support the other two levels of continuity?
   
2. Management Continuity – Includes care plans as well as Clinical Decision Support in EMRs / EHRs and it also include paper-based clinical practice guidelines that can help direct care. Patient specific guidelines, care directives, etc can help to ensure that providers are not working at cross purposes to patient goals. Clinical Decision Support Systems can provide reminders and alerts at the point of decision making to ensure informational continuity can translate into management continuity. Patient specific care plans / goals are important to capture and share (e.g. advanced directives) to ensure patient goals are addressed. Here, we need standards and distribution mechanisms to synchronize patient specific care plans and goals between disparate clinical systems. There are several gaps in current pan-Canadian standards at this level.
   
3. Relational Continuity – How can clinical systems help with relational continuity? I think that this is a key question to ask.
   • Telehealth – the classic tools of telehealth / telemedicine can extend the reach of the face to face relationship through video conferencing. This helps span distances for rural / remote / specialty care especially. Group telehealth visits can extend relationships and trust by having a (kn)own provider in a visit to share knowledge and to lend credibility to the new provider(s).
   • Electronic Patient-Provider Communication – with your (kn)own providers, electronic communication (e.g. secure email) provides better access and thus continuity.
   • Electronic Provider-Provider Communication – between providers, quick, secure communication (or phone) can extend aspects of the relational continuity to a surrogate provider.

Thinking about how to achieve benefits in continuity at each of these three level, through technology, is a useful exercise for an organization during planning and design of programs and initiatives.

Medicine Health Informatics, Medicine

A colleague of mine was presenting yesterday and used the metaphor of our “broken health record”. Not a new description, true. But used well as a great little metaphor during his presentation. It is used to discuss the fragmentation of a patient’s record across silos created by maintaining separate portions of the record at different locations.

But I got to thinking, the record is broken in different ways still. Definitions vary, so even IF we pull the pieces together we aren’t all singing in the same key. Lab tests with different normal ranges aren’t being graphed together properly. Even within my own EMR, depending on where a patient goes to get lab tests, results in the record may be coded, come in an ascii text documents or are returned on paper to be scanned into the chart. That feels broken - and that’s just lab results.

Diagnoses are certainly worse than lab results in terms of definitions and codes - tempo, instruments, and song are all different when you try to tape the record back together. Things like SNOMED will help, but in my neck of the woods, there is not a strong understanding of the depth that one will need to do to implement it effectively. Current state for many clinics with EMRs is that they have been building up a list of “coded” typos in their diagnosis tables for years. How those will ever be turned into music is serious question when we start integrating those electronically.

The broken record metaphor really doesn’t hold together, of course. At least not in Canada in this day and age.

It isn’t that the record WAS whole and now it is fragmented. It is more like we each sing our own piece of the song after being told what note and phrase the last person said. Now with EHR initiatives we are hoping it’ll fit together like the songs on St. Pepper’s Lonely Hearts Club Band.

Really, it is more like playing telephone than it is like making an album.

We need to work on common, standard, clinically and technically interoperable definitions to make sure we’re all singing the same songs before we can effectively stitch them together coherently.

Privacy issues, of course, are always raised when we talk about single records. Patients WANT to keep parts of their record separate. True. I have had several patients over the years who come to me for STD issues or Viagra prescriptions and not their GPs in order to keep some things more personal. But we can handle that with a single record with proper limits. To keep the analogy complete - isn’t that what the B-side is for?

Medicine Health Informatics, Medicine

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

I have been diving more into visual thinking and visual story telling.

I have often used stories in design and evaluation of clinical information systems - I call them storyboards or clinical cases. Clinical stories help to bridge the technical requirements and clinical needs. It also is an excuse to have some fun, add some color to dry requirements and come up with great names (how about Eara Weatherwax - look at the chart summary here - how can you NOT love a name like that?). They work to focus the clinical audience on a common picture, clear needs, and benefits. Clinicians are patient centric and we all have seen cases like the one’s presented. Cases can also highlight workflow and find gaps in design.

If the story is right.

And that is the tricky part — getting the right story (or stories) to highlight the needs without sounding like you have the worst possible patient in history. Doing that makes the story unbelievable. It has to be honest and completely apparent why a requirement needs to be met. It has to be pitched to the audience at the right complexity. If it is too simple, then the story doesn’t engage and it doesn’t test / stress a system. Too complex and you lose people.

So it is a balance and I have found a few things helpful to get that balance:

1. Carefully adding clinical twists to stories is useful, but only to a degree. They need to fit the scenario. They need engage people in the story line and test the system. Avoid “now this time put in a diagnosis of X” type of scenarios.
2. Making the stories longer is very helpful to enhancing understanding. It provides more context, gives the story duration, and stresses the system. Diagnose a patient with a cough in a visit and any EMR can document that. Now have the story continue with the patient going to get an X-ray and having to update the diagnosis to pneumonia. Shows the process and functionality in a whole different light.
3. Sweat the details. Making sure the story is believable is important. Clinicians will be more engaged the more realistic the story is. I had one colleague dream about our “patients” from a testing session because they were vivid. If there are gaps, errors, it is really REALLY hard to get past them. In one example, I had gone to the point of making up a paper discharge summary of a fictitious patient who was discharged from a fictitious hospital. The page was to be used as back up material in a case. On the list of discharge medications I forgot to add a statin. The doctor who runs the lipid clinic could let that go. So details are important.
4. Pick your values and tests carefully. If you want to show that a flag displays when a lab test is abnormal, don’t make it critical. Unless you intend to (in your story) act on that lab quickly. The doctors in testing will want to — that is what we’ve been trained to do. Better to show something that is slightly abnormal that doesn’t need to be acted on (e.g., a slightly low Hb) and try and impress me with a really high INR or really low potassium. I’ll respond clinically to the value, which isn’t necessarily what your want.

The clinical scenarios engage us in ways that tie us back to what we do as clinicians and that locks in more of our brain as we tie in clinical experience, link to previous cases, etc. This is similar to some of the work on visual thinking that activates more of the whole brain than just narrative.

We use teaching cases with students, but we tend not to use them as well for defining how our systems work.

We also need to look at how to better use clinical stories to teach leadership and the technical folk about the requirements. These require some simpler stories, perhaps, as they don’t need to learn all the details about how to work out pediatric dosing for an antibiotic. But they do need to understand the benefits of a system that supports me and calculates that dose quickly and safely. A system that prompts if there is a drug interaction / allergy. A system that allows me to attend to my patient while not having to think about every detail. Something that helps me treat Eara Weatherwax’s otitis media and makes sure she comes back for her immunizations when she’s feeling better.

Medicine Medicine, Thinking

I love this idea - tying together smoking cessation and social networking. It reminds me of the awe when I saw the marrying of videogames and maintaining good glucose control in glucoboy.

Qwitter, from tobacco free Florida, leverages the existing Twitter network to link people together and to monitor your own progress towards quitting smoking. Check out Qwitter. There is also a quick (qwick?) video on the site (although the connection does seem to be slow) that outlines how it works.

I had the luxury of spending a couple of years as a Visiting Worker for the National Research Council in Canada. I was working in their eHealth Group with Dr. Harrop. These were exciting times where some amazing ground work was done on Personal Health Records and how to use it integrate health behaviour change into people’s lives. Really, Qwitter is a very simple, targeted Personal Health Record that provides two of the key foundations of success for sustained change in behaviour that Dr. Harrop liked to quote:

1. Engagement in a person’s own health information - by using Qwitter, you will log your smoking habits and can watch them change over time. That is a key base to change, is to understand baseline and to receive feedback.
2. Community Support - by posting and inviting friends and family to participate through the Twitter Network, you are sharing your journey with them and they can support you in your process.

As I was writing this post, into my RSS feed came a great post on Zen Habits about health and balance where the guest poster talked about how he used his blog to publicly lose weight. He said it very well:

How am I healthier you ask? It’s simple really. I blogged. I read. People read. I felt accountable for my weight loss and health. We formed a community. I felt inspired. They felt inspired. I lost weight. I got healthier. I blogged some more. Repeat. It’s a no-brainer really.

The whole Qwitter site is public (you can, of course make up a great alias so nobody can figure out who you are, but everything you post is online. This is good to share publicly your thoughts and actions.

The Qwitter site also provides you with feedback in the form of graphs (see right).

Seems like a great idea, but I found it hard to find many people who had logged in and used it for more than a few days. I wonder if it would be more powerful if Qwitter is more integrated with community support locally. Perhaps providers and local programs could leverage a tool like this? I think this might be something to bring up with a couple of my patients.

Medicine, Software Medicine, Software