Why developers matter: The case of patient portals

Abstract

Existing studies on patient data portals are informative with respect to the patient and physician perspectives, yet relatively little attention has been paid to the role of developers. This case study focuses on how developers view the meaning and purpose of patient portals and how their perspective differs from that of physicians. The findings show that developers and physicians have different views on whether and how the portals can help achieve transparency, efficiency, and patient empowerment. This misalignment emerges because each group makes sense of the portal through a different frame of how they see patient data, medical work, and patient behavior. The study also finds that developers cope with the frame differences by engaging in practices of coproducing, bypassing, and reframing. The implication of the study is that technological frame analysis needs to incorporate the growing complexity and institutional character of modern technology, the diversity of target groups it serves, and their corresponding frames. The study also suggests that developers, instead of being seen as mere operational IT support, may need to be seen as strategically important actor groups for healthcare organizations—since their practices matter for the strategic agenda of transforming healthcare into a more patient-centric practice.

Introduction

Allowing patients to view their medical data via web-based portals has been advocated as a crucial step toward more efficient, patient-centered, and less paternalistic care delivery.^1–3 Yet, in clinical practice, embracing patient portals leaves much to be desired. Studies show that hospitals vary significantly in their ways of implementing patient portals ⁴ and that there is much controversy associated with such implementations. ⁵ To understand why it remains challenging to integrate the use of patient portals into clinical work, recent reviews suggest that we need to move beyond patient perspectives and technical considerations and direct our attention to organizational issues. ⁶ More research is called for to explore issues such as managing stakeholder interests, organizing for physicians’ engagement, or aligning different perspectives.^6–10

This study addresses the call by attending to the role of developers of patient data portals. Existing literature in health informatics is informative with respect to patient and physician perspectives on patient data portals,^5,8,9,11,12 yet relatively little attention has been paid to the developers’ role. In terms of patients, studies have explored various factors influencing patients’ acceptance of portals, ranging from basic sociodemographics ¹³ to more complex factors such as behaviors with data, digital literacy, perceptions of usability, and the aesthetics of portal design.^6,12,14 Another stream of the literature has focused on the effects of portals on various patient outcomes. Studies report, for example, that under certain conditions, portals indeed contribute to higher adherence to treatment and engagement in care, as well as a decrease in office visits and direct clinical outcomes such as hospital readmissions.^2,15,16

When it comes to physicians ¹ , a variety of attitudes toward portals have been documented. Some studies highlight outright resistance to portals, while others find more ambivalent views, reporting that physicians appreciate some portal functionality but remain apprehensive about their effects on patients’ emotions and physicians’ workloads.^16–18 A smaller number of studies report on the real-world effects of portals on physicians’ work practices, ¹⁹ including assessments of changes emerging in the provider-patient relationship. ²⁰ For example, studies explain how portals may grant patients more opportunities to engage in their treatment and to educate themselves, therefore, resulting in decreasing physicians’ workloads.^2,21,22 Recent research has also revealed how the perspective of physicians has changed over time and has become more positive with regard to certain aspects of the portals’ use. ²³

Up to now, developers’ practices have been missing from this body of research. Limited attention has been devoted to their interactions with clinicians, their efforts in implementing portals, and the differences between developers’ and physicians’ views about this healthcare technology. To address these lacunae, this study draws on the concept of technological frames, which helps identify the nature and reasons for differences in the stakeholder’s approach to the portals’ meaning and purpose. Such differences in perspectives are then illustrated via qualitative data drawn from a case study of patient portal implementation in a large urban hospital in the Netherlands. The case study reveals three points of differences between developers and physicians: related to how each group views the portals’ role in achieving transparency, efficiency, and patient empowerment. The study then identifies three practices—coproducing, bypassing, and reframing—used by the developers to address the differences. In what follows, related previous research is reviewed.

Related Research

Although current health informatics research has rarely attended to the role of developers, evidence from related studies can be used to explain why their perspective is important. We know from the previous literature that developers’ interpretations of what technology can accomplish are far from straightforward, but may encompass multiple purposes, which also change over time. ²⁴ Developers’ goals for technology may also aim at far-reaching institutional transformations, such as the reduction of public-sector bribery and corruption via computerization; these sorts of intentions introduce a political dimension into technological implementation, complicating and prolonging the process. ²⁵ Thus, the developers’ perspectives exercise an important social influence that shapes the trajectory of technology development ²⁶ and, as a result, affects the resources and time eventually spent on implementation. ²⁴

