Enhancing Computational Compliance Checking in Healthcare Facilities Through the IDS Standard

Abstract

The design of healthcare facilities must comply with applicable regulatory requirements, which significantly influence functional, spatial, and performance aspects of healthcare buildings. However, compliance checking is still predominantly conducted through manual procedures, leading to time-consuming workflows and a high risk of errors. In this context, Computational Compliance Checking (CCC) offers the potential to enhance the efficiency and reliability of regulatory verification processes. The adoption of Building Information Modelling (BIM), supported by the open standard Industry Foundation Classes (IFC), enables the formalisation of Information Delivery Specifications (IDS) as machine-interpretable rules for model validation. Additionally, the buildingSMART Data Dictionary (bSDD) contributes to the semantic structuring and classification of information requirements. This study explores how the IDS standard can enhance CCC processes by supporting the automated verification of regulatory requirements. Complementary solutions based on Python are proposed to address cases where IDS alone proves insufficient. A methodology for the semi-automated compliance checking of healthcare regulatory requirements is developed and applied to a case study based on regional regulations in the Veneto Region (Italy). Tested on the inpatient ward of a hospital BIM model, the procedure processed all 35 accreditation requirements, 91.4% through IDS and 8.6% through complementary Python routines, revealing several design non-conformities.

1. Introduction

The design of healthcare facilities represents one of the most demanding challenges in the Architecture, Engineering, and Construction (AEC) industry. The complexity of hospital buildings derives not only from their technical and functional requirements, but also from the density of regulatory constraints that govern their spatial configuration, operational performance, and accreditation status [1,2]. In Italy, the adoption of BIM for public procurement projects is mandated by D.Lgs. 36/2023 [3], which requires the use of digital information management tools for public tenders exceeding two million euros. Despite the availability of BIM models, the verification of regulatory compliance of projects remains a predominantly manual process, time-consuming, error-prone, and heavily dependent on the individual expertise of the verifier [4,5].

CCC has emerged as a research response to these limitations, enabling the automated or semi-automated verification of building models against formalised regulatory requirements [6]. Within the openBIM ecosystem developed by buildingSMART International, the IFC standard provides the data infrastructure for model exchange, while the IDS offers a machine-readable format for specifying and verifying information requirements [7]. In addition, the bSDD further supports semantic interoperability by providing standardised, unambiguous definitions for properties and classifications referenced in IDS files [7,8].

However, the applicability of these standards to the specific regulatory context of healthcare facilities has not yet been systematically investigated. The accreditation requirements defined in healthcare regulations combine dimensional, relational, functional, and conditional prescriptions whose computational complexity varies considerably. A significant portion of these requirements involves geometric and spatial checks that lie outside the current capability of IDS, which is designed exclusively for the validation of alphanumeric data [5,9].

This paper addresses these gaps by proposing a semi-automated methodology for compliance checking of hospital BIM models against regional accreditation requirements. By combining IDS-based verification with complementary Python-based solutions when the IDS alone proves insufficient, the article demonstrates how methodologies for semi-automatic requirements verification can be implemented successfully. The methodology is validated through a case study based on a hospital BIM model and the regulatory requirements of Veneto Region.

The remainder of the paper is structured as follows. Section 2 reviews the role of BIM in healthcare design and the relevant regulatory framework, introduces the CCC domain and the classification of rules, and analyses the openBIM standards IFC, IDS, and bSDD, critically assessing their applicability to healthcare regulatory requirements. It further defines the research gap and states the aims of the study. Section 3 describes the proposed methodology. Section 4 presents the case study and results. Section 5 discusses the findings, and Section 6 draws the conclusions.

2. Background

2.1. Healthcare Facilities and BIM

Healthcare facilities rank among the most complex building typologies in terms of design, given their high information density, multiplicity of stakeholders involved, and technical, hygiene, and functional requirements they must meet [2]. Unlike other building types, hospitals are systems in which design decisions have a direct bearing on the quality of care delivered. For example, spatial layout affects patient wayfinding, access to critical healthcare areas, staff visibility, and infection risk management [10]. This interdependence between spatial configuration and clinical outcomes makes hospital design a domain in which early-stage decisions carry long-term consequences: errors or inefficiencies that cannot be corrected during construction reverberate through daily operations for decades [2]. Zhang et al. [11] documented a sharp increase in publications since 2018 on the application of BIM, IoT, artificial intelligence, and digital twins to healthcare facility management, with these progressively converging into integrated digital frameworks. However, operational deployments remain largely confined to small-scale demonstrations, with little evidence that systematic and long-term integration has been achieved in practice [12].

BIM has assumed an increasingly central role in healthcare construction and management. Indeed, it enables multidisciplinary collaboration and supports informed decision-making across the full building lifecycle, with documented benefits for hospital functionality and efficiency [10]. During the design phase, BIM enables automated clash detection, simulation of alternative layout scenarios, and early involvement of clinical staff in the decision-making process, with documented benefits for planning quality, cost reliability, and scheduling accuracy. During construction, it allows up-to-date model information to be retrieved on site in real time, and for design changes and execution defects to be recorded digitally within the model [2]. In the operational phase BIM supports asset management, preventive maintenance, and intervention planning [13,14]. Within the Italian context specifically, adoption in the healthcare sector remains limited. A recent survey of fourteen Italian hospitals found that advanced digital modelling tools are still weakly diffused, with only 7.1% of the surveyed facilities having implemented a digital twin and a small minority having adopted BIM [15]. Nonetheless, a growing body of Italian studies applies BIM and openBIM to healthcare facilities. Recent work has used BIM and the IFC standard to model and optimise automated guided vehicle routes within a hospital [16], and computational BIM approaches have been proposed to support the spatial analysis of healthcare facilities [17]. At the project level, BIM models have supported the assessment of technological and medical-device requirements in a paediatric hospital [18], while BIM-based digital twins have been applied to optimise environmental comfort in the hospital setting [19].

In Europe, the growing recognition of BIM’s potential in healthcare construction has been accompanied by an expanding regulatory framework that increasingly shapes how digital information management is mandated, structured, and evaluated in public procurement. At the same time, the design of specific building typologies is governed by sector-specific regulations that impose precise requirements on spatial configuration, functional organisation, and technical performance.

