However, nothing is as simple as that!

Each record has a “context” surrounding it, made up of its metadata, access control information, events and related entities, such as a record’s parent aggregation, its classification and its disposal schedule.

When we export the record from one MCRS and import it into another MCRS we want its context to travel with it. This means a “lossless” transfer of information. If we don’t keep the context with the record then the transfer is “lossy”.

Whenever a user exports an entity, or entities, from an MCRS the specification defines precisely what other surrounding entities must be exported with it. There is also a technique for ensuring that this group of peripheral entities doesn’t grow too large.

By transferring context we can hopefully ensure that records can be successfully exported and imported by generations of records systems, into the future.

Underpinning all MCRS solutions are the core services that all records systems must have in common. These services manage things like users, classes, aggregations, records, disposal schedules, etc.

Each of these is an entity type that has its own set of system metadata and its own functional requirements. For example, every record has a title and a description, and a function for modifying the title and description, as required.

So what happens if the MGB creates an extension module in the future and how does this affect our definition of a record? Lets take a hypothetical scenario, for example, we want to create an extension of MoReq2010® specifically for hospitals.

As part of this we might decide we want a special type of record, let’s call it a “patient record”. A patient record will “extend” the basic record defined by the core services. (In technical terms it can be said to be a “sub-type” of the record entity type.)

Our new patient records might have more system metadata than other types of record, for example, they might always include the name of the doctor who performed the treatment that created the record.

Similarly patient records might also have more functions associated with them. For example, we might be able to link them to a new entity type called “patient”.

But MoReq2010 also has modularity built into the core services as well. Each service provided by an MCRS is defined as a logically separate set of requirements. The specification calls this a service based architecture.

An example is the classification service. The purpose of a classification service is to manage a classification scheme and maintain the classes it contains. Classes are therefore the only entity types a classification service needs to know about.

The service based architecture model, where different sets of functionality are contained in different logical services, allows for some interesting future innovation. For example, several records systems might share the same classification service, so that an organisation with many different business systems only needs to maintain a single centralised classification service.

There are lots of generic industry acronyms like ERMS, EDRMS, CMS and ECM, to name but a few. These terms are vague, they could mean anything, and they are frequently used for marketing purposes.

By comparison, MCRS has a highly specific meaning. It means that the product is compliant with MoReq2010®, it has undergone testing by an accredited test centre, and the supplier can produce a certificate issued by the DLM Forum.

Compliance with MoReq2010® is highly valuable as the specification is designed around the needs of interoperability. MCRS solutions can speak the same language – other records systems only speak their own proprietary language.

In the future one records manager may say to another, “Is your system just an ERMS, or is it an MCRS?”

ISO 15489 describes an “authoritative record” as being a record that has the characteristics of:

• authenticity;
• reliability;
• integrity;
• usability.

As explained in ISO 15489, the aim of all records management systems should be to ensure that records stored within them are authoritative.  Summarising, an authoritative record:

• can be proven to be what it purports to be;
• can be proven to have been created or sent by the person purported to have created or sent it;
• can be proven to have been created or sent at the time purported;
• can be depended on because its contents can be trusted as a full and accurate representation of the transactions, activities or facts to which it attests;
• is complete and unaltered;
• can be located, retrieved, presented and interpreted.

The requirements in MoReq® are designed to ensure that records stored in an MCRS are authoritative.  However, compliance with MoReq2010® alone is not sufficient; the existence of, and compliance with, corporate records management policies is also required within every organisation.

The illustration is from the MoReq2010® specification and contrasts two different types of document: to the left a shopping list written on the back of an envelope compared to a receipt on the right of the same items purchased from a shop. The accompanying caption states, "One of these is probably not a record... the other may be".

• Determining how long to retain records;
• Creating and registering records;
• Classification of records;
• Storage and handling of records;
• Controlling access to records;
• Tracking records;
• Disposing of records; and
• Documenting records management processes.

ISO 15489 proposes that an organisation should use a records system to implement these processes. It defines a records system as an “information system which captures, manages and provides access to records through time” (ISO 15489-1:2001, 3.17).

MoReq2010® is a specification for defining a records system expressed as a modular set of requirements. It goes beyond the broad description offered by ISO 15489 and adds a far greater level of specificity in how these processed should be carried out. Achieving MoReq2010® compliance requires a greater degree of rigour than can be achieved by simply building a records system that handles the records management processes described by ISO 15489 in its own proprietary way.

One of the advantages of this, and a design goal of MoReq2010®, is the potential for interoperability between MoReq2010® compliant records systems (MCRS). An MCRS does not only understand its own entities and its own processes, it can export them to a standardised format that can be understood by another MCRS.

Interoperability is essential to the management of records using a records system. Today’s organisations typically refresh their technology every three to five years. Records are often held for much longer than that. If an organisation is required to keep a particular record for 75 years then, at the end of that period, it will typically have been transferred from one records system to another between 15 and 25 times.

Even taking into account necessary plug-in modules, we have reduced the number of requirements in the core specification that a records system must comply with by 50%, compared to the previous edition. In fact, only around 10% of the specification is taken up by the functional and non-functional requirements (17% including the rationale to each requirement).

We have also made it easier to define a suitable records system for any given organisation by eliminating the previous practice of interleaving mandatory, desirable and conditional requirements. All requirements in MoReq2010® are mandatory within any given service or module. This means that a records system can be easily defined by simply listing the modules that are required in addition to the core services. Previously this meant working through dozens of desirable and conditional requirements to fully define a suitable records system for an organisation.

There is a quotation attributed to Albert Einstein that, “Everything should be made as simple as possible, but no simpler.” While we think that we have kept MoReq2010® as simple as possible, the reality is that the discipline of records management, by its nature, can be quite complex.

Because of this, we have intentionally increased the size of the document to include a much higher proportion of explanatory text. MoReq2010® is an international specification and we want to make sure that it is clear and accessible by people new to records management, people reading it who do not have English as their first language, and the diligent translators who work hard to bring MoReq2010® to as many different languages, countries and cultures as possible.

To achieve this, in addition to the introductory chapter there is a comprehensive section on key concepts at the head of each service and module; there are around three times as many diagrams, in colour, to accompany this text; we have completely revamped the non-functional requirements; we have included nearly five times as many terms and their definitions in the glossary; and we have a far more comprehensive and robust information model, including for the first time function definitions in addition to entities and metadata elements.

To illustrate this, the pie chart shown here gives a proportional breakdown of what is in the 463 pages of core services in version 1.0 of MoReq2010®. We hope you like what we have done with it!

By businesses

• As an aid for the procurement of a records system;
• As a practical tool in helping organisations configure records systems to meet their business and legal obligations; and
• As a guide to the audit of an existing records system implementation.

By experts

• As a reference document for training courses and the preparation of course material;
• As a teaching resource for academic institutions; and
• As an example of how traditional records management approaches and archival science can be applied to modern systems requirements.

By industry

• To guide the development of records systems by suppliers;
• To integrate records systems with other business systems; and
• As the authoritative source when undertaking the testing and certification of compliant solutions by accredited test centres.

By users

• As a user-centric and easily understandable resource and primer on implementing records systems;
• As the original for all translations; and
• As a reference glossary for guidance on records management terms and their meanings.

The MoReq® project is now regarded as an unqualified success. the specification has been cited many times on many continents and it has a central role in the electronic records management scene.

However, information technology has changed since 2001. There has been growth and evolutionary change in many technology areas that affect the creation, capture and management of electronic records. The original MoReq® has now had two major revisions. MoReq2® released in 2008, introduced a testing and certification programme. This was a significant step forward, as for the first time records systems could be certified as being compliant with MoReq®.

The recently released MoReq2010® continues to innovate and goes beyond any of the previous iterations. The main design goals of MoReq2010® include modularity and interoperability. Modularity is achieved by the specification of a minimal set of core services common to all records system. On top of this platform of core services, MoReq2010® can be extended and modified to address the specific needs of organisations in different sectors. To achieve this, MoReq2010® uses an innovative service based architecture, shown here.