this document is no longer current. please go to …...b2: document management - b.2.2 m b2:...

This document is no longer current. Please go to the following URL for more information:

http://www.nationalarchives.gov.uk/electronicrecords/reqs2002/rationale-erms.htm

B.2: DOCUMENT MANAGEMENT

B.2.1 M - B.2.21 HD

Version 2

April 2007

Description of Rationale Table Contents

REQUIREMENT SECTION HEADER - Sub-section details

Requirement Requirement number and M / HD / D status

Text * Original requirement text. This text is repeated from the 2002 Requirements for Electronic Records Management Systems.

Footnote

* Original footnote text. This text is repeated from the 2002 Requirements for Electronic Records Management Systems. Within the rationale, footnote numbering has been reset for each requirement. The entry "None" is used where footnote text is not present.

Rationale * New text. This text aims to provide fundamental reasoning and principles behind the requirement.

Example

* New text and / or diagrams. These entries aim to provide explanatory text and illustrative examples as appropriate for the requirement. The entry "N/A" is used where an example is not present.

Links

* New text. These entries provide details of related requirements. Hyperlinks are available where the linked requirements exist within the same document. The entry "None" is used where related links are not present.

Test Criteria

* New text. TNA previously operated a test scheme to evaluate ERM systems. These entries indicate in which test script(s) the requirement was tested.

Keywords * New text. These entries provide some key terms and phrases related to the requirement.

B2: DOCUMENT MANAGEMENT - B.2.1 M

B2: DOCUMENT MANAGEMENT

Requirement B.2.1 M

Text

The EDRMS must either • provide document management facilities as an integral

part of the system or must be capable of integration with one or both of:

• an electronic document management system capable of passing management control of documents within its own filestore(s) to an ERMS at time of declaration

• an electronic document management system capable of transferring declared documents as records to an ERMS directly from the EDM system.

Footnote None

Rationale

Acronyms • EDMS: electronic document management system • ERMS: electronic records management system • EDRMS: electronic document and records

management system Definitions ISO 15489-1 has the title:

"Information and documentation - Records management - Part 1: General"

Section 3 of this standard covers terms and definitions, including entries for:

• document "recorded information or object which can be treated as a unit"

• records "information created, received, and maintained as evidence and information by an organization or person, in pursuance of legal obligations or in the transaction of business"

Documents and records Documents are created and received as part of an organisation's everyday activities. These documents may exist in a variety of electronic and physical formats (e.g. word processor files, emails, databases, letters, maps, DVDs, etc.) Some documents will be of limited, short-term value, while others will contain evidence of business activities that must be retained in order to fulfil business needs and comply with legal requirements. Documents that fit into the latter category will

- 1 -


be declared as records at an appropriate point in time. Not all documents will become records, but those that do will change from being under an individual user's control to corporate control. While documents can be edited and deleted, records are held in a fixed state, with appropriate access and functional permissions applied. EDMS An electronic document management system (EDMS) can allow documents to be stored, with users generally able to add, edit (including the creation of different versions) and delete their documents. The functionality provided by an EDMS may vary - some systems may provide basic document management features while others may also offer more advanced functionality similar to that offered by records management applications. An EDMS is often used to manage the distribution and workflow of documents. ERMS An electronic records management system (ERMS) provides a controlled environment where records can be declared within a structured classification scheme. The ERMS prevents the modification of record content and applies strict controls on record metadata. The overall functionality of an ERMS may vary, however each system is expected to be capable of providing a core set of functions, managing records from the point of capture / declare through to disposal in accordance with business and legal requirements. EDRMS There are a variety of document and records management solutions available in the marketplace, including completely separate applications, integrated EDRMS products, enterprise content management (ECM) applications, etc. The potential benefits of establishing a connection between document and records management facilities include enhanced usability and the application of consistent management rules throughout. In terms of these requirements, the combination of document and records management is expected to be achieved either by:

• using an EDRMS - i.e. a complete, integrated system providing both document and records management facilities

OR, where separate EDMS and ERMS applications are deployed, the implementation is expected to provide one or both of the following capabilities:

• when a document held within the EDMS is declared as a record, its storage location does not change but the ERMS automatically takes over management control of

- 2 -


the record from the EDMS (including access and disposal settings, etc.)

• when a document held within the EDMS is declared as a record, the document (or copy thereof) is automatically transferred to the ERMS repository, where the ERMS has full records management control.

Integration of separate ERMS and EDMS applications may be implemented using an Application Program Interface (API), which is a set of routines and calling conventions that can allow a software application to access the operating system and other services.

Example

Examples of electronic document and records management solutions include: EDRMS

EDRMS

D

D D

R

R R

A single application is capable of providing both electronic document and records management functionality. Separate EDMS and ERMS used as part of a product suite

Product Suite

D

D D

EDMS

R

R R

ERMS

Separate applications can be integrated, with rules of precedence applied in order to provide the necessary electronic document and records management functionality.

Links B.2.2 M

Test Criteria TS22

Keywords document, EDMS, EDMS, EDRMS, record

- 3 -



Requirement B.2.2 M

Text Where an ERMS is integrated with an EDMS, it must in principle be capable of integration with new EDM systems and new versions of existing integrated EDMS.

Footnote None

Rationale

Documents and records Documents are created and received as part of an organisation's everyday activities. These documents may exist in a variety of electronic and physical formats (e.g. word processor files, emails, databases, letters, maps, DVDs, etc.) Some documents will be of limited, short-term value, while others will contain evidence of business activities that must be retained in order to fulfil business needs and comply with legal requirements. Documents that fit into the latter category will be declared as records at an appropriate point in time. Not all documents will become records, but those that do will change from being under an individual user's control to corporate control. While documents can be edited and deleted, records are held in a fixed state, with appropriate access and functional permissions applied. EDMS An electronic document management system (EDMS) can allow documents to be stored, with users generally able to add, edit (including the creation of different versions) and delete their documents. The functionality provided by an EDMS may vary - some systems may provide basic document management features while others may also offer more advanced functionality similar to that offered by records management applications. An EDMS is often used to manage the distribution and workflow of documents. ERMS An electronic records management system (ERMS) provides a controlled environment where records can be declared within a structured classification scheme. The ERMS prevents the modification of record content and applies strict controls on record metadata. The overall functionality of an ERMS may vary, however each system is expected to be capable of providing a core set of functions, managing records from the point of capture / declare through to disposal in accordance with business and legal requirements. EDRMS There are a variety of document and records management

- 1 -


solutions available in the marketplace, including completely separate applications, integrated EDRMS products, enterprise content management (ECM) applications, etc. Where document and records management is achieved by the integration of separate EDMS and ERMS applications, compatibility between applications is obviously a key factor. An organisation may wish to use applications that are part of a product suite provided by the same software house or may want to use two entirely separate and unrelated products. In principle, the ERMS must provide the capability of being integrated with any EDMS, thereby ensuring that the choice of applications is not prohibitively restrictive. Updates to the EDMS and / or ERMS software are expected to be supported in an appropriate manner, with no adverse effects on the EDMS / ERMS integration. Integration of separate ERMS and EDMS applications may be implemented using an Application Program Interface (API), which is a set of routines and calling conventions that can allow a software application to access the operating system and other services.

