System Integration in Regulated Industries Explained
System integration connects separate software systems and data sources so they exchange information automatically and behave as a coordinated whole. In regulated industries - labs, fintech platforms, eIDAS certificate services - integration engineering carries an additional obligation: every data exchange must be attributable, auditable, validated, and controlled under the same compliance rules that govern the systems themselves.
That distinction matters more than most project teams expect when they start.
What system integration means - and what changes in regulated industries
Connecting systems so they share data and act as one
At its most basic, system integration replaces manual data transfer with automated, structured data exchange between two or more applications. A laboratory might integrate its LIMS with an ERP to push sample results directly into billing workflows. A fintech platform might connect to a Mollie payment integration for European platforms to trigger payment events from within its own order system. In both cases, the goal is the same: eliminate re-keying, reduce latency, and make the combined system more capable than its parts.
The technical building blocks are endpoints, payloads, schemas, and transformation layers. Two systems agree on a data contract - what fields travel, in what format, and in what sequence - and a connector or adapter enforces that contract on every exchange.
Why regulated industries add an extra layer of engineering discipline
In a generic IT environment, a broken integration is a reliability problem. In a regulated environment, it is a compliance problem.
If a LIMS passes a result to an ERP with a missing timestamp, that is not just a data error - it may violate ALCOA+ principles set out by the FDA and EMA. ALCOA+ requires that every piece of data in a regulated workflow be Attributable, Legible, Contemporaneous, Original, and Accurate - plus Complete, Consistent, Enduring, and Available.
That changes the engineering question from "does the data arrive?" to "does the data arrive with the provenance, integrity, and traceability a regulator expects?"
Enterprise system integration approaches: point-to-point, hub-and-spoke, and event-driven
Three architectural patterns dominate integration design. Each carries a different profile for complexity, scalability, and audit-friendliness.
- Point-to-point: System A connects directly to System B via a custom link. Fast to build, hard to scale.
- Hub-and-spoke / ESB: All systems connect to a central broker that routes, transforms, and logs messages. More governance overhead, but far easier to audit.
- Event-driven: Systems emit events to a shared bus or message queue; consumers subscribe and react asynchronously. Naturally decoupled and highly audit-friendly because every event is a discrete, timestamped record.
| Approach | Complexity | Scalability | Audit-friendliness | Best fit |
|---|---|---|---|---|
| Point-to-point | Low (initially) | Poor - connections multiply as n² | Low - no central log | Two systems, low change frequency, non-regulated |
| Hub-and-spoke / ESB | Medium | Good - add spokes without rewiring | High - central broker can enforce logging | Multi-system regulated environments |
| Event-driven | Medium-High | Excellent - consumers are decoupled | Very high - event log is the audit trail | High-throughput, asynchronous regulated workflows |
How instrument middleware fits into this picture is worth reading separately - middleware in a lab context often occupies the hub role for instrument data, with its own device-layer concerns distinct from application-layer integration patterns.
Point-to-point integration - direct and fast, but hard to scale
Point-to-point is the right call when you have exactly two systems and those systems are unlikely to change. The connection is direct: System A calls System B's API endpoint and waits for a response. No broker, no transformation layer, no message queue.
The low setup cost is attractive. The problem is that every new system you add creates another bilateral connection, and in a regulated environment each of those connections needs its own validation evidence, its own audit trail, and its own change control path. What starts simple compounds quickly.
Hub-and-spoke and ESB - a shared communication layer
An Enterprise Service Bus (ESB) is the classic hub-and-spoke implementation: a centralised integration platform that receives messages, applies transformation rules, routes payloads to the right destination, and - critically for regulated industries - logs every transaction in one place. That central log dramatically simplifies audit trail reconstruction.
The trade-off is that the ESB itself becomes a system that needs to be validated, monitored, and version-controlled. It is not a passive pipe; it is a regulated component.
Event-driven integration - asynchronous, decoupled, and audit-friendly
Event-driven architecture turns every meaningful state change into a published event. A result is approved in the LIMS - an event fires. A payment is confirmed - an event fires. Downstream consumers subscribe and react independently.
Because each event is a discrete, immutable, timestamped record on the event bus, the event log is the audit trail. This makes event-driven the most naturally compliance-aligned approach for high-throughput regulated workflows. Our event sourcing patterns guide covers the architectural trade-offs in depth.
Integration patterns that appear most in regulated workflows
Request-reply (synchronous API calls)
A system sends a request and waits for a response before proceeding. This pattern is common in regulated environments where the calling system needs confirmation - for example, a lab portal calling an eIDAS certificate service to apply a qualified seal before releasing a report. The synchronous nature creates tight coupling, which means API versioning and error handling must be engineered carefully from the start.
Publish-subscribe (event streams and message queues)
The publishing system emits a message to a broker; one or more subscribers consume it in their own time. This pattern suits regulated workflows where downstream processes are numerous or where the publisher must not be blocked by slow consumers.
Idempotency is non-negotiable here. If a message is delivered twice - which queues can guarantee - processing it twice must produce the same result. We wrote in detail about why idempotency matters in API integrations; it is especially consequential in financial and lab workflows where duplicate records carry direct compliance risk.
File-based and batch transfer (still common in legacy lab environments)
Flat-file exchange - CSV drops, HL7 message files, XML batches - remains common in older lab environments and in integrations with instruments that predate REST APIs. Batch transfers are harder to audit in real time because a failure partway through a batch leaves the system in a partially updated state. Regulated organisations relying on file-based integration should pay close attention to batch integrity checks, checksums, and row-level error logging.
Where regulated constraints change the engineering work
Regulated integration engineering adds four categories of constraint that generic IT projects do not face:
- Data integrity under ALCOA+: Every field in every payload must meet attributability, accuracy, and completeness requirements.
- GDPR data minimisation: Only fields with a lawful basis may cross the integration boundary.
- Change control: Any change to an API schema, endpoint, or routing rule is a regulated change event.
- Validation scope: The integration layer itself must be validated, not just the systems it connects.
Data integrity at the integration boundary
When data moves from one system to another, the receiving system must demonstrate that what it holds is exactly what the sending system produced - unchanged, correctly attributed, and timestamped at the moment of transfer.
In ALCOA+ terms, the integration layer must preserve the "Contemporaneous" and "Original" qualities of the data. That means capturing the source system's record identifier, the transfer timestamp, and a checksum or hash of the payload. Transforming data at the integration boundary - reformatting a date, normalising a unit - must be logged as a transformation event, not silently applied.
GDPR data minimisation: only exchange what is lawfully necessary
GDPR Article 5(1)(c) requires that personal data be "adequate, relevant and limited to what is necessary." At an integration boundary, this means every field in the payload schema should be evaluated before the integration goes live. Does the receiving system need this field? Is there a lawful basis for transferring it?
In payment API integrations, this evaluation often removes several fields that the development team assumed were needed but are not actually consumed by the downstream system.
Change control: every schema change is a regulated change
Add a field to your API payload, change a field's data type, deprecate an endpoint - in a regulated environment, any of these is a change control event. That means a written change request, an impact assessment, regression testing against your validation evidence, and updated documentation before the change reaches production.
We see this catch teams off guard in LIMS-adjacent projects: a vendor updates their instrument driver's output schema, and the team discovers mid-audit that the change was never formally controlled.
What triggers a change control event at an integration point?
Any modification to the API endpoint URL, payload schema (field additions, removals, type changes), authentication mechanism, transformation rules, routing logic in the middleware, or the versioning of a third-party API your integration consumes. Each of these can alter the data your regulated system receives and must be evaluated, documented, and approved before deployment.
Audit trails and validation evidence at integration points
What an audit trail record must capture at an integration boundary
An audit trail at an integration point is not a server log. It is a structured, tamper-evident record of every data exchange. The minimum fields for a regulated integration event are:
- Timestamp - when the exchange was initiated and when it completed (UTC, with timezone)
- Source system identifier - which system sent the data, including its version
- Target system identifier - which system received the data, including its version
- Record identifier - the unique ID of the data object in the source system
- Payload hash - a checksum confirming the payload was not modified in transit
- Transformation log - any field-level changes applied by the integration layer
- User or service account - the identity that triggered the exchange
- Status - success, failure, or partial - with an error code if applicable
- Retry count - how many times the exchange was attempted
For deeper reading on audit trail design, see Audit trails for regulated software: what good looks like and Audit trail requirements for regulated laboratories.
Computerized system validation (CSV) for the integration layer itself
This is the point most regulated organisations miss. ISO 17025 and ISO 15189 accreditation programmes, alongside EMA and FDA computerized system validation expectations, require that any software system affecting regulated data be validated. That scope includes the integration layer.
If you replace your point-to-point API connection with a middleware hub, that middleware is now in scope for CSV. Computerized system validation (CSV) for laboratories covers the full lifecycle approach. The integration-specific point: your validation plan, test scripts, and execution records must address the data flow across system boundaries - not just the behaviour within each individual system.
How to structure validation evidence for an integration layer
Validation evidence for an integration should include:
- An interface specification - the agreed data contract
- Installation qualification records confirming integration components are correctly deployed
- Operational qualification records proving data flows correctly under normal and edge-case conditions
- Performance qualification records confirming correct behaviour with real or representative data
Any deviation found during testing must be formally documented and resolved before the integration goes live in a regulated environment.
Lessons from LIMS-adjacent, eIDAS certificate, and payment API integrations
LIMS-adjacent workflow integration: where data integrity breaks down
In our LIMS-adjacent projects, data integrity failures happen at transformation boundaries, not at transport boundaries. The network delivers the payload correctly, but a silent type coercion - a numeric result stored as a string, a date parsed in the wrong timezone - produces a corrupted record in the receiving system.
The fix is schema validation at ingestion, before the payload is written to the database, combined with a transformation log that records every normalisation step. See the LIMS integration page for the instrument-to-LIMS layer in detail, and why lab integrations fail for the most common root causes we have documented.
eIDAS certificate delivery integration: what a qualified seal adds to the design
Under the eIDAS Regulation (EU) No 910/2014, a qualified electronic seal applied to a document carries legal presumption of integrity and origin. When a lab report delivery system integrates with a qualified trust service provider to apply that seal, the integration must preserve the seal's metadata - the certificate serial number, the trust service provider identifier, the timestamp of sealing - as part of the document's audit trail.
Any transformation of the sealed document after sealing invalidates the seal, so the integration must pass the sealed binary to downstream systems without modification. For more on what a qualified seal means in practice, see eIDAS electronic seal: what it is and how it works.
Mollie payment API: where GDPR and financial regulation shape the integration design
As an official Mollie partner, we have built payment integrations where the data minimisation requirement materially changed the integration design. Mollie's API returns a rich payment object, but most platforms should not store the full object - cardholder details, full payment method metadata, and certain transaction fields carry GDPR obligations that the platform is not equipped to manage.
The right design passes only the fields the platform's own business logic requires, and stores a reference to the Mollie payment ID for reconciliation. Financial regulation adds a parallel concern: payment event logs must be retained for the legally required period and must be retrievable for audit. Our Mollie API integration patterns page covers the implementation detail.
How to reduce integration risk in regulated projects
Regulated integration projects fail more often at the design stage than at the implementation stage. Here are the steps we follow to keep projects on track:
- Define the integration boundary and data classification before writing any code. Map every field, label it as personal data or not, and confirm a lawful basis for each field that is personal data.
- Agree on the audit trail schema at the design stage. Retrofitting audit trail capture into a live integration is expensive and often requires revalidation.
- Include the integration layer in your CSV scope from day one. A validation plan that excludes the integration will fail an audit.
- Establish a change control process for API schema changes. Document who must approve a schema change, what testing is required, and how updated validation evidence is produced.
- Test data integrity end-to-end, not just at each system boundary. A result correct at the source and correct at the destination can still be wrong if the transformation layer introduced a silent conversion.
- Document every external dependency. API versions, SLA commitments, certificate expiry dates, and third-party deprecation timelines all become compliance risks if they change without a managed response.
- Plan for idempotent retry logic. In a regulated workflow, a failed exchange that retries incorrectly can produce duplicate records. Design retry behaviour before it fails in production.
- Review the integration design against ALCOA+ before sign-off. Run each ALCOA+ attribute as a checklist question against your integration architecture.
For further reading on building compliance into integrations from the start, we are preparing dedicated guidance - watch for that content on the Sandorian site. Teams working with legacy platforms will also find upcoming content on integrating with legacy regulated systems useful when it publishes.
Frequently asked questions
What is a systems integrator?
A systems integrator is an organisation or engineer that designs, builds, and validates the connections between separate software systems. In regulated industries, a systems integrator must also understand the compliance constraints - validation requirements, audit trail obligations, change control processes - that govern the integration layer, not just the technical connectivity.
What does system integration mean?
System integration means connecting two or more software systems so they exchange data automatically, eliminating manual transfer and creating a coordinated workflow. The term covers everything from a simple API call between two cloud services to a complex multi-system architecture managed by an ESB.
What are the main types of system integration?
The three most common architectural types are point-to-point integration (a direct connection between two systems), hub-and-spoke integration (all systems connect to a central broker), and event-driven integration (systems emit and consume events through a shared bus). Each type carries different complexity, scalability, and audit-trail characteristics.
What is the difference between API and middleware integration?
An API integration connects two systems directly using a defined interface - typically a REST or SOAP endpoint. Middleware integration places a broker layer between systems; the middleware handles routing, transformation, protocol translation, and logging. API integration is simpler for two-system connections; middleware becomes worthwhile when you have three or more systems, need transformation logic, or require a centralised audit log.
What is an enterprise service bus (ESB)?
An ESB is a middleware platform that acts as the central hub in a hub-and-spoke integration architecture. It receives messages from connected systems, applies transformation and routing rules, delivers payloads to destination systems, and maintains a transaction log. In regulated environments, the ESB's transaction log becomes a primary source of audit trail evidence, which makes the ESB itself subject to computerized system validation.
If you are scoping an integration project in a regulated environment and want to map your systems, data flows, and compliance constraints before committing to an architecture, get in touch with Sandorian to book an integration scoping call. We work with labs, fintech platforms, and eIDAS service providers across Europe - and we have learned, project by project, where the compliance gaps appear before they become audit findings.
Sources
Let's talk
We build the systems that power your business. Let us know how we can help.
Book a 30-min Call