Developing ERP System for Retirement Home Management

A case study for the development of an ERP system based on the microservices technology and of a progressive web application 

Cooperation and client

Our common history

Our cooperation with the company DelpSys s.r.o. and its founder Jakub Žákavec took off after we have won an invitation to tender for the development of an ERP system in April 2020. Since then, we have made a big progress, created a couple of modules for this system and also launched several other common projects. We have witnessed some important milestones in the life of the company and helped the Legato project to make it through various developmental stages. This study describes all fundamental aspects of our cooperation.

The company DelpSys s.r.o. is, among other areas, active in the field of social services. And it goes without saying that just as in other industries, a system for retirement home management also needs to meet certain standards. This is where the LegatoDelp system, developed by us for DelpSys, comes into play.

DelpSys logo

App logo

Requirements

Client’s wish

The Legato system was supposed to be modular and accessible from a web interface with a custom mobile mode. It was intended to comprise several subsystems and components, which is typical for ERP systems. Instead of usual “resources”, which are recorded and used for planning, consumption etc. in most ERP systems, this one was to work with residents (clients) of the retirement homes. These clients require recording, planning of various services in order to maintain sufficient quality of the day care, recording of current data and documenting of their stay in the retirement home.

An ERP system also needs to be set up properly and some features must be restricted for certain users through definable access rights. Another requirement of the client was the possibility of operating the system both as a cloud-based solution (for this, it was necessary to separate the data for each facility) and on custom servers of the given retirement home (on-premise). Of course, all actions performed in the system had to be logged.

The Legato system was also to be completed with the mLegato app, which was intended as a simplified mobile version to enable the social workers to perform scheduled services even in the offline mode. All this was to be done already during the first stage of the project for which 18 weeks were allocated.

Problem

Challenge for our developers

According to specifications, the whole system was supposed to be modular so that every client could buy only those modules they were interested in. Access to data was to be restricted using a complex hierarchy of rights and the solution was required to work both on a cloud and on-premise. Meeting all these requirements was not possible without careful preparation and consulting before the actual development. A tight deadline put us under time pressure. Moreover, we also had to consider other functional requirements, including a simplified mobile version.

Basic overview of a resident, including a mobile version preview
Difference between monolithic and microservice architecture

Microservices

…or the embodiment of modularity

Considering the requirement for modularity, we decided to divide the entire system into separate microservices with each of them operating one part of the system. With the microservices architecture, it is possible to easily add a new module to the solution, even without changing the existing code. Another benefit that comes with microservices is that for the clients with the on-premise solution, only parts belonging to them can be provided and it is not necessary to lock those parts of the system that were not purchased. On the contrary, in the cloud version where a virtual server is shared by several clients, it is possible to simply scale the individual microservices according to their load.

In the first stage, the following microservices were created:

  • Authorization core of the system with information on users and their rights
  • Management of retirement home clients – primarily for their details and accommodation
  • Sending of emails and SMS
  • Uploading of binary content (such as client images for their profiles)
  • Logging of all actions
  • Setting up and planning of services with clients; the first optional module 

In the beginning, all microservices had separate codes and databases. Internal communication was always performed using the interface of the individual microservices. For example, displaying of information about clients included calling a microservice for client management that would ask the authorization microservice whether the user has a permission to view these data, load the client’s photo from the microservice with binary content, log the action to the microservice with logs and to finally load data from the microservice with the client’s records to return these data back to frontend where the action was called.

Tenantization

Database division

The cloud version clearly presupposed that the system would be used by several facilities at once. However, these facilities could not share data. It was therefore necessary to choose a specific tenantization, or more specifically database division so that one retirement home would not have access to data from another retirement home. This issue was handled on the database level where every object instance has an identifier specifying to which retirement home it belongs. Every request or resulting database query is then filtered according to the tenant of the currently logged in user. Users received their own tenant identifiers to be distinguishable if one user has access to multiple retirement homes. Thus the tenant equals one retirement home.

General settings of the retirement home
Role settings in the system

Rights system

Restricting access to data

For the rights system we used the PRBAC (Partition Rule Base Access Control) library and built it directly into the Django framework, in which the app was developed. Thanks to this, each object from each microservice could have its own access rights set dynamically and systematically. These rights were retained in the authorization microservice and we called them “atomic” since they were further grouped into clusters and assigned to the individual roles on the frontend that could be obtained by users. Apart from the typical model rights, it is possible to additionally define custom rights, which we did later on to achieve even finer rights settings, such as when changing the password of another user, performing special actions, performing actions repeatedly and so on. Also, this could be applied to the whole frontend rights construct, which then determined the visible parts of the system frontend.

Services

First extending module

As has already been mentioned in the microservice list, one of the first optional microservices was the microservice containing services. Retirement home clients require performing certain periodic actions. These actions have certain prescripts – services. The service specifies what needs to be done. The action itself has the form of time data. Based on the pre-set service and according to the retirement home settings, actions to be performed were generated. These were classified according to the individual pathways or floors of the facility.

Performing actions on web and mobile phones
mLegato PWA

mLegato

Mobile app in the form of a PWA