Previous research has also shown that the developers’ perspectives on technology clashes significantly with the reality of user practices. One particularly rich body of research attests to the undermining of implementation due to a gross misalignment between the developers’ expectations of technology and the circumstances and priorities of situated practices.^27–29 For example, studying the introduction of the enterprise resource planning system into the university, Wagner and Newell (2004) showed how the developers’ desire to standardize the accounting processes contradicted the interests and independent reporting cultures among the faculty, resulting essentially in a project failure. ²⁷

Finally, developers are important to consider because it is through their practices that the emerging concerns of users can either be resolved or ignored. Research has noted, for instance, that the situated activities of lead technology enthusiasts can account for the success or failure ²⁸ of particularly arduous IT projects.^30,31 One example is the “My Medical Record on the Internet” project in Sweden, the success of which was partly attributed to the “entrepreneurship and persistence in seeing the project through” of the key developer, whose continuous efforts to achieve institutional change spanned 15 years. ³⁰

In sum, while current studies tell us that developers may assume a consequential role in the introduction of technology, we still need to know more about their role in the implementation of patient portals—a technology that, extending beyond a single organization, involves the interests of a multitude of stakeholders. We know relatively little about how developers, in practice, perform their actions, how they communicate what they are doing—and, if so, in what specific ways—and whether their perception of the portal’s purpose differs from the physicians’ views. Hence, we are underinformed about where differences might exist or create problems. This study thus asks the following research questions: What are the perspectives of developers on patient portals? How do these perspectives differ from physicians’? What practices do developers engage in to address such differences?

To trace such differences, this study draws on the notion of “technological frames,” a concept used widely in information systems research, and in studies of patient portals, in particular, to provide theoretical explanations of outcomes in technology implementation and use processes.^17,24,32 Technological frames refer to a “subset of members’ organizational frames that concern the assumptions, expectations, and knowledge they used to understand technology in organizations [...including…] specific conditions, applications, and consequences of that technology in particular contexts” (p. 178). ²¹ Grounded in sociocognitive theories, research on technological frames shows how frames act as an “attention-directing and problem-solving template” and an “interpretive filter” (p. 332) ²⁴ through which participants “make sense of contextual information and interpret implications for technological project requirements” (p. 331). ²⁴ Thereby, the frame perspective helps appreciate the sources of interpretations of technology and why they may be complex and change over time: the complexity of frames that are often not reflected upon complicates the development process, making priorities unclear and shifting requirements at different points in time. ²⁴

Frames theory also helps make visible certain political or ideological underpinnings of technology implementation, which is not a merely technical endeavor but requires “frame negotiation” to achieve a workable “truce frame” in IT projects. ²⁵ Studies have frequently reported that the frame incongruence between developers and users—in terms of the nature of technology, technology strategy, and “technology-in-use”—is a common problem complicating projects.^28,33,34 For example, Orlikowski and Gash (1999) showed, in their study of the groupware application Lotus Notes, a significant clash between the technology strategy and technology-in-use frame: While designers were convinced of the “transformative revolutionary potential” of groupware as a strategy, users failed to see any particular application of Lotus Notes to the extremely competitive and individualistic context of work and instead interpreted it as merely another “kind of e-mail.” As a result, a substantial IT investment was wasted because the frames were severely misaligned, not made explicit, or reflected upon, and thus never attended to. Similar frame incongruence continues to be illustrated among stakeholders, such as managers, users, and project leaders, with associated difficulties in implementing user-centered design approaches. ²⁸

In the case of patient portals—a technology associated with major institutional evolution toward patient-centered care and empowerment ³⁰ and thus touching on many stakeholder groups—a multitude of technological frames are invoked, often without explicit considerations of where they differ and how they may misalign. For example, the introduction of patient data portals is intended to achieve diverse purposes: to ensure information transparency, to facilitate patient empowerment, to speed up information flows, and to serve the ideological purposes of ensuring data ownership to name just a few.^30,35,36 Rarely are viewpoints on those purposes explicitly compared. This variety makes systematic comparisons increasingly urgent: We need research to reveal how these viewpoints relate to one another and how they may contribute to misunderstandings between groups. In what follows, insights from a qualitative case study will shed light on these concerns.