Example

D

D D

EDMS

R

R R

ERMS

Company AVersion 6.0

Company BVersion 2.7

Company A offers standard document management facilities in version 6.0 of its EDMS. Company B offers standard records management functionality in version 2.7 of its ERMS. In principle, the ERMS must be capable of integration with theEDMS to provide the desired document and records management environment.

D

D D

EDMS

R

R R

ERMS

Company AVersion 6.1


If Company A released an update for their EDMS product (e.g. version 6.1), the ERMS must be capable of offering at least the same level of integration as the preceding version.

- 2 -


D

D D

EDMS

R

R R

ERMS

Company CVersion 9.3


If Company B then decided they wanted to start using a different EDMS product offered by Company C, a similar level of integration would be expected.

Links A.2.3 M & B.2.1 M

Test Criteria TS22

Keywords EDMS, EDRMS, ERMS

- 3 -



Requirement B.2.3 M

Text The EDRMS must enable a newly created document to be captured and declared by the EDRMS in one operation.

Footnote None

Rationale

Documents and records Documents are created and received as part of an organisation's everyday activities. These documents may exist in a variety of electronic and physical formats (e.g. word processor files, emails, databases, letters, maps, DVDs, etc.) Some documents will be of limited, short-term value, while others will contain evidence of business activities that must be retained in order to fulfil business needs and comply with legal requirements. Documents that fit into the latter category will be declared as records at an appropriate point in time. Not all documents will become records, but those that do will change from being under an individual user's control to corporate control. While documents can be edited and deleted, records are held in a fixed state, with appropriate access and functional permissions applied. Capture and declare Capture is the point at which a copy of an electronic document that exists outside of the ERMS / EDRMS environment is added to the data repository, with appropriate system and user metadata closely bound to the document. Declaration is the point at which the document (i.e. record content) and specified metadata elements are frozen so that they cannot be edited by any user, thereby ensuring the integrity of the original data as a complete, reliable and authentic record. There will be instances where a user is aware that a new document warrants record status and will be declared as such when it is first added to the EDRMS. In order to facilitate this process, the EDRMS must be capable of capturing a newly created electronic document and declaring it as a record via a single function, as opposed to two entirely separate and distinct functions. Note: When a document is created, the author is the "Creator" and the "Creation Date" indicates the date on which the document was originally created (either external to the E(D)RMS or within the document management area of the system). By default, the "Creator" and "Date.Created" metadata values should reflect the original document properties, and if the document is declared, this information will be retained in the record metadata. However, there may be instances where document metadata elements must be

- 1 -


updated over time, e.g. a document may have been loosely drafted on behalf of someone else, and once captured into the document management area of an EDRMS, the metadata must be updated to more accurately reflect the document properties, etc. The E(D)RMS must therefore manage these metadata fields in a clear and unambiguous manner in order to avoid any confusion with other metadata fields such as "Date.Declared" or custom system-based metadata that is independently used to log the date on which the document was captured into the system.

Example

When a spreadsheet containing the final estimate covering the detailed costs of a proposed business activity is received, the user knows that they will want to save that document as a business record. In order to avoid wasting time and effort performing additional tasks and potentially having to re-enter the same information at different stages, the EDRMS must provide an option for the user to capture and declare the record as part of a single action or process.

Links A.2.13 M, B.2.4 M & B.2.5 M

Test Criteria TS22

Keywords capture, declaration, document, record

- 2 -



Requirement B.2.4 M

Text The EDRMS must enable a newly created document to be captured and not declared by the EDRMS.

Footnote None

Rationale

Documents and records Documents are created and received as part of an organisation's everyday activities. These documents may exist in a variety of electronic and physical formats (e.g. word processor files, emails, databases, letters, maps, DVDs, etc.) Some documents will be of limited, short-term value, while others will contain evidence of business activities that must be retained in order to fulfil business needs and comply with legal requirements. Documents that fit into the latter category will be declared as records at an appropriate point in time. Not all documents will become records, but those that do will change from being under an individual user's control to corporate control. While documents can be edited and deleted, records are held in a fixed state, with appropriate access and functional permissions applied. Capture and declare Capture is the point at which a copy of an electronic document that exists outside of the ERMS / EDRMS environment is added to the data repository, with appropriate system and user metadata closely bound to the document. Declaration is the point at which the document (i.e. record content) and specified metadata elements are frozen so that they cannot be edited by any user, thereby ensuring the integrity of the original data as a complete, reliable andauthentic record. There will be instances where a user is aware that a new document does not warrant record status in its current form and will simply be captured as a document when it is first added to the EDRMS. Therefore, the EDRMS must be capable of capturing a newly created electronic document, without having to declare it as an electronic record at that time. Note: When a document is created, the author is the "Creator" and the "Creation Date" indicates the date on which the document was originally created (either external to the E(D)RMS or within the document management area of the system). By default, the "Creator" and "Date.Created" metadata values should reflect the original document properties, and if the document is declared, this information will be retained in the record metadata. However, there may be instances where document metadata elements must be

- 1 -


updated over time, e.g. a document may have been loosely drafted on behalf of someone else, and once captured into the document management area of an EDRMS, the metadata must be updated to more accurately reflect the document properties, etc. The E(D)RMS must therefore manage these metadata fields in a clear and unambiguous manner in order to avoid any confusion with other metadata fields such as "Date.Declared" or custom system-based metadata that is independently used to log the date on which the document was captured into the system.

Example

When a bulk standard invitation is received for an external event, the user knows that they will not want to save that document as a business record. However, as they may want to retain the information for personal use or for a limited period of time, the EDRMS must provide an option for the user to simply capture the document without declaring it as a record at that time.

Links A.2.13 M, B.2.3 M & B.2.5 M

Test Criteria TS22

Keywords capture, declaration, document

- 2 -



Requirement B.2.5 M

Text The EDRMS must enable a document already existing in the document management environment or capability to be declared as a record in one operation.

Footnote None

Rationale

Documents and records Documents are created and received as part of an organisation's everyday activities. These documents may exist in a variety of electronic and physical formats (e.g. word processor files, emails, databases, letters, maps, DVDs, etc.) Some documents will be of limited, short-term value, while others will contain evidence of business activities that must beretained in order to fulfil business needs and comply with legal requirements. Documents that fit into the latter category will be declared as records at an appropriate point in time. Not all documents will become records, but those that do will change from being under an individual user's control to corporate control. While documents can be edited and deleted, records are held in a fixed state, with appropriate access and functional permissions applied. Capture and declare Capture is the point at which a copy of an electronic document that exists outside of the ERMS / EDRMS environment is added to the data repository, with appropriate system and user metadata closely bound to the document. Declaration is the point at which the document (i.e. record content) and specified metadata elements are frozen so that they cannot be edited by any user, thereby ensuring the integrity of the original data as a complete, reliable and authentic record. There will be instances where a user is aware that a new document does not warrant record status in its current form and will simply be captured as a document when it is first added to the EDRMS. Over time, or after further consideration, the user may decide that the stored document should be declared as a record within the fileplan hierarchy of the records management area. Therefore, the EDRMS must be capable of declaring an existing document as a record via a separate and distinct declaration action. Note: When a document is created, the author is the "Creator" and the "Creation Date" indicates the date on which the document was originally created (either external to the E(D)RMS or within the document management area of the system). By default, the "Creator" and "Date.Created" metadata values should reflect the original document

