ADVANCED JADE TIPS (and other things I’ve picked up on monitoring JADE…) Aubrey Bodden, Acting Policy Analyst Freedom 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 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

Complex Correspondence History

OUTCOMES * 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?