National health systems run on dozens of separate systems: hospitals, health centers, vertical programs such as immunization or malaria programs, insurance schemes, pharmacies, civil registration, and the administrative health map. Connecting them is not one project, it is many. Health system interoperability looks different depending on what is being exchanged, and Bluesquare’s growing interoperability practice, most recently through a national program in Mauritania, is already producing lessons worth sharing before the results are fully in.
Before choosing any architecture, a national program needs to know how many distinct systems it is actually connecting, an exercise usually smaller and more manageable than it first appears.
A network of two hundred health centers running on only six different software products creates, at bottom, only six integration problems. Sizing an architecture by site rather than by software editor overestimates the effort and hides where the real negotiation needs to happen. National programs benefit from a registry of points of service that records each site’s editor, product, and API version, since that is what determines the integration work remaining.
Interoperability can be governed two ways: a centralized model, where an integration layer absorbs each system’s native format node by node, or a prescriptive model, where the sector sets a shared API contract and reference terminologies upfront. Centralized gets a first exchange running fast but creates lasting dependency on whoever builds the connectors. Prescriptive requires real institutional authority to make the framework mandatory. The workable lesson so far: decide, system by system, which logic fits, and write an exit clause into every centralized connector so it doesn’t become permanent.
Much of what looks like a technical delay in interoperability programs is, in practice, a governance question that was never explicitly separated out.
Whether one facility can access another’s data actually depends on four separate decisions: a technical identity check, an inter-organizational right defined by a data-sharing agreement, a fine-grained access decision belonging solely to the facility holding the data, and an individual legal basis such as patient consent. Conflating these is one of the most frequent sources of blocked exchanges, or the opposite: ungoverned over-access. A sectoral framework agreement, signed once by all points of service, paired with a short bilateral annex per connection, turns this into a repeatable step instead of a negotiation each time.
A bounded exchange, such as a minimal patient summary, has a defined, verifiable set of concepts and is straightforward to govern. Sector-wide terminology is different: defining every concept a sector might ever want to exchange in advance never finishes, and scope declared complete at launch almost always proves incomplete once systems use it. The workable principle: add a concept only once a registered flow needs it, anchored on references such as ICD-11, LOINC, and ATC wherever they already fit.
Interoperability covers requests that look nothing alike once the expected response time is taken into account, and that difference drives most of the technical decisions that follow.
When a national immunization or malaria program sends aggregated indicators to the country’s health management information system, typically DHIS2, nobody is waiting online for a reply. This aggregate exchange runs on a schedule, from every few minutes to once a day, through a batch integration layer such as OpenHEXA, which extracts, cleans, deduplicates, and reconciles large volumes of data, keeps versioned working copies of registries and terminology tables, and never acts as the authoritative source of the data it processes.
Looking up a patient record during a consultation, validating a facility code, or checking insurance eligibility differ in kind: someone is waiting, typically within 100 milliseconds to 2 seconds for a single lookup, and up to about 10 seconds when several dependent calls must be orchestrated, such as resolving identity, facility, and terminology before transmitting a record. This real-time exchange runs through a transactional interoperability layer, logging every transaction, applying consent checks, and guaranteeing delivery, unlike the batch tools used for aggregate reporting.
Some real-time exchanges cross a line that neither a batch pipeline nor a transactional layer alone can safely handle: the boundary between two distinct legal entities.
Verifying a patient’s identity against civil registration, checking insurance rights or affiliation, notifying a birth or death, or checking a health professional’s license all involve two separate legal entities, each needing proof the other side cannot later dispute. That proof, a signed message, an approved timestamp, a verifiable log kept independently by each party, is what a national trust bus adds on top of an interoperability layer, a different guarantee than the layer alone provides.
A national trust bus should be proposed only where one is already in production, or where a mandated authority has committed to building it, never built from scratch inside a single health information system program. Purely internal exchanges, or large-volume analytical feeds for national dashboards, do not need this layer, and adding one anyway only doubles the logging burden for national teams afterward. Using the minimum layer a use case actually requires is one of the clearer lessons from this work.
Bluesquare is applying this interoperability approach through DIGISANTE MRT, a program supporting the digitalization of Mauritania’s health sector, and its early stages already carry lessons of their own.
Working with the Ministry of Health, the Ministry of Digital Transformation and Modernisation of the Administration, the national population registry authority, and professional bodies, the program held a national workshop that set a common foundation: HL7 FHIR R4, a national patient identifier, and harmonized terminologies (ICD-11, SNOMED CT, LOINC, ATC). It also identified several registries: a patient registry linked to the population identifier, a health workforce registry, a facility registry built on the administrative health map, insurances identification, a pharmaceutical registry and an export layer feeding DHIS2 for aggregated, anonymized reporting. A national steering unit, chaired by the Ministry’s Secretary General, held its first session in July 2026.
The program decided early to involve local software vendors and guide them toward the exchange standards. This choice supports the durability of the solution and its ownership by local teams, including the technical staff of the Ministry of Health and the Ministry of Digital Transformation and Modernisation of the Administration. The program enters an existing ecosystem, with hospitals already digitalized on several different solutions, for example. Its role is to build an interoperability framework that local actors adapt to, while continuing to develop their own activity.
Much of Mauritania’s primary health care still runs on paper registers, without internet access and with limited electricity, so the program digitalizes first and integrates deeper systems later, rather than assuming connectivity that isn’t there yet. After comparing two open-source electronic medical record platforms, the program recommended OpenClinic GA as the shared primary care record, favoring an open-source solution already aligned with national standards. Twelve of the twenty-one health centers assessed across Nouakchott, Trarza, and Brakna have been confirmed as pilot sites, ahead of a first deployment at Dar Naim health center.
These are early interoperability lessons from work still in progress, and the coming months in Mauritania, and in Bluesquare’s other national programs, will test them further. To learn more about how Bluesquare approaches registries and geospatial data at national scale, explore georegistry and microplanning tools.
