Megalabs: a pharmacist chatbot

Our client: Megalabs

Megalabs is a leading multinational pharmaceutical group that consists of different laboratories like Roemmers, Rowe, Medihealth, Poen, among others. Megalabs is dedicated to the production, distribution, and commercialization of quality pharmaceutical products, and it is the leader in LATAM.

Industry

Pharmaceutical

The Problem

All meds bring with them a leaflet with all the information about the drug, however, I’m sure you can think about more than one time that you needed the information and it wasn’t accessible.

According to our research, some of the most common reasons for non-accessible drug information in leaflets are thrown away leaflets, lost leaflets, wet/broken leaflets, and the most popular one among seniors, excessively tiny font. Let’s not forget about too technical and extensive medical language and format that most people can’t understand completely.

All these reasons, among others, prevent customers from finding the answers they need to stay healthy, and Megalabs knew it. That’s why they reached out to Light-it to figure out how we could leverage technology to make drug information more friendly and accessible.

Process & Workflow

Product strategy: Finding a solution

Megalabs came to us with the problem and the idea of solving it with an advanced chatbot that could answer all customer questions. They also came with a lot of doubts, but the most important one was: is this feasible?

This was our starting point: validating if we could build a chatbot that could interpret all questions correctly and give the right answers without errors, contemplating we’re dealing with a very delicate subject, and that a mistake here could lead to a health catastrophe.

Technical discovery

The thing that concerned us the most was risk prevention and compliance. We needed to utilize GAMP®5, a methodology provided by ISPE13 (International Society for Pharmaceutical Engineering). It defined the way we had to analyze risks, test, document, and develop a system for the pharmaceutical industry. We also had to be approved and validated by the health departments of the involved countries. At this stage, we investigated and defined the technology stack and methodologies we were going to use.

Product discovery

This was about validating that we were approaching the problem with a suitable solution for users, and defining how this solution would look like regarding features, user interaction, and scope. To cut a long story short, product discovery can be broken down into the following pieces:

User research:

We identified two main groups of users. The first group were the users that need the drugs information. Within this group, we identified that the variable age determined the way they interact with leaflets and tech. We built three user personas:

Cameron Williamson

18 years old

He isn’t used to taking meds.
He tends to discard leaflets and look up for it on the internet (many times, non-official information).
He has trouble understanding leaflets because of its complex and technical language.
He wouldn’t download a new app just for a chatbot; he would rather use messaging apps he already utilizes.

Guy Hawkins

50 years old

He is usually adding new meds to his routine and wants to be informed about them.
Looks up for information for his children and other family members.
As he gets older, he highlights the problem of leaflets being too hard to read because of tiny font.
He would rather download specific apps for drug information consultation.
His understanding on leaflets is proportional to the amount of meds he take.

Theresa Webb

75 years old

She takes meds regularely
She understands leaflets, and consults them frequently as she regularily changes meds.
She tends to worry about drug interactions, so this information is very relevant for them.
Leaflet’s font is too tiny for her.
Most of the she does consultations are for herself.
She would rather have a specific app for the chatbot.

The second group of users is Megalabs admins. They are the ones in charge of the system’s back-office. Their main tasks are uploading new leaflets to the system and verifying that messages were classified and responded correctly. If they detect an error, they should be able to correct it and train the system to prevent this error from happening again.

Exploration:

Understanding about meds, leaflets, and legal requirements was a part of the process too. One of the most relevant findings here where the categories of sections and questions. There are 15 categories within leaflets. We carried out and investigation to order them according to which ones get more questions from consumers. The category that is asked the most is posology, and the least was “what happens if I forget taking the med”.

Dosage (5.2%)
Posology - treatment (5.8%)
Interactions (8.8%)
Indication (3.9%)
Medical recommendation (18%)
Side effects (10.5%)
Commercial questions (11%)
Other (8.3%)
Posology and frequency (5.2%)
Contraindications (9.7%)
How to take (3.6%)
Treatment (4.7%)
Composition (2.2%)
Equivalent (1.9%)
I forgot taking the med (0.8%)

Decision-making:

Once we had all the relevant information on users, industry, and business needs, our product team explored the solution we were going to first test, to then build. After deeply assessing our findings, we decided to build:

An advanced chatbot that can answer 95% of questions asked by customers.

Available via the web application, mobile app, Facebook, and Whatsapp.

That can undestand natural language, and even interpret typos.

The chatbot lets the customer know when it can’t answer the question, to prevent errors. In this case, administators can manually add new answers.

Administrators can train and make changes to the information.

Product Design: Designing a user experience

We’ve all dealt with terrible chatbots, and we know how frustrating it can be. The decisive factor in chatbots is whether they are able to have a fluent conversation with users. This doesn’t just imply answering the questions correctly but also being smooth during the whole process of consultation. Some of the decisions we made to make this happen were:

The tone and voice of the chatbot would be formal, following the company’s brand guidelines, but still, be friendly and approachable to help users digest the information smoothly.

The chatbot can interpret informal language, typos, and grammatical errors. The chatbot is trained in a wide range of “ways of consulting”.

When the chatbot is processing the response, a “typing…” sign is shown to the user as feedback of the chatbot handling the question, just as if it was a person on the other side.

If there’s an internal error within the platform, the chatbot will alert the user that there are technical problems preventing it to reply.

The chatbot introduces the topic in the answers. For example, it includes “the posology for X drug is (...).”

In case users make mistakes during the conversation, they are always able to cancel or go back in the conversation to correct mistakes.

The chatbot’s visual design is simple and minimalistic.

Product Development: Developing and training the chatbot

The platform we decided to use is Watson Assistant and is provided by IBM. Watson Assistant includes natural language processing and artificial intelligence to enable the creation of contextual chatbots. During the active-development stage, we worked in two-week sprints, following Scrum.

Some important characteristics of the platform were: