Developing ERP System for Retirement Home Management

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.

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.

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.

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.

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.

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.