The proposed updates to ISO 19650 - 'UK National Annex'. What are they?

We have just been notified of a proposed update to the ISO19650-2 UK national annex and have been asked to contribute our thoughts. But what are the changes? Why have these changes been proposed and what is the reasoning behind them? How can you positively comment on a change without having any understanding of the reason behind it?

BSI has published a summary of the changes on their website under scope found HERE. Seven key changes have been identified. These changes came about from industry feedback and I thought it would be useful to give you some more information on the changes to help inform you when your reviewing the updates and leaving your comments as it will be the collective feedback that determines if and how the changes will be implemented as a lot can change from now to then.

Listed below are the 7 key changes being proposed. The text in italic is the text copied from the BSI website. I have added, "The Problem" to explain some of the drivers for the change and "The Rationale" behind the changed approach. I have also included my personal thoughts on impact by adding "Likely Disruption". I personally take no responsibility for many of the changes, but I was present during the discussions and wish to share what I took from them in a bid to be more transparent.

Main change 1: A new table has been created in NA.3.1 to summarise the field code lengths and to set an overall maximum string length for the information container ID. We have also included notes to explain what each field covers. The intention is to remove these notes in the final published version, but they could be retained if they prove helpful.

The Problem - There were several comments on the current string length of the container field ID, specifically in reference to how it's being misused by some. There have allegedly been instances where the field ID has had lengths for each field grossly extended to the point that field IDs have surpassed 50 characters and more.

The Rationale - It was suggested that this overextending of container field IDs was either because it was unclear in the original annex what the length of each field should be or the goals for the field ID were not taking into account the problems caused by making it too complex or long. So the table was suggested to make it clear, placing a maximum character limit in place.

Likely Disruption - Low in my opinion. My personal thoughts is this will have little disruption unless you're used to exceeding the 32 character limit.

Main change 2: The Volume field has been renamed System. Now that ISO 19650 talks about broader concepts than volumes, this field has been refined to support the federation strategy and the information container breakdown structure. This code is now used for a system-based sub-division of the project, with codes fixed on a project-by-project basis.

The Problem - Volumes have always been a difficult concept by some, mostly due to the terminology, whereby the physical and spatial entities of a built asset be formed into a strategy. This combined with the changing terminology and approaches of the ISO, it was deemed appropriate to review this.

The Rationale - The current annex already says "Volume/System", so the proposed change was to remove the volume element only. As part of the review, it was considered important by everyone however to not change the underlying concept of the field. This field has been used by many to identify the related system or package of systems the information container related to which aligned with the original "volume" concept. So to a degree, the word has changed but the idea has not. And because PAS1192-2 no longer exists, which defined the term "Volume", those entering our industry or the BIM/IM side of our profession would not understand the term without having to revert to superseded standards. So it made sense to remove a term that's no longer used in our 19650 standards.

Likely Disruption - Low in my opinion. My personal thoughts are that this will only disrupt you if you want it too. If this were to be implemented, I would not be changing my approach to this field ID as the original understanding of this field will still work in the new renaming of it. The only change maybe how you name this field in your plans/BEPs or internal training guides/plans.

Main change 3: Level/location field has been renamed Spatial. The new name is more generic, and hence easier to apply to infrastructure projects. Some more examples have been included in the notes for how project-specific codes can be created.

The Problem - Though "levels" usually play a part in any type of built asset, they are used more in buildings when trying to organise information containers by some kind of spatial grouping. There has been examples presented where individuals have misunderstood this and only tried to apply levels where none exist or don't help in the search and recall of information containers

The Rationale - The current annex labels the field "Levels/Location". Both are spatial descriptions so the rationale was to simply call it "Spatial".

Likely Disruption - Low in my opinion. Its an intended change in term only. If you disagree, I recommend you comment on the BSI site to highlight how yo think the change could be more significant. The main impact, in my opinion, is how you refer to this field in guidance/project plans etc.

Main change 4: The standard list of codes for the Type field has been overhauled to make the list more consistent in describing types of information container. We have removed codes that described specific examples of other codes - the existing list has “SA” as accommodation schedule, which is just one type of schedule “SH”. Examples of each Type have been included but are intended not to be published unless we receive comments indicating that these are helpful.

The Problem - The main problem reported by feedback is the inconsistency of some of the currently defined codes were unclear. For example, a schedule of accommodation could be an SA code but it could also be SH and that's because people are unsure whether to assign it by its presentation format (schedule) or by its contents (Schedule of accommodation), the latter often already residing in file descriptions. So there was the issue that the definition of TYPE was misunderstood. For example, SH-Schedule is the presentation format only, the contents could be anything whereas SA-Schedule of accommodation isn't the presentation format, it's describing the contents. So should TYPE be the "Presentation" definition of a container (SH, AF,RP,CA) or should it be a label to describe the contents (BQ, CP, HS, RD, SA)?

The Rationale - It was decided that TYPE should be the presentation format, not a label for the contents and so items like BQ, CP, HS, RD, SA were removed. There was also some consolidating too. MO was inserted to replace M2 or M3 as some argued that it was irrelevant for information container querying whether it was 2D or 3D as it was the contents people were often interested in, not the fact the Z axis was being visually portrayed or annotated.

