Setting Standards:
MoReq2: The New Model for Developing, Procurring Electronic Records Management Systems

Most records and information management professionals are familiar with the European Model Requirements for the Management of Electronic Records, commonly referred to as MoReq. Much like the U. S. Department of Defense’s DoD 5015.02-STD Electronic Records Management Software Applications Design Criteria Standard (DoD 5015.2) and the United Kingdom’s Requirements for Electronic Records Management Systems (PRO 2002), MoReq set out to define a standard specification of requirements for electronic records management.

Marc Fresko

However, unlike those two specifications, MoReq was intended for use in every European country and in every economic sector. Unexpectedly, MoReq also caught on beyond the European community and was translated into at least 11 languages. In early 2008, its successor, known as MoReq2, was published with several key enhancements.

The Genesis of MoReq2

The MoReq2 development process during 2007 was highly communal – with more than 200 volunteer individuals and organizations participating. The volunteers came from every sector – user organizations, consultants, integrators, academics, and software suppliers. Importantly, the volunteers included virtually all the significant suppliers of electronic records management systems in Europe, from the very largest multinational players to small companies active in only one region. During the consultation process, the MoReq2 development team received and processed thousands of comments, which makes MoReq2 the most comprehensive and usable electronic records management specification yet.

The guiding principle for MoReq2 was evolution, not revolution. It is an evolutionary step from MoReq – not a radical change. The basic ideas inMoReq – documents, records, files, classes, and the like – have been supplemented rather than replaced.

The Purpose of MoReq2

MoReq2 is intended to be useful to a wide community of stakeholders in electronic records management:

• Users of electronic records management, who can customise MoReq2 to guide specification and procurement
• Vendors of electronic records management software and services, who can use MoReq2 to drive software development
• Educators, who can use MoReq2 as a tool to teach and train the records managers of the future MoReq2 is intended as a specification for electronic records management systems – namely, applications that are intended for the management of electronic and physical records. Such records are, for the most part, “unstructured” – e-mail messages, text documents, scanned documents, and so on.

MoReq2 is not intended to specify the management of records in “legacy” applications (such as human resources or manufacturing applications), and is it not intended to specify how a system is implemented.

Key Differences Between MoReq and MoReq2

MoReq2 differs from MoReq in four ways:

Testability

Unlike DoD 5015.2 and PRO 2002, MoReq did not have a testing scheme. MoReq2 was designed and written expressly with testability in mind, and it was published along with extensive test data and test scripts. A by-product is that the language in MoReq2 is much clearer, with less room for ambiguity.

Governance

MoReq was effectively “orphaned” soon after its production. Not only did it not have a testing scheme, it was not maintained or controlled, despite its popularity (and probably because its worldwide popularity came as a surprise). The DLM Forum, an independent stakeholder group that first conceived MoReq, is working on a governance regime to control MoReq2, to monitor translations and extensions to it, and to manage a testing plan across Europe. This is expected to be in place by the end of 2008.

Strucure

MoReq2 has three structural innovations.

1. It allows for any country to add a “chapter zero” to explain language differences (such as the tricky idea that the English word “records” does not exist in most other European languages), national laws, and regulations.
2. It is modular, consisting of a core module of requirements that addresses specifically records management requirements and 13 optional modules that address closely related requirements that are essential to many groups of users. The 13 modules include, for example, collaborative working, distributed systems, fax integration, offline and remote working, and workflow.
3. The metadata model has grown to such large proportions that it has been split off into an appendix that is published alongside MoReq2 as a separate document. Few users of MoReq2 will need to refer to the metadata model, partly because an XML schema will be published later in 2008 for MoReq2. This will provide a way for electronic records, with their metadata and audit trails, to be transferred between disparate electronic records management systems without loss of records management functionality as long as both systems are MoReq2-compliant and respect the MoReq2 schema.

Content

The requirements specified by MoReq2 contain several enhancements and additions. Some of these are described below.

The Components of MoReq2

MoReq2 uses a new entity-relationship model, one that is clearer and more straightforward than MoReq’s model, but at the same time richer. This is because MoReq2 manages without the confusing concept of “hybrid” files (those files that contain both electronic and physical records) and because it adds two new entities and a few new relationships.

Instead of recognizing hybrid files, MoReq2 simply recognizes that any file – indeed, any aggregation – can contain any combination of physical and electronic records. This greatly simplifies the model and allows the language of the specification to be clearer and simpler.

New Entities

The first new entity introduced with MoReq2 is called “sub-file.” This is a subdivision of a file; the idea is that some files (not necessarily all files) can be divided in a way that supports its business use. For example, the client files in an accounting firm might be divided into sub-files for client correspondence, audit reports, working papers, and internal correspondence. Sub-files will be useful mainly, though not only, in case management environments.

This new facility is in addition to the existing requirement to be able to divide files into “volumes.” Not surprisingly, dividing some files into sub-files, and dividing some sub-files into volumes, could be too complex for some smaller organizations. Therefore, MoReq2 requires that the electronic records management system must be able to be implemented with either sub-file, or volumes, or both, or neither, implemented.

