Written by Technical Team | Last updated 03.09.2026 | 22 minute read
Patient demographics are deceptively difficult to manage well.
At first glance, demographic data appears simple: a patient has a name, NHS number, date of birth, address, telephone number, registered GP and other identifying information. In a real healthcare estate, however, these details are copied into Patient Administration Systems, Electronic Patient Records, departmental applications, integration engines, data platforms, portals and specialist clinical systems. Each copy can become stale at a different time.
That creates an architectural problem. A system may have retrieved a patient from the Personal Demographics Service yesterday, but the patient’s address may have changed this morning. Their GP registration may have moved. Their demographic record may have been corrected. A death may have been recorded. In more complex cases, changes to patient identity can affect the way local records should be linked and reconciled.
One solution is to repeatedly query the Personal Demographics Service, or PDS, for every patient of interest. This can work for individual point-of-care interactions, but it does not scale elegantly as a general synchronisation mechanism. Polling millions of local records simply to discover that almost all of them have remained unchanged is wasteful, introduces avoidable latency and creates unnecessary dependencies on a synchronous national service.
The alternative is to make demographics event-driven.
Within the NHS national architecture, PDS Notifications support this model by publishing information about demographic changes through the National Events Management Service, or NEMS, with subscribed events subsequently delivered to receiving systems through MESH, the Message Exchange for Social Care and Health.
The result is an important architectural shift. Instead of repeatedly asking, “Has this patient’s demographic record changed?”, a system can be informed that a change has happened and react accordingly.
The engineering challenge is that receiving a notification is only the beginning. A robust implementation needs to manage subscriptions, transport, duplicate delivery, message acknowledgement, patient identity, asynchronous processing, reconciliation, failure recovery and the relationship between an event and the current authoritative state in PDS. It also needs to avoid treating an asynchronous notification as if it were a perfectly ordered database replication log.
A well-designed implementation therefore separates three concerns: detecting that something happened, obtaining or interpreting the authoritative state associated with that change, and safely applying the result to local systems.
The first step is to understand the responsibilities of the different national components. PDS, NEMS and MESH are related, but they solve different problems.
PDS is the national demographic service. It holds core patient information including NHS number, names, addresses, contact details, date of birth, registered GP and other demographic attributes. For many healthcare applications, the modern PDS FHIR API is the synchronous interface used to search for patients, retrieve a patient’s current demographic record or, where permitted, update information.
NEMS provides publish-and-subscribe behaviour. A system subscribes to event types that it is authorised and entitled to receive. When an appropriate event is published, NEMS determines which subscriptions match and forwards the resulting notification towards those subscribers.
MESH provides the durable message transport through which subscribed notifications can be collected. It is effectively the delivery mechanism at the final stage of the event pipeline. Messages are placed into a MESH mailbox, remain available until retrieved and are acknowledged by the recipient once successfully downloaded.
This distinction matters because an implementation that conflates the three components tends to become fragile. PDS is the demographic authority. NEMS represents event distribution and subscription logic. MESH is a reliable asynchronous transport.
The high-level path can be thought of as:
PDS change → event publication → NEMS subscription matching → MESH mailbox delivery → local event consumer → demographic processing
PDS Notifications currently encompass several important categories of demographic change, including birth notifications, death notifications, change of address, change of GP and broader PDS record change notifications. The latter are particularly significant for organisations attempting to maintain a synchronised local demographic dataset because a generic record-change event can act as an invalidation signal: something about the patient’s national demographic record changed, so the receiving system can determine whether its local representation should now be refreshed.
That is conceptually different from treating every notification as a complete replacement patient record.
This distinction leads to one of the strongest design patterns for event-driven demographics: event as signal, PDS as state.
Key architecture principle: PDS Notifications should usually be treated as a signal that NHS patient demographics may have changed, rather than as a database replication feed. NEMS and MESH provide event distribution and reliable delivery, while the PDS FHIR API remains the authoritative source for current patient demographic data. Designing around this separation makes demographic synchronisation more resilient to duplicate, delayed and out-of-order events.
Where the use case and event definition allow it, the notification tells the consumer that something has changed. The consumer can then use the appropriate authoritative API to retrieve the current patient state. This prevents a local platform from becoming unnecessarily dependent on every historical version, payload convention or sequencing behaviour of the notification mechanism.
It also helps with race conditions. Imagine that a patient changes address twice in quick succession. Your system could receive two notifications after the second change has already been committed to PDS. If your business requirement is simply to maintain the latest demographic state, it may be preferable to retrieve the current PDS Patient resource once rather than attempting to reconstruct state by replaying two intermediate events.
This is why event-driven healthcare integration is not synonymous with event sourcing. Events may be useful triggers without being the authoritative representation of every state transition.
There is an additional strategic consideration. The current PDS Notifications integration remains available in production, while the PDS Record Change event is described as beta. At the same time, the underlying NEMS FHIR API is currently marked as being under review for deprecation, and newer national event patterns are appearing through the Multicast Notification Service, including a PDS change event.
That does not mean an organisation using NEMS should abandon an approved integration. It means engineers should avoid allowing NEMS-specific implementation details to leak throughout their application estate.
An internal event model such as PatientDemographicsChanged is much easier to migrate than hundreds of components that directly understand NEMS subscription structures, MESH headers and FHIR STU3 notification payloads.
The architectural boundary is therefore crucial: terminate the national integration at an adapter, normalise the incoming event and publish an internal representation that expresses your own domain semantics.
Event-driven architectures are often described as though subscribing to more events is inherently better. In healthcare, it is not.
A subscription determines which patient-related information enters your organisation. It therefore has technical, information-governance, operational and potentially clinical consequences.
The correct question is not “Which demographic events exist?” but “Which demographic changes does this system have a legitimate reason to process, and what should happen after each one?”
A hospital PAS attempting to maintain demographics for patients within its active population may have a different requirement from a local authority receiving specific birth or death information. A shared care platform may be interested in another cohort. A system that only needs to react to deaths should not automatically ingest every demographic mutation simply because the technology allows broader subscription patterns.
NEMS supports subscriptions to event types and, depending on the relevant integration and permitted configuration, subscriptions can represent explicit patient interests or broader cohort-based interests. Generic subscription patterns can cover groups such as patients associated with an organisation or geographical scope, subject to the event type and authorised use case.
This introduces an important engineering issue: subscription scope is part of your data architecture.
A very broad subscription creates a substantial downstream processing responsibility. A receiving system must be able to sustain the resulting message volume, secure the information, determine which events remain relevant, manage local patient matching and prove why the data is being processed.
A very narrow subscription, meanwhile, can create lifecycle complexity. If subscriptions are created for individual patients, the system needs dependable rules governing when to create them, when to remove them, what happens when a patient leaves a service and how subscription state is reconciled after outages or failed workflow steps.
The subscription model should therefore be designed alongside the patient lifecycle rather than as an isolated API integration task.
For example, if a local application subscribes when a patient enters a care pathway, it should define what happens when the pathway ends. Does the subscription remain because there is a continuing care relationship? Is it removed immediately? Is there a retention window? Which component owns that decision? What happens if the subscription creation succeeds nationally but the local database transaction fails?
Questions like these become especially important when asynchronous national integration interacts with synchronous local business processes.
It is usually helpful to maintain a local subscription registry. That registry should not merely contain a national subscription identifier. It should record the business reason for the subscription, its intended scope, local ownership, creation status, last successful validation and any lifecycle information needed to reconcile national and local state.
An implementation might maintain attributes such as:
The most important property of this registry is that it allows the organisation to answer a surprisingly difficult question: “Which demographic notifications do we believe we are subscribed to right now, and why?”
Without such a record, operational support teams can struggle to distinguish “No demographic changes occurred” from “Our subscription silently disappeared”.
Subscription management therefore deserves active monitoring. A production system should periodically reconcile expected subscriptions with actual subscription state rather than assuming a successful creation request establishes correctness forever.
The same principle applies during deployment. Configuration should be environment-specific and explicit. Development, integration, deployment and production environments should never share implicit identifiers, mailbox assumptions or subscription state. Promotion between environments should be reproducible, preferably driven by controlled configuration rather than manual operator knowledge.
Security must also be treated as an architectural prerequisite rather than an API-client feature. NEMS is an application-restricted integration. The subscribing application is authenticated and authorised for specific event types. Certificates, mutual TLS configuration and endpoint permissions consequently become part of the application’s runtime dependency chain.
This has operational implications. Certificate expiry can become a demographic synchronisation outage. A system that is functionally correct but cannot authenticate will stop creating or inspecting subscriptions. Certificate inventory, expiry monitoring, renewal procedures and deployment of replacement credentials should therefore be treated as first-class production concerns.
NEMS handles event distribution, but receiving systems collect subscribed event messages through MESH.
This means the consumer is not simply an HTTP webhook waiting for a notification to arrive. MESH uses a mailbox-oriented asynchronous model in which receiving applications poll for available messages, retrieve them and acknowledge successful download.
That distinction changes how the integration should be engineered.
A MESH consumer should be treated more like a durable message ingestion service than a conventional REST API client. It needs a continuous polling loop, bounded concurrency, persistent processing state, replay protection, acknowledgement logic and observable failure handling.
NHS guidance recommends regular polling, commonly every five minutes. In practice, the polling interval should be treated as part of the organisation’s end-to-end latency requirement. The event may already have taken time to travel from its publisher through NEMS into MESH; the consumer then introduces up to its polling interval before processing even begins.
The first rule is to separate retrieval from business processing.
A weak design retrieves a MESH message, attempts every downstream action synchronously and only acknowledges the message after the entire business workflow completes. That can create unnecessary coupling between MESH availability and local system health.
For example, suppose the consumer retrieves a demographic event successfully but the local PAS is unavailable for two hours. If MESH acknowledgement is withheld because the PAS call cannot complete, the transport layer is now being used as a local retry queue. Depending on implementation behaviour, that may generate repeated downloads, block throughput or complicate recovery.
A more resilient pattern is:
MESH → durable local inbox → acknowledge transport → asynchronous processing → downstream systems
Once a message has been safely persisted into a durable local store, the organisation controls its lifecycle. The MESH message can then be acknowledged according to the integration’s required semantics while downstream work proceeds independently.
The exact acknowledgement point should be chosen carefully. A message should never be acknowledged merely because the HTTP request succeeded. It should be acknowledged only after the receiving organisation can guarantee that the event will not be lost if the consumer process crashes immediately afterwards.
That normally means persisting the original payload, relevant MESH metadata, receipt timestamp and a stable message identifier inside a transactional boundary.
After persistence, processing workers can parse and validate the FHIR notification, identify its event type, extract relevant patient identity information and decide what action the event requires.
Idempotency is essential.
Healthcare messaging systems must assume that the same logical event may be observed more than once. Retries, redelivery, operational replay and downstream recovery can all create duplicate processing attempts. Exactly-once delivery should not be assumed simply because the business action should happen once.
The consumer therefore requires both transport-level and domain-level duplicate protection.
Transport-level deduplication may use a stable message identifier associated with the MESH item or incoming event. If the message has previously been persisted, a second receipt can be recognised without executing the workflow again.
Domain-level idempotency is even more important because different notification messages can sometimes point to an already-applied demographic state. If a notification causes the consumer to retrieve the latest PDS record and that version has already been processed, no further local mutation may be necessary.
The processing pipeline should consequently make repeated execution harmless.
A robust internal state machine might move through stages such as received, persisted, validated, demographic-refresh-required, PDS-retrieved, local-update-pending, processed or failed. The system should record errors against the stage at which they occurred rather than reducing everything to a binary success/failure flag.
Poison messages deserve special treatment. A malformed event should not permanently block consumption of every subsequent message. After a controlled number of retries, the message should move into a quarantine or dead-letter workflow where it can be inspected and replayed deliberately.
The original payload should generally be retained according to appropriate governance and retention rules so that engineers can distinguish between malformed input, a parser defect, an unsupported event version and a downstream business error.
Observability should follow the event throughout the pipeline.
A correlation record should connect the MESH message, NEMS/PDS event, NHS number or appropriately protected patient identifier, PDS retrieval and resulting local update. This does not mean placing identifiable patient data indiscriminately into central logging platforms. On the contrary, logs should minimise personal data. Stable internal correlation identifiers allow engineers to trace behaviour without exposing unnecessary demographics in telemetry.
Useful operational metrics include mailbox polling success, messages discovered, messages retrieved, acknowledgement failures, processing latency, duplicate rate, FHIR validation failures, PDS lookup failures, local update failures, dead-letter depth and age of the oldest unprocessed event.
The age metric is particularly valuable. A system processing 10,000 events per hour may look healthy while silently accumulating 11,000 events per hour. Queue depth alone tells part of the story; the oldest-event age reveals whether the platform is falling progressively behind.
The hardest part of event-driven demographics is not receiving the event. It is deciding what the event means for your local patient record.
Healthcare systems commonly maintain their own demographic copy because clinical workflows cannot depend on a national lookup for every screen render, report or downstream interface. The problem is that a local copy should not quietly become an independent truth.
For key national demographic attributes, PDS remains the authoritative national source. An event-driven synchronisation layer should preserve that distinction.
When a relevant notification arrives, one approach is to apply demographic fields directly from the event payload. Another is to use the event as an invalidation signal and retrieve the current patient through the PDS FHIR API. Which pattern is appropriate depends on the event type, payload and business requirement, but the second pattern provides several attractive properties for general record-change synchronisation.
Consider a simple sequence:
At 10:00, the patient changes telephone number.
At 10:01, PDS publishes a change notification.
At 10:02, the patient corrects their address.
At 10:03, another notification is published.
At 10:06, your MESH consumer collects both messages.
If you process each event as a historical patch, your system may briefly update the telephone number while retaining the old address before applying the second mutation. If instead both events independently trigger retrieval of the current PDS record, they may each return the state as of 10:06. With effective idempotency, the second update becomes a no-op.
For a cache or synchronised read model whose purpose is to reflect current demographics, this convergence is often desirable.
This is an important conceptual point: event-driven does not necessarily mean applying event payloads as commands. An event can mean, “Your local view may be stale.”
That approach also reduces coupling to notification schema versions. Your internal demographic model remains primarily mapped from the synchronous PDS representation, while events determine when the mapping should be refreshed.
However, a PDS refresh introduces its own failure modes.
The event transport may be functioning while the PDS FHIR API is temporarily unavailable. The system must not discard the event merely because the subsequent read fails. Instead, the local processing record should remain retryable.
Retries should use exponential back-off and jitter, with upper bounds appropriate to the workflow. A nationwide PDS incident should not cause thousands of consumers to hammer the service with immediate retries at identical intervals.
The system should also collapse redundant work.
Suppose a single patient’s record generates six events while the PDS API is unavailable. When PDS recovers, it may be unnecessary to perform six identical reads. The synchronisation service can coalesce outstanding invalidations for the same patient and retrieve the latest state once.
This technique is particularly valuable at scale because demographic events often exhibit locality. Organisational migrations, data-quality exercises or bulk corrections can generate bursts involving many records, while individual patients may also experience multiple closely related changes.
Patient identity needs equal care.
The NHS number is a central national identifier, but production systems must be prepared for identity lifecycle complexities rather than hard-coding a permanent one-to-one assumption between an NHS number and a local database row.
Changes to patient identity, duplicate records and supersession scenarios can have consequences beyond demographics. A naïve integration might treat an incoming identifier change as simply “update the NHS number column”. In reality, the application may need to identify whether the new identifier already maps to another local patient, whether records need reconciliation and whether clinical data could be associated with the wrong person if the change is applied automatically.
Identity changes should therefore be processed through dedicated patient-matching and record-reconciliation rules rather than ordinary demographic field mapping.
Death notifications should similarly be treated as domain-significant events rather than merely setting another boolean attribute. A recorded death can affect appointment scheduling, correspondence, population management, medication workflows, referrals and downstream messaging. Organisations should decide deliberately which workflows react automatically and which require human or clinical governance.
This is where the event-driven demographic layer becomes more than an integration adapter. It becomes a controlled propagation mechanism for clinically important identity state.
The safest implementation separates raw national events from downstream consequences. One service can determine that the authoritative demographic state has changed; downstream domain handlers can then decide whether appointment, correspondence or clinical systems need additional actions.
This prevents a single MESH consumer from becoming an enormous orchestration engine containing every piece of organisational business logic.
An event-driven demographic service should be designed on the assumption that every component will eventually fail.
PDS can be unavailable. NEMS can be unavailable. MESH polling can fail. Certificates can expire. A local message broker can stop accepting messages. A database can become read-only. A downstream PAS can reject an update. A deployment can introduce a parser defect. A patient can change several times while part of the pipeline is offline.
The architecture is successful not when failures never happen, but when those failures are visible, recoverable and do not silently corrupt demographic state.
The most important safety mechanism is reconciliation.
Notifications provide efficiency, but reconciliation provides confidence.
A receiving platform should have some means of determining whether local demographic state remains consistent with the authoritative source for the population it is responsible for. The precise reconciliation strategy will depend on permissions, scale and use case, but the architecture should not assume that a real-time event path can never lose operational continuity.
Reconciliation can happen at several levels.
At the subscription level, expected subscriptions can be compared with national subscription state.
At the MESH level, mailbox health and message age can reveal stalled ingestion.
At the processing level, every persisted event can be checked for a terminal status.
At the patient level, demographic records can carry metadata indicating when they were last refreshed from PDS and what authoritative version or update information was observed where available.
A carefully designed system can then answer questions such as: “Which patients have demographic state older than our tolerance?”, “Which incoming events have not produced a successful refresh?”, and “Which subscriptions have not been verified recently?”
These questions are far more useful during an incident than “Is the integration service running?”
Disaster recovery also requires attention to acknowledgement boundaries.
If MESH events are acknowledged after durable persistence, restoring the event-ingestion database from an old backup can create a gap: MESH may believe messages were successfully collected while the restored local system has forgotten them.
That means backup and disaster-recovery design must consider message offsets and transport acknowledgement state, not simply database recovery.
One approach is to preserve the durable event store with an RPO consistent with the acknowledgement strategy. Another is to use replicated storage. Whatever model is chosen, the team should explicitly test the scenario: “What happens if we lose the local event database after acknowledging MESH messages?”
If the answer is “we permanently lose awareness of demographic changes”, the recovery architecture is incomplete.
The same reasoning applies to deployments. The ingestion component and its message parser should be backward-compatible wherever practical. A new release that suddenly cannot parse an existing notification version should not acknowledge and discard the message. Schema validation should occur before the event crosses the point of no recovery.
Production release strategies should also separate ingestion compatibility from new business behaviour. It is safer to deploy support for a new event format before enabling new downstream actions than to combine transport, parsing and clinical workflow changes into a single release.
There is also a broader architectural reason to establish these boundaries now.
NEMS is currently a production NHS service but is under review for deprecation, while NHS England is developing and using the newer Multicast Notification Service pattern for patient-related state-change events, including newer PDS change-event capabilities.
Engineering teams should therefore resist designing a “NEMS application”. The goal should be a patient-demographic event capability with NEMS and MESH as one external integration implementation.
A future-proof internal architecture might look conceptually like:
National event adapter → canonical demographic-change event → durable internal event bus → demographic synchronisation service → domain consumers
Today, the national adapter may create the canonical event from a NEMS subscription delivered through MESH. In another architecture, a newer national event service may expose a different subscription model, FHIR version, delivery mechanism or notification structure.
If those details terminate at the adapter, the synchronisation engine does not need to care.
This is particularly relevant because legacy NEMS integrations use FHIR STU3, whereas newer NHS event interfaces increasingly use more modern API-platform patterns and FHIR R4 representations. Allowing raw external FHIR objects to become internal domain models creates migration work later.
Instead, translate external payloads at the edge.
An internal event might contain a small, stable semantic representation: the patient identifier, event category, source, observed timestamp, external message identifier, event version and a flag indicating whether authoritative demographic refresh is required.
The service can retain the original external payload for audit and troubleshooting without forcing every downstream component to understand its schema.
There are several engineering principles worth preserving throughout the design:
When implemented this way, PDS Notifications offer more than an alternative to scheduled polling. They provide the foundation for a genuinely event-driven demographic architecture in which healthcare systems react quickly to national patient changes while remaining resilient to temporary failure and changes in national infrastructure.
That architecture can materially improve data freshness. A local clinical system no longer has to wait for a nightly demographic synchronisation job to discover that information changed earlier in the day. Downstream workflows can respond sooner to relevant updates, and unnecessary PDS reads can be reduced by refreshing patients because a change has been signalled rather than repeatedly querying records that have not changed.
The largest benefits, however, come from treating event-driven demographics as an engineering capability rather than simply connecting three NHS services.
PDS, NEMS and MESH provide the national mechanisms, but the receiving organisation is responsible for the reliability of everything after the message enters its estate. Durable ingestion, idempotency, observability, patient identity management, reconciliation and transport abstraction are what transform a technically functioning integration into a dependable healthcare service.
The strongest designs therefore assume that demographic change is continuous, distributed and asynchronous. They accept that events may be delayed or repeated. They maintain a clear distinction between notification and authoritative state. They preserve the ability to replay work after failure. And they keep national integration protocols at the edge of the platform so that the internal architecture can survive changes in NHS event infrastructure.
That is the real value of building patient demographics around events: not merely receiving changes faster, but creating a system that can continuously converge towards authoritative patient identity and demographic state without depending on perfect timing, perfect delivery or perfect availability from any single component.
Is your team looking for help with NHS PDS Notifications and NEMS integration? Click the button below.
Get in touch