The project consists of three major phases:

• Phase 1 – NDSS Central (Dynamics CRM 365)
• Phase 2 – NDSS Health Professional Portal
• Phase 3 – NDSS Health Registrants and Access Point Portal.

The National Diabetes Services Scheme (NDSS) is an initiative of the Australian Government and provides access to subsidised products and services needed for the self-management of diabetes. The NDSS is administered by Diabetes Australia (DA) through an agreement with the Department of Health and will cost $851 million over a 4 year period (2016 – 2020). Registration with the NDSS is free and open to all Australians who are diagnosed with diabetes and certified as eligible to access the scheme. NDSS support services are available through DA and NDSS Agents (Diabetes organisations) in each State and Territory. NDSS products are obtained through NDSS Access Points (community pharmacies) in all states and territories. Persons registered with the Scheme can access subsidised products including: syringes and needles, blood glucose test strips, urine ketone test strips, and insulin pump consumables.

Diabetes Australia has been the administrator for all components of the NDSS since 1987. The existing NDSS system, maintained by DA, is primarily a logistics system and has not been set up to capture supporting client level data regarding Support Services and engagement with the NDSS. Support Services data is currently captured and stored in a variety of systems and formats at the State and Territory NDSS Agent and is not reported in a consistent manner to the Department of Health.

Criterion 1: Understand user needs

The project team demonstrated an extensive engagement with users. User research interviews were held with Diabetes Australia and NDSS Agents across five state sites and with representatives from one state Agent in Canberra. Teleconferences were held with the remaining two state Agents. Interviews were conducted by the Project Manager, the Business Analyst and one other team member. Though not all members of the team were able to attend all the initial interviews in person, each member did attend at least one interview session and the teleconferences. The results were synthesised in a team setting, providing opportunities for all team members to build empathy and understanding of their users. Additionally, as the discovery process developed, the team undertook teleconference interviews and discussions that allowed more members of the team to be involved. The results from the user research were documented and provided back to Diabetes Australia and the Agents for review and confirmation. The team has also established a User Reference Group to allow online collaboration with users as an aid to developing user stories and user journey maps. Insights were categorised into major pain points and have informed decision making on product improvements.

The users for Phase 1 of the project are considered “internal” users i.e. they are staff at Diabetes Australia and the various NDSS state agents. However, the project team also reached out to selected members of the “external” user groups ( i.e. the Pharmacy Guild and a small sample of Access Points) in order to understand the end–to–end system processes.

The team documented user personas in detail, providing description of how they interact with the system and the functions they perform. The team continued to engage with the users, testing a range of functionality and gathering user feedback. In particular:

• Discussed and agreed business roles with key system users.
• Tailored user accounts to enable NDSS business roles and ensured that each user is able to perform the tasks and access the information required for their specific job role.
• Designed a multi-layered attribute matrix: a specific combination of system attributes provide specific access privileges to users to meet their needs.
• Adjusted field names using terminology that is more familiar to users.
• Updated error messages to ensure they are easy to understand and to provide suggested recovery path.

The team responded and adapted the solution to meet users’ expectations. The following are some examples where user feedback resulted in adaptation of solution design:

• Default user dashboard views have been determined and agreed with key users and tailored to meet the needs of all user groups for Phase 1.
• Addressed user concerns about searching capability by providing additional education on default out-of-the box functionality through training and UAT sessions. Also implemented some minor changes for consistency of search results display.
• Required program changes for Continuous Glucose Monitoring (CGM) products have added a number of new application forms and complexity around eligibility criteria. This additional work has been completed for Phase 1.
• Completed and tested Purecloud telephone system integration.

This has been well received by users and will make finding key information easier and faster.

The project team continued to resolve key UAT feedback with more than 30 issues/bugs from UAT 5 and 6 have been addressed and included for Phase 1 release.

Criterion 2: Have a multidisciplinary team

The team is collaborative and positive, with a good mix of experience and skills in the areas of project management, business analysis, application development, user Interface and user experience, and testing. Since Beta stage, the team continued to review their resource requirements, bring skills needed to complete Phase 1. The product owner is fully engaged and empowered with decisions being made at the correct level resulting in the decision making processes being quick and efficient. Senior executive support is available.