The second new entity is the “component.” A component is a separate electronic entity that makes up an electronic record. The obvious example arises in web pages, which are usually made up of several “files” (in the computer sense, not in the records sense).

By way of illustration, at the time of this writing, the ARMA International website home page showed it consisted of two cascading style sheet files, 41 GIF and 10 JPEG image files, and four JavaScript files – a total of 57 components. All of these components must be kept in correct context for that page to be managed as an electronic record.

MoReq2 includes several requirements for the management of components to allow complex records to be managed properly, in particular as it regards long-term preservation. Those concerned about long-term access should look to components to become more and more important.

Retention

The underlying model for MoReq2 also provides greater flexibility inmanaging retention and disposal, a core records management function. Retention rules can be applied to classes and files, as before; but they can also now be applied, if needed, to sub-files, volumes, and even to individual records.

In another new departure, they can also be applied to “record types,” a feature that could be useful when implementing retention and disposal rules for records that include personal information. MoReq2 also specifies how the
system must behave if it encounters a conflict between retention rules.

Another addition to the model has proved to be contentious: the ability to “store” records directly in a class, without the need for the records to be allocated to a file. This is intended for use in environments that process large numbers of very simple cases – something like permit applications, perhaps. In a paper world, it is possible that the application forms would be processed and filed in a filing cabinet, without a file being opened for each form; this feature in MoReq2 mimics this behavior.

The feature is intended only for this niche situation, and it is expected to be used rarely. It would be poor practice to use it in any other setting, so MoReq2 requires that the system must allow the ability to store records directly into a class to be configured off during implementation.

Classification Scheme Integration

MoReq2 provides a lot more detail than its predecessor about the requirements for importing and exporting parts of classification schemes from other systems, which will facilitate mergers and other organizational change.

First, there are explicit requirements for the handling of the metadata associated with all the entities being exported or imported. For example, MoReq2 specifies that the systemmust not ignore the fact that “mandatory” metadata is missing from imported records or classes; it must handle it in a suitable way.

Also, MoReq2 allows for the possible naming and numbering clashes that the import of classes can lead to. And, on a related note, the requirements for moving parts of the classification scheme – moving a class to another point in the classification scheme – have been tidied up and comprehensively re-worked.

Vital Records Requirements

In the MoReq2 chapter dealing with controls and security, the sections on access controls and audit trails are perhaps the least-changed sections – though even here the language has been tightened up, clarifying the distinction between roles, users, and groups. for example. However, there is a new section that should please many records managers – namely, one that defines requirements for managing vital records (perhaps a “first” in the world of electronic records management).

E-Mail, Scanning Integration

The core module includes requirements for integration to e-mail systems and scanning sub-systems.These requirements have been the subject of some disagreement, though many believe that the majority of electronic records management implementations and the overwhelming majority of systems will need to integrate both with e-mail and with scanning. As elsewhere in MoReq2, the requirements for this integration are specified in more detail than before; in the case of e-mail, there is even a detailed mapping of the records management metadata requirements to the formal definitions of e-mail header metadata.

Naming, Numbering

MoReq2 ismuch clearer on how entities, such as records and aggregations, are to be named and numbered. Globally unique identifiers are recommended but not required, and there is more flexibility for naming, especially useful for case files.

Long-Term Preservation

The long-term preservation and accessibility of electronic records is becoming an increasing cause for concern – and quite rightly. MoReq2 introduces a new requirement to support long-term preservation, including a requirement to be able to convert records to a preservation format at time of capture and a rather complex set of requirements for the migration of selected components to preservation formats when required. This, too, is a first in electronic records
management, but it undoubtedly marks no more than one step in what will be a long and difficult journey.

Ease of Use

One of the distinguishing features of MoReq2 (and of MoReq before it) is that it includes requirements for ease of use. Novelties in MoReq2 include requirements that allow users to suspend, or interrupt, a process – say to look something up – and then to return to that process without having to start all over again. MoReq2 also considers accessibility for users with the widest range of needs and abilities, making reference to appropriate standards. These and other new requirements related to usability will contribute to the future acceptance of electronic records management systems.

Why So Many Changes?

This is a selective sampling of some of the main changes in MoReq2. There are many more – not only in the core requirements touched on above and in the optional modules not described above, but also in nine appendices that provide extensive supporting references and cross-references.

In the handful of years since MoReq was published, two developments have been influential. First, office software has evolved, bringing novelties such as collaboration software, more pervasive use of e-mail, electronic signatures, and so on.

Second, many of the difficulties encountered by MoReq clients with early-generation electronic records management software have been solved with MoReq2. As a result, MoReq2 is significantly longer than its predecessor, but this is inevitable for a specification that sets out to be completely generic, usable in organisations large and small, usable in the public, private, or nonprofit sector, usable in a centralized or distributed architecture, and usable in any country.

Where to Find MoReq2

MoReq2 can be downloaded freely from the MoReq2 project website, www.moreq2.eu. The site also contains the testing framework documentation, the XML schema, frequently asked questions, and other supporting collateral. More supporting material will be added as MoReq2 users demand it – and so it will evolve.

Marc Fresko can be contacted at marc.fresko@serco.com.

From July - August 2008