Homepage > Portfolio > Patient Record System & Database Migration

Patient Record
System &
Database Migration

Azati helped a well-known healthcare company to merge two separate solutions, enhance the user interface and optimize basic business processes.


Nowadays, all medical processes – from diagnostics to laboratory tests, data storage, and patient registration are powered by modern technologies. Patients use online services to make an appointment, contact a doctor, buy drugs from home. Today’s technologies allow people to gain access to medical care almost instantly.

Thanks to the online platforms, it has become possible to store information about a patient, check medical history, save prescriptions, systematize and analyze available data. These platforms allow doctors to quickly receive complete information about patients and more accurately prescribe treatment and significantly reduce bureaucracy.

Our Customer is a CIS-based company that provides software development services for medical institutions. At the moment when Azati was involved in the project, the Customer had already created three modules for healthcare online-platforms. Let’s have a closer look.

#1 Physician Module

The physician module helps doctors run basic operations (after they login to their online account): check clinical reviews of the patient’s condition, write prescriptions, fill out various medical forms, manage treatment history, etc.

When a doctor logs into the platform, he/she receives certain rights depending on their access level. If a doctor is the system administrator, he has more possibilities and available features than a regular user.

#2 Helpdesks Facilities Module

This module is a small part of the extensive system represented as E-Health Web-Portal. The portal empowers helpdesk facilities, makes it possible to register patients online, provides various FAQs, reduces bureaucracy, and allows users to get timely help and quick feedback.

#3 Patient Records Module

This part of the Patient Record System is entirely devoted to patients. Within the module, patients can keep track of their prescriptions, observe their health certificates. The application serves as a virtual medical card with general information about treatment history and health records.


The Customer hired Azati to deliver a number of objectives.

#1 Create a Unified Database

Initially, there were two databases for the two main subsystems: Physician Module and Patient Records Module. These databases had completely different structures and schemes, but at the same moment, many common records and entities: doctor lists, their roles, positions, etc.

It is a bit irrational to have separate databases since it decreases the system performance and significantly complicates the solution maintenance and the integration of third-party services.

Before Azati involvement, the previous vendors started database migration and merging, but it wasn’t completed in time.

#2 Combine Internal Java Logic

According to the product roadmap, it was necessary to add the second role to the Physician Module. The Customer wanted us to rewrite a considerable amount of internal logic to make it possible to work with the module under two roles: doctor and verified patient.

#3 UI Enrichment

As soon as a new role was added, it was necessary to make changes to the User Interface (recipes, forms, journals, etc.). At this stage, our team had to solve the issue concerned with ZK Framework (open-source Java framework) when each element’s behavior was created according to predefined methods and scenarios.

#4 Forms Implementation

As one of the modules was responsible for PDF generation, the Customer wanted us to rebuild one of the forms entirely from scratch. Form 088 is the primary document that contains information about the state of human health, to be more specific – disability group. This blank indicates and includes necessary information about the patient, degree of disability, guardianship, etc.

#5 Recruits Module Development

Our additional objective was the development of the Recruits module. Such a module should represent all necessary data to monitor Recruit’s suitability for military service on each step of medical examination.


01. Challenge

Merging the two databases is always risky, especially if we talk about databases based on two different technologies. The database of the Physician Module was based on Postgres, while the Patient Records Module was built around Oracle and related technologies.

In this case, our engineers needed to be especially careful, as they were operating with two massive databases (with over sixteen billion of records) used by solutions with hundred thousand active users.

02. Challenge

The next problem was related to a new user interface enrichment.

Our team needed to add tables to the web-page, which included medical conclusions for recruits. It was implied that such tables should be expanded both: vertically and horizontally. However, due to the limited features of ZK Framework, our team could only work with regular tables, which were based on the n-th number of columns and rows.

Such an approach entailed several difficulties in displaying all data correctly. It was necessary to write a gigantic chunk of code, and the UI adaptation process took a lot of time and resources.

03. Challenge

The workflow was entirely remote and fully distributed, as the Customer was located more than 5500 kilometers from our development center. The distance between our team and staging servers led to noticeable ping issues. For example, if a developer runs a set of automated tests, it could take about twenty five minutes for the algorithms to finish.

The staging and development servers were not powerful enough to carry all the load, and if any of these servers required a reboot – the work stopped for forty minutes.

Our team decided to involve one of our DevOps engineers to accelerate feature delivery. He helped deploy the application in a private cloud and move the databases to our office.

04. Challenge

Another problem was related to project management. Often, tasks were described superficially and without the dedication from the manager’s side. Our specialists had to spend a lot of time correcting and discussing tasks to perform them correctly.

Nevertheless, we successfully overcame the challenge. Our developers took a proactive position and began to take the initiative regarding the accurate task setting.


The first thing to mention is that the project management and task tracking was carried out via Redmine. The workflow proceeded as follows: our engineers received a task, accomplished it, logged the time spent on the implementation and necessary testing.

Testing was performed in two stages. At the first stage, the Customer and his team check the results superficially, mainly paying attention to the functionality. If, during the initial phase, there were any malfunctions or bugs, then the task was returned to the developers. If everything worked as expected, the task transferred to the testing team.

Due to the project’s complexity, managers had been changing quite often, so it was hard to keep the pace with all changes and track tasks accurately. However, through daily discussions, we set up a good workflow and communication. The team already knew who is the right person to ask about specific issues. Team meetings were held twice a week to discuss project progress and achieved results.

After the successful implementation of the first main objectives, Azati conducted the second phase of the project. This phase was mostly related to testing and bug fixing.

At the last and final stage for Azati, our team needed to update the first version of Form 088 and provide the ability to work with the old and new versions simultaneously.


To combine internal java logic, our developers performed great manual work to add a patient account into the Physician Module. They established a large volume of rules to set proper permissions for each user role.

Moreover, our specialists created a new UI Component within the Physician Module and transferred all the functionality and logic from the Patient Records Module.

The PDF documents generation was based on the JasperReports – is a specific open-source Java reporting tool. The objective turned out to be quite voluminous and took about three weeks to complete.

Since our additional objective was the implementation of recruit’s module consisting of all required medical data about military suitability, our engineers divided the solution into three different lists:

Initial recruit medical examination lists

Medical indications according to secondary examination at the recruiting station

Final medical reports

Migration Solution:

First of all, our team examined the initial code because previous vendors partially started the migration. Since we worked with two different databases, each of which has individual properties, it was necessary to study all the ways to efficiently extract data from one database and place it to another: from PostgreSQL to Oracle.

Moreover, because the database schemes were different and had to be merged into one, many reports suffered from database merging. To deal with these reports, engineers analyzed which properties and entities were affected by the migration and fixed all the related reports.




During the project development, Azati
achieved the following results:


Two separate databases were merged successfully


Testing and bugfix successfully conducted


New functionality introduced and deployed


New UI features were developed and implemented into the platform

Our engineers received great experience and upgraded their hard and soft skills. Even though some tasks were quite intricate due to the complex software architecture, we did our best and left a positive impression on the Customer.


Unfortunately, the project was suspended. The development team shifted to a more relevant project. Nevertheless, the project was launched, and all the features were released. All additional requests and new features were added to the pipeline for 2021.

Drop us a line

If you are interested in the development of a custom solution — send us the message and we'll schedule a talk about it.