- 1 -


properties, and if the document is declared, this information will be retained in the record metadata. However, there may be instances where document metadata elements must be updated over time, e.g. a document may have been loosely drafted on behalf of someone else, and once captured into the document management area of an EDRMS, the metadata must be updated to more accurately reflect the document properties, etc. The E(D)RMS must therefore manage these metadata fields in a clear and unambiguous manner in order to avoid any confusion with other metadata fields such as "Date.Declared" or custom system-based metadata that is independently used to log the date on which the document was captured into the system.

Example

When a user creates a set of reports that may be used for a business presentation, they may not have decided which reports will actually be circulated as final business records. Once it has been decided that a report will be selected, the user can formally declare the document as a record within the business classification scheme.

Links A.2.13 M, B.2.3 M & B.2.4 M

Test Criteria TS22

Keywords capture, declaration, document, record

- 2 -



Requirement B.2.6 M

Text The EDRMS must support the creation of versions of electronic documents which are closely bound together, and must manage version control to support progressive drafting and ensure continual integrity of the document as a whole.

Footnote None

Rationale

Documents and records Documents are created and received as part of an organisation's everyday activities. These documents may exist in a variety of electronic and physical formats (e.g. word processor files, emails, databases, letters, maps, DVDs, etc.) Some documents will be of limited, short-term value, while others will contain evidence of business activities that must be retained in order to fulfil business needs and comply with legal requirements. Documents that fit into the latter category will be declared as records at an appropriate point in time. Not all documents will become records, but those that do will change from being under an individual user's control to corporate control. While documents can be edited and deleted, records are held in a fixed state, with appropriate access and functional permissions applied. Versions Another distinguishing characteristic between documents and records is that while the document management environment allows for the creation of multiple versions of an existing document, there will only ever be one version of a record. An EDRMS must be able to support and manage document version control, ensuring that the relationship between versions and overall data integrity is maintained at all times. Document versioning allows the creation of many different versions of a single document, and can be of particular use in the drafting process or for a piece of collaborative work where several team members contribute to the document over a period of time. Each document has a version history, providing information such as when the document was edited and by whom. The maximum number of document versions allowed (and the way in which they are identified) will depend on the EDRMS configuration properties, however, all existing versions must be closely bound together within the document object. When a document is to be updated, the user can edit the most recent version (as will normally be the case) or, should the need arise, they can choose to revert back to an older version of the document before applying the latest changes.

- 1 -


Furthermore, the EDRMS must be capable of declaring one or more specified versions of a document as a single record, where each selected version of the document remains closely bound within the lone declared record in the records management area. Note: While it is acknowledged that some products support "record versioning", this concept is beyond the scope of these requirements.

Example

EDRMS

D

D D

R

R R

Document:Version 1

D

When a user wants to work on a draft report, they may store the initial, work-in-progress document within the document management area of the EDRMS.

EDRMS

D

D D

R

R R

Check-outand edit

document

Check-innew versionof document

Document:Version 1Version 2Version 3Version 4

D

DDDD

Over a period of time, the user can then add detail to the report, with the EDRMS implementing version control rules in order to maintain the integrity of the data stored. On completion, the user can present the completed report to colleagues, and declare the final version of the document as a record within the business classification scheme.

Links B.2.7 M & B.2.8 M

Test Criteria TS22

Keywords document, version

- 2 -



Requirement B.2.7 M

Text

Where more than one version of the document has been created, the EDRMS product set must support the ability to declare:

• the most recent version • one specified version only • all existing versions, and hold all of these as a single

electronic record.

Footnote None

Rationale

Documents and records Documents are created and received as part of an organisation's everyday activities. These documents may exist in a variety of electronic and physical formats (e.g. word processor files, emails, databases, letters, maps, DVDs, etc.) Some documents will be of limited, short-term value, while others will contain evidence of business activities that must be retained in order to fulfil business needs and comply with legal requirements. Documents that fit into the latter category will be declared as records at an appropriate point in time. Not all documents will become records, but those that do will change from being under an individual user's control to corporate control. While documents can be edited and deleted, records are held in a fixed state, with appropriate access and functional permissions applied. Versions Another distinguishing characteristic between documents and records is that while the document management environment allows for the creation of multiple versions of an existing document, there will only ever be one version of a record. An EDRMS must be able to support and manage document version control, ensuring that the relationship between versions and overall data integrity is maintained at all times. Document versioning allows the creation of many different versions of a single document, and can be of particular use inthe drafting process or for a piece of collaborative work where several team members contribute to the document over a period of time. Each document has a version history, providing information such as when the document was edited and by whom. The maximum number of document versions allowed (and the way in which they are identified) will depend on the EDRMS configuration properties, however, all existing versions must be closely bound together within the document object.

- 1 -


Furthermore, the EDRMS must be capable of declaring one or more specified versions of a document as a single record, where each selected version of the document remains closely bound within the lone declared record in the records management area. In particular, the EDRMS must allow users to:

• declare all existing document versions as a single record

• identify, select and declare the most recent document version

• identify, select and declare any specific, individual document version from the history list

Note: While it is acknowledged that some products support "record versioning", this concept is beyond the scope of these requirements.

Example

When multiple versions of a document have been created and stored within the document management area of an EDRMS, users must be allowed to specify any version(s) they wish to declare as a record.

EDRMS

D

D D

R

R R

Document:Version 1Version 2Version 3

Select mostrecentversion

(Version 4)and declare.

Record A

Version 4

DDDD

R

The user can select the most recent version of the document and declare it as "Record A".

EDRMS

D

D D

R

R R

Document:Version 1Version 2

Version 4Version 3

Selectspecificversion

(Version 3)and declare.

Record B

DDDD

R

The user can isolate and select the third version of the document and declare it as "Record B".

- 2 -


EDRMS

D

D D

R

R R


Select allversions anddeclare as a

single record.Record C

RDDDD

The user can select all of the existing versions of the document and declare these collectively as "Record C".

Links B.2.6 M & B.2.8 M

Test Criteria TS22

Keywords declaration, document, record, version

- 3 -



Requirement B.2.8 M

Text The EDRMS product set must be capable of allowing versions of a document to be created, as part of drafting process, without automatically creating a new record on each occasion.

Footnote None

Rationale

Documents and records Documents are created and received as part of an organisation's everyday activities. These documents may exist in a variety of electronic and physical formats (e.g. word processor files, emails, databases, letters, maps, DVDs, etc.) Some documents will be of limited, short-term value, while others will contain evidence of business activities that must be retained in order to fulfil business needs and comply with legalrequirements. Documents that fit into the latter category will be declared as records at an appropriate point in time. Not all documents will become records, but those that do will change from being under an individual user's control to corporate control. While documents can be edited and deleted, records are held in a fixed state, with appropriate access and functional permissions applied. Versions Another distinguishing characteristic between documents and records is that while the document management environment allows for the creation of multiple versions of an existing document, there will only ever be one version of a record. An EDRMS must be able to support and manage document version control, ensuring that the relationship between versions and overall data integrity is maintained at all times. Document versioning allows the creation of many different versions of a single document, and can be of particular use in the drafting process or for a piece of collaborative work where several team members contribute to the document over a period of time. Furthermore, the EDRMS must be capable of declaring one or more specified versions of a document as a single record, where each selected version of the document remains closely bound within the lone declared record in the records management area. Note: While it is acknowledged that some products support "record versioning", this concept is beyond the scope of these requirements. When a new version of a document is created, it is quite possible that it should be kept as an undeclared document rather than a record. The EDRMS must therefore ensure that

- 1 -


whenever new document versions are drafted, they are notautomatically declared as records within the system.

Example

EDRMS

D

D D

R

R R

Document:Version 1

D

When a user wants to work on a draft spreadsheet with basic information regarding a casual social event for employees, they might store the initial, incomplete document within the document management area of the EDRMS.

EDRMS

D

D D

R

R R

Check-outand edit

document



D

DDDD

Over a period of time, the user can then add detail to the spreadsheet, with the EDRMS implementing version control rules in order to maintain the integrity of the data stored. On completion, the user can circulate the completed spreadsheet to colleagues. In this instance the document content does not warrant record status and the EDRMS must ensure that none of the document versions are automatically declared as such.

Links B.2.6 M, B.2.7 M & B.2.16 M

Test Criteria TS22

Keywords document, version

- 2 -



Requirement B.2.9 M

Text

The EDRMS product set must support the ability to define different templates for electronic documents, and the allocation of different metadata elements sets for each template. Examples of distinct types are:

• pre-defined forms • report layouts • standard letter formats.

Footnote None

Rationale

A template provides a pattern or model that acts as a guide to help a user complete a piece of work in an expected manner. In the electronic environment templates are regularly created in a number of software applications to enhance usability and maintain consistency. Organisations can use templates to manage and standardise the appearance and structure of standard forms, reports, letters, emails, etc., with users entering appropriate text as required. In addition to providing document content models, the EDRMS must be able to support the allocation of pre-defined sets of associated metadata fields to different templates. This approach can be particularly beneficial because the information provided in the document can be used to automatically populate specified record metadata fields should the document be declared as a record at a later stage. The ability to manage metadata in this manner can enhance usability and increase the quality of the data (e.g. the likelihood of spelling errors or other manual mistakes will be reduced). While the way in which templates are presented and managed may vary, it is expected that the EDRMS will provide an appropriate level of document management functionality that will allow users to create new documents (adding and editing content as required), with metadata values populated manually and / or automatically based on system functionality and template rules. It should be noted that once a document has been created using a template, the controls applied by the template become fixed within the document - i.e. any changes to a template definition will not affect previously saved documents.

Example The appearance of electronic document templates may vary depending on the EDRMS.

- 1 -


[Sender Name][Sender Position]

Company ABCHigh StreetTownsville

[dd] / [mm] / [yyyy]

[Recipient Name][Recipient Position][Recipient Address 1][Recipient Address 2][Recipient Address 3]

Re: [Letter Reference Details]

Dear [Recipient Name]

[Body of Letter]

Best Regards[Sender Name][Sender Position]

A standard letter template may present a typical A4 page, with a pre-defined layout and metadata fields for names, addresses, dates, etc. In this instance, user-editable metadata fields are represented by text enclosed within square brackets, displayed in dark grey italics. Template fields such as the "Letter Reference Details" can be configured so that when the user declares the completeddocument as a record, the given value is automatically assigned to an appropriate record metadata field, such as "Title" or "Subject".

- 2 -


Dear [Patient details added automatically from metadata]

Our records show that it has been [number] months sinceyour operation / procedure at County Hospital.

We therefore recommend that you contact your GP for a[status] check-up.

Best Regards

County Hospital

County Hospital - Private Data

SurnameFirst NameMiddle Name(s)

TelephoneSurgerySurgery ID

County HospitalRiverbankTownsville

Patient ID Doctor

A medical document template may be presented via a split screen display, with metadata fields displayed in the top half and a document content area in the bottom half. In this instance, private metadata fields are available at the top of the screen, and user-editable metadata fields within the document content template are represented by text enclosed within square brackets, displayed in dark grey italics.

Links B.2.10 M & B.2.11 M

Test Criteria TS22

Keywords document, metadata, template

- 3 -



Requirement B.2.10 M

Text

The EDRMS product set must be capable of configuring the mapping of electronic document metadata to electronic record metadata, to ensure that an electronic record always possesses correct and authentic metadata as defined by the accompanying records management metadata standard and in accordance with ERMS functional requirements.

Footnote None

Rationale

Metadata Metadata is essentially "data about data" and is the term used to describe the information provided by users and system-controlled functions that is closely bound to document or record content. Document metadata In terms of these requirements, there is no mandated metadata standard for undeclared documents. The metadata maintained for documents is likely to vary depending on the EDRMS environment and how the documents are managed. Document metadata might range from a small set of vital fields to a larger set encompassing many records management fields and additional custom fields. However, every document within the EDRMS will have some associated metadata (e.g. "Title" and "Creator" details), with appropriate rules applied to govern the content and use of these fields. Records metadata The records management metadata standard indicates which metadata fields must be included for records. The Metadata Standard document used with the 2002 Functional Requirements is available on the "2002 revised requirements" page of The National Archives website. Functional, policy and procedural rules are applied to govern the content and use of metadata fields. Record_types Every record is associated with a particular record_type. The record_type essentially specifies the metadata attributes and behaviour connected to record objects that are created using the particular record_type. Some EDRMS products may allow the same principle to be applied for documents, effectively introducing the concept of "document_types". Alternatively, document management templates may be used to similar effect.

- 1 -

http://www.nationalarchives.gov.uk/electronicrecords/reqs2002/


Mapping metadata When a document is declared as a record, it is likely that users will want to retain some or all of the metadata values that were populated for the document. The process of mapping corresponding metadata fields can ensure that important information is not lost and that users do not always have to re-enter data values as the object status changes. The EDRMS must therefore be capable of mapping specified document metadata to appropriate record metadata, with the ability to automatically process the data - allowing appropriate manual intervention and performing automated validation checks to ensure the mapped metadata is correct and authentic. The EDRMS Administrator must ensure that all document metadata is properly mapped, particularly as the metadata held for documents may differ from the metadata set used for records. Care should be taken when configuring the mappings so that the potential for conflicts between metadata from the document and records management areas is minimised. There may be some document metadata elements that contain vital information that must be carried over to declared records but are not included in the records management metadata standard (or other metadata sets used by the organisation). Therefore the EDRMS must allow an Administrator to create and manage additional user-defined metadata fields for records. It is recommended that the EDRMS be able to create a minimum of 10 user-defined metadata fields. Note: While it is not mandatory for the EDRMS to identify mapped metadata fields using the same label name for both documents and records, this approach is strongly recommended for usability and data management purposes. Authenticity ISO 15489-1 has the title:

