Sexual Assault Kit (SAK) Tracking System Project Management Washington State Patrol. Business and Technical Requirements v2.1

Transcription

1 Sexual Assault Kit (SAK) Tracking System Project Management Washington State Patrol Business and Technical Requirements v2.1 November 16, 2016

2 TABLE OF CONTENTS TABLE OF CONTENTS... i 1. DOCUMENT PURPOSE AND REVISION HISTORY INTRODUCTION... 3 SAK Tracking System Project Objectives... 3 Approach to Collecting the Requirements... 4 General SAK Tracking System Philosophy... 5 Document Organization CURRENT HIGH LEVEL PROCESSES... 7 SAK Categorization / Prioritization... 7 STR... 8 SAK SAK SAK TRACKING SYSTEM USER GROUPS System User Groups Other Stakeholders BUSINESS REQUIREMENTS High Level Future Process Flow Business Requirements TECHNICAL REQUIREMENTS High Level Technical Architecture Technical Requirements APPENDIX A TRACKING SYSTEM SCOPE DECISION PAPERS APPENDIX B ON PREMISE SOLUTION TECHNICAL REQUIREMENTS... 40

3 1. DOCUMENT PURPOSE AND REVISION HISTORY This document presents the business and technical requirements for the Sexual Assault Kit (SAK) tracking system. These requirements are intended to be used by WSP in its upcoming Request for Proposals (RFP) for the SAK tracking system. This document also provides several high level processes that depict where SAKs can be stored, a high level process overview for the future environment, and several details on tracking system stakeholders / users. Document Revision/Release Status Version Date Description of Changes Author/Editor /31/16 Initial draft. Slalom Team /31/16 Reviewed initial draft with Robert Marlatt, Stephen Guest, and Nichole Minas and incorporated feedback. Draft ready for Slalom Team distribution to WSP SAK Tracking System Steering Committee /9/16 Incorporated the feedback from WSP SAK Tracking System Steering Committee Slalom Team members for final version /16/16 Incorporated the feedback from Representative Tina Orwall on Topic 5 in Appendix A. Slalom Team 2 P age

4 2. INTRODUCTION Washington State Patrol (WSP) is undertaking a project to implement Washington State Second Substitute House Bill 2530, which created Revised Code of Washington (RCW) Statewide sexual assault kit tracking system. WSP has engaged Slalom Consulting to provide project management services for the definition of requirements for the Sexual Assault Kit (SAK) tracking system and assistance with the agency s procurement activities. The objective of the tracking system is to provide survivors with the ability to anonymously track the location and status of their SAK from the point of collection through forensic analysis to final storage location and possible destruction. According to the legislation, The system will be designed to track all sexual assault kits in Washington state, regardless of when they were collected, in order to further empower survivors with information, assist law enforcement with investigations and crime prevention, and create transparency and foster public trust. 1 All entities in possession of SAKs must participate in the tracking system by June 1, However, WSP intends to use a phased implementation process, as allowed for in the RCW, with the creation of a pilot program mid This document presents the business and technical requirements for the SAK tracking system. Once finalized, they will be included in WSP s RFP to procure the future solution. Vendors will be asked to explain how their proposed solution meets each business and technical requirement. This will assist the WSP evaluation committee determine the best solution to meet the SAK tracking system legislation. SAK Tracking System Project Objectives The SAK tracking system project is a significant undertaking and Washington State is viewed as a pioneer in implementing this type of system on a statewide scale. The objectives of the tracking system project are to: Develop and deploy a system to track the location and status of all SAKs in Washington State When implemented, the system will track the SAK from examination at the medical facility to the law enforcement agency through forensic analysis at the WSP Crime Labs and to final storage or destruction 2 Allow updates / access to the tracking system by: o Medical facilities performing sexual assault examinations o Law enforcement agencies (LEAs) o WSP Bureau of Forensic Laboratory Services o Prosecutors (read-only access) o Other entities in the custody of SAKs Allow survivors to anonymously track their SAKs 1 While there are a number of entities that stand to benefit from this initiative and will be involved in updating and viewing SAK information in the tracking system, it is the Slalom team s understanding that the victim is the key beneficiary / customer of the system. 2 The scope of the tracking system is limited to the SAK box solely, which contains several articles of evidence including the DNA. There may be additional evidence not included in the SAK (e.g., blood, urine, clothing). These items are out of scope for the SAK tracking system. 3 P age

