Designing for Doctors: Medlife

A case study detailing my experience of redesigning the doctor suite at Medlife

Backdrop

Medlife is primarily divided into two product verticals or business lines: The consumer end product and the doctor ecosystem. The consumer ecosystem deals with consumer services such as medicine delivery, diagnostic tests, health products and remote doctor consultations. The doctor business line, on the other hand, offer doctors a wide array of features to manage their day to day practice. These include electronic health record management, appointment management, prescription digitisation and medicine delivery.

The doctor business was primarily handled through a product known as Zip Rx. Zip Rx is an application that helped doctors write digital prescriptions on a tablet device. Medlife also had a huge number of doctors registered on their doctor business line. The number at this point of time was above 1500 doctors across the country. The prescriptions collected from doctors is a major business influx for Medlife. Upon enrollment into the program, each doctor was offered a tablet device free of cost, with the Zip Rx application installed.

Brief

Medlife made a huge investment in the doctor side business. Although the enrollment numbers of doctors were growing by the day, thanks to the strong affiliate network and the relationship managers, who handled Medlife’s equation with the doctors, the number of prescriptions doctors were writing on our ecosystem kept dwindling by each passing day.

Doctors slowly stopped using the tablet and the Zip Rx application to record their prescriptions and reverted back to using the traditional methods of pen and paper. Although we started at a decent 29,000+ prescriptions a month with Zip Rx, the number quickly fell to around 11,000 prescriptions a month.

The aim of this project was to realise Medlife’s goal of a fully functional doctor ecosystem. The North-star metric for this project was the number of prescriptions we got per day. This is a significant metric which tied together two very important things:

1. This number directly represented the usage of the doctor ecosystem. The more the doctors used the product, the more prescriptions were generated.
2. The number of prescriptions generated directly translated into a growing user base for the consumer side of the business as after a prescription is generated by a doctor, A customer gets the digitised prescription with a one-click option to order the medicines at a discounted rate.

Apart from looking into the bad numbers in Zip Rx, Medlife wanted to facilitate quicker, easier ways of writing prescriptions. As we were currently offering tablet devices to most doctors, we wanted to see if we could eliminate this cost by achieving this through our mobile application. This was in conjunction with the government of India directive to all doctors to hereby write prescriptions with the drug names and not the brand name of the medicine. This posed a major problem to most doctors as they usually tied up with brands and remembered a medicine by the brand name and not the chemical composition. This presented a new opportunity to Medlife for a digital product intervention.

The current mobile application offered appointment management and prescription digitisation to doctors. Doctors could take a picture of the prescription they wrote and could upload it on their mobile for digitisation.

Instead, we wanted to explore other easier ways of generating digital prescriptions and on that front, wanted to explore prescriptions on mobile through the application. There were explorations being made on prescription generation on two fronts: The mobile application and prescriptions through voice input. Although early user research sessions revealed that voice input might be a failure in the doctors’ clinics due to multiple factors, we went ahead with developing a prototype for testing and then taking a call on the same.

Another problem arose from the multitude of devices that were present in the doctor product ecosystem: We had a tablet application, a mobile application and a windows based desktop application. However, the product significantly differed across these devices and posed a problem to many doctors.

In totality, the brief boiled down to achieving things:

1. Arrest the fall of numbers in daily prescriptions generated on Zip Rx (Tablet device)
2. Explore prescription generation through voice input
3. Explore prescription generation on a mobile application.
4. Standardise the product across different platforms to eliminate confusion among doctors.

1. Improving prescription generation numbers on Zip Rx

User Research

Thanks to the relationship managers from Medlife, who visited doctors every week and inquired about their needs and kept the relationship between the organisation and the Doctors very steady, we were able to set up visits with multiple doctors. We selected doctors in different localities and with different clinic sizes and patient capabilities.

The aim was to shadow the doctor in his / her cabin and observe doctor behaviour when interacting with patients and writing their prescriptions. But this proved to be a challenge as most doctors were understandably not comfortable with having another person around while treating another patient. There were concerns about patient privacy and understandably so.

We then split the session into two different phases. In phase one, we sent out two people to go to these selected clinics as patients and observe what the doctors were doing while the consultation was taking place. These observations were pertaining to how the doctor’s workspace was, how the doctor went about his / her work, what questions were asked and primarily related to how the doctor used the Zip Rx device and if the doctor faced any problems with it.

After noting down all these curious observations, we then booked a device feedback session with the doctors and walked in to understand the doctors’ problems with the device. Since the device at this point of time had limited features, the questions we asked were pretty pointed and were specifically targeted to elicit doctor behaviour w.r.t these couple of features.

