Records Management System History The Law Enforcement Information Technology Standards Council (LEITSC) was created in 2002 with funding (Grant Number 2002-LD-BX-0002) from the U. S. Department of Justice, Bureau of Justice Assistance, and continued in 2003 with funding (Grant Number 2003-MU-BX-0068) through a collaborative effort between the Bureau of Justice Assistance and the National Institute of Justice. LEITSC is currently funded under the Bureau of Justice Assistance (Grant Number 2003-MU-BX-0068) and continues to work in cooperation with the National Institute of Justice.
LEITSC brings together representatives from the International Association of Chiefs of Police (IACP), National Sheriffs’ Association (NSA), National Organization of Black Law Enforcement Executives (NOBLE), and Police Executive Research Forum (PERF) to address law enforcement information technology standards issues. The mission of the group is to foster the growth of strategic planning and implementation of integrated justice systems through the development and implementation of information technology standards.
With guidance and leadership from BJA, LEITSC involves law enforcement partners to speak with a clear and consistent voice in shaping the course of crucial developments in information sharing. The national initiatives include the Law Enforcement Information Sharing Program (LEISP), Law Enforcement National Data Exchange (N-DEx), and Law Enforcement Regional Data Exchange (R-DEx). As law enforcement agencies move toward the procurement of computer aided dispatch (CAD) and law enforcement Records Management Systems (RMS), it is vital to recognize and consider the Law Enforcement Information Sharing Program (LEISP) developed by the U. S. Department of Justice (DOJ).
The LEISP is designed to promote information sharing among all levels of the law enforcement community and to guide the investment of resources in information systems that will further this goal. The goals of LEISP are supported through the proliferation of the Global Justice Information Sharing Initiative (Global) Extensible Markup Language (XML) Data Model (Global JXDM). For additional information on the Global JXDM, visit www. it. ojp. gov. The Global JXDM is an XML standard designed specifically for justice information exchanges.
It provides law enforcement, public safety agencies, prosecutors, public defenders, and the judicial branch with a tool to effectively share data and information in a timely manner. There are several ongoing DOJ initiatives incorporated into the LEISP. One program currently being developed jointly between the Federal Bureau of Investigation (FBI) and state and local law enforcement is the Law Enforcement National Data Exchange (N-DEx) System. A second program—the Law Enforcement Regional Data Exchange (R-DEx) System—has been developed and implemented by the FBI. Both programs are new law enforcement information sharing systems based upon the above critical standards.
The N-DEx Program is an incident- and case-based information sharing system (e. g. , RMS) for local, state, tribal, and federal law enforcement agencies that securely collects and processes crime data in support of the investigative and analytical process and will provide law enforcement agencies with strategic and tactical capabilities that do not currently exist on a national scale. An N-DEx concept of operations (ConOps) document is being finalized to aid in the design of the N-DEx system and to ensure that stakeholders understand and share the N-DEx vision.
The R-DEx Project seeks to securely share sensitive but unclassified crime information between federal agencies, while allowing for connection with several existing regionally based local and state information sharing systems to impede criminal and terrorist activities. R-DEx is now operational in several metropolitan areas. Standard Functional Specifications for Law Enforcement Records Management Systems (RMS) ix Purpose In 2003, LEITSC identified the need for a national standard for Records Management Systems (RMS) functional specifications with the following goals: ?
Provide a starting point for law enforcement agencies to use when developing RMS requests for proposals (RFP). ? Streamline the process and lower the cost of implementing and maintaining an RMS. ? Promote information sharing. With these goals in mind, the LEITSC Functional Standards Committee, composed of law enforcement practitioners and industry experts from around the country, was appointed to develop the Standard Functional Specifications for Law Enforcement Records Management Systems. The baseline document was developed from common elements found in the RFPs, technical documentation, and other RMS-related research.
The document was then validated by the LEITSC Functional Standards Committee using a computerized modeling tool. Once developed and validated, the specifications were vetted through the law enforcement community via each of the participating associations, as well as through other stakeholder communities, in an effort to gain input from a number of different perspectives. It is intended that these standards will be updated and augmented on a regular basis. Introduction RMS is an agency-wide system that provides for the storage, retrieval, retention, manipulation, archiving, and viewing of information, records, documents, or files pertaining to law enforcement operations.
RMS covers the entire life span of records development— from the initial generation to its completion. An effective RMS allows single entry of data, while supporting multiple reporting mechanisms. For the purposes of this document, RMS is limited to records directly related to law enforcement operations. Such records include incident and accident reports, arrests, citations, warrants, case management, field contacts, and other operations-oriented records. RMS does not address the general business functions of a law enforcement agency, such as budget, finance, payroll, purchasing, and human resources functions.
However, because of operational needs, such as the maintenance of a duty roster, law enforcement personnel records and vehicle fleet maintenance records are included within an RMS. This document addresses the following business functions: Document Scope ? Calls for service This document presents standard functional specifications for law enforcement RMS. The specifications found in this document are intended to be generic in nature rather than favoring one particular system or approach over another.
They are at the functional level in that they define what is to be accomplished versus how it should be accomplished. These specifications were developed to depict the minimal amount of functionality that a new law enforcement RMS should contain. They are not intended simply to be substituted for an RFP but should be tailored to fit the specific needs of each agency or group of agencies looking to purchase or upgrade an RMS. These specifications should be used as a starting point to build a fully functional RMS, based on agency needs and open standards, to efficiently interface and share information with other systems both internally and externally. ? Incident reporting ? Investigative case management ?
Traffic accident reporting ? Citations ? Field contact ? Pawns ? Civil process ? Orders and restraints ? Permits and licenses ? Equipment and asset management ? Fleet management ? Personnel ? Internal affairs It is expected that the process of defining detailed information exchanges in RMS will be addressed in future phases of this project. In addition, these specifications are intended to be used in conjunction with technical standards such as the U. S. Department of Justice’s (DOJ) Global Justice Extensible Markup Language (XML) Data Model (Global JXDM) to streamline the process of sharing information. ?
Analytical support (crime analysis) In addition, the following support functions are addressed: ? Master indices ? Interfaces ? RMS administration ? RMS reports (general) Standard Functional Specifications for Law Enforcement Records Management Systems (RMS) 1 Business Function: General Requirements The following are general requirements of RMS: ? Single entry (i. e. , no duplicate data entry) ? RMS should automatically submit data to external sources as defined by the agency ? Maximum use of code tables ?
Ability to enter and query narrative(s)/text fields ? Spell check and formatting capability on narrative(s)/text fields ? Ability to access multiple systems from a single RMS workstation ? Single database (i. e. , virtual or physical) ? Validation on data entry (i. e. , logical edits, edit checks for all fields) In addition, RMS should provide the user with the ability to reuse and/or import data returned from external sources to eliminate redundant data entry. RMS also should provide the capability to electronically forward RMS data to external data sources, either automatically or upon the user’s request (i. e. , based on agency rules embedded within RMS).
The above capabilities should be based on existing and emerging criminal justice standards, including DOJ’s Global JXDM; the National Information Exchange Model (NIEM); and the National Institute of Science and Technology (NIST), including the Electronic Fingerprint Transmission Specification (EFTS) and Facial Recognition Collection standards. Some functional specifications need to be addressed at the agency level, such as the identification of specific external agency interfaces. These unique functions are addressed within each applicable business function. For all exchanges generated by RMS, conformance with DOJ’s Global JXDM is required. Internal and External Databases:
An agency’s RMS should provide the capabilities for users to generate inquiries to internal and external data sources—such as state Department of Motor Vehicles and criminal history files, as well as the National Crime Information Center (NCIC)—from within each module where such inquiries make sense. A module is an independent portion of an RMS software application which provides specific functionality, e. g. , Arrest and Booking. Each module performs those procedures related to a specific process within a software package. Modules are normally separately compiled and linked together to build a software system.
Single modules within the application can normally be modified without requiring change to other modules, so long as requisite inputs and outputs of the modified module are maintained. Standard Functional Specifications for Law Enforcement Records Management Systems (RMS) 2 Business Function: Master Indices An agency’s RMS should have basic master indices that correlate and aggregate information in the following areas: people, locations, property, conveyances (e. g. , vehicles), and organizations (including businesses and gangs).
Master indices eliminate redundant data entry by allowing the reuse of previously stored information and the automatic update of the master indices upon the entry of report information. Master indices information can be captured in a variety of ways, including during the input of information from incident, traffic accident, and vehicle reports and citation, booking, arrest, juvenile, fingerprint, and mug shot subsystems. Prior to accepting an entry, RMS should automatically give the user the option of determining whether there is a match based on existing data. The system should support the validation and linking of addresses, commonplace names, and street intersections.
Linkages among any information contained in the master indices (e. g. , people to places or person to person) must be included in RMS. Standard Outputs, External Data Exchanges, and Internal Data Exchanges Standard Outputs: ? Query and retrieval by name, vehicle, location, organization, and/or property to produce a comprehensive response displaying all related records in the system Standard External Data Exchange: ? The master indices serve as an internal or external portal for information sharing ? Mobile computing system ? State databases ? NCIC Standard Internal Data Exchange: ? Existing RMS data 2.
1 Use Case Diagram (see page 4) 2. 2 Use Case: Master Name Index The RMS Master Name Index (MNI) function links an individual master name record to every event (e. g. , incident report, arrest report, field interview, accident report, and license and permits) in which the individual was involved or associated. Every person identified within these events is given a master name record.
Should that person become involved in another event, the single master name record is linked to all of the other events so that by querying that one name, the system can produce a synopsis of all the involvements associated with that one person. It also facilitates the linking of additional names to an individual master name record (i. e. , alias information and relationship data). In querying an individual MNI record, the user also would be able to view all related records, as well as those associated with that individual.
When a record or report is added to RMS and a person is linked (i. e. , indexed) to that event, the system should URL Integration collaborated with LEITSC to assist in the development of the functional standards. URL Integration used an alternative method to requirements analysis with their RequirementsModeler software.
RequirementsModeler is based on Uniform Modeling Language (UML), which is the defacto standard for documenting functional requirements. UML was created by the Object Management Group (OMG) in 1997 as a standard for visual object-oriented modeling. RequirementsModeler, consistent with UML principles, automatically generates diagrams and process flow (Use Case and Activity diagrams). URL Integration’s Use Case and Activity diagrams were reproduced for use in this report. Standard Functional Specifications for Law Enforcement Records Management Systems (RMS) Figure.
2. 1 Use Case Diagram— Master Indices Master Name Index Master Vehicle Index Master Property Index System Master Location Index Master Organization Index perform a very important matching function using a rulebased process defined by the agency. The purpose of this matching function is to either automatically link an existing MNI record or to present the user with a list of possible matches to the name so that the user can make the matching decision. RMS should provide a matching algorithm that will provide the ability to search the name file by a variety of criteria, such as sound-alike searching; phonetic replacement; diminutive first names (e. g. , James/.
Jim/Jimmy, Elizabeth/Beth/Betty, and Jack/John); and other static demographic information, such as age, sex, and race. ? Telephone numbers ? Known associates ? Alias names/monikers ? Available mug shot(s) and photographs ? Scars, marks, and tattoos ? Modus operandi (i. e. , unique method of operation for a specific type of crime) ? Identification (e. g. , social security, driver’s license, and local and county identification) ?
NCIC fingerprint classification Once a list of possible matches is provided, the user can decide whether the information should be linked to an existing master name record or whether a new master name entry should be added. This step is very important in maintaining the quality and integrity of the master name file in the system. In addition to names, the MNI should, at a minimum, capture and maintain information on: Over time, and depending on the circumstances, this information may change, and new information will be made available. Additional information can be added, but older information should be maintained and viewable. ? Physical characteristics (e. g. , current and past descriptors) ? Race and ethnicity ?
Location history (e. g. , current and past residences) ? The RMS MNI should also provide maintenance functions that will permit a record or report to be unlinked from one MNI and relinked to another. Since it is not always possible to ensure that the correct MNI record is linked to an event record, it must be possible to correct it. Functions also should be provided that will allow two or more MNI records to be merged into one record. Employer information Standard Functional Specifications for Law Enforcement Records Management Systems (RMS) 2. 3 Use Case: Master Vehicle Index 2. 5 Use Case:
Master Location Index Like individuals, vehicles often are directly or indirectly involved in events. When a vehicle is linked to an incident in RMS, it should be added to the vehicle record in the Master Vehicle Index (MVI), which provides an agency with a detailed, searchable store of information about vehicles. The Master Location Index (MLI) provides a means to aggregate information throughout RMS based on a specific address, a range of addresses, an area (i. e. , as defined in the agency geofile), and/or locations based on X/Y/Z coordinates.
A geofile is the location information base file for emergency 911 computer aided dispatch (CAD) systems. It also provides a facility to store information about a specific location that may not be stored elsewhere in RMS. MLI should store or provide access to additional premise information, such as occupancy, elevation (e. g. , floor), and premise type (e. g. , residence versus business). RMS should provide the capability to search on: ? Vehicle Identification Number (VIN) ? License plate number ? License plate state ? License plate year ? Registered owner ?
Description (e. g.. make, model, year, color, style, and attributes) When an inquiry is made on a vehicle, the system should return a list of all events in which the vehicle was involved. In addition, RMS may require MVI to have external interfaces. 2.
4 Use Case: Master Property Index The Master Property Index (MPI) is the central access point that links all property records entered into RMS. Each record is catalogued by using unique property characteristics, such as make, model, brand, description, distinguishing characteristics, and serial number. Industry property coding standards, such as NCIC property codes, should be used during the entry of property records into RMS. In addition, any property records entered throughout RMS should automatically cross-reference MPI to find potential matches based on the unique property characteristics outlined above.
An assumption is made that all location information being processed in RMS is subject to stringent formatting rules. In addition, if the address is within the boundaries of the agency geofile, the actual location is validated. Typically, during the geovalidation process, key identification information, such as X/Y/Z coordinates and agency-defined reporting areas, is added to the location information.
The geovalidation process should allow an address to be accepted, even if it does not appear in the geofile. Unverified addresses should be flagged for possible review. Optionally, all addresses or only addresses within the jurisdiction are available in MLI. 2. 6 Use Case: Master Organization Index Many events also involve an organization, such as a gang, business, school, or shopping center. Information about these groups entered into RMS should be contained in a Master Organization Index (MOI).
MOI provides an agency with a detailed, searchable store of information about organizations. An agency should be able to search on a variety of data elements and obtain a listing of all records associated with that organization. Organizations may change location and name, but these changes should be tracked in RMS.
In addition, MOI also should permit the linking of aliases to organizations (e. g. , M&M Associates, doing business as Joe’s Pawn Shop). Standard Functional Specifications for Law Enforcement Records Management Systems (RMS) 3 Business Function: Calls for Service All calls for service (CFS) are recorded in a structured records environment, providing the ability to run reports on these data, while also maintaining a historical record on all calls. The data are either segmented or identifiable by the agency. Standard Outputs, External Data Exchanges, and Internal Data Exchanges.
Typically, data in this module cannot be modified after the call is closed because they serve as a formal audit trail of the information that started the law enforcement activity. If RMS is not integrated with a CAD system, this function must be able to serve as the initial point of data entry for a CFS. The basic call data (e. g. initial call time, units dispatched, and call disposition) can be available to facilitate the creation of an incident report. The data imported into the incident report can be modified, whether or not the call has been closed, to reflect the latest information known regarding the incident.
Basic call data may be transferred at the time an incident number is assigned or at the initial closing of the call, depending on specified call types. ? Activity analysis by specified geographical area and time period ? CFS summary, by specified geographical area and time period ? Activity analysis by day of week ? Activity analysis by hour of day ? Activity analysis by day and hour ? Response time analysis by specified geographical area and time period (e. g. , receipt of call, dispatch time, on-scene time, and time call cleared) ? Response time analysis by call type ? Time consumed by call type by hour of day?
Workload activity by resource assigned ? Workload activity by group assigned ? Time consumed by day of the week and hour of the day ? Time consumed by specified geographical area and by time period ? Calls that should result in the creation of an incident report In the event that CFS data are transferred from CAD to RMS, RMS should receive the call number and associated incident number from the CAD system. If the call does not originate from a CAD system, this CFS module should be capable of generating or allowing manual entry of a sequential event number and an associated incident number to link CFS and incident records.
If the department is dispatched by a CAD system, an interface to the CAD system will be required to transfer the CFS data to RMS. The CAD workload reports also should be available from the calls for service module. Workload is the metric or metrics which accurately describe the amount of work performed by or within a process in a specific period of time. For example, the Calls for Service (CFS) module contains information about the number of calls received and the length of time needed to process those calls. The data on time and number of calls describes workload.
A workload report in an RMS is a compilation of data that provides a user with statistics pertinent to the functions performed by or recorded within a module. Standard Outputs: ? Daily log showing all calls received for the prior 24 hours from prior printing of the daily log Standard External Data Exchanges: ? CAD Standard Internal Data Exchanges: ? MNI ? Incident reporting Standard Functional Specifications for Law Enforcement Records Management Systems (RMS) Figure 3. 1 Use Case Diagram— Calls for Service RMS CAD initiates receives Transfer CFS Data to RMS* 3. 1 Use Case Diagram 3. 2 Use Case: Transfer CFS Data to RMS.
If CFS information is retransferred from CAD, the most current data will replace the information previously transmitted. The call data are transferred to RMS when units are initially dispatched after an incident number is assigned or when the call is closed in CAD. Standard Functional Specifications for Law Enforcement Records Management Systems (RMS) 4 Business Function: Incident Reporting Incident reporting is the function of capturing, processing, and storing detailed information on all law enforcementrelated events handled by the department, including both criminal and noncriminal events.
The incident reporting function collects sufficient information to satisfy the National Incident-Based Reporting System (NIBRS) or the Uniform Crime Reports (UCR). Incidents often are initially documented as CFS in a CAD system. The CFS record in RMS should be linked to the incident and should be easily accessible from the incident report. Standard External Data Exchanges: ? Federal databases to support electronic submissions Certain types of incident reports must be available to the public. Witness information, as well as the names of juveniles who are subjects or victims, may need to be redacted for public consumption.
RMS must be able to recognize the age of the majority in the jurisdiction by the date-of-birth information entered into the system that is available to the public. The system should support the redaction prior to printing a public copy or making the report available online to the public. Standard Internal Data Exchanges: ? Mobile reporting system The data captured in this module must support the preparation and submission of all required federal crime reporting and provide the capability to print a copy of both the completed department’s incident report and the redacted incident report.
Standard Outputs, External Data Exchanges, and Internal Data Exchanges Standard Outputs: ? All summary UCR reports and NIBRS reports ? Total incident reports based on period of time, area or beat, and incident type ? Location code (e. g. , geocode) ? Initial call type ? Offense type ? Summary of incidents by a responsible officer ? State submission following NCIC standards ? Prosecutor ? Courts ? Jail Management System (JMS) ? Regional Information Sharing Systems (i. e. , standardsbased, such as Global JXDM, NCIC) ? Investigative case management ? Property and evidence 4. 1 Use Case Diagram (see page 10) 4. 2 Use Case: Prepare Initial Incident Report
The incident report is prepared as soon as it is practical to do so following the incident and, depending on department procedure, may be updated throughout the initial investigation. Multiple officers may provide input once a single incident report is created and an incident number assigned. A primary officer will be assigned with overall responsibility for completing the report. This primary responsibility may shift to other officers during the life of the report.
The incident report must contain sufficient information to comply with national reporting requirements. Typically, an incident report contains factual information pertaining to the incident, including offense information, suspect information, and case status, as well as information pertaining to perpetrators, witnesses, victims, and complainants. Reporting requirements typically mandate the collection of certain elements of information. Standard Functional Specifications for Law Enforcement Records Management Systems (RMS) In addition, incident reports have free-text fields, which allow the collection of an unlimited amount of narrative information. The system should provide the capability to search the narratives for a specific word or phase.
Once completed, officers submit the incident report to their supervisor for review. Investigators are typically the individuals within the law enforcement agency responsible for follow-up investigation and for creating supplemental reports. To that end, they must be able to query and retrieve the initial incident report and use it as a baseline document for the supplemental report. They also must be able to electronically submit the report to a supervisor for review and dissemination. Multiple officers must be able to simultaneously create and add supplemental reports regarding the same event.
4. 3 Use Case: Create Supplemental Report A supplemental report is used to add new information to the case after the initial incident report has been submitted and approved. The creation of a supplemental report may result from information gained during additional investigation and also may result in updating the status of the investigation, possibly bringing it to closure. All supplemental reports are linked to the original incident report. The agency should be able to link all of the associated reports with a common report number.
This may be done using the original incident report number, possibly with a suffix indicating supplementals or a case number. Figure 4. 1 Use Case Diagram— Incident Reporting Prepare Initial Incident Report* receives generates Law Enforcement Officer performs Investigator Create Supplemental Report* receives performs conducts updates updates Report Review* 10 Standard Functional Specifications for Law Enforcement Records Management Systems (RMS) Supervisor 4. 4 Use Case: Report Review The incident report must be able to be locked from further edits at a point determined by the agency.
This does not preclude the viewing of the document by those with access permissions, but the ability to block access should be a capability of the system. Supervisors review incident reports and supplemental reports for accuracy and quality prior to their permanent, noneditable storage in the local RMS database and/ or their distribution to the agency records bureau; to other agencies; and to local, state and federal criminal information repositories. RMS must allow supervisors to receive, review, and approve incident reports online and to electronically respond to submitting officers and investigators regarding report quality and accuracy issues.
The department’s Standard Operating Procedures (SOP) also may require that the records division complete an accuracy review for compliance to reporting requirements prior to adding the information to the database. The system should support all required reviews and corrections prior to locking down the incident report. Standard Functional Specifications for Law Enforcement Records Management Systems (RMS) 11 5 Business Function: Investigative Case Management Incidents that require further investigation or follow-up may be referred to an investigator before they are closed or submitted to the prosecutor for a charging decision.
Depending on the department’s size and policies, the assignment may be made to a patrol officer, generally the officer who responded to the original incident, or the department’s investigative unit. The system should be able to assign case responsibility and task responsibility. The assigned officer receives these referrals or cases electronically and records all of the subsequent case management-related activities in RMS. Case management functions include, but are not limited to, capturing and storing investigation data, requesting a warrant, conducting interviews and photo lineups, and producing supplemental reports.
Investigators also may initiate criminal charges and obtain and execute both search and arrest warrants. The department should be able to define its specific activities, including a tim