"Show notes" for this episode…

Episode 003 - The Disposal Process

Synopsis

In this episode James and Jon dissect the disposal scheduling service in MoReq2010 and walk through the disposal process for records and aggregations. The link between classification and disposal is summarised as “class determines destiny”.

Featuring

James Lappin and Jon Garde

When recorded

October 2011

Running time

108 minutes

Main topics discussed

Disposal is very closely linked to classification in MoReq2010
In MoReq2010 disposal schedules are not associated with aggregations
Records may inherit their class from their aggregation
Records get their default disposal schedule directly from their classification
In order to use a class to classify an aggregation or record it must first be given a disposal schedule
A class without a disposal schedule cannot be used in classification
The principle of “class determines destiny” means that only classes can give records a default disposal schedule
The disposal schedule associated with a record can be overridden but this is normally done in the context of a review
A review is not complete until the user has authorised the new disposal schedule given to the record under review
Disposal scheduling is not done at the level of an aggregation, file or folder
This is different to other records management specifications
Other records management specifications allow a record to have different and conflicting retention rules from different sources
In MoReq2010 there can never be a conflict of retention rules because a record only has one disposal schedule (because it only has one class)
The disposal of each record is determined individually by the MCRS
Theoretically an authorised user can override the disposal schedule when a record is captured but this is not recommended and changing disposal schedules should only be permitted for privileged users
A requirement to change the disposal schedule at record capture is often an indication that the classification scheme is not detailed enough
In some cases classification can be used in a more granular way than the level of aggregation alone
For example, MoReq2010 is able to cope with aggregations that contain records with many different classifications, such as hospital patient files
Other examples of records with different classifications are Leave Forms and Leave Summaries on Personnel Files
One extension module that has been suggested for MoReq2010 is an “aggregation type” which can be used to restrict the records that are placed into an aggregation to a specified range of classes
With MoReq2010, organisations can pick and choose the functionality they want in their records systems, this can be likened to an “app store”
To define an extension module for MoReq2010 there needs to be a suitable chunk of requirements that is broadly applicable to more than one system
The MoReq Governance Board will judge the suitability of future extension module projects
The MGB is looking at setting up joint working groups to develop future extension modules
The MoReq2010 core services do not specify rules for which class is classified against a particular record
By associating a disposal schedule with a class we create a future plan for any record classified
Aggregations are destroyed with the last record in the aggregation is destroyed as long as the aggregation is closed
This is called “bottom up destruction”
Several tiers of aggregation will be destroyed from the bottom up, as their contents are destroyed
MoReq2010 does not dictate the purpose of an aggregation or a layer of aggregation
Aggregation structures can be flat containing millions of records with different classes or they can represent a traditional file where every record has the same class derived from the parent aggregation’s class
In MoReq2010 a class must have a disposal schedule and a record must have a class
Therefore it is not possible to have a record without a disposal schedule
Each record has at least one and no more than one disposal schedule
In some records management specifications there is a way of placing the same record into more than one file (aggregation)
MoReq2010 solves this problem through record duplication
A duplicate of a record has the same content
The metadata of a duplicate is the same at the moment of duplication but may change later
Similarly the event history is the same up to the duplication event but will change subsequently
Each duplicate also has its own access control list
The duplicates (records, components and events) will cross reference all other duplicates
Duplicates can be in other aggregations or even other records systems cross referenced by a universally unique identifier
Disposal schedules in MoReq2010 are tightly defined so that each metadata element is the same across all MoReq2010 compliant records systems
This allows for universal understanding and applicability of the disposal process
Disposal schedules can be transferred from one records system to another and both systems will give it the same meaning
The disposal schedule governs:

The event which triggers retention
The length of the retention period
The disposal action that is taken at the end of the retention period
And any subsequent confirmation period

Retaining permanently represents a special type of disposal schedule which does not define this metadata (there is no retention trigger)
Disposal actions are:

Review
Transfer
Destroy

Reviewing means determining what to do with a record
The review cannot be completed until a new disposal schedule is assigned to the record
Confirmation periods are required for transfers and sometimes for destruction
When a record is transferred, either by MoReq2010 export or another mechanism, confirmation is required that the receiving system has successfully imported the record
Sometimes confirmation of destruction of components is also required
This depends on the nature of the component and how directly it is managed by the records system
If the content of the record is under the records system’s control then the record system will destroy it immediately
If the content is not directly under a records system’s control then a confirmation will be necessary
Physical content is an example of the type of content that will always require a confirmation
Destruction is not deletion in MoReq2010
The content is deleted but the record is not destroyed as an entity
MoReq2010 allows for the pruning of the metadata and the event history of entities that are destroyed
An authorised user can specify by event type which events are kept on destruction
An authorised user can also specify which metadata fields are kept on destruction
It is important to get rid of some metadata that might reveal the contents of the record
MoReq2010 records systems keep some trace of all records they have ever contained for as long as the system is active
MoReq2010 allows all of the metadata, event history, access control list, class, disposal schedule, the components and content of a record to be transferred from one system to another and be understood and acted upon
Disposal schedules are held in a disposal scheduling service that is similar to a classification service approach to managing classes
A records system can use one or more disposal scheduling services
In the future, industry wide disposal scheduling services may be published by different regulators
Each disposal schedule is an entity with its own metadata
Many metadata for a disposal schedule cannot be changed, instead a new replacement disposal schedule must be defined
MoReq2010 allows one disposal schedule to be replaced by another for every entity within the records system to which it is applied
The disposal process is represented by Figure 8h as a decision tree or flowchart
For every record an MCRS must evaluate it by applying this disposal process every day for every record
The lowest granularity for a retention periods is one day
MoReq2010 does not dictate how an MCRS evaluates which records it must process so long as the observed behaviour is the same as if the system worked through the disposal process decision tree every day for every record
Because each records system follows exactly the same disposal process (no matter how they do it under the surface) and they all keep the same metadata this enables all systems to have a common understanding
By classifying a record under MoReq2010 a record is given a plan that defines its lifecycle going forward and what will happen to it in the future
It also protects the record from users who try to circumvent the plan
It is this rigour that separates a true records system from a document management system that has some records “features” added to it

Latest news

Musing over MoReq2010 has its own website at www.musingovermoreq2010.com
The postbag is postbag@musingovermoreq2010.com
The website has detailed show notes for each episode
MoReq2010 translators conference in Warsaw is on November 7th and 8th (Monday/Tuesday)
DLM Forum Triennial Conference has a lot of discussion around MoReq2010 topics and is in Brussels on December 12th to 14th (Monday through Wednesday)

From the postbag

Does MoReq2010 apply to the new world of cloud computing and how does it apply?
A great fear around the transition to cloud computing is how an organisation can get its records back in the future
Eventually we hope that cloud platforms will evolve to have built in MoReq2010 compliance
In the meanwhile smaller vendors must step in to fill the gap using APIs
This type of bolt on application for the cloud is similar to the ecosystem that can be seen around Microsoft Sharepoint
Another problem is how to transfer records between the enterprise and the cloud
The MoReq2010 XML schema can represent a standard format for transfers that everyone can agree on
Consumers adopting cloud computing solutions must ask the question of their supplier “How can I get my records back from the cloud in the future?”