What the three architectures actually are
The terms get used loosely, so it's worth being precise before comparing them.
Point-to-point means each pair of systems has its own direct interface. System A sends to System B in a format the two agreed on. Add System C and you build two more interfaces, or three, depending on who needs to hear from whom.
Hub-and-spoke means every system connects once, to a central hub. The hub receives a message, translates it, and routes it to whichever systems need it. This is what most people mean by a traditional interface engine, and it is the classic message broker topology.
Orchestration means the central layer doesn't just route and translate, it runs multi-step flows. Receive a message, validate it against a profile, enrich it from a lookup, branch on the result, deliver to two destinations, confirm both, and handle what happens if one fails. The flow itself is the unit of configuration, not the interface.
The distinction between the second and third is where most confusion sits. Hub-and-spoke moves a message from one place to another correctly. Orchestration is about what happens between those two points.
Comparison table
| Point-to-point | Hub-and-spoke | Orchestration layer | |
|---|---|---|---|
| Connections for N systems | Grows roughly with the square of N | One per system | One per system |
| Adding a new system | Build an interface per consumer | One connection, then routing config | One connection, then include it in existing flows |
| Where transformation lives | In each interface, duplicated | In the hub, per route | In the flow, reusable across routes |
| Multi-step logic (validate, enrich, branch) | Hand-coded in each interface | Limited; often pushed back into endpoints | First-class, configured in the flow |
| Observability | Per interface, inconsistent | Per message, at the hub | Per flow step, end to end |
| Change unit | An interface release | A routing and mapping change | A flow configuration change |
| Failure isolation | Per pairwise link | Per route | Per step, with defined retry and compensation |
| Knowledge dependency | High; often one person per interface | Moderate; concentrated in hub specialists | Lower; flows are legible artifacts |
| Best suited to | Small, stable estates | Many systems, simple routing | Multi-step clinical and operational workflows |
The table shows something worth stating directly: hub-and-spoke and orchestration have identical connection economics. The difference between them is entirely about what the middle can do, not how much it's connected to. If you are evaluating products rather than architectures, our healthcare integration platform comparison covers how to run that assessment.
How each one handles change
Change is where the architectures separate most sharply, because change is constant in a healthcare estate.
In a point-to-point estate, a change to one system's output means finding every interface that consumes it. There is no central inventory unless someone maintained one, and that person may not be there. The work is proportional to how many consumers exist, and the risk is proportional to how many you missed.
In hub-and-spoke, the same change is contained: you update the inbound mapping at the hub, and consumers are unaffected because they still receive the format they always did. This is the main reason interface engines exist and it's a genuine improvement.
In an orchestration layer, the containment is the same, but there's an additional property: because the flow is a configured artifact rather than code, the change is visible before it's applied and reversible after. You can see which flows reference the changed field, change one, and route back if it misbehaves. That property is what makes phased migration workable, as described in legacy EHR migration without a big-bang cutover.
How each one handles failure
Failure handling is the less-discussed difference and often the more expensive one.
Point-to-point failure is pairwise. Interface A-to-B fails; A-to-C keeps working. That sounds like good isolation, and it is, but there's usually no consistent retry behaviour, no dead letter channel, and no common place to look. Each interface was built by whoever built it.
Hub-and-spoke centralises the failure surface, which is better for diagnosis and worse for blast radius. When the hub is down, everything is down. Retry is usually available but applies to delivery, not to the semantics of what was being delivered.
Orchestration handles a category the other two mostly can't: partial failure of a multi-step flow. If a flow validates, enriches, then delivers to two destinations and the second delivery fails, what should happen? Point-to-point has no concept of the question. Hub-and-spoke retries the delivery. An orchestration layer lets you define it: retry with backoff, compensate the first delivery, route to a human queue, or fail the whole flow atomically.
When point-to-point is still right
It would be dishonest to present this as a straight hierarchy. Point-to-point is the correct architecture in real situations.
If the estate has a handful of systems, the interfaces are stable, the message volumes are low and the team that built them is still present and documenting properly, then point-to-point is simpler, cheaper and has fewer moving parts. Introducing a central layer adds an operational dependency and a skill requirement that a small, stable estate may not need.
The signal that it has stopped being right is not the number of systems. It's the rate of change. When the estate is adding or modifying data flows faster than the team can safely track which interfaces are affected, the architecture has become the constraint. That's usually visible as growing lead times on small requests, not as an outage.
What "orchestration" means that "integration" doesn't
The word integration describes a connection. Orchestration describes a process.
That's not a semantic point. It determines what you can observe and therefore what you can improve. In a connection-oriented estate, the thing you can see is whether a message arrived. In a process-oriented estate, the thing you can see is whether the clinical or operational workflow completed, which step it reached, and where it stopped.
A referral that was received, validated against a FHIR profile, enriched with a patient identifier, routed to a service, and acknowledged is a workflow with five observable states. In a point-to-point estate that workflow is five separate messages with no shared identity, and nobody can answer "where is this referral now" without checking five systems.
That question is usually the one the organisation actually cares about.
Where WeHub Studio fits
Studio is an orchestration layer by this definition. Flows are configured rather than coded, with HL7 and FHIR processors handling the standards-level work, validation and enrichment as flow steps rather than endpoint responsibilities, and per-step observability so a stalled workflow is a lookup rather than an investigation. Ten must-have capabilities for building low-code healthcare workflows covers what to look for more generally.
The honest framing: if your estate is small and stable, this is more machinery than you need. If your lead time on a new data flow is measured in quarters, the architecture is the reason, and this is the category of thing that fixes it. When you do move, decommissioning a legacy interface engine sets out the order that keeps live feeds running.
