ADVANCED JADE TIPS(and other things I’ve picked up on monitoring JADE…)

Aubrey Bodden, Acting Policy AnalystFreedom of Information Unit

IM Network Meeting 25 November 2009

Presentation Outline Taking Ownership of JADE

Entering Request Details

Should it go in JADE?

Requests are for Records

Correspondence History

Outcomes

Splitting Requests

Logging Appeals

Taking Ownership of the JADE System

YOU are responsible for the data entered in JADE and its accuracy

YOU produce the quarterly reports to the ICO and must explain the data

YOU may use JADE to report statistics to your supervisor or Chief Officer

I will call YOU when I do not understand information in JADE

Not sure about a task in JADE? ASK!

Entering Request Details - DOs

DO capture the entirety of the applicant’s request in a way that is clear and concise

DO summarise the request if necessary

DO amend request details after clarification is received to reflect the newly clarified details

DO use proper grammar, spelling, punctuation and capitalisation

Entering Request Details - DON’Ts

DON’T include anyone’s contact details

DON’T include salutations and other information irrelevant to the request

DON’T include the record delivery format

DON’T delete the request description when clarification is received from the applicant

DON’T include notes to yourself or others

Are you able to tell what the following requests were asking for from this?

Is all of this information necessary for you to know what records are relevant?

Should it go in JADE? - YES

YES – The request is for information that is not available under another administrative policy or procedure in your public authority

YES – It is not information that you could give out in the normal course of business

YES – The applicant wants to obtain access to a record not previously made public

YES – The requested record is not listed in your publication scheme

Should it go in JADE? - NO

NO – The record is open to access by the public pursuant to an enactment (s. 6(4)(a))

NO – The record is available for purchase by the public in accordance with administrative procedures (s. 6(4)(b))

NO – The information is in the public domain

NO – You gave out this kind of information before FOI came into effect

NO – The request is for contact details or other basic information about your public authority and its functions

Should it go in JADE? - NO ctd.

NO – JUST BECAUSE… Another staff member thinks you should

deal with it because you’re the IM It came in to the FOI email It is addressed to the Information Manager It mentions Freedom of Information It came in on an FOI application form Your Chief Officer told you to

Remember – Requests are for Records

Requests are for Records, Not Answers to Questions

Section 3(1): The FOI Law applies to public authorities and records

Section 6(1): “Subject to the provisions of this Law, every person shall have a right to obtain access to a record other than an exempt record”

Ensure that FOI Requests are Always Answered with Records

Don’t just answer the applicant’s question Give it some thought! How do YOU know the answer?

If the answer is hard or impossible to give with records, the question might not be an FOI request

You can answer a portion of an applicant’s request outside of the parametres of FOI

Creating Records and Collating Information

You are not required to create a record to respond to a request FOI applies to records held by public authorities

You are required to collate all relevant information to respond to a request Creating a new record from

information held in various records can be done at your discretion and as necessary

Correspondence History - DOs

DO record ALL correspondence with ANYONE Applicant, third parties, Legal Department, other

staff members within your public authority

DO state the correct date (you can backdate)

DO utilise the “File Note” option

DO summarise the content of and reason for the correspondence if not a template letter

DO – Check this section to see what is updated automatically and what you must add manually

Correspondence History - DON’Ts

DON’T neglect this section if you use your own templates for response letters

DON’T enter the same details multiple times

DON’T add correspondence manually when it is automatically recorded during a task

tasks toolbar

edit request toolbar

stages of the request life cycle

where you are now

CORRESPONDENCE HISTORY

The Tasks Toolbar - Each Stage of RQ

tasks toolbar for third parties

Simple Correspondence History

Detailed Correspondence History

Detailed Correspondence History

Complex Correspondence History

Complex Correspondence History

OUTCOMESGranted in full

Granted in part

Exempt

Public domain

Refused

No records exist

Withdrawn by applicant

Deferred

* as at 30 September 2009

Outcomes – General DOs

DO record the CORRECT outcome

DO record ALL correct outcomes

DO utilise the outcome remarks section, especially if you record multiple outcomes

DO indicate who made the decision if not you

DO double-check your outcomes before closing

