Begin with why the data needs to move

Consider a cross-border public-health use case. Several institutions need information to identify an emerging pattern, and technical teams can agree data formats, common definitions, APIs, and security mechanisms; without that interoperability, timely analysis becomes harder. But the connection itself cannot answer the next questions. Does the purpose require an individual record or an aggregate? Which institution is authorized to request it? Can information supplied for surveillance later be reused for research? How long should it remain available? Who corrects an inaccurate record? What happens if information is used outside the intended purpose?

Those questions define the legitimate flow. The African Union Data Policy Framework deliberately combines greater data use with stronger governance. It calls for harmonized governance, a shared data environment, protection of rights, and a trustworthy digital economy. [2] The objective is therefore not maximum movement, but useful movement with an explainable basis.

Minimum data is an architecture decision

Data programs often begin by asking what information is available. The stronger question is what information the purpose requires. A surveillance system looking for an epidemiological pattern may work with aggregate or de-identified information, where an individual clinical service would require a detailed record. A regional dashboard may need less again. A research use case may require a different permission route and retention period. The infrastructure can be identical while the appropriate dataset changes.

WHO's data policy follows the same principle within its remit. It supports sharing health data for public-health and scientific purposes, while requiring attention to national law, confidentiality, privacy, security, and anonymization where appropriate. [3] Sometimes the strongest data architecture is the one that knows what not to move. That is more than a privacy principle. Every unnecessary field increases storage, security, quality, and governance obligations, and can increase the consequence of misuse. Minimum necessary data is an architectural and operating choice.

The Data Permission Corridor

The five gates answer three questions, and naming them that way makes the corridor easier to apply than remembering five steps.

1. Legitimacy. Why should this exchange occur, and under whose authority? This covers purpose and authority.
2. Proportionality. What is the minimum information the purpose requires, at the lowest level of identification that still works? This is the gate most often skipped, because the answer is usually less than what is available.
3. Accountability. Under what conditions may it be used, retained, corrected, and challenged, and who answers when it goes wrong?

A proposed data movement should pass five gates (purpose, authority, minimum data, conditions, and accountability) before it reaches the technical exchange at all. We call the sequence a permission corridor.

Article 9 traces a business decision down into configuration. This corridor does something different: it follows one proposed data movement and tests whether it should reach the technical connection at all. The API is the destination of the design process, not its starting point.

Governance can accelerate sharing

Data governance is often introduced late, once technology teams are ready to connect systems, and at that point it can feel like delay. Designed earlier, it can make recurring legitimate sharing faster. Settle six things once for a recurring class of exchange: purpose, authorized participants, minimum dataset, conditions of use, accountability, and the exception route. The next occurrence then starts from an established path rather than from the beginning. That matters particularly in regional environments involving several institutions and jurisdictions, where repeatedly renegotiating the institutional rules can be as costly as rebuilding the technical connection.

Africa CDC's federated model illustrates that interoperability and retained data ownership can coexist in the same architecture, and the AU framework similarly seeks increased utilization of data within a trusted governance environment. [1] [2] The next frontier is to make permission routes as operational and repeatable as technical standards.

Bespoke approval has a cumulative cost

Approving each exchange as a one-off feels faster than building a class, and for the first few it is. The cost arrives later and it compounds.

An institution that has approved thirty bespoke exchanges may hold thirty approval records, thirty retention arrangements, thirty sets of conditions, and thirty technical configurations. Each was negotiated by different people at different times against different interpretations. Nobody holds the whole picture. A change in law requires thirty reviews. A breach requires establishing which of thirty arrangements applied.

The alternative is to settle a class once. Six things for a recurring category of exchange: purpose, authorized participants, minimum dataset, conditions of use, accountability, and the exception route. The next occurrence then starts from an established path.

A permission class makes legitimate exchange faster and unusual exchange slower, because anything outside the class now needs a decision it previously avoided.

Test one data flow end to end

Start with a real recurring use case.

1. State the outcome. Explain why information needs to cross an institutional boundary.
2. Establish authority. Identify who may provide, receive, and use it.
3. Reduce the dataset. Test whether the purpose can be achieved with fewer fields or a lower level of identification.
4. Define the conditions. Set access, retention, permitted reuse, correction, security, and accountability.
5. Connect the systems. Implement the technical exchange after the boundaries of legitimate use are clear.

This order does not remove the complexity of cross-border data governance. It stops that complexity from being hidden inside an integration project, and it gives Africa's expanding regional and continental data capabilities a way to make trusted exchange repeatable rather than bespoke.

A mature data architecture does more than prove that information can move. It can explain why this data should move, why no more is required, who authorized it, and what happens after it arrives.