"Information and documentation - Records management - Part 1: General "

Section 7.2.2 of this standard concerns record authenticity and states:

"An Authentic record is one that can be proven a) to be what it purports to be, b) to have been created or sent by the person

purported to have created or sent it, and c) to have been created or sent at the time

purported" Essentially, if record metadata (and / or content) cannot be

- 2 -


proven to be what it professes to be, doubt will be cast over the integrity of the record and it will be compromised, effectively rendering it worthless in business and legal terms. It is therefore vital that an electronic record always possesses correct and authentic metadata, regardless of whether the metadata was mapped from the source document or applied directly to the record. Process considerations The way in which metadata mappings are managed may vary depending on the EDRMS and it is recommended that careful consideration be given as to how this is achieved - particularly in terms of usability and data integrity. Where documents are first captured with one set of metadata fields and later declared as records using a potentially different set of metadata fields, it is important that the user is able to view (and if necessary edit) the metadata associated with the record. This is particularly important where the document and record metadata sets differ significantly. Where the EDRMS supports the ability to first capture a document with one set of metadata fields and later declare it as a record with a different set of metadata fields, consideration should be given as to how the declaration process is managed. For example, if the EDRMS is capable of offering multiple "document_type" and record_type definitions, it would be advantageous to also support a mechanism to manage these definitions in such a way that the EDRMS automatically presents users with the most appropriate record_type selection during the declaration process. This approach could potentially result in less confusion and potential problems than an EDRMS that allows users to pick and choose record_types without any guidance.

Example N/A

Links A.2.26 M, A.2.43 M, B.2.9 M, B.2.11 M, B.2.12 M, B.2.13 M, B.2.14 M & B.2.15 M

Test Criteria TS22

Keywords document, metadata mapping, record

- 3 -




Text The EDRMS product set must allow metadata to be acquired from the user during the process of declaration.

Footnote None

Rationale

Metadata is essentially "data about data" and is the term used to describe the information provided by users and system-controlled functions that is closely bound to document or record content. When documents are captured and records declared, it is important to gather sufficient information to establish context, enhance retrieval, and store relevant data regarding the document or record. The EDRMS will gather some metadata automatically (e.g. from document properties, system functions and metadata mappings, etc.) but in order to provide complete and accurate information, authorised users must also be able to manually populate / edit certain metadata fields as required during the record declaration process. The extent to which users can edit record metadata will depend on role functionality, however any user authorised to declare records should be able to edit and / or add standard metadata elements (e.g. fileplan location, "Title", "Description", etc.) during the declaration process.

Example

A spreadsheet document entitled "draft report numbers for schools by AW" might have been stored in the document management area of the EDRMS. If this document was later declared as a record, the user could manually override the mapped metadata value and enter a more appropriate title during the declaration process, e.g. "Financial Report for Schools Project 2005".

Links A.2.34 M, B.2.9 M & B.2.10 M

Test Criteria TS22

Keywords declaration, metadata

- 1 -




Text

When declaring a record, the EDRMS product set must give precedence to the process of capturing metadata in accordance with ERMS functional requirements above metadata from the document management environment or capability, where any potential conflict arises.

Footnote None

Rationale

Metadata is essentially "data about data" and is the term used to describe the information provided by users and system-controlled functions that is closely bound to the document or record content. When documents are captured and records declared, it is important to gather sufficient information to establish context, enhance retrieval, and store relevant data regarding the document or record. The EDRMS will gather some metadata automatically (e.g. from document properties, system functions and metadata mappings, etc.) but in order to provide complete and accurate information, authorised users must also be able to manually populate / edit certain metadata fields as required during the record declaration process. The range of metadata fields, their allowed values and the rules applied for document management may vary from those expected in the records management area of an EDRMS. While any such differences may not be problematic in separate EDMS and ERMS environments (where the metadata may be managed independently using separate functions, etc.), significant issues may be encountered - and must be addressed - in an EDRMS product (where the same functionality may be applied to metadata from both environments, etc.). Document and record metadata should be properly governed by the EDRMS, with data integrity maintained at all times. When a record is being declared in the EDRMS, precedence must always be given to the behaviour and functionality expected in the records management environment as opposed to the document management area. Appropriate management controls must be in place to ensure that any conflicts between document and records management settings or processes are properly handled, including clear user alerts and a mechanism for resolving conflicts. The Metadata Standard document used with the 2002 Functional Requirements is available on the "2002 revised requirements" page of The National Archives website.

- 1 -




Example

Consider an EDMS that supports retention and disposal functionality. There may be a document management rule that specifies that all documents should be kept for a minimum of 5 years, after which time the document should be reviewed and appropriate action taken. By default the EDRMS product set maps the document management retention and disposal metadata to corresponding fields in the records management area. A document is then captured, and 3 months later it is declared as a record of a specific, non-default record_type (e.g. a record_type relating to data protection legislation), where a disposal schedule for destruction after 1 year has been allocated. In this instance, while the mapping may not be entirely appropriate, the resulting difference in disposal settings is not necessarily a mapping error and must be properly managed as a metadata conflict between the two environments. The EDRMS must therefore ensure that declared records are governed in such a way that records management metadata rules take precedence over those of the document management environment. Note: If a copy of the document remains in the document management area once the record has been declared, the document management disposal settings will still be valid as the document and record are two entirely separate objects.

Links A.2.31 M, B.2.10 M, B.2.13 M, B.2.14 M & B.2.15 M

Test Criteria TS22

Keywords document, metadata, record

- 2 -




Text

The EDRMS product set must ensure that any metadata captured in the document management environment or capability, that will be carried over into records management metadata, is managed in accordance with ERMS functional requirements to ensure authenticity.

Footnote None

Rationale

Document metadata In terms of these requirements, there is no mandated metadata standard for undeclared documents. The metadata maintained for documents is likely to vary depending on the EDRMS environment and how the documents are managed. Document metadata might range from a small set of vital fields to a larger set encompassing many records management fields and additional custom fields. However, every document within the EDRMS will have some associated metadata (e.g. "Title" and "Creator" details), with appropriate rules applied to govern the content and use of these fields. Note: When document metadata has been configured with the aim of being carried over into records management metadata, it is recommended that appropriate validation and functional controls be applied as early as possible - i.e. while strict checks will later be applied in the records management area, the application of similar checks on document metadata can help ensure the correct metadata is provided and also minimise problems at the point of declaration. Records metadata The records management metadata standard indicates which metadata fields must be included for records. The Metadata Standard document used with the 2002 Functional Requirements is available on the "2002 revised requirements" page of The National Archives website. Functional, policy and procedural rules are applied to govern the content and use of metadata fields. Mapping metadata When a document is declared as a record, it is likely that users will want to retain some or all of the metadata values that were populated for the document. The process of mapping corresponding metadata fields can ensure that important information is not lost and that users do not always have to re-enter data values as the object status changes. The EDRMS must therefore be capable of mapping specified document metadata to appropriate record metadata, with the

