F-548(5)_Attch_G.doc

Attachment G: Livescan Interface Control Document Version 2.0 (ICD)

State of Minnesota

Department of Public Safety

Bureau of Criminal Apprehension

MNJIS Section

Livescan

Interface Control Document

Version 2.0

TABLE OF CONTENTS

31.

INTRODUCTION

1.1 Purpose 1.2 Basic Data Flow 1.3 References 2.

INTERFACE SPECIFICATIONS

2.1 Relationship to FBI NIST EFTS 7.1 2.2 Types of Transactions 2.3 CRIMINAL IDE and CRIMINAL IDE RESUBMIT REQUEST 2.4 IDENT ONLY and VERIFY ONLY REQUEST 2.5 CRIMINAL IDE and CRIMINAL IDE RESUBMIT REPLY 2.6

CIVIL BACKGROUND REQUEST

2.7 Notes on Error Handling 3.

BioID DATA DEFINITIONS 3.1 Header Fields (equivalent to Type-1 record) 3.2 Demographic and Charging Fields (equivalent to Type-2 record) 3.3 IDE Transaction Request XPath Mapping 3.4 IDE Response XPath Mapping 3.5 IDE Resubmit Request Transaction XPath Mapping 3.6 IDE Resubmit Response Transaction XPath Mapping 3.7 IDOnly Request XPath Mapping 3.8 IDOnly Response XPath Mapping 3.9 RapidID (TFS) Request XPath Mapping 3.10 RapidID (TFS) Response XPath Mapping 3.11 Civil Background Check Request XPath Mapping 3.12 Civil Background Check Response XPath Mapping 3.13 Rolled Images (equivalent to Type-4 record) 3.14 Photo Images (equivalent to Type-10 record) 3.15 Flat Images (equivalent to Type-14 record) 3.16 Palmprint Images (equivalent to Type-15 record) Appendix B – Lists of Values Appendix C – Charge and Hold Purposes

1. INTRODUCTION

1.1 Purpose

This document defines the interface between Livescan devices providing data to the Minnesota Bureau of Criminal Apprehension (BCA) Biometric Identification (BioID) Server.

BioID is a software solution that enables biometric-related transactions to be processed among appropriate criminal justice applications. Its two major components are message handling and workflow management. BioID typically stores no data of its own; rather, it facilitates and coordinates biometric transactions between criminal justice applications. BioID also provides data validation and translation capabilities allowing applications to communicate transparently.

1.2 Basic Data Flow

The LiveScan operator enters demographic data, rolls the arrestee’s/applicant’s fingerprints, and optionally takes palm prints and arrest photos. Once the data is entered, the operator electronically submits the various biometric images and arrest data to the BioID at the BCA, which sends an acknowledgement of receipt, then processes it. BioID interfaces to various subscribers: internal BCA applications (Criminal History System, AFIS, Minnesota Repository of Arrest Photos (MRAP), Livescan Messaging Enhancements (LME), Archive) and external agencies (FBI), as needed. BioID, in turn, sends the combined results from multiple subscribers back to the LiveScan operator and LME. If previously sent data is resubmitted later, the response data lets the BCA know that the originator is attempting to update previously sent data.

The following chapters describe the interface in greater detail.

1.3 References

· Criminal Justice Information Services (CJIS) Electronic Fingerprint Transmission Specification (EFTS); CJIS-RS-0010 (V7.1); May 2005

2. INTERFACE SPECIFICATIONS

2.1 Relationship to FBI NIST EFTS 10.1

As the format of the requests and replies between Livescans and BioID is XML, the field identifiers (acronyms), field numbers, and references to Type-1, Type-2, etc. from the FBI’s EFTS 10.1 are used here for reference only.

2.2 Types of Transactions

BioID accepts only the following transactions from Livescans:

· CRIMINAL IDE

REQUEST

· CRIMINAL IDE RESUBMIT REQUEST

· IDENT ONLY REQUEST

· VERIFY ONLY REQUEST

· CIVIL BACKGROUND REQUEST

Livescans accept only the following transactions from BioID:

· CRIMINAL IDE REPLY

· CRIMINAL IDE RESUBMIT REPLY

· IDENT ONLY REPLY

· VERIFY ONLY REPLY

· CIVIL BACKGROUND REPLY

The Types of Transactions (TOTs) are defined in the following sections.

2.3 CRIMINAL IDE and CRIMINAL IDE RESUBMIT REQUEST

