Thanks Maureen. That is totally complicated and I am glad I do not have
to deal with it. I work on "simpler stuff" primarily. But good to know if
I run into this. Get an expert involved.
Trudy M. Phillips
File Management, LLC
"Bringing Order Out of Chaos"
8440 Lanewood Circle
Leeds, AL 35094
Office: 205/699-8571 Fax: 205/699-3278
_www.filemanagement.com_ (http://www.filemanagement.com/)
In a message dated 8/7/2009 11:35:53 A.M. Central Daylight Time,
[log in to unmask] writes:
An example these 'complex' systems with middle-step processing data
'records' is medical claims and the systems that process them. The raw data
might be the two dozen or so processing actions for a given claim, which
might be a claim submitted by a patient or a provider. Each step leaves
records behind; for example step 7 might be the patient's new phone number,
step 14 might be the batch error report showing success or failure of the
previous processing transaction which may have been an important process,
and the subject of a law suit, because it's evidence of a company
'decision'
, for example data showing how the system codes something - maybe a
medical
procedure- which in turn might be based on certain information in
other records stored in another module of the system. The processing data
doesn't move, neat and tidy, from one processing action to the next, to the
final record which might be the payment and remittance advice. Each step
leaves 'pools' or 'puddles' behind: huge volumes of data that accumulate
where created, and if extracted as a screen shot or a print out is readable
to non-experts suits, and is very much the subject of a law suit if it is
important enough.
So the records manager has to decide for each each pool or puddle, such as
steps 7 and 14, 'is it a record?' If so is it the same record type (eg a
'related record') as the final record, therefore needing the same retention
period? Or is it merely an administrative record, unrelated to the final
record, because the processing step is something minor ? Then once you
decide what raw data are 'records' and what kind of records they are, you
must decide how they will get destroyed by IT staff to conform to the
retention period assigned: will you build in automated destruction
programming? Will you get IT people to manually destroy stuff? How often?
Then you must make rules around storage migration: will you let the data
move offline to be stored on inaccessible media? (laws are getting
increasingly stringent laws about use of inaccessible media like backup
tape). IT shouldn't decide these things but often do, considering only
efficient 24/7 functioning of the system and cheap storage options. So you
have to poke your nose in and find out what data exists, where it lives
through its lifecyle, what it looks like (eg as federal and state
edisacvoery rules say what 'categories of information' it is),
how/when/where it is destroyed, especially when hit with preservation
orders
or production orders.
maureen
On Thu, Aug 6, 2009 at 6:46 PM, Trudy M Phillips <[log in to unmask]>
wrote:
> Thanks Maureen,
> Being somewhat simple minded, can you give me a specific example of
"each
> of
> which produces records that accumulate rapidly in that particular
location
> (on that server processed by that module of the software) which may be
> more
> or less readable by non-system experts (e.g. by attorneys).".
>
> I read what you are saying, but unsure as to an instance, application
or
> report. And honestly, I have not ever worked with huge mega systems of
> data
> where this occurs. Or at least on the smaller applications, I am not
> aware this is happening in the background.
>
> Trudy M. Phillips
> File Management, LLC
> "Bringing Order Out of Chaos"
> 8440 Lanewood Circle
> Leeds, AL 35094
> Office: 205/699-8571 Fax: 205/699-3278
> _www.filemanagement.com_ (http://www.filemanagement.com/)
>
>
> In a message dated 8/6/2009 7:56:58 P.M. Central Daylight Time,
> [log in to unmask] writes:
>
> Well the distinction between raw data and final 'record' gets blurred
with
> big complex systems: there may be two dozen middle processing steps,
each
> of
> which produces records that accumulate rapidly in that particular
location
> (on that server processed by that module of the software) which may be
> more
> or less readable by non-system experts (e.g. by attorneys). These 'raw
> data' middle-step processing records may specifically be required in
law
> suits when the issue is the way the system processed the data; so the
data
> in module 1 must be compared with the same data in module 2 and so on
> through the data's journey to becoming a final record that, for example
> was
> the basis of a company decision and/or that was mailed to a customer.
>
> Maureen
>
> On Thu, Aug 6, 2009 at 5:06 PM, Trudy M Phillips <[log in to unmask]>
> wrote:
>
> > Well, I am not understanding this conversation thread at all.
> >
> > I thought we had determined that data in a database or in a
spreadsheet
> was
> > just data until a report was created from the data and such report
was
> > would be attached to the retention period for which the report was
> > created?
> > So, how can you parse sections of a database? To me, databases are
in
> a
> > continual state of flux? Data changes, sometimes by the minute. I
> do
> > not
> > see a database as being stagnant so there for needing a retention
> period
> > requirement.
> >
> > Now if it is a database, that was created for a specific purpose and
not
> > changed afterwards, then yes I can see that it could then become
> something
> > with a retention period.
> >
> > Trudy M. Phillips
> > File Management, LLC
> > "Bringing Order Out of Chaos"
> > 8440 Lanewood Circle
> > Leeds, AL 35094
> > Office: 205/699-8571 Fax: 205/699-3278
> > _www.filemanagement.com_ (http://www.filemanagement.com/)
> >
> >
> > In a message dated 8/6/2009 5:19:38 P.M. Central Daylight Time,
> > [log in to unmask] writes:
> >
> > I usually find out the preference of the users or IT administrator
and
> > it's
> > usually one of three things: (1) to parse sections of the db and
> establish
> > particular retention periods for each, (2) to run static reports and
> > consider those the (only) 'records, (3) to retain the whole database.
> The
> > last option entails locking the down the database at a certain point,
> e.g.
> > at the end of a project, and using the youngest record's creation or
> > modified date to begin the retention period; this is similar to the
> > concept
> > of 'closing the record series' (a phrase repeated in the UK
> government's
> > ERMS requirements standard). The first option is surprisingly
popular
> with
> > some IT people if the database is big, complex, with multiple IT
> support
> > people, strict capacity limits, and if different business units use
> > different sections of the system. The second option: it's difficult
to
> > reach
> > consensus on what to capture in a report, and what is important will
> > change
> > over time anyway, plus there are risks to deleting the underlying
data
> > (you
> > never know what will be needed in a law suit).
> >
> >
> > --
> > Maureen,
> >
> > List archives at http://lists.ufl.edu/archives/recmgmt-l.html
> > Contact [log in to unmask] for assistance
> > To unsubscribe from this list, click the below link. If not already
> > present, place UNSUBSCRIBE RECMGMT-L or UNSUB RECMGMT-L in the body
of
> the
> > message.
> > mailto:[log in to unmask]
> >
> >
> >
> >
> > List archives at http://lists.ufl.edu/archives/recmgmt-l.html
> > Contact [log in to unmask] for assistance
> > To unsubscribe from this list, click the below link. If not already
> > present, place UNSUBSCRIBE RECMGMT-L or UNSUB RECMGMT-L in the body
of
> the
> > message.
> > mailto:[log in to unmask]
> >
>
>
>
> --
> Maureen,
>
> List archives at http://lists.ufl.edu/archives/recmgmt-l.html
> Contact [log in to unmask] for assistance
> To unsubscribe from this list, click the below link. If not already
> present, place UNSUBSCRIBE RECMGMT-L or UNSUB RECMGMT-L in the body of
the
> message.
> mailto:[log in to unmask]
>
>
>
>
> List archives at http://lists.ufl.edu/archives/recmgmt-l.html
> Contact [log in to unmask] for assistance
> To unsubscribe from this list, click the below link. If not already
> present, place UNSUBSCRIBE RECMGMT-L or UNSUB RECMGMT-L in the body of
the
> message.
> mailto:[log in to unmask]
>
--
Maureen,
List archives at http://lists.ufl.edu/archives/recmgmt-l.html
Contact [log in to unmask] for assistance
To unsubscribe from this list, click the below link. If not already
present, place UNSUBSCRIBE RECMGMT-L or UNSUB RECMGMT-L in the body of the
message.
mailto:[log in to unmask]
List archives at http://lists.ufl.edu/archives/recmgmt-l.html
Contact [log in to unmask] for assistance
To unsubscribe from this list, click the below link. If not already present, place UNSUBSCRIBE RECMGMT-L or UNSUB RECMGMT-L in the body of the message.
mailto:[log in to unmask]
|