At iStandUK, we believe that when local services share data consistently using open standards, citizens can access vital support far more quickly, while public sector organisations operate free from the friction of disconnected, siloed systems.
With this in mind, we are delighted to share an update highlighting the real-world impact of our work. Open Referral UK (ORUK) has been featured as a core case study in TPXimpact’s newly launched Market-Shaping Playbook.
In this case study, ORUK Technical and Standards Advisor, Mike Thacker sat down for an in-depth video interview with Linda O’Halloran, Senior Partner at TPXimpact. During their conversation, Mike and Linda explored how adopting a common open data standard allows councils, health services and voluntary sector organisations to publish and exchange local service information consistently.
They focused heavily on how improved interoperability streamlines referral pathways, allowing practitioners to connect individuals to community support seamlessly. Crucially, the discussion highlighted how open standards break long-standing dependencies on closed, proprietary software, thereby reducing costs, preventing vendor lock-in, and establishing the key conditions required for nationwide adoption across the public sector. You can watch and listen to the full interview online.
Having ORUK showcased within this playbook reinforces the strategic value of data interoperability, demonstrating that adopting the standard is not merely a technical task, but a vital mechanism for building modern, scalable digital government.
1 Like
This is quite interesting. I have recently been thinking about rigidity, and how a more flexible data standard would work, focusing on controlling how data was documented, rather than how it was exposed. I asked AI about this, and ultimately, it didn’t agree with me, and made me see…
You are architecturally right about where the friction lies, but the commitment to a shared schema exists because data publishers and data consumers have diametrically opposed incentives.
Neither perspective is technically invalid; they just optimize for different ends of the network.
The Two Competing Models
Dimension
|
Documented Source Data (Your Model) |
Canonical Interchange Standard (Open Referral / HSDS) |
Primary Goal
|
Faithful, low-friction representation of domain operational models. |
Zero-friction cross-boundary querying and aggregation. |
Mapping Burden
|
Pushed downstream to data consumers and aggregators. |
Pushed upstream to data publishers and source APIs. |
Domain Fidelity
|
High. OFSTED retains its exact inspection grades, early-years provision types, and statutory frameworks without distortion. |
Low / Lossy. OFSTED must be forced into generic entities (organization, service, location, eligibility). |
Integration Complexity
|
O(N) integrations. An aggregator wanting 50 local directories and OFSTED must write and maintain 51 distinct parsing pipelines. |
O(1)integration. A single client can consume all data sources using the identical parser and search index. |
Why Open Referral Insists on Everyone Exposing the Same Schema
The core mandate of Open Referral is not to represent internal systems accurately; it is to break down directory silos to enable generic discovery tools.
- The Consumer-Side Scalability Problem: If 150 local authorities and national bodies (like OFSTED or the NHS) each publish their own well-documented, native JSON schemas, building a national or regional service directory requires writing, testing, and perpetually maintaining custom ETL transformers for every single source. Open Referral attempts to push that transformation cost upstream onto the provider once, so anyone can build front-end apps, referral bots, or directory engines out of the box.
- Core Discovery Equivalence: From a citizen or social prescribing point of view, a childminder listed on OFSTED and an after-school youth club in a community hall are functionally doing the same high-level thing: offering a localized service with eligibility criteria, a physical or virtual location, and operating hours. HSDS was designed around the minimum set of attributes needed to discover a resource, not manage it.
Where Your Critique Hits the Mark
Where Open Referral regularly stumbles—and where your critique is entirely justified—is treating HSDS as a universal domain model rather than an interchange protocol:
- Information Loss and Semantic Bending: OFSTED’s data model is regulatory and inspectorial. Forcing concepts like “requires improvement” ratings, child-to-staff ratios, or specific regulatory provisions into generic
service_at_location or taxonomy tags either strips out vital operational nuances or turns schemas into messy catch-all metadata blobs.
- Maintenance Drag on Providers: Asking an organization whose primary job is operations or regulation to continuously maintain an unnatural translation layer creates high maintenance overhead. If the upstream domain model updates, the mapping breaks or silently lags.
- The Extension Pitfall: To address domain-specific realities like UK council services and regulatory bodies, the UK standard added profile extensions (HSDS-UK / ORUK extensions). While this helps, it often compromises the simplicity of the standard—reintroducing divergence under the hood.
The Pragmatic Ground
Your assessment is correct that forcing deeply specialized operational data (like OFSTED or statutory healthcare registries) into a generic community services schema is an exercise in fitting square pegs into round holes.
The middle tier of mature data ecosystems is transformation middleware:
- Source providers expose their data natively via well-documented, stable APIs/schemas (exactly as you suggest).
- Mediating ingest pipelines or adapter microservices (often built by platforms or community initiatives) map the subset of data needed for discovery into ORUK/HSDS endpoints, while linking back to the rich, authoritative source API for domain-specific operational workflows.
Open Referral demands a single schema because without one, discovery cannot scale across fragmented ecosystems. However, whenever an initiative forgets that HSDS is merely a thin discovery envelope and tries to treat it as a master record for complex domain data, your critique explains exactly why implementation stalls.
…I thought it as interesting perspective.