The team has well defined processes for knowledge sharing and on-boarding of new team members. New starters get a walkthrough from project SMEs; peer reviews; SharePoint; sprint reviews; and daily stand-ups. System design is well documented and the team uses a range of collaboration tools such as Octane, Sparx, SharePoint, and TRIM.

The project team has well-documented principles which were revisited to ensure they are still accurate and to get new team members familiar with them.

There was a good amount of sharing and cross-skilling apparent, with the product and delivery managers inviting experts from the wider department to support the team’s project work. For example, due to architectural similarities with the Department’s Health Products Portal (HPP), the team was able to tap into this knowledge to help inform some of its design process. The project team provided advice and assistance to other Departmental projects regarding the use of software products for the agile approach. The team also reached out to other Departments regarding common services such as security, identifying providers and data validation.

The team is highly motivated, multi-disciplinary and performing very well in adhering to the Digital Service Standard.

Criterion 3: Agile and user-centric process

The project is effectively using agile/scrum processes and is aligning work appropriately. The project team has produced an “Agile Method” booklet that outlines their principals, definitions and the team roles. The project team demonstrated the use of agile tools such as electronic Kanban, backlog refinement, sprint reviews, retrospectives and showcases. Agile Scrum methodology was refined to suit. It was changed to 3 week sprints incorporating backlog-grooming, user story refinement, sprint-planning, daily stand-up, sprint reviews, and sprint retrospectives. That was implemented in order to adjust to complex deliverables to reduce overheads for the team.

The team is using agile tools including kanban board and Octane as an agile development, delivery and management tool. Hypothesis statements and validating approaches have been captured as part of the confirmation process to ensure a delivery of user centric design throughout all stages of system delivery.

The team had to deal with some challenges that impacted the timeframes, resources and scope. In particular, the implementation of Continuous Glucose Monitors (CGM) v2 – including the ‘extension’ and ‘exemption’ requirements have very complex business rules. Even though the above challenges led to re-work, the team was able to adapt the system and complete some of the new requirements for Phase 1.Phase 2 will include additional functionality required for CGM v2 roll out.

Criterion 4: Understand tools and systems

The team is re-using and leveraging a technology stack used successfully in other areas of Health. The procurement costs and ongoing support costs in infrastructure and technical support will be minimised. It also aligned extremely well with future frameworks and overall technology directions in Health.

The NDSS Central CRM leverages a software-as-a-service (SaaS) Microsoft cloud arrangement involving online services. The team worked with the ITD Commercial Management Section to engage with the Whole of Government (WOG) volume reseller for Microsoft SaaS cloud products. As development has progressed, the D365 licencing requirements and environments has expanded. Data migration ETL has been built using SQL Server Integration Services. Azure Service Bus and Azure Apps have been added to support data integration.

The project team updated migration mappings to include business evolution, in particular additional CGM requirements. Successful data migration test runs have been completed and migration performance has been improved from 70 to 35 hours to better fit the change window.

The project team concentrated on integration capability that maintains data consistency between the NDSS Central CRM and the legacy NAV system. The integration development and testing team:

• enabled the collection of telemetry data to allow analysis of problems if they occur and to make this data available for monitoring purposes
• configured Serverless360 as a service health monitoring tool, raising alerts if adverse events occur such as Apps failing, messages building up on queues, Function Apps errors, etc.
• conducted testing to ensure integration orchestrations maintain data accurately in both NDSS Central and NAV systems.

The team also engaged with the department’s ITD Strategy and Governance Branch, Security and IT Services Branch to ensure products, services and licencing comply with Enterprise solutions, DTA, and ISM standards.

The NDSSE project team will be responsible for ongoing NDSS system development. Coordination with the project team is needed to ensure effective and efficient resolution of issues or defects while system development remains ongoing.

The NDSSE Project team will provide Level 2 (via a contracted supplier), Level 3 and 4 support for the operational NDSS Central system. The rationale for this approach is to leverage build expertise progressively created since 2018 to maintain consistency and direction of ongoing system development. The NDSS Central Standard Operating Procedures (SOPs) document defines the responsibilities and procedures for administering the NDSS Central CRM solution. SOP was further refined for go live and support plan was elevated to provide 24/7 access for engineers.

Criterion 5: Make it secure

The team has developed a project security strategy providing a framework for the delivery of a secure NDSS solution.

SaaS cloud arrangement determines a shared responsibility approach to security and privacy, security controls are clearly documented. The team analysed possible threats and risks for the system in preparation for penetration testing.

On 20 May the project team achieved ITSA approval for the migration of production data into the NDSS Central cloud tenancy.

On 28 May the project team submitted a package of security artefacts to Health ITSA for go-live security accreditation in accordance with Health’s IT Security Accreditation framework.

Since June the NDSS Central cloud tenancy has undergone further ‘hardening’. An additional 20 security risk treatments have been implemented or scheduled for implementation.

These 20 additional treatments complement the 73 security controls which the system had in place as at end of May 2019. The 93 security treatments and controls have been implemented across the following categories:

• access management
• business continuity
• cloud service provisioning
• data breach
• design
• logging
• security monitoring
• security assurance
• solution hardening
• user management.

Comprehensive penetration testing was conducted over August and September 2019 which identified three Medium and two Low risk vulnerabilities.

Medium risks have been treated and Low risks accepted and incorporated into the Security Risk Register.

In May 2019 a Privacy Impact Assessment was conducted which provided 12 recommendations directed at the Department of Health more broadly, Diabetes Australia and the NDSSE project team. All recommendations have been or are being addressed. Recommendations requiring immediate action to enable go live have been completed, other broader recommendations are being progressed by other areas in the Department and Diabetes Australia. The NDSSE project team will monitor the implementation of these recommendations and report on their completion.

The Department’s IT Security Adviser assessed the NDSS Central solution security posture between 28 May 2019 and 19 September 2019. A ITSA assessment report, recommending a Security Authority to Operate for 2 years, has been approved by the Department’s Chief Information Security Officer on 15 October 2019.

Criterion 6: Consistent and responsive design

The UX/UI team specialist reviews functionality and adapts designs to improve usability. Due to the use of the COTS product that is not fully accessible and has some limitations in creating fully responsive design, the user interface is developed to support both data entry functions and easy access to registrant information. System users top to bottom data entry with the same patterns used for paper form completion. Consistent navigation and screen design is used throughout the system, which were clearly demonstrated to the assessors during the demo.

Layout and theme adjustments were made to improve keyboard use and visual experience, to suit NDSS branding and to create a unique and recognisable environment for users. All custom sections utilise consistent design styles, such as font family and colour. Interface optimised for the platform and screen sizes on which it will be used. Application is functional in all supported web browsers. Content is consistent and written in the language of users of the system.

User testing and observation of users is fed back into design ensuring key information is easily accessible on the screen, making comments button easy to locate and providing flexibility for recording recipient’s contact information.

Criterion 7: Use open standards and common platforms

The service is re-using and leveraging a technology stack used successfully in other areas of Health and other government departments. During development, the project team actively adhered to open standards of development and common platforms where this delivers a secure and acceptable solution. The team is using a COTS product with minimal customisations that enhances Health’s existing D365 implementation. Microsoft Cloud layer used for the system is in line with open data design and functionality principles.

Criterion 8: Make source code open

Project is reusing/sharing code and documentation from other D365 projects within the Department of Health. The project is applying open standards and common platforms where this delivers a secure and acceptable solution. Code is owned by the Department and could be shared with other departments/communities if permitted and subject to compliance with government security standards and privacy legislation.

There are some concerns from ITSA that the code might reveal weaknesses allowing malicious actors to attack the system. This has been evidenced in recent security assessments in other systems.

Criterion 9: Make it accessible

The COTS product used for the system is not fully WCAG compliant, making it difficult for the team to create fully accessible product. However all the customisations implemented by the project team based on the user feedback follow the standard Health governance process for ensuring adherence to WCAG 2.0 level AA in both development and design protocols within the known limitations. Layout designed to improve keyboard and visual experience. Interface incorporates usability and accessibility standards. The team improved accessibility by changing the colour scheme adhering to colour contrast requirements, utilised icons in the traffic light type dashboard to avoid reliance on colour alone indicators, improved search capability, navigation consistency, page structure, improved label visibility, allowed for page and text resize with the reduced need for scrolling.

