Written by Technical Team | Last updated 20.08.2026 | 22 minute read
The NHS is moving towards a model of care in which the organisation delivering a service matters less than the ability of different services to work together around the needs of an individual. Neighbourhood health is an important expression of that change. Rather than expecting hospitals, general practice, community services, mental health teams, social care and other local services to operate as largely separate parts of a pathway, the ambition is to bring care together around defined populations and deliver more of it proactively, closer to home.
It sounds primarily like a change to service design. In practice, however, it is also a substantial software and integration challenge. An integrated neighbourhood team may include professionals employed by several different organisations, each with its own clinical systems, operational processes, information governance arrangements, identity infrastructure and technology suppliers. A GP may work from one patient record, a community nurse from another, a hospital specialist from an EPR, a social worker from a local authority platform and a pharmacist from yet another system. The patient, meanwhile, experiences one health problem rather than five organisational systems.
That distinction is important. Neighbourhood health cannot be delivered simply by placing existing services alongside one another and calling them an integrated team. If information still has to be copied between systems, referrals disappear into organisational queues, staff cannot see what colleagues elsewhere have done and nobody has a reliable view of the shared care plan, the organisational chart may have changed but the experience of care has not. Healthcare software therefore becomes part of the operating model for neighbourhood health. Its purpose is not merely to digitise existing processes, but to make cross-organisational working practical at the point of care.
Traditional healthcare software has usually been purchased and configured around organisations or services. A hospital implements an electronic patient record. A GP practice uses a primary care system. A community provider buys a community clinical platform. A local authority operates its social care systems. Each product may work perfectly well within its own boundary, because that is the boundary it was originally designed to support.
Neighbourhood care changes the unit of design. The relevant unit increasingly becomes the person, pathway, multidisciplinary team or defined population rather than the institution. Software needs to support a clinician who starts a task in one organisation, another professional who contributes to it elsewhere, and a patient whose care may move repeatedly between home, general practice, community services and secondary care. That does not necessarily require replacing every underlying system. It does require a digital layer capable of making those systems behave as components of a connected service.
This is particularly important for people with complex needs. Someone living with frailty, multiple long-term conditions and social care requirements may interact with a GP, district nurse, community pharmacist, physiotherapist, hospital specialist, social worker and voluntary-sector support within a relatively short period. In a fragmented model, every interaction can create another hand-off. Each hand-off introduces the possibility that information will arrive late, arrive incomplete, be interpreted differently or fail to generate the action that was intended.
Neighbourhood software should reduce those hand-offs rather than simply digitise them. If a community nurse identifies deterioration, for example, the important question is not whether a note can be stored successfully in the community system. It is whether the people responsible for the next decision can see the relevant information, whether an appropriate action can be initiated, whether somebody owns that action and whether completion is visible to the rest of the team. That is the difference between exchanging data and supporting integrated care.
This also means avoiding the temptation to define neighbourhood digital transformation as the procurement of a single new neighbourhood application. A new front end may be useful, but introducing another isolated product can simply create one more system that staff have to check. In many environments, the better approach will be to connect existing systems, expose appropriate information and functions through standards-based interfaces, and build new workflow capabilities only where there is a genuine gap.
The architectural question therefore becomes: what capabilities must be shared across the neighbourhood, and what can remain within existing systems? Answering that question carefully can prevent a programme from becoming either an unrealistic attempt to replace the entire local technology estate or a superficial portal that presents information without improving how work actually moves between teams.
The most difficult boundaries in neighbourhood health are often invisible. Two professionals may work in the same building while remaining separated digitally by different logins, records, data models, referral processes and organisational policies. Conversely, a well-designed digital service can allow professionals in physically separate locations to work as a coherent team. Digital integration therefore has a direct influence on whether an integrated neighbourhood model exists operationally or only conceptually.
Consider something as apparently simple as a referral. In a conventional pathway, a professional may create a referral document, send it to another service and then wait. The receiving organisation triages it using its own workflow. If information is missing, somebody may telephone or email the referrer. If the patient’s circumstances change, the original referral may already be out of date. The referrer may have little visibility of the queue, decision or eventual outcome. Every organisation can legitimately say that its own system is functioning correctly while the overall patient journey remains fragmented.
A neighbourhood approach should treat that referral as a shared workflow. Structured information can move with the request. The receiving service can accept, redirect or request additional information. Status can be surfaced to appropriate professionals. Important changes can be communicated without relying on somebody remembering to make a telephone call. If responsibility moves from one team to another, the software should make that transition explicit. This is why standards for booking, referral and clinical information exchange matter: they provide building blocks for workflow across systems, not simply technical connectivity.
Identity creates another boundary. Health and care organisations need to know not only who a user is, but what that person is permitted to do in a particular context. A clinician may have legitimate access to information while supporting a patient but should not automatically receive unrestricted access to every source system. Neighbourhood software needs an identity and access model capable of supporting cross-organisational working without weakening security. Authentication, role-based or attribute-based access, legitimate relationships, auditability and session management all become important components of the clinical workflow rather than back-office concerns.
Semantic differences are equally significant. Two systems can successfully exchange a payload and still fail to understand one another. One organisation may describe a service, status, appointment, clinical concept or care-plan element differently from another. Free-text fields compound the problem because information technically becomes visible while remaining difficult to search, prioritise or use in automated workflows. Interoperability therefore needs to extend beyond transport. Shared information models, terminology, coding and clear definitions of the meaning of data are required if software is going to support reliable decision-making across organisations.
There is then the question of operational ownership. This is one of the less discussed software challenges in integrated care. A digital task is safe only when it is clear who is responsible for it. If a test result, deterioration alert or care-plan action is visible to six organisations but owned by none of them, increased connectivity can actually create ambiguity. Neighbourhood software should make ownership, escalation and completion explicit. The system needs to distinguish between “information that can be seen” and “work that somebody is accountable for doing”.
For that reason, the core capabilities of a neighbourhood digital architecture are likely to include:
This distinction between connectivity and workflow is fundamental. A shared care record, for example, can dramatically improve situational awareness by allowing professionals to see information recorded elsewhere. But visibility alone does not create an integrated operating model. Neighbourhood teams also need the ability to initiate, coordinate and complete work across boundaries. The next stage of interoperability is therefore not simply “Can I see the information?” but “Can we complete the care process together?”
Neighbourhood health depends on more than a shared care record. Effective NHS interoperability must allow multidisciplinary teams to coordinate referrals, care plans, tasks and clinical decisions across organisational boundaries. The goal is not simply to share healthcare data, but to create connected NHS digital workflows that help professionals deliver integrated care around the patient.
There is unlikely to be one universal technology architecture for neighbourhood health. Local systems start from very different positions. Some already have mature shared care records and established interoperability infrastructure. Others have substantial point-to-point integration estates, legacy clinical systems or uneven digital maturity across providers. The architecture needs to accommodate that reality rather than assume a blank sheet of paper.
A useful starting principle is to separate systems of record from systems of coordination. Existing EPRs, GP systems, community platforms and social care systems will often remain the authoritative source for particular information. Trying to duplicate all of their functionality in a new neighbourhood platform would be expensive, disruptive and difficult to govern. A coordination layer can instead provide the capabilities that need to span organisations: shared workflows, consolidated views, orchestration, notifications, care-plan coordination and access to data through appropriate APIs.
This architecture should be deliberately loosely coupled. If a neighbourhood service becomes dependent on the proprietary behaviour of one provider’s system, every upgrade or procurement change can destabilise the wider pathway. Integration through well-defined interfaces creates a more resilient model. FHIR-based APIs and NHS interoperability standards can play an important role, but standards should be treated as a means rather than an objective. The architectural test is whether a system component can change without requiring the entire neighbourhood service to be redesigned.
Event-driven integration is particularly valuable. Much traditional integration is request-based: a user opens a system and asks for information. But integrated neighbourhood care frequently depends on knowing when something has changed. A person has been discharged. A new result is available. A medication has changed. A referral has been accepted. A patient has missed an important appointment. A new risk factor has been recorded. An event-based architecture can allow appropriate services to respond to those changes without requiring professionals to continuously search multiple systems.
There is also a strong case for treating the shared care plan as a service rather than simply a document. A PDF care plan uploaded into several records may technically be shared, but it becomes outdated as soon as one organisation changes the plan. A truly shared care plan needs structured elements, provenance, versioning and clearly defined permissions. Professionals should understand what has changed, who changed it, when it changed and which elements represent agreed current intent. Where appropriate, patients and carers should also be able to see or contribute to parts of that plan.
This becomes even more important when neighbourhood teams undertake proactive care. Population health techniques can identify cohorts that may benefit from intervention, but identification is only the first step. A useful digital pathway must connect analytical insight with operational action. If a risk-stratification process identifies a group of people at increased risk of hospital admission, software needs to support what happens next: allocating people to teams, reviewing records, undertaking assessments, creating interventions, monitoring completion and measuring outcomes. A dashboard that identifies risk without connecting it to workflow risks becoming another source of information that busy teams must manually translate into action.
The same principle applies to data platforms. Analytical infrastructure and shared datasets can improve planning considerably, but neighbourhood services need a bridge between population-level intelligence and person-level delivery. Commissioners and operational leaders may need aggregated information about demand, utilisation and outcomes, while frontline professionals need specific information about the individual in front of them. These are connected but different requirements. Architecture should therefore keep operational clinical workflows, population analytics and secondary uses of data appropriately separated while enabling safe flows between them where there is a legitimate requirement.
Patient-facing technology is another part of the architecture rather than an optional addition. As more interactions move through the NHS App and other digital channels, neighbourhood services should avoid creating a parallel professional workflow that is invisible to patients. Appointment management, questionnaires, care-plan information, messaging, remote monitoring and service navigation can all form part of a connected pathway. At the same time, digital-first must not become digital-only. Software should allow alternative routes for people who cannot or do not want to use digital channels, without creating a lower-quality version of the service.
A practical architecture might therefore contain several distinct layers rather than one monolithic platform:
The value of thinking in layers is that local systems can evolve incrementally. A neighbourhood programme does not need to wait for every organisation to replace its core system before improving a pathway. Nor does a local innovation need to become a permanent point-to-point workaround. New capabilities can be introduced behind stable interfaces, then progressively connected to additional services as technical and operational maturity improves.
However, incremental architecture only works if interoperability is treated as a product in its own right. Interfaces require version management, automated testing, monitoring, support arrangements and clear ownership. When a hospital changes its EPR configuration or a source system changes the structure of a message, somebody needs to know before a critical neighbourhood workflow stops functioning. Integration cannot be treated as a one-off implementation task that ends when an interface first goes live.
Technology programmes frequently begin by asking what data needs to be shared. Neighbourhood health programmes should begin one step earlier: what decision or action are we trying to make easier, safer or faster? That question changes software design considerably. A multidisciplinary team reviewing an individual with complex needs does not need every piece of information held by every organisation. It needs a coherent view of the information relevant to the decisions being made, together with the ability to act on those decisions.
User research therefore needs to cross organisational boundaries too. Designing only with one provider can produce software that optimises one stage of a pathway at the expense of another. Discovery should follow real patients and real work through the complete process. Where does information originate? Who re-enters it? Who calls whom? Which spreadsheets exist because official systems cannot support a task? Where do staff maintain unofficial lists? When does somebody have to switch systems or re-authenticate? Which steps rely on professional memory? What happens out of hours? These details reveal the true integration requirements far more effectively than an abstract catalogue of desired features.
Multidisciplinary-team meetings provide a useful example. Simply creating a screen containing information from different providers may make the meeting more efficient, but the greater value comes from capturing the decisions made during it. Who is taking the next action? What is its priority? When should it be completed? What happens if it is not completed? Should the patient or carer be informed? Which source record should be updated? Does another professional need a notification? Software that answers those questions turns an MDT from a meeting into a coordinated clinical process.
Clinical safety needs to be considered at the same level. In cross-organisational systems, hazards often arise at the seams: information displayed out of date, duplicated records, incorrect patient matching, an alert delivered to the wrong team, a failed referral message, ambiguity over whether an action has been accepted, or information that appears complete when another source has not loaded. These risks are not adequately addressed by testing whether individual screens work as specified. Clinical risk management needs to consider the entire end-to-end workflow, including integration failure modes and the behaviour of staff when technology is unavailable.
This makes graceful failure an important design principle. Healthcare integrations will occasionally fail. Networks become unavailable, APIs time out, source systems undergo maintenance and data may arrive in unexpected formats. Safe software does not pretend those conditions will never occur. It detects them, makes failures visible, provides appropriate retry or reconciliation mechanisms and, where required, gives users a safe alternative process. An integration error hidden in a technical log may represent a clinical task that nobody knows has failed.
Information governance is similarly more nuanced than obtaining permission to transfer data. Neighbourhood services bring together organisations with different roles and responsibilities, and software must reflect the purpose for which information is being accessed. Access controls should support legitimate care without creating indiscriminate visibility. Audit records should make it possible to understand who accessed or changed information. Data flows should be mapped clearly enough that controllers and processors understand their responsibilities. New uses of information should be assessed rather than assumed to be covered because the data already exists somewhere in the system.
Trust also depends on data quality. A beautifully designed neighbourhood dashboard will lose clinical credibility quickly if allergies are duplicated, contact details disagree, referral statuses are stale or professionals cannot tell which organisation supplied a piece of information. Provenance should therefore be visible where it matters. Healthcare software development should help users understand where information came from and how current it is, rather than flattening multiple sources into an apparently definitive record that conceals uncertainty.
Patient trust matters just as much. Integrated care should not feel like invisible data movement happening around the individual. Good services should make it understandable how information supports care and provide appropriate mechanisms for patient preferences, communication needs and reasonable adjustments to travel with the person. Where patients can contribute information directly, the system should distinguish patient-entered information clearly while ensuring it becomes useful to the professionals coordinating their care.
Accessibility and inclusion must be designed into this model rather than addressed at the end of development. A neighbourhood approach is intended to improve access and tackle inequalities, yet poorly designed digital services can create new barriers. Mobile-only interfaces, assumptions about literacy, inaccessible authentication journeys or workflows that depend on patients owning modern devices can systematically exclude some of the people neighbourhood teams are intended to support most. Designing alternative routes through the same underlying workflow is therefore preferable to creating entirely separate digital and non-digital services.
The practical lesson is that compliance, safety, interoperability and usability cannot be separate workstreams that converge shortly before go-live. They affect architectural decisions from the beginning. Clinical safety may change how message acknowledgement works. Information governance may alter data storage. Accessibility requirements may change the interaction model. Interoperability constraints may affect the product roadmap. Bringing these disciplines into discovery and healthcare software development early is generally cheaper and safer than trying to retrofit them when a service is already built.
One of the risks in neighbourhood health is creating a collection of successful local pilots that cannot be expanded. A team may build an effective workflow for one neighbourhood because motivated staff know one another personally, agree informal processes and manually overcome gaps in the technology. That can demonstrate clinical value, but it does not necessarily prove that the service can operate across ten or fifty neighbourhoods.
Scaling changes the software problem. Different neighbourhoods may use different GP systems, provider organisations, community platforms and local services. The composition of multidisciplinary teams may vary. Referral destinations and escalation arrangements can differ. Population needs will not be identical. A scalable solution therefore needs to separate what should be standard from what should remain configurable.
The common layer should contain the things whose variation adds little value: integration patterns, security controls, identity, audit, common information models, clinical-safety processes, observability, deployment practices and reusable workflow components. Local configuration can then express the genuine differences: which service receives a referral, which professionals participate in a pathway, locally agreed thresholds, neighbourhood boundaries and available community resources. Without this separation, every deployment becomes a bespoke software project. With too much standardisation, however, teams may be forced into workflows that do not reflect local care. The architecture needs both consistency and controlled variation.
This is also why organisations should resist building neighbourhood software around point-to-point connections between every participant. That model becomes increasingly fragile as the number of services grows. If each application has bespoke logic for every other application, the number of dependencies increases rapidly and changing one component can have consequences across the estate. A reusable interoperability layer provides a more sustainable foundation, particularly when combined with canonical data models, common API contracts and event-based patterns.
Procurement should reflect this long-term view. Evaluating a neighbourhood solution based only on its visible functionality can overlook the characteristics that determine whether it remains viable over time. Buyers should understand how easily data can enter and leave the platform, whether functionality is exposed through documented APIs, how the product supports recognised standards, what happens when another supplier is introduced, how integrations are monitored and who owns the resulting data. Open interoperability is both a technical and commercial consideration because it affects the system’s ability to evolve without becoming dependent on a single supplier.
Delivery should be organised around pathways rather than technology components. Instead of running an “API project”, a “shared record project” and an “MDT application project” independently, a team might focus on a concrete outcome such as preventing avoidable deterioration among people with frailty. The programme can then identify the digital capabilities needed to support that pathway: cohort identification, shared information, assessment, coordinated care planning, task ownership, escalation, patient communication and outcome measurement. The technology has a clear purpose and success can be evaluated in terms of the service rather than the number of interfaces delivered.
Measurement deserves particular attention. Digital programmes often report adoption measures such as logins, messages exchanged or number of users. Those measures are useful operationally but do not show whether neighbourhood working is improving. Better measures connect software to care: whether duplication has reduced, whether referrals are completed faster, whether professionals can resolve more issues without escalation, whether care plans are more current, whether patients repeat information less often and whether teams can intervene earlier. Digital telemetry should help explain how the operating model is functioning.
Software teams should also expect neighbourhood services to evolve. New providers will join. Contracting arrangements may change. National capabilities will develop. Existing EPRs will be replaced. New NHS APIs will become available. Patient-facing functions will expand. Technologies such as remote monitoring and clinical AI may become embedded within pathways. Designing a platform that assumes today’s service map will remain static for a decade is therefore risky.
The strongest neighbourhood architecture is one that allows new capabilities to be added without repeatedly rebuilding the foundations. For example, a remote-monitoring product should be able to publish observations into an established interoperability layer rather than building separate integrations with every provider. A new AI tool should be able to retrieve appropriately governed contextual information and return outputs into existing workflows rather than becoming another standalone destination for clinicians to check. A new voluntary-sector partner should be incorporated according to the information and tasks it legitimately needs, rather than being given access to an entire clinical system.
That requires disciplined software engineering. Automated deployment, API versioning, contract testing, structured logging, monitoring and alerting may sound distant from neighbourhood care, but they directly influence its reliability. Once a digital pathway spans several organisations, an apparently minor technical failure can interrupt coordination between teams. Engineering maturity is therefore part of service resilience.
The aim should ultimately be to make organisational boundaries less visible to the patient without making accountability less clear to the organisations providing care. That is a subtle but important distinction. Integration should simplify the experience of care while preserving clear provenance, responsibility, security and governance behind the scenes.
Neighbourhood health will not be achieved by one national platform, one shared record or one new application. It will emerge from an ecosystem of national capabilities, local systems, interoperable services and carefully designed workflows that allow people to act as one team even when they belong to different organisations. The technical challenge is to connect that ecosystem without reproducing the fragmentation that neighbourhood care is intended to solve.
For NHS organisations, this means treating software architecture and interoperability as core components of neighbourhood service design, not technical work that begins after the operating model has been agreed. For digital health suppliers, it means building products that can participate in a wider ecosystem: products with open interfaces, structured data, clear provenance, strong security and the ability to fit into workflows that extend beyond the product itself.
The opportunity is significant. For years, healthcare technology has largely mirrored the organisational structure of the health service. Hospitals have hospital systems, general practice has GP systems and community services have community systems. Neighbourhood health creates an opportunity to design technology around a different organising principle: the person receiving care and the professionals collectively responsible for supporting them.
At 6B, we work with NHS organisations and digital health innovators to build and integrate software within this complex environment. That includes connecting existing clinical systems, implementing NHS APIs and interoperability standards, developing healthcare software, and engineering the integration layers that allow information and workflows to move safely between organisations. As neighbourhood services mature, those foundations will become increasingly important.
The organisations that make the greatest progress will not necessarily be those that procure the largest new platform. They will be those that understand where digital boundaries obstruct care, establish a robust interoperability foundation and design software around the real work of multidisciplinary teams. When information, actions and responsibility can move safely with the patient, neighbourhood health stops being an organisational aspiration and starts becoming a deliverable model of care.
Is your team looking for help with NHS software development? Click the button below.
Get in touch