The European Commission does not guarantee the accuracy of the information included in this report, nor does it accept any responsibility for any use made of it.
Background
Purpose and Scope of this Specification
Related issues such as digitization and other means of creating electronic records are beyond the scope of this specification. Because it is modular, user communities can add additional functionality specific to their own business requirements (see section 1.6 and Annex 3 for guidance on using and customizing this specification).
What is an ERMS?
This specification was written with the assumption that ERMS users include not only administrators or archivists, but also general office and operational staff who use ERMS as part of their everyday work while creating, receiving and retrieving records.
For What can this Specification be Used?
Emphasis and Limitations of this Specification
Using this Specification
Organisation of this Specification
Mandatory and Desirable Requirements
Comments on this Specification
This is followed by a narrative description of some key concepts (section 2.2) and an entity-relationship diagram showing the model on which this specification is based (section 2.3).
Key Terminology
Note: may be in electronic form as a result of creation by application software or as a result of digitization, e.g. by scanning paper or microform. Different types of metadata can be defined, for example, for indexing, for storage, for presentation, etc.
Key Concepts
As with files, this specification states the requirements for the hierarchy without specifying the manner in which it is implemented. The term class thus corresponds in some texts to "group" or "series" (or subgroup, subseries, etc.).
Entity-Relationship Model
In practice, this means persons who create, receive, review and/or use records, and those who administer the ERMS. A classification scheme is the core of any ERMS, as described in detail in section 2.2.
Configuring the Classification Scheme
Classes and Files
Volumes
Maintaining the Classification Scheme
In other words, it must be impossible for a situation to arise where any user action or software failure causes inconsistency within the ESUD or its database. Finally, security requirements for security-marked documents (as commonly found in some government departments and their contractors) are listed in section 4.6.
Access
This function must be granted to the user by the Administrator according to the organization's policy. Note that the requirement in the third option (ie the strictest) means that ERMS must not include such data in any number of search results; this level of security is normally appropriate for data related to matters such as national security.
Audit trails
As a result, in some implementations, management may decide that the selected actions should not be audited; and in most cases the online audit trail is periodically moved to offline storage and is subject to deletion if and when the relevant records are disposed of. The word "unchanged" means that the audit trail data cannot be changed in any way or deleted by any user; it may be subject to reorganization and copying to removable media if required by e.g. database software as long as its content remains unchanged.
Backup and Recovery
Vital data is that data that is absolutely necessary for the organization's ability to continue its business either in terms of its ability to cope with emergency/disaster conditions or to protect its financial and legal interests.
Tracking Record Movements
Authenticity
Security Categories
In this fictional example, the "Class" subcategory is hierarchical (see 4.6.6), while the other subcategories are not. However, the requirements for hierarchical subcategories can be complex; with the exception of requirement 4.6.5, they are not detailed here.
Retention Schedules
The processes that can take place on the date specified by retention schedules are described in the following sections. Therefore, for simplicity, the word "file" is used in this chapter to denote "file or volume as appropriate".
Review
Transfer, Export and Destruction
In some environments, this may require multiple data rewrites to certain standards. The term "capture" is used to cover the processes of registering a document, deciding what class it should be classified into, adding further metadata and storing it in the ESUD.
Capture
Section (6.3) describes considerations for particular types of documents; and because of the increasing importance of e-mail, this is followed by a section on e-mail (6.4). Some of the required metadata may already be present or may be extracted automatically from the record.
Bulk importing
The reasons for this requirement are to minimize the amount of data entry performed by users and increase metadata accuracy. Which metadata elements are involved, and for which types of documents this is possible, depends on the environment.
Types of Document
The list of document types that ERMS must support will vary from organization to organization. The list of document types that ERMS must support will vary from organization to organization.
E-mail Management
Regional plan development : Public consultation : Correspondence 7.1.3 ESUD must be able to store unique identifiers as metadata elements. Similarly, if the administrator adds a new class to the "Production" class, ESUD must automatically assign it a reference of 900 - 24.
Search and Retrieval
In other words, ERMS must never present information to any user that that user is not entitled to receive. If the unique identifier is not available to the user (see note to 7.1.5) this is not relevant.
Rendering: Displaying Records
For example, when reading a record, the user should be able to find out what volume and file it is on; if looking at the metadata of the file, the user should be able to find information about the class it is in. If ERMS is storing data in a proprietary application format, it may be acceptable for the mapping to be performed by an application outside of ERMS.
Rendering: Printing
Rendering: Other
Some degree of organizational change is normal and should be taken into account in ERMS maintenance and system support facilities. An ERMS must also provide the administrator with facilities to support events such as changing number of users, increasing demand for storage capacity, recovery from system failures and monitoring system errors.
General Administration
Requirements are listed in this chapter for general administration (section 9.1), system reporting (section 9.2) and data editing (section 9.3). The changes in organizational units described above may imply corresponding changes in the classification schemes of the units and their user populations.
Reporting
The term "bulk changes" implies that all classes, files, records that are affected can be processed in a small number of transactions, instead of having to be processed individually.
Changing, Deleting and Redacting Records
The process is referred to here as editing, and ERMS stores both the original record and the edited copy, which is called here an. If ERMS does not provide these facilities directly, it must allow other software packages to do so.
Management of Non-electronic Records
It covers requirements for handling physical records within ERMS, document management, workflows, electronic signatures and other authentication mechanisms. Such a need may or may not exist, according to law and legislation; where there is such a need, care must be taken to preserve the integrity and usefulness of electronic and physical records as a whole.
Hybrid File Retention and Disposal
Document Management
For example, a user can copy a record to send a copy to a recipient who is not a user of ERMS. This copy may or may not be declared a new record according to the context.
Workflow
A user may want to send a file or recording to another user because of the content of the recording or the specified user is on vacation. In other words, flows that take the record or file to one of a number of participants depending on a condition set by one of the participants.
Electronic signatures
Encryption
This feature may be desirable in some large record archives that have a long-term access requirement (since encryption etc. will likely reduce the ability to read the records in the long term). In this case, the organization would rely on an audit trail or similar information to prove that encryption etc.
Electronic Watermarks etc
Interoperability and Openness
In addition, users of this specification will need to consider their needs with respect to current technical and operational standards, and with respect to the ERMS provider's support services, including documentation, training and consulting. This section is intended as a checklist of aspects that users will need to consider when developing their requirements, to be added to the generic requirements given in earlier sections.
Ease of Use
There will be exceptions to this, such as a remote user who does not have consistent access to the central repository.
Performance and Scalability
This requirement is intended to enable rapid retrieval of frequently used records, provided that frequency of use is typically correlated with recency of use. The time scale should be inserted by the organization, based on an evaluation of the time after which the heavy use of records decreases.
System Availability
Technical Standards
Legislative and Regulatory Requirements
Outsourcing and Third Party Management of Data
The service provider must also have procedures in place for the client to transfer individual files and records. The service provider must deliver either a reproduction of the record or the original record to the client at an agreed time and price.
Long Term Preservation and Technology Obsolescence
However, for specific media, the manufacturer's specifications must be followed (eg the environment must not be colder than a certain temperature; the media must, or must not, be cleaned periodically);. It is not possible to avoid the evolution by "freezing" the configuration, due to the need to migrate to current hardware, as described above; new hardware frequently requires new software drivers, which in turn require a new operating system, and so on.
Principles
If ESUD only stores permissions and categories as text fields that are not used for access control, this requirement is not met. For example, ESUD can pass a name and zip code to an addressing application, which then returns the street name for use as metadata.
Organisation of the Remainder of this Chapter
1 specifies that the metadata element must appear once for each element (eg, file, volume, or record) that it refers to. 0-n indicates that the metadata element can occur zero, one, or many times for each element.
Classification Scheme Metadata Elements
Class and File Metadata Elements
For example, information about the release of the file under the Convention on Human Rights, or intellectual property restrictions.
Metadata Elements for File or File Volume
Volume Metadata Elements
Record Metadata Elements
For example, rules on the use of data in the record and copyright payments.
Record Extract Metadata Elements
Users of this specification should analyze their application's requirements for metadata and modify the above accordingly. Note that the rules for validation, autocommit, inheritance, and default value are especially important for usability and acceptably low error rates when the system is used in an ongoing office operation (as opposed to in a dedicated archive).
Glossary
The point in the ESUD lifecycle at which it is installed and its parameters are established. Note: The exact nature of the delivery may be affected by the software and hardware environment.
Entity-Relations hip Model
Note: Subsections are created to improve file content management by creating units that are not too large to manage successfully. Each end of the relation has a number representing the number of occurrences (strictly, cardinality); the numbers are explained in the key.
Entity-Relationship Diagram Narrative
This is to reflect the reality that using the term electronic volume instead of electronic file could hinder understanding. This is to reflect the reality that using the term electronic document version instead of electronic document is not useful.
Access Control Model
Accordingly, in this document the term electronic document is used loosely to mean a version of an electronic document in most cases. OPTIONAL indicates that ESUD may allow or prevent this combination of roles and functions and that the using organization must determine whether its procedures allow or prevent this combination.
Development of this Specification
Use of this Specification in Electronic Form
Acknowledgements
Correspondence to Other Models
The metadata elements described in Chapter 12 can be mapped to the "Pittsburgh Metadata Model" (see Appendix 1 of ref. [9]). User group access rights User access rights Security category User group access rights User access rights Security category.
Date Processing
Standards and Other Guidelines
