1 Introduction
Traditionally, patients’ health information has been stored in medical records maintained by healthcare institutions, such as hospitals and general practitioners’ offices (GP offices). These records are compiled and controlled by healthcare professionals. Often, patients could ask for copies of the records and keep a personal file in paper-based folders in their homes to track medical encounters, test results and prescriptions along with their own notes. In some cases, these folders would also be used during patients’ medical visits—for instance, when visiting a healthcare provider for the first time. Such paper-based personal health records kept by patients can deteriorate over the years: the ink can fade, while normal use of the copies may result in torn or stained documents. Also, paper files can take up a significant amount of space and it can be difficult to carry the accumulated documents when they are needed. Furthermore, tracing information in the folders can be slow and making annotations can be problematic.
In response to the limitations of the traditional way health information has been collected and organized by patients, tools that allow them to better manage their own health information have been introduced in the form of digital personal health records (PHRs). Key features of a PHR are that it is under the control of the patient and that information contained is at least partly entered by the patient (International Organization for Standardization 2005). There are different types of PHRs (Archer et al. 2011; Davidson et al. 2015). In some cases, they are tethered to medical record systems. In that configuration, part of the PHR information is provided and maintained by healthcare providers. PHRs can also be self-contained or untethered. In that case, they are fully controlled by patients, who enter and maintain their own health data. The portable health records on USB sticks that patients can bring to medical consultations allowing clinicans to access the content through their computer (Maloney and Wright 2010), is an example of simple self-contained PHRs. Some PHRs are intended for patient use only, whereas others are designed to support information handling beyond patients’ discretionary use. These may, for instance, include functionality for exchanging information between patients and healthcare providers or patients and insurers (Davidson et al. 2015). PHRs can also include extensive functionality to support health monitoring over time, setting reminders and recording prescribed and non-prescribed medicines or treatments (Chinta and Raghavan 2015). PHRs are considered to have the potential to stimulate transformational changes in healthcare delivery by empowering patients to play a more active role in self-care and assisting their self-management of health issues (Detmer et al. 2008; Pagliari et al. 2007). Thus, they are seen as a vehicle to shift the capabilities and responsibilities of both patients and providers and create new dynamics between those groups (Ventres et al. 2006).
Anzeige
The creation of PHRs is a complex and multifaceted sociotechnical problem, not least because PHRs function as a way to connect multiple parties and social actors (Simborg 2009). From the patients’ perspective, the use of PHRs addresses the need to collect and organize personal health information, and to share information with selected health providers when needed. From the health providers’ perspective, PHRs are seen as valuable tools to address shortcomings in information sharing across health providers, for instance, providing a workaround solution for accessing information that is distributed in medical records kept in multiple health institutions. PHRs can be conceptualized as hybrid information spaces that are both private (serving sensitive personal health information management needs) and communal (facilitating information sharing between patients and healthcare professionals). This hybrid character points to the multiple roles of a PHR, which we analyze as a design challenge. Different needs have to be reconciled before taking decisions regarding what types of information will be included and how this information should be shared. Furthermore, decisions have to be taken on who should be able to add, update or delete information and on the organization and presentation of the information. These are core issues that need to be resolved during the design of any actual PHR system, and the design resolutions will strongly influence the character of the PHR developed. In this paper, we seek to investigate these issues based on the following research question: “What are the design tensions related to PHR’s hybrid nature and how does resolving these tensions shape the design of PHRs?”
We answer this question through the analysis of two empirical cases. The use of two cases gives us the opportunity to analyze two different design processes making comparisons and associations that allow the identification of salient design tensions. The two cases studied are MyBook, which is a secure web-based application for storing personal health data, initiated by a private entrepreneur and developed in collaboration with a leading Norwegian University; and MyHealth, which is the PHR component of the Norwegian government’s national eHealth platform. In our analysis, we focus particularly on how members of the design teams in the two cases articulated the different tensions related to the hybrid nature of the systems under design and how they found tradeoffs between fitting the systems for private use and configuring them as common spaces. We organized the tensions identified in the analysis along three key themes: control allocation, content origination, and user environment localization. These three key themes identified in the analysis of tensions all point to decisions related to regionalization (Clement and Wagner 1995). Regionalizing or contouring areas within an overall collaborative space, can help actors to get focused and to protect their views. The concept of regionalization is relevant to design decisions about information spaces that are hybrids (partly communal and partly private) such as the PHRs under study.
The rest of the paper is structured as follows. In the next section, we present our conceptual grounding, drawing from prior research on PHRs and on the design of common information spaces. This is followed by the presentation of the two empirical cases and the description of our research method. We then present the findings of our analysis. Finally, we present the discussion and conclusions based on our findings.
2 Conceptual grounding
In this section, we present prior research that is relevant for making sense of PHRs as design objects. The hybrid nature of PHRs (i.e., the need to serve as information spaces that are simultaneously private and common) brings attention to the role of the design choices that shape their qualities.
Anzeige
2.1 The PHR concept
The electronic patient records maintained by healthcare institutions evolved from doctors’ handwritten notes to become connected and standardized information artefacts that support the cooperation and coordination of different health professionals, across disciplines and institutional boundaries. Berg’s seminal research on the role of electronic patient records (EPRs) in clinical work identified two roles of health records: to accumulate and to coordinate (Berg 1999). An EPR accumulates information and coordinates the work of medical professionals. This coordinating function is central in understanding the shared nature of records in medical work and the related use of information. Researchers in Computer Supported Collaborative Work (CSCW) have examined the coordinating role of specific parts of patient records. For instance, Bansler and colleagues describe how clinical notes sequentially written by doctors are a coordinative artefact that facilitates collaborative work in treating patients (Bansler et al. 2016). Winthereik and Vikkelsø examined the use of discharge letters as bridging devices that support continuity of care and coordination across health providers (Winthereik and Vikkelsø 2005). Østerlund studied the relation between electronic documents, places and collaborative activities in a hospital context. He argues that documents and the way they are used reveal insights about the organizing of social relations in connection to specific place and time (Østerlund 2008).
Similar to electronic medical records of different types, PHRs can work across roles and boundaries—between patients and health professionals and between the home and the clinic—and need to address different concerns. Despite being seemingly simple, the concept of PHRs is fundamentally complex (Huba and Zhang 2012). The design of PHR systems entails answering questions concerning ownership of, access to, and regulation of health information. Addressing these questions requires reflection on the envisioned type of patient-doctor relations, and on the premises for their collaboration. Prior research on PHRs’ use and user practices has identified a number of tensions. For instance, patients and health providers may have diverging views on personal health information (Piras and Zanutto 2010) and on the distribution of duties among the patient and the provider (Nazi 2013; Turvey et al. 2014). Tang and colleagues argue that from a healthcare provider’s perspective, not all patient-supplied data can inform providers’ decision making; this information could be “clinically irrelevant” or become overwhelming for a healthcare provider to review (Tang et al. 2006). More generally, they also argue that health providers may consider PHRs to be a threat to their control, autonomy and authority, based on traditional patient-provider roles (Tang et al. 2006). Archer and collegues report that many PHR systems are physician-oriented in practice and they argue for the inclusion of patient-oriented functionalities if improvements in health outcomes are to be expected (Archer et al. 2011). Piras and Zanutto, show how PHRs’ formalization of information practices may oversimplify the complex array of patients’ practices in maintaining personal health information (Piras and Zanutto 2010). Overall, PHRs need to cater for personal health information management work including “invisible” work, such as collecting, organizing and maintaining information as well as researching using the internet and remembering questions to ask. Patient work involves also demanding information, resolving inconsistencies and maintaining continuity of care across institutions (Unruh and Pratt 2008).
The research insights on user practices have significant implications for the design of PHRs. Greenhalgh and colleagues discuss the importance of taking into account patient self-management practices, information needs and preferred styles of communication in the design of PHRs (Greenhalgh et al. 2010). If these are not considered in the design phase, the PHR will poorly align with patients’ needs and will have limited use or even, no-use. Similarly, Piras and Zanutto showed that the design of PHRs “requires specific attention to be paid to the different forms assumed by self-care practices in domestic spaces, and to the various activities with which they intersect” (Piras and Zanutto 2010). Cabitza and colleagues argue that conceptualizing PHRs as tools for seamless flow of information downplays their potential to be more collaboration and communication oriented (Cabitza et al. 2015). They suggest framing PHRs as hubs or meeting places to stress the social and collaborative aspects of patient care. Similarly, Lahtiranta and colleagues define “health space” which is the collaborative information space for patients and health providers (Lahtiranta et al. 2015). They argue that the cooperation in the health space should be seen from the patient perspective and therefore should not be limited to healthcare-related encounters. However, they recognize the existence of social and cultural barriers to this approach and argue that “without a more equal and balanced approach, it is probable that new forms of co-operation that regard patients as resource will not come into fruition” (idem, p. 802). Taking the patient’s perspective, Unruh and Pratt identify a set of functional requirements for an information space designed explicitly for patients’ cooperation with clinicians. They identify and describe a wide variety of tasks in the cooperation between patients and clinicians, for instance, patients can cooperate with clinicians to highlight dependencies, resolve inconsistent recommendations, couple clinical options with procedural task information, and track progress of clinical and logistical tasks (Unruh and Pratt 2008). They point to the key role of explicit representations which are constructed by patients or clinicians to support their cooperation and the iterative refinement of these representations. Conceptualizing PHRs as common information spaces (CIS), stresses the cooperative dimension of the patient-doctor relation. In the next section, we consider the literature on CIS.
2.2 The design of common information spaces
The CIS concept has been developed in the field of CSCW to indicate spaces that support distributed cooperative work as an alternative to procedural or workflow-type arrangements. The focus for CIS is on how people in a distributed setting can work cooperatively by sharing an information space with some level of agreement as to the meaning of information (Bannon and Bødker 1997; Schmidt and Bannon 1992). A CIS is actively constructed by its participants: objects must be interpreted and assigned meaning, and meanings are created by specific actors on specific occasions of use (Schmidt and Bannon 1992 p. 20). The challenge is to maintain and preserve some shared interpretation across divides of space, time and culture (Bossen 2002). The primary role of a CIS in a work setting is to support work coordination, providing awareness (Bardram et al. 2005) and connecting multiple groups across heterogeneous contexts (Munkvold and Ellingsen 2007; Rolland et al. 2006). For instance, a CIS can be constituted in relation to a complex web of artefacts as in the case of healthcare work in hospital departments (Bardram and Bossen 2005; Bjørn and Hertzum 2011). Nevertheless, a CIS is not simplistically about just making one digital information space available to all groups (Hepsø 2009) or providing access to everything everywhere (Bertelsen and Bødker 2001).
In a seminal paper, Bannon and Bødker (1997) analyze different CISs and provide insights related to information openness and closure. For instance, they show how in some CISs the interpretation of information relies on the disclosure of additional contextual data such as the identity of the originator of information, while in other CISs anonymity is required. By identifying the dialectics between openness and closure as a fundamental aspect of CISs, Bannon and Bødker (1997) stress the importance of coordinating interpretations in CISs and propose that this should be seen as a new kind of articulation work. This articulation work addresses problems arising from bringing together different webs of significance which makes it difficult to achieve shared understandings. Bossen argues for the need to understand better the different degrees and combinations of openness and closure in CISs (Bossen 2002). He proposes a framework of seven parameters to characterize a particular CIS: the degree of distribution, the multiplicity of webs of significance, the level of required articulation work, the multiplicity and intensity of means of communication, the web of artefacts, the immaterial mechanisms of interaction, and the need for precision and promptness of interpretation.
In this study we propose to understand PHRs as information spaces of a hybrid character. A PHR can be more than a private tool, serving as a CIS that straddles work and non-work contexts, bringing together participants - patients and professionals - in a collaborative relation. Understanding PHRs requires accounting for how they can be designed to accomplish a dual role as personal and common information spaces. To this purpose, we found particularly interesting the insights from Clement and Wagner’s analysis of complex organizational collective communication spaces (Clement and Wagner 1995). Examining four different types of settings, Clement and Wagner show that collective communication spaces need not be homogeneous, or complete, or equally accessible to all actors. They can consist of regionalized communication spaces with carefully defined and restricted communication. Clement and Wagner examine communication spaces in relation to situations of ‘disarticulation’ “as a phenomenon which highlights the fact that the regionalization of communication spaces may help actors to get focused and/or to protect their view” (Clement and Wagner 1995 p.36). Regionalization implies that parts of the space have restricted access, without resulting necessarily to a deterioration or disruption of the supported collaborative work. The concept of regionalization is relevant for the design of information spaces that support personalization and privacy while facilitating sharing such as the PHRs under study.
The CSCW field is explicitly design oriented. Still, design processes have rarely been studied in their own right. When this has happened, they have most often been seen as instances of collaborative work, and the emphasis has been on the requirement for coordinative practices and tools in these design processes. There are, however, also studies that pay explicit attention to the social structuring of design processes. For instance, Bowers and Pycock argue based on an examination of social interaction in design work, that “requirements are a negotiated product of argument and resistance” (Bowers and Pycock 1994). Seeing users and developers as belonging to different language games, they illustrate how new ideas require legitimation to be able to counter “the gradient of resistance.” Similarly, researchers with a relation to the participatory design approach address more explicitly the role of power differentials in design processes (Kyng 1991). This literature mainly conceptualizes controversies in design projects as an effect of the diversity of participants’ backgrounds, and typically the problems of handling the different knowledge brought to the process by designers and users are discussed. There is less emphasis on controversies that are inherent in the design project itself, as in the case of PHRs where design solutions have to accommodate the hybrid character of the novel digital artifacts developed. With this paper we shift focus on this topic.
3 Empirical study of early stages of PHR design and development
We have studied the initial stages of the design and development of two different PHRs in Norway. Our study explores how the tensions inherent in the PHR concept are addressed through resolutions during the design process. We followed the design team deliberations that led to particular choices shaping each PHR’s character. Specifically, we studied the national initiative for the introduction of a PHR component within the Norwegian government’s eHealth platform called MyHealth. This aims to become a key element of the Norwegian eHealth ecosystem, providing secure and trusted means for storing personal health information and for exchanging information with healthcare providers. We also studied a joint project between a doctor/entrepreneur and our university for the design and development of a standalone PHR called MyBook. MyBook aims to support patients in filing and organizing personal health information and to provide a workaround solution to interoperability problems within the Norwegian health system by supporting information sharing between patients and healthcare providers. We investigated both cases in situ, following the design process in team meetings and workshops. Table 1 summarizes key aspects of the cases and includes a brief description, the targeted users and the institutional positioning. In the two subsections that follow the table, we provide an overview of the two cases.
Table 1
The two cases studied
Case | Description | Targeted users | Institutional positioning |
|---|---|---|---|
MyHealth | A platform component for accessing and storing personal health information and electronic exchanges between patients and healthcare providers, offering connections to several existing systems (e.g. EPRs, e-prescription, vaccination registries) and the possibility for other applications to connect and extend its core functionality. | All residents of Norway, part of the national health services. | National-level initiative by the government, implemented by a specialized agency. |
MyBook | Standalone application that supports filing and organization of personal health information and facilitating information sharing between patients and healthcare providers chosen by the patients. | Anyone interested in using a secure solution for filing and sharing health information, with chronic patients as primary target users. | Joint project between a doctor/entrepreneur and a university. |
3.1 MyHealth
The first case concerns the design and development of novel, patient-oriented, personalized services (MyHealth) as part of a national e-health platform that citizens can access over the internet (HealthNorway). A key aim for this initiative is to facilitate patients in assuming a more active role in their own healthcare and to provide a secure and trusted channel for electronic exchanges between patients and healthcare providers. The Norwegian government decided to embrace the platform idea for this initiative, aiming to “serve as a basis for new and innovative services from both the public and the private sectors” (Norwegian Ministry of Health and Care Services 2013). The development of MyHealth is aligned with the Norwegian National Strategy for Quality Improvement in Health and Social Services (2005–2015), which stipulates: “A well-informed, participative user has a greater possibility to achieve a good result in his or her interaction with health and social services. Reliable information shall be available and understandable for ordinary people” (Norwegian Directorate of Health 2005).
MyHealth is designed and developed by a specialized governmental agency that is authorized to implement national health policies and ensure secure and simple information flow in the health and care sector (henceforth referred to as the Agency). This Agency is also responsible for maintaining and expanding the overall platform. In 2013, only a few services were available under MyHealth (expense management, a functionality to change GP and prescription viewing). Soon after that, new functionality was added for accessing more personal information (e.g., summary care records), and a dedicated team undertook the task of designing and developing new electronic services to enable digital interactions between patients and healthcare providers. The team worked along the lines of a detailed “pre-study.” This pre-study identified the need to create a storage solution for patient data (a personal health archive) and the need to connect with the various EPRs for the exchange of information between patients and healthcare practitioners. During this pre-study, a panel of patients was set up and a number of patient personas (i.e. user archetypes) and scenarios were developed. Furthermore, the design team for the new services held a number of workshops with healthcare practitioners and visited practitioners in their work settings. The design team included members with backgrounds in technical development, user experience, law and regulations, economics and management.
This initiative was considered a high priority, and the team started work by exploring the perspectives of prospective users. Overall, the patients consulted were very positive about the idea of using electronic means for communicating with their healthcare providers. Around 50% of patients who participated in the user panel thought that it would be important to have a functionality for uploading documents and making them available to healthcare practitioners. On the other hand, although in general healthcare providers were positively dispositioned toward electronic services, they were not entirely comfortable with the introduction of these services, as evidenced in comments provided to a survey performed by the Agency. For example, a doctor was skeptical about the potential for patients to bypass secretaries and reach out to doctors directly: “I see that when there are requests for unnecessary consultations a secretary can prevent them by explaining over the phone.” A medical secretary was worried about the lack of completeness and comprehensibility of electronic messages: “patients write obscure messages making it difficult for us to understand how quickly they need an appointment or what medications they need to order.” Naturally for a project that would bring novel tools to the everyday life of patients and the everyday work of healthcare practitioners, there were divergent views and some reservations among the potential users.
The members of the design team also had to reconcile their own different views on the project approach. For example, a team member with a legal background expressed concern with how other team members approached the project: “it is more creative what they want to do, and sometimes they forget the need to be within the legal framework. You cannot just do whatever you want and make it work technically; it has to be within the legal framework, which is not easy to see.” Another team member with a background in user experience said that “the future is now, we need the laws to move faster. Of course, we know by looking at the political system that it takes time—that is why the whole concept needs to be so scalable that we are ready to embrace all new things happening.” The deliberations among team members with different backgrounds and roles led to the gradual concretization of the initially abstract electronic service ideas into a configured solution shaped by specific tradeoffs between being a private tool for the patients and a common space for patient-provider collaboration. The design process for the new interactive services was initiated in 2013; the development started in 2014; a pilot was launched in 2016; and the new services are currently (early 2017) about to transition from pilot to roll-out status.
3.2 MyBook
The second case concerns a joint project between a doctor/entrepreneur and our university for the design and development of a standalone PHR called MyBook. This project was initiated by the doctor who identified the opportunity to create a solution for information sharing between patients and healthcare providers. The joint project delivered the design specifications of the system and a fully functional prototype. The concept behind this project is related to a practical need identified by the doctor: expediting the flow of health information within Norwegian healthcare, which can be very slow in the case of handovers between healthcare providers. For example, if a patient is discharged from a hospital on one day and has to consult a GP the next day, the discharge report will not have reached the GP. Furthermore, the mechanism is too restrictive: reports are sent only to the doctor who referred the patient; other relevant care providers do not receive them.
The idea for MyBook is a simple one: introduce a new application to support patients in organizing their electronic health files and storing them in a secure central database so, they can be accessible over the internet after proper authentication and authorization. The new application would support patients in photographing the paper printouts of their medical records and uploading the digital files to a central database. Patients could then give viewing access to care providers as needed. Conceptualizing MyBook as a patient-owned application for own data, implies that it is not regulated by the Health Registry law (which would necessitate a heavy approval process). MyBook does not require digital integration (at least not initially) but instead relies on the patients’ work to collect and share information.
In the early stages of the design and development of MyBook, the project team worked closely with the doctor who initiated it to further elaborate the idea and develop concrete functionality. After the functionality was initially defined, a demo was presented in a user workshop with patients, at which the desirability of such a solution was discussed together with functionality options and opinions regarding security and privacy. The patients expressed wishes for specific additional functionalities, such as note keeping (on health events or questions for the next appointment with a doctor). They also wanted to be able to register data and display them in a graph. Additionally, they expressed the wish to selectively share single documents rather than opening access to the whole folder, which includes everything uploaded. The doctor, for whom simplicity was an overall design goal, maintained that minimal functionality should be pursued. Following this workshop, a functional prototype for smartphones and computers and a secure database were developed.
The functionalities included in the prototype developed support patients to a) digitize and tag paper copies from their records, b) upload to a central database and c) manage access rights to a personal data folder in the central database. The documents uploaded can be categorized in five fixed categories: record extracts, prescriptions, laboratory results, medical imaging and “other”. The project started in the spring of 2012, the development started during the summer of 2012 and the prototype was tested in 2013. The project has been dormant since late 2013 due to difficulties in defining the business model for launching MyBook for the general public.
4 Method
This study adopts a qualitative interpretive research approach (Klein and Myers 1999; Walsham 1995) and aims to examine the design of PHRs with the analytic lens of hybrid CIS. PHRs can have a hybrid character when their purpose is to go beyond personal discretionary use and extend to information exchanges between patients and healthcare providers. With this aim, we studied the early stages of the design and development of MyHealth and MyBook (presented in the previous section).
For the case of MyHealth, data collection started in January 2013 and ended in December 2014. We attended weekly project meetings, workshops and other thematic meetings, at which we took detailed notes (49 meetings in total). We also conducted interviews (28 in total) with members of the project team. Additionally, we were granted access to review meeting documents, presentation slides and project reports. We had the role of observers during meetings and workshops; we did not pose any questions or engage in discussions. We complemented observations with interviews, in which we explored issues that we noted during observations or other topics of interest and sought to capture the different perspectives of the different members of the design team.
For MyBook, the approach was different because this was a joint project between our university and a doctor/entrepreneur. The researchers who attended project meetings also had a participant role as discussants, but they were not decision makers or members of the core design team, which included the doctor who conceptualized MyBook and one technical developer. Data collection started in March 2012 and ended in June 2014. Data were collected by attending project meetings and a workshop with users. Detailed notes were taken (including several verbatim quotes), but none of the discussions was recorded. Additionally, the researchers had access to and reviewed project documents, including several drafts on requirements as well as specifications and the final technical documentation for the prototype delivered. In Table 2, we provide an overview of data collection for the two cases.
Table 2
Overview of data collection
Case | Data sources | Period of data collection |
|---|---|---|
MyHealth | Notes from project weekly meetings (49 in total), 1 design workshop and 5 thematic meetings; 28 semi-structured interviews; project documents and Norwegian Healthcare Strategic Planning Documents | January 2013 to December 2014 |
MyBook | Notes from 18 design meetings and 1 workshop with the users; working drafts, requirements, specifications and technical documentation | March 2012 to June 2014 |
This study is part of a research program on the interplay between new information and communication technology applications and modes of organizing within Norwegian healthcare. Within this program, new patient-oriented, web-based technologies are studied in the context in which they are designed and developed. Also, the current IT landscape in the Norwegian healthcare context is mapped and studied by analyzing policy documents, laws and regulations on the use of health information, standards for IT in healthcare and documents related to ongoing relevant initiatives. For this research program, we examine how “things change over time” (Pettigrew 1997) by employing multiple methods of data collection, including observations, interviews and document analysis (Benbasat et al. 1987). The empirical material yielded for this research has been analyzed previously to investigate the work of infrastructuring and the influence of established logics on infrastructure transformation (Grisot and Vassilakopoulou 2015; Grisot and Vassilakopoulou 2017; Vassilakopoulou et al. 2017). For this prior analysis, we conceptualized the new patient-oriented solutions as extensions of the overall Norwegian healthcare information infrastructure and explored the challenges of developing new technological capabilities not as standalone objects, but as elements in wider infrastructures. Furthermore, we have used some of this empirical material together with data from another case to explore issues related to service design (Vassilakopoulou et al. 2016). With this paper, we shift our attention to the hybrid nature of the artefacts that are being designed and developed and the tensions in the design process that are inherent in such projects. By analyzing our empirical material, we aim to trace salient design considerations related to PHRs’ hybrid nature.
For the analysis of PHR design we draw from prior empirical research which has pointed to the processual nature of design and the role of decision making throughout the design process. For instance, Bratteteig and colleagues examined how a “successful” design idea moves from being just a statement to being an idea, then manifested as a representation and, finally, as design results (Bratteteig et al. 2016). In research that has an empirical focus on design the central role of decision-making is emphasized: “Design is decision-making… all decisions are a choice between possibilities, and selecting one of them and making it concrete as a change in an artefact, is a demonstration of the capacity to transform” (Bratteteig and Wagner 2012 p. 41). A series of design choices redefine an initial open “problem space” into a more well-defined and configured “design space.” We build on this to investigate how the PHRs studied attained their characters through specific design decisions.
We performed the analysis of our empirical material in three steps. First, we used our empirical data to construct a list of controversial issues and tensions that were discussed in meetings and workshops. We then marked the issues that are related to the hybrid nature of the artefacts being designed and developed, filtering out tensions that are not relevant to our specific research interest (e.g., tensions related to business models or the adoption of alternative technological standards for queuing messages). As a third step, we identified overarching themes for grouping the different tensions: control allocation, content origination and user environment localization. All authors participated in the analysis of the empirical material. Our findings are presented in the next section.
5 Empirical findings
The study of the design and development of the two different PHRs allowed us to trace how the tensions inherent in the PHR concept are addressed through specific design resolutions. In our analysis, we focused particularly on how project team members articulated different tensions related to the hybrid nature of the systems under design and how they found tradeoffs between fitting the systems for private use and configuring them as common spaces. In analyzing the two cases, we unpacked the hybridity of PHRs by organizing these tensions along three key themes: control allocation, content origination and user environment localization. The main research findings are now presented in subsections related to the three themes identified.
5.1 Control allocation
5.1.1 Deliberations about control in the case of MyHealth
The decision to introduce MyHealth as a patient-controlled solution that would be part of the national health service offering, led the design team to deliberate on how this could be translated into actual design decisions on allocation of control rights. In other words, what kind of approaches would be adopted for handling the health information content, and what would be the logic for user control? One of the first issues discussed relates to the national and universal character of MyHealth. Because this is a national-level initiative addressing all residents of the country, would everyone need to have a PHR? The straightforward answer was that it would be something that each person would have to decide. The technical functionality would be available and the connections that allow information flow between various systems and MyHealth would be in place, but it would be activated only if a person decided to activate it. One of the legal experts in the team investigated how adequate control could be ensured in legal terms: “consent might not even be enough, because it will be so much information that you will store … We need probably a regulation in law. We had a meeting with the Data Protection Authority on Friday, but it is unclear yet how we will do this … You will store too much information in one place, each citizen will kind of be responsible for so much. And people do not know much about information security and they do not know how to do it safely. So, it is a big responsibility to put on the citizen.” There was uncertainty both about how to regulate access and how to inform citizens about what to expect from the new electronic solution.
One key aspect that sets the idea of a national PHR apart from previous personalized information initiatives within HealthNorway is the accumulation of sensitive personal information. At the time of the study, there were already two personalized services offered through HealthNorway: one for viewing prescriptions and one for viewing vaccinations. The new initiative was considered different from prescription viewing, which “is deleted after three months, so there is no history there.” Furthermore, it was also considered different from viewing vaccination records: “information on vaccination is not very related to you as a person; for instance, the child vaccination program is just the standard vaccination—it does not say anything about you as a person.” Even more importantly, patient ownership is something that sets the new initiative apart, as a team member explained: “that you are responsible, you as a person are responsible for that information … An archive is not the same as your medical health record. You can include things like appointments for your physiotherapist, dentist, anything, and then it can be things that they send you like lab results and things like that, but it is not like a medical journal where a doctor or nurse decides what should go into the journal … For instance, if you test your sugar level ten times a day, not all of them would be part of the medical record, only a few, the important ones. In the medical record, you are not supposed to enter all information but just the relevant information. The personal health archive will be different because you can put in whatever you like, even your own notes.” A core characteristic of the solution was that it was up to citizens to decide what the archive would contain.
This new solution would provide connections to various systems within healthcare, but this would also need to be controlled by the patients. A team member elaborated on how this control could be enacted: “the hospitals will be able to send you things, but you need to give your consent of who can send you anything. It is not that anyone can start sending … You can also make your personal notes … No one can access your personal archive. If you give your consent I can send you something. Others cannot log on or look at it. And then you can decide if you want to share information, but it won’t be by logging in, it will be that you send out information like an email, so it is still your responsibility and your archive.”
The initial discussions led to the realization that designing for control by patients has multiple facets. First, it is important to ensure that patients will be in a position to make informed decisions about having or not having such a PHR and that patients will be able to control what pieces of information are stored in their archive and with whom they share specific pieces of information. In a design workshop, the team discussed how patients would be able to restrict access. During the discussion, the information flow paradigm was used. Patients would have their own space, and information could flow in and out of this space based on their will according to a messaging logic. In the discussions, the team said that input from the doctors´ association is also required on the patient options, and they were in dialogue with the association. When interviewed, the design team’s legal expert said that there are many issues related to doctors’ professional responsibility: “you should be able to make your own notes and you can decide to share it with your doctor, but also you need to make sure to know when is it that the doctor is responsible. For instance, if I send a note to the doctor, a message where I say that I will kill myself, is he then going to be responsible for that? You cannot have an open channel to the doctor because then the doctor will have to sit with all the messages, when is the doctor going to read them and how fast?” This extreme example was used to illustrate the implications of design decisions and how the team had to consider possible unintended consequences.
In the workshop, there were more discussions about what it means to have control over sharing. Can a patient decide to share a message written by a doctor with a third doctor? The answer was yes, in principle, because this is a patient-controlled record. Similarly, the team said that in principle, patients should be able to export data. However, there were concerns about how patients would treat their data in a way that ensures that data are kept safe and private and how to “find ways so that it is not too easy to resend it, or download by default. It should be a little bit difficult to do those things, not very difficult, but a little bit difficult … If people download everything to their laptop, then the safety will be as safe as the laptop … so it is better if you log on and everything is kept in the same place and that the place takes care of the security. If you make it easily accessible and everything is very easy after you log on, then I would not expect people to download.” These concerns show how the issue of delegating control is closely related to issues of personal information security.
Following the general mandate of patient control, the design team had to put in place routes and methods for patients to handle their health information. This entailed taking a position on a number of issues and making choices among different design options. The design team had to balance the autonomy of patients with the need to provide protective mechanisms, to facilitate sharing and to ensure adherence to established logics of healthcare delivery.
5.1.2 Deliberations about control in the case of MyBook
The doctor-entrepreneur who came up with the idea for MyBook conceptualized it as patient owned and selected a name that signals that this is something that belongs to the patient. To make this point clear, he made comparisons with other initiatives that simply modify existing record systems by giving patients access to specific documents. He explained that the key difference between MyBook and these initiatives is that they do not allow patient ownership and responsibility. Although the idea of patient control was clear from the start, the details of it were not; the actual ways of giving to patients control over MyBook had to be worked out. For instance, the doctor-entrepreneur envisioned that patients would be given functionality to control sharing at the level of the “whole book” but during a workshop with patients it became apparent that they wanted more granular control (i.e., sharing parts of their health document collection). One patient explained that selective disclosure was required because some things were more personal or “taboo” than others. Although the patients expressed a preference for selective/granular sharing, this was not adopted by the design team because it opposed the principle of simplicity that the initiator of MyBook had defined as a key requirement. In a different workshop discussion, patients expressed concern about using mobile phones for taking photos and uploading documents because some apps can access the phone’s photo album. The technical developer explained that there are ways to develop the application to ensure that no photo will end up being stored on the phone. This indeed became part of the specifications and the functionality in the prototype developed. Additionally, a design decision was to allow patients to set the duration of sharing with particular healthcare providers (i.e., the number of days, months or years) and enable them to revoke access to documents at any times.
In the case of the national solution, the sharing approach was conceptualized in terms of information flow to and from the personal health archive; in other words, a messaging logic was adopted rather than an access logic. Unlike MyHealth, in the case of MyBook, the preferred approach was to grant access. In the workshop with patients, the actual functionality that would implement such an access logic was discussed. Patients discussed the possibility of giving their doctors a one-time password and referred to their experiences with such passwords when using internet banking solutions. After discussion, the solution of giving a password with a patient-specified duration was selected.
Giving control to patients also meant that they would have the ability to delete their book permanently or temporarily deactivate it if they wanted. A key question was whether the patients would have the ability to export and locally store the content of their book before deleting it from the central remote storage. The doctor-entrepreneur objected to this: “I see a security risk in copying and moving data. It can lead to things going astray, and the system coming into discredit.” This security concern was similar to the concerns expressed in the discussions we followed for MyHealth: downloading the accumulated information to local computers was considered risky.
Interestingly, when discussing the possibility of deleting individual files from MyBook, some patients expressed doubts. One patient said that it is one thing to take a document under the radar (by not allowing it to be shared) and a very different thing to remove it permanently; the patient was concerned about the desirability of a delete option. Another patient said, “I will not delete anything. My history should be there … Doctors have to trust that we have entered all data.” The patients wanted control, but at the same time they felt that the book was not totally private and that they had to ensure some sort of integrity by informally following some of the rules that hold for medical records. They felt accountable for the completeness of information in MyBook.
It was interesting to identify also in the MyBook case the tension between the autonomy of patients and the need to provide protective mechanisms against privacy threats (as illustrated in the decision not to provide a download functionality). Furthermore, concerns about balancing patient autonomy with the need to facilitate sharing and ensure adherence to the established logic of healthcare delivery emerged. Although the tensions observed around issues of control during design deliberations are similar in the two cases, the two teams made different choices.
5.2 Content origination
5.2.1 Deliberations about content origination in the case of MyHealth
The design team for MyHealth not only had to put in place routes and methods for patients to handle their health information, they also had to think of what types of health information would be supported and what would be acceptable data sources. In other words, the team had to make decisions on the origination of the content of MyHealth. Several discussions were triggered by comparisons with a parallel Norwegian government initiative to introduce digital mailboxes. The citizens who would opt in to using a digital mailbox would receive documents in a digital format in these mailboxes instead of physical letters by post. The design team discussed what makes the new patient-controlled health archive solution different from a digital mailbox.
A key difference discussed was that the new digital mailboxes are “only meant for the government to send things out … It is like the mailbox you have at home. It is one-way.” Thus, the possibility of including content that is patient generated sets the personal health archive apart from a mere digital mailbox. Furthermore, the concept of the digital mailbox was very simple compared to the dynamics of the information content envisioned for MyHealth. One team member explained this: “what they want to do is to create a standard solution for the government to replace paper mail. Instead of sending email in the mail box on paper and with envelopes, hospitals and other government agencies can send a digital mail … But what we want to do is to have an interactive experience at a new locality … The patient to access his or her information in only one place. We want it to have different types of data that could be stored and patients to get the possibility to write in information of their own. We also want people to upload their own information of different data types … Then we are thinking about the devices, mobile systems. People already use instruments to check their sugar levels … It is very easy to visualize that in the future a family doctor and the patient, when they know each other, they can agree that the patient can bring some of his own monitoring information instead of hurrying into the doctor and they will take the blood pressure or other measurements … We don’t think that we will use medical devices connected to mobile phones in their own right and put all the data into a system that the doctor would see. But when he agrees at a specific time, then you would upload or synchronize data over a period of time or a specific type of data after agreeing with your doctor … We want to have a system that could expand into this.” The vision behind MyHealth was the creation of a flexible space where patients could enter information in different formats and from different contexts. Another team member explained how patients could include content from various sources: “here is an appointment that is generated from the system, here is an event that you put in yourself because maybe you were out travelling and you broke your ankle in New York city … so something will be generated from the system, and something you will put in yourself.”
The importance of patient-generated data together with the potential for interactions with doctors were considered pivotal. For doctor-patient interactions, however, patient preferences and wills were not the only concern. In the design workshop, the interactive services were discussed as “an individual offer not to be considered as a right-based service, meaning that it will not be considered an equal right for everyone. It will come out from the relations between doctor and patient: the doctor decides if it is appropriate to use. It is not a right to have, and it is important to inform patients about this point.” Doctors’ autonomy and the need to preserve their leading role in shaping their relationships with patients were considered important. Furthermore, the issue of feeding medical health records in the EPRs with patient-generated content was discussed. In the same way that patients select what to include in their patient health archive, doctors would have to judge what parts of the patient-generated information would be included in the patients’ medical record. In the workshop, concerns were raised about the availability of time on the doctors’ side for making decisions about what to include in the patients’ medical record. The team participants stated that they expected a transition period during which doctors would learn how to use the system and make it work for them.
Although the design team decided to include patient-generated data, the complexity of including these data in the national solution was such that the initially launched version does not include any functionality for patients to upload their own data. Therefore, patients at this moment (early 2017) cannot “write” into the Personal Health Archive, and all data stored there are linked to their actual encounters with the health system. Thus, patients do not have the right to upload data from other relevant sources, such as wearable devices. Furthermore, patients cannot yet edit or annotate the documents that are stored in the archive. Overall, the design team made a number of choices regarding content origination. They had to decide whether the content would only be extracts from healthcare provider systems or if patient-generated content also would be included. They also had to decide about the practicalities of getting information from other systems: would it be pushed to the repository or pulled by the patients? Furthermore, they had to think about the relationship of the content in the patient health archive and the content of medical health records.
5.2.2 Deliberations about content origination in the case of MyBook
MyBook was created with the key aim of filling a gap in the healthcare information infrastructure. It was conceptualized as a way to make health documents available to healthcare practitioners when they cannot reach these documents through the existing healthcare system mechanisms. Hence, the envisioned content was mostly copies of documents generated within the healthcare system such as previous diagnoses, prescriptions and lab results. In that sense, patients were meant to perform an administrative role by copying, uploading and sharing documents rather being actual content generators. The patients who participated in the workshop expressed a desire for additional functionality that would allow them to annotate and tag the documents uploaded; furthermore, they expressed a need to save structured data in numerical format. The team decided that the system would eventually include functionality for creating notes and comments and storing numerical data, but this was not a first priority and could be developed in a later stage. Nevertheless, because any type of file in the form of a picture can be uploaded to MyBook, patients can store anything that can be photographed, including lists, but not structured data.
Interestingly, the patients expressed concern about their ability to judge what would be useful to include in the “book” in order to support doctors. A patient said: “it is not always easy for patients to know what doctors need to know … Doctors are asking about everything. They will of course need to have full history, chronic diseases and more.” Another patient agreed that it is important to start understanding what doctors would like to know, which is as important as considering what she would be comfortable sharing. In a sense, the patients were thinking of MyBook as a common space populated by information that both patients and doctors agree should be there.
Although the design team made the decision not to explicitly include patient-generated data in MyBook, the decision to rely on patients to upload information and the decision to use generic image files led to the development of an application that essentially gives patients many options for the generation of content. The situation with MyBook in terms of content origination is actually the opposite of MyHealth, where user-generated content is supported in principle but not yet implemented.
5.3 User environment localization
5.3.1 Deliberations about user environment localization in the case of MyHealth
During the pre-study for MyHealth it was decided that it would be accessed by patients through the already existing HealthNorway platform and that new visual elements and additional screens would have to follow the overall style of HealthNorway to ensure a consistent user experience. Although HealthNorway was chosen as the patient interface for MyHealth, a different approach was followed for the healthcare practitioners’ side. Specifically, the existing EPRs would be extended to support healthcare providers interact with patients without leaving their familiar software environments. Practically, this means patients and healthcare providers would not share one common user environment.
For the interface on the healthcare practitioners’ side, the Agency team aimed to ensure embeddedness within the pre-existing work arrangements. For instance, they wanted to avoid introducing a new system that would require extra work (e.g., following additional authentication procedures) and time to learn how to use it. Therefore, it was decided that healthcare providers would access the new services through their existing EPRs. At the same time, for the patient side, a new web-based environment was put in place. Having a dedicated interface for patients opened numerous possibilities for configuring the presentation of information. One of the team’s main concerns was to create an interface that would be expandable in the future. A team member explained the need to “make it as wide as possible with a clear concept …make a platform that can change together with the user and the user needs.” The design team thought of approaches for presenting information that do not require specific predefined thematic categories and are generic and expandable. One such idea was to use a timeline.
Furthermore, one of the team members who was responsible for interaction design explained that it is important to think of “service design as a thing on top of interaction design. The patient is a patient at home in the morning and evening and having kids and an old mum to take care of and all these different aspects … We need to see all the other touch points, as I was saying—what happens in the waiting room before you go into the doctor … I see that all the work that we do with the user does not go wide enough.” The team understood that there are limitations to what can be designed and developed as a start but also recognized the importance of making good decisions during this early stage even if they are just ‘baby steps’ as one of the team member said.
The design choice of using the HealthNorway interface for patients and the EPR interface for doctors was made at a strategic level and was not decided by the design team. This strategic decision opened up multiple possibilities for configuring local environments. The design team had to balance the need to cater to current needs with the need to ensure the future evolvability of the patient-use environment to address the multiple aspects of everyday patient activities and include multiple information sources.
5.3.2 Deliberations about user environment localization in the case of MyBook
In the case of MyBook, it was decided that patients and healthcare providers would use a common interface. The concept is that doctors will be granted access after getting an invitation and password from patients and then, proceed to the same content views that patients can access. The team decided that these content views should not be dynamic or tailorable by individual users (patients or healthcare providers). Instead, the team chose to implement a predefined structure according to five specific categories: record extracts, prescriptions, laboratory results, medical imaging and “other”. This predefined structure facilitates use by busy healthcare providers who need a consistent and unvarying structure for all patients, minimizing the time required to identify useful information. Hence, there was an explicit choice to not allow tailoring at the user environment level. The doctor-entrepreneur explained: “simplicity is important, I believe in these four plus one categories.” The patients expressed a desire to define categories themselves. For example, for some users it would be interesting to define a category for diet supplements and to register what worked and what did not work for a specific person at a specific time. The workshop participants also asked for functionality to visualize data in graphical form. Although the design team was aware of these user preferences and desires, they decided to defer them for a later application release. Simple, uniform content presentation was the choice for the first version of MyBook. The design team addressed the tension between personalization and standardization by downplaying individual preferences.
6 Discussion
In the previous sections, we examined the tensions in the design of PHRs that aim to go beyond personal discretionary use and extend to information exchanges between patients and healthcare providers. We followed the deliberations of the design team and grouped tensions in three overarching themes: control allocation, content origination and user environment localization. Specifically, the tensions identified point to: the need to balance communality against autonomy, the need to find ways to empower users while restricting user behavior that can compromise security, the need to ensure quality assurance while accommodating inclusiveness, the need to strike a balance between transforming and preserving established logics, the need to support personalization while pursuing standardization and the need to strike a balance between dynamic/adaptive and static/predefined options in the user environment. The different tensions identified and the respective design resolutions that shaped MyHealth and MyBook are presented in Table 3. The tensions included in the table largely constitute the general problem space for the design of the two PHRs.
Table 3
Design tensions and their resolutions for MyHealth and MyBook
Tensions | MyHealth Resolutions Patients can: | MyBook Resolutions Patients can: | |
|---|---|---|---|
Control allocation | communality vs autonomy protecting vs empowering users | decide not to have MyHealth send information download information locally only through cumbersome procedures | decide to have MyBook share information download information locally but only document by document |
Content origination | inclusiveness/comprehensiveness vs quality assurance transforming vs preserving established logics | create their own subsets of medical health records inform healthcare practitioners through formal information flows to EPRs within a framework set by doctors | create content collections that include extracts from medical health records and other content in image format inform healthcare practitioners through informal means by providing access to own document collections |
User environment localization | personalization vs standardization dynamic/adaptive vs static/predefined | view a dynamically created timeline | arrange information in predefined categories |
In our analysis we focused explicitly on design tensions related to the hybrid nature of PHRs. PHRs are hybrids because they can be conceptualized as information spaces that are partly private (serving sensitive personal health information management needs) and partly communal (facilitating information sharing between patients and healthcare professionals). Although earlier literature on PHRs emphasizes the challenges of bridging patient and provider perspectives, we shift attention to enabling hybridity and regionalizing (Clement and Wagner 1995). Regionalizing can help actors to get focused and to protect their views by contouring areas within an overall collaborative space. PHRs provide great opportunities for sharing but also for preserving the autonomy and privacy of personal health management practices. One important aspect of the work performed for the two PHRs relates to the identification of ways that allow users to create regions and dynamically adjust the regional boundaries. Essentially, the three key themes identified in the analysis of tensions (control allocation, content origination, user environment localization) all point to decisions related to regionalization. This is the general design problem identified in the design of the two PHRs.
The design resolutions for the different tensions identified reveal that many of the design decisions tend to privilege the existing arrangements for patient–healthcare provider interactions. These existing arrangements have been largely shaped by the organizing logics of the institutionalized healthcare system. For instance, in the MyHealth case, the preservation of doctors’ leading role in shaping relationships with patients was considered important. Similarly, in the case of MyRecord, the presentation of health information was designed in a way that facilitates busy healthcare providers that prefer consistent and unvarying structures for all patients. Our findings show that the transformative aims of PHRs are difficult to achieve. This is consistent with prior research on the introduction of digital tools for personal health information management that also facilitate patient–healthcare provider information exchange. For instance, Hess and colleagues studied a PHR (UPMC HealthTrak) that was introduced by the University of Pittsburgh Medical Center to allow patients to access medical record information and communicate with their physician’s practice (Hess et al. 2007). UPMC HealthTrak mirrored to a great extent the pre-existing arrangements for patient–healthcare provider communications, and this is close to what we have observed in the cases studied.
The difficulty to break away from established arrangements is not surprising. Breaking away from the organizing logic of the healthcare system entails first of all making sense of idiosyncratic patient information management practices that remain mostly uncharted. As Piras and Zanutto have pointed out, these practices are in some ways invisible as they are interwoven with everyday routines and objects that are part of the private sphere (Piras and Zanutto 2010). Designing systems adapted to current patient information management practices would require intensive engagement with the everyday “work” of patients through an iterative combination of ethnography, design and redesign (Greenhalgh et al. 2010). Nevertheless, although following such a user-centered approach could lead to the design of technologies that align well with existing patient health information management practices, it would still be challenging to anticipate and cater for the future transformations of such practices that PHRs enable. Furthermore, as PHRs straddle work and non-work contexts, it is not possible to reorient user activities by redesigning and introducing new operating procedures (as in institutionalized work settings). This singularity of PHRs was identified by Fitzpatrick who noted that “while at their core they might be functionally equivalent to institutional technologies, they need to be able to be appropriated and integrated by people into their everyday lives and spaces and social contexts” (Fitzpatrick 2011). Overall, the design of PHRs with the aim to realize their transformative potential and stimulate changes in healthcare delivery (Detmer et al. 2008; Pagliari et al. 2007) is challenging because it is hard to accommodate multiple current patient information management practices and to incite their transformation. The identification of this challenge shifts our attention to the role of patients in the design process.
In both cases the patients contributed to the design process through their participation in user panels and workshops but were not part of the core design teams that made the choices related to the specific design resolutions identified. Each resolution is essentially the materialization of one out of many different possibilities contributing to the configuration of the two PHRs (Bratteteig et al. 2016). Analyzing our empirical data, we can trace several decisions taken that would probably have been different if the patients had a stronger decision taking role (e.g., in the case of MyBook, functionalities for uploading structured data and adding annotations might have been added). Nevertheless, even a stronger involvement of patients in decision taking during the early design and development phases of the two PHRs would not resolve the challenge of delivering solutions useful now and in the future for varied patient audiences with different medical conditions, lifestyles, perspectives and capabilities. The PHRs that are targeting the general population have an open character that is difficult to address with established user centered design approaches which necessitate the identification of specific user groups and specific use contexts. Designing systems that can evolve toward new patient-friendly configurations catering to idiosyncratic, largely uncharted patient information management practices that keep evolving, entails making conscious choices to allow end-user tailorability after introduction to use (Cabitza and Simone 2015; Germonprez et al. 2007). Our findings show that designers had to delegate several decisions to the patients themselves. For instance, the patients can decide what to include in their PHRs, what to share and when to share.
Cabitza and Simone, envision a radical new approach for the design of information systems that are to be embedded in social cooperative settings (Cabitza and Simone 2015). They suggest a new strategy that relies on end-users taking up the role of bricoleurs who in different circumstances can either construct and assemble pieces of technology or exploit those assembled pieces by actively using them according to the situation at hand. For this to happen, a general, versatile technical environment will have to be available enabling end-user design activities that go beyond the mere adjustment of a predefined (at design time) set of elements. This environment (or meta-system) would allow resourceful bricoleurs to create new functionalities according to their needs and competencies by combining elements they already possess with novel digital capabilities. Such an approach, would radically change the role of designers: instead of making design resolutions that shape the evolution of solutions (as in the two PHR cases we studied), their role would be to focus on providing enabling environments that are easy to use, while being powerful and flexible enough to support bricolage activities. This proposal by Cabitza and Simone is actually different to calls for more close cooperation between designers and users during system design. Their vision defies the idea of defining functionalities “a priori” (i.e., outside the use setting) and aims towards a shift to a situation where information systems will be shaped and re-shaped “in situ” by users during use. Hence, they are proponents of a clear separation of concerns: design of enabling environments (meta-systems) for designers and bricolaging in practice for end users.
Although the design teams for the two PHRs did not envision fully shifting the responsibility for functionality shaping to the patients themselves, they did aim to deliver initial solutions that allow adaptations and expansions toward a better accommodation of patient needs. The vision by Cabitza and Simone would require dramatic changes to both design and use practices. Nevertheless, we are currently going through an opportune moment for experimenting towards the direction they propose. Open, modular and flexible technological capabilities are becoming more available and mature, and the general population accumulates digital experiences becoming more capable of making sense and visualizing new technological possibilities. Such an experiment could provide new avenues for delivering technologies that accommodate the current and future needs of the varied user groups involved in personal health information management and would result to design processes where tensions are not resolved “a priori” by designers that are external to actual use settings. The discussions within the design teams in the projects we followed revealed an explicit concern about how PHRs that are now launched with only core functionalities can evolve into real tools for patients.
7 Conclusion
Our paper offers an empirical exemplification of the tensions in the design of PHRs that have a hybrid character (i.e. PHRs that have the dual purpose to serve as both personal and common information spaces). The tensions identified point to the multiple alternative design choices to address the problem of regionalization (Clement and Wagner 1995) in such hybrid artefacts. In the cases studied, specific design resolutions (choices among different possibilities) were made by the design teams shaping each PHR’s character. Our study can be extended by following the evolution of the specific PHRs over time as they are appropriated by various user groups, to get a more complete picture of PHR-shaping dynamics. Furthermore, it would be interesting to experiment with a design approach that supports different patients to act as genuine bricoleurs constructing/assembling and exploiting technology (Cabitza and Simone 2015). For this to happen, professional designers would have to restraint from resolving specific design tensions and instead focus on providing generic enabling environments. PHRs are suitable for such a real-world experiment that has the potential to bring path breaking insights for design processes.
Acknowledgements
We acknowledge the support of the Responsive Architectures for Innovation in Collaborative Healthcare Services (REACH) project, funded by Norwegian Research Council, VERDIKT program (project nr. 213143), and of the Centre for Connected Care (C3) funded by the Norwegian Research Council’s SFI scheme for Centres for Research-based Innovation (project nr. 237766). We are grateful to the members of the design teams for the two PHRs, and to the anonymous reviewers that helped us improve the paper.
Open Access This article is distributed under the terms of the Creative Commons Attribution 4.0 International License (http://creativecommons.org/licenses/by/4.0/), which permits unrestricted use, distribution, and reproduction in any medium, provided you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons license, and indicate if changes were made.