Sexual Assault Kit (SAK) Tracking System Project Management Washington State Patrolwastatepatrol.net/sak/wp-content/uploads/2017/02/SAK... · 2017-02-09 · 1 All entities in possession

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

TABLE OF CONTENTS

TABLE OF CONTENTS ...................................................................................................................................... i

1. DOCUMENT PURPOSE AND REVISION HISTORY ...................................................................................... 2

2. INTRODUCTION ........................................................................................................................................ 3

SAK Tracking System Project Objectives ................................................................................................ 3

Approach to Collecting the Requirements ............................................................................................. 4

General SAK Tracking System Philosophy .............................................................................................. 5

Document Organization ......................................................................................................................... 6

3. CURRENT HIGH LEVEL PROCESSES ........................................................................................................... 7

SAK Categorization / Prioritization ......................................................................................................... 7

STR .......................................................................................................................................................... 8

SAK 2 ...................................................................................................................................................... 9

SAK 3 ...................................................................................................................................................... 9

4. SAK TRACKING SYSTEM USER GROUPS .................................................................................................. 11

System User Groups ............................................................................................................................. 11

Other Stakeholders .............................................................................................................................. 14

5. BUSINESS REQUIREMENTS ..................................................................................................................... 15

High Level Future Process Flow ........................................................................................................... 15

Business Requirements ........................................................................................................................ 18

6. TECHNICAL REQUIREMENTS .................................................................................................................. 23

High Level Technical Architecture ........................................................................................................ 23

Technical Requirements ....................................................................................................................... 24

7. APPENDIX A – TRACKING SYSTEM SCOPE DECISION PAPERS ................................................................ 30

8. APPENDIX B – ON PREMISE SOLUTION TECHNICAL REQUIREMENTS .................................................... 40

2 | P a g e

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

1.0 10/31/16 Initial draft. Slalom Team

1.1 10/31/16

Reviewed initial draft with Robert Marlatt, Stephen Guest, and Nichole Minas and incorporated feedback. Draft ready for distribution to WSP SAK Tracking System Steering Committee.

Slalom Team

2.0 11/9/16 Incorporated the feedback from WSP SAK Tracking System Steering Committee members for final version.

Slalom Team

2.1 11/16/16 Incorporated the feedback from Representative Tina Orwall on Topic 5 in Appendix A.

Slalom Team

3 | P a g e

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) 43.43.545 – 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, 2018. However, WSP intends to use a phased implementation process, as allowed for in the RCW, with the creation of a pilot program mid-2017.

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 destruction2

• 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.

4 | P a g e

• 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 data3

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 Force4 • 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.

5 | P a g e

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.

6 | P a g e

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.

7 | P a g e

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 1068. 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 1068. 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.

8 | P a g e

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.

9 | P a g e

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

10 | P a g e

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.

11 | P a g e

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.

12 | P a g e

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

Unknown5

Medical Facilities

SANEs Yes Write Access with Scanner

Initial data entry of SAK

~150-2506

5 According to a survey conducted by WASPC in 2014-2015, 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.

13 | P a g e

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

~100-2007

LEA Property / Evidence Management

Officers / Deputies / Sergeants

Yes Write Access with Scanner


~6008

WSP Crime Lab Property and Evidence

Property and Evidence Custodians (PECs)

Yes Write Access with Scanner


~20-25

WSP Crime Lab Additional WSP personnel who process RFLEs

No Write Access without Scanner


~10

Prosecutors Deputy Prosecutors / Paralegals

No User Read Only Track SAK location / status

~2009

System Administrators

Assigned personnel in medical facilities, LEAs, and WSP

No System Administrator

Manage users in District / local jurisdiction

~100-125

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.

14 | P a g e

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.

15 | P a g e

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

16 | P a g e

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.

17 | P a g e

18 | P a g e

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 The system must comply with Washington State Second Substitute House Bill 2530 available at: http://lawfilesext.leg.wa.gov/biennium/2015-16/Pdf/Bills/House%20Passed%20Legislature/2530-S2.PL.pdf

GB-2 The system must create a new record for a sexual assault kit (SAK).

GB-3 The system must assign a unique barcode number for each SAK.

GB-4 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).

GB-5 The system must be able to change the jurisdiction of the SAK.

GB-6 The system must capture date/time stamp of the scanned barcode.

GB-7 The system must capture date/time stamp of the updated record (i.e., manual data entry).

GB-8 The system must integrate with current barcode scanners (e.g., at existing LEA evidence and property management units, at WSP Crime Labs).

http://lawfilesext.leg.wa.gov/biennium/2015-16/Pdf/Bills/House%20Passed%20Legislature/2530-S2.PL.pdf

http://lawfilesext.leg.wa.gov/biennium/2015-16/Pdf/Bills/House%20Passed%20Legislature/2530-S2.PL.pdf

19 | P a g e


GB-9 The system must integrate with new barcode scanners.

GB-10 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).

