Humanitarian healthcare · Cameroon

MedMission Dschang 2026 — End-to-End Healthcare Digital Transformation in the Field

DeliveredSoftware Engineering · DevSecOps · GitOps & Cloud · DataDschang, Cameroon · 16–19 February 2026

The two-minute summary

Challenge
Digitise patient registration and consultations for a four-day medical and surgical mission, across three sites with uneven connectivity.
Solution
OpenMRS 3 on a central environment, three field Wi-Fi kits, on-site training, then a data pipeline (MedFlow, Metabase) up to the mission reports.
Role
Integration coordinated by TDKSOFT's founder; delivered by a team spread across Europe, India and Africa.
Results
128 people mobilised, 2,550 distinct patients and 3,700 consultations, according to the mission's official reports.
For your project
The same skills apply to any multi-site rollout: software, network, user adoption and data.

Mission context

MedMission AISBL is an international not-for-profit association that has run medical and surgical missions in Cameroon since 2024, with diaspora volunteers, local volunteers and Cameroonian health institutions. From 16 to 19 February 2026, its Dschang mission mobilised 128 people across three sites: the Dschang Regional Hospital Annex, CIRDO and Bawa.

TDKSOFT Consulting designs and maintains MedMission's IT solutions on behalf of the Meffo Tuebou Foundation (Dortmund), the association's partner. For Dschang 2026, patients and consultations had to be recorded digitally across several sites, then turned into reliable reports.

Engineering challenges

  • Three sites to equip at the same time, two of them outside the main hospital, with uneven connectivity.
  • Many clinical and administrative users, diaspora and local volunteers, who had to become autonomous very quickly.
  • Four days of operations: no room for a late go-live.
  • Health data: individual records must stay strictly separate from published indicators.
  • A technical team spread over several countries, whose contributions had to converge into one consistent solution.

From scoping to the published outcome

  1. Before the mission

    Scoping and preparation

    Team needs, registration and consultation workflows, configuration of OpenMRS 3 and the central environment.

  2. Before the mission

    Field kits

    Preparing and configuring the three Wi-Fi kits for the sites.

  3. February 2026

    Rollout and training

    Installation on the three sites and onboarding of clinical and administrative staff.

  4. 16–19 February 2026

    Operations

    Patient and consultation registration, user support, coordination between sites.

  5. After the mission

    Data and reports

    Extraction, validation and transformation (MedFlow), Metabase dashboards, operational and HR reports.

  6. 9 October 2026

    Publication

    Aggregate outcome published on MedMission's website, also built by TDKSOFT.

Pre-campaign preparation

Before the mission, the team prepared the digital environment: OpenMRS 3 configured for registration and consultation workflows, hosting in a central VPS application environment, and three Wi-Fi kits for the sites.

The rollout plan started from field constraints: several sites, uncertain connectivity, users to train on site and technical support throughout the mission.

Solution architecture

The diagram shows the architecture actually deployed, not an idealised reference architecture. It is deliberately high-level: no host, address or network configuration is published.

  • Field layer: staff devices on the three sites, connected through the Wi-Fi kits.
  • Application layer: OpenMRS 3 and its MySQL/MariaDB database, in a central VPS environment.
  • Analytics layer: MedFlow, an ETL process written in Python, and Metabase for dashboards.
  • Data boundary: individual records stay in the clinical environment; only aggregates leave it, for the reports and MedMission's public website.
Architecture deployed for MedMission Dschang 2026Three care sites, each with a Wi-Fi kit, reach OpenMRS 3 and its database in a central VPS environment over the internet. Data then flows through MedFlow (Python ETL) and Metabase. Only aggregates cross the boundary to the reports and MedMission's public website.Field3 sites, one Wi-Fi kit per siteRegional Hospital AnnexWi-Fi kit · staff devicesCIRDOWi-Fi kit · staff devicesBawaWi-Fi kit · staff devicesUsers on the 3 sitesclinical and administrative staffInternet accessvariable connectivityCentral clinical environmentVPS · individual dataOpenMRS 3patient records · consultationsMySQL/MariaDBclinical databaseData and analyticsafter collectionMedFlowPython ETLMetabasedashboardsextractionBoundary: no individual data beyond this lineReports · MedMission public siteaggregates only, no count below 10
Deliberately high-level: no host, address or network configuration detail is published.

Field Wi-Fi kits and deployment

