Integrating OpenBIM and LCA for Sustainable Construction: A Systematic Review and Proposed Research Framework

Abstract

In recent years, an essential approach for promoting and implementing efficient sustainable construction practices has been considered through the integration of Building Information Modeling (BIM) and Life-Cycle Assessment (LCA). The introduction of OpenBIM, which is characterized by its collaborative and interoperable nature, offers an ideal framework to enhance this integration. This paper conducts a systematic review of the literature concerning the practices applied to integrate BIM and LCA, focusing on the present trends, challenges, and opportunities as well as on how the concept of OpenBIM can be applied to tackle the identified issues and gaps. Based on an intense review of the literature to identify the ways currently used to exchange data, this paper proposes a robust framework to create Information Delivery Specifications (IDS) as a solution to the identified gaps to attain an effective implementation, ultimately contributing to sustainable buildings’ practices and enhancing the integration of OpenBIM and LCA. OpenBIM emphasizes interoperability and collaboration by using open standards like Industry Foundation Classes (IFCs), which, when combined with LCA, offer a powerful method for the practice of sustainable building and provide a transparent evaluation of the environmental impacts of building materials and processes. This paper explores the definitions, key concepts, types of the exchanged data, and methods of integration and therefore provides insights into their potential in addressing the gaps that the construction industry is currently facing. The framework of integrating OpenBIM and LCA will be developed as a tool; therefore, it will combine an automated validation option by using IDS, create an enriched IFC file(s), dynamically map the data to an external LCA repositories, and incorporate feedback and reporting mechanisms. All those will be combined to address the most persistent shortcomings in the reviewed studies related to the integration of BIM and LCA. The framework will promote a holistic approach covering the early design benchmark to the detailed Whole Building LCA (WBLCA), including the operational and end-of-life phases. This next-generation workflow will align closely to the principles of OpenBIM, leading to improvement in the efficiency, accuracy, and deeper understanding of the environmental impacts by stakeholders over the construction lifecycle of buildings.

1. Introduction

The Architecture, Engineering, and Construction (AEC) industry relies on consistent collaboration through iterative models to share information [1] and, therefore, is undergoing a significant deviation toward digitalization with an increased demand for the use of Building Information Modeling (BIM) in all project stages [2]. The design of a building progresses through multiple stages, where each stage focuses on a well-defined task with multiple design and engineering objectives. The BIM concept supports this process through a well-structured method to create, manage, and exchange semantically rich 3D models [3].

Integrating Life Cycle Assessment (LCA) as a method to assess the environmental impacts of building materials [4] and processes from cradle to grave into BIM models requires comprehensive coordination among the different stakeholders [5]. To enhance the practices of sustainable construction, detailed geometric and semantic information from BIM models needs to be incorporated with LCA tools to assess the environmental impacts. This would help create a quantitative framework to assess the environmental performance of different design options and their associated materials, which would help make informed decisions that reduce the negative environmental impacts [6,7]. Although the use of the BIM concept has introduced many advanced solutions, some challenges persist, particularly in achieving seamless integration between BIM and LCA. These challenges are clearly noted in most of the studies that had been published until now, which focused on the proprietary formats of data and lacked standardized data exchange protocols [8].

To meet the increased demand for sharing the information in digital format, it is essential to move from a restricted digital environment, referred to as closedBIM, to an OpenBIM process. In a closedBIM environment, the project stakeholders work together on a unified 3D model of a building that is created in a particular (proprietary) data format, which is only possible when supported by software from a single vendor’s application suite [9].

OpenBIM, however, is a collaborative approach for exchanging information in the built environment that enables stakeholders to work across various platforms and disciplines. This approach is facilitated by OpenBIM standards, such as Industry Foundation Classes (IFC), Information Delivery Manual (IDM), Information Delivery Specification (IDS), Model View Definition (MVD), and BuildingSMART Data Dictionary (BSDD) [10,11]. OpenBIM standards are the basis for exchanging information, which enhances the efficiency of data integration from the individual stages of construction, that leads to an improved project management, reduced errors, better coordination between stakeholders, and ultimately time and cost savings [12]. This would allow various parametric tools, which are typically utilized by stakeholders in collaborative processes, to automatically share this data without the need for translation or human involvement [13].

This paper reviews the studies published until recently and explores the definition, key objectives, and key challenges of the current state of integrating BIM and LCA, the integration methods that employ open standards, and OpenBIM with LCA. Through the comprehensive analysis, we found that previous studies have explored various integration strategies, but there remains a lack of a clear, OpenBIM-based structured workflow that addresses information requirements, model validation, and a consistent mapping system.

Many existing IFC-based studies have focused on the potential of neutral data exchange [5,9,14]; however, many still rely on project-specific naming conventions [15,16,17] and software-specific assumptions associated with particular BIM plug-ins, APIs, and LCA datasets [18,19,20]. Although IDS has been introduced to validate information requirements in OpenBIM workflows [11,12,21], its application in BIM–LCA integration remains limited. Consequently, existing IFC-based BIM–LCA workflows provide limited support for verifying, prior to assessment, whether the model contains the required quantities, material properties, classifications, and LCA-related parameters in a consistent and machine-checkable format [5,14,18,22].

To address this gap, this study proposes a comprehensive framework to enhance the integration that differs from prior IFC-based BIM–LCA integration studies by combining three complementary components: first, the use of IDS to define and validate the LCA-related information requirements in IFC models; second, the use of structured naming conventions and classification-based mapping to improve the consistency and traceability of links between IFC entities, building elements, materials, and Life Cycle Inventory (LCI) datasets; and third, the development of an enriched IFC-based workflow that supports dynamic mapping to external LCA repositories and provides feedback to improve model completeness and assessment reliability. Therefore, the contribution of this study is not limited to using IFC as a neutral exchange format but also extends to a more comprehensive OpenBIM-based information exchange framework for standardizing and improving BIM–LCA integration within the practice of AEC sector.

2. Literature Review and Methods

2.1. Search Strategy for a Systematic Literature Review Approach

The methodology applied in this study followed the Preferred Reporting Items for Systematic Reviews and Meta-Analyses (PRISMA) guidelines, which are adopted from a study published by [23] to bring transparency in the selection and assessment of published studies, while the Web of Science Core Collection (WoSCC) and Scopus were used for the literature retrieval process to thoroughly examine the current studies that focus on the integration of OpenBIM and LCA for sustainable construction. Those were selected for their broad range of peer-reviewed journals and conference proceedings in engineering, architecture, and construction, where publications from 2016 to 2025 were covered to capture a decade of research studies to reflect the current trends and advancements. To ensure consistency and accessibility to the required data, only the articles and conference papers that were published in English were included. The utilized strategy was carefully selected to search the articles by using keywords and Boolean operators to effectively collect only the relevant studies. The full list of search strings and the number of retrieved records for each search step are provided in Supplementary Material Table S1 and the PRISMA checklist in Supplementary Material Table S2.

2.2. Selecting Keywords and Studies

For a comprehensive search of the relevant studies, a set of search queries was created using a combination of key terms and specific concepts related to BIM, LCA, open standards, data structures, and classification systems. The selected keywords were based on their frequency in the literature and their significance and relation to the current research objectives. The keywords’ selection, as outlined in Supplementary Material Table S1, was created so that it covered a wide range of research, starting from core concepts related to the integration of BIM and LCA, including “Building Information Modeling” and “Life Cycle Assessment”. Thenceforward, terms like “OpenBIM”, “Industry Foundation Class”, and “IFC” were used to search for the studies that involved open standards and interoperability. Data structures and specifications, such as “Information Delivery Specification”, “Level of Detail”, naming conventions, and classification systems like “Masterformat”, “Uniformat”, and “UniClass” were included to identify the studies that stressed on data structuring and information exchange. After all, the integration’s challenges were denoted by terms like “data mapping”, “information exchange”, and “nomenclature”.

The records were compiled through an extensive search using predefined strings during the “Identification” step for a thorough collection of potentially relevant studies, as shown in Figure 1. During the “Screening” step and to eliminate duplications, studies that were in both databases were identified, and the remaining records were examined based on their titles and abstracts to assess their relevance to the objectives of this study, while the reasons for exclusions were documented when necessary. During the “Eligibility” step, the articles’ full texts, which passed the screening step, were examined, and therefore, each article was assessed to evaluate its relevance and impact on the current study as well as the methodological quality of the published studies to ensure reliable findings. In the “Inclusion” phase, the studies that fulfilled all the set criteria were chosen for the systematic review and were incorporated into the qualitative synthesis, which served as the foundation for additional analysis. The complete PRISMA 2020 flow diagram process is illustrated in Figure 2.

2.3. Extracting Information from the Existing Studies

Information from the included studies was extracted, as illustrated in Figure 3. The collected information covered the following essential categories: Bibliographic Details, which encompassed the authors names, year of publication, title, and the journal or conference in which the study was published. The focus, objectives, scope, and the aspects of integrating BIM with LCA that needed to be explored were outlined for each study to help in creating a critical approach for analysis. Those aspects included the tools and software utilized; the formats of the exchanged data, such as IFC, the integration techniques, and the use of the open standards; and the utilized data structures and classification systems, which included the Level of Detail (LOD), the naming conventions, and the frameworks like Masterformat, Uniformat, UniClass, and IDS. Lastly, the collected data was combined, and the identified limitations were noted to categorize the potential areas for future research and to create a thorough overview of the existing studies related to the integration of OpenBIM and LCA.

2.4. Bibliometric Analysis

To examine the published research trends and thematic domains, a bibliometric analysis was essential to create, and therefore, in this study, the VOSviewer 1.6.20 software was utilized [24]. Data from the Web of Science Core Collection and Scopus was imported into VOSviewer to create and to visualize the bibliometric networks and thus to have insights into the research trends and identify the gaps in the literature that are related to the integration of BIM and LCA. Then, a keyword co-occurrence network was created to identify the significant research themes and their evolution over the time. This network provided a thorough map of the research area and showed how various themes (keywords) were connected [24]. As shown in Figure 4, BIM, being identified as the most common term within the selected articles, was essential to the research network (was centrally located). BIM’s application within the different fields is shown, as illustrated in Figure 3, with other terms like LCA and IFC, highlighting its crucial role in evaluating the environmental impacts and enabling data interoperability.

Concepts, such as interoperability, which were directly related to BIM and IFC, emphasized the significance of seamless data exchange and integration between the different platforms. Terms like sustainability and embodied energy underline the shift towards evaluating and enhancing the environmental performance in buildings. In contrast, words such as optimization and construction highlighted the continuous work to refine processes using advanced modeling and analytical methods. The network has identified emerging topics, such as digital construction and digitalization, highlighting an increased interest in more sophisticated digital modeling methods and automated construction techniques for sustainable practices. OpenBIM, as a key theme, promotes open standards such as IFC, which can be employed to integrate environmental impact’s data into BIM models. This would permit comprehensive environmental evaluations and sustainable construction practices by incorporating essential standards like the Interoperability Data Model and MVD to enhance the data consistency, as shown in Figure 3, where the connections to OpenBIM and IFC do support such an option.

