The HBIM Maturity Model: Accrediting Historic Building Information Modelling (HBIM) Development

Abstract

HBIM is the application of BIM, a digital information management process, to cultural heritage (CH) assets. Despite the numerous potential benefits posed by the adoption of HBIM, the current practice is limited by a lack of consideration of the end user and a lack of guidance regarding the application of HBIM. To address this, the article presents the HBIM Maturity Model, the culmination of a multi-year research project developing user-centric guidelines for HBIM via consultation with the international heritage community. The article details the development of the HBIM Maturity Model, a scalable, level-based approach for developing and assessing HBIM systems. Subsequently, 122 case studies are evaluated using previously defined HBIM system requirements and the HBIM Maturity Model to assess to what extent the current HBIM application meets the needs of the heritage community. The evaluation concludes that, despite the technological ability to achieve the requirements of the heritage community, the majority of HBIM case studies fail to report outputs deemed most critical by the heritage community, namely, those related to structured information management. This should be considered a key barrier to HBIM adoption.

1. Introduction

1.1. Background

This article represents the culmination of a longitudinal research project investigating the standardisation of Historic Building Information Modelling (HBIM). HBIM, the development of which will be addressed in this section, is the application of BIM, a digital information management process [1], to the management of cultural heritage (CH) assets. Details of the longitudinal research project will be provided in Section 1.2.

HBIM was first proposed in 2009 [2] and there has been an increasing academic interest in the topic since. One driver of this increasing interest has been the implementation of international BIM mandates [3], which dictate the use of BIM on specific projects. Notably, the Italian BIM mandate [4], coupled with the large number of CH assets in the country, has positioned Italy at the forefront of HBIM development.

The adoption of HBIM by the heritage community, defined by the Faro Convention [5] as “people who value specific aspects of cultural heritage which they wish to sustain and transmit to future generations”, will provide numerous potential benefits for the sustainable management of CH including more efficient resource management, and more informed decision making. Throughout this article, heritage ‘management’ refers to the overarching concept of ‘asset management’, defined as “the coordinated activity of an organisation to realise value from assets” [6]. This is an intentionally broad concept and, within a heritage context, could range from daily management activities to large-scale interventions [7]. However, early HBIM research was largely focused on the issues surrounding geometric modelling for heritage assets [8,9,10,11,12], and model creation remains a prevalent topic to date [13,14,15,16,17,18,19,20,21].

In more recent years, emerging topics of HBIM research have included the following: HBIM and Geographic Information System (GIS) integration [22,23,24,25,26,27,28]; incorporating condition data in HBIM (e.g., via modelling decay and damage [19,29,30,31,32,33]); the integration of HBIM and extended reality (XR) technology [14,24,34,35,36,37,38]; modelling changes over time [39,40,41]; evaluating the current and potential energy performance of heritage assets [42,43,44,45]; conducting a structural (in particular, seismic) assessment of built heritage [31,46,47,48,49,50,51]; modelling lost heritage [52,53,54,55,56]; and information management including data standards [46,57,58,59,60,61].

Historically, existing HBIM case studies focus on a singular element of heritage management. However, the potential use cases of HBIM within the whole lifecycle of heritage management are numerous, ranging from daily maintenance to major capital investments. In particular, the potential to integrate diagnostic campaigns within HBIM systems [62] or utilise HBIM data to perform structural analysis [63,64] has been successfully used for planning and conducting large-scale restoration projects [65]. Similarly, a newly developing use case is HBIM to inform adaptive reuse [66] or sustainability-focused alterations [42,43,44,45,67,68] of heritage assets, perhaps resulting from the suggestion that our existing building stock provides a critical path to Net Zero [69]. HBIM has also been utilised to inform the translocation of heritage assets [70], albeit an infrequent occurrence. In most cases, HBIM acts in conjunction with other tools such as non-destructive testing, geospatial surveying equipment, and structural evaluation software.

Alongside physical interventions, HBIM is also frequently used as a tool for the valorisation and dissemination of CH. This can involve, among other things, the use of HBIM for planning visitor movement [71], providing virtual access to inaccessible heritage [38], and creating virtual experiences to enhance visitor experiences [14,34,35,72,73,74].

It is evident that, no matter the chosen use case, HBIM can act as a centralised digital information repository, capable of supporting the collaboration of all actors within the heritage management process. However, despite the popularity of HBIM as a research topic, there still remains limited practical HBIM application [12,75]. Likewise, current HBIM users are typically academics, despite the fact that one of the key potential benefits of HBIM is that it will enable collaboration among all actors involved in heritage management.

There is also a lack of apparent consideration of the end user [76], as evidenced by Ávila et al. [75], who reviewed the HBIM literature and suggested “several HBIM models were created without a clear and well-defined purpose, rendering them ineffective in addressing the practical needs that arise during the management of the building”. This problem is not unique to HBIM and is an acknowledged flaw in information system design for many other sectors [77,78].

To date, there also exist minimal guidelines for how HBIM should be applied. Despite some regional guidance such as that produced by Historic England [79,80], there remains no internationally recognised standard for HBIM. Consequently, some authors [81] have advocated for both guidelines for and the standardisation of the application of HBIM. It should be noted here that standardisation does not infer an exact duplication. Instead, it suggests an aligned practice. Siewczyński et al. clarify this, stating “successful BIM implementation does not at all imply full implementation of all elements of the methodology, but only implementation of areas where implementation can deliver measurable results” [81].

The purpose of this paper is to provide practical guidelines, in the form of a newly developed HBIM Maturity Model, that will facilitate standardised HBIM implementation. The HBIM Maturity Model has been developed as part of a multi-year research project, details of which will be given in Section 1.2. A significant feature of the work is that it prioritises the systematic governance and management principles that will enable HBIM to serve as a sustainable, long-term solution for the heritage community, rather than focusing solely on technical system design (e.g., what software or hardware should be used). The HBIM Maturity Model is intended to be, as far as possible, technology-agnostic. The successful utilisation of the HBIM Maturity Model will facilitate HBIM systems which are supported by defined governance and long-term information management plans, a feature rarely considered in the existing HBIM practice [12,76].

This approach was influenced by both the existing guidance on digital technologies for asset management [6,82,83] and existing standards for heritage data management, such as MIDAS Heritage [84], which advocates for consistent terminology and conceptual frameworks as opposed to standardised technology. This approach aligns with the existing BIM standard (e.g., ISO 19650 [1]), focusing on HBIM as a tool for information management, decision support, and stakeholder collaboration, and ensures that, as technology advances, the guidance remains relevant.

1.2. Research Context

This section will briefly outline the key information required to provide context to this article. However, readers should refer to the contributing articles [12,85,86,87,88,89] for full details of each stage’s methodology and evaluations of results.

This article constitutes the culmination of a multi-year research project, of which there are six contributing articles [12,85,86,87,88,89], investigating the standardisation of HBIM. The aim of the research is to develop user-centric guidelines for the application of HBIM. Figure 1 is a pictorial representation of the project’s five-stage research methodology (1–5a, 5b), each numbered in Figure 1. This article corresponds with Stages 5a and 5b of the figure.

The research methodology used herein has been influenced greatly by the Technology Acceptance Model (TAM) [90], principles of participatory design [91], and established system design processes such as the v-process model [92]. The general principles are that systems should be defined in direct response to the needs of the system user, and that subsequent technological adoption is dependent on the extent to which end users perceive that system as useful.

In Stage 1 of the project, the standards, academic literature, and grey literature regarding HBIM, heritage management, and asset management were reviewed to determine the state of the art in HBIM application and to gather forty-one recommended information requirements for heritage management. Subsequently, a survey was designed to determine the current practices and challenges within heritage management and to validate the recommended information requirements. More information is available in the associated publications [12,85,86].

