Katherine Atkinson is a PhD student at the Karolinska Institutet in the Department of Public Health Science.
Cameron Bell has a B. Eng from McGill and is the lead technical architect for the project.
Kumanan Wilson is a physician and senior scientist at the Ottawa Hospital, Professor of Medicine at the University of Ottawa, and lead at the
As they accumulate their “10,000 hours” of caring for patients or examining the health system, health care providers and researchers often come up with great ideas on how the system could be improved. The advent of digital technologies and mobile apps has helped to tear down the barriers to introducing these newly devised solutions and created opportunities for a new breed of medical entrepreneurs. You may want to build an app that will help you get critical information to your patients because you know this is why they are having trouble staying healthy. Or perhaps you want to empower them to manage their own health care by tracking aspects of their health. Or maybe you have an idea that could allow physicians to do simple diagnostic tests at the bedside using smartphones.
At the beginning of 2018, there were almost 100,000 health apps on the and . Health and fitness apps are cited to have the highest user retention rates, engagement, and frequency of use, with the latter having . mHealth apps have been shown to , appointment attendance rates and adherence to therapies. Despite this, there isn’t a whole lot of information to guide people through the development and deployment of mHealth apps. Based on our experience developing several apps, both for research purposes and for public release, here are 5 pointers to get you started.
1. Is a mobile app the best solution?
One of the first questions we often hear is “should the app be available on Android, iOS or both”? Instead, think about your users – when and how often will they be interacting with the solution? Will they be using the product to enter information, access it or both? Does it require an internet connection? Is the information complex, or is there a lot of it? That might be better suited to larger screens. Finally ask yourself, “Could the same solution be provided quicker, cheaper and easier through a website?” Overall, mobile apps have more significant barriers to use than websites, given the number of steps a user must take to download and begin using an app.
You may want to consider whether your idea might be best suited to a chatbot or virtual assistant interface. These new types of apps leverage conversational contexts and infrastructure provided by systems like Apple’s Siri, Facebook Messenger, or Amazon Alexa, and can potentially reduce barriers to your users interacting with your product.
If you decide that a mobile app is best, you will need to decide which kind of technology to use to build your app. Some technologies are referred to as ‘native’ and will require you to code the app once for each operating system you intend on making the app available for. Others are called ‘hybrid’, and these technologies allow you to code the app only once while still offering the app on multiple operating systems. Your decision will largely center around the tradeoff between performance of the app and development cost.
Native apps have better performance, often resulting in a better user experience(5). However, they are more expensive to develop because you need developers who specialize in each OS you wish to support, and you will need to maintain multiple versions of your application throughout its lifetime. For example, we have developed CANImmunize natively for both iOS and Android platforms, and consequently we require both Android developers and iOS developers on our team. The other, less expensive option is to , which is developed once using web technologies which are supported by most operating systems. While it is less expensive, at present, hybrid user interfaces are rarely as smooth and polished as those of native apps. For an app that is not designed to be used every day, this trade-off in performance might be acceptable and get your product into the app store sooner and at a lower cost.
Whatever choice you make, you should also consider giving your users the ability to export their data in ways that could make your app interoperable with other apps or systems. There are many standards and terminologies that can be used to make this possible, but HL7® FHIR® and SNOMED CT would be a good starting point.
2. Understand the “Rules”
A psychological barrier to many in creating an app is the daunting prospect of learning the laws and best practices related to privacy and security of personal health data. If your app will store health data on behalf of your users, you should always be keeping an eye on the relevant legal, privacy and security legislation and regulations in your jurisdiction. In Canada, if you are developing an app as a commercial entity, you must comply with the Personal Information Protection and Electronic Documents Act (PIPEDA). This law is not specific to health information, and as such, many provinces and territories have their own health information privacy laws which more clearly govern how personal health information can be collected and used, and by whom. Ontario’s Personal Health Information Protection Act (PHIPA) is one such example, and in our opinion, adhering to the principles and regulations of this law will provide a solid foundation for your app’s privacy program.
If your application is to be made available to users in the United States, you should investigate whether the American Health Insurance Portability and Accountability Act (HIPAA) applies, and if so, you should ensure you are compliant.
You should also be aware of the General Data Protection Regulation () which applies to all companies that collect and process data belonging to European Union (EU) citizens, even if this occurs outside of the EU. The GDPR articulates best practices for data privacy and security, specifying how entities build their data security programs, conduct which includes breach notification and a right to data erasure.
If you are collecting or storing personal information, or personal health information, think about where it will be stored. If it resides on the individual’s device, you should at a minimum, provide users with methods to protect it. Examples of this include an in-app password or fingerprint authentication. Some challenges you may encounter with on-device data storage is that if someone damages or loses their device, their data will be lost too. This can be frustrating to users and discourage them from using your product. To avoid this, you can store your users data on a server. This allows people to access their data from any of their devices. However, establishing a secure server environment can be onerous and expensive. If your institution already has one, using it would help you minimize costs. Another option is to provide your users the ability to back up their data to their own cloud storage solution, like iCloud or Google Drive.
Either way, you will likely hear about three different assessments you should conduct: a privacy impact assessment (PIA), threat risk assessment (TRA) and technical vulnerability assessment (TVA). The PIA will assess the privacy risks your product could create. The PIA will include documentation on the background and purpose of the product, data elements and flows, privacy program elements. The PIA will also identify the risks and provide recommendations to address them. While privacy impact assessments are often useful when conducted internally, it is considered a best practice to have assessments of your system performed by an objective third party.
Through a TRA, you will identify and classify all the potential technical, operational, reputational, and legal risks incurred by making your app available to the world, and as a result, put in place measures to mitigate or manage these risks. A TVA looks very specifically at the technological security and functionality of your app to identify, classify, and prioritize vulnerabilities in the software.
In most cases, other than when mobile health apps act as a medical device or accessory to medical devices, regulatory approval is not necessary. Most publicly available health apps would be categorized as minimal risk and thus, the evaluation of these products has fallen to the academic community - or to the marketplace itself. As a result, evidence on the efficacy, effectiveness or accuracy of information is . This does, however, present an opportunity and advantage for our medical entrepreneurs who likely already work in environments where evaluation of clinical interventions is commonplace and well understood.
3. Be Agile and Listen to Your Users
Technology changes rapidly – and likely so will your idea. Remember the problem you are trying to solve and remain focused on that problem. However, be prepared to adapt as you learn about the strengths and weaknesses of your solution and, most importantly, what your target audience thinks about it. It is unlikely you can know what the product will look like at the beginning of the project. In software development, this approach – of beginning with a minimally viable product and then rapidly iterating based on user feedback and new knowledge – is referred to as agile development. They key messages from agile is the importance of getting a product to users quickly and the recognition that this product will be constantly changing.
And remember, if you are going to have tens of thousands of users, you are likely going to need a user support team. We have used Zendesk to help manage incoming feedback, marketing requests and privacy inquiries. We aim to always respond within one business day and make sure our users are supported as the product evolves.
4. Evaluate your product (and keep evaluating)
In your Agile cycle, you are going to be releasing multiple versions of the app. When you are introducing new features, or making changes, it can be intimidating – here is how we approach it. First, we define the business requirements of the feature/ change. Then, they are converted into technical requirements and handed off to the development team to build. Once the development team has developed the initial version, the feature goes into “alpha”. This means that our internal team (and maybe some trusted friends, parents and colleagues) load it onto their devices and try it out. This gives us initial feedback on ease of use and helps to identify bugs and crashes. This feedback is compiled, and the development team does another few rounds until the feature is stable and meets business requirements. Next, the feature moves into “Beta” which means real users, real data but in a controlled way. We have users which have signed up to our “Beta Program” and are the first to try out new features. Beta is an opportunity to explore edge cases which may cause the app to crash and to get real, unstructured user feedback. After Beta, the product is ready to be released.
In some cases, “Release” means that it is headed for a formal, academic evaluation – perhaps through a randomized controlled trial. If the outcome is positive, the app could be released in the app stores for general use. Whether the app is evaluated academically or not prior to general release, you should always be thinking about “post-market surveillance” and continue to develop, improve and evolve the product as your users’ needs change.
5. Things [sometimes] go wrong
Okay, things always go wrong, but you have to adjust and respond. Don’t let this discourage you, remember that even the biggest and best technology companies have endured significant product issues. Unlike most “traditional” research, when there are issues with your product you will find out pretty quickly - often through feedback from upset end users. While this can stressful to endure, it is important to recognize the importance of communication and see it as an opportunity to improve the product.
Good Luck! If you are interested in learning more about developing an app from a developer’s perspective the excellent team at Medic at Mohawk College has created this very helpful video to get you started: