Presentation to the IEEE Toronto Section on designing health apps that work.

1. CREATING THE NEXT
GENERATION MHEALTH APP:
A REFERENCE ARCHITECTURE
Karim Keshavjee MD, MBA, CCFP, CPHIMS-CA
Pannel Chindalo, PhD
Arsalan Karim, MD, MBA
Ronak Brahmbhatt, MD, MPH
Nishita Saha
Ryerson University, Feb 27, 2017

2. OUTLINE
• Background
• Challenges
• Complexities, rabbit holes and confusion
• Solution
• Reference architecture
• Conclusion

3. BACKGROUND:
MOBILE APPS ARE TAKING OFF

4. DOCTORS WANT TO RX HEALTH
APPS

5. BUT: HEALTH APP USE IS LOW

6. WHY?:
HEALTH APPS DON’T WORK

7. SOME EXCEPTIONS
Use a
wearable
fitness
tracker
Use a smart-
phone application
Do not use a
device or app
Plan to start
using a device or
app

8. TYPE 1 DIABETES APPS
• Patients have traditionally
always written down their
insulin dosages and their
blood sugar readings
• Apps are a natural
replacement of paper logs and
provide some additional
useful functionality
• But does not apply to Type 2
diabetes, who make up 90% of
patients with diabetes.

9. COMPLEXITIES, RABBIT HOLES AND
CONFUSION
What is preventing patients and health
practitioners from adopting mHealth
apps?

10. METHODS
• Searched: PubMed & Google Scholar
• Used gap analysis: that drew on philosophy, data science,
education, life science and business analyses methods to
develop a concept that would overcome the constraints and
meet the goals identified
• Through analysis, discussion and iteration: arrived at an
evidence-informed proposed architecture
• Works within the framework of clinical practice
• Values the patient-physician relationship
• Uses scientifically validated tools effectively

11. OUR PUBLICATION

12. 9 BARRIERS TO MHEALTH USE
Conflicting Information: App provides information that conflicts
with that received from health care providers (Bierbrier, Lo & Wu,
2014);
Health Literacy: Language and terminology of the app may not be
compatible with the patient’s health literacy (Caburnay, 2015);
Data Entry: Patient has to enter the data themselves (Gruman, 2013);
Meaningful Use: Patient cannot use information in a meaningful
way;
e.g., he or she cannot order diagnostic testing or prescribe
medications to himself or herself;
Lack of incentives like cost saving or social approval;

13. BARRIERS TO MHEALTH USE
(CONT’D.)
Not Habit Forming: Daily use of the app is not required and
therefore the patient does not get into the habit of using it;
Unknown Provenance: Providers don’t value data collected by
patients in apps downloaded from an app store whose
provenance and pedigree is not known or established (Terry, 2015);
Lack of Tools: There is no way for providers to consume the large
amounts of data that are collected in apps (Terry, 2015);
i. i.e., visualize, analyze, derive meaning from;
Lack of Interoperability: Providers unable to integrate app data
into their own (EMR) for analysis or follow-up or share the data
in their EMR with their patient’s apps (Abebe, 2013).

14. AT HEART – INFORMATION
ASYMMETRY…

15. …AND INFORMATION CREDIBILITY
Doctors are trained to trust only their own data
Patient-entered data is not trusted

16. OPEN MHEALTH GROUP
 Lots of technology and data
× No workflow or information

17. ENGAGING THE PATIENT
Does not happen in a vacuum

18. GAMIFICATION IS NOT ENOUGH
• Patient engagement needs to be rooted in science, not games
• Need behavior change models with evidence behind them
• Prochaska’s Model
• Behavior Change Wheel
• Commitment needs to be cemented
• Accountability to health care team
• Follow-up by physician and their staff
• App is ‘prescribed’ from EMR which activates App
• Doctors are regulated by their colleges and are expected to
act according to professional rules

19. SOLUTION:
NEEDS LOTS OF INFORMATION (DATA)
A. Healthcare without data is meaningless
B. Must meet evidence-based content and
process requirements
C. Also need to track patient experience and
outcome measures

20. Solution:

21. APPLICATION TO
DIABETES TYPE 2 APPS
• We developed screening criteria using our reference
architecture for design and development of mhealth apps,
• Apple iTunes and Google Play app stores were searched for
diabetes apps –found 201
• Following a calibration exercise, two individuals
independently reviewed and evaluated each app against the
screening criteria
• Data was collated and analyzed

22. RESULTS:
• 201 total apps were reviewed
• No app met all the criteria outlined
• Most apps were replacement of paper journals or diaries
• Many apps were recipe apps
• Majority of the apps provided education/recommendations
• Most of the apps failed at integrations with devices
(glucometer, BP machine) and patients medical records (EMR,
primary care provider)

23. RESULTS

24. SCORES (MAX = 15)

25. WE INTERRUPT THIS
BROADCAST…..
• Bluestar is a new diabetes
app that must be prescribed!
• It recently obtained FDA
approval
• Got a score of 12 (out of 15)
on our rating scale
• Very promising development

26. REASONS FOR NOT MEETING
CRITERIA
• Many apps were conference apps or guideline apps for
professionals
• Of the highest scoring apps, major reasons for not getting a
higher score
• Lack of integrations with devices–relatively easy these days (but
requires FDA approval)
• Lack of integration with EMRs –many features are dependent on
this

27. DISCUSSION
• There is great need for high quality apps which can be
prescribed by a physician and whose use can be monitored by
the health care team
• Apps need to focus on managing the whole patient along with
their disease and not a small part of a patient’s care such as
self management
• Better embedding physician patient relationship into patient
app interactions for provider guided management

28. LIMITATIONS
• Due to budgetary constraints, we did not download apps from the
stores
• Some vendors had poorer descriptions of their product than
others
• A very small number of apps were in languages that are not
understood by the people conducting the review
• We were not able to quantitate which apps are used and which
ones are not
• We did not include any patients in defining the criteria nor in
reviewing the apps.

29. RECOMMENDATIONS
• Apps should be prescribed and monitored by health care
providers
• Requires participation of EMR vendors in developing APIs for apps
• mhealth app certification by a standards organization would go a
long way to ensuring higher quality apps and increasing the level
of trust for apps by health providers
• An Interoperability Kit for EMRs and Apps would help make it
easier to deploy an app
• Standard interoperability for apps with medical devices would
lower the investments required to create good apps

30. CONCLUSION
• mHealth Apps show lots of promise, but not being used
• Information asymmetry, data credibility and entering own
data are main causes
• Engagement framework requires a commitment to
communication and empowerment
• Need to use scientific, proven behavior change models
• Needs to be grounded in clinical practice and within the
patient-provider relationship –needs to support on-going
communication and interaction after the visit is over

31. CONCLUSION
• Health behavior changes are difficult to sustain
• Need external motivation and commitment –App needs to
be “prescribed”
• Needs consistent follow-up and reinforcement
• mHealth Apps need to have bi-directional integration with
EMRs
• Need to collect lots of experience, process and outcome data –
lab, questionnaire and system use data
• Use the data to constantly improve the user engagement and
user experience
• Use the data to improve patient disease outcomes

32. REFERENCES
Chindalo P, Karim A, Brahmbhatt R, Saha N, Keshavjee K. Health Apps by
Design: A Reference Architecture for Mobile Engagement. International
Journal of Handheld Computing Research (IJHCR). 2016 Apr 1;7(2):34-43.
Balouchi S, Keshavjee K, Zbib A, Vassanji K, Toor J. Creating a Supportive
Environment for Self-Management in Healthcare via Patient Electronic
Tools. Social Media and Mobile Technologies for Healthcare. 2014 Jun
30;109.
Brahmbhatt R, Niakan S, Saha N, Tewari A, Pirani A, Keshavjee N,
Mugambi D, Alavi N, Keshavjee K. Diabetes mHealth Apps: Designing for
Greater Uptake. Studies in health technology and informatics. 2017;234:49.