- 1 -



ability to automatically process the data - allowing appropriate manual intervention and performing automated validation checks to ensure the mapped metadata is correct and authentic. The EDRMS Administrator must ensure that all document metadata is properly mapped, particularly as the metadata held for documents may differ from the metadata set used for records. Care should be taken when configuring the mappings so that the potential for conflicts between metadata from the document and records management areas is minimised. In order to facilitate metadata mapping and ensure the authenticity of records, the EDRMS must be able to manage any metadata captured in the document management environment that will be carried over into records management metadata set, in accordance with ERMS functional requirements. Note: While it is not mandatory for the EDRMS to identify mapped metadata fields using the same label name for both documents and records, this approach is strongly recommended for usability and data management purposes. Authenticity ISO 15489-1 has the title:

"Information and documentation - Records management - Part 1: General "

Section 7.2.2 of this standard concerns record authenticity and states:

"An Authentic record is one that can be proven a) to be what it purports to be, b) to have been created or sent by the person purported

to have created or sent it, and c) to have been created or sent at the time purported"

Essentially, if record metadata (and / or content) cannot be proven to be what it professes to be, doubt will be cast over the integrity of the record and it will be compromised, effectively rendering it worthless in business and legal terms. It is therefore vital that an electronic record always possesses correct and authentic metadata, regardless of whether the metadata was mapped from the source document or applied directly to the record.

Example N/A

Links B.2.10 M, B.2.12 M, B.2.14 M & B.2.15 M

Test Criteria TS22


- 2 -




Text

When declaring a record, the EDRMS product set must give precedence to the access controls for the record in accordance with ERMS functional requirements above access controls applying in the document management environment or capability, where any potential conflict arises.

Footnote None

Rationale

Metadata Metadata is essentially "data about data" and is the term used to describe the information provided by users and system-controlled functions that is closely bound to the document or record content. The range of metadata fields, their allowed values and the rules applied for document management may vary from those expected in the records management area of an EDRMS. While any such differences may not be problematic in separate EDMS and ERMS environments (where the metadata may be managed independently using separate functions, etc.), significant issues may be encountered - and must be addressed - in an EDRMS product (where the same functionality may be applied to metadata from both environments, etc.). Document and record metadata should be properly governed by the EDRMS, with data integrity maintained at all times. When a record is being declared in the EDRMS, precedence must always be given to the behaviour and functionality expected in the records management environment as opposed to the document management area. Appropriate management controls must be in place to ensure that any conflicts between document and records management settings or processes are properly handled, including clear user alerts and a mechanism for resolving conflicts. The Metadata Standard document used with the 2002 Functional Requirements is available on the "2002 revised requirements" page of The National Archives website. Access controls Access control measures are required to ensure that only authorised users can gain access to, and perform certain actions in specified areas of the ERMS as part of a controlled and audited environment. For various reasons, the access controls applied within the document management environment may differ from those that may exist within a records management area. However, when a record is declared, the EDRMS must ensure that all

- 1 -




access control metadata is managed so that precedence is given to ERMS functional requirements over any document management rules. Section "A.5: Access Control" of the Functional Requirements provides specific detail for records management access control. The complete 2002 Functional Requirements document is available on the "2002 revised requirements" page of The National Archives website.

Example

A document is captured into the document management area of an EDRMS, with access control metadata configured to grant access to all users from a large department of employees, which is made up of several separate teams. Any user given access to the document can perform a number of actions, including view, share, and delete. When the document is declared as a record, different rules are applied. The record is assigned to an area of the fileplan related to a specific function performed by only one team from the department, with access controls set accordingly. The records management access control metadata determines which user(s) can view and edit access metadata for the record (up to and including the level that they themselves possess) but only a high-level ERMS administrator would be able to perform a delete action (as part of an audited process). Essentially, in addition to difference in metadata values, access control metadata may also be linked to functionality and role permissions with the ERMS. The EDRMS must therefore ensure that declared records are governed in such a way that records management rules take precedence over those of the document management environment.

Links B.2.10 M, B.2.12 M, B.2.13 M & B.2.15 M

Test Criteria TS22

Keywords access controls, document, metadata, record

- 2 -





Text

The EDRMS product set must not allow a concept of ownership which, within the document management environment or capability gives rights that must not be allowed within the records management environment or capability, to apply to a declared record.1

Footnote 1For example, rights of edit on document content, rights of edit on certain metadata elements, rights of deletion.

Rationale

Metadata Metadata is essentially "data about data" and is the term used to describe the information provided by users and system-controlled functions that is closely bound to the document or record content. The range of metadata fields, their allowed values and the rules applied for document management may vary from those expected in the records management area of an EDRMS. While any such differences may not be problematic in separate EDMS and ERMS environments (where the metadata may be managed independently using separate functions, etc.), significant issues may be encountered - and must be addressed - in an EDRMS product (where the same functionality may be applied to metadata from both environments, etc.). Document and record metadata should be properly governed by the EDRMS, with data integrity maintained at all times. When a record is being declared in the EDRMS, precedence must always be given to the behaviour and functionality expected in the records management environment as opposed to the document management area. Appropriate management controls must be in place to ensure that any conflicts between document and records management settings or processes are properly handled, including clear user alerts and a mechanism for resolving conflicts. Ownership When a document is first created, the author (i.e. the creator) is the owner of that document. When documents are created using software applications, appropriate details will often be automatically entered into the "Author" properties associated with the document. It should be noted that on occasion, a document might be drafted on behalf of someone else, in which case, ownership belongs to the latter party and the "Author" properties may be updated as necessary. When a user creates or captures a document into the document management area, they become the owner of the document within the EDRMS. The owner of a document may

- 1 -


not necessarily the creator of the original document. For example, if a document was initially created outside of the EDRMS environment by User A and later captured into the document management area by User B, ownership is given to User B. Furthermore, as User B is likely to be responsible for the document content up to the point of declaration as a record, the document metadata may also be updated so that User B is identified as the document creator. Owners will typically have full control over their own documents within the document management area, with the ability to edit and delete metadata and content as desired. The concept of document ownership is similar to that of custodianship in the records management environment. Where it is applied, custodianship can be held by an individual or a group of people, and identifies who has responsibility for particular folders or records. As a custodian, users can make decisions regarding who can access a folder or record in their care. While there are similarities between document ownership and record custodianship, the level of permissible functionality associated with these roles differs between the document and records management environments within the EDRMS. When a document is declared as a record, strict records management rules prevent the modification of record content (regardless of the user) and apply strict controls on record metadata. Where the document owner is a typical end user, they will only have basic function and access rights within the records management area of the EDRMS. Furthermore, unless the ownership metadata is mapped across from the document at the point of declaration, the document owner details may not even be included with the record for information purposes. The EDRMS must ensure that declared records are governed in such a way that records management rules will always take precedence over those of the document management environment.

