So you want to launch a mobile medical app?
You have trained your pet to remind you to take your medicines by giving it a treat on the same moment every day. It actually works great, but what to do when you are on vacation? There should be an app for that.
You think to yourself: 'If I can get a reminder to take out the trash, I can expect the same level of user-friendliness for my health. Let's do this!'. That is great and I am rooting for you, just be prepared to hit some speed-bumps on your way to app stores. And they will definitely affect your mood.
In my experience you will go through 5 stages before you start developing your mobile medical app:
- Naive enthusiasm when you see the opportunities.
- Concern when you discover the seemingly infinite number of existing health related apps. How will your app stand out?
- Confidence when you find out that most of these apps offer no real value. Your app will be so much better!
- Concern again when the regulation aspect gets in the picture. This is where a lot of people throw in the towel.
- Determination to make this work.
I could add a bunch of extra 'concern' stages, but let's not do that. Let's just focus on the bases you will have to cover to actually launch your mobile medical app so you can plan the necessary actions and invest your energy in making a better app.
- Is your idea really that good?
- Intended use & medical device classification
- Data privacy
- Gather user input throughout development
- Devices used by your target group
- App deployment
- Functioning mock-up for Apple
- Alignment with brand guidelines
- Legal & privacy statements
- Maintenance & continuous development organization
1. Is your idea really that good?
Start with these 4 questions:
- Is the problem important?
- How will you solve it?
- Are you able to make it happen as an organization?
- Can you refine the idea towards a scalable business concept?
2. Intended use & medical device classification
You need to know which rules to follow and comprehend all their implications. Those rules can originate in legislation, certification and app acceptance criteria. When you do not comply with them, every time your app is used it can put your company, or worse patients' lives, in danger.
Questions to ask yourself are:
- In which geographical regions will I roll out my app? Eg.: US, EU and China all have different regulations.
- In what setting is my app intended to be used? Eg.: hospital, doctor's office, OR, home setting …
- Who will use my app? This includes intended users as well as other stakeholders such as patients, doctors, IT-department, …
- How can my app be misused?
- Can using my app lead to physical harm? Eg.: Does my app provide a drug dosage calculation?
- Will my app be used to diagnose or treat patients?
- Does my app save protected health information?
3. Data privacy
Imagine Facebook putting your vacation photos in an ad for Canned Ham. Now imagine your insurance company increases your premium because they know that you do not take 10.000 steps every day. Or better yet: imagine your photo and health data are used in an ad for that prescription drug you use to treat that delicate condition.
People are understandably very protective of their health information and a lot of legislation is in place to make sure you are too. In Europe, personal data protection is a fundamental right (Article 8 of the Charter of Fundamental Rights of the EU).
But don't take this as a disadvantage: this legislation prevents you from damaging patients' lives, your company's value and its reputation.
One example: the General Data Protection Regulation comes with a non-compliance fine up to €20 million or 4% of annual turnover … whichever is higher.
It all boils down to be compliant with:
- EU General Data protection regulation
- Code of Conduct on privacy for mHealth
- General Data Protection Regulation (GDPR)
Avoiding data leakage becomes easier when you:
- don't save data
- encrypt all data
- don't link data to a patient
- have a rule for data destruction after a period of X days
- get explicit consent from your users to handle their data
Globally the market share of iOS was 13% in 2016 (Gartner), but when you zoom in on Belgian cardiologists you will notice that they really like their iPhones.
4. Gather user input throughout development
I hope I am kicking at an open door here: a mobile medical app that serves your need but not the needs of the intended user will not be successful. IEC 62366 on application of human factors/usability engineering to medical devices is a must read.
Focus on getting and keeping a deep understanding of the behavior of the intended users and involved stakeholders. Translate your findings in a strong Minimum Viable Product, other and list opportunities and risks.
5. Devices used by your target group
While hybrid development allows you to develop for all operating systems in parallel*, it is worth checking what your target group actually wants. Don't just do desktop research, actually ask them what they use and need.
Eg. Globally the market share of iOS was 13% in 2016 (Gartner), but when you zoom in on Belgian cardiologists you will notice that they really like their iPhones.
Be careful not to extrapolate user group results to your complete target group. I've noticed a that certain phone users (eg.: Windows) are over-represented in user groups. I think the last few Mohicans know they need to speak up or be forgotten.
The harsh reality is that 2 operating systems remain relevant. If you don't know which, I think you better focus on something other than launching an app.
Besides operating system, you should also determine which phone models your target group uses. If you want your app to be backward compatible with older models and operating systems, explicitly stipulate this to your development team. This requires extra development time and thus budget. Today, most app developments strive for compatibility with iOS 10 or above and Android 6.0 or above.
* While 'code once, deploy multiple' sounds interesting, there are some risks involved.
• Platform-specific rules often restrict hybrid development
• Reduced efficiency. Eg.: location accuracy and battery consumption
6. App deployment
You have the ideal version of your app in mind. This ideal app will fit perfectly in your long term strategy. You will feel disappointed if some feature is not included in the first gen. Not for yourself, but for your users.
‘Think big, act small’ is the way to go here.
You will hear yourself or your colleagues saying: 'While we are at it, you might as well include this and this and start with the best app.' Believe me when I say: your long term initial plans will change along the way.
Early adopters that believe in your idea, and want to contribute to improving it, will share their feedback. You will discover your target group has different needs and expectations than you picked up during your user research.
The market will change while you take time to develop the most perfect version of your app. Plus, don't forget: changing your app to cater these newfound user needs will be exponentially more difficult and expensive further down the line.
So be smart and define the MVP that still proves your app's USPs (I've achieved good results with InVision). This will allow you to enter the market faster at a lower development cost and avoid costly red-designs. After that: learn with the market and continuously integrate improvements based on user feedback.
7. Functioning mock-up
Apple and Google want to test apps before allowing them on their stores. You are not getting away with screen shots or a dummy.
An app we recently developed was to be used within an operating room, during a procedure and used data from the Hospital Information System. Obviously, you cannot give Apple nor Google access to the internal network of a hospital.
So we had to build a server to host a mock-up database and user management, have our app communicate with it to allow thorough testing. Planning will keep you from stressing in the final development hours or push back your time to market.
8. Alignment with brand guidelines
I estimate about 85% of employees have no idea what brand guidelines even are. At least, that is what they claim when their 'below the radar' app is discovered.
Obviously less people meddling in will help you move forward faster. But why are you building this app again? Ah, you want it to get traction in the market, do you? That means your best case scenario includes your HQ discovering that you broke the rules.
Include your brand management colleagues or their guidelines from the get go. If nobody has this specific title, your best bet is the marketing and communication department.
9. Legal & privacy statements
Another topic that might seem trivial, but keep in mind: every single usage of your app can ruin your company (Remember the 20 million euro fine I mentioned earlier?).
This is not something you want people remembering you for. The bigger the company the more time it will take to get the required input. Don't procrastinate or you risk launching late.
10. Maintenance & continuous development organization
An important part of costs comes after the MVP or even the 1.0 version. Post Market Surveillance activities, such as maintaining, fixing and evolving the app requires time and money. Compliance with IEC 62304 (on development and maintenance of a safe software system) is no walk in the park. I’m not diving in this rabbit hole in this article.
If you plan to scale globally you should pay special attention to country specific rules and conventions.
Two groups that speak, what you perceive as, the same language, often use different naming conventions.
Like that great time I told people in Mexico 'Voy a coger un taxi'. Laughs were had by all.