1

Proposed EDMS/ERMS APPLICATION STANDARDS a.k.a. ELECTRONIC DOCUMENT MANAGEMENT SYSTEM (EDMS)

ELECTRONIC RECORDS MANAGEMENT SYSTEM (ERMS)

Developed byThe State Records Center &

Archives, The State Library &

The EDMS Project Team

2

Agenda Executive Branch ECM Project

Overview Executive Summary

EDMS/ERMS Integration with ITEA SRCA Vision

EDMS/ERMS Standards & Guidelines Multiple Disciplines Interoperability and Metadata

Benefits of EDMS/ERMS Integration with ITEA

Next Steps

3

NM ECM Project Overview Three agencies, HSD, TRD & SRCA

submitted project requests for funding document & records management in 2003-2004 State CIO combined these requests into a

multi-agency project due to their obvious synergies

Multi-agency Executive Steering Committee (ESC) structure oversees the project

Both the AOC JID and the ITC require continuing communication between the Judicial and Executive Branch ECM Projects

4

Strategic Objectives Lower the Cost of Government Improve Service Delivery to Constituents Enterprise Model

Define an ECM strategy that supports all content types and formats over the entire life cycle

Centralized Electronic Records Repository Integrated approach for the capture, maintenance, storage,

access, disposition and preservation of electronic records Business Process Management

Content, documents and document management are inherent within Agency business processes. Reengineering the business processes in State Government is fundamental to implementing ECM

5

Tactical Objectives Two current tactical projects:

HSD Child Support Payments Capture and image payments and manage Child

Support paper documents MVD Citations

Capture MVD Citations, payments and manage paper documents

Improve ability to access and retrieve records: Find documents in 3 – 5 seconds Instead of 3 – 5 days

6

Executive SummaryProposed EDMS/ERMS Guidelines are: A framework that overlays, or cross-cuts,

the inter-related Information Technology Enterprise Architecture (ITEA)

A framework for incorporating statutory records management requirements and sound records management principles

seamlessly into agency work processes enterprise architectures information systems

7

Executive SummaryAgencies should use the proposed

EDMS/ERMS Guidelines: In conjunction with the NM ITEA

As the common State-wide framework For identifying records management (RM)

requirements To identify RM requirements and

Link them to their information technologies Link them to their business processes

To educate all state employees in their records management responsibilities

8

Executive SummaryAgencies should use the proposed

EDMS/ERMS Guidelines: Build RM requirements into agency IT

governance processes for planning IT funding enterprise architecture business process design the systems development life cycle

To establish a concise and coherent body of records management resources that places this information in the proper context within the ITEA

9

EDMS/ERMS & the ITEA

text

Constituent Services

Business Domains

ERMS - Records Management & the Centralized Electronic Records Repository

Government OperationsEducationResource

ManagementJustice

EDMS/ERMS Interrelation to the ITEA

Agency Strategic Architectures

Enterprise Business Architectures

EDMS - Electronic Document Management Systems

10

Federal Enterprise Architecture Records Management Profile

Federal Enterprise Architecture Records Management Profile Version 1.0

Initial Public Release Sponsored By: National Archives and Records

Administration Office of Management and Budget,

Architecture and Infrastructure Committee Federal Chief Information Officers Council

December 15, 2005

11

Potential Consequences of Inadequately Managing Records

Inability to retrieve business critical information

Increased costs of doing business Caused by inefficiencies Due to disparate/inaccessible data

Failure to comply with statutory or regulatory retention and disposition requirements

Reduced ability to comply with Court orders & other litigation Imperatives requiring access to existing information

Inability to respond promptly to inquiries

12

Potential Consequences of Inadequately Managing Records

Consequences of a failure vary depending upon the circumstances, but could range from minor to catastrophic: Inefficient service to state constituents Regulatory fines and penalties, which have

recently reached eight figure amounts Civil litigation consequences, such as increased

litigation costs and fines Vicarious liability for responsible senior

management Criminal liability for agencies and individuals

13

Intended Audience The following individuals should use

these EDMS/ERMS Guidelines to support effective decision-making : Chief Information Officers (CIO) Executive Management, Directors,

Deputy Directors Records Liaison Officers (RLO) Program/Project Managers General Counsels (GC)

14

SCRA Vision Centralized Electronic Records Repository

integrated Electronic Document Management Systems & an Electronic Records Management System (ERMS)

