AN MHEALTH MOBILE APP

If a doctor prescribes you medication, you need to take it regularly to feel better. For this purpose, you can use one of the existing mHealth applications. Most healthcare apps are targeted at people with chronic conditions, have an inconvenient user interface, and many ads that distract users. 

Moreover, to report adverse reactions to your doctor, you need to assign a new appointment, which takes time and money. 

The mHealth application we developed for our client will help users keep track of their medicinal consumption. Another of the app’s functions is to provide users with a community of people and articles to answer health-related questions that they might have. 

How does mHealth app work?

It allows users to create a list with personal medication, log symptoms, and keep prescriptions in one place. The app sends reminders to the phone and always tells users the exact time they need to take medicine.  

Users may also specify certain medications as “emergency”, which must be taken in extreme situations. The app provides users with quick access to the Emergency screen with information about medicine and doctor’s contacts. 

Users can monitor their own health and create profiles of their family members.

The community feature provides users with access to articles & opinions to clarify issues that they might be facing with one or other medication.

Client requirements

Client wanted to create a medical & non-medical adherence and community app that is targeted for women between the ages of 25-40, but open to all.

The app had to become a digital friend for managing medication adherence, developing routines, and nurturing health-related curiosities. 

Our solution 

For this particular case, we suggested she participate in the Inception phase, our service that shapes the project vision and its roadmap. But, for the rest of our clients, we suggest moving with MVP.

Our challenges

A team to develop the product roadmap from scratch. For this task, we followed such requirements:

• Find the ultimate database of medications available across the European market.
• Make the product compliant with existing digital product regulations in the European Union (GDPR and PIPEDA).
• Create UI/UX design. The product should have a custom design tailored to the target audience and a convenient interface. 

How we did it 

The Inception phase took us through the following steps: 

Step 1. Market research 

Before designing the project documentation, we conducted market research in the search for potential competitors. It turns out that app has three main competitors – CareZone, Dosecast, Mango Health apps. 

Then, we made up a table with their main drawbacks:

• CareZone has too many ads, an outdated list of medications, and an inconvenient user interface. 
• Dosecast offers users a database of drugs available only in the U.S., device synchronization issues, and no ability to set different tones for different medicines.
• Mango Health application has a UX which is too tricky to navigate and cannot log medication intake before reminder.

We also analyzed what color scheme and layouts competitors use to create a custom design for the project.   

Competitor analysis also gave us insights into the monetization strategy to suggest the feature list and user stories. With this information at hand, we began to create project documentation. 

Step 2. Project documentation 

The project documentation performs as an instruction for developers and gives them an idea of what product they are about to develop. We developed the documentation for the main project parts are a mobile application, the Admin Panel, and a marketing landing page. 

The project documentation starts with the following elements:

General Functional Requirements

In this section, we highlighted the main requirements for the project, i.e., what the system must and mustn’t do, such as: 

• The User must access the same account created in the app from multiple devices with the installed app. 
• The app should ask the User to update time once the User switches the time zone.  
• The application must have both offline and offline modes. In the offline mode, the User must have access to Home, Emergency, Stories, and Symptoms screens. 

Non-functional Requirements

Non-functional requirements explain how the app should work. Our general non-functional requirements are the following: 

• Applications must support three languages: English, French, German.
• The backend must handle increasing traffic loads – from 40,000 users for the first year to 200,000 users for the third year after the project launch. 

Once we were done with the project’s general requirements, our solution architect, project manager, and business analyst started mapping up the project architecture and listing third-party solutions to apply. 

App structure 

App structure helped us map up features and user flow in the app before writing use cases. The app structure is the very first text-based wireframes for the project. Thanks to the app structure, we placed the User into the app’s flow and determined whether a conceptual framework agrees with the target audience and its needs. 

The diagram below shows the action flow the User must take for completing a particular task. 

Project architecture 

We decided to begin with a monolith web-application containing most of the features to simplify initial development and split it into microservices over time. 

For this project, we suggested the Google Cloud Platform as a cloud environment. GCP provides many built-in tools for developing the app’s architecture and the ability to move architecture to other environments without significant changes. 

Since data synchronization was one of the competitor’s weak points, we decided to power up the project with the Kubernetes platform and Docker containers. Both solutions synchronize data in real-time and ensure the system’s scalability and portability. 

Then, we drew up a scheme of the project architecture’s main components: 

• The Admin Panel for managing users and tracking statistics, connected with the app via Admin API 
• A mobile app retrieves and stores user info via Client API
• Global Load Balancer HTTPS ensures cross-region load balancing. i.e., distributes backend tasks over a set of resources, making their overall processing more efficient.
• CDN (Content Distribution Network) caches HTTP(S) load balanced content in users region through Google’s globally distributed edge points; thus, delivers the content without downtime.
• Kubernetes cluster runs containerized web applications for authentication, authorization, and User management via API.
• CloudSQL database is a solution for storing encrypted user data and relational databases for application statistics.
• Cloud Storage is a hosting server for storing files that are not sensitive data. 
• Cloud Build is a tool for the continuous development of Docker images. 
• Container Registry is a GCP component for storing Docker container images.
• Stackdriver is also a GCP component. It ensures operational logs, monitoring dashboards, and alerting to email and SMS. 

Integrations 

• Chino.io is our solution of choice for ensuring GDPR and HIPAA compliance because it is ISO 13485 and 27001 certified. The platform encrypts data with secure record level encryption and sends it to the server via API calls. This integration also significantly reduces the development time and costs. 
• Drugbank API is an ultimate database of medications that includes all drugs available across the E.U. The database also contains info about contraindications, adverse effects, and medication compatibility. 
• Mandrill API is a mailing platform for sending transactional emails to users. 

Main actors and use cases 

We made up the list of features to add to the project right after competitor analysis. 

When we mapped app structure, we prioritized functionality to implement first (the must-have features) and those to integrate later (nice to have features). 

Then, we created a list of actors (users) who will interact with the app and the Admin Panel. They are:

• Unregistered User, who does not have an account in the system, so cannot use the functionality of applications 
• Registered User, who successfully created an account in the system and has access to all functionality of applications
• Unregistered Admin is a person who does not have a user account in the Admin Panel. 
• Registered Admin is a person who has a user account in the Admin Panel.

We have written user stories that describe each type of actor’s user path based on user goals. User stories are also handy for testing and quality assurance since they represent what the User should do on one or other screen. 

Step 3. UI/UX design

Wireframes 

We also leveraged the app structure during the wireframing stage. Wireframes are another Inception phase deliverable that includes a schematic view of app screen components. Instead of giving the ultimate design view, wireframes percentage the information displayed on the page, an outline of structure and layout of the page and user experience, and the overall direction and description of the user interface.

Once wireframes were ready, our designers created the app’s prototype in Figma, a professional web-based tool for prototyping apps. The prototype simulates the navigation, gestures, and overall look and feel of the app.

Then, we moved to the visual design stage to give more personality to the app. 

Visual design 

As we previously said, the app is going to serve women between the ages of 25-40. To make the app attractive for the target audience, we used a combination of pink and blue colors for Medicine, Home, and Emergency screens. 

For the rest of the app’s screens, we used a blue background, white and dark blue elements to make users stay focused on their goals.

The main app’s screens we designed are: 

Build-in calendar for logging symptoms and medication intake. Users flow for logging symptoms includes: 

• Selecting the date on the calendar at the Home screen 
• Pressing on the “Symptoms” button
• Opening a carousel with symptoms and indicating symptom level

History of symptoms. The User can access one’s history via a full calendar view or from the Symptoms page.

Reminders. Users can keep track of their intake and log their symptoms.

Emergency information. Users have quick access to the critical information they choose to have.

Medications list. Users have their list of medications on hand with product details.

Articles. Users can access articles about medications, their adverse effects, and symptoms shared by other app users. 

Offline access. The app provides users with offline access to the following data:

• All medicine consumption related information
• What users have to take
• Users’ inventory 

Results that we achieved

The Inception Phase took us two months from signing the contract to agreeing on the app’s last screen. 

The team that worked on this project included:

• 1 Business analyst
• 1 Project manager
• 1 Solution architect 
• 1 Designer

After partnering with us, client received the following Inception phase deliverables: 

• Written market and competitor research 
• Technical documentation
• UI/UX design screens
• A clickable prototype 
• A product roadmap 
• Project architecture 
• A list of integrations for medications database and user data encryption 

Related reading: 

At this moment, the client is pitching the project in the first round of investments and confident of victory.

Want to develop a healthcare mobile app but don’t know where to start?