5 Deploy barcode readers, where required, to enable system use Create reports required by the Legislature Deploy a cloud-based solution with appropriate security, controls, and authentication in order to protect system data 3 Once fully implemented, WSP will provide system administration for the SAK tracking system and oversee the agreement with the tracking system vendor. Approach to Collecting the Requirements The Slalom team employed several activities to determine the business and technical requirements for the tracking system. The requirements were derived through: Conducting approximately 40 stakeholder interviews with the following: o Local LEAs o WSP Crime Labs o Prosecuting attorney offices o Sexual Assault Forensic Examination (SAFE) Best Practices Task Force members o Sexual assault nurse examiners (SANEs) o Victim advocacy organizations o Washington Association of Prosecuting Attorneys (WAPA) o Washington Association of Sheriffs and Police Chiefs (WASPC) o Washington Coalition of Sexual Assault Programs o Washington State Department of Corrections (DOC) o Washington State Hospital Association (WSHA) o WSP SAK Steering Committee members o WSP Information Technology Department Observing SAK intake and release processes at the WSP Crime Lab with LEAs Reviewing SAK intake and release processes at the King County Sheriff s Office s Property Management Unit Attending SAFE Best Practices Task Force meetings Discussing several tracking system scope topics with Representative Orwall, a key sponsor of the Legislation and co-chair of the SAFE Best Practices Task Force 4 Discussing system requirements and potential solutions with several Slalom technology experts Reviewing pertinent background documentation related to the Legislation Reviewing available WSP technical documentation 3 The decision to procure a cloud-based or on-premise solution is still being determined by WSP. The business and technical requirements that will be included in the RFP will be updated to reflect WSP s final decision. 4 The Slalom team provided several discussion papers for the WSP Government and Media Relations (GMR) team to review and receive feedback from Representative Tina Orwall regarding the scope of the SAK tracking system. Slalom did not attend the meeting but received the Representative s feedback through WSP GMR. 4 P age

6 The activities listed above delivered the information necessary for the Slalom team to define the business and technical requirements for the SAK tracking system. General SAK Tracking System Philosophy Due to the number of stakeholders involved, their different perspectives on the subject, and the general complexity of rolling out this tracking system on a statewide basis, WSP and the Slalom team have been working to confirm several key attributes of the system. These considerations directly impact the business and technical requirements of the future solution. They are: The SAK tracking system will be entirely stand alone and is not intended to integrate with any existing or future solution. Victim information entered into the system will be limited to the extent possible to keep with the intent to allow victims to anonymously track their SAKs. This may require local law enforcement or medical personnel to confirm identity and provide information regarding the SAK barcode or identifier to the victim if misplaced or compromised. It may also require the involvement of these personnel in certain WSP system administration activities (e.g., resetting system access information). Further details will be determined during system design activities. The tracking system is not intended to replace or provide redundancy for current chain of custody practices, existing evidence / property management systems, or existing laboratory information management systems (LIMS). The location or status of a SAK in the tracking system is not and should not represent where the case is in the investigative, case filing, Combined DNA Index System (CODIS) match, or general criminal justice process. Sexual assault cases are challenging to prosecute and decisions to refer a case to the prosecuting attorney s office by law enforcement or to file charges by the prosecutor are under the discretion and authority of those agencies. The purpose of the SAK tracking system is strictly to indicate where the SAK is located and the status of forensic analysis. Information provided by the tracking system has no direct relationship to the investigation or adjudication of the sexual assault case. The SAK tracking system will meet the letter of the Legislation. Several stakeholders expressed desired system functionality far exceeding the current Legislation. In order to set up WSP and all of the stakeholders for success on the initial implementation, the business and technical capabilities of the tracking system are focused on meeting the specific requirements of the Legislation. Additional functionality may be added to the system in the future but is considered out of scope for the initial implementation. The SAK tracking system will be a statewide system. It will not meet each jurisdiction s or agency s current processes and procedures for processing SAKs. The tracking system will be general enough to provide a baseline for all users throughout the state to update the location and status of the SAK and, in certain cases, local processes or procedures may need to change in order to better align with the SAK tracking system. 5 P age

7 A more detailed discussion of these topics is provided in Section 5 Business Requirements. These general principles were critical to informing the relevant business requirements for the SAK tracking system and the supporting technical requirements in terms of security, availability, and compliance with applicable state and federal standards. Document Organization The remainder of this document is presented in the following sections: Current High Level Processes Provides information and process diagrams on the various types of SAKs that exist throughout the state. SAK Tracking System User Groups Identifies the various system user groups, the levels of system access available, and what level of access each user group will need. Business Requirements Presents a high level future process flow for the SAK tracking system and the business requirements for the solution. Technical Requirements Presents high level proposed system architectures for the SAK tracking system and the technical requirements for the solution. Appendix A Tracking System Scope Decision Papers Presents topic descriptions, key considerations / impacts, recommendations, and additional notes for several critical scope decisions that directly impact system requirements, design, and implementation. Appendix B On Premise Solution Technical Requirements Identifies the additional technical requirements that will be included in the RFP if WSP determines to pursue an on premise solution. These sections provide the relevant information for WSP to communicate to potential RFP bidders the solution requirements for the SAK tracking system. 6 P age

8 3. CURRENT HIGH LEVEL PROCESSES This section provides high level process and information on SAKs. Current practices for storing, testing, and retaining SAKs vary substantially throughout the state. As such, it is important to recognize that there is no standard, consistent process for processing SAKs. Sexual assault cases are inherently nuanced and complex and the same is true for the SAKs associated with an alleged sexual assault incident. There are also different types of SAKs those associated with an active investigation or criminal case filing, those where there was determined to be insufficient evidence to refer to the prosecutor or file criminal charges, those being stored by law enforcement that have not been submitted for forensic analysis, as well as those where the victim chose to not file a police report and / or not consent to forensic analysis of the SAK. In the absence of consistent, standard practices regarding the handling of SAKs throughout the state, each medical facility, law enforcement agency, and prosecuting attorney s office has adapted and implemented an approach that works for their agency. Oftentimes, the current storage timelines or storage locations of the SAKs are based simply on space constraints. In this section, a brief overview of the current types of SAKs are discussed and the high level, admittedly oversimplified, process of each type of SAK is provided. SAK Categorization / Prioritization Previous to House Bill 2530, the Washington State Legislature passed Substitute House Bill 1068, which was enacted into law in July 2015, that requires law enforcement in receipt of a SAK to submit a request for laboratory examination (RFLE) within 30 days to the WSP Crime Lab for prioritization and forensic analysis if consent has been provided by the victim or the victim is under the age of eighteen and not emancipated. According to the Legislation, the WSP Crime Laboratory Division (CLD) developed a taxonomy that would appropriately categorize and prioritize each type of SAK. Short Tandem Repeat (STR) Highest priority of SAKs for testing by WSP CLD. STRs, named after the forensic analysis and testing technique used, are defined as all SAKs associated with a current, active investigation, as indicated by law enforcement upon submission of the RFLE. SAK 2 Second priority SAKs, which are defined as SAKs collected on or after July 24, 2015, which would not have previously been submitted to the CLD prior to the requirement of House Bill Currently, law enforcement is submitting the RFLE to WSP without the evidence (i.e., SAK) due to limited storage capacity by WSP CLD. SAK 3 Third priority SAKs, which are defined as SAKs collected prior to July 24, 2015, where the submission to CLD would not have previously occurred but is now required by House Bill These SAKs are commonly referred to as previously un-submitted kits. The following sections provide high level process diagrams for each type of SAK and a brief description of the process. 7 P age

9 STR For current, active sexual assault investigations, the SAK is completed by a SANE at certain medical facilities throughout Washington State and victims either provide or decline consent to have the kit forensically analyzed. In some instances, an on-call community-based advocate may meet the victim at the medical facility to provide support during the examination. The victim may or may not file a police report. If a report is not filed, the SAK remains at the medical facility for a duration that varies by medical facility or county generally based on local practices and capacity to store the SAKs. Once the duration has passed, in many cases the medical facility attempts to notify the victim and destroys the SAK. In certain counties, local LEAs may store the SAKs even though no police contact has been initiated by the victim, in order to relieve the storage burden on the medical facility. Furthermore, due to House Bill 1068, RFLEs may be submitted to the WSP Crime Lab in some of these cases and the WSP Crime Lab has received some of these SAKs although no testing is occurring because consent has not been provided. For cases where the victim does contact law enforcement, the LEA transports the SAK from the medical facility to its local evidence / property management unit where it is typically logged into the local evidence / property tracking system, creates a case, and assigns a detective. The detective or evidence custodian sends the SAK with RFLE and additional required documents to the appropriate WSP Crime Lab. The RFLE may be sent separate from the SAK with the LEA awaiting a response from WSP Crime Lab that they are ready to receive the evidence. Once the RFLE or SAK with RFLE is received by the WSP Crime Lab, the evidence is logged into the WSP LIMS, stored, forensically analyzed, and, upon completion, returned to the LEA for storage. LEAs determine how long to retain the SAKs based on a variety of factors (e.g., type of case, prosecuting attorney s office s guidance). The STR process, admittedly oversimplified, is represented in the following process diagram. 8 P age

10 SAK 2 SAK 2s, or those collected on or after July 24, 2015, which would not have previously been submitted to the CLD prior to the requirement of House Bill 1068 and are in the possession of law enforcement, follow a slightly different process. Currently, law enforcement is submitting the RFLE to WSP without the evidence (i.e., SAK) due to limited storage capacity by WSP CLD. When WSP is prepared to receive these SAKs, they will notify the LEA to physically transfer or send via mail the SAKs. The following process diagram shows the intended receipt, forensic analysis, and post-analysis transfer of the SAK back to law enforcement for additional investigation (in the case of a CODIS hit) and storage. The SAK 2 process, admittedly oversimplified, is represented in the following process diagram. SAK 3 SAK 3s, or those collected prior to July 24, 2015, where the submission to CLD would not have previously occurred but is now required by House Bill 1068, are commonly referred to as previously un-submitted kits. WSP has contracted with an external laboratory for forensic DNA testing services for the SAK 3 cases. Currently, law enforcement is submitting the RFLE to WSP without the evidence (i.e., SAK). WSP 9 P age