Example N/A

Links A.5.41 M, B.2.10 M, B.2.12 M, B.2.13 M & B.2.14 M

Test Criteria TS22


- 2 -




Text The EDRMS product set must not allow a declared record to be checked out, where this implies any capability to amend the record content in any way.

Footnote None

Rationale

Documents An EDRMS must be able to support and manage document version control, ensuring that the relationship between versions and overall data integrity is maintained at all times. Document versioning allows the creation of many different versions of a single document, and can be of particular use inthe drafting process or for a piece of collaborative work where several team members contribute to the document over a period of time. Document management features allow authorised users to check documents in and out of the data store. The first version of a document is created when it is captured into the EDRMS. A user can check out a copy of the document to their local environment in order to apply any necessary changes, checking in the updated document when complete. It is only ever possible for one user to have a document checked out at any given time. When a document has been checked out, other users will typically have read-only access to the previous version for reference or review purposes. Once the document has been checked in, it becomes available for all authorised users to select and edit further as required. It is also worth noting that information such as when documents were checked in / out and by whom is routinely logged. When a document is to be updated, the user can edit the most recent version (as will normally be the case) or, should the need arise, they can choose to revert back to an older version of the document before applying the latest changes. Records The EDRMS must be capable of declaring one or more specified versions of a document as a single record, where each selected version of the document remains closely bound within the lone declared record in the records management area. Different management rules apply to documents and records. In particular, it must not be possible to edit record content in any way at any time, thereby ensuring the integrity of the original data as a complete, reliable and authentic record. The EDRMS must therefore never allow records to be checked in / out and edited in the same manner as undeclared documents.

- 1 -


Note: While it is acknowledged that some products support "record versioning", this concept is beyond the scope of these requirements.

Example

EDRMS

D

D D

R

R R

Check-outand edit

document



D

DDDD

When one or more users work on a draft document, the initial, incomplete document can be stored within the document management area of the EDRMS. Over a period of time, the user(s) can update the document as required, with the EDRMS implementing version control rules in order to maintain the integrity of the data stored.

EDRMS

D

D D

R

R R

RRecord content fixed.

No check in / outfunctionality for records.

X X

When the document is complete, the final version can be declared as a record. Unlike documents, record content cannot be edited.

Links B.2.8 M & B.3.20 HD

Test Criteria TS22

Keywords check in, check out, document, record, version

- 2 -

B2: DOCUMENT MANAGEMENT - B.2.17 HD


Requirement B.2.17 HD

Text The EDRMS product set should be capable of managing documents and records within the same class and folder structure.1

Footnote 1That is, documents that have been declared as records, and documents that have not been declared as records within the same folder.

Rationale

Documents and records Documents are created and received as part of an organisation's everyday activities. These documents may exist in a variety of electronic and physical formats (e.g. word processor files, emails, databases, letters, maps, DVDs, etc.) Some documents will be of limited, short-term value, while others will contain evidence of business activities that must be retained in order to fulfil business needs and comply with legal requirements. Documents that fit into the latter category will be declared as records at an appropriate point in time. Not all documents will become records, but those that do will change from being under an individual user's control to corporate control. While documents can be edited and deleted, records are held in a fixed state, with appropriate access and functional permissions applied. EDMS An electronic document management system (EDMS) can allow documents to be stored, with users generally able to add, edit (including the creation of different versions) and delete their documents. The functionality provided by an EDMS may vary - some systems may provide basic document management features while others may also offer more advanced functionality similar to that offered by records management applications. An EDMS is often used to manage the distribution and workflow of documents. ERMS An electronic records management system (ERMS) provides a controlled environment where records can be declared within a structured classification scheme. The ERMS prevents the modification of record content and applies strict controls on record metadata. The overall functionality of an ERMS may vary, however each system is expected to be capable ofproviding a core set of functions, managing records from the point of capture / declare through to disposal in accordance with business and legal requirements.

- 1 -


EDRMS There are a variety of document and records management solutions available in the marketplace, including completely separate applications, integrated EDRMS products, enterprise content management (ECM) applications, etc. The potential benefits of establishing a connection between document and records management facilities include enhanced usability and the application of consistent management rules throughout. If an organisation regularly handles both documents and records, it may be particularly desirable for the EDRMS to be able to manage documents and records within the same fileplan hierarchy. The ability to manage and present the different object types within the same class and folder structure can provide a consistent, user-friendly environment that helps to ensure that all users become familiar with the business classification scheme, where related objects are visible and can be readily managed as a whole. Where this arrangement is possible, documents and records must be assigned to at least one folder in the EDRMS classification scheme - i.e. undeclared documents typically held at the same hierarchical level as declared records. Note: The ability to manage documents and records within the same class and folder structure is more likely to be achieved by (though not limited to) a fully integrated EDRMS rather than by the combination of separate EDRM and ERMS applications.

Example

C Class 1

F Folder 1

P Part 1

D Document 1

R Record 1 Rather than managing documents and records separately and in completely separate areas, the EDRMS should be capable of allowing documents and records to be held and managed within the same fileplan.

Links B.2.18 M, B.2.19 M & B.2.20 M

Test Criteria TS22

Keywords classification scheme, document, record

- 2 -




Text

Where the EDRMS product set is capable of managing documents and records within the same class and folder structure, it must make a clear and immediately visible distinction between documents declared as records and those that are not.

Footnote None

Rationale

Documents and records Documents are created and received as part of an organisation's everyday activities. These documents may exist in a variety of electronic and physical formats (e.g. word processor files, emails, databases, letters, maps, DVDs, etc.) Some documents will be of limited, short-term value, while others will contain evidence of business activities that must be retained in order to fulfil business needs and comply with legal requirements. Documents that fit into the latter category will be declared as records at an appropriate point in time. Not all documents will become records, but those that do will change from being under an individual user's control to corporate control. While documents can be edited and deleted, records are held in a fixed state, with appropriate access and functional permissions applied. EDRMS interface It is important that the EDRMS interface presents each fileplan object in a clear and distinct manner, allowing users to quickly determine the aggregation level and type of each object being viewed. While different metadata and functionality associated with different fileplan objects can help users determine the nature of individual objects, the EDRMS should provide consistently clear formatting so that users can readily identify objects displayed via the EDRMS interface. Visible distinctions (e.g. the use of different display icons for different object types) are particularly important where the EDRMS is capable of managing documents and records within the same class and folder structure. As undeclared documents will typically reside at the same hierarchical level as declared records, if they were not displayed in a distinct manner, this could have a negative impact on users as they might be confused and waste time attempting to figure out which objects are which.

- 1 -


Example

Region A

Finance

Part1

-

-

-

Root Class

Planning

- Costs

-

Region B

Region C++

root class

class

folder

part

2004 Exhibition Cost Plan

2004 Exhibition Basic Expenses - Draft

record

document

Navigating through the fileplan may be achieved in various ways, for example a fileplan "tree" structure may allow the user to expand / collapse branches of the fileplan in order to locate a particular record; this approach is often favoured because the full hierarchy is always available for display but other approaches are also available. When browsing the fileplan in this manner, it is important that users are able to quickly distinguish between different kinds of object. In particular users must be able to readily determine which objects are documents and which are records.

