From FRAM Guidelines to Reality: Incorporating Stakeholder Variability in Work-as-Done in Healthcare

Abstract

Background: The Functional Resonance Analysis Method (FRAM) analyses discrepancies between written protocols (Work-as-Imagined) and real-world practice (Work-as-Done) in healthcare. Work-as-Done is created based on multiple stakeholders, leading to variability in reported functions. No guidance exists how to manage this variability. This study examines between-stakeholder variation in Work-as-Done and its impact on differences from Work-as-Imagined in FRAM visualisations. Methods: Two FRAM studies were analysed: delirium diagnosis and treatment (1) and perioperative anticoagulant management in two hospitals (2). Heatmaps visualised between-stakeholder variability of reported functions in Work-as-Done. We assessed the impact of including only functions shared by multiple stakeholders on Work-as-Imagined versus Work-as-Done comparisons. Results: In study 1, 23 of 33 functions were shared among at least two stakeholders. In study 2, stakeholders shared 30 of 33 functions in Hospital 1 and 29 of 32 functions in Hospital 2. Including or excluding functions, e.g., only mentioned by one stakeholder, influenced the observed differences between Work-as-Imagined and Work-as-Done. Conclusions: Between-stakeholder variability in both studies influenced differences between Work-as-Imagined and Work-as-Done, which often is the starting point improving the process. Showing between-stakeholder variability in FRAM studies enhances transparency in researcher decision-making. This supports more informed analysis and discussion in process improvement efforts.

1. Introduction

The Functional Resonance Analysis Method (FRAM) is increasingly used in healthcare. The FRAM can be used as a method for both incident analysis and for providing a visual overview of a working process [1,2,3]. Using this method, researchers can divide the steps of a process into so-called functions to analyse how they interact and who is responsible for those functions. To understand or improve a working process, the FRAM is often used to gain insight into how a written process (Work-as-Imagined) compares to daily practice (Work-as-Done) [1,4,5]. Clinical guidelines are often interpreted as how work is supposed to be conducted (Work-as-Imagined), whereas Work-as-Done refers to the system in practice, in which variable demands may require adaptations by professionals in every-day work. This way of using the FRAM is an emergent approach in healthcare. For example, Work-as-Imagined and Work-as-Done were compared for anticoagulant management in the pre-operative trajectory [6], elastic compression stocking therapy [7], restraint use in neurological and neurosurgical patients [8], the discharge process for older people with complex care needs [9], medical device management [10], and nurse-led Critical Care Outreach Service [11].

For Work-as-Imagined, protocols or guidelines are mostly analysed using document analysis, e.g., [4,8,9,12,13]. For Work-as-Done, in most cases, data is collected from involved stakeholders, through semi-structured interviews [1,14], but focus groups or observations are also used [1,4,14]. Additionally, a combination of these data collection methods is common practice [15]. Where Work-as-Imagined can usually be captured by a few specific protocols or guidelines, Work-as-Done is far more heterogeneous due to multiple involved stakeholders and multiple data sources [1,5,16]. For example, a surgeon and a nurse could have different perspectives on a specific process due to their roles, resulting in different versions of Work-as-Done. Some functions in Work-as-Done may thus be mentioned by multiple stakeholders but others by only one. However, this heterogeneity in Work-as-Done is not explicitly taken into account in FRAM analyses.

This heterogeneity can affect multiple decisions in a FRAM analysis based on the collected data [15]. Variability in reported functions of Work-as-Done may influence the decision to conclude that there are differences between Work-as-Imagined and Work-as-Done. Some functions mentioned in the Work-as-Imagined may be mentioned by only one stakeholder. Should that function then be added to the Work-as-Done so that it is a cumulative representation for all stakeholders? Or should there be a distinction between functions that are shared across stakeholders and those that are rarely mentioned? In this example, including the function mentioned by a single stakeholder would mean that no difference between Work-as-Imagined and Work-as-Done is identified, whereas it would create a difference if researchers would decide to only include functions mentioned by multiple stakeholders. Awareness of differences between stakeholders could lead to useful conversation about the process, since currently not all stakeholders seem aware of the specific function, or perform workarounds [17]. This shared awareness could also contribute to a shared mental model in healthcare professionals, in which all involved stakeholders are on the same page regarding the understanding of a process [18,19]. Currently, Work-as-Done typically represents a combined perspective of all stakeholders, which may obscure critical bottlenecks or opportunities for process improvement. FRAM research lacks clear guidance or best practices on how to effectively visualise and incorporate the variability and heterogeneity within Work-as-Done data, and the impact of decisions regarding such between-stakeholder differences have not been studied.

The objective of this study, therefore, is to analyse and visualise the extent of between-stakeholder variation in Work-as-Done using heatmaps and show how this might impact identified differences between Work-as-Imagined and Work-as-Done.

2. Materials and Methods

2.1. Components of FRAM Visualisations

FRAM visualisations consist of several functions that interact with other functions through couplings. These couplings are input, output, precondition, time, control, and resource. Couplings show how functions link together in the process. The functions in FRAM can either be foreground or background functions. Foreground functions, shown as hexagons, are activated by a function and provide output that leads to another function. Background functions, portrayed as circles, are the more supporting functions of the foreground functions often providing resources, controls or other conditions.

2.2. Design

The data from two FRAM case studies in healthcare were analysed. Case study 1 researched diagnosis and treatment for delirium in a neurological and neurosurgery ward in a Dutch hospital. Delirium management was selected given the perceived difficulty to diagnose delirium and frequent occurrence in the wards, which has also been emphasised in previous research, e.g., [20]. Case study 2 researched anticoagulant medication management in the perioperative trajectory in the vascular surgery departments of two Dutch hospitals. This was selected given the frequent occurrence of medication errors with anticoagulant medication [21].

Document analysis was used to create the Work-as-Imagined, using one local protocol (case study 1) or one local and one national protocol (case study 2). Semi-structured interviews were used in both case studies to create Work-as-Done, with case study 1 also using observations.

2.3. Ethical Approval

For case study 1, ethical approval was granted by the Ethics Committee of Psychology at Leiden University (CEP19-1219/588). For case study 2, ethical approval was granted by Delft University of Technology (application number 3265). Informed consent of all participants was obtained for both studies.

2.4. Participants

For case study 1, the hospital staff present at the wards were observed, and therefore the sample varied per shift. An invitation was sent by a senior nursing manager to all department staff for the interviews. Due to the COVID-19 pandemic, the total number of interviews was reduced since multiple professionals from the department were moved to other departments to care for infected patients. A total of six healthcare professionals responded and were interviewed to create the Work-as-Done; see

Table 1. Participants in both case studies.

Case Study 1		Case Study 2
Roles	Participants	Roles	Participants
			H1	H2
Nurse	3	Surgeon	2	2
Physician	2	Anaesthetist	2	2
Manager	1	Planner	1	1
		Nurse	1	1
		Recovery nurse	1	1
		Ward physician	1	1
Total	6		8	8

.

For case study 2, purposive sampling was used to include all healthcare professionals involved in the perioperative trajectory in each hospital. If new roles were identified throughout the interviews, they could be added to the interview sample provided these related to foreground functions. A total of 8 healthcare professionals per hospital were interviewed to create the Work-as-Done (Table 1). The ward physician was identified as a new role during the interviews and thus added as a participant. Even though the pharmacist was also identified as a new role, an interview was not conducted since this role concerned a background function in the Work-as-Done (i.e., providing medication verification as a control function during the preoperative screening).

2.5. Data Collection

2.5.1. Case Study 1: Delirium Management

Researchers observed twelve shifts (morning, afternoon, and night) in pairs and took field notes individually (NL, DvD, SH, MB), to gain a thorough overview of Work-as-Done. They followed healthcare professionals during patient visits, medication delivery, multidisciplinary team meetings, and general activities throughout the day. If healthcare professionals were not providing acute care, researchers asked professionals clarifying questions. Field notes were cross-validated approximately every hour.

Semi-structured interviews were held online by one researcher (NL), and another researcher was present to transcribe (DvD, SH, MB). Each interview took approximately an hour to complete, and they were conducted iteratively (Appendix A). Specifically, the first interview started with a series of general questions based on steps defined in the local protocol. For subsequent interviews, more in-depth questions were added informed by the answers of earlier interviews. Based on the answers of the participants, more specific and detailed follow-up questions were added. For instance, when mentioning a step, questions were asked about who performed the function, when it was performed, or whether there were other actions required for this step to succeed.

2.5.2. Case Study 2: Anticoagulant Medication in the Peri-Operative Process

