STATE OF MINNESOTA DEPARTMENT OF PUBLIC SAFETY

Transcription

1 STATE OF MINNESOTA DEPARTMENT OF PUBLIC SAFETY BUREAU OF CRIMINAL APPREHENSION Query Person Information Service (QP) Published On: September 21, 2010 Service Release Version#: 1.0 Prepared By: Bureau of Criminal Apprehension Criminal Justice Information Systems 1430 Maryland Avenue East St. Paul, Minnesota Service Visibility Service Description Accessibility Service Inputs Service Outputs SERVICE SUMMARY Public Restricted Private See Glossary for definitions This service provides users with the capability to retrieve information on a person s MNJIS hot files and federal NCIC hot files. BCA Criminal Justice Partners Name (NAM) Date of Birth (DOB) MNJIS and NCIC Person Hot Files

2 Document Revision History Date Version Description Author 09/21/ Initial Document BCA MNJIS 11/24/ :20:24 PM Page 2

3 Table of Contents SERVICE SUMMARY... 1 BUSINESS SERVICE DEFINITION... 4 QUERY PERSON SERVICE... 4 SERVICE OVERVIEW... 4 REAL WORLD EFFECTS... 4 SUMMARY... 4 BUSINESS SCENARIOS... 5 INPUT DETAIL AND BUSINESS VALIDATION RULES... 5 SERVICE CONSUMERS AND ACCESS RIGHTS... 5 SERVICE-LEVEL EXPECTATIONS... 5 SERVICE LOGGING AND AUDITING REQUIREMENTS... 6 TRAINING AND CERTIFICATION... 7 POLICIES... 8 STATUTES AND RULES... 9 RULES... 9 STATUTES BUSINESS USE-CASE TECHNICAL SERVICE DEFINITION ACCESSING THE SERVICE PRE-CONDITIONS (TECHNICAL) POST-CONDITIONS (TECHNICAL) SERVICE INTERFACE MESSAGE FORMAT EXCEPTION CONDITIONS AND ERROR HANDLING SECURITY PROFILE APPENDIX A: GLOSSARY /24/ :20:24 PM Page 3

4 Business Service Definition Query Person Service Service Overview The Query Person (QP) information service is a message key in the Law Enforcement Message Switch (LEMS) system that retrieves information on a person s MNJIS hot files and NCIC hot files, if any. QP begins with a query by agency personnel and ends with agency personnel receiving information regarding a person per MNJIS and NCIC Person Hot Files. See the following example: Service Inputs: Name (NAM) Date of Birth (DOB) Consumer of Service: BCA Criminal Justice Partner Provider of Service: MNJIS Hot Files and NCIC Hot Files Service Outputs: MNJIS and NCIC Person Hot Files Real World Effects The following is a list of effects of using this service: Summary A BCA criminal justice partner obtains MNJIS and NCIC Person Hot Files for the specified person. A User s application hub submits a service call to the BCA Enterprise Service Bus (ESB), which authorizes, authenticates, and validates the request. A valid request is then routed through the Law Enforcement Message Switch (LEMS) as a query to the required data sources, MNJIS Hot Files, and NCIC Hot Files. Either hot files or No Hit responses are returned to the BCA via the LEMS, is validated, and stored in the SQL Server database until the User Application Hub 11/24/ :20:24 PM Page 4

5 requests the response. The BCA ESB sends the hot file responses (if any) or No Hit response to the User Application Hub. Business Scenarios This service s resulting hot file data will be used by courts, law enforcement, and other BCA criminal justice partners in investigations on individuals in line with officially assigned duties. This may be in conjunction with, but not limited to an investigation of an individual s legal status in connection with an actual or alleged crime, search for missing persons, confirmation of identity or other cause; often in conjunction with a traffic offense, an incident response, an investigation, et cetera. Input Detail and Business Validation Rules Mandatory QP input includes the following criteria: Name (NAM) Date of Birth (DOB) The following validation rules apply to QP service calls: Data inputs must be submitted in upper case alphanumeric characters with special characters as required or permitted for each input field. See Appendix A: Glossary for definitions and business rules. Service Consumers and Access Rights The authorized users of the QP service are select BCA personnel and BCA criminal justice partners including but not limited to law enforcement officials, courts, probation officers, and parole officers. The QP service is query-only. No updates occur with this service. Service-Level Expectations Support Availability On call support for this service is available Monday through Friday, 8:00 a.m. to 4:30 p.m., except state holidays, through the BCA Service desk at telephone number: or Service Availability This service is designed to operate 24 hours a day, 7 days a week, 365 days a year. Though this service is intended to operate 24/7/365, the BCA s technical support of this service is limited to what has been identified in the Support section above. External Service Dependencies The Law Enforcement Message Switch (LEMS) must be available in order for the service to complete successfully. If LEMS is not available for more than 30 minutes an exception will be returned indicating that the LEMS service was not available for 30 minutes. Minnesota Person Hot Files, including the Gang File, Predatory Offender File, Protection Order File, Wanted Persons File, and Keep Our Police Safe (KOPS) File must be available to the BCA ESB via LEMS in order for the service to complete 11/24/ :20:24 PM Page 5

