Electronic Recordkeeping

Automating Electronic Records Management in a Transactional Environment: The Philadelphia Story

by Mark D. Giguere
The popular and timely notion of reinventing business processes has caught hold at all levels of government. Indeed, many federal, state and municipal governmental entities are currently engaged in re-examining their ways of doing business. In the city of Philadelphia, as elsewhere, the culmination of many of these efforts is the re-design of information technology (IT) systems to support re-defined activities.

When information system designers and program managers discuss the functions of a new system, they rarely include records management capabilities in that conversation. In the paper world, the fact that few people thought about records management issues at the time of the creation of records was not as serious a problem as it is in the electronic world. Records managers and archivists are faced with a multitude of problems trying to preserve records in electronic form. But many records managers understand that an organization in the throes of re-engineering is a perfect candidate for the incorporation of records management functionality into the re-design and/or procurement of information systems that support re-defined business activities.

In 1991 the National Historical Publications and Records Commission (NHPRC) supported a national meeting to devise an electronic records research agenda. Since that meeting, the Commission has funded over 30 projects that have examined a set of questions that need to be answered for the profession in this developing area. The city of Philadelphia project is one of the most technically ambitious of these efforts.

In Philadelphia, the need is to jump start an electronic records program for the municipal Records Department at a time of development or redesign of over 100 significant information technology systems outlined in the city's strategic IT plan. This massive city-wide information systems effort has caused the NHPRC project to concentrate on intervening in the redesign of specific, small- and medium-sized transactional information technology systems. This article outlines the approach taken in this initiative jointly sponsored by the city of Philadelphia's Records Department and the Mayor's Office of Information Services, the alternatives to such an approach, and the risks associated with our proposed course of action.

Principles Tempered by Pragmatism

Archivists and records managers recognize that information and records are not synonymous concepts, and our understanding of the differences helps us to articulate the distinctions between automated information systems and electronic record keeping systems. In fact, there are many contentious issues associated with the notion of transforming an information system, whose primary function is to facilitate the update and delivery of electronic information that supports business processes, into a system capable of generating records from that electronic information.

One of these issues is determining who has stewardship of the electronic record and what additional contextual information must be bound to the information content of an electronic transaction for record keeping purposes. Another matter of concern is whether adding the record keeping functionality to each system individually is better than an enterprise-wide solution, such as an integrated paper and electronic system.

The activities pursued in Philadelphia thus far sidestep many of these issues because of the prototype nature of these efforts and the need to demonstrate to city agencies an agreeable means of incorporating records management functions into system redesign and procurement. By the conclusion of the final phase of the project (November 1997), we hope to have achieved a workable solution and will report to the larger, national records management community the successes and shortcomings of our approach.

The Various Approaches

Recent judicial decisions have required that certain information be preserved with electronic files to make them meaningful. The best known of these decisions was handed down in Armstrong v. Executive Office of the President, commonly referred to as the PROFS case, which established that additional contextual information be bound and preserved with the electronic information content of a transaction (i.e., e-mail message) in order to achieve record status. Examples of additional information that could be added include who created an electronic record, when the record was created, who received it, if and how it was altered, which version was it, what is its electronic structure, etc. There has been much research activity in recent years into precisely what additional information is needed and the best methods by which it can be preserved so that future users can access electronic records many decades or even centuries from now.

The University of Pittsburgh Research Project

One such research project took place at the University of Pittsburgh. This three-year, NHPRC-funded effort established a set of functional requirements for electronic record keeping. The Pittsburgh project focuses on records as evidence of business activities for the purpose of accountability.

Results of this effort have advanced one possible set of contextual information necessary to describe an electronic record. It includes hardware- and software-related information that provides for the long-term access to the electronic record, audit trail information that denotes subsequent use and inviolability of the electronic record, and retention and disposition information that can be used to automate the subsequent management of the electronic record. All of this contextual information is bound with the information content of the record and packaged into some uniform electronic record data structure which is thought to be capable of acting as evidence of an electronically accomplished business transaction. The last point is significant, in that the efficacy of their recommended body of additional contextual information has yet to be legally tested. And indeed, there may well be other facets to an electronic record's required contextual information beyond the evidential focus achieved by the Pittsburgh research.

This contextual-information-binding alternative that is a natural by-product of the Pittsburgh functional requirements model is known as a record-description-record (RDR) approach and was the basis for the short-lived Federal Information Processing Standards (FIPS) effort at the federal level. The hallmark of this approach, however, is simple:

In this way, the electronic record is self-contained, self-sufficient, inviolable and hopefully acceptable as evidence for lawyers and judges, auditors, journalists and historians - in short, it would satisfy all potential uses of records, not just for archival purposes.

Similarities to the OOD Approach

The RDR approach bears some similarity to an object-oriented (OOD) approach to software design, in which electronic record keeping software would be organized as a collection of discrete objects that incorporate both data structure and behavior. The most familiar example of object-oriented software design is the Windows operating system's graphical user interface. A window is an object that possesses characteristic attributes (e.g., it has dimensions, it may be active or tiled, etc.) as well as having inherent behaviors that are programmed into it (e.g., it may be resized, maximized, minimized or closed). Clearly, each electronic record created in the RDR approach can conceptually be thought of as an object. The additional contextual information specified in the RDR approach becomes the attributes of the electronic record "object" data structure. What differentiates the RDR approach from the OOD paradigm is that RDR electronic records do not internalize any of the software procedures that would typically be associated with a record (e.g., disposition, migration, retrieval, access). Some system analysts would argue that incorporation of such records-related "behaviors" would be a natural extension of the RDR methodology. While the resultant self-containedness of the OOD approach would be desirable, this method would greatly inflate the "byte-wise" volume of the electronic record.