Surprisingly, after the first session, we noticed that barely any of the doctors used the prescriptions. Some doctors only used it to write the minimum amount of prescriptions that were needed to receive the financial bonus. Some doctors never actually used the devices, but instructed their assistants at a later time to sit and digitise the prescriptions.

Once we visited the doctors in their offices, the problems were out there for all to see:

Problems

1. Most of the doctors were middle-aged and their extent of using technology like mobile phones was restricted to elementary operations like calling and whatsapp.
2. The doctors were extremely comfortable with writing their prescriptions by hand. This was a habit formed out of years of practice and the free flow nature of writing a prescription appealed to them instead of a structured form that was offered in the Zip Rx platform.
3. Most doctors remembered the medicines by shorthand and usually did not know the complete name of the medicine. The doctors would usually write the medicine name in short and the pharmacist would decode the medicine. This understanding between a doctor and a pharmacist was a very efficient factor the doctors used in reducing the time taken for writing a prescription.
4. Time was of the essence to a doctor. Typing speeds of doctors were extremely low. The doctors had an innate goal of treating more customers and the Zip Rx platform, although offered them a solution to digitisation, terribly reduced their speed of writing a prescription.
5. The product’s medicine search feature depended a lot on new medicine inventory that was fetched to the device via the internet. A lot of doctors were unaware of this and did not recharge the SIM cards provided to them with the tablet devices.
6. The medicine list always kept updating and there were always a bunch of medicines that were not available in the inventory. This was a major problem for Doctors.

The entire product ecosystem was far too big a behavioural change for the doctors and in the end, the doctors simply abandoned the system that did not adapt to them.

The Solution

Instead of going ahead and preserving the doctor’s behaviour and building a product ecosystem around that, we had gone the other way and defined a product that we assumed most of the doctors would use. But this was not the case as the ecosystem needed a significant change in technological behaviour, which the doctors simply refused to adapt to. The solution lay in preserving this behaviour of the doctor and building the product ecosystem around this behaviour.

On the Medlife consumer application, customers would upload their prescriptions and place an order against the prescription. This was made possible due to a team of pharmacist-digitisers that sat at the back end, read these prescriptions and digitised them for repeated consumption of the Medlife platform.

Also, in the user study, we noticed how almost all the doctors had either a laptop or a desktop in their clinics. After some exploration, we discovered a pen input tablet that captured handwriting strokes when kept under the paper. The device had two input spots on the writing area that could be used to trigger digital functions. The device fitted on to it a stash of A4 papers and could recognise pen strokes on it.

On the slate device, we mapped the two hot spots to the functions “Add page” and “Submit prescription”. In order to further enhance the experience, we personally stickered the spots beside the hot spots on the tablet edge with stickers displaying the function of the hotspot.

The tab looked something like this:

The prescription pad would fit in the white space of the illustration above. As and when the doctor was done with writing a prescription, a simple dot on the right-hand side hot spot wired to submit prescription did the job. The device would then be on stand-by for recording the next prescription. All inputs were mapped on the slate device and the only thing the doctors were supposed to do is to connect the device at the start of the day and disconnect it at the end of the day.

The slate device could be used with any one of our platforms; desktop, mobile or tablet. All it needed was to be connected and paired to the respective device at the start of the day and they were good to go. The relationship managers made sure to teach all doctor assistants to do the same effectively. Pairing could also be done via the doctor assistant application from our Doctor suite.

Result

There were multiple benefits afforded by the newly designed doctor ecosystem.

1. It preserved the doctor’s disposition to write a prescription.
2. The doctors saved loads of time
3. The ecosystem was not internet dependent. It would upload the list of prescriptions as and when the internet was connected on any one of the devices; desktop, mobile or tablet.
4. This resulted in an explosion of prescriptions, taking out monthly count from 11,000 to 1.5 lakhs.
5. We had the added benefit of gaining more effectiveness out of out digitisers, who used to digitise on an average 10 prescriptions a day. After this, the number of digitisations went up to 25 per day.
6. Overall, this bumped the monthly orders from prescriptions by 5.8x, which was a huge influx of business.

Digital Prescriptions on Mobile

After fixing the issues with the drop in Zip Rx product, we wanted to explore generating digital prescriptions through our mobile application. This represented a great opportunity to cut down on device costs as if the same task can be achieved by a mobile application, it would give us an additional benefit of zero digitisation cost. Further, the process of generating a digital prescription helped us with creating the perfect fodder for the AI algorithm we were developing on the sidelines to integrate medical inventory to the doctors and deploy a one-click medicine order from the doctor side. The aim was to ensure the customer had the medicine delivery at home by the time the customer reached home. In lieu of the same, we were also launching out 2-hour express delivery feature and remapping out inventory centres in heavy demand locations like Bengaluru. More on this in my case study on the consumer application.

