An IM1 integration is two programmes running together. One is engineering, the connectors, mappings, and write paths. The other is assurance, the clinical safety case, information governance, the Supplier Conformance Assessment List, and the licences. Teams that treat the second as paperwork to finish after the build are the ones that miss their dates. The order below keeps both moving in parallel, and it assumes you already know what IM1 is. If you need that first, our explainer on IM1 covers the standard and the pairing process.

Step 1: Settle the route and scope before any code

Start by deciding which IM1 API your product needs, because the choice shapes everything downstream. The Patient API suits patient-facing services. The Transaction API suits real-time, professional-facing work such as searching for a patient, retrieving and updating demographics, filing structured data, and retrieving or filing documents. The Bulk API suits analytics and reporting, and it is not recommended for direct care because its data can be up to 24 hours old. The Partner API exists for EMIS only.

Then build a capability matrix. For each GP system supplier you intend to pair with, list the endpoints you will use, the payload shapes, any rate limits, and the pairing requirements, all taken from that supplier's Pairing and Integration Pack. Note where appointment data may only be available through GP Connect rather than IM1, since that changes your scope. This one document forces product, engineering, and clinical leads to agree what is being built, and it becomes the backbone of the backlog and the test plan.

Step 2: Decide the architecture and the canonical model

Each supplier's implementation differs in endpoints, authentication, data shape, and operational expectations. IM1 gives a common assurance wrapper, but your engineers still carry the per-supplier differences. There are two sensible responses. You can build a connector per supplier. Or you can put a normalised internal API in front of them, so the rest of your codebase never sees supplier quirks. The second adds work at the start and removes a great deal of it when a supplier changes an endpoint or you add a second supplier.

Whichever you choose, define one canonical data model and write a mapping specification for each supplier. Treat coding systems as first-class. Use SNOMED CT for clinical concepts and dm+d for medicines, keep a mapping file for supplier-specific codes, and normalise legacy medicine codes as close to dm+d as you can. Record provenance on everything you import, the source system, author where available, effective dates, and identifiers. That is what lets you reconcile duplicates and explain a discrepancy to a clinician later.

Decide at this stage how practices will be onboarded. Pairing is per practice, and it needs the practice's permission. Plan an admin experience that shows each practice's status, paired, pending, or suspended, and stores practice-level credentials safely. Leaving this to be handled by hand is how operational work quietly takes over a small team.

Step 3: Start assurance in parallel

Do not wait for the build. Complete the IM1 Clinical and Information Governance prerequisites form and stage one of the SCAL, describing the product, its data flows, and its clinical safety considerations. Appoint a Clinical Safety Officer, start hazard workshops, and draft the DPIA, data inventory, retention schedule, and role-based access model. Plan your incident process, including how you will tell practices and the GP system supplier when something goes wrong.

Once NHS England confirms the product is viable through the available APIs, you will sign a Model Interface Licence with each provider supplier. That licence gives access to a test environment, and it is updated later to include the assured SCAL. Keep the safety and governance artefacts in the same repository as the technical documentation, so a change to a feature prompts a change to the hazard log rather than being discovered at assessment.

Step 4: Build one vertical slice first

Pick one supplier and one data domain, appointments or medications are good candidates, and implement the whole path. That means pairing, authorisation, create, read, update, logging, and audit. Develop against the supplier's Pairing and Integration Pack, using synthetic patient data and realistic fixtures. This is the unsupported testing stage, and it is the right place to prove data flows, error handling, and system behaviour before supplier support is involved.

Test the mapping, not just the happy path. Include null codes, legacy fields, unexpected status transitions, and records with long medication histories or several allergies. When one complete slice works, add the second supplier and the next domain. If the second supplier forces changes through your codebase, your abstraction is leaking, and it is far cheaper to find that now.

Step 5: Make identity and writes safe

Treat patient matching as a safety-critical process. Decide when a strong match is required before any write, an NHS number plus date of birth for example, and make "no match" and "multiple matches" outcomes your interface handles properly rather than errors it hides. Use ODS codes for organisations, and where your product spans several settings, keep one identity service that reconciles identifiers rather than string matching scattered through the code.

Make every write idempotent, so a retried call cannot create a duplicate record. Prefer append over overwrite for clinical data such as medications, with explicit status and versioning, validate code systems and require units. Review failed operations from a dead-letter queue rather than losing them. For documents, the hard part is the metadata. Agree the document category, author, source organisation, and patient visibility with practices, enforce size limits, scan files for malware before sending, and use checksums so you can show that what you sent is what was received. If the supplier accepts only certain categories, document any lossy mapping.

Step 6: Test the failures you will meet in production

Supplier test environments cannot reproduce live primary care data, so combine three layers. Unit tests cover payload mapping. Component tests exercise each connector against controlled fixtures. End-to-end tests run in the supplier's environment from pairing through to audit, wired into continuous integration so they run on every build.

Then rehearse failure. Simulate timeouts and throttling to confirm back-off behaves as designed. Test what happens when a practice revokes pairing or your credentials rotate. Confirm that alerts fire on a spike in failed writes, rising latency, or reads and writes drifting apart in a way that suggests a stuck job. Rehearse a rejected write as well as an accepted one, because the rejection path is the one nobody tests.

Step 7: Assurance, witness testing, and the Recommendation to Connect

With the SCAL fully completed and agreed with the provider, witness testing can begin. NHS England 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, and the product then joins the list of assured suppliers. Treat the evidence as something you have been producing all along. The safety case, DPIA, access model, and test results should already exist, and assurance should be the moment you show what your telemetry and documentation already say.

Step 8: Roll out gradually and operate

Go live with one supplier, a small group of practices, and a limited set of data domains. Use feature flags that isolate suppliers and capabilities, so a problem with document upload does not pause appointments. Give each pilot practice a named contact who can approve pairing, and agree rollback plans and success criteria in advance. Build dashboards for volumes, error rates, timeouts, and latency per supplier, with logs that carry identifiers to trace a patient or operation across services without exposing more than necessary.

Keep a kill switch per supplier and per capability. If a supplier has an incident, or error rates climb, pausing only the affected feature protects everything else and preserves the practices' trust. Practices care less whose fault an outage is and more whether they were told quickly.

Operating is where the work continues. Supplier APIs change, so review dependencies on a schedule and version your mapping specifications. Rotate credentials on a fixed cadence, run penetration tests focused on the integration surface, and check that audit logs stay complete. Revisit the clinical safety case and DPIA periodically, because live data often shows hazards and likelihoods the design stage missed.