In Italy, Legislative Decree 36/2023 [3] makes the use of digital information management methods and tools mandatory for public tenders with an estimated works cost exceeding two million euros from 1 January 2025, establishing BIM as a regulatory requirement rather than merely a technical choice [20]. In the healthcare sector, this digital obligation intersects with a parallel layer of sector-specific accreditation requirements that directly shape the informational content of design. The regulatory framework is structured across a hierarchy of instruments: at the national level, DPR 14 January 1997 [21] establishes the minimum structural, technological and organisational requirements for healthcare facilities; at the regional level, L.R. 22/2002 [22] transposes these obligations and delegates their operational definition to successive regional council resolutions, of which the most recent are DGR n. 2266/2016 [23] and its interpretive guide DGR n. 1732/2017 [24]. These documents, which designers must comply with to ensure the accreditability of the project, cover requirements ranging from minimum room dimensions to clinical risk management. These requirements must be satisfied independently of, and in addition to, the digital obligations introduced by BIM mandates.

2.2. Computational Compliance Checking (CCC)

Regulatory compliance checking is a central activity in the building design process, and is particularly critical in complex typologies such as healthcare facilities, where regulatory requirements pervasively influence the functional, spatial, and performance dimensions of the built asset [5,6]. Traditionally, this activity is carried out through manual procedures: an expert interprets the regulatory text, compares it against the design, and formulates a compliance judgement. This approach is slow, prone to subjective interpretation errors, and poorly scalable on large and complex projects, with direct consequences for project costs and schedules [4].

Computational Compliance Checking can be conceptualised as the matching of a subject (the project data) with a requirement (the regulatory provision) in order to generate a compliance assessment [5].

According to Eastman et al. [25], from a methodological standpoint, any CCC system articulates around four fundamental components: (1) rule formalisation, namely the translation of regulatory text into a machine-processable format; (2) model preparation, which ensures that the model contains the necessary data in the correct form; (3) rule execution, which applies the formalised requirements to the model to identify non-conformities; and (4) report generation, which produces clear and auditable outputs for the project stakeholders.

Among the four components, rule formalisation (1) constitutes the foundational step upon which all subsequent stages depend. For example, Solihin and Eastman [6] propose a four-class taxonomy. Class 1 rules check data explicitly present in the BIM dataset and require no transformation. Class 2 rules derive values not directly stored in the model through arithmetic or geometric operations. Class 3 rules require extended data structures for complex geometric, topological, and spatial processing, demanding solid modelling engines and graph processors. Class 4 rules require a proof of solution, entering the domain of expert systems where compliance must be actively demonstrated rather than simply verified against fixed criteria. This four-class taxonomy represents one of the first systematic proposals for the formalisation of normative rules in BIM-based compliance checking.

The effective implementation of CCC systems depends on the availability of structured, machine-readable building models and formalised rule sets. In the openBIM ecosystem, this infrastructure is provided by a set of complementary standards developed by buildingSMART International, which are discussed in the following section.

2.3. OpenBIM Standards for Validation: IFC, IDS and bSDD

IFC is an open international standard developed and maintained by buildingSMART International for the representation and exchange of BIM models across different software applications. The schema is formalised in the EXPRESS data modelling language (ISO 10303-11 [26]), while the main exchange is the STEP file format (ISO 10303-21 [26,27].

The IFC data model is hierarchically structured and object-oriented, organised around three fundamental constructs: IfcObjectDefinition, which defines physical and spatial entities; IfcRelationship, which expresses the relationships between them; and IfcPropertyDefinition, which specifies their properties. However, the significant extent and complexity of the schema introduce technical difficulties and redundancies in practice [28].

To complement the data infrastructure provided by IFC, buildingSMART International has developed two additional standards: IDS [29] and bSDD [30]. The two standards are specifically oriented towards formalisation and automated checking of information requirements.

2.3.1. IDS

The IDS formally defines the information requirements that a BIM model must satisfy [7]. Unlike traditional requirements documents produced in PDF or spreadsheet format which lack a formally verifiable structure, IDS adopts a file format that makes it processable by verification software while remaining readable by practitioners [7,9]. Cerovšek and Omar [4] highlight how IDS enables a white-box workflow, transparent and inspectable, in contrast to proprietary black-box validation workflows.

An IDS file allows the formalisation of requirements relating to the main categories of alphanumeric data contained in IFC: entities, classifications, attributes, property sets, materials, and units of measurement [7]. This standardised approach improves transparency in information exchange between project parties, and can be used as a contractual attachment and as a model quality verification tool across the different phases of the construction process.

Cerovšek and Omar [4] classify IDS-verifiable requirements into three categories: explicit checks, directly mappable to IFC entities, properties, or classifications; implicit checks, which involve derived values, relationships, or conditional logic; and unsupported checks, which cannot be validated due to structural limitations of the standard. Nuyts et al. [5] offer a complementary perspective, classifying regulatory requirements into five categories of constraints: information availability, value, relational, mathematical, and conditional. They demonstrate that IDS natively supports only the first three through its facet-based specification mechanism, while mathematical, conditional, and geometric–spatial constraints fall outside the capability of version 1.0.

The quantitative extent of these limitations is documented by Wrzosek et al. [31] on a real railway case study, where IDS covered approximately 40% of the requirements in an Exchange Information Requirement (EIR), with only around 30% verifiable without manual intervention.

The structural limitations of IDS version 1.0 have been documented across studies that proposed complementary solutions to extend its capabilities. In the context of digital building permitting, Fischer et al. [32] applied IDS to Austrian fire resistance regulations and identified three categories of structural gaps: the inability to filter elements based on characteristics of related elements, the absence of the IfcRelSpaceBoundary relation in the PartOf facet, and the lack of mechanisms to compare properties across multiple related elements. To address these limitations, the authors proposed targeted extensions to the IDS schema. The proposed extensions allowed 12 out of 25 regulations to be fully implemented, 8 to be partially implemented, and 5 to remain not implementable, primarily due to geometric and topological dependencies that fall outside the scope of IDS by design. Guntermann et al. [8] encountered a further structural limitation: IDS v1.0 does not support the validation of abstract IFCs and requires that the entities to be checked are defined explicitly. To work around this constraint, the authors developed a Python script that automatically manipulates the IDS file in XML format, duplicating the generic rules and assigning each to a specific instantiable IFC entity. The resulting IDS was then used as the basis for model validation.

2.3.2. bSDD

bSDD is an open complementary tool to IFC and IDS, designed for publishing and sharing standardised data dictionaries across the construction industry. bSDD implements ISO 23386 [33] and ISO 12006-3 [34], assigning each property a globally unique identifier (GUID) that ensures unambiguous machine-readable identification across platforms [7]. Each dictionary hosted on the official bSDD online platform [35] functions as a structured repository of property definitions, providing clear and consistent semantic descriptions that support correct interpretation of model information. bSDD can additionally store relationships between definitions and mappings between different classification systems, preventing divergent interpretations across tools and disciplines [8,36]. Unlike standard IFC property sets, bSDD allows organisations and standards bodies to publish their own custom dictionaries while maintaining full compatibility with the openBIM framework [7,8].

2.4. Applicability of CCC to Healthcare Regulatory Requirements

As discussed in Section 2.2, the application of CCC to healthcare facilities raises specific challenges stemming from the nature of the requirements contained in the accreditation regulations.

Automated and semi-automated compliance checking has so far seen only limited application to healthcare facilities, and existing studies have concentrated on narrow rule classes. Zhang et al. [37] examined rule representations for automated compliance checking in healthcare buildings, identifying eighteen core capabilities required to interpret complex regulations, such as requirements, applicability, and exceptions. Accessibility compliance has been addressed more recently by Haque and colleagues, who developed a semi-automated framework integrating BIM and Python for the assessment of Americans with Disabilities Act (ADA) requirements, initially in restroom areas [38] and subsequently extended to circulation spaces through the integration of a large language model [39]. Requirements management in healthcare BIM projects has instead been investigated by Baldauf et al. [40], who proposed a method for structuring and linking client requirements, including user, process, and regulatory requirements, to 3D digital models in order to facilitate value generation and design assessment. These works verify specific requirement classes, predominantly related to accessibility, in contrast to the full set of accreditation requirements addressed in the present study.

Beyond their thematic breadth, accreditation requirements also differ in the type of logical constraint they impose on the information model. This heterogeneity determines whether, and by what means, each requirement can be verified computationally. To characterise it, the accreditation prescriptions addressed in the present study were analysed through the constraint taxonomy of Nuyts et al. [5]. These prescriptions span all five constraint categories, as described below.

Information availability. Verifies whether the attribute or property required in the regulation is present in the information model. For instance, healthcare regulations may require the presence of specific properties relating to the surface finish of walls.

Value. Verifies whether a value is greater than, less than, or equal to a nominal value defined in the regulation. For instance, the minimum area of a bathroom may be required to be at least 9 m².

Relational. Verifies whether an element is in relation to another element as defined in the regulation. For instance, that a room is contained within a specific healthcare area.

Mathematical. Verifies whether the result of a formula calculated from multiple properties of the information model meets a defined threshold from the regulation. For instance, the minimum percentage of single-bed rooms within a healthcare unit may be required to be at least 10%.

Conditional. Verifies a property only if a preliminary condition is met. In regulation, this is typically expressed in an “if...then...” structure. For instance, if a room is classified as an inpatient room, it must contain a minimum set of furnishings and medical equipment.

Not all these constraint categories can be verified through IDS alone, as the standard does not natively support mathematical and conditional constraints. The aim of this study is to develop a methodology for the computational compliance checking of hospital buildings, integrating IDS into a Python-based validation engine to extend verification to these unsupported constraint types. The following section presents the proposed methodology, which is subsequently validated through a case study on a hospital facility in the Veneto Region of Italy.

3. Methodology

The proposed methodology aims to semi-automate compliance checking of hospital BIM models against healthcare regulatory requirements. As discussed in Section 2, the application of the IDS standard does not allow for the verification of all regulatory requirements, as it is only capable of natively handling information availability, value and relational constraints. For this reason, the methodology extends the functionality of IDS with a validation engine written in Python 3.14 that is capable of verifying conditional and mathematical constraints. The workflow is divided into two main macro-phases, excluding the project creation stage: (1) the analysis of healthcare regulations for the translation of requirements and (2) the execution of validation to verify the requirements (Figure 1).

3.1. First Phase: Analysis of Healthcare Regulations for Requirement Translation

This phase begins with an analysis of the relevant healthcare regulations. The analysis aims to create a bSDD for the unambiguous identification of elements and to translate regulatory requirements into IDS or Python rules according to the constraint type. This phase needs to be carried out only once for each regulation, as once the files have been produced, they can be reused for any BIM model underlying the same regulatory framework.

3.1.1. Unique Coding of Elements and Creation of the bSDD

To comply with healthcare regulations, each element must be assigned a unique identifier, as neither the IFC class nor the name is sufficient. The classes in the IFC data model (IfcSpace, IfcFurniture, IfcCovering, etc.) are too generic. For example, in healthcare regulations a space can be a patient room, a toilet or a corridor, and a piece of furniture can be a bed, a wardrobe or an armchair. Not even the standard PredefinedType covers the full range of possible cases. Finally, the element name would only be reliable if there were a naming standard shared by all designers, but it remains a fragile identifier prone to errors.

The methodology proposes the use of codes to unambiguously identify elements, which will then be included in a bSDD to ensure complete standardisation. For each code, the dictionary contains the unique identifier, the textual definition derived from the corresponding regulatory article and, optionally, the list of properties expected of the element.

To ensure the traceability of the process, each code should correspond directly to the regulatory provision from which it derives, and the coding system should be hierarchical. The code for a room must include, as a prefix, the code for the area in which it is located, and the code for a piece of equipment must include the code for the room for which it is intended. This hierarchical structure enables the validation engine to filter elements by code prefix when verifying conditional constraints. Once the bSDD has been created, it will be exported in JSON format to ensure it can be read by the validation engine.

3.1.2. Classification of Constraint Types and Translation of Requirements into IDS or Python Rules

Regulatory requirements are classified according to the constraint taxonomy of Nuyts et al. [5] presented in Section 2. This classification serves as the key for mapping the requirement to the appropriate type of translation into IDS or Python rules. Specifically, the following are converted: information availability, value and relational constraints into IDS; mathematical constraints into Python script; and conditional constraints into Python script and IDS, with the premise being verified using Python and the requirement using IDS (Figure 2).

The methodology involves generating a general IDS file for each healthcare area, containing all the directly applicable rules (information availability, value and relationship constraints) relating to the area and the rooms it contains. The mathematical constraints are translated into a Python script associated with the healthcare area, which verifies the set of mathematical checks required by the regulations for that area: checks on minimum floor area, dimensional ratios, relative number of elements, and so on. Finally, to check the conditional constraints relating to room equipment, a specific IDS file is generated for each regulated room. This file contains only the relational rules required by the regulations for that room. The conditional part of the requirement (i.e., the selection of the room to which the rule applies) cannot be verified via IDS, but is delegated to the main engine, which filters the IfcSpace elements and subsequently applies the IDS rules to the subset of elements contained within. By setting a filter via the main engine, the conditional constraint is reduced to a simple relational check and is therefore fully expressible by the IDS. The separation into multiple IDS files, a general file per area and a specific file per room, is not a syntactic choice, but a semantic one that reflects the different modes of rule application.

To summarise, the files generated will be: an IDS file containing the information availability, value and relational rules specified for each healthcare area; a Python file containing the mathematical rules specified for each healthcare area; and an IDS file containing the relational rules for each room within the specific healthcare area.

3.2. Second Phase: Execution of Validation to Verify the Requirements

The process of verifying and validating data extracted from the data models is carried out using a validation engine written in Python (Figure 3). Upon launch, the user is prompted to enter the path to the main folder where all project files are stored. Within this directory, the key element for data management is the Guide.xlsx file, a configuration spreadsheet that maps and organises the files so that they can be read correctly by the validation engine (Section 4.2.1). Based on the information extracted from the Guide file, the script identifies and proposes a list of specific healthcare areas for which the check can be initiated. Once the operator has selected the area of interest, the engine loads the relevant information template and associated files into memory. Subsequently, the validation process begins, structured in four sequential steps: (1) bSDD code validation; (2) general IDS validation; (3) custom Python validation; (4) hybrid validation of room furnishings (Section 4.2.2). At the end of the cycle, the validation engine returns a structured report containing the results of the checks (Section 4.2.2).

3.2.1. Guide File

The analysis of the regulations generates various files that will be used to carry out all the necessary validations. To simplify their association with the corresponding healthcare area, a Guide file in .xlsx format is used. The Guide file is organised into six columns: the name of the healthcare area and the names of the five files associated with it, namely the IFC model, the bSDD, the general IDS, the custom Python, and the Rooms Guide (

Table 1. Guide file.

Healthcare Area	IFC Model	bSDD	General IDS	Custom Python	Rooms Guide
Area 1	Area_1.ifc	NSRV.json	Area_1.ids	Area_1.py	Area_1.xlsx

). Each row corresponds to a specific healthcare area as defined by the regulations. Ideally, once the regulations have been analysed, only the IFC file will be modified for each project, as the remaining files are simply the translation of the regulations into rules.

The Rooms Guide is also an .xlsx file, and it serves as a reference for checking conditional rules, which require the use of a combination of Python and IDS, since the various rooms must first be filtered before the IDS rules can be applied. Thus, for each healthcare area, there is a Rooms Guide file listing the rooms, organised into three columns: room name, bSDD code, and IDS for the furnishings required within it (

Table 2. Rooms Guide file.

Rooms	bSDD Code	IDS for Furnishings
Room 1	Room code 1	Room_1_ furnishings.ids
Room 2	Room code 2	Room_2_ furnishings.ids

). Each Rooms Guide file will be created during the analysis of the regulations and associated with the specific healthcare area.

These two files form the basis for the Python validation engine and once set up, remain unchanged except for the reference IFC file. This allows the engine to be used to verify multiple projects that are subject to the same regulations.

3.2.2. Validation Engine

Once the validation engine has been launched, the user interacts with the command line to specify the working directory. The engine is then able to read the Guide file, and the user is prompted to select the healthcare area to be checked. Then the engine proceeds sequentially through four validation steps (

Table 3. Validation steps of the engine.

Step	Validation	Type of Constraint	Input File
1	bSDD code validation	Presence and correctness of the bSDD codes assigned to the elements	IFC model + bSDD (.json)
2	General IDS validation	Information availability, value, and relational constraints	IFC model + general IDS
3	Custom Python validation	Mathematical constraints not handled by IDS	IFC model + Python script (.py)
4	Hybrid validation of room furnishings	Conditional constraints on room specifications (IDS + Python filter)	IFC model + specific IDS + Rooms Guide (.xlsx)

):

Step 1—bSDD code validation. The aim of this step is to ensure that every space (IfcSpace) and item of furniture (IfcFurniture) is mapped in accordance with the semantic criteria of the reference bSDD. The validation engine loads the .json configuration file and extracts the list of accepted codes. It then performs the actual audit on the IFC model, categorising the elements into lists of correct, incorrect or unclassified components. This step is strictly preparatory to the subsequent ones, as the absence of a correct code would render the IDS rules structurally inapplicable.

Step 2—General IDS validation. In this step, the “direct rules”, information availability, value and relationship constraints are verified. The validation engine uses the xml.etree.ElementTree library to decode the XML structure of the IDS file. This process relies on dedicated routines to isolate the applicability and requirements nodes. At the same time, the algorithm queries the IFC model via the ifcopenshell library to collect the actual instance data, utilising targeted extraction routines for classification relationships, property sets, numerical quantities for area or volume metrics, and native attributes. Finally, the validation engine correlates the theoretical requirements with the actual data, determining whether the specification is met or breached. In particular, it coordinates the validation through dedicated matching routines that perform precise comparisons of textual equality or mathematical inequality.

Step 3—Custom Python validation. In the third step the validation engine executes rules that cannot be handled natively by the IDS (i.e., mathematical constraints), delegating their implementation to an external Python script specific to the healthcare area. The validation engine identifies the path of the previously mapped .py file, reads its contents and executes it dynamically at runtime, injecting the IFC model into the execution context. Once the dedicated function is detected in the external file, it is invoked by passing the model as an argument. This flexible extension mechanism allows the validation engine to remain unchanged whilst introducing advanced checks (e.g., calculations of air-to-light ratios or inter-parametric consistency).

Step 4—Hybrid validation of room furnishings. The final step addresses complex conditional constraints expressed in the logical form “if the room has classification X, then it must contain furniture with classification Y”. The methodology breaks down the constraint by handling the conditional part in the engine and the furniture requirement as a simple IDS specification. The validation engine retrieves the list of rooms from the Room Guide file, and for each room identified in the model, it analyses the spatial containment relationship (IfcRelContainedInSpatialStructure), isolating the furniture elements (IfcFurniture) actually contained within the IfcSpace. In parallel, the IDS of the furniture associated with that room is read and its specifications are scanned to extract the codes of the minimum required components. The final check compares the codes of the furniture present with those required. Matching is performed using an initial partial match criterion (prefix-based comparison), allowing the presence of furniture subcategories nested within the hierarchical structure of the adopted classification to be validated.

3.2.3. Results Report

At the conclusion of the validation cycle, the validation engine generates a text report summarising the outcome of the verification of the information model against the specified requirements. To ensure immediate readability and facilitate subsequent model correction activities, the results are formatted and categorised into four distinct macro-sections, corresponding to the verification steps implemented in the methodology. With regard to bSDD code validation, the report organises spatial and furnishing elements into three mutually exclusive lists, clearly distinguishing between classifications that are correct, incorrect or entirely missing from the reference bSDD. The General IDS Validation section isolates the global specifications, clearly separating the requirements that have been met from those that have gaps in the required attributes. The Custom Python Validation displays the results of algorithmic expressions and complex geometric–spatial checks, indicating whether they have passed or failed logically via explicit textual indicators. Finally, the hybrid validation of room furnishings analyses the compliance of the internal fittings in each functional unit to accurately identify any items of furniture that are included or missing.

4. Case Study and Results

This case study concerns a design alternative developed for a hospital in the Veneto Region, among several alternatives under consideration for the final design. For confidentiality reasons, the name and precise location of the healthcare facility, as well as the design firm that provided the BIM model, cannot be disclosed. The BIM model was shared with the authors by the design firm responsible for the project, under the condition of anonymity. The project was developed in accordance with the Veneto Region’s institutional accreditation regulations, structured across L.R. 22/2002 [22] and its implementing resolutions DGR n. 2266/2016 [23] and DGR n. 1732/2017 [24]. The aim is to verify whether the resulting information model complies with these requirements. From the hospital’s BIM model created using Revit 2025, only the inpatient ward was exported in IFC4 format [41] (Figure 4). The methodology is designed to process one healthcare area at a time, in accordance with the structure of the regulatory requirements. The inpatient ward selected for assessment comprises a total of ten patient rooms, divided between single rooms (one bed) and double rooms (two beds), along with a series of support and service areas necessary for the proper functioning of the ward, in accordance with the minimum regional requirements. It should be noted that the BIM model provided by the design firm did not always employ geometrically accurate representations of the actual furniture and equipment; in several instances, generic objects (e.g., a chair) were used to represent different items (e.g., a bed), while being correctly renamed and classified according to the appropriate IFC entity and property set. As a result, the geometric representation may not always correspond to the actual physical object, although the semantic classification remains reliable for compliance-checking purposes.

All the material related to this case study is publicly available at the following repository: https://github.com/gMarcellino/PythonIDS_HealthcareFacilities_checking, accessed on 25 August 2026.

4.1. First Phase: Analysis of Healthcare Regulations for Requirement Translation

4.1.1. Unique Coding of Elements and Creation of the bSDD

Following the defined methodology, the Veneto Region’s healthcare regulations were analysed to create a bSDD containing unique codes for the elements, which must then be linked to the model’s objects during its implementation. The bSDD for the inpatient ward was structured as follows:

Healthcare Area: A group of rooms with the same intended use. The official alphanumeric UDO (“Unità Di Offerta”, in English: service provision unit) identifier issued by the Veneto Region is used as the root code. For example, the inpatient ward (in Italian “Reparto di Degenza”) is mapped using the string 10.200.DEG [42].

Ward rooms: Individual rooms with specific functions within the healthcare area. The code is generated by combining the UDO area prefix with the identifier of the regulatory requirement that makes it mandatory. For example, an inpatient room is assigned the code 10.200.DEG01.AU.2.1.

Minimum furnishings: Furniture, fittings and equipment required in a specific room. In line with the principle of hierarchical encapsulation, furnishings inherit the code of the room in which they are located. For example, the articulated bed required in inpatient rooms is coded as 10.200.DEG01.AU.2.1.2. In this way, the Python script can perform a partial string filter (e.g., 10.200.DEG01.AU.2.1.) to verify the spatial containment relationship.

Performance materials: Specific characteristics for wall coverings, flooring or other surfaces. The properties of interior coverings directly adopt the reference item code, which is derived from the healthcare area but not directly from the room itself. For example, a requirement for waterproof and washable walls up to a height of 2 metres is associated with the code 10.200.DEG01.AU.1.18.

The bSDD dictionary was created using the usBIM.bSDDeditor module of ACCA Software’s usBIM platform [43], in accordance with the specifications of the International Framework for Dictionaries (IFD) standard (ISO 12006-3). It should be noted that, although usBIM is a proprietary tool, it allows certain modules to be used free of charge following registration for a free account. In particular, usBIM.bSDDeditor enables users to create a bSDD dictionary at no cost and to submit it directly for publication on the official buildingSMART International portal. However, the decision to create the dictionary using usBIM represents only one of the possible implementation options. Indeed, dictionaries compliant with the bSDD standard can also be created and managed using open-source tools and libraries, without relying on proprietary platforms. Examples include the bSDD-Toolkit (an open-source editor for bSDD) and the bSDD Excel Template (the official template provided by buildingSMART on its GitHub repository [30]). The resulting dictionary (NSRV.bsdd) has been uploaded on a trial basis to the official buildingSMART International portal to allow it to be exported in the JSON format, but it is not currently available as further studies are required to fully formalise it.

4.1.2. Classification of Constraint Types and Translation of Requirements into IDS or Python Rules

Following the methodology described in Section 3, the regulatory requirements constraints applicable to the inpatient ward were analysed and translated into computational rules. The analysis covered a total of 35 regulatory requirements applicable to the inpatient ward, and their translation into computational rules is set out in

Table 4. Distribution of regulatory requirements by constraint type and validation tool.

Requirements	Constraint Types	Tool	Number	Percentage
Information availability requirements of the rooms of inpatient ward	Information availability	IDS	11	31.43%
Value requirements of the rooms of inpatient ward	Value	IDS	5	14.29%
Minimal outpatient clinic furnishings	Conditional	Python + IDS	7	20.00%
Minimal inpatient room furnishings	Conditional	Python + IDS	7	20.00%
Hydro-sanitary equipment in toilets	Conditional	Python + IDS	2	5.71%
Geometric analyses and ward indices	Mathematical	Python	3	8.57%
Total requirements	-	-	35	100%

.

The IDS, version 1.0, was used to directly formalise 32 rules (direct and conditional, accounting for 91.4% of the total), utilising the visual interface of ACCA Software’s usBIM platform. In detail:

• 16 Direct Rules were applied directly to the entire IFC file to verify the information availability and value requirements of the rooms of inpatient ward (respectively 11+5 rules). For example, the rooms of inpatient ward must have a wall finish of type 10.200.DEG01.AU.1.18 and a minimum wall finish height of 2 m.
• 16 Hybrid Rules were used to manage conditional constraints relating to internal fittings (7 for inpatient room, 2 for toilets, 7 for the outpatient clinic). To overcome the IDS’s inability to check nested conditions, a methodological breakdown was adopted: the validation engine first isolates the target rooms, whilst the IDS rule is limited to checking that the furniture is present within the filtered subset. For example, the inpatient room (10.200.DEG01.AU.2.1) must contain the articulated bed 10.200.DEG01.AU.2.1.2.

The limitations of IDS when dealing with complex mathematical constraints (in this case three constraints, accounting for 8.6% of the total) necessitated the development of a custom rules file in Python, programmed using the Visual Studio Code editor v1.134 [44]. The script handles three key rules:

• Verification of the minimum percentage of single rooms: Counting the number of IfcSpace instances classified as single rooms in relation to the total number of rooms and checking whether the minimum threshold of 10% set by the standard has been exceeded.
• Ratio between toilets and beds: Algorithmic calculation of the theoretical requirement for toilets (one toilet for every four beds, rounded up) and comparison with the actual number of toilets modelled.
• Maximum number of beds per room: Checking that the care standard of four beds per inpatient room is not exceeded.

4.2. Second Phase: Execution of Validation to Verify the Requirements

4.2.1. Validation Engine

The validation methodology described previously was tested in practice on the Inpatient Ward. After launching the validation engine and selecting the folder containing the files, the target area for the check was selected. Upon receiving the input, the engine dynamically loaded the ward-specific files into memory, retrieved from the Guide file, namely: the Inpatient_Ward.ifc model, the NSRV.json bSDD, the General_IDS.ids file and the Inpatient_Ward.py script dedicated to the mathematical constraints. At the same time, the algorithm processed the supporting file Rooms_Guide.xlsx to index the rooms to be subjected to spatial filtering and the corresponding IDS codes for the furnishings. The validation engine then carried out the checks sequentially: first the bSDD semantic audit, then the IDS verification of direct rules, followed by the dynamic execution of Python rules and, finally, the hybrid validation of the rooms, isolating the internal furnishings via the spatial containment relationship. The workflow concluded with the generation of a detailed text-based report on the terminal, structured with graphical logs to enable the immediate identification of design non-conformities.

4.2.2. Results Report

The application of the methodology to the inpatient ward model made it possible to successfully assess 100% of the 35 requirements under review. The detailed reports generated at the various stages of the computational validation engine highlighted specific issues relating to information and design, which are summarised below.

Step 1—bSDD code validation. The cross-check against the bSDD has demonstrated the importance of this preliminary stage in eliminating false negatives. For example, regarding incorrect classifications, the engine identified numerous native elements described as ‘Single-door cupboard’ and ‘Shelving furniture’, to which the incorrect code “E2010200” had been assigned, a code not mapped within the reference bSDD. Regarding missing classifications, several key spatial entities (e.g., rooms designated as storage, hallway, and lift shafts) were found to be completely lacking a classification code in the IFC model.

Step 2—General IDS validation. A check of the direct IDSs revealed that four rules relating to the minimum mandatory ward rooms had not been met. Specifically, the engine reported that the following spatial entities were missing and had not been modelled within the ward area: 10.200.DEG01.AU.1.1.5 (Equipment storage room), 10.200.DEG01.AU.1.1.7 (Meal distribution room), 10.200.DEG01.AU.1.1.9 (Visitors’ waiting area), 10.200.DEG01.AU.1.1.10 (Room for viewing/holding of deceased persons).

Step 3—Custom Python validation. The algorithmic checks carried out using the Python rules file returned a positive result for all the numerical and planning constraints analysed. With regard to the percentage of single rooms, the model shows a total of 10 rooms, of which 2 are single rooms. The resulting percentage of 20.00% comfortably meets the minimum regulatory requirement of 10%. Furthermore, the toilet-to-bed ratio showed that, given a total care capacity of 18 beds distributed across the ward, the theoretical requirement calculated by the script corresponds to 5 toilets. As the model includes 10 compliant toilets, the rule is satisfied. Finally, regarding the room overcrowding check, the result is that no room had more than the limit of 4 beds.

Step 4—Hybrid validation of room furnishings. The analysis of the containment reports examined the consistency of the interior furniture in individual rooms, highlighting both physical omissions and semantic calculation anomalies. For example, requirement 10.200.DEG01.AU.1.4, relating to the hand-washing basin for staff in the rooms, generated a false negative: the object is graphically included in the model but was rejected by the algorithm due to the semantic coding error identified in step 1. Regarding the set of criteria from 10.200.DEG01.AU.2.2.2 to 2.2.7, which defines the mandatory specialist medical equipment (including the medicines cabinet (.2), the emergency trolley complete with cardiac monitor and defibrillator (.4), the treatment trolley (.5) and the dressing trolley (.6)), the validation revealed a complete physical omission in the model, confirming a design non-conformity. Finally, within the medical examination room, the codes 10.200.DEG01.AU.2.2.1 (examination bed) and 10.200.DEG01.AU.2.2.3 (desk and chairs) were found to be correctly present.

4.3. Accuracy and Performance Evaluation

4.3.1. Accuracy Validation

To assess the accuracy of the automated engine, its output was cross-checked against a manual review of the same 35 requirements, conducted directly on the IFC model and the original regulatory text. This manual review provided the reference baseline (ground truth) for the comparison, and is independent in the sense that each manual verdict was established without reference to the output of the automated engine. The comparison yielded 20 true positives, 12 true negatives, 2 false negatives and 1 false positive, corresponding to an overall agreement of 91.43% (the proportion of the 35 requirements for which the automated and manual verdicts coincided). Both false negatives were attributable to upstream semantic issues rather than errors in the validation logic: in one case (requirement 10.200.DEG01.AU.1.1.6), the corresponding room is physically present in the model but lacks a classification code, so the engine could not detect it; in the other (10.200.DEG01.AU.1.4), the hand-washing basin is present but was rejected due to the incorrect bSDD classification identified in Step 1 (Section 4.2.2). The single false positive (10.200.DEG01.AU.2.2.3) revealed a limitation in the granularity of the IDS translation: the underlying regulatory requirement mandates the joint presence of a desk and chairs, and so a single bSDD code was used to represent both elements, but only one object was modelled under this classification. The engine correctly detected the presence of a classified element and therefore reported the requirement as satisfied, while manual inspection judged it unsatisfied because the model does not distinguish whether the single object represents one or both furnishing types.

4.3.2. Computational Performance

The validation engine was executed on a Lenovo Legion Y520 laptop (Windows 10, Intel Core i5-7300HQ CPU @ 2.50 GHz, 16 GB RAM).

Table 5. Execution time per validation step.

Step	Execution Time (s)
Step 1—bSDD code validation	0.035
Step 2—General IDS validation	0.364
Step 3—Custom Python validation	0.015
Step 4—Hybrid validation of room furnishings	0.035
Total	0.449

reports the execution time of each of the four validation steps, measured as the average of four consecutive runs (individual runs varied by less than 50 ms per step).

The Inpatient Ward model comprises 48 IfcSpace instances, 128 IfcFurniture elements, and 70,922 total IFC entities. Loading the model into memory via ifcopenshell required an additional 0.585 s on average, exceeding the combined duration of the four validation steps. Among the four steps, Step 2 (General IDS validation) accounted for approximately 81% of the total validation time, as it requires iterating over every IfcProduct instance in the model for each IDS specification until a match is found; this nested-loop structure is the primary computational bottleneck of the current implementation. Steps 1, 3 and 4 operate on comparatively small, pre-filtered subsets of the model (IfcSpace and IfcFurniture instances, or single-room containment queries) and each complete in under 40 ms. For a model of this size, overall execution time remains negligible from a practical standpoint (under half a second). However, since Step 2 scales with the product of the number of IDSs and the number of IfcProduct instances, execution time is expected to grow accordingly on larger and multi-area models, a factor that should be assessed in future work.

5. Discussion

The paper proposes a solution to the structural limitations of IDS through its integration with Python scripts. The case study confirmed the effectiveness of this methodological choice, successfully verifying the regulatory requirements applicable to the inpatient ward. Without Python integration, only 45.71% of the requirements would have been verifiable, specifically the 11 information availability requirements (31.43%) and the 5 value requirements (14.29%), which are natively supported by IDS. The remaining 54.29% required complementary approaches: 45.71% of conditional requirements were addressed through a hybrid Python-IDS mechanism, while the 8.57% of mathematical requirements were handled exclusively by Python. This empirical finding is consistent with the order of magnitude reported by Wrzosek et al. [31] for a railway infrastructure context, where IDS covered approximately 40% of Exchange Information Requirements, suggesting that the structural ceiling of IDS is a domain-independent phenomenon rather than a context-specific finding.

These findings also help position the proposed methodology relative to other compliance-checking approaches. Rather than replacing IDS with more expressive but less interoperable approaches, the methodology extends it through an external validation engine, allowing IDS to continue handling the constraint types it manages natively, while Python addresses those it cannot. This choice contrasts with Linked Data-based approaches such as SHACL, which, as demonstrated by Nuyts et al. [5], supports all five constraint categories through its SHACL-SPARQL extension. However, SHACL operates on RDF data and requires the prior conversion of the IFC model into an RDF graph via ifcOWL, a step that introduces additional dependencies and potential information loss. In practice, existing converters either produce complex graphs based on the full ifcOWL ontology or rely on simplified but incomplete linked construction data ontologies [5,45]. The comparison therefore involves a trade-off rather than a strict ranking. SHACL achieves native coverage of all five constraint categories, whereas the proposed methodology reaches comparable coverage only by adding dedicated Python routines for the requirement classes that exceed IDS. In return, the proposed methodology avoids any conversion of the model and operates on the native IFC file, without the additional dependencies or the risk of information loss that the RDF transformation entails.

This approach mirrors the strategy independently adopted by Guntermann et al. [8] in the domain of circular design, where a Python script was used to compensate for IDS limitations on abstract IFCs, a convergence that confirms external scripting as a viable general-purpose extension pattern for IDS-based workflows. It differs, however, from the approach proposed by Fischer et al. [32], who address IDS limitations by extending the standard schema.

A small number of studies have nonetheless applied compliance checking within the healthcare domain itself, and a direct comparison with them, introduced in Section 2.4, further clarifies the position of the present work. Zhang et al. [37] characterise the capabilities that a rule representation must possess to express healthcare regulations, but they remain at the level of rule representation and do not carry the process through to verification against a model. The present study, by contrast, executes the checks on an IFC model and reports concrete non-conformities. Haque et al. [38] and Haque and Kim [39] are the closest precedents, since both combine a BIM model with Python for healthcare compliance checking. However, they target only accessibility (ADA) requirements, they rely on geometric and dimensional rules, and they operate through a proprietary Revit-based toolchain, with the more recent work adding a large language model for rule interpretation. The present study instead addresses the full range of regional accreditation requirements, spanning information availability, value, relational, conditional, and mathematical constraints, and does so through the openBIM standards IDS and IFC, extended by Python only where these standards prove insufficient. Baldauf et al. [40] address a different stage of the process, namely the structuring and linking of client requirements to the model, rather than the automated verification of compliance that is the focus here.

Beyond this positioning, the choice to extend rather than replace IDS also carries a number of methodological advantages. The proposed methodology avoids conversions by operating directly on the native IFC file via ifcopenshell and preserving its integrity throughout the verification process. Furthermore, IDS rules can currently be authored through dedicated graphical tools, such as the usBIM platform used in this study, without requiring knowledge of XML or SPARQL syntax, lowering the technical barrier for practitioners compared to the authoring of SHACL shapes.

Although schema extensions may progressively expand the native coverage of IDS, the present methodology deliberately avoids modifying the standard. This choice preserves its native advantages, such as open format, software portability, human readability, and white-box transparency, while compensating for its structural limitations through Python. The tools adopted in this methodology (the IDS standard, the ifcopenshell library, and the Python validation engine) together ensure that the workflow is accessible without licensing costs, reproducible by third parties, and independent of proprietary software ecosystems. This is a relevant consideration in public procurement contexts such as the Italian healthcare sector, where transparency and auditability of verification processes are regulatory requirements.

Another key advantage of the methodology is the decoupling between the verification logic and the regulatory knowledge it encodes. The validation engine does not embed any project-specific information: file paths are provided by the user at runtime, and the association between files and healthcare areas is managed through the Guide file. Therefore, the regulatory analysis phase needs to be conducted only once per regulation, and the resulting files (the bSDD, the IDSs, and the Python scripts) can be reused for any BIM model subject to the same regulatory framework. Extending the methodology to a new regulation requires only the preparation of the corresponding input files, without modifying the engine itself.

Overall, the proposed methodology is best understood as a deliberate compromise between expressive coverage and preservation of the standard. It does not provide the self-contained expressiveness of SHACL, nor the potential long-term native coverage of a schema extension of the type proposed by Fischer et al. [32], and it requires dedicated routines to be written and maintained for the requirement classes that exceed IDS. In return, it preserves the interoperability, human readability, and transparency of the unmodified standard, and it avoids model conversion entirely. This trade-off is most favourable where openness, auditability, and independence from proprietary ecosystems are paramount, and less advantageous where the priority is maximal automated coverage obtained with the least possible custom code.

Beyond these methodological considerations a critical observation emerging from the case study concerns the distinction between regulatory compliance of the design and informational compliance of the BIM model. A project may fully satisfy the applicable regulatory requirements in its spatial and functional configuration, yet the corresponding BIM model may fail verification due to missing classifications, incorrect property assignments, or incomplete semantic encoding. The quality of the verification output therefore depends not only on the regulatory correctness of the design, but also on the rigour with which the model has been developed and annotated. This distinction has practical implications: non-conformities identified by the validation engine may require either a design revision or a model correction, and the two interventions are fundamentally different in nature and effort.

Alongside these advantages, the study also presents a number of limitations. A limitation emerged from the manual accuracy validation (Section 4.3.1): where a single bSDD code is used to represent a compound, regulatory requirement involving multiple distinct object types (e.g., “desk and chairs”), IDS can only verify the presence of a classified element, not whether all the constituent components mandated by the regulation are actually present. This granularity mismatch between the regulatory text and the classification schema represents an additional structural constraint of IDS, alongside the mathematical and geometric limitations already discussed, and suggests that finer-grained bSDD classification, assigning a distinct code to each individually mandated object, would further reduce the residual error observed in the validation.

Regarding scope, a limitation concerns the scope of the validation, which was carried out on a single healthcare area, namely one inpatient ward of a single hospital. The results should therefore be regarded as demonstrative rather than as evidence of general applicability. By design, the methodology processes one healthcare area at a time, in accordance with the structure of the accreditation requirements, which are organised by service provision unit. This modularity is advantageous for large projects, since a complete hospital can be verified area by area rather than through a single monolithic check. As noted above, the same reuse logic that allows a new regulation to be encoded into a fresh set of input files also applies to new healthcare areas and to other building typologies, without any modification of the validation engine. These extension mechanisms, however, have not yet been tested empirically. Future work will validate the methodology across several healthcare domains and on larger, multi-area models. It will also apply the methodology to regulatory frameworks other than the Veneto accreditation requirements, so as to assess its scalability and to confirm whether the coverage observed in this case study holds more generally.

A further consideration concerns the security and version control of the external Python scripts on which the validation engine relies. Because these scripts execute with the same privileges as the user running them, their provenance must be verified before use, and practitioners should apply the same scrutiny to externally sourced code, including that developed here, as to any other code integrated into a professional workflow. Version control is equally important, since the scripts, IDSs, and bSDD codes jointly define the regulatory logic applied at runtime: modifying any one of these files can change the outcome of a subsequent execution. All materials produced in this study are maintained in a public GitHub repository under version control, with releases tied to their corresponding regulatory framework and hospital typology, so that any output can be traced to the exact files used to generate it. Equivalent version control and code-review practices are recommended for any future extension of the methodology.

The current implementation is not integrated with BIM authoring tools, and such integration represents an important direction for future development. A plugin-based connection with Revit, for instance, could allow the validation engine to be invoked directly from within the modelling environment, removing the need to operate a separate command-line tool. This would also open the way to real-time feedback during design, such as highlighting non-conforming elements directly in the 3D view as the model is developed, rather than only at the end of a design phase. Realising this would require translating the Python-based checks into a form compatible with the authoring software’s own API and data model, and reconciling the different pace of interactive modelling with that of rule-based verification. On the adoption side, designers would need to become familiar with the semantic coding conventions underlying the methodology, namely the bSDD classification scheme and the property structure required by the IDS rules. This represents a non-trivial learning curve, particularly for practitioners without prior exposure to structured classification systems, and would likely require dedicated training or in-tool guidance to be adopted effectively in professional practice.

Finally, the system as currently implemented presents interface-level limitations. The validation engine operates exclusively through a command-line interface, requiring users to interact with a terminal and to have basic familiarity with file system navigation. The absence of a graphical user interface represents a significant barrier to adoption in professional design workflows, where practitioners typically operate within BIM authoring environments. Validation results are returned as a structured text report on the terminal and are not exported. This requires the designer to manually locate non-conforming elements within the BIM model, increasing the time and effort required for model correction.

6. Conclusions

This paper addressed the challenge of semi-automating compliance checking of hospital BIM models against healthcare regulatory requirements, with specific reference to the accreditation framework of the Veneto Region. Its main scientific contribution is a semi-automated compliance checking methodology that extends IDS with a Python-based validation engine, capable of addressing the full range of constraint types identified in the regulatory framework. In developing this methodology, the study also assessed the applicability of IDS to healthcare regulatory requirements, showing that the standard natively supports information availability, value, and relational constraints, while mathematical, geometric–spatial, and conditional constraints lie outside its current scope.

The methodology was structured in two phases: the analysis of healthcare regulations for the translation of requirements into IDS and Python rules, and the execution of validation through a four-step engine. The application to a real-world inpatient ward design alternative model demonstrated that the methodology was able to assess 100% of the 35 regulatory requirements under review, identifying both informational non-conformities (such as missing or incorrect bSDD classifications) and design non-conformities (including absent mandatory spaces and missing specialist medical equipment).

Future developments should focus on the integration of validation results directly into BIM authoring environments through BCF export, the extension of the methodology to additional healthcare areas and other regional regulatory frameworks, the simultaneous validation of multiple healthcare areas within a single workflow, and the formalisation of the bSDD as a shared national reference for healthcare facility design.