A Guide to User-Centered Healthcare Software Design and Development

Additional Development Considerations

Over the years we’ve gathered a list of issues we’ve had to spend some time thinking about during (or after) development. We’ve picked a few things you might want to think about when you’re planning your application and given tips and things to consider for your application.

Two Views on Offline Data Storage

Don’t Support Offline

Consider not supporting offline data storage as it inherently makes an app less secure. Since data security is extra important when it comes to information about people’s health, offline data storage increases the effort required to secure and synchronize the data for the following reasons:

  • It requires a native component
  • It introduces various synchronization challenges that could lead to bugs that disrupt the data.

Obviously, there is a usability trade-off to requiring a persistent connection. However, there are workarounds to ensure it is as user-friendly as possible without a constant “you are disconnected” message. While performance could be slightly improved with a local cache, there is little impact on usability without offline storage.

Do Support Offline

Providing offline support for an application is a lot of work. This is particularly true in the case of healthcare applications where protected health information (PHI) is involved. For this reason, many people approach the problem by deferring the offline support to a future release. “We want to get to market quickly, and the application will still be useful without these few features until version 2.”

The problem with taking this approach is three-fold:

  • First, the effort to retrofit offline support into an application that hasn’t been designed to support offline data from onset is huge, often impacting technology choices and requiring significant application re-writes.
  • Second, it leads to the prioritization of features based on what can be provided online vs offline, rather than features that provide the most benefit to end-users.
  • Third, it encourages “cutting corners” to keep features in an online-only model, so the experience never really meets users expectations.

The solution is to invest up front in the added effort to support offline mode in order to have the luxury of being able to choose the right technology, the best features, and using offline features when and where they make sense to deliver the best possible user experience.

Time–Saving Decisions

Healthcare practitioners work in a very time-compressed environment. If a new software solution takes too long to use, users tend to either stop using the software or develop task shortcuts to reduce wait times. This behavior not only highlights, but also exacerbates design flaws. Healthcare software needs to be responsive in terms of informing end users about what the application is doing. In a system with long-running tasks or data transfers, make sure to ask the following questions:

Are blocking operations as short as possible?

Short blocking times will ensure users are not kept waiting.

Are progress indicators provided and are they accurate?

If users do need to wait, progress indicators will allow them to know how long it will be until they can regain control.

Are network data transfers atomic and able to recover from failure?

When large amounts of data have to be transferred, they should either happen in their entirety or not happen at all. When dealing with a patient case or a hospital visit, a non-atomic transfer could leave partial data in a remote database. If there is a network error or the receiving application stops the transmission, it should be possible to resume the transfer without duplicating or overwriting data.

Are users aware of impacting operations that run in the background?

When an application features jobs that run in the background, the normal speed of the program can be delayed. Users should be made aware that such jobs are running so they do not attribute a lag in the application’s performance to an unknown or unresolved problem.

Are there any alternate designs to speed up operations?

Sometimes a design may work but not be the most optimal configuration available. In many cases, a simple “rethink” in how things are done can improve operations significantly. Caching interface components, for example, can offer performance gains by eliminating the need to access databases or other networked resources. By thinking about each of these questions, your team will be able to properly address delays or dependencies in the application and provide users with clear indications of wait times and when tasks can be performed.

Secure Mail and Calendar Functions

Secure Mail

In the case of secure e-mail, the majority of users are knowledgeable about how an e-mail application works. In this instance, any deviation from the established design paradigms will trigger usability issues and user dissatisfaction. Software developers are no different, they have an intimate understanding of how an email application works so that when they design one and estimate the effort involved, they think only about the most overt steps and not the corner cases nor the details in between. Take for example the “save a draft” functionality where moving messages from one folder to another is routine, but moving a message from the draft folder to inbox doesn’t make sense. This is an example of a special case.

Scheduling / Calendar

In contrast to secure mail applications, a scheduling / calendar feature provides a great opportunity to innovate on the user- interface (UI). Expect UI discussions and iterations to deal with creative ideas on how to offer better, usable functionality. Based on our experience, custom UI controls tend to be complex, and we have yet to see a calendar feature take less time than planned in any application.

TIP: Scheduling? Other Things to Consider.

Patient portals are on of the places you might want to consider scheduling as an option. Read more on a clinician’s possible concerns with scheduling in our section on patient portals and their special considerations.

Flexible Databases

Given that clinical workplace processes are in a constant state of flux, there is an ongoing requirement for collecting new patient data for regulatory or new treatment reasons. When architecting, developing, and deploying software, these constraints need to be taken in to account. With the right data model that allows for continual updates as requirements are refined and features are added, these challenges can be eased.

When creating a data model that stores patient risk factor data, for example, there is a requirement to create a table to store these values. If additional risk factors are added, the table would be extended, or new tables would need to be created to accommodate them. Consider a requirement to store the following risk factors: current smoker (true/false), date of bypass surgery (date), and the number of family members with diabetes (number). The resulting structure would be as follows:

If a fourth risk factor is added, you would need to create an additional column in the table, and so forth. This approach, however, requires that all programmed models be updated to reflect the newly updated table. This can require significant re-work, and often the changes end up being undone at a later stage. Risk factors and any other set of data fields that need to be modified frequently require a more adaptable data model. An alternative to the above-mentioned data model would be to create a set of tables to hold a more generic structure of key / value pairs. Such a structure would look like the model shown below. This data model stores data as:

