Migrating from National Events Management Service to Multicast Notification Service

NEMS and MNS both use a publish-subscribe model, but they handle event data differently.  

• NEMS sends detailed event messages containing full business payloads directly to subscribers, collected via MESH using the NEMS FHIR STU3 API.  

• MNS uses a lightweight event model. An MNS event confirms that an update has occurred and provides a URI or resource link pointing to where the full information is held. It does not contain the underlying business event payload.  

Following migration, subscribers will: 

• subscribe to relevant events in MNS.  

• receive lightweight events as changes occur.  

• use the resource link provided in the event to identify where the data is stored.  

• retrieve the required underlying information directly from the relevant source service (for example, PDS FHIR API or Child Health FHIR API).  

This model ensures subscribers always consume data directly from the primary source.  

Migrating as a publisher involves making event data accessible via the designated source service before publishing corresponding events to MNS.  

You must: 

1. Identify existing NEMS events: Audit all event types currently published through NEMS.  

2. Confirm MNS event availability: Verify whether equivalent events exist in the MNS events catalogue. If an event type or required metadata is missing, contact the onboarding team to discuss your requirements before proceeding.  

3. Onboard to the source API: If your system does not already write to or expose data via the required source API, complete onboarding and technical integration for that source API first.  

4. Onboard to MNS: Complete publisher onboarding for MNS.  

5. Conduct data schema mapping: Map existing NEMS FHIR STU3 payload fields to the target source API resources (typically FHIR R4) to ensure no required downstream clinical or administrative data fields are lost. 

6. Implement dual-publishing: Configure your systems to publish to both NEMS and MNS during the transitional window to support subscribers migrating at different cadences. 

7. Coordinate decommissioning: Do not unilaterally cease publishing NEMS events when your MNS build is complete. Agree cutover schedules with downstream subscribers and regional programmes, and only decommission NEMS publishing feeds once all dependent subscribers have migrated. 

You must replace your NEMS subscription with an MNS subscription and build the capability to call the underlying source API to fetch the required event details.  

You must: 

1. Audit current subscriptions: Identify every NEMS event your systems consume, noting all dependent downstream processes and workflows.  

2. Identify MNS equivalents and source APIs: Map each NEMS event to its MNS replacement and corresponding source API. If an event replacement cannot be identified, contact the onboarding team.  

3. Onboard to source APIs: Access to MNS does not grant automatic access to source APIs. You must onboard to each required source API.  

4. Onboard to MNS: Complete subscriber onboarding and configure required event subscriptions and filters.  

5. Update integration architecture: Update ingestion pipelines to receive MNS events, use the resource links, call the source service, and ingest the required records.  

6. Perform end-to-end testing: Test the full integration cycle, including event receipt, token retrieval, API calls, and failure/retry flows.  

7. Manage dual-running: Implement deduplication logic to handle parallel events if both NEMS and MNS feeds are active during migration.  

8. Retire NEMS subscriptions: Decommission NEMS feeds only after end-to-end validation of the MNS and source service workflow is confirmed.  

MNS supports PDS events in production. Subscribers consuming demographic updates via NEMS must move to MNS and use the PDS FHIR API as the source API.  

Supported events in the MNS catalogue include:  

• changes to a PDS record  

• changes of GP  

• death notifications  

• NHS number changes  

Review the event documentation for filter options and subscription rules before development. Do not assume a direct one-to-one field match with legacy NEMS payloads.  

The target architecture for child health integrates MNS for events and Child Health FHIR R4 as the underlying source service.  

• Existing publishers and subscribers: Replacement functionality is actively being developed. Begin migration planning and gap analyses now, but maintain your existing NEMS integration. Do not retire your NEMS child health feeds until the replacement services are released, tested, and mutually agreed.  

• New organisations: New child health integrations will not be onboarded to NEMS. Contact the onboarding team to align your technical roadmap with the Child Health FHIR R4 and MNS rollout.  

Start migration planning early to accommodate technical development, onboarding governance, and inter-organisational coordination.  

Managing cutover and dual-running 

To avoid service disruption across care settings, publishers and subscribers must coordinate their cutovers:  

• Dual-publishing obligations: Publishers must maintain active NEMS event publication alongside MNS until downstream subscribers have cut over and validated their pipelines. 

• Deduplication: Subscribers consuming both feeds during parallel running must ensure systems can handle identical business updates arriving through both NEMS and MNS without creating duplicate local records.  

• Rollback criteria: Define clear operational rollback criteria in case source API retrieval or notification delivery fails during cutover.  

Requirement gaps and missing functionality 

If you identify NEMS event types, data attributes, or filtering rules that are not currently supported by MNS or the relevant source APIs, do not attempt to proceed with an incomplete architecture. Submit your use case to the programme team via [NHS England Service Desk / Onboarding Team contact link] so the requirement can be formally reviewed.  

Before decommissioning NEMS integrations, verify the following milestones:  

• all currently consumed or published NEMS events are catalogued

• corresponding MNS events and authoritative source APIs are identified

• any missing event functionality or payload requirements are raised with the NHS England team 

• schema mapping between NEMS FHIR STU3 and source API FHIR R4 resources is complete

• onboarding and authentication credentials for both MNS and all required source APIs are secured  

• publishers have implemented source API updates and configured dual-publishing

• subscribers have implemented event processing, data retrieval from the source service, and deduplication logic  

• end-to-end integration and retry testing across MNS and source APIs are signed off 

• cutover schedules and rollback criteria are formally agreed between publishers and subscribers 

• NEMS feeds are decommissioned only after downstream operational stability is confirmed 

Use these resources to plan and implement your migration: 

• Multicast Notification Service (MNS) – understand MNS and how publishers and subscribers access the service 

• MNS events catalogue – find events currently available through MNS 

• MNS API specification – technical API specification 

• PDS FHIR API – retrieve patient demographic information from PDS 

• Child Health FHIR R4 – retrieve child health information using the new Child Health API 

• Integration Support: For questions or functional gap submissions, reach out to us in the Developer Community