The results of the bibliometric analysis also indicated that the relatively weak presence of IDS, classification systems, and LCI-related terms suggests that the literature has not yet fully integrated information requirement management into environmental assessment workflows. One possible reason is that IDS has mainly been introduced in the OpenBIM context to define and validate exchange requirements, whereas its application to BIM–LCA workflows requires a more specific translation of LCA needs into machine-checkable model requirements. For example, quantities, material properties, classifications, units, service life assumptions, and links to LCI datasets must be clearly specified before they can be validated through IDS. This additional step may explain why IDS appears only as an emerging and weakly connected topic in the current BIM–LCA literature.

A similar issue can be observed for classification systems. Although classification systems are important for organizing building elements and supporting information exchange, their use in BIM–LCA integration remains limited because they do not always align directly with the structure of BIM objects or LCI databases. As a result, one-to-one mapping between IFC entities, classification codes, BIM materials, and LCI datasets is not always possible. This explains why several studies still rely on project-specific naming conventions or customized data structures to connect BIM information to environmental datasets.

Although IFC-based workflows have shown clear potential for neutral data exchange and interoperability, their practical implementation is still affected by inconsistent IFC exports, incomplete material and quantity information, and variations in how authoring tools represent objects and properties. In addition, several automated or semi-automated workflows remain dependent on specific BIM tools, plug-ins, APIs, or LCA databases. Therefore, the bibliometric analysis not only shows that these themes are underrepresented, but it also reveals a deeper methodological gap.

2.5. Trend Analysis of Key Research Areas

At the beginning, combinations of keywords were selected to assess their growth and transformations over the years to cautiously analyze the publication trends. Figure 5 illustrates the key areas that have been analyzed. Each dataset represents the number of publications retrieved in a given year for a specific keyword combination, including BIM & LCA; BIM, LCA & IFC; BIM, LCA & LOD/Naming Systems; LCA & IFC; IDS & BIM; BIM, LCA & Master Specifications; and OpenBIM & LCA. The rationale behind selecting this list of keywords and the combinations was due to their direct relation to the objectives of the current study, which involved reviewing the recent approaches to integrate BIM with LCA, the significance of open standards like IFC, the application of classification systems and master specifications, and the influence of LOD and data mapping practices on the integration results. Given the annual number of publications for each keyword and combinations, an order of research engagement was created over the years, exemplifying the times of increased interest and emerging themes while providing insights into areas that were less explored. These datasets represent raw annual publication counts for each search theme, and no scale normalization was applied.

The findings showed the trend of research publications related to the incorporation of BIM, LCA, IFC, IDS, and master specifications (such as Masterformat, Uniformat, and UniClass) spanning from the year 2016 through 2025. It is clearly visible that the publications’ trend has surged, which indicates an increased recognition of the need to integrate these concepts into the construction and sustainability studies. Since 2016, the category of BIM and IFC experienced a noticeable rise in the publications with an emphasize on interoperability and data exchange standards in BIM practices. Likewise, the area of BIM and LCA experienced a significant expansion, stressing on the environmental evaluations within BIM processes to promote sustainable building practices. Furthermore, the publications related to BIM, LCA, and IFC significantly raised since 2018, which indicates that the industry has interest and need to provide solutions for both the sustainability and interoperability challenges. Publications on OpenBIM and LCA, especially since 2020, reflect a recent growth in the interest of incorporating open standards and workflows for improved collaboration and data exchange. Moreover, the limited research studies about IDS and BIM represent a recent acknowledgment of the importance of defining data requirements.

However, the LCA and IFC categories show relatively few publications, highlighting a gap in the research studies that directly address the integration of IFC with BIM and LCA. Similarly, the scarcity of publications in IDS and LCA also shows the need to investigate how IDS can support the definition and validation of LCA related information requirements within BIM workflows. The analysis also shows that there is a lack of comprehensive studies that integrate BIM, LCA, IDS, IFC, and classification systems into a unified framework, although broader topics like sustainability and BIM–LCA integration are well investigated. Ever since the growing interest in OpenBIM supports the need for research studies in this area, developing and assessing the potential of IDS and LCI within BIM-based LCA workflows for sustainable construction should be a priority for future investigation.

2.6. Analytical Framework

Following the data extraction and bibliometric analysis, an in-depth analysis of the content was conducted, which was structured into four main components, as illustrated in Figure 6. In the first component, a review of the integration of BIM and LCA was conducted to identify and analyze the categories stated in highly cited review articles. This included a comprehensive evaluation of these categories with an emphasis on their characteristics as well as analyzing each category in relation to the open standard factors, such as interoperability, data exchange, naming systems, and information exchange workflows, which was followed by an example from the literature.

The second component explored the role of open standards and OpenBIM in facilitating the integration of BIM and LCA, with a focus on the studies that incorporated IFC standard, emphasizing its role in enhancing interoperability and facilitating seamless exchange of data. A thorough exploration on how OpenBIM principles would improve the exchange of data and the lifecycle integration.

The third component thoroughly analyzed the studies that are related to IFC-driven integration. This involved compiling a summary table of key aspects from these studies, including BIM- and LCA-specific dimensions. The analysis also assessed the selected studies based on the integration frameworks, automation, interoperability, lifecycle phase coverage, data embedding, and the use of advanced methods.

In the fourth component, the results of the former components were combined to pinpoint the gaps and to propose a framework for the integration of OpenBIM with LCA. The proposed framework will be designed to address the limitations found in the evaluated studies while improving interoperability and data sharing. The proposed framework serves as a first step toward overcoming the challenges in integrating BIM and LCA, and it provides a roadmap for future studies to build upon.

3. Findings

3.1. The Current State of BIM–LCA Integration Methods

First, it is essential to evaluate and categorize the current state of integrating BIM and LCA and to identify the characteristics and gaps within these categories. While the above review papers have proposed broad categorizations, the current study builds on these foundations by emphasizing on the interoperability and open standards as key considerations for achieving more transparent and scalable BIM–LCA workflows.

Integrating BIM and LCA can be classified through many categories, while the reviewed articles assessed them for sustainable construction. Chen et al. evaluated different integration methods, such as BoQs import, IFC import, and BIM plug-ins for direct LCA calculations, and they noticed the lack of a standardized approach in selecting the suitable tools and software for the challenges of interoperability [8]. Arenas and Shafique focused on optimizing the materials’ usage, energy consumption, and carbon emissions using BIM models. Several interoperability challenges between BIM and other sustainability tools were identified, and therefore, they suggested that standardized approaches are necessary to understand the benefits of BIM-based sustainable buildings [23]. Teng et al. identified three methods that include embedding data into third-party applications, importing BoQs into LCA tools, and using plug-ins to embed LCA data within BIM tool [25].

Crippa et al. examined the studies that evaluated the environmental impacts, including carbon footprint, embodied carbon, and energy consumption. Then, they classified the methods according to the life-cycle phases, the types of impacts analyzed, and the necessity for automated LCA processes in BIM models [26]. Xue et al. focused on the interoperability issues by categorizing the integration of BIM with LCA into several key areas, including material selection, where LCA data is incorporated into BIM models to enhance the selection of materials driven by their environmental impact factors; energy analysis, utilizing BIM for energy modeling and integrating LCA to assess the energy consumption throughout the building’s lifecycle; waste management, applying BIM to plan and manage the construction waste combined with LCA to evaluate the environmental impact of the generated waste and disposal; and design optimization, using BIM tools for design simulations and incorporating LCA to assess and enhance the sustainability of the different design options [27].

Marrero et al. identified three primary categories for the integration of BIM with LCA as follows: the BIM model’s data is transferred to standalone LCA software for analysis (exporting data to external tools) through the use of plug-ins inherited into BIM tool(s) to connect with the external databases of LCA (connecting QT to external databases of LCA through the integrated tools); LCA data is embedded into a BIM environment to provide real-time feedback on the environmental impacts (incorporating environmental data directly within the BIM model). The strengths and weaknesses of each approach are examined, with an emphasis on the challenges, such as interoperability issues and data quality [28].

While reviewing the published studies, it was noticed that there is a need for a systematic categorization to capture how the different studies managed the exchange of data, the naming conventions, interoperability, and various LODs.

The classification framework used in this study was therefore developed through a two-stage process. First, the BIM–LCA integration approaches discussed in prior review studies were examined to identify the main categories commonly discussed in the literature, including quantity take-off or BoQ-based exchange, IFC-based exchange, plug-in/API-based integration, BIM-integrated LCA tools, and approaches based on standardized templates, libraries, cloud-based platforms, or parametric workflows. Second, the selected studies were reviewed in detail to refine these initial categories. In this step, the focus was on the actual workflow used in each study to connect BIM information with LCA data, including how data was extracted, exchanged, mapped, structured, or embedded within BIM–LCA integration processes.

Based on this classification, the reviewed BIM–LCA integration studies were grouped into seven information exchange categories: manual data extraction and input, file-based data exchange using neutral formats such as IFC, software integration using APIs and plug-ins, BIM-integrated LCA tools, web-based or cloud-based integration, parametric and script-based integration, and standardized data templates and libraries. The detailed comparative table is provided in Supplementary Material Table S2 to organize and compare the different approaches for integration across several dimensions, including their principal objectives, main characteristics, technical interoperability, data exchange protocols, overall workflow evaluation, LOD compatibility, and data mapping or naming systems.

The first category, Manual data extraction and input, in relation to the naming systems and data mapping practices, is mainly assessed based on the project-specific classification systems and standard naming conventions. In their study, Veselka et al. manually exported BIM data and mapped it to the categories of green building certification systems, such as BREEAM, LEED, DGNB, and SBToolCZ, which are mainly the general categories for construction (e.g., external walls, windows, floors, roofs, internal partitions) and which are closely aligned with the standard bill of quantities and classification systems such as Uniclass 2 and CoClass to facilitate the manual management of data [29]. Likewise, Palumbo et al. developed a method that incorporated the Environmental Product Declarations (EPD) data for concrete products by establishing factors for safety at the early LOD to predict accurate environmental impacts and to reduce data inconsistency [30]. Soust-Verdaguer et al. used a semi-automatic approach to integrate BIM with an external spreadsheet to execute LCA calculations, where the initial naming system is manually defined with the lack of standard national classification. They customized a three-level system (envelope, structure, finishes), which enables a comparative analysis between the timber and concrete-masonry alternatives at both the whole-building and assembly levels [15]. Arenas and Shafique conducted a cradle-to-gate analysis and applied factors for CO₂ emission to manually extract the quantities of material based on standardized data coefficients at the whole-building level. They stated that the environmental impacts are greatly influenced by the transportation and sourcing distances [16].