6 successfully. If MN Hot File services are not available, the call will be repeated to MN Hot Files until the service is available. NCIC Person Hot Files data are provided by the FBI and includes the Foreign Fugitive File, Gang File, Immigration Violators File, Known or Appropriately Suspected Terrorist File, Missing Person File, Protection Order File, Sexual Offender File, Supervised Release File, U.S. Secret Service Protective Order File, and Wanted Person File. NCIC Hot Files must be available to the BCA ESB via LEMS in order for the service to complete successfully. If NCIC Hot File services are not available, the BCA ESB will continue to attempt to access the NCIC Hot Files until the service is available. Service Maintenance Window The LEMS and the ESB are designed to function 24 hour per day, seven days per week. When LEMS is down, it is for patches or upgrades, usually occurring on Tuesdays or Wednesdays at 11:00 AM and lasting five to ten minutes or longer, depending on the activity. These downtimes are announced and occur on an as-needed basis. Service Downtime Notification The message returned during system downtime and/or unavailability will depend on the source system and the destination system. Messages returned will either indicate the host system is unavailable or the request timed out. Expected Response Times Responses from each system queried are delivered separately to ensure the return of information as it becomes available. Average response times vary depending on the responding system as described below. MN Hot Files Responses: NCIC Hot File Responses: Service Logging and Auditing Requirements within two seconds within thirty seconds Service consuming agencies are responsible for complying with FBI security policies in Criminal Justice Information Services (CJIS) Security Policy, Version 5.0, (CJISD-ITS-DOC ), including but not limited to logging and auditing requirements in section 5.4 Policy Area 4: Auditing and Accountability. Log files should be maintained for six years to meet State legislature auditor requirements. If a six year retention program is not feasible for the consuming entity, the consuming entity may submit to the BCA a written request for an exemption to the sixyear retention policy. The written request must include a detailed explanation describing the reason why the six year retention policy is not feasible and specify an alternative retention period. BCA management will consider each such request on a case by case basis. Note: Responses from the BCA contain confidential data. Agency staff, including employees and contractors, that can access logs containing confidential data provided by BCA services must be fingerprinted and have a criminal background check 11/24/ :20:24 PM Page 6

7 performed. An individual must pass the background check before access to service logs is allowed. Training and Certification The BCA shall ensure that security awareness training is provided at least once every three years to all personnel who manage or have access to FBI CJIS systems. All new employees who have access to FBI CJIS systems and all appropriate IT personnel shall receive security awareness training within six (6) months of their appointment or assignment. Documentation pertaining to the materials used and those employees which receive security awareness training shall be maintained in a current status. The BCA s responsibilities: 1. Within 6 months of employment or assignment train, functionally test, and affirm the proficiency of terminal (equipment) operators in order to assure compliance with FBI CJIS policy and regulations; 2. Biennially, provide functional retesting and reaffirm the proficiency of terminal (equipment) operators in order to assure compliance with FBI CJIS policy; 3. Maintain records of all training, testing, and proficiency affirmation; 4. Initially (within 12 months of employment or assignment) provide all sworn law enforcement personnel with basic training in NCIC 2000 matters to ensure effective use of the System and compliance with FBI CJIS policy regulation; 5. Make available appropriate training on NCIC 2000 System use for criminal justice practitioners other than sworn personnel; 6. Provide all sworn law enforcement personnel and other practitioners with continuing access to information concerning NCIC 2000/state Systems using methods such as roll call and in-service training; 7. Provide peer-level training on NCIC 2000 System use, regulations, policy, audits, sanctions, and related civil liability for criminal justice administrators and upperlevel managers; 8. Annually review all curricula for relevancy and effectiveness; 9. Instituted appropriate and reasonable quality assurance procedures for all federal and state System users; and 10. Ensure reasonably sufficient record management, for electronic and/or hardcopy case management systems, by ensuring that there are security standards, audit standards, and personnel training standards which allow accurate and up-todate records and proper/secure dissemination of the same. The BCA s Criminal Justice Partners responsibilities: 11/24/ :20:24 PM Page 7

