For this study, we used the design science framework [23] to guide the development of requirements and use cases for eHealth solutions for FACT teams. This framework was chosen as it aligns with our goal of creating user-centered eHealth solutions that are well adjusted to teamwork. It supports a structured approach and emphasizes an iterative process in artifact development. Design science consists of a set of iterative steps: (1) explicate the problem, (2) define requirements, (3) design and develop an artifact, (4) demonstrate the artifact, (5) evaluate the artifact, and (6) communicate artifact knowledge [23]. We focused on the initial 3 steps of this framework to inform the development of eHealth solutions that support teamwork in health care settings.

In the first step of the design science framework, we defined the problem that the eHealth solutions aim to address. We defined the problem precisely to make it clearer and easier to communicate; positioned the problem in a context; and justified the identified problem to demonstrate its significance, relevance, solvability, and level of challenge. The explication also included an analysis of its root causes, which provides additional context, ensuring focus on the causes of the problem rather than its symptoms. Unless otherwise specified, analytical steps were conducted collaboratively, with the first author leading the analysis and the coauthors contributing through iterative discussion and review.

To define the problem precisely, we built on the results of a previous thematic analysis of observations and interviews in both urban and rural FACT teams [9]. In that study, initial themes were defined and coded. During review, subthemes were added to differentiate distinct aspects of the data. In this study, these themes and subthemes formed the foundation for problem definition. The narratives underlying each theme and subtheme were analyzed in light of the existing eHealth infrastructure and regulations governing eHealth in Norway [19].

The initial identification of problem situations was conducted by the first author, who reviewed each theme and its associated coded extracts to identify instances where current digital tools hindered teamwork, coordination, or patient care. These preliminary interpretations were then presented to the coauthors, who provided methodological and domain-related feedback. Through iterative discussion in project meetings, the problem descriptions were refined as necessary. This process ensured analytic rigor by combining the detailed perspective of the primary analyst with validation from experienced researchers.

The resulting set of problem descriptions was subsequently grouped into broader categories representing the general shortcomings of current eHealth solutions. Table 1 provides an overview of the themes and subthemes applied in this study, and full details of their derivation have been reported previously [9].

Although no patient data were used in this study, ethical considerations regarding patient privacy and data security were considered when analyzing FACT team needs and designing requirements. Ensuring that eHealth solutions enable data sharing while protecting sensitive health information informed the extraction of problem descriptions and requirements.

To position the problem, we performed a document analysis [25] of 2 central sources: the FACT model description [5] and a national evaluation report of FACT teams [26]. The analysis followed a structured process of identifying, selecting, appraising, and synthesizing information from these documents. The documents were first read superficially to gain an overview and then examined in depth to extract descriptions of the purpose of FACT teams, their core activities, their organizational structure, stakeholder involvement, and the environments in which they operate. This contextualization ensured that the problem definition was not limited to the technical shortcomings of eHealth solutions but was situated in the organizational and operational realities of FACT teams, thereby informing the relevance and scope of the requirements.

Similar to the precise problem definition, the justification of the problem was based on an analysis of the results of the thematic analysis reported previously [9]. In this step, we re-examined the themes in relation to their degree of solvability (ie, whether they could realistically be addressed by digital interventions) and level of challenge (ie, the practical and organizational difficulties involved). This evaluation was informed by our knowledge of the Norwegian eHealth infrastructure and regulatory environment [19]. The purpose of this step was to assess whether the problems were significant for FACT teams and whether they represented broader structural issues in Norwegian health care.

To analyze the root causes of the problem, we used the “five whys technique” defined by Serrat [27], by starting with the basic problem and then repeatedly asking the question why until we reached explanations that pointed to the root causes of the problem. At each stage, the answers were informed by contextual knowledge of the Norwegian eHealth infrastructure and regulatory environment [19], ensuring that the reasoning remained realistic and grounded. This systematic approach helped distinguish surface-level symptoms from structural issues, guiding us toward a technical framing of the root problem that directly informed the design of potential solutions.

Together, the positioning, justification, and root-cause analyses established a structured understanding of the problem. These steps provided the conceptual and contextual foundations for the subsequent design work. By systematically connecting prior findings, contextual documents, and infrastructure knowledge, this phase ensured that the later definition of requirements and design of artifacts were grounded in the realities of Norwegian health care.

Following the second step of the design science framework, we outlined an artifact that solves the explicated problem and defined requirements for the artifact. To outline the artifact, we chose the type of artifact that should be designed to solve the problem and briefly described the main functionality. To define requirements for the eHealth solutions, the first author created a table in Microsoft Excel in which each element of the problem description was entered as a separate row. For each row, the corresponding narratives from the thematic analysis were reviewed to identify the underlying user needs, workflow challenges, and contextual constraints. This table served as the analytical structure for translating empirical insights into requirements and was iteratively discussed and refined in project meetings with the coauthors.

Some requirements were derived directly from clearly stated needs within the themes, while others required further interpretation and design reasoning, where the themes pointed to broader challenges that implied more complex system functionality. For the electronic whiteboard, we additionally examined existing solutions to understand what information is typically displayed and how it supports coordination. Each requirement is linked to the corresponding element of the problem explication, ensuring transparency and traceability in how empirical insights informed the requirements. The requirements are presented at different levels of abstraction, with the electronic whiteboard receiving the most detailed specification due to its critical role in improving coordination in FACT teams. We defined functional requirements, describing what each eHealth solution can accomplish, as well as nonfunctional requirements, which apply across all the eHealth solutions.

Finally, 2 field experts with extensive experience supporting FACT teams reviewed the requirements for the electronic whiteboard. The review process involved providing written feedback on the draft requirements, followed by a meeting to clarify and discuss the comments. The experts evaluated the clarity, feasibility, and relevance of the proposed requirements. Their input was instrumental in refining the requirements, particularly by ensuring that the functionality aligned with real-world team workflows and that the terminology accurately reflected clinical practice.

The third step of the design science framework involves designing an artifact according to the requirements and the explicated problems [23]. In this paper, we present use cases and use case diagrams for an eHealth solution and justify the design proposals.

To generate ideas for the design of the eHealth solution, all 3 authors participated in a structured, guided brainstorming session. The session was conducted in person and facilitated by the first author, who prompted idea generation using the explicated problem, the defined requirements, and our shared knowledge of Norwegian eHealth infrastructure and regulations [19] as framing inputs.

During the session, ideas were presented, discussed, and clustered into emerging solution concepts. These concepts were then reviewed and refined based on their anticipated feasibility and usefulness in the Norwegian context (eg, alignment with existing infrastructure, compliance with regulations, and integration potential). The first author took notes throughout, capturing both the proposed ideas and the reasoning behind them.

After the session, the first author drafted the design rationale for the major design decisions, which was subsequently reviewed by the coauthors to ensure accuracy and shared agreement. Building on the selected ideas and the requirements, we developed use cases that describe the actors, goals, and interaction flows of each proposed eHealth solution. The first author also used a Unified Modeling Language (UML) 2.0 diagram [24] to visualize system functionality and relationships.

The project received approval from the Data Protection Official at Innlandet Hospital Trust (reference: 137877) and was reviewed by the Regional Ethical Committee, which deemed the project outside of their mandate (reference: REK Sør-Øst 104537). All participants provided signed informed consent. No patient data were gathered. The data were stored securely and deidentified. No compensation was given to the participants.

In this section, we present the results obtained from the initial 3 steps of the design science framework. These reflect the explication of the problem to be addressed by the proposed eHealth solutions, the definition of requirements, and the creation of use cases that can guide the development of solutions.

Problem descriptions are presented in Table 2, along with the source of each part of the description. Themes and subthemes in the table refer to the data analysis presented previously [9].

The precisely defined problem should also be positioned in a larger context. This context is provided in Textbox 1, which presents the purpose, stakeholders, activities, and operational environments of the teams.

In the context of this paper, we define the various stakeholders as follows:

The activities of the FACT teams can be divided as follows:

The operational environments are as follows:

To justify the problem, we built on our thematic analysis reported previously [9]. The analysis showed that team members of Norwegian FACT teams have highlighted the significance of the challenges associated with current eHealth solutions, by stressing the practical difficulties experienced in health care delivery, and identified the need for integrated eHealth solutions that can effectively support the complex, multidisciplinary nature of their work [9]. Although the identified challenges are technically manageable, they are complicated by the eHealth infrastructure and regulations in Norway [19]. This complexity affects not only FACT teams but also other multidisciplinary teams in Norway, indicating a general interest in improving the coordination of Norwegian health care. Together, these findings show that the problem is significant and of general interest in health care.

The results of the five whys technique are presented in Table 3. We started with the following basic problem: “FACT team members have difficulty using their eHealth solutions optimally for providing efficient care.” The technique showed that the root cause is a lack of integration between the systems in different health care sectors.

In this section, we outline the artifacts that meet the explicated problem and define the functional and nonfunctional requirements for eHealth solutions for FACT teams.

To outline the artifacts we aim to design, we classify them as instantiations (systems that can be used within a practice) [23]. These include the following eHealth solutions: EHRs, electronic whiteboards, calendars, video conferencing solutions, and digital questionnaires. EHRs represent the central storage of patient data. Electronic whiteboards are used in daily meetings to coordinate treatment and care. Calendars are used for scheduling appointments and treatments, and they provide team members with an overview of both their own calendars and the team’s calendar. Video conferencing solutions allow for meetings and video consultations, and digital questionnaires can be used to gather various patient information. To ensure that the systems are integrated, we assume that an integration and access engine is in place, which routes messages between the systems and ensures that the information is in the correct format. The basic outline and structure of these eHealth solutions are illustrated in Figure 1.

The proposed requirements and use cases are based on several underlying assumptions. Technically, the design assumes that key systems, such as EHRs and scheduling tools, can communicate through standard APIs and that local IT infrastructure allows integration of new modules. Furthermore, we assume that the necessary hardware and infrastructure are in place. Legally, it is assumed that solutions will be implemented in compliance with data protection regulations, including the General Data Protection Regulation (GDPR), and that access to patient data will follow existing legal frameworks and institutional policies. These assumptions define the boundaries of the design and should be considered when evaluating its feasibility and applicability in practice.

Certain functional requirements apply across multiple eHealth solutions, including integration with EHR systems and between calendar and video consultation solutions. These shared requirements are described here, while solution-specific requirements are detailed in the following subsections.

In addition to the functional requirements, this study identified nonfunctional requirements that define the qualities that determine how well these systems operate in practice. Unless otherwise specified, these nonfunctional requirements apply to all eHealth solutions.

In this section, we present the rationales behind our design choices and use cases for the proposed design.

This study aimed to identify the requirements and use cases for eHealth solutions that support teamwork in fragmented health care settings, with a focus on FACT teams. The problem analysis showed that limited access to patient data and poor integration across existing systems hinder coordinated care. From these challenges, we derived a set of requirements emphasizing interoperability and modular design. The resulting use cases illustrate how electronic whiteboards, EHRs, calendars, video conferencing solutions, and digital questionnaires can support core FACT workflows.

Although developed in a Norwegian context, the challenges of fragmented infrastructure, lack of shared information spaces, and mobile work are widely recognized across health care settings [16-18,20], indicating that the proposed requirements may be generalizable to other interdisciplinary and integrated care models.

With emerging trends like integrated care and patient-centered care, it is vital to support teamwork in health care [1,2]. In this study, the analysis showed that current digital infrastructure does not adequately support the forms of collaboration that integrated and patient-centered care rely on. The identified requirements highlight that teamwork requires systems that enable continuous coordination across distributed actors and settings. These findings situate the need for technical integration within a broader, workflow-oriented perspective, in which the goal is to connect systems and to support the collaborative practices that define integrated and patient-centered care.

Efforts to address integration challenges in health care more broadly provide useful context for our work. Kinast et al [21] have defined a comprehensive set of requirements for data integration, encompassing data acquisition, processing, analysis, storage, and security. Their work focuses on the technical and data management layers of integration, thereby ensuring that information can be exchanged reliably and securely across systems. In contrast, this study addresses a higher level of abstraction, defining requirements and use cases that support team-level coordination and shared clinical workflows. The Valkyrie project offers another perspective by proposing a prototype ICT architecture centered on a virtual health record that provides cross-level access to patient data [22]. Such an infrastructure could enable the implementation of many of the requirements identified in this study, particularly those related to shared information spaces and cross-organizational coordination.

Our findings suggest that effective support for teamwork in FACT settings depends on an eHealth architecture that enables reliable interoperability across the diverse systems used in daily workflows. The proposed integration and access engine addresses this need by supporting both syntactic and semantic interoperability through established standards such as HL7 FHIR, SNOMED CT, and ICD (International Classification of Diseases). Because primary and specialist care in Norway rely on heterogeneous IT platforms, the requirements were formulated at a system-independent level to support interoperability across sector-specific infrastructure.

