{"id":2150,"title":"Electronic health records: Acceptance provides the allure","link":"https:\/\/www.programm-gesundheit.blog\/en\/electronic-health-records-acceptance\/","date":"28. November 2017","content":"

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<\/a> 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 \u2013 in this specific case, the electronic health record, and how it can be achieved.<\/em><\/p>\n

Acceptance is not the use of solutions without alternatives<\/h4>\n

Acceptance<\/strong> (from the Latin \u201caccipere,\u201d meaning endorse, take on, approve)<\/p>\n

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\u2019ve come to myself again, and am seriously contemplating whether I\u2019m a masochist for still using these folder trees every day. But do I have an alternative? After all, everyone does it. It\u2019s something that\u2019s just accepted \u2013 it gained acceptance. Really? Acceptance? Is there really no file management solution that is suitable for the human brain? But now we\u2019re 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\u2019t 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.<\/p>\n

(*Searching using the search term didn\u2019t work, because I didn\u2019t know the right word that would find me the correct file.)<\/em><\/p>\n

So, on the one hand:<\/strong> There\u2019s software that gains superficial acceptance, has no alternative, and that we nevertheless de facto just have to use \u201cas it is.\u201d We adopt it, although we don\u2019t approve of it. \u00a0Such as, for example, the medication plan or emergency medical data stored on the German electronic health card (elektronische Gesundheitskarte,\u00a0eGK) \u2013 if we want one or the other, we always have to run around taking the card with us (oh \u2013 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 \u2013 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 \u2013 which can be interpreted as acceptance. However: Mass usage of solutions without alternatives is not the same as genuine acceptance!<\/p>\n

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 \u2013 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\u2019s 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\u2019s a success story.<\/p>\n

Finally, let\u2019s 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\u2019t correspond to the mental world of physicians, but rather to the developer\u2019s imagination of it. Based upon the dictates of the hospital administration, physicians have to use this \u201cimagination software\u201d on a daily basis. As a shown in survey by Dr. Anke Simon published in 2017(!): \u201c34 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 \u201cadequate.\u201d \u201cGood enough,\u201d as Dueck called it (Dueck, G., (2014). Die stille Good-Enough-Revolution (The silent \u201cgood enough\u201d revolution). Informatik Spektrum Volume 37, No. 4, p. 348 \u2013 351), but only just good enough. With respect to the end user, digitalization in the healthcare sector is actually still in its infancy.<\/p>\n

But on the other hand:<\/strong> Genuine<\/em> 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\u2019s really useful, then I\u2019ll use software that doesn\u2019t 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<\/a>, 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 \u201csuitability for the task.\u201d Or, as my former colleague, Professor Pretschner, often said \u201cSoftware has to be sexy.\u201d True \u2013 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: \u201cSoftware, I accept you with all my heart, and want to share my life with you, because you help me and are good to me.\u201d Can you say that about any software that you use on a daily basis? Yes? Well, that must be nice for you.<\/p>\n

To obtain acceptance from the heart, the developer has to know:<\/p>\n

    \n
  1. what is useful to the user,\u00a0and<\/li>\n
  2. what “high\u00a0ease-of-use”\u00a0means for the use.<\/li>\n<\/ol>\n

    Software development with user involvement pays off in the long-term<\/h4>\n

    Work in the early 90s, consolidated in the 2000s, already referred here to the \u201cperceived usefulness\u201d and the \u201cperceived ease-of-use\u201d (see, for example, the Technology Acceptance Model<\/a>). This shows something that is also obvious \u2013 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\u2019 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 \u2013 from a beginner mode, to an expert mode, allowing anyone to use it.<\/p>\n

    Why is it then, that, time and again, one sees solutions presented at trade fairs, where one invariably gets cold shivers \u2013 or one meets people that say \u201cAh, our new software \u2026 trying to work with the new e-record wasted half my workday.\u201d 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 \u2013 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 \u2013 in other industries either \u2013 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.<\/p>\n

    So, it comes as no surprise that solutions that the users have helped work on are often particularly well accepted and widely distributed (I\u2019m 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).<\/p>\n

    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 \u2013 preferably in at least three feedback loops. This is difficult and costs money and time (possibly even \u201ctime to market\u201d) \u2013 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 \u2013 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.<\/p>\n

    Downstream end users need to be included in development processes at an early stage<\/h4>\n

    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?<\/p>\n

    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 \u2013 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.<\/p>\n

    In future, target-group oriented focus groups <\/a>(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 \u2013 they can also help uncover potential not yet seen by developers.<\/p>\n

    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.<\/p>\n

    There are of course further aspects to acceptance (including status symbols, prior experience, and so on), but these don\u2019t play as great a role as usefulness and ease-of-use. Furthermore, their discussion is beyond the scope of this individual blog post.<\/p>\n

    In closing, two aspects should be highlighted:<\/p>\n

      \n
    1. Computer scientists design more than just technology \u2013 they design socio-technological systems in which people are a key component. In doing so, however, they also transform the reality of peoples\u2019 lives \u2013 sometimes to a significant degree. As early as 1992, Arno Rolf titled a book contribution \u201cSichtwechsel \u2013 Informatik als Gestaltungswissenschaft\u201d (\u201cA change of perspective \u2013 information technology as a design science\u201d). If we transform the reality of peoples\u2019 lives, we should do this to ensure a better new situation for those involved, both in terms of usefulness and ease-of-use, and particularly in the field of e-health. This is a responsibility for computer scientists and all developers of informational artifacts for people, and even more so in the development of solutions for patients.<\/li>\n
    2. 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\u2019t 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 \u201cuser-centric\u201d 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:<\/li>\n<\/ol>\n

      \u201cFor any questions regarding usefulness and ease-of-use, please consult your doctor, pharmacist, and impacted patients.\u201d<\/p>\n

       <\/p>\n

      \n

      Note: On this topic, see also Chapter 8 on the expert report on electronic health records <\/a>(in German). Theses for the EHR there include:<\/p>\n