How to Create Engaging Patient Software. Lorraine Chapman, Anneliis Tosine and Patrick Pichette

Transcription

1 How to Create Engaging Patient Software Lorraine Chapman, Anneliis Tosine and Patrick Pichette

2 Increasingly, healthcare software vendors are developing electronic Personal Health Records (PHRs), Patient Portals, and mobile self-care 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 PHR 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. 1 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 legal implications of interacting with a patient portal While these are all valid criticisms, at Macadamian we believe that there is more to the story. Our work with both healthcare providers and Electronic Medical Record (EMR) / Electronic Health Record (EHR) software vendors has given us unique insight into the real-world obstacles encountered by both patients and clinicians using patient software. 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. In this paper, we provide our top recommendations for software executives and healthcare institutions looking to increase the adoption of patient-facing software and realize its full benefits

3 1 Most Design to Specific Patient Personas 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 EHRs, already exist and developers often borrow an area from the existing interface and simply expose it to patients via the web with little to no redesign. Unfortunately, for reasons that we will explain in this paper, patients do not normally engage well with interfaces designed for clinicians. patient Software In formal conversation, the terms Patient Portal and Personal Health Record are sometimes used interchangeably. At other times, a Patient Portal may refer specifically to a secure website through which a patient can access a PHR. In this paper, we will use patient software as a catch-all term to refer to both patient portals and PHRs. Even if the software was designed from the ground up for patients, the work is often done with a typical patient in mind. In reality, there is no such thing as a typical or average patient. 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 particular chronic condition. Moreover, patients with chronic conditions will have needs that are unique to their specific ailment. Instead of designing for a 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 the patient software in order for it to be valuable and actively used. Determine primary personas By using formal user research techniques, you can identify the most common user groups and usability goals, and prioritize your patient software s features accordingly. These user research techniques could include: User Interviews, Focus Groups and Surveys to uncover actual user goals and opinions. 4 5

4 Field Research that identifies (through observation) how users interact with physicians or existing patient software in the real world Usage Scenario Definitions that model a day in the life of particular patient types. Aim to identify the most prevalent personas and then determine the primary personas for your application. Solutions that cater to more than a handful of personas tend to be watered-down and fail to address the most important needs effectively. Many poorly-designed EMRs, for example, try to please 15 different physician specialties but end up not meeting any individual doctor s needs. As with EMRs, patient software needs to provide real value to a few specific, but prominent, groups. Focus on specific goals The ultimate goal of user research and the persona 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 the patient software. of these techniques is outside the scope of this paper, so we recommend that you consult our user research reference material or seek the advice of a User Experience (UX) professional with credentials in human-computer interaction design. As we noted earlier, many patient software systems fail because they don t target a specific group of users they are either remnants of clinicianfocused applications like Electronic Health Records, or were developed with a generic patient in mind. These unfocused solutions try to satisfy everyone (or satisfy non-existent typical users) and, as such, do not address any particular patient s needs and goals. It may sound simple, but the first step to creating truly engaging patient software is to determine who you are engaging, and satisfy that group of users exceptionally well. Goals & Needs Be sure to differentiate between goals and needs they are not synonymous but are inextricably linked. For example, a patient may need a data repository to meet his goal of managing his health between medical visits and making the most of doctor appointments. If a patient s goal is to lower her cholesterol level, she will need the software to track that level over time and indicate whether it has improved or declined. 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 2 : The ability to organize health records, including medication reconciliation (91 percent); The availability of online calendars and reminders (74 percent); Access to personalized health education (71 percent); Access to community services (69 percent); The ability to communicate online with providers and health plans (60 percent); The ability to manage health care costs (57 percent). 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. Evolve the design to match the personas Once you have identified both the primary personas for your patient software and their needs and goals, we recommend defining key usage scenarios that are illustrated through visual concepts called low fidelity prototypes. You can test these concepts with real-world patients in order to guide the development and evolution of the software. Explaining the details

