1. Creating and Maintaining Proper Systems for Electronic Record Keeping
Massachusetts Digital Government Summit
Claudia Boldman, Director of Policy and Architecture
Information Technology Division
September 24, 2004
So now that we have the proper legal foundation, we can eliminate all paper and go “electronic”, right?
Not so fast….
I’m going to address the business and technical context for creating and maintaining proper electronic records

2. Agenda From Paper to Electronic: Important Considerations
Identification and Capture of Electronic Records
Management and Disposition of Electronic Records
This presentation is based on the work done by a workgroup, which I co-chaired, of the NECCC and presented at their national conference in December of Major contributors included Mark LaVigne and Alan Kowlowitz from New York.
An associated white paper can be accessed at
The intent of the white paper and this presentation is to provide a flexible framework that can be used to incorporate records management issues in the planning and development of transaction systems

3. Identifying the Risks Risks to the System Risks to the Transactions
Security
Technology
Risks to the Transactions
Relationship between the parties
Value of the transaction
Considering and assessing the risks of going from paper to electronic will help determine the amount of resources that should be devoted to mitigating them. A cost/benefit analysis can then help determine whether the transition from paper to electronic should be made.
Comprehensive approach to identifying the risks:
The integrity and security of records will be affected by the risks to the system, the risks to the transactions and the risks to the records themselves
Risks to the System
Security – the risk of intrusion
The level of risk depends on the value of the transaction to the potential attacker and whether the transaction is regular and predictable as opposed to intermittent or one-time
Technology – the impacts of system failure or lack of resources to maintain systems over time
Higher risk when we’re talking about proprietary, highly complex systems or cutting-edge systems
Lower risk when systems are based on open standards or generally accepted technologies
Risk to the Transactions
The relationship between the parties (ongoing vs. one-time)
The value of the transaction (high value more risky)
Risk to the Records
Evidentiary value of the record (the likely need for accessible, persuasive information regarding the transaction at a later point).
See whitepaper for examples
Risks to the Records
Evidentiary value

4. Mitigating the Risks Cost/Benefit Analysis Examples of Costs:
Technology-related costs
Records-related costs
Examples of Costs:
Design, development, implementation and maintenance of new system
Proper migration of records from old to new system
Ongoing maintenance, migration and conservation of records
Training of staff and end-users
Re-training of staff that may be reassigned to other duties due to automation
New management, administrative and/or process controls required by the electronic transaction
Potential damage to reputation, credibility and public trust

5. Mitigating the Risks Examples of Benefits:
Increased speed of the transaction
Incrased partner participation and customer satisfaction
Improved record keeping efficiency and data anlaysis opportunities
Increased employee productivity and improved quality of final product
Greater information benefits to the public
Improved security and reduction in fraud
Improved security for highly sensitive information
Improvement in reputation, credibility and public trust

6. Mitigating the Risks Focus on ensuring Authenticity Integrity Security
Accessibility
Once the decision is made to invest in an electronic transaction system how do you develop one that will properly create and maintain electronic records?

7. Definition of “System”
What is a system for electronic record keeping?
Our focus: electronic transaction systems and the electronic records they create
Many different types of systems
Systems designed specifically for the management of electronic records:
Imaging systems
Record Management Applications (RMA)
Document management systems
Systems designed to automate business transactions
Their primary purpose is not the management of electronic records
The creation and management of e-records is a necessary by-product
These are the systems that are the subject of my talk today

8. Lifecycles System Development Lifecycle (SDLC): Record Lifecycle: Plan
Design
Develop
Operate
Maintain
Enhance
Retire
Record Lifecycle:
All systems have a development lifecycle (7 major phases):
Plan
Design
Develop
Operate
Maintain
Enhance
Retire
A record also has a lifecycle (three major phases):
Create
Maintain and Use (during this phase a record may be inactive but still needs to be retained)
Dispose (records are either destroyed or preserved)
Create
Maintain and Use
Dispose

9. Gap Number One Disconnects between SDLC and Record Lifecylce
Beginning:
Plan
Design
Develop
These lifecycles don’t exactly mirror each other
So we must address the resulting gaps
Gap number one has to do with the disconnect between the two lifecycles:
Records issues are not always considered at the very beginning of the system development lifecycle –
Plan
Design
Develop
Nor are they always considered in relation to the very end of the system lifecycle:
Enhance
Retire
Planning for the data the system will capture and manage is not the same as planning for the electronic records that will be created as a result of the business transaction that is being automated
End:
Enhance
Retire

