Method for managing requirements in healthcare projects using building information modelling

Abstract

Purpose

This paper proposes a method for managing client requirements with the use of Building Information Modelling (BIM). The development of healthcare projects demands a large amount of requirements information, in order to deal with a diversity of clients and frequents changes in healthcare services. The proposed method supports healthcare design by adopting a process-based approach for client requirements management, with the aim of improving value generation.

Design/methodology/approach

Design Science Research was the methodological approach adopted in this investigation. The main outcome of this study emerged from an empirical study carried out in a healthcare project in Brazil.

Findings

The proposed method involves three stages: (1) capturing and processing requirements; (2) product and requirements modelling, which involves the connection between requirements and the BIM 3-D model and (3) supporting design solution refinement, through the communication of requirements and the assessment of design in relation to updated client requirements information.

Originality/value

This study explores client requirements management from a process perspective, proposing activities and their interdependences and possible sources of data, including healthcare services information. The main theoretical contributions are related to the understanding of the nature and complexity of the information involved in client requirements management, and how this can be modelled.

Citation

Baldauf, J.P., Formoso, C.T. and Tzortzopoulos, P. (2021), "Method for managing requirements in healthcare projects using building information modelling", Engineering, Construction and Architectural Management, Vol. 28 No. 8, pp. 2090-2118. https://doi.org/10.1108/ECAM-12-2020-1040

1. Introduction

In highly complex and dynamic construction environments, such as healthcare projects, client requirements management can help improve value generation (Parsanezhad et al., 2016), one of the main goals of the Lean Philosophy. In fact, value generation is the result of a cycle in which requirements are captured and converted into a product or service delivered to clients (Koskela, 2000). In healthcare projects, this requires both capturing the needs of different stakeholders, and understanding the relationships of the built environment and healthcare services (Sengonzi et al., 2009; Hicks et al., 2015).

Requirements management research originated in the field of information systems and software engineering (Fiksel and Hayes-Roth, 1993). The literature on that topic provides some guidelines for devising information systems, including requirements management activities, such as eliciting, analyzing, specifying, verifying, validating and managing changes in requirements (Khan et al., 2013). In the construction context, products tend to be much more complex, and requirements management is understood as a systematic process that involves capturing and modelling requirements (Kamara et al., 2002; Kiviniemi, 2005; Yu and Shen, 2013; Pegoraro and Paula, 2017), as well as maintaining requirements that are explicit and up-to-date during the project life cycle and controlling whether the design solution and the final product fulfil those requirements (Koskela, 2000; Shen et al., 2004; Jallow et al., 2014; Pegoraro and Paula, 2017). Requirements modelling is part of the client requirements management process (Kiviniemi, 2005). The main purpose of this process is to facilitate visualization, traceability and the communication of requirements, as well as to structure design assessment (Baldauf et al., 2020).

This research adopts a broad definition of requirements, which express functions, attributes and characteristics that a product or service must perform, produce or supply in order to meet the project and client needs or objectives (Kamara et al., 2002; Dick, 2004). Therefore, requirements can be regarded as statements expressed at different levels of precision (Pfleeger et al., 1994; Atoum and Otoom, 2016), using distinct forms of representation (e.g. text, images, tables, numbers, etc. or a combination of these) (Seaman, 1999; Dick, 2004), originated from different sources, such as users, regulations, processes or operations (Kamara et al., 2002; Kim et al., 2015).

Managing client requirements is important in healthcare projects as: (1) there is a large number and a wide diversity of clients (e.g. patients, healthcare professionals, facilities managers, owners, investors) (Sengonzi et al., 2009; Hicks et al., 2015); (2) these clients often have different or conflicting requirements, which makes it difficult to manage trade-offs and meet project objectives (Sengonzi et al., 2009; Tzortzopoulos et al., 2009; Hicks et al., 2015); (3) there is a large number of regulations, which strictly control healthcare services and environments (Hicks et al., 2015); (4) the development of new healthcare facilities often involve changes in service delivery models (Rankin et al., 2014; Righi and Saurin, 2015), which are not well defined at the beginning of design development (Tzortzopoulos et al., 2009); (5) healthcare facilities contain a large number of elements, such as building services, equipment and other components that dynamically interact (Rankin et al., 2014; Hicks et al., 2015; Righi and Saurin, 2015) and (6) the built environment often needs to be refurbished due to changes in demand or advances in healthcare processes (Ornstein and Ono, 2010).

In this context, Building Information Modelling (BIM) can potentially be used with human input for storing and structuring requirements, and connecting that information to building models for visualizing requirements, maintaining them updated and performing design assessment tasks (Jansson et al., 2013; Parsanezhad et al., 2016; Kamara, 2017). However, previous research has pointed out that requirements management is rarely implemented in the construction industry (Kiviniemi, 2005; Koppinen et al., 2008; Jallow et al., 2014) and the information on client requirements available to support design decision-making is usually inadequate (Yu and Shen, 2013). Some previous studies developed or used computer tools that make connections between requirements and objects of the product model, using IFC Open Standards (Kiviniemi, 2005; Fu et al., 2007; Tarandi, 2011; Shen et al., 2013; Jallow et al., 2014; Soliman-Junior et al., 2020b). Despite some important contributions from those studies, their main focus has been on developing digital solutions (Baldauf et al., 2020) or exploring benefits and limitations of BIM tools and their impact on healthcare design (Soliman-Junior et al., 2020b), rather than on improving the information processing steps that are necessary in client requirements management. Such steps involve requirements capture, structuring, storage, communication, and assessment. Moreover, the literature does not explore how those steps can be improved by using BIM-based tools. Therefore, this investigation provides a process management approach for client requirements in healthcare projects, based on the use of digital tools to support different tasks involved.

It is worth noting that requirements management can be considered as a broader approach than the use of BIM for automated assessment of design compliance to regulations (Macit İlal and Günaydın; Soliman-Junior et al., 2020a). In fact, the scope of requirements management includes design assessment for both regulatory and other client requirements, considering both requirements that can be translated into checkable rules and those that require subjective assessment. Moreover, in contrast with automated rule-checking, collaborative working plays an important role in requirements management (Jallow et al., 2014), and this can potentially be facilitated by BIM-based methods, tools and protocols (Mignone et al., 2016). In the context of healthcare facilities, it is also important to consider that healthcare systems change over time (Soliman-Junior et al., 2020b). In this scenario, asset management and project delivery based on BIM are valuable to deal with emerging client needs (Cavka et al., 2017; Soliman-Junior et al., 2020b).

The aim of this research is to propose a method for managing requirements in healthcare projects, based on the use of BIM. This method brings a process-based approach to client requirements management, based on the understanding of the nature and complexity of the client requirements information. This investigation is based on an empirical study conducted in close collaboration with a University Hospital in Porto Alegre, Brazil.

Finally, BIM-based client requirements management provides an opportunity to explore some of the synergies between BIM functionalities and Lean principles (Sacks et al., 2009), the theme of this special issue. In one hand, it is an approach to implement value generation related Lean principles. On the other hand, some BIM functionalities are clearly related to client requirements management, such as “multiuser viewing of merged or separate multidiscipline models”, and “automated checking” (Sacks et al., 2009).

2. Client requirements in healthcare projects

The starting point for the identification of requirements are user needs and constraints captured from different stakeholders (Kamara et al., 2002). Needs express a state in which there is a lack of some product or service characteristic or attribute (Kotler, 1991). While needs are regarded in this research as unprocessed sentences, expressed in natural language, requirements are the result of the interpretation of client needs (Kamara et al., 2002). Therefore, requirements can be regarded as information presented at a neutral solution level (Kamara et al., 2002), which can be converted into specific design solutions (Jallow et al., 2014).

Requirements information can be generated by different stakeholders and expressed at different levels of abstraction (Kamara et al., 2002; Sengonzi et al., 2009). Therefore, it is important to understand the complexity that results from the diversity of requirements from distinct client groups (Kamara et al., 2002). Even if one considers only the final users of healthcare facilities, there are many stakeholders with different requirements, such as medical staff (e.g. doctors, nurses), administrative staff, technicians involved in equipment maintenance, cleaning staff, workers involved in logistics, patients, family members, visitors and, in the case of educational institutions, medical students (Kollberg et al., 2006; Sengonzi et al., 2009). These users interact and give rise to several types of flows, such as patient, staff, medication, family, supplies, information and equipment (Hicks et al., 2015). In addition, healthcare design projects involve designers, funding agencies, regulatory bodies, cost estimators, design managers and the community (Kollberg et al., 2006; Sengonzi et al., 2009; Davis, 2014). There are other stakeholders involved in the production stage, such as contractors, subcontractors, suppliers and project managers (Sengonzi et al., 2009; Davis, 2014). Table 1 presents categories of requirements that should be considered in healthcare projects.

Client requirements can also be categorised as subjective or objective, qualitative or quantitative, and those categories influence the possibility to automate design assessment. A requirement is objective if it is based on precise information (Pfleeger et al., 1994; Atoum and Otoom, 2016), allowing the same interpretation by different people (Soliman-Junior et al., 2020a). By contrast, subjective requirements express beliefs, or conflicting opinions from experts (Pfleeger et al., 1994; Atoum and Otoom, 2016), demanding interpretation to be incorporated into the design (Soliman-Junior et al., 2020a). Qualitative requirements are the ones that can be expressed by words or figures, while quantitative requirements are represented by numbers or other measurable characteristics (Seaman, 1999). In other words, the distinction between qualitative and quantitative requirements has to do with the way in which information is represented, rather than whether it has a subjective or objective character (Seaman, 1999).

Design assessment is performed to determine whether the design or the final product fulfil the set of requirements used as reference (Shen et al., 2004; Eastman et al., 2009; Parsanezhad et al., 2016). Automated assessment can be applied for both quantitative and some qualitative requirements, that are categorised as objective, usually represented in a logical structure (Macit İlal and Günaydın; Soliman-Junior et al., 2020a). The semi-automated approach has been defined as an assessment carried out using computer-processed data (Macit İlal and Günaydın), which requires some degree of subjectivity to determine the compliance of the design concerning the requirements (Soliman-Junior et al., 2020a). Although assessments in relation to subjective requirements may lead to inconsistencies and inaccuracies in this process, they might be necessary (Seaman, 1999) in some situations due to the complexity involved in devising a design solution (Soliman-Junior et al., 2020a).

3. Client requirements management and BIM benefits

The starting point for client requirements management is understanding the project context (Kamara et al., 2002), followed by the identification of different types of clients, which might have distinct roles in the project (e.g. users, owners, investors, designers), and the systematic capture of information related to user needs and expectations (Kamara et al., 2002; Shen et al., 2004). Then, information must be translated into explicit requirements, which must be understood and interpreted by people or computer programs (Fiksel and Hayes-Roth, 1993; Eastman et al., 2009). Requirements should be grouped and structured, that is organized into categories, due to a large amount of information involved (Kamara et al., 2002; Kiviniemi, 2005; Jansson et al., 2013). Explicit requirements and specifications must then be stored (Kiviniemi, 2005; Shen et al., 2013; Jallow et al., 2014), refined, communicated, prioritized by decision makers and, finally, be used to assess design compliance (Shen et al., 2013; Jallow et al., 2014).

Baldauf et al. (2020) proposed a process model with interrelated activities involved in client requirements management with the support of BIM for the context of social housing projects. Those authors also identified benefits of using BIM in client requirements management, which are summarised in Table 2. The outcomes of that study were used as a starting point for the development of the method proposed in this investigation. An additional benefit was added to this list, namely collaborative access: BIM should facilitate collaboration between stakeholders by providing multiple access to the current version of requirements (Kamara et al., 2002; Jallow et al., 2014).

4. Research method

4.1 Research design

Design Science Research (DSR) was the methodological approach adopted in this investigation. DSR aims to develop artefacts to solve classes of real problems, and at the same time contribute to the development of prescriptive theories (Lukka, 2003). March and Smith (1995) proposed four types of outcomes in DSR: models, methods, constructs and instantiations. The artefact proposed in this research study is a method to manage requirements of healthcare projects using BIM.

An empirical study was carried out in a public university hospital in Porto Alegre, referred to as Healthcare Institution X (HIX), which invested 72 million dollars in a construction project, including two new buildings (Buildings 2 and 3). During this empirical study, the existing emergency department (ED) of the hospital, located in Building 1, was evaluated in order to capture client requirements. This was the main source of information for modelling client requirements for the new emergency department, to be installed in Building 2. After structuring and processing requirement data, the adequacy of the new ED was assessed.

The study was divided into three stages: (1) understanding the context and capturing requirements of the existing emergency department (ED); (2) refining and modelling requirements, connecting them to the product model and assessing the new ED based on the client requirements model and (3) devising the method for managing requirements, and assessing its utility and applicability. This research study was submitted and approved by the Research Ethics Committee of the Hospital.

4.2 Description of HIX and of the emergency department

