Digital health is expected to change healthcare as we know it. Many prototypes and sophisticated communication infrastructures that connect patients and clinicians have been developed and successfully demonstrated.
Unfortunately, research prototypes in digital health rarely become part of regular use in hospitals or by patients. The promises dreamed up and discussed in workshops, and sometimes demonstrated in small pilots, often fall short when clinicians and patients try to incorporate them into their real work practices or everyday lives. Invention in digital health may be fast, but diffusion of innovation is rather slow.
The main reason for the slow uptake is that design rarely continues after implementation. Too little time and effort is spent on configuring the systems and adapting the clinical practices and the day-to-day activities of patients (not) using the new systems. In many projects, designing with users is something that happens before the new system is implemented—active user involvement in co-design workshops and prototyping sessions is considered good enough.
However, when engaging users only at design time, we miss the opportunity for responding to the inevitable (and often uncomfortable) learnings that can only occur at use time, when new technologies are put to use as part of actual healthcare practices. The learnings that arise from implementation and iterative adaptation to clinicians' and patients' responses have received little attention in research on design methods for digital health. In this article, I will discuss and showcase a solution for this issue.
For 10 years, I have been co-leading an interinstitutional research and development program for connected and preventive care for heart patients with an implanted cardiac device (such as a pacemaker, ICD, or loop recorder). It began in 2008 with professor Finn Kensing (one of the founding fathers of participatory design (PD) ) and a few clinicians from the Rigshospital in Copenhagen, Denmark, who got funding for a PD project called CITH, aiming at improving patient engagement in remote follow-ups of cardiac device patients. I was a Ph.D. student doing ethnographic field studies, co-design, prototyping, testing, and iterative configuration of different features in a Web application for patient-clinician interaction called myRecord . We developed a prototype that proved valuable for both patients and clinicians and for an overall approach to co-designing at use time. As only a few connected-care applications were available at the time, my Ph.D. colleague and close partner Jonas Moll and I brought the prototype and the published results to Medtronic. Two years later we got funding for a large four-year follow-up R&D project called SCAUT, where the Rigshospital, two Danish investors, and the Department of Computer Science at the University of Copenhagen engaged in a public-private consortium.
An outcome of the project is a preventive- and connected-care software system called the SCAUT platform. It is currently running at the Rigshospital and continuous R&D of the platform is made possible by a spinout company called Vital Beats, where I am head of research. The platform supports asynchronous communication and coordination through a patient mobile app and a Web app for clinicians. Cardiac device patients can answer questionnaires, get personalized feedback from the clinic, share their medication list, and notify the clinic when traveling.
Another outcome of the project is a large-scale, long-term living laboratory (living lab) where end users, engineers, designers, researchers and relevant stakeholders collaborate around designing, developing, and getting new digital health tools to work in real life.
It is a living lab because clinicians and patients use SCAUT as part of the treatment while trying out new functionality. At the same time, we can observe how they use (or not use) it, get their feedback, and react to that feedback by redesigning, reprograming, and rolling out updated software.
Patients and clinicians operate in different worlds with different needs. They have divergent concerns.
It is large scale because more than 350 cardiac device patients have been recruited as participants. They have given consent for a five-year period, to use their data and to be involved as informants in interviews and as co-designers when new features become available. This means that we can learn and react to how well or how poorly the new features perform at small scale with few users and, quickly after, at a larger scale.
It is long term because patients can participate as long as they use the platform, which means that we learn how functionality works over time and can engage users continuously in redesign.
One of the major challenges we have encountered when designing new digital forms of interaction in this context is the gap between the lived world of patients and the professional practices of clinicians. We have spent a great deal of time and resources on aligning the concerns of these two different groups of end users. It has been very hard to enable remote collaboration between clinicians and patients. As we show in a recent article, patients and clinicians operate in different worlds with different needs . They have divergent concerns.
Patients experience illness directly in their own body. A disease appears as something immediate that manifests itself, for example, as pain and uncomfortable feelings. It requires attention and engagement in self-care, which can make it difficult to live a normal life. We found that the disease experience for heart patients means several things: to cope with unexplained symptoms; being uninformed; feeling uncertain and anxious; dealing with identity change; and managing expectations and new responsibilities .
Clinicians, in contrast, experience health-related illnesses from the outside and through the presence of known signs, seeing the patient's disease through a medical framework. They have limited time for decision making and can take action only on what is known with the tools that are available. For example, at the Rigshospital, clinicians still rely on telephone calls as a common way of interacting with patients .
When developing digital support for remote patient-clinician collaboration, we need to ensure that the features simultaneously support the needs of both patients and clinicians. Connected-care functionality has to align the divergent concerns and enable meaningful, actionable, and feasible interaction. Otherwise, the prototype won't be used.
The need for communication, coordination, and negotiation between the different actors in a living lab is extensive.
To give an example, we developed a symptom diary in the SCAUT mobile app where patients could track symptoms such as abnormal heartbeat (arrhythmia) and share it with clinicians. In early field studies, we found that patients asked questions about their symptoms in consultations, and clinicians called patients over the telephone to understand what patients experienced when arrhythmic episodes were present in the transmitted cardiac device data. We co-designed, developed, and deployed a prototype of the symptom diary where patients could audio-record their symptoms and share it with the clinic. It seemed like the perfect idea in workshops. However, when we deployed it as part of remote follow-ups, we learned that it was more complicated than anticipated. Some patients were unsure when to track symptoms: "If I should note down and share symptoms every time I felt something, then I could do nothing but that ... because is it a symptom or is it just my imagination?" And clinicians got overwhelmed by the patient-generated information, finding it too time-consuming to listen through, diagnose, and create a course of action: "That's why we are not so damn interested in these symptom recordings coming in like this."
To get the symptom diary to work, we had to redesign and adapt it to align both the patients' and clinicians' concerns. It needed to be meaningful, actionable, and feasible; for example, by enabling patients to track symptoms only when necessary and by allowing clinicians to visualize the symptoms using well-known bar charts instead of audio . The diary also had to allow clinicians to take action quickly, for example by using standard replies. Patients currently have to turn the tracking feature on in the symptom diary; clinicians can quickly attend to the few patients who need feedback and, in turn, use it for interpreting arrhythmic episodes. All features in the SCAUT app have gone through a similar adaptation process of design after implementation.
|Components of the SCAUT Living Lab.|
While bridging the gap between clinicians and patients is certainly a challenge for designing connected care, the gap between users and designers is a second major challenge.
Ever since the early days of HCI and CSCW research, ethnography has been the umbrella term for undertaking qualitative research for understanding users and their context. Ethnographic studies provide valuable insight about the routines and contingencies of users' activities and are perceived as a fruitful way of informing design and bridging the gap between users and designers. In PD, researchers have gone other ways to form a bridge between users and designers. Rooted in a political ambition for democratic design, a long range of co-design methods, techniques, and tools have been developed and presented in conferences to support mutual learning and participation when designing new systems. The workshop format has been the main setting, where users and designers get together to sketch and sometimes play, act out, or rehearse the future. PD usually focuses on ideation and the early phases of development, seldomly moving beyond the construction of prototypes on to actual implementation .
As mentioned above, we combine participatory design and ethnography in the living lab by carrying out design interventions and design-in-use. For example, we are currently experimenting with automating the interaction between patients and nurses, aiming to tackle the increasing number of patients (350 users) and the increased patient-generated information to which nurses must attend. We visit the clinic weekly to observe the task of patients replying to questionnaires. We also discuss ways to improve and redesign the reply feature. This is a design intervention and an example of design after implementation, that is, design-in-use.
In the design interventions, we catalog the learnings and the types of interaction that seem unnecessary, for instance if a patient describes in the questionnaire that "everything is fine" and "I have no questions." The first redesign was the development of automated replies. Around 35 percent of 1,000 yearly patient-clinician interactions have been automated. We then carry out design interventions in patients' homes or over the telephone to learn about their use experience, for instance, when a patient has received an automated reply. Clinicians and most patients are much more satisfied. This means that the questionnaire feature fits better with the needs of both patients and clinicians.
Transitioning digital health prototypes into large-scale use is related to a third major challenge that is often underestimated. As I have hinted, there is another decisive gap between early design and diffusion of innovation, which passes through a difficult and sometimes prolonged time of adaptation.
Despite the many benefits of the living-lab approach for both research and end users, it is important to emphasize that the method is associated with significant organizational and practical challenges. It is resource intensive to establish a living lab and to operate the day-to-day design and test environment. When many parties are brought together, interests must be organized and continuously negotiated and upheld. The need for communication, coordination, and negotiation between the different actors in a living lab is extensive. It requires resources and focus on ensuring progress on design processes, and there are a number of necessary activities that require diverse competencies.
Some of the challenges that can arise in a living lab involve: lack of trust and transparency, poor education of users, and bugs in technology.
|A design in use situation where an ICD patient is telling about his experience using the app and discussing ways to improve it.|
Transparency and trust are two very important factors for patients and clinicians to commit themselves to as partners and active participants in the overall innovation process. Confidence drops, for example, if participants do not receive feedback on their contributions or if they feel that they are just informants and are not heard. We have learned that personal contact, preferably with the same person, and social events help with confidence building. Transparency can be created through personal messages or relevant newsletters, which update the participants about what is going on in the project. A strategy for ongoing contact and early feedback is important to have in place, and we have built features into the SCAUT platform to support this work.
Bugs in the protype deployed can also create distrust; at worst, participants discard the technology and become non-users. It is therefore important to make clear that minor errors may occur, but also to assess whether the prototype is robust or mature enough to be deployed. To have a process for informing and educating users on new or redesigned features is critical. Patients and clinicians also need easy access to the design team, ideally built in as features in the prototype such as a message module.
When engaging with change management and designing at use time, we increase the chances for positive adoption. If we as HCI, CSCW, and PD researchers want to see our designs become innovations that diffuse into practice, we must engage in more demanding real-world interventions. Instead of studying the "as is" and the "what could be," the large-scale and long-term living lab increases full-circle learning and makes it possible to study and experiment with the becoming of the future.
2. Andersen, T.O., Bjørn, P., Kensing, F., and Moll, J. Designing for collaborative interpretation in telemonitoring: Re-introducing patients as diagnostic agents. International Journal of Medical Informatics 80, 8 2011, e112–e126.
3. Andersen, T.O., Bansler, J.P., Kensing, F., Moll, J., Mønsted, T., Nielsen, K.D., Nielsen, O.W., Petersen, H.H., and Svendsen, J.H. Aligning concerns in telecare: Three concepts to guide the design of patient-centred e-health. Proc. of Computer Supported Cooperative Work. ACM, New York, 2018.
4. Andersen, T.O., Andersen, P.R.D., Kornum, A.C., and Larsen, T.M. Understanding patient experience: A deployment study in cardiac remote monitoring. Proc. of the 11th EAI International Conference on Pervasive Computing Technologies for Healthcare. ACM, New York, 2017, 221–230.
5. Andersen, T.O., Nielsen, K.D., Moll, J., and Svendsen, J.H. Unpacking telemonitoring work: Workload and telephone calls to patients in implanted cardiac device care. International Journal of Medical Informatics 129, 2019, 381–387.
6. Hartswood, M.J., Procter, R.N., Rouchy, P., Rouncefield, M., Slack, R., and Voss, A. Working IT out in medical practice: IT systems design and development as co-realisation. Methods of Information in Medicine 42, 4, 2003, 392–7.
Tariq Osman Andersen is an assistant professor in the Department of Computer Science at the University of Copenhagen and head of research at Vital Beats. His research is concerned with patient-clinician interaction, large-scale co-design, and predictive analytics. He received his Ph.D. in computer science from the University of Copenhagen in 2012. firstname.lastname@example.org
Copyright held by author. Publication rights licensed to ACM.
The Digital Library is published by the Association for Computing Machinery. Copyright © 2019 ACM, Inc.