Twelve steps were identified in the Work-as-Imagined of perioperative anticoagulants. To ensure sufficient detail of the functions within the steps and keep the time necessary for the interviews within an hour, the research team decided to focus on four of these twelve steps for Work-as-Done. All interviews had the same semi-structured interview format (Appendix A). The interviews were held online and took approximately an hour to complete, in which one researcher asked the questions (NL), and one researcher was present to ask clarifying questions if required (EdG). These interviews were recorded and transcribed.

2.6. FRAM Visualisations

FRAM visualisations for case study 1 were created in the Fram Model Visualiser [22] and for case study 2 using Figma [23]. For Work-as-Imagined in both case studies, specific steps in the protocol were identified through document analysis, which were translated into functions. Based on how a step was described, we determined the interaction between the functions and who should perform the function according to the protocol. This information was visualised in the Work-as-Imagined FRAM. Roles were indicated by different colours in the functions. In case study 1, this visualisation was then validated in a meeting with the senior nursing manager, resulting in small corrections. In case study 2, the Work-as-Imagined visualisation was validated in an online meeting with, for each hospital, a physician with detailed knowledge of the department protocols. This meeting led to small corrections to the Work-as-Imagined related to textual differences between local and national guidelines in the hospital.

For Work-as-Done, interview transcripts were analysed to identify functions and connected couplings. Coding of the interview data for both case studies was performed by two independent researchers, after which consensus was reached. For each participant, an individual FRAM visualisation was created, and colours were used to indicate roles within functions. The Work-as-Imagined visualisation was used as a template to identify mentioned and unmentioned functions. Mentioned functions outside the protocol were added. A final Work-as-Done visualisation was created, which integrated all individual visualisations. The field notes were cross-checked against this final Work-as-Done visualisation to check whether it represented the observations. Cross-checking the field notes with the Work-as-Done visualisation did not identify any new functions.

The steps within delirium management were indicated within the hexagons (e.g., “Step 1. To diagnose delirium”). The final Work-as-Done for case study 1 was validated in a meeting with a healthcare professional who specialised in using the FRAM. Work-as-Done visualisations were validated in an online session with a (different) physician who worked within the process. Study 2 included focus groups with interviewees and staff from the perioperative process to validate both Work-as-Imagined and Work-as-Done and explore their differences.

2.7. Outcome Measures

The outcome measures in this study are the between-stakeholder variability in Work-as-Done and the impact of only including functions mentioned by multiple stakeholders on identified differences between Work-as-Imagined and Work-as-Done.

2.8. Analyses

Between-stakeholder variability of the Work-as-Done was operationalised by counting the number of times a function was mentioned across interviewees. This heterogeneity was visualised by colouring the functions depending on how often they were mentioned, creating a gradient. The more frequent a function was mentioned, the darker it was coloured, which resulted in a heatmap of Work-as-Done.

Based on the sample size of both case studies, we chose to exclude functions mentioned by only one stakeholder to assess how this would impact identified differences between Work-as-Imagined and Work-as-Done. These excluded functions (mentioned by only one stakeholder) in the Work-as-Done were shown in a table and compared to Work-as-Imagined.

3. Results

The final Work-as-Imagined and Work-as-Done visualisations of case studies 1 and 2 are shown in Appendix B and Appendix C, respectively.

3.1. Case Study 1: Delirium Management

3.1.1. Between-Stakeholder Variability in Work-as-Done

For case study 1, a total of 33 functions were identified in the Work-as-Done, 20 foreground functions and 13 background functions (Figure 1A). Across six interviews, three functions were mentioned by all stakeholders and were shown in the darkest colour. Specifically, these functions were “to develop delirium”, “to diagnose delirium” and “to fill in DOSS score”. Most functions were either mentioned by one (10, 30%) or two stakeholders (10, 30%) (Figure 1B).

Looking at the average and standard deviation of how often a function is mentioned gives information about whether there is consensus from stakeholders about a function. Each function, on average, was mentioned 2.5 times (SD = 1.5). There is little difference between how often foreground functions were mentioned on average (M = 2.6, SD = 1.5) and how often background functions were mentioned (M = 2.5, SD = 1.5). Some parts of the process are mentioned more often than others. Specifically, functions that were mentioned less concerned aspects about physical restraints (e.g., “to put patient in tent bed” or “to physically restrain patient”; M = 1.8, SD = 0.7), aspects on reducing and stopping medications (e.g., “to reduce dose of medication”, M = 1, SD = 0), and functions related to step 5 (M = 1.7, SD = 0.6).