Links A.3.3 M, B.2.17 HD, B.2.19 M & B.2.20 M

Test Criteria TS22

Keywords classification scheme, document, record

- 2 -




Text

Where the EDRMS product set is capable of managing documents and records within the same class and folder structure, it must provide options for:

• automatically declaring all undeclared documents in a specified folder or folders as records

• automatically deleting all undeclared documents in a specified folder or folders

• automatically deleting all undeclared documents in a specified folder or folders that are older than a specified period of time.

Footnote None

Rationale

Documents and records Documents are created and received as part of an organisation's everyday activities. These documents may exist in a variety of electronic and physical formats (e.g. word processor files, emails, databases, letters, maps, DVDs, etc.) Some documents will be of limited, short-term value, while others will contain evidence of business activities that must be retained in order to fulfil business needs and comply with legal requirements. Documents that fit into the latter category will be declared as records at an appropriate point in time. Not all documents will become records, but those that do will change from being under an individual user's control to corporate control. While documents can be edited and deleted, records are held in a fixed state, with appropriate access and functional permissions applied. EDRMS options Where the EDRMS is capable of managing documents and records within the same class and folder structure, it is important that appropriate functionality is available to govern the undeclared documents. In particular, the EDRMS must be able to provide an option for:

• automatically declaring all undeclared documents in a specified folder or folders as records

Where the EDRMS supports the ability to delete records, parts or folders on an ad hoc basis (outside of the disposal process), it must ensure that only the highest level EDRMS Administrator can perform the deletion. Where such functionality is available, the EDRMS must provide options for:

• automatically deleting all undeclared documents in a specified folder or folders

- 1 -


• automatically deleting all undeclared documents in a specified folder or folders that are older than a specified period of time.

While it is not explicitly stated, for obvious usability and ease of management reasons, it is preferred that the declaration and deletion actions specified in these options be provided by automatic system functions, as opposed to the user having to manually perform separate actions for each undeclared document.

Example N/A

Links A.4.65 M, B.2.17 HD, B.2.18 M & B.2.20 M

Test Criteria TS22

Keywords classification scheme, declaration, delete, document, record

- 2 -




Text

Where the EDRMS product set is capable of managing documents and records within the same class and folder structure, it must:

• provide a notification, within the disposal management mechanism, where undeclared documents exist within a folder to be exported, and enable them to be declared as records

• export only the records within that folder • in a transfer process, automatically destroy any

remaining documents when the records are destroyed following confirmation of successful export.

Footnote None

Rationale

Documents and records Documents are created and received as part of an organisation's everyday activities. These documents may exist in a variety of electronic and physical formats (e.g. word processor files, emails, databases, letters, maps, DVDs, etc.) Some documents will be of limited, short-term value, while others will contain evidence of business activities that must beretained in order to fulfil business needs and comply with legal requirements. Documents that fit into the latter category will be declared as records at an appropriate point in time. Not all documents will become records, but those that do will change from being under an individual user's control to corporate control. While documents can be edited and deleted, records are held in a fixed state, with appropriate access and functional permissions applied. Disposal Functions Records management functionality must support four standard disposal functions: review, export, transfer and destroy. Over time, electronic data stored in the EDRMS may need to be copied or archived outside the EDRMS. In addition, records that should no longer be stored by an organisation may need to be removed from the EDRMS and transferred elsewhere (e.g. to The National Archives) for permanent preservation. Where the EDRMS is capable of managing documents and records within the same class and folder structure, it is important that disposal actions are executed in the appropriate manner.

- 1 -


Export The export process allows metadata and record content to be exported outside the EDRMS environment in a suitable file format. These files may be archived or later used as part of an import operation. The fileplan objects remain in the EDRMS, with the metadata updated (e.g. "Disposal.Export status") as appropriate. When a folder (or part) containing both undeclared documents and declared records is identified for export, the EDRMS disposal mechanism must:

• alert an authorised user that undeclared documents are present, and allow them to be declared as records Note: While it is not explicitly stated, for obvious usability and ease of management reasons, it is preferred that the declaration action be provided by an automatic system function, as opposed to the user having to perform an individual manual action for each undeclared document.

• ensure that only declared records are exported - i.e. undeclared documents must not be included in the export action.

Transfer The transfer process is a single process that consists of 2 stages. The EDRMS must first export the identified fileplan objects and await user-confirmation that the export has been successful before continuing to the next stage, at which point the objects are destroyed. When a folder (or part) containing both undeclared documents and declared records is identified for transfer, the EDRMS disposal mechanism must ensure that the entire folder (or part) is destroyed once confirmation has been received that the export stage of the transfer was successful. As the export stage will only export declared records, the EDRMS disposal mechanism must ensure that any undeclared documents are automatically destroyed as part of the destruction stage of the transfer action.

Example N/A

Links A.4.50M, B.2.17 HD, B.2.18 M & B.2.19 M

Test Criteria TS22

Keywords classification scheme, document, export, record, transfer

- 2 -


- 1 -


Requirement B.2.21 HD

Text The EDRMS product set should support a personal workspace for each user, used for storing drafts of document which are not yet (and which may never be) declared as records.1

Footnote 1Such a personal workspace may also distinguish between private and public documents, neither of which are records.

Rationale

When an EDRMS is implemented within an organisation, a common aim is to reduce and ultimately eliminate the amount of information stored on different storage devices such as the pc desktop, network drives or CDs, etc. Where the EDRMS is to be the main data repository, in addition to being able to declare records, provision should be made to allow users to store draft documents that are not yet (and may never be) declared as records. The EDRMS should therefore be capable of supporting a personal workspace area for each user so that undeclared documents can be captured as required. Users should be able to view and manage the contents of their own workspace in an appropriate manner via the EDRMS interface. When a document is ready to be declared, the record will typically be assigned to a folder in the business classification scheme. However, it should be noted that some EDRMS products might allow the presence of both documents and records in a user's personal workspace. Personal workspaces will typically be governed in the same manner as other areas of the EDRMS, with functionality managed and audited as required. By default, access to a personal workspace is expected to be limited to the allocated user (with the EDRMS Administrator given standard administrative rights). However, more advanced products may allow the user to configure the access controls on each individual document in order to specify which documents are private and which can be accessed by other EDRMS users.


- 2 -

Example

A user may be working on an early draft of a production report that they do not yet wish to share. Instead of saving the report to a local drive on the pc, it is captured into a folder in the user's personal workspace within the EDRMS.

Function A

Root Class - Business Classification Scheme

Function B

Function C++

+

Personal Workspace - Jane Wilson

+

Part1

- Draft Reports

-

2005 Production Report Draft

2005 Expense Claims

Development Report - 2nd Draft

root class

class

folder

part

document

Once stored within the EDRMS environment, the document can be managed using version control, and declared as a record when deemed appropriate.

Links None

Test Criteria TS22

Keywords document, personal workspace