10. Gap Number Two Duration of the lifecycles System: Record: 3 Years
Gap number 2 occurs because the lifecycles are of different duration:
Average system may last 3 years
The lifecycle of a record ranges from very short to “forever”
So how do we start bridging the gaps?
Record:
10 Years

11. Bridging the Gaps
Interdisciplinary approach to planning and designing system
Policy and program staff
IT professionals
Legal staff
Records management and/or archives staff
An interdisciplinary approach to planning and designing the system is essential

12. Identification and Capture of Electronic Records

13. The assumptions Agencies are creating electronic records but…
They view records management as an isolated activity (someone else’s responsibility)
Systems do not sufficiently support business or evidentiary needs
Organizations are forced to maintain duplicative paper records
Records are created that are not accessible to the organization
Information vital to organizations and society is lost or remains in personal domains

14. The objectives
Integrate records management into the design and ongoing operation of e-government systems
Address records management in business process analysis and improvement processes

15. Electronic Records Management
Identify the records being created in the business process
Capture records
Maintain accessibility to records

16. System Requirements
Communicate to program and IT managers what systems must achieve to ensure e-records are:
created
maintained
preserved
To support operational, informational, and evidentiary needs

17. Definition of a Record The complete set of documentation
required to provide evidence of
a business transaction
Working definition that supplements the legal definition in UETA

18. What’s in a record? A record consists of:
Structure -- the appearance and arrangement of the record…paragraphs, fields, language
Content -- the substance of the record…words, numbers, images
Context -- the background information that enhances understanding…metadata, software

19. What records need to be captured
Laws, regulations, policies and professional practices that define a business process also determine the records that must be created
They define the records’
Management requirements
Access requirements
Content, structure, context

20. Identifying Records Requirements
Business Process Level
Capture/creation requirements (content, structure, and context)
Record Level
Access and maintenance requirements
Identification of complete record
How long should the record be retained
System Level
System management requirements

21. What is a business process?
One or more tasks that add value by transforming a set of inputs into a specified set of outputs (goods or services) for a customer by a combination of people, methods, and tools
A simple example is responding to a letter. A letter is received, a supervisor decides who to routed it to for a response, information collected for a response, a response is drafted, routed for review, and sent to the customer. In this case the product, like many government products, is an information product (a letter). However, such a product could have great value to the receiver.

22. Business Process Level
A business process focus
Essential to identify records requirements
When systems are designed, records requirements must be
Identified and incorporated into the system
Business process analysis can be used to
Improve the process during system design
Identify records and requirements

23. Business Process Level
Key questions to ask
What business process is the system a part of?
What is the purpose of this business process?
What tasks or transactions will this system automate?
What records are captured or created by the process?
Will it fulfill a legal, regulatory, or operational purpose?
What other records need to be imported to complete the transaction?

24. Business Process Level
For each answer to the above questions the following should be asked
What are the legal requirements for this process, activity, or record?
What are the business or regulatory guidelines driving this process, activity, or record?
What are the organizational policies for completing this process, activity, or record?
How do others complete this process, activity, or record?

25. Business Process Analysis Tool
Answer
Laws
(What are the legal requirements for this process, activity, or record?)
Regulations
(What are the business or regulatory guidelines driving this process, activity, or record?)
Agency policies or practices
(What are the organizational policies for completing this process, activity, or record?)
Generally accepted best practices
(How do others complete this process, activity, or record?)
What business process is this automated system a part of?
What is the purpose of this business process?
What tasks or transactions does this system automate or cover?
Are there any ‘when’ or ‘how’ requirements for the transaction?
What are the records captured or created in the process or transaction?
What other records need to be imported to fulfill the transaction?

26. What’s in a record? A record consists of: Structure Content Context
Now that you have gone through bpa, you will have some of these buckets filled out? What other information do you need?

27. Record Level -- Internal access
Which departments or agencies need access to the record?
What components of the record do they need to see?
What are the most efficient/effective ways for providing access to those records?

28. Record Level - External access
How will the record be reproduced to meet the needs of external users?
If these records are covered by FOIL:
For those components of the record that the Agency wishes to restrict access to, what category of exemption does the component fall under?

29. Capturing the Record For all defined business transactions
At the appropriate point in the business transaction
Import records related to business transactions created in other environments
Ensure records comply with requirements as far as content, structure, and context of creation

