A talk I gave to the Oxford UX group, on medical apps and the challenges of balancing creativity with regulatory approval

1. Medical Apps – Applying Usability Principles
Disclaimer:
These are
my personal
views

2. 1968 , Apollo 8
The smartphone in
your pocket is more
powerful than all the
tech put together on
the Apollo 8

3. Global Mobile Medical Apps Market
to Reach $11.22 Billion by 2025,
Reports BIS Research
Big Data and AI in present
and future healthcareHow wearable devices can help solve
issues plaguing the Indian healthcare
industry
Healthcare Industry
Scores Low on Data
Security Knowledge
Virtual health is the
future healthcare
Amazon Reportedly Building
Healthcare Team for Alexa So You
Can Ask If That Cut Looks Infected
FDA issues 'recall' on heart implants
for security firmware update
Poor mHealth App Usability
Limits Patient Engagement

4. The mHealth market is growing

5. 36 mHealth apps
account for half of all
downloads

6. Some mHealth apps
are medical devices
• And the Regulators want to
regulate them

7. Mobile Medical Applications - Guidance for Industry and Food
and Drug Administration Staff, 2015
The FDA intends to apply its regulatory oversight to only the subset of mobile
apps:
If the app causes harm by not functioning as intended…

8. 1. Mobile apps that are intended to
provide access to electronic “copies”
(e.g., e-books, audio books) of medical
textbooks or other reference materials
with generic text search capabilities.
Do not need to be regulted

9. 2. Mobile apps that are intended for
health care providers to use as
educational tools for medical training or
to reinforce training previously received.
Do not need to be regulted

10. 3. Mobile apps that are intended for
general patient education and facilitate
patient access to commonly used
reference information.
Do not need to be regulted

11. 4. Mobile apps that automate general
office operations in a health care setting
and are not intended for use in the
diagnosis of disease or other conditions,
or in the cure, mitigation, treatment, or
prevention of disease.
Do not need to be regulted

12. 5. Mobile apps that are generic aids or
general purpose products. These apps
are not considered devices because they
are not intended for use in the diagnosis
of disease or other conditions, or in the
cure, mitigation, treatment, or
prevention of disease.
Do not need to be regulted

13. Regulated
1. Mobile apps that are an extension of one
or more medical devices by connecting to
such device for purposes of controlling the
device(s) or for use in active
patient monitoring or analysing medical
device data.

14. Regulated
2. Mobile apps that transform the mobile
platform into a regulated medical device by
using attachments, display screens, or
sensors or by including functionalities
similar to those of currently regulated
medical devices.

15. Regulated
3. Mobile apps that become a regulated
medical device (software) by performing
patient-specific analysis and providing
patient-specific diagnosis, or treatment
recommendations. These types of mobile
medical apps are similar to or perform the
same function as those types of software
devices that have been previously cleared or
approved.

16. Mobile apps that help patients with
diagnosed psychiatric conditions
(e.g., post-traumatic stress disorder
(PTSD), depression, anxiety,
obsessive compulsive disorder)
maintain their behavioural coping
skills by providing a “Skill of the Day”
behavioural technique or audio
messages that the user can access
when experiencing increased
anxiety.

17. Mobile apps that provide periodic
educational information, reminders,
or motivational guidance to smokers
trying to quit, patients recovering
from addiction, or pregnant women.
Discretion

18. Mobile apps that use video and video
games to motivate patients to do
their physical therapy exercises at
home.
Discretion

19. Mobile apps that are intended for
individuals to log, record, track, evaluate,
or make decisions or behavioural
suggestions related to developing or
maintaining general fitness, health or
wellness.
Discretion

20. European Commission Regulation for
Medical Apps
MEDDEV 2.1/6 2016

21. The European commission has
produced a useful flowchart to
identify whether your app will be
covered by the Medical Device
Regulations

22. FDA EU

23. FDA EU?

24. Step 1: To encourage adherence.
-To gather data on how effective the patient’s
treatment plan is.
Next step: To establish clinical claims
for apps
-And persuade payers to pay for them
What is big pharma doing with apps?