Method

The research reported here used a case study approach, focusing on the patient portal implementation in a metropolitan academic hospital in the Netherlands. The patient portal “MyChart” (a module of Epic software systems) was introduced in 2014 and at the time of the data collection had extensive functionality, including the viewing of laboratory results, electronic check-ins, the ability to make appointments online, and the viewing of medical letters between providers. MyChart’s implementation was supported by the national program put forward by the Dutch Hospital Association and the Ministry of Health, Welfare and Sport, which had set an ambitious digitalization goal: Every healthcare institution would need to be able to provide patients with web-based insights into their records by 2020. This program’s goals were the implementation team’s leading priority since the more goals they achieved, the more funding and resources they could obtain from the government.

Appendix 1 provides a chronological overview of the portal’s feature development over the years. As illustrated in the chronology of the portal’s development, one can say that it was a relatively successful implementation: MyChart’s functionality continued to expand—its initial limited viewing possibilities succeeded by the incorporation of questionnaires and eCheck-in functions. At several points, the portal’s functionalities were questioned or opposed by physicians, but ultimately these features were pushed through by developers after making certain adjustments in response to the physicians’ concerns. When the data was collected, the developer team was working on the implementation of further features, such as the viewing of physician’s notes and radiological images, along with integrating external applications. By mid-2018, the portal had around 40,000 active users (around 8% of the hospital’s patient population), indicative of a growing uptake among patients. ² The data collection took place from December 2017 to July 2018.

Data collection

This case study collected qualitative data through semi-structured and unstructured interviews. ³ All developers (four), as well as one head of the physician’s user group, who were actively involved in the portal development and implementation, were interviewed at least once using a semi-structured interview protocol. Questions posed to developers focused on their experiences with the introduction of portal functionalities, their views on all the portal’s functions, as well as their activities related to implementation, and their interactions with users. To obtain greater insight into the IT development perspective, the head of the hospital’s electronic patient records and e-Health projects was consulted during the final workshop conducted at the end of the case study; he offered feedback and reflected on the preliminary first version of the findings. Additionally, 13 informal, unstructured interviews with the head developer responsible for overseeing portal implementation were conducted over the course of the study. These conversations served as a source of retrospective data on portal evolution, provided evidence related to the broader context of portal implementation and hospital policies, and helped clarify and sharpen reflections on the insights emerging from the formal interviews.

Enabling comparisons with the developers’ perspective, seven physicians were interviewed using a semi-structured interview protocol, focusing on their perceptions of how portal features affected their practice. Interview questions to physicians focused on their experiences with the portal as it was being used by patients, their views on how the portal might help or hinder their work, as well as eliciting any episodes or anecdotes related to their stances.

In addition to interviews, the study draws on insights from one in-depth reflection workshop organized with the developer team, which helped to obtain the “member check” to establish the reliability of the study’s insights. ³⁷ All developers were invited to participate. The research assistant and the researcher first presented emerging themes from the analysis of the collected data. The focus of the presentation was on the chronology of portal development and on perceptions of each group of each function that was made available on the portal. The presentation lasted about 40 min, after which developers were invited to provide corrections, reflections, and further background information on the divergence. Appendix 2 details the study’s informants, the types and number of interviews with them, and the use of interview insights in data analysis. Appendix 4 provides the protocols used for interviewing each group.

Data analysis

The data were analyzed iteratively, in several rounds, using a combination of inductive and theory-driven coding techniques. ³⁸ The detailed description of the coding process is presented in Appendix 5. In the first rounds of coding, performed together with the research assistant, we focused on reconstructing the chronology of portal development to distill a sense of the project’s overall success, as well as specifying which features became available when and at whose request, and pinpointing the kind of discussions or negotiations involved with their implementation. The results of this analysis are presented in Appendix 1. We also identified key stakeholders surrounding the developer team whose interests needed to be considered in implementing the portal.

The next step focused on identifying the perceived value of the portal features, as well as related views and justifications. At this stage, we used sociocognitive theory concepts, such as “beliefs” of actor groups and their “standards of excellence” ³⁹ to search for interpretations for why certain functions are or are not perceived as valuable. For example, when coding the perception of physicians referring to the feature of viewing lab results as “not valuable,” we searched for more evidence to identify what the underlying rationale was, resulting in such examples of codes as “patient is not better informed” or “care does not improve” as their “beliefs.” As a result of this analysis, we concluded that even though developers and physicians were broadly alluding to similar ideals (“best possible care”), their approaches in how to achieve those and the role of the portal in them differed. During the workshop, the developer team corroborated our interpretations.

