$0.+12'32.&'$!-44+55+-/6.5$&/7$#6&'6.5$55-1+&3 · Assessment Report and a detailed System...

CACASA – CalPEATSCalifornia Agricultural Commissioners and Sealers Association California Pesticide Enforcement Activity Tracking System

SYSTEM DESIGN SPECIFICATION

Revised Draft

May 19, 2015

CalPEATS System Design Specification May 19th, 2015 CaliCo Solutions LLC REVISED DRAFT

Page 1 of 132

Table of Contents 1. Background and Purpose ................................................................................................ 5 1.1. Background ................................................................................................................................................................ 5 1.2. Purpose of this Document .................................................................................................................................... 5 1.3. User Interaction Storyboards – InVision ....................................................................................................... 7 1.4. Lifecycle of this Document ................................................................................................................................... 7 1.5. Reviewer Guide – Revised Draft ........................................................................................................................ 8 2. System Setup .................................................................................................................. 9 2.1. Internal County/DPR Organization .................................................................................................................. 9 2.2. Supervisor/Staff Relationship .......................................................................................................................... 10 2.3. What Data Can A Given User See? ................................................................................................................... 11 2.4. Summary of DPR Access to County Data ...................................................................................................... 11 2.5. Cradle to Grave Violation Tracking ................................................................................................................ 13 2.6. Automated ID Creation ........................................................................................................................................ 13 3. Inspection Component .................................................................................................. 15 3.1. Inspection Component Overview .................................................................................................................... 15 3.2. Inspection Workflow ............................................................................................................................................ 15 3.3. Inspection Statuses ............................................................................................................................................... 18 3.4. Mobile Database Design ...................................................................................................................................... 21 3.5. Inspections User Interface Design .................................................................................................................. 23

3.5.1. Dashboard - Mobile ............................................................................................................................................. 26 3.5.2. Dashboard – Web ................................................................................................................................................. 28 3.5.3. Search Records ...................................................................................................................................................... 30 3.5.4. Inspection Selection ............................................................................................................................................ 31 3.5.5. Information Block Setup ................................................................................................................................... 34 3.5.6. Inspection Record – Mobile ............................................................................................................................. 36 3.5.7. Inspection Record – Web .................................................................................................................................. 39 3.5.8. Information Block: Contacts ........................................................................................................................... 41 3.5.9. Information Block: Handlers .......................................................................................................................... 45 3.5.10. Information Block: Requirements ................................................................................................................ 46 3.5.11. Information Block: Signature ......................................................................................................................... 48 3.5.12. Delivering the Inspection Forms ................................................................................................................... 49 3.5.13. Suggestion Engine ............................................................................................................................................... 50

3.6. Mobile Specific Functionality ............................................................................................................................ 53 3.6.1. Authentication ....................................................................................................................................................... 53 3.6.2. Settings / Customizations ................................................................................................................................ 54 3.6.3. App Delivery and Updates ................................................................................................................................ 55

3.7. Platform-Specific Screenshots .......................................................................................................................... 56 4. Investigation Component .............................................................................................. 67 4.1. Investigation Component Overview .............................................................................................................. 67 4.2. Investigation Workflow ...................................................................................................................................... 67 4.3. Investigation Statuses .......................................................................................................................................... 70 4.4. Investigation User Interface Design ............................................................................................................... 72

4.4.1. Viewing/Searching for Investigations ....................................................................................................... 72 4.4.2. Starting an Investigation ................................................................................................................................. 76 4.4.3. Investigation Home Page ................................................................................................................................. 79 4.4.4. DPR WHS Branch Illness Case Management ........................................................................................... 88


Page 2 of 132

5. Enforcement Component .............................................................................................. 90 5.1. Enforcement Component Overview ............................................................................................................... 90 5.2. Enforcement Response Workflow .................................................................................................................. 90 5.3. Enforcement Response Statuses ..................................................................................................................... 93 5.4. Enforcement Component User Interface Design ................................................................................... 100

5.4.1. Viewing/Searching for Enforcements ..................................................................................................... 101 5.4.2. Starting an Enforcement ............................................................................................................................... 109 5.4.3. Enforcement Home Page ............................................................................................................................... 110

6. Activity Tracking Component ...................................................................................... 119 6.1. Activity Tracking Overview ............................................................................................................................ 119 6.2. Inspection Activity Goals ................................................................................................................................. 119 6.3. PRAMR Data Entry ............................................................................................................................................. 119 6.4. PRAMR Data Analysis and Reporting ......................................................................................................... 121 7. System Administration ................................................................................................ 126 7.1. User Control – Roles and Permissions ....................................................................................................... 126 7.2. User Credentials .................................................................................................................................................. 130 7.3. User Profile Management ................................................................................................................................ 131 7.4. County Settings .................................................................................................................................................... 131 List of Figures Figure 3-1: Inspection Workflow ................................................................................................................ 17 Figure 3-2: Inspection Statuses ................................................................................................................... 20 Figure 3-3: Mobile App Navigation ............................................................................................................ 24 Figure 3-4: Inspection Navigation Details ............................................................................................... 25 Figure 3-5: Mobile Dashboard – Tabular View ...................................................................................... 26 Figure 3-6: Mobile Dashboard – Tiled View ........................................................................................... 27 Figure 3-7: Web Dashboard .......................................................................................................................... 29 Figure 3-8: Mobile Inspection Search Screen......................................................................................... 31 Figure 3-9: Inspection Selection – Tabbed View .................................................................................. 32 Figure 3-10: Inspection Selection – Tiled View ..................................................................................... 33 Figure 3-11: Inspection Record – Tabbed View .................................................................................... 37 Figure 3-12: Inspection Record – Tiled View ......................................................................................... 38 Figure 3-13: Inspection Record – Web (Part 1) .................................................................................... 40 Figure 3-14: Inspection Record – Web (Part 2) .................................................................................... 41 Figure 3-15: Contact Selection Screen – Tabbed View ....................................................................... 42 Figure 3-16: Inspection Contacts Listing – Tiled View ....................................................................... 43 Figure 3-17: Handler Information Block – Handler Details ............................................................. 46 Figure 3-18: Requirements Information Block ..................................................................................... 47 Figure 3-19: Signature Information Block .............................................................................................. 49 Figure 3-20: Logic Diagram for Mobile Application User Authentication .................................. 53 Figure 4-1: Investigations Workflow ........................................................................................................ 68 Figure 4-2: Investigation Statuses .............................................................................................................. 71 Figure 4-3: Investigation List/Search ....................................................................................................... 76 Figure 4-4: Investigation Setup ................................................................................................................... 78 Figure 4-5: New Investigation From Inspection ................................................................................... 79


Page 3 of 132

Figure 4-6: Investigation Main Page .......................................................................................................... 80 Figure 4-7: DPR WHS Branch Illness Cases ............................................................................................ 88 Figure 5-1: Enforcements Workflow ......................................................................................................... 92 Figure 5-2: Enforcement Response Statuses ........................................................................................ 94 Figure 5-3: Compliance Action Statuses .................................................................................................. 95 Figure 5-4: Enforcement Action Statuses ................................................................................................ 96 Figure 5-5: Referral Action Statuses .......................................................................................................... 97 Figure 5-6: Enforcement Detail Listing – Grouped ............................................................................ 105 Figure 5-7: Enforcement Detail Listing – Flat ...................................................................................... 106 Figure 5-8: New Enforcement Response From Inspection ............................................................. 109 Figure 5-9: Enforcement Response Home Page .................................................................................. 111 Figure 5-10: NOPA Detail Page .................................................................................................................. 116 Figure 6-1: PRAMR Monthly Data Entry ................................................................................................ 122 Figure 6-2: Training and Outreach Entry .............................................................................................. 122 Figure 6-3: PRAMR Monthly Review ....................................................................................................... 123 Figure 6-4: PRAMR Fiscal Year Review .................................................................................................. 124 Figure 6-5: PRAMR Multi-County Review ............................................................................................. 125 List of Tables Table 2-1: Data Access in CalPEATS For Counties and DPR Users ................................................ 12 Table 3-1: Information Blocks Used By Inspection Type .................................................................. 34 Table 3-2: Location Information Block Details By Inspection Type ............................................. 35 Table 3-3: Product Information Block Details By Inspection Type ............................................... 36 Table 3-4: Expected Contact Types By Inspection Type .................................................................... 44 Table 3-5: Suggestion Engine Configuration .......................................................................................... 51 Table 7-1: Default and Configurable User Permissions in CalPEATS ......................................... 127


Page 4 of 132

Date Description Approved By

1/30/2015 First Draft for Technical Advisory Committee (TAC) Review TAC

2/9/2015 Revisions from First Draft Review Meeting TAC

5/8/2015 Revised Draft for TAC Review

5/19/2015 Revisions from Revised Draft Review Meeting


Page 5 of 132

1. Background and Purpose

1.1. Background

In December 2014, CACASA contracted with CaliCo Solutions to implement a new software system named the California Pesticide Enforcement Activity Tracking System (CalPEATS). At that time, CACASA with assistance from GeoPraxis Corp had prepared a Needs Assessment Report and a detailed System Requirements Specification (SRS) describing the desired features of the software system and the background leading up to the Request for Proposal.

1.2. Purpose of this Document

The System Design Specification (SDS) document describes how the features and functions described in the SRS will be implemented. It is part of a trio of documents that will guide the development of CalPEATS:

1. The SRS details the specific features and functions required in the application; 2. The SDS explains how those features and functions will be delivered; and 3. The System Acceptance Test Plan (SATP) shows how the target users will verify that

the features listed in the SRS have been delivered per the SDS.

The SDS is divided into seven major sections – this first section explains the background and purpose of the SDS document, while the remaining sections cover different portions of the CalPEATS application.

Each major section describes how the CalPEATS application will be built to deliver the functionality described in the corresponding section of the SRS. The SDS uses the following mechanisms to document the application design:

x Workflow Diagrams – these diagrams show the process to be used to implement a group of features. They show the various steps the user will go through to complete a “use case” and the data inputs and outputs for that process.

x Status Diagrams – these diagrams show the sequence of statuses that each major system entity (an Inspection, an Investigation, etc) will go through during their lifecycle, and explains how transitions will be accomplished from one status to the next (who, how, when, etc).

x Screen Mockups – these pictorial representations show how the various application screens will be laid out.

x User Interaction Storyboards – these are graphical depictions of how the user will move through the application screens to accomplish a specific task. These are presented in an accompanying online website for interactive review (see Section 1.3)


Page 6 of 132

Each of these components is accompanied by narrative that explains details that can not be captured easily on the diagrams themselves, such as data validation rules and user security requirements.

The purpose of the SDS is threefold: 1. Clearly describe the system design and implementation to the TAC and other

stakeholders so they can understand what the final product will look like and how it will operate. The document must contain sufficient detail to ensure that the system will provide the functionality described in the SRS in a manner that will satisfy the Department of Pesticide Regulation (DPR) and County users, without overwhelming the reviewing audience and unnecessarily constraining the creativity of the development team.

2. Document the TAC approval of the proposed design, and any changes to the design details or system requirements over time.

3. Serve as a guide during User Acceptance Testing to ensure that the testing process is properly targeted at the agreed-upon design and that the testers have a clear definition of the system to test against.

Item number two above is critically important – the SDS will be updated as the project proceeds, with any changes to the SDS requiring review and concurrence by the TAC. Changes in the SDS may stem from three sources:

1. Cosmetic or procedural changes that we discover as the application is developed. This type of change relates to how a screen is laid out or the sequence of events a user will use to accomplish a task, but do not change the underlying requirement(s) from the SRS;

2. Addition of detail in the SDS for specific screens or functions that were not enumerated in the earlier SDS versions. In trying to keep the review burden on the TAC to a series of manageable steps, we will gradually build up the level of detail in the document as we complete major milestones and begin to add specific areas of functionality;

3. An update, change, deletion, or addition of a requirement that is discovered (or analyzed in more detail) as the system progresses. The change in requirements will need an accompanying change in the SDS and potentially in the SATP.

These updates to the SDS will be the primary mechanism for proposing, approving, and tracking changes to the scope of the project during the development phase. Even modifications that do not require changes in budget or schedule will be documented in the SDS to ensure that all stakeholders have the same expectations at the beginning of the system acceptance testing phase.


Page 7 of 132

1.3. User Interaction Storyboards – InVision

To provide a more dynamic view of the operation of the application screens and navigation in CalPEATS, this document is accompanied by an online website that shows the user interaction storyboards as a series of annotated screen pictures. The website is a product of InVision (www.invisionapp.com) and allows reviewers to follow pre-set narratives created by the authors of this document, or to click through screens using “hot-spots” that represent actual buttons or links in the application. The InVision web site provides an easy-to-use mechanism for reviewers to post comments directly on the screens and narrative text, and for the CalPEATS designers read and respond to those comments.

The InVision website will be used to document the important system navigation pathways and user interactions, and when the SDS is finalized the InVision website storyboards will be compiled (along with all of the final narrative text) into a Portable Document Format (PDF) document to attach to the final SDS.

Reviewers can access the InVision screen designs (and other useful design supplements) at http://calicosol.com/calpeats.

1.4. Lifecycle of this Document

The SDS will be published in a series of increments. The first three official versions of the SDS will be published prior to the main development phase. During development, updates to the SDS will be published as needed to document agreed-upon changes to the design or system requirements. When the system is accepted by CACASA, a final SDS will be published that reflects the final “as-built” system design.

Version Expected Date Description

First Draft 1/30/2015 Initial draft containing three example use cases for review of style and level of detail

Revised Draft 5/15/2015 First complete draft with all components included

Final Draft 7/3/2015 Complete design incorporating comments and changes from Revised Draft review – primary guide for system development phase

Updated Draft As Needed Published as needed when changes are agreed upon

Final 10/14/2016 “As-built” design, updated with changes required during User Acceptance Testing and Pilot operation

http://www.invisionapp.com/

http://calicosol.com/calpeats


Page 8 of 132

1.5. Reviewer Guide – Revised Draft

This is the Revised Draft of the SDS. The primary purpose of this version of the SDS is to establish the look and feel of the applications (both mobile and web) and to illustrate how the system will be developed to deliver the functionality required in the SRS. The application functionality and user interface style presented herein is based on the discussions held with the TAC during the project kickoff meetings (January 6th and 7th, 2015) and the subsequent review comments received from the First Draft SDS. In addition, we have incorporated knowledge gathered during a series of in-person design review meetings conducted in March and April 2015 with a large number of counties and DPR staff.

We ask the reviewer to understand that it is not the goal of this design to document every screen, button, link, report, and feature of the software. At well over one hundred pages (plus the online content), this version of the SDS already poses a significant review challenge. Our goals in determining what level of detail is appropriate for each section of the design were:

1. Present enough detail that the reviewer can visualize the application in operation and comment on the user interface look and feel.

2. Cover enough about each major operation in the system to give the reviewer a big picture understanding of where all of the important components are in the overall design.

3. Explain the flow of the system from Inspections to Investigations to Enforcements so the reviewer understands how the PUE process is handled and how the interactions with DPR will be accomplished.

4. Include detail on the presentation and operation of the main screens in the system so the reviewer will understand how to view, search, create, and edit the records required to document their work processes.

5. Be concise and focused, and do not overwhelm the reviewer with details that they may not be ready to process given that this is their first full view of the system design including all four of the major components.

It is important to note that the SRS remains part of the system design/build documentation – if the SDS does not at this version mention a specific feature or function, that item will be added to the SDS and TAC approval for the item will be gained as that level of details becomes appropriate. For example, this version of the SDS does not cover the details of the data interchange with Accela – that work is currently in discussion and will be added to the SDS and submitted to the TAC for review as it becomes clearer. The lack of that information at this stage does not diminish the reviewer’s ability to understand and comment on the overall application design, operation, and look and feel.


Page 9 of 132

2. System Setup

2.1. Internal County/DPR Organization

Counties and DPR have different mechanisms for managing workflows and assigning responsibilities for different portions of the Pesticide Use Enforcement (PUE) program covered by CalPEATS. CalPEATS will provide the following properties on each user account to aid in the management of workflows and to help users filter information that is most relevant to them.

Supervisor

Each user account can optionally have a supervisor assigned. The supervisor is another CalPEATS user within the same organization. The designated supervisor should have the appropriate permissions on their account to allow them to perform supervisory functions, such as reviewing and approving work products and re-assigning work to another user. If a supervisor is assigned, this will override the user’s district assignment, if any.

District

