Interoperability has been on the NHS agenda for years, and it matters more as digital products take a bigger role in patient care. A remote monitoring tool, a digital triage service, or a patient app is only as useful as the information it can read from, and write back to, the GP record. IM1, short for Interface Mechanism 1, is the NHS England route that makes that possible without a separate integration for every practice.

IM1 is not a single API. It is a set of API standards, plus a pairing and assurance process, that lets a third-party product talk directly to a principal GP clinical system. It is the route most GP system suppliers and NHS buyers expect to see from a product that has to sit inside primary care workflows.

What IM1 is

An interface mechanism lets separate systems do three things. A product can read patient information, extract data in bulk, and enter data into the GP system. The standard exists because the alternative is point-to-point integration, one build per practice or per supplier, which does not scale and does not carry a shared assurance position.

A consuming supplier pairs its product with a provider supplier's system, currently EMIS, now part of Optum, and TPP SystmOne. Each pairing is assessed against that provider's own API and guidance. NHS England has stated that there are no current plans to decommission IM1, which matters for any team deciding whether the assurance effort is worth making.

IM1 is already in production use. The NHS App is itself on the list of assured IM1 suppliers, alongside a range of commercial products, which is a useful signal of how central the standard is to patient-facing services in England.

What it means for clinicians and patients

For clinicians, integration means quicker, better-informed decisions about diagnosis and treatment. Timely, accurate data reduces the risk of missing information and supports safer prescribing, referrals, and follow-up. It also cuts duplicate data entry, because a record updated in one system is reflected in the GP record rather than retyped.

For patients, it means more flexibility and control over appointments and prescriptions. It also improves trust. A patient who books, orders, or shares information through a digital service can be confident that it appears accurately in their GP record.

Why IM1 matters in the wider NHS digital picture

IM1 sits within a wider set of NHS interoperability standards, alongside NHS login, the NHS App, and GP Connect. As care moves beyond a GP-centric model towards multidisciplinary, digitally enabled services, IM1 is one of the ways new products reach the clinical systems where day-to-day work happens. Remote consultation platforms, long-term condition tools, and patient engagement apps all depend on it.

It also supports several national priorities. It reduces administrative burden on primary care, improves access to services through digital channels, supports population health management and analytics, and improves patient safety and data quality. By standardising how data is read from and written to GP systems, it allows innovation to scale without weakening governance or data integrity.

It is worth being clear about where IM1 ends and GP Connect begins. IM1 is the interface a supplier pairs with, one GP system at a time. GP Connect is the FHIR-based national programme that standardises access across systems. In some cases appointment data is available only through GP Connect, which is set out in each supplier's Pairing and Integration Pack. A product that needs both should plan for both from the start.

The APIs a product can pair with

To join the list of assured suppliers, a product pairs with one or more IM1 APIs for each GP system supplier. Each solves a different problem, and choosing the wrong one is a common early mistake.

The Patient API gives patients, or their authorised representatives, access to the functionality a GP practice has chosen to expose. That includes booking, requesting, viewing, amending, and cancelling appointments and repeat prescriptions, and secure communication with the practice. It is the backbone of most patient-facing digital services.

The Transaction API is the real-time option, aimed at professionals. With the permission of the patient and the practice, an application can search for a patient, retrieve and update demographics, retrieve a full medical record, file structured data, retrieve or create a consultation record, and retrieve or file documents. Use cases range from recording structured clinical data to creating consultation entries directly inside the GP system.

The Bulk API delivers scheduled extracts of patient or clinical system user data, daily, weekly, or monthly, once the practice has consented. Because that data can be up to 24 hours old, NHS England does not recommend it for direct patient care. It suits analytics, reporting, population health, and service optimisation, where a day-old extract is acceptable.

The Partner API is specific to EMIS. It is similar to the Transaction API, but with different functionality, and it applies only to the EMIS Web GP module for practices in England.

How the pairing process works

The process starts before any code is written, and it is worth planning for as a whole.