8 Policies 1. The primary responsibility for the entry and maintenance of accurate, timely, upto-date and complete records lies with the entering agency. 2. Each agency is required to develop system security training that covers appropriate use, dissemination, and security requirements for their agency. BCA policy ADMINISTRATIVE POLICY NO for the BCA s general handling of public, private, and confidential data states the following: Data accessible to BCA personnel is often Private or Confidential Data; therefore, it is important to ensure the integrity of that data. BCA Personnel may only access those data sources, systems and storage devices they have authority to access strictly for the purpose of fulfilling their assigned job duties. Accessing a data source, data system or storage device for any other purpose is a violation of this policy and may also be a violation of the data practices act and/or federal law. To clarify this policy further, one may not access data on individuals known to the employee (e.g. family members, friends, daughter s boyfriend, etc.). If during the course of your duties you encounter information or a need to access information on any such individual, you should immediately report it to your supervisor so the task may be reassigned. Violation of this policy will result in discipline, which may include dismissal from employment, and may result in criminal prosecution. Please see the BCA s General Policies for complete text. The following statements are drawn from the Data Practices Assessment Checklist and provide additional details regarding how to execute the following rules and statutes. A clearly defined and stated purpose for a service is necessary to help a government entity decide what data it needs to collect. It can also help it determine if providing the data is mandatory or voluntary by data subjects. Copies of data on individuals taken for backup and recovery purposes, as well as those used for development, testing, training and certification, should be protected electronically (via encryption) and physically. Consider opportunities for loss, theft, or disclosure of data on individuals through premeditated, opportunistic and accidental means. A data subject can challenge data wherever it is maintained, even if the data did not originate in that agency. While not required, coordinating data challenges with the originating agency would be the most effective way for an entity to reach a determination as to data that didn t originate with their agency. Additionally, providing assistance to a data subject in locating inaccurate/incomplete wherever it is maintained would be a valuable customer service and best practice. Training and certification activities, while necessary for administration and management of programs, can be accomplished without the aid of private or confidential data on individuals. 11/24/ :20:24 PM Page 8

9 As a responsible business practice, private/confidential data on individuals should not be used by or disseminated to employees or contractors if their work assignments could be completed using surrogate data that is not private or confidential data on individuals. Development and testing activities, while necessary for administration and management of programs, can be accomplished without the aid of private or confidential data on individuals. If data elements or records are removed, hidden or altered to prevent the identification of individuals, it must be evident that: 1) the resulting data set does not contain private or confidential data on individuals, and 2) one could not easily reverse these alterations to reveal the original data. If a data subject successfully challenges the accuracy and/or completeness of data, the responsible authority must make every reasonable effort to notify those who accessed the challenged data. Knowing the classification of data determines who has access and for what purpose(s). Security measures are also based on the sensitivity / classification of the data. Therefore, anyone can have access to public data and can t be required to explain how it will be used. Statutes and Rules Rules Access to Public Data: procedures regarding data collection must be easily accessible to the public with free copies available Access to Private Data, subp. 2: only individuals within an entity whose work assignments reasonably require it can have access to private/confidential data. Individuals can include employees in an entity as well as contractors. Subp. 3: safeguards are in place to ensure individuals given access to data are the correct individuals Access to Private Data Concerning Data Subjects Who are Minors; a government entity must have a plan for reviewing the administration of their data collection and storage. Subpart 5, provides direction for the treatment of any unnecessary data. Subp. 3: procedures must be in place for parents to access information about their minor children Access to Confidential Data, subd. 2(A): only individuals within an entity whose work assignments reasonably require it can have access to private/confidential data. Individuals can include employees in an entity as well as contractors Duties of the Responsible Authority in Administering Private and Confidential Data, subp. 5: state and federal law may require certification or baseline training of users for a particular data system before data may be accessed Duties of Responsible Authority in Administering All Entity Data: the responsible authority is required to establish procedures to ensure that data are accurate, complete and current. 11/24/ :20:24 PM Page 9

10 Statutes MSS Access to Government Data, subd. 1, all government data is public unless it is otherwise classified by state or federal law. Subd. 2(b): procedures regarding data collection must be easily accessible to the public with free copies available. Subd. 4: data classification travels from one government entity to another. Unlike the general rule, criminal justice data often remains public at a local level and changes to private/confidential classification at the state level. Ex: arrest data is private at BCA, public at local law enforcement agency. MSS Rights of Subjects of Data, subd. 2: a data subject is entitled to a warning before private or confidential data are collected from them. Subd. 3: the responsible authority must prepare data subject access procedures. Subd. 4: procedures must be in place to allow data subjects to challenge the accuracy and/or completeness of data about him or her, to flag any data being challenged, and to post the subject s statement of disagreement. MSS Duties of Responsible Authority, subd. 3, a government entity can only collect private or confidential data on individuals that are necessary for the administration and management of programs specifically authorized by legislature or local governing body or mandated by the federal government. Subd. 4: Private or confidential data on an individual shall not be collected, stored, used, or disseminated by government entities for any purposes other than those stated to the individual at the time of collection, therefore, private or confidential data on an individual can only be collected from that individual if the individual is given a Tennessen warning. Subd. 2, provides an exception when an individual is asked to supply investigative data pursuant to 13.82, subd. 7, to a law enforcement officer. Subd. 5(2): the responsible authority is required to establish appropriate security safeguards for data on individuals. Subd. The BCA must maintain a contract with Dakota County requiring compliance to data practices. Subd. 8: the responsible authority must prepare data subject access procedures. Subd. 13: the names of the responsible authority/designees/data practices official for an agency must be publicized. When private or confidential data on an individual is collected from a third party, a Tennessen warning is not given to the individual. If a Tennessen warning was required but was not given, the statute provides that the government agency cannot use the data at all. Subd. 5(1): the responsible authority is required to establish procedures to ensure that data are accurate, complete and current. Subd. 9: not public data can only be shared with another government entity if a state or federal law requires it. MSS Comprehensive Law Enforcement Data, subd. 2; Private/confidential data are not available to the public. Data related to arrest/deprivation of liberty are public at the originating law enforcement agency but become private as part of criminal history data at the BCA. MSS Criminal Justice Data, subd. 1; Private/confidential data are not available to the public. Data related to arrest/deprivation of liberty are public at the originating law enforcement agency but become private as part of criminal history data at the BCA. 11/24/ :20:24 PM Page 10

11 MSS Government Records Administration: Data must be maintained according to an approved retention schedule. A specific individual is assigned the task of assuring compliance to records management laws and procedures. MSS , subdivision 1A establishes access to driver photo information from Driver and Vehicle Services. MSS , subdivision 7(d) establishes access to driver license address data. MSS 260B.171 Records, subd. 5; peace officer records on juvenile offenders must be kept separately from records on individuals 18 yrs and over. MSS 299C.095, 299C.10, 299C.11, 299C.13, 299C.14: a government entity can only collect private or confidential data on individuals that are necessary for the administration and management of programs specifically authorized by legislature or local governing body or mandated by the federal government (See MN Stat , subd. 3). MSS 299C.15 Cooperation; Criminal Identification Organizations: provides access to required data. MSS 299C.46 Criminal Justice Data Communications Network: provides access to required data. 11/24/ :20:24 PM Page 11

12 Business Use-Case Main Flow Query The Main Flow for this use case is described below. Pre-Conditions The following must occur before the flow begins: 1. The following inputs are known and provided: Name (NAM) and Date of Birth (DOB). Post-Conditions Success End-Conditions The following have occurred as a result of the successful completion of the main flow: 1. The query results in either hits or no hits. 2. Hits produce information contained in the person s MNJIS Hot Files and NCIC Hot Files data sources. 3. No hits reveal that the data sources queried have no information on the person in question. Failed End-Conditions The following have occurred as a result of the main flow failing: 1. One or more of the databases queried return an error message indicating information submitted was in some way erroneous. This may be due to a syntax error, missing data, a system failure, or a system being down. 2. The ESB security or archive service returns an error message to the agency hub reporting an error with authentication, authorization, or validation. 11/24/ :20:24 PM Page 12