30. System Requirements
Communicate to program and IT managers what systems must achieve to ensure e-records are:
created
maintained
preserved
To support operational, informational, and evidentiary needs

31. Management and Disposition of Electronic Records

32. Records Value Identifying record’s value can help determine:
Resources devoted to:
Incorporating requirements into system design
Maintaining records
Retention periods that will satisfy agency needs

33. National Archives and Records Administration’s Model
Administrative Value
Conduct the agency's current business
Communicate and document decisions
Contain information necessary to conduct business
Fiscal Value
Document financial transactions and obligations
Budget, voucher or expenditure, and accounting records
State fiscal control agencies often prescribe the form and content of fiscal records

34. National Archives and Records Administration’s Model
Legal Value
Support rights based on statute or regulation
Factors to consider: statutes of limitation, the potential for fraud, and litigation trends
Archival Value
Agency’s corporate memory (3-5% of records)
Document policies, programs, and rights
Captures information that defines the state’s character

35. E-records as a System Design and Management Consideration
Resources expended on e-records issued should be related to:
Value of the records
Risks if the records authenticity, integrity, security, and accessibility are compromised
Minimal considerations
Records created or received for all defined business transactions
Records minimally comply with legal and business requirements (content, structure, and context)

36. Maintenance: System Management
E-records’ authenticity and reliability are contingent on the system’s trustworthiness
Systems that produce e-records must
Perform in an accurate, reliable, and consistent manner
Limit access to authorized individuals
Maintain integrity of e-records as captured or created
Retain e-records in an accessible form for their retention periods

37. Maintenance: System Management
Perform in an accurate, reliable, & consistent manner
Management policies and procedures
Assign system roles and responsibilities
Problem resolution procedures
System performance tests
Audit trails of system activity
User training and support

38. Maintenance: System Management
Limit access to authorized individuals
System security policy and program
Physical and environmental security controls
Identification and authentication procedures
Logical and external access control

39. Maintenance: System Management
Maintain integrity of e-records as captured or created
E-records management policy
Controlled storage or filing systems
Contingency plan
Controls for accuracy and timeliness of I/O
Media controls
Routine backups

40. Maintenance: System Management
Retain e-records in an accessible form for their retention periods
Retention = retention of access
Determine retention period when system is designed
Use records retention and disposition schedules

41. Maintenance: Records Retention Solutions
Records retained for short periods (3-6 years) could be maintained in the originating system
Records retained for periods that exceed the creating system’s life must be migrated or otherwise retained
Solutions should also:
Maintain original functionality to the degree necessary
Preserve context & links to e-record’s components
Require the least human intervention
Be independent of media

42. End of the Line: Records Disposition
Destruction
Must comply with state laws and procedures
All copies of the record should destroyed
Coordinated with backup and storage procedures
Systems should ensure that destroyed records are not recoverable

43. End of the Line: Records Disposition
Preservation of long-term / archival records
No easy technical solutions or standards
Number of approaches
Migration
Standard formats
Encapsulation
Emulation
Conversion

44. End of the Line: Records Disposition
Migration: most commonly cited solution
E-records are moved from existing system to a new one (including needed metadata)
Complex and requires planning
Implemented incrementally with system upgrades 
Storing e-records in standard formats: relational databases, ASCII, SGML, etc.
Should be included in system’s design
Reduces rate of technological obsolescence and the need for migration

45. End of the Line: Records Disposition
Encapsulation: capture e-record and metadata as a portable digital object (being investigated)
Combines system migration with standard formats
Emulation: enables new technology to act like obsolete technology (being investigated)
E-records remain in original file formats, technology changes
Conversion to other media (e.g. computer-output microfilm (COM)
Only viable when required metadata can be captured, records not needed in electronic form and formats make conversion feasible

46. Conclusion
Carefully consider risks and cost/benefit of going from paper to electronic
Electronic record keeping issues should not be an afterthought
Incorporate at earliest stages of system design
System planning and design teams should include multiple disciplines
Policy and program, IT, legal, records management/archives
System requirements such as security should reflect results of risk assessment and cost/benefit analysis
One size does not fit all
Map records lifecycle over system lifecycle
Identify record keeping functionality the system will be expected to handle and for how long
Plan for what happens to records once system is retired

47. Contact Information
Claudia Boldman
Director of Policy and Architecture
Information Technology Division
(617)