Medical consumption data tool

About the project

For Médecins Sans Frontières, also known as Doctors Without Borders, I worked on a proof of concept for the Medical Consumption Data Tool. At the time, the organization was using several Excel files to track the consumption of medical supplies. These files were important for day to day operations, but in the long term they were vulnerable, difficult to maintain and limited in scalability.

Our proposal was to gradually translate these Excel processes into robust and sustainable .NET applications. As a first step, the Consumption Data Tool was selected. Within a few weeks, I developed a working proof of concept and presented it to Médecins Sans Frontières. The goal was to demonstrate that the existing way of working could be replaced by a modern application in a user friendly way, without losing sight of the practical constraints in the field.

The presentation was successful and contributed to the decision to further develop the concept.

Functional objective

The tool is designed to track the consumption of medical supplies per location and department. Based on this consumption data, the application can provide insight into current usage and support forecasting of future demand.

This is important because medical supplies must be available on time, especially in areas where logistics are complex and shortages can have a direct impact on healthcare delivery. The application therefore supports not only registration, but also overview, analysis and planning.

Existing historical data also had to be importable, so locations would not have to start from scratch and previously collected information could be preserved. In addition, it had to be possible to eventually move or send data to the central systems of Médecins Sans Frontières.

Important requirements

One of the most important requirements was that the application had to work completely without an internet connection. The tool is used in countries and areas where internet access is limited, unstable or not available at all. Therefore, the application had to be able to run locally and remain fully usable on its own.

The application also had to be easy to install and use. The users are not necessarily technically skilled, so the solution could not require a complex installation process or technical administration knowledge. The user experience therefore had to stay close to the existing way of working, while at the same time becoming more reliable and clearer than the Excel based solution.

Another important requirement was multilingual support. The application not only had to support multiple languages, but also had to be suitable for Arabic. This meant that the user interface had to support both left to right and right to left layouts. This influenced the structure of screens, tables, forms and navigation, because the application also had to remain logical and pleasant to use for Arabic speaking users.

Another important requirement was that multiple devices within a single location had to be able to work with the same database. This meant the tool had to support not only individual use, but also a small local working environment where multiple users could view and update the same data.

Architecture and technical choices

The application was set up as a desktop application in .NET. Technically, we chose a Windows Forms host running a Blazor application. This makes the application feel like a normal Windows desktop application for the user, while the user interface itself is built using modern Blazor technology.

This choice aligned well with the requirements of the project. The application can be installed locally, run offline and still be built with a modern and maintainable web based interface. This setup also made it possible to build the interface with multilingual support and to account for languages such as Arabic, where the entire screen layout must be able to be displayed from right to left.

The code was structured according to Clean Architecture, keeping the domain logic separate from presentation and infrastructure. In the application layer, CQRS was used in combination with MediatR, clearly separating read actions from write actions and keeping the different use cases well structured. In addition, several DDD principles were applied to explicitly model the most important domain concepts around medical supplies, locations, periods and consumption data.

This setup made the proof of concept suitable not only as a demonstration, but also as a solid foundation for further development.

My role

My role consisted of setting up, developing and guiding the proof of concept from a technical and functional perspective. I defined the technical direction, established the basic architecture and developed the most important screens and functionality.

The focus was not only on making the application work technically, but especially on demonstrating that an Excel based process could be replaced in a practical and sustainable way. The solution had to be convincing enough to create confidence in further development, while also remaining realistic for the conditions in which the tool would be used.

After approval of the proof of concept, I continued to guide and further develop the project for a short period. After that, I handed it over to a colleague because I was needed on another project.

Result

The result was a working proof of concept that showed how the existing Excel based way of working could be replaced by a user friendly offline .NET application. The tool provided a foundation for managing medical supplies, registering consumption, showing overviews and supporting future consumption forecasts.

For Médecins Sans Frontières, this was an important step in assessing whether their existing Excel processes could be converted into more robust software. The proof of concept successfully supported this direction.

Reflection

This was a meaningful project because of the combination of technical challenge and social relevance. The application had to be modern and maintainable, while at the same time remaining extremely practical. No complex cloud dependencies, no complicated installation process and no assumptions about stable internet. Those limitations are exactly what made it technically interesting.

For me, this was a valuable project because I was able to create a convincing foundation in a short period of time, both technically and functionally. The project shows well how I try to work: not only building software that is technically correct, but especially creating solutions that fit the people, circumstances and processes they are meant for.