In Stage 2 of the project, the survey was distributed to the United Kingdom (UK) heritage community. The ‘heritage community’ refers to “people who value specific aspects of cultural heritage which they wish to sustain and transmit to future generations” [5]. The definition is intentionally broad so as not to unintentionally exclude potentially valuable perspectives. Thirty-three responses were received. As a result of the survey, the forty-one information requirements were found to be valid and a further twenty information requirements were identified. Systems thinking processes, namely, the Soft Systems Methodology [77,93,94,95,96], and systems engineering guidance (as provided by the International Council on Systems Engineering (INCOSE) [92,97]) were used to evaluate the results. Consequently, the subsequent root definition (core purpose) of HBIM was defined as follows:

“A system owned and maintained by members of the Heritage Community involved in the management and maintenance of cultural heritage, which, utilising BIM and HBIM technology financially viable to the Heritage Community, contains, in a structured and connected manner, all the information required for Heritage Management. The system makes information easy to locate to ensure informed management decisions.” [87].

The root definition describes the core purpose of HBIM according to the identified needs of the heritage community. A system that can be described using the root definition would be considered to meet the needs of the heritage community.

In Stage 3, INCOSE guidelines were used to define thirty-three system requirements for HBIM. More information regarding Stages 2 and 3 is available in the associated publications [87,88].

Finally, in Stage 4 [89], a survey of the international heritage community was undertaken to validate the proposed system requirements. A total of 60 responses were received validating the requirements. As a result of participant feedback, a key feature of the participatory design process, nine requirements were altered and one requirement (requirement I9) was added.

These validated system requirements are presented in

Table 1. Validated system requirements for HBIM. Reproduced from Lovell et al. [89] (authors’ own work).

Theme	ID	Requirement
Information management	I1	The HBIM system will contain a comprehensive and accurate record of asset information (regardless of form). Note—The types of asset information will likely be asset-specific.
	I2	The HBIM system will allow new information to be added over time whilst retaining previous information.
	I3	The HBIM system will have a search function for finding information.
	I4	The HBIM system will have a structured, reportable, and viewable data storage schema.
	I5	The HBIM system will allow information (irrespective of format) to be viewed or exported at different degrees of granularity.
	I6	The HBIM system will allow all information to be accessed from a single source (i.e., a single platform/software/database/hardware/etc.). Information may be stored elsewhere.
	I7	Information in the HBIM system should be associated with a digital entity with a known position in space.
	I8	The HBIM system will record and report each change made to asset information.
	I9	The HBIM system will contain comprehensive and accurate metadata regarding asset information. Note—The types of metadata may be asset/organisation specific.
Collaboration	C1	The HBIM system will present current planning/legislative/listing restraints in a manner clearly understandable to users without expert knowledge.
	C2	The HBIM system can share and receive information for related assets (both internally within an organisation and externally).
	C3	The HBIM system can present the same information in differing ways for a defined audience.
	C4	The HBIM data will be shareable with interested parties with specified access controls and monitoring processes. Example monitoring processes may include version control or download tracking.
	C5	The HBIM system will be aligned with existing BIM practices for non-heritage assets.
	C6	The HBIM system will integrate with other systems without duplicating information.
System operability	S1	The HBIM system will be accessible from multiple locations at the same time.
	S2	The HBIM information will be accessible to users without an Internet connection.
	S3	Users without an Internet connection can record new information to be input into the HBIM system.
Resource management and planning	R1	The HBIM system will indicate whether an area is private or open to the public and any restraints this poses, e.g., maintenance timing or increased level of risk for the public.
	R2	The HBIM system will collate and supply information required for funding applications.
	R3	The HBIM system will collate and supply information required to undertake defined activities.
	R4	The HBIM system can be used to digitally simulate planned activities.
	R5	The HBIM system will calculate the expected costs of user-defined work.
	R6	The HBIM system will record and report all details of each work activity undertaken and each future work activity planned.
	R7	The HBIM system will assist with the creation of proactive maintenance schedules, utilising both mandatory testing intervals, previous maintenance records, and current asset condition.
Visualisation	V1	The HBIM system will record and visually display information associated with the location of the asset.
	V2	The HBIM system will record and visually display each known or theorised (appropriately indicated) historic change to an asset (both large changes and small changes).
	V3	The HBIM system will provide a 3D visualisation of an asset.
	V4	The HBIM system will contain an accurate visual record of the current asset condition.
Public engagement	P1	The HBIM system will assist with the creation and dissemination of audience-appropriate informative materials and educational resources for the public.
Environmental management	E1	The HBIM system will record and visually display environmental hazards associated with the asset.
	E2	The HBIM system will monitor and report right-time data regarding the environmental conditions of the asset. Environmental condition derived from information such as temperature, light, humidity, weather, etc.
	E3	The HBIM system will monitor and report right-time data regarding the performance of the asset. Performance will be evaluated against organisation-specific targets.
	E4	The HBIM system will allow the comparison of current performance with predicted outputs of alterations and upgrades.

. A full analysis of how validity was assessed and how bias was reduced is provided in the contributing articles. For the purposes of this article, the system requirements should be viewed as an accurate reflection of the needs of the heritage community.

1.3. Introducing the HBIM Maturity Model

In this final stage of the research project the authors will evaluate the state of the art for HBIM implementation and will provide guidelines for HBIM development.

It is important to note that, at this stage of system design, the system requirements are technology-agnostic. The actual digital system implementation will be dependent on the financial, resource, and technical capabilities of the implementing organisation [98]. The purpose of these system requirements is to guide the function of HBIM as opposed to the form. The intention is that organisations will use the requirements to decide what they require an HBIM system to do, and then they will assess the available software and hardware against their own organisational factors.

It is widely acknowledged [81,99,100,101] that HBIM guidelines should be flexible, and, consequently, it would not be appropriate for the authors to propose guidelines that mandate the inclusion of all the proposed system requirements. The authors have previously recommended [88,89] that the proposed system requirements should be seen as a flexible guide for implementing HBIM, and that organisations looking to implement HBIM will have to evaluate for themselves which requirements are critical for their own assets. It is not expected that organisations will choose to, or need to, implement all the requirements as management needs vary. However, there are some key requirements that the authors propose are prerequisites for achieving an effective, useable, and long-term information management system. Likewise, simply assessing an HBIM system against the number of requirements it achieves would not accurately convey how well that system meets the actual needs of the heritage community.

Currently, the lack of standardised HBIM implementation guidance means there is a risk that organisations seeking to implement HBIM may miss potentially crucial requirements. Therefore, to address this issue, this article presents the HBIM Maturity Model. The model is inspired by building assessment models such as the Green Star Certification [102], the LEED rating system [103], and the BREEAM certification scheme [104]. Another comparable system would be the CMMI capabilities levels which assess organisational capability in a given area [105].

The HBIM Maturity Model is a flexible approach consisting of hierarchical levels, that enables the development and subsequent assessment of HBIM systems via a series of prerequisites and credits totals—to enable organisations to gradually develop their HBIM system maturity, and proficiency in sustainable heritage asset management.

The concept of maturity models is not new to the field of digital information management. For instance, the 2008 Bew-Richards BIM Maturity Model, although now superseded, described three achievable levels of BIM and informed early BIM guidance within the UK [106], and ISO 19650 [1] also discussed BIM development in terms of maturity. Similarly, in a 2020 review, Kim [107] discussed various proposed maturity models for digital twin development. Despite their prevalence in the sector, the authors are aware of no existing HBIM-specific maturity model.

