Descripition:
Summary web page screen showing all certificate applications, ability to filter, sort and search through the data to find what they are looking for, no advanced reporting capabilities

Tasks:

• Create design/wireframe for summary view
• Create a screen for all submitted applications, apply paging, select # of records per page
• Show the fields listed in the AC below
• Ability to sort by the fields listed, route back to server for long term solution
  sort by expiration date, employer name, main establishment state, cert effective date
• Filter by the following fields:
  cert status, cert type
• Free text search across fields listed below:
  employer name
• Count of all records that come back from sort/filter
• model the following fields: Certificate Effective Date, Certificate Expiration Date, Certificate Status and Certificate Number
• Back end work to create the appropriate aggregate grouping, new data model, group all aplications by EIN, most recent application which will already have the main establishment, doing the counts on the worksites
• Test Coverage to 90%

Old Description:*******
Evaluate wage rates to be better informed for policy and procedures
Geographic analysis
Not a set of canned reports, more like a web page on admin interface with capabilities to view and filter

Report what DoL does on their website will be routinely pulled

Initial requirements - simple capabilities
Advanced requirements - maybe more canned reports and searching capabilities

Access to high level statistics.
*****End Old Description

AC: Ability to view all certificates sorted, filtered and/or searched by the fields identified above in the Tasks section. Summary view will include all of the following fields: Certificate #, employer name, cert effective date, cert expiration date, cert status, # of workers, cert type (CRP, hospital, SWEP, business), initial/renewal?, # of work sites, main establishment state

Descripition:

Tasks:

• Task 1
• Task 2
• Task 3
• Task 4

Acceptance Criteria:

Requirements:
UX Design/Assets
Collection of Data, basic version section by section
Follow physical form flow and data requirements
Proposed WH226.pdf
Proposed WH226A.pdf

Acceptance Criteria:
PO review and approval of designed Wireframes on 226/a forms

See if investigator, can automatically retrieve their applications, read only view no edits, can see diary records view only

Search by EIN to pull what they need, not automatically assigned

Liz - will map out section by section compliance links

Acceptance Criteria - defined by mapping and associated to each section as being filled out by applicant

Descripition:
Applies to detail view of application after clicked from summary view

Tasks:

• Design/wireframes for front end
• Front end dev of design/wireframes - following wireframes (UPDATED LINK 11/14) - https://app.atomic.io/d/7wkCldPvw5K2?page=afc9eab6-2ba9-4663-a59e-d3569060cfe7
• Back end use existing controllers, api

Acceptance Criteria:
Ability to view submitted application and data associated with that application. Design/wireframes similar to web forms and front end design along the lines of #59.

Considerations:

1. Application Status
2. Role

Descripition:
Submission done in user story #8, certificate status created in data model in #7, this user story would consist of setting the certificate status field to pending on submission from story #8
Applications should automatically be in "pending" status after the employer submits the application.

Tasks:

• Back end set certificate status on submission to Pending

Acceptance Criteria: As applicant submits a completed application the system sets the certificate status to pending
Considerations:

1. Application Status
2. Role

Card #2 is specifying that individual fields have parameters to improve/ensure accuracy (standardized formats for dates, wages, zip codes, phone numbers, etc.) cc: @elizabethstriegel

Access to certificate team in addition to investigators and other WHD users, team Manager and team member

search across all diary sheet logs to search, helpful canned search drop down of common violations
Liz to provide possible violations list, look into violation letters to possibly attach to diary, what can we do to help automate manual process and data collection

Enforcement database separate to form application, communication to pull information from WHISARD, tied by EIN information, data issue on EIN maybe so backup on name and other linking criteria.

Lookup validation check on EIN agaisnt CPS and WHISARD

Brandon Brown - POC on finding out more on interfacing with WHISARD

separate logins used for both systems, CPS and WHISARD

Descripition:
Provide an e-signature method following one of methods in User STory #60 on the bottom of the Assurances Section during application creation process.

Tasks:

• Create the following input fields in Assurances Section:
  Full Name, Title, Date
• Provide a statement certifying you are the authorized individual and it is you, see below:

Acceptance Criteria: Applicant will be able to enter their full name, title and date on the Assurances section and save it to the database acknowledging the Assurances statement.

• Create Registration form (simple no design)
• Data Modeling
• Create Services, including DOL Complexity Rules
• Captcha

