1. IMPLEMENTING AN ELECTRONIC RECORDS MANAGEMENT PROGRAM
Philip C. Bantin
Indiana University Archivist
IU Electronic Records Program Website:

2. Outline of Presentation
3 Primary Objectives in Starting an Electronic Records Management Program
Objective 1: Define a Recordkeeping System
Activity: Develop Requirements for an Electronic Records Management System (ERMS)

3. Outline of Presentation
Objective 2: Evaluate Existing Data and Information Systems as Recordkeeping Systems
Activity: Analyze On-Line Transaction Processing (OLTP) Systems, Decision Support Systems (DSS) , and Electronic Document Management Systems (EDMS)
Activity: Articulate why these systems do NOT Meet the Requirements of a Recordkeeping System
Activity: Specify how the functionality of these systems needs to be augmented

4. Outline of Presentation
Objective 3: Define the nature of a record – Articulate what constitutes Complete, Authentic and Reliable Records
Activity: Develop Metadata Specifications
Activity: Define the levels at which this metadata will be applied

5. RECORDKEEPING REQUIREMENTS
Our goal is tell system designers what types of functionality need to be created or designed into the system.
Our goal is not necessarily to tell system designers how to translate these requirements into automated solutions.
However, our requirements must eventually include enough specificity to achieved desired results.

6. RECORDKEEPING REQUIREMENTS
Requirements are not much different than what we would like to see in an ideal paper recordkeeping system
Differences: 1) Requires in many cases that the requirements be automated and executable by the system;
2) Reflects the fact we can do a better job documenting recordkeeping in an automated environment

7. Compliance
The system must manage and control electronic records according to the standards for compliance and the requirements for legal admissibility and security, and must be capable of demonstrating this compliance.

8. Record Capture The term capture represents the processes of:
Registering a record – Unique ID, time and date when record entered system
Assigning classification metadata to record(s)
Adding further metadata to record(s), and retaining them in a tightly bound relationship
Storing record(s) in the ERMS.

9. Record Capture
It is recommended that, whenever possible, the capture function be designed into electronic systems so that the capture of records is concurrent with the automatic creation of records.

10. Record Capture Record Capture: Various Strategies
1) Applications that include BUSINESS PROCESS ENGINES
2) Applications that include WORKFLOW ENGINES
3) RECORDS MANAGEMENT APPLICATIONS (RMA)

11. Business Process Models
Primary Advantage:
Models clearly identify all activities within a process and consequently identify all records and the relationships between records and processes
It is a complete representation of the business process and of the various inputs and outputs generated by the process

12. Business Process Models
Primary Disadvantage
These models are not often designed into the system - automated business process engines are not the norm in North America
Good Examples of automated business process engines are the European Registry Systems

13. WORKFLOW MODELS Advantages: 1) Commonly used
2) Coming back into fashion with an emphasis on life cycle management
3) Often Automated

14. WORKFLOW MODELS Disadvantages
1) Primarily a Routing mechanism and thus:
a) not all records that are created go through workflow process
b) routing process may not identify all activities, all inputs and outputs within a given process; consequently some records within the process may not be identified and captured

15. Classification Scheme
Classification is the systematic identification and arrangement of records into categories according to logically structured conventions, methods, and procedural rules represented in a classification scheme.
The system must support and be compatible with the organization’s or the application’s classification scheme.
The system must automatically assign appropriate classification metadata to records and files and to classes within the classification scheme at the point of creation and capture.

16. Classification Scheme
The benefits of a good classification scheme are:
1) providing linkages between individual records;
2) assisting in the retrieval of all records related to a particular activity or function;
3) determining appropriate retention periods for classes of records;
4) determining security protection appropriate for classes of records;
5) allocating user permissions for access to or action on particular groups of records;
6) distributing responsibility for management of particular classes of records.

17. Classification Scheme
There are many types of classification schemes, but the one I recommended is a scheme based an articulation of the functions and transactions of the organization derived from the analysis of business processes.
The business classification scheme represents and describes functions, business processes, transactions or other elements, and shows their relationships.

18. Authenticity
To be authentic in archives and records management, a record must be genuine, or be “what it claims to be.”
In order to trust that a record is authentic, the user must be assured that the system:
Maintains inviolate records that are protected from accidental or unauthorized alteration and from deletion while the record still has value.

19. Audit Trails
A system audit trail is a record that tracks operations performed on the system. In essence, the audit trail documents the activities performed on records and their metadata from creation to disposal.
The audit trail typically documents the activities of creation, migration and other preservation activities, transfers or the movement of records, modification, deletion, defining access, and usage history.

20. Audit Trails The system must automatically capture the audit trail.
The audit trail data must be unalterable.
 The audit trail must be logically linked to the records they document, so that users can review audit information when they retrieve records.

21. Metadata
In the context of archives and records management, metadata is structured or semi-structured information that documents the creation, management and use of records through time and across domains.
Recordkeeping metadata can identify, authenticate and contextualize records and the people, processes and systems that create, manage and use them.

