The development of the PHNs Program Electronic Reporting System (PPERS) was a recommendation of the 2018 PHNs Deliverables Working Group (DWG) Review Final Report. The report made several recommendations related to reducing reporting burden, including introducing electronic reporting.

All PHNs are required to submit multiple deliverables to the Department of Health each financial year. Submission, review and assessment are currently done using manual processes.

PPERS is expected to significantly reduce the administrative burden associated with the receipt and assessment of PHN deliverables through streamlined reporting via a single online portal.

PPERS also aims to improve data quality and performance analysis by having all performance information for a PHN stored in the same place.

Criterion 1 – Understand user needs

Since commencing in 2015, the rapid expansion of PHNs has seen an increase in the associated reporting obligations. At the March 2017 PHNs CEO Workshop, the Department of Health committed to reviewing the PHNs reporting processes in consultation with those networks.

The DWG was established, combining representatives from PHNs and individuals from the Department of Health who were responsible for administering the PHNs program. These groups conducted an 8-month review of PHNs reporting requirements with a view to reduce the reporting burden for both parties and make sure the deliverables were fit-for-purpose.

User working groups

The DWG Review Final Report identified 2 distinct user groups for this project:

• PHNs staff who prepare and submit information
• departmental staff who assess and accept information.

Two working groups made up of people from these user groups was created to (a) streamline deliverable templates (implemented in November 2018 for 2019-20 deliverables), and (b) design, build and implement an electronic reporting system.

Membership of the DWG was renewed in August 2018 to provide an avenue for understanding PHN user needs, as well as provide advice on the design, build and implementation of PPERS.

A new PPERS Internal Working Group was established in June 2019, following extensive one-on-one consultation with relevant policy areas responsible for administering the PHNs program (August 2018 to May 2019). The aim of this new group was to better understand departmental user needs and provide advice on the design, build and implementation of PPERS.

The department continues to work closely with the DWG and the PPERS Internal Working Group via fortnightly teleconferences and meetings, and receives feedback on each component of PPERS to make sure it meets user needs and aligns with expectations.

Site visits

The project team undertook numerous site visits to PHNs around Australia to better understand their current reporting processes, their expectations, requirements, and preferences for an electronic reporting solution.

Surveys

An online survey was developed to gather baseline information from departmental and PHNs staff on current reporting processes. The survey also captured expectations for PPERS, and level of understanding of the purpose and impact of PPERS.

Additional surveys will be conducted following implementation to help the department measure the success of implementation. Outcomes from these surveys will also be used to inform ongoing communication, change management and implementation activities for the PPERS project. 

Operations Working Group

PPERS is only one component of the PHNs program, and regular reports on progress were provided to the policy group, the PHN Operations Working Group. The monthly meetings provided a forum to engage with internal stakeholders more broadly across the PHNs program and discuss program-wide policy issues related to the design and/or build of PPERS.

Criterion 2 – Have a multi-disciplinary team

The project team is highly skilled, experienced and have a track record of successfully delivering projects within the department.

Having a multi-disciplinary team ensured there were no gaps in skills, knowledge, or experience, allowing full capability to deliver the project. The team comprised of:

• Project Manager
• Scrum Master
• Product owner / Subject matter expert
• Business Analyst
• Software Developers
• Testers
• Solutions Architect/ Security
• Change Manager
• UX/UI Design Specialist.

Team members were comprised of both full-time contractors and permanent APS staff.

All members of the team were involved in Agile Development processes, specifically using Scrum. Business Analysts and the Project Manager also attended various User Working Group meetings to better understand user requirements.

To make sure work was completed within specified timeframes, additional recourses were brought in as required and priorities were revised as needed.

The Product Owner and Subject Matter Expert were heavily involved in the design and build process, and had the authority make all necessary decisions.

Criterion 3 – Agile and user-centred processes

