The document discusses the need for a risk-based validation framework for digital health tools. It identifies several components that could be used to assess the risk level of an e-health application, including the domain, users, aim, intervention depth, user health status, data handling, and integration of elements. A list of 10 potential components is presented. Feedback is sought to expand this list and further develop a framework that links risk analysis to the appropriate validation mechanisms in order to reduce unnecessary validation demands while still ensuring proper validation practices based on risk.
6. CORE PROBLEM:
Current systems to assess modern digital (E-) health tools
are often NOT sufficiantly tailored to cater for the specific
qualities of these new digital developments, often leading
to unnecessary heavy validation demands
HKU
7. CORE PROBLEM:
PULL THE HEAVY WEIGHT WHERE THE RISK IS HIGH
MAKE IT LIGHTWEIGHT WHERE THE RISK IS LOW
HKU
8. WHY IS THIS A PROBLEM?
RCT validation takes a lot of time…
… costs a lot of money
… raises the threshold for small enterprises
…. delays the critical time to market
…prolongues the ‘valley of death’
HKU
9. FOR WHOM IS THIS A PROBLEM
Transparency for patients, informal carers, health professionals,
insurance companies, policy makers
Developers and enterpreneurs
HKU
10. WHAT WE WANT TO ADDRESS
KEEP OUR FOCUS ON PROPER VALIDATION PRACTISES
IMPROVE NATIONAL RISK ANALYSIS SCHEMES LINKING
TO THE RIGHT VALIDATION MECHANISMS
HKU
11. WHAT WE TRIED TO DO!
TO IDENTIFY POSSIBLE (!) BUILDING BLOCKS
OR COMPONENTS
FOR A MORE ACCURATE
RISK ANALYSIS FILTER
HKU
12. WHAT WE DID NOT TRY
TO SOLVE THIS COMPLEX ISSUE
OR PRETEND WE CAN
HKU
13. WHAT WE IDENTIFIED:
In which domain is the application situated
I pre care
II community care
III (low) complexity care, cure or training
IV high complexity care, cure or training
1
HKU
14. Who is or who are the end users?
Patient? Doctor? Combination? etc..
WHAT WE IDENTIFIED:
2
HKU
15. What is the intended aim of use?
Examples:
‘empowerment’, ‘diagnostics’, ‘monitoring’, treatment
WHAT WE IDENTIFIED:
3
HKU
16. What is the intervention ‘depth’ of the application?
WHAT WE IDENTIFIED:
4
HKU
17. What is the user status?
(with the health ‘consumer’ as end user)
healthy (general life style intervention / advice / nudging)
healthy with risk of falling ill
(focussed lifestyle intervention, advice, nudging)
temporary ill (recovery support, enhancement)
chronically ill (lifestyle modification, continuous monitoring, acute
intervention in escalation)
WHAT WE IDENTIFIED:
5
HKU
18. medical professional as end-user
1. involved in part of the execution of treatment
(monitoring, care support, signalling)
2. responsible for treatment
(planning, communicating, follow up, monitoring)
3. responsible for coordination of various stakeholders in
treatment
(community care, home care, intramural multidisciplinary setting)
4. responsible for execution of complex medical interventions
(doctors, surgeons, psychiatrists etc.)
WHAT WE IDENTIFIED:
6
HKU
19. Actual data profile (risk)
What type of data is actually transferred or stored?
Locally, server side? Encrypted?
WHAT WE IDENTIFIED:
7
HKU
20. Integration
How to handle applications containing one or more elements from
this collection? Will the most heavy define all? Differentiated
validation?
WHAT WE IDENTIFIED:
8
HKU
21. Specific game related
1. functionality, is the game playable (withou bugs or procedural
errors)
2. validity of the game design, parametrisation
WHAT WE IDENTIFIED:
9
HKU
22. Specific game related
Effectivess of a game as intervention includes
1. Ease of use
2. the impact of the serious game on the end user within the
set therapy, context or domain
WHAT WE IDENTIFIED:
10
HKU
23. WHAT WE ASK YOU?
CAN YOU HELP US EXPAND THIS LIST
TO SET THE AGENDA
FOR FURTHER DEVELOPMENT
OF THIS KIND OF ARTICULATED FRAMEWORK
IN ORDER TO AVOID…
?
HKU
24. WHAT WE ASK YOU?
CAN YOU HELP US EXPAND THIS LIST
TO SET THE AGENDA
FOR FURTHER DEVELOPMENT
OF THIS KIND OF ARTICULATED FRAMEWORK
IN ORDER TO AVOID…
HKU