Many counties organize work into geographic or task-based districts. Each user can optionally be assigned one or more districts (which are defined by the county application administrator in CalAgPermits). Individual inspections, investigations, and enforcements belong to the user that opened them – when deciding whose records a supervisor should review, the association is made based on the user’s district code compared to the supervisor’s. For example, if a supervisor is assigned districts D and E, he/she will see the work products for all users in those districts (unless an individual user is specifically assigned to another supervisor), plus any individual users who have been directly assigned to him/her.

Multi-County Users

Certain counties share staff for PUE work. In these cases, the counties have the option to create separate user accounts for work in different counties (as is done in CalAgPermits), or to use the same login credentials and select their “active” county as they perform work in CalPEATS. In either case, a user will only be able to work on data from one county at a time in CalPEATS – users may be able to see records from other counties if those counties have granted access.

DPR Enforcement Branch – Headquarters and Regions

DPR Enforcement Branch personnel may be assigned to one of DPRs Regions, or they may be considered Headquarters staff. If a user is assigned to a region, then all activity for that region (i.e., the DPR staff assigned to the region, plus activity in


Page 10 of 132

counties within that region) is assumed to be relevant to that user. If the user is designated as Headquarters, then the entire State is relevant to them. Regional staff can further be designated as an Enforcement Branch Liaison (EBL), in which case their scope of relevance is focused on their assigned counties within the region. CalPEATS will not enforce the relationship between an EBLs assigned Region and their assigned counties.

Other DPR Roles

DPR users in CalPEATS can optionally be assigned one or more other DPR roles – each DPR role corresponds to a specific set of activities (screens) in CalPEATS. The following DPR roles will be defined:

x Worker Health and Safety (WHS) Branch – users who initiate and track illness investigation requests, including priority illness investigations.

x Priority Investigations – users who track non-illness priority investigations.

x PRAMR – users who review and use monthly/annual PRAMR activity data for all counties.

The DPR role assignments are cumulative – a user who is assigned to WHS Branch and Priority Investigations would see both sets of functions in CalPEATS.

The assignment of these management categories is supplemental to the User Roles and Permissions system, described in Section 7.1. They are designed to help users focus their dashboard views and are not intended as controls or limitations on what a user can see or do in CalPEATS.

2.2. Supervisor/Staff Relationship

In several places in CalPEATS, the workflow features require us to identify one or more supervisors for a given staff member, and vice-versa. For example, the dashboard screens for a user with a supervisory role will include the status of work products owned by staff to report to them. This relationship is determined first by direct assignment of a supervisor on the user record, and second by the designation of districts for both supervisors and staff. Lacking either of these assignments, a supervisor will see activity for all staff in the county.

DPR users do not use districts to organize their staff reporting hierarchy. Instead, in the absence of a direct supervisor assignment, the supervisor is determined based on their region assignment. A user with a region assignment reports to supervisors assigned to that region. If no supervisor is assigned to that region, then the supervisor moves up to DPR headquarters supervisors. For the purpose of this paragraph, “report to” means that the user will appear in the work item listings of supervised staff for that supervisor.


Page 11 of 132

2.3. What Data Can A Given User See?

Access to data in CalPEATS is limited based on which counties and DPR regions a user may access. Table 2-1 shows the data access schema for CalPEATS. Note that these data access controls refer to the “domain” that the user can see – data belonging to counties and DPR depending on status. Not all users of each type will see all of the records – a user must also have the appropriate role-base permissions to access specific records (see Section 7.1).

2.4. Summary of DPR Access to County Data

DPR users with appropriate user permissions (see Section 7.1) can view the following county data:

x Closed Inspections, Investigations, Enforcement Responses, Response Actions, and Pesticide Regulatory Activities Monthly Report (PRAMR) Months.

x In Progress Priority Investigations.

x In Progress Non-Priority Investigations to which counties have granted DPR access.

x Claimant/Injured Party Attachments (any status).

x In Progress Enforcement Responses where the initial DPR notification date has been entered.


Page 12 of 132

Table 2-1: Data Access in CalPEATS For Counties and DPR Users

County*

DPR Enforcement

Branch EBL**

DPR Enforcement

Branch - Region***

DPR Enforcement

Branch - HQ****

DPR WHS Branch****

County Inspections (In Progress) Yes No No No No County Priority Investigations (In Progress) Yes Yes Yes Yes 3 County Investigations (In Progress) Yes 2 2 2 3 County Enforcements (In Progress) Yes 2 2 2 No County Inspections (Closed) Yes Yes Yes Yes No County Investigations (Closed) Yes Yes Yes Yes 3 County Enforcements (Closed) Yes Yes Yes Yes No County PRAMR Data (In Progress) Yes No No No No County PRAMR Data (Closed) Yes Yes Yes Yes No

DPR Oversight Inspections No Yes Yes Yes No WHS Illness Cases 1 Yes Yes Yes Yes DPR Investigations No Yes Yes Yes 3

* For their assigned counties only. County users may view closed county records for other counties if access is granted. ** For their assigned counties only. *** For all counties in the region. **** Not limited by county or DPR region.

1 When the illness case is assigned to their county. 2 If access is granted by the originating county. 3 Investigations linked to WHS illness cases only.


Page 13 of 132

2.5. Cradle to Grave Violation Tracking

One of the goals of CalPEATS is to provide a full picture of the final disposition of all violations identified either through inspections or investigations. Each violation noted is tagged in CalPEATS with a unique identifier, and is linked directly to the enforcement response in which it is handled. Within the enforcement response, the Deputy (or other county staff that is performing the enforcement) can subdivide a violation into more specific subsections – for example, a single violation with respect to CCR 6738 for PPE could be broken down into multiple violations at the enforcement response stage for each different type of PPE that was not correct (gloves, eye protection, respiratory protection, etc.) The relationship between the original inspection violation and the subsequent breakdown in the enforcement response is maintained.

As the enforcement response proceeds, CalPEATS tracks the actions that are taken and which of the violations in the enforcement response they include. Thus the users of CalPEATS will know exactly which compliance, enforcement, and/or referral actions were taken for a given violation. If a violation is included in an enforcement response but the county is not required to pursue any actions for that violation, the enforcement officer will note in CalPEATS that No Further Action was required and will provide an explanatory note. This way, a query for the full picture related to a violation will include a final outcome regardless of the type of enforcement taken.

2.6. Automated ID Creation

Within CalPEATS, several records will have recognizable identifiers assigned automatically by the system. These identifiers will be generated as follows:

Inspections <Form Type>-<County ID>-<CY>-<CalPEATSDeviceId>-<###>

Investigations INV-<County ID>-<YYYYMMDD>-<###>

Enforcement Responses ER-<County ID>-<FY>-<###>

Compliance Actions (Notices of Violation, Warning Letters, etc.) CA-<County ID>-<YYYYMMDD>-<###>

Decision Reports DR-<County ID>-<YYYYMMDD>-<###>

Enforcement Actions (Notices Of Proposed Actions, or NOPAs) EA-<County ID>-<FY>-<###>


Page 14 of 132

Referral Actions RA-<County ID>-<FY>-<###>

In the above ID templates, the following abbreviations are used:

<Form Type> – the three-digit main inspection type (102, 103, 104, etc.)

<CY> – the two-digit calendar year

<County ID> – the two-digit county numerical identifier

<CalPEATSDeviceId> – a unique identifier assigned to each device (see below)

<###> – a sequential three-digit integer (zero-padded)

<YYYYMMDD> – the year, month, and day of the incident/report

<FY> – the fiscal year indicator (e.g., 14/15)

CalPEATSDeviceId

The mobile app needs to be able to generate a unique inspection id when in offline mode. The identifier must be unique across the entire state, so it must include the county id. Since the device cannot check with the main server for a new inspection number, the device itself needs a unique identifier to include in the inspection id to differentiate it from other devices in the county. This id is assigned by the CalPEATS server when the app is initialized on a new device and is called the CalPEATSDeviceId. This identifier will take the form M### where M indicates a mobile device and is followed by a three digit sequential number unique within each county. For inspections entered on the web platform, the CalPEATSDeviceId will be W000.

If the device owner uninstalls the app then reinstalls the app, the server will create a new device id since the stored device id value would be blank. This limitation does not effect the creation of a unique number, however users should be aware that a different CalPEATSDeviceId does not mean the inspection came from a different physical device.

Inspection Subtypes

CalPEATS will count completed inspections for PRAMR reporting based on the number of subtypes completed in the inspection record (e.g., Pesticide Use Monitoring inspection has subtypes for Mix/Load, Application, etc.). Some counties prefer to have each inspection subtype use a different inspection id – those counties can simply create two inspection records in CalPEATS and only complete one subtype in each inspection record. Other counties can use the inspection requirements information block to complete multiple inspection subtypes on one inspection id. CalPEATS will calculate the correct inspection count regardless of who the county chooses to enter the inspections.


Page 15 of 132

3. Inspection Component

3.1. Inspection Component Overview

The Inspection component in CalPEATS consists of web and mobile data entry forms for the 22 types of inspections defined in the SRS, plus screens for finding inspection records, conducting and documenting reviews of inspections, viewing and recording work activity logs associated with inspection activities, printing hard-copy inspection forms, and attaching files to inspections.

Inspection activity in CalPEATS uses a number of reference databases, as described in Section 3.4. The Inspection component also includes screens for finding, viewing, and linking to reference data.

3.2. Inspection Workflow

The process for completing an inspection record in CalPEATS is shown in Figure 3-1.

The first step in the Inspection workflow is the creation of a new inspection record. This step can be accomplished on the web or the mobile platform. Data entry for the new inspection record may occur in the field using the mobile application, or the inspector may opt to use paper forms for recording the inspection data and enter the results later. In the latter case, the inspector can choose to begin the inspection on the web platform before the inspection and print out a partially completed form, or they may conduct the investigation using a blank paper form and simply enter the data via the web interface after returning to the office (or any internet-enabled location).

Once the inspector believes the data for the inspection are complete, they will run a validation check to see if all required data are complete and valid. If the inspection is marked as Partial, the inspector may proceed to finish the inspection even if the validation checks are not passed. Follow-up inspections will be validated on the portions that are completed, but not all required fields must be filled out to proceed. For full inspections, all validation checks must be passed before the inspection can be marked as complete.

For inspections that require signatures from the inspected party, the inspector can obtain the signature electronically on the mobile application. Alternately, the inspector may print the completed inspection form in the field (if they have access to a field printer), or they may print the completed form at the office and mail it to the inspected party for signature. If a signature is required, the inspection cannot be marked as complete until the electronic signature is recorded or the signed paper copy is received, scanned, and uploaded to the inspection record as an attachment.


Page 16 of 132

Once this field work step is complete and the inspector leaves the field, the requirements portion of the inspection can not be edited without an explanation for any changes to the compliance status of any citable section.

While the inspection is in progress, or once it is marked as complete, the inspection data must be synchronized to the main database. The next step in the workflow is for a supervisor to review the inspection and either accept it as complete or send it back to the inspector for updates or corrections. This review must occur via the web platform, so the inspection data must be uploaded to the main database to be accessible to the reviewer.

During inspection data entry, the inspector can add and edit data via the mobile and/or web interface. Data conflicts will be resolved by keeping the most recently updated record.

Once the inspection is complete and has been approved by the reviewer, it will be closed. If violations were noted on the inspection, an enforcement response will be started to address the individual violations.


Page 17 of 132

Figure 3-1: Inspection Workflow


Page 18 of 132

3.3. Inspection Statuses

During its lifecycle, an inspection record in CalPEATS transitions through four statuses: 1. In Progress 2. Draft (after field work is completed and the inspected party has received a copy of

the inspection form) 3. In Review (once the inspector has finished all data entry for the inspection and

passed it to their supervisor for review) 4. Complete

These statuses are depicted in Figure 3-2. Rules for the status transitions are as follows:

Create (N/A => In Progress)

Any user with the Inspector role can create any inspection type at any time.

Finish Field Work (In Progress => Draft)

The inspector will collect the signature in the field, or may mark the form as signature refused. If the data is entered in the office after collecting the information on a paper form, then the inspection transitions to Draft status as soon as the record is saved.

Complete (Draft => In Review)

Any user with the Inspector role can mark any of their Draft inspection records as complete. If the inspection is marked as Partial, it can be marked as complete whether or not it passes validation. If the inspection is not marked as Partial, it must pass all validation checks before the status will change.

Approve (In Review => Closed)

Any user with the Reviewer role can mark any Complete inspection record as Closed. This action indicates that the Reviewer has approved the content of the inspection record. The inspection record must be synchronized to the main database before it can be reviewed.

Revise (In Review => Draft)

The inspection owner can withdraw the inspection from In Review status and make revisions if they determine that there is missing or incorrect information and the reviewer has not completed their review.


Page 19 of 132

Reject (In Review => Draft)

Any user with the Reviewer role can mark any Complete inspection record as In Progress. This action implies that the Reviewer recommends changes to the inspection record. The work activity log associated with this transition will include comments from the Reviewer explaining the changes recommended. The inspection record must be synchronized to the main database before it can be reviewed.


Page 20 of 132

Figure 3-2: Inspection Statuses


Page 21 of 132

3.4. Mobile Database Design

The database for inspections on the mobile platform is designed to operate offline – thus all data required to support the mobile inspections interface will be downloaded to each tablet. The mobile data will be stored in SQLite, a highly performant relational database, and will include reference data and current inspections, as well as two years of inspection and enforcement history.

We expect that most tablets will be updated daily when Internet connectivity is available, but tablet users can update more or less frequently as desired. The application will allow updates whenever a data connection is available – it will be up to each county and DPR to establish policies for the use of cellular and public WiFi networks for CalPEATS data transfers (all data transfers will be conducted over an encrypted connection). Since Investigation data is not stored on or downloaded to the mobile devices, it is unlikely that any HIPAA protected information would be transmitted during data synchronization.

The mobile database will contain the following reference information:

x Two years of CalPEATS data: o Inspection records (excluding attachments). o Enforcement records (excluding attachments).

x Current CalAgPermits data: o Permits (current versions only) including permit sites (excluding GIS data). o Contacts including contact types, licenses, and county registrations. o DPR licenses. o SPCB licenses. o DPR product labels. o County active commodity list. o Recent use reports (60 days). o Recent NOIs (5 days).

x FLC license database (this data may also flow through CalAgPermits).

The two-year history of CalPEATS data available on the mobile device will exclude attachments to conserve space on the device and to limit the time required for synchronization. One exception is a “pinned” inspection, as described in Section 3.5.1. All attachments for pinned inspections will be downloaded to the mobile database.

The mobile app communicates with the CalPEATS mobile update server through an Application Programming Interface (API) that allows for two-way synchronizing of data.


Page 22 of 132

The process for selecting data to synchronize is different for timestamped and non-timestamped records.

The CalPEATS records will all be timestamped and can be synchronized using with “delta” updates as follows:

x If the shared record does not exist on the mobile device, download it.

x If the mobile record does not exist in the shared database, upload it.

x If the record exists in both locations and the timestamp is different, replace the older record with the most recent.

CalPEATS will not implement a full transactional audit trail on each record update; therefore it will be possible for a user to perform updates on the mobile and web platforms separately after the most recent data sync. In such a case, the earlier changes will be lost when the record is synced because the more recently updated record will be transferred. As an example:

x User creates an inspection record version A on the web at 8am.

x User synchronizes their mobile device.

x User edits version A on the web, creating version B, but does not re-sync their mobile device.

x User later edits version A on their mobile device, creating version C.

x User syncs their mobile device, and version C is copied to the web database. The changes made in version B are lost.

We do not believe this scenario would occur frequently and can easily be avoided with simple user instructions, and therefore the additional programming and processing time required to implement a more complex record audit trail is not warranted.

At this time, CalAgPermits does not keep track of update timestamps on contact record updates or any of the reference lists. It does contain a date/time stamp as well as a version number for each permit that is issued; however after a permit is issued small changes can be made (corrections) without issuing a new version. Therefore, we are unable to manage CalAgPermits reference data using the “delta” method described above unless timestamps are added to the database.

As an alternate approach for downloading the CalAgPermits reference data to the mobile device, CalPEATS will generate a data file nightly that contains all of the required information for each county and the mobile device will perform a complete replacement of the reference data.

If timestamps can be added to the CalAgPermits data, we will conduct performance testing of the delta synchronization method to ensure that the operation of the CalAgPermits


Page 23 of 132

database is not adversely affected when multiple users sync their mobile devices each morning.

