| Comment Record|
Dr. Larry Leeth ||
2002-10-11 15:01:31 |
QAD, Inc. |
| Comments for FDA General |
1. General Comments
Section 22.214.171.124 - Electronic Record Integrity Attributes Should Be Preserved states:
“Where a migration, in effect, creates a new electronic record (by transforming the old electronic record) then, per section 11.10(e), the audit trail for the migrated electronic record would have to cover this creation.”
It would be most useful if the parenthetical expression “by transforming the old electronic record” could be clarified.
Is it the intended meaning that a new record is created only when some transformation of the ‘old electronic record’ occurs as part of the migration process?
Or does the act of migration itself create a new electronic record and therefore create a requirement to generate an audit trail entry?
A typical scenario in the migration of a database application to a later version involves the following cases:
1. Most database tables involve no transformation. The set of fields in the ‘old’ version are identical to the fields in the new version. Data from the ‘old’ version is exported to a ‘flat file’ format and then loaded into the database for the new version. If an audit trail entry were created when such a record were loaded to the new version, the before and after values of every field in the record would be identical.
2. The new version of the application involves changes to fields that were present in the previous version. These changes could consist of increasing the size of the field, or changing the format of the field (e.g. from an integer to a decimal format). Such changes can be effected by a conversion program executed after data has been transferred from the ‘old’ version’ to the ‘new’ version. These changes can be readily audit trailed.
3. The new version of the application may support additional fields that were not present in the previous version. Rather than simply creating a flat file of the record contents, additional content is generated for the flat file to reflect the additional fields supported by the new version.
For example, a simple ‘Parts’ table could consist of the fields:
· ‘description’, and
When a new version of the application involves no changes to this table, data exported to a flat file for conversion could look like this:
“location 100” “part123” “part 123 description” 100
If the new version of the application adds a “Site” field to the Parts file, the flat file could look like this if the new Site field will have no initial value:
“” “location 100” “part123” “part 123 description” 100
or like this, if a default initial value of “Site A” is established:
“Site A” “location 100” “part123” “part 123 description” 100
In the second case, when the record is loaded into the new version, an audit trail entry could be generated that reflects a ‘blank’ before value for Site and an after value of “Site A”. In the first case, an audit trail entry would contain ‘blank’ for both the before and after values.
Is it necessary to create audit trail entries in both cases, or only when new data (“Site A”) is being added to the record?
Another factor related to application version migration (conversion) is changes to the indices of database tables. For example, in the situation cited above, the index to the Parts table on the ‘old’ version would consist of ‘location’ + ‘part_number’. In the new version, the index would be ‘site’ + ‘location’ + ‘part_number’.
This creates additional issues/questions regarding audit trails and signature linking.
In the case of audit trails, each audit trail record contains fields comprising the index of the table containing the audited record. To maintain the ‘linkage’ between audit trail records and the records being audited, it would be necessary to transform each audit trail record to reflect any changes to a database index (such as the addition of index field ‘Site’). Each audit trail record pertaining to table Part would be transformed to add the “Site” field.
Does the guideline statement:
“An audit trail itself may undergo a transformation during a migration, but keep in mind that section 11.10(e) requires that the audit trail convey certain information, including information about the creation, modification, and/or deletion of the old electronic record.”
imply that such a transformation is acceptable, if not expected?
Is there any additional meaning to the ‘keep mind’ caveat, beyond not ‘loosing’ the specified information in the transformation process?
A similar situation exists with respect to signature linking, where signature components are associated with a ‘signed record’ via the use of database index values. If the database index changes, the signature data must also be updated to reflect the modified index.
This appears to a similar, albeit simpler, case to that described for updating signature links necessitated by technological changes.
Is this an accurate interpretation?