Developing Patient Portals
Macadamian Technologies | January 9, 2017 | 16 Min Read
Increasingly, digital health software vendors are developing systems that aim to improve the quality and portability of patient information and give patients more control over their own care and well-being. However, many healthcare organizations are struggling to institute these systems in a way that satisfies the needs of both patients and physicians.
Increasingly, digital health software vendors are developing patient engagement and care management applications, patient portals, and remote patient monitoring software. These systems aim to improve the quality and portability of patient information and give patients more control over their own care and well-being. Many healthcare organizations, however, are struggling to institute these systems in a way that satisfies the needs of both patients and physicians. Google Health is a well-known example of a patient platform that did not live up to initial expectations, but it is not alone. Across North America, patient software, whether developed by a healthcare organization or a third-party software vendor, is suffering from low adoption. In fact, only 7% of respondents in a recent survey had ever used a Personal Health Record. Critics cite a number of factors for the overall lack of patient software success to date:
- Existing patient software is not user-friendly or engaging enough to encourage repeat usage
- Patients are unable or simply not “ready” to interact with self- care software
- Patients are concerned about the privacy and security of their information
- Physicians are concerned about the added responsibilities and regulatory implications of interacting with a patient portal
Ultimately, the biggest patient software challenge is to include the right feature set that will encourage patients to use the application regularly and, ultimately, convince reticent healthcare institutions to engage in the patient software process. If you’re looking to build a patient-facing application and want to make sure you address some of the key issues, consider our top four areas of consideration for software executives and healthcare institutions looking to increase the adoption of patient-facing software and realize its full benefits.
Where’s Your Typical Patient?
Believe it or not, most patient software was not designed with the right users in mind. Many patient portals actually feature screens that were originally designed for clinicians. Clinician-facing systems, such as electronic health record systems (EHRs), already existed. It was the simplest (and cheapest) solution for developers to borrow an area from the existing interface and simply expose it to patients via the web with little to no redesign.
Unfortunately, patients do not normally engage well with interfaces designed for clinicians.
Even if the software was designed from the ground up for patients, the work is often done with a “typical patient” in mind; but good luck defining typical. The requirements of a healthy person who visits a doctor once or twice per year will differ greatly from those of a patient with a chronic condition. Moreover, patients with chronic conditions will have needs that are unique to their specific ailment.
Instead of designing for some unattainable generic patient, software developers must identify the key patient personas found among the system’s user base. While patients vary greatly in age, health, income, and comfort level with technology, those with common characteristics can be grouped together to create profiles — called personas — that reflect particular patient attributes, needs, and goals.
These personas must guide the design and development of patient software in order for it to be valuable and actively used.
Patient-facing applications can be uniquely difficult to design and develop as a result of the added complexity of a geographically wide and diverse user base. It’s because of this we recommend creating low fidelity prototypes for patient groups. You can then test the concepts with real-world patients in order to guide the development and evolution of the software. You’ll want to consult a user experience professional with credentials in human-computer interaction design to ensure the greatest success of your application.
EXAMPLE: Patients with Congestive Heart Failure
The ultimate goal of all of the user research and the persona grouping exercise is to determine the needs and goals of your target audience: what is this specific patient type trying to achieve? What are his or her motivations, concerns, and context? What terminology would this patient use? These focused goals should drive the evolution of patient software.
Let’s imagine that your patient software is focused primarily on patients with congestive heart failure. The results of your user research might suggest the following areas of focus as being most important to the product:
- The ability to organize health records, including medication reconciliation (91%)
- The availability of online calendars and reminders (74%)
- Access to personalized health education (71%)Access to community services (69%)
- The ability to communicate online with providers and health plans (60%)
- The ability to manage health care costs (57%)
By identifying specific patient needs like those listed above, you can start to map out a design that will directly address those particular user requirements.
Engage Patients the Right Ways
Once you have identified a specific set of primary patient users, it is time to determine what will engage those patients and keep them returning. What information and features will they value most? How must that information be presented initially and over time?
Healthcare consumers will submit their patient data only if they are motivated to do so. Any mobile application, patient portal, or online marketplace intended to engage them must be designed with these considerations in mind:
- Design the product using well-documented interaction design patterns, as outlined for example in BJ Fogg’s model for persuasion.
- Identify the user’s emotional needs through research techniques like diary study and journey mapping, and then design to those needs.
- Explore the user of different engagement techniques like gamification, but rigorously test their use with real-world users in real-world context.
- Focus on creating a trusted system that is robustly engineered, using an iterative software design and engineering process.
- Fogg’s model on creating habits and automating behavior change is an excellent starting point, but it must go in hand with a strategic and long-term vision. Take advantage of proven, repeatable techniques for designing motivation systems, rooted in user experience design carried out by robust software engineering.
While this information will vary from patient group to patient group, the following are some of our top guiding principles for driving long-term patient engagement with patient portals.
Present Information They Want
A recent study by Sharp Rees-Stealy found that the four most frequently accessed areas of a portal by a patient differ completely from those areas accessed by a clinician. Patients used the portal for booking appointments online, engaging in secure messaging with a provider’s office, and viewing lab tests. Your own patient research may or may not match those particular findings, but if your interface does not present a clear path to the information patients are most interested in, they can become frustrated and less likely to interact regularly with the system.
Provide Immediate Value
For illustrative purposes, let’s explore how a patient with Type 2 Diabetes might use the patient software. If she needs to enter a blood glucose reading, she will not be content to simply enter the data. She will want to monitor trends, see correlations with her activity levels or what she ate for lunch, and understand the implications. She may wonder: “Should I call my doctor?”, “Is this a normal reading?”, “If not, what should I do?”.
Patients with a chronic illness may deal with a large number of providers and wish to keep track of all of their contact information, upcoming appointments, and recent communications via the software. If your system can provide added value beyond simply housing basic information, you will be able to ensure patient satisfaction and uptake.
Make the Information Relatable
In a very real sense, patients and clinicians speak a different language. A doctor can quickly recognize a high cholesterol number, but a patient may have no way to interpret whether a figure is high or low (you need to put the information in the patient’s context). When designing your interface, implement illustrative techniques (such as color coding or a dashboard) that will help patients interpret and understand the metrics they find in their online file.
Below is an excellent example of a blood test result design (conducted by Wired Magazine) that color-codes and simplifies the results. It is much easier to understand than a simple black and white piece of paper with only text and numbers.
Include Next Steps and Offer Patient Goal Tracking
While a physician might be content with simply knowing that a future appointment has been scheduled, a patient will want to know exactly when that appointment will take place. Moreover, a patient with a chronic ailment may want to track her progress over time and the ways in which she is contributing to her own healthcare via exercise or alternative treatments. If a user can see (via visual graphics) that she is losing weight or lowering her blood pressure, she will be more likely to return frequently to the software and feel empowered through its use.
Give Patients Reasons to Return
Many patients think that the idea of patient software “sounds” great, but quickly abandon it after their initial interaction. Patient software is worthless if patients aren’t entering data on a regular basis, or using it at all. Consult your patient persona and user research findings to hone in on areas that give users a reason to come back to the software again and again. These could include:
If a patient has an upcoming appointment with a specialist, the system could send that user a message via e-mail or SMS to a mobile device. Or, if the system knows that the patient has diabetes, it could send reminders to enter a glucose reading and monitor trends.
Integration with Other Apps and Systems:
Many patients already use some sort of monitoring device — be it a step counter, a glucose monitor, a fitness and sleep tracker, or a jogging app on their mobile device. If a patient is able to upload readings directly from a medical device, fitness tracker, or mobile phone, that will encourage use and add value by reducing the amount of data entry required.
Real-Time Access to Health Info:
If a patient has just finished an appointment but has forgotten the proper dosage for the new medication prescribed, that user will want to check the portal immediately upon returning home. If the data does not appear, the patient will have to call the office, they’ll have to look up the information or check the health records, and everyone can become frustrated. Note that according to the U.S. Department of Health and Human Services, up to 80% of patients forget what their doctor said as soon as they leave the clinic, and nearly 50% of what patients do remember is actually incorrect. Full access to important notes and details on their visit is important for effective care.
Provide Access to Communities and Forums:
Patients often seek out other patients with a similar ailment for advice and comfort. If possible, consider ways to link your patient software to popular communities and forums such as www.patientslikeme.com or, at a minimum, recommend appropriate responsible forums based on the patient data (and you can put this directly in their notification alerts or in their health info taking the information on its full loop).
Allow Mobile Access:
A user who has just checked his blood pressure at a drugstore may want to immediately input that data instead of waiting until he gets home to his desktop. Consult your patient personas and user research to determine whether a mobile version of your patient software would be of value and, if so, which components of the software would be most useful on a mobile device. Then make them as responsive and mobile-friendly as possible.
Address Their Fears & Concerns
Your user research may uncover specific patient concerns or reasons why patients have not used patient portals in the past. Some common concerns we’ve heard include:
“Who will be accessing my data and what information will they see?”
“Will I need to pay some sort of subscription fee?” • Technology: “I’m not good with computers—what happens if I make a mistake or need help?”
“I struggle to read on a computer.” Or “I’m not well enough to access the system regularly.” Or “I don’t have access to a computer.”
Patient / Doctor Relationship:
Some patients may be concerned that a portal will hinder communication with their physician. For example, if I spend time inputting information, will my doctor rely on this data rather than a face-to-face meeting or telephone conversation?
Make it First-Use Friendly
People are notoriously fickle, particularly as software experiences proliferate and options abound. An app takes more than a few minutes to understand these days and people move on, possibly to the next one or not. As a result, it is particularly important today to design the interface in a way that first-time users can access what they need quickly and easily. Patients, in particular, can be easily turned off by a bad first impression and may never return. To ensure that an interface is usable for both first-time and repeat visitors, consider engaging experts to perform interaction design and usability testing — particularly for the primary, high-frequency, or critical tasks. Usability experts can test an existing design and provide recommendations on how the UI can be improved.
Even if your solution addresses the needs of its key patient groups and actively engages them, it can still fail if clinicians ignore it.
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.”
While our advice is that patient software should always be designed with the patient as the primary user, patient software needs to provide enough value to clinicians to outweigh its perceived risks.
Set Patient Expectations Up-Front
Clinicians are very concerned about the expectations of patients entering health data into a patient software system. If a patient enters information daily, will that patient expect his doctor to be checking it daily and to have read all of the information before the patient’s next appointment?
When inviting a patient to register to a portal, set expectations. For example, if the software allows patients to leave a message in the portal for a provider, work with the client to make the rules of engagement clear. If a patient enters a very high blood pressure reading that the doctor does not see until days or weeks later, will the patient blame the doctor if he suffers a blood pressure-related problem before his next visit?
The care team should set expectations up front when first speaking with the patient about the portal, and 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. For example, “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”.
Address Privacy & Security
Privacy and security concerns will often create a barrier. Healthcare providers in the United States are bound to comply with the Health Insurance Portability and Accountability act (HIPAA) regulations, and in Canada, they are bound by the Personal Information Protection and Electronic Documents Act (PIPEDA). For these reasons, security has always been a top concern for the industry 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 that will be raised by providers.
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 judge 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.
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 www.mydoctor.ca Health Portal 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.
Considering Additional Stakeholders
Patients and clinicians are unquestionably the primary users of patient portals and other patient health systems, but they are not the only stakeholders. To develop a truly effective and usable solution, you must be aware of the “hidden” actors that may also use — or be influenced by — patient software.
In a healthcare setting, a number of user groups will be affected by the implementation of patient-facing software. These stakeholders often have conflicting needs, so you will need to understand their goals — and what they need to have in order to accomplish them — to mitigate conflict and satisfy the key users.
In a typical healthcare environment, you will encounter the following groups who will either use or be affected by patient software:
Reception or Front Desk Workers:
Workers at the “front desk” play an administrative role and are especially concerned with scheduling and billing. You will need to ensure that those areas of the patient software address their particular concerns and, ultimately, enhance their daily workflow. For a front desk worker, concerns could include proper scheduling, collecting accurate and up-to-date insurance information and ensuring that it is valid, and identifying the reason for an appointment.
Nurses are being given more and more responsibilities, including triage and working closely with patients that have chronic conditions. They may be entering patient data into the system, face numerous distractions, and are not tolerant of a complicated system with a lot of data entry.
Patients with acute or chronic ailments may also need to see a number of different specialists and educators. These clinicians may also wish to have access to the patient portal in order to see and understand the patient’s treatment and medication history.
Some patients may wish to use patient software but be unable to for health or technological reasons. In many cases, a caregiver (be it a professional caregiver or family member) may be the individual accessing and updating the patient record. Unlike a nurse, the care giver’s level of medical knowledge could range from low to high. The portal, therefore, needs to use simple language that can be easily understood by those unfamiliar with medical terminology.
Patient software facilitates collaboration between the care team and the patient. As with patients and clinicians, you will need to identify the particular goals of these stakeholders through formal user research techniques and determine the degree to which the patient software should accommodate them. As the table on the following page illustrates, each stakeholder group will benefit differently from patient software. By ensuring that you’ve captured the user requirements for all stakeholders (or have, at a minimum, understood them), you will be in a better position to assess their interdependent relationships and processes. This knowledge is key to de-risking the important design decisions you will need to make when developing or updating your patient software.
Download the Guide to Developing Engaging Digital Health Software
This 90+ page guide focuses on the intersection of your user, technology choices, and the regulatory environment you face that will play a critical role in the success of your application.
Applications of Voice Assistants in Healthcare
Discover how organizations across the continuum of care can leverage the growing consumer demand for voice-enabled devices to achieve an extensive list of objectives from increased patient engagement to improved outcomes and lowered care costs.Read More
Structuring Multidisciplinary Software Teams
5 strategies we've learned from working with the biggest names in software for structuring multidisciplinary software teams to get amazing software out the door fast.Read More
How to Design and Develop the Right Healthcare Software Solution
This guide shares our knowledge and insights from years of designing and developing software for the healthcare space. Focusing on your user, choosing the right technology, and the regulatory environment you face will play a critical role in the success of your application.Read More