For any timestamped records, if the server timestamp is newer than the last synchronized timestamp on the mobile device, the user will be issued a warning and notified that if they proceed they may overwrite newer data. In this case, the user can see who made the newer update on the server and manually obtain any updated information before syncing their mobile data.

3.5. Inspections User Interface Design

The user interface for the Inspections component will be available both on mobile devices and on the web. The mobile interface will be a native app for each mobile operating system and the web interface will be a HTML/JavaScript application accessible using any modern web browser. The functionality available on the web site is almost identical to the functionality of the mobile app, therefore this document does not present separate design discussions for the two platforms; instead this section notes any features that will differ between the two platforms. To illustrate the look and feel of the web version of the Inspections component, an example inspection web form is presented in Section 3.5.7. There are also numerous web form designs presented in Sections 4.4 and 5.4 that show the web presentation format and style.

In discussing the CalPEATS Mobile App functionality, we recognize that mobile device users with an Internet connection can also browse and operate the CalPEATS web interface using the browser software on their mobile device. The distinction we draw for the inspections interface is that users can operate the CalPEATS Mobile App in an offline mode, and it is delivered as a high-performance native app rather than as a website.

The Inspections module user interface includes the following screens:

x Mobile Dashboard and Web Dashboard

x Firm/Person Details.

x Inspections Listing/Search.

x Inspection Home Page.

x Information Blocks.

The Information Blocks on an inspection screen represent portions of the inspection form relating to a specific topic, and that are common (or very similar) across inspection types. The setup and content of the various Information Blocks are discussed in detail in Section 3.5.5.

The overall application navigation in the Inspection component is presented in Figure 3-3. Details of the navigation model for an individual inspection are shown in Figure 3-4.


Page 24 of 132

Figure 3-3: Mobile App Navigation


Page 25 of 132

Figure 3-4: Inspection Navigation Details


Page 26 of 132

3.5.1. Dashboard - Mobile

After a successful login, the user is presented with the mobile dashboard. Alternatives for the layout of the dashboard are presented in Figure 3-5 and Figure 3-6. Unlike the dashboard for the web interface, which is customized to the role of the user, the mobile dashboard is optimized the inspector role.

The first component on the dashboard is the quick search. The quick search enables the inspector to type in a name (or permit/license number or license plate number) of a business or licensed individual and view a summary of inspection and compliance history as well as license, permit, and contact information. Equipped with that information, the inspector can make an educated decision to perform an inspection or not.

Figure 3-5: Mobile Dashboard – Tabular View


Page 27 of 132

Figure 3-6: Mobile Dashboard – Tiled View

Active Inspections comprise the second component listed on the dashboard. There are two types of inspections that will appear in the list:

a) Inspections that have been created by the user and have not yet been reviewed and approved (moved to Closed status). All In Progress, Draft, and In Review Inspections will remain active on the mobile device. Closed inspections within the two year history period will also be available via the Inspections Search function.

b) Inspections that have been “pinned” by the inspector. The user is able to “pin” any inspection, which not only adds it to the Active Inspection list, but also downloads all attachments onto the device for offline use. An example of this would be for a scheduled follow-up inspection. The user can pin the original inspection and have all relevant information available when performing the follow-up. Removing a


Page 28 of 132

pinned inspection is as easy as tapping on the pin. The inspection will disappear from the list and all the attachments are removed from the device during the next sync (the inspection record may remain as part of the two-year history of inspections on the device).

Other features of the Active Inspection list are noteworthy. An indicator lets the user know that that record has been modified on the mobile device and has not yet synced with the CalPEATS server. Also, a warning icon appears when the inspection is missing data or has other form errors.

The third component displayed on the mobile dashboard is a list of NOIs. These records retrieved from CalAgPermits provide the user with information about intended restricted material use. Tapping on an NOI creates a new inspection. The app also automatically copies available data from the NOI into the inspection record.

3.5.2. Dashboard – Web

The user dashboard on the web platform is substantially more comprehensive than the mobile version, due to the fact that the web platform includes the investigation and enforcement components. The dashboard is made up of several distinct displays:

x Inspections

x Investigations

x Violations

x Enforcement Responses

x Decision Reports Awaiting Review

x WHS Investigation Requests

Not all users will see all displays – the user will have access to the displays that are appropriate for their user role(s) – they can then customize which displays are included and how they are initially filtered on their dashboard to suit their preferences.

The top part of the Web Dashboard is shown in Figure 3-7 (the full page is too long and is not necessary to illustrate the utility and layout of the dashboard). Each of the displays has a limited set of filtering tools – designed to quickly give the user access to information pertinent to their job function(s) but with the option to expand the display in place without having to navigate to the more detailed search/listing screens.


Page 29 of 132

Figure 3-7: Web Dashboard


Page 30 of 132

The Inspections display shows the inspection date, inspector initials, inspection type, status, inspected party, complete/partial indicator, follow up indicator, and number of non-compliances. The filters include the inspection owner, status, and date. These filtering controls operate as follows:

x Owner: o My Inspections – displays inspections on which the current user is the owner

plus inspections belonging to users who report to the current user. o All Inspections – displays all inspections to which the current user has access.

x Inspection Status: o Open Inspections includes inspections that are In Progress, Draft, or In

Review status. o All Investigations includes all inspections to which the current user has

access.

x Inspection Date: o The Timeframe filter can be used to limit the age of inspections displayed.

Options include Current Month, Last 3 Months, Current Calendar Year, and All.

The Search button on the inspections display opens a more detailed inspections search page.

3.5.3. Search Records

The user can access the record search screen (Figure 3-8) through the global navigation menu to search for either inspection or enforcement records. The app stores the previous 2 years for offline use. For inspections no attachments are available for offline use (attachments are only available for Active Inspections).

Inspections can be searched by date range, status, and the type/subtype of the inspection. In addition the user can do a free text search which queries the following data fields:

x Inspection ID

x Inspector Name

x Business / Grower Name

x Permit ID

x License ID

x Site ID

From the query results, the user can tap on an inspection to view its details, or tap the “pin” icon to add the appropriate inspection to the Active Inspection list.


Page 31 of 132

Figure 3-8: Mobile Inspection Search Screen

3.5.4. Inspection Selection

The inspection selection screen (Figure 3-9 and Figure 3-10) presents the user with a list of available inspection types.


Page 32 of 132

Figure 3-9: Inspection Selection – Tabbed View


Page 33 of 132

Figure 3-10: Inspection Selection – Tiled View

By tapping on an inspection type, the app generates a unique inspection ID, creates an empty inspection record and displays the inspection record for data entry.

This screen can be reached from 3 different places: 1. Create new inspection from the dashboard. 2. Tapping a NOI from the dashboard. 3. Detailed Contact view from a quick search.

For options 2 and 3, the app will automatically enter available information once the inspection type is selected.


Page 34 of 132

3.5.5. Information Block Setup

CalPEATS divides every inspection into Information Blocks. Not every information block is available for every inspection. In fact only the Inspection Details (meta data), Contacts, Requirements, Remarks, and Signature information blocks are available for every inspection. Table 3-1 shows which information blocks appear on each of the defined inspection types.

Table 3-1: Information Blocks Used By Inspection Type

INFORMATION BLOCK 102 103 104 105 106 107 108 109 110

1 Inspection Details X X X X X X X X X

2 Contact X X X X X X X X X

3 Location X X X X X X X

4 Pesticide X X X X X X X

5 Handlers X X X X X X

6 Requirements X X X X X X X X X

7 Remarks X X X X X X X X X

8 Environmental Hazards X

9 Equipment X

10 Signature X X X X X X X X X For the most part, each information block appears and behaves the same way regardless of which inspection type it appears. There are some exceptions – for example, the Location information block asks for Property Location and Site ID for a 104 Pesticide Use Monitoring inspection, but asks for Application Site Address and Treatment Site for a 108 Structural Use Monitoring inspection. These changes are detailed in Tables 3-2 and 3-3.


Page 35 of 132

Table 3-2: Location Information Block Details By Inspection Type

LOCATION 102 103 104 105 106 107 108 109 110

Property Location X X X X X X

Site ID X X X X

Treatment Site X X

Commodity / Site X X X X X

Site Type X X X

Adjacent Environment X X X X

Field Size X

Wind Velocity X X X

Wind Direction X X X

Buffer Zone Type X


Page 36 of 132

Table 3-3: Product Information Block Details By Inspection Type

PRODUCTS 102 103 104 105 106 107 108 109 110

For e

ach

pest

icid

e

Name / Manufacturer X X X X X X X

Label Reg. # X X X X X X X

Signal Word X X X X X X X

Form X X X X X X

Rate X X X X X X

Dilution X X X X

REI X

Once

on

the

form

Application Method X X X

Structural Fumigation X

Proposed Date/Time of App. X

Date of Application X

REI Expired X

4 digit Fumigation Method Code X

One other information block that varies by inspection type is the Contacts block, where the types of contacts expected change by inspection type. These details are presented in Section 3.5.7.

3.5.6. Inspection Record – Mobile

Viewing or editing a specific inspection record begins with a display of all the associated information blocks. The screen shows the status of data entry for each information block (Figure 3-11 and Figure 3-12). By default the Inspection Details tab is expanded to display high-level information about the inspection. Tapping on any of the tabs or tiles opens the details for the selected information block.


Page 37 of 132

Figure 3-11: Inspection Record – Tabbed View

Summary status information included on the Inspection Record screen includes:

x Number of records entered.

x Inspection subtypes recorded.

x Incomplete/missing data warning.


Page 38 of 132

Figure 3-12: Inspection Record – Tiled View

Access to general inspection records is available via the functions menu at the bottom of the screen display; these include:

x Attachments, where the user can attach electronic files, photographs (existing or added on the fly), videos, audio, etc.

x Activity Log, where the system will automatically record certain activities and the user can add additional entries.

x Errors, showing all of the errors and warnings for the inspection record in one place.

x Scratch Pad, which gives the inspector a place to record notes that are not part of the inspection record (to be deleted once their supervisor approves the inspection).


Page 39 of 132

3.5.7. Inspection Record – Web The web version of the main inspection record screen takes each of the information blocks that are summarized on the mobile inspection record screen and expands them so they are accessible without navigating to separate web pages for each block. Figures 3-13 and 3-14 show the layout of the inspection detail page on the web.

The web form includes the same visual cues for data completeness as are displayed on the mobile device. To make the data entry as efficient as possible, all items on the form are editable “in place”, meaning that the user does not need to navigate to another web page to enter and save information, then returning to the main inspection record page. Data fields that utilize search screens to locate appropriate reference data (e.g., Product) will provide the search functions in a pop-up panel over the existing page, and will update the form with the selected entry when the user closes the panel. The search functionality provided will be identical to that offered in the mobile app, with the exception of using the device location to determine potential property operators (the web browser will generally not have access to GPS coordinates).


Page 40 of 132

Figure 3-13: Inspection Record – Web (Part 1)


Page 41 of 132

Figure 3-14: Inspection Record – Web (Part 2)

3.5.8. Information Block: Contacts One of the information blocks that is available for every inspection type is Contacts (Figure 3-15 and Figure 3-16). Here the user connects people or businesses to the inspection. While every inspection type has a list of expected contacts the user is able to add any number of additional contacts to the inspection record. For example, the Pesticide Use Monitoring inspection (104) is expecting a Property Operator, a Pest Control Business (if not grower-applied), and a Supervisor. However, the inspector may add additional records identifying the licensed individual who performed the employee training, or the licensed supervisor for a restricted material application (if different than the field supervisor).


Page 42 of 132

Figure 3-15: Contact Selection Screen – Tabbed View


Page 43 of 132

Figure 3-16: Inspection Contacts Listing – Tiled View

For the Contacts information block there are certain contact types expected for each inspection type, as shown in Table 3-4.


Page 44 of 132

Table 3-4: Expected Contact Types By Inspection Type

CONTACTS 102 103 104 105 106 107 108 109 110

1 Property Operator X X X X X

2 Firm/Person Inspected X X X

3 Firm Inspected X X X X X

4 Person Inspected X X X X X

5 Supervisor X X X X

6 PCA X X

7 PCB X X

8 Handler Trainer X

9 Field Worker Trainer X

In most cases, the supervisor is only identified by a name since they are usually not licensed, but he/she may also be a licensed individual. In the later case the user can make the connection to a licensed CalAgPermits contact and store the detailed data on the inspection record.

The user is able to add additional contacts to the inspection by adding OTHER contacts. Assigning a role to this contact clearly identifies the involvement of this contact for this inspection. OTHER contact roles include:

x Prime Contractor

x Qualifying License for Business

x Licensed Trainer

x Licensed Supervisor

x Pest Control Advisor

x Handler Trainer

x Field Worker Trainer

x Respirator Program Administrator

x Other (specify)


Page 45 of 132

This OTHER contact type can be linked to a CalAgPermits contact and therefore all the contact details can be copied into the new inspection contact. The user does have the choice to only enter a name without a link to CalAgPermits.

Selecting contacts employs the Suggestion Engine (see Section 3.5.13): known information is used to present the user with likely hits based on location, history, and permit/license number. Without typing anything the user simply taps on the correct contact (and selected license if required) and the app copies the detailed contact information from CalAgPermits into the inspection. The system also maintains the linking information (primary key) for the contact so that any edits to the contact information during the inspection can be transmitted back to the CalAgPermits contact manager for potential updates.

If none of the suggestions are correct, the user can start typing into the query textbox, which will trigger a search of the CalAgPermits contacts database. The county contacts database is part of the data that has been synced and is therefore available for offline consumption. The freeform search includes contact name, agent, address, permit/op-id number, license numbers, and historical grower names. The search for historical names works as follows: CalPEATS stores a list of grower names associated in CalAgPermits with prior versions of a given permit number/op-id – if the search term matches an old name in the list, the new contact record currently associated with that permit number/op-id will be displayed in the search results.

If for any reason the appropriate contact is not available, the user can enter all the data manually. If the contact type is indicated to be a grower or a license holder, the CalAgPermits contacts manager will be notified that a new contact record may be required.

3.5.9. Information Block: Handlers

The information block for Handlers (Figure 3-17) can collect an unlimited number of handlers. In contrast to the Contacts, handlers are not linked to CalAgPermits records. Generally, handlers are unlicensed individuals for whom data is not entered into the CalAgPermits database. CalPEATS is only recording the individual’s name; no address, phone, or other contact information is recorded. The most important information for each handler is the PPE worn by the individual.

There are also two icons available for each handler: one to record and attach an audio recording, the other to attach pictures (e.g. to document incorrect PPE).


Page 46 of 132

Figure 3-17: Handler Information Block – Handler Details

3.5.10. Information Block: Requirements

A key part of every inspection is the checklist of regulatory code sections that DPR recommends verifying for the different inspection types/subtypes. The system administrator configures and manages the specific citable sections that will be listed for each inspection subtype. Each county can add additional items to this list for county regulations or ordinances that apply only in their county.

The entry form for indicating compliance with each citable section is shown in Figure 3-18.


Page 47 of 132

Figure 3-18: Requirements Information Block

The different citable sections for the subtypes of an inspection are accessible through tabs. The inspector can easily switch back and forth between them (e.g. a mix/load and application use inspection).

Tapping on the citation section description or number brings up not only the detailed description of that citable section but also the explanatory text of the Compendium Vol. 4.

Users can tap the appropriate column to mark compliance, non-compliance, or N/A. They can change their selection during the inspection, or leave an entry blank if they are not sure of the proper answer. In the case of selecting non-compliance, the user is required to enter additional remarks to explain the non-compliance. When entering non-compliance remarks the user can also attach photos, video, etc. directly to the non-compliance explanation.


Page 48 of 132

Counties can opt in to a requirement to provide reasons for any N/A answers. If the county opts in, the user will be given a menu of explanatory options for the N/A answer (e.g., “Did not witness”, “No restricted material applied”, “Grower application”). If the county has not opted in, the user can check N/A with no additional input required.

After the inspector has collected the signature (or the inspected party has refused to sign the inspection), the inspection status changes from In Progress to Draft, indicating that field work is complete. After this status transition, any further changes to the requirements settings (compliance, non-compliance, N/A) will require a brief statement of explanation from the inspector and the change will be tracked for audit purposes.

3.5.11. Information Block: Signature

The signature information block (Figure 3-19) records both the inspector’s signature and the inspected party’s signature. Part of the app setup will include the user creating and storing their signature image so it will be automatically added to the signature block. The date and time is pre-populated for both signatures with the current date/time – this can be edited for the purpose of entering old inspections.