a comprehensive, systematic, and dynamic means for preserving virtually any kind of electronic record

free from dependence specific hardware or software Benefits

Make it easy for state agencies and constituents to find the records they want easy for the SRCA to deliver those records in any format suited to the users' needs

15

Centralized ElectronicRecords Repository Aligned with the IT Enterprise Architecture

Data Model for the Centralized Electronic Records Repository

General Administration

General Personnel

Administration

General Education

Local Government

Records common to all state agencies,

correspondence, annual reports

General Financial

General Medical

Constituent Services

Government OperationsEducationResource

ManagementJustice

16

Multiple Disciplines The EDMS/ERMS Guidelines builds upon

multiple disciplines as a foundation: Library Science Records Management Business Process Management

Process Mapping Information Technology

Enterprise Architecture Data Modeling

Metadata and XML

17

Public Record defined A Public Record is Content

regardless of physical form or characteristics - Made or received by any agency in pursuance of law

or in connection with the transaction of public business

And preserved, or appropriate for preservation, by the agency or its legitimate successor

As evidence of the organization, functions, policies, decisions, procedures, operations or other activities of the government;

For government responsiveness and accountability to state constituents;

To preserve the rights of citizens; Or because of the informational and historical value of data

contained therein.

18

Records Management Records Management is the

systematic control of Public Records from creation or receipt, through processing, distribution, maintenance and retrieval, to their ultimate disposition.

The preservation, retrieval and non-alteration of Public Records -

for the purpose of auditing or potential litigation

Statutory requirement that every executive is responsible for within each State Agency.

19

Implementing EDMS/ERMSProject Initiation

and Funding

Analyze Records Management

Practices

Perform Business Process

Reengineering

Develop metadata

Realize improved constituent services,

compliance with records regulations and

real cost savings

Implement ECM (aka EDMS/ERMS) Solutions

Imaging System Plan

ECM (aka EDMS/ERMS) Project Management

20

21

Analyze Agency Records Series

Initiate Records Series Inventory and Records Management

Practices Survey

· Conduct detailed onsite surveys with Agency staff

· Complete “Program Records Series Inventory (Form B)”

Create Pre-Survey Report:· Statutes· NMAC Rules · Website· Org chart· Unit size and budget

· Revise NMAC Rules as necessary

· Present to SRCA Review Committee

Provide Recommendations for Improved Records Management

Practices & Amended Record Retention

Schedule

· Present updated NMAC Rules to the Commission of Public Records

· Approval of updated NMAC Rules· File Rule with Administrative Law

Division as Law

22

Imaging System Plan – File with SRCA

Initiate Microphotography System planning· Contact Electronic Records

Management Bureau, SRCA

Managerial Planning· Facility· Policies & Procedures· Future Migration· Records Storage· Disaster Recovery

SRCA Approval for Agency Imaging System

Agency produces Microphotography Systems Plan

Pre-requisite:Records Management Analysis and Inventory

System Description· Goals· Fiscal· Programmatic· Managerial· Other: technological, legal, etc.

System Specifications· Imaging Hardware· Software· Operational

documentation

23

The Drive to Share Information

Next step in government IT development: Moving information across institutional

boundaries between states across executive agencies and to private entities from courts to executive agencies, and between courts

The drive to share information depends on: how successful the State is in framing the policy the available technology

Two interrelated concepts facilitate this effort:

Enterprise Architecture (EA) Service-Oriented Architecture (SOA)

24

InteroperabilityThe challenge for NM State agencies: Embrace the opportunities of EA

and SOA technologies To enhance the quality of executive,

legislative and judicial information sharing

As an explicit objective of their systems development

EA & SOA support interoperability

25

Interoperability Defined Interoperability has different meanings

depending on the context: Information Technology – “the ability of

independently developed and fielded applications that execute on heterogeneous computer platforms to communicate with one another and to exchange and use information (content, format, and semantics).”

Public safety – “the ability for public safety agencies and public services to talk to one another via radio communication systems and/or share information with one another accurately, on demand, in real time, when needed, and when authorized.”

26

Federal E-Gov Architecture Guidance (Common Reference Model)

“XML provides a critical foundation for E-Gov data architectures.

“XML is emerging as the Industry and Government standard for moving and sharing information.

