National Annex to ISO 19650 consultation
Help formulate CIAT's response to this consultation.
The UK Annex for BS EN ISO 19650-2 has been released for public consultation. Find the document here.
(Please note that you will need to register/log in with BSI to read the document, and it is free to register.)
So that CIAT can formulate a response to this, please ensure any comments you have are forwarded to Graham Chalkey, Assistant Practice Director at [email protected] by Tuesday 7 July 2020.
In order for CIAT to represent its membership and their views, it is essential that we receive your comments and views to enable us to collate and effect change in our industry. To assist you with regards to this consultation, below is a table for you to use as a starting point for any comments you wish to make.
|
Clause
|
Comment
|
Change
|
Member comment
|
|
n/a
|
[Throughout] Standard codes, such as type codes and status codes, are currently too ambiguous as they only state what they are, not how they should be used.
These codes cannot be applied without ambiguity unless they are accompanied with an explanation.
|
Include a clause for each standard code stating its use/applicability.
For example:
S5 – Suitable for review and authorisation. This status code should be used for information containers being authorised by the lead appointed party prior to being assigned a PUBLISHED state (see ISO 19650-, 5.7.2). |
|
|
NA.2.2
|
It is good to see that the naming convention hasn't functionally changed.
|
n/a
|
|
|
NA.3.1
|
Having an overall recommended length is a positive inclusion. However, each field should not have its own recommended lengths as they are distinguished by a delimiter and controlled by the overall character limit.
|
Keep overall character limit, omit field recommended lengths.
|
|
|
NA.3.6
|
Type codes should be limited to those expected to be shared during a project as part of good practice document management procedures documented in other British, European and international standards.
Document types that cannot hold title blocks or headers should be omitted as well as those that aren't for consumption by the wider project team or unlikely to be revised. Invoices, for example, should not exist on a common data environment nor should they be referenced within the national annex.
While it is recognised that organisations may want to expand the codes and their use outside of a project or asset CDE, standard codes within the national annex should not support this and be limited to the core functionality.
|
Limit document types to:
Explanations for these types should be included from within BS ISO 29845.
|
|
|
NA.3.6
|
It should be made clear that these are top-level (parent) codes that further sub-codes (children) could exist.
For example, if a project wanted to use M3 for 3D models, it could do so if project documentation made it clear that M3 was a type of Model file.
|
Modify note to say that codes can be expanded or broken into sub-types.
|
|
|
NA.3.7
|
It is good to see the change from roles to disciplines and the omission of the projected title 'Architect' in favour of 'architecture'.
|
n/a
|
|