After the inspected party signs the inspection report, the status of the report changes from In Progress to Draft. The significance is that any change to the requirements section of the inspection report after the signature has been taken will be recorded in the activity log.

If the signature is refused by the inspected party, the inspector can select the switch “Signature Refused” in the Inspection Details. This switch is not displayed on the Signature Information Block to give any indication to the party inspected that they have the option of not signing. Turning on this switch also changes the status of the inspection from In Progress to Draft.

If the inspection being viewed was entered manually from a paper form, a flag on the inspection information block will indicate whether the signature was captured on the paper form.


Page 49 of 132

Figure 3-19: Signature Information Block

3.5.12. Delivering the Inspection Forms

CalPEATS supports generating inspection forms to deliver to the inspected party, their employer, and other interested parties as desired. The “printed” version of the forms will be generated as PDF files that look very much like the current series of DPR paper forms except that the forms will not be structured as a single page with supplemental forms for additional information. Each section of the form (products, handlers, citable sections, remarks) will expand as necessary to contain all information entered, pushing the succeeding sections down onto multiple pages. The PDF forms can be viewed, printed (in the office or in the field if the inspector has a portable printer) or emailed. Certain operating systems allow other mechanisms for file delivery such as AirDrop on iOS – these features will be available when the user views the PDF document on their device – however


Page 50 of 132

it will be the responsibility of the inspector to note the document delivery details in the inspection work activity log.

The email option will be initiated within the CalPEATS mobile app, so that the date, time, and recipients can be noted in the work activity log for the inspection. The actual delivery of the email will be handled by CalPEATS rather than handing off to the device default email client so that counties with shared devices (that do not want to set up personalized services like email) can still deliver emails from CalPEATS. If the device does not have Internet connectivity at the time the email is requested, it will be queued up and sent once connectivity is established. Each county will have to set up appropriate access to their outgoing email service for this approach to work. If that is not possible, the mobile device user can use built in features to mail the PDF form after it is generated and displayed on their device – but the delivery information in the work activity log will have to be manually entered.

3.5.13. Suggestion Engine

Typing on a tablet device is not the most effective way to enter and capture data, which is especially true when the inspector is out in the field conducting an inspection. CalPEATS mobile will have two features to streamline data capture: speech-to-text and suggestions. Suggestions are enabled when a selection screen appears and the user has not entered any search/filter terms into it, yet. The Suggestion Engine determines what kind of information the user is looking for and goes through a list of actions to come up with a list of possible entries (Table 3-5). The order of the list of actions is important because we want more likely suggestions to be further up in the list. The suggested list displays an explanation for each entry explaining how entry was included. This will help the user to pick the right entry.


Page 51 of 132

Table 3-5: Suggestion Engine Configuration SUGGESTION ENGINE SOURCE

Known Past Inspection

Current Location Permit NOI

Property Operator

Firm Inspected

Person Inspected Supervisor PCA

SEAR

CHIN

G FO

R

Cont

acts

Property Operator X X X X X X X

Firm Inspected X X X X X

Person Inspected X X X X X

Supervisor X X X

PCA X X X

Handler Trainer X X X

Field Worker Trainer

X X X

RPA X X X

Handler

Other

Oth

er

Permit X X X

Site ID X X X X

Commodity X X X

Product X X X

Property Operator X X X X X X X


Page 52 of 132

Explaining all of the different scenarios the Suggestion Engine covers would overwhelm this document. Instead, one scenario is described in detail below to illustrate the process.

Suggestion Engine process for Property Operator 1. If a permit or operator id is known, add the Property Operator as the most likely.

Suggestion Explanation: “found on permit” 2. If the inspection is based on an NOI, add the Property Operator to the list

Suggestion Explanation: “found on NOI” 3. If the location of the device is known, the Suggestion Engine can perform a lookup

by location -> CalAgPermits section -> site -> property operator. Suggestion Explanation: “nearby sites”

4. Add each of the following items with a database query of previous inspection records and sort the results by inspection date.

a. Is Firm/Person Inspected (FPI) already entered?

x SELECT Prop-Op FROM old_inspections WHERE FPI=’known contact’ b. Is Supervisor (SUP) already entered?

x SELECT Prop-Op FROM old_inspections WHERE SUP=’known contact’ c. Is PCA already entered?

x SELECT Prop-Op FROM old_inspections WHERE PCA=’known contact’ Suggestion Explanation: “inspection history”

5. Go through all available/active NOIs: add Prop-Op to list Suggestion Explanation: “available NOIs”

Once the inspector decides that the desired record is not included in the suggestion list, and they must begin to type a search term, they will have the option to use the speech-to-text functionality built in to their mobile device (this functionality is currently on available if the device is online). In many cases, the data entry process can be accomplished with little use of the mobile device keyboard. The speech-to-text function can also be used to dictate notes and remarks, with final editing for spelling and punctuation occurring long after the field work is complete.

These features are not available on the web platform (although speech-to-text is supported on some desktop operating systems). The suggestion engine is primarily designed to speed up the data entry process in the field. Most users will only use the web inspection data entry interface to enter inspection data “after the fact,” meaning that the data has already been recorded on paper. Rapid search capability and minimization of keyboard input are not important design features on the web platform – since the database is remote for web operations the suggestion engine is expected to be too slow to be useful in that environment.


Page 53 of 132

3.6. Mobile Specific Functionality

3.6.1. Authentication

The mobile app authentication for CalPEATS is somewhat complex in that it must handle initial logins, changing users, and online/offline modes. Figure 3-20 shows the application logic for user authentication including the login and logout processes.

Figure 3-20: Logic Diagram for Mobile Application User Authentication


Page 54 of 132

If the user has never logged into the device, he/she must be online for a credential check against the CalPEATS server. The CalPEATS server checks the credentials against it’s own main database. To avoid maintaining multiple user sign-on passwords, CalPEATS can utilize user credentials that are already in place for CalAgPermits. An additional flag “isCalAgPermitsUser” within the CalPEATS user table directs CalPEATS to validate the user id and password in the CalAgPermits database for that user. In cases the username does not exist in the CalPEATS database, or has invalid credentials in either database, the server rejects the login request.

A successful login displays the user’s dashboard and stores the username (for the technically inclined: as well as a credential hash) on the device. This enables the user to login with those credentials in an offline scenario.

The mobile user only has to validate their password with the CalPEATS app once each day. During the day, they can run the app without re-authenticating (the device itself will have a password-protected lock mode that kicks in when the device is idle). When syncing data, the user must be re-authenticated if they have not synced with the server that day.

3.6.2. Settings / Customizations

Certain aspects of the inspections interface are customizable through a combination of County Settings and User Settings. County settings include:

x Opt in or out of N/A explanations x Additional citable sections to be included on certain inspection types

These settings are stored in the main database and are included in the mobile application data sync, so if a county changes one of these settings they will need to ensure that all inspectors perform a data sync to pick up the changes.

User Settings are specific to the user’s device and are not transmitted to the main database. These include:

x Color scheme

x Signature image

x Allow use of cellular and/or wifi data for syncing

x CalPEATS Device Id (see Section Error! Reference source not found.)

While the device stores the inspector’s signature securely on the device, they will have to regenerate the image when using a new device. Similarly, when an inspector switches to a new device, their color scheme settings will not be transferred automatically my CalPEATS. If the user uses a backup/restore process offered by their OS vendor (or other commercial service), then their device restoration will carry all of their settings over to the new device.


Page 55 of 132

3.6.3. App Delivery and Updates

The CalPEATS mobile app will be delivered via the CalPEATS web site. Users will be required to log in to the web site on their mobile device before they can download the app installer. Alternately, users (or a county IT support person) can download the installer locally and install it on devices. CaliCo Solutions will obtain the necessary enterprise code signing licenses to allow this mode of installation.

Once CalPEATS mobile is installed, the app checks the CalPEATS server for the latest available version once a day. If a new version is available, the app notifies the user with a list of improved features.

In detail the app will go through those steps: 1. Upon app startup, it requests the current app information from the CalPEATS

server, sending the current installed version as part of the request. This happens even before the actual login to ensure a working upgrade path even when bugs prevent the app from logging in.

2. The API server responds with the most current version number for this platform as well as a list of changes between the installed version and the most current version.

3. The app decides if the returned version is newer (or different) from the one that is installed:

a. In most cases, the update will be a minor update and the inspector could continue using the old version with no adverse effects. If we are in this scenario and haven’t asked the user this day, the message box lets the user know that a new version is available incl. version number and the description (release notes). The user has the option to decline the update, or choose to install the update now.

b. If the update is critical (meaning that there could be inconsistent data or the loss of data if the update is not performed) the end user will be presented with a message box informing them of the need to update the application. The end user has no choice to decline the update and can only proceed into the application after performing the update.

4. If the user wants to install the update, the app downloads the file from CalPEATS server and executes the installer. The app automatically restarts and goes through the same steps. This time the versions will match and the user proceeds directly to the login screen.

5. Database structural changes will be handled as critical updates so that the application can ensure no loss of data on the mobile device for any records not yet synced to the main database.


Page 56 of 132

3.7. Platform-Specific Screenshots

The screenshots provided above are “conceptual” design models for the mobile platform. When the common code base for the applications is deployed to each operating system, the actual screens will appear slightly different on each platform – this is by design so that users that are familiar with a particular type of device will see familiar tools and controls. Rather than produce three sets of screen shots for every screen in the mobile application, we have included in this section a series of examples that illustrate how different on-screen controls will appear on each operating system. The reader should use these examples to extrapolate the actual appearance of the screens for each platform.

Note that these platform-specific screenshots were developed based on the First Draft SDS and have not been updated to reflect the new screen designs. To perform this update, the demo app would need complete re-coding – since the objective of this section is to illustrate the differences between platforms for a general list of screen controls it was not necessary that the actual screens here be updated.


Page 57 of 132

Example 1 – Authentication Screen

Conceptual Design:

x The authentication screen contains two input boxes for userid and password.

x A switch enables the user to preset the userid.


Page 58 of 132

iOS Android Windows

x The active input field magnifies to help in challenging environments

x The input field themselves have a platform specific look & feel

x The Store User switch has a platform specific look & feel.

x The keyboard is the native platform specific the user is used to.










Page 59 of 132

Example 2 – Context Menus

Conceptual Design:

x The conceptual design does not have a separate screenshot, but it spells out in the narrative which items the context menu contains. For example the Archive view in the Inspection Management level, calls for a context menu for Follow-Up, Sync, Help, Delete.


Page 60 of 132

iOS Android Windows

x iOS reveals its context menu by a left swipe on that particular row.

x While the row itself is moved to the left, the context menu moves in from the right.

x If there are more than three items in the context menu, iOS groups them under ‘more’

x To cancel out, the user taps anywhere on the screen

x Android reveals its context menu at the top of the screen.

x Windows reveals the context menu as a list of items beneath the selected row.

x To cancel the context menu, the user taps anywhere on the screen outside the context menu.


Page 61 of 132

Example 3 – Message Boxes

Conceptual Design:

x A message box communicates a specific status to the user or offers the user a choice.


Page 62 of 132

iOS Android Windows

x A message box in iOS looks like one on the desktop with a distinct area floating on top of the screen.

x Android displays message boxes horizontally extended and more blended into the current view.

x Windows positions the message box on top of the screen with big buttons that are easy to tap.


Page 63 of 132

Example 4 – PR-ENF-104A Inspection Main Screen

Conceptual Design:

x The header indicates which inspection the user is working on.

x The icon in the top right is a navigational button which always navigates one level up (in this case to the Inspection Management screen)

x At the bottom is the tool bar which provides different views of this inspection record

x The main view shows a list of modules that make up the inspection form. A status indicator clearly shows the progress of that module.


Page 64 of 132

iOS Android Windows

x The tool bar is at the bottom

x Selected page is marked in blue

x The tool bar is at the top

x Selected page has a blue underline

x The tool bar is at the top as a scrollbar

x Selected page is always on the left, marked in white


Page 65 of 132

Example 5 – AOL Module Display

Conceptual Design:

x The four submodules for the AOL module are stacked on top each other and can be scrolled vertically. The Location Module is not visible as it is scrolled off the screen.

x All the details are displayed right on the submodule itself.

x Each of the submodules have a Search and Edit button.


Page 66 of 132

iOS Android Windows

x The Search & Edit buttons are iOS specific but have been enhanced with a border for clarity.

x The Search & Edit buttons are Android default.

x The Search & Edit buttons are Windows default.

x The button text/background colors need to be adjusted as part of the color theme.


Page 67 of 132

4. Investigation Component

4.1. Investigation Component Overview

The second major CalPEATS component supports and organizes investigations. County staff can document and track investigation progress of non-compliances, worker exposures, complaints, and a variety of other situations. Investigations fall into four major categories: human exposure, crop loss/damages, environmental effects, and other. The CalPEATS component will allow all of the supporting files, evidence, and documentation to be collected into a single electronic case file for ease of review, tracking, and analysis.

4.2. Investigation Workflow

Figure 4-1 shows the detailed workflow processes for investigations. Based upon the workflow included in the SRS, the CalPEATS workflow shows the planned available steps for investigations.

The first step in starting an investigation is to review the list of open investigations to see if a related investigation has already been opened; another county staff or DPR may have received a complaint, for example, and already begun work. If so, the user can add to that investigation; if not, the user creates a new Investigation Record in CalPEATS, documenting the initial event or episode. WHS staff will have access to enter their individual illness case information and can request that a county initiate a worker exposure investigation. Users enter basic initial data here and can upload the initial documentation reports or forms. This process can be sidestepped if the investigation is pursued directly as a result of an inspection, in which case there is no need to search for existing investigation cases first.

For Priority Episode Investigations, a decision point is available for staff to add a Priority Episode flag, which can be added at any point in an investigation as additional information becomes available. Users enter documentation data for any number of attributes (number of workers affected, value of crops lost, environmental effects, etc.). An automated, pre-filled notification form (Priority Episode Notification Report, or PENR) can be generated by DPR and sent to appropriate agencies (DPR adds notification documentation back into CalPEATS). A 15-day update report is manually issued by DPR (so indicated by the orange shading on Figure 4-1), but documented within CalPEATS. Upon completion, DPR generates a Closing Report and updates CalPEATS with the issue date for that report.


Page 68 of 132

Figure 4-1: Investigations Workflow


Page 69 of 132

From this point onward in the Investigation workflow, all activities are centered within the large “Conduct Investigation” activity box. Users can enter information as collected, and in any order to meet their needs:

x Attach files (any format for which viewers are available on user desktops) and enter file metadata,

x Link the investigation to inspection(s), and/or create a new inspection that is pre-linked to the investigation,

x Add entrees to the workflow log,

x Complete and attach available fillable form reports,

x Enter data about alleged respondents, pesticide products, and claimants/injured parties,

x Allow DPR access to an investigation (if not already automatically provided for a Priority Episode), and similarly allow other counties access as well,

As the investigation proceeds, investigations can tabulate instances of non-compliance (from linked inspections or entered directly) and document them as violations. Future Enforcements will use documented investigation violations as the basis for future actions.

The main outputs of a CalPEATS investigation are: 1. An Investigation Report, and 2. A Investigation Case File Report

The user selects the appropriate pre-filled report forms (PR-ENF-127 et al) and prepares the Pesticide Episode Investigation Report (PEIR) or Antimicrobial Exposure Episode Report (AEER), which may include lengthy investigation summaries as attachments. The Investigation Case File will be an automated report that will compile all of the investigation data (workflow log, attachments, product lists, violations, etc.) into a single electronic file that can be shared with external agencies and parties for review and analysis. Video, audio, and other files will be attached in their native formats for separate review.

Once the county has reviewed and approved the file, the Investigation is closed, and available for enforcement if violations have been documented. Concurrent with the county’s enforcement process, DPR may review the case file and can request updates and additions to the PEIR, and possibly recommend additional investigation activities. If the county agrees to changes, they may reopen the case file.


Page 70 of 132

4.3. Investigation Statuses

There are three potential statuses of Investigations: 1. In Progress 2. In Review 3. Closed

If violations are documented, the county will need to open an Enforcement Response for resolution (even if the county does not plan to pursue the violations, they will need to document that decision in an enforcement response record). The statuses are depicted on Figure 4-2, and some additional information on the transitions is supplied below.


Any county user or a DPR user with WHS permissions can create a new Investigation Record. Note that a separate workflow will be provided in CalPEATS to combine multiple investigations into one, if investigation(s) were created in error.

Finalize (In Progress => In Review)

An Investigation “owner” believes the investigation to be complete and requests county review by a supervisor or designee. A validation check is provided for completeness.

Revise (In Review => In Progress)

If the investigator determines that they need to make revisions to a completed investigation prior to the review, they can revise the case file and move it back to In Progress status.

Approve (In Review => Closed)

The county reviewer approves the Investigation report.

Reject (In Review => In Progress)

The county reviewer requires changes in the case file before it can be closed.

Reopen (Closed => In Progress)

The case file is reopened and can be edited and updated.


Page 71 of 132

Figure 4-2: Investigation Statuses


Page 72 of 132

4.4. Investigation User Interface Design

The Investigations Component in CalPEATS is comprised of the following user interface screens:

o Investigation Listing – Dashboard o Investigation Listing – Details and Search o New Investigation Setup o Inspection Respondent/Claimant Assignment o Investigation Home Page o Work Activity Log List and Details o Attachment List and Details o Investigative Forms List and Details o Notification List and Details o Alleged Respondent List and Details o Claimant/Injured Party List and Details o Product List and Details o Related Inspections List and Details o Violations List and Details o DPR WHS Branch Illness Case List and Details

The following subsections describe the processes and user interface screens for starting investigations, viewing/searching for investigations, conducting investigations, exporting investigation data, sharing investigations with DPR and other counties, querying/reporting on investigations, and closing investigations.

4.4.1. Viewing/Searching for Investigations

Investigations are listed in two places in CalPEATS – a simplified listing is available on the Dashboard page (see Section 3.5.2 for details), with a more detailed listing available on the Investigation Listing page in the Investigations Module.

Investigations Dashboard Screen

The dashboard listing shows (by default) all investigations relevant to the currently logged on user. “Relevant” is defined as:

x For County/DPR staff that are not designated as supervisors, In Progress investigations on which they are the designated investigator. This may be because they opened the investigation, or a supervisor assigned it to them. For multi-county staff, these are filtered to their currently selected county.


Page 73 of 132

x For County/DPR staff that are designated as supervisors, relevant investigations include:

o In Progress investigations on which they are the designated investigator. o Investigations in Internal Review status belonging to staff that report to them

(see Section 2.2).

x For DPR EBLs, priority investigations in their assigned counties that are In Progress or in County Review, investigations that are Closed but have not yet been marked as Reviewed by the EBL, and priority investigations that do not have a Priority Closing Report.

x For DPR WHS Branch staff, closed county illness investigations that have not been updated in the DPR web-based database, plus Priority Episode illness investigations. For this purpose, the term “county illness investigations” means investigations that include WHS illness cases.

x For DPR Priority Investigations staff, all priority investigations that are In Progress, or are Closed but do not yet have a Priority Closing Report.

These two filters are implemented using the “Whose Investigations” and “Investigation Status” controls on the Investigations Dashboard (Figure 3-7). These filtering controls operate as follows:

x Whose Investigations: o My Investigations – displays investigations on which the current user is the

owner plus investigations belonging to users who report to the current user. o All Investigations – displays all investigations to which the current user has

access.

x Investigation Status: o Open Investigations:

� For county staff and supervisors, this includes investigations that are In Progress or in Internal Review status.

� For DPR users, this includes DPR investigations that are In Progress or in Internal Review status, county Priority investigations that are In Progress or in Internal Review status, county priority investigations that are Closed but do not yet have a Priority Closing report, and WHS illness investigations that are Closed but that have not been input into the DPR web-based database.

o All Investigations – all investigations to which the current user has access.

To simplify the presentation and operation of the dashboard listing of investigations, the list will not offer additional filtering options. Investigations will be sorted to show Priority


Page 74 of 132

Investigations first, then non-priority investigations. Within those groupings, investigations will be sorted by age – the user can select ascending or descending order.

The tabular listing of investigations will show the following information for each investigation:

x Investigation Case #

x Investigator

x Incident Date

x Respondent (first entity listed)

x Location

x Investigating County (for DPR users only)

x County of Incident (if different than Investigating County)

x Status

x Priority Indicator

x Countdown or Completed Date*

x For Priority Investigations viewed by DPR users: o PENR Submitted Date o Update Report Countdown or Date** o Closing Report Submitted Date

* The countdown for an investigation is the number of days remaining until the investigation should be completed. For priority episodes, the investigation should be completed within 120 days after the incident date (or the date the incident was flagged as a priority investigation if later). For other investigations, the County Application Administrator may set a desired completion interval for the county. If this interval is not set then the countdown column will be blank until the investigation is complete, at which time the completion date will be displayed.

** The update report countdown is the number of days remaining until the 15-day update report is due (15 days after the initial PENR is submitted). Once the update report has been submitted, this column will display the submittal date.

Investigations Listing Screen

The detailed listing screen for investigations (available from the user dashboard and as the introduction page in the investigation module; also displayed as the first step in starting a new investigation record) provides the same listing of investigations as the dashboard view with addition filtering and sorting options, as well as additional columns available for display in the tabular listing (Figure 4-3).


Page 75 of 132

The additional search/filtering options will include:

x Investigation Case # (wildcard text search)

x Investigator (list of users)

x Incident Date (date range)

x Location (wildcard text search)

x Investigating County (list of counties, DPR users only)

x Status (multiselect)

x Priority/Non-Priority/All (3-way selector)

x Claimant Name (wildcard text search on all claimant names)

x Respondent Name (wildcard text search on all respondent names)

x Respondent License/Certificate (wildcard text search on all respondent license numbers/certificate numbers)

x Product Name (wildcard search on all product names)

x Product Label Number (wildcard search on all product label numbers)

x Code Section Violated (wildcard text search on all violation code sections)

x Narrative Text (wildcard text search in narrative)

Additional columns available for display in the tabular listing of investigations are listed below. The screen will default to the same display columns as the dashboard view; users can then customize the list of columns displayed and optionally save their selected column list as their default display for this screen.

x Investigation Start Date/Time

x Investigation Type

x Investigation Subtype

x DPR Access Allowed

x Number of Claimants

x Number of Respondents

x Number of Products

x Number of Violations

x Investigation Report Attached

From the investigation listing screen, the user can begin a new investigation record by clicking the New Investigation button (Section 4.4.2), or view an existing investigation


Page 76 of 132

record by clicking the View button in the investigation row. Viewing an investigation takes the user to the Investigation Home Page (Section 4.4.3).

Users with the appropriate permissions can delete investigation records while the investigation is In Progress. The system will provide multiple confirmation prompts before actually deleting the data. Once the user confirms all of the prompts, the investigation record and all associated data will be deleted.

Figure 4-3: Investigation List/Search

4.4.2. Starting an Investigation

In CalPEATS, users with the appropriate privileges can begin an investigation in several ways:

1. From the Investigations Listing page by clicking the New Investigation button. This will open the New Investigation screen (Figure 4-4) with the following fields filled in:

x Investigation Start Date/Time – defaults to the current date/time on the user’s computer.

x County of Incident – set to the current user’s county (currently selected county for multi-county users, left blank for DPR users).

x Investigating Party – set to the current user’s county (currently selected county for multi-county users, set to “DPR” for DPR users).

x Case Number – auto-numbered using the county-selected numbering scheme.

x Record Status – set to In Progress.

x DPR Access – defaults to No.

x Other County Access – defaults to None.


Page 77 of 132

The user will then complete the remaining fields on the new investigation screen and save the new investigation record.

2. From an Approved inspection report where non-compliances have been noted. The user (inspector or supervisor) can click the “Open Investigation” button to begin a new investigation record, provided that there is not an existing investigation record linked to the current inspection. This will open the New Investigation screen, and will automatically fill in the fields noted above with the addition of:

x Location – will contain the property location for Ag field inspections, the application site address for structural inspections, and the firm location for headquarters inspections.

The user will then complete the remaining fields on the new investigation screen and save the new investigation record. When the user clicks the Save button, the system will display a list of all of the parties involved in the inspection (Firm/Person Inspected, Property Operator, Supervisor, Handlers, etc.) in a grid, allowing the user to check Respondent or Claimant (or neither) for each party (Figure 4-5). Upon saving the new record, the system will add the following records to the investigation case file:

x Link to inspection record

x Work log record indicating investigation was opened

x Product records for all products noted on the inspection

x Violation records for all non-compliances noted on the inspection

x Alleged Respondent records as indicated by the user

x Claimant/Injured Party records as indicated by the user 3. From a DPR WHS Branch Investigation Request record. WHS investigation requests

are listed on the WHS Investigation Request screen, grouped by WHS reference number. Any group containing WHS illness cases that have not yet been linked into a county investigation record is eligible to be used to open a new investigation record. The CalPEATS user may click on the group record, or on an individual case record to begin the process. This will open the New Investigation screen with the fields filled out as in Case 1 above. The user will then complete the remaining fields on the new investigation screen and save the new investigation record. After saving the initial investigation record, the system will add a Claimant/Injured Party record to the investigation for each WHS Illness Case in the group selected during the initial setup (or just one record if a specific WHS Illness case was selected to begin the investigation record).

If the investigator marks the case as a priority investigation, an email notification will be sent to the EBL assigned to the users county. In addition, the investigation will appear on that EBL’s dashboard display. For priority investigations, the investigation setup screen


Page 78 of 132

will display three additional fields that are viewable only by DPR users, and editable only by the DPR EBL for the county. These fields are:

x Date Initial PENR Submitted.

x Date 15-Day Update Report Submitted.

x Date Closing Report Submitted.

The DPR EBL can edit/update these fields at any time on a priority investigation. They will not be displayed for county users.

When the investigation setup data are saved, the system will display the Investigation Home Page (Section 4.4.3).

Figure 4-4: Investigation Setup


Page 79 of 132

Figure 4-5: New Investigation From Inspection

4.4.3. Investigation Home Page

The Investigation Home Page shows a summary of each of the components of the investigation. Each component can be expanded to a more detailed view using the Edit button; the investigator can then add, edit, and delete records. The main investigation page layout is shown in Figure 4-6.

Each individual component of the investigation process is discussed in the following subsections. This section describes the page-level functions available on the Investigations Home Page.


Page 80 of 132

Figure 4-6: Investigation Main Page


Page 81 of 132

There are several functions that the investigator and/or reviewer can use during the course of the investigation (under the Investigation Actions menu):

x DPR Access – for non-priority investigations that are In Progress, the investigator can provide online access to DPR staff using this feature. Access can also be revoked for non-priority investigations at any time before the investigation is closed.

x Other County Access – the investigator can provide access to other counties for Closed investigations. This option is supplemental to the county-level configuration option to share all closed county records with other counties. Again, access can also be revoked using this feature.

x Complete Investigation – this marks the investigation record as ready for internal review (only available on In Progress investigations). When an investigation is marked as Completed, the system will prompt the user to delete any attachment or work activity log entry that is marked as Draft. The user may choose to ignore the prompt (retaining the draft records in the case file), allow the system to delete all marked records, or cancel the action and manually remove or modify the draft records.

x Revise Investigation – this places the investigation back into In Progress status for the investigator to make revisions or complete additional work. Only available to reviewers on Completed investigations.

x Approve Investigation – this marks the investigation as Closed, and is only available to reviewers on Completed investigations. If there are any Draft records in the case file when an investigation is marked as Approved, the system will prompt the reviewer to delete any record that is marked as Draft. The user may choose to allow the system to delete all marked records, or cancel the action and manually remove or modify the draft records.

x Reassign Investigation – in some cases, the investigation owner may need to be changed (for example, if the original investigator leaves the county or is reassigned to other duties). Any user with appropriate permissions can reassign the investigation to a different user who has permissions to conduct investigations. The user id on all existing attachments, work activity logs, etc. will remain unchanged – only the investigation owner id will change.

x Export Investigation File – when requesting an electronic Investigation file from CalPEATS, the user will be given two options. They may include/exclude HIPAA protected records, and they may include/exclude Draft records. Excluding HIPAA protected records means that CalPEATS will remove any Personally Identifiable Information (PII) from the Claimant/Injured Party printout and will exclude any attachments or work activity logs that are flagged as HIPAA protected. Excluding Draft records means that CalPEATS will exclude any attachments or work activity logs that are marked as Draft. In both cases, the Investigation file will include a listing of the redacted records but not the actual content.


Page 82 of 132

x Reopen Investigation – in some limited cases, a closed investigation file may need to be reopened and modified. Users with the appropriate privileges can reopen the case file, moving the investigation status back to In Progress. All existing work activity log records (particularly those showing the previous review and approval) are retained, but the investigator can now add, edit, and delete records as with any In Progress investigation. No restrictions will be placed on the investigator – it is incumbent on them to maintain the historical integrity of the case file attachments, while recognizing that in some cases even the historical records may need to be updated.

x Transfer Investigation – this feature is only available to system administrators, and allows for the transfer of an In Progress investigation (including all records and attachments) to another county. In order for the System Administrator to complete this process, both counties must agree on the transfer, and the receiving county must identify a specific user to whom ownership of all records will be transferred. Since this process happens very infrequently, a manual process to be handled by the System Administrator is deemed sufficient. The originating county should clean out any record they do not wish to transfer before requesting the transfer operation.

Investigation Setup

This screen was previously discussed in Section 4.4.2. At any time after the initial investigation setup is complete but before the investigation is completed, the investigator may re-open the investigation setup screen and edit data. The investigator may also modify the priority investigation criteria and flag the case as a priority investigation (in which case the appropriate EBL will be notified by email and the PENR and subsequent DPR reporting requirements will kick in).

For priority investigations, the DPR EBL for the county can use the Investigation Setup screen to enter and update the three DPR tracking dates (initial PENR, update report, completion report). The EBL can enter/update these dates regardless of the status of the investigation.

Investigation Narrative

This field in the investigation case file is intended for a short synopsis of the incident and ensuing investigation, and is not intended to be used for the final investigation report. To edit the narrative for an In Progress investigation, the user will click the Edit button next to the narrative text box. The narrative text box will expand to fill the screen allowing the user to modify the text and either save or cancel the changes.

Work Activity Log

Summary View:

x Display date/time of entry, user, action taken.

x Sort by date/time in descending order (newest first).


Page 83 of 132

Detailed View:

x Also display notes/comments, draft flag, PII flag.

x Sort on any column.

x Filter on entry date, action taken, draft flag, PII flag.

x Provide links to associated forms and attachments.

x Export to Excel.

User can add, update, and delete non-system entries while the investigation is In Progress.

Attachments

Summary View:

x Display date attached, type, file name (link to open file), title.

x Sort “Investigation Report” to the top of the list (if present), then sort remaining attachments by date attached in descending order.

Detailed View:

x Also display user, document date, notes/comments, “Investigation Report” flag, draft flag, PII flag.


x Filter on date attached, document date, type, draft flag, PII flag.

x Export to Excel (metadata, not file content).

User can add, update (including replacing the attached file), and delete entries while the investigation is In Progress.

One (and only one) attachment may be flagged as the official investigation report. This attachment may be a final copy of the PEIR or AEER, or (more commonly) it may be a report document written by the investigator summarizing the investigation and findings. Flagging this document makes it easier for others to locate the report for review.

When adding an attachment, the user will be reminded that scanned or electronically completed Investigation Forms should be uploaded via the Investigation Forms module.

If the user indicates they are uploading an outside agency notification letter or form, they will also be prompted for the metadata required for notifications (name of person and agency name). Upon completing the upload, a record will be added to the Notifications module linking to the uploaded notification document. The notification date will be assumed to be the same as the document date.


Page 84 of 132

Investigation Forms

Summary View:

x Display date uploaded, form number, and form title (link to open PDF).

x Sort by date uploaded in descending order.

Detailed View:

x Also display user, document date, notes/comments, draft flag, PII flag.


x Filter on date attached, document date, draft flag, PII flag.

x Export to Excel (metadata, not file content).

Above the form listing grid, the screen will display a dropdown menu of forms with a Generate button. This will create a fillable PDF file for the selected form type with data fields filled in from the CalPEATS database. Most forms will only be partially filled in from the database information – after generating the PDF the user will need to complete the remainder of the form and then upload the final result to CalPEATS on this screen.

User can add, update (including replacing the attached file), and delete entries while the investigation is In Progress.

County Notifications

Summary View:

x Display entry date, notification date, agency notified.

x Sort by entry date in descending order.

Detailed View:

x Also display name of person notified, user, link to notification document (if uploaded).


x No filters (we anticipate at most a handful of records so filtering is not required).

x Export to Excel (indicate file name if uploaded).

User can add, update, and delete entries while the investigation is In Progress. To replace an uploaded file, the user must do so in the Attachments module.