The University of British Columbia's Approach

Work at the University of British Columbia (UBC) at Vancouver has approached electronic records management from a more global and traditional systems analysis viewpoint. The project employs the science of diplomatics as a means of defining records management related "entities," namely archival fonds. The archival fonds identified in the UBC research could form the basis for a traditional systems development approach to building a records management information system. Traditional systems analysis is predicated on the credo that it is possible to build information systems that are capable of mimicking real-world activities as a series of "data flows."

Typical information systems primarily consist of various software modules that interact with or manipulate a database of information. When analysts build such a system, one primary concern is how to define the information bins contained in the database. The UBC-defined archival fonds could conceivably act as bins in such a records management information system's database.

Furthermore, the UBC research has preliminarily identified relationships between archival fonds that could easily be translated into data flows (i.e., transfers of pieces of information between the records management application's database bins).

On the basis of this discussion, it is clear that the scope of the UBC inquiry is much broader than that of the Pittsburgh research. An electronic records management application that is based on their analysis would clearly be an enterprise-wide application, given the amount of time and money necessary to conduct a traditional system analysis and development. In comparison to the RDR approach, much of the evidential acceptability of the electronic record in the traditional systems development approach is inherited from the integrity and inclusivity of the records management application. Obviously, this approach is predicated upon an overarching system that monitors the electronic record via database information recorded in the entity bins, as the electronic record moves from platform-to-platform or application-to-application.

Philadelphia's Approach and the Associated Risks

In Philadelphia, the Electronic Records Project has concentrated on the use of an RDR approach in facilitating the delivery of functioning, prototype systems within the time frame of federal funding in order to demonstrate to city agencies the relative ease of incorporating records management functionality at the system design stage. Specifically, Philadelphia's project has focused on two test case, transactional systems: a mid-sized human resource information system and a smaller adjudication tracking system. Each of these approaches represents an integration to some extent of both the RDR and OOD approaches to electronic records management. The human resource system will represent an attempt to incorporate automated records management functionality at the system design/procurement stage while the adjudication tracking system will involve a records management functionality retrofit. The latter is of particular importance for two reasons. First, we will be working closely with the municipal judiciary to establish an "evidentiary acceptable" body of contextual information to be bound to the electronic record. Second, because of the smaller nature of the adjudication tracking system, it will be the first system operating with the proposed automated records management functionality.

We have chosen the contextual-information-binding RDR record encapsulation approach as the primary means by which electronic records will be created. The application will, on the basis of a client-negotiated list of electronic record-generating transactions, gather the required contextual information from a variety of locations (e.g., operating system, application/platform interface, specifically coded system "traps"), reformat this information into a standardized data structure (initial discussions have focused on the use of a comma-delimited ASCII text file) and thus create an electronic record.

Fortunately, the reality of the situation in Philadelphia is that much of the agreed upon minimal set of additional contextual information necessary to accurately document an electronic transaction is naturally occurring in most applications. The only unique aspect of this approach is the realization that this information must be gathered at the time of an electronic transaction and subsequently bound and preserved with the electronic information content. An internal, independent software module will use the contextual information to automate subsequent records management functions (i.e., monitoring security and inalterability of as well as access to the electronic record, automating retention/disposition and delivering copies of the official electronic record if required for litigation discovery requests). It is anticipated that the software code for this records management oversight system will be reproduced in each system (re)design/procurement.

This oversight module embodies the inherent behaviors that would be built into an object-oriented design approach (e.g., create, dispose, move offline, retain, retrieve, report), but unlike typical OOD, the code that enables these functions is not contained within the record itself (the electronic record contains the instructions for these activities governed by the oversight module, in the form of the embedded additional contextual information contained within the record).

There are risks associated with this project, but given the prototype nature of these efforts, both the project staff and the Records Commissioner feel that these demonstrations will provide valuable data that will either validate or refute the RDR approach. One of these risks is the potential difficulty of incorporating contextual metadata into the myriad of applications capable of generating electronic records, as opposed to adding them to the more specific transactional electronic record-generating systems (this extension of the RDR application will be tested in Phase III). Another danger is that the needs of individual client agencies may require system modifications that could hamper the development of a city-wide records management application. Finally, the judicially untried nature of the body of contextual metadata may cause subsequent reformatting/augmentation of the extant body of electronic records generated by these two prototype applications. Nonetheless, these efforts will provide valuable information and insight, both locally to the Records Department, the Mayor's Office of Information Services and the city, and nationally and internationally to the larger records management community regarding the efficacy of this approach.


Mark Giguere is the NHPRC-funded electronic records manager for Philadelphia. He recently concluded an appointment as an adjunct assistant professor at Drexel University's College of Information Science and Technology, where he taught information system analysis and design. For more information about the Philadelphia Electronic Records Project, contact the author by phone at 215/686-2284, fax at 215/686-2273 or e-mail atmark.giguere@phila.gov or visit http://www.phila.gov/city/departments/erms/erm.html. This article is reprinted with permission from NARA's The Record.