5 stand the implications. She may wonder Should I call my doctor?, Is this a normal reading?, If not, what should I do?. 2 Drive Patient Engagement 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? While this information will vary from patient group to patient group, our researchers have compiled a list of the most important guiding principles for driving long-term patient engagement. 1. Present the information that the *patient* cares about 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 accessed by a clinician 3. In the study, patients indicated that they were most interested in booking appointments online, engaging in secure messaging with a provider s office and viewing lab tests. Your 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. 2. Provide *immediate* value to the patient during the interaction For illustrative purposes, let s explore how a patient with Type 2 Diabetes might use 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 identify trends, see correlations with her activity levels or what she ate for lunch, and under- Google Health: A Cautionary Tale Google introduced a PHR in 2008 that allowed Google users to volunteer their health records either manually or by logging into their account at partnered health services providers. In 2011, however, Google announced that it was discontinuing the service, stating that... with a few years of experience, we ve observed that Google Health is not having the broad impact that we hoped it would. 4 In our opinion, Google Health failed because it was designed for everyone. Its features were arguably very open and generic, and as a result did not add value to patients with specific needs. Google Health did not aggregate data from other sources. All health information needed to be manually entered by the user and there were no pre-populated forms to make that data entry easier for people with a specific condition. For most users, it was not tied in any way to their physician so it also required appointment and visit result data to be manually entered. In addition, the system did not integrate with many popular third-party health apps. All of these were missed opportunities to drive patient engagement.. Patients with a chronic illness may deal with a large number of providers and wish to keep track of all of their names, upcoming appointments and recent communications via the software. If your system can provide added value beyond simply housing information, you will be able to ensure patient satisfaction and uptake. Kaiser Permanente s My Health Manager is an example of a system whose features provide immediate value to target users. A table on Kaiser Permanente s website FAQ, meant to show the portal s growing user base, turns out to be a wonderful illustration of features that are resonating with users such as online prescription refill, appointment requests and access to health information resources: In 2009 alone, there were: Total visits to My Health Manager (secure features) 27,068,824 19,355,762 Members with access to secure features (My Health Manager) 3,000,000+ 2,716,341 Total online prescription refill orders 6,854,722 3,432,858 Total online appointment requests 1,852,178 1,403,870 Total s sent to doctors & other care team members 8,641,703 6,068,843 Total lab-test results viewed online via My Health Manager 21,693,301 16,773,273 Total healthy lifestyle program questionnaires submitted 185, ,495 Total visits to the health encyclopaedia 4,416,585 3,975, Ensure that patients can *relate* to the information 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. When designing your interface, implement tools (such as color coding or a dashboard, perhaps) that will help patients interpret and understand the metrics they find in their online file. It s not good enough to simply reflect data back to the patient the patient needs to know what that data means and its implications. Below is an excellent example of a blood test result design (conducted by Wired Magazine 5 ) 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

6 5. Give patients other 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: An automatic trigger. If a patient has an upcoming appointment with a specialist, the system could send that user a message via or to a mobile device. Or, if the system knows that the patient has Diabetes, it could send reminders to enter a glucose reading. Links to existing patient apps, programs and systems. Many patients already use some sort of monitoring device be it a step counter, a glucose monitor or a jogging app on their mobile device. If a patient is able to upload readings directly from a medical device 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 can become frustrated. Note that according to the U.S. Department of Health and Human Services 6, up to 80% of patients forget what their doctor said as soon as they leave the clinic, and nearly 50% of what patients remember is incorrect. 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 or, at a minimum, recommend appropriate forums based on the patient data. 4. Include *next steps* and 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 his progress over time and the ways in which he is contributing to his own healthcare via exercise of 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. 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. 6. Address specific user fears/concerns Your user research activities may uncover specific patient concerns or reasons for which patients have not used patient software in the past. Some common concerns include: Privacy/Security: Who will be accessing my data and what information will they see?

7 Payment: 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? Accessibility: 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? 7. Make the software first-use-friendly It is particularly important 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 not 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. Our white paper, 9 Usability Mistakes Your Team is Probably Making (and How to Fix Them) offers insight in to the most common usability errors in the Healthcare industry. Even if your solution addresses the needs of its key patient groups and actively engages them, it can still fail if it is ignored by clinicians. Our next recommendation examines the ways in which you need to encourage patient software buy-in from clinicians. 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. 7 Today s clinicians, however, are often reluctant to adopt patient portals, worrying that patient 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, patient software 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 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, 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. 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? Pharmacists and Health Information Technology: Emerging Issues in Patient Safety. HEC Forum, manuscript in press,

8 The care team should set expectations up front when first speaking with the patient about the portal, and as described above, 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 8, and in Canada by the Personal Information Protection and Electronic Documents Act (PIPEDA) 9. 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. 4 Identify Additional Stakeholders & Consider Their Needs 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 Health Portal 10 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 recommendation relates to all of the other stakeholders that can interact with a patient software solution 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. Understand the stakeholder value chain In a healthcare setting, a number of user groups will be affected by the implementation of patient 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 goals and, ultimately, enhance their daily workflow. For a front desk worker, these goals could include proper scheduling, collecting insurance information and ensuring that it is valid, and identifying the reason for an appointment. Nurses: 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 and are normally very rushed so they will not tolerate a lot of data entry. Other Clinicians: Patients with acute or chronic ailments may also need to see a number of different specialists and educators. These clinicians may