DPR Notifications

County users will not see the DPR notifications section, and it will only be displayed for DPR users for Priority investigations. The functionality is identical to the County


Page 85 of 132

Notifications module except that only the DPR EBL for the county can add/edit records, and they do not have the ability to upload attachments for notification records. The EBL can add/edit DPR notification records regardless of the status of the investigation.

Respondents

Summary View:

x Display date record added, type, name, license/permit number.

x Sort by date record added in descending order.

Detailed View:

x Also display license/permit expiration, license categories, mailing and physical addressed.

x Sort on any column (address columns sorted on city/state/zip).


x Export to Excel.

User can add, update, and delete entries while the investigation is In Progress.

When adding a respondent, user will be presented with the Person/Business search screen. Upon finding the desired person or business, the user will be required to identify the permit/op-id or license number under which the person or business is being investigated.

If the desired person/business in not found in the CalAgPermits permit/contact information, the user may enter an “unlinked” record (i.e., name and address will be stored in the investigation but not linked to a CalAgPermits contact). If the user updates name or address information on a linked contact record, the changes will be stored in the investigation case file and the CalAgPermits contact manager will be notified of the potential update.

Claimants/Injured Parties

Summary View:

x Display date record added, name, type, WHS case number.


Detailed View:

x By default, also display address, telephone, email, age, gender, and attachments.

x Allow user to customize columns displayed to include any column in the Claimant/Injured Party data elements. Allow user to save column display preferences.


Page 86 of 132


x Filter on date record added, claimant type, complaint signed, doctor visited.

x Search on name, address, telephone, email, medical facility where admitted, physician name, employer of injured person.

x Export to Excel, allow user to include all fields, exclude symptom/injury information, or exclude name/address information.


If user is adding a WHS illness case, they must select from a list of open WHS cases assigned to their county to create the linkage, and then fill in the details for the individual. If WHS has not yet opened a case for the individual, the investigator has two options: 1) they can email the data to WHS and wait for them to open a case; or 2) they can complete the investigation and allow WHS to create their case number and record after the investigation is closed.

If the user deletes a record that is linked to a WHS illness case, the WHS illness case is not deleted – instead it goes back into the pool of open WHS illness cases for the county.

The attachments feature for Claimants/Injured Parties is intended to replace the functionality previously available via the DPR Secure Access Website (SAW). When DPR is viewing a case via their WHS Illness Cases screen, or the county is viewing an individual via the Investigations Claimants/Injured Parties screen, both parties will see ALL attachments for the individual case. Only the owner of each attachment record can edit or update the record. When an attachment record is added, updated, or deleted, the other party on the investigation is notified by email of the change.

Products

Summary View:

x Display date record added, product name, label number, signal word.


Detailed View:

x Also display formulation, rate and units, dilution and units, treatment date/time, commodity treated, and application equipment used.



x Export to Excel.



Page 87 of 132

Related Inspections

Summary View:

x Display inspection date/time, id (link to open inspection), type, person/firm inspected, number of non-compliances.

x Sort on inspection date/time in descending order.

Detailed View:

x Also display code sections violated (comma separated list), violation notice flag, cease and desist flag.

x Sort on any column (code sections sorts on first code section listed).


x Export to Excel.

To add an inspection into an investigation case file, user will select either “Add existing” or “Add new”. When adding an existing inspection, the user will be presented with the inspections listing screen, operating in “select” mode. Once the inspection is selected, the system will prompt the user to add details to the investigation case file (see discussion in Section 4.4.2 for starting an investigation from an existing inspection record).

If the user opts to add a new inspection, they will be prompted for the inspection type and then a new blank inspection record of that type will be created under their user id and linked to the investigation case file. The user can then complete the inspection record after the investigation case file link is saved, or can leave the inspection in their queue to be completed at a later date.

User can delete linked inspections while the investigation is In Progress.

Violations

Summary View:

x Display violation date, violation inspection id (if applicable), code section violated, violation remarks (trim text to available screen space, hover mouse for full text).

x Sort by violation date in descending order.

Detailed View:

x Display full violation remarks text, links to attachments.

x Sort on any column except attachment links.

x No filters (no useful detail fields for filtering).

x Export to Excel.


Page 88 of 132

Violations may be linked in to the investigation case file from an inspection – in this case, the violation details will be linked to the inspection record and will not be editable in the investigation case file. Attachments to the violation on the inspection record will be shown with links to open them. These violations may be deleted from the investigation.

When adding violations to an investigation, the user may select violations on existing inspection records, or they may create new violation records by entering the violation data elements directly (violation date, code section violated, violation remarks, attachments). To pull in violations from an existing inspection record, the user should use the process described above for linking the inspection record to the investigation.

4.4.4. DPR WHS Branch Illness Case Management

DPR’s WHS Branch staff receive illness notifications from Poison Control and Workers Compensation personnel, which they manage in a separate DPR database system. In the past, the WHS staff have referred these illness cases to the county where the incident took place using the Secure Access Website (SAW). The purpose of SAW as to provide a secure mechanism for WHS and the investigating county to exchange details about the illness cases which are protected by HIPAA. The WHS staff would upload the illness report(s) to SAW, then notify the county who would then download the information from SAW. In return, the county could upload documents to SAW as the investigation proceeded and WHS would be notified so they could view those documents.

In CalPEATS, these functions are accomplished using the WHS Branch Illness Cases screen (Figure 4-7). This screen lists all of the WHS illness cases with filters to easily narrow down the list to pending cases, in progress investigations, and specific case or reference numbers.

Figure 4-7: DPR WHS Branch Illness Cases

To initiate an investigation, the WHS staff will click the Upload New Cases button. They will then specify one or more PDF files to upload. Each PDF file contains the documentation for


Page 89 of 132

a specific individual – when CalPEATS processes these files it will assign the PDF file name as the WHS Case #. All of the cases in a particular batch are assigned the first Case # as their Reference # so that they remain grouped as a single incident. WHS will also identify some basic information about the incident, including the date and time of the incident and the county where the incident took place. Each case also has a note field for WHS staff to keep remarks about the case.

Once a batch is uploaded, the WHS staff can assign some of all of the cases in the batch to a county for investigation. Using the filtering tools on the screen (most effectively by filtering on reference #), the user will narrow the display to just those cases to be assigned, then will select all the rows in the grid and assign them to the desired county. The individuals designated in the county setup as recipients of WHS notifications will receive an email telling them that new WHS cases were assigned to their county, and the cases will appear in the Outstanding Items area of their CalPEATS dashboard.

Once the investigation is underway, the county investigator can attach documents to specific Claimant/Injured Party records – if the record is associated with a WHS case # then the attachment will also be displayed when the user expands the display row for that case on the WHS Branch Illness Case screen. The WHS Branch staff will be notified when a document is added to a case in this manner.

When an illness case row is expanded to show subsequent documents, the WHS user can also attach new documents (or update documents they previously uploaded) to the case. If the case is already under investigation, then the county investigator will be notified of the new document. Otherwise, the designated county staff will be notified.

WHS staff can export the illness case data for fulfilling reporting requirements to the regional office and individual counties on outstanding illness cases. In addition, the export function can provide an import file should DPR build an automated import function for their web-based illness case database system. This export would pull in details from the closed investigation claimant/injured party records.


Page 90 of 132

5. Enforcement Component

5.1. Enforcement Component Overview

The Enforcement Component is a continuation of the Inspection and Investigation Workflows. Violations that are documented in earlier processes must be addressed via an enforcement response. Similar to investigations in that a large, central process enables county users to develop and document the outcome, it enables a county to address each and every violation via a variety of response actions.

5.2. Enforcement Response Workflow

The workflow for the CalPEATS Enforcement Response component, including all related Response Actions, is presented on Figure 5-1. A new Enforcement begins with a process to view outstanding violations from existing closed inspections and/or investigations and to select those to make up the enforcement response. The process will link those violation records into a new CalPEATS Enforcement Response record.

Much like the Investigations main process, the CalPEATS Enforcement Response will enable users to attach a variety of file types and enter related metadata. A Workflow log tracks upload actions, and provides a place for users to enter documentation in a Workflow log.

Each selected violation may be pursued “as is,” or the violation may be subdivided into separate subsections within the specific code section cited. County staff will enter a severity classification (A for Serious, B for Moderate, or C for Minor) to each violation.

Then, each violation can be assigned to a Response Action: Compliance, Enforcement, or Referral. A single action can deal with multiple violations, and a violation may appear in multiple response actions. As the county user creates and issues compliance, enforcement, and referral actions, the status of each violation is updated to reflect the actions taken. If a “closing” action (compliance action with decision report, compliance action with no decision report required, NOPA, or accepted referral) is taken, the user must use a “no further action” flag to close out the violation and provide an explanatory note.

As a function of the severity, only the possible actions will be available. Note: As per the Needs Assessment Report, “Compliance actions are always allowed for Class C violations, never allowed for Class A violations, and only allowed for Class B violations if the respondent has not committed any Class A or B violations during the previous two years.” These business rules will be programmed so that only allowable combinations of severity and Response Actions are displayed for each violation.


Page 91 of 132

Compliance Actions

Compliance Actions are used by counties for less severe violations. Once a Compliance Action record is created, the county determines the appropriate action: a Public Protection Action (such as Cease and Desist Orders), a Compliance Interview, a Warning Letter, or a Violation Notice. The orange shading on the “Order” and “Notice” documents indicates these are prepared outside of CalPEATS, but when issued are then uploaded and attached to the Compliance Action Record. Of the Compliance Action documents, only the Notice of Violation (NOV) is prepared as a fillable form (PR-ENF-101) in CalPEATS.

Following completion of a Compliance Action, a Decision Report (DR) is prepared (if required) for DPR review. The DR form (DPR-161) is generated as a fillable form via CalPEATS, and attached to the Compliance Action record. If accepted by DPR, the action is closed. If not, the county must then decide on another, more severe, Response Action for the violation(s).

Enforcement Action

Enforcement Actions are the most complicated workflow for Response Actions. Once an Enforcement Action is created, and the basic data is entered, a variety of processes ensue (as shown in the SRS workflow diagrams). CalPEATS, however, only has to track the statuses of the enforcement, including the preparation of a Notice of Proposed Action and the various possible following steps as stipulations, payments, hearings, decisions, and appeals move forward. Once the outcome is received and recorded, the county has the option to pursue an additional response. If the county does not pursue any further action, the enforcement action is closed for the related violations.

Referral Action

Referral response actions involve preparation of a “Case Packet” and presenting it to another agency to pursue. Referrals could go to the DPR or the SPCB for licensing infractions, or to the county District Attorney for civil or criminal actions. If the case is accepted, it is pursued by others and the outcome recorded by the county in CalPEATS. If the case is rejected, the county selects another Response Action for resolution.


Page 92 of 132

Figure 5-1: Enforcements Workflow


Page 93 of 132

5.3. Enforcement Response Statuses

The enforcement status diagrams are shown on Figures 5-2 through 5-5. The overall status diagram is Figure 5-2 for Enforcement Response. There are three statuses:

1. In Progress 2. Actions Pending 3. Closed – when all Response Actions have been completed and all violations are

closed

Explanations for the transitions are as follows:


Any county user can initiate an enforcement response once one or more violations have been determined.

Notify DPR (In Progress => Actions Pending)

Noting that the DPR has been notified that an Enforcement Action is being planned indicates that the Enforcement Response record is ready for their review, and that the county is moving on to processing response actions.

Close (Actions Pending => Closed)

The entire Enforcement Response can be closed only when every violation within the response record has been addressed and closed. This status change is managed automatically by the system based on the status of the response actions and violations contained in the enforcement response.


Page 94 of 132

Figure 5-2: Enforcement Response Statuses


Page 95 of 132

Figure 5-3: Compliance Action Statuses


Page 96 of 132

Figure 5-4: Enforcement Action Statuses


Page 97 of 132

Figure 5-5: Referral Action Statuses


Page 98 of 132

Compliance Actions The statuses are shown on Figure 5-3. Compliance Actions include both the steps to complete the actions themselves and then a Decision Report (if required).

Create Record (N/A => In Progress)

A Compliance Action record can be created for a violation when a severity has been assigned and the action is available for the assigned severity. A county determines if the Compliance Action is the best course.

Complete (In Progress => Closed)

The most appropriate (county-determined) action has been completed, allowing the county to set the status to complete. Once the compliance action is complete, the user must indicate if a Decision Report is required or not.

Decision Reports

If a Decision Report is required to justify pursuing no actions beyond a compliance action, the report must be prepared and submitted to DPR for review and approval.

DR Record Created (DR Required => In Progress)

County makes determination that a DR is required for the completed Compliance Action and creates a DR record.

Complete DR (In Progress => DPR Review)

County sets DR status complete and enables DPR review.

DPR Concurs (DPR Review => Closed)

DPR approves No Further Action and county closes the action.

DPR Rejects (DPR Review => Closed)

Although the Decision Report record is closed regardless of the DPR review outcome, a rejected decision report forces the violations in the original compliance action out of closed status. Therefore, the county must select another Response Action (Enforcement or Referral) for those violations.


Page 99 of 132

Enforcement Actions

The statuses for Enforcement Actions are illustrated on Figure 5-4.

Create Enforcement Action Record (N/A => In Progress)

The county creates an Enforcement Action Record and NOPA preparation is in-progress, outside of CalPEATS.

Issue NOPA (In Progress => NOPA Issued)

Actions outside of CalPEATS proceed with Respondent determining how to proceed. After the NOPA has been issued, a number of status transitions will occur depending on the path the NOPA takes to final resolution. These status transitions are accomplished simply by entering the date that a particular event happened (e.g., date hearing requested).

Final Decision and Order (NOPA Issued => Closed)

Once the CAC issues their final decision and order, the enforcement action is considered to be Closed. Additional changes to the final fines and administrative actions can be tracked through DPR and Superior Court appeals to properly record the final judgment, but the action is counted for PRAMR purposes once the final decision and order is issued.

Referral Actions

The third Enforcement Response Action is referral to another agency; a county may refer the response to DPR and SPCB for license infractions, or to the District Attorney.

The available statuses include referral request In Preparation, Agency Review, and Action Complete. The status diagram is shown on Figure 5-5.

Create Record (N/A => In Progress)

The county creates a Referral Action record in CalPEATS when a severity has been assigned and a referral action is available.

Submit Referral Request (In Progress => Agency Review)

County prepares Case Package (outside of CalPEATS) and submits to agency for review.

Agency Rejects Case (Agency Review => Closed)

County considers additional options in light of rejection


Page 100 of 132

Accepts Case (Agency Review => Pursuing Case)

Agency pursues case and records outcome.

Action Complete (Pursuing Case => Closed)

Case decided and county uploads documentation.

5.4. Enforcement Component User Interface Design

The Enforcement Component in CalPEATS is comprised of the following user interface screens:

o Enforcements Listing – Dashboard o Enforcements Listing – Details and Search o Enforcement Response Setup o Enforcement Response Home Page o Enforcement Response Attachments o Enforcement Response Work Activity Log o Compliance Action Details o Decision Report Details o NOPA Details o Referral Action Details o Accounts Receivable Summary

The following subsections describe the processes and user interface screens for starting enforcement responses, viewing/searching for enforcements, adding compliance/enforcement/referral actions, exporting enforcement data, querying/reporting on enforcements, and tracking enforcement and referral actions to completion.


Page 101 of 132

5.4.1. Viewing/Searching for Enforcements

Enforcement information is listed in four ways in CalPEATS:

x Enforcement Responses

x Violations

x Decision Reports (for DPR EBLs)

x Accounts Receivable

The enforcements dashboard page shows a quick list of open enforcement responses, a summary of violations that have been noted on inspections or investigations that have not yet been pulled in to an enforcement response, a list of decision reports awaiting review (for DPR users), and list of outstanding accounts receivable (unpaid fines). More detailed list/search screens are available for each of the four dashboard views.

Enforcement Responses

The Open Enforcements listing on the enforcements dashboard shows (by default) all open enforcement responses relevant to the user. In this case, “relevant” means:

x For county users, any enforcement response they own that contains open actions and/or violations that have not been addressed.

x For DPR users, any enforcement response which has been marked as “Initially Complete”. This flag indicates that the initial enforcement response information has been entered and reviewed, and is equivalent to the delivery of the opening ECAS (Enforcement/Compliance Action Summary) for a NOPA. Note that within an enforcement response record, DPR users will only see closed/completed action items.

The two filter settings available for county users are “Whose Enforcements” and “Enforcement Status” (Figure 3-7). These filtering controls will operate as follows:

x Whose Enforcements: o My Enforcements – displays enforcement responses that belong to the

current user. o All Enforcements – displays all enforcement responses the current user has

access to.

x Enforcement Status o Open Enforcements – displays only enforcement responses that are open,

either because they have pending compliance/enforcement/referral actions or because they contain violations that have not been addressed.

o All Enforcements – displays all enforcement responses the current user has access to.


Page 102 of 132

The tabular listing of enforcement responses will provide a display showing top-level information about the enforcement response. The information displayed will include:

x County/County Contact (DPR users only)

x Response ID #

x Incident Date

x Date Response Initiated/Closed

x Date DPR Notified (if Enforcement Action is taken)

x Respondent Firm/Person Name

x Status

x A link to open the Enforcement Response Home Page

The enforcement responses will be sorted first showing open responses then closed responses. Within each group, the responses will be sorted by the date they were initiated, oldest first.

The more detailed version of the enforcement response listing screen will operate in two user-selectable modes. In the Grouped mode (Figure 5-6), the display will include a grouping container plus details about each response action taken.

x The grouping container shows the enforcement response details: o Response ID # o Investigator o Incident ID (Inspection or Investigation) o Incident Date/Time o Date Response Initiated/Closed o Date DPR Notified (if Enforcement Action is taken) o Respondent Firm/Person Name and Address o Status

x Within the grouping container, after the top-level details, each compliance/enforcement/referral action will be displayed in order of the date they were added to the enforcement response. The details displayed depend on the action type. Each action listing will include a link to open the detail page for that action.

o Compliance Actions: � Type � ID Number


Page 103 of 132

� Status � Decision Report ID # � Action Date

o Decision Reports: � Type � ID Number � Status � Decision Report ID # � Action Date � DPR Review Date

o Enforcement Actions (NOPAs): � Type � ID Number � Status � Decision Report ID # � Action Date � DPR Notification Date � NOPA Status (narrative describing current status of NOPA, response,

hearings, appeals, and fine payments) o Referral Actions:

� Type � ID Number � Status � Decision Report ID # � Action Date

Additional filtering and sorting options will be provided in this view:

x Filtering: o County (DPR users only) o Incident Date (date range) o Enforcement Response Status (multiselect) o Investigation Case # (wildcard text search) o Inspection ID # (wildcard text search)


Page 104 of 132

o Code Section Violated (wildcard text search) o Respondent Name (wildcard text search) o Respondent License/Permit # (wildcard text search) o Product Label Number (wildcard text search) o Product Name (wildcard text search) o Setting (multiselect) o Activity Type (multiselect) o Comments (wildcard text search) o Compliance Action Type (multiselect) o Decision Report In Progress/In Review/Approved/Rejected (multiselect) o NOPA Includes ACP/SCP/Administrative Actions (multiselect) o Hearing Requested/Scheduled/Completed (multiselect) o Referral Agency (multiselect)

x Sorting o County (DPR users only) o Response Initiation Date o Response Closed Date o Enforcement Response ID # o Incident Date o Respondent Firm/Person Name o Decision Report Signed Date o Decision Report Approved Date o NOPA Issued Date o Referral Date

The second display mode is the “Flat” mode (Figure 5-7) that eliminates the grouping mechanism and displays all enforcement responses combined with compliance/enforcement/referral actions in a flat tabular view. The Flat mode will include the same additional filters as the Grouped mode, but sorting will be available on each column in the tabular display. Also available in Flat mode will be a listing of all available columns from which the user can customize and save their desired table setup.

From either Grouped or Flat display mode users with appropriate privileges can delete In Progress enforcement responses, provided that the enforcement response does not contain any closed/completed actions. All associated records will be deleted along with the


Page 105 of 132

enforcement response record. The user will be prompted multiple times to confirm the delete action.

Figure 5-6: Enforcement Detail Listing – Grouped


Page 106 of 132

Figure 5-7: Enforcement Detail Listing – Flat

Violations

In addition to ongoing enforcement responses, county users will need to know about violations that have not yet been pulled in to an enforcement response. This Outstanding Violations list will include any violation identified on an inspection or investigation where there is no existing enforcement response that includes that violation. In most cases, an enforcement response will include all violations on the associated inspection or investigation; however, in cases where a single inspection or investigation results in enforcements against multiple parties the violations will be split between multiple enforcement responses. Where other such examples exist, CalPEATS will allow the user to organize the violations and enforcement responses in any manner they wish. The outstanding violations listing will include (Figure 3-7):

x Inspection Number/Investigation Case Number

x Firm/Person Inspected (if violation came from an inspection, first listed respondent for violations on Investigations)

x Violation Date (inspection date or date of incident from investigation)

x Enforcement Response ID

x Code Section/Title

x Severity (if assigned)

x Response Actions Taken

The more detailed Violations listing page will include the following additional fields for each violation:

x Final Disposition Type

x Final Disposition Date


Page 107 of 132

x Violation Notice ID #

x Decision Report ID #

x NOPA ID #

x Referral ID #

The detailed violations display can be filtered and sorted as follows:

x Filtering: o Code Section (multiselect) o Violation Date (date range) o Origination Type (inspection or investigation) o Origination ID (wildcard text search) o Firm/Person Inspected Name (wildcard text search) o Alleged Respondent Firm/Person Name (wildcard text search) o Severity Classification (multiselect) o Final Disposition Type (multiselect) o Violation Notice ID #/Decision Report ID #/NOPA ID #/Referral ID #

(wildcard text search on all four fields)

Violations are attached to their originating inspection or investigation; therefore, users will not be able to add or delete a violation from this page.

Decision Reports Awaiting Review

The third component in the enforcements module displays is a listing for DPR EBLs of the Decision Reports awaiting their review. Because of the specific nature of this listing, only the dashboard summary view is provided – if DPR users wish to search and view more detailed decision report data they will be redirected to the Enforcement Response Details listing in Flat mode using the Decision Report filter.

The Decision Report dashboard view shows all Decision Reports in any of the counties assigned to the EBL that are in DPR Review status. The display will include:

x County

x Decision Report ID #

x County Submittal Date

x Code Sections Violated and Severity Classifications

x Justification Type

x Review Age (number of days since DR was submitted)


Page 108 of 132

The records will be sorted by Review Age in descending order (oldest first). The user can open the Decision Report detail page using the view button on each row.

Accounts Receivable

The fourth and final component in the enforcements module displays focuses on the status of fines that have been levied by the County. This screen lists all NOPAs that have outstanding amounts due, sorted by receivable age (number of days since fine became due and payable). The table includes the following fields:

x Enforcement Response ID #

x NOPA ID #

x Respondent Firm/Person Name

x Fine Type (ACP/SCP)

x Decision Type (stipulation, closed no hearing, upheld at hearing, modified at hearing, etc.)

x Fine Amount

x Due Date

x Date Paid In Full (will display “PP” if payment plan)

x Payment Plan Listing (dates/amounts for payments received, future due dates)

Two filter settings will be available: “Whose Enforcements” and “Payment Status”. These filtering controls will operate as follows:

x Whose Enforcements: o My Enforcements – displays enforcement responses that belong to the

current user. o All Enforcements – displays all enforcement responses the current user has

access to.

x Payment Status o Outstanding – displays only enforcement responses that have payments still

due. o All – displays all enforcement responses the current user has access to.

From this screen, the user can click the View button to go to the Enforcement Response Home Page, or (if they have appropriate privileges) they can click “Edit” to enter information for a new payment received.


Page 109 of 132

5.4.2. Starting an Enforcement

There are two ways to start an enforcement response in CalPEATS: 1. From a closed Inspection record that contains outstanding violations. A button on

the Inspection Home Page for a closed inspection will begin this process. The user will be prompted to select which of the people/businesses identified on the inspection record will become the respondent on the enforcement response, as well as which violations and products to carry forward to the enforcement response record (Figure 5-8).

2. From a closed Investigation record that contains outstanding violations (i.e., violations that have not been linked in to another enforcement response). A button on the Investigation Home Page for a closed investigation will begin this process. The user will be prompted to select one of the alleged respondents who will then become the respondent for the enforcement record. In addition, the user will select which violations and products will be carried forward to the enforcement response (almost identical to the screen used for an inspection as described above).

After saving the initial enforcement response setup, the system will display the Enforcement Response Home Page (Section 5.4.3).

Figure 5-8: New Enforcement Response From Inspection


Page 110 of 132

5.4.3. Enforcement Home Page

The Enforcement Response home page in CalPEATS shows the top-level setup information for the response, followed by a listing of all the actions taken within the context of the enforcement response (Figure 5-9). The response-level information includes:

x County and county contact (for DPR users)

x Initiation date/time, closure date/time

x DPR Notification Date (for NOPAs)

x Record owner

x Status

x Date/time of incident

x Inspection ID# or Investigation Case #

x Respondent: o Type o Firm/Person Name o Employment Sector o License or Permit Number with Expiration Date o License Categories o Physical and Mailing Addresses

x Products: o Name o Label Number o Signal Word

x Setting

x Activity Type

x Comments

x Attachments

x Violations: o Code Section o Severity Classification o Response Type(s)

x Work Activity Log


Page 111 of 132

When the user has specified the initial DPR Notification date to indicate that the response record should be made available to their DPR EBL for initial review, the EBL will be notified via email.

Figure 5-9: Enforcement Response Home Page

The violations display area in the enforcement response header information shows the details about each violation that is being addressed in the enforcement response. The violations are displayed in a matrix format, with columns to indicate which types of actions were taken for each violation. As response actions are added to the enforcement response, they are linked to specific violations and the violations matrix is updated to show the associated actions.

Violations at this stage can be broken out into more detailed subsections than the citable section numbers/titles given in the originating Inspection or Investigation. The user can


Page 112 of 132

use the Manage Violations to manage the linkages between the violations listed on the original Inspection/Investigation and those handled in the current Enforcement Response, and can use the Split and Merge icons on each original violation row to either create more collapse additional detail for the purpose of tracking specific fines and actions written into the NOPA.

This process of splitting or merging details based on the original violations noted is different than selecting a new code section to enforce during the preparation of the response actions. For example, if the enforcing officer decides to enforce a violation against the employer under a more general employer due diligence clause than the original violations (which were cited against code sections requiring employees to wear PPE for example), the enforcing officer should go back to the original Inspection or Investigation and add the new code section violation in that originating record. The Manage Violations can then be used to pick up the new violation code section and add it (along with remarks, etc) to the enforcement response package.

To “close out” a violation, one of several options must be used:

x The violation is associated with an approved decision report.

x The violation is associated with a closed NOPA, and was included in the final decision (i.e. the specific violation was not rejected at hearing and dropped from the CAC final decision).

x The violation is associated with a closed referral action.

x The violation is associated with any compliance action, and the user selects “No Decision Report Required” in the violations matrix.

x The violation has no actions associated with it, and the user selects “No Further Action” in the violations matrix.

Once all of the violations in an enforcement response are closed out, the enforcement response record will automatically move to the Closed status. Additional information can still be entered into a Closed enforcement response for the purpose of tracking administrative actions, fine payments, and the disposition of referred cases.

Below this, the screen displays the Compliance Actions, Decision Reports, Enforcement Actions, and Referral actions that are part of the enforcement response. Each of these is discussed in more detail below.

Compliance Actions

Within an enforcement response, the user can create compliance action records representing Public Protection actions, Compliance Meetings, Warning Letters, and Violation Notices. Each compliance action must be specifically tied to one or more of the violations defined in the enforcement response. A single violation may have multiple compliance actions taken – for example, the county may conduct a compliance meeting that


Page 113 of 132

covers a violation, and later they may issue a warning letter for the same violation depending on the outcome of the meeting.

The CalPEATS enforcement response home page will list all of the compliance actions taken within the context of the enforcement response. As each compliance action is taken, the violations grid will be updated for the related violations to indicate that a compliance action was taken. When the compliance action is complete, the user will be prompted as to whether the violation will proceed to a NOPA, and if not whether a Decision Report is required before closing out the violation. The following information will be displayed on the corresponding detail screen for each compliance action:

x ID #

x Type

x Status

x Violations Addressed

x Explanatory Statement

x County Preparer

x Date Signed by Preparer

x Date Signed by Respondent

x Decision Report ID # (or “Not Required”)

Tracking for compliance actions will include the initiation date/time, completion date/time, attachments for any letters or other documentation generated.

Decision Reports

When a county determines that a Civil Penalty fine will not be levied on a violation where the regulations permit a fine, the county must document the rationale for not pursuing a fine to DPR. The decision report is the mechanism for documenting and submitting that rationale for review by their EBL. The county user will create a decision report record, indicating which violations are included in the decision report document. Once the document is complete, the user will upload the document to CalPEATS and mark it as ready for DPR review. The DPR EBL for the county will use the Decision Reports screen to indicate the result of their review, either pushing the report back to the county for modifications/edits or accepting the report as written. Once the report is accepted by DPR, the associated violations are closed and no additional documentation is required for them.

If DPR does not concur with the decision report, the county may revise and resubmit the report, or they may withdraw the decision report (or simply leave it in Denied status), in which case an alternative mechanism must be used to close out the associated violations.


Page 114 of 132

The following information will be displayed on the corresponding detail screen for each decision report:

x ID #

x Compliance Action ID #

x Status



x Compliance History Narrative

x Justification Type

x County Preparer

x Date Preparer Signed

x Date DPR Signed

x Approved/Denied

x Reviewer Comments

The DPR signature date, approved/denied flag, and reviewed comments will only be editable by DPR users.

Enforcement Actions

Enforcement actions are more complex than compliance actions, and comprise a series of documents exchanged between the county, the respondent, DPR, and potentially the courts. The process always begins with a Notice of Proposed Action (NOPA) that the county sends to the respondent notifying them of the proposed action. The actions that can be taken include Agricultural Civil Penalties (APCs), Structural Civil Penalties (SCPs), and Administrative Actions including Revocation/Denial of a Restricted Materials Permit, Revocation/Denial of Registration of a statewide license, and Revocation/Denial of a Private Applicator Certificate.

Agricultural Civil Penalties and Structural Civil Penalties (ACPs and SCPs) are tracked for each violation cited in the NOPA. On the NOPA detail screen, the user should keep track of the proposed fine types and amounts, as well as the final disposition of each fine in the Final Decision and Order, or after appeals/court cases as appropriate. If a fine is modified after the initial proposal the user should indicate the basis for the modification (modified, rejected, withdrawn). If a violation is eliminated from the final action altogether, the user should un-check the Final box for that violation so the system will put that violation back on the open list.

The package of enforcement documents and actions is handled as a single Enforcement Action record in CalPEATS. The user will create a new NOPA, indicating which of the


Page 115 of 132

violations in the enforcement response they are addressing with the NOPA. The NOPA preparation screen is shown in Figure 5-10.

Once the NOPA is issued, the documents and dates that are tracked depend on the response from the respondent. If the respondent stipulates to the NOPA, then CalPEATS will track the dates when the fines are paid and/or the administrative actions are completed. If the respondent fails to respond within the 20-day timeframe (plus any grace period offered by the county), the system will track the CAC Decision and Order, the demand for payment, and the dates when the fines are paid and/or the administrative actions are completed. If the respondent requests a hearing, the system will track the hearing dates and outcome (including any modifications to fines or administrative actions), and then the dates when the fines are paid and/or the administrative actions are completed. Note that the CAC Decision and Order following a hearing may or may not adopt the recommendations of the hearing officer – CalPEATS tracks the fines and administrative actions issued in the CAC Decision and Order.

If the respondent appeals the hearing, the system will track the appeal dates and outcome (including any modifications to fines or administrative actions), and then the dates when the fines are paid and/or the administrative actions are completed.

In some cases, the county may agree to a payment schedule – CalPEATS will track the payment due dates and amounts as well as the dates and amounts received.

For the purpose of closing out a violation, the enforcement action is considered closed when the CAC issues the Decision and Order. At that point, the enforcement action will count on the PRAMR report and the violations associated with the NOPA will require no further action. If specific violations have been rejected during the hearings or appeals process, the county must update the NOPA record to indicate that those linked violations were not included in the final Decision and Order so that they may be addressed by another action within the enforcement response.


Page 116 of 132

Figure 5-10: NOPA Detail Page


Page 117 of 132

Information that is tracked for an enforcement response includes the following:

x ID #

x Status



x Proposed and Final ACP/SCP/Administrative Actions

x County Preparer


