Australian Healthcare Associates on behalf of Department of Health – Beta assessment

Australian Healthcare Associates (AHA) has been engaged by the Department of Health (Health) to administer the 23 Community Pharmacy Programs funded under the Sixth Community Pharmacy Agreement (6CPA). AHA will commence administration of these programs from 1 February 2019, accepting program registrations, service claims and making payments from this date. AHA will operate under the name ‘Pharmacy Programs Administrator’ (PPA) for the administration of these programs. Core components of AHA’s overall solution for delivering the PPA are; a registration and claiming portal for all relevant 6CPA program stakeholders, a PPA Website and a PPA Support Centre.

AHA successfully engaged with a broad range of stakeholders and users in the short timeframe available. A strength of this process was the sustained engagement with users, who have continued to review the system throughout the build, providing advice and suggestions that were incorporated into the final solution. User experience has been of paramount in building a consistent and responsive service.

AHA built a strong and committed team, supplementing its internal development team with appropriately skilled business analysts and testers, that were embedded during the discovery phase to ensure the whole team has a detailed understanding of user needs.

The build progressed quickly, utilising open standards (HTML5, CSS3, JS), with appropriate supporting documentation developed. Robust security measures and testing, including external penetration testing by Shearwater, will be supplemented with an IRAP assessment, which is currently being arranged. 

Parallel to the system build, AHA rolled out a Support Centre to provide assistance for users to engage with the system. These operators have been trained to support users to utilise the system themselves, rather than on their behalf, to encourage fully digital service provision.

Criterion 1: Understand user needs

Engagement with a wide range of users was a strength of the team, with consultations held with groups and individuals representing approximately 30% of pharmacies across Australia. Additional engagement with non-pharmacy users (universities, NACCHO) also occurred. Feedback from users was captured throughout the build period, with these comments and suggestions incorporated into the final build. Examples of the feedback received and actioned included:

  • The time taken for data input for one claim type was onerous, so a file upload feature to avoid this data entry was added
  • A request for the ability to copy and paste data exported from pharmacy software directly in to a claim, rather than needing to complete manual data entry.

All project team members attended at least one consultation and feedback after sessions was provided to the wider group to ensure the team had a shared understanding of user needs and priorities.

A key pain point identified related to the lack of automation between pharmacy software and the current system. Whilst the timeframe for delivering the MVP is too short for these automation features to be incorporated, the team has already engaged with software providers, with an expected delivery timeframe of approximately 6 months.

Criterion 2: Have a multi-disciplinary team

A strong, multidisciplinary team was engaged to deliver the project. AHA’s internal development team was complemented by business analysts and testers who were recruited for the build and go live periods. Team stability has been a strong point, with very low staff turnover. 

The team consisted of the following sub-units:

  • Service delivery management group
  • Design and testing group
  • IT development group
  • Content and interaction design group
  • Subject matter experts (SMEs).

When required, the team has reached out for additional SME input, which has been facilitated by having an existing user and pharmacist co-located on site with the development team.

The team has recently grown again, with the addition of 15 Support Centre staff. This team commenced prior to go live to provide users with assistance to engage with the new system and support them in their transition to the new arrangements. 

As the service continues to evolve and move to Go-Live, a ‘step-down’ plan was put in place to manage knowledge transfer, as the requirement for all business analysts in the design and testing group reduced.

Criterion 3: Agile and user-centred process

The project has embraced an agile methodology, utilising an electronic Kanban board and daily standups to prioritise tasks. As the build progressed, additional tools, such as Azure DevOps have allowed for the efficient and effective management of testing and bug fixes. The interface is simple enough for non-developers to use, allowing real users to provide their feedback quickly and systematically to the development team, which is then used to update and prioritise the sprint backlog.

Continual improvement is built in to the service delivery model, with ‘transformation cycles’, where formal feedback is sought and collated from multiple sources and then used to guide future upgrades.

The team has a clear management structure with an engaged delivery manager, service manager and production manager.

Criterion 4: Understand tools and systems

The team demonstrated they had considered a range of options before choosing an approach and selecting tools and systems, which were reviewed by the Department of Health’s Architectural Working Group (AWG). 

A rapid environmental scan, comparing requirements to existing platforms and solutions was undertaken, however the complexity of rules for 23 the programs and the data specifications provided by the Department of Health meant COTS customisation was not a viable option. Neither AHA or Health hold the IP for the existing solution, so reuse and update was also not possible. The outcome was therefore the in-house development of a bespoke system, designed as three modular components, Web Application, Web APIs and Database/stores. The development of which leveraged industry standard resources, frameworks and platforms such as Bootstrap, Angular and .Net Web API. This system design ensured all functional and non-functional requirements specified by Health could be delivered.

The suite of supporting documentation developed will be updated as required as the system goes live and will be provided to the Department of Health.

Criterion 5: Make it secure

AHA developed a set of system security principles to ensure that all required standards were considered during system development. These principles, along with relevant standards, our privacy policy, and comprehensive risk assessments documented in our Risk Management Plan, guided system development.

AHA has developed robust security infrastructure, with appropriate supporting documentation in place. AHA has also undertaken an Essential 8 Maturity Model Assessment, external penetration testing by Shearwater and is currently arranging for IRAP assessment to occur. A small number of risks were identified by Shearwater, which are currently being addressed and will be retested by Shearwater prior to go live.

Data security and access is managed through a variety of tools and practices, including:

  • Encryption of all communication between different system components with TLS
  • Encryption through the standard encrypted SQL connection protocol for databases
  • IP/domain whitelisting
  • Role based access controls for users (which are contractually defined) that must be validated prior to user access.

These elements indicate the appropriate level of rigour for a system that will collect store information that is considered Sensitive: Personal.

Criterion 6: Consistent and responsive design

User feedback drove system design, with a review of the current system identifying:

  • A lack of consistent identity across the three existing platforms utilised by users
  • The need to streamline and update the information available and present it in a form that meets the WCAG 2.0 AA standards.

The team has successfully prioritised consistent service design, with the two elements of the new system, the website and the portal, appearing seamless from a user perspective. Consistency has been maintained with the use of a clear, detailed design brief, supported by a team of experienced front end developers and user experience designers. Additionally, a full content and document audit was undertaken, with all information reviewed, updated and professionally edited to make the user experience cleaner and simpler.

Bootstrap was used to ensure responsive design, with testing across multiple platforms and browsers in place to test these elements. 

Criterion 7: Use open standards and common platforms

During development, AHA actively adhered to open standards of development as outlined by W3C for HTML, CSS and JavaScript. AHA’s adherence to these standards promoted a participative and inclusive practice of development, that delivered:

  • Transparency - all decisions and code development were available to the team through Azure DevOps
  • Relevance – via the use of up to date practices for development and coding (e.g. HTML5, CSS3)
  • Openness – by ensuring that all stakeholders had input into the development process, including those without coding experience.

Where possible, the team reused and repurposed code, both from previous AHA projects, as well as other best practice code repositories, such as Bootstrap and Angular.

Criterion 8: Make source code open

Health holds the IP for all source code, so can choose to make source code open. All code will be held in escrow.

AHA’s open and transparent development practice promoted internal code sharing and reuse, with all decisions and code development available through Azure DevOps.

Criterion 9: Make it accessible

The website has been developed in parallel for desktop and mobile devices with WCAG 2.0 AA specifications as guiding principles to ensure a consistent, accessible user experience. User experience designers are now also working on making the portal WCAG 2.0 AA compliant, with testing underway by users that have undertaken accessibility training. Due to time constraints, an external accessibility audit could not be performed prior to go live, however this will occur and any findings will be addressed as a priority.

To assist new users with the system, a Support Centre is now operational, with team members trained to guide users though the system, rather than undertaking tasks on their behalf.

Criterion 10: Test the service

Testing is being managed via Azure Dev Ops and standard procedures for testing, recording, prioritizing and actioning bugs are in place. Two testing environments that replicate the end-to-end live production environment are in place. System integration testing, user acceptance testing and security testing have all been completed, with performance testing currently underway. Results from external penetration testing were pleasing, with no critical or high risks identified. A small number of medium and low risks were identified and rectification work is currently underway to address these findings prior to go live.

It is recommended that risks identified via penetration testing should be prioritised by the development team so that rapid retesting can occur.

Criterion 11: Measure performance

Whist historical performance data is unavailable, AHA are currently engaged with Health to determine the best reporting and KPIs for this project going forward. 

User experience has been a priority, with a number of pain points already identified and addressed. Ongoing user satisfaction will be measured in a range of ways, including via the wide range of data that will be collected as part of the ongoing management of the project, including minimum service level reporting about query resolution timeframes and user surveys about ease of use. This information, as well as ‘transformation cycles’ that include stakeholder consultation could form the basis of reporting against the DTA’s user satisfaction standard, should the Department agree to the public release of this information.

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

A Support Centre has been successfully deployed to ensure those that require assistance to access the digital service get the help they need, with extended operating hours of 9am to 8pm AEST. Outbound calling has begun, to assist current users migrate to the new system. Support Centre operators exhibited excellent program knowledge and will be a valuable resource for the team.

Criterion 13: Encourage everyone to use the digital service

Currently, all users engage with the digital service. To encourage them to keep doing so, significant resources are being allocated to the production of appropriate support materials including FAQs, user guides, video tutorials and face to face sessions, including at The Australian Pharmacy Professional Conference and Trade Exhibition (APP) in March 2019. 

Users that call the Support Centre with IT questions will be supported to use the system to complete their transactions.

Assessment against the Digital Service Standard

Criterion Result
1 Pass
2 Pass
3 Pass
4 Pass
5 Pass
6 Pass
7 Pass
8 Pass
9 Pass
10 Pass
11 Pass
12 Pass
13 Pass