A digital prescription primarily needed to digitise multiple data points on a prescription. Having an inventory of these terms also helped us generate better prescriptions quicker. The following were the components of a digital prescription.

1. Medicine data

This contains the name of the medicine, the chemical composition, the dosage, duration and the number of medicines prescribed for the medical course. Comments pertaining to medicines were also included occasionally.

2. Symptoms

Symptoms that the doctor notices in the patient like cough, cold etc.

3. Vitals

Information about the patient’s vitals like Blood pressure, temperature etc.

4. Diagnosis

The doctor’s analysis and interpretations of the symptoms

5. Tests

Any diagnostic tests prescribed by the doctor

6. Comments

General comments w.r.t the patient or medicines or any other item that does not fall under the above-mentioned categories.

Out of the aforementioned categories, the medicine data is mandatory. Medlife has a huge inventory of medicines, whose SKUs are digitised and ready for consumption into the product. For us, this became a good opportunity to collect the digital inventory for the other 4 categories (except for comments).

Insights

With the parallel effort to generate voice prescriptions going on, we needed to design to ensure consistency in interaction pattern and data collection for both the use cases. We conducted a small study with a limited group of doctors for this. We asked doctors to dictate prescriptions to their assistants, who would digitise the prescriptions on the Zip Rx interface. We came up with some interesting insights in these sessions.

The primary insight was the use of vocabulary we were earlier unaware about. For example: TID was a term used to describe a dosage of 3 times a day. We noted the way doctors dictated the medicine, dosage and duration data to their assistants and tried to ensure that this speech pattern dictated the flow around which the product would be built.

Automation was done wherever possible. For ex: For the number of medicines, this was done automatically by multiplying the dosage given with the duration of the prescribed medical course. If the doctor said:

Calpol 650mg BID 2 weeks

It translated into 2 medicines per day * 14 days = 28 days. Since Medlife only dispensed medicines in full strips, this was rounded to the nearest complete strip value, i.e: 30 tablets.

Another insight we got was that a lot of doctors were using WhatsApp a lot. They were fairly comfortable with typing out medicines or dosage changes to their patients over Whatsapp. They were very familiar with the text-based communication application and its interaction patterns resonated well within the community. Tasks like sharing images, dropping voice notes and searching and sending emoji and other visual formats of communication were well versed among the community. In lieu of the same, we tried to retain such simplistic interaction patterns and rode the wave of WhatsApp familiarity on this design exercise.

Designs

The primary action of starting a new prescription was linked along with the patient to whom it was being written. This was done using the live queue on the doctor application. Through the supporting Dr. assistant application, the assistant would select the profile of the patient being allowed inside the doctor’s cabin. This change would reflect on the Doctor’s end and all the doctor had to do was to pick up the phone and write the prescription.

As soon as the doctor starts typing, the closest results in the categories of medicines, symptoms, tests, vitals and diagnosis are shown in the suggestion bar that spans above the text field. Medicines would be preferred in the search results for obvious reasons.

As soon as the doctor clicks the medicine, a page opens, asking the doctor to define the dosage and duration for the same. As mentioned earlier, the doctors use a different terminology for dosage. We retrofitted that into a keyboard that enables the doctor to fill the dosage in one single step. This again shows the power of user research and its ability to makes users’ life easier.

Post filling the duration, the number of medicines is automatically filled. The screen for dosage and duration definition has been carefully crafted keeping in mind the necessity of constant keyboard changes and finger and palm accessibility. There is an optional comments field associated with each medicine for the doctors to specify contextual instructions along with medicines. Once submitted, the medicine loads on the prescription screen, with the doctor ready to input the next medicine.

Similarly, here is the flow for symptoms, diagnosis, vitals and tests:

Additionally, for any terms pertaining to the categories of symptoms, diagnoses, tests and vitals, we added a flow to tag these as such on the backend in the case our inventory did not have them in the first place.

The design was tested with a few doctors and doctors liked the easiness of generating a prescription. The full scale development of the same module is currently underway. If deployed and successful, this can save Medlife huge costs on both digitisation and doctor devices. In addition, it builds up our inventory that feeds into the AI. Additionally, doctors seemed to really like the application, which is always welcome. This increases our retention capability and new doctor adoption rate.

Voice-based prescription generation