At the final stages of analysis, we noticed that most of the informants’ arguments corresponded to several expectations that are often discussed in the existing literature as either an expected outcome of the portal or an ideological driver for its implementation. By iterating between the informants’ arguments and the existing literature,^3,9,20,40 eventually, three second-order themes were settled on: transparency, efficiency, and patient empowerment, as those were exhaustively capturing all the arguments that were both invoked in the data and transpired in other settings as reported in the literature. At this stage, the theory of technological frames was chosen as a useful lens for synthesizing and interpreting findings. Utilizing the theory of technological frames helped explain why the two groups saw the portal’s role in transparency, efficiency, and empowerment differently by attending to different “contextual filters” or “sensemaking devices” employed by each group.^24,25 Finally, the analysis was concluded by going through the statements in which developers mentioned any activities they engaged in to address the divergence of the frames. These statements were further analyzed as to whether there was an active attempt to collaborate or compromise with the physicians. Based on the analysis of those statements, the activities were grouped into “coproducing,” “bypassing,” and “reframing” practices.

The findings below are structured around three main areas of frame differences followed by developer practices. The findings are visually summarized on Figure 1. Each theme is illustrated with a key quotation; additional illustrative evidence is provided in Appendix 3.

Figure 1.

Differences in technological frames between developers and physicians.

Findings

Transparency: Ownership versus expert judgment frame on medical data

One of the technological frames around the portal is the transparency of medical information. Developers and physicians alike viewed transparency as an important goal that the portal may help to achieve. However, their views on what transparency actually is, and whether it can, realistically, be ensured, differed.

The developers’ view of transparency centered on legal considerations related to “data ownership”: the individual’s right to access information about oneself. For example, they often invoked a “legal right” to personal information as the key, indisputable justification for why they introduce or prioritize certain features on the portal. They also often reflected on transparency via the portal by comparing alternative ways in which patients could obtain the same information—mostly neutral, noncontroversial types of data, such as appointments or information on yet to be completed tests. In addition, the developers’ reflections did not involve scenarios that would result in interpretive difficulties:

It’s a pity that there is still a discussion going on about who is the owner of the health record. Nine out of ten things are owned by the patient, as that is the law. If the patient wants to have an overview of his medical data, he can go to the facility desk and ask for a full copy of his record. Moreover, the information they provide at the facility desk is more than what is shown on the portal. The only drawback is that patients have to pay for a certain number of pages. Not every patient will do that or want that. I think it’s a pity that we are being held back due to this. (Interview 2, Developer)

The physicians’ reflections on transparency were similar to the developers in one respect: most acknowledged the value of transparency as an ideal, especially when related to less sensitive medical information, e.g., an overview of medications, allergies, or previous treatments. The physicians also acknowledged the legal right of patients to have access to their data. However, their reflections were more nuanced regarding this particular goal of the portal. For one, physicians doubted whether meaningful transparency was even possible: the information shown on the record is by its nature incomplete and thus never provides a full picture, even for the physicians involved in the patient’s treatment:

[The record contains] a combination of the medical history, physical examination, and the additional diagnostic research. It is difficult to say what is [a] good [result] and what is not. The radiologist only sees a part of the whole story. All those answers combined allow you to create a full picture. If the patient receives the results bit by bit without interpretation, this makes it difficult for us to explain [the full situation]. (Interview 10, Physician)

Physicians further saw transparency as an unachievable ideal because they argued that medical information on its own, as recorded in a patient’s file, is rarely self-explanatory; transparency cannot be realized without someone interpreting and explaining the information. Because this sort of interpretation is inextricably linked to expert judgement, the whole project of transparency, therefore, seemed too naïve to them:

The patient is not better informed at all, as he has no clue what he is looking at. The information is actually useless, in my opinion. Only if you see a scan with an interpreted report in a way that it is understandable to the patient: only then will the patient be reassured. (Interview 5, Physician)

