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