22. Metadata
The system must be capable of extracting metadata elements automatically from records when they are captured.
The system must permit metadata values to be retrieved and captured from lookup tables or from calls to other software applications.
The system must allow creators of records to enter manually pertinent record metadata that cannot be captured automatically.

23. Security and Control
The system must allow only authorized personnel to create, capture, update or purge records, metadata associated with records, files of records, classes in classification schemes, and retention schedules.
The system must control access to the records according to well-defined criteria.

24. Retention and Disposition
The system must include an automated, schedule-driven disposition management plan.
The system must provide for the automated retention of records with long-term value in accordance with authorized and approved record retention schedules.
The system must provide for the automated destruction of records in accordance with authorized and approved records retention schedules.

25. Preservation Strategies, Backups and Recovery
The system must incorporate a strategy or plan for backing up and preserving records.
The system must ensure that records, components of records, audit trails, metadata, links to metadata or to files, and classification schemes can be converted or migrated to new system hardware, software and storage media without loss of vital information.

26. Access and Use
The system must ensure access to and use of business records for current business and future research needs.
The system must ensure that all components of a record or file, including contents, relevant metadata, notes, attachments, etc., can be accessed, retrieved and rendered as a discrete unit or group and in a single retrieval process.

27. Documentation
All system policies and procedures must be defined and documented. This documentation helps to ensure continuing access to records within the system, and can be used to help prove the authenticity of a record.

28. MoReq
The IU Requirements are modeled to a large degree on the “Model Requirements for the Management of Electronic Records” (MoReq) commissioned by the IDA Programme of the European Commission.

29. Systems Design Systems Development Lifecycle
System concept: purpose, goals, scope
Analysis: user/functional requirements
Design
data design: what information?
software design: processed how?
interface design: user interaction?
Coding and testing: execute & evaluate
Key issue: Systems do (only) what they’re designed to – purpose, goals, scope, requirements.

30. Data and Information Systems
On-Line Transaction Processing (OLTP) Systems
Data-oriented
Automate basic business processes
Decision Support Systems (DSS)
Management Information Systems (MIS)
Data Warehouses
Electronic Document Management Systems (EDMS)

31. On-Line Transaction Processing (OLTP) Systems
The most basic business system and the heart of most organizations
TPS is a computerized system that performs and records the daily routine transactions necessary to the conduct of business
Primary goal is to automate computing intensive business transactions, such as those undertaken in the financial and human resource functional areas

32. TRANSACTION PROCESSING SYSTEMS
Inputs=transaction data like financial information, human resource data
Processing=sorting, listing, updating, merging
Outputs=bills, paychecks, orders, detailed lists and reports

33. DATA WAREHOUSE
Unlike operational databases that are set up to handle transactions and that are kept current as of the last transaction or update, data warehouses are analytical, subject oriented and are structured to aggregate transactions as a snapshot in time.

34. DATA WAREHOUSES - PRIMARY CHARACTERISTICS
Separate from the Operational systems and populated by data from these systems
Available entirely for the task of making information available to users
Time-stamped and associated with defined periods of time
Subject Oriented as defined by the customer
Accessible to users who have limited knowledge of computer systems

35. Electronic Document Management Systems (EDMS)
EDMS: Primary purpose is to support day-to-day use of documents for ongoing business; major emphasis is on managing content
EDMS functionality typically includes: indexing of documents, storage management, version control, integration with desktop applications, and retrieval tools to access the documents

36. Data and Information Systems as Recordkeeping Systems
Data and Information Systems have some of the same functionality as recordkeeping systems, particularly in the areas of security and access and use.
However, on the whole, data and information systems are poor recordkeeping systems.
WHY?

37. Data and Information Systems may not routinely capture all records of a business process
OLTP systems are primarily concerned with providing an organizational resource to current data that will support on-going business needs.
In OLTP systems what is often retained is only the final record of a process; transition documents may not be captured.
Historical data on business processes, if kept at all, is usually incomplete or summarized.
Decision Support Systems are largely focused on transforming data into reports and other information packages designed to assist decision-making; they are not designed to capture records

38. Data and Information Systems may not systematically preserve immutable records
OLTP are dynamic, volatile systems, in a state of continual change; databases typically maintain only the current value for any given data element.
“Snapshots" or back-ups of a database are useful, but they may not capture all the data values needed to reconstruct a specific record.
Consequently, once a virtual view of a document is erased from the screen, it may or may not be possible to recreate the record exactly as it originally appeared.

39. Data and Information Systems may not systematically preserve immutable records
While EDMS do a better job of preserving and managing original documents and versions of records, these systems typically have less control over modification and deletion than would be permitted in a recordkeeping system.

40. Data and Information Systems may not systematically preserve complete, fully documented records
All of the most popular information systems fail to meet the requirement for capturing and preserving fully documented digital objects. More specifically, two major problems exist:
1) Metadata that was never created
2) Metadata that exists but is not linked to or part of the record.