Three Wi-Fi kits were prepared and configured in advance, then installed on the sites to give staff devices access to OpenMRS.

  • Preparation and configuration before the mission, to reduce work on site.
  • Installation on each site and verification that devices could reach the application.
  • Troubleshooting and technical support during the four days.

Training and adoption

A successful rollout is also measured by adoption. The team supported clinical and administrative staff on site: getting started with OpenMRS, patient registration and consultation entry workflows, then help at the workstation during operations.

The number of people trained and session length are not published, as there is no consolidated source.

Operations, 16–19 February

During the four days, the system was used to register patients and consultations on the three sites. The team provided application support to users and technical coordination between sites, working with the mission's clinical and coordination teams.

Connectivity remained the main constraint: the mission's official outcome reports data losses caused by the internet connection, mainly at CIRDO and Bawa.

Data engineering and reporting

After the mission, OpenMRS data was extracted, validated and transformed by MedFlow, an ETL process written in Python, before feeding Metabase dashboards and the mission reports.

  • Raw data: records and consultations as entered in OpenMRS, including the gaps caused by connection drops.
  • Transformed data: cleaned and structured by MedFlow for analysis.
  • Published indicators: the consolidated aggregates from the operational and HR reports; these, not raw counts, are authoritative.
  • Publication rules applied on MedMission's website: no per-site figures, no count below 10, no person names.
  • Backup: the OpenMRS and Metabase data volumes were copied, with a documented restore procedure (SHA-256 integrity check, database engine version compatibility).
Data pipeline, from OpenMRS to published indicatorsOpenMRS data is extracted, validated, transformed by MedFlow into analytical datasets, explored in Metabase, then consolidated into the reports and published as aggregates on MedMission's website.Raw dataTransformed dataOpenMRS 3field data entryExtractionfrom the clinical databaseValidationconsistency checksMedFlowPython ETLAnalytical datasetsstructured for analysisMetabasedashboardsReportsoperational and HRMedMission sitepublic aggregate outcomePublished indicators
Illustrative diagram: the steps are real; detailed data flows are not published.

Verified results

of operations
4 days16 to 19 February 2026.
care sites
3Dschang Regional Hospital Annex, CIRDO and Bawa.
people mobilised
128Including 30 doctors, 22 nurses, 55 diaspora members and 54 local volunteers. Source: HR report.
distinct patients
2,550Source: operational report.
consultations
3,700Source: operational report.

These figures describe the whole mission, not just the IT system. They are the consolidated aggregates from the operational and HR reports, published unchanged by MedMission. Connectivity losses mean the records entered in OpenMRS do not cover all field activity, so raw database counts are not published as indicators.

Engineering lessons

These lessons apply to any multi-site rollout: clinic networks, construction sites, industrial sites or events.

  • Connectivity: on remote sites, data quality depends on the network. Data entry that needs a permanent connection loses records when the network drops; degraded-mode operation must be designed in from the start.
  • Indicators: separate raw counts, transformed data and published indicators from day one, each with its definition and source.
  • Governance: keep the clinical environment apart from published content, and set publication rules before you need them.
  • Backups: a file-level copy of a database only restores on a compatible engine version; it needs checksums and a written procedure.
  • Adoption: on-site training is part of the delivery, just like the software.
  • Distributed team: a single integration point with explicit standards makes contributions from several countries converge.

Role and responsibilities

Henri Kengne, founder of TDKSOFT Consulting, coordinated the technical integration. The TDKSOFT team is based in Belgium and Germany, with nearshore contributors in Eastern Europe and offshore contributors in India and Africa.

  • Personal contribution: integration coordination; receiving, reviewing and upgrading the code delivered by the team to TDKSOFT's governance rules and European data protection requirements.
  • Team work, under that coordination: scoping, OpenMRS 3 configuration, hosting, Wi-Fi kits, training, support during the mission, data extraction and processing (MedFlow), Metabase dashboards, operational and HR reports.
  • Medical mission: care and mission organisation belong to MedMission AISBL and the 128 people mobilised.
  • Third-party software: OpenMRS (open source, from the OpenMRS community) and Metabase. TDKSOFT configured and operated them; it does not publish them.

Transferable expertise

For a client, this project shows end-to-end delivery: from scoping to the field, then from data to decisions, in a constrained environment. For a recruiter or engineering manager, it shows the ability to own integration for a distributed team, operate a real health information system and publish traceable figures.

← All case studies