First, a supplier completes the IM1 Clinical and Information Governance prerequisites form and stage one of the Supplier Conformance Assessment List, known as SCAL. This describes the product, its intended functionality, its data flows, and its clinical safety considerations. NHS England's IM1 team then confirms whether the product is viable through the available APIs.

Once viable, the supplier signs a Model Interface Licence with each provider supplier. This gives access to a test environment and the supplier's own guidance, known as the Pairing and Integration Pack. The licence is later updated to include the assured SCAL.

The remaining work falls into three stages.

Testing begins with unsupported testing against the Pairing and Integration Pack. This is where data flows, error handling, and system behaviour should be proved, before moving to the supported test environment where provider suppliers give direct assistance and feedback.

Assurance starts once the SCAL is agreed with the provider. Witness testing then assesses whether the solution behaves correctly in realistic scenarios. A successful outcome results in a Recommendation to Connect, which formally authorises the product to connect to IM1.

Live follows. The product joins the list of assured suppliers, and the supplier takes on the ongoing obligations: reporting faults and incidents, and remaining compliant across the product lifecycle.

What SCAL is checking

SCAL is where most of the effort sits, and treating it as a form is a mistake. It covers information governance, clinical risk management, resilience, and adherence to NHS data standards. A supplier is asked to evidence these, not assert them. That is why clinical safety documentation, hazard logs, and a named Clinical Safety Officer need to exist before the assessment starts, rather than being assembled to meet it.

IM1 compared with bespoke GP integrations

A bespoke integration can be quicker to stand up for a single practice or region. It also repeats its cost with every new site, carries its own assurance burden each time, and leaves a supplier maintaining a separate integration per customer. Compliance varies by implementation, and local assurance effort is often needed on top.

IM1 asks for more upfront, in assessment, onboarding, and assurance. In return it gives a single standardised route to the principal GP systems, aligned with NHS standards for information governance, clinical safety, and supplier assurance, with change managed centrally rather than practice by practice.

The trade-off is straightforward. A short-lived or highly local product may not justify the assurance investment. A product intended for wide, long-term adoption in the NHS usually does.

Security, consent, and trust

Every IM1 integration has to meet NHS information governance standards, including data minimisation, role-based access, audit logging, and secure authentication. Patient consent applies whether data is read in real time or extracted in bulk, and the practice's permission is a separate requirement from the patient's. Clear permissions and transparency are what maintain public trust in digital health services.

Access to free text and documents is controlled and limited to specific approved use cases. IM1 prioritises structured data and governed access, so not all record content is automatically available to a consuming product.

Where IM1 is heading

IM1 is expected to evolve alongside emerging standards. The direction of travel is towards FHIR-based APIs such as GP Connect, broader cross-sector data sharing, and tighter integration with national platforms. For a supplier, the sensible position is to treat IM1 as a durable base, and to design the product so that a change in the underlying interface does not mean a rewrite.

Common questions

IM1 is not legally mandatory. It is the preferred route for connecting third-party services to GP systems at scale, and many buyers and GP system suppliers expect it.

Approval commonly takes several months. The time goes on assurance work, clinical safety documentation, information governance checks, testing, and witness assessment, not on development.

It supports both patient-facing and clinician-facing products. Which APIs a product pairs with depends on the service design, the permissions granted, and whether the product supports patient access, clinical workflows, analytics, or a combination.

It is built for production services with a clear route to rollout. It can support a pilot, but the assurance and onboarding effort rarely makes sense for a pilot alone.

Where this connects to build work

The hard part of an IM1 integration is not calling the API. It is identifying the right patient, validating data before it is sent, writing back only what has been approved, and keeping an audit trail that survives assessment. The closest work we have delivered is a primary care integration against the NHS Spine, where we replaced manual demographic entry with a certificate-secured lookup through QuickSilva's Spine Mini Service, with NHS number modulus checks before any request and a full audit record of every lookup. That discipline, validate first, write safely, prove everything, is what a pairing assessment tests for.