13 QUERY PERSON (QP) REQUEST INSTANCE Consumer Application HUB ESB LEMS Request Service LEMS, Data Source Data Server M1. Submit Request M2. Authorize, Authenticate, Validate M2.A. Receive Error Message N Pass? Y M3. Translate M4. Place hold in data store M6. Receive Message Receipt M5. Archive Req. Msg. Receipt M7. LEMS Queue M8. Query Data Sources M11. Hold in data store M10. Translate M9. LEMS Queue Request Response M1. Submit Request A law enforcement agent (user) initiates a query from the Consumer Application Hub, or hub. His or her system puts the request in XML format encased in a SOAP envelope, which is sent to the BCA. M2. Authorize, Authenticate, Validate The security service performs an authentication and authorization of the hub s ID and password to confirm whether the consumer application hub may request a QP query. The message SOAP format is validated against the schema. Pass? If the authentication, authorization, and validation are successful, then the flow continues to M3. Translate. If the authentication, authorization, or validation is unsuccessful, then the flow continues to M2.A. Receive Error Message. M2.A. Receive Error Message The ESB sends an error message to the user, indicating either a failure to authenticate, pass authorization, or validate the schema. 11/24/ :20:24 PM Page 13

14 The user s hub receives the response message including the correlation ID. M3. Translate The XML message is translated to SIF format. M4. Place hold in data store A placeholder is placed in the data store. In this way, the data store is prepared to receive responses. M5. Archive Request Message Receipt The archive service archives the response message with correlation ID being sent to the hub. The full response to the client is archived, including the correlation ID for the request. M6. Receive Message Receipt The Consumer Application Hub receives a message confirming the query has been received, which includes a correlation ID. M7. LEMS Queue The query is placed in the LEMS Queue, where it waits until LEMS is able to process it. LEMS removes the query from its queue and directs it the required data sources. M8. Query Data Source MNJIS Hot Files. The inquiry is received by Minnesota Hot Files data source. This data source returns information on the individual. A hit generates a hit response with information. A no-hit generates a NO HIT response. MNJIS Hot Files queried include Gang File, Predatory Offender File, Protection Order File, Wanted Persons File, and Keep Our Police Safe (KOPS) File. NCIC Hot Files. The inquiry is received by National Crime Information Center (NCIC) Hot Files data source. Its databases return information on the individual. A hit generates a hit response with information. A no-hit generates a NO RECORD response. NCIC Hot Files queried include the Foreign Fugitive File, Gang File, Immigration Violators File, Known or Appropriately Suspected Terrorist File, Missing Person File, Protection Order File, Sexual Offender File, Supervised Release File, U.S. Secret Service Protective Order File, and Wanted Person File. M9. LEMS Queue The query is placed in the LEMS Queue, where it waits until LEMS is able to process it. ESB removes the query result from its queue and directs them to SQL Database. M10. Translate The SIF message is translated into XML. 11/24/ :20:24 PM Page 14

15 M11. Hold in data store The separate responses received through LEMS from the data sources are held separately, until the user hub retrieves them by correlation ID. Main Flow Request Response The Main Flow for this use case is described below. Pre-Conditions The following must occur before the flow begins: 1. The response from the data source is received, translated to XML, validated, and stored in the data store. Post-Conditions Success End-Conditions The following have occurred as a result of the successful completion of the main flow: 1. Parsed XML is returned to the client. 2. The consumer of the service has a drivers license image for the person in question. Failed End-Conditions The following have occurred as a result of the main flow failing: 1. The database queried returns an error message indicating information submitted was in some way erroneous. This may be due to a syntax error, missing data, a system failure, or a system being down. 2. The ESB security or archive service returns an error message to the consumer application hub reporting an error with authentication, authorization, or validation. 11/24/ :20:24 PM Page 15