The objectives (O1 to O3) of this article are as follows:

• O1—Detail the development of the HBIM Maturity Model (Section 2.1);
• O2—Evaluate to what degree the current HBIM application meets the needs of the heritage community (Section 3.1);
• O3—Evaluate the current HBIM application using the HBIM Maturity Model (Section 3.2).

Future work will be discussed in Section 4 and the conclusions are discussed in Section 5.

2. Materials and Methods

2.1. The HBIM Maturity Model

2.1.1. Contributing Data

The development of the HBIM Maturity Model and the analysis in this article utilises some data obtained from Stage 4 of the research project. This section will briefly describe only the information which is relevant to this work (full details of the previous work are available in Lovell et al. [89], the supporting data for which is openly available on the UBIRA E Data Repository and accessible at the following address: https://doi.org/10.25500/edata.bham.00001279 (accessed on 2 May 2025).

To validate the system requirements, a survey was undertaken with the international heritage community. A total of 60 responses (41 UK and 19 non-UK) were received (full details of the participants and detailed discussion of potential biases is provided in Lovell et al. [89]).

Respondents were asked to state whether a requirement was ‘critical’ (+3—a system that cannot achieve this requirement would not be useable in their role), ‘useful’ (+2—assists with/adds value to a task but work can progress without it), for a ‘wish-list’ (+1—viewed positively but not meeting the definition of ‘useful’ or ‘critical’), ‘not needed’, or ‘not relevant to their role’ (−1). For analysis, a response of ‘not relevant to my role’ was taken as neutral (0).

The survey question (asking participants to evaluate criticality) was a modified Likert scale. Assigning numbers to Likert scales is a recognised approach to enable some basic quantification of qualitative data [108]; hence, each response option was assigned a value e.g., a value of +3 for a response of ‘critical’. However, Likert scales are ordinal responses [109] which, in simple terms, means that the intervals of the scale are not fixed. For instance, whilst an answer of ‘useful’ was assigned a value of +2, this does not mean that it is twice as critical as a requirement deemed ‘wish-list’, which is assigned a value of +1. Consequently, the numbers themselves are arbitrary and are only intended to allow a general comparison of requirements where a higher number suggests greater perceived criticality.

From the values assigned to the survey responses, the average criticality was calculated using Equation (1) [89]. The only purpose of the equation is to enable some quantitative evaluation of the qualitative survey responses; e.g., a higher average criticality implies greater perceived criticality.

$$\mathrm{A}\mathrm{v}\mathrm{e}\mathrm{r}\mathrm{a}\mathrm{g}\mathrm{e} \mathrm{c}\mathrm{r}\mathrm{i}\mathrm{t}\mathrm{i}\mathrm{c}\mathrm{a}\mathrm{l}\mathrm{i}\mathrm{t}\mathrm{y}={\displaystyle \frac{\left(\mathrm{n}\mathrm{o}.‘\mathrm{C}\mathrm{r}\mathrm{i}\mathrm{t}\mathrm{i}\mathrm{c}\mathrm{a}\mathrm{l}’\times 3\right)+\left(\mathrm{n}\mathrm{o}.‘\mathrm{U}\mathrm{s}\mathrm{e}\mathrm{f}\mathrm{u}\mathrm{l}’\times 2\right)+\left(\mathrm{n}\mathrm{o}.‘\mathrm{W}\mathrm{i}\mathrm{s}\mathrm{h}-\mathrm{l}\mathrm{i}\mathrm{s}\mathrm{t}’\times 1\right)+(\mathrm{n}\mathrm{o}.‘\mathrm{N}\mathrm{o}\mathrm{t}\mathrm{n}\mathrm{e}\mathrm{e}\mathrm{d}\mathrm{e}\mathrm{d}’\times \left(-1\right))}{\mathrm{n}\mathrm{o}.\mathrm{r}\mathrm{e}\mathrm{s}\mathrm{p}\mathrm{o}\mathrm{n}\mathrm{s}\mathrm{e}\mathrm{s}}}$$

(1)

The results of the survey are displayed in Figure 2. Analysis of the survey results is given in Lovell et al. [89], so it will not be repeated herein. The pertinent data for this work is the number of respondents (60), the number of critical responses each requirement received, and the calculated average criticality of each requirement.

Requirement I9 is absent from Figure 2 as it was a new requirement added as a result of feedback received during the requirement validation process.

2.1.2. The Development of the HBIM Maturity Model

The first stage of the HBIM Maturity Model creation involved attributing ‘credits’ to the achievement of each requirement. One of the intended use cases of the HBIM Maturity Model was for the evaluation of the quality of HBIM systems. The underlying system engineering design principles that have informed the longitudinal research project [92] state that the quality of a system can be evaluated based on the extent to which it meets the needs of its users. Therefore, the HBIM Maturity Model should answer the following questions:

• Q1—What user needs does the HBIM system meet?
• Q2—Does the HBIM system meet the most important needs of its users?

The credit system had to reflect this.

The system requirements represent a technical translation of the needs of the user (answering Q1), and the calculated average criticality (Equation (1)) provides an initial estimation of the relative importance of each need (answering Q2). Therefore, the average criticality was used as the starting point for assigning credits to a requirement.

Since Requirement I9 was added as a result of the validation activity, no criticality score was available. For the purposes of credit assignment, the authors assumed the requirement to have the same criticality as Requirement I1 as they are both related to storing information. Whilst this may result in an overestimation of the importance of Requirement I9, it was decided that, until other evidence is available, it was more appropriate to overestimate rather than underestimate the requirement’s importance. Future work involving additional survey distribution will gather the evidence required. The authors also required the HBIM Maturity Model to be quick to use and easy to understand. This was informed by technology acceptance model, where the use of technology is partially dependent on how easy it is to use.

Simply assigning the average criticality to the credit values would have resulted in credits that were difficult to add up (e.g., Requirement E4 would have had 2.19 credits assigned) and would have made it hard to understand what percentage of the total credits had been achieved (the total available credits would have been 68.58). Consequently, it was decided that the total available credits should equal 100, making calculating the percentage achieved easier, and the available credits for each requirement should be rounded to the nearest 0.5, allowing easy addition.

To achieve this, the following operations occurred for each requirement. Firstly, the average criticality for each requirement was scaled so that the sum of the average criticalities was equal to 100 (see Equation (2)):

$$\mathrm{S}\mathrm{c}\mathrm{a}\mathrm{l}\mathrm{e}\mathrm{d} \mathrm{a}\mathrm{v}\mathrm{e}\mathrm{r}\mathrm{a}\mathrm{g}\mathrm{e} \mathrm{c}\mathrm{r}\mathrm{i}\mathrm{t}\mathrm{i}\mathrm{c}\mathrm{a}\mathrm{l}\mathrm{i}\mathrm{t}\mathrm{y}=\mathrm{a}\mathrm{v}\mathrm{e}\mathrm{r}\mathrm{a}\mathrm{g}\mathrm{e} \mathrm{c}\mathrm{r}\mathrm{i}\mathrm{t}\mathrm{i}\mathrm{c}\mathrm{a}\mathrm{l}\mathrm{i}\mathrm{t}\mathrm{y}\times \left({\displaystyle \frac{100}{\mathrm{S}\mathrm{u}\mathrm{m}\left(\mathrm{a}\mathrm{v}\mathrm{e}\mathrm{r}\mathrm{a}\mathrm{g}\mathrm{e} \mathrm{c}\mathrm{r}\mathrm{i}\mathrm{t}\mathrm{i}\mathrm{c}\mathrm{a}\mathrm{l}\mathrm{i}\mathrm{t}\mathrm{y}\right)}}\right)$$

(2)

Then, the scaled average criticality was rounded to the nearest 0.5.

Table 2. Example of the credit assignment process for Requirement I1.

Average Criticality	Scaled Average Criticality	Scaled Average Criticality Rounded to the Nearest 0.5
2.483333333	3.620899149	3.5

provides an example of the process used for Requirement I1. Full data is provided as part of the supporting data which is openly available in the UBIRA E Data Repository and accessible at the following address: https://doi.org/10.25500/edata.bham.00001557 (accessed on 2 May 2025).

The process was repeated for all system requirements. This resulted in a credit total of 99.5. In order for the credit total to equal 100 and a percentage of achievement to be calculable, the credits assigned to Requirement I4 were increased from 3.5 to 4. The justification for this increase is that the authors believe Requirement I4 is critical for the longevity of an HBIM system and that it facilitates interoperability with other systems [110,111].

Table 3. System requirements and achievable points in the HBIM Maturity Model.

Requirement Theme	ID	Credits Available	Total Credits
Information management	I1	3.5	31.5
	I2	4
	I3	4
	I4	4
	I5	3
	I6	3
	I7	3
	I8	3.5
	I9	3.5
Collaboration	C1	3	17.5
	C2	3
	C3	2.5
	C4	3.5
	C5	2.5
	C6	3
System operability	S1	3	7
	S2	2
	S3	2
Resource management and planning	R1	2.5	19
	R2	2.5
	R3	3
	R4	2.5
	R5	2.5
	R6	3
	R7	3
Visualisation	V1	3.5	13
	V2	3
	V3	3
	V4	3.5
Public engagement	P1	2.5	2.5
Environmental management	E1	3	9.5
	E2	2
	E3	2
	E4	2.5
Total			100

shows the credits attributed to each requirement.

It should be noted here that the credit assignment in Table 3 is ‘Version 1’ of the HBIM Maturity Model credits. The average criticality values that informed the credit assignment were informed by the opinions of the survey participants. Therefore, if additional survey responses were gathered, an already suggested avenue of future work, the average criticality would change, and the credits assigned to each requirement would need to be adjusted accordingly.

In addition, the average criticality value, which served as the starting point for credit assignment, only represents the perceived criticality (usefulness) of a requirement. This is a useful metric as perceived usefulness is directly related to long-term use (see Technology Acceptance Model discussion). However, perceived usefulness is a subjective metric, and the actual usefulness of a requirement may vary. With the data available to the researchers at the time, it is not possible to accurately quantify this. Likewise, alternative analysis methods, such as multi-criteria analysis, would have required knowledge of how a requirement might be achieved so that other criteria (e.g., cost) can be considered. As previously stated, the system requirements only describe what should be achieve as opposed to how it should be achieved.

To overcome these limitations, future work will involve the distribution of the HBIM Maturity Model to the wider heritage community for use and empirical validation. Feedback received at this stage might result in additional changes to the credit assignments.

Subsequently, the authors derived the assessment criteria for achieving each level within the HBIM Maturity Model. Four levels are described. The minimum requirements, credit requirements, and a description of each level are displayed in

Table 4. HBIM Maturity Model levels.

Level	Minimum Requirements	Credit Requirements	Description of Level
Level 1	Must achieve Requirements I2 and I4. Must demonstrate progress towards achieving Requirement I1 1.	Minimum of 20 credits.	A sustainable, long-term information storage solution for an organisation. Information will be retrievable and retained by the system owner throughout the asset lifecycle.
Level 2	Must achieve Requirements I2, I4, C4 and either V1 or V4. Demonstrable progress towards achieving Requirement I1 1.	Minimum of 30 credits.	Level 1 plus: Some information will be available in a visual format and collaboration with members of the heritage community beyond the system owner will be possible.
Level 3	Must achieve Requirements I1, I2, I3, I4, I7, C4 and either V1 or V4.	Minimum of 40 credits.	Level 2 plus: The system makes information easy to locate by linking the information with a digital object and by having providing a mechanism for searching information.
Level 3*	Must achieve Requirements I1, I2, I3, I4, I7, I8, I9, C4 and either V1 or V4.	Minimum of 50 credits.	Level 3 plus: The information within the system is traceable and verifiable.

¹ Supporting evidence would consist of the following: 1. an organisation-specific list of information requirements; 2. an actionable plan of the actor/s responsible for the procurement and maintenance of a specific information requirement; 3. a defined plan for how each information type will be stored within the system; 4. a proposal for how often a specific information type will need to be updated/reviewed and the actor/s responsible for this; and 5. evidence of 1–4 being implemented e.g., one information type has been collected and stored in the system.

. Level 1 describes a good, albeit simple, organised data management system. There is no requirement for a 3D model to achieve Level 1. An HBIM system that does not achieve the requirements for Level 1 is defined as Level 0. Level 2 describes a great, organised data management system which incorporates some of the visualisation and collaboration benefits associated with BIM. A system achieving Level 3 would be considered an exemplary HBIM system. The fourth level is named ‘Level 3*’ as the difference between a system achieving Level 3 and 3* is marginal. The key distinction between the two is that an HBIM system achieving Level 3* will have traceable and verifiable information.

The minimum requirements for each level were derived from the requirements deemed most critical by the heritage community (attributed at least 3.5 credits), the principles in ISO 19650-1:2018 [1], and best practice principles for information system definition [112], and asset management [6,82,83]. Previous works [113,114] have proposed new terminology specifically for HBIM. However, the authors believe that developments in International BIM standards [1], primarily “level of information need” [115], can be applied proportionately to the needs of the heritage community, in a way that aligns with international procedure. Furthermore, BIM is, in many countries, mandated for new construction. The authors would argue that, since it is not possible to know which of these new assets will be considered heritage in the future, the only way to ensure the longevity of BIM is to align HBIM with BIM practice.

Each level of the HBIM Maturity Model is designed to provide direct benefits for the end user in response to existing issues with and features of heritage information management (identified in the first survey of the research project [87,88]), and the level description encompasses the key envisioned benefits.

Table 5. Problem/feature of heritage management and how it is addressed by each level.

Level	Problem/Feature of Heritage Management [87,88]	How Level Addresses Problem/Feature
Level 1	Information is difficult to find due to ad hoc information storage processes. Much information retrieval is dependent on individual knowledge and can be lost when an individual leaves the organisation. Historic information may be lost, resulting in duplicating previously created information.	A structured, reportable, and viewable data storage schema (I4) means that any individual with access to the schema can locate information. The schema can be passed to successors and information management will be consistent [116]. The system can store historic data, as well as new data (I2), meaning the organisation can continue to use the system as time progresses.
Level 2	Heritage management often involves the collaboration of external stakeholders (e.g., subject specific experts), as well as individuals with limited technical experience.	The asset owner can share information securely with external stakeholders (C4). The visualisation capabilities (V1 or V4) can assist with explaining topics with individuals with less technical expertise.
Level 3	Retrieving relevant information is a time-intensive process. When information is prepared by a technical expert, it can be difficult for layman users to know what to look for.	The system can be quickly and easily queried (I3). Users of the system do not need to know naming classifications (etc.) to find data. Data can be retrieved by knowing what the physical item looks like and/or where it is (I7).
Level 3*	Insufficient data may result in uncertainty regarding the quality and reliability of historic data. This can make decisions, which must be informed by a good knowledge of the asset history [7].	The system tracks changes to data over time (I8) and contains sufficient metadata (I9) that added information can be traced and verified in perpetuity.

describes the key issue/feature of existing heritage management practices [87,88] and how the level addresses the issue/feature.

Generally, the requirement must be assessed as fully achieved before credits can be earned. However, the exception to this is Requirement I1 (“The HBIM system will contain a comprehensive and accurate record of asset information (regardless of form)”). Meeting the minimum requirements of Level 1 and Level 2 requires only demonstrable progress towards achieving I1. This is to account for the large variation in the amount of information associated with a heritage asset and the limited resources typically available to heritage organisations.

However, the required evidence to prove demonstrable progress towards achieving Requirement I1 (given in Table 3) is not insubstantial. The required evidence was derived from the principles in ISO 19650-1:2018 [1] and the authors believe that, whilst the process may require significant upfront effort, it is critical to the long-term efficacy of the information management system.

To assist organisations with defining their own, organisation-specific, information requirements, the HBIM Maturity Model assessment tool, which is openly available in the UBIRA E Data Repository and accessible at the following address: https://doi.org/10.25500/edata.bham.00001557 (accessed on 28 May 2026), contains a list of suggested high-level information requirements. These information requirements were defined in an earlier stage of the research project, initially via consulting existing guidance [86], and then subsequently validated via consultation with the heritage community [88].

The authors would also advise the use of the “level of information need” principles outlined in ISO 7817-1:2024 [115] to ensure that organisations collect the right amount and types of information to meet their actual management needs. The “level of information need” has a proven efficacy for defining HBIM information requirements in a heritage context [57,59,61,117].

For Level 2 and higher, the system must provide some visualisation capabilities. This can be achieved via either V1 (“the HBIM system will record and visually display information associated with the location of the asset”) or V4 (“the HBIM system will contain an accurate visual record of the current asset condition”). This is to account for different types of CH (e.g., heritage landscapes) and for variations in existing heritage documentation practice worldwide. For instance, the UK recently launched Arches for Historic Environment Records (Arches for HERs) [118], a digital information management system that can be used in combination with GIS, which displays data at the location scale. It is the responsibility of the asset owner to decide which is more appropriate for their needs. Asset owners may also seek to achieve both V1 and V4.

The minimum credits required for each level are an intentionally low proportion of the total available (100). They are intended to be only slightly higher than the credits gained after achieving the prerequisite requirements for each level. This is to ensure that organisations are encouraged to achieve additional requirements (by having to implement more than the prerequisites to achieve a level) but are still able to critically choose which requirements to implement (by not having to excessively implement requirements in order to achieve the minimum required credits). There are several justifications for this.

Firstly, the HBIM Maturity Model must account for the diversity of heritage assets and the organisations who steward them. It is expected that some types of heritage asset or organisation will make certain system requirements obsolete. For instance, an organisation caring for a private site would be unlikely to need to create educational resources for the public (Requirement P1). The intention is that Level 3* should be attainable for all organisations and heritage types. Increasing the credit requirements could unintentionally exclude assets from the higher maturity levels.

Furthermore, any system feature or functionality within an HBIM system should be directly related to a defined organisational need. Any surplus features would be considered waste. More specifically, applying the TIMWOODs (Transport, Inventory, Motion, Waiting, Overproduction, Overprocessing, Defects, and Skills) acronym for sources of waste in lean manufacturing [119], this would be considered overprocessing waste, doing more than is required. This waste, and the consequent environmental impact of the HBIM system itself, risks counteracting the sustainability benefits of HBIM, such as informed decision making, the ability to evaluate energy performance, and more efficient resource use [43,120]. The authors believe that increasing the point requirements would encourage this waste.

In addition, cost of implementation can be a key barrier to HBIM implementation [87]. Therefore, requiring HBIM systems to achieve an overtly high level of credits and be assessed as ‘good’ would likely discourage the intended end users from attempting to adopt them to begin with. Likewise, if achieving a higher level requires a significant number of additional credits, then organisations may be less likely to improve their HBIM systems, consequently missing out on the additional benefits of a more mature HBIM system. The authors strongly believe that simple systems are sufficient to make significant improvements for many heritage organisations.

Digital sustainability is becoming an increasingly prevalent topic of discussion [121] and is even a part of UK Government strategy [122]. The lack of available funds to the heritage community may be perceived as a barrier to implementing HBIM; however, it may also prove advantageous to implementing digital tools as sustainably as possible. The authors would argue that the heritage sector is best placed to pioneer digital sustainability. If a designed HBIM system can achieve the maximum benefit with the minimum possible overhead (due to resource limitations), it will also result in an HBIM system that is as lean as possible.

The heritage community also already possesses the skills to design systems in this way, with the concept of minimum intervention being a key principle in heritage management worldwide [7]. Similar principles should be applied by other sectors looking to employ digital information management tools so that they do not use excessive resources simply because they can afford to.

2.2. HBIM Case Study Evaluation

2.2.1. Selection Criteria

In Section 3, HBIM case studies are evaluated against the validated HBIM system requirements (Section 3.1) and the new HBIM Maturity Model (Section 3.2) to assess how well current HBIM practice meets the identified needs of the heritage community.

The SCOPUS database was used to identify relevant case studies. To ensure consistency with the authors’ previous literature review on HBIM [12], the same keyword search, “HBIM” AND (“cultural heritage” OR “built heritage”), was used. Likewise, to avoid duplicating their previous work, the date range was limited to articles published from 2023 onwards. Two hundred and three papers were initially returned by this search.

The initial sample of papers were then evaluated for relevancy. Papers were not filtered geographically. Papers fitting the following descriptions were removed from the sample:

• Theoretical frameworks and literature reviews;
• Articles discussing point cloud segmentation and automatic mesh generation, the exception to this being Avena et al. [123], who, whilst investigating automatic mesh creation and segmentation, did convert the created mesh into a parametric Revit object;
• Articles that focused on geometric surveys without elaborating on the HBIM methodology;
• Case studies of moveable objects, the exception being objects that are a physical architectural part of the building, such as the altar described by Scandurra et al. [110]. The justification for their exclusion is that the HBIM system requirements were defined at asset level so several would not be relevant to many moveable objects. Therefore, evaluating the case study against the requirements would provide an overly negative assessment of the case study. Whilst there are potentially relevant articles, such as the work by Moyano et al. [124], that investigate the modelling of movable objects, these are not considered significantly novel that their exclusion is detrimental to the findings of this article;
• Case studies of roads. Whilst some interesting historic road case studies exist [125,126], they were, like moveable objects, considered to have fundamentally different management considerations to buildings. Notably, bridge case studies were included because the survey used to define the requirements had respondents who worked with both bridges and buildings in a singular organisation;
• Articles using the HBIM methodology to recreate lost heritage unless there were plans to restore the heritage asset in the future. Whilst a valuable use case for HBIM technology, they are not created with the intention of being used for management activities;
• Case studies that included insufficient technical details to be repeatable. For instance, Ortiz Villarejo et al. [127] detail a pilot case study for the DIGITALESCAPE project. Whilst the paper is interesting and the project has undeniable benefits for evaluating the impacts of climate change on cultural heritage, the exact HBIM approach, being only a minor element of the overall project and, thus, a minor focus in the article, lacks specificity, and is thus excluded from the case study analysis.

When several papers were published on the same case study, only one paper was included in analysis unless the others were deemed significantly different. This was done so as to not overrepresent the number of case studies that had achieved a given requirement. A total of 122 relevant case studies were identified [13,14,15,16,17,19,23,24,25,27,29,30,31,32,33,34,35,36,37,39,40,41,42,44,45,46,47,48,49,50,51,52,57,58,59,60,61,62,64,67,68,71,72,73,74,99,101,110,111,116,117,120,123,128,129,130,131,132,133,134,135,136,137,138,139,140,141,142,143,144,145,146,147,148,149,150,151,152,153,154,155,156,157,158,159,160,161,162,163,164,165,166,167,168,169,170,171,172,173,174,175,176,177,178,179,180,181,182,183,184,185,186,187,188,189,190,191,192,193,194,195,196]. Readers may refer to the supporting data (see data availability statement) for full details of the selected case studies.

Table 6. The number of case studies per country.

Country	Number of Case Studies
Italy	54
Spain	12
Brazil	6
China	5
Jordan	5
Egypt	4
Poland	4
Saudi Arabia	4
Indonesia	3
Turkey	3
United States of America	3
Morocco	2
Portugal	2
Algeria	1
Canada	1
Czech Republic	1
Ecuador	1
El Salvador	1
France	1
Greece	1
Iran	1
Iraq	1
Korea	1
Republic of Mozambique	1
North Macedonia	1
Pakistan	1
Peru	1
Switzerland	1

reports the twenty-eight different countries where the case studies were located. Whilst the case studies were geographically diverse, approximately 45% of the case studies were located in Italy. As previously discussed, this was expected as the 2017 Italian BIM mandate [4] and large quantity of CH assets within the country have positioned Italy as an epicentre of HBIM development in recent years.

2.2.2. Evaluation of HBIM Case Studies

The chosen case studies were then evaluated against the established HBIM system requirements (Table 1). For each article, it was noted whether the requirement can be considered achieved. A requirement was only considered to be achieved if it was explicitly mentioned in the article. For the purposes of Requirements I1 and I9, since the exact information requirements will be asset-specific, the requirement was deemed achieved if the case study mentioned an information/metadata type besides geometric data and referred to some method of inclusion.

The authors acknowledge that only accepting explicit referral means that the evaluation may underrepresent the actual number of requirements that are achieved. For example, many of the examples of software used had capabilities that could theoretically achieve other requirements. However, explicit referral was considered critical for three key reasons. Firstly, many of the case studies integrated multiple types of software and it was unknown how the integration may have impacted individual software capabilities. Likewise, the assessment would also have been limited by the authors’ own knowledge of the software in use. Moreover, the research project is reliant on system design principles such as the TAM [90]. A key concept of TAM is that actual technology use is dependent on the “perceived usefulness” of the technology by the end user. Assuming that the end users in this case are individuals involved in the management and maintenance of built heritage, who, as previous research has found [87], typically only have theoretical BIM knowledge, then it should be assumed that they will not have in-depth technical knowledge of the capabilities of the software being used in the case studies. Therefore, if the end user were to read the case study, they may not perceive the system as useful (meeting their requirements) if it is not explicitly mentioned.

Academic publications do not always talk about every single capability of the systems they develop. This may be due to the constraints inherent to different publication styles. For instance, a publication prepared for a conference is likely to be restricted in length, and, consequently, the authors must limit their discussion to that which they consider most novel about their work. They are therefore unlikely to talk about elements of an HBIM system which they consider as ‘taken as given’ for those familiar with BIM. For example, the use of a common data environment (CDE), a central repository for all asset information, is a principal element of the BIM methodology [1] and discussion of a CDE would contribute to achievement of Requirement I1. However, since a CDE is such a fundamental component of BIM, academic publications may consider it superfluous to mention.

Since academic endeavours remain one of the largest sources of actual HBIM implementation, they are, in turn, the primary advertising source for heritage managers to find out more about HBIM. However, the implicit assumptions regarding what authors of academic publications consider to be ‘taken as given’ for HBIM introduces an unacknowledged bias into how HBIM is advertised.

The authors hope that, whilst the evaluation technique used herein depicts an academic bias regarding what functionalities are discussed, it will encourage other authors to think differently about the features they draw attention to in future publications.

Within the analysis, for each achieved requirement, a brief note was included detailing how it was achieved. System requirements, at the level of analysis occurring in this research project, do not need to establish how a requirement should be achieved [92], and the authors do not believe there is one definitive way each requirement should be achieved. They also do not wish to suggest that one way is more effective than another since actual implementation will vary according to individual organisational restraints and capabilities. Therefore, this article will not discuss how the requirements were achieved unless it is relevant to the wider discussion of results. The results of the evaluation are freely available online (see data availability statement) for anyone who wishes to investigate how a requirement might be achieved. The authors would stress that the evaluation constitutes a short moment in time (from 2023 to mid-2025), so it may not represent new innovations, and was subject to the risk of interpretive error by the authors of this paper. It is not intended as the definitive explanation of how the proposed system requirements may be achieved, and anyone seeking to find out more should refer to the original case studies and their authors in the first case.

Section 3.1 will use the results of the case study evaluation to evaluate to what extent the HBIM case studies meet the needs of the heritage community. In Section 3.2, the case studies will be further evaluated using the HBIM Maturity Model. Discussion will involve what levels were achieved and why case studies did not achieve a particular level.

3. Results and Discussion

3.1. Evaluating the Extent to Which Current HBIM Application Meet the Needs of the Heritage Community

Figure 3 compares the percentage of papers that achieved a requirement with the percentage of survey respondents (from the 60 respondents in the requirement validation stage [89]) that believed a requirement was ‘critical’ (e.g., a system that did not achieve this would not be useable in their role). Requirement I9 was added as a result of the requirement validation stage so no data is available for the percentage of critical responses. These metrics were chosen for comparison because the authors believe they most effectively convey the difference between what the academic community perceives as most critical (i.e., what they choose to write about) and what the end users perceive as most critical. There is evidently a disparity between the two. For conciseness, this article will only discuss requirements where the difference between the percentage of case studies that achieved the requirement and the percentage of critical survey responses is greater than 20 (deemed to be a significant difference). The exception to this is Requirement V1. Whilst the difference in percentages was less than 20, the requirement was considered critical (as indicated by the assigned credits of 2.5 (see Table 2)) so failure to achieve the requirement was considered significant.

Most importantly, Requirements I2, I3, and I4 were deemed the three most critical requirements by the heritage community but less than 30% of papers explicitly mentioned them. Cultural heritage assets should, all being well, be managed for many years, likely by many different people. Given this fact, Requirements I2 (“HBIM system needs to allow new information to be added over time whilst retaining previous information”) and I4 (“HBIM system needs to have a structured, reportable and viewable data storage schema”), which enables new users to identify how data is managed, are arguably essential prerequisites for an information management system to assist with heritage management. Nevertheless, these requirements are rarely reported as addressed in the literature. Similarly, less than 2.5% of papers mentioned methods for achieving Requirement I8 (“HBIM system needs to record and report each change made to asset information”), a requirement that would enable the traceability and verification of data over time.

Admittedly, many of the case studies could, given the software used, be reasonably expected to achieve Requirement I3 (“HBIM system needs to have a search function for finding information”). The same is true for Requirement C4 (“the HBIM data will be shareable with interested parties with specified access controls and monitoring processes. Example monitoring processes may include version control or download tracking”), which less than 10% of papers addressed, but which is often possible with commercial BIM software. However, as previously noted, only an explicit reference was accepted.

One potential explanation for the lack of reported achievement of C4 is that many of the case studies reviewed were created purely as an academic endeavour. Therefore, for many, the data was only required to be shared among the individuals creating the system. Consequently, discussing access controls may have been irrelevant to the subject of the paper. This may also explain the lack of reported achievement of Requirement S1 (“HBIM system needs to be accessible from multiple locations at the same time”).

Requirement C1 (“HBIM system needs to present current planning/legislative/listing restraints in a manner clearly understandable to users without expert knowledge”) was only accomplished by one article [157], whereas 33% of survey respondents believed it was a critical requirement. Fernandes Dionizio et al. [157], who included the information as a textual description, are proof that achieving Requirement C1 does not need to be a complicated process. Similarly, Requirement R1 (“HBIM system needs to indicate whether an area is private or open to public and any restraints this poses e.g., maintenance timing or increased level of risk for public”) was only reported as achieved by Suhari et al. [168], whose system included a relatively simple function for enabling users to filter what areas were public or private.

Almost all papers (approximately 99%) achieved Requirement V3 (“HBIM system needs to provide a 3D visualisation of an asset”) despite a relatively low perceived criticality (approximately 28%) by the survey respondents. However, this is to be expected given the search criteria for papers (HBIM), and the fact that HBIM is an object-based information management process. Furthermore, the HBIM-oriented scope of the search may also explain the minimal achievement of Requirements V1 (“HBIM system needs to record, and visually display information associated with the location of the asset”) and E1 (HBIM system needs to record and visually display environmental hazards associated with the asset”). Information associated with the location of the asset (many environmental hazards are also related to the location, e.g., seismic hazards or flood risks) is typically stored in GIS-related systems. Whilst some of the evaluated case studies did investigate HBIM and GIS integration [22,23,24,25,26,27,28,56,141,157,182,194,197,198], there are acknowledged interoperability issues with HBIM and GIS systems [199,200,201,202], so it is less likely that case studies utilising HBIM-related software would also achieve Requirements V1 and E1. Future work could address this limitation by expanding the case study evaluation to include digital information management systems for heritage that are not exclusively HBIM.

Notably, a significant portion of case studies (approximately 73%) achieved Requirement C5 (“HBIM system needs to be aligned with existing BIM practices for non-heritage assets”) despite a lower perceived criticality by the heritage community (approximately 20%). Requirement C5 was achieved via a number of mechanisms including but not limited to the following: the HBIM model was created using established software and methodologies (e.g., parametric models created in Revit or ArchiCAD); all outputs were made compatible with the IFC format (the open exchange format for BIM [203]); and the project was planned and executed according to existing BIM standards (e.g., often utilising the ISO 19650 standard [1] and the concept of ‘level of information need’ [115]). The latter is significant since, at the beginning of the longitudinal research project, of which this article constitutes the final part, the authors posed the question “to what extent can HBIM be aligned with the existing and future developments of ISO 19650?” [12]. Having reviewed the contents of ISO 19650-1:2018 [1] and now seeing the high percentage of case studies that are aligned with the existing developments of ISO 19650, the authors would argue that there is no reason HBIM should not be aligned with the existing and future developments of ISO 19650. This is also reflected by the proposed HBIM Maturity Model, which is heavily influenced by the concepts outlined in ISO 19650-1:2018 [1].

The evaluation suggests that HBIM case studies are not reporting outputs that address the requirements of the heritage community. Since the perceived usefulness of a system is directly related to its subsequent adoption [90], this should be considered a key deficiency of academic HBIM development to date.

However, all but one of the system requirements was achieved by at least one case study. No case study reported outputs which achieved Requirement R2 (“the HBIM system will collate, and supply information required for funding applications”). Whilst a relatively low proportion of survey respondents believed it was critical (approximately 22%), it may provide a novel research topic for future work. The case study evaluation supports the argument that all the system requirements are achievable with current technology. Thus, the authors suggest the greatest barrier to HBIM adoption is that the publicly advertised perception of HBIM does not address the needs of its end users.

3.2. Evaluating HBIM Case Studies Using the HBIM Maturity Model

After the requirements that each case study had achieved were recorded, the results were input into the HBIM Maturity Model Assessment Tool. Figure 4 depicts the number of papers that achieved each level: 112 achieved Level 0, 8 achieved Level 2, 2 achieved Level 3, and no case studies achieved Level 1 or 3*. The reasons why a case study at Level 0 did not achieve Level 1, a case study at Level 1 did not achieve Level 2, and a case study at Level 3 did not achieve Level 3* are depicted in

Table 7. Reasons why Level 0 systems did not achieve (DNA) Level 1.

Credit Totals	Minimum Requirements	No. of Case Studies
Too few credits	DNA I1, I2, nor I4	51	73
	DNA I1 nor I2	5
	DNA I2 nor I4	19
	DNA I1 nor I4	1
	DNA I2	2
Sufficient credits	DNA I1, I2 nor I4	1	34
	DNA I1 nor I2	3
	DNA I1 nor I4	2
	DNA I2 nor I4	12
	DNA I1	1
	DNA I2	11
	DNA I4	4

,

Table 8. Reasons why Level 1 systems DNA Level 2.

Credit Totals	Minimum Requirements	No. of Case Studies
Too few credits	All achieved	1	2
	DNA C4	1
Sufficient credits	DNA C4	5	6
	DNA V1 or V4	1

, and

Table 9. Reasons why Level 3 systems DNA Level 3*.

Credit Totals	Minimum Requirements	No. of Case Studies
Sufficient credits	DNA I8	1	2
	DNA I8 nor I9	1

, respectively.

Looking at Figure 4 and Table 7 alone may suggest a rather bleak outlook on the quality of HBIM case studies to date, since the majority of case studies failed to achieve Level 1. Many of the Level 0 case studies were still at the early stages of HBIM implementation with a singular, or at least primary, focus on geometric modelling [13,14,15,16,17,18,19,20,21,30,72,116,142,148,149,150,163,176,183,184,186,196]. Hence, they rarely discussed Requirements I1, I2, or I4. This is consistent with the previous review undertaken by the authors [12]. However, there also appear to be fewer instances where the effort required for modelling is seen as an insurmountable problem, perhaps due to modelling approaches for HBIM becoming more established. It is now evident that the limitations of an idealised geometric model may be overcome by conducting a deviation analysis between the point cloud and the model, such as in the works by Wang et al. and Quattrini et al. [33,193].

Likewise, there is a notable increase in the use of parametric modelling as opposed to Non-Uniform Rational B-Spline (NURBS) modelling (or similar). This is likely an effort to (as claimed by Quattrini et al. [193]) align HBIM with BIM for new build projects which would consequently enable a system to achieve Requirement C5. Similarly, whilst Sampaio et al. [149] may have primarily discussed the modelling approaches used, they also comprehensively describe the data collection process, and it is explicitly mentioned that the modelling approach (parametric) has been chosen to enable organised data management. The paper itself is titled as “first steps” so it is reasonable to expect further developments. Several other case studies had future stated developments for their HBIM model, such as Garramone et al. [196], who intended to integrate a monitoring system and use the HBIM as a single, updateable repository for all maintenance information.

Moreover, seven of the Level 0 case studies achieved received over 30 credits (the credit total required for Level 2). Of these seven, four of them only failed to achieve I2, one only failed to achieve I4, one failed to achieve I1 and I4, and one failed to achieve I2 and I4. Achieving these requirements is not insurmountable and may well have been implemented by the case studies and just not mentioned in the published literature for the previously mentioned reasons (see Section 2.2.2).

Therefore, whilst many of the Level 0 case studies do not yet meet the minimum requirements for Level 1, the authors are optimistic that many will, as their reported planned future work is undertaken.

Case studies that achieved Level 1 present good examples of HBIM implementation. For instance, the work of Celli and Ottoni [147] is one of the few instances where information management is treated as the primary concern of HBIM. They consequently achieve fourteen of the proposed requirements, with the likely potential to achieve more with their planned future developments.

Regarding Table 8, the primary reason six of the eight case studies were not eligible for Level 2 is that they failed to achieve Requirement C4 (“the HBIM data will be shareable with interested parties with specified access controls and monitoring processes. Example monitoring processes may include version control or download tracking”). As previously discussed, many of the case studies reviewed were created purely as an academic endeavour, in which case the data was only required to be shared among the individuals creating the system. Consequently, discussing access controls may have been irrelevant to the subject of the paper. Regardless, C4 remains a critical requirement for the heritage community because actual heritage management involves the contributions of various subject experts.

The case studies that achieved Level 3 [49,194] should be considered exemplars of HBIM implementation. For instance, the Main10ance project [28,194] is an open-source web-based HBIM-GIS integration that achieved seventeen of the suggested requirements, with future planned developments that will achieve several others (e.g., virtual tours which would encompass Requirement P1). It addresses many of the challenges facing heritage management (e.g., multiple actors contributing to a project, issues regarding data security, a desire for more active maintenance, etc.). It is arguably one of the best bespoke systems available at the time of writing. Whilst the system is bespoke and currently all in Italian, its open-source nature means it could reasonably be applied on a wide scale for heritage management.

Likewise, the project described by Cardinali et al. [49] also achieves seventeen of the requirements. A key reason for this is the detail that is provided regarding how information should be managed (including storage methods and naming conventions). Whereas the Main10ance Project utilised open-source software, the project by Cardinali et al. utilised Revit, a proprietary software, for model creation. This supports the authors’ assertion that there is no singular technology which is the most appropriate for HBIM implementation and that software decisions should be based on organisation-specific factors. However, it is worth noting that both projects advocated for the use of open standards, namely, the Industry Foundation Class (IFC), to enable greater cross-platform interoperability.

It should be noted that both projects that achieved Level 3 are multi-year, multi-actor developments, hence their high maturity.

As shown in Table 9, the reason the Level 3 case studies failed to achieve Level 3* is that they both did not achieve I8 [49] and one also failed to achieve I9 [194]. Regardless, the case studies provide evidence that many of the proposed system requirements can be simultaneously achieved by an HBIM system.

4. Future Work

There are three distinct avenues of future research. Firstly, the HBIM Maturity Model is version 1 of the proposed model. The current HBIM Maturity Model should be distributed to the wider heritage community for use/feedback and further empirical validation. The feedback received at this stage could be used to adjust and/or validate the proposed model. Likewise, as discussed in Section 2.1.2., the scope of the survey used to calculate ‘average criticality’ should be increased to gather additional responses from different regions. The credit assignments and prerequisites should be updated according to this feedback. This future work should be repeated on an ongoing basis to account for changing needs in the heritage community.

Secondly, the current case study evaluation is limited to academic case studies only. This, in turn, is limited by the bias introduced by academic publishing (e.g., the omission of elements assumed to be ‘taken as given’). The authors of the evaluated case studies could be approached directly to perform a more complete evaluation of case studies. The scope of the case study evaluation could be increased to involve digital information management case studies which are not explicitly HBIM, and case studies detailed in the grey literature. At the time of writing, there is an ongoing MSc project at the University of Birmingham intending to survey industry practitioners to evaluate their current HBIM Maturity using the HBIM Maturity Model.

Lastly, future work should involve the use of the HBIM Maturity Model for the definition, and subsequent deployment of, an HBIM system. This definition will, as with any BIM implementation, need to consider the influencing socio-economic factors [98] of a given organisation, such as its financial, resource, and technical capabilities. An element of the definition may also choose to compare the use of open-source or proprietary software for HBIM system development. The evaluation of the resulting HBIM system will also provide further evidence to validate the HBIM Maturity Model.

5. Conclusions

This article presents the first HBIM Maturity Model, a flexible framework designed to guide HBIM implementation and allow the evaluation of HBIM systems against the needs of the international heritage community. The Maturity Model constitutes the culmination of a multi-year research project involving iterative engagement with the international heritage community. It describes four achievable levels that are evaluated based on a series of prerequisite system requirements and minimum credits. Credits are gained by demonstrating the achievement of a series of HBIM system requirements, co-created with the international heritage community. The article details the development of the Maturity Model (Objective O1) including the derivation of credits, and the key issues/features of heritage management that each level addresses.

Subsequently, the article evaluated to what extent the current HBIM application meets the needs of the heritage community (Objective O2). One hundred and twenty-two HBIM case studies were evaluated. The results of the evaluation determined that HBIM case studies rarely address the requirements deemed most critical by the heritage community (typically related to information management). Since the perceived usefulness of a system is directly related to its subsequent adoption [90], this should be considered a key deficiency of HBIM development to date. Future case studies should consider how they can better meet these requirements. One requirement (R2—“the HBIM system will collate, and supply information required for funding applications”) was not reported as achieved by any case study, so it could provide a novel field of study for future research.

Finally, the case studies were evaluated using the HBIM Maturity Model (Objective O3). Almost all (one hundred and twelve) of the case studies failed to achieve Level 1 (the lowest achievable level). However, eight case studies achieved Level 1 and two case studies achieved Level 3. The two case studies that achieved Level 3 [49,194] should be considered exemplars of HBIM practice to date as they most clearly address the needs of the heritage community.

The key reason case studies failed to achieve Level 1 is that they did not demonstrate the prerequisite requirements required for a sustainable, long-term information management system. However, this was most likely because many case studies were in the initial steps of HBIM development and the authors acknowledge that many Level 0 case studies stated planned future developments which would enable them to achieve higher levels in the Maturity Model.

Case studies evaluated as Level 1 almost always failed to achieve a higher level because they did not address the need to share information with external parties, a key feature of heritage management. This failure may be due to the nature of academic case studies, which often only involve a single team.

Whilst the evaluation of the academic HBIM case studies appears to present a poor argument supporting the adoption of HBIM by the heritage community, it is notable that two case studies were able to achieve Level 3 (the second highest level), and all but one HBIM system requirement was achieved by at least one HBIM case study. This suggests that HBIM systems are able to meet the needs of the heritage community; however, the academic community has a responsibility to better advertise these capabilities.

The research discussed herein also answered a question posed by the authors at the beginning of the research project: “to what extent can HBIM be aligned with the existing and future developments of ISO 19650?” [12]. Reviewing the contents of ISO 19650-1:2018 [1] with respect to the identified needs of the heritage community and seeing the high percentage of case studies that are aligned with the existing developments of ISO 19650, the authors would argue that there is no reason HBIM should not be aligned with the existing and future developments of ISO 19650. This is also reflected by the HBIM Maturity Model, which is heavily influenced by the concepts outlined in ISO 19650-1:2018 [1].

The first HBIM Maturity Model, introduced herein, has been shown to enable a more nuanced evaluation of how well an HBIM system meets the identified needs of the heritage community compared to simply assessing the number of system requirements achieved.

The HBIM Maturity Model, created by the authors, is now a publicly available tool to assist organisations with effectively defining HBIM systems for their own needs. It approaches the development of HBIM from a management perspective and is intended to guide organisations with developing the governance that is required to ensure the long-term viability of HBIM systems. For instance, to achieve the minimum maturity level, an organisation must define what information is required, who is responsible for procuring and maintaining each information type, and how the information will be stored. The HBIM model is intended to complement ISO 19650 whilst accounting for the unique requirements of the heritage context.

An HBIM system developed utilising the HBIM Maturity Model will be capable of acting as a decision-support system, enabling whole-life information management and engendering co-ordination between all stakeholders involved in heritage management.