“XML provides an opportunity for Federal Lines of Business to define and standardize XML schemas for their functions and for interactions with other Lines of Business and external entities such as State and Local Governments or Industry.

“Particularly powerful where Lines of Business can leverage emerging industry standards, or join with State and Local Governments to define joint XML schemas that provide data interoperability across tiers of government.

“All E-Gov Initiatives should define and implement an approach for using XML.”

E-Gov Architecture Guidance (Common Reference Model) Draft – Version 2.0, Interagency FEA Working Group, July 25, 2002 http://www.cio.gov/archive/E-Gov_Guidance_July_25_Final_Draft_2_0a.pdf

27

NASCIO Recommendations “A common vocabulary is needed to

facilitate cross boundary information exchange.

“Extensible Markup Language (XML) has become the de facto standard for government data sharing. “The Global Justice XML Data Model (GJXDM) is

the standard being widely implemented by government agencies at all levels for inter-organizational communication and data sharing of public safety and criminal justice information.”

Connecting the Silos: Using Governance Models to Achieve Data Integration, NASCIO Research Brief, Interoperability and Integration Committee , June 2005 (Updated November 2005), page 3https://www.nascio.org/nascioCommittees/interoperability

28

JXDM Defined JXDM – The Justice XML Data Model (JXDM) was

developed by the U.S. Department of Justice's (DOJ) Office of Justice Programs (OJP), together with the Global Justice Information Sharing Initiative (Global).

The purpose is to increase the ability of justice and public safety communities to share justice information at all levels laying the foundation for local, state, and national justice interoperability.

The DOJ began developing the requirements for the justice data model in 1998.

Document Management System Interoperability -- The Need, The Answer: A White Paper for Federal Agency CIOs and IT Architects, February 1998 (Department of Justice)http://www.cio.gov/archive/dms_interoperability_feb_1998.html

29

GLOBAL definedGlobal - The Global Justice Information Sharing

Initiative (Global) mission: the efficient sharing of data among justice

entities at the very heart of modern public safety and law

enforcement. Advises the U.S. Attorney General on justice information

sharing and integration initiatives Created to support the broad scale exchange of pertinent

justice and public safety information Promotes standards-based electronic information exchange to

provide the justice community with timely, accurate, complete, and accessible information

in a secure and trusted environment

30

GJXDM Defined Global JXDM - a comprehensive product that

includes a data model a data dictionary and an XML schema

The Global JXDM is an XML standard designed specifically for criminal

justice information exchanges providing law enforcement, public safety agencies,

prosecutors, public defenders & the judicial branch with a tool to effectively share data & information.

31

GJXDM Defined Removes the burden from agencies to

independently create exchange standards because of its extensibility more flexibility to deal with unique

agency requirements and changes Global JXDM enables interoperability

through the use of a common vocabulary that is understood system to system

32

Developing Metadata- Process Diagram

· Initiate process - meet with EDMS/SRCA staff

· Agency analyzes current business process

· Resulting in data model

EDMS/SRCA staff cross references Common Tables · Agency inputs from SME· Output – ensure all

metadata is captured· Agency ownership· National Standards

Agreement on Agency specific tables:· Accuracy· Comprehensive· Extensible

Approval by· EDMS metadata

review committee· SRCA/EDMS staff· Agency staff

Cross referenceagency metadata for interoperability

Pre-requisites:· BPR· Records

Management Analysis

33

Metadata Standards for ECMAgenda Definitions:

Metadata Data Dictionary Data Model XML Interoperability

34

Metadata Defined “Metadata” means "data about data"; it is

information that describes another set of data. Example is a library catalog card

Contains data about the contents and location of a book: It is data about the data in the book referred to by the card.

Metadata is structured information that describes and/or enables finding, managing, controlling, understanding or preserving other information over time.

In a records management context, metadata are data describing the context, content and structure of records and their management through time.

As such metadata are structured or semi-structured information that enables the creation, registration, classification, access, preservation and disposition of records through time and within and across domains.

35

Data Dictionary Defined A data dictionary is a set of metadata that

contains definitions and representations of data elements. Amongst other things, a data dictionary holds the following information:

Precise definition of data elements Usernames, roles and privileges General database structure

A data dictionary supports consistency between data items across different tables. For example, several tables may hold telephone numbers, using a data dictionary the format of this telephone number field will be consistent.

Data dictionaries are one step along a pathway of creating precise semantic definitions for an organization.