16 QUERY PERSON (QP) RESPONSE INSTANCE Consumer Application HUB ESB LEMS Request Service Data Server Query Request M12. Request Response M13. Authorize, Authenticate, Validate M13.A. Receive Error Message N Pass? Y M14. Retrieve from data store M16. Validate M15. Create Response Y N All anticipated responses in? M18. Receive Response Message M17. Archive Request and Response M12. Request Response The consumer application hub requests responses for the query, sending the correlation ID as the transaction identifier. M13. Authorize, Authenticate, Validate The ESB authenticates the hub s identity and whether the hub is authorized to request the query results. Pass? If the authentication and authorization is successful, then the flow continues to M14. Retrieve from data store. If the authentication and authorization are not successful, then the results of the inquiry are withheld and an error message is sent to the hub; the flow continues to M13.A. Receive Error Message. M13.A. Receive Error Message The hub receives an error message indicating the ESB rejected the request due to a problem with authorization, authentication, or validation. M14. Retrieve from data store The query results are identified by correlation ID, copied from the data store, and brought into the ESB. M15. Create Response The various responses from the SQL database are formatted into a Response Message instance document. 11/24/ :20:24 PM Page 16

17 M16. Validate The Response Message instance is validated. Pass? If the response message is valid, then the flow continues to M17. Archive Request and Response. If the message is invalid, the results of the inquiry are withheld and an error response message is generated; the flow continues to M17. Archive Request and Response. M17. Archive Request and Response The valid response or error message response is sent to Archive Services. Either response is sent to the hub. M18. Receive Response Message The consumer application hub receives the response from the ESB in XML, in a SOAP envelope. All anticipated responses in? If one or more responses have not been received, the hub will repeat its request. This will continue until each of the message keys and their three data sources have given a valid response. The following fault conditions could exist: 1. One or more systems involved in this service is unavailable. 2. The service query request is unauthorized, fails to authenticate, or is invalid. 3. The data source returns an invalid response. 4. The service results request is unauthorized, fails to authenticate, or is invalid. Alternative Flows No alternative flows exist for this service. 11/24/ :20:24 PM Page 17

18 Technical Service Definition Accessing the Service Accessing the Query Person Information service is restricted to systems on the CJDN network that have access to the BCA s ESB. The Query Person Information Service interface is not discoverable. Once an agency is approved for access to this service, BCA will provide a document that includes access details. Pre-Conditions (Technical) MCJE compliant request Request is valid Request contains a valid instance of the BCA Header Access to this service is secured. The agency must have a valid MNJIS System user ID and password Post-Conditions (Technical) This is a read only service; therefore this service will not change the state or data All requests to and responses from this service will be archived Service Interface Provide Justice Partners the ability to submit Query Person requests. Responses from this service are retrieved using the BCA Asynchronous Messaging pattern as follows: 1. Upon submitting a Query Person request operation, the service returns a MessageReceipt that contains a unique correlation ID synchronously. 2. The service consumer will then make a RequestMessage request operation passing in the correlation ID obtained from the initial request. If the responses are available, an MCJE compliant ResponseMessage will be returned. If the responses are not available, an empty response will be returned by the service and the service consumer needs to make another RequestMessage request at a later time. Once an agency is approved for access to this service, BCA will provide a document that includes the WSDL. Message Format Communication to and from this service is handled using Simple Object Access protocol (SOAP). Request and Response messages are XML instances that are embedded in the header and body of the SOAP envelope. Both the Request and Response XML messages conform to the BCA s Schema standards. There are multiple Schema files that define the request and response formats. The sample exchanges 11/24/ :20:24 PM Page 18

19 are meant to demonstrate several but not all possible query/response scenarios and can be used as a basis for understanding how to use this service. Once an agency is approved for access to this service, BCA will provide a document that includes the schemas and sample messages. Submission Request/Response Messages The following is a list of the supported request operations (refer to the request message schemas): o QueryPersonRequest The response to the above requests is a MessageReceipt (refer to the MessageReceipt schema) that contains a unique correlation ID Retrieve Request/Response Messages The request for retrieving the responses is a RequestMessage (refer to the RequestMessage schema) The following is a list of the responses (refer to the response message schemas) that are wrapped in a ResponseMessage (refer to the ResponseMessage schema): o QueryPersonResponse Exception Conditions and Error Handling This service will return a SOAP Fault if there is an error with the Service Consumer initiated calls If the consumer s request contains improper data in the BCA Header or service request, the XML response will contain a FailureReason that describes the error During processing unhandled exceptions happen for unknown and unpredicted reasons. When an unhandled exception occurs, a Fault is returned to the consumer of this service. The Fault element will contain any known information about the unhandled exception. Security Profile Access to this service is limited to criminal justice agencies that are connected to the State of Minnesota Criminal Justice Data Network (CJDN). Workstations and servers that access the services must be granted access by IP address through the BCA s firewall in order to reach the servers where the service is running. The IP addresses of all computers directly accessing the services must be provided to the BCA so that firewall rules can be created. This service operates over HTTPS on TCP/IP port 443. An SSL certificate is required to be installed on any workstation or server consuming this service. SSL certificates can be obtained from the BCA. When configuring the endpoint in a consuming client or service, make sure that https is specified. 11/24/ :20:24 PM Page 19