We thus see different frames among the developers and physicians: frames reliant on legal approaches to what “data” represents on the one hand versus a more nuanced view on the other, which accounts for medical expertise to make medical information meaningful. It is important to acknowledge that both groups recognize nuances and variations as to which aspects of information may and should be made transparent. However, these different underlying approaches to the nature of medical data render the transparency ideal elusive, and the varying approaches to transparency irreconcilable.

Efficiency: Situated practice versus administrative frame on medical work

Another technological frame emerging in the reflections of interviewees concerned a portal’s ability to improve the efficiency of care. Here, the developers and physicians diverged most markedly because different kinds of work were implied as to the target of efficiency gains: work as situated physician practice against work that implies broader hospital processes.

The developers took a global view of the healthcare work as consisting of multiple interdependent administrative processes. They believed that the portal possessed enormous potential to reduce the hospital’s administrative costs and improve its process efficiency. The efficiency gains were seen, for example, in the amount of time saved involving patient registration at reception and medication prescription management, as well as an optimized collection of medical history from patients. There would be better email functionality in communicating test results to patients and time saved in informing them about their health in person:

eCheck-in is one example of efficiency gain. Patients can now verify and check their personal data and answer questionnaires in advance. Name and address details can be checked and verified so that they no longer have to do this at the counter, and this saves a step in the work process. The hospital spends less time with the patient when checking in for the appointment. Social Security number check, insurance check, GP name check: the doctor's assistant usually does that. This means that there could be very long wait times and that there wasn’t a lot of time and that there were many errors in the system. Letters were not sent to patients informing them about the appointments being rescheduled. There were letters to the wrong GPs. The portal functionality will reduce the administrative workload, and that is now one of the core concerns of the implementation project. (Interview 3, Developer)

The efficiency gains achieved by the portal’s features were the most salient for the developers reflecting on the portal. These improvements were often given as examples of prioritized features put on the “top list.” In addition to administrative efficiency, developers also reflected on medical process efficiency, essentially applying the same frame when considering how the treatment process could be optimized and reflecting on how physicians’ practice could benefit from workload reduction:

When the patient gets to see their results online, you don’t have to make an appointment, but you will be able to email the patient. This can also be declared by the healthcare professional but does not take up time during consultation hours. You will not have 23 patients at your morning consultation hour, which means you have more free time. This is an improvement not only for care providers but also for patients, who no longer have to stressfully wait for their results. (Interview 3, Developer)

The physicians’ view of efficiency lacked this sort of global reach. They concentrated instead on their own situated practice and evaluated whether the portal’s functionality, in practice, ultimately saved time with regard to consultation work. The physicians, in fact, challenged the proposition that providing patients with more information would necessarily save the physicians’ valuable time. Instead, they pointed to the opposite outcome, i.e., increased inefficiency. One common explanation was that patients’ exposure to complex terminology is counterproductive since physicians need to spend extra time explaining irrelevant, nonessential matters:

When people come to the consult, I must explain to them Latin words and other terminology that are not important. I will explain everything, but I don’t think this is a solution. Small deviations are discussed, and this takes extra time and does not improve the patient’s care. (Interview 5, Physician)

Sometimes patients call about lab results. They would like to have an explanation of what they mean. This will take extra time and interrupt your work routine. The patient will get his information bit by bit, which is not always best for the patient. (Interview 6, Physician)

The second most common explanation of increased inefficiency was related to email functionality. Most physicians associated the uptake of email communication with an unreasonable increase in workload that—while not factored into their hourly compensation schema—takes significant effort and disrupts routine. Thus, in contrast to how developers imagined things—email would help solve “easy cases” or save consultation hours—email functionality, in practice, contributed to perceptions of inefficiency and uncompensated increases in the workload. Two physicians reflected, for example:

From what I experience, the number of emails increases every six months. The disturbing part of this functionality is that in theory it could save time, as fewer checkups are needed, but since the time spent is not calculated as part of our consultations, I do this work in my free time. (Interview 12, Physician)

The number of emails is increasing. Sometimes the questions are also not relevant or not necessary. Why do I have to pay attention to this? It’s a waste of time and can wait till the next consultation as well. (Interview 7, Physician)

