creating and maintaining proper systems for electronic record keeping massachusetts digital...
TRANSCRIPT
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) [email protected]