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

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]

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

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

APPENDIX A: PRIMARY WORKFLOWS
Livescan Workflow Use Case 1
Export Booking Data from RMS/JMS
LivescanRMS/JMS State/County/NGI
Phase
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
Photo/SMT
Save Person
Information and
Send to State/NGI
and Sub-Systems
Enter/Update
Person Information
Process Person
Information

Import Booking Data from Livescan to RMS/JMS
LivescanRMS/JMS
State/County/NGI
Enter/Update
Person Information
and Confirm
Standard
Exchange of
Person
Information
IEPD
Extract Person
Information
Consume Person
Information and
Validate
Capture Biometrics
Photo/SMT
Save Person
Information and
Send to Sub-Systems
Enter/Update
Person Information
Process Person
Information
Photo/SMT

Process State and FBI Response
LivescanRMS/JMS
State/County/NGI
Standard
Exchange of
Response
Information
IEPD
Consume Response
Information and
Validate
Save Response
Information
Process Person
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
Agency Livescan data entry personnel
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
 Agency Livescan data entry personnel
 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.
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.
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.

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

IJIS RMS_JMS_LS Task Force Recommendations v1_4

Recommended

Recommended

More Related Content

Similar to IJIS RMS_JMS_LS Task Force Recommendations v1_4

Similar to IJIS RMS_JMS_LS Task Force Recommendations v1_4 (20)

IJIS RMS_JMS_LS Task Force Recommendations v1_4