Creating and Maintaining Proper Systems for Electronic Record Keeping

Massachusetts Digital Government SummitClaudia Boldman, Director of Policy and ArchitectureInformation Technology DivisionSeptember 24, 2004

Agenda From Paper to Electronic:

Important Considerations Identification and Capture of

Electronic Records Management and Disposition of

Electronic Records

Identifying the Risks Risks to the System

Security Technology

Risks to the Transactions Relationship between the parties Value of the transaction

Risks to the Records Evidentiary value

Mitigating the Risks Cost/Benefit Analysis

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

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

Mitigating the Risks Focus on ensuring

Authenticity Integrity Security Accessibility

Definition of “System” What is a system for electronic

record keeping? Our focus: electronic transaction

systems and the electronic records they create

LifecyclesSystem Development Lifecycle (SDLC):

Plan Design DevelopOperateMaintainEnhance Retire

Record Lifecycle:

Create Maintain and Use Dispose

Gap Number One Disconnects between SDLC and

Record Lifecylce

Beginning:

End:

Plan Design Develop

Enhance Retire

Gap Number Two Duration of the lifecycles

System:

Record:

3 Years

10 Years

Bridging the Gaps Interdisciplinary approach to

planning and designing system Policy and program staff IT professionals Legal staff Records management and/or archives

staff

Identification and Capture of Electronic Records

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

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

Electronic Records Management

Identify the records being created in the business process

Capture records Maintain accessibility to records

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

Definition of a Record

The complete set of documentation

required to provide evidence of a business transaction

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

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

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

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

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

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?

Business Process Level

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?

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?

 

         

What’s in a record?

A record consists of: Structure Content Context

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?

Record Level -- Internal 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?

Record Level - External access

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

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

Management and Disposition of Electronic Records

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

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

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

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)

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

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

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

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

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

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

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

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

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

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

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

Contact Information

Claudia BoldmanDirector of Policy and ArchitectureInformation Technology Division(617) 626-4422Claudia.Boldman@state.ma.us