Content was developed following a user centred approach and written in the language of system users. Reference Guides and video walkthroughs of processes have been created to assist the learning curve.

The new version of CRM D365 has more accessibility features, improving system accessibly. The NDSSE application will be upgraded to a new version of CRM D365 before October 2020.

Further accessibility testing has been conducted using manual and automated testing. Improvements were made where possible to address identified issues, ensuring that new custom sections utilise consistent design styles in accordance with WCAG 2.0.

Criterion 10: Test the service

The team has a comprehensive multi-layered test strategy in place. It covers usability, accessibility, unit (developers), system, and user acceptance testing. Test plans for each stage of the project have been developed. Test cases; execution/defect reports; test summary reports are generated for each sprint. Unit testing has been conducted by the Development team in the Dev environment. Data Migration testing, Integration testing, System testing and Regression testing has been conducted on several Test environments by the NDSSE test team.

Internal Dev team has simulated 105 users to run load testing and understand the impact on the performance of the system.

End-to-end user testing has been completed with specific user role scenarios in both face-to-face settings and remotely allowing for direct user feedback. The team with the assistance of the Health testing team conducted five rounds of User Acceptance Testing for the NDSS Central CRM with representatives from DA and all NDSS Agents. All the User groups have been involved throughout the Beta stage and will be involved in Data Migration and Integration UAT.

Testing results and general feedback were captured and categorised as a defect, enhancement, business process, training issue or policy issue. These items were discussed with the project team and prioritised for resolution between testing rounds.

Security and Penetration testing has been performed by an external consultant on the integration Test environment. Results from this testing has informed the security accreditation of the NDSS Central Phase 1 CRM solution. It further resulted in implementation or scheduling of implementation of a number of additional treatments to improve the security posture of the solution.

Criterion 11: Measure performance

The team will measure user satisfaction through Qualitative User feedback on adoption, satisfaction, effort/time spent on administrative tasks; reduction in form errors and redirection of resources to deliver other NDSS services.

A user satisfaction survey was conducted following the Super User training sessions - 76% of respondents rated the training overall as very good or excellent.

It is planned to conduct a user satisfaction survey following the Phase 1 release, periodically following subsequent releases then at regular intervals following release.

Digital take-up will be 100% as all users will use NDSS Central instead of the legacy systems. The team is planning to use Microsoft Azure monitoring tools to measure usage, performance and availability.

For Completion rate user experience will be monitored in the Live phase as more users access and interact with the environment.

Although cost has not been a driver for the project, it is expected the processing of registrations will be made more efficient allowing for the redirection of resources to deliver NDSS support services. The team is investigating how to model cost per transaction on an annual basis. For example, the number of transactions over a 12 month period X costs to deliver the services (such as, usage costs, licence costs, resources costs). A cost per transaction could be modelled on an annual basis. Project team created a baseline for future performance measurement based on 20 people trial.

There is not a Performance Dashboard for this service. With the provision of supplementary advice from DTA, Health will explore establishing a Performance Dashboard for this service.

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

To maintain support and continual engagement with Health Professionals and registrants future phases will continue to include manual application forms and processes for those who have limited access to electronic transactions.

It is anticipated that non-digital engagement will reduce over a period of time whilst retaining current manual processes.

Criterion 13: Encourage everyone to use the digital service

The project team developed the following take-up strategies:

• The established Transition Working Group and Transition plan has guided implementation activities.
• The project team used targeted communications announcing NDSS Central, key functionality, what’s new and improved usability features as development progressed.
• Electronic FAQs, extensive reference guides and training modules have been prepared/updated regularly and are accessible via the NDSS Central training environment.
• DA, NDSS Super Users and Health program staff participated in a Train the Trainer program, as well as supplementary training for the development of additional functionality
• Training environment has been updated with full functionality and production data - available for all users from September through to planned go live.

Future phase - NDSS Online Portal

Subsequent phases of the project will provide alternative channels (to paper-based forms) for health professionals, hospitals, medical centres and diabetes clinics.

The HP NDSS portal is subject to a separate DTA pathway – Alpha assessment has been completed in December 2018.