Likely Disruption - Low in my opinion when considering there is a NOTE just under the table allowing project-specific codes still to be used. So if you're used to having dozens and dozens of codes, that vary between the presentation format and the contents, then you can continue to work in this way by inserting your project codes. The proposed changes try to reduce this by making it clear by selecting only one definition of the term TYPE and allowing you to find other ways to describe the contents through either descriptions, System code or classification perhaps?

Main change 5: The Role field has been renamed as Discipline, and the list of standard codes has been revised. This is so that Disciplines align with project activities rather than job titles and make them easier to apply across the whole project team. Some anomalies have been removed, such as the distinction for subcontractors or specialist designers – these will either be assigned to their discipline or a new code would need to be created.

The Problem - Like the Type field, there was a common confusion over whether the provided ROLE codes were clear enough. For example, a facade contractor can be both X- Subcontractor and Y-Specialist designer. Because this isn't clear, it was noted that it was being applied insistently on every project, with some contractors/Specialist designers choosing the Y, others choosing the X.

The Rationale - It was suggested that the most important aspect of this ROLE field was the understanding of the nature of the information. For example, you want to identify the drawings linked with facade. One method that was suggested was to either allow those trying to find information containers, filter by the SYSTEM field and then by "A-Architect" or if the facade was now being done by another discipline like a specialist designer/contractor, you would simply filter by the SYSTEM field and choose "O-Other" to represent someone other than the architect which can only be a subcontractor/specialist design in this case so is assigned O.

Likely Disruption - This could be a medium impact because you may be used to assigning subcontractor or specialist designer to your organisation and now there isn't a code for this so you may have to change your approach if this proposal becomes part of the new update. You can either try to simplify your approach by only focusing on the discipline rather than the organisation type (Subcontractor) or you can perhaps make use of the two character allowance for the role field and change to your heart's contempt. As always, I would urge you to provide examples for how you feel this cant work when commenting on the draft update or propose something better whilst still taking into consideration the problem.

Main change 6: Status codes for the common data environment have been revised. The list of Shared codes has been simplified, with S4 and S5 now aligning with the two-step review that is specified in ISO 19650-2 between Shared state and Published State. S4 is the review by the lead appointed party and S5 is review by the appointing party. Also, Published code CR was deemed to be duplicating A5 and/or A6, and has been removed.

The Problem - ISo 19650-2 introduces two very clear tasks that must be performed by the information authors, 1) They must seek authorisation from the Lead Appointed party, and 2) They must seek acceptance by the appointing party. So the suitability (Information is either suitable for authorisation or for acceptance) for each issue should have its own code.

Another problem that was identified as no one could answer how A6 differed from CR when referring to stage 6 definitions in the original PAS but also in other stage 6 definitions used in the NBS toolkit, RIBA and BS8536 as both seemed to denote a finalisation of issue.

The Rationale - To better align to the steps in the ISO, S4 and S5 were assigned the authorisation and acceptance tasks as the original "stage approval" was a redundant term used in the PAS. And as the PAS was now a withdrawn standard/specification, updating for ISO terms was proposed. This problem was explored further in the second edition - detailed CDE guidance that was published when trying to use the national annex codes.

Likely Disruption - This very much depends if you and your organisation followed the original national annex codes to the letter. I personally very rarely noticed the S4 S6 and S7 codes used correctly on the majority of the projects I have been associated with. Infact, what I noticed was that most still preferred the original BS1192:2007 codes (not the addendum 2 published in 2016). So I found many still used the original S4 definition "For Approval or construction approval" rather than the newer "Stage approval". What is clear is that there is still nothing to stop you applying additional suitability codes. So if an information author only wants to issue information for costing or building control purposes, they may apply a new code so long as it's recorded in the project`s information standards.

Main change 7: The use of classification has been clarified. Classification codes are used both to apply codes to the information container itself (as metadata specified in ISO 19650-2 clause 5.1.7 item c) and separately to apply codes to the objects contained in the information container. This second use is now spelt out in new clause NA.5.2.

The Problem - There was some comments that people were confused by the original national annex stating "Classification of information WITHIN information containers" because some considered this meant classification only applied to objects for example, not to the containers.

The Rationale - This needed clarifying. It is not assumed to have any impact apart from those who misunderstood this and believed no classification had to be applied to the information container, only the contents within.

Likely Disruption - I personally see no impact here.

So I hope you found this useful. I gave up a couple of hours of my Saturday to write this up (mainly because its raining) to help provide further insight into the changes. Most changes are down to a problem. The options are to ignore the problems, force-fit a solution on every project whilst fighting the bureaucracy because each person has their own understanding of a solution or try to resolve the problem at the source by trying your best not to make more...Hopefully!

Like always, with any of these standards that affect us on the front lines, I would ask everyone to contribute through the BSI commenting page. Highlight examples of how any changes cant work and even propose an alternative now you have some understanding of the problem.