David

Really good point. One other thing to remember is the need to ensure that what ever the trip reason (rule, date that starts the clock ticking) is used actually  gets filled in. The more unusual the trip reason the less chance staff ever fill it in.  For example The  date closed rule is a common one to use (it would fit in with your example) but is it very likely no one in the business will ever fill the date closed field in on the EDRMS. The only way to use this rule is if the EDRMS is integrated with the line of business (LOB) application and the staff actually fill in the date closed (employment ended, etc) as part of their normal work (it helps if someone is reporting on number of the field use for quality or performance requirements).

 

A couple of examples of trip reasons I use are;

 children social care/education files and personnel files I use date of birth. As date is entered when file is created you know when the file is to be destroyed.

For Adult client files I use date closed - date automatically transferred from the LOB

Contract records also use date closed, but it requires work from the business to do a little calculation when they create the folder (i.e. Date contract started plus number of years contract is let for, I also usually suggest they also add in the possible extension period as they may forget to do this in future) - The business unit staff also have the option to alter the date closed field (in case it is extended but they have not entered the date previously)

 

Other standard type trip reasons I use are;

Date folder created

date  last document added into a folder (this is usually instead of a date closed rule, or counts as date of last action). This is probably the best one for use in an EDRMS as the last document/record added into the system is the one that governs the retention.

 

 But at the end of the day you still need to create some additional rules within the system to fit with what the business needs.

 

hope this helps

 

 

Dear list members,

 

I wonder if you could clarify something that I have been discussing with my colleagues.

We have been discussing the implementation of an EDRMS based upon LGCS and the practicalities of initiating the rules that surround the schema.

 

Imagine you have an area in the LGCS where you want to implement an expiration rule e.g. LGCS ID3 - Adult Care Services > Carers>Agency Provided Services>Destroy 25 years after end of employment

 

I have argued that given there are 1039 entries in the LGCS schema it may be impractical to expect records managers to input each of these rules into an EDRMS.

I also argued that each node in the LGCS schema may need its own bespoke metadata to capture the correct rule –

So in the example above you would need a metadata field to capture 'end of employment' and then add 25 years to calculate the expiration date.

 

Given that given there are 1039 nodes in the schema and that each one may need its own set of metadata,  it may be simply too time consuming and expensive to setup all of these rules in an EDRMS.

 

My argument is that records managers may set rules at a higher level e.g. Adult Care Services>25 years after record creation

 

Could you possibly provide me with some advice/guidance as to what is common practice/experience when setting up these rules in an EDRMS and if you manage your records down to this level of granularity?

 

 

Many thanks

 

David Nixon

 

 

For any technical queries re JISC please email [log in to unmask] For any content based queries, please email [log in to unmask]