GB-11 The system must indicate and display whether consent was provided for forensic analysis.

GB-12 The system must support the changing of whether consent has been provided for forensic analysis.

GB-13 The system must identify a SAK associated with a juvenile victim.

Location / Status

LS-1 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.

LS-2 The system must store the complete tracking history of the SAK including location and status.

LS-3 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.).

LS-4 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).

LS-5 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).

LS-6 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.

LS-7 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).

LS-8 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).

LS-9 The system must display individually entered messages, as needed, to explain the location and status of the SAK.

LS-10 The system must identify when SAKs are transferred to a jurisdiction outside of Washington State (e.g., LEAs outside of Washington, federal jurisdiction).

LS-11 The system must relate entities (e.g., LEAs, medical facilities) to a City and / or a County.

LS-12 The system must relate jurisdictions to a City and / or a County.

LS-13 The system must relate jurisdictions to a WSP District.

20 | P a g e


LS-14 The system must display contact information for victim resources (e.g., community-based advocates).

Reporting10

RE-1 The system must provide robust ad hoc reporting capabilities based on inclusion / exclusion and filtering or sorting on specific fields.

RE-2 The system must report the total number of SAKs in the system statewide.

RE-3 The system must report the total number of SAKs by jurisdiction.

RE-4 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.

RE-5 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.

RE-6 The system must report the total number of SAKs where forensic analysis has been completed by jurisdiction.

RE-7 The system must report the total number of SAKs added to the system during a specific period statewide.

RE-8 The system must report the total number of SAKs added to the system during a specific period by jurisdiction.

RE-9 The system must report the total and semiannual number of SAKs where forensic analysis has been requested but not completed statewide.

RE-10 The system must report the total and semiannual number of SAKs where forensic analysis has been requested but not completed by jurisdiction.

RE-11 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.

RE-12 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.

RE-13 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.

RE-14 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.

RE-15 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, 2018.

21 | P a g e

ID Business Requirement completed on SAKs after being submitted for analysis for all SAKs in the system statewide.

RE-16 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.

RE-17 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.

RE-18 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.

RE-19 The system must report the total and semiannual number of SAKs destroyed or removed from the system statewide.

RE-20 The system must report the total and semiannual number of SAKs destroyed or removed from the system by jurisdiction.

RE-21 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.

RE-22 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.

RE-23 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.

RE-24 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.

RE-25 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).

RE-26 The system must produce all of the required reports by City, County, and WSP District.

Querying

QU-1 The system must search for SAKs by various attributes (e.g., barcode number, date SAK was added) for certain roles.

QU-2 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,

22 | P a g e

ID Business Requirement location of the SAK).

QU-3 The system must support users sorting search results.

QU-4 The system must support users filtering search results.

Other

OT-1 The system must support a system administrator adding new values to tables.

OT-2 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.

OT-3 The system must support a system administrator editing the messages regarding expected timeframes.

OT-4 The system must provide quick data entry for users updating the location or status of a SAK.

OT-5 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).

OT-6 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).

OT-7 The system must support multiple user views depending on role and type of user (e.g., victim, prosecutor, LEA, WSP Crime Lab, System Administrator).

OT-8 The system must log all user transactions for auditing purposes.

OT-9 The system must support batch printing of barcode stickers.

23 | P a g e

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:11

11 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.