Another exploration we were conducting on the prescription generation front was through Voice input. The challenge for the same was to not confuse the doctors and to retain the same UI. As alluded to before, we wanted to retain the interaction patterns that users were familiar with; i.e Whatsapp.

Voice on its own cannot stand as a fully functional interaction input pattern as the technology is still in its infancy and the names of medicines are quite intricate in nature. For this reason, we needed to have the normal way of digitising prescriptions as a backup option for quick edits and corrections.

There was a keyword that triggered a search in a particular category. These keywords were “Symptoms”, “Diagnosis”, “Vitals”, “Tests” and “Comments”respectively. The medicines field did not have a trigger word as that was the most common use case for the doctors. Doctors could simply click on the record icon and start speaking and generating the prescription.

Unfamiliar with most voice interfaces, we also needed to prime doctors on the voice base input mechanisms and needed to train them to use the same to quickly generate prescriptions. The training was done on the doctor’s first instance of invoking the voice input mechanism either from the doctor application home screen or from the new prescription screen. This training went in hand with the doctor’s task of writing a prescription. This training was split into three simple steps:

1. Medicine Input

To begin with, we trained the doctor to generate a medicine entry through voice. In the medicine field, the dosage and duration were the only mandatory inputs that were needed apart from the medicine name.

2. Advanced medicine input

Reinforcing the earlier training, this time we trained a doctor to input the complete set of fields that were possible for a medicine. This meant including a comment and the quantity of medicines being prescribed. The order of prompts could be in any order as long as the medicine name was spoken out first. Out voice detection algorithm allowed for this.

As soon as the medicine card is generated, it collapses into a summary state in a matter of seconds to make space for the next medicine.

3. Other inputs

After taking the doctor through a cycle of medicine generation on the prescription, they are then taken through a single round of tagged inputs field generation. This was done with the single trigger word. Everything recorded after the trigger word would be recorded as belonging to that particular category. In case the entry did not exist in our backend inventory before, a new tag would be created for the same. In the end, the doctor would be given the other keywords as well with similar usage pattern as that of the first one presented.

Post Setup Prompt

Post the voice setup, a permanent prompt reminding the doctor of medicine format and the keywords would be consistently present on as the default state, eliminating the need for doctors to remember keywords and medicine input patterns.

Result

Although the digital prescription generation feature proved to be very well received by the doctor community, the same could not be said about the voice prescription feature. Due to several glitches in voice detection and due to technological shortcomings, it did not perform as well as expected.

Further, user tests of the design revealed some interesting insights. Most of the doctors who were prolific at generating prescriptions for us were usually in low-income neighbourhoods and in congested buildings with noisy waiting rooms. This hampered the performance of the voice input.

Further, although the doctors were excited at the technology, they were uncomfortable at loudly proclaiming names of medicines and symptoms in a way that was audible to the other patients sitting on the outside. This was a further deterrent against using this feature.

In general, Voice detected had a low success rate and with the contorted names of the medicines combined with doctors remembering only half medicine names in most cases, this feature failed to find a fit in doctor’s clinics, as was the assumption from an initial user test of the same.

As a result, this proposition was rightly left out of the final release.

Learnings

This huge project had many learnings for me personally as a designer.

There were times when I had to work around the reluctance of doctors to let me observe their practice. We worked around by using assistants to note the observations instead. We also sent separate trained teams as legitimate patients to observe the behaviour of the doctor the environment in which a doctor operates.

Tapping into the inner secrets and working methods of a doctor’s daily life helped us unlock some pain points and solve them in an easy way like the dosage keyboard.

From an interaction standpoint, the exercise was an excellent way to prove that continuous iterations do make way for much cleaner, consistent and simple to gauge patterns among users.

By observing Doctors’ readiness to spend time on applications like Whatsapp, we preserved those interaction patterns and rode on their wave of similarity to design efficiently for the users. By observing the other stakeholders in the environment, like the doctor assistant, we were able to further iron out experience of the doctors by delegating necessary tasks to the assistant and letting him/her handle the appointment queue and the name of the patient on the prescription.

Searching outside the product channel for solutions to a problem is another important thing I learnt from this project. There are some problems that are better solved outside a product and it is the duty of the designer to look at the total ecosystem around the user and the interplay between the elements in this environment to find cues for possible solutions.

Most importantly, the biggest lesson from this project was that users will not adapt to behaviour or products that are forced upon them. Contrastingly, if the product starts by banking on the user’s strongest behavioural patterns, adoption, numbers and the user experience will all shoot through the roof.

As someone rightly said “Follow the user and all else will follow”.