IJIS RMS_JMS_LS Task Force Recommendations v1_4

IJIS Institute

RMS/JMS/Livescan Data Exchange

Standardization Task Force

December 2014

Lead Authors Matthew Johnson, South Sound 911 Srinivasan Venkatraj, Emergitech

Contributors Tim Ball, Kentucky State Police AFIS Bob Beall, MorphoTrak Pete Fagan, NGI Executive Education & Outreach Steve Hoggard (Task Force Chair), Spillman Technologies Ed Raper, Shelby County (TN) Teresa Wu, 3M (Cogent)

FINAL RECOMMENDATIONS OF THE RMS/JMS/LIVESCAN

DATA EXCHANGE STANDARDIZATION TASK FORCE

Final Recommendations of the RMS/JMS/Livescan Data Exchange Standardization Task Force

IJIS Institute, RMS/JMS/Livescan Data Exchange Standardization Task Force Page i

ACKNOWLEDGEMENTS

The IJIS Institute is grateful to the RMS/JMS/Livescan Data Exchange Standardization Task

Force members who volunteered time, expertise, and leadership to support the work of this

important endeavor. We are appreciative of the input, participation, and knowledge of the

following individuals:

Principal Contributors

Matthew Johnson, South Sound 911

Srinivasan Venkatraj, EmergiTech

Committee Members

The IJIS Institute Task Force Committee is comprised of the following members:

TASK FORCE MEMBER

COMPANY/ ORGANIZATION

TYPE OF ORGANIZATION REPRESENTED

Steve Hoggard (Task Force Chair) Spillman Technologies CAD/RMS/JMS Provider

Ed Raper Shelby County TN Practitioner

John Goergen Grand Ledge, MI Practitioner

Leila Tite Hennepin County Sheriff MN Practitioner

Matthew Johnson South Sound 911 Practitioner

Pete Fagan NGI Executive Education & Outreach CJIS Consultant

Srinivasan Venkatraj EmergiTech CAD/RMS/JMS Provider

Teresa Wu 3M (Cogent) Livescan Provider

Tim Ball Kentucky State Police AFIS Practitioner

Tony Misslin (Bob Beall) MorphoTrak Livescan Provider

Don Gabbin IJIS Institute IJIS Support Staff


IJIS Institute, RMS/JMS/Livescan Data Exchange Standardization Task Force Page ii

EXECUTIVE SUMMARY

About the RMS/JMS/Livescan Taskforce

The IJIS institute, at the request of the IJIS Public Safety Technical Standards Committee

(IPSTSC), initiated the Records Management System (RMS), Jail Management System (JMS),

and Livescan Data Exchange Taskforce (herein known as the RMS/JMS/Livescan Taskforce).

The goal of the RMS/JMS/Livescan Task Force was to solve interoperability issues surrounding

the abovementioned systems (referred to in this paper as the domain). The RMS/JMS/Livescan

Task Force is composed of practitioners and service providers that are expert in implementing

and operationally supporting technology within the domain.

Problem Identification

This RMS/JMS/Livescan Task Force drilled into the problem and identified the primary

workflows of domain end users while also taking into consideration alternate workflows and

upstream and downstream requirements of systems outside of the domain. This enabled the

domain expertise on the RMS/JMS/Livescan Taskforce to reduce the problems into

understandable, agreed-upon problem statements and then further distill those into requirements.

This effort created a foundation on which the group could identify a solution to solve the

inoperability within the context of the domain.

The following problem space statements were determined to be in-scope for the solution

recommendation:

1. Entry points into and out of the domain vary.

2. Custom system implementation results in increased cost.

3. There is not a subsystem within the domain that acts as the data of record.

4. There is not common data definition.

Solution Recommendations

The solution recommended reinforces existing standards available from the National Information

Exchange Model (NIEM) and Interface Solutions already available and in use. This Taskforce

will recommend the solution to the IJIS Springboard Program Team for acceptance into the

Springboard Certification Initiative (SCI). The program has a tried and tested framework to

verify and certify interoperability standards for the justice, public safety, and homeland security

communities. In solving the problems within the domain, the Taskforce recommends

approaching the solution through the SCI as follows:

1. Review domain process and data definition and make selection of NIEM Information

Exchange Packet Documentation (IEPD) and Interface Solution.

2. Validate Prospective Solutions using the Springboard Test Harness.


IJIS Institute, RMS/JMS/Livescan Data Exchange Standardization Task Force Page iii

3. Create and (or) Assimilate a Domain Data IEPD from NIEM.

4. Create Implementation Best Practices and Tools for practitioners and solutions providers.

5. Create an Adoption Plan for the justice community.

Business Value

Creating a data standard and Interface Solution through the SCI will lead to the fulfilling the

following business goals within the justice community:

1. Enhance functionality to the end-user and reduce procedural burdens through improved

interoperability.

2. Adapt to data formats and standards used by upstream or downstream processing.

3. Provide transparency to practitioners and service providers who implement and support

the system

4. Enable continual enhancements as subsystems and related technologies emerge and

improve.

5. Reduce effort required to implement new systems and subsystems resulting in cost

savings.

6. Have common data and definition that are predominantly used in systems to support

data fidelity.


IJIS Institute, RMS/JMS/Livescan Data Exchange Standardization Task Force Page iv

CONTENTS

ACKNOWLEDGEMENTS ......................................................................................................................................... I

Principal Contributors ......................................................................................................................................... i Committee Members ............................................................................................................................................. i

EXECUTIVE SUMMARY ......................................................................................................................................... II

About the RMS/JMS/Livescan Taskforce .................................................................................................... ii Problem Identification ..................................................................................................................................... ii Solution Recommendations ............................................................................................................................ ii Business Value ................................................................................................................................................... iii Table of Figures .................................................................................................................................................. v

PREFACE .................................................................................................................................................................... 1

Task Force Background ................................................................................................................................... 1 Task Force Goals ................................................................................................................................................ 1 Previous and Ongoing Efforts in Law Enforcement Standards ........................................................... 2

THE ROLE OF STANDARDS IN RMS/JMS/LIVESCAN................................................................................... 5

APPROACH TO CREATING A STANDARD ....................................................................................................... 7

Problem Identity ................................................................................................................................................ 7

RECOMMENDATIONS .......................................................................................................................................... 11

#1—Domain Process and Data Definition ............................................................................................... 11 #2—Validate Prospective Solutions within the Springboard Test Harness ................................. 13 #3—Create and (or) Assimilate Domain Data IEPD ............................................................................. 13 #4—Create Implementation Best Practices and Tools ........................................................................ 13 #5—Create an Adoption Plan ...................................................................................................................... 14

SCOPE ....................................................................................................................................................................... 15

ROADMAP EXAMPLE ........................................................................................................................................... 16

ABOUT THE IJIS INSTITUTE ............................................................................................................................. 17

About the Springboard Program ................................................................................................................ 17

APPENDIX A: PRIMARY WORKFLOWS ......................................................................................................... 19

APPENDIX B: USE CASES .................................................................................................................................... 22

APPENDIX C: DATA ELEMENTS ....................................................................................................................... 28

APPENDIX D: NGI ADDITIONAL HISTORY, BACKROUND, AND INTERFACE NUANCES ................ 31

APPENDIX E: REQUIREMENT TRACEABILITY ............................................................................................ 32

APPENDIX F: ACRONYMS AND ABBREVIATIONS ...................................................................................... 35

APPENDIX G: TERMS AND DEFINITIONS ..................................................................................................... 36

APPENDIX H: REFERENCES ............................................................................................................................... 38


IJIS Institute, RMS/JMS/Livescan Data Exchange Standardization Task Force Page v

Table of Figures

Figure 1: Multiple Entry Points into the System are Possible ....................................................................................... 8

Figure 2: Mugshot Booking Implementation Cost Breakdown ..................................................................................... 8

Figure 3: Subsystems may Contain the Most Up-to-date Data ...................................................................................... 9

Figure 4: Interoperability Throughout the Criminal Justice Community in the RMS/JMS/Livescan Domain............ 12


IJIS Institute, RMS/JMS/Livescan Data Exchange Standardization Task Force Page 1

PREFACE

Task Force Background

The Records Management System (RMS), Jail Management System (JMS), Livescan Standard

Data Exchange Task Force (herein known as the RMS/JMS/Livescan Taskforce) was formed by

the IJIS Institute at the request of the IJIS Public Safety Technical Standards Committee

(IPSTSC) to expand on efforts to enhance interoperability between RMS, JMS, and Livescan

systems. The IJIS Institute, the members of the RMS/JMS/Livescan Task Force, and the criminal

justice community as a whole are generally aware of the data exchange issues caused by a

federated,1 multi-vendor criminal justice system, on which the criminal justice community is

wholeheartedly reliant. Compounding the problems imposed by a system-of-systems are ever-

changing data, compliance requirements, and standards. The result? Costs that do not equate to

end user functional capabilities, reduction in data fidelity and integrity, and brittle, un-scalable

systems inflexible of change.

Stakeholders of the RMS/JMS/Livescan Task Force are aware of the industry-wide efforts that

have come before this undertaking. Collectively these efforts are not to be overlooked as each,

whether data format or transport standard, is worthy of viability review. The validity of

previously developed standards was reconciled against the problem statement and in-scope use

cases that are outlined herein. Upon recognition of use case, fulfillment gap analysis against

scope drove additions where additional standards are required.

IJIS Institute and members of the RMS/JMS/Livescan Task Force realize that there are a variety

of efforts underway to improve information sharing in federated systems, both within the

criminal justice community and in private industry with similar problem domains. Within the

criminal justice community, standards include the Automated Biometric Identification System

from the American National Standards Institute and National Institute of Standards and

Technology (ANSI/NIST), the Electronics Biometrics Transmission Specification (EBTS), and

the National Information Exchange Model (NIEM). Both NIEM and EBTS are well received yet

not broadly adopted in the criminal justice community at the local agency level. Outside the

criminal justice community there are highly transactional systems like those used in the

healthcare industry. Health care currently has a Health Level 7 (HL7) standard that is broadly

adopted and vastly expanded patient information interoperability.

Lastly, the RMS/JMS/Livescan Task Force understands the environment and imposing factors

that make creating one standard a moving target but also serve as reasons for pursuing one.

Task Force Goals

Based on the agreement of the members, the goals of the RMS/JMS/Livescan Task Force are to:

1 Federated system is a collection of multiple autonomous systems that are connected to achieve multiple user goals.



1. Explore all the efforts currently prevailing in each of the sectors outlined so that the task

force may intelligently review information sharing landscape between RMS/JMS and

Livescan Systems.

2. Specifically examine the role that nationally-accepted technology standards may play in

addressing information sharing between RMS/JMS and Livescan systems as it relates to

justice and public safety community.

3. Specify steps that need to be taken to develop a road map to address the information

sharing related challenges within the domain.

4. Recommend a framework of best practices guide for implementation and operations can

be developed and promoted to the entities involved in both the public and private sector.

5. The efforts of this Task Force will result in the development of requirements for the

RMS/JMS/Livescan standard, identify the standards body to take the lead to develop the

standard, and kick-off the Springboard initiative to certify the standard. (see Appendix E:

Requirement Traceability).

Previous and Ongoing Efforts in Law Enforcement Standards

This section details some of the historical efforts undertaken by, the IJIS Institute, and others.

It is important to understand previous efforts related to standards for interoperable federated

criminal justice systems. The RMS/JMS/Livescan Task Force has a forward-looking approach in

identifying how standards will continue to play a role in criminal justice systems, in the system

of systems, and in new technologies as they continue to manifest themselves. We will identify

successful standards both within law enforcement and in other industries. By pursuing the

recommendations as suggested, criminal justice system decision makers, and those that desire to

share information with them, would benefit from being in a position to effectively plan for the

demands of next generation needs rather than being forced to react to them.

American National Standards Institute (ANSI) and National Institute of Standards and Technology (NIST) Standard on Automated Biometric Identification System (ABIS)

This standard is specific to the capture and definition of biometric modalities. It defines the

content, format, and units of measurement for the exchange of fingerprint, palm print,

facial/mugshot, scar mark & tattoo (SMT), iris, and other biometric sample information that may

be used in the identification or verification process of a subject. The information consists of a

variety of mandatory and optional items, including scanning parameters, related descriptive and

record data, digitized fingerprint information, and compression.

Currently, both government and industry partners ubiquitously use the term Automated

Fingerprint Identification System (AFIS), but AFIS has transitioned over time. As AFIS have

been more widely deployed and technology advancements have occurred, the F in AFIS, which

historically referred to fingerprints, is no longer a valid reference. Traditional AFIS capabilities

and capacity have been surpassed by the inclusion of new biometric modalities to include palms,

faces, SMTs, and irises. As this transition has occurred over the last decade, the more appropriate

system reference has become the Automated Biometric Identification System (ABIS).



Similarly, the Federal Bureau of Investigation (FBI) Criminal Justice Information Services

Division (CJIS) Integrated Automated Fingerprint Identification System (IAFIS) has also

transitioned with the final deployment of the Next Generation Identification System (NGI) in

September 2014; as a result, IAFIS changed in name to NGI. Since accepting new biometrics

(palm, face, SMT, and iris) this will provide new investigative and informational service

capabilities to accommodate users of current and future biometric modalities. Future modalities

may include rapid DNA identification sent to Federal and state agencies in the coming years.

The standard experienced the following transitions over time:

1986 – 1993 First version released as a minutiae-based standard. It required a minimal

amount of memory for the exchange and storage of fingerprint data.

1993 – 1998 An addendum to the standard was made to include mugshots, scars, marks, and

tattoos. Data format was also included however minutiae provisions were

maintained. A revision was made in 1998 that included new record types for

fingerprint and palm print.

1999 – Present The current version is a product of workgroups convened in 2005 and most

recently updated in 2013. This version defines image quality and best practices

for image capture. An iris record type was also added, as well as an XML

alternative representation.

Electronic Biometric Transmission Specification (EBTS)

EBTS seeks to complement the ANSI/NIST data standard by creating transactional standards to

communicate with the FBI NGI System for identification, verification, informational, and

investigative purposes. The authorized local or state arresting/booking agency that sends data to

State Identification Bureau (SIB) must use the EBTS standard to successfully transmit and

receive messages back and forth between agencies. FBI’s CJIS Division’s NGI (replaces the

IAFIS) will have a complete biographic profile in the subject records, in addition to the

fingerprints, the palm print, mugshots, SMT, and iris information.

The FBI is now prepared to include additional biometric modalities. This will support the

American National Standards Institute the National Institute of Standards and Information

Technology Laboratory ANSI/NIST ITL-2013 with the new record types and transactions.

Obviously, without submission of the new data and capturing and submitting the correct data

elements, the new biometric modalities cannot be submitted to further the mission of enhancing

criminal justice and homeland security. There are unique data fields that are applied to the

records and transactions that are sent and received from the SIB and NGI that can link records

and can be used to enhance data fidelity by contributing agencies, see Appendix D: NGI

Additional History, Background, and Interface Nuances for additional information.



Data Standardization – System Non Specific

National Information Exchange Model (NIEM)

With roots in state and local government, NIEM2 is a community-driven, government-wide,

standards-based approach to exchanging information. Information exchange is about connecting

data from one computer to another, and another, and so on. NIEM ensures that information is

well-understood and carries the same consistent meaning across various communities, allowing

interoperability to occur. With NIEM, you only need to know two languages—your own and

NIEM.

The standard experienced the following transitions over time:

2003 – 2005 Global Justice Information Sharing Initiative was a grass-roots initiative set into

motion by the desire to create a seamless, interoperable model for data exchange

that could solve a range of information-sharing challenges across a variety of

government agencies. After a two-year effort, the first pre-release of the Global

Justice XML Data Model (GJXDM) was announced in April 2003.

Built upon GJXDM’s success and lessons learned from it’s use, the National

Information Exchange Model (NIEM) was launched in 2005, uniting key

stakeholders from Federal, state, local, and tribal governments to develop and

deploy a national model for information sharing and the organizational structure

to govern it.

2005 – Present NIEM was formally initiated in April 2005 by the chief information officers of

the U.S. Department of Homeland Security and the U.S. Department of Justice.

In October 2010, the U.S. Department of Health and Human Services joined as

the third steward of NIEM.

Since 2005, NIEM has issued four releases: 1.0 in 2006, 2.0 in 2007, 2.1 in

2009, and 3.0 is now available.

Relevant NIEM Implementations 2005 to Present

The FBI CJIS National Data Exchange System (N-DEx) is a national information system that

was born out of the events of 9/11 for criminal justice and law enforcement agencies. It was

created as a result in the change in philosophy from a need to know to a need to share that ham

strung efforts to thwart the tragic events. The N-DEx Information Exchange Package

Documentations (IEPDs) were created to standardize data elements and enable data

interoperability between disparate RMS/JMS to further the goals of N-DEx and national un-

classified information sharing. Under the umbrella of NIEM, N-DEx created the Incident and

Arrest IEPD and the Incarceration, Booking, and Probation and Parole IEPD.

2 http://www.niem.gov

https://www.niem.gov/glossary/Pages/global-justice-xml-data-model.aspx

http://www.niem.gov/



THE ROLE OF STANDARDS IN RMS/JMS/LIVESCAN

A lot has been said of standards throughout history. During the colonial times in the United

States, John Q. Adams stated, “weights and measures may be ranked among the necessities of

life to every individual of human society.” In 1948, an organization by the name of the Bureau of

Standards, created a computer standard using vacuum tubes and diode logic. By 1988, this

bureau became the National Institute of Standards and Technology. NIST overseas several

laboratories, one of which houses an atomic clock that just happens to be the national time

standard.

Even with just this brief history lesson in standards, it is still obvious that standards are rooted in

everything we do. More so in many things we take for granted such as universal weight,

distance, or time measurement. When technologies are universally implemented in a similar

fashion, the result is reduced ambiguity with secondary results of efficiencies, tertiary results in

decreased implementation costs, and so on. There are stellar examples where technical standards

have vastly enhanced our professional and personal lives. Take, for instance, the World Web

Consortium (W3C) – every digital device we own depends on the web platform standards

provided by the W3C. The web platform standard, along with hundreds of other proprietary and

universal standards, enable tens of thousands of different components to connect with our

devices; all of which delivers utility by making technology relatively universal.

While the necessity for RMS/JMS/Livescan standards may not be quite as critical to be a

necessity of life, or as essential to keeping watches set across the nation, it is critical in keeping

our criminal justice systems operating with a high-degree of fidelity in order to keep our general

public safe. That said, this criminal justice federated system is worthy of a standard. Without

standards, there is a series of cobbled-together interfaces, technologies, and devices that make

our system of systems. Ultimately, we often do not know who has the key to the castle that keeps

our constituents safe.

Standards have different meanings to different groups. Project managers and finance departments

in criminal justice agencies see the result of the lack of standards. Custom development, where

there could be standards-based best practices, accounts for 30% of criminal justice system

integration costs. Criminal justice service providers and IT shops see technology standards as

inflexible and (or) an imposition. Most importantly, obfuscated to most if not all, is the time

customizing interfaces that have reproducible inputs and outputs is time not spent enhancing

end-user functionality. As service providers and practitioners, we are capable of solving these

issues and influencing our local, state, tribal, or Federal ABIS to adapt to such a solution.

In order to be successfully adopted and as an ongoing concern, the standard must address each of

the stakeholder objections or reasons for resistance to adopting. With approaches such as Service

Oriented Architecture (SOA), design patterns, and open or semi-open source, it appears to be

technically feasible to address stakeholder concerns about standards. When focusing on core data

elements that are important to improve data fidelity across systems and ultimately enhance the

quality of the records. Creating the capability to link activity to records that will allow data

transfer back and forth as the data traverses several disparate systems such as JMS/RMS

Livescan local, regional, state ABIS and the NGI System. Therefore, the RMS/JMS/Livescan

Task Force will seek to create a standard that will:



1. Enhance functionality to the end user and reduce procedural burdens through improved

interoperability.

2. Adapt to data formats and standards used by upstream or downstream processing.

3. Be transparent to practitioners and service providers who implement and support the

system.

4. Provide continual enhancements as subsystems and related technologies emerge and

improve.

5. Reduce effort required to implement new systems and subsystems, which will result in

cost savings.

6. Have common data and definition that are predominantly used in systems to support

data fidelity.



APPROACH TO CREATING A STANDARD

The first step to solve any problem is identifying that there is one. The problem cannot be merely

stated in a broad stroke; it needs to be distilled to a level of understanding of which all

stakeholders of the system understand. In this case, the Task Force is the subset of stakeholders.

Therefore, requirements are, in-turn, clearly identified in order to make recommendations for a

solution. The scope will be reviewed and updated iteratively and, from this, the roadmap toward

a universal standard is drafted. Finally, with these elements we can enlist the support of agencies,

service providers, and accredited institutions for adoption.

Problem Identity

RMS, JMS, and Livescan collectively are the lion’s share of the subsystems that makeup the

federated criminal justice system. There are both upstream and downstream systems, such as

mugshot and iris systems and local, regional, or state ABIS. There are also ancillary systems that

are data dependent, such as court management systems (CMS). While each subsystem has a

distinct purpose, each also has ancillary

purposes, which creates further complexity.

These subsystem customizations are then left

in the hands of the local agency IT

departments. This, along with multiple

agencies supporting the subsystems, results

in tribal knowledge3 for maintenance,

troubleshooting, and upgrades, in other

words: “who has the keys to the castle?”

Problem Statement #1 – Entry Points and Workflows Vary

There are numerous examples of multipurpose subsystems. The Livescan machine has the

primary purpose to capture fingerprints; however, it is often used to capture arrest and

demographic information. The process is intended to maintain personal criminal history, verify

identity, and update the state and national criminal history record with new criminal activity or

other relevant information. Most, but not all, agencies use it as the conduit to local, regional, and

State Identification Bureau (SIB) and state ABIS and, subsequently, to the FBI-CJIS NGI

System to establish identity and criminal activity that establishes a national criminal history

record. Once the criminal history is established, it is used for criminal and non-criminal justice

purposes such as the applicant background check. However, even though the RMS/JMS usually

acts as the master data aggregator for local agencies, this is not always the case. Compounding

the disparity is that there is not a single entry point into the system, see Figure 1. For instance,

many of the systems are used for demographic intake at a jail. There are likely no two agencies

alike in their RMS, JMS, and Livescan implementation, see Appendix A: Primary Workflows.

3 Tribal knowledge is any unwritten information that is not commonly known by others within a company/organization. This term is used most when referencing information that may need to be known by others in order to produce quality product or service.

“Organizations which design systems….are constrained to produce designs which are copies of the communication structures of these organizations.”

-Melvin Conway



FIGURE 1: MULTIPLE ENTRY POINTS INTO THE SYSTEM ARE POSSIBLE

Problem Statement #2 – Custom Adapters Result in Increased Costs

Each implementation and or change to the RMS/JMS/Livescan requires custom interfaces. Each

change or addition has resultant costs for both the producer and consumer of the interface.

During a recent new mugshot booking implementation at a Pierce County (WA) agency, the

costs for custom integration amongst systems accounted for 27% of the overall costs, see Figure

2. While this may not necessarily be significant when looked at individually, if replicated in

thousands of subsystems across law enforcement agencies nationwide, it does become

significant, especially when you also consider the ongoing support costs will increase as a direct

result of custom adapters.

FIGURE 2: MUGSHOT BOOKING IMPLEMENTATION COST BREAKDOWN

Interfaces 27%

Hardware & Server

Licensing 19%

Mugshot Software Licensing

45%

Travel / Training

9%



Problem Statement #3 – It Isn’t Always Known What System is the Most Up-to-date

While RMS is typically the master data repository for an agency, there are many instances where

the subsystems are updated with the most recent data. For instance, someone is taken into

custody and they use a false name, and the inaccuracy is not discovered until the person is

fingerprint verified. When this happens, the upstream or downstream systems may not be

updated, see Figure 3.4

External Domain Interfaces

Internal Domain

Records Management

System

Jail Management System

Livescan System

Dept of Licensing

Courts/Legal

State Patrol

CJIS/FBI

AFIS/ABIS

Mugshot and Iris

FIGURE 3: SUBSYSTEMS MAY CONTAIN THE MOST UP-TO-DATE DATA

Problem Statement #4 – There Isn’t Common Data

Data that traverses multiple systems does not have common definitions or organization. Most of

this data is backed by different database types, which makes the system of systems not only a big

4 This figure is a generic representation that is reflective of many justice information system and may not be as representative of a

smaller agency’s systems.



data’5 problem, but there is also a lack of common definitions. State and local offense data or

charges may not be reflective of those used by a state or county, which causes data translation

issues when creating or updating a criminal history. Additionally, one system may identify with

Uniformed Crime Reporting (UCR) crime types and another Incident Based Reporting (IBR)

crime types. Nationally, only IBR is accepted, however, many agencies and municipalities still

use UCR-based reporting. Not only does this result in duplicate entry, the fidelity of the data is

compromised.

5 Big data is an all-encompassing term for any collection of data sets so large and complex that it becomes difficult to process

using on-hand data management tools or traditional data processing applications. [Source: Wikipedia]

http://en.wikipedia.org/wiki/Data_set



RECOMMENDATIONS

The RMS/JMS/Livescan Task Force’s analysis and problem definition led headlong into part of

the solution. When reviewing existing data standard solutions available there was little debate as

to what solution, whole or in part, would solve the lack of data definition in our proposed

problem domain. During the review of prospective solutions, the task force members were often

reflecting back to the National Information Exchange Model (NIEM) and noting, “NIEM already

does that.”

There are holes, however, identified where NIEM meets interoperability requirements. (See

Appendix E: Requirement Traceability, specifically BR-1.) The RMS/JMS/Livescan Task Force

preliminarily looked into an Interface Solution6 to fill these requirements. There are a multitude

of off-the-shelf and third-party solutions available to create workflows and connect disparate

systems, however, not one of the solutions was as obvious as NIEM is to solve data fidelity

issues. Therefore, we opt to perform further analysis before recommending an Interface Solution.

Adopting both NIEM and an Interface Solution will provide cost savings through the use of

community-developed tools and standardized data; this is contrary to the problems caused from

individual custom integration efforts between stovepipes of data and disparate systems. NIEM

will increase data fidelity by defining commonalties in the RMS/JMS/Livescan domain and an

Interface Solution can easily adapt to each organizations’ disparate systems, workflow, and

business rules. The combined solution will build upon an NIEM IEPD of data definitions and

implementations based on industry best practices. The result will be interoperability throughout

the criminal justice community in the RMS/JMS/Livescan domain, Figure 4.

#1—Domain Process and Data Definition

The RMS/JMS/Livescan Task Force spent a significant amount of time reviewing and

documenting data elements, workflows, and use cases; however, more analysis is required. A

deeper analysis will ensure all the primary workflows, process exceptions, and up and

downstream processing is identified. The analysis will capture as many workflows and data used

in the RMS/JMS/Livescan domain. It will also identify a large representation of the internal and

external dependent systems. Addressing these workflows and data will create the foundation for

primary/exception workflows, common and unique data for further validation against IEPDs and

Interface Solutions.

To be considered for an IEPD, NIEM requires documentation that is more extensive. While

populating the remaining documentation, we can begin reviewing the existing IEPDs, such as the

Justice clearinghouse, for a prospective fit against the primary use cases and data elements

outlined in Appendix A: Primary Workflows, Appendix B: Use Cases, and Appendix C: Data

Elements. This review would include data validation by and between upstream and downstream

data standards such as N-DEx, NIST records, and EBTS. In this review, it will be possible to

standup up the IJIS Institute test harness for validation of potential IEPD data models and

Interface Solutions with existing use case data and process flows respectively.

6 Interface Solution is a term used to refer to a kind of middleware (e.g., MULE ESB) standards based framework, or web

services, which can be used to transform, route, clone and translate messages.



External Domain Interfaces

Internal Domain

Records Management

System

Jail Management System

Livescan System

Dept of Licensing

Courts/Legal

State Patrol

CJIS/FBI

AFIS/ABIS

Standards Based

Interface Solution

Mugshot and Iris

FIGURE 4: INTEROPERABILITY THROUGHOUT THE CRIMINAL JUSTICE COMMUNITY IN THE RMS/JMS/LIVESCAN DOMAIN

Outcomes and Artifacts

NOTE: Artifacts are identified with italics and NIEM required artifacts are annotated with

asterisk.

RMS/JMS/Livescan Standard Mission Statement*

NIEM Readiness Assessment*

Identify, as much as possible, summary use cases identified within the

RMS/JMS/Livescan domain

Exchange Content Model* showing the relationship and cardinality of objects in the

domain

Document mapping* of the RMS/JMS/Livescan data in UML

Document remaining Sequence and Process Diagrams as necessary

Identify which additional use cases need 100ft definition

NIEM Cost Model*



#2—Validate Prospective Solutions within the Springboard Test Harness

This will begin validating domain data and definitions against NIEMs existing IEPD

clearinghouse(s), and downstream EBTS standards. This will lead to the determination what

existing IEPD(s) fit the JMS/RMS/Livescan domain. This work will be in conjunction

identifying a repeatable Implementation Solution using existing off the shelf, open source

project, or other Interface Framework. Domain workflows will be used to evaluate existing or

create an in-house implementation of best practices. We shall evaluate and recommend an

implementation framework from the existing workflows. The Domain workflows will be used to

evaluate existing or creating an in-house toolset of implementation best practices.

Outcomes and Artifacts.

Finalize the Business Requirements outlined in this document

Business rules* which will be will be derived from the use cases

XML schema documents* for structure and constraints of the XML

Implementation Solution recommendation and justification

Draft outcomes of prospective IEPD and IE evaluation

#3—Create and (or) Assimilate Domain Data IEPD

Artifacts from previous documentation will be packaged and submitted to NIEM for IEPD

evaluation by the NIEM Business Architecture Committee (NBAC) and the NIEM Technical

Architecture Committee (NTAC). This will include the XML data to determine if a new IEPD is

required or assimilate and harmonize with an existing clearinghouse. This will result in creating

an exchange XML IEPD instance or assimilate an existing clearinghouse.


Sample XML instance* that contains all Information Exchange Package

Mapping document* between the source domain data and the NIEM current data model

Identify either an existing clearinghouse or recommend making a new IEPD

NBAC and NTAC recommendation

#4—Create Implementation Best Practices and Tools

NIEM has a core of required artifacts that assist in adoption and implementation. On the other

hand, and depending on the proposed Interface Solution, the solution may have out-of-the-box

APIs and best practices already identified. Knowing an Interface Solution requires user

documentation for successful adoption and implementation; the documents will model and

assimilate with the NIEM user documentation into a comprehensive ‘Read Me’ package.


User documentation assembled into comprehensive package, this will include but not limited to

the following:



NIEM Model Package Description (MPD)* to validate between MPD and XSD

Read Me* to describe the NIEM XML artifact and Implementation Solution

Change log* to describe upcoming and previous changes to the IEPD

Sample XML* to demonstrate each Information Exchange Package

#5—Create an Adoption Plan

There will be a clearly defined plan for industry adoption, ongoing support, and continual

improvements. This is important to ensure the solution has a successful launch and the industry

has awareness of its availability and merits. This will include adoption strategies by including the

requirement to support the proposed standard in upcoming RFPs for RMS/JMS/Livescan

implementations. The Plan will be transferred into a roadmap, and feedback will be requested on

the roadmap to assist in defining the long-term direction of the standard.


Adoption Plan* identifying which industry associations to approach, ongoing operations

and ownership, and implementation strategy

Solution/Standard Roadmap that depicts ongoing efforts and functional releases

Put operational controls around the IEPD to include governance, technical architecture,

versioning controls, etc.



SCOPE

In Scope

Should the recommendations be accepted by and brought into the Springboard Certification

Initiative (SCI), the RMS/JMS/Livescan Task Force recommends focusing on the primary

workflows and use cases with Common and Unique Data Elements exchanged – outlined in

Appendix A: Primary Workflows, Appendix B: Use Cases, and Appendix C: Data Elements.

These workflows have the potential to provide immediate interoperability and solve the NGI

biometric submission challenges that face the criminal justice community. Once validated, that

the solution would increase interoperability, and it would be timely to work with early adopter

service providers and practitioners to gain immediate benefit and show viability. This viability

would include the internal interoperability and an external interfacing system.

The documentation will lead into end-user documentation, both for the prospective NIEM data

standard and the Interface Solution best practices. This documentation would assist practitioners

and service providers to implement and operationally support the standards-based solution.

Therefore, at the end of the evaluation period, there will be end-user documentation and an early

release recommended Implementation Solution and data definition available to the community.

Out of Scope

This recommendation only includes the solutions leading toward the enhancement of data

fidelity and an Implementation Solution within the RMS/JMS/Livescan domain. This is not

inclusive of any aspect of system security as is covered under FBI CJIS Security Policy

standards and requirements as well as those that may be more stringent in any given state. It will

be up to the implementing agencies network security to limit/prevent access to the data formats

and administrative tools.



ROADMAP EXAMPLE

The following provides a graphic example of the roadmap.



ABOUT THE IJIS INSTITUTE

The IJIS Institute unites the private and public sectors to improve mission-critical information

sharing and safeguarding for those who protect and serve our communities. The IJIS Institute

provides training, technical assistance, national scope issue

management, and program management services to help

government fully realize the power of information sharing.

Founded in 2001 as a 501(c)(3) nonprofit corporation with

national headquarters on The George Washington University

Virginia Science and Technology Campus in Ashburn, Virginia,

the IJIS Institute has grown to nearly 320 member companies

and individual associates from government, nonprofit, and

educational institutions from across the United States.

The IJIS Institute thanks the RMS/JMS/Livescan Task Force for their work on this document.

The IJIS Institute also thanks the many companies who have joined as Members that contribute

to the work of the Institute and share in the commitment to improving justice, public safety, and

homeland security information sharing.

For more information on the IJIS Institute:

Visit the website at: http://www.ijis.org/,

Follow the IJIS Institute on Twitter: @ijisinstitute,

Read the IJIS Factor Blog, and

Join us on LinkedIn at: Justice and Public Safety Information Sharing.

About the Springboard Program

Springboard is an evaluation and certification program designed to help advance information

sharing in the justice, public safety, and homeland security communities. Springboard provides

independent services to industry and government for the evaluation and certification of

implementations of standards-based information sharing solutions.

The Springboard program works with sponsor organizations and an initiative team of industry

and government representatives to provide a venue for the evaluation of implementations of

interoperability standards. Each Springboard Certification Initiative (SCI) team develops a Test

Harness that serves as the focal point for testing of implementations in the field, which is

followed by formal conformance testing and certification.

The SCI conformance criteria are developed to match a standards-based interoperability

specification. Tests against these criteria are then implemented in the SCI Test Harness, which is

made available to participants seeking to engage in conformance testing of their own products or

systems.

A specification owner participates in each initiative to ensure that the Test Harness

implementation is true to the intent of the specification of the standard or service. These owners

http://www.ijis.org/

https://twitter.com/ijisinstitute

http://www.ijis.org/EDblog/

http://www.linkedin.com/groups/Justice-Public-Safety-Information-Sharing-4104229?trk=myg_ugrp_ovr



can include a standards development organization (SDO) committee such as the Organization for

the Advancement of Structured Information Standards (OASIS) Electronic Court Filing

Technical Committee (ECF TC) or the developer of a Global Reference Architecture (GRA)

service specification.

The first certification initiative provided evaluation and certification of implementations of the

Prescription Drug Monitoring Information Exchange (PMIX) GRA Service Specification. The

second initiative is nearing completion and will provide evaluation and certification of

implementations of the OASIS ECF Standard. During this initiative, the SCI Team of

government and industry representatives worked with the OASIS ECF Technical Committee to

develop the Test Harness, a tool based on the ECF Standard and used for carrying out the

certification tests. The Technical Committee and the Initiative Team worked in close cooperation

to ensure that the Test Harness was an accurate reflection of the specification’s normative

requirements for the use of eXtensible Markup Language (XML) to transmit legal documents

among court system participants.

Conformance testing generates a record of all tests that are passed by a candidate product or

system that has implemented the specification in part or in its entirety. The successful

completion of these tests will enable purchase of a certification mark license that can be used in

product packaging, documentation, and promotional material.

Source: http://www.ijis.org/_programs/springboard.html

https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=legalxml-courtfiling



https://it.ojp.gov/GRA

http://www.ijis.org/_programs/pdmp.html

http://www.ijis.org/_programs/springboard.html



APPENDIX A: PRIMARY WORKFLOWS

Livescan Workflow Use Case 1Export Booking Data from RMS/JMS

LivescanRMS/JMS State/County/NGI

Ph

ase

Enter/Update Person Information

and Confirm

Optional – Capture Photo/SMT

Standard Exchange of

Person Information

IEPD

Extract Person Information from

Database

Consume Person Information and

Validate

Capture Biometrics


Save Person Information and

Send to State/NGI and Sub-Systems


Process Person Information



Livescan Workflow Use Case 2Import Booking Data from Livescan to RMS/JMS

LivescanRMS/JMSState/County/NGI


and Confirm


Person Information

IEPD

Extract Person Information

Consume Person Information and

Validate

Capture Biometrics


Save Person Information and

Send to Sub-Systems






Livescan Workflow Use Case 3Process State and FBI Response

LivescanRMS/JMSState/County/NGI


Response Information

IEPD

Consume Response Information and

Validate

Save Response Information


Extract Person Information and

Biometrics

Send to State/NGI

Prepare Response Information

Process Response Information

Prepare Response Information and

Send

Note

The Response Information may be

returned in many ways

LiveScan, email, CJIS, etc



APPENDIX B: USE CASES

Export Booking Data from RMS/JMS

Brief Description

This use case documents the functionality when an agency has entered demographic and charges

data into a RMS/JMS system and exports it to a Livescan system. The scope of the use case is to

the point where the data is pulled up in a Livescan system and updated for missing information.7

Actors

RMS/JMS data entry personnel (data entry clerk, booking officer, etc.)

RMS/JMS system

Livescan system ABIS

Agency Livescan data entry personnel

Flow of Events

Basic Flow

1. RMS/JMS data entry personnel at the agency enter demographic and charges data for the

booking into RMS/ JMS system. List of data elements that may be entered is documented

in Section 1 of ‘Data elements exchanged between RMSJMS and Livescan’

2. RMS/ JMS data entry personnel confirm data entry completed for transfer to agency

Livescan system

3. RMS/JMS system extracts and exports demographic, charges data and other associated

biometrics such as mugshots, Scars/Marks/Tattoos, iris and DNA coding available in the

RMS/ JMS associated to the booking activity. The biometrics may have been contributed

from subsystems as part of or interfaced to the JMS/RMS. These biometrics are to be

associated with the current booking activity)

4. Agency Livescan system accepts data from the RMS/ JMS system

5. Agency Livescan system performs any required validations and presents the data to the


6. Agency Livescan data entry personnel update any incorrect or missing information

required to be entered

7. Agency Livescan personnel capture biometrics at the Livescan device not extracted from

the RMS/JMS and subsystems such as mugshots, Scars/Marks/Tattoos, iris and Rapid

DNA

8. Agency Livescan data entry personnel save updated data in the appropriate system,

including images, for further processing (submission to the local, regional, state, tribal

agencies (ABIS) FBI(NGI) etc. as appropriate)

7 Note: The general use of the term Livescan device in the context of this document is for ease of reference. It is recognized that a Livescan device is the primary data entry point for capture of biometric, biographic and associated information that is collected by the device and then stored, in a local, state, regional, tribal or federal ABIS and other databases. The state – State Identification Bureau, is the state criminal history record repository and the state ABIS is interfaced with the state criminal history record repository.



9. Use case ends here

Alternative Flows

Step 5 of Basic Flow - Livescan system mandatory validations on data file fail

1. Agency Livescan system sends back an error to RMS/ JMS system of failed validations.

Examples of some of the validations - required fields missing, length of data in the field

is more than what the Livescan can accept, code value (such as hair color, eye, color,

POB) is not in the list of accepted values by the Livescan system

2. RMS/ JMS data entry personnel update required data and confirm data entry completed

for transfer to agency Livescan system

3. Use case continues at Step 3 of Basic Flow

Step 3 of Basic Flow - Workflow involves Livescan system personnel pulls data from

RMS/JMS

1. Agency Livescan data entry personnel at the agency enters identifying information for the

booked inmate (e.g. unique master name number, booking number)

2. Agency Livescan system sends query to RMS/ JMS system with identifying information

for the inmate

3. RMS/JMS system extracts and exports demographic, charges data and other associated

biometrics such as mugshots, Scars/Marks/Tattoos, iris and DNA coding available in the

RMS/ JMS associated to the booking activity. The biometrics may have been contributed

from subsystems as part of or interfaced to the JMS/RMS. These biometrics are to be

associated with the current booking activity

4. Use case continues at Step 4 of the Basic Flow

Pre-Conditions

Charged suspect has been booked

Post-Conditions

All data necessary from RMS/ JMS system for further processing beyond the agency Livescan

system has been imported and validated in agency Livescan system for submission to the state

ABIS and to NGI if appropriate.

Extension Points

None identified



Import Booking Data to RMS/JMS

Brief Description

This use case documents the functionality when an agency has entered demographic and charges

data into a Livescan system and exports it to a RMS/ JMS system to process the booking on that

side. The scope of the use case is to the point where the data is pulled up in a RMS/ JMS system

and updated for additional information.

Actors

RMS/JMS data entry personnel (data entry clerk, booking officer, etc.)

RMS/JMS system

Subsystems ( mugshot, iris, Rapid DNA)

Livescan system ABIS


State/ FBI – CJIS NGI system

Flow of Events

Basic Flow

1. Agency Livescan data entry personnel at the agency enter demographic and charges data

for the booking into Livescan system. List of data elements that may be entered is

documented in Section 1 of ' Data elements exchanged between RMSJMS and Livescan'.

2. Agency Livescan data entry personnel capture biometrics for the booked subject at the

agency Livescan station

3. Agency Livescan system sends biometric, demographic/ biographic and charges data for

further processing (submission to the local, regional, state, tribal agencies (ABIS)

FBI(NGI), etc. as appropriate)

4. Agency Livescan system extracts and exports the demographic/ biographic and charges

data from the state/NGI response

5. RMS/JMS system accepts the data from the agency livescan system

6. RMS/JMS system performs all required validations. Examples of some of the validations

- required fields missing, length of data in the field is more than what the RMS/ JMS

system can accept, code value (such as hair color, eye, color, POB) is not in the list of

accepted values by the RMS/ JMS system

7. RMS/ JMS system saves the booking data

8. RMS/ JMS system presents the booking data to the RMS/ JMS personnel

9. RMS/ JMS system forwards data and biometrics images to interface subsystems as

needed




Alternative Flows

Step 5 of Basic Flow - RMS/JMS system mandatory validations on data file fail

1. RMS/ JMS system sends back an error to Livescan system of failed validations

2. Agency Livescan data entry personnel update required data and confirm data entry

completed for transfer to state Livescan ABIS system


Pre-Conditions

Charged suspect has been booked

Post-Conditions

All data necessary for the RMS/ JMS system has been imported from the Livescan system.

Any subsystems associated with this booking activity has needed data imported to update records

associated with the booking activity.

Extension Points

None



Process Response from State

Brief Description

This use case documents the functionality when an agency has submitted biometric,

demographic and charges data to the State ABIS (State Identification Bureau) and/or FBI

(IAFIS/NGI) system, a response with relevant data is received back and forwarded to the RMS/

JMS system and all subsystems.

Actors

RMS/JMS system

Subsystem Mugshot iris, Rapid DNA

Livescan ABIS system

Local, regional, state ABIS/ NGI system

RMS/ JMS personnel

Flow of Events

Basic Flow

1. Agency Livescan system submits biometrics, demographic and charges data for further

processing to the local/ regional/ state agencies (ABIS), FBI(NGI) system

2. Agency Livescan system accepts response from the local/ regional/ state ABIS/ NGI

system

a. Note: The state – State Identification Bureau, sends back responses that provide

information about booking activity/event submitted to the state and the subject of

the booking activity. The response may come back in various formats. For

example, the response typically it is sent back via an “Administrative Message”

to what is typically a NCIC type terminal. It may also come back via designated

agency email, specific web portal or sent directly to the submitting agency

Livescan device. The message provides information about subject, and unique

identifiers about the event transaction that was submitted to the state. The unique

identifiers in the response should be used to tie the activity in the record with the

images to ensure data fidelity that ties the messages with the event and data

collected and submitted.

3. Agency Livescan system exports to the RMS/ JMS system, the local/ regional/ state

agencies (ABIS) FBI(NGI) / response data. List of data elements that may be exported is

documented in Section 2 of ' Data elements exchanged between RMSJMS and Livescan'.

4. RMS/JMS system accepts the data from the agency Livescan

5. RMS/ JMS system performs validation and updates (manual or automatic updates) to

include all subsystems – mugshot, iris, Rapid DNA




Alternative Flows

Step 4 of Basic Flow - RMS/JMS system automatically updates information based on

response from NGI/State ABIS system

1. RMS/ JMS system accept sends back an error to Livescan system of failed validations

2. Agency Livescan data entry personnel update required data and confirm data entry

completed for transfer to Livescan system


Step 2 of Basic Flow - NGI/ state ABIS does not return response via the Livescan but

instead via email, state CJIS system or some other method

1. RMS/ JMS system processes the alternate method of delivery and parses out the data


Pre-Conditions

Charged suspect has been booked, biometrics captured and agency Livescan system has

demographic and charge data updated

Post-Conditions

NGI and State ABIS response data has been processed to update booked inmate's data in the

RMS/ JMS system and all related subsystems.

Extension Points

None



APPENDIX C: DATA ELEMENTS

Livescan and RMS/JMS Exchange

1. Originating agency for the booking export (ORI)

2. Booking Number (RMS/ JMS tracking number)

3. Originating Agency Case Number (OCA)

4. Social Security Number

5. Name - last, first, middle

6. Aliases

7. Place of Birth

8. Country of Citizenship

9. DOB

10. Sex

11. Race

12. Height

13. Weight

14. Eye Color

15. Hair Color

16. Skin Tone

17. Scars, Marks, Tattoos

NCIC Code Table for LocationANSI/NIST Table 68 for Description

18. Photos available Y vs NO

19. Event Identifier

20. Biometric Set Identifier

21. FNU/Universal Control Number

22. SID Number

23. Transaction Control Number TCN

24. Transaction Control Reference Number TCR

25. Employer - Name and address

26. Occupation

27. School - Name and address

28. Residence street name

29. Residence street number

30. Residence street suffix

31. Residence street pre direction

32. Residence street post direction

33. Residence city

34. Residence state

35. Residence zip

36. Residence phone number



37. Arresting county

38. Date of Arrest

39. Date Printed

40. Arresting officer

41. Booking agency

42. Date of Offense

43. Offense (charge) code

44. Offense (charge) description

45. Court charge disposition

46. Court of jurisdiction - Name and address

47. Warrant number (if one involved in booking)

48. Offender ID number (for agency)

49. Fingerprint Reason

50. Fingerprinting officer

51. Was there firearm possession

52. Was arrest due to domestic disturbance

53. Any notes or comments

NGI/State ABIS Response Data Elements

The following NGI - State ABIS response data elements sent to the agency Livescan system, sent

via an email response to the agency, or sent to the agency via "Administrative Message" are

exported by to RMS/ JMS system and subsystems – State and local User Defined Fields sent to

NGI are also returned.

1. Were fingerprints identified - Identification/ Non-Identification response decision

2. FBI identification number/Universal Control Number (FNU/UCN) - Unique number

assigned for established criminal and civil identities to the record associated with

biometrics submitted by the State Identification Bureau and then retained by NGI

3. State identification number (SID) - Unique number for the record associated with the

biometrics submitted to the State Identification Bureau

4. Transaction Control Number – Unique number assigned to the booking event once

submitted and received at the State Identification Bureau. Note - NGI takes the state

TCN and places it in the TCR field. NGI creates their own TCN for transactions

received at NGI

5. Transaction Control Number Reference Number – Unique FBI supplied number

applied when biometric submission from the State Identification Bureau reaches NGI

and is transmitted back by NGI to the agency

6. Local agency supplied data, OCA, Booking number should be validated and is

returned to submitting agency

7. Event Identifier (EVI) - Unique number assigned to the event when it was received at

NGI (arrest/ booking). This numeric field is used to identify a specific biometric



enrollment event for an identity such as a date of arrest or date printed. A single EVI

may encompass multiple BSIs, if more than one biometric set is enrolled for the event

8. Biometric Set Identifier (BSI) - Numeric field that is used to identify a specific

biometric enrollment event for an identity. A single EVI may encompass multiple

BSIs, if more than one biometric set is enrolled for the event. The BSI

uniquely identifies each biometric image set or photo, such as a facial photo, a

fingerprint set, a palm print set, or a supplemental print set.



APPENDIX D: NGI ADDITIONAL HISTORY, BACKGROUND, AND INTERFACE NUANCES

The general use of the term Livescan device in the context of this document is for ease of

reference. It is recognized that a Livescan device is the primary data entry point for capture of

biometric, biographic, and associated information that is collected by the device and then stored,

in a local, state, regional, tribal, or Federal ABIS and other databases. The state – State

Identification Bureau (SIB) – is the state criminal history record repository and the state ABIS is

interfaced with the state criminal history record repository.

The term state is used interchangeably in the document in this regard. To describe the work flow

for the context of this document, authorized local and state arresting/booking agencies submit

biometric, biographic, event, and charge data to the state ABIS – SIB. The Livescan which used

to be the primary electronic data entry point for booking data to submitted to the state and NGI

has transitioned; now, data may be imported from a JMS/RMS interface and there may be

systems interfaced to the JMS/RMS such as a mugshot or iris system.

Once the data is submitted via the Livescan device, it may update a local ABIS but, at a

minimum, it is connected to the state ABIS and SIB. Once submitted, if a match occurs with the

biometric data (fingerprints are primary) submitted along with other biometric modalities, the

ABIS and SIB provide an identification match or non-identification based on the fingerprint

submission. The submission either updates an existing record or creates new criminal history

record.

If there is no identification at the SIB by the ABIS, if authorized, the SIB will transmit the data

to NGI for an identification/non-identification decision. If there is an identification match NGI

will respond back to the SIB with the information it holds on the matching biometrics and/or

what other state may hold the information for the subject. If no identification is made, the state

may direct NGI to create a new record to establish a criminal history record for the subject.

The SIB receives information back from NGI or if it is just a state submission only, the state

communicates the information back to the original contributing agencies so they can update their

agency records associated with subject.

The FBI-CJIS NGI System and the SIB create and/or provide unique identifying data fields to be

able to link what information was submitted to each entity for record linking. The return of these

data fields is to enable data integrity so information can be associated between what was

submitted from the contributing agency with what information was returned. In addition to

information in unique identifying data fields the SIB and NGI typically return state or local

agency applied fields that may or may not be stored at the SIB or NGI, such as the transaction

control numbers or agency booking number.



APPENDIX E: REQUIREMENT TRACEABILITY

BUSINESS

REQ NO.

BUSINESS REQUIREMENT

NAME/DESCRIPTION

FUNCTIONAL

REQ NO.

FUNCTIONAL REQUIREMENT

PROSPECTIVE SOLUTION

1=Neither enables or disables functionality

2=Enables Functionality

NAME/DESCRIPTION NIEM Interface

Solution8

BR-1 The standard will enhance

functionality to the end-user and

reduce procedural burdens through

interoperability

1-FR-1 The standard/solution must be workflow

agnostic for intake processing

1 2

1-FR-1.1 Allow the intake workflow to be initiated

by RMS

1 2


by JMS

1 2


by the livescan

1 2

1-FR-2 The standard/solution will update

subsystems with the most current data

1 2

1-FR-3 Configurable to assign which system

contains the master data

1 2

1-FR-4 Configurable to update other systems

with most current data

1 2

1-FR-5 Trigger other subsystems to initiate

updates when a data update takes place

1 2

1-FR-6 The standard/solution will have

undefined data fields

2 1

8 MULE Enterprise Service Bus (ESB), Global Reference Architecture (GRA) and Mirth were used for requirement fulfillment evaluation as prospective solutions.



BUSINESS

REQ NO.


NAME/DESCRIPTION

FUNCTIONAL

REQ NO. FUNCTIONAL REQUIREMENT




1-FR-7 Data fields available in the standard will

allow custom data fields

2 1

1-FR-8 Data can be converted from one system to

the other

2 1

1-FR-9 There will be a configurable data

translator

1 1

BR-2 The standard will adapt to data

formats and standards used by

upstream or downstream processing

2-FR-1 The standard shall be configurable to

address individual agencies system needs

2 2

2-FR-2 Shall adapt to each agencies sub-system

configuration

2 2

2-FR-3 The standard shall allow adaptation for

systematic changes

2 2

2-FR-4 Changes can be made to onboard new or

replacement subsystems.

2 2

BR-3 The standard will be transparent to

practitioners and vendors who

implement and support the system

3-FR-1 The standard/solution will be supported

by training and documentation

2 2

3-FR-2 The standard/solution will be documented 2 2

3-FR-3 Documentation will allow staff to create

adapters that maintain the standard

2 2

3-FR-4 Training will be available to service

providers and agency staff

2 2

3-FR-5 Training will be available both online and

in-person

2 2



BUSINESS

REQ NO.


NAME/DESCRIPTION

FUNCTIONAL

REQ NO. FUNCTIONAL REQUIREMENT




3-FR-6 Training shall be at no cost to the

implementing agency

2 1

3-FR-7 Implementing the standard will not hinder

the end-users workflow

1 2

BR-4 The standard will be continually

