A Guide to User-Centered Healthcare Software Design and Development

Developing Patient Portals

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, but 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 the 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.

TIP: Finding Your Patient Groups

Not sure where to start? Go back and review Who is Your End User? All the research techniques are relevant for patient-facing applications and then walk the path to understanding your customer.

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 the 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.


PDF Download Button

Download The Complete Guide to Engaging Digital Health Software

Get the PDF