File-based data exchange using neutral formats (e.g., IFC) emphasizes the neutral formats of exchanging the data to enhance interoperability in LCA workflows. Horn et al. proposed a structured IFCXML-based method to embed LCA data within BIM models, promoting bidirectional integration and hierarchical data configuration and facilitating continuous exchange of data throughout the different planning phases, but this requires a well-defined data interface to ensure seamless communication with sustainability rating systems [9]. Similarly, Xu et al. automated the calculations of embodied carbon through IFC-based workflows for prefabricated buildings but identified challenges in the interoperability and the presentation of LCA-specific parameters within the IFC schema [5]. Forth et al. employed NLP-based semantic model healing, focusing on the assessment of early-stage embodied GHG to solve inconsistencies in IFC data [31]. Zheng et al. considered four integration methods for the same construction project to analyze the LCA results. Their results indicated that the IFC-based method yields to LCA’s outcomes with an error margin of 1%, demonstrating its validity and showing that the current IFC workflows often depend on an external LCA software rather than embedding the environmental data natively within BIM models [14]. Despite their contributions, these studies highlighted the absence of a standardized IFC schema for LCA attributes to enhance interoperability.

Integrating different software using APIs and plug-ins (e.g., Revit or other BIM tools) leverages customized applications to automate the extraction and transfer of data. Sameer and Bringezu developed a plug-in called the Sustainable Resource Application (SURAP) for Autodesk Revit to integrate BIM models with openLCA platform using its Python API. The plug-in enhances the decision-making by providing an environmental impact analysis from cradle to gate directly within a BIM environment. However, project-specific factors are challenged, as the plug-in relies on the pre-built GaBi datasets [19]. Parece et al. developed a method that utilizes APIs, known as SECCLasS (Sustainability-Enhanced Construction Classification System), to integrate BIM models with external databases for LCA. The method facilitated the process of having BIM objects mapped to LCA datasets across the different LODs based on Uniclass to simplify the sustainability assessments. However, the process still requires considerable manual intervention for data preparation and mapping [22]. Su et al. introduced a system that integrates BIM with dynamic LCA (DLCA) as a BIM-DLCA framework, in which the environmental impacts are analyzed over a building’s lifecycle. Although the system improved the quality of assessing these factors, it has scaling issues given that it requires an extensive time-dependent data and software compatibility [32]. Klumbyte et al. established a Python-based API to connect BIM models with LCA workflows. They validated their technique using OneClickLCA and investigated the use of APIs to automate the data interchange between BIM and LCA environments. However, its limitations include the absence of standardized databases, and its challenges are in addressing the regional sustainability requirements. Most of the systems, such as GaBi or OneClickLCA, rely on specific APIs or datasets, which limit the flexibility in adapting to the diverse project’s needs or new data formats. Despite the automation efforts, manual steps in the data mapping and preparation remain significant, which risk the presence of errors and inefficiencies [18]. Generally, the performance of the developed tools is low when applied during the early stages of design due to the incomplete or generic data, which limits the accuracy of assessing sustainability.

BIM-integrated LCA tools, such as Tally or custom plug-ins like BIMEELCA [33], are designed to function as embedded extensions within a BIM environment. Asare et al. developed a framework by using Autodesk Revit, Green Building Studio, and Tally. The naming system and data mapping follow the materials’ specifications and energy data, specifically for Ghana’s energy and LCA simulations. They clearly defined LOD from a conceptual mass model to a detailed model with performance specifications at both the product and assembly levels, evaluating embodied and operational carbon results at the whole-building level [34]. Santos et al. proposed a prototype within Autodesk Revit, a BIM-based environmental and economic life-cycle assessment (BIMEELCA) to fully automate the LCA/LCC analysis. For data mapping, they incorporated environmental and economic impacts directly into the BIM model’s objects and conducted whole-building and detailed assembly analyses [33]. Kurian et al. emphasized the importance of selecting consistent and region-specific naming conventions for accuracy, and they investigated the LCA results of a residential building in India using three LCA databases (GaBi, Ecoinvent, ICE); as a result, they noticed significant variability across those databases [35]. Kamari et al. developed a plug-in in Autodesk Revit to automate the calculations of the environmental impacts at a LOD of 100–300, which is directly linked to a predefined Excel-based material database derived from the ÖKOBAUDAT database [20].

Parametric and script-based integration is known to use programming languages (like Python) or visual scripting (like Grasshopper and Dynamo) to automate the QTs, calculations of the environmental impacts, and multi-objective optimization for LCA. Chen et al. proposed a digital twin framework by utilizing radio-frequency identification (RFID) to automate the cradle-to-cradle embodied carbon assessments. The approach of their framework applied semantic web technologies to facilitate the consistent transfer of the data [36]. Hollberg et al. used Dynamo in Autodesk Revit as a BIM tool to link BIM models with LCA databases for real-time environmental performance and to evaluate the embodied Global Warming Potential (GWP) over different design iterations [37]. Kim et al. followed a similar approach and extended it to existing buildings using a scan-to-BIM technique and parametric algorithms to comprehensively automate the lifecycle data [38]. Atashbar and Noorzai utilized a genetic algorithm (NSGA-II) to optimize the exterior walls’ materials to achieve significant reductions in the consumption of operational and embodied energy [39]. Relying on generic data during the early design stages [37] and challenges in precisely incorporating renovation details into BIM models [38] have highlighted the absence of detailed material- and component-specific information.

Standardized templates for data and libraries, which involve the creation of reusable objects’ libraries in a BIM tool with embedded LCA parameters, as discussed in a study by Lee et al., who developed a BIM-based library (BTEI) for environmental impact assessment, embedding environmental parameters in buildings’ materials like concrete and insulation to promote accuracy and efficiency by enabling automated estimates of the environmental impacts inside BIM systems. However, they indicated that there is a limitation in extending the library’s specifications for different regions and even to consider a more comprehensive environmental impact [40]. Mohammed proposed a process map to minimize manual intervention and to enhance data accuracy by creating a BIM model that includes all the necessary LCA-related data. The process aligned the capabilities of BIM in decision-making with LCA requirements and supported the framework through surveys and expert interviews. LCA calculations, which are based on the BIM model, including all the necessary LCA-related data, are performed. Interoperability across the different software platforms and adaptability to different project-specific scenarios are considered as gaps [41].

Almeida et al. examined the integration of Environmental Product Declarations (EPDs) within BIM models by using ISO 19650:2018 standards [42]. They defined EPD data structures based on project phases and LODs and extended the EPD coverage to include operational and end-of-life data. They emphasized the significance of standardized data for reliable environmental assessment [43]. Nehasilova et al. developed EnviBIM, which links cost-estimating and environmental data for rapid LCA calculations at the design stage. The semi-automated system utilizes local databases for early design optimizations, limiting its adaptability for global applications by its reliance on country-specific information and achieving full automation [44]. While these frameworks enhance standardization and automation, cross-platform compatibility issues continue.

Web-based or cloud-based integration extends the integration of BIM and LCA into collaborative and location-independent realms. Within this approach, Gui and Chen presented an integrated conceptual platform for bridge projects during the whole life cycle and utilized cloud technologies for data sharing, visualization, and collaboration by integrating various software systems [45]. A similar strategy was adopted by Lima et al. using BIM 360 as a Common Data Environment (CDE) to improve dynamic feedback and information exchange during the different project phases.

A semi-automated integration was developed to link Autodesk Revit as a BIM tool and OneClick LCA, depending on exporting data for material classification and carbon emissions analysis [17]. In contrast, Sobhkhiz et al. developed a knowledge-driven framework by utilizing a web-based approach that integrates semantic web technologies, such as RDF, OWL, and SPARQL. By automating the data retrieval and interpretation, this approach addressed the concerns of data discrepancy and made early lifecycle evaluations easier. While the cloud-based approach prioritizes centralized collaboration, the semantic web highlights the importance of smart data interpretation and automation [46]. Across these methods, there is an agreement on the challenges related to standardizing the workflows, ensuring smooth interoperability, and integrating into later lifecycle phases like operations and maintenance.

Overall, most of the evaluated studies have primarily identified results at the whole-building or assembly level, with occasional detailed assessments at the product level, especially when specific EPD data is involved. The methods clearly highlighted the existing gaps in naming standardization, data mapping granularity, and interoperability. They emphasized the manual effort involved and underscored the need for robust, standardized frameworks to improve the integration of BIM and LCA [15,16,30]. Despite the advanced data mapping, the complexity and manual interventions required to homogenize the data from diverse BIM families presented challenges in reducing the efficiency of integration during the early stages [33] and challenges related to manual database calculations, emphasizing the need for additional automated processes to minimize discrepancies between the databases [35]. Many studies, including the one of Chen et al.’s, noted interoperability issues that complicate a seamless data exchange among stakeholders and the use of computational tools that require significant expertise [36], which makes the process challenging for non-expert practitioners, as seen in Kim et al.’s findings [38].

3.2. OpenBIM and Its Potential for the Integration of BIM and LCA

OpenBIM is built based on essential standards and specifications that enhance the integration of data across various stages of construction and operation by improving project management, enhancing stakeholder coordination, and ultimately, saving time and expenses [12].

IFC is a standardized, open-data model that supports interoperability between different tools while accommodating the high fragmentation typically known in the sector. IFC data schema has been enhanced to facilitate high-level semantic flows for exchanging information [13]. Okonta et al. claimed that future improvements in the IFC schema can integrate sustainability parameters into BIM models to better support informed decisions related to energy efficiency, environmental impacts, and lifecycle analysis. The IFC file format (.ifc) facilitates the transfer of a wide range of data across different software and platforms within a BIM environment [47].

IDS is one of the open standards that define the scope and outline the method for transferring information. It helps stakeholders to specify the information they need at the different stages of a project. Integrating IDS with other OpenBIM standards, such as IDM, is critical in ensuring efficient exchange of information throughout the construction process. IDS specifies when and by which participant the information is to be exchanged in the construction process, ensuring that the information will be provided at the right moment and in accordance with the format, as required in the project. Moreover, the use of the different IDS format for models in the IFC schema may allow for better results; as such, the IDS standard can be based on classes and relationships between elements defined using the IFC structure. They can be used at the stage of defining the owner’s requirements as well as in the preparation of a BIM Execution Plan [12].

MVD is a predefined subset of information and views within a BIM model [48]. It also refers to an IFC view definition as a targeted subset of the IFC schema that is designed to facilitate the exchange of data for specific purposes or processes. It facilitates narrowing down the scope of the data based on users’ requirements and is often labeled as an IFC-filtered view. It enables users to extract specific segments of the model’s information based on their requests instead of exporting the entire model. MVD provides three key capabilities: 1) selecting a relevant subset of the IFC schema for a specific goal, 2) applying additional constraints to this subset to improve its relevance, and 3) defining the required level of software implementation to support the selected schema [47].

