Electronic health records: Acceptance provides the allure
Both treatment providers and patients will only accept an electronic health record (EHR) if it is clearly organized, simple, and easy to use, claims Professor Peter Haas, a medical information scientist at the Dortmund University of Applied Sciences and Arts (Fachhochschule Dortmund), in an expert report on the EHR commissioned by us. In this guest blog post, Professor Haas pointedly describes why acceptance is a crucial success factor for the introduction of an IT solution – in this specific case, the electronic health record, and how it can be achieved.
Acceptance is not the use of solutions without alternatives
Acceptance (from the Latin “accipere,” meaning endorse, take on, approve)
I fainted again today. After minutes spent clicking through Windows folder trees, I lost my way in the depths of the folder hierarchies searching for a file, took leave of my senses, and fell from my chair.* Now I’ve come to myself again, and am seriously contemplating whether I’m a masochist for still using these folder trees every day. But do I have an alternative? After all, everyone does it. It’s something that’s just accepted – it gained acceptance. Really? Acceptance? Is there really no file management solution that is suitable for the human brain? But now we’re conditioned this way, and consider it the gold standard: Folders in folders in folders. And there are even electronic health records that function this way, and only this way. Hopefully my physician won’t lose it from over-clicking when looking for my various diagnoses in the depths of his hospital system, even though he only needs four pieces of information in total.
(*Searching using the search term didn’t work, because I didn’t know the right word that would find me the correct file.)
So, on the one hand: There’s software that gains superficial acceptance, has no alternative, and that we nevertheless de facto just have to use “as it is.” We adopt it, although we don’t approve of it. Such as, for example, the medication plan or emergency medical data stored on the German electronic health card (elektronische Gesundheitskarte, eGK) – if we want one or the other, we always have to run around taking the card with us (oh – my life could depend on it in an emergency!). And to read the data you need a card reader at home. Developers in far-flung Prussia even have ideas of being able to attached said reading device to a mobile phone, allowing users mobile access to their own data. However, the two-key principle also dictates that the physician somehow also has to be able to stick their card in at the same time – maybe via remote VPN. As there is no alternative, it will probably even find a certain degree of acceptance, and will be at least used – which can be interpreted as acceptance. However: Mass usage of solutions without alternatives is not the same as genuine acceptance!
And this remains the case with a number of business applications that people need to use. Scores of (unnecessary) clicks and mouse miles and getting lost in branching folder hierarchies and sub-interfaces are the new instruments of torture. Bad software, at work for example, is like an uncomfortable office chair or a perpetually bad-tempered colleague – if this is the case, you just have to endure it on a daily basis. In your private life, you can simply delete bad software from your phone or PC. By the way, here’s a business model in the e-health app area to take advantage of the current situation: Create a good-sounding health app and sell a million in the App Store for one euro as quickly as possible. Go back to the start and do it again. And again. Now that’s a success story.
Finally, let’s take a look at hospital software for physicians: The developer tries to imagine what the physicians are probably thinking when they are thinking, and what they need when they are thinking, and then develops something that doesn’t correspond to the mental world of physicians, but rather to the developer’s imagination of it. Based upon the dictates of the hospital administration, physicians have to use this “imagination software” on a daily basis. As a shown in survey by Dr. Anke Simon published in 2017(!): “34 percent of physicians are not satisfied with the user-friendliness of their clinical workplace systems, and almost half find the ease-of-use of their IT systems, when not unsatisfactory, then only “adequate.” “Good enough,” as Dueck called it (Dueck, G., (2014). Die stille Good-Enough-Revolution (The silent “good enough” revolution). Informatik Spektrum Volume 37, No. 4, p. 348 – 351), but only just good enough. With respect to the end user, digitalization in the healthcare sector is actually still in its infancy.
But on the other hand: Genuine acceptance that comes from the heart arises from joy. Joy in being able to use something great, that is useful, and is nice and easy to use. To a certain extent, both of these criteria can compensate for each other: If it’s really useful, then I’ll use software that doesn’t have a perfect user interface. And: The triumph of email and WhatsApp are examples of this: High usage! Or, looking at the healthcare sector, the steep usage curve of OpenNotes, with over 20 million users in the United States already. The dry ISO term, which in principle unites the factors of usefulness and ease-of-use, is “suitability for the task.” Or, as my former colleague, Professor Pretschner, often said “Software has to be sexy.” True – but it also has to provide functional benefits. Many people spend more time with certain software than with their partners or other people. It would be great if we could say: “Software, I accept you with all my heart, and want to share my life with you, because you help me and are good to me.” Can you say that about any software that you use on a daily basis? Yes? Well, that must be nice for you.
To obtain acceptance from the heart, the developer has to know:
- what is useful to the user, and
- what “high ease-of-use” means for the use.
Software development with user involvement pays off in the long-term
Work in the early 90s, consolidated in the 2000s, already referred here to the “perceived usefulness” and the “perceived ease-of-use” (see, for example, the Technology Acceptance Model). This shows something that is also obvious – usefulness and ease-of-use are also, to a certain extent, subjective. Nevertheless, both can be specified within a definable spectrum for certain work/life situations. Applied to e-health: Indications and medical condition determine the functional requirements and the potential uses, for example, of applications for patients, while general and individual aspects determine the ease-of-use. Users’ experience with IT applications should be given less weight as a determinant. Here, one can think back to approaches from the 80s: Software had a number of different modes – from a beginner mode, to an expert mode, allowing anyone to use it.
Why is it then, that, time and again, one sees solutions presented at trade fairs, where one invariably gets cold shivers – or one meets people that say “Ah, our new software … trying to work with the new e-record wasted half my workday.” This is because usefulness and ease-of-use for the actual user are still not sufficiently the focus of development. Maybe the focus is the usefulness for the company implementing the software to optimize processes. But this falls short – ease-of-use is also an economic factor: If physicians in hospitals lose an hour a day through cumbersome system usage, crashes, and so on (as was estimated by participants in a workshop), then it also has to be an issue for hospital management. You only need to convert what this value means in terms of full-time equivalents. This, however, is not done – in other industries either – because this overhead is considered a problem of the employee, who has to deal either way with the work that still needs to be done.
So, it comes as no surprise that solutions that the users have helped work on are often particularly well accepted and widely distributed (I’m thinking of, for example, of an approach to diabetes that was co-developed with a diabetes support group, or a palliative record that was initially developed by palliative care physicians and members of other professional groups involved with palliative care).
As such, in the field of e-health, it is more important than ever to appropriately integrate the participation of downstream users in the development process – preferably in at least three feedback loops. This is difficult and costs money and time (possibly even “time to market”) – which is also the crux of the matter: Software development involving users, which was presented and discussed in many specialist articles at the start of the 90s, is expensive – perhaps twice as expensive as developing just from the imagination. In addition, it is not enough to include just one user: A representative group needs to be used, such as a focus group. And then legitimate qualitative methods of social research also need to be applied.
Downstream end users need to be included in development processes at an early stage
How do the many companies in the food industry manage this? Products are often tested there by consumer panels made up of a group of consumers gifted with sharp senses. Depending on the approach (or if there was a prior descriptive panel), the product is modified after each round of testing based on the results of the sensory tests, and then tested again until a result is reached that, on average, tastes good to the target-group-specific average consumer. Incidentally, the consumers on the panel are generally firmly booked and also receive a small payment for their time and cooperation. Have you experienced anything like this in the software industry?
As such, a necessary precondition of the widespread accepted application of health telematics solutions is the inclusion of downstream end users from as early as the specification of the framework conditions and boundaries of solutions, down to the concrete solutions themselves – the final results of development cannot be left to the imagination alone. Here, it is legitimate to ask about how many patients and practicing physicians from practices and hospitals, how many nursing staff and so on, gematik has repeatedly spoken to about, and reflected on, their planning over the last twelve years.
In future, target-group oriented focus groups (in the context of the healthcare sector, general and indication-specific focus groups) should be regarded as the natural partners of development teams by start-ups, established software companies, gematik, and other software producers in the healthcare sector, and these focus groups should also be established in an appropriate manner. They not only provide important information regarding the potential usefulness and ease-of-use aspects – they can also help uncover potential not yet seen by developers.
It is also necessary to increase research efforts in order to arrive at patient-appropriate IT solutions for certain indication-specific target and age groups, especially when one considers the many new modes of interaction, including speech and gesture recognition, sensor integration, as well as virtual and augmented reality. In order to achieve this, it would also be worthwhile launching the corresponding research programs.
There are of course further aspects to acceptance (including status symbols, prior experience, and so on), but these don’t play as great a role as usefulness and ease-of-use. Furthermore, their discussion is beyond the scope of this individual blog post.
In closing, two aspects should be highlighted:
- Acceptance is the key factor also, and above all, in e-health solutions. Acceptance provides the allure in the eyes of the user, but is also interesting for the pockets of developers and suppliers. The much-vaunted digitalization of the healthcare sector, although still in its infancy in Germany, is inescapably linked with the acceptance of healthcare professionals and patients. This requires that solutions aren’t just useful, nor that they only look good and are easy to use; both of these aspects need to be combined to the greatest degree possible to ensure that something can become a sure-fire success, and thereby also a comprehensive part of modern healthcare. And this, in turn, requires not only “user-centric” applications that a developer thinks up for a particular user or user group, but also user-involving development models in the relevant companies, in gematik, and wherever software is developed for people. Prior to starting development of e-health solutions, the checklist for developers could look like:
“For any questions regarding usefulness and ease-of-use, please consult your doctor, pharmacist, and impacted patients.”
Note: On this topic, see also Chapter 8 on the expert report on electronic health records (in German). Theses for the EHR there include:
- Key message 69: Both treatment providers and patients will only accept EHR systems if they are clearly organized, simple, and easy to use.
- Key message 70: User interfaces of EHR systems have to address the special features of medicine. This concerns both the conceptual model of the domain as a starting point for an interaction design, as well as the task-specific information requirements and actions of the various user Groups.
- Key message 71: Representatives of medical practitioners, nursing staff, and patients of various indication and age groups have to be involved in the design of the user interfaces of EHR systems. This will also help ensure that specific information requirements are covered.
- Key message 72: The task-appropriate and effective synchronization of information between institutional electronic medical record systems and electronic health record systems is a critical success factor for the acceptable and widespread usage of EHR Systems.
- In Chapter 9, user participation in the form of focus groups and thematic boards is given prominent consideration within the framework of the developed governance structures.
Click here to subscribe to our newsletter: