F-548(5)_Attch_F_Technical_Specifications_and_Responses.xlsx
XLSX spreadsheet 258 KB Posted
- Attached to
- Livescan Machines
- Solicitation number
- 2000016267
- Issued by
- Aitkin County, Minnesota
About this file
This is a technical specifications document detailing requirements for Livescan fingerprinting devices and systems for the Minnesota Bureau of Criminal Apprehension (BCA). The document outlines comprehensive technical requirements for fingerprint and palm print capture devices, including hardware specifications for 1000 ppi resolution scanning, software functionality, data transmission protocols, printer specifications, and centralized management capabilities. Key requirements include the ability to capture rolled and flat fingerprints, palm prints, and demographic data, along with integration with the BCA's Automated Biometric Identification System (ABIS) and Criminal History System. The system must support multiple booking profiles including criminal, civil, and training purposes, with devices to be delivered and installed within 30 days of order acceptance.
The specifications require vendors to provide maintenance plans with 24/7 support, including one-hour response times and next-business-day onsite support when needed. Security requirements mandate FIPS 140-2 encryption compliance, FBI CJIS Security Policy adherence, and implementation of multifactor authentication. The system must support both networked and standalone operations, with devices being able to store and forward transactions when network connectivity is restored. Centralized management capabilities must include user administration, software updates, and reporting functions. While specific pricing terms are not detailed, the document indicates that delivery and installation costs must be included in the price schedule.
View the file
Other files
| File | Type | Posted |
|---|---|---|
| F-548(5)_Attch_C_Sup_1_Price_Schedule.xlsx | XLSX spreadsheet | |
| F-548(5)_RFP_SampleContractandExhibits.pdf | ||
| F-548(5)_addendum1.docx | DOCX document | |
| D3_F-548_rfp_Attachments_A-E.docx | DOCX document | |
| RFP_Attachment_H_-_Fingerprint_Card_Redacted.pdf | ||
| F-548(5)_Attch_I_LiveScan_Locations_and_Configurations.docx | DOCX document | |
| D3_F-548(5)_rfp.docx | DOCX document | |
| F-548(5)_Attch_G.doc | DOC document | |
| Livescan_Machines.pdf | ||
| F-548(5)_addendum2-12.27.2024.docx | DOCX document |
On GovTribe
Work with this file
- Download the original file
- Contacts named in this file
- Similar government files
- Ask GovTribe AI about this file
Text version
Sheet1
| Company Name: | |||||||
| Complete the sections below. If needed, you may upload brochures, screenshots, photos, etc. These must be clear, easy to understand, and labeled appropriately. Please include this additional documentation in a separate document attached to your proposal. In the separate document, you must clearly note which specification the diagram, description, or additional documentation relates to. Within the response section below, provide the location of where the additional documentation may be found in your proposal. | |||||||
| Responses are to be prepared and presented in the same sequential order as the presented in this document. If a feature or benefit of your product falls into more than one of the following components/capabilities, include it in both areas. | |||||||
| Mandatory Requirements | Desired Capabilities | ||||||
| Yes/No | Instructions: Provide a "yes" or "no" response and a description of your proposed solution’s components/capabilities. | Yes/No | Instructions: Provide a "yes" or "no" response. Provide additional information for services, features or other relivant information in the space provided. | ||||
| Livescan Devices | |||||||
| Image Capture | |||||||
| 1 | Image Capture | ||||||
| Issue | Livescan has features to protect the quality of the images that it captures. | ||||||
| Description | 1.1 | Solution allows operators to view images as they are captured in real time and without modification or warping. | M | ||||
| 1.2 | Slap fingerprints are captured prior to rolled fingerprints and solution compares rolled fingerprints to slap fingerprints after each roll to avoid incorrect sequencing of fingerprints. | M | |||||
| 1.3 | Images captured at a solution device cannot be removed, modified and replaced using anything other than the Livescan device and software. | M | |||||
| 1.4 | In most circumstances, solution is tolerant of moist, wet, or dry skin when capturing images. | M | |||||
| 1.5 | Solution allows flexibility in the direction the fingerprint is rolled, right to left or left to right at the operator’s speed without changing settings. | M | |||||
| 1.6 | In most circumstances, solution is tolerant of residual oil and dirt when capturing images; residual oil and dirt does not cast images. | M | |||||
| 1.7 | Rolled fingerprints, palm prints, and flat fingerprints shall be part of the image capture. Responders are to detail in their response if these fingerprints can be done in one capture instance, or if each type of fingerprint must be captured in separate instances. | M | |||||
| 1.8 | The solution device presents a quality score for rolled and flat fingerprints while being captured. | D | |||||
| 1.9 | The solution device presents the reason for a failure of the fingerprint images in an error message, correlated with the score of the images. | D | |||||
| 2 | Finger Orientation Markers | ||||||
| Issue | Solution has finger orientation markers (horizontal and vertical) to assist the operator in properly orienting each finger. The purpose of this requirement is to ensure that when printed, each captured image is properly situated in the appropriate block on the fingerprint card. | ||||||
| Description | 2.1 | The orientation markers are clearly marked either adjacent to the platen surface, or on the monitor. | M | ||||
| 2.2 | This orientation must occur prior to the scan process in order to eliminate the need to re-scan a finger because of improper placement within the fingerprint block. | M | |||||
| 2.3 | Solution automatically re-centers images that are not centered in the frame. | M | |||||
| 3 | Palms | ||||||
| Issue | Solution is capable of capturing and transmitting palm prints including writer’s palms (outer edges of the hand/palm). | ||||||
| Description | 3.1 | Palm prints are optional for the Criminal Justice profile and are not applicable to the other profiles; however these settings are configurable | M | ||||
| 3.2 | Solution is capable of taking and submitting complete palm prints – from the heel of the hand to the tips of the fingers, according to FBI standards as detailed in | M | |||||
| https://fbibiospecs.fbi.gov/file-repository/palm/palmguidance-v3-0-lfsu.pdf/view | |||||||
| 3.3 | Palm prints are transmitted to in the appropriate format as described in the Attachment G: Livescan Interface Control Document (ICD) Version 2.0 | M | |||||
| 3.4 | Palm prints must be EBTS compliant; if palms are captured in a single image, the system must divide the palm image into upper and lower palm sections. | M | |||||
| 4 | Image Labels | ||||||
| Issue | Solution has features to enable operators to add a label to individual fingerprint images to further describe the fingerprint or to submit to the BCA in place of the fingerprint. | ||||||
| Description | 4.1 | The following rules apply to image labels: | M | ||||
| § Only one image label may be applied to a single image. | |||||||
| § The image labels amputated, unprintable cannot be accompanied by an image on submission to the BCA | |||||||
| § The image label best print available may only be selected after the images have been failed twice and must be accompanied by an image on submission to the BCA. | |||||||
| 4.2 | As result of adding an image label to an image, a label is a) placed in the booking record for submission, b) displayed on solution, and c) printed on the fingerprint card. The default image label is “none” which does not appear in the record, on the screen, or on the printed card. Labels must not obscure actual fingerprint images. | M | |||||
| 4.3 | The image label appears separately from any messages generated by solution (e.g. “rolled print does not match slapped print”) that is, all messages and labels can be viewed on the screen simultaneously. | M | |||||
| 4.4 | The following rules summarize the number of attempts needed to add a label. | M | |||||
| § To submit a failed image with the ‘best print available’ label, the operator has attempted to take that image a minimum of two times. | |||||||
| § The labels amputated, unprintable require no attempts. | |||||||
| 5 | Rejected Images | ||||||
| Issue | When one or more images are failed, the Livescan operator encounters the following business rules and procedures: | ||||||
| Description | 5.1 | Solution assesses the quality of captured images and prompts the operator to recapture an image, if necessary. Rather than using a range of values or a score, Livescan ranks each image as either PASS or FAIL. | M | ||||
| 5.2 | A failed image will be treated as a passed image if it is subsequently given an Image Label. The operator should be instructed to “re-roll the image or apply an Image Label”. | M | |||||
| 5.3 | Solution should not display minutiae counts to the operator. | D | |||||
| 5.4 | The Automated Biometric Identification System (ABIS) is expected to either ACCEPT or REJECT individual images. When ABIS fails one or more images, the operator views the ten-print image summary and all failed images are highlighted (perhaps a red outline?). The operator rescans the appropriate finger(s) in order to replace the failed images and/or adds an image label, as appropriate. The operator is not required or prompted to re-scan any accepted images. | M | |||||
| 5.5 | For resubmissions, the operator can specify that the “subject is no longer available”. This indicates to the ABIS fingerprint technician that no further images can be expected for this booking. This designation allows the operator to resubmit images, even if some have failed to pass Livescan edits or have been marked for resubmission by ABIS. Unlike an Image Label, the “subject is no longer available” flag applies to all images for a booking. | M | |||||
| 5.6 | Solution will allow the operator to submit a booking to the BCA / ABIS when | M | |||||
| § All fingerprints are Passed by the Livescan device, or | |||||||
| § All the Failed fingerprint images have an Image Label, or | |||||||
| § The operator has specified that the “subject is no longer available”. | |||||||
| 5.7 | Solution allows the operator to place an out of sequence fingerprint in the correct position without having the operator recapture the image. | D | |||||
| 6 | Photo Capture | ||||||
| Issue | Solution is equipped with photographic hardware and software to capture and transmit mug shots of subjects together with data and fingerprint images. | ||||||
| Description | 6.1 | Solution can be configured both with and without photo capture equipment. See Section 41. | M | ||||
| 6.2 | Solution is configured to NIST standards for photo capture Best Practices including minimum number of pixels, color space, pixel aspect ratio, compression, and file format. | M | |||||
| 6.3 | Solution accepts images from third-party photographic hardware and software that also meet NIST standards. | M | |||||
| 6.4 | Solution is configured to capture photographic images of scars, marks and tattoos. | M | |||||
| 6.5 | When equipment is installed or a photo is imported, Solution captures and displays a thumbnail photo of the subject in the header of appropriate data and fingerprint entry screens to help identify subjects, particularly when bookings are interrupted. The thumbnail image, if implemented, is not transmitted to any other application and is discarded with the rest of the booking data and images when the booking is discarded. | D | |||||
| 6.6 | The following business rules apply to photo capture: | M | |||||
| · Solution will automatically prevent submission until at least two photos are taken (front face and left profile) | |||||||
| · The operator cannot override the requirement unless the camera is broken. | |||||||
| Data Capture | |||||||
| 7 | Field Validation | ||||||
| Issue | Solution is expected to validate that appropriately formatted, rational and reasonable data is entered. | ||||||
| Description | 7.1 | Validation of input data where the field validation is not dependent on other fields includes: | M | ||||
| § Validating the format of input fields | |||||||
| § Validating the allowed values of input fields | |||||||
| § Validating whether mandatory fields have been valued | |||||||
| Validation rules can be obtained either from searching internal (to Livescan) tables. Note that field edits may not be universal and may differ from one profile or purpose to the next. | |||||||
| 7.2 | Validation of input data includes fields being compared to other fields in the input set to ensure that business rules are not being broken. An example might include: | M | |||||
| Booking Date cannot precede the Arrest Date | |||||||
| 7.3 | Blank data fields are not indicated as invalid until the Operator selects to submit the booking. | M | |||||
| 7.4 | The included Attachment G: Livescan Interface Control Document (ICD) Version 2.0 shows which fields are mandatory or optional and clearly establish dependencies among fields. | M | |||||
| 8 | Data Fields | ||||||
| Issue | Solution must capture data elements required to support the criminal justice process. | ||||||
| Description | 8.1 | Solution must be capable of capturing and transmitting all data elements specified in Attachment G: Livescan Interface Control Document (ICD) Version 2.0. | M | ||||
| 9 | Mandatory Fields | ||||||
| Issue | Solution highlights mandatory fields. Note that mandatory fields may not be universal and may differ from one profile or purpose to the next. |
| Description | 9.1 | Highlight mandatory fields to differentiate from optional. | M |
| 9.2 | Fields that become mandatory as Operator enters data must also become highlighted. The highlight must be removed if Operator removes the dependency. | M | |
| 10 | Statutes | ||
| Issue | Solution integrates to the Minnesota Criminal Justice Statute Service to insure up to date statutes for livescan users. | ||
| Description | 10.1 | Solution validates statutes using the Arrest Date (or Booking Date if not specified); only statutes effective for that booking can be entered. | M |
| 10.2 | Solution presents the charge degree (felony, gross, misdemeanor, etc.) from the statute table, where possible, and allows the operator to choose a charge degree appropriate to the statute where the charge degree is ambiguous. | D | |
| 10.3 | Solution allows operators to enter statutes as numbers or literals. If entered as numbers, the literal is generated – and vice versa. | M | |
| 10.4 | Solution allows operators to specify the minimum statute hierarchy (i.e. chapter and section) while not disallowing the entry of further hierarchy (i.e. subdivision and paragraph) if known by the operator. | M | |
| 10.5 | The Solution utilizes dropdowns, type-ahead and other data entry features to improve accuracy of statutes and promote ease of use. | M | |
| 10.6 | Two special conditions exist when operators describe statutes under the Criminal Justice profile: | M | |
| 1. For charges with a charge purpose of Predatory Offender Registry, the statute defaults to MN Statute 243.166 (and corresponding literal). | |||
| 2. For charges with a charge purpose of Interstate Transfer for Probation, the operator is not allowed to specify a Minnesota statute (or corresponding literal). | |||
| 10.7 | The Vendor Solution must ensure the Statute Tables are provided on the Livescan Management server. Locally available to each livescan device on the Management server, updated at appropriate intervals. | M | |
| 11 | Data Import | ||
| Issue | Most Minnesota jails have a computerized records management system (RMS) or jail management system (JMS). Much or all of the data for the Livescan booking has already been entered into RMS/JMS. To eliminate reentry of the data the Livescan must provide a means to import data. | ||
| Description | 11.1 | Solution provides an import feature using the BCA’s Demographic Import XML schema. | M |
| 11.2 | The Demographics Import XML file is exchanged using a shared folder on a network location outside of the Livescan. | M | |
| 11.3 | When the Criminal Booking profile is selected, the Livescan presents the operator with an option to import data. | M | |
| 11.4 | If the operator chooses to import data, the Livescan must present the operator with a list of the files available to be imported. It is desired that the list include the subject’s name and date of birth. | M | |
| 11.5 | The Solution will allow the import of any data and there must be no minimum or required data elements. | M | |
| Booking Profiles and Purposes | |||
| 12 | Booking Profiles | ||
| Issue | The current generation of Minnesota Livescan devices allows operators to indicate what “profile” of subject is being booked. | ||
| Description | 12.1 | The Solution operator will choose only one profile per booking. The current profile definitions are: | M |
| § Criminal Booking | |||
| § Elimination Prints | |||
| § Verify Identification | |||
| § Identification Only | |||
| § Training: Criminal Booking | |||
| § Training: Identification Only | |||
| § Civil, Applicant, and Non-Criminal | |||
| 12.2 | Local Administration and Operators will be able to configure booking profiles and booking options. See Section 41. | M | |
| 12.3 | Adult and Juvenile cases differ only slightly in how data is treated downstream of the Livescan (i.e. Criminal History System, ABIS, and Next Generation Identification (NGI)). The Livescan must automatically determine whether the subject is a juvenile based on Date of Birth and Date of Arrest. | M | |
| 12.4 | The Livescan must enable to operator to override the juvenile indicator. | M | |
| 12.5 | Solution is equipped with a magnetic card swipe so that a Driver’s License or State ID Card can be used to pre-populate some of the demographic fields for this transaction. This data and other fields can also be entered manually. | D | |
| 12.6 | Solution is capable to read Driver Licenses barcode so that a Driver’s License or State ID Card can be used to pre-populate some of the demographic fields for this transaction. This data and other fields can also be entered manually. | D | |
| 13 | Booking Purposes | ||
| Issue | Each booking is associated with at least one Charge, Hold, Civil or Identification Purpose, which further describes why the booking has been created. | ||
| Description | 13.1 | Criminal Justice bookings comprise at least one Charge (and corresponding Charge Purpose) or one Hold (and corresponding Hold Purpose) and may encompass more than one of either. | M |
| 13.2 | The solution must be configurable such that each Hold Purpose Code may also be accompanied by an ORI, State code, or description field. | M | |
| 13.3 | Identification Only bookings have no charges and have only three Purpose Codes: Identification, Verification, and Elimination. | M | |
| 14 | Civil Profile | ||
| Issue | Solution allows the use of two profiles for Civil prints. One profile is used in conjunction with a new BCA Background Check application where fingerprint images are forwarded to the BCA / FBI electronically. The second profile is used to produce printed card(s) and the transaction is not electronically transmitted. For example, civil subjects may have pre-filled in cards or out-of-state subjects want fingerprints taken but have no reason for submission to the BCA for comparison / background check. | ||
| Description | 14.1 | Both profiles must include all data fields included in the current version of the FBI EBTS specification for NFUF and MAP transaction types. All data fields are optional for these profiles to allow for pre-printed applicant cards. | M |
| 14.2 | Solution is equipped with a magnetic card swipe so that a Driver’s License or State ID Card can be used to pre-populate some of the demographic fields for this transaction. This data and other fields can also be entered manually. | D | |
| 14.3 | Solution is capable to read Driver Licenses barcode so that a Driver’s License or State ID Card can be used to pre-populate some of the demographic fields for this transaction. This data and other fields can also be entered manually. | D | |
| 14.4 | Solution allows the operator to indicate that the subject has a pre-printed FBI applicant card in order to avoid entering demographics. | D | |
| 14.5 | The solution captures ten-finger slaps/rolls for the transaction. | M | |
| 14.6 | The system will be able to transmit to the BCA electronically and/or print fingerprint cards for mailing to the BCA or another state. | M | |
| 15 | Fingerprints and Profiles | ||
| Issue | Solution must be prepared to collect various fingerprints, possibly in combination, for each profile and to change this relationship when necessary. | ||
| Description | 15.1 | Solution is capable of capturing these finger combinations. | M |
| § Ten Finger slaps and rolled fingerprints | |||
| § Palms and Writer’s palms | |||
| § Two finger slap images (one finger from each hand) | |||
| § Four finger slap images (four fingers of one hand) | |||
| 15.2 | The current defaults by profile are: | M | |
| § Ten-finger slaps and rolls, palm (hereafter, Palms means Palms and Writer’s Palms) for Elimination Prints. | |||
| § Ten-finger slaps and rolls, and palms for all Criminal Justice profile | |||
| § Ten-finger slaps and rolls for the Civil profile | |||
| § Two-finger slap images for the Identification Only profile, with an option to select additional images. | |||
| See Section 41. | |||
| 15.3 | Solution can be configured to match the profile and purpose to the appropriate fingerprints combination. For example, the BCA requires rolled and slap fingerprints for electronic civil submissions now but changes its process to only require slap fingerprints in the future. | M | |
| Interface and Usability | |||
| 16 | Graphical User Interface (GUI) Guidelines | ||
| Issue | The solution user interface subscribes to generally accepted Windows GUI guidelines. | ||
| Description | 16.1 | The BCA does not wish to dictate the Livescan GUI; conversely, the BCA does not want to leave principles of good interface design unstated. | M |
| Solution devices must adhere to the following guidelines: | |||
| § Group related items together visually | |||
| § Scrolling is discouraged; the use of tabs for transactions involving many input fields is encouraged | |||
| § Tool tips are encouraged | |||
| § Keyboard shortcuts are encouraged | |||
| § Buttons sizes are standardized, button labels are concise and have expected outcomes | |||
| § Mandatory fields are closer to the top of a page or tab so that the operator can easily skip other fields as needed | |||
| § Drop downs have limited values and require little scrolling and fields with many values have features for ease of navigation: lookup functions, type-ahead, pop-up windows, searching features, etc. | |||
| § Text boxes will select the entire text when the operator enters the field so it is ready to be edited without any extra key strokes. | |||
| § Navigation is clear; the use of traceable paths (how did I get here and how can I get back?) is encouraged | |||
| § Width of fields is appropriate to the data to be entered | |||
| § Asymmetric interface components are discouraged (fields should be lined up) | |||
| § Keep the OK and Cancel buttons in the same spot on each dialog. The standard is the lower right hand corner, in the order OK, Cancel. The cancel button should respond to the escape key. | |||
| § Navigation to one data field should not be dependent on any other data fields being completed. | |||
| § The GUI will be touchscreen compatible; touchscreen data selection is possible for every data field that includes a dropdown or other selection process. | |||
| § Touchscreen GUIs are the same size as desktop monitors. | |||
| 17 | Capture of Fingerprints and Data | ||
| Issue | Whether due to agency procedures, operator availability, or conditions at a jail, operators need flexibility to capture fingerprints and suspect data. | ||
| Description | 17.1 | Solution is configurable to allow operators to capture fingerprints, demographics, charging data, and photos in any order; both as categories of data and as individual data fields. See Section 41. | M |
| 18 | Operator Skill | |||
| Issue | Solution does not require exceptional operator skill. | |||
| Description | 18.1 | Solution does not require exceptional or extraordinary operator skill or attention to produce satisfactory results. | M | |
| 18.2 | Solution can be operated from a keyboard and mouse. | M | ||
| 18.3 | Solution can be operated from a keyboard | M | ||
| 18.4 | Solution can be operated via a touch screen interface. | M | ||
| 19 | Training Mode | |||
| Issue | Solution provides a Training Mode so that operators can practice entering data and taking fingerprints though they do not actually submit transactions to the BCA. | |||
| Description | 19.1 | The interface clearly and unambiguously indicates when Livescan is in Training Mode using one or more visual clues including alternate color screen backgrounds, highlighted labels, warning messages, watermark, etc. | M | |
| 20 | Sorting of Lists | |||
| Issue | The solution interface allows for sorting of data as defined by Local Administration. | |||
| Description | 20.1 | Solution allows the operator to sort predefined lists such as ORI’s and names of agencies. See Section 41. | M | |
| 20.2 | The Local Administration / operator can designate most often-used values and sort them for rapid access. | D | ||
| 20.3 | The sorting feature must be explained in training materials. | M | ||
| 21 | Incomplete Bookings | |||
| Issue | Solution allows operators to start and not complete a booking. This feature is implemented so that an interruption to the normal process does not result in loss of either data or images resulting in unnecessary re-entry / re-capture. | |||
| Description | 21.1 | Solution should allow operators, whether in data entry or image capture (or photo capture as applicable), the operator may denote a booking as Incomplete for further update and submission at a later time. Minimum data requirements are Last Name, First Name, DOB, and slap fingerprints including thumbs suitable for submission (i.e. passed Livescan edits). | D | |
| 21.2 | Although solution allows an incomplete booking to be completed later, once all fingerprints are complete and all mandatory data fields have been entered (or defaults supplied), there is no option to denote the booking as Incomplete – it must be submitted or cancelled at that point. | |||
| D | ||||
| 21.3 | This Incomplete Booking feature applies only to the Criminal Justice profile – and only for initial bookings, not for resubmissions. | D | ||
| 21.4 | A Criminal Justice booking can be interrupted more than once prior to initial submission, however, once the transaction has been submitted to the Criminal History System and ABIS, it cannot be marked as incomplete again (i.e. for resubmissions). | D | ||
| 21.5 | Incomplete bookings are highlighted in the Booking Status Summary screen so that these bookings are more likely to be eventually completed. | D | ||
| 21.6 | Solution has facilities to warn an operator that a new booking may be a duplicate of a saved booking. Livescan warns the operator after comparing the Booking Date, Subject Name and DOB that an existing incomplete booking may exist for this subject. If any of the requirements 21.1 through 21.5 are implemented, then this requirement must be implemented. | D | ||
| 22 | Booking Edit | |||
| Issue | Solution allows operators to edit a Booking under certain circumstances. | |||
| Description | 22.1 | Bookings are editable if a) the last status of the booking was an error (Accepted or Rejected) and the booking has not yet been resubmitted, or b) the last status of the booking is Incomplete. | M | |
| 22.2 | Bookings are locked from editing until a response is received. | M | ||
| 22.3 | System Administration can unlock a booking for editing, when the booking is awaiting a response. | M | ||
| 22.4 | System Administration can override the lock on editing a booking, or can delete a booking. | M | ||
| 22.5 | Fingerprints / palm prints are not editable if all of them have been accepted by ABIS. That is, once fingerprints have been accepted and written to ABIS with no requests for resubmission, they can no longer be edited. Subject demographics and charges can continue to be updated even after acceptance by the Criminal History System. | D | ||
| 22.6 | Bookings can be selected for edit from the Booking Log or one of the Booking Status Detail screens, assuming the booking is editable. | M | ||
| 22.7 | The Booking Edit interface separates the following functions into pages or tabs: | D | ||
| § Subject Demographics | ||||
| § Charges | ||||
| § Fingerprints | ||||
| § Palm Prints (if applicable to the device) | ||||
| § Photos (if applicable to the device) | ||||
| § Status | ||||
| § Messages / Results | ||||
| 22.8 | The Status tab shows all of the statuses of this booking in date/time sequence in reverse chronological order. | D | ||
| 22.9 | Solution shall be capable to change the sorting of booking statuses in the Status tab to chronological order and vice versa. | D | ||
| 22.10 | Operators may not copy / reuse subject demographics, charges, fingerprints, or palm prints from one booking to another. | M | ||
| 22.11 | Treatment of the SID (State Identification Number): The SID of subject is returned in the success or error message if the subject was matched or created in ABIS. The SID is copied from the return message to the newer submission so that if the prints are improved for resubmission, ABIS will not attempt to re-match the prints. The SID, however, is displayed and treated differently than other fields in the booking edit: | M | ||
| § A SID returned from ABIS for the Law and Enforcement and Identification Only profiles is displayed in the Livescan interface but is not modifiable by the operator. | ||||
| § A SID returned from ABIS for the Civil profile is not displayed. | ||||
| 23 | Subject Identity | |||
| Issue | On some of our existing solution devices, lists of bookings are displayed without identifying data to help the operator ensure that he/she has the right subject or the right booking. Simple improvements to the Livescan user interface involving subject identity help alleviate this problem. | |||
| Description | 23.1 | Whenever a Booking ID is displayed, it is always accompanied by the subject’s last name, first name, and booking date. | M | |
| 23.2 | While a booking (or the edit of an existing booking) is in progress, the subject’s last name, first name, and booking date are always prominently displayed in the Header of the Livescan screen. | M | ||
| 23.3 | A configuration option must exist such that Juvenile names may not be displayed. Depending on the location of the device (e.g. adult and juvenile bookings from the same location), it may be necessary to blank the display of Juvenile names for selected screens. See Section 41. | M | ||
| Booking Status, Responses and Error Handling | ||||
| 24 | Booking Statuses and Responses | |||
| Issue | Solution receives messages from BioID (routed from other applications such as ABIS and the Criminal History System) that indicate the status of past and current submissions. | |||
| Description | 24.1 | The following Booking Status values exist: | M | |
| Status | When Used | |||
| Sent | Livescan has submitted a booking and not yet received a return message from BioID. | |||
| Manual Review | BioID returns a manual review message. | |||
| This message occurs when intervention by an ABIS Fingerprint Technician is necessary for fingerprints to pass through ABIS. The manual review response alerts the operator that more time is needed to process or reject the submission. | ||||
| Not Responded | Livescan has not received a response from BioID within acceptable time limits or cannot communicate with BioID. See Section 29. | |||
| Partial | The Operator chooses to create a booking and save it for continuing edits at a later time. See Section 21. | |||
| Success | BioID returns a success message. | |||
| Accepted with Errors | BioID returns an error message with a SID. See Note below. | |||
| Rejected | BioID returns an error message without a SID. See Note below. | |||
| Technical Error | BioID returns a technical error message. | |||
| 24.2 | All of these statuses are defined for each booking. | M | ||
| 24.3 | The system must be able to accept multiple responses for one booking. | M | ||
| 24.4 | Booking statuses do not necessarily follow a sequence; a booking can change to any status based on responses. | M | ||
| 24.5 | Status should be readily visible. | M | ||
| Note: The BCA’s current workflow reacts to small errors by storing data but still prompts the operator with an error message (i.e. ‘Accepted with Errors’). Submissions with more severe errors are ‘Rejected’. Returned messages from the Criminal History System and/or ABIS must provide an indication of the outcome of the submission and Livescan, and will display the Booking Status Summary and Booking Status Detail screens accordingly. |
| 25 | Booking Status Summary | ||
| Issue | Solution provides a Booking Status Summary so that operators can easily see if there are errors yet to be resolved and incomplete bookings yet to complete. Also, the message types are logically separated so that the operators can focus and navigate to the most important messages, typically errors. | ||
| Description | 25.1 | This Booking Status Summary is easily available on all Livescan screens. It can be accessed from the Task Bar or other control so that the operator can tell at a glance the status of submissions to and from the device. | M |
| 25.2 | The Booking Status Summary displays the total number of messages for all message types. An example summary display may look like: | M |
Success 4 Waiting 1 Error or Needs Attention 2
| Statuses that require operator action are highlighted in a consistent manner and location. | ||
| 25.3 | Operators can easily navigate to the Booking Status Detail screen from the Booking Status Summary. | M |
| 25.4 | The Booking Status Summary display can survive a re-boot of the CPU or restart of the application without losing statistics. | M |
| 25.5 | The Booking Status Summary is automatically updated when a booking is edited or resubmitted, is saved as incomplete for later submission, is deleted or purged, receives a response, or is not responded to within the appropriate timeframe. | M | |
| 25.6 | The system will notify the operator on-screen if operator action is required in response to the booking status. | M | |
| 25.7 | The Booking Status is always visible on-screen. | M | |
| 26 | Booking Status Detail | ||
| Issue | Solution provides a Booking Status Detail screen so that operators can focus on active (non-purged) bookings that have relevant statuses. | ||
| Description | 26.1 | By default, the Booking Status Detail screen is sorted by Submission Date/Time with the latest submissions listed first. | M |
| 26.2 | The Booking Status Detail screen displays these data fields: | M | |
| § Submission Date/Time – when the booking was last submitted (or marked as Incomplete, if that was the last action taken) | |||
| § BID – the Livescan Booking ID | |||
| § Last Name – the subject’s Last Name; juvenile names are not displayed depending on the Livescan configuration | |||
| § Additional SID – display if included in response | |||
| § Match to SID - for ID Only where ID is made to a different SID | |||
| § Booking Status | |||
| § Error Type – ‘Prints’, ‘Data’ or ‘Prints & Data’ (required only when there are errors) | |||
| 26.3 | Error Message – only displays that part of the ABIS error message that is germane to understanding and fixing the error(s). Operators need a way to view the entire error message if it is truncated on this screen. | M | |
| 26.4 | The Booking Status Detail screen displays the error messages, and has a link to an error list. | M | |
| 26.5 | The solution must be configurable such that a booking submission or resubmission may result in more than one returned message. Livescan displays the last message returned in the Booking Status Detail. The previous messages are ‘hidden’ when the booking is resubmitted to prevent another operator from attempting to fix and resubmit the same booking. An historical view of all messages is available. | M | |
| 26.6 | The Booking Status Detail screen can be filtered to display bookings with one or more statuses per the table below. | D |
| Note that this filter feature is slightly different from the values of the booking statuses: | |||
| § * The ‘Action Required’ filter combines Accepted with Errors and Rejected Errors, Incomplete, Not Responded and Technical Errors. | |||
| § ** The ‘Errors’ filter combines both Accepted with Errors and Rejected Errors in a single view and is the default display. | |||
| § The ‘Incomplete’ filter shows bookings in progress that have yet to be submitted. | |||
| 26.7 | To make searching easier for lists of more than one page, Livescan allows the operator to search or filter for one or more bookings by fields such as Last Name, Booking ID, Date, etc. | D | |
| 26.8 | The system enables the operator to filter for one or more submissions by record type. Record types include: | D | |
| · All Records (default, shows all records) | |||
| · Criminal Records | |||
| · Civil Background Records | |||
| · Identification Records | |||
| · Criminal Incomplete Records | |||
| · Criminal Waiting and Not Responding | |||
| · Criminal Records that Require Attention | |||
| 26.9 | To make navigation easier for lists of more than one page, Livescan provides navigation elements such as Next Page, Previous Page, First Page, Last Page, etc. | D | |
| 26.10 | The solution must allow the operator to select a Booking ID from the Booking Status Detail to edit. If the booking is currently non-editable, the booking is displayed for read-only or printing purposes. | M | |
| 26.11 | The operator can change the default sort to any of the columns in the display. | D | |
| 27 | Booking Status History | ||
| Issue | The Booking Edit screen provides a tab that shows all statuses for a single booking. Operators are able to display a complete Status History for the booking. | ||
| Description | 27.1 | So that the operator can trace their previous actions, the Livescan operator has the ability to display all messages from all submissions in sequence for a given booking. | D |
| § The rows of the screen are sorted by the date/time column. | ||
| § Booking ID, Primary Last Name and DOB will be the same for all rows. | ||
| § Booking Status – See Section 24. | ||
| § Error Type is ‘Prints’, ‘Data’ or ‘Prints & Data’. | ||
| 28 | Booking Retention | |
| Issue | Solution has the capability to maintain bookings and messages for an extended period of time. |
Description 28.1 Livescan retains bookings according to the following table: M
| 28.2 | The following business rules apply to booking retention: | M | |
| § Livescan operator should not be able to delete records. | |||
| 28.3 | A purge deletes the booking data and images and all related messages and statuses. | M | |
| 28.4 | Automatic purge settings (number of days) listed in the table above are configurable. | M | |
| 28.5 | The screens for configuring booking retention are viewable and modifiable by System Administration. | D | |
| 29 | ‘Not Responded’ Bookings | ||
| Solution expects a response to submissions within a timeframe set by administrators. | |||
| Description | 29.1 | A solution submission not receiving a SRE or ERRT message within a configurable timeframe is also marked as ‘Not Responded’. See Section 41. | M |
| 29.2 | A visual indicator to the operator should be displayed / heard when there are Not Responded instances being generated by Livescan. | D | |
| 29.3 | Livescan does not allow bookings to be resubmitted before a full response is returned. | M | |
| 29.4 | The preceding requirement makes it impossible for ‘Not Responded’ bookings to be resubmitted. To resolve this problem, Livescan can be instructed to allow a resubmission of a ‘Not Responded’ booking. This action is restricted to the BCA staff or Local Administration and cannot be taken independently by the Livescan operator. | M | |
| 30 | Error Messages Navigation | ||
| Issue | Operators can quickly view and correct errors in Livescan. | ||
| Description | 30.1 | The Error Message Detail Screen links directly to the related booking. Solution highlights which images have been failed by ABIS and/or which fields have been failed by the Criminal History System. | M |
| 30.2 | Solution always displays the latest error message while the operator is editing the booking so that the operator does not have to remember or write down the error message. | D | |
| 30.3 | Starting with the first error and progressing to the next error after the user fixes the error, the error will display in the text field where the error occurred starting with the first error and progressing to the next error after the user fixes the error. | M | |
| 30.4 | The solution highlights data fields and data that is erroneous or missing when the operator attempts to submit a booking. | D | |
| 30.5 | Error message(s) returned from BioID will be formatted approximately as shown in the following pseudo-XML. The schema simultaneously includes fields that can be parsed by Livescan and displayed by solution to the operator (for both data errors and print errors). The structure also allows for ‘general errors’ that are not specific to data or fingerprints. | M | |
| <Error Message> | |||
| <BID> | |||
| <SID> | |||
| <Status> | |||
| <General Error Readable Message> | |||
| <Error Messages> | |||
| <Data Errors> (0..n) | |||
| <Field Identifier> | |||
| <Occurrence> | |||
| <Error Text> | |||
| <Data Error Readable Message> | |||
| <Fingerprint Errors> (0..n) | |||
| < Fingerprint Identifier> | |||
| <Technician Comments> | |||
| <Fingerprint Error Readable Message> | |||
| Status values are (“Accepted with Errors”, “Rejected”, “Technical Error”) | |||
| Status value “Success” does not need the error message structure. | |||
| 30.6 | When displaying the Image Summary of all images for a booking, solution displays image numbers with the images. This will help the operator cross-reference the error message to the correct image(s). Image numbers, like all associated labels and messages should not obscure the image. | ||
| M | |||
| 30.7 | If the Operator interface uses tabs or its equivalent, Solution highlights the tabs requiring operator attention (having errors). Solution also removes the highlighting when the fields/images are fixed so that the operator is easily aware of what work remains to be done. | D | |
| 30.8 | Solution automatically advances to the first failed fingerprint or field. Solution has the ability to advance the operator to the next failed field or fingerprint similar to a FIND NEXT word processing feature. | D | |
| Printer Requirements | |||
| 31 | Printer Options | ||
| Issue | The BCA requires multiple options for printers attached to Livescan devices. | ||
| Description | 31.1 | Livescan agencies may buy their own printers provided the printers are on the FBI certified product list. | M |
| 31.2 | Solution is offered with and without printer. See Section 41. | M | |
| 31.3 | Contract Vendors are expected to offer Livescan devices with three printer options: | M |
| 32 | Printer Specifications | ||
| Issue | The BCA requires multiple options and specifications for use with printers attached to Livescan devices. | ||
| Description | 32.1 | Solution printers are laser-quality, either local or networked, capable of printing at a resolution of 1000 dpi. | M |
| 32.2 | Solution supports printing on superior bond paper (20 lb. or better) as well as fingerprint card stock. | M | |
| 32.3 | Solution printers are configurable and adaptable to adjust the number of trays for a particular Livescan unit. Livescan printers have one or more trays and a capacity of at least 250 cards per tray. | M | |
| 32.4 | Solution provides the ability to print multiple types of cards and forms: | M |
| 33 | Printing Specification | ||
| Issue | Solution operators can easily switch between forms. | ||
| Description | 33.1 | Solution operators can easily switch between: | D |
| § Pre-printed cards/forms, and | |||
| § Plain cards/forms where the boxes, lines and words are printed with the subject’s data and fingerprints. | |||
| 33.2 | The Solution printer can print upon the Minnesota Fingerprint Card. See Attachment H: Sample Fingerprint Card for format details. | D | |
| Livescan Hardware | |||
| 34 | Standard Configurations and Options | ||
| Issue | Contract Vendor provides multiple configurations and options in response. The BCA may purchase these configurations or others as needed and provided by the Contract Vendor. | ||
| Description | 34.1 | The BCA needs Livescan solution devices to be configured as follows: | M |
| 34.2 | The Contractor must offer each of the following options such that the BCA can, at the BCA's discretion, add one or more options to the configurations above | M | |
| § Printer Option 1, 2 or 3 (see Requirement 33, Printer Options.) | |||
| § Integrated Photo | |||
| § Touch Screen (if not included in the standard configuration) | |||
| § Card Swipe (applicable for secure sign in) | |||
| 34.3 | Solution scans at a resolution of 1000 ppi for all configurations | M | |
| 35 | Appropriate to the Environment | ||
| Issue | Contract Vendor provides devices and configurations that are appropriate to the usage and environments where they are installed. | ||
| Description | 35.1 | Solution hardware must be durable, resistant to damage and safe to operate. | M |
| 35.2 | Solution must function safely and easily for the operator within the environment and conditions of the jail. | M | |
| 35.3 | With the ruggedized option, all components are securely mounted to the cabinet or other work surfaces to prevent their use as weapons. In particular, the keyboard is fastened to the cabinet. | D | |
| 35.4 | The ruggedized cabinet has wheels for ease of movement. If included, wheels are required to be lockable. | D | |
| 36 | Ergonomics | ||
| Issue | Solution is ergonomically designed for the height of the operator and subject. | ||
| Description | 36.1 | Solution has a computer monitor that is adjustable in height and viewing angle. | D |
| 36.2 | The Livescan capture deck height is adjustable. | D | |
| 37 | Platen Requirements | ||
| Issue | The Solution platen is continually operable. | ||
| Description | 37.1 | If any platen is designed so that it needs replacement after a certain amount of use, the Contract Vendor tracks its usage and is responsible for regular maintenance so that the device is continually operable. | M |
| 38 | Fingerprint and Palm Prints | ||
| Issue | Fingerprint and palm prints are combined. | ||
| Description | 38.1 | Fingerprint and palm prints are not scanned in separate units; Livescan combines these in the same device/enclosure | M |
| 39 | UPS and Surge Suppression | ||
| Issue | Solution includes both an Uninterruptible Power Supply (UPS) and Surge Suppression. | ||
| Description | 39.1 | Solution Includes an installed Uninterruptible Power Supply (UPS) that will maintain operation for at least a period that allow users to complete a graceful shutdown and save current work. | M |
| 39.2 | The UPS is included in the device enclosure for the ruggedized option. | M | |
| 39.3 | Transient voltage surge suppressors rated at 25,000 amps of power line surge suppression or equivalent must protect all Livescan equipment. | M | |
| 40 | Miscellaneous Hardware Requirements | ||
| Issue | Miscellaneous hardware requirements: | ||
| Description | 40.1 | Solution does not require periodic calibration/light balancing by operators. | D |
| 40.2 | Solution has Network Time Protocol to synchronize with Livescan Centralized Management server for their system clock to accurately maintain an internal date and time. | M | |
| 40.3 | The noise level produced by Livescan during operation, including any audible malfunction warning signals, must not exceed sixty decibels at three feet. | D | |
| 40.4 | Solution is equipped with a wedge bar-code and/or magnetic stripe card reader so that data entry and identification of operators (via magnetic stripe) or subjects (via bar-coded papers, folders or wristbands) is easily accomplished. | D | |
| Management Server | |||
| Configuration Management | |||
| 41 | Configuration Management | ||
| Issue | Solution has configuration options that may be controlled by Local Administration or the Contract Vendor. | ||
| Description | 41.1 | The following table illustrates a possible scenario for controlling various configuration options: | D |
| 42 | Tables of Values | ||
| Issue | Solution has numerous tables that control input of booking data. | ||
| Description | 42.1 | The following Lookup Tables must be supported by replacement Livescans for the life of the machine: | M |
| 42.2 | All tables in Solution must be updatable by the Livescan Centralized Management server. | M | |
| Operating System and Software Environment | |||
| 43 | Encryption | ||
| Issue | Solution is capable of submitting and receiving encrypted messages. | ||
| Description | 43.1 | Solution must be capable of submitting and receiving encrypted message with FIPS140-2 NIST certified encryption. | M |
| 43.2 | Data stored at rest must meet FIPS 140-2 or FIPS 197 NIST certified encryption. | M | |
| 44 | Transmission Protocol | ||
| Issue | The BCA chosen protocol for secure and guaranteed delivery of transmissions to/from Livescan is IBM MQ. The BCA will maintain MQ version 9.2 or later infrastructure for Livescans to connect. Contract Vendor(s) commit to applying this technology to communicate with the BCA’s BioID. The BCA may make periodic updates to this infrastructure and the Contract Vendor is expected to work with the BCA to accomplish updates. | ||
| Description | 44.1 | Solution uses the latest version of MQ Client as provided by IBM as the sole means to communicate with BioID; all other protocols are disabled unless approved by the BCA. | M |
| 44.2 | Contract Vendor is responsible for installation, deployment, and testing of the latest version of MQ Client as provided by IBM software to interact successfully with solution. | M | |
| 44.3 | Contract Vendor is responsible for licensing all copies of the latest version of MQ Client as provided by IBM on solution devices. | M | |
| 44.4 | Section 45 will be satisfied by employing the encryption capabilities of the latest version of MQ Client infrastructure using certificates issued by the BCA. | M | |
| 45 | Internet Access | ||
| Issue | Although it may be controlled or restricted, it is expected that Livescan devices will need access to the Internet for remote support and updates when it is not connected to the management server. | ||
| Description | 45.1 | Depending on the agency and operating environment of the device, Internet browser software must be installed on solution. This feature is configurable for each device. See Section 41. | M |
| 45.2 | The Livescan Centralized Management server must be the default for remote support and updates. | M | |
| 45.3 | Connectivity, to/from resources that are not secure locations connected via CJDN must meet requirements in the latest version of CJIS Security Policy. This includes any connectivity proposed for the purpose of remote support or system/software updates, whether using the internet or not. | M | |
| 46 | Operating System | ||
| Issue | The following requirements apply to workstations equipped with any operating system except where noted. | ||
| Description | 46.1 | The operating system is the latest release at the time of purchase. The operating system must be the latest release, generally available and unrestricted, and widely and extensively supported. The system will be completely updated with OS, bios updates, before being shipped to the customer. | M |
| 46.2 | The Contract Vendor commits to the installation, at no additional charge under the maintenance agreement, of critical hardware and software system upgrades throughout service life of the solution device. | M | |
| 46.3 | The Contract Vendor explicitly authorizes and facilitates installing all OS patches in a timely manner. The BCA requires 7 day remediation for critical patches, 30 day remediation for high, 90 day remediation for medium, next routine patch cycle for low. | M | |
| Vendor will address any zero day vulnerability as soon as the patch for mitigation control is put out | |||
| 46.4 | The Contract Vendor is required to verify that all solution pick up and process operating updates are completed in a timely manner. | M | |
| Vendor has to report to all software updates in the system. . | |||
| 46.5 | The risk of an operating system upgrade or patch rendering the application unusable is borne by the Contract Vendor at the Contract Vendor’s expense. | M | |
| 47 | Anti-Virus Software | ||
| Issue | For any operating system-based software, Contract Vendor must explicitly authorize and facilitate the installation and maintenance of BCA-approved anti-virus software on all units. | ||
| Description | 47.1 | The current Windows-based anti-virus software used should be BCA approved. The successful use on device is demonstrated in the device acceptance testing. The risk of an anti-virus program rendering the application unusable is borne by the Contract Vendor. | M |
| 47.2 | For all units running other than Microsoft Windows-based software, the BCA is open to reasonable negotiation to achieve the same or similar levels of protection from malicious software; viruses, spyware, malware. | M | |
| 47.3 | The solution will receive anti-virus software updates to from BCA designated servers. | M | |
| 47.4 | The Contract Vendor is required to verify all Livescan pick up and process anti-virus updates. The BCA will forward any appropriate reports available from the anti-virus software update server. | M | |
| Centralized Management | |||
| 48 | Livescan Centralized Management (LCM) Functions | ||
| Issue | LCM requires an administrative server that is networked to all solution devices. The application on the administrative server permits System Administration to make updates to tables and configuration files, download patches, files, and anti-virus definitions from the Contract Vendor and third party sources, and view Livescan status and statistics. | ||
| Description | 48.1 | The system supports User Management by Local Administration and System Administration. | M |
| · A Local Administration will be able to add Operators at the local agency. | |||
| · System Administration can manage all Operators in the total system. | |||
| · Each Operator can access each Livescan at the agency. | |||
| · All Operators must have a unique username and password. | |||
| · Each Operator can change their password. | |||
| · Timeouts occur on administrative logins after 5 minutes of inactivity. | |||
| · There is a 15 minute timeout after no use for Operators. | |||
| · All Operators can use the Livescan when the network is down. | |||
| · Booting the computer leads directly to the Livescan application login. | |||
| · Only Local and System Administration can exit the Livescan program. |
This is the start of the file's text. The full file is on GovTribe.
File details come from the government source that posted it. Updated .