WeHub Proof

Validate it.
Move it clean.

WeHub Proof checks live FHIR resources and bundles, and HL7 v2 feeds, against the profiles, terminology and referential rules you configure. Run it on the Managed footprint hosted by WeHub in the UK, or on a Runner inside your own tenant, where the payload never leaves your boundary.

Get it onMicrosoft Marketplace

Engines

Choose your validator type

Each Proof validation server runs one validator type, chosen when you create the server.

  • Dike: large FHIR bundles in a single pass
  • HAPI: open-source, enhanced by WeHub
  • Themis: WeHub's HL7 v2 validator
  • OpenAPI: full REST API, spec included
  • Inline, synchronous: issues in the same call

Pipelines

Studio integration

Proof is a step in a WeHub Studio pipeline, and can appear more than once. Validate the inbound HL7 v2 message, transform it to FHIR, validate the output, deliver. Payloads that fail at either point branch to a review or dead-letter queue instead of reaching the target system.

Standards

Profile library

Validation is only as good as what you validate against. Proof keeps a library of everything a server can check a payload against:

  • Implementation Guides — FHIR NPM packages, dependencies resolved.
  • UK Core preloaded; add NHS England, regional or your own.
  • Individual StructureDefinitions, for profiles outside a package.
  • HL7 v2 schemas, plus your own message profiles and Z-segment definitions.

Pick a profile per request by canonical URL, or set a server default.

Terminology

Semantic validation

Codes are checked for meaning, not just shape. For FHIR, Proof validates coded values, ValueSet bindings and CodeSystem membership against WeHub Term by default, and can point at any FHIR terminology server you already run. For HL7 v2, coded fields are checked against HL7 tables and the same terminology servers.

Resolution

Referential integrity (FHIR)

References are resolved, not assumed. Proof checks that a referenced resource exists, that its type matches the reference, and that bundle-internal references resolve, against a WeHub FHIR server or your own. Dangling and mistyped references come back as issues with the exact FHIRPath location. Referential integrity checks are available on Dike only.

Validator type

Dike

FHIR20ms · against UK Core

HAPI

FHIR121ms · against UK Core

Themis

HL7 v226ms

Time to validate one payload. Shorter is faster.

Deploy

Run Proof where your data lives

Same API and same validator types in each.

Your Azure tenant

Runner

Inside your own Azure tenant. Data never leaves.

See the footprint
Air-gapped · HSCN

Self Hosted

Your infrastructure, air-gapped or HSCN.

See the footprint

FAQ

Common questions

WeHub Proof checks FHIR resources and bundles, and HL7 v2 feeds, against the profiles, implementation guides and schemas you choose. Connect a terminology server and it also checks the codes and referenced values inside each message.

Three ways. Managed, hosted by WeHub on Azure in the UK, with UK data residency (UK South) and per-customer tenant isolation. Runner, inside your own Azure tenant, where payloads are validated within your boundary and the data never leaves it. Or Self Hosted, on your own infrastructure. Same API and same validator types in each.

Yes. UK Core ships preloaded, and you can add NHS England, regional or your own FHIR NPM packages, with dependencies resolved on the way in. Individual StructureDefinitions can be loaded for profiles that sit outside a package, and HL7 v2 schemas can be extended with your own message profiles and Z-segment definitions.

WeHub Proof runs on Dike, WeHub’s own validation engine, by default. You can choose HAPI FHIR Validator for FHIR or Themis, WeHub’s HL7 v2 validator, per server.

Yes. The issues come back on the same request, so Proof can sit in a live message path rather than behind a queue. A validator that queues turns an inline ADT feed into an asynchronous one, and you then need somewhere to park the message and a way to match the verdict back to it. Proof answers in the request, so the integration pattern stays as it is.

Yes. Everything Proof does is available over REST, including creating the validation server itself. An OpenAPI spec and full documentation ship with the service.

More answers in the WeHub FAQ

Ready when you are

See Proof on your own systems.

We'll run WeHub Proof against your own FHIR resources and bundles, and HL7 v2 feeds, in the infrastructure your data has to stay in.