36

Data Dictionary Example Telephone Number

field label field name nulls type key references list field notes

TELEPHONE_ID yes serial PK n/a noPrimary key for the telephone table.

PARTY_ID no Integer FKparty. PARTY_ID no

Foreign key into the party table

phoneNumber no varchar (30) n/a n/a no n/a

phoneType no varchar (20) n/a n/a closed closed list

Field Definition: This is the type of telephone: home, work, fax, cell, secretary, other.Phone Type

Phone Number Field Definition: Telephone number.

ID Field Definition: Database generated identifier assigned to each unique telephone contact record.

Party Field Definition: This is the 'link' between a PARTY and an entry in the TELEPHONE table.

37

Data Model Defined A data model is a model that

describes in an abstract way how data is represented in a business organization, an information system or a database management system.

Data models include complex relationships between data elements

A data model shows how data of a specific business function is organized logically

38

Data Model Example Telephone Number

TELEPHONE_IDPARTY-ID

PhoneType

39

Data Model ExampleMVD Conceptual Data Model – by subject area

DriverLicenseDriverLicense

CustomerCustomer VehicleVehicle

InsuranceInsurance

LiensLiens

RegistrationsRegistrations

TitlesTitles

PlatePlate

CitationsCitations

DriverTest

DriverTest

AccountsAccounts DealersDealers

AddressAddress

InventoryInventory

DistributionDistributionOrganizationOrganization

StaffStaff

CashDrawerCashDrawer

Suspensions,Restrictions,Violations

Suspensions,Restrictions,Violations

DocumentImaging

DocumentImaging

DocumentWorkflowDocumentWorkflow

40

XML Defined XML – Extensible Markup Language (XML)

is a programming language devised for the web environment.

XML was designed to describe data and to focus on what data is. XML does not DO anything.

XML was created to structure, store and to send information.

XML is the most common standard for web programming

41

XML Example Telephone Number<?xml version=“1.0” encoding=“utf-16”?><XS:schema xmlns:ns)=“http://NMDA_Schemas.NMDA_Telephone_Record”

“http://NMDA_Schemas.NMDA_Telephone_Record: xmlns:b=“ http://schemas.microsoft.com/BixTalk/2003” elementFormDefault=“unqualified: targetTelephone=http://NMDA_Schemas.NMDA_Telephone_ID version=“0.2” <xs:import schemaLocation=“.\NMDA_Telephone_ID.xsd” Telephone=http://NMDA_Schemas.NMDA_Telephone/>

<xs:annotation><xs:appinfo><b:references><b:reference targetTeleponeRecord=“http://NMDA_Schemas.NMDA_Telephone_Record:/>

</b:references></xs:appinfo><xs:annotation><xs:Telephone_ID name=“TelephoneID”></xs:annotaiton><xs:documentation> Database generated identifier assigned to each unique telephone contact record.>/xs:documentation>

</xs:annotation><xs:complexPARTYID>

<xs:documentation>This is the ’link’ between the party and the entry in the telephone table<xs:documentation>

42

Data Dictionary & Data Model

43

Common Administrative Metadata

Metadata common to all agencies The Metadata Standards have been

organized into five tables: Table 1: Access Control/Rights/Redaction; Table 2: Retention/Disposition Instructions; Table 3: History or Audit Trail; Table 4: Document/Records Description, and

Document/Record Content; Table 5: Agency Specific metadata

These common metadata elements capture information needed to adequately administer content and documents

44

Common Administrative Metadata Table 1:

Access Control /Rights/Redaction: Security Classification Rights – (to read, write, change, delete)

Table 2: Retention and Disposition:

Retention Schedule Disposal Notification Flag Record Series Number (NMAC Number)

45

Common Administrative Metadata

Table 3: History or Audit Trail

Date accessed Preservation and migration history Hardware Software

Table 4: Document / Record Description

Author/Creator/Originator Date Created Key words (for searching) Retention Record Series Number

46

Agency Specific Metadata Table 5:

Agency Specific Metadata for Discovery These elements capture information

contained in the content or document that support retrieval and searching.

Record Type Description Subject(s) Person(s) Date(s)

See NM Court Workflow Design

47

Next Steps

Developing NMAC Rules for EDMS/ERMS Application Standards, plus the Whitepaper

Updated Timeline - September Application Domain Team Review

and Approval