Key design decisions and their rationales are summarized in Table 4. Rather than embedding all functionality within the EHR, we chose a modular approach in which tools, such as electronic whiteboards and calendars, operate as separate systems but integrate through shared standards. This reflects the need for flexible, task-specific views that support daily coordination in FACT teams while still ensuring that essential information remains available within the core clinical record. Some functional overlap remains, for example, planned consultations appear in both the calendar and the EHR. However, this redundancy helps maintain continuity of documentation. While consistency between systems is critical, detailed mechanisms for synchronization, conflict resolution, and data ownership were beyond the scope of this study and would need to be addressed during subsequent technical design and implementation. Similarly, enabling video consultations to be initiated from either system supports the varied work practices of teams and preserves the EHR as a central workspace. Calendars retain integration with video conferencing systems to facilitate scheduling without constraining the modular architecture.

Beyond integration and system design, several of the identified requirements focus on the workflows of FACT teams, such as managing patient lists, conducting video consultations, and assigning digital questionnaires. These ensure that essential functionalities are in place before addressing nonfunctional requirements, such as accessibility across devices and patient inclusion.

A nonfunctional requirement is the availability of eHealth solutions on a range of devices. This is required since FACT team members often travel to meet their patients and therefore need access to eHealth solutions on mobile devices. For eHealth solutions that involve patients, it is important that the patients can access the solutions on their devices. While this study focused on the perspectives of health care professionals, the requirements for digital questionnaires and video consultations involve patient interaction. In practice, not all patients are able or willing to complete questionnaires independently, which highlights the need for flexible solutions that allow for assisted reporting when necessary. Similarly, the suitability of video consultations in psychiatric care varies across patients and situations, as discussed in previous research [9]. Their use in psychiatric care therefore requires clinical judgment, as limitations in assessing nonverbal cues and managing acute situations may pose safety risks.

Building on these requirements, we defined use cases for the eHealth solutions and illustrated the use cases in UML use case diagrams. These use cases were helpful in detailing the functionality of each solution and can serve as a foundation for communication with stakeholders and for guiding future development efforts.

A key strength of this study is its grounding in real-world clinical practice. The design science approach enabled us to build on empirical insights from prior observations and interviews of FACT teams, complemented by document analysis and contextual knowledge of the Norwegian eHealth infrastructure. By structuring the work through the iterative steps of problem explication, requirement definition, and design of use cases, the study adhered to core design science principles that emphasize problem-driven development closely linked to practice. This ensured that the proposed eHealth solutions were informed by the actual workflows, constraints, and coordination challenges experienced by FACT teams.

While the study provides a structured foundation for designing eHealth solutions for FACT teams, several limitations must be acknowledged. First, the requirements and use cases were derived through document analysis, thematic analysis of prior empirical material, and expert review, but were not validated through direct empirical testing with end users. This limits certainty about how well the proposed solutions align with real-world practices. Although grounding the work in existing evidence and expert input helped mitigate this limitation, future studies should include workshops, usability testing, and pilot implementations. Second, the design recommendations were developed within the context of the Norwegian eHealth infrastructure. As a result, adaptations may be necessary in countries with different infrastructure. However, challenges, such as fragmented systems and limited data access, are widely reported, suggesting that the underlying design principles may still be transferable. Third, the study focused primarily on the perspectives and needs of health care professionals. While patient-facing functionalities, like digital questionnaires and video consultations, were considered, direct patient involvement fell outside the present scope. This may have constrained the identification of needs related to usability, digital literacy, and patient experiences. Future work should therefore incorporate input from patients and caregivers. Fourth, the study did not consider financial or policy-level feasibility. Evaluating costs, sustainability, and prioritization will be important in future work to inform decisions about implementation at scale.

This study shows how current eHealth solutions influence teamwork and care coordination in FACT teams and how digital support can reduce fragmentation and improve information flow. The requirements and use cases developed here provide a foundation for designing solutions that align with real-world workflows and the needs of multidisciplinary teams.

Although grounded in the Norwegian context, the core design principles of interoperability, timely access to information, and support for distributed decision-making are relevant across health care settings. The findings therefore have implications for not only technical development but also policy, highlighting the importance of digital infrastructure that actively enables collaborative work.

More broadly, the study illustrates how workflow-oriented design can strengthen integrated and patient-centered care models that rely on effective teamwork. By focusing on how technology can support collaboration, the work offers insights applicable to multidisciplinary health care teams beyond FACT.