24 | P a g e

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 141.10 (https://ocio.wa.gov/policies/141-securing-information-technology-assets/14110-securing-information-technology-assets). 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.

https://ocio.wa.gov/policies/141-securing-information-technology-assets/14110-securing-information-technology-assets

https://ocio.wa.gov/policies/141-securing-information-technology-assets/14110-securing-information-technology-assets

25 | P a g e

ID 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.

GT-2 The system must support the User Interface (UI) browser based and made available via the Internet.

GT-3 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.

GT-4 The system must support a secured (SSL) connection for all authentication requests.

GT-5 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 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.

GT-8 The system must support multi-factor authentication.

GT-9 The system's User Interface must adhere to WSP's standard UI guidelines.

System Requirements

SR-1 The system must support an interface for the victim and/or their guardian to login.

SR-2 The system must support an interface for tracking system Users to login.

SR-3 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.

26 | P a g e


SR-4 The system must not capture any PII data for the victim, if possible.

SR-5 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.

SR-6 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 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.

SR-9 The system must store all passwords in a database and they must be in encrypted or cryptographically hashed form.

SR-10 The system must force password changes at specified intervals, and not allow users to re-use the same password, or a recently used password.

SR-11 The system must enable users to reset their password. The system must prompt user to enter the

27 | P a g e

ID Technical Requirement FUID and send a password reset link to their email address.

SR-12 The system must associate SAKVID and/or SAKGID with the SAK barcode number.

SR-13 The system must support associating multiple SAKVIDs and SAKGIDs with a unique SAK barcode number.

SR-14 The system must support only one SAKVID and SAKGID to be in "Active" status at any given time for a specific SAK barcode number.

SR-15 The system must support "Expiring" a SAKVID or SAKGID when a new SAKVID or SAKGID is generated for any given victim.

SR-16 The system vendor must recommend various options to enable victims to login securely to track their status using SAKVID. It is preferred that no victim PII data be stored in the system.

SR-17 The system must not enable generating a new SAKVID or SAKGID if the victim’s identity has not been established.

SR-18 The system must ensure that SAKVID is hidden when victim is entering the data on the SAK website.

SR-19 The system must support the victim to track status of the SAK using their SAKVID.

SR-20 The system must register last login date for all users.

SR-21 The system must log all updates and capture appropriate audit trail.

SR-22 The system must enable users to enter and/or update the SAK tracking information depending on their role.

SR-23 The system must store the location of the SAK and the name of the individual SAK was received by.

SR-24 The system must support the ability for users to generate standard and ad hoc reports.

SR-25 The system must generate a separate Guardian Tracking ID SAKGID and should not be same as SAKVID.

SR-26 The system must enable guardian to track status of the kit using their SAKGID.

SR-27 The system must display to victim on the tracking page the last login date and "Guardian Tracking Enabled" status only if the victim has a guardian.

Administrative Requirements

AR-1 The system must provide Super Users the ability to onboard and manage different Agencies and associated details like agency type, address, primary contact, email, agency phone number, and jurisdiction.

AR-2 The system must provide Super Users the ability to create and manage different Agency Types.

AR-3 The system must support the creation of a user(s) with System Administrator role for any given

28 | P a g e

ID Technical Requirement Agency.

AR-4 The system must support Super Users to specify the user name, user role, user badge id, user email and user phone number for a given user record and associate it with SAKADM, SAKSPU Ids auto generated by the system.

AR-5 The system must generate a one-time password for all newly created users and send an email with a link to enable user to complete registration process. Clicking the link should enforce user to complete a registration process.

AR-6 The system must prompt user to create their own friendly userID (FUID) that should be globally unique and a password that they can use for logging in to the system. The friendly userID will be associated with the system generated Id.

AR-7 The system must enable Super Users to configure, create new and manage roles (e.g., Read Only, User Read Only, Write Access with Scanner, Write Access without Scanner, System Administrator, Super User)

AR-8 The system must enable Super Users to configure SAK statuses to be used.

AR-9 The system must enable Super Users to configure all Entities that are entitled to possess a SAK (e.g., Harborview Medical Center, Tacoma Police Department) along with the entity’s address, county and contact person details.

AR-10 The system must enable System Administrators to create users within their own Agency domain.

AR-11 The system must enable System Administrators to update victim's info, like generating new SAKVID, assigning a guardian, generating guardian ID, removing a guardian.

AR-12 The system must enable victims to search for the nearest Agency (e.g., local law enforcement agency, WSP Crime Lab, medical facilities) where they can reach out to System Administrators to help update their account.

AR-13 The system must disable user accounts that have been inactive for a duration of time. Super User will have ability to configure the inactivity duration at a system level.

AR-14 The system must notify a user and their System Administrator via email a certain number of days before their account is disabled. The number of days must be configurable by Super User at a system level.

AR-15 The system must enable users with System Administrator role to disable/remove the guardian on request of the victim, provided victim has established their identity with the System Administrator.

AR-16 In cases where the system is not able to detect the barcode number via scanner, the system must allow the user to enter the SAK barcode number manually.

AR-17 The system must enable Super Users and System Administrators to enable/disable/remove users.

Deployment

29 | P a g e


DE-1 The system must be deployed with enough redundancy and all web application servers must be load balanced.

DE-2 The system must store all data in a database that has encryption of data at rest enabled.

DE-3 The system must take regular backup of data and must have system restore capabilities.14

DE-4 The system must have an availability time of 99.9%.

DE-5 The system must have active monitoring, auditing of all servers.

DE-6 The system must report the performance and availability metrics at regular intervals or on demand.15

System Support

SS-1 Vendor must provide full access to the application database(s) for report creation, and ad hoc SQL queries for problem isolation, and responding to investigative and public disclosure requests.

SS-2 Vendor must provide a complete and documented data dictionary for the applications mapped to the complete database schema for all application tables. Additionally, we require mapping of the User Interface elements to the database schema. Documentation should include field descriptions, entity relationship diagrams, and all foreign key constructs.

SS-3 Vendor must provide fully replicated production environments for UAT, test, and QA.

SS-4 Vendor must provide the ability for audit log files and high volume production data used in intensive reporting (e.g., the reports listed in the business requirements) to be replicated to, or migrated to, a separate environment to allow WSP to run reports, research issues, and run ad hoc reports for investigative and public disclosure requirements without impacting response time in the production environment.

SS-5 Vendor must provide a system that is highly responsive and highly available at all times. Where server and application fault-tolerance apply, Microsoft Windows Failover Clustering and its associated back-end infrastructure must be supported. This includes (but is not limited to) fiber-channel attached shared storage, Cluster Shared Volumes (CSV), live migration, and performance resource optimization (PRO).

14 The RFP will ask bidders to discuss their Disaster and Recovery Plan in their RFP response. 15 The RFP will ask bidders to identify what types of performance metrics their solution typically provides.

30 | P a g e

7. APPENDIX A – TRACKING SYSTEM SCOPE DECISION PAPERS

Topic 1: General System Scope Topic Description The Revised Code of Washington (RCW) 43.43.545 – Statewide Sexual Assault Kit Tracking System – Section 2.a states that “The statewide sexual assault kit tracking system must: Track the location and status of sexual assault kits throughout the criminal justice process, including the initial collection in examinations performed at medical facilities, receipt and storage at law enforcement agencies, receipt and analysis at forensic laboratories, and storage and any destruction after completion of analysis.”

The purpose of the tracking system is to provide visibility to survivors of the location and status of the SAK. Our understanding is that it is not intended to replace current chain of custody practices or to provide the same functionality as a Laboratory Information Management System (LIMS) or Evidence / Property Management System. As such, updates to the system should be made at key location or status changes but not at a level of granularity that implies more detailed tracking of the transfer of custody, the contents of the SAK, the evidence included in the case but outside of the SAK (e.g., toxicology, articles of clothing), the status of the survivor’s case in the criminal justice process (e.g., referred to the prosecutor by the detective or the prosecution’s decision to file or decline), or the actual results of the forensic analysis (e.g., CODIS hit). The system should track the change in location or status of the SAK at key transition points (e.g., location updated from X medical facility to Y law enforcement agency (LEA), status updated from forensic analysis requested to forensic analysis completed).

Key Considerations / Impacts

- For certain agencies, any LEA officer / deputy can be responsible for retrieving SAKs from medical facilities. Therefore, the receipt of the SAK by LEA should be updated in the system by the evidence unit or detective when the SAK arrives at the LEA for several reasons (e.g., adequate training, system knowledge, system licensing).

- The current chain of custody processes have been in place for significant time and are not considered inherently flawed. The intent of the tracking system is to provide information to the survivor regarding the location and status of the SAK, not replace current chain of custody procedures.

- There are some cases when the SAK is in the possession of an agency that does not typically store SAKs (e.g., submitted into evidence and stored by the Superior Court Clerk, submitted to the FBI for testing of previously un-submitted SAKs, temporarily retrieved by the prosecutor from the court clerk to be delivered to the LEA). It is unreasonable to assume that every individual who may come into contact with a SAK would have login access to the system or adequate system training.

- Current LIMS and evidence / property management systems track more granular details about the SAK than the Legislation intended, including evidence submitted with the kit and exact storage location. The tracking system is not intended to replace or duplicate the systems that are currently in place.

- If the scope were expanded to require physical receipt of the SAK by all agencies / individuals who are even temporarily in possession of a SAK, there are substantial impacts to system access, system security, training needs, system cost (including additional barcoding devices), and data accuracy.

31 | P a g e

Recommendation Slalom recommends that the tracking system is updated at key points in the process as the SAK changes location and status. The key points currently identified include:

- Initial creation at the medical facility by the SANE - Disposition of the SAK at the medical facility by medical staff / SANE - Transfer of the SAK from the medical facility to the LEA by the LEA evidence / property

management unit or detective - Request for forensic analysis of the SAK by the LEA or WSP Crime Lab. Note: the WSP Crime

Lab may receive the request for forensic analysis prior to receiving the SAK (e.g., Seattle Police Department and King County Sheriff’s Office).

- Transfer of the SAK from the LEA to the WSP Crime Lab by the WSP Crime Lab property and evidence custodians

- Transfer of the SAK from the LEA or WSP Crime Lab to a third party lab, federal agency, or other agency receiving possession of the SAK by the LEA or WSP Crime Lab

- Completion of forensic analysis of the SAK by the WSP Crime Lab or LEA - Transfer of the SAK from the WSP Crime Lab to the LEA by the WSP Crime Lab property and

evidence custodians - Receipt of the SAK from a third party lab, federal agency, or other agency in possession of

the SAK to the LEA by the LEA - Disposition of the SAK at the LEA by the LEA evidence / property management unit

Updating the location and status of the SAK in the tracking system at these key process points would align with the intent of the Legislation and provide the accountability and information to the survivors that is intended.

Additional Notes The philosophy of the tracking system outlined above was socialized with all interviewed stakeholders during Slalom’s discussions to complete the business requirements for the system. There was general consensus by all parties that this was the correct approach (e.g., SANEs, LEAs, WSP Crime Labs, Prosecutors, Survivors). The one exception was a discussion with two representatives from the Washington Association of Sheriffs and Police Chiefs (WASPC) who were under the impression that the tracking system would log the SAKs in and out of every agency similar to a chain of custody system. Slalom does not believe that WSP can be successful implementing the tracking system as a chain of custody system requiring this level of granularity and highly recommends that, to satisfy the spirit and letter of the RCW 43.43.545, a more reasonable guiding philosophy is approved for the tracking system as outlined in the Key Considerations / Impacts above. 10/24/16 – According to WSP’s Government and Media Relations (GMR) team that met with Representative Orwall, the Representative is comfortable with this approach.

Decision Steering Committee Decision: 11/02/16 – The Steering Committee members discussed this topic and confirmed the SAK Tracking System should not act as a chain of custody system, but rather operate as a high-level tracking system. The majority ruled in favor to move forward with this approach.

32 | P a g e

Topic 2: Victim Information / PII in Tracking System Topic Description The Revised Code of Washington (RCW) 43.43.545 – Statewide Sexual Assault Kit Tracking System – Section 2.c states that “The statewide sexual assault kit tracking system must…Allow victims of sexual assault to anonymously track [emphasis added] or receive updates regarding the status of their sexual assault kits.”

WSP and the Slalom team need guidance on whether victim information should be entered into the tracking system. The Legislation requires that the SAK’s location and status will be tracked from collection until disposition. The intent of the legislation is to track all SAKs for the purpose of allowing survivors to check on the status and location of their kit and provide the ability for WSP to report on a variety of statistics regarding the number, location, and status of SAKs within Washington State and local jurisdictions. The design and implementation of the tracking system is highly dependent on coming to a decision regarding whether victim information will be included in the tracking system. Victim information is extremely sensitive, especially since the intent of the Legislation is to track all SAKs, which includes adults and juveniles. However, there are several key considerations to take into account when determining how the tracking system will function and how victims will be able to securely access their SAK information with or without victim information in the system.

Key Considerations / Impacts If victim information is not included:

- The system will feel more anonymous and capture only information about the SAK and the location and status history through collection, forensic analysis, and storage.

- The system will be less complex (e.g., does not necessarily require data to be encrypted for protection, involve PII or HIPAA compliance protections).

- The system will be less secure to other individuals accessing the information. Anyone provided the information about the SAK (e.g., either SAK number or SAK number as well as survivor’s date of birth) could access the SAK’s location and status information. In some cases, this may be desirable (e.g., the victim advocate on the behalf of the victim) while in other cases, if given access to the information, it may be undesirable (e.g., the defense or accused).

- The system will be potentially less secure to intrusion; however, there is no victim information stored in the system.

- The process to regain the SAK number would be complex if lost (or unknown at time of system implementation) by the survivor as the data would not be located within the tracking system and identity could not be verified by WSP.

If victim information is included: - The system will be more secure in terms of accessing the information with additional levels

of authentication for the victim in order to access the SAK location and status. Note: this would require victims to create a user account much like modern systems do to access financial account or medical record information.

- System cost and complexity will increase as a result of the higher system security requirements associated with storing and managing sensitive data (e.g., PII, HIPAA compliance) for the victim as well as the adult guardian (in the case of juveniles).

- Tracking of the SAK would not feel anonymous as the survivor would need to log in to the

33 | P a g e

system to view the location and status of her/his case. - There is additional risk exposure to WSP to protect this very sensitive information.

Recommendation There is general consensus among the various stakeholders that excluding victim information is the desired approach. However, we seek the input of Representative Orwall and WSP to determine the best approach in terms of system design.

Additional Notes 10/24/16 – According to the GMR team that met with Representative Orwall, the Representative is comfortable with this approach.

Decision Steering Committee Decision: 11/02/16 – The Steering Committee members discussed this recommendation. There was concern around using a victim’s date of birth with the SAK tracking system. The majority ruled in favor of the recommendation to avoid PII data in the system, as much as possible. The tracking system vendor will be responsible for determining how to satisfy this preference.

34 | P a g e

Topic 3: Victim Notifications / Updates Topic description The Revised Code of Washington (RCW) 43.43.545 – Statewide Sexual Assault Kit Tracking System – Section 2.c states that “The statewide sexual assault kit tracking system must…Allow victims of sexual assault to anonymously track or receive updates [emphasis added] regarding the status of their sexual assault kits.”

The purpose of this decision paper is to clarify the scope of the tracking system related to victims receiving updates regarding the status of their SAK. It is unclear whether the language “receive updates” is intended to have the SAK tracking system electronically provide victims automatic notifications based on changes in the status of their SAK. The general consensus of those interviewed by the Slalom team was that, due to the sensitivity of the subject, notification of key status changes to the SAK, if not viewed by the victim accessing the tracking system, should be a human to human interaction.

The final decision on this topic could impact whether the SAK tracking system will store contact information for the victim, which is highly sensitive information, thereby impacting system complexity, security, and cost, and potentially subjecting WSP to risk exposure were the system to inadvertently notify the wrong individual (e.g., if an email address or telephone number changes) or create emotional distress for a victim.


- Automatic system notification is a very active way to provide victims with updates regarding changes in the location or status of their SAKs.

- While some sexual assault survivors may desire this type of notification, WSP has no control over whether an individual’s contact information (e.g., address, cell phone number, email address) changes. Were the tracking system to inadvertently notify the wrong individual of the change in location or status of a kit, WSP may be subjected to additional risk or liability exposure.

- Some survivors may initially consent to receive updates regarding their SAKs and then subsequently change their preference. If this occurs, the survivor would need to actively contact WSP to change the notification setting.

- Managing these preferences and how they change would be challenging for WSP to ensure that they are accurate and timely.

- The potential for unintentionally re-traumatizing a survivor by sending notifications is significant.

- Business processes can be established to contact the survivor at key points in the process of forensic analysis of the SAK that takes a more victim-centered approach and would likely involve a personal notification and, ideally, multi-disciplinary team (e.g., victim advocate, prosecutor, detective).

Recommendation Based on information received from a variety of stakeholders, Slalom recommends that WSP does not include the ability to provide automatic notifications to victims through the SAK tracking system. We believe the intent of the tracking system is to help victims feel prioritized and empowered to move forward in their healing process and that this goal could be negatively impacted if system notifications are put in place. A safer, more sensitive approach is to make sure the victim is actively

35 | P a g e

seeking information regarding the status or location of their SAK, which the tracking system will provide.

Additional Notes 10/24/16 – According to the GMR team that met with Representative Orwall, the Representative is comfortable with this approach.

Decision Steering Committee Decision: 11/02/16 – The Steering Committee members discussed this recommendation and confirmed that the SAK Tracking System should not store contact information and will not produce automatic system notifications to victims. The majority ruled in favor to move forward with this approach.

36 | P a g e

Topic 4: Previously Un-submitted SAKs in the Tracking System Topic Description The Revised Code of Washington (RCW) 43.43.545 – Statewide Sexual Assault Kit Tracking System – Finding – Intent – 2016 c 173 states that “The system will be designed to track all sexual assault kits in Washington state, regardless of when [emphasis added] 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.”

It is currently unclear whether the previously un-submitted SAKs (i.e., SAK 3s), those being stored by an LEA that have not been referred to the WSP Crime Lab for forensic analysis, are included within the scope of the tracking system and the Legislatively mandated implementation timelines. Some stakeholders that the Slalom team interviewed believed they were and others believed the tracking system would track net new SAKs in the spirit of providing more accountability to survivors going forward. If considered in scope for the tracking system, it is unclear whether the previously un-submitted SAKs are required to be entered into the tracking system according to the timelines laid out in (RCW) 43.43.545, with the first report due July 31, 2018.

Two outstanding questions require clarification:

1. Are the previously un-submitted SAKs included in the scope of the tracking system? 2. If so, are they subject to the timelines outlined in (RCW) 43.43.545 (i.e., all previously un-

submitted SAKs entered into the tracking system by the due date of the first report on July 31, 2018).


- The WSP has contracted with an external forensic laboratory to provide analysis of the previously un-submitted SAKs.

- The National Institute of Justice (NIJ) and FBI have developed an initiative to provide forensic analysis of previously un-submitted SAKs and some counties in Washington State have begun submitting these SAKs to the FBI for testing.

- The WSP, Slalom team, and tracking system vendor will need to determine an implementation timeline that reasonably accommodates including the previously un-submitted SAKs, which may or may not be before the first report is due on July 31, 2018, depending on the LEAs’ ability to enter these SAKs into the tracking system.

- If included in the scope of the tracking system, we need to confirm that the system would include location and status of current and future events and would not provide historical location and status for the SAK 3s.

- Notifying victims of changes in the location and status of their SAKs is a sensitive matter (see Topic 3 – Victim Notifications / Updates). The potential of re-traumatizing a victim with notification that their SAK is undergoing forensic analysis is high. Partners throughout the criminal justice process (e.g., Prosecutors, LEAs, WSP, and Victim Advocates) are currently in conversations regarding the handling of notification for cases where a previously un-submitted SAK results in a CODIS hit. The system should not notify on these cases.

- If included in scope of the tracking system, a process will need to be established so that survivors can gain access to their SAK number in order to access the tracking system.

37 | P a g e

Recommendation Consensus is not found among the various stakeholders regarding whether the SAK 3s are in scope for the tracking system. We seek the input of Representative Orwall and WSP to advise whether they are in scope and whether they are subject to the timelines laid forth in the Legislation.

Additional Notes 10/24/16 – According to the GMR team that met with Representative Orwall, the Representative indicated that the kits that have been submitted prior to the tracking system going live are on a slightly different timeline because the law enforcement agencies will likely have to manually do barcoding to catch up. She noted that the tracking system would need to differentiate these kits and capture them from the point in the system that they are currently at forward rather than tracking them from start to finish. Therefore, recommendations from the Slalom team are to:

- Ensure the business and technical requirements of the solution can accommodate the addition of the SAK 3 kits to the tracking system;

- Focus the initial implementation period on net new and active cases; - Develop a plan to assist law enforcement with the entry of SAK 3 location and status

information into the tracking system.

Decision Steering Committee Decision: 11/02/16 – The Steering Committee members discussed the three recommendations and based on majority votes, the following decisions were made:

- The SAK tracking system should have the ability to include SAK 3 kits; - The initial implementation timeline referenced in the Legislation will focus on new kits and

active cases. - The status and location of the SAK 3 will start at the current location of the kit. Recreating

the historical location and status information in the SAK tracking system is not required. The only exception may be recording the status that forensic analysis was requested by law enforcement in order to properly reflect the status of the SAK 3s in the tracking system, for the Legislative reporting purposes. Further discussion on this topic is needed as the implementation of the system progresses.

38 | P a g e

Topic 5: Completed SAKs Topic Description The Revised Code of Washington (RCW) 43.43.545 – Statewide Sexual Assault Kit Tracking System – Finding – Intent – 2016 c 173 states that “The system will be designed to track all sexual assault kits in Washington state, regardless of when [emphasis added] 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.”

It is currently unclear whether SAKs that are considered “complete” in terms of analysis or adjudication that are being stored by the LEAs, are out of scope for the initial implementation of the tracking system. There is nothing necessarily preventing these SAKs from being entered into the tracking system in the future, but WSP and the Slalom team need to confirm they are out of scope for the timelines laid out in (RCW) 43.43.545 to have the tracking system in place and operational.


- The inclusion of SAKs that are being stored where no future activity is anticipated in the same timeframe for the tracking system to be operational statewide may not be realistic.

- If included in the scope of the tracking system, we need to confirm that the system would include location and status of current and future events and would not provide historical location and status for the SAK 3s.

- Notifying victims of changes in the location and status of their SAKs is a sensitive matter (see Topic 3 – Victim Notifications / Updates). The potential of re-traumatizing a victim with notification that their SAK is changing location or status is high. The system should not notify on these cases.

- If included in the scope of the tracking system, a process will need to be established so that survivors can gain access to their SAK number in order to access the tracking system.

Recommendation General consensus among the various stakeholders is that these SAKs are out of scope for the tracking system, although a decision could be made in the future to add them to the system. We seek the input of Representative Orwall and WSP to advise whether they are in or out of scope and whether they are subject to the timelines laid forth in the Legislation.

Additional Notes

39 | P a g e

Additional Notes 10/24/16 – The GMR team was not able to discuss this topic with Representative Orwall. Based on the Representatives comments on Topic 4 – Previously Un-submitted SAK in the Tracking System, the Slalom team recommends:

- Ensuring the business and technical requirements of the solution can accommodate the addition of these SAKs to the tracking system;

- Focus the initial implementation period on net new and active cases and subsequently the SAK 3s;

- Discuss further with Representative Orwall the intent of the Legislation to include ALL SAKs existing in Washington State in the tracking system.

11/10/16 – The GMR team has contacted Representative Orwall to seek feedback via email. GMR is currently awaiting her response. 11/16/16 – The GMR team received additional feedback from Representative Orwall. House Bill 1069 mandates that “In any felony case involving a violent or sex offense as defined in RCW 9.94A.030, a governmental entity shall preserve any DNA work product that has been secured in connection with the criminal case. The DNA work product must be maintained throughout the length of the sentence, including any period of community custody extending through final discharge, or throughout the period of the statute of limitations pursuant to RCW 9A.04.080, whichever comes later.” The DNA work product includes “the contents of a sexual assault examination kit”. Due to House Bill 1069 and House Bill 2530, which states that “The system will be designed to track all sexual assault kits in Washington state, regardless of when [emphasis added] they were collected…” it is recommended that the completed SAKs be added to the SAK tracking system. This does not substantively impact the 11/02/16 Steering Committee’s decision that the completed SAKs are out of scope for the initial implementation but can be added to the SAK tracking system by LEAs at a later date.

Decision Steering Committee Decision: 11/02/16 – The Steering Committee requested that the GMR team seek Representative Orwall’s input on this topic. The majority of the Committee voted that any kit that has already been completed and is being stored by an LEA should be considered out of scope for the initial implementation of the SAK tracking system. Law enforcement may add these SAKs to the tracking system later on if they elect to do so.

40 | P a g e

8. APPENDIX B – ON PREMISE SOLUTION TECHNICAL REQUIREMENTS

The following standard WSP technical requirements will be included in the RFP if WSP determines to host the system on-premise.

ID Category On-Premise Technical Requirements

ON-1 Operating System (General)

Supports editions of Microsoft Windows within their mainstream support and service pack support periods.

ON-2 Operating System (General)

Compatible with Windows User Account Control (UAC) technologies does not require modification of default UAC security levels.

ON-3 Operating System (Server)

Support for Windows Server 2012 R2 or later.

ON-4 Operating System (Client)

Support for Windows 7 SP1 (64-bit) or later is required.

ON-5 Virtualization Fully supports virtualization on Microsoft Hyper-V technologies (2012 R2 or later).

ON-6 Security Product demonstrates implementation of the principle of least privilege. Applications are able to access only the information and resources that are necessary for their legitimate purposes. Excessive credential requirements such as necessitating Enterprise Admin/Domain Admin privileges (or similar requests) are not permitted.

ON-7 Security Compatible with Windows BitLocker Drive Encryption technologies.

ON-8 Security Vendor demonstrates knowledge of and action to security threats faced by modern enterprise IT.

ON-9 High-availability

Where server and application fault-tolerance apply, Microsoft Windows Failover Clustering and its associated back-end infrastructure must be supported.

ON-10 Management Manageable by standard Windows technologies such as Terminal Services, Remote Desktop, Remote Assistance, and System Center Configuration Manager (SCCM) Remote Tools.

ON-11 Management Vendor provides a turnkey comprehensive Management Pack for use within System Center Operations Manager 2012 R2 or later.

41 | P a g e


ON-12 Management Includes a comprehensive suite of tools to facilitate centralized management, troubleshooting, and auditing. This includes (but is not limited to) a central management console, Active Directory Group Policy ADM/ADMX templates, server/client health reporting, and preferably SCCM Desired Configuration Management (DCM) packs.

ON-13 Database Microsoft SQL Server 2014 or later.

ON-14 Database Uses Microsoft SQL Server application components such as Integration Services and Reporting Services if such functionality is necessary.

ON-15 Database Database authentication via Windows Authentication. SQL authentication is not permitted.

ON-16 Database Requires no client-side database engine instance such as SQL Express or similar.

ON-17 Code Base Based on a Windows API-native (Win32, WinFX, etc.) or Microsoft .NET Framework 4.5 or later managed code base.

ON-18 Code Base Leverages no deprecated Win16/Win32/MFC/.NET library or assembly functionality.

ON-19 Code Base No client-side components may depend on or require in any way the Java Runtime Environment (JRE).

ON-20 Web Browser Internet Explorer 11 or later.

ON-21 Web Server Requires no Java-based server technologies such as IBM WebSphere, Apache Web Server, Apache Tomcat.

ON-22 Web Server Microsoft IIS 8.5 or later.

ON-23 Firewall/Antimalware

Compatible with Microsoft System Center Endpoint Protection.

ON-24 Firewall/Antimalware

Compatible with Microsoft Windows Firewall technologies.

ON-25 Reverse Proxy Access

Compatible with Microsoft Forefront Threat Management Gateway/F5/Kemp or similar.

ON-26 Messaging If messaging functionality is required, must support use of either the Microsoft Outlook 2013 (or later) API and/or fully support Microsoft Exchange 2013 or later web services.

42 | P a g e


ON-27 Authentication (Users)

Product must use Microsoft Active Directory Domain Services as the primary means of user authentication and user information lookup. An internal/proprietary user database may be available but must not be required, unless otherwise specified by WSP Information Technology Division (ITD).

ON-28 Authentication (Users)

Must support and use integrated Windows authentication to Microsoft Active Directory Domain Services. The Windows credential currently logged on should be automatically detected and used for subsequent user authentications unless otherwise specified.

ON-29 Authentication (Computers)

If computer authentication is required, must support and use Microsoft Active Directory Domain Services to validate current host against a published domain computer account.

ON-30 Authentication (Multi-factor)

Must not interfere with the use of multi-factor authentication technologies such as smart cards, key fobs, etc. built into the Windows operating system.

ON-31 Authentication (SSO)

Any single sign-on technologies used must be fully compatible with and use Microsoft Active Directory Domain Services.

ON-32 Active Directory

Requires no modifications to Active Directory schema.

ON-33 Logging Uses Windows Event Viewer technologies for logging. Must use unique event IDs and event source names so to facilitate effective filtering, triggering, audit, and capture.

ON-34 Deployment (Client)

Fully implements a silent installation option and supports the use of System Center Configuration Manager for deployment.

ON-35 Deployment Uses an industry standard Microsoft-certified installer such as Windows Installer, InstallShield, etc.

ON-36 Network Must not use Windows Internet Naming Service (WINS) name resolution technologies, DNS only.

ON-37 Network Must not use the Windows Computer Browser service.

ON-38 Currency Vendor demonstrates adherence to a well-documented software development lifecycle open to inspection and has a verifiable history of maintaining technical currency. This includes operating systems, development frameworks, deployment, patching, security, and virtualization technologies, and general enterprise IT industry trends.

43 | P a g e


ON-39 Currency Vendor publishes a clear and concise technology roadmap for their product line including feature releases, service pack releases, upgrades to architecture, etc.

Documents

Sexual Assault Kit (SAK) Tracking System Project Management Washington State Patrolwastatepatrol.net/sak/wp-content/uploads/2017/02/SAK... · 2017-02-09 · 1 All entities in possession