Involving Patients in IT Application Design

Involving clinicians and administrative staff in IT system design is common practice. For patient-facing apps, should we include patient reps in design sessions?

Involving Patients in IT Application Design

For years now, involving clinicians and administrative staffs in design sessions for IT implementations has been common practice. In fact, the thought of deploying a new application, or making significant changes to an existing one, without their input is almost unheard of.

So why do so many organizations deploy patient facing apps without input from patients?

In theory, every single one of the team members working on a project has the ability to look at things from a patient perspective. After all, everyone has been a patient at some point in their lives. Many also have experience navigating through patient-facing applications as caregivers for children, family members, or other dependants. Unfortunately the problem with relying only on the perspective of team members is that they may not be able to represent the broader patient community. Especially when it comes to experience with technology and general levels of health literacy.

Health IT project team members, including consultants, tend to be quite tech savvy and they often understand far more terminology and health system process than the average aunt Sally or cousin Arthur.

Incorporating patient representatives.

With the industry moving more towards a consumer-based approach, there are patient representative groups that have been established in almost every state and province. Many organizations also have internal or partner adjacent groups they leverage for facility and process design. They just need to loop them into IT.

When considering incorporating patient feedback into the design phase it is important to have some clear engagement parameters established. To understand the size of the group you are looking for, the general representative sample you wish to target, and the time commitment that is expected. For example, involving a group of university students for a single session may not be as effective if the target end users for the application are homebound senior citizens. It is also critical to define the level of influence that the group is to have. Will the group be making decisions on functionality, visual design, workflow, etc.? (Failing to communicate this in advance can lead to a lot of unnecessary frustration by participants.)

Once all the guidelines and intentions have been set, reaching out to individuals that have been involved with past projects is a great place to start. If involving patients is something new to the organization, consider posting an invitation with community groups, in local gathering spots (such as a library), or in media publications.

Before the first meeting, don't forget to assess the current knowledge level of the individuals participating. It's important to understand  how familiar they are with the healthcare workflow that is being considered so you can prep materials appropriately. Determine whether the group has familiarity with the technology to be leveraged or if general instruction needs to be provided in that area as well (E.g., if the workflow something they can relate to another area of their lives? Like online banking, or FaceTime calls with grandchildren?)

Keep lines of communication open, maintain a positive outlook, and welcome the patient representatives with an open mind.