The NordDEC begins with a series of questions to capture a Digital Health Technology’s (DHT) core purpose and functionality. These include the target audience, the type of data the DHT collects and the DHT’s primary functions and features. None of the scene setter questions are intended to have any scoring or risk implications and are purely to decide on the line of enquiry further in the evaluation.
Data and Privacy
Initially, the NordDEC identifies the relevant privacy policy for the DHT, which is available to users through the DHT and/or the App Store or Play Store. Once it is established what data is collected by the DHT, the NordDEC looks at how that data is used and shared, and if this is communicated to the user.
The data privacy policy should inform the user of where their data is stored, how their data is protected in storage, and how it is protected in transit between the user’s device and the host storage. The NordDEC looks for specific and secure storage techniques, such as encryption or firewalls. The transparency of the privacy policy should extend to inform the user that any links to third party websites or DHTs are not covered by the developer’s privacy policy, and users should make themselves aware of such third party policies.
For DHTs that collect and process personal and/or sensitive data, they will undergo the questions focused on the General Data Protection Regulation (GDPR), which in May 2018 came into force to replace the Data Protection Act 1998.
In the NordDEC there are further checks carried out within the data area that does not necessarily need publicly available information.
Professional Assurance and Clinical Safety
Following on from the questions answered in the Scene Setter section, this review area looks at a range of ‘indicators’ of Professional and/or Clinical Assurance.
If the DHT requires registration with a relevant regulatory body, we look for evidence of this such as registration with the Care Quality Commission (CQC).
With relation to medical devices, we first assess if the DHT is likely to be a medical device under the current guidance from the MDR (Overview ). We then evaluate if the DHT displays the relevant CE mark.
When we examine the evidence of effectiveness we use the Evidence Standards Framework published by NICE.
We also look for evidence of an appropriate professional being involved in the DHT’s design and development, or if the DHT has been externally accredited.
The Clinical Safety Assessment looks into whether the DHT developer put in place appropriate measures to assess and mitigate any potential clinical risks which may arise from the use of the DHT. This relies on looking at risk management documentation which the developer may have and assessing whether it covers the key areas. The assessment is undertaken in conjunction with a trained Clinical Safety Officer, who is able to comment and evaluate on both the risks recorded, and the suitability of the developers whole process.
Usability and Accessibility
This section of the evaluation looks into DHT design, accessibility features, usability and user experience, forums and moderation, and support options.
The NordDEC considers the design and development of the DHT and whether it considered any recognised DHT design standards, such as WC3, WCAG 2.0 AA, WCAG 2.1 AA, ISO 9241, Apple HIG, or Android App Quality Guidelines. The evaluation also considers whether there was any user involvement during the development of the DHT, or if any features were based on user feedback.
Security + Technical Stability
Security is one of the most challenging area for Digital Health assessments.
Overarching principles such as the OWASP guidelines for mobile and web applications provide a very high level frame of reference but this doesn’t equate to a very clear set of measurable requirements.
Whilst OWASP does differentiate between different types of applications, it is a relatively crude 2 tier model and does not account for the wide range of different features and functions that digital health solutions offer.
The focus is therefore switching now to a more tangible but flexible requirement that focuses on a graduated or tiered model with expected relevant security ‘credentials’ increasing as the complexity and risk of the relevant product increases.
This enables the specific features of the DHT and its associated security risks to be calibrated and aligned to different security characteristics/credentials.
This is however still an evolving model and the security ‘credentials’ can change in differing jurisdictions.
Interoperability
Interoperability looks to establish how well the product exchanges data with other systems. In particular, we are interested in how the product interoperates with clinical or healthcare systems, rather than other apps.
To provide a seamless care journey, it is important that relevant technologies in the health and social care system are interoperable, in terms of hardware, software and the data contained within. Where there are Application Programme Interfaces (APIs), these should follow the relevant best practices, be documented and freely available, and third parties should have reasonable access in order to integrate technologies.
Good interoperability reduces expenditure, complexity and delivery times on local system integration projects by standardising technology and interface specifications and simplifying integration. It allows it to be replicated and scaled up and opens the market for innovation by defining the standards to develop upfront.
To view the full assessment framework questions documentation, please click here.