9 also wish to have access to the patient software in order to see and understand the patient s treatment and medication history. Care Givers: Some patients may wish to use patient software but be unable to for health or technological reasons. In many cases, a care giver (be it a professional care giver 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. An effective patient software should glue the care team together around the patient. Key Potential Benefits of PHRs and PHR Systems Role Consumers, Patients, and Their Caregivers Benefits Support wellness activities Improve understanding of health issues Increase sense of control over health Increase control over access to personal health information Support timely, appropriate preventive services Support healthcare decisions and responsibility for care Strengthen communication with providers Verify accuracy of information in provider records Support home monitoring for chronic diseases Support understanding and appropriate use of medications Support continuity of care across time and providers Manage insurance benefits and claims Avoid duplicate tests Reduce adverse drug interactions and allergic reactions Reduce hassle through online appointment scheduling and prescription refills Increase access to providers via e-visits Healthcare Providers Payers Employers Improve access data from other providers and the patients themselves Improve knowledge of potential drug interactions and allergies Avoid duplicate tests Avoid medication compliance Provide information to patients for both healthcare and patients services purposes Provide patients with convenient access to specific information or services (e.g. lab results, Rx refills, e-visits) Improve documentation of communication with patients Improve customer service (transactions and information) Promote portability of patient information across plan Support wellness and preventive care Provide information and education to beneficiaries Support wellness and preventive care Provide convenient service Improve workforce productivity Promote empowered healthcare consumers Use aggregate data manage employee health 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. Societal, Population Health Benefits Strengthen health promotion and disease prevention Improve the health of populations Expand health education opportunities Source: National Committee on Vital and Health Statistics. Personal Health Records and Personal Health Record Systems. February Available online at hhs.gov/0602nhiirpt.pdf

10 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. Developing Engaging Patient Software Designing successful, usable patient software requires a deep understanding of its key users patients and their desired experience. Through formal user research and the development of patient personas, healthcare software vendors and healthcare institutions can identify the key goals of the most important patient groups, and architect the design to satisfy their particular needs. While clinicians have a set of concerns that must be addressed, patients have a completely different set of expectations and requirements and should be the focus of the patient software development process. By designing to patient goals without stepping over the concerns of clinicians and other stakeholders, you can keep users engaged, which is first step to a successful solution. While patient software adoption rates have been low to date, the ideas behind patient software are gradually becoming more and more accepted. Successful sites such as and Kaiser Permanente s My Health Manager demonstrate that momentum is building and patients are keen to adopt systems that directly address their particular needs. Software vendors and health institutions need to decide whether they want to be on the leading edge of the patient software movement or sit on the sidelines to wait and see what happens. For those on the leading edge, the techniques and suggestions listed in this white paper will help you deliver what patients really want, and what clinicians will actually use. About Macadamian Macadamian is a global leader in software product creation providing a complete range of product strategy, user experience design and software engineering services to clients around the world, including healthcare industry leaders like Cardinal Health, Elsevier and Telus Health. For established and emerging technologies and platforms, Macadamian has a track record of helping clients create successful products on iphone, ipad, Android, Web 2.0 & RIA, Windows and Mac OS X. Macadamian s medical software development team understands the unique requirements of the healthcare industry, its standards and its regulatory requirements. Our experts are well versed in FDA, HIPAA, ARRA and CCHIT requirements and the environments in which healthcare devices are used. We also know that usable, well designed software can differentiate you from your competition and drive the adoption of your medical software product. Over the past twelve years, our engineering, usability, and visual design teams have worked with clinicians, doctors, nurses, and domain experts to develop a range of healthcare products that integrate with their workflow and addresses specific clinical needs. At Macadamian, we follow proven processes to provide the skilled, speedy and high-quality development you need to deliver on your commitments. Our healthcare experts can help you tackle your clinical software development project and ensure your product will be embraced by users when it hits the market. Additional information can be found at Contact Us For questions or comments about this whitepaper, or for more information about our healthcare software design, and development services, please contact: Didier Thizy, Director, Healthcare Solutions 165 Rue Wellington Gatineau, QC, Canada J8X 2J3 didier@macadamian.com x