What is the difference between developing applications for physicians and patients and designing, for example, electronic banking solutions?
There is an essential distinction between a medical app project and any other technology project. It's called the Medical Device Regulation (MDR) – the European Union's regulation on software development for medical purposes.
The MDR introduces the term Software as a Medical Device (SaMD) and refers to computer applications intended for medical purposes, such as monitoring, diagnosis, and treatment – medical software developers in Europe are bound by the same rules as medical device manufacturers. They define the requirements and standards for a medical product's design, construction, and marketing, imposing an appropriate manufacturing process, such as considering risk analysis, maintaining proper documentation, and ensuring a quality process compliant with standards like ISO13485. For some solutions, a clinical trial will be required if they aspire to become digital therapeutics. The process can take several months to complete.
The critical point is the role of the user in the design process, primarily patients and doctors. Including them in the application's design and testing process is vital. Conducting tests of software developed with users helps verify at an early stage whether the final product will be valuable and easy to use. It also enables us to make changes, which are much cheaper at the design stage than at the development stage.
What are the most critical stages of the development of medtech solutions?
Developers of medical applications should start by determining the "intended use" of the software. The term includes the medical purpose, the target user group, and any specific clinical conditions indicated by the manufacturer, defining who the software is designed for, e.g., "for people over 18" or "for people with type 2 diabetes," etc.
Specifying the use of the product is extremely important because of another requirement of the MDR regulation – the designation of the application's risk class. There is a fundamental difference between Class I, II, and III medical applications. The higher the class, the greater the risk to the patient and the more time-consuming the design, documentation, implementation, quality maintenance, and risk analysis process. This will affect the time and budget of the product. Examples of Class II applications are diagnostic software for mammography and Class III software for insulin pump control.
Class I software could be, for example, an application for managing migraine by keeping a pain diary to mark episodes, pain levels, potential triggers, and medications taken. Class I software does not require third-party certification and is easier to market. For software above Class I, external certification by an appropriate notified body will be required to verify compliance with standards (e.g., IEC62304 and IEC62366), which significantly lengthens the process of bringing the product to market. Still, it is necessary to obtain the CE mark.
Knowing the purpose of the application, we can move on to its design, a process often led by User Experience (UX) specialists. The work proceeds from the general to the specific, and the final result is usually a mockup of the application containing the information architecture and its most important functionalities. A crucial part here is user research.
At this stage, the first views of the future application may already be created. Sometimes, a so-called clickable prototype of the product is also produced, which provides the operation and appearance of the application. It is possible to determine the time needed to create the first version of a working application that includes basic functionality, often called an MVP (Minimum Viable Product).
How have the principles of so-called user experience (UX) and user interface (UI) in healthcare changed recently?
The principles of UX and UI are universal regardless of the industry. We certainly see one positive change: the industry, often thanks to healthcare startups, is opening up to the patient and is starting to pay more attention to UX and UI areas.
There is also increased awareness related to accessibility: There are around 1.3 billion people with disabilities worldwide. Accessibility doesn't just apply to people with disabilities, as everyone experiences temporary limitations. It could be a broken arm and, because of that, a hindered use of a computer or phone, but it could also be harsh light on the beach that makes it difficult to read something from a screen. Limited accessibility can occur when we are in a place where we don't have access to high-bandwidth internet.
For all these problems, accessibility techniques help. They ensure that the right colors are selected to be readable even in harsh light and the size of texts and clickable elements so that the visually impaired or mobility impaired don't have problems using applications. So that the final product can be navigated easily and users don't get annoyed when they can't find some information they need.
And what are the current trends in building digital health solutions?
The word that is being used in all cases these days is interoperability. It refers to the ability of IT systems, applications, and devices created by different entities to cooperate, exchange data, and integrate to effectively share and process medical information.
I'm glad there is more and more talk about unifying operations and using standards such as HL7 FHIR (one of the most widely used standards for exchanging medical data), for example, or DICOM. This should make integrating with other IT systems easier for application developers.
I also see positive signals from the medical community about using the cloud and the slow move away from desktop applications installed only on local servers.
Can data security be communicated to users through proper solution design?
I would say it must be communicated. Users' trust in medical applications and their manufacturers is one of the main factors influencing their market success.
Here, we can include transparency among valuable practices through easily accessible privacy policies and the publication of documents describing data processes. CE marking and information that the application is medical software can significantly affect user confidence in the product. Implementing strong passwords, masking of typed data, and using multi-factor authentication are all solutions that increase system security and, as a result, trust.
Can you briefly describe what makes applications patient-unfriendly?
First, an illegible interface that makes navigation and use of functions difficult. Second, the use of unintelligible language can limit patients' ability to use the app. Finally, inaccurate information or lack of clarity in messages can mislead patients, making it difficult for them to use the application effectively.
And the opposite: what five features should an app have to make end-users like it?
First and foremost, it should be practical, genuinely helping patients solve their specific health problems. Technical stability is another critical aspect, ensuring smooth operation on any device and eliminating frustrating stutters or hangs. The app should also feature a clear interface devoid of unnecessary features, making it easy to use even for those unfamiliar with today's technology. Communication in a language familiar to the patient, not necessarily the official one, is an integral part of customization. Ultimately, to gain patient favor, the app should be free of ads and sponsored content, allowing users to focus on using it without distractions or interruptions.