In sum, the views on efficiency differed to such an extent that we could detect almost opposite perceptions at play, shaped by different underlying perspectives on what kind of work is likely to be affected. The physicians also brought up concrete experiences of technology-in-use in their practice more frequently; the developers, for their part, appealed to hypothetical gains for a broader range of processes. It is important to note here that the developers, fully aware of all the nuances of the physicians’ concerns, actively tried to find solutions for the situated work problems, all the while trying not to compromise on the broader efficiency goals central to the portal implementation project.

Empowerment: Technical opportunity versus situated interaction frame on patient behavior

The final technological frame focuses on empowering patients, i.e., the portal would allow patients to take greater control of their care. Here again, the focus of developers and physicians differed with different aspects of empowerment emphasized, depending on the key concerns of their respective practices. For the developers, the portal could empower patients by giving them technical opportunities to control the information in the electronic record. The physicians’ perceptions of empowerment were instead more focused on whether they indeed observed the behavior of patients during interactions changing—whether, that is, their patients took greater responsibility for their own health.

The developers, being focused on the functionalities they could make available, saw a multitude of possibilities for patients to more actively contribute to their own records via composing and editing the data. Examples of features highlighted by developers included patients inputting a list of their allergies or uploading a list of medications being taken, along with deleting information in the file that they deem irrelevant or inputting more information before a consultation. This way, patients are empowered, according to the developers, because they would now be given a greater voice in what is actually written down in the file, as opposed to relying on the input made solely by representatives of a healthcare institution.

Patients can also now add their own notes; the doctor does not [have to] see that; instead [it is] more of a reminder for patients themselves: “take this with you the next time you visit.” About editing the field with “your complaints”—right now we don't have it on yet. The registration of complaints is also done by doctors in the problem list. [Patient editing rights] are not turned on yet. Doctors must fill out a problem list, that is the agreement, and the patient does not yet have the right to add to it. Technically, it is possible, we are busy pushing those kinds of functionalities more because then we can also integrate it again with eCheck-in prior to the appointment, but this is a process that takes a while. We have started to inquire about the possibility for patients to edit their medication and allergies, and patients demand that the most because medication shows an overview of the known medications taken, and we are working on adding patients. But to get approval there takes forever. People must make decisions and that doesn't happen. (Interview 4, Developer)

The physicians, whose work involves continuous interactions with a variety of patients, tended to see empowerment differently: as embodied in behavior, and as being actualized only when manifested in observable changes by patients during consultations. The physicians did agree that the portal can—hypothetically—contribute to the empowerment of patients. However, they were more eager to see such empowerment realized via participation in care and shared decision-making. Reflecting on their current experiences with patients, the physicians were ambivalent about whether the portal actually enabled, and did not, in fact, hinder empowerment. One line of reasoning suggested a degree of variability in how different patients react to the information they read online. Another issue they mentioned was the changes needed on the part of the physicians, e.g., being ready for more difficult conversations or being more available to provide explanations to patients. One physician recalled a positive example, offering an experience that is contrary to those often described in the literature, ¹⁷ to illustrate what they would ideally like to see achieved by the portal to properly empower their patients:

A few weeks ago, I had one patient who read her medical letter. This letter included my suspicions as well as my considerations. This woman read the sensitive information, she Googled a bit and discovered her illness on her own. This resulted in a rich conversation due to her self-explanatory research and the fact that she was already prepared for the bad news that was highly possible to come in the next consultation. This enriched and helped me a lot throughout the conversation when it happened. (Interview 9, Physician)

The views expressed by the physicians thus introduced several alternative dimensions of empowerment: On top of providing technical affordances of portals to allow patients to participate, empowerment for them was more concerned with the behavior of patients and with how the conversations with patients are conducted in practice. The physicians’ views, when contrasted with the developers’, helped us, therefore, to appreciate that empowerment is not limited to the technological possibilities of the portals: empowerment is also about how, in practice, patient and doctor interactions happen.

Responses to diverging frames

The developers, aware of the frames employed by physicians, referred to physicians’ concerns as “understandable” and “legitimate,” even if they personally did not agree with them and were “sorry they [could] not progress with the portal more quickly” (Interviewee 2, developer). However, the developers also found themselves in the center of multiple and often competing interests, which they also needed to take into account, such as those of the patient group, administrative group, project funding group, and others. Such positions meant that developers had to engage in various practices to both accommodate physicians’ interests and advance the project further along in its implementation.