All aspects of the design and development process was Agile and user centred. Both the Deliverables Working Group and the Internal Working Group convened fortnightly to test and validate design and build elements of the system, in line with the fortnightly development sprints.

Both user groups were exposed to wireframes, prototypes, and mock-ups/screenshots throughout all stages of development, and encouraged to provide their feedback, comments and preferences for refinement. Feedback was subsequently prioritised to make sure a ‘minimum viable product’ was delivered in line with set timeframes.

The Subject Matter Expert and Product Owner were responsible for prioritisation and approval of component development (via Azure Dev ops) to ensure that the system met the requirements of the user.

During Beta, the team have continued to demonstrate further development of prototypes, which align to user stories.

Criterion 4 – Understand tools and systems

The team have demonstrated a very strong understanding in the technology of choice used for PPERS.

Criterion 5 – Make it secure

Secure development practices were followed. PPERS was developed using O365 and Azure services and is hosted on their SaaS platform where Microsoft supported industry standard security controls are used. This application went through security assessment including penetration testing by an independent authority to make sure applicable ISM controls are used and to verify their effectiveness.  

Criterion 6 – Consistent and responsive design

The UX Designer provided expertise in user-friendly layout and function and used the DTA’s Design System as a base. It is functional in all supported web browsers across different operating systems.

User Research concluded that users would primarily be using this service on desktop devices such as laptops, tablets etc.

The User Interface is logical and easy to navigate and responds to all screen sizes having been designed as ‘Mobile First’. However, there are some restrictions on how the forms display on mobile devices which should be addressed in future.

Approximately 18 future PPERS users, made up of both departmental and PHNs staff participated in onsite User Acceptance Testing (UAT) of the system. During UAT, participants tested real life scenarios relevant to their user group, to ensure PPERS is fit for purpose.

Criterion 7 – Use open standards and common platforms

PPERS was built by re-using an existing Health platform with customisation. Open standards for form creation using HTML, CSS, JS etc. were used.

Existing standard- based Health authentication mechanisms that follow the federated authentication have been used. These integrate well with WoG authentication mechanisms and can be more easily replaced as solutions evolve.

Federated authentication following common standards and patterns will evolve and standardize ways of working.

Criterion 8 – Make source code open

The code is owned by the department and may be shared with other departments/communities.

The code is stored within the CRM and has been shared across many other CRM services.

Governance and procedures relating to open sourcing code is a larger topic for the department beyond this one project.

Criterion 9 – Make it accessible

The design and user experience will follow the WCAG 2.0 level AA standard.

The User Interface responds to all desktop screen sizes. It is mobile responsive and uses DTA Design System components which include accessibility requirements.

The layout is designed to support keyboard tab navigation, and content is written in plain English with an active user centred approach, where appropriate.

Criterion 10 – Test the service

There is an end-to-end testing environment where code is promoted from Development, to Test, to Acceptance, and then to Production. Testing is conducted in each environment under formal change management procedures.

A brief private Beta was conducted with internal department users, prior to moving to a limited public Beta with key external users. The quick progression to a limited public Beta was due to external users being the main target audience for the tool.

Security testing will be undertaken via penetration and load testing prior to PPERS going live.

Criterion 11 – Measure performance

User satisfaction 

User satisfaction and feedback will be measured by periodic qualitative surveys.

This will help to inform further enhancements.

Digital take-up 

The PHNs team will measure the number of users who log in and regularly use PPERS.

Digital take-up and completion rate will be measured using Google Analytics.

Criterion 12 – Don’t forget the non-digital experience

The release of the system has been brought forward to support the business area in:

• ensuring technological stability
• training internal staff on use of the system.

Further guidance material will be developed and is intended to be published on the PPERS Portal itself.

Criterion 13 – Encourage everyone to use the digital service

Prior to the PPERS portal, users have been using Microsoft Excel on a day-to-day basis.

The Alpha and private Beta functionality has been popular with users.

Digital take-up is guaranteed since only the digital space can provide the functions identified as being required for this complex system.