11 notifies law enforcement to send the SAKs directly to the external lab for testing and, when complete, the SAKs are sent directly back to the LEA. Some LEAs are also sending their SAK 3s directly to the FBI under the FBI/NIJ Sexual Assault Kit Partnership program under which the FBI will test previously un-submitted kits at no cost. However, as an example, LEAs in Lewis County, WA, recently sent 30 SAK 3s to the FBI under this program and 17 were returned as not meeting the FBI s testing standards as they were missing the appropriate paperwork. In this particular case, multiple LEAs transported the SAKs to the Lewis County Sheriff s Office, which sent them all in a single shipment to the FBI. SAKs returned by the FBI untested will be stored by the local LEA until arrangements are made with the WSP CLD for testing by the external lab. The following process diagram shows an oversimplified view of the SAK 3s. The current high level processes for each type of SAK help provide an understanding of how the SAK progresses through the testing process differently and illuminate the various user groups that will need access to the SAK tracking system at various points in the process. 10 P age

12 4. SAK TRACKING SYSTEM USER GROUPS House Bill 2530 identifies a number of stakeholders that are required to participate in the statewide SAK tracking system. This section identifies those stakeholder groups, the purpose for which they will access the tracking system, and several key system access details. System User Groups The following user groups have been identified as needing access to the SAK tracking system. Each group of stakeholders and their purpose for accessing / updating the SAK tracking system is provided below: Victims Log into the system anonymously to track the location and status of their SAK, using the SAK tracking information provided to them at the point of collection of the SAK at the medical facility. SANEs Will be responsible for initial SAK entry into the tracking system. In addition, the SANE or other medical facility personnel will be responsible for updating the disposition of the SAK in cases where the SAK is being stored at the medical facility, a police report has not been filed, and the SAK is being destroyed. LEA Officers/Deputies Will be responsible for transporting SAK evidence from the medical facility to the local precinct or evidence / property unit and from the evidence / property unit to the WSP Crime Lab. They will also be responsible for updating the status and location of the SAK if they are a named user in the system with appropriate authority and adequate training. LEA Detectives Will be responsible for submitting the RFLE to the WSP Crime Lab and updating the SAK tracking system accordingly. They will also have the ability to check on the status and location of the kits submitted, as needed. LEA Property / Evidence Management Personnel Will be responsible for updating the status and location of the SAK when received from the medical facility; transferred to the WSP Crime Lab, other contracted entity, or the FBI; and received back into evidence management. WSP Crime Lab Property and Evidence Personnel Will be responsible for updating the location and status of the SAK during the evidence intake and release process at the Crime Lab. Prosecutors Will have the ability to login to the tracking system as a secured user to view the status and location of SAKs for cases in which they are directly involved. System Administrators Will have the ability to login to the back-end of the system for the purpose of tracking all SAKs in the jurisdiction, adding / removing system users within the jurisdiction, running reports, and making changes in the SAK tracking system. Super Users Will have the ability to login to the back-end of the system for the purpose of making configuration changes, running reports, resetting user access, adding / removing system users, and overseeing general system performance. 11 P age

13 With such a diverse user group community, it is important to establish the general roles for system access and permissions. Each user type requires the appropriate access needed to perform their responsibilities. The proposed access types are defined below: Read Only Logs into the system and views the status and location of their SAK; exclusively held by victims. User Read Only Logs into the system with secured login using UserID and Password to view the status and location of kits in the system by manually entering the SAK barcode number; the primary users will be prosecutors. Write Access with Scanner Logs into the system with secured login to update the location or status of a SAK via data entry and / or barcode scanner. Write Access without Scanner Logs into the system with secured login to update the location or status of a SAK via data entry. The primary users will be detectives and some WSP Crime Lab personnel. System Administrator Logs into the system with secured login to track all SAKs in the local jurisdiction, run reports, reset user access, and add / remove system users. Super User Logs into the system with full ability to administer the system including making configuration changes, running reports, resetting user access, adding / removing system users, overseeing general system performance. The following table identifies several attributes of the future SAK tracking system usage. For each entity / agency that will have access to the tracking system, the table identifies the users of the system, whether barcode scanning is needed, access type, actions performed by each group, and estimations of number of users: Entity / Agency Users Barcode Scanner Needed? Access Type Actions Performed Approximate # of Users N/A Victims / Survivors No Read Only Track SAK location / status Unknown 5 Medical Facilities SANEs Yes Write Access with Scanner Initial data entry of SAK ~ According to a survey conducted by WASPC in , the average number of SAKs received by LEAs annually is 1,300 kits. The agencies that responded to the survey comprise 74% of Washington State s population. The same survey revealed there are approximately 6,000 SAKs in Washington that have not been submitted for forensic analysis to the WSP Crime Labs. The number of SAKs that are collected by medical facilities and subsequently destroyed are unknown. Therefore, the approximate number of victims using the tracking system in the future is very difficult to estimate. 6 Slalom is in the process of confirming the approximate number of SANE users with WSHA. For Counties that do not have SANE trained staff, sexual assault exams may still be completed by other medical professionals. A process to enter the SAK data into the tracking system will need to be developed for these scenarios. 12 P age

14 Entities / Agency Users Barcode Scanner Needed? Access Type Actions Performed Approximate # of Users LEAs Detectives / Officers / Deputies No Write Access without Scanner Update SAK location / status ~ LEA Property / Evidence Management Officers / Deputies / Sergeants Yes Write Access with Scanner Update SAK location / status ~600 8 WSP Crime Lab Property and Evidence Property and Evidence Custodians (PECs) Yes Write Access with Scanner Update SAK location / status ~20-25 WSP Crime Lab Additional WSP personnel who process RFLEs No Write Access without Scanner Update SAK location / status ~10 Prosecutors Deputy Prosecutors / Paralegals No User Read Only Track SAK location / status ~200 9 System Administrators Assigned personnel in medical facilities, LEAs, and WSP No System Administrator Manage users in District / local jurisdiction ~ WSP Super Users Assigned personnel No Super User Manage all system administration ~5-10 Note: The number of users are general estimates based on information that was provided during the requirements gathering process. Estimating the number of users is inherently difficult because of the number of user groups, the various agencies involved, and the variety of users within each agency. It is 7 The number of users in this category was estimated based on the total Sexual Assault Unit (SAU) detectives within the Seattle Police Department (SPD) and the population they serve and then extrapolating to all of Washington State. 8 Estimate based on an average of 2 users per LEA for each LEA in Washington State, of which there are 300 agencies. 9 This approximate number includes deputy prosecutors and paralegals. This is a rough estimate provided by a representative from WAPA. 13 P age

15 recommended that over the next several months, WSP starts to gain clarity around the number of users and specific named users in each group. Other Stakeholders There are additional entities that are directly involved in a sexual assault case or may receive possession of a SAK. In order to limit the complexity of an already complicated implementation, the Slalom team recommends that WSP not plan on providing direct tracking system access to the following entities during the initial implementation: Independent Labs Contracting with WSP As mentioned previously, WSP currently contracts with an external laboratory for forensic DNA testing services for the SAK 3 cases. FBI Under the FBI/NIJ Sexual Assault Kit Partnership program, some LEAs are sending previously un-submitted SAKs (i.e., SAK 3s) directly to the FBI. Superior Courts: In rare cases, the Superior Court Clerk may take possession of the SAK as evidence in a court case. In the case of an appeal, the Clerk may have the SAK in its possession for a significant duration. Other Private Labs During the adjudication of the court case, the defense may request that the SAK be tested by another forensic laboratory. Community-Based Victim Advocates In some counties, community-based victim advocates are present during the sexual assault examination to provide support for the victim. These advocates can be a key source of information and healing support for the victims of sexual assault. How the tracking system will be updated to reflect a SAK s location and / or status at these entities is reflected in the high level future process diagram in Section 5 Business Requirements. 14 P age

16 5. BUSINESS REQUIREMENTS The design and implementation of the SAK tracking system will be a complex undertaking. The greatest challenges will not be technical in nature; they will be establishing the policies, procedures, and processes within and between the various entities and individuals that come into the possession of a SAK to ensure the tracking system is updated in a timely and accurate manner. During the Slalom teams initial stakeholder interviews, it was determined that there were several key topics where the scope of the SAK tracking system was inconsistent across the stakeholder groups or within groups. Therefore, the Slalom team recognized the need to develop several Scope Decision Papers, currently provided in Appendix A, that require final decision by the WSP SAK Tracking System Steering Committee (discussion scheduled for 11/2/16 meeting). If approved, the scope of the SAK tracking system and its implementation will be clarified in the following ways: The SAK tracking system is not intended to replace or provide redundancy for current chain of custody, evidence management, LIMS, or other current systems or processes. Personally identifiable information (PII) will not be included in the SAK tracking system if at all possible. No victim notification or updates will be automatically generated by the system. Previously un-submitted SAKs (i.e., SAK 3s) are on a different timeline for entry into the tracking system than the June 1, 2018, Legislative reporting requirement. Completed SAKs currently being stored by law enforcement with no anticipated changes to their location or status are on a different timeline for entry into the tracking system than the June 1, 2018, Legislative reporting requirement. Some entities that come into possession of the SAKs (e.g., external forensic labs, the FBI, Superior Court) will not have direct access to the tracking system but the location and status of the SAK will be entered in the system to reflect current location and status, typically by the LEA that is transferring the SAKs in and out of their possession. These scope guidelines directly impact the requirements for the SAK tracking system and the future processes that are developed to provide consistency, standardization, and optimization of the tracking solution. High Level Future Process Flow The following high level diagram presents a proposed process flow for which various entities will be responsible for updating the location and status of the SAK at key points in the process of a SAK. This is an oversimplified view of the SAK collection; receipt to law enforcement; request for and analysis by the WSP Crime Lab; and receipt, storage, and possible destruction by law enforcement. It does not account for all possible exceptions and variations in the process. More specific details of the specific processes for the future SAK tracking system will be determined once the tracking system vendor is onboard and 15 P age

17 helping WSP design, configure, and implement the SAK tracking solution. Slalom is providing the following high level future process flow as a depiction of how the future tracking system could work and where the various entities in possession of the SAK would update the location and status of the SAK. It should be noted that the victim / survivor should have the ability to track the location and status of their SAK at any point in the process. 16 P age

18 17 P age