Basic Data Model

Healthcare Basic Data Model

  • QuestionField – The question text.
  • AnswerType – The type of answer expected.
  • QuestionAnswer – A mapping from the patient record to the actual answer values.


Generic Data Model

Generic Data Model

With this model, it is possible to add fields to an interface of risk factors without having to modify the database schema. With the right data model in place, you will be better positioned to refine the software and handle new requirements as they arise.

Input Validation Best Practices

A rigorous input validation process based on a user’s context is critical to a successful application. Consider these scenarios:

Scenario 1:

An input field for blood pressure readings is set for integer-only with both a systolic and diastolic component. In practice, however, it is sometimes difficult for a physician to measure the diastolic blood pressure component. In those cases, the physician or practitioner would normally want to enter non-numerical values, such as ‘125/?’ or even ‘125/P’ which stands for 125 over pulse.

Scenario 2:

A standard patient information form has pre- set, required fields for patient identifiers, such as first name, last name, gender, phone number, address line 1, city, state, and zip code. The software requires that all pre-set fields must be filled out before proceeding to the next step. But in our example, a patient arrives at a hospital emergency department alone and unable to speak. How would the patient’s data be entered into the system if the pre-set fields cannot be circumvented? In practice, false data would be entered to skip past the road blocks put up by the system and then corrected once the true identity of the patient is known. While the work-around gets the job done, it is not elegant.

Scenario 3:

Another example could be where a patient declines a portion of a test, every field in that test used for data collection then should be made optional. And if the patient does not stay for a test, the technician or physician also must be able to record patient refusal. Given that these types of scenarios may exist; there is a high probability that there will be fields that will be left blank. Developers must ensure that the application can still function, provide a missing data error alert, or provide the ability to enter data once it is known.

User research focused on understanding the user’s experience prior to development and incorporating the user’s context into the overall design helps avoid these types of scenarios. But even user research doesn’t catch everything. In that case, software validation during the development cycle allows users to report on any problems they have seen and gives users confidence that the application will fit into their workflow and do everything it is needed to do.

Validation must include testing of all exceptional cases to ensure that the application is well integrated into the environment— even the most unusual circumstances. A solid process will catch problems before too much development work has been completed. Consider using an agile process, it enables the application to be tested and deployed at various milestones of the development cycle and allows for more opportunities to perform software validation early in the project lifecycle.

To summarize, effective input validation in a healthcare environment should follow these input validation best practices:

  • Input validation should not block users from submitting a form.
  • Keep the number of required fields to a minimum. A field should only be set to required if its absence makes the form in its entirety irrelevant.
  • Provide defaults or other mechanisms when data cannot be provided, rather than requiring the data to be entered.
  • Users should be able to skip questions and complete them later.
  • Any dependence between questions should be functional, so there’s no way for one to be answered without the other being answered first.
  • Data quality checks should account for incomplete or ‘fake’ placeholder data and advise users to complete the data entry once the values are known.
  • Downstream data consumers must continue to function and raise alerts in case they are fed incomplete data.

By understanding the range of possible validation errors and the risks associated with them, your team can ensure medical care is never delayed because of a software requirement.

Questions on Integration

Very few healthcare applications operate in a vacuum. They need information, and typically communicate with various third-party systems to get it. Some questions that need to be addressed early on in development include:

  • Which back-end systems must be supported?
  • How do the respective functionalities vary?
  • Is the app catering to the lowest common denominator or is it customizable based on back-end functionality?

Sometimes those systems might not even exist and you are building them yourself. Regardless of whether you are integrating or building, you need to spend time getting alignment on:

  • What system needs to be accessed and how.
  • What information is going to be updated.
  • Who is most impacted by these integrations?

There may be new workflows for other users of the system to respond to. You might need to provide a data transformation layer to convert what is being delivered from the server into a format that can be consumed by the application.

This creates questions like:

  • Who is building these pieces?
  • Where do they live?
  • Who supports them?
  • How do they get updated?

Answering these questions involves a collaborative discussion between your team and the third-party or server teams. Engaging people in these types of discussions take time, especially when the teams you are collaborating with aren’t focused on your project and have other priorities; so be patient, persistent, and clear about what is needed and when. Despite these collaborative discussions, you will still find that schedules often don’t line up, so be prepared to work independently until everyone is ready for integration and be flexible enough to adapt during integration when the integration points are not quite in the format you originally expected.

Be patient, persistent, and clear about what is needed

Server-Side Development Takes Longer Than you Think

By far, server-side under-estimation in addition to lack of coordination with front-end development can cause the most delays and re-work. Consider planning the next server-side development tasks more than one sprint in advance of what you will do on the UI side. For example, could the server team be two sprints ahead? Be sure to tackle integration issues early and determine what your strategy is for dealing with specifics (i.e., a scheduling service). For stakeholder demos, it is far more effective to show interaction with real data (e.g., UI hooked to API, API hooked to server). This makes the timing of server-side development even more important. Having server-side functionality ready prior to the corresponding UI tasks also saves a lot of re-work. While you could stub out the back-end, invariably the server will behave differently than you expected in your stub.

PDF Download Button

Download The Complete Guide to Engaging Digital Health Software

Get the PDF