BSDD is a centralized database that provides standardized terms, definitions, and classifications for building information, facilitating consistent terminology and data semantics to establish a common understanding among various industry experts, BIM end-users, and solution providers. It establishes a common technical language that works as a semantic mapping tool to connect like-terms based on their meaning as it pertains to the AEC/FM industries [49]. BSDD contains IFC elements and standard classification systems, such as UniClass [50]. Furthermore, BSDD is also known as the International Framework for Dictionaries (IFD) libraries, and it provides concepts with a detailed description in a machine-readable format. It was developed using ISO 12006 Part 3 “Framework for object-oriented information” [51] as being the standard information schema so that it contains over 1000 terminologies, including IFC elements, standard classification systems, and application system standards, such as the European Technical Information Model (ETIM) and universal types [50].

IDM is defined as the processes/workflows associated with the data exchange [52] that provides detailed guidance on how information should be exchanged and delivered throughout the lifecycle of a project, especially in the context of BIM models. The IDM process identifies the information requirements and creates the process map to show the flow of information and the data exchanged between stakeholders [48]. It delineates precise moments at which information must be exchanged and clearly identifies the role and responsibilities in the project that align with stakeholders’ expectations for these exchanges [12].

BIM Collaboration Format (BCF) is an open file format and one of the dominant BIM collaboration and coordination tools that is considered along with the IFC format as one of the main pillars of OpenBIM [53]. It is an XML-based format that is used for communication and collaboration in BIM projects to enable the exchange of 3D coordination issues between BIM tools while separating communication data from the model. BCF organizes the information into different topics where each topic represents an issue, with a precise structure of attributes and tags, has been identified with a unique Globally Unique Identifier (GUID) or a Universally Unique Identifier (UUID), which ensures distinct identification within a decentralized system [53]. BCF also contains information related to specific design issues, such as clash detection or design changes [54], which is used to exchange comments, issues, and viewpoints linked to specific locations in a BIM model. Plus, it facilitates BIM-based collaboration for projects by communicating and solving issues, such as clashes, and works similarly to a ticketing service [55].

3.2.1. Comparison with Conventional BIM–LCA Integration

Dervishaj and Gudmundsson stated that although the conventional integration of BIM and LCA, which is mostly in the form of developed plug-ins in a BIM environment, tends to leverage BIM models for LCA calculation and automation, but it reduces the flexibility as it limits the utilization of parametric modeling’s capabilities and integration with other plug-ins’ workflows [56]. To overcome these challenges, the authors recommended more efficient approaches that advance the exchange of data, automation, and standardization. Furthermore, they suggested computational tools and linking scripts to BIM models to increase flexibility and to enable the parametric optimization and multi-indicator assessments. Likewise, new approaches, such as using classification systems, enriching BIM models through BSDD, and adopting a standardized taxonomy for LCA to enhance data exchange and collaboration, were recommended by Rodriguez et al. and Ghose et al. to enhance the reliability of environmental assessments [57,58].

In 2022, the Swedish Institute for Standards (SIS) recommended the integration of BIM with ISO 22057 [59]-compliant data templates that standardize EPD structure, enabling data exchange between BIM and LCA tools by defining the principles for organizing EPD data into machine-readable templates based on ISO 23386 [60] and ISO 23387 [61]. This approach can enhance the automation, consistency, and reliability in the sustainability evaluations [59]. The implementations of OpenBIM for a Canadian roadmap emphasize that IFC classes and their associated properties must remain consistent throughout the workflow, allowing for each building’s element to be correctly matched with an external LCI or EPD data [62].

3.2.2. Innovations and Challenges Specific to OpenBIM

The advantages of OpenBIM extend beyond exchanging the data. Its collaborative nature leads to more efficient and effective project workflow, reduces conflicts among stakeholders [63], streamlines the data-sharing process that minimizes errors and delays [64], and has the ability to be integrated into various software applications that enable a comprehensive project management approach [65]. These integrated approaches will improve project outcomes and reduce the overall costs [66].

Despite the numerous advantages of OpenBIM and its potential to be integrated with LCA, several challenges hinder its broad implementation for seamless integration, including data standardization, interoperability issues, and the need for user-friendly computer tools [67]. Different software applications use various data structures and formats, leading to inconsistencies and errors in exchanging the data. The lack of standardized data schemas for LCA-related information within the IFC framework complicates the integration process [68]. Another challenge is the complexity of transferring the data among various sources to achieve seamless integration. Moreover, the difficulties related to the quality of the data and the limited algorithms pose additional challenges [65].

The lack of standardized data schemas for LCA within the IFC framework is a significant barrier to make the integration between BIM and LCA software seamless [56,69]. This challenge requires the creation of custom scripts or data mapping procedures, which can be time-consuming [67]. Organizational and cultural barriers also play a significant role in adopting the OpenBIM approach. Many organizations hesitate to change their established workflows and are yet to use new technologies. They prefer to stick with the familiar and proprietary software [70]. Also, a lack of training and expertise in the use of OpenBIM and LCA methodologies restricts this adoption. To overcome these barriers, the industry needs to enhance its collaboration and sharing of information to demonstrate its potential benefits [71].

To this end, the economic considerations do affect the adoption of OpenBIM. The lack of clear evidence on its financial benefits can make it difficult to justify the associated investment. However, its long-term benefits, such as improving collaboration, reducing errors, and enhancing project efficiency, can lead to significant cost savings and increased profitability [64].

3.3. Analyzing the Research Articles Related to the Integration of BIM and LCA via IFC

In forming a well-detailed framework for the integration of OpenBIM and LCA, it is crucial to assess the existing studies that utilized IFC as inevitable to find how it functions as a standardized schema for the integration of BIM and LCA and how it addresses critical data inputs from BIM and LCA models. Among the categories of integrating BIM and LCA, IFC-based methods address the interoperability challenges, which are critical obstacles in the data exchange workflows between BIM and LCA systems [10]. The current integration strategies often lack standardized data naming, mapping, and structuring methods, resulting in inefficiencies and inaccuracies.

Table 1. Analysis of BIM-specific dimension of selected articles.

Reference	BIM-Specific Dimensions
	LOD	Geometric and Spatial Data	Material Data Specifications	Data Exchange & Interoperability	Embedded Environmental Data	Operational and Lifecycle Data