HIX is a healthcare complex formed by several buildings, including Building 1, a 128,000 m² hospital inaugurated in 1972, and the new buildings 2 and 3, which extended the area of Building 1 in 70%. Building 2 has 54,000 m², including nine floors, two basements and a vertical circulation tower that connects this building to Building 1.

Four design companies were involved in the project. The brief and conceptual architectural design of Buildings 2 and 3 were developed by Company A. Company B was in charge of architectural design detailing, and companies C and D of engineering design. From 2014 to 2019 a consortium of two companies, E and F, constructed buildings 2 and 3. HIX has a construction engineering department, which had the role of coordinating design approval and managing design changes requested by medical staff.

The area of the existing ED is approximately 1,700 m² and it is located on the ground floor of Building 1, which has around 5,000 m². The ED was selected for this investigation based on the following criteria: (1) a partnership between HIX and the research team was established for the assessment of existing and new buildings; (2) emergency departments are highly complex socio-technical systems, and the head managers were very interested in having an assessment of the new ED regarding user requirements and (3) there was an opportunity to take advantage of the results of the existing ED assessment for future improvements in the new ED.

The existing ED has 47 beds (38 adults and 9 paediatric) in the Brazilian Unified Health System (SUS). Several professionals work in that department: 80 physicians, 40 nurses, 120 nursing technicians, 20 physician candidates, 8 residents, secretaries, security staff, heads of the emergency service, consultants, respiratory therapists, physiotherapists, pharmacists, paramedics, graduate students, social workers and psychologists. The ED works as a complete hospital because it comprises not only the emergency service but also other specialties, such as general practice, gynaecology and obstetrics, general surgery and paediatrics.

The area of the existing ED is divided into: reception, triage, 3 emergency rooms (2 adults and 1 for children), 8 medical offices (6 for adults and 2 for children), 4 adults care rooms (CRA, B, C and D), 3 paediatric care rooms (CRA, B and C) and isolation rooms (Figure 1). The most critical patients are stabilized at emergency rooms and then they are transferred to the Intensive Care Centre (on the second floor of Building 1) or to Care Room D (CRD), which is intended to keep unstable patients, who require multi-parameter monitors and mechanical ventilation. The ED also has a pharmacy, diagnostic and administrative rooms, teaching and research facilities (Figure 1).

Figure 2 shows the new ED design, which consists of: patient reception, 2 triages (adult and paediatric), 9 consulting rooms (5 for adults and 4 for children), adult care rooms (52 beds in the CRB1, CRC1, and CRD1), paediatric care rooms (13 beds in the CRB1 and CRC1), 6 isolation rooms (4 for adults and 2 for children), pharmacy, administrative rooms, teaching and research rooms.

4.3 Stage 1: understanding the context and capturing requirements of the existing ED

Table 3 presents the sources of evidence used in Stage 1: (1) 2 meetings (M); (2) 8 direct observations (O); (3) 52 open-ended interviews (OI); (4) 8 semi-structured interviews (SSI) and (5) document analysis. Open-ended interviews were conducted during visits to the existing ED, through the application of a few quick questions, without intervening in the activities of the staff. SSI sources 2, 13 and 20 had a defined script which allowed a wide range of data to be captured. SSI sources 16 and 17 included specific questions for further clarification regarding the existing and the new ED.

