1500 hours of development, 300 hours of analytics and coordination of layouts with doctors to develop a health diary
Hello! I am Vera Osolodkina, I work as an account director in digital production Next. Today I want to talk about the development of a medical service for MEDSI, which has turned from an MVP into a full-fledged product. This is one of the most interesting projects in my track record and, in general, a useful thing for monitoring your health.
My team was given the task of developing an MVP for a health monitoring service. A kind of observation diary for doctors and patients. The diary is based on surveys that the doctor launches in his personal account and sends to the patient. Using a diary, you can track the progress of treatment, request feedback from the patient when prescribing procedures and medications, and monitor your well-being and changes.
Where did we start?
At the start, we had a brief with a top-level description of the solution and its functional characteristics. We expanded and clarified this brief, agreed with the client and went to the analytics stage.
Based on the brief, we formed a technical specification, decomposed the individual blocks of the future solution, wrote down the requirements and characteristics, and began to design and draw sketches.
During the work, the MEDSI team got a taste for it. The layouts and functionality were approved not only by the product team from MEDSI, but also by doctors – one of the end users of the service. The requirements and wishes became more and more, the product began to turn from an MVP into a full-fledged service.
At the stage of creating a concept and brief, it is sometimes difficult to imagine the end result, especially when you are working with a fundamentally new solution. The client developed an understanding of what exactly he wanted to get as a result while working on the project. Therefore, we spent a lot of time on analytics, defining the functional requirements of the solution, modules and screens as clearly as possible.
Polls and admin panel – the main primary entity
We started creating prototypes and demos from the admin panel. This is logical, because the service is based on the essence of surveys, which are created and launched from the administrative panel.
The system has several types of questions: with a choice of one or more options, open, open with reference values, questions with a picture that the patient uploads.
The purpose of the survey is to quickly assess the patient’s condition. Therefore, the service not only collects information from the patient, but also analyzes it. For ease of analytics, responses can be assigned a value (index) and a color code can be selected.
Surveys are created in relation to the diagnosis or prescription. For example, in the case when the survey concerns not the assessment of the general condition, but the patient’s reaction to the drug.
After we agreed on the functionality and designs of the admin panel, we moved on to working on two other service entities: doctors and patients.
With the increasing changes and expansion of functionality of the admin panel, the requirements for the other two sections, “Doctors” and “Patients”, have also increased. It took more time to systematize them, and the time frame for working on the admin panel was already stretched out. But since the functionality of the surveys and the general logic of the entire system had already been fixed, we were able to parallelize the process of analytics and backend development.
Functionality for doctors and patients
Doctors in the service can add and edit lists of patients, view information about them, assign surveys, set their duration and frequency, and analyze the results.
Surveys are divided into surveys of quality of life and general condition. Color codes help you react quickly if something goes wrong – deviations from reference values are marked in red. Results are available by date.
The service module for doctors includes not only analytics on surveys, but also on medications and prescriptions. The doctor can look at the test results and the regularity of taking prescribed medications.
Patients connect to the service through the SmartMed platform, and in their personal account they have access to prescriptions, medications and surveys prescribed by the doctor.
Frontend development and design
MEDSI has internal standards and rules for developing IT solutions. They concern not only the development languages used, but also the components. So, the front-end of the service had to be written in Vue.js using libraries that are used in MEDSI.
Design also has its own requirements. Despite the fact that we did preliminary design analytics and UX research and met the expectations quite accurately the first time, some elements had to be changed in accordance with MEDSI rules.
For example, we couldn’t simply draw a drop-down menu – we had to focus on the available similar elements in the library. If there was no suitable element, but we couldn’t do without it, we went to the client, agreed on these changes, and they added an additional element to the library.
Of course, it was not easy and labor-intensive, but we also felt the advantages of this approach. Since the project has grown significantly in volume relative to the first agreed brief, some of the tasks were completed by the MEDSI team: design and development of the front end of some elements. A unified approach to design and development simplified interaction between teams; transferring technical specifications was easier than if we had written a service according to our own standards.
Backend and integrations
To write this section, I went to our developer, Dana Likhachev. Everything that follows is written from his words.
The diary can be considered an independent application, built into the microservice architecture of the MEDSI SmartMed application and connected in several places with their services.
Initially, the Observation Diary was planned as a separate application that works through redirects and is not located in the client’s circuit. But since the requirements changed during the work, it had to be integrated into the MEDSI infrastructure, connecting it with SmartMed. And in such a way that this transition is seamless for application users.
To achieve this, we used authentication through one of the client services. This integration was planned in the final part of development, but it was laid out architecturally right away, writing code for validation.
In addition to linking users, we integrated the chat with the MEDSI system. The client had a chat backend and components that could be used on the front end of the application for doctors, but not for patients.
Therefore, we refined the chat front for doctors, and wrote it from scratch for patients. Next, we integrated the front with the back of the diary, which, in turn, initiates a gRPC request to the MEDSI backend to create a chat. After creating a chat with our backend, the front contacts directly with the MEDSI chat service and processes the correspondence on their side.
We worked through these and other integration requirements together with the client. An analyst from MEDSI joined us and described interservice integrations. This helped us not waste time researching services and immediately move on to finding solutions for integrations.
Another requirement was development in Python. We were offered to use a FastAPI application template with SQLAlchemy with additional internal libs for FastAPI. But difficulties arose. Although SQLAlchemy is a kind of standard that is often used with FastAPI, it was inconvenient for us to work with it.
At some point, we realized that developing in SQLAlchemy would be too labor-intensive, and the quality of the code was mediocre due to certain solutions in the library. Therefore, with part of the finished code, we decided to move to another ORM, Tortoise ORM. It is inspired by the DJango ORM, but is also asynchronous. Having felt it outside the project, we began to slowly migrate.
At first we simply added it to the project, then we started rewriting the existing code, and at the very end, when we finally removed SQLAlchemy from the project, we realized that we were not mistaken. The amount of pain, lines of code and time was cut in half, if not more, when switching to Tortoise ORM. Although we already had working functionality, migrating it to the new ORM took less than one day.
The release pattern is also worth mentioning. Initially, we launched the backend on our servers, then deployed it to the pre-sales in the MEDSI circuit. For production, the client rolls out the backend independently and does it quickly and without problems, since we took into account all the requirements and features of the MEDSI infrastructure.
Taking into account these requirements, we also needed to either keep the repository in the client’s GitLab, so that it would not be very convenient for the team, or resolve the issue of automating version control. We chose the second option. We came up with a script that transfers all changes from our repository to the MEDSI team, and vice versa.
What is the result
We had many strict requirements for the development and architecture of the solution. The project expanded greatly during the work process, we had to quickly rebuild and look for ways to optimize labor costs.
I believe that the right decision on our part was not to be shy about spending time on analytics. Thanks to this, we avoided the difficulties associated with the fact that the client may not like something, and the development progress is already such that it is very expensive to make changes and rollbacks. With projects in which there are many requirements and they are regularly updated, such risks are especially high. This means analytics becomes especially important.
Coordinated work with the MEDSI team also helped. We had to negotiate a lot: due to changes in requirements, the scope of work and our labor costs changed, it was necessary to revise some of the functionality, reduce something. We have always managed to come to the optimal solution in such cases.
Due to the fact that MEDSI took over part of the work on the project, the launch timeline was not greatly affected. The product has indeed become much more complex and voluminous compared to the planned MVP, but has not lost any quality.
