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

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 2002. Major contributors included Mark LaVigne and Alan Kowlowitz from New York. An associated white paper can be accessed at http://ec3.org/Downloads/2002/creating_systems.pdf. 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

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

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

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 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?

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

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

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

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

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

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 Working definition that supplements the legal definition in UETA

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 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.

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

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?

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 Now that you have gone through bpa, you will have some of these buckets filled out? What other information do you need?

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?

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?

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 Boldman Director of Policy and Architecture Information Technology Division (617) 626-4422 Claudia.Boldman@state.ma.us