Ray makes some interesting points below mine so perhaps read from the bottom
up.
When I say save the data in ASCII I implied saving the schema as well. I
guess the way I would handle the FDA rule is to go ahead and keep all the
binary stuff knowing full well I won't use it, but also have the ASCII so
that I can actually reconstruct the data.
It might also take some time to sit down and actually figure their intent:
they want to know the data and how you arrived at it. That could be
procedural, flow chart, etc. Having the code on a tape doesn't mean you
could actually run it. I suppose one could analyze the code to see what it
"did", but it probably couldn't still "do" it.
You know, to be honest, this is the first time I've ever had anyone produce
the actual requirement! Most folks can't get this far. They know they are
supposed to save stuff, but they don't know what or how or why. While the
directive is subject to interpretation, at least it is a directive.
If one wants to take this to the best conclusion, I would suggest ensuring
that all applications being developed have the additional requirement of
being able to read the data from the previous application. That way you
bring your old data with you. This has interesting connotations not the
least of which is the cost. However, imagine in your business: you develop
a new technique for analyzing data. This technique is applied to older data
obtained from a completely different study. However, by twisting it a new
way, the old data yields a new solution. Could be valuable.
I'm sure this is done anyway and not due to the tool but rather to the
researchers: they know what drugs already exist, the studies for those drugs
and possible new interactions. Given that, though, if the old data were
available to the new application their analysis might be easier.
The most interesting aspect of this is how often are we actually required to
recover data this old? And when we do, it's rarely for a good purpose.
Usually for a bad one: somebody is suing us. Oh shucks, were we supposed to
keep that old stuff?
I don't fight this battle much, especially as vehemently as I used to. I
encourage folks to keep that data they know they are going to need (I mean
really know, and not just for the bad purpose) in a format they can actually
read. The rest of it I encourage them to simply keep it. That's a good
place for separate archive pool in TSM. Write it to those tapes and get 'em
out of the library.
Finally, who ensures that the backup software used to write the tapes is
available seven years from now? I guess since we're keeping everything
forever we might have a chance of recreating that as well. With tools that
use a standard format like tar, we're pretty much safe.
Blather, blather, blather. It's Friday.
Kelly J. Lipp
Storage Solutions Specialists, Inc.
PO Box 51313
Colorado Springs CO 80949-1313
(719) 531-5926
Fax: (240) 539-7175
Email: [EMAIL PROTECTED] or [EMAIL PROTECTED]
www.storsol.com
www.storserver.com
-----Original Message-----
From: Dmochowski, Ray [mailto:[EMAIL PROTECTED]]
Sent: Friday, April 06, 2001 9:25 AM
To: '[EMAIL PROTECTED]'
Subject: RE: long-term archive and retrieve
Kelly ...
In your white papers you wrote:
"When archiving data it is imperative to consider the format of
the
archived data. If the data is in a database, saving the entire
database assumes that same database application will be
available
when the archived data is required. In many instances, this will
not
be the case. Archived data, therefore, should be stored in a
format
easily imported into future applications that will use the data,
such as simple delimited ASCII text."
I've been in the IT business for more than 30 years and can appreciate
exactly what you're saying .....
In the regulatory world of the FDA, however, their "Guidance for Industry"
document (copy attached) states:
"FDA expects to be able to reconstruct a study. This applies not
only to the
data, but also how the data were obtained or managed. Therefore, all
versions of application software, operating systems, and software
development tools involved in processing of data or records should
be
available as long as data or records associated with these versions
are
required to be retained. "
I don't think I'm alone in having difficulty reconciling this FDA
"regulation"
with your ASCII text approach, particularly when dealing with complex
software built on the relational database model ---
the content might be saved in ASCII, but I don't believe the interaction of
the data elements and the structures (i.e., the "context") can be imported
into another application and easily massaged...
I'm not asking that you "modify" your ASCII advice, but perhaps you have
some additional insights about archive and retrieve for those of us
in regulated industries where long-term retention is a real issue ...
Ray Dmochowski
Schering-Plough Research Institute
Kenilworth, NJ 07033, U.S.A.
(908) 740-3261
[EMAIL PROTECTED]
-----Original Message-----
From: Kelly J. Lipp [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, April 04, 2001 4:28 PM
To: [EMAIL PROTECTED]
Subject: Re: long-term archive and retrieve
The most important issue to my way of thinking is the format with which you
archive. I believe that it makes no sense to archive data in its native
format. For instance, in the case of a database, archiving the database
itself, that is the binary images, makes no sense. How will you read that
data 2, 5, 7, 10 years from now? You won't that's how. I advocate
exporting the data to some textual format, perhaps CSV so the data can be
easily imported into some application and massaged.
Second issue is to only archive that which you are required to archive.
Most folks simply archive everything hoping that will ensure they have
something. Unfortunately when that is done it is likely you will have
archived something you distinctly did not want to have lying around.
There is a white paper I wrote a number of years ago that appears to be
relevant again:
http://www.storsol.com/cfusion/template.cfm?page1=wp_whyaisa&page2=blank_men
u
A number of other papers are at:
http://www.storsol.com/cfusion/template.cfm?page1=whitepapers&page2=blank_me
nu
Kelly J. Lipp
Storage Solutions Specialists, Inc.
PO Box 51313
Colorado Springs CO 80949-1313
(719) 531-5926
Fax: (240) 539-7175
Email: [EMAIL PROTECTED] or [EMAIL PROTECTED]
www.storsol.com
www.storserver.com
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED]]On Behalf Of
Dmochowski, Ray
Sent: Wednesday, April 04, 2001 10:18 AM
To: [EMAIL PROTECTED]
Subject: long-term archive and retrieve
Hi, *SMers
Does anyone have any experiences, best practices, etc.
they'd like to share about long-term retention (archiving) of
vital records. What to do to support expeditious retrieve?
If you can point me to any references or URLs that would
also be greatly appreciated.
Ray Dmochowski
Schering-Plough Research Institute
Kenilworth, NJ 07033, U.S.A.
(908) 740-3261
[EMAIL PROTECTED]
This E-mail and any files transmitted with it may contain information that
is confidential and privileged. This material is intended solely for the
use of the individual(s) or entity to whom it is addressed.
Opinions and conclusions contained in this message shall be understood as
non-binding and neither given nor endorsed by Schering-Plough Research
Institute.
If you believe you have received this email in error, please notify the
sender.
***************************************************************
This electronic message, including its attachments, is confidential and
proprietary and is solely for the intended recipient. If you are not the
intended recipient, this message was sent to you in error and you are hereby
advised that any review, disclosure, copying, distribution or use of this
message or any of the information included in this message by you is
unauthorized and strictly prohibited. If you have received this electronic
transmission in error, please immediately notify the sender by reply to this
message and permanently delete all copies of this message and its
attachments in your possession. Thank you.
***************************************************************
This electronic message, including its attachments, is confidential and
proprietary and is solely for the intended recipient. If you are not the
intended recipient, this message was sent to you in error and you are hereby
advised that any review, disclosure, copying, distribution or use of this
message or any of the information included in this message by you is
unauthorized and strictly prohibited. If you have received this electronic
transmission in error, please immediately notify the sender by reply to this
message and permanently delete all copies of this message and its
attachments in your possession. Thank you.