Another important part of the specifications was a small mobile app for the management of services. The client required that this part function even in the offline mode in case the given employee does not have Internet access. Although we could have developed this app separately, this would have increased the budget disproportionately and prolonged the development time of the first stage. Considering the fact that actions in mLegato were just following the functionalities of the web app, we decided to implement the web app as a progressive web application – this means the entire app can be downloaded to a mobile phone and even used in offline mode after adding the relevant features. The employees may therefore perform actions on their mobile phones and we managed to save for the development of a separate app.

Client’s reference

“Think Easy won our tender for ERP system development. The project was implemented by means of microservices architecture and a progressive web application. I particularly appreciate the brisk responses to our requirements and straightforward communication. The cooperation with Matěj, Matouš and their team is really purposeful. Together with Think Easy we’re launching the next stages of our project.”

Jakub Žákavec, Delpsys s.r.o.

Platforms and used technologies

Which technologies were used

The majority of microservices were programmed in Python and its Django Rest Framework using the PostgreSQL database. For asynchronous actions, we used the Celery planner and the redis queue. For the microservice that sends emails, we used FastAPI as this was a “passage type” of API. The logging microservice uses the Influx database, which is suitable for large quantities of data with a timestamp (“timeseries” database). Deployment was prepared on Amazon Web Services. The frontend was implemented as a progressive web app in React.js/Typescript.

Benefits

  • Providing services for retirement home clients, users and management of their access rights
  • Planning and performing of services for clients
  • Overviews allow sorting, filtering and searching
  • Details contain set standard actions for changes, action confirmation and deletion
  • Visible parts of the detail can be partially hidden or shown; the hidden parts remain hidden even after clicking on another detail
  • The tables have columns with adjustable width
  • Every object can be deleted unless it is assigned; otherwise it is deactivated
  • Sophisticated rights system restricts access, actions and visible parts of the system
  • Deactivated objects can be activated again
  • System contains several settings for each retirement home, or more specifically for the tenant, such as settings of the time needed for generating actions according to services or the length of the action plan in mLegato
  • Scalable microservice system
  • Preparation of deployment for cloud and on-premise
  • Logging of all actions in the system
  • All dials for forms can be adjusted in the settings

Further stages

Signalling system

Which technologies were used

Before finishing and fine-tuning the first stage, we received a new request: To integrate the already existing signalling app into the entire solution. The signalling component works with bracelets worn by the retirement home clients, also called “gates” (their function is to collect location data using the Bluetooth signal). Using the analysing interface, the signalling component can determine the location of the individual clients and enables their protection in case of unexpected problems. The users of these bracelets can call for help to which the retirement home employees can respond in the mobile app SignalDelp displaying the alarms. The system can also report users who get out of reach and identify their last known location.

The app was written in Node.js, i.e. in a different framework than the rest of the microservices. However, with microservices this is an advantage rather than a problem – the interface enables communication with any system. Additionally, we programmed tenantization into the app and integrated the whole microservice as an extension for the microservice containing the clients’ data. After the integration, we added the possibility of setting up the entire signalling system to the Legato web app and also worked on other extensions as per the client’s requirements.

Signalling system settings in Legato
Client detail preview

Redesign, refactoring

Preparation for further stages

After the first stage was finished and the signalling system was integrated, we agreed with the client on a comprehensive redesign and refactoring of the frontend as it was developed in bit of a hurry due to the tight deadline. This allowed us to revitalize the frontend, prepare it for year-long development and give it the shape that can be seen in the previews. We also finished and fine-tuned several functionalities so that they are compact and complete.

Planning

Free assignment of actions

During the redesign stage, we began working on the planning module – an extension of the service microservice. This extension allows employees to assign the individual actions for the given week to themselves in a neat table with several other functionalities. Furthermore, we modified the mLegato app in this stage and partially changed some of its features.

Planning calendar preview
Documentation records
Example of a simple map

Documentation

Other records for clients

After the planning, we had to address the documentation module along with several other features. One of them was separate documentation to record medical reports of the retirement home clients. These records could be signed digitally, which would prevent their further modification. Another function we added was storing of documents for the given client. These were added to the microservice containing binary data. 

The final and at the same time most difficult bit was adding of records to clients. Apart from their adding, filling in with client data and editing, it was also possible to display them in a fully adjustable mind map. The records can be texts, numbers, dates etc. However, the section with calculated values was the most interesting one. In this type, we granted the admins restricted access to the database so that they could send a request for any system data and thus display various calculated values for the client, such as the number of scheduled actions. The admin was able to do all the settings, which meant the values could vary greatly. Their calculation is asynchronous and every calculated value has a certain life-time before it is recalculated in case of a query. To work properly, the individual databases were migrated as individual schemes into a shared database that runs under a new microservice designed to handle these records.

Within this module, we also added a new type of rights – the so-called “type rights”. Documentation, documents, records and maps contained a certain type that could be added to each role. If no role that had been assigned to the user contained the rights for the given type, the documents, documentation, records and maps would not be shown to the user. These rights arise and cease together with the new or deleted object types that can be dynamically added in the system settings.

External module

Looking after clients even outside the retirement home

The last part we implemented together with the client was the external module integration. This external module serves basically as a signalling system for clients using the day care from their own homes. This module enables an advanced analysis of the collected data, which means it can analyse even falls or prolonged immobility of the client.

The module was integrated as a third-party API, meaning it is not a direct part of the Legato system and is hence not a new microservice. In the web app, users can set various delay values for sensors – not only for the tenant, i.e. for all clients of the given retirement home, but also for the individual clients separately.

Localization using external module