A screening result can reach the correct system and still fail to support the next action.
Making interoperability work at the frontline means considering both how data moves and how people use it to provide care.
The NHS 10 Year Health Plan sets out three key shifts for the health service going forwards: from hospital to community, analogue to digital, and sickness to prevention.
Delivering these shifts depends on health information moving reliably across services and organisational boundaries. In children’s health, those connections span maternity services, primary care, community teams and screening programmes, while families also need information they can understand and use.
Shared data standards and integrations, including FHIR, provide the structure needed to exchange that information consistently. They are an essential foundation, but the software built around them can still make day-to-day work harder.
Information may arrive without enough context, sit outside the usual workflow or fail to create a clear next action. Staff may still need to search across records, enter information more than once or establish who is responsible for following it up.
The information has moved but the pathway around it has not.
This implementation gap appears when services reflect technical structures more closely than the work people need to complete. The consequences can include duplicate administration, increased cognitive demand and less time for care.
In 2022, the British Medical Association estimated that delays caused by inadequate or malfunctioning IT were costing doctors in England more than 13.5 million working hours each year.
Source: British Medical Association, Getting IT Right, 2022.
How UCD supports health data interoperability
User-centred design (UCD) helps teams look beyond whether a technical exchange has completed and examine whether the information supports the work that follows.
In practice, that means checking whether people can:
- Find the right information at the point it is needed.
- Understand what it means and whether it requires attention.
- See who owns the next step.
- Complete or escalate the required action.
- Confirm that follow-up has taken place.
Working alongside data engineering and formal clinical safety assurance, UCD can reveal risks that technical testing alone may not identify.
Why data standards aren’t enough
Health data standards establish shared rules for recording and exchanging information. They cannot determine how that information fits into someone’s work.
A local Child Health Information Service (CHIS) can use consistent schemas and identifiers while still requiring staff to move between systems, reconcile records manually or enter the same information several times.
Receiving a screening result is also only one stage in the pathway. Staff need to see what has happened, whether the result requires attention, who owns the next step and whether any follow-up has been completed.
When a service does not make those things clear, people have to create the connections themselves.
When connected data does not complete the pathway
The consequences can affect safety as well as efficiency.
A 2025 thematic review by the Health Services Safety Investigations Body found that electronic patient record systems had contributed to patient safety incidents when they lacked the functions organisations needed or did not adequately support their users.
The review also found that local users were not always involved effectively during configuration and testing. This matters because configuration affects what information people see, how tasks move between teams and whether the technology reflects the conditions in which it will be used.
A system may pass a technical integration test without showing whether someone can complete a critical task during a busy clinic, respond to an incomplete record or identify an unresolved result across a large caseload.
The cost of digital friction
Digital friction is usually spread across small, repetitive tasks: waiting for systems, searching for records, checking whether information is current and entering data that already exists elsewhere.
Individually, these tasks may take minutes. Repeated across teams, organisations and pathways, they consume time that could be spent on care and create more opportunities for information to become incomplete or inconsistent.
An analysis of 2023/24 ERIC data by Future Health Intelligence reported that the NHS spent more than £230 million on physical medical records despite widespread digital adoption.
There are several reasons physical records remain in use, so that figure cannot be attributed to usability alone. It does show how much work remains before digital services can reliably replace parallel processes.
Where paper records, digital systems and local workarounds operate together, staff may need to check several places before they can be confident they have the complete picture.
Where CHIS and screening pathways become vulnerable
Our earlier article on closing the visibility gap in children’s health explored how a real-time population register could create a more connected view of a child’s journey.
A connected data layer can help make that information available, but the services built around it still need to support each handover and decision across the pathway.
Following a Newborn and Infant Physical Examination, the result must reach the appropriate service and make any required follow-up visible. A newborn blood spot result may be incomplete, late or require further action. Hearing screening information may need to pass between maternity, screening, audiology and child health teams.
In each case, someone needs to understand what has happened, what should happen next and whether responsibility has passed safely between services.
Families also need information that is timely, clear and appropriate to their circumstances. A technically successful exchange offers limited value if a result becomes harder to explain or responsibility for communicating it remains unclear.
Research and testing allow teams to trace these handovers and exceptions before they become embedded in the service. They can show whether information is visible, whether its meaning is clear and whether every important action has an owner.
Interoperability should be judged by
safe, timely action
not whether the data was received
Engineering for human behaviour
In delivery, we often find the most important risks in the gap between the formal process and the way work happens day to day.
A process map can show the intended route through a pathway. Research adds the interruptions, competing priorities, local responsibilities, informal handovers and established workarounds that shape how people complete it.
For child health services, that means involving clinical, administrative and operational teams. Parents and carers can also help teams understand how appointments, information and follow-up are experienced outside the service.
Research and testing should reflect the different conditions in which the service will operate, including:
- Routine tasks and common pathways.
- Missing, delayed or incomplete information.
- Failed integrations and duplicate records.
- Children moving between services or geographical areas.
- Accessibility, identity, safeguarding and digital exclusion.
Prototypes give teams a way to explore these conditions while the service can still change. They can reveal whether people notice important information, understand what it means and complete the necessary task under realistic time pressure.
The work continues through configuration, implementation and ongoing improvement. Once a service is being used at scale, new workarounds, support needs and changes to the wider pathway may emerge.
Turning user insight into the service
The technical architecture must support the way work moves between people and organisations.
NHS England’s Digital Child Health FHIR integration uses a publish-and-subscribe model. Events such as blood spot test outcomes, newborn hearing results and NIPE outcomes can be published through the National Events Management Service and shared with subscribed systems.
The integration moves an event between systems. Research and service design establish who needs to receive it, what context they require, how it should appear and what action should follow.
For example, research might show that administrators need to monitor unresolved screening results from a shared worklist. To support that workflow, the service may need:
- A visible status for each result.
- Clear ownership of the next action.
- An escalation route for unresolved cases.
- Monitoring that shows whether follow-up has been completed.
Data and engineering teams can then build the event definitions, permissions and monitoring needed to support those requirements reliably.
This is how user insight can influence more than the interface. It may affect the information an event contains, how it is routed, the access rules surrounding it and the way exceptions are handled.
The approach also reflects NHS England’s guidance on nursing and midwifery documentation, which calls for intuitive data entry and for information to be entered once and reused where clinically appropriate and safe.
From design principle to frontline outcome
Designing for risk throughout delivery
Research findings need to remain visible through configuration and implementation.
A finding about an informal handover or hidden workaround may require a change to a data requirement, event definition, access rule, escalation process or approach to monitoring. Testing can then examine whether that change holds up when information is missing, records are duplicated or an integration fails.
User research and service design help teams understand where risk may emerge and how it could be reduced. Clinical safety provides the formal process for assessing, documenting and managing that risk.
The DCB0129 standard sets clinical risk-management requirements for organisations developing and maintaining health IT systems. DCB0160 applies to health organisations deploying, using, maintaining or decommissioning them.
This work supports formal assurance by giving clinical safety teams clearer evidence of how risks may appear when technology becomes part of a wider service. It also gives delivery teams an opportunity to address those risks while the service can still change.
From health data exchange to safe, timely action
The NHS shift towards digital, preventative and community-based care depends on connected information reaching people in a form they can use.
Across this connected childhood series, we have considered the role of CHIS, connected data layers and a Single Unique Identifier in creating a more complete view of a child’s health journey. We have explored why a real-time population register matters for child health and safeguarding and what neighbourhood health services could mean for families.
The same service also needs to work when information is missing, a child moves between areas or a family cannot use the expected digital route.
Interoperability should be judged by the safe, timely action it enables.
Reaching that point requires UCD, data, engineering and clinical safety to be aligned from the beginning. Insight from frontline teams and families should shape the architecture, workflows, permissions, monitoring and assurance surrounding the service.
Bringing those disciplines together can reduce the burden placed on frontline teams, make important information easier to act on and support continuity for children and families across local authority boundaries.
Moving a connected child health service from policy or pilot into delivery?
Speak to Hippo’s health technology experts about bringing user-centred design, data and engineering together around the realities of frontline care.
Frequently asked questions about health data interoperability
Integration connects systems so they can exchange data. Interoperability goes further by ensuring the information can be understood and used by the people delivering care, without relying on additional searches, re-entry or manual reconciliation.
FHIR provides a shared structure for exchanging health information consistently, but it does not define the complete service around that exchange. Teams still need to consider how information appears, who owns the next action and how exceptions are handled.
Technical measures can confirm whether information has been sent and received. Frontline measures should also examine whether it can be found and acted on, whether follow-up is completed and whether manual workarounds are being reduced.
UCD should begin during discovery, while the service and technical approach can still be shaped. Research and testing should then continue through configuration, implementation and ongoing improvement as workflows and user needs change.
These exceptions should be clearly visible and assigned to an appropriate person or team. Services also need defined escalation routes and monitoring so unresolved information does not disappear between systems or organisations.