Our case study identified three such practices, which can be conceptualized as coproducing, bypassing, and reframing. Coproducing encompassed those developer activities that involved compromises in larger project objectives and the incorporation of physician concerns into the technology’s design. To move the implementation forward, many formal agreements and approvals were needed from various “user groups,” including the physician user group. When the impact on the medical user group was significant, considerable development time was spent on “taking the doctors along” (Interviewee 2), including presenting, discussing, adjusting, and incorporating the version of the features into the final portal design that was workable for physicians. An example of such coproducing efforts was the feature that made lab results available for patient viewing. Instead of making the lab results transparent immediately, as the project goal would require, developers made a concession: the results would be made available 21 days after they become known (see Appendix 1). Reaching agreement on this feature took the developers 6 months of discussions with physicians, a process one developer referred to as playing “ping pong until you have a yes or a no” (Interview 1, Developer), demonstrating how significant resources are spent on what is technically a simple feature to implement.

Another practice is bypassing, in which developers proceeded more directly, and the design choices were guided mostly by their frames on the portal’s purpose. Bypassing was possible in cases where they estimated that the impact on the medical work was not significant enough to warrant objections or in cases where they felt the implementation was justified by the vision behind the project’s funding. For example, one developer explained the reasoning behind a feature enabling patients to download their medical files:

What is also nice about the file is the health summary. Your total overview: overview per contacts, what is registered, and you can take [it] with you on holiday on your USB [storage]. Because it is such a specific change for the patient, it does not affect the outpatient clinic. We do not visit the user groups. We only visit the group where it can have the most impact. (Interviewee 8, Developer).

Finally, reframing involved the developers’ active attempts to convince physicians to change certain ways they thought about the portal, finding ways to highlight its benefits, and appealing to the value it can bring to physicians’ professional lives. As one developer explained:

If we think there will be a lot of discussion, then we try to show doctors the benefits of what it will bring to them rather than what it will bring to the patient. We write memos, try to think for ourselves what the added value is for them. We just want to go on and on and on with the implementation, and we feel we are often held back. So, we are trying to make sure it is well formulated [so] that they see the added value of [it]. We try to convince them by saying: “With this change, you will have to spend less time, which will leave you with more time,” trying to make a promotional sentence out of this. If we give them more freedom of choice, we notice that it is easier for them to accept the features than if we had put it down as a “done deal” already. “We are going to do it, and you have these choices” is better than “We are going to do this, and you just have to agree.” In this way, we try to involve the doctors more in this [process]. (Interviewee 2, Developer)

Importantly, the developers, while engaging in the practices outlined above, also acknowledged that they lacked a systematic approach for enacting those practices; they were not doing as much as they felt they could or should be doing due to a lack of resources, and they regretted not progressing quickly enough in implementation.

Discussion

This case study has shown that developers and physicians differ in their views on how the portal can help achieve transparency, efficiency, and how it can empower patients. This misalignment emerges because each group makes sense of the portal through a different frame of how they see patient data, medical work, or patient behavior. The findings also revealed that the differences are not set in stone but can be actively addressed when developers engage in practices of coproducing, bypassing, and reframing. Thereby, the developers can exert a consequential influence on which features will be made available on the portal and how quickly, the likelihood of buy-in from care providers, and whether and when the portal achieves its impact on care. Such findings suggest that developers, instead of being seen as mere technical executors or operational IT support, may need to be seen as a strategically important actor group for healthcare organizations—since their practices, ultimately, can enable the realization of the important strategic agenda of transforming healthcare into a more patient-centric practice.

In accounting for more than just physician perspectives, the findings complement the previous research on patient portals. As in previous studies, the physicians here raised similar apprehensions and concerns related to increasing workloads, ¹⁷ patient empowerment, ³⁰ and in having doubts about the meaningfulness of the information being transparent for patients. ⁴¹ This study extends the existing literature by bringing the heretofore missing voice of developers into the picture. Importing developers’ frames yields insights into previously unexamined rationales and arguments employed throughout portal implementation. It allows us to see that the physicians’ concerns and oppositional arguments may, in fact, be known to implementers, and give further insight into how they are considered, overturned, or mitigated. Uncovering the developers’ role in addressing already known physician concerns, therefore, helps us appreciate that the developer group is not blind to the objections raised by physicians, understand that certain arguments may still be discarded because of a larger institutional agenda, and learn more about what can be done to manage the implementation, even in the face of opposition.