41. Data and information systems may not provide for the long-term preservation of records
In most institutions the typical strategy for protecting data is to generate daily back-ups of all system data. While the back-up strategy is a necessary and useful activity, it must be regarded more as a disaster preparedness plan than as a preservation strategy.
Unlike a true preservation strategy, the back-up solution does not deal with the root causes of the deterioration and obsolescence of digital records: hardware obsolescence, storage medium deterioration, and the biggest problem of all, software dependence.

42. Data and Information Systems may not provide for the systematic retention and disposition of records
In many systems, the primary disposition strategy consists of copying data, and moving this data to near-line and eventually off-line storage status. In this strategy, no appraisal decisions are made on what to keep or destroy and why.
Some EDMS may include retention controls, but the majority of these systems do not include the rigorous controls for disposing and retaining records that must be a required feature of any recordkeeping system.

43. Data and Information Systems As Recordkeeping Systems
In short, most data and information systems are not recordkeeping systems because they do not:
1) Routinely capture records – Evidence of Business Transactions
2) Manage information or records over the entire life cycle

44. Defining a Record WHAT IS A RECORD?
A specific type of information produced by a business event
Evidence of business transactions
Evidence is metadata documenting the context of creation and defining the content and structure of the record

45. Defining a Record
The essence of a record, and what distinguishes it from other types of digital objects, is the existence of critical metadata defining content, context and structure
Our job is to identify this Recordkeeping Metadata and define at what level it will be applied

46. Metadata – Levels of Application
To be successful, a metadata strategy must meet 2 requirements:
1) Some, even most, of the metadata must be automatically captured by the system
2) Some of the metadata must be automatically assigned to many records within a classification system

47. Metadata – Levels of Application
Metadata can be applied at 3 Levels:
1) Class or Record Series Level
2) File Level
3) Individual Record Level

48. Metadata elements that must be present with each record or file or class of records
Unique Identifier
Name Given to the Record, File or Class that is Representative Of Its Contents, Form or Function
Description of Content or Function
Person or Post Responsible for Maintaining the Classification Scheme and the Class and File Structure

49. Metadata elements that must be present with each record or file or class of records
Audit Trail Metadata on Activities Performed On Individual Records or on Classes or Files of Records
Activities include: Creation, Capture and Entry into Recordkeeping System, Modification, Deletion, Disposition and Retention, Preservation Activities, Access and Use.
For each distinct activity, metadata will be created that documents: 1) Date of Activity; 2) Nature of Activity; 3) Person Responsible for Activity

50. Metadata elements that must be present with each record or file or class of records
Context of Creation and Transmission
Metadata documenting:
1) Originator of the record;
2) Receiver of the record;
3) Date when record was transmitted;
4) Date when record was received;
5) Date when the action or event documented by the record took place

51. Metadata elements that must be present with each record or file or class of records
Relationships to other Records or to Files or Classes of Records within the Classification Scheme
Metadata that identifies:
1) related records and files or classes of records;
2) which record is authoritative, when multiple copies exist;
3) attachments or notes appended to the record;
4) aggregation level at which the record is being controlled and managed.

52. Metadata elements that must be present with each record or file or class of records
Record Category – If Necessary
If the classification scheme is not based upon business functions and processes, then metadata must be created that identifies the business transaction that directly generated the record.

53. Metadata elements that must be present with each record or file or class of records
Relationship to Business Functions and Processes - If Necessary
If the classification scheme is not based upon business functions and processes, then metadata must be created that identifies:
1) other records created by the same business process;
2) the business functions and sub-functions documented by the record or files.

54. Metadata elements that may be applied at various levels, but often at the file or class level
Depending on the specific application, the business environment, the business function and processes that produced the records, and assessment of needs and risks, some metadata may be applied at the class (series), file or record level.
In many instances, some metadata specifications can be applied at higher levels than the record, often times at the class level or even for many classes of records.

55. Metadata elements that may be applied at various levels, but often at the file or class level
Access and Use Metadata:
Metadata that:
1) depicts laws, policies, or best practices that govern or restrict access or use;
2) identifies which users or groups of users have access;
3) defines the terms of access or use, including restrictions such as those related to intellectual property rights.

56. Metadata elements that may be applied at various levels, but often at the file or class level
Disposition Metadata:
Metadata that identifies:
1) laws, policies or best practices that govern disposition;
2) the retention period;
3) the destruction date;
4) current storage system or physical location;
5) person or post responsible for maintaining the record disposition schedules and for managing and monitoring the disposition and retention process.

57. Metadata elements that may be applied at various levels, but often at the file or class level
Structural Metadata:
Metadata that identifies:
1) the data format or the logical or file format of the data (e.g., ASCII, UNICODE, SGML, TIFF);
2) the media format or the type of data representation and file types;
3) any hardware and software that will effect opening and rendering data;
4) the method of compression, if any;
5) the encryption algorithms, if any.

58. Metadata elements that may be applied at various levels, but often at the file or class level
Preservation History Metadata
Metadata that identifies:
1) what specific preservation strategies were performed (e.g. ,scanned, medium refreshed, converted);
2) the impact of the preservation process on form, content, accessibility, and use;
3) the physical storage medium;
4) person or post responsible for managing and monitoring the preservation process.