enhanced as subsystems and related

technologies emerge and improve

4-FR-1 The regulatory institution will provide

updates to the standard to meet system

requirements

2 2

4-FR-2 The standard will support updated

platform and related upgrades

2 2

BR-5 The standard will reduce effort

required to implement new systems

and subsystems resulting in cost

savings

5-FR-1 The standard/solution must reduce

implementation time

2 2

5-FR-2 Allow for repeatable implementations 2 2

BR-6 The standard must have common

data and definition that are

predominantly used in systems

6-FR-1 The standard must create common data

definition

2 1

6-FR-2 Have all common data elements within

JMS

2 1


RMS

2 1


Livescan

2 1

6-FR-5 Data transferred between sub-systems in

industry standard languages, i.e. xml.

2 1



APPENDIX F: ACRONYMS AND ABBREVIATIONS

ACRONYM OR

ABBREVIATION DEFINITION

ABIS Automated Biometric Identification System

ANSI American National Standards Institute

APCO Association of Public-Safety Communications Officials

AVL Automatic Vehicle Location

BJA Bureau of Justice Assistance

BSI Biometric Set Identifier

CAD Computer-aided Dispatch

CFS Call for Service

ConOps Concept of Operations

DMV Department of Motor Vehicles

EIDD Emergency Incident Data Document

EMD Emergency Medical Dispatch

EMS Emergency Medical Services

ERDG Emergency Response Design Group

EVI Event Identifier

FBI Federal Bureau of Investigation

FirstNet First Responder Network Authority

GIS Geographic Information System

GRA Global Reference Architecture

HL7 Health Level 7

IACP International Association of Chiefs of Police

IAFIS Integrated Automated Fingerprint Identification System (FBI)

IEPD Information Exchange Package Documentation

III ( or Triple I) Interstate Identification Index (FBI)

LEITSC Law Enforcement Information Technology Standards Council (IACP)

LPR License Plate Reader

LTE Long-Term Evolution

MDC Mobile Data Computer

NCIC National Crime Information Center (FBI)

N-DEx National Data Exchange

NENA National Emergency Number Association

NG9-1-1 Next Generation 9-1-1

NGI Next Generation Identification (Replaced IAFIS)

NIEM National Information Exchange Model

NLECTC National Law Enforcement and Corrections Technology Center

Nlets The International Justice & Public Safety Network

NOBLE National Organization of Black Law Enforcement Executives

NSA National Sheriffs' Association

PDA Personal Digital Assistant

PERF Police Executive Research Forum

PSAP Public Safety Answering Point

PSDI Public Safety Data Interoperability

RFP Request For Proposal

RMS Records Management Systems

SEARCH National Consortium for Justice Information and Statistics

SRE Submission Results Electronic

Task Force RMS/JMS/Livescan Task Force

TCN Transaction Control Number



ACRONYM OR

ABBREVIATION DEFINITION

TCR Transaction Control Reference

SID State Identification Number

UCN Universal Control Number

APPENDIX G: TERMS AND DEFINITIONS

TERM DEFINITION

Adaptability Ability to change a system or component of a system to incorporate

systematic changes.

Biometric Set Identifier (BSI) Unique numeric field will be used to identify a specific biometric enrollment

event for an identity. A single EVI may encompass multiple BSIs, if more

than one biometric set is enrolled for the event. The BSI will

uniquely identify each biometric image set or photo, such as a facial photo, a

fingerprint set, a palm print set, or a supplemental print set.

Event Identifier (EVI) Unique Number assigned to the event when it was received at NGI

(arrest/booking). This numeric field will be used to identify a specific

biometric enrollment event for an identity such as a date of arrest or date

printed. A single EVI may encompass multiple BSIs, if more than one

biometric set is enrolled for the event.

Federated System Pattern in enterprise architecture that allows interoperability and information

sharing between semi-autonomous de-centrally organized systems and

applications. [Wikipedia]

Health Level 7 (HL7) A set of international standards for transfer of clinical and administrative

data between Hospital information systems.

Interface Solution An Interface Solution is a term used to refer to a kind of middleware, e.g.

MULE ESB, standards based framework, and web services, which can be

used to transform, route, clone and translate messages.

Interoperability Ability of making systems and organizations work together (inter-operate).

Service Oriented Architecture

(SOA)

A loosely-coupled architecture designed to meet the business needs of the

organization. [MSDN Network, SOA]

State Identification Number

(SID)

Unique number assigned to a criminal identity at a State Identification

Bureau. This number may have a different name/label used by each states.

Submission Results Electronic

(SRE)

EBTS Transaction response from NGI that provides information about the

subject whose biometrics have been submitted for a state or local agency for

an identification search transaction.

Transaction Control Number

(TCN)

Unique number assigned to a request by the State Identification Bureau

(SIB) and NGI when a submission is received. Each assigns a unique

number. NGI returns the SIB TCN in the Transaction Control Reference

Field. States may return their TCN back to the local agency in the TCN field

and not the TCR.

Transaction Control Reference

(TCR)

EBTS Field that returns the original TCN from the State Identification

Bureau to the submitting agency.

http://en.wikipedia.org/wiki/Enterprise_architecture

http://en.wikipedia.org/wiki/Hospital_information_systems



Transactional System Transaction processing systems consist of computer hardware and software

hosting a transaction-oriented application that performs the routine

transactions necessary to conduct business. [Wikipedia]

Transparency A system operating in such a way that it is easy for others to see what and

how actions are performed.

Universal Control Number

(UCN)

Assigned to criminal and civil identities by the FBI CJIS Division Next

Generation Identification System upon the authorized submission of

fingerprint records. This number is replacing the FBI Number (FNU).



APPENDIX H: REFERENCES

Brown, R. (2014, August). Sr. Systems Integrator. (M. Johnson, Interviewer) Dave Evans. (2011, April). The Internet of Things How the Next Evolution of the Internet is

Changing Everything. Retrieved October 22, 2014, from Cisco: http://www.cisco.com/web/about/ac79/docs/innov/IoT_IBSG_0411FINAL.pdf

None. (2010, Febuary). Open-Source Software. Retrieved October 22, 2014, from

Wikipedia: http://en.wikipedia.org/wiki/Open-source_software None. (2012). FBI Biometric. Retrieved October 28, 2014, from Federal Bureau of

Investigations: https://www.fbibiospecs.org/ebts.html None. (2014, October 1). About W3C. Retrieved October 22, 2014, from World Wide Web

Consortium: http://www.w3.org/Consortium/ None. (2014, October 9). Conway's Law. Retrieved November 7, 2014, from Wikipedia:

http://en.wikipedia.org/wiki/Conway%27s_law None. (2014, January 31). National Institute of Standards and Technology, General

Information. Retrieved October 28, 2014, from National Institute of Standards and Technology: http://nist.gov/public_affairs/general_information.cfm

None. (2014, February 5). Presidential Measurement Timeline. Retrieved October 22, 2014,

from National Institute of Standards and Technology: http://www.nist.gov/pml/wmd/metric/presidential-measurements-timeline.cfm

None. (2014, December 4). Tribal Knowledge. Retrieved December 15, 2014, from

Wikipedia: http://en.wikipedia.org/wiki/Tribal_knowledge None. (n.d.). Health Level Seven International. Retrieved October 22, 2014, from HL7 Intl.:

http://www.hl7.org/ None. (n.d.). Interoperability. Retrieved October 22, 2014, from Wikipedia:

http://en.wikipedia.org/wiki/Interoperability None. (n.d.). Service Oriented Architecutre (SOA). Retrieved October 22, 2014, from

Microsoft Developers Network: http://msdn.microsoft.com/en-us/library/bb833022.aspx

Date post:	14-Apr-2017
Category:	Documents
Upload:	matt-johnson
View:	272 times
Download:	0 times

IJIS RMS_JMS_LS Task Force Recommendations v1_4

Documents