Org REgistration Flow
User enters email, pwd, EIN if duplicative, then blocked from creating account and told who to contact from DoL to investigate (internal business rules to contact the associated POC for certificate), , two factor auth (in future phases not in phase 1)

The landing page for the Certification Team manager (or those with admin access) should show the entire application inventory, with the ability to filter base on specialist and/or status.

Descripition:
Per section diary entries, summary on application summary page, diary entry consists of: 1. comment, 2. section associated to comment, 3. upload file per entry, NO delete or edit of existing diary entry, Security: everyone except applicants can add diary entries

Tasks:

• Front end diary entry form, summary view simple table including comment, author, section and file uploaded, auth trimmed by everyone except applicants
• BAck End data modeling, setting controllers, auth/role features
• Test Coverage 90%

Acceptance Criteria: administrative team can add diary entries per section (see wireframes from user story #11 ) Add comment, section dropdown, and file upload. No ability to delete or edit after submittal of entry.
Considerations:

1. Application Status
2. Role
   OLD Notes:***linked list per application of issues

Notes - date time, who, continue adding instead of edit

Liz - provide examples of diary sheet

As an Applicant, I want to submit my application via a web form so that the submission process is quicker and I no longer have to mail my application. AC: Data will end up in a database. AC: The applicant must be logged in.

All user types involved with this User story

withdrawn - manaul process
pending - submitted state, allows them to continue existing status until they make decision (only for existing approved applicants) : pending new or pending with authority to continue to operate
amending - (Liz to ask for definition from Chicago team)
issued - approved
denials - during application
revoke - post application
expired - have to re apply before certification expiration date

Assigned by state - iniital assignment capability, state where

WH-40 is lcoated in WHISARD, time they spend on different activities and cases, enforcement activity

Time sheets
Specialists record activity
Certificate team members record activity

effort needs to be tracked by WHISARD ultimately
Need to figure out whether data transfer or merged, POC Brandon Brown, discuss WHISARD interface and data

Most folks by end of week, enter time, end of pay period
Liz - will go back to research need and WH-40 system
calendar events - interfacing from where?
Alert/Reminder on follow up related to diary entries

flagged for previously revoked or denied, so the processor can see history

Manager view of #34

open investigation of employer, Chicago wont make a decision until investigation has been completed,

enforcement history is being pulled from WHISARD, if current then they hold, if existing or previous they will review

CPS & WHISARD two separate applications and logins

Screen for registered applicant, enters email address and button for invite/add user, sends email to user and user follows registration link to finish account and set their own password, active or inactive user flag, limit on total, delete hides but doesnt remove user from users table, same workflow different beginning point

generally assign status by state, need maybe backups or just re-assign

See current assignment, edit and pick from list of certificate team members to re-assign

Descripition:
Applicant can save the application in draft while filling out the application, continue when logs back in, auto saves in n minutes (configurable) - last saved date time stamp. Further Dashboard capabilities can be found in User STory #70 Session timeout will be encompassed in Security User STory # Save in separate data store from submitted applications, Allowing user to do what they want in draft state, not enforce sequential completion.

Tasks:

• Create logic to change button to continue versus start a new application on landing page
• Implementation of save functions:
  auto-save, next section save
• Implementation of Last saved date timestamp

Acceptance Criteria: Applicant can save in draft state any time, autosave - during go to next section, autosave - every n minutes (configurable). Landing page will only have start or resume application.
Considerations:

1. Application Status : N/A
2. Role: Applicant

Once tracking has been implemented, need to provide history within the system, need DoL network access, need to get examples from DoL

WH-228sample.pdf

Need to look into certificate number generation,
Drop data in certificate, create pdf/document and email to certificate or have access to in their profile interface, email could possibly be just a link to pdf or place where they can download

Need to see history of certificates issued similar to seeing history of applications

Always had data paper based, ability to do basics on applicant information, how its done is probably basic at first cut, simple break down by regions, aggregate information

Discover Metrics - work with data analytics team to figure out need - Brandon Brown - POC

related to #507
Descripition:
Identified rules for the summary validation, to ensure a complete form is submitted by the Applicant. All fields presented to the user should have a response except fax number (requires a response/check box). Prevailing wage surveys, attach an additional sheet if needed (not required)

Tasks:

• apply rules that get fed into User STory #58
• submit form, save data to database, provide user verification statement pre-submit

Acceptance Criteria: User clicks on summary view and submits application. Valid application is saved to the database, invalid application returns errors (not visible/in UI)
Considerations:

1. Application Status
2. Role: Applicant

Card #4 is asking that we only allow complete applications to be submitted (we will have a predetermined criteria defining 'complete'). cc: @elizabethstriegel

information on what is failing before submittal, where the draft applications are stuck or empty areas/gaps in information submitted

Certain metrics, - abandonment, possibly use usage analytics tools on consumer facing site

Research Spike - look into analytic tools on web traffic

226 form
1. Section 1 everyone
a. Follow up on signature - esignature
2. Section 2 everyone sees
a. Except 3rd on b unless they click YES
3. Section 3 - everyone
a. Lead with questions on if fields
i. Only seen if says yes
4. Section 4 - If YES from 3
5. Section 5 - eveyone
6. Section 6 - everyone, the number they put there should be linked to 226a for 5 locations, include validation to see if they match
7. Sectiion 7 - everyone
8. Section 8
a. A and b - everyone
b. C and d - dependent on answer to b
c. Yes to b triggers attachment on d - could be large file attachment
d. E - everyone
9. Section 9
a. if they say no to 9a, skip to 11
b. If they say yes, see how many workers in b
i. c, questions indicate whether to show the 1st, 2nd or 3rd
10. Section 10
a. Only see 10 if yes to 9a
b. A is an answer
c. B is an attachment, different file formats
11. Section 11
a. If they say nom, skp to 13
b. If yes, c is three questions
i. Minimum of 3 on 11c
12. Section 12
a. Only see 12 if yes to 11a
b. A is an answer
c. B is an attachment
13. Section 13
a. If box checked then proceed
14. Section 14
a. If box checked then proceed
15. Section 15
a. Everyone
16. Section 16
a. Everyone on a
b. For b, everyone shoulkd see, if they hgave a worker than they need yes/no in field

226a Form
1. Section 1 - everyone
2. Section 6 - mapped to Section 7 number of workers from 226 form
3. Section 7 - should match number of workers entered and number for rows completed should match as well

Administrative reports view

Non-WHD interested parties - advocacies, most will be satisfied by what they are currently posting on webiste, it is the internal admin view that could vary

Could be rolled into #7 but of a lesser priority.

Descripition: Following the approved wireframes v2, develop the section for Application Info performing the following tasks. Does Include the instructions within the section as well as expanded areas within section, does not include validation #6 , conditional logic #9

Tasks:

• Implement UI based on Wireframes
• Implement Data Modeling to support the Section of the form
• Implement the Services/API layer to support the SEction of the form

Acceptance Criteria: Review of section within 226/a form web application follows look and feel as dictated from wireframes v2, Technical review will meet standards as defined by QASP and 18f guidelines

similar to previous requirement on public facing site, need to provide ability to search certification status by state or employer name

Descripition: Following the approved wireframes v2, develop the section for "Employer" performing the following tasks. Does include the instructions for the section, does not include #9, and the validation from user story #6 and also the file upload user story #15

Tasks:

• Implement UI based on Wireframes
• Implement Data Modeling to support the Section of the form
• Implement the Services/API layer to support the SEction of the form

Acceptance Criteria: Review of section within 226/a form web application follows look and feel as dictated from wireframes v2, Technical review which meets QASP standards from 18F guidelines

Applicants are only logging in every other year

Person would be logging in for one EIN at a time, need to understand if that requirement exists - Liz

Most are renewals, very few new - Liz

Do not pull out all data, Liz to identify a few fields from the last application for that organization/EIN

Acceptance Criteria : few fields from the last application for that organization/EIN, fields identified by Liz

what are the 14c form features?
EIN Validation - masking, validation

Research Spike - look into IRS service validation on EIN

looking into briefly the IRS service, will fall back on confirmation during registration if complexity is too great.

Acceptance Criteria:
Anytime Applicant enters EIN there is a validity check on that data point, to be further defined through above mentioned Research spike.

Further define metrics captured on all transactions

Do the following Tasks for Each User STory within this epic

• Build out Form Screens
• Data Modeling
• Build Services

Acceptance Criteria: Review of screens showing all data points from form 226/a, review of data model and services - Liz and Steven

Description: Allow the user to upload PDFs, office docs and images to support their form data.

1.   File types (doc, docx, xls, xlsx, ppt, pptx, pdf):
   

   • This is a good start for the file types. We would also suggest adding .jpg & .png for users that have image documents

2.   Size limits, where are they stored, access to uploaded documents
   

   • 10MB is a good start. The infrastructure team will create a NFS mount point size of 500GB. All cluster web nodes will connect to the mount point location.
   • If a file upload is initiated at submission, the database (PostgreSQL) can point/map to the mount point location.
   • Question: Will the uploaded files contain PII?

3.   Document management? - how long to keep, administrative access on process
   

   • 7 years for record retention

4.   OCIO manages files in another VM, web server and path file share in past
   

   • Operations will provide the mount point location as soon as the development environment is ready

5.   Thomas to find out direction from OPA, Mike. Answer: backend to be saved to fileshare over smb
   

   • See question 2 response

6.   Records Management discussion on document retention/lifecycle
   

   • See question 3 response

Acceptance Criteria: See identified attachment sections, types (pdfs, office docs), size (less than 10MB), file upload: check browser compatibility, ability to edit/delete in draft state, backend to be saved to fileshare over smb

• I believe the application logic should handle this criteria.
• Question: Will the application prohibit users/admins from deleting documents that have submitted?

Already available on WHD public facing site

POC from DOL to talk through the backend - Content Manager - Mike

Get copy of xml/data dump for better understanding of data needed for integration points - Michelle

Source: http://dolcontentdev.opadev.dol.gov/
Target: http://www.dol.gov/

File(s) to be transmitted from Source to Target:

http://dolcontentdev.opadev.dol.gov/whd/specialemployment/SWEPlist.htm
http://dolcontentdev.opadev.dol.gov/whd/specialemployment/SWEPListWorkSheet.xls
http://dolcontentdev.opadev.dol.gov/whd/specialemployment/SWEP_Sort.xml
http://dolcontentdev.opadev.dol.gov/whd/specialemployment/CRPlist.htm
http://dolcontentdev.opadev.dol.gov/whd/specialemployment/CRPWorkSheet.xls
http://dolcontentdev.opadev.dol.gov/whd/specialemployment/CRP_Sort.xml
http://dolcontentdev.opadev.dol.gov/whd/specialemployment/PatientWorkerList.htm
http://dolcontentdev.opadev.dol.gov/whd/specialemployment/PatientWorkerListWorkSheet.xls
http://dolcontentdev.opadev.dol.gov/whd/specialemployment/EPW_Sort.xml
http://dolcontentdev.opadev.dol.gov/whd/specialemployment/BusinessCertList.htm
http://dolcontentdev.opadev.dol.gov/whd/specialemployment/BusinessCertListWorkSheet.xls
http://dolcontentdev.opadev.dol.gov/whd/specialemployment/business_Sort.xml

Asking for email address, that they identify as POC or email as register, or option when submitting

Need to capture workflow diagram/state

STatus is simple, pending, received and issued or denied

Renewals are included, reminder for resubmitting
Alert templates?
Submission
Decision
Reminder 60 days out
Certificate expiration

Nightly backend process that runs for possibly all alerts

Acceptance Criteria:
Applicant receives email during the following actions: submission, decision, reminder 60 days out, Expiration

Estimation - complexity in login rules, validation beyond, delegate permissions, forget password link

similar to #23 different end user type - public for FOIA

provide existing calculators, access when needed in the process:

Time studies,
Wage studies (?) - capture use in online calculator instead of uploading attachments
existing today - cant save data today, would be great option, at a minimum save to pdf and attach, need to further explore/research saving directly

Acceptance Criteria:
At a minimum provide contextual links in the form for the user, look into possible saving of calculated data and effort involved.

Aggregate view from time keeping requirements in #30 for Manager user type

Descripition: Following the approved wireframes, develop the section for "Assurances" performing the following tasks. Will not include e-signature, will be addressed in user story #44

Tasks:

• Implement UI based on Wireframes v2
• Implement Data Modeling to support the Section of the form
• Implement the Services/API layer to support the SEction of the form

Acceptance Criteria: Review of section within 226/a form web application follows look and feel as dictated from wireframes, Technical review will meet standards as defined in QASP following 18f guidelines