19 Business Requirements The business requirements were developed to meet the letter and spirit of the legislation, but were also developed in such a way to provide the Super Users with enough flexibility to modify the system as necessary. The list of business requirements are intended to be included with WSP s upcoming RFP to procure the SAK tracking solution. For each business and technical requirement, bidders will be asked to indicate how their solution meets the requirement in the following five ways: Current Capability This capability is part of the vendor s system and has been in production for no less than 6 months; current capabilities do not require additional configuration or cost. Requires Configuration This capability can be met through vendor-supported changes to existing settings and application options as part of the initial implementation at no additional cost (e.g., setting naming conventions, creating user-defined fields). Modification to Software Required The requirement can be met through vendor-supported writing or changing new or existing software code that can be completed as part of the initial implementation at no additional cost. Future Enhancement This capability is a planned enhancement and will be available within the next 12 months at no additional cost. Not Available This capability is not currently available and a future enhancement is not planned. The full list of business requirements for the SAK tracking system, separated into a number of functional categories is provided in the table below. ID Business Requirement General Business GB-1 GB-2 GB-3 GB-4 GB-5 GB-6 GB-7 GB-8 The system must comply with Washington State Second Substitute House Bill 2530 available at: S2.PL.pdf The system must create a new record for a sexual assault kit (SAK). The system must assign a unique barcode number for each SAK. The system must track the jurisdiction of the SAK (i.e., the LEA anticipated to receive the SAK or otherwise in the custody of the SAK). The system must be able to change the jurisdiction of the SAK. The system must capture date/time stamp of the scanned barcode. The system must capture date/time stamp of the updated record (i.e., manual data entry). The system must integrate with current barcode scanners (e.g., at existing LEA evidence and property management units, at WSP Crime Labs). 18 P age

20 ID GB-9 GB-10 GB-11 GB-12 GB-13 Business Requirement The system must integrate with new barcode scanners. The system must print barcodes that are visibly and clearly distinguishable from other barcodes on the SAK (e.g., barcodes from the medical facility, LEA, or LIMS). The system must indicate and display whether consent was provided for forensic analysis. The system must support the changing of whether consent has been provided for forensic analysis. The system must identify a SAK associated with a juvenile victim. Location / Status LS-1 LS-2 LS-3 LS-4 LS-5 LS-6 LS-7 LS-8 LS-9 LS-10 LS-11 LS-12 LS-13 The system must track the location of the SAK, including various types of locations (e.g., medical facilities, LEAs, WSP Crime Labs, other forensic labs, and other entities) in possession of the SAK. The system must store the complete tracking history of the SAK including location and status. The system must track the specific location / entity in possession of the SAK (e.g., Harborview Medical Center, Tacoma Police Department, WSP Spokane Crime Lab, Other Forensic Analysis Laboratory, King County Superior Court, etc.). The system must associate and display a contact phone number for the location / entity in possession of the SAK (e.g., Harborview Medical Center, Tacoma Police Department). The system must record transfers of SAKs between the same types of entities (e.g., LEA to LEA, WSP Crime Lab to WSP Crime Lab). The system must record historical location(s) and status(es) of SAKs with an approximate date/time (e.g., LEA completing initial entry of the SAK and recording medical facility location, SAK status, date/time) that is different than the time stamp of when the record is updated. The system must track the status of the SAK, including various types of statuses (e.g., collected, forensic analysis requested, forensic analysis completed, transferred, stored, disposed). The system must display a variety of messages to the user based on different logic that includes the status and location of the SAK (e.g., if forensic analysis has been requested but the SAK remains stored at the LEA, if the SAK is being stored at the WSP Crime Lab but consent for forensic analysis has not been provided and therefore the SAK will not be analyzed). The system must display individually entered messages, as needed, to explain the location and status of the SAK. The system must identify when SAKs are transferred to a jurisdiction outside of Washington State (e.g., LEAs outside of Washington, federal jurisdiction). The system must relate entities (e.g., LEAs, medical facilities) to a City and / or a County. The system must relate jurisdictions to a City and / or a County. The system must relate jurisdictions to a WSP District. 19 P age

21 ID LS-14 Business Requirement The system must display contact information for victim resources (e.g., community-based advocates). Reporting 10 RE-1 RE-2 RE-3 RE-4 RE-5 RE-6 RE-7 RE-8 RE-9 RE-10 RE-11 RE-12 RE-13 RE-14 RE-15 The system must provide robust ad hoc reporting capabilities based on inclusion / exclusion and filtering or sorting on specific fields. The system must report the total number of SAKs in the system statewide. The system must report the total number of SAKs by jurisdiction. The system must report the total number of SAKs where forensic analysis has been completed statewide on an annual and semiannual basis, by date range. The system must report the total number of SAKs where forensic analysis has been completed by jurisdiction on an annual and semiannual basis, by date range. The system must report the total number of SAKs where forensic analysis has been completed by jurisdiction. The system must report the total number of SAKs added to the system during a specific period statewide. The system must report the total number of SAKs added to the system during a specific period by jurisdiction. The system must report the total and semiannual number of SAKs where forensic analysis has been requested but not completed statewide. The system must report the total and semiannual number of SAKs where forensic analysis has been requested but not completed by jurisdiction. The system must report the average and median length of time for SAKs to be submitted for forensic analysis after being added to the system for all SAKs in the system statewide. The system must report the average and median length of time for SAKs to be submitted for forensic analysis after being added to the system for all SAKs in the system by jurisdiction. The system must report the average and median length of time for SAKs to be submitted for forensic analysis after being added to the system for SAKs added to the system during a specific period statewide. The system must report the average and median length of time for SAKs to be submitted for forensic analysis after being added to the system for SAKs added to the system during a specific period by jurisdiction. The system must report the average and median length of time for forensic analysis to be 10 The reports identified in requirements RE-2 through RE-24 are legislatively mandated by House Bill 2530 with the first report due July 31, P age