[72]	Not explicitly discussed.	Extracted component quantities using IFC relationships, exterior-wall detection via Revit plug-in.	Extracted material types using IFC relationships, quantification is paired with emission factors via the classic factor method.	Extended IFC for attributes needed for cold-region assessment.	Applied cold-region factors (heating, winter loss) to IFC-derived quantities.	Considered Whole life (A–C).
[73]	Not explicitly discussed.	Extracted quantities from IFC elements.	Extracted from BIM using IFC, considering emission factors, transport, and equipment parameters.	Extended IFC, a generic IFC to XML converter automatically builds DES models.	Mapped EFs and construction-resource parameters from the IFC into the DES template.	Considered A1–A5 only, operational stage is out of scope.
[74]	300	Prepared the Revit model for IFC export; quantities are driven by BoQ.	Introduced explicit user parameters to store names, LCIA units, and quantity bases.	Exported to IFC 4.3, grouped user-defined properties into Psets for export for a table-based (schedule) export by IfcOpenShell.	Embedded EPD-derived GWP values as element/material attributes.	Not addressed.
[21]	Mapped required BEM data to applicable LODs	Relied on IFC geometry/space boundaries; addresses transfer to IDF/gbXML.	Noted missing material libraries and the need to map material properties.	Described IFC → IDF transformation and IDS-based auditing.	Linked environmental data via post-BEM mapping to ecoinvent.	Included on operational schedules/HVAC/location metadata.
[9]	Utilized early benchmarks at low LOD, with detailed EPD data integrated at LOD 300+ for certification.	Extracted from IfcWall, IfcSlab, and IfcSpace, this supports volumetric and spatial calculations for LCA.	Defined by IfcMaterial and IfcPropertySet, enhanced with external databases such as Ökobau. dat and GENERIS®.	Enabled bidirectional data exchange of IFCXML between BIM and LCA tools, reducing manual data entry.	Not directly embedded in IFC; external databases (e.g., Ökobau.dat) supply this information during mapping.	Included end-of-life scenarios using IFC for deconstruction and waste flow, and partial modeling of operational energy through IfcEnergyAnalysisProperties.
[7]	Streamlined LCA utilizing generic data (LOD < 300) and comprehensive LCA employing EPD data for detailed analysis (LOD ≥ 300).	Extracted from IFC entities.	Linked material properties to IfcMaterial and external databases such as Ecoinvent.	Utilized IFC4 for information exchange, requiring enhancements for smooth integration at both material and project levels.	Limited incorporation of environmental data; properties related to environmental impacts are absent in IFC4 for thorough assessments.	Partially addressed data on operational energy use, maintenance, and end-of-life stages, but required manual input from designers.
[14]	Not explicitly discussed.	Evaluated the accuracy of BoQ extraction.	Extracted from BIM using IFC; encountered issues with misclassification and an incomplete Bill of Quantities.	Used IFC for data sharing; however, issues include incorrect object classification and missing data.	Not incorporated in IFC; external tools and datasets (e.g., Ecoinvent) are connected.	Primarily focuses on production and construction phases (A1–A5).
[5]	LOD standards are not explicitly referenced.	Extracted from IFC files.	Categorized by quantities and types, associated with specific construction elements.	Enabled IFC4 workflows by automating data transfer between BIM and LCA tools; challenges include inconsistent data mappings and naming conventions.	Not embedded; supplementary data are linked externally via tools such as SimaPro.	Not addressed.
[75]	Not explicitly discussed, but multi-level assessment is conducted.	Extracted from multiple IFC models, supporting hierarchical relationships.	Connected through IfcMaterial, and additional data enrichment features.	Enabled interoperability for multi-source IFC integration across Revit, ArchiCAD, and other tools.	Stored embodied carbon data in IFC models using custom property sets for delivery and reuse in carbon audits.	Comprehensively modeled lifecycle stages (A–D)
[76]	Not explicitly discussed, concentrating on the early design stages.	Extracted from IFC entities; provides geometric data for embodied carbon calculations.	Incorporated embedded embodied carbon factors into the BIM model, enhancing the data with external ICE database values.	Used the open-source IFC2x3 schema for data exchange and employed IfcOpenShell for automated data extraction.	Incorporated embodied carbon data into IFC files.	Not addressed.
[77]	300/400	Extracted from IFC entities and enhanced through User-Defined Property Sets.	Linked building services components to LCA datasets using material and service life data.	Created custom property sets for building services due to limitations in standardized attributes.	Linked environmental impact data using UUIDs assigned to building service components.	Modeled stages A1–A3, B4, C3–C4, and D; excluded operational energy (B6).
[78]	350	Extracted from IFC entities	Included types and quantities; limitations noted in linking these directly to environmental impacts.	Facilitated semi-automatic workflows and data exchange with SBToolCZ.	Utilized external databases for carbon and quality assessments through manual or semi-automated workflows.	Minimally included; lifecycle stages beyond A1 to A3 are modeled inconsistently.
[79]	200	Extracted from IFC entities	Enhanced extracted material information with regional databases such as BEDEC and BCCA for LCA.	Utilized IFC4.1 to enhance interoperability, incorporating additional properties to enrich data.	Incorporated environmental properties such as GWP into IFC models.	Not addressed.
[80]	Focused on early-stage visualization processes and conceptual modeling.	Extracted from IFC entities.	Connected to environmental properties through external CSV files.	Utilized IFC files for data integration and visualization, facilitating open workflows across various platforms.	Calculated environmental impact values were assessed externally and linked to IFC objects.	Not addressed.
[81]	Relied on simplified parametric models for initial assessments.	Included parametric models with geometric properties for predicting carbon footprints.	Sourced from databases such as Ökobaudat and EPDs, integrated via AI-driven workflows.	Utilized IFC for data exchange, facilitating interoperability in web-based applications for LCA and AI integration.	Calculated and integrated through material takeoff; not included in IFC models.	Partially addressed.
[82]	Emphasized various LCA levels (Generic, System, Component) in alignment with LOD 200, 300, and 350.	Extracted from IFC entities.	Externally sourced from databases such as Athena and Ecoinvent; no native embedding into IFC models has been demonstrated.	Used IFC for data exchange, but the limited implementation of MVDs hinders full interoperability.	Not directly embedded in IFC files; external mapping is necessary for LCA workflows.	Not addressed.
[83]	300	Extracted from IFC entities for structural and service components.	Linked to LCI databases; SCC-specific data added manually through extended property sets such as Pset_EnvironmentalCostValues.	Relied on IFC for interoperability but lacks robust MVD usage for automating workflows across platforms.	Embedded social cost of carbon (SCC) data in IFC with extended property sets; however, the process is manual.	Included stages are A1–A5, B1–B5, B6–B7, and C1–C4, with operational phases representing the majority of SCC contributions at 84.6%.
[84]	Not explicitly discussed but indirectly addressed through the modeling of prefabricated components and their processes.	Extracted from IFC entities, the components are modeled to include attributes such as size, shape, and placement.	Integrated into the BIM model and connected to energy consumption for the production and transportation stages.	Enhanced IFC with new property sets to include energy consumption information	Embedded in IFC with property sets	Concentrated on the stages of raw material production, transportation, and factory production, while excluding operational and end-of-life phases.
[31]	Not considered.	Extracted from IFC entities, the lack of detailed geometry is compensated for using a knowledge database.	Connected via NLP-based matching to an LCA knowledge database.	Relied on openBIM principles and IFC, enhanced interoperability is achieved by integrating BIM Collaboration Format (BCF) for feedback loops.	Manually enhanced in later design stages; early-stage models depend on defaults from the LCA knowledge database.	Focused on embodied emissions (A1–A3, C3–C4), with limited consideration of maintenance or operational phases.
[55]	Not considered.	Extracted from IFC entities.	Matched with a Knowledge Database for LCAs using NLP techniques to enhance semantics.	Used IFC as the main format and expanded BCF to convey decisions and incorporate LCA results.	Integrated into BIM models using property sets derived from the LKdb.	Covered stage include A1–A3, B4, and C3–C4, operational phases are excluded.
[85]	Although not explicitly discussed, the end-of-life phase was addressed.	Included the volume of building components, assembly codes, according to NBS standards.	Linked LCA data through Dynamo scripts.	Utilizes IFC properties enhanced by shared parameters and integrates external databases through Dynamo scripts.	Sourced from eToolLCD and external LCA databases.	Focus on EoL scenarios (C1–C4) and benefits beyond the system boundary (D).
[86]	Not explicitly discussed, detailed thermal and material properties for external walls.	Modeled second-level space boundaries and facade details in IFC format.	Retrieved and expanded using the BIMERR Building Material and Component Database.	Relied on IFC as the primary standard for data exchange, providing seamless integration with RenoDSS modules.	Embedded sustainability KPIs, like GWP in the IFC data and extended through RenoDSS.	Included operational energy demand and cost data, lifecycle stages A1–A3 and B2 analyzed for renovation scenarios.
[87]	300	Extracted from IFC entities, focusing on building-level details and city-scale context through CityGML integration	Enriched using historical engineering drawings and mapped to LCA databases for material impact analysis	Utilized IFC and CityGML as primary data standards to integrate data for sustainability analysis	Included material attributes embedded in IFC for building scale analysis	Covered lifecycle phases such as A1–A3, C3, C4, and D.
[22]	200–300	Developed model in Revit, enabling QTO.	Partially included, generic materials were used in LOD 200, with predefined material libraries applied for LOD 300.	Used SECClasS classification system for data exchange, linked to BIM objects.	Embedded GWP data using external databases such as ICE and EPDs.	Included A1–A3 and B4.
[88]	200–300	Extracted from IFC models created using Autodesk Revit and ArchiCAD.	Connected to LCA tools through Dynamo, relying on predefined material libraries.	Used IFC as the exchange standard, but variations occur during the import/export.	Partially embedded in BIM objects for end-of-life and embodied energy analysis.	Covered lifecycle stages A1–A3 and C3–C4, along with module D (partially).
[89]	Considered multiple LOD levels.	Extracted from IFC entities.	Integrated within IFC entities, focusing on the characteristics of concrete and steel.	Utilized the extended IFC schema (IFC4x3_RC3) for semantic data exchange.	Included some property sets for materials and operations.	Reviewed O&M data for hydropower reservoirs and structures.
[90]	Not directly addressed.	Extracted from IFC entities.	Employed layering and thermal properties for precise energy simulation.	Concentrated on converting IFC into OpenStudio models.	Supported attributes such as solar heat gain, but lacks comprehensive environmental data.	Restricted to operational energy and lighting data.
[91]	Not directly addressed.	Extracted from IFC entities.	Connected to LCA data sources such as SimaPro and Ecoinvent.	Employed IFC schema as the data exchange standard.	Incorporated carbon emission factors into the IFC schema.	Focused on embodied carbon (A1–A3).

and

Table 2. Analysis of LCA-specific dimension of selected articles.

Reference	LCA-Specific Dimensions
	LCI Data	Impact Categories and Methods	Construction and Transportation Processes	Maintenance and Replacement Data	End-of-Life Scenarios	Data Validation and Consistency
