Macadamian Blog

Part 4: How to Create Engaging Patient Software

This is the 4th post in this series of five posts. Part 1 Part 2 Part 3

Understand & Address the Concerns of Clinicians

Patients are not the only users who stand to benefit from patient software. Clinicians — including physicians, nurses, and nurse practitioners — can benefit as well. As noted by K.T. Fuji and K.A. Galt, “Healthcare providers want access to a patient’s aggregated health record to enhance their own abilities to accurately and comprehensively treat and monitor the patient.”

Today’s clinicians, however, are often reluctant to adopt portals, worrying this software will add to their workload or present difficult legal and privacy concerns. While our advice is that patient software should always be designed with the patient as the primary user, it needs to provide enough value to clinicians to outweigh its perceived risks.

1. Patient expectations and legal responsibilities
Clinicians are very concerned about the expectations of patients entering health data into a patient software system. If a he enters information daily, will that he expect his doctor to check it daily and to have read all of the information before the next appointment?

When inviting a patient to register to a portal, set expectations. For example, if the software allows patients to leave a message, make the rules of engagement are clear, i.e. “This portal is not meant for urgent care. If you leave a message, expect a minimum of two business days for a reply. For an emergency, call 911”. In turn, the software should support the rules of engagement by displaying the appropriate warning messages at key times — including during registration and before data is submitted.

2. Privacy/security
Privacy and security concerns will often create a barrier. Health care providers in the US are bound to comply with HIPAA regulations, and in Canada by the Personal Information Protection and Electronic Documents Act (PIPEDA). For these reasons, security has always been a top concern when dealing with the adoption of patient portals. Providing clinicians with an audit trail of all interactions and allowing patients to see exactly which providers have access to their health data can help address some of the concerns raised by providers.

3. Scheduling
Many clinicians we have spoken with are uncomfortable with the idea of having a patient schedule an appointment via a portal. Patients are not qualified to know the amount of time a visit will take and many doctors only schedule appointments for certain activities (such as physicals) at specific times or on specific days of the week.

If you do design a patient self-scheduling application, start small. Only allow patients to request an appointment rather than to schedule one. Or, work closely with your client to identify routine procedures that can be made available for self-booking during a specific block of time. For example, your system could act like a seat reservation system for an airline and allow adult patients to book a 20 minute consult for a physical on Wednesdays between 9:00 a.m. and noon.

4. Billing
A significant barrier to physician adoption of patient software is remuneration. How can physicians bill for online interactions with a patient? Ideally, your patient software should take this issue into consideration by allowing physicians to issue invoices and collect payments online. The Canadian Medical Association’s http://www.mydoctor.ca is an example of a portal that allows physicians to bill patients directly for uninsured services, such as requests for prescription refills and remote monitoring of chronic conditions.

Clinicians are a key “non-patient” user group, but they are not the only one. Our final post in this series relates to all of the other stakeholders that can interact with a patient software solution. Stay tuned!