The understanding of the HIX extension project, especially in terms of requirements management, was based on sources 1, 2, 13, 17 to 20, while sources 5, 6, 12 to 14, 16 and 17 were used to analyse the new ED design, and to identify design changes that were introduced. With the purpose of understanding healthcare services and spaces, visits were made by the researchers to the existing ED, in which direct observations and interviews with users were carried out (sources 3, 6 to 8, 10 to 12, 14 and 16 (Table 3). The main topics explored in the interviews were: (1) understanding space functions and uses, and the main existing services, including patient and staff flows; and (2) identifying layout changes and refurbishments carried out in the existing emergency (sources 14 and 16).

The sources of evidence 3, 4, 6, 8, 9, 11 to 16 (Table 3) were used to capture client requirements from the existing emergency. Process requirements were obtained from an in-depth analysis of processes and the identification of those that accommodate or directly support user activities, while user requirements resulted from the capture of desires, perspectives and expectations of the different users. Although the source of evidence 17 (Table 3) revealed some operation requirements (see Table 1), they were not considered in the scope of this research. Secondary data from previous studies (Righi and Saurin, 2015; Wachs et al., 2016) were also used to identify requirements and to understand processes from the existing emergency. In addition, four documents provided by the Head Administrator of the ED were also used as sources of evidence. These documents, entitled of Changes Request Guide, containing the description of changes required for the new ED design.

The main regulatory requirements were identified from the analysis of building codes, statutes and especially in the RDC50 standard, which establishes technical regulations for designing healthcare buildings. Only the regulatory requirements directly related to the fulfilment of client requirements were modelled in this investigation.

4.4 Stage 2: processing and modelling client requirements and assessment of design

Stage 2 involved the following steps: (1) analysing and refining requirements; (2) developing a digital building model and connecting it to the requirements model; (3) structuring and storing requirements and (4) assessing the new ED design regarding the fulfilment of requirements.

Some commercially available BIM tools for requirements management were analysed, such as Onuma System, Trelligence Affinity, Codebook, dRofus and Solibri Model Checker. dRofus and Codebook enable tracking the reasons for making requirements changes in design over time. dRofus synchronize requirements and the 3D model bi-directionally and it also allows controlled access to the requirements database. Solibri enables requirements to be checked automatically.

Solibri and dRofus were the BIM tools chosen for modelling requirements, as those tools have complementary attributes, allowing the connection of requirements to the digital product model, using the IFC Open Standard (Eastman et al., 2009; Kim et al., 2015). dRofus can be used as a broad repository of requirements and also enables requirements to be tracked and reused in similar projects. Solibri also enables requirements to be connected to spaces, being able to translate them into parametric rules (Eastman et al., 2009). By using those rules, compliance checking can be automated to some extent (Soliman-Junior et al., 2020a). The digital building model was developed in Autodesk Revit, based on 2D drawings provided by HIX.

After collecting information from client's needs and regulations, these were analysed, refined and translated into users, process, and regulatory requirements. Thereafter, requirements were grouped into categories and subcategories based on Kiviniemi's model (2005) and on the existing requirements structure of dRofus. This was an interactive process, as those categories needed refinements, considering the specificities of healthcare projects. The description of the main healthcare services was based on observations and interviews described in Table 3.

User, process, and regulatory requirements were used to assess the design of the new ED. dRofus is especially useful in assessing subjective requirements by using a semi-automated approach, while Solibri enabled the automated assessment of a large number of requirements (Eastman et al., 2009). The requirements that could be checked by a semi-automated or automated approach were identified, as well as whether these were fulfilled or not in the new ED design.

4.5 Stage 3: devising the method and assessing its utility and applicability

The method was developed during the empirical study. In Stage 3, after the development of the final version of the method, a partial assessment of the method was carried out through (1) 2 seminars and 4 meetings with representatives of HIX, and (2) 1 evaluation seminar with researchers. In the final seminar (source of evidence 7 in Table 4), 18 staff from HIX participated in the evaluation of the proposed method, including of the head managers in charge of the transition of services from Building 1 to Buildings 2 and 3.

The aim of the meetings and seminars was to assess the applicability and utility of the proposed method and contribute to its refinement. A set of criteria was used in this assessment, based on the benefits of using BIM in client requirements management, described in Section 2.

5. Results

5.1 Difficulties of managing client requirements in HIX expansion project

The brief and the conceptual design for Buildings 2 and 3 were developed by Company A, based on meetings held with the president and a small number of representatives of the medical staff. According to some interviewees, this is a practice widely used in hospital projects in Brazil. In fact, designers and construction managers pointed out difficulties in the management of the project due to the fact that it is challenging to consider all needs communicated by a wide variety of users, who have conflicting and evolving requirements. They also reported that there were frequent demands for design changes made by medical staff, which caused disruptions in the project.

By contrast, the head ED physician pointed out that important user requirements have not been considered in the design of the new ED, e.g.: (1) the main healthcare flows (patient, staff, medication, waste, and supplies), which had not been fully defined during building design; (2) some specific uses of the new ED as an university hospital had not been clearly defined, mostly due to the limited participation of medical staff in design definitions and (3) some furniture and equipment had not been defined. In fact, both furniture and equipment should be considered as part of the built environment, due to the impact on the performance of healthcare services and, consequently, in value generation. In addition, recent healthcare service changes should have been considered the design of the new ED, but they were not.

Furthermore, some of the changes requested by the ED staff and from other HIX representatives were not considered, due to the need to deliver the project within the deadline, as well as due to the costs associated to design changes. Therefore, there is evidence that the lack of systematic client requirements management in this project caused problems in the delivery of value to the final users.

5.2 Capturing, analysing and refining requirements

Figure 3 presents examples of needs, captured through interviews and observations (expressed in a narrative way), that were translated into requirements, and the classification of those requirements according to the nature of the information. The following categories were adopted: users or process requirements, qualitative or quantitative and subjective or objective requirements. Altogether, 190 requirements (72% users' requirements and 28% processes' requirements) were captured: 163 were identified in the 14 visits to the existing ED, although 9 of them were also identified in previous studies, and 26 in change request documents. A total of 128 requirements were elicited through visits and interviews (e.g. doctors, nurses, nursing technicians, and administrators). This highlights the importance of using observations and interviews as sources of evidence for capturing requirements. The analysis of the information collected also indicates that 143 requirements (75%) were expressed qualitatively, while 47 had a quantitative nature.

From the analysis of building codes and regulations, 73 regulatory requirements were selected and modelled due to their direct connection with users and process' requirements. Regulatory requirements provided parameters for some user and process requirements, initially classified as qualitative, enabling them to be assessed by automated rule checking. The first two requirements in Figure 3 are qualitative and translate the wishes and expectations of users regarding patients' comfort. These requirements are indirectly related to the emergency service. The third refers to a process, for example the nursing staff needs computers to store patients' information. This requirement could become quantitative and objective if there was the definition of a parameter, such as, for example, one computer for every two employees.

The 190 requirements were grouped according to affinity and organized into categories and subcategories of requirements (Figure 4). Based on the understanding of the existing ED services (sources 3, 6–8, 10–12, 14 and 16 in Table 3) and the analysis of RDC50 standard, the services were structured and connected to the 190 requirements. Figure 4 presents the main connections between built environment requirements and healthcare services, in which each line is related to a single requirement. The number of requirements for each category or subcategory is also represented in Figure 4, being possible to identify which services are strongly influenced by built environment requirements (see the right side of Figure 4). This map of relationships can support stakeholders in the design decision-making process. The main category of services, “Urgency and emergency care”, comprises 120 requirements (62%), while the “Treatment, general care and monitoring of the patient” service contain 45 requirements (23%). This service is related, for example, to the requirement “having a patient's overview in the observation rooms” and it influences the effectiveness of clinical staff to provide patient care.

“Space conformity requirements” was the category of requirements that concentrated the largest number of requirements, 92 (48%) (Figure 4). Specific information related to ergonomics was placed in the “Furniture or equipment requirements” category, which was the second one in terms of the number of requirements, 31 (16%). Those 31 requirements are distributed into three subcategories (Ergonomics, Dimensions and Operation and maintenance). The subcategory “Dimensions” consists of seven requirements, of which three are related to the service “preparation of medicines”.

For some requirements, an in-depth analysis of the information was carried out, such as, for example, the analysis of patient and staff flows. Based on the understanding of these main flows in the existing ED, an analysis of the flows for the new ED was carried out. One of the most important flows, reported in interviews, was the immediate care of critically ill patients. In the existing emergency, these patients are first taken to the emergency room while the doctors move from their workstations located in care room D, which is 9 m away from the emergency room (Figure 5). In the new ED, the administrative and medical head managers requested a direct connection between the emergency and care room D1, which was only made possible through the insertion of a fire door (Figure 5). That connection can facilitate the care of patients. However, the distance involved in that flow is 26 m, almost three times longer than in the existing ED.

5.3 Modelling of functions, spaces, items and the digital model

Product modelling was carried out for the ground floor of building 2, in which the new ED is located. That department was divided into sectors according to the main functions or services provided (e.g. Logistical support, Technical support, Diagnostic and therapy, Teaching, Research and Administration, Emergency care for adults and Paediatric emergency care) (Figure 6). The emergency care for adults sector was subdivided into seven subsectors, such as “Ambulance, Emergency and Care Room D1”, which consists of 13 spaces, such as, nursing room, prescription room, emergency room. dRofus allowed spaces to be visualized in 3D, as shown in Figure 6.

5.4 Structuring and storing requirements for software

Besides the 3D visualization of spaces and equipment, on selecting a space or item, dRofus opens a requirements sheet (Figure 7), where requirements can be stored using different information configurations, such as text-edit boxes and multiple-choice fields. Hence, this stage consisted of structuring the requirements into 12 categories and 30 subcategories (as presented in Figure 4) and storing 190 users and process requirements and 73 regulatory requirements in dRofus. In fact, the software works as a repository of requirement-related information.

The number or type of categories and subcategories in dRofus could be refined and adjusted according to the types of requirements captured. For this study, some categories of requirements were not considered, such as sustainability and cost requirements, because there were no requirements related to those categories. Figure 7 illustrates the “Space conformity” requirements category, which had five subcategories: proximity, space dimensions, occupancy, number of space units and equipment/furniture in space.

Furthermore, 36 requirements were modelled and converted into rules in Solibri to allow automated checking, for example accessibility and ergonomics. Figure 8 shows the requirements structure in Solibri, and, as an example, the storage and translation of the requirement “Adequate space dimensions to allow the wheelchair manoeuvre area” into a parametric rule. Solibri provides predefined templates of rules, which were refined and adapted to healthcare requirements. This also allows the re-usage of rules when checking similar projects. In addition, details had to be provided in the information take-off sheet for all components of the model, including the object classification and information about space usage, name, operation (e.g. door with single swing left).

Solibri and dRofus allow the definition of the templates, which could be used as a point of departure for managing requirements of other projects, so there is no need to create a new structure for every project. The dRofus' template consists of all categories and subcategories previously stored in the requirements sheet. When re-using a template, all connections to spaces and items need to be defined, as well as the storage of specific requirements of the project at hand.

5.5 Design assessment

Table 5 shows the results of the new ED assessment, including both automated and semi-automated design checking. From the 190 requirements, 80 of them were fulfilled and 14 were partially fulfilled in the design of the new ED. Thirty seven requirements were not fulfilled, from which 17 had been requested in the Changes Request Guide. This created dissatisfaction among emergency management team members. Table 5 also shows that 59 requirements were not verified due to the lack of design definitions. As mentioned in item 5.1, the furniture and equipment and important flows (e.g. patients, medications) were not clearly defined at the design stage. As a result, the assessment of design compliance in relation to requirements was incomplete.

The semi-automated assessment was performed for 106 of the requirements modelled in dRofus, which are easily visualized in the BIM model, but still requires a subjective assessment as previously pointed out in Section 2. In this research study, the importance of carrying out this type of assessment is highlighted, as a large share of users and process' requirements (56%) required subjective evaluation.

Figure 9 provides an example of a requirement from the “Visual requirements” category that was assessed in a semi-automated way in a meeting with the Head Physician of the existing ED, and nursing staff. The requirement “technicians or nurses need to view the patient from the nursing workstation” was presented in association with the digital model. Thereafter, the staff was able to understand that an existing wall compromised the monitoring of some patients. Due to the qualitative and subjective character, this type of requirement is more easily understood if the digital model is analysed, or by using illustrative examples as a reference for design development. The connection of requirements with a 3D digital model (BIM) allows participants to understand the design, and make an assessment regarding value generation from the client's perspective.

A certain level of subjectivity is also involved in the assessment of distances between spaces. In the new ED, the proximity of the ambulance parking areas to the adult and paediatric emergency rooms will improve safety for the care of critically ill patients, compared to the existing ED. By contrast, the longitudinal shape of the new ED floor plan and issues in the organization of the spaces may result in longer flows, if compared to the existing ED, especially due to the inadequate location of the pharmacy, as reported by the head managers of the existing ED. This reinforces the importance of clearly defining healthcare services and flows to fulfill critical service requirements.

Automated assessment was carried out with the BIM tools for 44% of users and process' requirements (as shown in Table 5). Fifty two requirements related to the quantity and types of spaces, equipment, components and furniture were checked in dRofus, while Solibri was used to check 32 requirements related to ergonomics and dimensions of equipment and furniture, and also accessibility requirements.

As an example, an interview with ED staff revealed the need to improve accessibility of beds from adult and paediatric care rooms to the diagnosis and therapy rooms. With Solibri, it was possible to simulate the bed displacements to the final destination. If performed manually, this check would have been much more time-consuming (Figure 10).

6. Method for managing client requirements

6.1 Overview of the method

The proposed method emerged at the end of the empirical study. It consists of a set of interconnected activities, organised into three stages (Figure 11): (1) capturing and processing requirements; (2) product and requirements modelling and (3) support to solution development.

The capturing and processing requirements stage happens at the beginning of the design process. Data on client requirements can be captured from different sources, including interviews with stakeholders and direct observation of existing healthcare units. This information is predominantly expressed in a narrative way. It is also important to capture healthcare service requirements, especially flows of patients, staff, medication, visitors and supplies. This understanding can be obtained from the observation of existing units or by interviewing staff involved in the design or improvement of the healthcare services. These requirements are usually classified as users' requirements, which express desires, perspectives, and expectations of users, or process requirements, which are the ones that enable healthcare operations to be performed properly. Operational requirements (see Table 1) from the construction team also need to be collected. Data obtained from standards and regulations are usually more objective and include parameters that can be directly converted into rules. The captured data must then be analysed, refined, and translated into requirements.

In Stage 2, product and requirements modelling, requirements should be structured, that is organised into categories, so that they can be modelled in BIM tools. Requirements modelling is the task of representing requirements in digital tools, in which these can be stored, and connected to building objects. This is done in parallel with product modelling.

At Stage 3, support to solution development, the design solution is developed and assessed according to the requirements model.

The client requirements management activities are not carried out in a linear way: there are several iterations, as indicated by the loops in Figure 11. These loops happen between the processes of capturing requirements and understanding healthcare services, during requirements modelling activities, and also between design and assessment. In order to improve value generation, there is a need to continually assess design solutions regarding the fulfilment of relevant requirements. In this respect, the transparency of requirements information plays a key role, especially for qualitative or subjective requirements. Another important issue is the need to frequently communicate up-to-date information on requirements to stakeholders.

6.2 Capturing and processing requirements (Stage 1)

Understanding the healthcare services is the starting point to find out the relationships between services and the built environment (Figure 12). For this purpose, it might be necessary to analyse and categorise those services. Different sources of evidence can be used, such as direct observations in buildings with similar services, prototyping of spaces and analysis of documents describing services. However, the analysis of documents is not enough to understand the services, as the operation of activities performed in complex contexts sometimes is different from prescribed activities (Rankin et al., 2014).

The requirements capturing step (Figure 12), involves the identification of clients. Data can be collected through different sources, e.g. interviews, direct and participant observation, documents analysis, secondary data sources, walkthroughs using BIM and analysis of changes in existing facilities, where appropriate.

The information collected must be interpreted and transformed into explicit requirements (Figure 12) so these can be stored in a BIM tool. In order to do that it is often necessary to refine these requirements by conducting new interviews, observations, or reinterpreting the information. In this process of interpretation and refinement, some inconsistencies, for example. between regulations and other sources of information, as well as conflicts between the needs of different clients. The resolution of these inconsistencies requires trade-offs to be made among requirements.

There is a need to organise requirements according to affinity at the beginning of the process and prior to the inclusion of the requirements into a BIM tool. At later stages, emerging requirements can be stored directly in the requirements management software. In this investigation, an initial structuring of requirements was done in a spreadsheet, prior to any BIM modelling. This supported the process of structuring and storing information in both dRofus and Solibri, and it helped identify relationships between requirements and services. This structure can be built from an existing taxonomy (e.g. Kiviniemi, 2005), but adaptations are needed due to the specificities of healthcare facilities.

The storage of requirements can be undertaken after the definition of functions, spaces and items in the requirements model (Figure 12). There is a need to store all requirements in a database, including those that might be considered less important, because during design the recovery of initial requirements may be necessary. This database was created in this study by using dRofus, and only after that some requirements were chosen to be converted into logical rules, modelled in Solibri.

6.3 Product and requirements modelling (Stage 2)

Product and requirements modelling (Figure 13) comprises the definition and classification of items (furniture, equipment and components) and spaces both in the digital model and the requirements model. These models should be developed in BIM tools to establish connections between requirements and the digital model. In conceptual design, it is also possible to define the main spaces in the requirements model and link them to the product model based on information usually presented as a space programme. The linking of the requirements model and the spaces and items in the digital model needs to be adjusted as the design process evolves.

6.4 Support to solution development (Stage 3)

During solution development, it is important to identify which stakeholders have access to view and which ones are allowed to modify the requirements database. Collaboration in this process is important, and so is controlled access to the requirements database (Figure 14). Different stakeholders may need to have access to the requirements database so that requirements can be considered throughout different design, construction and operation phases.

The assessment step refers to the verification of whether the design solution meets requirements. If the assessment is performed in cycles during design development, issues or errors can be eliminated before the completion of design, avoiding value loss and rework. A set of indicators can be used to assess the fulfilment of requirements (as shown in Table 5). Furthermore, the definition of which assessment approach is most suitable for each group or type of requirement is often necessary. The assessment may result in the need to restructure and update requirements in the model.

6.5 Partial assessment of the method

The partial assessment of the proposed method was based on discussions with potential users of the new buildings (as shown in Table 4) and also on researchers' perceptions. The method was assessed through an evaluation of the general benefits of client requirements management described in the literature, that is storage, reuse of requirements, connection, visualisation, assessment, communication, traceability, automation, standardization, comprehensiveness and collaborative and controlled access. The main elements are discussed as follows.

Storing requirements in a BIM tool contributes to collaborative work by making requirements available to different stakeholders, including key users. However, controlled access to the repository of requirements must be ensured. Moreover, templates of requirements can be created in BIM tools (e.g. dRofus) and these could be reused in new designs, reducing the effort involved in modelling requirements for new projects.

The connection of the requirements model with a digital model makes it possible to enrich the 3D representation and the visualization of requirements, which allows several stakeholders to understand the functionalities designed in a healthcare project. Most interviewees agreed that requirements modelling can improve the visualization and understanding of healthcare project information, as well as make design assessment faster and more consistent.

The interviews pointed out that it is often difficult to track changes in requirements, and also when changes happened. An effective structure and storage of requirements enables requirements to be traced in the model and to be communicated to decision makers as soon as changes in the requirements are made. This is a benefit of adopting the method and using BIM tools.

The use of BIM enables a degree of automation in the design assessment process, contributing to the standardization of a large number of criteria for evaluating design proposals. For this purpose, the conversion of requirements into a logical structure depends on the consistency of data of both the digital and requirements models, and it is more suitable for objective requirements (Soliman-Junior et al., 2020a). In the empirical study, 56% of requirements were assessed in a semi-automated way while 44% could be translated into logical rules by using Solibri or dRofus, enabling fully automated assessment. The more automated the design assessment is, the longer the time designers will have to improve design solutions (Baldauf et al., 2020).

According to Baldauf et al. (2020), there is a need to define the scope of the managerial process in terms of the comprehensiveness of client requirements. For instance, in this study, the scope was limited to the new ED and on requirements captured from users, regulations and processes. The level of abstraction of these requirements was limited to product attributes, rather than focused on high abstract values, related to consequences in use or clients' perceived values, as modelled by Lee and Lin (2011). Kumar et al. (2020) pointed out that those abstract values are a potential sources of information for improving the quality of healthcare projects.

6.6 Discussion

This research study proposed a process approach for client requirements management based on some BIM functionalities and a set of Lean principles. The main innovations in client requirements management introduced by the proposed method are: (1) the use of multiple sources of data, including both needs directly captured from users, and indirectly obtained by understanding healthcare services, and (2) the adoption of a systematic process of requirements modelling, which includes categorising, structuring and storing requirement information. In fact, an important contribution in relation to previous studies (Kiviniemi, 2005; Fu et al., 2007; Tarandi, 2011; Shen et al., 2013; Jallow et al., 2014; Baldauf et al., 2020) is the emphasis on understanding the impact of built environment on healthcare service delivery. However, due to time constraints and limitations of the BIM tools, the main healthcare processes have not been digitally modelled. As the method was developed along the empirical study, it was not possible to fully implement it in practice, which is a limitation of this investigation.

This investigation also contributed to the understanding of the nature and complexity of the information concerned with client requirements modelling. That information was categorized in several ways: accuracy of the information (subjective or objective), the type of the information (qualitative or quantitative), different sources (users, regulations, processes, or operations) as well as the degree of automation that it is possible to implement in design assessment. Based on these categories, this research study pointed out that none of the BIM-based tools available in the market are able to model and store all types of requirements needed to improve value generation. A set of constructs, proposed by Baldauf et al. (2020) was used to assess the proposed method. Those constructs explain potential benefits of BIM in client requirements management, and can also be used to guide the development of specific solutions.

Regarding the synergies between BIM functionalities and Lean principles, the proposed method contributes to the implementation of four out of the five value management Lean principles proposed by Koskela (2000): (1) capture client requirements systematically; (2) make client requirements available to different stakeholders; (3) consider client requirements in all deliverables and (4) control whether value has been generated from the perspective of the client. In turn, two BIM functionalities proposed by Sacks et al. (2009) are enabled through the proposed method: (1) multiuser viewing of merged or separate multidiscipline models, by visualising both product and requirements model; (2) automated checking of design in relation to client requirements model. Moreover, two additional BIM functionalities were identified: (1) structuring and storing client requirements (Baldauf et al., 2020); and (2) visualising interactions between the built environment and business processes (Drevland and Gonzalez, 2018), that is healthcare services, in this investigation.

Finally, it must be pointed out that the effective implementation of the proposed method depends on the type of project delivery system. In the case of Integrated Project Delivery (IPD), for instance, the implementation of some processes involved in managing client requirements is facilitated by the fact that collaboration is encouraged between stakeholders, including designers, construction companies, specialty subcontractors and different types of users, as reported by (Mesa et al., 2019). By contrast, the simple adoption of IPD or similar forms of project delivery might be not sufficient to enable the systematic capture, processing and communication of requirements to decision-makers in healthcare design projects, resulting in value loss.

7. Conclusions

This research highlights the importance of managing client requirements in healthcare projects, which often face limitations due to the poor involvement of users during design. This study pointed out the difficulties in dealing with a large number of different clients, who may have conflicting requirements. In addition, this type of project involves frequent changes in healthcare services, often caused by the introduction of new protocols or technologies, which demand changes in requirements. With the intention of dealing with these issues, a method for managing client requirements in healthcare projects supported by BIM was proposed.

One of the main contributions of the proposed method is to bring a process perspective to client requirements management, which includes a clear description of the activities involved and their interdependencies. Requirements management was organised in stages, starting from an understanding of healthcare services. Requirements information must be analysed, structured, continuously refined and connected with the digital model, so that the up-to-date information are considered in the development of design solutions. This type of modelling has the benefit of creating a broad repository of requirements that can be reused for different projects in the healthcare context. The modelling of client requirements also enables a better visualization, traceability, communication of requirements and creates a reference for the assessment of design solutions.

This method can be used by client organisations in the development of healthcare projects to manage and control requirements, especially those that emerge over time. This information could be used to support the delivery of both new and refurbishment projects. For design companies, this type of innovation is useful to guide design development and also assess whether the main requirements are fulfilled in design solutions. The method can also provide insights for software companies to develop or improve their products.

Regarding theoretical contributions, this investigation contributed to the understanding of the nature and complexity of the information concerned with client requirements modelling. Based on a definition of client requirements, different forms of categorizing requirements information were proposed, including accuracy of information, type of requirement, sources of data and degree of automation to be used in design assessment.

Some limitations of the research must be pointed out:

1. the method has not been thoroughly tested in real projects, and further work is needed to further assess its utility and applicability;

2. only the researchers have used the BIM based requirements modelling tools, and practical implementation of the method requires the use of those tools by practitioners;

3. the scope of client requirements modelling was limited to technical requirements, which are related to product attributes, rather than to high abstract values.

There are several opportunities for further research on client requirements management. Firstly, the proposed method needs to be implemented in real project, assessed and refined. In addition, there are opportunities for research on the development of tools that can provide a comprehensive approach in terms of requirements modelling, including different types of information, for example qualitative and quantitative, subjective and objective and for automated and semi-automated checking. Regarding the use of BIM, new functionalities should be explored in the future, including requirements structuring and storage, and modelling relevant business processes (e.g. healthcare services), and the interaction between those processes and the built environment.

Figures

Figure 1

Floor plan of the existing ED

Figure 2

Floor plan of the new ED

Figure 3

Examples of needs translated into requirements

Figure 4

Relationships between requirements and services

Figure 5

Physician's flows in the emergency room

Figure 6

Modelling of functions, spaces, items and the digital model of the new ED

Figure 7

Structuring and storage of requirements at dRofus

Figure 8

Structuring and storage of requirements at Solibri

Figure 9

Semi-automated assessment using dRofus

Figure 10

Automated assessment of the bed displacement

Figure 11

Client requirements management method

Figure 12

Capturing and processing requirements

Figure 13

Product and requirements modelling

Figure 14

Support to solution developing

Table 1

Categories of requirements in healthcare projects

Origin	Definition	Source
Operation requirements	Requirements defined by the construction, manufacturing and logistics processes; they must be considered in the design phase	Adapted from Kamara et al. (2002)
Process requirements	These are requirements to accommodate or support user activities. They result from the interaction between the users and the activities performed within the built environment	Adapted from Carayon et al. (2006) and Kim et al. (2015)
User requirements	Incorporate the collective desires, perspectives and expectations of the different users	Kamara et al. (2002)
Regulatory requirements	Correspond to regulations, rules and laws related to the design, construction, planning, health and safety as well as to other legal requirements that influence the acquisition, existence, operation and demolition of the project	Kamara et al. (2002)

Table 2

Benefits of using BIM for client requirements management (Baldauf et al., 2020)

Benefits	Description
Visualisation	Requirements must be well structured and easy to be visualised (Kiviniemi, 2005; Shen et al., 2013; Jallow et al., 2014)
Storage	Requirement information should be stored in a central and accessible repository (Christiansson et al., 2011; Shen et al., 2013; Jallow et al., 2014)
Connection	Requirements must be connected to spaces and components in product models (Kiviniemi, 2005; Koppinen et al., 2008; Christiansson et al., 2011; Shen et al., 2013)
Communication	Requirements must be available in a useable format to stakeholders (Kiviniemi, 2005; Christiansson et al., 2011; Shen et al., 2013; Jallow et al., 2014)
Assessment	BIM should assist stakeholders in assessing design, based on a set of current requirements (Eastman et al., 2009; Parsanezhad et al., 2016; Macit İlal and Günaydın, 2017)
Automation	BIM should support the automation of the design assessment process (Eastman et al., 2009; Jansson et al., 2013; Parsanezhad et al., 2016; Macit İlal and Günaydın, 2017)
Traceability	BIM should enable stakeholders to track requirements in order to improve change management and the verification of requirements consistency (Dick, 2004; Jallow et al., 2014)
Reuse of requirements	A broad repository of requirements is useful for creating requirement templates that allow a large set of requirements to be reused in different projects (Kiviniemi, 2005; Jallow et al., 2014)
Changes control	BIM should assist in monitoring and controlling changes and understanding how other requirements may be affected by a change (Shen et al., 2013; Jallow et al., 2014). It can also be used to communicate in real-time changes in requirements that need to be updated or refined frequently (Jallow et al., 2014; Baldauf et al., 2020)
User interface	BIM should facilitate the user interface and its widely accepted by project teams (Eastman et al., 2009)
Standardization	BIM can potentially support the standardization of a large number of criteria for assessing design proposals (Baldauf et al., 2020)
Comprehensiveness	BIM should support the modelling of different types of requirements and levels of abstraction (Baldauf et al., 2020)

Table 3

Sources of evidence of Stage 1

	Date/duration	Sources of evidence	Main topics involved	Job role of interviewees
1	02.2014	M (3 staff; 1 Researcher; 2 Professors	Understand the context and the main difficulties of HIX concerning the product development process	Head Engineer, Head Architect and an Architect of the construction Engineering Department of HIX
	40 min
2	06.2014	SSI	Activities and organizational structure of HIX construction engineering department; characteristics of projects and services delivered; understanding the product development process (PDP) and its main problems	Head Architect of the Construction Engineering Department of HIX
	60 min
3	01.2016	O and 7 OI	Use of spaces and furniture and the main services of the ED	Nurse; 2 Nurse Technician; Physiotherapist; 2 Physicians; Cleaning Service Employee
	150 min
4	02.2016	O and 7 OI	The layout of furniture; dimensions and adaptations of space, ideal furniture for space, use of spaces	Nurse; Nurse Technician; Secretary; Nurse of Paediatric Emergency
	360 min
5	02.2016	OI	Main changes requested by the emergency team concerning the new emergency design	Head Manager of the ED
	60 min
6	03.2016	OI	Use of spaces and furniture and understand the main services of the Paediatric Emergency; understand the design and changes of the new ED	Head of the Paediatric Emergency Nursing Department
	60 min
7	06.2016	O and 2 OI	Patients flow in the reception and triage, and services provided at the reception room	2 Secretaries
	90 min
8	07.2016	O and 12 OI	Understand patient flows, use of spaces and furniture at CRA, consulting rooms and triage	2 Secretaries; 7 Nurse Technicians; 2 Nurses; Security Guard
	275 min
9	08.2016	2 OI	Use of spaces and furniture at Pharmacy	Head of Medicine Management and Logistic Sector; Pharmacist
	80 min
10	09.2016	O and 3 OI	Evaluation of flow maps	2 Nurse Technicians; Nurse
	240 min
11	10.2016	O and 8 OI	Understand patient admission, evolution and prescription; medication flow; patient flows at the diagnostic room; capture client requirements	3 Nurse Technicians; X-ray Technician; Physician; Resident Physician; Pharmacist; Pharmacist Assistant
	220 min
12	12.2016	3 OI	Uses and services of administrative office; uses and needs of CRD; design assessment of the new Paediatric Emergency	Head of the Paediatric Emergency Nursing Department; Physician; Administrative Sector Employee
	90 min
13	12.2016	SSI	Understand and assess requirements concerning space conformity, furniture, equipment, visualization, accessibility; understand the design and changes of the new ED	Head Physician of ED
	90 min
14	12.2016	O and OI	Ergonomic requirements, understand the changes made in the existing ED; understand services flows of existing ED	Nurse Technician
	30 min
15	12.2016	O and 3 OI	Capture and assess ergonomic, visualization, space, and furniture requirements of Paediatric Emergency, CRB, CRC and CRD	Head of the Paediatric Emergency Nursing Department; 2 Physicians
	120 min
16	01.2017	3 SSI	Understand changes made in the existing ED, and design of new ED; understand services/patient flows of existing ED; capture client requirements	Head Manager of the ED; Physician; Resident Physician
	90 min
17	05.2017	OI and 2 SSI	Understand the main difficulties of HIX concerning the product development process; understand changes and PDP of the new ED and the company B's involvement	Head Engineer of the Construction Engineering Department of HIX; Architect responsible for design compatibility; Project Manager and Architect responsible for detail design (Company B)
	110 min
18	07.2017	OI	Understand the companies A and B's involvement in the PDP, main problems in PDP, requirements management and design changes processes	Head Engineer of the construction Engineering Department of HIX
	30 min
19	09.2017	M 1 staff HIX; 5 Researchers, 2 Professors	Understand the main difficulties of HIX concerning the product development process; understand the main changes of processes	Head Engineer of the construction Engineering Department of HIX
	90 min
20	10.2017	SSI	Understand the participation of the construction engineering department of HIX, design approval, the main problems in the design process	Head Architect of the Construction Engineering Department of HIX
	40 min

Note(s): M = Meeting/O= Observation/SSI = Semi-structure Interview/OI = Open-ended Interview/HIX = Healthcare Institution X

Table 4

Sources of evidence of Stage 3

	Date/duration	Sources of evidence	Job role of attendants	Institutions/no of attendants
01	07.2016	Seminar	4 Researchers; Head Administrator of the ED; Head of the Paediatric Emergency Nursing Department; Head Physician of ED; 4 Nurses; 3 Doctors; 4 Nursing Technicians	Research Institution: 4
	60 min			HIX: 14
02	05.2017	Meeting	Researcher and 2 Professors; Head Architect of the Construction Engineering Department of HIX	Research Institution: 3
	60 min			HIX: 1
03	08.2017	Meeting	2 Researchers and 1 Professor; Physician in charge of transferring the existing services from building 1 to the new buildings 2 and 3	Research Institution: 3
	60 min			HIX: 1
04	09.2017	Meeting	Head Engineer of the Construction Engineering Department of HIX; 5 Researchers and 2 Professors	Research Institution: 7
	90 min			HIX: 1
05	12.2017	Seminar	1 Professor, expert in Requirements Management; 2 Ph.D. Students in Production Engineering, experts in Managing Healthcare Services; 1 Master's Student in Construction Management	Research Institution: 4
	80 min
06	03.2018	Meeting	Head Manager of the ED and Researcher	Research Institution: 1
	30 min			HIX: 1
07	07.2018	Seminar	Manager of the Intensive Care Centre; Head of the Health Quality and Information Management Program; Adjunct to the Administrative Direction; Head of the Nursing Service; Head Manager of the ED; Head Physician of ED; Head of the Nursing Emergency Adult Department; Administrative Coordinator; 2 Medical Direction Advisors; intensive Care Department Nurse; Production Engineer; Administrative Supervisor; Emergency Medical Manager; Head Architect and an Architect of the construction Engineering Department of HIX; Civil Engineer; Head of the Paediatric Emergency Nursing Department	Research Institution: 2
	90 min			HIX: 18

Table 5

Assessment approaches and the number of client requirements fulfilled in the new ED design

	Fulfilled	Not fulfilled	Partially fulfilled	Not assessed	Total
Total	80	37	14	59	190
	42%	19%	7%	31%
Semi-automated	49	22	06	29	106 (56%)
Automated	31	15	08	30	84 (44%)