22 ID RE-16 RE-17 RE-18 RE-19 RE-20 RE-21 RE-22 RE-23 RE-24 RE-25 RE-26 Business Requirement completed on SAKs after being submitted for analysis for all SAKs in the system statewide. The system must report the average and median length of time for forensic analysis to be completed on SAKs after being submitted for analysis for all SAKs in the system by jurisdiction. The system must report the average and median length of time for forensic analysis to be completed on SAKs after being submitted for analysis for SAKs added to the system during a specific period statewide. The system must report the average and median length of time for forensic analysis to be completed on SAKs after being submitted for analysis for SAKs added to the system during a specific period by jurisdiction. The system must report the total and semiannual number of SAKs destroyed or removed from the system statewide. The system must report the total and semiannual number of SAKs destroyed or removed from the system by jurisdiction. The system must report the total number of SAKs where forensic analysis has not been completed and six months or more has passed since those SAKs were added to the system statewide. The system must report the total number of SAKs where forensic analysis has not been completed and six months or more has passed since those SAKs were added to the system by jurisdiction. The system must report the total number of SAKs where forensic analysis has not been completed and one year or more has passed since those SAKs were added to the system statewide. The system must report the total number of SAKs where forensic analysis has not been completed and one year or more has passed since those SAKs were added to the system by jurisdiction. The system must run complex queries to produce the reports listed in these requirements (e.g., exclude SAKs where a request for forensic analysis has been received by the WSP Crime Lab but the victim has not provided consent for the SAK to be forensically analyzed, exclude SAKs where a request for forensic analysis was not completed because the SAK was destroyed by the medical facility). The system must produce all of the required reports by City, County, and WSP District. Querying QU-1 QU-2 The system must search for SAKs by various attributes (e.g., barcode number, date SAK was added) for certain roles. The system must provide enhanced search capabilities for certain users to search the system based on additional attributes (e.g., partial or complete SAK barcode number, state, city, date, 21 P age

23 ID location of the SAK). Business Requirement QU-3 QU-4 The system must support users sorting search results. The system must support users filtering search results. Other OT-1 OT-2 OT-3 OT-4 OT-5 OT-6 OT-7 OT-8 OT-9 The system must support a system administrator adding new values to tables. The system must display a variety of messages regarding expected timeframes to the user (e.g., timeframe from SAK collection to completed forensic analysis is approximately XX to XX months based on current caseload), depending on location and status of SAK. The system must support a system administrator editing the messages regarding expected timeframes. The system must provide quick data entry for users updating the location or status of a SAK. The system must support batch processing of SAKs by updating multiple SAKs with the same location and status (e.g., 5 SAKs with new LEA location and status). The system must support entering notes regarding the SAK s location or status changes for certain roles (e.g., if a SAK is returned from the WSP Crime Lab to the LEA and has not been forensically analyzed, an explanation can be provided). The system must support multiple user views depending on role and type of user (e.g., victim, prosecutor, LEA, WSP Crime Lab, System Administrator). The system must log all user transactions for auditing purposes. The system must support batch printing of barcode stickers. 22 P age

24 6. TECHNICAL REQUIREMENTS The technical requirements were developed to align and support the business requirements. In addition, it was determined that the technical requirements needed to ensure the ability for the SAK information to be found and tracked. All requirements support a victims right to anonymously inform themselves of the location and status of their SAK, and access information concerning the agency to contact with follow-up questions. The technical requirements also ensure WSP s ability to manage and update the SAK tracking system as needed; actions such as, but not limited to, access management, user management, SAK victim management, and SAK reporting are system-wide functions that WSP will need to successfully manage in the tracking system. Considering the sensitive information stored on this site, specific security measures are outlined as well. The Slalom team collaborated with current WSP IT leaders to ensure the agency would be able to support the technical requirements with WSP s current technical landscape. High Level Technical Architecture Allowing victims to anonymously track their SAKs requires special security considerations. The high level technical architecture of a system that will allow a user to login anonymously may be designed in the following manner: This is a representation of how the system could be architected to ensure privacy as well as system security. It is not intended to be an exact depiction of the solution, which will be architected by the tracking system vendor. 23 P age