Outcomes – General DOs ctd.

DO backdate the outcome if necessary Time to complete = date of receipt to date of outcome

Outcomes – General DON’Ts

DON’T copy and paste the full text of a letter Generic introductory statements and information

about appeals do not need to be recorded

DON’T be careless with spelling and grammar

DON’T use the outcome remarks for just gibberish, it is not a mandatory field

Outcomes – General DON’Ts ctd. DON’T add multiple outcomes without making

it clear what information they each apply to

DON’T record outcomes that don’t make sense

Outcomes – General DON’Ts ctd.

DON’T record the same outcome multiple times

Outcomes – General DON’Ts ctd.

DON’T close a request without an outcome!

1. Granted in Full – Best Practice

Remarks may not always be necessary for this outcome type, or may be very simple

Only include useful information in the remarks

2. Granted in Part – Best Practice

Record all additional outcomes utilised Include remarks that explain why the request

was only granted in part In additional outcome remarks, detail what records

or portions of the request were not granted

2. Granted in Part – Best Practice ctd.

Always include the granted in part outcome

NB: The exemption for unreasonable disclosure of personal information is only applicable to

information about actual human beings

2. Granted in Part – Best Practice ctd.

Always include ALL other outcomes as well

2. Granted in Part – Best Practice ctd.

Always DETAIL all other outcomes

3. Exempt – Best Practice

Explain why the information is exempt

Confirm application of the public interest test

3. Exempt – Best Practice ctd.

Include all exemptions utilised

4. Excluded – Best Practice

Select the specific section of the FOI Law

4. Excluded – Best Practice ctd.

If the record is exempt because another law takes precedence, cite the appropriate law

Remember – this information has not been provided under FOI

because it is already in the public domain, so an additional outcome for public domain is not necessary,

so the remarks are correct

5. Deferred – Best Practice Explain why the request is being deferred

Indicate the date that the applicant will be provided with a copy of the record

6. Refused – Best Practice

9(a) Explain why the request is vexatious

Include details and request numbers for other applications which may be relevant

9(b) Include the reference number of the substantially similar request from the same person that you have already dealt with

State the outcome of the original request

6. Refused – Best Practice ctd.

9(c) Explain how compliance with the request would unreasonably divert the resources of your public authority

6(b). Public Domain – Best Practice

9(d) Indicate where the information is publically available, and how to access it

7. No Records Found – Best Practice

Detail the search for records

Explain why you might not have the records

Indicate whether the request will be transferred to another public authority

8. Administrative Closure – Best Practice

Always include outcome remarks that explain why the request was administratively closed

If the request is a duplicate, indicate the number of the active file in the remarks

Splitting Requests

If a request will become clearer by splitting it into more than one part, treat that application as multiple separate requests in JADE

Splitting a request is useful if the initial request consists of many records and you will be making multiple decisions Multiple decisions will lead to multiple outcomes

Distorts reporting

Complicates statistical analysis

Confuse records keeping

See FOI Circular #5 – Clarifying Requests for more information on splitting requests

Splitting Requests - DOs

DO split the request using the JADE task

DO explain the split to the applicant cite which sections from the “parent” request will

constitute each “daughter” request

DO consolidate the multiple correspondence letters generated by multiple requests

Splitting Requests – DON’Ts

DON’T split requests unnecessarily

DON’T enter each request individually

DON’T leave the correspondence history of all but one request empty

DON’T wait to send your decision letter until all responses are ready

DON’T include portions of a request that should not fall under FOI procedures

Requests that could have been split into multiple parts

Requests that could have been split into multiple parts ctd.

Logging Appeals - DOs

DO record the appeal information in the same file as the original request for information

DO give the information to the original IM promptly if the request has been appealed to the Ministry/Portfolio above the public authority

DO record the delivery of records that have been released upon appeal

DO indicate who conducted the IR

DO include ICO mediations as appeals

Logging Appeals - DOs

DON’T create a new request for an appeal

DON’T wait until the resolution of the appeal to log receipt of the application

DON’T attempt to change the original outcome made by the Information Manager if the appeal overturns that decision

THANK YOU!ANY

QUESTIONS?