MoReq2010® is a modular specification, in fact we changed the name because we felt that this was its most important aspect. MoReq® stands for “Modular Requirements for Records Systems”. But how does modularity work?
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”.