x Date Mailed – Certified Mail

x Date Received by Respondent – Certified Mail

x Date Mailed Regular Mail

x Date Assumed Received by Respondent – Regular Mail

x Response Type

x Response Date

x Dates Hearing Scheduled/Held

x Hearing Officer Decision

x Hearing Officer Remarks

x Dates Appeal Scheduled/Completed

x Appeal Officer Decision

x Appeal Officer Remarks

x Appealed to Superior Court?

x Date CAC Decision and Order Issued

x Violations Addressed in Decision and Order

x Date Respondent Stipulated

x Date Closed by Decision

x Fine Payment Scheduled Amounts/Dates

x Fine Payment Receipt Amounts/Dates

x Date Administrative Actions Completed

The NOPA listing screens will compress this information down to a matrix format that provides a quick reference to the status of each NOPA record (Figure 5-7, filters set to display NOPAs only and columns set for NOPA fields).


Page 118 of 132

Referral Actions

Within an enforcement response, one or more of the associated violations may be referred to an outside agency for enforcement. The Referral Action records in an enforcement response will track the following information:

x ID #

x Status

x Associated Violations


x Referral Agency

x County Preparer


x Date Referral Accepted

x Case Closure Date

x Case Outcome Narrative

x Amount of Fines Paid

x Fines Paid Date

As soon as a referral action is accepted by the referral agency, the associated violations are considered closed out.


Page 119 of 132

6. Activity Tracking Component

6.1. Activity Tracking Overview

The activity tracking component in CalPEATS serves two purposes – it provides a mechanism for staff and managers to see inspection activity within a county or EBL county area compared to goals and targets set up by the county or DPR; and it also provides detailed data to DPR to replace the existing Pesticide Regulatory Activity Monthly Report (PRAMR).

6.2. Inspection Activity Goals

Both County inspectors and DPR EBLs are responsible for conducting pesticide inspection activities. Each county develops a Work Plan in concert with DPR to set the expected level of inspection activity and to establish goals for the county inspection program. Similarly, each EBL works with their manager to establish expectations for their oversight inspection activity. In many cases, these plans/expectations do not establish specific numerical targets for each inspection type, but the county management team or DPR regional manager may set up specific targets to help manage their work load.

In CalPEATS, county users with appropriate privileges can establish targets for each inspection type/subtype. These targets can be specified countywide, in which case the only metrics reporting view will be countywide activity. Alternately, the county may establish targets by district, in which case the management staff can view progress against the goals by district and rolled up to the county level. Finally, a county may establish individual goals for each inspector, in which case inspectors can view their own metrics tracking, and managers can view metrics rolled up by district (if districts are used in their county) and countywide.

EBLs can also use this feature to set up their own tracking numbers by inspection type and subtype. For DPR, this functionality is limited to individual EBLs.

6.3. PRAMR Data Entry

The PRAMR tracking component in CalPEATS will use a combination of CalPEATS inspection, investigation, and enforcements data, permitting, licensing, and registration information from CalAgPermits, and additional information entered by county users in CalPEATS to track and report all of the data currently reported through the paper PRAMR form. The SRS lists all of the required data elements and describes their origin.

For monthly activity hours, notices of intent reviewed/denied, and restricted materials permit applications denied, the user will use the PRAMR Monthly Data Entry screen (Figure 6-1). At the beginning of each calendar month, the system will automatically append a new month column to the data entry screen. The designated county PRAMR entry person will then enter values for all cells in the column, and (when the data have been reviewed and


Page 120 of 132

approved), will mark that month as complete. The data may be re-opened and edited at any time up until the closing date for the fiscal year – the purpose of marking the data as complete for a specific month is to make that month’s data available to DPR.

Once the PRAMR Fiscal Year is marked as closed, the counts that were dynamically generated from the CalPEATS and CalAgPermits databases will be saved to a PRAMR table and no longer generated on the fly. This is to prevent loss of PRAMR data when counties purge the original inspection/investigation/enforcement records according to their data retention policy.

The counts of Training and Outreach sessions and attendees will be derived from records entered for each session conducted by the county. The Training and Outreach Session screen (Figure 6-2) lists all prior sessions entered by the county and includes the following fields:

x Title

x Session Date and Time

x Duration

x City

x Topic

x Audience Type

x Number of Attendees

x Languages

x C.E. Credit Hours

x Attachments (scanned attendee list, presentation file, etc.)

The training and outreach list can be filtered/sorted as follows:

x Sort By: o Title o Date/Time o City o Topic o Audience Type

x Filter By: o Date (date range) o City (pick list) o Topic (wildcard text search)


Page 121 of 132

o Audience Type (pick list) o C. E. Credit Hours (yes/no)

The number of sessions and attendees on the PRAMR report will be queried dynamically from these training and outreach sessions.

6.4. PRAMR Data Analysis and Reporting

The primary mechanism in CalPEATS for viewing PRAMR data is a spreadsheet-style view (as opposed to the current PRAMR paper form). The PRAMR review screen is accessible to county and DPR users and can be set to display:

x Monthly data for a single fiscal year and county: o Rows are PRAMR categories. o Columns are months. o Rightmost column shows totals for the fiscal year. o Second row shows whether county has approved that month. o User can choose to view all PRAMR categories or only categories entered

manually.

x Fiscal year totals for multiple fiscal years for one county. o Rows are PRAMR categories. o Columns are fiscal years. o No totals column. o Second row shows whether county has closed that fiscal year. o User can switch to “Inspections Only” view, and can then switch between raw

counts and comparisons to goals. In comparison mode, each cell displays the goal and then the actual number completed.

x Fiscal year totals for a single fiscal year for multiple counties (DPR only). o Rows are PRAMR categories. o Columns are counties. o Rightmost column shows totals for all counties. o Second row shows whether county has closed the selected fiscal year. o User can view raw counts, or can switch to “Prior Year Comparison” mode

that displays the percentage increase or decrease from the prior fiscal year in each cell.

Figure 6-3, Figure 6-4, and Figure 6-5 show the design of the PRAMR data review screen in the three modes mentioned above.


Page 122 of 132

Figure 6-1: PRAMR Monthly Data Entry

Figure 6-2: Training and Outreach Entry


Page 123 of 132

Figure 6-3: PRAMR Monthly Review


Page 124 of 132

Figure 6-4: PRAMR Fiscal Year Review


Page 125 of 132

Figure 6-5: PRAMR Multi-County Review

A more detailed view of the data which shows monthly data for a single fiscal year for multiple counties is available as an Excel export for DPR users. In this export file, each county is shown on a different tab, with a summation tab for the whole state at the end.

Users can also generate a copy of the current PRAMR paper form as a filled PDF file for any selected month or fiscal year (and selected county for DPR users).


Page 126 of 132

7. System Administration

7.1. User Control – Roles and Permissions

CalPEATS offers a fine-grained permissions system wherein the record types and activities available to a specific user can be highly customized. In order for a user to perform a function (view, edit, delete, etc.) on a record, two questions must be answered:

1. Does the user have access to the record type based on the record owner and status? 2. Can the user perform the desired function on that record, again based on the record

ownership and status?

The rules around the first question were described in Section 2.3. The rules applicable to the second question are presented in Table 7-1. This table does not necessarily specify the answer to the question – it may only specify that the user must be granted permission by the County Application Administrator via a defined user Role. To interpret the table, first locate the row that corresponds to the record type, status, and operation. Then find the column that describes the relationship between the user requesting the activity and the record owner. Then interpret the table cell contents:

x Y – by default the user has permission. There is no specific role-based permission that the CAA can administer for this request.

x P – a specific role-based permission exists for this request. If the user has been granted that permission then they can execute the request.

x N – no specific role-based permission exists for this request. The user can not perform the action requested.


Page 127 of 132

Table 7-1: Default and Configurable User Permissions in CalPEATS ALL DPR ONLY ALL

Record Type Status Operation Owner Super-visor

Within County

Assigned Counties

DPR Region

State Wide Granted

Investigation

Create N N P N N N N Investigation In Progress View Y P P N N N P Investigation In Progress Edit Y P P P* P* N N Investigation In Progress Delete Y P P N N N N Investigation In Progress Complete Y P P N N N N Investigation In Progress Reassign P P P N N N N Investigation In Progress Grant DPR Access P P P N N N N Investigation In Review View Y P P N N N P Investigation In Review Edit N N N P* P* N N Investigation In Review Revise Y P P N N N N Investigation In Review Review N P P N N N N Investigation Closed View Y Y P P P P P Investigation Closed Edit N N N P* P* N N Investigation Closed Reopen N N P N N N N Inspection

Create N N P N N N N

Inspection In Progress View Y P P N N N N Inspection In Progress Edit Y P P N N N N Inspection In Progress Delete Y P P N N N N Inspection In Progress Finalize Y P P N N N N Inspection In Progress Reassign P P P N N N N Inspection In Review View Y P P N N N N Inspection In Review Revise Y P P N N N N Inspection In Review Review N P P N N N N Inspection Closed View Y Y P P P P P Oversight Inspection

Create N N N P N N N

Oversight Inspection In Progress View Y P N P P N N


Page 128 of 132

ALL DPR ONLY ALL


Within County

Assigned Counties

DPR Region

State Wide Granted

Oversight Inspection In Progress Edit Y P N P P N N Oversight Inspection In Progress Delete Y P N P P N N Oversight Inspection In Progress Finalize Y P N P P N N Oversight Inspection In Progress Reassign P P N P P N N Oversight Inspection In Review View Y P N P P N N Oversight Inspection In Review Revise Y P N P P N N Oversight Inspection In Review Review N P N P P N N Oversight Inspection Closed View Y Y N Y Y Y N Enforcement Response

Create N N P N N N N

Enforcement Response In Progress View Y P P N N N N Enforcement Response In Progress Edit Y P P N N N N Enforcement Response In Progress Delete Y P P N N N N Enforcement Response In Progress Reassign P P P N N N N Enforcement Response DPR Notified View Y P P P P P N Enforcement Response Closed View Y Y P P P P P Compliance Action Complete View Y P P P P P N Decision Report In DPR Review View Y P P P P N N Decision Report In DPR Review Review N N N P P N N Decision Report Approved View Y P P P P P N Enforcement Action Issued View Y P P P P P N Enforcement Action Closed View Y P P P P P N Enforcement Action Closed Edit Y** P** P** N N N N Referral Action In Progress View Y P P N N N N Referral Action Complete View Y P P P P P N PRAMR In Progress View N N P N N N N PRAMR In Progress Edit N N P N N N N PRAMR In Progress Finalize N N P N N N N


Page 129 of 132

ALL DPR ONLY ALL


Within County

Assigned Counties

DPR Region

State Wide Granted

PRAMR Final View N N P P P P N PRAMR Final Revise N N P*** N N N N Training/Outreach Sessions

Create/Edit/Delete N N P*** N N N N

Training/Outreach Sessions

View N N P P**** P**** P**** N User Admin

All N N P N P P N

Role Admin

All N N P N P P N County Lookup Tables

All N N P N N N N

DPR Lookup Tables

All N N N N N P N County/DPR Settings

All N N P N N P N

Data Exchange

All N N P N N N N Exception Reports All N N P N N N N Granted Means:

Counties granting access to other counties DPR automatically granted access to priority investigations in progress

Top categories:

Am I the owner of the record? Is the record owned by a user in my county? Is the record owned by one of the counties assigned to me? Is the record owned by a county in my region? Is the record owned by any county in the state? Has my organization been granted access to the record by the owner?

Footnotes:

* - editing only enabled for DPR fields on priority investigations (PENR date, 15-day update date, Completion Report date, notifications) ** - editing on closed enforcement actions is limited to tracking post-closure activity (fines paid etc.) *** - PRAMR data can not be revised after the fiscal year end close date **** - training/outreach sessions can be viewed by designated DPR personnel after the associated PRAMR month is finalized by the county


Page 130 of 132

For example, a DPR EBL wants to view an in-progress investigation owned by a county user in one of their counties. We locate the second row in the table (Investigation, In Progress, View), then proceed to look at the relationship between the EBL and the investigator:

x Is the EBL the record owner? NO

x Is the EBL the supervisor of the record owner? NO

x Is the EBL in the same county as the record owner? NO (the EBL may be assigned to that county but their user “county” is DPR)

x Is the owner county within the counties assigned to the EBL? YES – however there is no user permission that would grant the EBL access to the record so continue

x Is the owner county within the EBL’s assigned DPR Region? YES – but again no permission exists that would grant access so continue

x Is the owner county part of the statewide DPR network? YES, but again no permission exists that would grant access so continue

x Has the EBL been granted access to the specific investigation record? MAYBE – we can examine the investigation record to see if this is so. In the notes for the Granted column we see that an “automatic” grant exists for priority investigations, so if the investigation is a priority or the county has specifically opened the investigation to DPR then we can proceed to determine if the EBL user has the required permission or not.

From Table 7-1, we can derive the list of settable permissions by including every cell that contains a P. These permissions are listed on the User Roles management screen, where the CAA can define as many roles as desired. Each role has a short name, a list of the assigned permissions, and a comments field.

7.2. User Credentials

Each user who accesses CalPEATS must have a unique user record, identified by their user id and password. Each user account is assigned to one or more counties or to DPR. DPR users may have counties assigned to their account for oversight purposes, but their account itself is not assigned to those counties. In some cases, county users may be assigned to more than one county – those users will have to select a county to work on after logging in to CalPEATS. For those users, their other assigned counties will appear as if they had granted access to the users’ currently selected county (i.e., closed records will be viewable). To edit records in a different county, the user will need to switch their currently selected county.

The following security rules will be implemented for CalPEATS:

x Passwords must be 8 characters or more.

x Passwords must contain three of the following: lower case letters, upper case letters, numbers, standard symbols.


Page 131 of 132

x Three invalid password entries in a 10-minute period will result in the user account being locked. It will automatically unlock in 24 hours, or can be unlocked by the CAA or technical support team.

x Users will be required to select and answer three security questions. To reset their password, they must enter their user id and correctly answer two randomly selected questions – they will then be sent a link via email to their registered email account to reset their password.

x Clear-text passwords are not available through CalPEATS. The system encrypts the user passwords with a one-way encryption technique before storing them. There will be no mechanism to display a users existing password.

Although it is desirable in the future to implement a single sign-on system for CalAgPermits and CalPEATS (and other similar county software systems), creation of such a system is not currently in scope. However, to alleviate confusion for users of both systems a user record in CalPEATS can be flagged as a CalAgPermits user. Such users will still need to have their CalPEATS roles and permissions set up through he CalPEATS user management screens, but their password will be validated against CalAgPermits. While the user will still have to enter the password separately when logging in to CalPEATS and CalAgPermits, they only have to manage and remember one password. CalPEATS will require direct access to the CalAgPermits database to support this feature – such access is already contemplated for other data sharing between the two systems.

7.3. User Profile Management

The Welcome control displayed on the CalPEATS home page allows each user to manage their user profile. Functions available to users include:

x Change password (if they are flagged as a CalAgPermits user this will change their password in CalAgPermits).

x Answer/update security questions.

x Update email address.

x Modify components to display on dashboard.

x Clear memorized column lists.

7.4. County Settings

Each county (and DPR) will have several data elements that can be set up and/or configured for their users. This section will continue to grow as new configuration settings are determined to be appropriate. The settings currently envisioned are:

x Work Plan Goal Tracking Basis – counties can indicate if their work plans goals are specified on a Calendar Year or Fiscal Year basis. If Fiscal Year, the Fiscal Year will be assumed to run from July 1 through June 30.


Page 132 of 132

x WHS Notifications – a list of users who are designated to receive notifications from the DPR WHS Branch staff regarding new cases to be investigated.

x N/A Explanations – each county can determine if they want their inspectors to be prompted for explanations for each N/A selected on an inspection form.

x Additional Ordinances/Regulations – counties can create citable section records for county-specific requirements and indicate the inspection types/subtypes on which they should be included by default.

x Work Plan Targets – counties can indicate for each fiscal year what their target inspection counts are by inspection type/subtype. This can be done for each inspector, by district, or just county-wide.

x Districts – counties maintain their own reference list of district codes and names to be used for tracking work plan goals and for identifying “relevant” records for a given user.

$0.+12'32.&'$!-44+55+-/6.5$&/7$#6&'6.5$55-1+&3 · Assessment Report and a detailed System...

Documents

Transcript of $0.+12'32.&'$!-44+55+-/6.5$&/7$#6&'6.5$55-1+&3 · Assessment Report and a detailed System...