25. Dexcom G6, an integrated
continuous glucose
monitoring

26. Kardia Mobile Mobile ECG Monitor by AliveCor

27. EpiFinder application to help
differentiate between epilepsy
syndrome or another diagnosis in
adult patients.

28. Usability Principles

29. Device
Use
Correct use:
Safe and effective
Use error:
Unsafe or ineffective
Use environment
User
User interface
What the Regulators want…

30. User Research
CONTEXTUAL RESEARCH
ETHNOGRAPHIC STUDIES
USABILITY AND DESIGN CONTROL FOR MEDICAL DEVICE APPS
Design Verification
USABILITY RESEARCH
FORMATIVE STUDIES
Design Validation
SUMMATIVE STUDIES
PRE-MARKET SUBMISSION

31. • Documenting the process
• Traceability
• Protocol-driven testing
• Assumes semi-fixed prototypes
• Good Document Practice
• Use-related risk assessment
• It takes time!
• Pharma companies work on long lead times
Challenges of developing apps within Design Control

32. • Clinical claims (e.g. improving asthma
control) need clinical data
• Clinical data must be based on a
controlled clinical trial
• Clinical trials take a long time
• Once the clinical data is pinned to an
app, the app design cannot be changed
• If you change the app after the clinical
study, it must be revalidated
Challenges of developing apps with Clinical Claims
Clinical claim
HF validation

33. Ensure that the app
you are testing is as
close to finished article
as possible.

34. Focus on the most difficult tasks that may
be new or specific to that interface
And those associated with ‘Severe Harm’
© Geoff Mcfetridge

35. If holding rough and fast guerrilla style
usability sessions, asking participants to
complete the tasks that are difficult,
unique and specific to that app or
interface will provide much richer
feedback that will be much more useful
in improving the design.
© Geoff Mcfetridge

36. Use a combination
of closed and
open-ended
questions to get a
good mix of
feedback.

37. Our approach
Test interfaces and design concepts using a range
proven and effective methodologies such as;
• User interviews
• Tree testing
• Card sorting
• Paper prototyping
• Wireframing
• Low and high fidelity prototypes
• Video analysis and screen recording

38. Participant interviews
are recorded, with
cameras targeting
both the screen and
participant. The
interviews are
conducted in a
structured, relaxed
style using a mix of
closed and open-
ended questions,
meaning dialog from
the participants
containing useful
insights is not missed
and can be discussed.

39. Paper prototyping can
be used to analyse the
app prior to
conducting the study
so a strong
understanding of the
apps hierarchy can be
made by all those
involved in testing.

40. Linked technology Tools Used
The phone running the prototype app can be mirrored and recorded,
allowing the observer to see all the interactions the participant makes,
take notes and discuss with the moderator any points of discussion that
can be further explored.

41. Markers can be placed
on iPhone screens to
show all of the
touches and swipes
the participant would
make.

42. Video footage of the
recordings taken from
the screen and our
cameras can be
combined onto one
video. This means no
interactions are lost
that aren’t captured
by the software and
the two can easily be
watch side by side.

44. Using the video footage and notes taken from the session we can analyse
the prototype and identify problem areas.
These problem areas then be presented via heat maps generated over
screenshots of the app to visualise problem areas. Hierarchy maps can also
be used to visualise problem routes within the app.
The combination of video footage and observer notes allows the session to
be replied multiple times ensuring that no insights that could be useful to
the development of the app are missed.

45. Heat maps can be
generated to display
problem
icons/features within
the app.
Different colours can
be used to signify
the frequency of
which those errors
occur.

46. Hierarchy Map

47. Hierarchy Map

50. We aim to uncover..
Why some users of mHealth apps continue to use the apps for a long time, and why some users
stop using the app after a short period of time.
Are there trends within users characteristics and personal traits that can be clearly defined between
the two groups?
From these findings can design principles be made to reduce drop off rates and keep all users better
engaged?
Our own funded research project:

51. Thanks for listening