The project consists of 3 major phases:

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

This report is for the Beta assessment of Phase1 - NDSS Central (Dynamics CRM 365).

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 5 state sites and with representatives from one state Agent in Canberra. Teleconferences were held with the remaining 2 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. 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:

• form field layout and flow was adapted to make it easier for data entry users to process forms, where only relevant data are collected
• detection and reuse of existing contact records during data entry
• traffic-light Registrant summary of key contact information was included following User feedback.

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

The project team implemented the plan for further improvements to the system based on the user feedback and due to policy changes, taking a phased approach and identifying priorities.

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 Alpha, the team has expanded to include resources with skills in data synchronisation to manage the data migration and integration with existing legacy systems. 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
• daily stand-ups.

System design is well documented and the team uses a range of collaboration tools such as Octane, Sparx, SharePoint, and TRIM.

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, resulting in delays in progressing some aspects of the build. Some of the examples include:

• although the MVP was clearly documented and articulated for Phase 1 release, it has changed due to impacts of policy and program changes external to the project
• the dependency on third party resources contracted through DA (and not directly by Health) has led to communication issues, inability to control time and resources
• issues raised late in the development phase by the contracted NDSS service provider (DA) regarding assigned user roles and access to information not previously provided to all users.

Even though the above challenges led to re-work, the team was able to adapt the system by locking access to certain user types to some functionality, such as, export data, mailing lists, reporting etc.

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 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.

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.

On 29 May the team started up a penetration testing process which will evaluate 2 principal threat scenarios:

• Scenario A: an external user is trying to obtain unauthorised access to the NDSS Central CRM to exfiltrate data and to sabotage the solution.
• Scenario B: an internal user with no administrative privileges is trying to exfiltrate data and to modify solution security configuration settings.

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 have 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. 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.

Further accessibility testing is planned before go-live.

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 5 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.

Performance and Load testing on the integrated systems will be done on the Pre-prod environment by an external consultant. Security and Penetration testing will be outsourced to an external consultant.

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. It is planned to conduct a user satisfaction survey following initial training and 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 in the Beta phase will be monitored 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).

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:

• establishment of a Transition Working Group and Transition plan to guide implementation
• targeted communications announcing the NDSS Central, key functionality, what’s new and improved usability features
• electronic FAQs, reference guides and training modules accessible via the NDSS Central training environment
• train the Trainer program for DA and NDSS Super Users
• Beta (Training) environment available for all Users from June 2019 through to planned go-live.

Recommendations

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.