20 Appendix A: Glossary DOB (Date of Birth) The subject s date of birth composed of year, month, and day. FORMAT: numeric, 0-9; two hyphens. BUSINESS RULES: Sequenced as YYYY-MM-DD, maximum 10 characters NAM (Name) - the name by which a person is known or designated. The NAM must include a minimum of last and first name. Middle name or initial and cadence are optional. FORMAT: alphabetic, A-Z, maximum of 138 characters, typed SURNAME, FIRST MIDDLE CADENCE. Special characters hyphen, comma, and space are accepted. BUSINESS RULES: The SURNAME is 50 characters maximum, the FIRST (name) is 30 character maximum, the MIDDLE (name) is 50 characters maximum, and the CADENCE is 4 characters maximum. First position must not be a blank, comma, or hyphen; must contain at least one, and only one, comma, which must not be preceded by a blank or hyphen. Two or more consecutive blanks or hyphens between characters are invalid. A hyphen must be preceded and followed by alpha characters. Hyphenated surnames are fully typed. First names may also be hyphenated. Compound surnames using a space are typed with the space. Hispanic names using the Spanish letter Y as a separator are typed with the Y. CADENCE has the following permissible values: JR, SR, II, III, IV, V, VI, VII, VIII, IX, and X; and must not exceed four characters. Complete names are to be used if available. No name or alias should be abbreviated unless the name exceeds the maximum field length. Should a name exceed the maximum field length, the initial(s) of the middle name(s) should be used rather than the full middle name(s). For first and last names, characters may be dropped from the end of the name to keep it within the maximum number of characters. Names must not be truncated (i.e. changing Jackson to Jack). All text after the space following a first name is recognized as a middle name. Accepted values for Cadence appearing after a space following a middle name are automatically recognized as a Cadence. When entering records for persons with only one name, the surname and an alphabetic X for other name(s) should be used; or the single name may be entered as both the first and last name. Abbreviations such as FNU, IO, LNU, MNU, NMI, and NMN should not be used. Periods (.) are not permitted within this data field. Use of periods will cause an error. Periods may be substituted with additional spaces or an alternate punctuation mark. See NCIC Code Manual for further details. 11/24/ :20:24 PM Page 20

21 NAM Examples SMITH, X SMITH, X X X SMITH, JACK JR II SMITH, JOHN HENRY SMITH, JOHN HENRY JR SMITH, JOHN H Q SMITH, JOHN HENRY LEWIS SR SMITH-JONES, JANE ELLE VON WRIGHT, JOHANNES HENRY CRUZ Y ROMERO, JUAN HENRIQUE NAM as Recognized by BCA Systems Last: SMITH, First: X (unknown) Last: SMITH, First: X, Middle: X, Cadence: X Last: SMITH, First: JACK, Middle: JR, Cadence: II Last: SMITH, First: JOHN, Middle: HENRY Last: SMITH, First: JOHN, Middle: HENRY, Cadence: JR Last: SMITH, First: JOHN, Middle: H Q Last: SMITH, First: JOHN, Middle: HENRY LEWIS, Cadence: SR Last: SMITH-JONES, First: JANE, Middle: ELLE Last: VON WRIGHT, First: JOHANNES, Middle: HENRY Last: CRUZ Y ROMERO, First: JUAN, Middle: HENRIQUE Private Service - A service that is only available internal to the BCA. That is, can only be consumed by other BCA services. Public Service - A service that it is available for anyone to consume. This includes anyone with access to a computer and the World Wide Web. Restricted Service - A service that can only be consumed after authorization and configuration by the BCA. 11/24/ :20:24 PM Page 21