[72]	Used China-standard factors for materials/energy; municipal tariffs for use-phase.	Evaluated carbon emissions across the full cycle.	Included loaded vs. empty conditions with vehicle-specific factors and modeled winter penalties (extra losses, delay).	Used a gamma-process degradation to schedule repairs, calculated materials, machinery, labor.	Approximated as 1% of the sum of prior phases.	IFC-based automation and the exterior-wall identification algorithm.
[73]	Used emission factors for materials, transport, and equipment; a specific database is not mentioned.	Reported GWP only.	Quantified energy and fuel consumption for transport and construction.	Not considered.	Not discussed.	IDS-based validation.
[74]	Used International EPD System (generic) values; EPDs cited as Type III declarations per ISO 14025 [92].	Implemented GWP only; noted the same path can be extended to other indicators by adding attributes.	Not incorporated.	Not considered.	Not discussed.	Focused on rules/naming and user-defined Psets for consistent export.
[21]	Mapped EnergyPlus outputs to LCI (e.g., ecoinvent) for GWP.	Calculated GWP; lists typical LCIA families.	Not incorporated.	Not considered.	Not discussed.	Strongly emphasized on IDS-based validation of IFC submissions.
[9]	Connected to external databases (e.g., Ökobau.dat) through IFC properties.	Supported EN15804 [93] for GWP, ODP, and other environmental metrics; aligns with certification workflows such as DGNB.	Integrated impacts and workflows indirectly via LCA data, lacking clear IFC entity representation.	Limited representation in the IFC for lifecycle maintenance and replacement.	Modeled with IFCXML to integrate LCA results for iterative design feedback and certification.	Limited validation workflows, compliance checks are not automated, necessitating manual adjustments.
[7]	Sourced from EPDs and databases like Ecoinvent, EPDs address modules A1–A3, providing limited data for later lifecycle stages.	Used CML 2001 midpoint method for environmental metrics such as GWP, AP, EP, and ODP.	Required manual entry; not directly represented in IFC.	Partially addressed through estimated service life, but additional properties are needed.	Modeled through modules C2 to C4, waste scenarios depend on designer inputs.	Depended on manual checks; lacking automated validation mechanisms.
[14]	Enhanced BoQ including transport and energy data; LCI datasets from Ecoinvent v3.0 integrated into SimaPro.	Evaluated environmental impacts using the EN 15978 [93] and CML 2001 midpoint methods for GWP, AP, EP, and other metrics.	Assumed transportation distances and construction energy demand calculated based on the types of machinery used.	Not considered.	Not discussed.	Validated by manual BoQ validation against 2D and 3D models; the IFC-based approach is prone to significant BoQ deviations.
[5]	Generated using BIM, enhanced with external sources for transportation and equipment details.	Embodied carbon is assessed using SimaPro with databases such as Ecoinvent; it complies with EN 15978 for reporting.	Modeled with predefined routes and emission factors for cradle-to-site phases.	Not considered.	Not discussed.	Automated extraction of IFC-based workflows for data, though the checks for data consistency are limited.
[75]	Incorporated with custom databases for carbon emission factors, unit-in-place data, and quota data.	Embodied carbon calculated using process-based LCA, following ISO 14040 [6] and ISO 14044 [94] standards.	Modeled using region-specific databases and algorithms for overlap deduction.	Considered during the usage phase, with repeated calculations for optimization.	Included are the impacts of waste treatment and recycling, along with deductions for recovered materials (e.g., steel).	Automated collision detection guarantees precise BoQ calculations, minimizing errors.
[76]	Used the ICE database for embodied carbon factors and density values; focuses on cradle-to-gate assessment.	Embodied carbon benchmarking aligns with the RIBA 2030 Climate Challenge through a detailed analysis of materials.	Not incorporated.	Not considered.	Not discussed.	Automated data extraction through IFC-based workflows, although validation mechanisms remain limited.
[77]	Sourced from ÖKOBAUDAT and IBU.data, LCI datasets were linked to corresponding BIM objects via UUIDs.	Assessed environmental impacts, including GWP, ODP, AP, EP, and others, as defined by EN 15978 and EN 15804.	Modeled transport distances and materials for building services installation but lacked detailed logistics data.	Included the service life of components (e.g., HVAC systems).	modeled waste treatment and recycling for Modules C3–C4 and D, including reuse scenarios.	Ensured consistency through rule-based linking in mapping BIM objects to LCA datasets.
[78]	Sourced from external tools and databases such as SBToolCZ; lacks complete integration with IFC.	Assessed embodied carbon and other quality metrics using the SBToolCZ framework; impact categories align with ISO 14044.	Included construction materials and limited transportation modeling.	Not considered.	Not discussed.	Reduced errors with semi-automated workflows, but they rely heavily on manual inputs.
[79]	Sourced from the BEDEC and Ecoinvent databases for embodied carbon calculations.	Analyzed GWP, costs, and working hours using modular LCSA frameworks.	Covered modules A1 to A3 and A5; the transportation data is minimal and relies on general assumptions.	Not considered.	Included (C1, C2, C4) with assumptions regarding demolition and landfill processes.	Used Dynamo scripts for automated enrichment and validation, but manual checks are still necessary for element selection.
[80]	Gathered from environmental databases and processed externally in CSV format.	Focused on the Environmental Cost Indicator (ECI), using normalization across phases of a product’s lifecycle.	Included installation data and assumptions for transport processes.	Modeled but lack detailed breakdowns; replacement data not explicitly included.	Modeled, including disposal and recycling pathways.	IFC models are manually validated and updated to incorporate external environmental data, with limited automation.
[81]	Sourced from databases such as Ökobaudat and integrated through AI to predict carbon footprints.	Analyzed embodied and operational carbon footprints, focusing on A1–A3 and C3–C4, with a limited assessment of B6.	Included fundamental transportation impacts and restricted modeling of construction processes.	Not considered.	Included phases C3–C4 with assumptions about disposal and recycling.	Validated material selection and suggested optimizations; AI-driven workflows exhibit some inconsistencies.
[82]	Manually mapped from external sources, including the Athena and Ecoinvent databases.	Embodied carbon and energy calculations dominate the analysis using EN 15978.	Simplified impacts are included based on general assumptions.	Not considered.	Limited impacts are modeled.	No automated validation for data consistency or accuracy, Manual workflows dominate.
[83]	Sourced from external databases and manually linked to BIM elements.	SCC calculated using three LCIA models (LIME, EPS, ReCiPe), focusing on human health, ecosystem quality, and social costs	Simplified assumptions included, lack of detailed logistics modeling	B1–B5 included but not deeply modeled; replacement data is simplified	C1–C4 included focusing on the impacts of disposal and recycling.	Manual workflows dominate; no automated validation or consistency checks for LCI data integration
[84]	Detailed for raw material production, transportation, and factory-level prefabrication processes.	Evaluated energy consumption across stages but did not include broader environmental impact categories.	Included distances and energy usage for various raw materials	Not considered	Not discussed	Energy data relies heavily on manual inputs, with limited validation mechanisms
[31]	Derived from Ökobaudat and linked to BIM models using NLP for semantic matching.	Evaluated GWP and related environmental categories using the Ökobaudat database.	Considered simplified transportation data and manufacturing impacts	Limited inclusion of maintenance phases; default lifespans and replacement rates are sourced from the knowledge database.	Incorporated as default options in the database, ensuring consistency for C3–C4 and module D.	Automated semantic healing improves validation by addressing inconsistencies and missing details.
[55]	Sourced from Ökobaudat and integrated into workflows via NLP-based element matching.	Focused on GWP.	Modeled based on generic data from the LKdb, with limited specificity.	Replacement rates for layers are included but rely on generic LKdb defaults.	C3–C4 and benefits beyond the system boundary (D) are accounted for.	Semantic model healing improves consistency by enriching incomplete or missing data at early design stages
[85]	Sourced from eToolLCD, with dynamic linking to BIM elements using Dynamo visual programming.	Evaluated GWP, ADP, and other categories using CML-IA methodology.	Considered transportation distances and related emissions for demolition and recycling scenarios.	Not considered.	Covered C1–C4 and quantified recycling and disposal impact.	Dynamo scripts and external spreadsheets are used to ensure alignment between BIM data and LCA.
[86]	Sourced from ÖKOBAUDAT and other regional databases.	Evaluated GWP, AP, and other metrics using EN 15804.	Modeled the impact of material sourcing, transportation, and installation within renovation scenarios.	Included recurring maintenance costs and refurbishment cycles for key materials like insulation.	Some recycling and disposal costs are considered.	Utilized RenoDSS scenario generator to validate and align building data with KPIs.
[87]	Sourced from the ÖKOBAUDAT database for material impact analysis.	Analyzes GWP, ozone depletion potential, acidification, and eutrophication, based on DGNB.	Transportation data and impacts are considered in material flow and lifecycle scenarios.	Not considered.	Included C3 and C4 phases.	Data integration involved manual validation for consistency, focusing on material mapping.
[22]	Sourced from ICE database, supplemented by EPDs.	Focused on GWP for assessing embodied carbon.	Not incorporated.	Modeled for B4 stage using predefined service life values.	Not discussed.	Manual data validation required for resolving inconsistencies in BIM models.
[88]	Sourced from ÖKOBAUDAT and GaBi datasets for embodied carbon and energy metrics.	Evaluated GWP, ozone depletion, and other metrics aligned with DGNB guidelines.	Not incorporated.	Not considered.	Included C3 and C4 phases.	Errors in geometry and material assignments during IFC imports, requiring manual adjustments.
[89]	Integrated through IFC ontologies for material and energy-related assessments.	Analyzed production, transportation, construction, and O&M phases, focusing on CO2 emissions.	Considered carbon emissions from transport distances, machinery, and material usage.	Included O&M data for energy usage and reservoir maintenance with carbon conversion factors.	Not discussed.	Implements rule-based reasoning and SPARQL queries for data validation and consistency.
[90]	Not included.	Concentrated on operational energy use.	Not incorporated.	Not considered.	Not discussed.	Validation through OpenStudio and BIMserver.
[91]	Utilized SimaPro and Ecoinvent databases for embodied carbon factors.	Focused on embodied carbon emissions during material production and construction stages.	Transportation impacts are included in carbon calculations for prefabricated components.	Not considered.	Not discussed.	Automated data validation is achieved via the IFC-enabled data transfer tool.

provide a concise overview of these essential data points from both BIM and LCA domains illustrating within these moderately detailed tables, where all the details across this integration process are analyzed, and later an explanation of some of the findings concerning the integration framework of the advanced methods, the interoperability, and the life-cycle coverage.

Taking into consideration the integration frameworks, Santos et al. proposed IDM/MVD as a justifiable BIM–LCA–LCC methodology that uses IFC plus custom property sets. The authors do not impose a single classification standard; however, building elements can be considered either as the entire assemblies (IfcElement) or they can be broken down into individual materials (i.e., IfcMaterial), referencing the EPD data. This approach is flexible and can be aligned with any local or national LCA database [7].

Zheng et al. investigated the following four different ways to link the BIM tool (i.e., Autodesk Revit 2022) with LCA software or LCA data derived from the Ecoinvent V3.0 database: (1) a conventional “Excel + SimaPro V9.0”, (2) a parametric Dynamo script, (3) a custom Autodesk Revit plug-in, and (4) an IFC-based export to Bexel Manager + SimaPro V9.0. The authors did not adopt a formal classification reference or any official LOD labeling. The building used was a complex high-rise; therefore, its geometry and the accuracy of the quantity take-off were of high concern. The environmental data, Emission Factors (EFs), were partially embedded in the parametric or plug-in approach, while in the conventional or IFC-based approach, the LCA data resided externally in SimaPro V9.0 [14].

On the other hand, J. Xu et al. developed an IFC4-based data exchange approach for prefabricated buildings to automate the assessment of embodied carbon. The system sorts the data at the material, component, assembly, flat, and building levels. While this brings a consistent flow of the data, but it does not depend on a universal classification system. Instead, the “assembly” or “component” categories are customized to the IFC’s resource breakdown, and connections to the external LCA database are formed, even with minimal classification constraints. The authors did not use a specification system like Uniformat or Omniclass; however, they built on the IFC’s categorization (e.g., IfcWall, IfcBeam) to consolidate the domain, element, BOQ, and resource data. This adapted classification merges into a hierarchical structure, even though it requires extensive manual enrichment [5]. Ramaji et al. explored how LOD increments can align with the IFC-based data structures. They did not depend on a fixed classification standard, but they categorized the building’s data into LOD200 (generic) and LOD300/350 (system, component). This layered approach works effectively as a form of classification for the design detail levels, highlighting the evolution of IFC geometry from conceptual to more detailed stages. The material data remains linked to external LCA sources (i.e., Athena, Ecoinvent), but it is manually enriched [82].

Parece et al. created a classification-centric framework that links LCA with the construction classification system. Each object and material in the model is tagged with SECClasS codes, which serve as stable keys to join quantities to LCA datasets across varying levels of development. A two-stage PyRevit-based add-in generates model validation reports to check coding coverage and database joins; it then extracts quantities, ties them to the selected dataset, and writes back object-level GWP for transparent feedback. The logic travels well from early sketches to detailed models, and the dynamic linking approach avoids the cost of re-modeling when designs change. However, when elements depart from standard families or when parametric parts are only partly merged, users must reclassify or adjust codes to keep the mappings reliable [22]. Y. Xu et al. designed a multi-source requirements layer; an ontology that creates a clear understanding of which quantities, materials, factors, and process attributes are needed for A1–A5); IFC enrichment with rule-based validation targeted property sets on the right entities; checked via IDS-style rules; and a template-driven IFC to XML transform that instantiates a Discrete Event Simulation (DES) model [73].

Hosseini Gourabpasi et al. proposed an OpenBIM workflow that used IDS as the layer between BIM (IFC) and BEM (EnergyPlus/IDF). The authors first identified the information needed for energy modeling, mapped those needs to LOD by phase, and formalized them in a machine-readable (.ids) file; models are then validated in BlenderBIM against these rules before any conversion to IDF to reduce work at later stages [21].

Considering the full automation and interoperability, Alwan and Jones developed an automated embodied carbon benchmarking tool, pycab, which employs IFC2x3. The authors did not impose a single classification standard, but they rely on IfcOpenShell to parse the building geometry and foster open-source potential. BIM models are aligned with the Inventory of Carbon and Energy (ICE) database. The goal was the early phase of carbon benchmarking, not a complete multi-phase LCA classification; whole-model material substitutions; and modules (A1–A3), as their approach supports quick comparisons against RIBA 2030 Challenge benchmarks [76]. Růžička et al. presented a hybrid, IFC-enabled Complex Building Quality Assessment (CBQA) method that automates what the model already formalizes while showing why full automation remains a gap. At LOD 350, geometry-based quantities are extracted semi-automatically, but site- and context-specific SBToolCZ indicators still depend on user input. The authors explained what a truly fully automatic system would require, naming highly structured model data, assessment algorithms embedded as plug-ins or external engines, automatic boundary data, and write-back of non-graphical results to the native model, highlighting a practical gap between common numeric extraction and end-to-end assessment [78].