This study also makes a contribution to existing research by specifying the practices—coproducing, bypassing, reframing—used by developers to manage frame misalignment. Interestingly, in the hospital being studied, the developers engaged in such practices but acknowledged the lack of a structured approach for them, characterizing their efforts as “organic,” “informal,” and “insufficient,” and lamenting that they lacked sufficient resources to have done more to involve stakeholders to a greater extent or to push implementation forward sooner. In this sense, the situation observed in the hospital resembled the achievement of a “workable system” as in the study of an e-government system that aspired to settle on at least some degree of desired functionality. ²⁵ Such findings imply that research and practitioner attention should be directed to the kinds of developer practices employed in other settings and to exploring combinations of practices that can be most effective for the strategic purposes of technology implementation for patient-centered care.

This study also has implications for research on patient empowerment. Previous studies have focused on clarifying the concept of patient empowerment from several perspectives: cognitive, behavioral, and that of digital literacy, among others.^40,42–44 Another body of research has evaluated whether, and if so, under what conditions, newly introduced health IT helps achieve patient empowerment ³⁵ and provided comprehensive frameworks for linking characteristics of empowerment to its consequences. ⁴³ This study’s contribution lies in going beyond the focus on patients, offering further insight into how various groups, such as developers and physicians, view empowerment differently. Knowing these differences can ultimately inform health IT design by redirecting developers’ attention away from a focus on technical features and their abstract mental model of the patient and toward a paradigm that also incorporates the situated, institutional, and multi-stakeholder aspects of empowerment.

Finally, this study has implications for broader information systems research of technological frames, as well as user-centered design. Much of the previous research has emphasized that the failure of IT projects can be traced to frame misalignment between developers and users, often explained as due to the frames of actor groups remaining implicit ³⁴ or to developers encountering user resistance or organizational inertia. ²⁸ This study, too, shows frame misalignment in underscoring why different aspects of efficiency, transparency, and empowerment are brought up by different groups. In contrast to previous research, however, the present study reveals that developers may, in fact, be fully aware of the technological frames of others, as when they recognize how the portal may be interpreted differently from the point of view of the physicians’ practice. However, the study questions the ideal of aligning frames, which has perhaps been too romanticized. Since the portal is not directed at a unified user group whose frames need to be appreciated but instead spans multiple practices and care processes (e.g., administrative and medical), differences may become harder to bridge. Therefore, for existing scholarship, our case implies that technological frame analysis may need to be updated to incorporate the growing complexity and institutional character of modern technology, the diversity of target groups it aims to serve, and their corresponding frames. One implication here is that developers, instead of attempting to bring frames into alignment, may need to continually perform a variety of brokering practices, balancing different interests, and making tough choices regarding which aspect of the frame to prioritize or bypass, based on whose approval counts more or is easier to obtain or where there is the least pronounced divergence of frames.

This study has certain limitations, of which perhaps the most important one is the bounded nature of what can be concluded about developer practices without observing them in situ. Future research is encouraged to adopt a more in-depth focus and employ an ethnographic approach to study what developers do, observing the different strategies employed by developers and richly describing how decisions are made as well as how interactions transpire, and with what consequences, in the course of their everyday work. Another limitation of this study lies in its inability to make direct conclusions about the specific influence exerted by developer activities on the success of implementation. Future studies could take the preliminary findings offered in this paper as the foundation for a more systematic assessment of the developer’s impact on care outcomes, more broadly. This study’s findings are also limited in that they rely on a single case study approach and thus, would need further validation to establish transferability to other contexts.

Practically, the insights from this case may benefit healthcare organizations by suggesting that they reconsider the role of the IT developers: instead of viewing them as serving a mere support function, developers could be regarded as a strategically significant actor in the fulfillment of the organizations’ mission. As this study has shown, many purposes of the patient portals encompass transformational goals regarding the practice of care, which endows developers with quite a major responsibility, going well beyond their former mandate in the past. As this case study also demonstrates, it is likely that developers lack sufficient resources to properly fulfill such a role. Thus, healthcare organizations may benefit from realizing that IT implementation can be a means of driving institutional change, and they may consider greater investment in the design of more structured approaches and methodologies, in so doing granting greater legitimacy and institutional support to such development efforts.