Healthcare is a new hot topic in software development, which means that user experience designers are getting more requests for designing and conducting research for medical applications. Working on something that will help patients manage a chronic disease, administer the correct dose of medication, or communicate more effectively with their healthcare provider can be very rewarding. However, there are many unique issues to be aware of before starting the design and development of a medical application or device.

The design of a medical product may fall under various regulations that can impact the design, implementation, and record keeping decisions related to the product. Not being aware and informed about these laws and regulations before starting design may delay getting your product to market. It may also result in spending additional time and money retrofitting the product. Worse, regulatory bodies may prevent you from launching the product. These regulations generally fall into two categories: one details the handling and protection of personal information about patients; the other ensures that patients, caregivers, and medical staff are not harmed when using a medical device.

In the United States, patient privacy is protected by the Health Insurance Portability and Accountability Act (HIPAA). The European Union’s equivalent is the Data Protection Directive. Some European countries have additional requirements. For example, France requires that personal data be stored on servers physically located in France. In the U.S., patient safety is regulated by the Food and Drug Administration (FDA), which regulates everything from blood glucose meters to allergy medications. The European Union, Japan, and most other countries have similar regulatory agencies and laws, although the degree to which they impact product design varies by regulatory body. (See the sidebar for more details about these laws.)

Impact of Privacy Laws

Much of the impact of privacy is on the development side. For example, selecting hosting servers where the data is encrypted. This prevents administrative staff and other unauthorized users from viewing patient records. However, there is often a UX impact as well. These laws require limiting access to information only to users who actually need it. This might require creating user accounts and levels of access, usually role-based, to limit access to different users. For example, the billing department may need to know what services were provided for a given patient, but don’t need to know the diagnosis. These design issues need to be taken into account in the initial designs, and throughout the product development lifecycle.

Example: access to patient data

A recent client didn’t want the added expense of building and maintaining individual user logins. They knew their product was going to be used in medical offices where administrative staff is usually responsible for entering patient data but the doctor is required to provide the final sign-off. The client wanted to have the administrators sign in using the doctor’s login. The problem with this approach is that U.S. privacy laws require that detailed records be kept of who has accessed and changed patient records. While the client acknowledged that some offices may choose to have multiple users use the same login to access the accounts, privacy regulations preclude designing this as the default behavior. An option that would allow each user to have their own account with a separate login and password has to be provided.

Protecting Patient Safety

When it comes to protecting patient safety, the rules and regulations of the FDA, EU, and other regulatory bodies often overlap, but are not identical. In general, all safety regulations aim to prevent patient harm due to misuse of a product. A lot of the requirements for implementation revolve around patient risk. Will a particular feature cause harm? If so, what design changes are required to mitigate the risk?

Many of the regulatory requirements around designing and building a safe, risk-free product follow user experience best practices. Identifying every target audience is required, similar to UX personas. Also, it is important to identify each task a user might perform. Here the emphasis is on identifying risk, not usability problems, but a detailed analysis could identify both at the same time. User and design evaluation is also a major component of the regulations. In fact, to obtain FDA approval you must provide results of at least one round of user testing, usually called human factors testing (although it is highly recommended to do more). The difference again is an emphasis on risk. But a good, usable design will, in most cases, also reduce the likelihood for user error and thus risk.

Example: recommended dosing application

Another client recently had an application which provided a dosing recommendation to patients. It then required the patient to enter how much of the medication they had actually taken. The default value indicating the actual dose taken was initially set to zero. During the evaluation process, it was discovered that the zero was confusing patients. The confusion arose because the zero conflicted with the actual recommendation displayed elsewhere on the screen, making it appear that the application was providing two values, the actual recommendation and a recommendation of zero (or do nothing). It also caused some patients to incorrectly enter the dose they had actually taken, impacting future calculations. The default display was changed to blank. This reduced the risk of potential harm to patients by eliminating the confusion between the recommended dose and entering the actual dose they had taken. This made it clear that no value had been entered by the patient, and ensured that future recommendations would be calculated correctly.

In the same application, users have the option to link their mobile app to an online web account. This is a complicated process and does not follow a standard method. Many users were unable to complete this task. While the feature may be annoying and difficult to use, it is not harmful. Linking with the website is not required to use the application properly. Since it does not pose a medical risk to patients, regulatory bodies are not likely to be concerned by it. However, if this were to impact the effectiveness of the application, then it may be found to be important.

Conclusion

There are many considerations to take into account when designing medical products, some of which are not relevant when designing other types of applications. One important area is the impact of the environment under which the application will be used. This can include extreme noise and light; for example, an operating room or hospital patient rooms. A lot of medical equipment has alarms. How do you make sure your product doesn’t add to the noise, resulting in alarms that end up being ignored? How do you differentiate between minor problems and critical issues? If the product is for personal use by a patient, can it be used discreetly to avoid embarrassment to the patient and thus increase compliance? Differences in reimbursement models between healthcare systems can also impact the adoption of the product. A product covered by health insurance in one country may not be covered elsewhere. How patients are taught to treat their illness may also have an impact. Is there a global standard for care? Even within the same country, there can be regional variations in care and variations between large cities and small towns.

There are many more areas to consider when designing an application for healthcare. By addressing the issues above and keeping privacy concerns, patient safety, and risk in mind, you will be on your way to designing a successful medical application.

Topics: Standards & guidelines, Healthcare
Published in: September, 2014 in Healthy Designs

Comments are closed.