Horn et al. introduced a BIM2LCA approach within variable levels of development, such as an IFC integrated whole-building LCA in the early design, assembly or element level LCA in the semi-final design, and product/material level LCA in the final design by employing IFCXML to link BIM entities with external LCA databases for exchanging the data. While the study mainly focused on a German or EU context, the IFC-based integration can be applied internationally using open standards [9]. Strelets et al. created an IFC file processing workflow that opens the IFC, extracts elements’ quantities and environmental attributes into data frames, and computes impacts automatically, making reports via IfcOpenShell (Python 3.10.5). Interoperability is ensured by exporting IFC in the case study and, where needed, by using user-defined property sets to push custom attributes into the IFC [74].

Concerning the Lifecycle Phase Coverage and Data Embedding, Theissen et al. examined how a building’s services (HVAC, plumbing, etc.) can be integrated into a whole-building LCA within an OpenBIM approach. To address the existing gaps in the standard IFC for service life data, the authors developed and used user-defined property sets (UDPS). Life-cycle modules (A1–A3, B4, C3–C4, D) were partially modeled, with a strong emphasis on embodied impacts. Moreover, the authors utilized a unique ID-based linking to Germany’s ÖKOBAUDAT. However, their OpenBIM implementation was possible only to a limited extent, indicating that data standardizing to building services beyond the conventional IFC categories remained challenging [77]. Barbini et al. showed how an IFC model can be used to compute and visualize Environmental Cost Indicator (ECI) values for a wooden window across production, installation, maintenance, and decommissioning by creating four IFC objects and linking them to LCA data by phase stored in a CSV, first by manual text edits and later via a small Python script. While their study demonstrated how OpenBIM can boost sustainability assessments, it relied heavily on manual CSV-to-IFC data enrichment even when later scripted and relied on project-specific mapping rather than governed IFC property sets [80].

Lu and Deng embedded Social Cost of Carbon (SCC) into IFC models at LOD300 to be able to track carbon across the phases (A1–A5, B1–B7). Their approach covered production, maintenance, and operational phases; however, an automated validation was missing for manually extended property sets (Psets). By embedding SCC within IFC, they tracked the carbon externalities across the major phases (A1–A5, B1–B7). They realized that B6–B7 (e.g., lighting retrofits materially reduce SCC) stresses the value of keeping operational data in the same IFC context; however, lifecycle data embedding still relied on manual properties, and therefore, automation and cross-tool compliance remained limited by non-standard property extensions [83]. Płoszaj-Mazurek and Ryńska presented an AI-assisted, open-source web app with an IFC 2 × 3 model that auto-generates a bill of quantities, lets the designer assign layer related component definitions, and then computes a project’s embodied carbon while offering large language model (LLM)-based material substitution suggestions [81].

H. Xu et al. worked on whole-life coverage specific to cold regions. Their framework covered construction, operation, maintenance, and demolition and embedded specific factors of the designated region (district-heating intensity, freeze–thaw, winter construction) directly into the assessment. Then, with quantities derived from the model and region-specific parameters stored as properties, results are written back to IFC, so the assessment will be associated with the model. A small Revit plug-in auto-identified exterior walls, reducing manual handoff. Some inputs were still manually entered, and there were no published IDS to automatically validate the added properties [72].

Through the application of advanced methods, Forth et al. proposed an NLP-based method to enhance incomplete BIM data for LCA in a partial automation, focusing primarily on the production stage and end-of-life phases. They connected IFC-based geometry with an LCA knowledge database (LKdb). By using AI to match BIM elements to the LCA knowledge base, it reduced the need for strict, upfront classification. In testing five BIM models, the process reduced the manual work. However, accuracy still depends on how well elements are initially labeled and on the size of the LKdb, so it relied on the trained knowledge rather than the fixed, rule-based mappings [55]. Focusing on AI-driven parametric design, Płoszaj-Mazurek and Ryńska labeled broad type elements (e.g., walls, floors), with adequate distinctions in the parametric environment. This classification made early exploration fast, but it also weakened reliability without a shared classification or stable identifiers, links to EPDs are harder to audit and reuse across tools [81].

A practical next step would be to add a small set of LCA property sets in IFC, link datasets by persistent IDs, and introduce IDS checks so that the same workflow has stronger interoperability. H. Xu et al. worked on cold-region LCA with three practical advances. First, they used two alternatives: a mean-value estimator for city-level data and a weather-driven dynamic method when daily heating/meteorological data are available. Second, maintenance was scheduled with a gamma random process, as they claimed that component degradation is one way. Third, manual work was reduced by auto-identifying exterior walls via a small Revit/IFC plug-in, closing a common gap in model extraction [72]. The novelty of the work of Y. Xu et al. was DES automation driven by IFC. The tool auto-generated DES models from the validated IFC, allocating resources and routing for transport and site activities, so idle time, loading, and sequencing were represented rather than approximated by static factors. Scenario controls (route distance, equipment choice) were also parameterized [73].

4. Discussion

4.1. Proposed Framework

The main components of the framework and the information flow show how an IFC file undergoes several processing stages to produce comprehensive LCA results, as illustrated in Figure 7 and Figure 8. Figure 7 presents the logical flow from IFC upload and storage to reporting, while Figure 8 specifies how this flow is directed across services using the Business Process Modeling Notation (BPMN). The framework operationalizes two key steps that we previously developed: IDS-based information requirements and validation for LCA-ready IFC exchanges [95] and a naming system for a consistent data mapping [96].

In this study, the proposed framework primarily operationalizes IFC and IDS, supported by structured naming and classification-based mapping. IFC is used as the open data exchange format for transferring building geometry, material information, quantities, and property sets from BIM authoring tools into the framework. IDS is then used as the validation mechanism to check whether the IFC model contains the LCA-related information required for assessment, such as material assignments, quantities, classification codes, and accepted data formats. After this validation step, the structured naming and classification-based mapping system links the validated IFC entities and material information to the appropriate LCI datasets before the LCA calculation and reporting stages. Other OpenBIM standards discussed earlier, including IDM, MVD, bSDD, and BCF, are considered as part of the broader OpenBIM context rather than as fully implemented components of the proposed framework.

Based on this scope, the proposed OpenBIM–LCA workflow is organized into the following sequential steps:

1. IFC File Upload and Storage: When users create a building’s 3D BIM design model, which contains all the relevant geometric and material information, the framework starts by uploading the IFC file. This process is compatible with OpenBIM standards since the IFC format allows for interoperable exchange of the data between the different software platforms. The IFC file is then stored into the system for later access during the subsequent stages. As shown in Figure 8, the Web App UI initiates the process (“Upload an IFC file”), emitting a message that the Storage service persists (“Save the file within the system”).

2. Parsing the IFC File: Next, the system retrieves comprehensive information of the BIM 3D model from the IFC file and prepares it for LCA’s related tasks. The first two stages in Figure 7 (Upload and Storage; Parse and Extract) are presented in Figure 8 by two distinct pools. The IFC entities are identified and categorized, which possess key building’s elements (e.g., IfcWall, IfcSlab, IfcColumn), standard and user-defined property sets (psets), geometric dimensions (spatial attributes such as length, height, thickness, and volume), and material properties (material compositions and possible information such as density and embodied energy, if available). By doing so, the raw IFC data is converted into a structured in-memory model, whereas the parser ensures that the following validation, mapping, and calculation stages can consistently be operated and yet information is efficiently accessed.

3. Validating the Extracted Data Against the IDS: The parsed IFC data goes through a compliance check with an IDS, which outlines mandatory data fields, classification codes, and accepted formats. The validation step in Figure 7 (Validate vs. IDS) is directed by the Validator and IDS pools in Figure 8. This stage involves a completeness check to confirm whether each IFC entity has an assigned material, quantities, and classification codes (e.g., Uniformat, Masterformat). It also includes a verification of the data format to ensure that the properties are presented in the correct and consistent formats (e.g., numeric vs. alphanumeric fields) and therefore identifies any missing or incorrect data to recognize inconsistencies or incomplete attribute fields. Then, an enriched IFC file will be generated, containing suggested corrections or user-specified changes based on LCA requirements, if applicable. Only properly structured data will proceed to the mapping stage, ensuring a reliable environmental assessment.

4. Translating the BIM Model’s Data into a Format Compatible with LCA Processes: The translation and preparation stages in Figure 7 (Translate and Map; Compile Data for LCA Calculations) build directly on the Parser’s structure and the Validator’s outcome. The enhanced IFC data is converted into standardized structures for LCA workflows. This process involves the creation of a mapping system for both the Uniformat and Masterformat systems. Each IFC entity is mapped with a specific Uniformat unique number that corresponds to the Masterformat code, bringing a standardized naming convention and ensuring an efficient classification across BIM and LCA. Next, the IFC Entities are linked to LCA stages, where the building’s components are associated with the relevant life-cycle phases (e.g., production, construction, use, and end-of-life). The LCI Database (e.g., Ecoinvent) is linked to the Masterformat codes to connect the information of the material or component from the IFC model and reference it to the appropriate environmental impact datasets. This step establishes the basis for precise calculations to LCA by confirming that all the essential building’s components, materials, and processes are aligned with the established classification systems and are referenced to the validated LCI data sources.

5. Compiling Data for LCA Calculations: In the next stage, the system compiles and structures the data for LCA calculations. This process is divided into four main tasks: (1) quantification, which determines the total quantities of materials (e.g., area, volume, weight) using the geometric information extracted from the IFC model; (2) aggregation, which organizes the data by categories such as material type, LCA stage, or other user-defined criteria (e.g., structural versus non-structural elements); (3) mapping extracted materials to LCI, where each mapped material is connected to a relevant record in the external LCI database to retrieve the emission factors and other impact indicators; and (4) data formatting, which organizes the aggregated data of the materials into a format that is compatible with the specialized LCA tools.

6. Performing the LCA Calculations: At this stage, the framework continues with the calculations of LCA for each element and its impact assessment. Environmental impact metrics (e.g., GWP, acidification, eutrophication) are assessed for each building’s element or group of materials and, thus, are aggregated based on the relevant life-cycle stages. For a robust understanding of the project’s overall environmental footprint, this structure allows us to analyze the impact of each building component from cradle to grave.

7. Results and Report Stage: Comprehensive results are generated during the final stage either as a PDF or as a webpage report that contains the process for validation. The calculation and reporting stages shown in Figure 7 (Perform LCA Calculations; Results and Report) are reflected in Figure 8 by the Reporter pool, which “processes the output from the Validator service” and “generates the report from the results,” exposing a “Download report” action in the UI. In practice, the Reporter consumes both validation metadata and the LCA computation outputs (produced by the calculation module that uses the compiled dataset), generating a document that links back to IFC object IDs, classification codes, and LCI references. This preserves end-to-end traceability from each impact number in the report to the specific model elements and datasets that produced it, and it closes the design feedback loop as highlighted in Figure 7.