These transactions represent a criminal arrest fingerprint submission for which the requester desires a response. A Livescan submits one or more CRIMINAL IDE requests until the BCA accepts and commits the data to its AFIS and CCH databases. Further updates to the booking including improved images and/or data are accomplished via CRIMINAL IDE RESUBMIT requests. Both TOTs contain various images, subject demographics and information relative to an arrest or to custody or supervisory status as follows:

· Header Information (equivalent to Type‑1 record)

· Demographics and Arrest Data (equivalent to Type‑2 record)

· 14 Rolled and Plain (Flat) Images (equivalent to Type‑4 records)

· (Optional) up to 99 Mug Shot Images (equivalent to Type-10 records)

· (Optional) 6 Palm Print Images (equivalent to Type-15 records)

2.4 IDENT ONLY and VERIFY ONLY REQUEST

These transactions represent an attempt by a local agency to identify the fingerprints of a subject. IDENT ONLY attempts to establish the identification of the subject by comparing fingerprints to the criminal database of fingerprints (AFIS) at the BCA. VERIFY ONLY is similar, however the request includes a presumed identification field and asks the BCA to verify the identification of the subject against the AFIS database. Both TOTs contain one of the following fingerprint combinations:

· Header Information (equivalent to Type‑1 record)

· Limited Demographics Data (equivalent to Type‑2 record)

· (2 Finger) 2 Plain (Flat) Images (equivalent to Type‑14 records)

· (4 Finger) 2 Plain (Flat) Images (equivalent to Type‑14 records)

· (10 Finger) 3 Plain (Flat) Images (equivalent to Type‑14 records)

2.5 CRIMINAL IDE and CRIMINAL IDE RESUBMIT REPLY

These transactions are returned by BioID as a result of a CRIMINAL IDE (or RESUBMIT) REQUEST to indicate the Ident/Non-Ident decision of the Minnesota AFIS. Both TOTs contain the following:

· Header Information (equivalent to Type‑1 record)

· Results, Status and Messages (equivalent to Type‑2 record)

These replies include a Transaction Result field from BioID with the following possible values:

· SUCCESS – the request has resulted in the enrollment (or replacement) of the fingerprints in the AFIS database and demographics and arrest data in the CCH database. No further input for this arrest/custody is required.

· ACCEPTED WITH ERROR(S) – the request has resulted in the enrollment (or replacement) of the fingerprints in the AFIS database and demographics and arrest data in the Criminal History System. A further submission to improve the fingerprints and/or data is requested.

· REJECTED – the request has NOT resulted in the enrollment (or replacement) of the fingerprints in the AFIS database and demographics and arrest data in the Criminal History System. A further (re-)submission to improve the fingerprints and/or data is required.

· ACKNOWLEDGEMENT – BioID has acknowledged the successful receipt of the request. Another reply indicating SUCCESS (or otherwise) is pending.

· MANUAL REVIEW – AFIS informs the Livescan operator (via BioID) that the request requires human intervention to discern the identity of the subject and will take longer than a lights-out transaction. This result does not apply to resubmissions.

· TECHNICAL ERROR – BioID informs the Livescan operator that a technical error occurred with the transaction. The error message will indicate what action to take next.

No booking is resubmitted to BioID until a SUCCESS, ACCEPTED WITH ERROR(S), REJECTED, or TECHNICAL ERROR response from the initial request has been returned.

2.6 CIVIL BACKGROUND REQUEST

These transactions represent an attempt by a local agency to identify the fingerprints of a subject for civil purposes (e.g. employment, housing, membership, etc.) and to determine if a relevant criminal history exists for the subject. A CIVIL BACKGROUND REQUEST attempts to establish the identification of the subject by comparing fingerprints to the criminal database of fingerprints (AFIS) at the BCA. The TOT contains one of the following fingerprint combinations:

· Header Information (equivalent to Type‑1 record)

· Limited Demographics Data (equivalent to Type‑2 record)

· (2 Finger) 2 Plain (Flat) Images (equivalent to Type‑14 records)

· (4 Finger) 2 Plain (Flat) Images (equivalent to Type‑14 records)

· (10 Finger) 3 Plain (Flat) Images (equivalent to Type‑14 records)

2.7 Notes on Error Handling

BioID will return two separate data structures for errors from CHS and AFIS respectively.

The CHS structure can occur 20 times and includes a field number, an occurrence number (if applicable), and a description of the error. Note that occurrence numbers start with 1, not 0.

· Example: 15, null, “Subject’s sex code was not specified.”

The AFIS structure can occur up to 10 times for IDE submissions and resubmissions and includes an array of finger numbers that require re-rolling. Note that there is error message currently specified to match the array. Is this needed?

· Example: 2, 4, 9 Submissions involving less than 14-image full rolled prints (i.e. two fingers, four fingers, and ten finger flats) should automatically require all images to be resubmitted with a REJECTED Transaction Result.

3. BioID DATA DEFINITIONS

The following describes all of the fields used by all transaction types between Livescans and the BCA’s BioID.

3.1 Header Fields (equivalent to Type-1 record)

· CRIMINAL IDE REQUEST

· CRIMINAL IDE RESUBMIT REQUEST

· IDENT ONLY REQUEST

· VERIFY ONLY REQUEST

· CIVIL BACKGROUND REQUEST

Livescans accept only the following transactions from BioID:

· CRIMINAL IDE REPLY

· CRIMINAL IDE RESUBMIT REPLY

· IDENT ONLY REPLY

· VERIFY ONLY REPLY

· CIVIL BACKGROUND REPLY

M

3.2 Demographic and Charging Fields (equivalent to Type-2 record) Legend

· In some cases, a group of fields may be optional, but when the group is used, some fields within the group become mandatory.

· In other cases, a field is mandatory as a result of another field or a field is mandatory as a result of a particular Profile being selected.

· In one case, one of two fields is mandatory but not both.

· Null values should not prevent the Gen 4 Livescan from submitting the booking.

· Non-null values should be edited to ensure valid data and the Gen 4 Livescan should not allow the booking to be submitted otherwise.

Field Name

EFTS Ref and

Gen 4 Format

(all responses)

AN10

O

O

AN12

IDE: Only applies if passed to Livescan by local JMS. Does not apply to resubmissions. UI Edit(s): None, the field does not appear in the IDE UI.

IDV: The Livescan operator must specify either a Reported SID or a Reported LID in the IDV UI, but not both. Does not apply to TFS.

UI Edit(s): Existing SID values are 10 characters in the format ‘MNYY999999’ or ‘MNJY999999’. New SID values are expanded, explicitly indicate Adult vs. Juvenile, and include a check digit in the format ‘MNAYY999999C’ or ‘MNJYY999999C’.

The BCA owes Identix a check digit algorithm for 12-character values.

O

M

AN11

M

AN10 or

AN12

IDE: Will always be valued for SUCCESS and ACCEPTED; not valued for REJECTED.

IDE RESUB: Always included in these replies as the subject of the booking has already been identified.

ID ONLY: Will have a value if SRF = ‘H’ or ‘NM’; will be null if SRF = ‘N’.

CIVIL: SID is not returned to the Livescan, even for SUCCESS.

UI Edit(s): None; cannot be input or modified by the LS operator.

C

C

AN10 or

AN12

C

C

AN15

O

O

N9

UI Edit(s): The UI presents two fields to the operator. The first field is a LOV (two-character codes). The second field is a free-form alphanumeric field which must have a minimum of two characters. In addition, the values AF and AS in the code field should result in only numeric characters in the second field.

M

M

M

O

O

AS30

TFS and IDV replies will only include a single DOB value.

UI Edit(s): All Dates of Birth must be prior to the Date Printed, less than 100 years ago, and prior to all Offense Dates. Format is CCYYMMDD. The Livescan should warn (but not otherwise prevent submission) of a subject with duplicate primary or alias DOBs.

M

ANS254

UI Edit(s): The field is no longer needed in the UI; default to “Y” and transmit to the BCA.

Default(s): Originating Agency ORI (1.08) but can be changed.

Field Names: Normally ‘Confinement Start Date’. If charges include Interstate Transfer for Probation (and no other Custodial Charge Purposes) then ‘Probation Start Date’.

UI Edit(s): The Supervisory Status Date must be on or before the Date Printed. Format is CCYYMMDD. This date can be in the future if and only if all custodial charges on the booking have the Consecutive Indicator turned on (“Y”). Since Interstate Transfer for Probation and PSI charges do not allow a “Y” value for the Consecutive Indicator; the presence of these charges preclude the Supervisory Status Start Date from being in the future for the booking.

Field Names: If charges include Custodial or Confinement, then ‘Confinement Comments’. If charges include Probation (and not Custodial and not Confinement), then ‘Probation Comments’.

UI Edit(s): Free-form text.

CIVIL: Not returned to the Livescan.

UI Edit(s): None; not input by the LS operator.

ANS300

M

O

M

M

UI Edit(s): As each booking is started, the operator is asked to enter a userid. The input value is validated against the User table and the full name of the operator is entered in this field for transmission to the BCA. The UI should hide the value of the fingerprint official from view i.e. treat like a password “********”.

M

UI Edit(s): The user interface should reflect that the entry of driver’s licenses OR state identification card numbers are allowed in this field.

C

C

M

M

Default(s): Originating Agency ORI (1.08) but can be changed.

M

M

UI Edit(s): LOV. If Charge Purpose is Custodial (but not Interstate Transfer for Probation), then the only ORI values allowed to be displayed in the interface and sent to the BCA end with the letter “C”.

Note: FBI allows multiple values; MN allows only one per charge.

Default(s): If Charge Purpose is Custodial, POR, or Fugitive, then Jurisdiction defaults to “M”. If Charge Purpose is Interstate Transfer (Probation or Confinement) then Jurisdiction defaults to “M”. These defaults cannot be changed.

UI Edit(s): LOV.

Default(s): If Charge Purpose is Fugitive, then Statute Offense = 629.13. If Charge Purpose is POR then Statute Offense = 243.166. These defaults cannot be changed. (Default the ChapterSection value and make the Subdivision dropdown read-only.)

ANS60

N8

UI Edit(s): N8

1. If there is a known DOO, compare it to the Primary DOB (first entered).

a) Set the Juvenile Flag to “Y” if the difference is less than 18 years; the flag setting cannot be changed.

b) Set the Juvenile Flag to “N” if the difference is 18 years or greater; the flag setting cannot be changed.

2. If the DOO is null, compare today’s date the DOA to the Primary DOB (first entered).

a) Set the Juvenile Flag to “Y” if the difference is less than 18 years; the flag setting cannot be changed.

b) Set the Juvenile Flag to “N” if the difference is 18 years or greater; the flag setting can be changed. (The investigator does not have a specific DOO but knows that the subject was a juvenile when the offense occurred.)

UI Edit(s): Checkbox or radio buttons (“Y” or “N”).

AN50

UI Edit(s): For Charge Purpose = Custodial, Interstate Transfer for Probation and Interstate Transfer for Confinement, mandatory LOV with values “F”, “G”, or “M”. For all other Charge Purposes, the field is derived from the CriMNet Statute Service with values “F”, “G”, and “M”, “J”, “P” or null.

Field Names: If Probation, the label of the field in the UI should be ‘Probation Length’.

UI Edit(s): format is “YYMMDDD” where “YY” is the number of years, “MM” is the number of months, and “DDD” is the number of days in confinement; zero-filled.

Default(s): For PSI, the Confinement Length is set to 000, 00, 000 and cannot be modified.

UI Edit(s): Checkbox (“Y” or “N”), default not checked.

UI Edit(s): Free format; no spaces.

If Hold Purpose is custodial, i.e. DOC, then the only ORI values allowed to be displayed in the interface and sent to the BCA end with the letter “C”.

UI Edit(s): Checkbox (“Y” or “N”), default not checked.

UI Edit(s): None, not entered by LS operators.

UI Edit(s): None, not entered by LS operators.

UI Edit(s): None, not entered by LS operators.

O

M

M

M

M

The MATCH Request Barcode ID provides a link to the demographic data held in the BCA’s MATCH database, relieving the operator from entering those fields.

UI Edit(s): In case the Barcode cannot be read by the reader, the operator must be allowed to enter this number via the keyboard. Format of the field TBD.

3.3 IDE Transaction Request XPath Mapping

**prefix0 = mnbioid:mn-bioid / mnbioid:Request / mnbioid:IDE / mnbioid:Request

Field Name

(CCH Field Num) XPath

Mapping XML Data Type

3.4 IDE Response XPath Mapping

**prefix = mnbioid:mn-bioid / mnbioid:IDE / mnbioid:Response

Field Name

(CCH Field Num) XPath

Mapping XML Data Type

Note: <TRR> is token which has a real values as: SUCCESS, REJECTED, ACCEPTED, MANUAL-REVIEW, and TECHNICAL-ERROR

3.5 IDE Resubmit Request Transaction XPath Mapping

**prefix0 = mnbioid:mn-bioid / mnbioid:Request / mnbioid:IDE / mnbioid:Request

Field Name

(CCH Field Num) XPath

Mapping XML Data Type