A vendor pitching EPR integration will often lead with a logo wall: connectors for this system, that system, the other one. It's a reassuring slide, and it's also, more often than the pitch admits, a promise that doesn't survive contact with a real deployment, because the same EPR product, installed at two different Trusts, is frequently configured differently enough that a connector built for one needs meaningful rework for the other.
The durable answer to EPR integration was never really "which connectors do you have." It's whether the underlying pattern, the actual sequence of parsing, transforming and routing data, is solid enough to apply to any deployment it meets, regardless of whether a named connector exists for it yet.
In brief
Every deployment of every major EPR or PAS is configured differently: local field usage, site-specific workflows, and version differences mean a connector built against one Trust's instance frequently needs real rework at the next, even for the same underlying product. The durable approach treats EPR integration as a pattern rather than a connector catalogue: an inbound feed from the EPR, most commonly HL7 v2 over MLLP, parsed into structured data, transformed into FHIR resources conformant to UK Core, and routed to whatever needs it. That pattern, built once as a capability, applies to any EPR deployment a workflow meets, whereas a pre-built connector only ever covers the specific configuration it was tested against.
Why "we have a connector for that" is the wrong promise
The connector-list pitch is appealing because it sounds concrete: name your EPR, get a tick in a box. The trouble is that EPR deployments aren't standardised the way the pitch implies. Two Trusts running the same underlying product frequently have meaningfully different local configuration: different fields actually populated, different workflows built on top of the base product, different versions in place, sometimes different modules enabled entirely. A connector genuinely built and tested against one Trust's specific configuration is, at best, a strong starting point at the next Trust, not a plug-and-play guarantee, and pitches that imply otherwise are setting an expectation the deployment reality won't meet.
This is a specific, deliberate boundary in how this piece is written: it describes the integration pattern generically, and doesn't name or imply specific pre-built connectors for named EPR products, because that's precisely the promise that tends to overstate what any integration layer, including WeHub's, can guarantee before a real deployment has been seen.
What actually varies between EPR deployments
The variation that matters clusters into a few consistent categories. Local field usage: a field the standard makes optional might be populated religiously at one site and left blank at another, and any integration assuming otherwise will break exactly where it wasn't tested. Workflow-specific customisation: many EPRs support extensive local configuration of order sets, forms and clinical workflows, which shapes what data actually flows and in what shape. Version and module differences: the same product name can represent meaningfully different capabilities depending on the release and which modules a Trust has licensed and enabled. None of this is unusual or a sign of anything gone wrong locally; it's the normal texture of enterprise clinical systems deployed independently across autonomous organisations, and any integration approach that doesn't expect it will be surprised by it.
The pattern: inbound feed, parse, transform to FHIR, route
Stripped of vendor specifics, EPR integration has a consistent shape. Data arrives as an inbound feed, most commonly HL7 v2 messaging over MLLP, since this remains the dominant real-time interface most EPR and PAS systems expose, though file-based or API-based feeds appear too depending on the system and the data domain. That feed is parsed into structured data, treating segments and fields as the structures they are rather than string-splitting them, and explicitly handling the local variation described above rather than assuming a single expected shape. The parsed data is transformed into FHIR resources, conformant to UK Core where the receiving context requires it, using a converter capability built to handle HL7-to-FHIR translation as a maintained function rather than a one-off script. And the result is routed to wherever it's needed: another clinical system, an analytics platform, a workflow that acts on the data.
Built this way, using WeHub Studio's HL7 and FHIR processors, the pattern doesn't depend on a pre-built connector existing for a specific EPR product; it depends on the parsing and transformation capability being robust enough to handle the local variation any real deployment presents, with the deployment-specific detail, which fields are actually used, which local codes need mapping, living in configuration rather than in a rewritten core.
Where the pattern flexes, and where it shouldn't
The honest distinction worth drawing is between what should vary per deployment and what shouldn't. What should flex: field mappings, handling of locally-used optional fields, local code-to-terminology bindings specific to that Trust's configuration. What shouldn't: the underlying parsing logic, the FHIR transformation capability, and the validation applied to outbound data, because if those need rewriting for every new EPR deployment, the pattern has quietly become a connector-per-site model wearing different language. The discipline is identical to the one described in the estate-wide configuration piece elsewhere in this series, applied specifically at the EPR integration layer.
What this means for evaluating an integration approach
For a Trust or vendor evaluating an integration approach for EPR connectivity, the useful question in a demo isn't "do you have a connector for our specific system" so much as "walk me through how your platform would handle a deployment you've never seen before." A vendor whose answer describes the pattern, the parsing capability, the transformation logic, the configuration surface for local variation, is describing something that will hold up at the next unfamiliar deployment. A vendor whose answer is a list of named integrations is describing something that's only been proven to work exactly where it's already been built.
The bottom line
EPR integration that scales isn't built on a growing list of named connectors; it's built on a pattern robust enough to meet any deployment's local variation without needing its core rewritten. Parse properly, transform to FHIR against the right profile, route to what needs it, and keep deployment-specific detail in configuration rather than in the underlying logic. Before the next EPR integration is scoped, ask what in the plan is genuinely reusable capability and what's specific to this one deployment; if the honest answer is "most of it is specific," that's a connector being built, not a pattern.