The developed framework produces validated and enhanced IFC files with recommended data for improvements and accurate information as an output. These files are created for LCA applications to help making efficient decisions during the design and construction stages of building projects. Figure 7 outlines the framework’s responsibilities: validation, translation, quantification, calculation, and reporting. Figure 8 specifies how these responsibilities are executed across services. A comprehensive LCA report outlines the compliance of the IFC file with LCA requirements and highlights any issues encountered along the whole process.

4.2. Addressing the Gaps

The reviewed studies highlighted a broad variety of methods to integrate BIM and LCA, which range from manual Excel-based methods to more automated and IFC-centric workflows; however, they all pointed to recurring gaps in the data validation, lifecycle coverage, interoperability, and result transparency. In this paper, the proposed framework to directly integrate OpenBIM with LCA targets these challenges by introducing a structured method for IFC parsing, data validation via an IDS, systematic classification mapping (e.g., Uniformat, Masterformat), and a full cradle-to-grave coverage. The result is an end-to-end solution that not only streamlines LCA calculations but also offers deeper transparency into how the data is sourced, validated, and reported. The proposed framework directly addresses the identified limitations retrieved from the literature as follows:

Numerous studies emphasized the importance of lowering manual interventions in LCA workflows [7,9,14]. Even in many recent IFC-based workflows, for example, the workflow described by Strelets et al. assume the input model is already complete and error-free and do not run a formal, machine-checkable check before calculations. Therefore, the developed method in this study adds an IDS-based pre-run validation that verifies required properties, units, and classification codes, so results do not depend on inputs. This built-in verification helps to extend beyond the early modules by making sure that the downstream phases, such as transport (A4–A5) or maintenance (B2–B4), are not left to be improvised by manual updates [74]. This automated check is a main key for keeping the model coherent and transparent so that designers and LCA practitioners can easily visualize and identify if a building’s element meets the pre-defined data rules or if it is missing any information.

Studies, such as the ones of Alwan and Jones and Theissen et al., emphasized the integration of building services or UDPS [76,77]. However, the approach presented in this study extends this concept by embedding service-life or HVAC data directly into IFC, which is subject to the same validation steps. Also, some of published IDS profiles are effective for energy-model handoffs but remain BEM-focused and do not yet govern LCA property sets [21]. The proposed framework in this study adds LCA-specific IDS clauses, so services and replacements are validated at exchange time. This means that the in-service data is no longer scattered or partially missing; all the information is systematically included in the same IFC environment, facilitating how each mechanical equipment contributes to the overall carbon footprint, with minimal confusion about the data origins or validity.

Similarly, Růžička et al. and LLatas et al. developed semi-automatic solutions that utilize parametric or Dynamo-based scripts; however, these solutions still lacked robust data checks and comprehensive coverage of all modules [78,79]. In this paper, the entire life cycle is mapped systematically from material extraction to end-of-life. By applying an IDS-driven approach, assumption is avoided: parametric scripts can feed data into IFC, but the model’s compliance is then automatically confirmed, ensuring more consistent results and providing a transparent record of any compliance failures or missing data. Moreover, DES automation is strong for A1–A5 but typically validates only units rather than dataset identity; the proposed framework extends to A–D and binds factors by UUID with origin to improve cross-project comparability [73].

For early design phases, Płoszaj-Mazurek and Ryńska employed AI and machine learning for parametric exploration but omitted the B6 or B2–B4 phases [81]. While the proposed framework presented in this study ensures that even at a conceptual stage, placeholders for those phases are embedded in IFC. If the data is incomplete, the system logs it at the Validation or Mapping step, notifying users that certain modules are unspecified. This transparency in the partial data supports a better iterative design loop, permitting designers to see where the data is exactly lacking and yet can address it before reaching the final stage. A similar logic is applied in the study of Forth et al., who attempted to unify IFC geometry with external environmental data, but inconsistent cross-software imports and a reliance on manual corrections remained a challenge [55,88]. The method proposed in this paper automatically logs each mismatch (e.g., a slab’s volume or an undefined occupant usage) and presents these discrepancies to users. The result includes a more reliable geometry data alignment and a clear path on how each correction was decided, which improves the overall transparency of the final LCA metrics. Likewise, Han and Rajabifard and Fenz et al. presented web-based or multi-criteria decision support tools where users’ input for data enrichment was still needed [85,86].

The framework proposed here enforces uniform data input at the IFC level, validated by the IDS, so that any subsequent web-based decision-making tool can draw from a consistently structured dataset, thereby enhancing not only the efficiency but also the clarity on how results are derived. A recent cold-region whole-life study [72] included dynamic heating and winter-construction effects, but they still rely on assumed and parameterized utility factors rather than values linked to a verifiable dataset, and handled demolition with a simple percentage add-on. The presented framework herein replaces these assumptions with dataset-linked, auditable properties (source, version, region) and richer C-stage templates for demolition and processing.

Finally, Tauscher and Wong relied on CityGML for city-scale contexts but still parsed IFC geometry with partial success [87]. In principle, the same IDS-based validation step can be extended to city-scale expansions once the building’s level data is robust. All the environmental metrics remain attached to the IFC building’s elements that pass the compliance checks, and if expansions to CityGML are needed, they remain consistent. Similarly, Parece et al. discussed the potential of linking IFC data with classification systems like SECClasS to improve the GWP calculations, but they relied on a manual reclassification [22]. The approach proposed in this paper places the classification step in the Translating BIM Data phase, systematically linking each IFC entity to the recognized codes and the external LCI references for a fully traceable approach. Python IFC-native calculators still prioritize A1–A3 and assume local naming rules [74], whereas the proposed framework generalizes with cradle-to-grave scope, standardized classification relations, and IDS-checked naming so that automation scales across projects and tools.

Overall, the proposed framework delivers three main enhancements if compared to the ones published in the literature. First, the IDS-based validation checks the model before starting any calculations, identifying all the missing or inconsistent fields and making data use transparent. Second, the framework’s cradle-to-grave scope settles the partial life-cycle coverage reported in earlier studies. Third, adopting standardized classification and naming systems (e.g., Uniformat, Masterformat) supports cross-project consistency and improves interoperability between different tools. Most importantly, each of these improvements underscores a higher level of transparency in the final LCA outputs, where the project teams would always know the IFC properties that were validated, the classification codes that were applied, how the aggregator computed each module’s emissions, and how the results were derived from those verified inputs.

4.3. Practical Implementation Challenges and Mitigation Potential of the Proposed OpenBIM–LCA Framework

Although the OpenBIM–LCA framework addresses interoperability and standardization issues, its practical implementation may encounter some challenges. An important challenge is the quality and completeness of the BIM model. In practice, BIM models are primarily built for design coordination, visualization, and documentation rather than for environmental assessment. While IFC provides open data exchange, the quality of exported data can still vary depending on the BIM authoring tool, export settings, and level of development of the model. The proposed framework can partly address this issue by implementing IDS-based validation before conducting the LCA calculation. The framework checks whether the required information is present and properly structured. This does not replace the need for robust modeling practices, but it provides a systematic quality control step that can identify missing or inconsistent data earlier in the workflow.

Industry adoption is also a major challenge. Many practitioners are already used to existing BIM–LCA practices, such as proprietary tools, spreadsheet-based calculations, and plug-ins tailored to specific BIM platforms. Moving toward an OpenBIM–LCA workflow may therefore require modifications in existing routines, additional training, and enhanced coordination. The proposed framework can help address this challenge by offering a more structured process for information exchange through the combining IFC-based model exchange, IDS-based validation, and classification-based LCI mapping, the framework clarifies required data and integration steps. This can help project teams move away from highly project-specific procedures towards a more repeatable workflow.

Software vendor limitations are another issue that can affect the practical use of the proposed workflow. Although OpenBIM standards are intended to improve interoperability, BIM software tools do not always implement IFC export, property sets, classifications, and material definitions in the same way. In some cases, required material layer data may be missing, quantities may be exported differently, or object relationships may not be structured consistently. These inconsistencies can increase the need for custom scripts, manual checking, and additional mapping work. The proposed framework can partly address this issue by reducing reliance on software-specific workflows. Since IFC is used as the central data exchange format, the workflow is not restricted to a single BIM authoring tool. In addition, IDS can be used to define information requirements independently from a particular software platform, which supports a more vendor-neutral validation process. Classification systems such as Uniformat, MasterFormat, or UniClass can also act as a bridge between BIM objects and LCI datasets. This reduces dependence on project-specific object names or proprietary material labels and makes the mapping process more consistent across different software environments.

Scalability is also an important concern. While the proposed workflow may be easier to apply in small or medium-sized case studies, larger projects include thousands of BIM objects, different material layers, multiple design alternatives, and several life-cycle scenarios. Managing this amount of information can make data extraction, validation, classification, LCI mapping, and LCA calculation more complex and time-consuming. Regional differences can also create additional challenges since LCI databases, environmental product declarations, construction practices, transportation assumptions, and end-of-life scenarios may vary from one context to another. The modular structure of the proposed framework can help reduce these challenges. By separating the workflow into distinct components, each part can be updated or expanded without changing the entire system. This flexibility supports the future use of the framework in larger projects and allows it to be adapted to different levels of detail, life-cycle scopes, and data availability.

5. Conclusions

A comprehensive review of the literature related to the integration of BIM and LCA through IFC is definitely essential for advancing sustainable practices in the construction industry. A structured review of the existing literature allows us to identify the level at which each of the following critical components, geometric and material data, life-cycle inventory data, and impact assessment categories, is currently addressed within the integration of BIM and LCA. This will provide a clear overview of the existing gaps, overlaps, and inconsistencies in the data used and the methodology that may otherwise weaken the effectiveness of BIM–LCA’s applications.

By categorizing the inputs from both BIM models and LCA models meticulously, it is possible to outline the status of interoperability and methods of data exchange, which are used in many published studies. This understanding is important because only seamless data integration can assure accurate and reliable environmental impact assessments. Also, the best mapping practices and common challenges about data mapping enable managing how to overcome technical barriers linked with the integration of OpenBIM and LCA.

Ultimately, this approach in the literature review is crucial in informing the development of a robust framework for integrating OpenBIM and LCA. This would mean that such a framework would not only standardize the integration process, but at the very least, it would consider all the required data from a detailed materials specification to the end-of-life scenario. It would also ensure that the standards within the industry, including the adoption of interoperable data formats, such as IFC, become more attractive to stakeholders, and collaboration can be increased. This framework will, therefore, attempt to achieve better accuracy, efficiency, and sustainability in the outputs of BIM–LCA initiatives in the built environment by addressing the identified gaps and leveraging the best practices extracted from the literature.