M&E information systems: data flow, interoperability and architecture

Start from decisions, not forms

Most failed M&E systems were specified forwards: someone listed the data that could be collected, designed forms for it, and then wondered why nobody used the output. The durable design method runs the other way. Begin with the decisions the organisation actually has to make — continue or stop an activity, reallocate budget, report against a target, escalate a risk — and derive, for each, the information need, the indicator that would satisfy it, the source that can supply the indicator, and only then the flow that moves the data [1].

This derivation is why an information system inherits, rather than invents, its indicator set: the definitions, units, disaggregations and frequencies live in performance indicator reference sheets, and the system’s job is to store and enforce that metadata, not to improvise around it.

Three kinds of data, three different machines

An M&E system rarely runs on one data type. The three main streams differ in cost, cadence and bias profile, and the design question is which stream carries which indicator — not which stream is “best”.

Routine, survey and administrative data compared

Property	Routine monitoring data	Survey data	Administrative / secondary data
Typical cadence	Continuous or monthly	Baseline / midline / endline	As published by the owner
Marginal cost	Low once the system runs	High per round	Low, but no control over content
Coverage	Programme participants and sites	Sampled population, incl. non-participants	Whole jurisdictions
Characteristic bias	Reporting incentives; completeness drift	Sampling and response error	Definitions set for another purpose
Best carries	Outputs, service volumes, early warning	Outcomes, comparison groups, attitudes	Context, denominators, baselines

Routine streams are where quality is won or lost: the completeness, timeliness and consistency metrics of the WHO Data Quality Review framework exist precisely because routine data degrade silently between capture and report [2]. Survey streams buy representativeness at a price that rules out monthly use. Administrative data are cheap and broad but measured to someone else’s definition — usable for denominators and context, dangerous as a drop-in substitute for a programme indicator.

Data-flow design: capture, hops and feedback

Draw the flow before choosing any software. Where is each datum captured, by whom, on what device or paper? How many aggregation hops sit between capture and the national or organisational report? Every hop — field tally to site summary, site to region, region to headquarters — loses detail and admits transcription and aggregation error, so a defensible architecture minimises hops and keeps record-level data addressable as deep in the system as confidentiality allows [2].

The most neglected arrow in the diagram points downward. Systems that only extract data die at the periphery: facility and field teams keep reporting into a void until the numbers stop meaning anything. Feedback of results — dashboards, league tables, quarterly data-review meetings that return analysis to the people who captured the data — is an architectural requirement, not a courtesy [1].

Interoperability: why point solutions strand data

A tool bought for one form, one survey or one donor report becomes a data island the day its project closes. The remedy is architectural, and it is well worked out in the health sector: the OpenHIE pattern separates shared registries — the authoritative lists of facilities, clients, terminologies — from point-of-service systems, and routes exchange through an interoperability layer speaking standard interfaces [3]. Generalised to M&E at large, the pattern says: agree the master lists first, expose data through documented interfaces, and treat any tool that cannot import or export against those lists as a liability regardless of its features.

The Principles for Digital Development encode the same instinct as procurement guardrails — reuse and improve what exists, use open standards and open data, design for sustainability — and they are short enough to paste into a terms of reference [4].

Governance: master lists, unique IDs and metadata ownership

Interoperability fails on identifiers before it fails on technology. If two systems spell a facility differently, or assign the same project two codes, no interface can join their data honestly. A functioning system therefore names an owner for each master list (facilities, projects, administrative geographies, partners), issues unique identifiers from one register, and versions its indicator metadata so that a definition change is an audited event rather than a silent drift [5]. The indicator reference sheet is the metadata contract here; the information system is where that contract is stored and enforced [1].

Build, adopt or configure

The last decision is the one most organisations take first. Three honest options exist: build custom software, adopt an established platform as-is, or configure a platform to the organisation’s model. The comparison that matters is total cost of ownership over five years — licences or hosting, configuration, training, data migration, and the salary of whoever keeps it alive — against the risk each option carries: custom builds die with their developer; adopted platforms impose their world-view; configured platforms demand governance of the configuration itself. Field realities weigh heavily here — offline capture, sync conflicts and platform migration are decisive in many programme contexts, and are treated in depth in Monival’s practice guides on offline data collection and sync conflicts and duplicates rather than on this page.

Whatever the choice, the tests of this page still apply: does the tool serve derived decisions, respect the data-flow design, exchange against shared master lists, and enforce indicator metadata? A national-scale worked example of these trade-offs is DHIS2; the assessment machinery for the data such a system carries is the data quality assessment.