If only functions mentioned by multiple stakeholders were included (excluding those in yellow in Figure 1A), Work-as-Done would have 23 functions (14 foreground, 9 background), reducing the total of 33 by 10 functions (−30%). The excluded functions are related to reducing medication and informing family but also consulting geriatrics, discussing between nurses and residents about physical restraints and reporting to the GP after treatment.

3.1.2. Impact on Differences Between Work-as-Imagined and Work-as-Done

Table 2. Overview of the functions mentioned by one stakeholder in Work-as-Done, compared to Work-as-Imagined in case study 1.

Work-as-Done		Work-as-Imagined
Function	Role	Function	Role	Match
To consult elderly healthcare	Nurse	-	-	-
To discuss with resident about physical restraints	Resident/ Nurse	-	-	-
To give folder to family	Nurse	To give patient information brochure	Nurse	Partial *
To inform family	Resident	-	-	-
To look at other possible factors	Resident	-	-	-
To reduce dose of medication	Resident	To reduce dose of medication	Resident	Yes
To perform weekly medicinal check	Resident	-	-	-
To increase dosage of medication	Resident	-	-	-
To decide to stop DOS scores	Resident	-	-	-
To report to GP	Resident	To transfer care to other healthcare institute	Resident	Partial

*: To give a folder to the family is seen as a partial match because the nurses described that the folders never were present during their shift. Management staff described that the folder was always given to patients. Therefore, this function was added to the Work-as-Done visualisation with an asterisk. In addition, “To report to GP” was described in a broader statement in Work-as-Imagined (i.e., “To transfer care to other healthcare institute”).

compares the 10 functions mentioned by only one stakeholder to Work-as-Imagined, showing whether they match in description and assigned role. Only 3 of these 10 functions also appear in the Work-as-Imagined (with 2 matching partially), while 7 functions appear only in the Work-as-Done. Excluding the functions mentioned by one stakeholder would thus lead to fewer differences between Work-as-Imagined and Work-as-Done.

3.2. Case Study 2: Anticoagulants in the Perioperative Process

3.2.1. Between-Stakeholder Variability in Work-as-Done

For Hospital 1, a total of 33 functions were identified in Work-as-Done, 14 foreground functions and 19 background functions. The heatmap of the Work-as-Done shows that most functions are mentioned across multiple interviews (Figure 2A). A starting function (i.e., “To experience problems that might indicate need for surgery”) was added by the researchers to indicate where the process began and is coloured grey but does not count as a function for the results. The most frequently reported functions were mentioned seven times in eight interviews, i.e., “to submit surgery order” and “to report to patient file” in the outpatient clinic. Most functions were mentioned by two stakeholders (nine functions, 26%; see Figure 2B). Only background functions were mentioned once (3, 9%), and all foreground functions were mentioned at least twice across interviews.

Across all functions, the average function was mentioned 3.8 times (SD = 1.8) with little difference between foreground functions (M = 3.7, SD = 1.8) and background functions (M = 3.8, SD = 1.8). The functions in some steps in the process were mentioned more often than others. The 11 functions in the outpatient clinic (step 1) were on average mentioned 4.4 times (SD = 2.0), the 9 functions of the preoperative screening (step 2) were mentioned 3.1 times (SD = 1.6), the 6 functions of planning (step 3) were mentioned 3.3 times (SD = 2.3), and the 7 functions in patient admission (step 4) were mentioned on average 4 times (SD = 1.4). This shows that functions in the outpatient clinic were mentioned most but that there was most variation in how often functions were mentioned in the planning.

Only including functions mentioned by multiple stakeholders resulted in 30 (rather than 33) functions for the Work-as-Done, of which 14 were foreground functions and 16 were background functions. Excluded functions relate to step 2 “assessment of risk” during the preoperative screening and step 3 “To check if patient has had POS” and “to start bridging” by the patient.

In Hospital 2, a total of 32 functions were identified in Work-as-Done (Figure 3), 14 foreground functions and 18 background functions. One start and one ending function in grey were not counted in the analysis. In eight interviews, the most frequently reported functions were mentioned six times (i.e., “To see patient in outpatient clinic” and “to verify all preoperative decisions”). Altogether, most functions were mentioned by two stakeholders (9, 28%).

On average, a function was mentioned 3.2 times (SD = 1.4). Foreground functions were on average mentioned 3.6 times (SD = 1.4), and background functions were mentioned 2.9 times (SD = 1.2). There were some differences between how often functions within the steps of the process were mentioned. The 11 functions in step 1 (outpatient clinic) were mentioned 3.1 times on average (SD = 1.4), the 9 functions in step 2 (the preoperative screening) were mentioned 2.4 times (SD = 1.3), the 7 functions in step 3 (planning) were mentioned 2.1 times on average (SD = 0.9), and the 6 functions in step 4 (patient admission) were mentioned on average 4.7 times (SD = 1). This shows that the functions in the planning were mentioned least in the interviews but that there was the most variation (highest SD) in the number of mentioned functions in the outpatient clinic.

Only including functions that were mentioned by multiple stakeholders, the Work-as-Done visualisation showed 29 (rather than 32) functions, with 13 foreground functions and 16 background functions. The excluded functions were placed in step 1, “To reach consent”, and step 2, “to decide pros cons & optional adjustments” and “to decide about anticoagulants and bridging”.

3.2.2. Impact on Differences Between Work-as-Imagined and Work-as-Done

Table 3. Overview of the functions mentioned by one stakeholder in Work-as-Done, compared to Work-as-Imagined in case study 2.

Hospital	Work-as-Done		Work-as-Imagined
	Function	Role	Function	Role	Match
Hospital 1	To assess risk (risk classification)	Anaesthetist	To assess risk (risk classification)	Anaesthetist/ Surgeon	Partial
	To check if patient had POS	Planner	-	-	-
	To start bridging	Patient	To start bridging	Patient	Yes
Hospital 2	To reach informed consent	Surgeon/Patient	-	-	-
	To discuss pros, cons, and optional adjustments	Anaesthetist/Patient	To discuss pros, cons, and optional adjustments	Anaesthetist/ Patient	Yes
	To decide about anticoagulant and bridging	Anaesthetist	-	-	-

shows how the excluded functions for both Hospital 1 and Hospital 2 compare to the Work-as-Imagined. In Hospital 1, only one function matches and one partially matches; thus, removing all three functions would increase differences between Work-as-Imagined and Work-as-Done. In Hospital 2, only one function matches to Work-as-Imagined; thus, removing these three functions would reduce differences.

4. Discussion

This study demonstrates a method to visualise between-stakeholder variability using heatmaps in FRAM visualisations. Through two case studies, we observed significant variability between stakeholders that differed per case. In the delirium case (1), stakeholder variability was greater than in the anticoagulant management case (2). Removing functions mentioned by only one stakeholder affected the detectable differences between Work-as-Imagined and Work-as-Done. In case study 1, removing these functions reduced the differences between Work-as-Imagined and Work-as-Done. In case study 2, the impact varied; in H1, differences increased, whereas in H2, differences decreased. These findings highlight the importance of understanding between-stakeholder variability and more explicitly incorporating it into decision-making when analysing differences between Work-as-Imagined and Work-as-Done as a starting point for improvement.

Including between-stakeholder variability can be valuable in conversations with healthcare professionals, for instance, while validating the FRAM visualisations, which is already common practice [15]. During validation sessions, heatmaps can be used to discuss functions containing between-stakeholder variability. This can provide insight as to why this variability occurs; is it a workaround, do stakeholders not know it should be done, or are there other reasons why stakeholders (did not) mention a specific function? Asking such questions can contribute to a shared understanding of the working process and its roles, also known as shared mental models or team mental models. Such shared mental models have been found to increase team performance and have been researched extensively in healthcare and other domains [18,19,24]. In addition, including stakeholders in this process can further engage them, which is especially important when new parts of a process are adopted or implemented [25]. Furthermore, including stakeholders can improve role clarity, which can increase interprofessional teamwork [26].

In the literature, Work-as-Done visualisations are typically presented as a final version without explicitly stating whether they include all reported functions or represent a shared visualisation among stakeholders. Additionally, agreement metrics, such as interrater reliability, are rarely documented. In practice, professionals in different roles often have varying perspectives on a process, as demonstrated in our case studies. Using heatmaps as a visual tool can serve as a semi-qualitative indicator on the degree of agreement between stakeholders in FRAM studies, offering valuable insights into stakeholder variability. By making the data used for FRAM visualisations more transparent, this approach can enhance the starting point for improvement projects and provide greater clarity on the data sources and decision-making process behind final Work-as-Done representations.

4.1. Strengths and Limitations

A strength of this study is the use of two different case studies to show between-stakeholder variability and how this affected identified differences between Work-as-Imagined and Work-as-Done in different ways. This suggests that the inclusion of analysing between-stakeholder variability can provide valuable information for FRAM studies. Another strength is that this study extends the FRAM methodology by adding between-stakeholder variability to the visualisation. Adding this to general practice of using FRAM could lead to better generalisability and transparency within FRAM research since this shows the data on which FRAM visualisations are based and the decisions made by researchers.

A limitation is that the iterative interviews used in case study 1 influenced the density of the heatmaps because not all interviewees were asked the same questions and therefore did not have equal opportunity to provide an answer and mention a function. Multiple questions about parts of the process were added in later interviews, which could skew the insights of the heatmap. This could also partially explain the larger between-stakeholder variability of mentioned functions in case study 1, compared with case study 2.

4.2. Practical Implications and Future Research

Based on insights from the heatmaps, different decisions could be made regarding including or excluding functions; see

Table 4. Practical implications of between-stakeholder variability.

Scenario	Advantages	Disadvantages
Include all identified functions	Representation of all information	Might include perspectives that are not representative of most stakeholders
Include functions shared by multiple stakeholders and those that relate to their own work	Assumptions about the roles of other stakeholders are excluded Maintenance of detailed role-specific steps	Limits the opportunity to discuss role-based assumptions and shared learning
Exclude functions mentioned by only one stakeholder, regardless of role	Systematic approach Ensures functions are represented by multiple stakeholders	Relevant bottlenecks, workarounds, or functions important for safety could be missed

. The first scenario, which is likely common in FRAM research, includes all reported functions to create Work-as-Done. This approach ensures that all collected information from interviews is represented. However, it may also lead to the inclusion of workarounds reported by a single stakeholder, which might not reflect a shared perspective. For example, in case study 2 (second hospital), two conflicting actions were identified in the preoperative screening process; in one case, the surgeon determined the anticoagulant policy; in another, the anaesthetist made the decision. Further validation revealed that the anaesthetist only made this decision when the surgeon had not addressed anticoagulant management during the inpatient clinic. This indicated that the anaesthetist’s role was a consequence of an unaddressed task, rather than a defined responsibility in the workflow. This example highlights the importance of discussing Work-as-Done findings with stakeholders, identifying between-stakeholder variations, and clarifying potential conflicts to improve process accuracy and understanding.

A second scenario would be to only include functions shared by multiple stakeholders and those that relate to their own work. An advantage would be that assumptions about the role of others can be filtered out of Work-as-Done. For instance, in case study 1, the managing nurse assumed that all nurses would give brochures to the family, but in reality, these brochures were out of stock, which made this impossible to do. This highlights how assumed practices may not align with the actual Work-as-Done. Another advantage is maintaining detailed role-specific steps. For example, in Hospital 1 of case study 2, a planner mentioned checking whether a patient had completed preoperative screening. This step influenced the information included in the patient’s pre-surgery letter, showing the direct impact of a single role on later stages of the process. The disadvantage of this scenario is limited opportunities to address role-based assumptions. By excluding stakeholder assumptions, this approach misses the chance to clarify misconceptions about responsibilities. Such discussions could improve across-stakeholder understanding and foster better collaboration in the process. This scenario offers a more refined representation of Work-as-Done, but at the cost of reducing opportunities for shared learning and process improvement.

A final scenario would be to exclude functions that were mentioned only once, regardless of which stakeholder mentioned it. This could be beneficial since this is a systematic process, in which there is certainty that at least two stakeholders share the perspective of functions in the process. However, workarounds performed or bottlenecks experienced by healthcare professionals might not be identified when these functions are excluded in advance, or these functions could be important for the safety of patients.

Therefore, there does not seem to be a one-size-fits-all solution. These three scenarios all have benefits and disadvantages, and what solution fits best could be case-dependent. This decision remains up to the researchers, just as multiple decisions are made throughout FRAM studies. It is important that these decisions are clearly described and motivated. In this study, we used one stakeholder mentioning a function as a cut-off point for possible exclusion since this was considered realistic for the sample size of the case studies. Until further research is available on cut-off points, it is up to the researcher to decide and report what fits best with their sample.

5. Conclusions

Visualising variability between stakeholders provides a comprehensive insight into different perspectives on Work-as-Done and highlights the extent to which those perspectives are shared. Discussing these findings with stakeholders can help develop a shared mental model, enhance role clarity, and strengthen interprofessional collaboration. The use of heatmaps in FRAM studies can support researchers in determining which Work-as-Done perspectives should be included and the impact on identified differences between Work-as-Done and Work-as-Imagined, thereby helping to identify steps in a process that may require improvement.