25 The high level technical architecture of the system from the perspective of those scanning SAKs in and out of the system (e.g., SANEs, LEA personnel, WSP Crime Lab personnel) and updating the status and location of the SAKs may be designed in such a manner: Technical Requirements The technical requirements capture the guidelines necessary to successfully set up and maintain a system that will provide a victim the ability to anonymously track their SAK, as well as provide general guidelines to System Administrators for the successful ongoing maintenance of the system. 12 ID Technical Requirement General Technical GT-1 The software must meet or exceed the security requirements outlined in Washington State s OCIO Policy ( This includes: A security design review (facilitated by Washington Technology Solutions [WaTech]) with the Washington State Office of Cyber Security (WA-OCS). A design review requires that the bidder provide 1) a network security diagram depicting how information flows through the software including all firewalls, intrusion detection/prevention systems (IDS/IPS), and connection types and 12 WSP s current technology environment is highly Microsoft-based. While non-microsoft-based solution providers are not precluded from responding to the RFP, the RFP will be clear that WSP has a strong preference for Microsoft-based solutions. 24 P age

26 ID GT-2 GT-3 GT-4 GT-5 Technical Requirement 2) a SOC 2 Type 2 audit report for the datacenter where the software is hosted, if applicable/available. A design review evaluates data, network, access, and application security controls as well as change management, media handling and disposal, data/program backup, security monitoring and logging, and incident response processes. The bidder will cover all costs associated with the design review. The ability to encrypt data in transit using TLS 1.0 (AES-256) at minimum. TLS 1.2 is preferred. The ability to enforce multifactor authentication (MFA) for all administrative access into the solution both by the bidder and by DEL. The ability to build and customize "user" profiles, (e.g. Roll-based access control (RBAC)). Profile type examples include administrator, substitute, and facility user(s). The ability for system administrator(s) to perform administrative tasks, including: 1) set and reset passwords; 2) define and maintain security roles; 3) define and maintain user profiles; and 4) define and maintain system access levels, etc. Please describe your RBAC. The system must support the User Interface (UI) browser based and made available via the Internet. The system must support Transport Layer Security (TLS) version 1.0 or higher for encryption of data in transit. TLS version 1.2 is preferred. The system must support a secured (SSL) connection for all authentication requests. The system must use enhanced security features like Captcha for protecting the web based application against bot attacks. GT-6 The system must be a cloud hosted solution and must comply to WSP s security standards. 13 GT-7 GT-8 GT-9 The system must include multiple environments (e.g., Development, User Acceptance Testing, Training, and Production). Production should have a physically separate environment and Production data will not be used in non-production environments without some level of obfuscation. The system must support multi-factor authentication. The system's User Interface must adhere to WSP's standard UI guidelines. System Requirements SR-1 SR-2 SR-3 The system must support an interface for the victim and/or their guardian to login. The system must support an interface for tracking system Users to login. The system must support disabling the account if more than 3 incorrect attempts to login are made. User must be displayed a message to contact their administrators to reactivate their account. 13 The decision to procure a cloud-based or on-premise solution is still being determined by WSP. The business and technical requirements that will be included in the RFP will be updated to reflect WSP s final decision. 25 P age

27 ID SR-4 SR-5 SR-6 Technical Requirement The system must not capture any PII data for the victim, if possible. The system must support different roles as listed below for SAK tracking system Administrators/Users Read Only: Logs into the system and views the status and location of their SAK; exclusively held by victims. User Read Only: Logs into the system with secured login using UserID and Password to view the status and location of all kits in the system by manually entering the SAK barcode number; the primary users will be prosecutors. Write Access with Scanner: Logs into the system with secured login to update the location or status of a SAK via data entry and / or barcode scanner. Write Access without Scanner: Logs into the system with secured login to update the location or status of a SAK via data entry. The primary users will be detectives and some WSP Crime Lab personnel. System Administrator: Logs into the system with secured login to track all SAKs in the local jurisdiction, run reports, reset user access, and add / remove system users. Super User: Logs into the system with full ability to administer the system including making configuration changes, running reports, resetting user access, adding / removing system users, overseeing general system performance. The system will have the ability to support auto-generation of globally unique IDs for victims (SAKVID), victims guardians (SAKGID) [where applicable], users (SAKUID), System Administrators (SAKADM) and Super Users (SAKSPU). SR-7 The system will have the ability to generate all IDs with 11 to 13 characters and will start with a 3 letter code appended to random 8 to 10 alphanumeric characters. The codes for each ID type must be unique, namely: For SAKVID : SVI For SAKGID : SGI For SAKUID : UID For SAKADM : ADM For SAKSPU : SPU SR-8 SR-9 SR-10 SR-11 The system will meet or exceed the Washington State s OCIO minimum standards for password security. Passwords will be a minimum of 10 characters long and contain at least three of the following character classes: uppercase letters, lowercase letters, numerals, special characters. Passwords will not contain the user's name, User ID or any form of their full name, will not be a complete dictionary word, and will be significantly different from the previous four passwords. The system must store all passwords in a database and they must be in encrypted or cryptographically hashed form. The system must force password changes at specified intervals, and not allow users to re-use the same password, or a recently used password. The system must enable users to reset their password. The system must prompt user to enter the 26 P age