Integration & Interoperability for GxP Data
How systems exchange information: interfaces and APIs, events, master data, the semantics on each side, reconciliation, error handling, and lineage across the boundary. Integrations are where regulated data most often lose their meaning — not through corruption but through a field that means something slightly different on each side. These errors are silent by construction, because a successful transfer looks identical to a correct one.
What an explainer is not
A topic explainer is SPEQ’s synthesis of what a practice involves, cited to the standards that govern it. It does not reproduce their text, and it does not determine which of them apply to your product or process.
[ POSITION IN THE FRAMEWORK ]
7 DIMENSIONS · 24 LINKSEvery interface is a place a record can change meaning: units, rounding, time zones and identifiers are transformed in transit, and reconciliation as a permanent activity is the symptom of an interface nobody specified.
06 · QUALITY MATURITY — INTEGRATION & INTEROPERABILITY FOR GXP DATA, REACTIVE TO ADAPTIVE
Systems are connected point to point as projects require. Transfers are trusted because they usually work.
Interfaces are documented and tested at implementation, and failures are detected when someone notices a discrepancy.
Each interface has a specification stating what is transformed and what is preserved, transfer integrity is verified rather than assumed, and failure is detected by the interface rather than by a person.
Data has one authoritative source per attribute, so downstream systems reference rather than copy, and reconciliation becomes a check instead of a repair.
Interoperability is designed — shared identifiers, defined semantics — so a record means the same thing wherever it is read.
SPEQ’s shared five-stage progression, labelled synthesis — not the FDA QMM rating scale. Where does your organization sit? Score your quality system →
07 · REGULATORY & EVIDENCE
GOVERNING STANDARDS · 5
Derived from the 5 standards SPEQ maps to this subject, across 5 regulatory bodies: FDA, EMA, ISPE, MHRA, PIC/S.
RECORDS & OBJECTIVE EVIDENCE
- Interface specifications stating transformations, units, precision and identifiers
- Transfer integrity verification, including how failure is detected
- The authoritative source per critical data attribute
- Error handling and reprocessing arrangements, with records of their use
- Change control covering both ends of each interface
COMMON INSPECTION FINDINGS
- Transformations occurring in transit that no specification describes
- Transfer failures detected by users noticing missing data
- Rounding or unit conversion applied inconsistently between systems
- One system changed without assessing the interfaces that depend on it
- Permanent reconciliation processes treated as a control rather than as a defect
Semantics, not transport
Integration testing concentrates on whether the message arrives, is well formed and is acknowledged. Those are transport properties and they are the easy half. The failure that reaches product is semantic: a result field that carries a rounded value on one side and a raw one on the other, a units assumption, a status code whose meaning differs, a timestamp in local time on one system and UTC on the other.
None of that produces an error. The transfer succeeds, the receiving system stores something plausible, and the discrepancy surfaces months later when two systems are compared during an investigation. The countermeasure is an interface specification that defines meaning — units, precision, rounding, time zone, null handling, allowed values and what each one means — rather than only structure.
Master data is the shared assumption nobody owns
Integrated systems depend on agreeing what a product, a material, a site, a batch or a unit of measure is. Where each system maintains its own list and mapping happens at the interface, the lists drift: a material added in one and not the other, a code reused, a site renamed. The integration continues to work and quietly maps to the wrong thing.
Governed master data with a single owning system, and mappings that fail loudly on an unknown value rather than defaulting, is the structural answer. The failure mode of a permissive mapping is the dangerous one: an unmatched code silently assigned to a default is worse than a rejected message, because a rejected message gets investigated.
Reconciliation is the control that finds silent loss
Because integration errors do not announce themselves, the only reliable detection is periodic reconciliation: comparing what the sending system believes it sent against what the receiving system holds, on counts and on content. Sites that run this find things — a nightly job that has been silently skipping records with a particular character, a queue that drops messages beyond a depth, a filter that was narrowed during a change.
It has to compare content and not only counts. Matching record counts with a field mis-mapped is the exact failure this control exists to catch, and a count-only reconciliation reports success on it. The comparison also has to be automated, because a manual one at any useful frequency will not be sustained.
SPEQ interpretation — the audit trail has to cross the boundary
Each system maintains its own audit trail, and each is complete within its own boundary. What is usually missing is the join: a value in the receiving system that can be traced back to its origin, through the transformation applied, to the record that created it. Annex 11 and Part 11 obligations attach to the regulated record wherever it lives, and a record whose provenance stops at an interface cannot be fully defended.
The practical requirement is that every transferred GxP record carries the source system, the source record identity, the transfer timestamp and the interface version that moved it. That costs four fields and it is the difference between reconstructing a data path in an afternoon and reconstructing it from two audit trails and a log file that has rolled over.
FREQUENTLY ASKED
Why are integration errors so hard to detect?
Because they are semantic rather than structural. A rounded value on one side and a raw one on the other, a units assumption, a timestamp in local time versus UTC — the transfer succeeds, the receiving system stores something plausible, and no error is raised. A successful transfer looks identical to a correct one.
What should an interface specification define?
Meaning, not just structure: units, precision, rounding, time zone, null handling, allowed values and what each one means. Structure-only specifications produce integrations that pass every test and still transfer a value that means something different on arrival.
Why is a permissive mapping dangerous?
Because an unmatched code silently assigned to a default is worse than a rejected message — the rejection gets investigated and the silent default does not. Governed master data with a single owning system, and mappings that fail loudly on unknown values, is the structural answer.
Is matching record counts sufficient reconciliation?
No. Matching counts with a field mis-mapped is precisely the failure reconciliation exists to catch, and a count-only comparison reports success on it. The reconciliation has to compare content, and it has to be automated, because a manual one at a useful frequency will not be sustained.