Editorial prototype — sample content, not published
Perspective

Interoperability begins with the workflow.

Before choosing an interface, protocol or integration product, define who needs the information, where it originates, when it is needed and what action should follow.

The interface is not the starting point.

Integration conversations often begin too late in the reasoning process. Teams ask whether two systems expose APIs, whether a standard is supported or which middleware should sit between them. Those questions matter, but they describe the mechanism rather than the requirement.

A more useful starting point is operational: which person or system needs information, what decision or task depends on it, how current it must be and what should happen when the information is missing or delayed.

Map the work before the data.

Consider a diagnostic result. The technical object may be a report, a status update or a study reference. Operationally, however, it belongs to a chain of work: an order is created, a patient is identified, a procedure is performed, a specialist interprets it, a result is approved, and someone must act on that result.

If the integration design only moves the data but ignores the state of the workflow, the organisation may still rely on phone calls, spreadsheets or manual reconciliation to know what actually happened.

Interoperability needs ownership.

Every connection should have a clear source of truth, an expected destination, rules for exceptions and an owner for failures. Without those decisions, technical connectivity can create ambiguity instead of removing it.

This is why integration architecture is partly organisational design. It formalises where information is trusted, when it is shared and which workflow is allowed to depend on it.

The architecture follows the operating model.

Once the workflow is understood, technical choices become easier to evaluate. Real-time API calls may suit one interaction. Events or queued messages may suit another. Batch synchronisation may be acceptable for low-urgency reference data. A standard such as FHIR, HL7 or DICOM may be appropriate in a clinical context, but the standard alone does not define the operating behaviour.

The goal is not maximum connectivity. The goal is dependable information movement that supports a defined piece of work.

Working principle

A useful integration question

Who needs what information, when do they need it, what should they do with it, and what happens when the exchange fails?

Architecture view

Workflow-first integration

Source system
Workflow state
Integration
Receiving system
Action
Exception

The highlighted integration layer is only one part of the operating chain. The design is complete when the downstream action and exception path are also understood.

Related prototype content

Continue the subject.

Technology brief
Editorial prototype

What belongs at the centre of a multi-site architecture?

A companion framework for deciding what should be local, shared or centrally visible.

Read sample →
Perspective
Editorial prototype

Integration is not the same as replacement.

Why integration may preserve useful systems while removing operational fragmentation.

Read sample →
Product context

Integration Platforms

See how V3C describes integration environments at product level.

Explore product →

Use the framework. Then test it against the operating environment.

V3C editorial content should help readers ask better questions before they choose technology.