…of all those who aspire to develop online systems for patients. - Chapter 2 - e-Patients

It’s not a norm (yet) in medicine to involve patients in the process of care or in improvement of the system. What that means for me and others like me is that we’re going to get lots of “why?” questions about this in everything we do. Most (let’s say, all) of them are going to be intelligent, rational ones, from people who want to improve our health system.

Some of the questions are coming from myself to myself, most recently in the context of the project I am developing with California Healthcare Foundation. I think it’s really important to involve a person (patient, employee, participant) in designing the work, and that I should observe them managing their condition in their native environment (in this case high blood pressure). I recently had to remind myself, “I just gave a presentation on 5 1/2 reasons why patients and families should be involved in their care. I know why.”

Well-timed support from colleagues helps too - enter Susannah Fox, one of my favorite patient empowerment observers and informers, who referred me to this article by Diana Forsythe about a migraine headache patient education software system that was designed by physicians, programmers, and ethnographers, to empower patients with headaches.

If you don’t have access to the article through your institution or purchase it from the link above, there’s a brief summary of it in Chapter 2 of e-patients. In her journey, Ms. Forsythe discovers that a planned intervention to empower patients has the strong potential to disempower them, by connecting patients to information “needs” developed by physicians and programmers only, and not needs stated by others involved in care, including the patients themselves, nurses, and other caregivers.

I added this to what I was asked/told at the Health 2.0 conference in San Diego in March : “Why are current applications only about one to one relationships - patient to doctor?” and realize that’s the “why?” that’s really important. Since it’s a reality that people are as likely to trust someone “just like me” as much (if not more than) their doctor, both have to be brought into the picture. Which means both need to be involved in designing the system.

On the topic of computer programmers, it might be tempting to interpret the story in the article as evidence that software engineers cannot express their coding (or other) creativity and need to be handed specific things to code. What I’ve seen in my own work is that the opposite is more effective - bringing more of the specialized team members into the patient experience is better rather than more shielding from it.

There’s an important clue about this - it’s noticed that several project team members have significant experience with migraines as patients but do not bring these experiences into their professional roles on the project.

Everyone has something meaningful to contribute if they understand (and observe) the customer’s experience, and it’s the role of project leaders to create an environment where this happens.

Related Posts