Written by Technical Team | Last updated 15.08.2025 | 14 minute read
Before you start drafting forms and hunting for evidence, it helps to understand what IM1 and the SCAL are—both in spirit and in practice. IM1 is the umbrella term historically used to describe integrations with GP clinical systems via managed interfaces. It has evolved alongside newer interoperability programmes, but the underlying principle is the same: if your product reads from or writes to patient or practice data in primary care systems, you’ll need to satisfy a formal assurance process. The SCAL—short for the Standards/Conformance Compliance Assessment List—is the structured set of questions and evidence requests that prove your organisation and solution meet the requirements for safe, secure, interoperable deployment in the NHS. Treat it as both a checklist and a self-assessment: you assemble artefacts that show you’ve implemented the standards, and you explain how they apply to your specific product.
The onboarding process typically combines commercial arrangements, information governance checks, clinical safety assurance and technical conformance. Different products will take different routes depending on which APIs, suppliers and care settings are in scope, but there are common steps: registering your intention to integrate, scoping the interfaces and capabilities you plan to use, completing the SCAL with supporting documents, undergoing technical and security reviews, and demonstrating clinical safety management. You may also need to agree data-sharing and pairing arrangements with a principal system supplier if your integration touches their environment. It’s not just a technical gateway; it’s organisational due diligence around patient safety, privacy, and operational reliability.
It is worth thinking of IM1 onboarding as the point where your product’s internal quality system meets external regulation. Many teams underestimate that the questions in a SCAL are deliberately holistic: they probe your company’s security posture, software development lifecycle, incident response, data retention, access controls and consent handling, as well as the way your application behaves at the user level. If you’ve ever passed a robust enterprise procurement process, you’ll find the tone familiar—but the clinical safety and patient data dimensions make the evidence deeper and more exacting.
Another point that is often missed is that IM1 onboarding is not a one-off activity. Your first submission gets you through the gate, but you will be expected to maintain compliance, refresh evidence periodically, and engage when standards or APIs change. That means building a sustainable internal cadence—say, quarterly security reviews and annual policy updates—so that when you are asked for fresh artefacts you are not rebuilding everything from scratch. Teams that integrate ongoing assurance into their roadmap find subsequent changes, such as onboarding new GP practices or enabling additional capabilities, much faster.
Finally, don’t assume that “SCAL completion” equals “go-live tomorrow”. Your evidence can be immaculate, but you still need real-world arrangements in place: data-sharing agreements with practices, local configurations, user identity provisioning, training materials, and go-live support. The more you plan these dependencies in parallel, the sooner you will convert approval into production usage. Think of your SCAL as the narrative of how your product is safe and compliant, and your deployment plan as the evidence that you can run it safely, day in and day out.
If you take one thing from this guide, let it be this: clinical safety and information governance are not paperwork you bolt on at the end. They must shape your product from the first interface design. For clinical safety, you’ll need a documented Clinical Safety Management System guided by recognised health IT safety standards. In practice, that means appointing a competent clinical safety officer (CSO), establishing a hazard log, performing risk assessments and assigning mitigations, then maintaining an incident process with feedback loops into product changes. The SCAL will ask for evidence of each of these artefacts, plus proof that they are alive—meeting minutes, hazard reviews, closed actions—not merely templates.
Information governance (IG) focuses on how you lawfully and ethically process personal data. You should anticipate questions on your legal basis under UK data protection law, your approach to consent or legitimate interests, the data controller–processor relationship, and how you uphold the Caldicott principles. Most organisations will need a current submission of the national data security toolkit to demonstrate baseline compliance. Do not gloss over the details of purpose limitation or data minimisation; the SCAL is designed to smoke out designs that “collect everything just in case”. You’ll be stronger if your data flows show only the minimum attributes required to deliver the clinical purpose, with clear retention periods and deletion routines.
Your privacy and security by design story needs to be visible in your technical choices. For example, if your application surfaces sensitive information to non-clinical users, what safeguards prevent unauthorised access? If you expose clinical features to clinicians, how do you ensure identity assurance is commensurate with the risk? Your documentation should connect the dots: clinical risks in the hazard log are mitigated by specific features (like role-based access control or on-screen warnings), those features are covered by test cases, and post-market monitoring checks they are effective. Reviewers want to see this traceability.
Finally, the legal framing matters. Clarify in your contracts and data-sharing agreements whether you act as data controller, joint controller or processor for each flow. Provide a Data Protection Impact Assessment (DPIA) that covers the integration rather than just your generic product. If you intend to use the data for secondary purposes—analytics, research, service improvement—describe the governance and anonymisation or pseudonymisation approach explicitly. A crisp, honest DPIA and a clear controller–processor model save weeks of back-and-forth later.
A strong technical submission starts with an architecture narrative that is easy to follow. Provide a layered diagram showing the user, application, integration and data tiers, and annotate where the IM1 interfaces sit. Explain how your application authenticates users, how it authorises access to features and records, and how it manages sessions and tokens. If you depend on an external identity provider or smartcard-based workflow, show the happy path and the failure modes (e.g., what happens if token refresh fails). Map all inbound and outbound data flows with protocols and encryption in transit. The goal is to let a reviewer pick any box on the diagram and understand what it does and how it is secured.
Security controls should be described as part of your software development lifecycle, not just as a pen-test at the end. Demonstrate secure coding practices (such as static and dependency scanning on every merge), threat modelling for the integration features, and segregation of environments with strict secret management. Your submission will be stronger if you can articulate how you manage vulnerabilities end to end: intake (from scanners, bug bounty, or supplier advisories), triage by severity, remediation targets, and verification. Don’t forget operational security: who has production access, how you approve and log emergency changes, and how you rotate keys and certificates.
Testing is another area where teams either shine or stumble. You will be asked for evidence that your solution behaves correctly against the integration contract, that negative paths are safe, and that your service is resilient under load. Provide both automated test summaries and manual test scripts for user-facing workflows, especially where data is written back to a clinical system. If your product caches data, explain cache invalidation and how you prevent stale data from misleading users. For performance, present metrics that match real-world usage: how fast does a patient search return? How does response time scale with concurrent sessions? What happens during a supplier outage?
Technical readiness is also about deployment maturity. Describe your release strategy (blue-green, canary, or phased rollout), backup and restore procedures, and your disaster recovery plan with tested recovery time objectives. If your product relies on third-party services (for example, a messaging broker or an external analytics pipeline), show the contractual and technical measures you have in place to ensure continuity and data protection. For monitoring, be explicit: list your service-level objectives, the alerts you have configured, and the human response processes behind them. Reviewers want to be confident that when something goes wrong at 02:00 on a Sunday, you will notice and act.
To help you structure the dossier that supports your SCAL responses, assemble a consistent evidence pack. The following items are commonly requested or helpful to include:
From the outside, onboarding can look like a single gate. On the inside, it is a multi-track project with dependencies on clinical safety, IG, security, product, commercial and customer success. The best way to keep momentum is to run it like a delivery workstream in its own right. Nominate a lead who can speak fluent product and fluent compliance, form a small taskforce around them, and put the SCAL questions into a shared tracker with owners, artefacts and due dates. Create a living index of your evidence pack with version control; reviewers appreciate being able to find artefacts quickly, and you will spare your team the pain of chasing “final final” PDFs in email threads. Agree internal service levels for how quickly each discipline will review and return edits; otherwise, you will stall on small changes to policy wording or diagrams.
Engagement with external stakeholders is equally important. If you are pairing with a principal system supplier, book early technical sessions to align on interfaces, data items, throughput expectations and error handling. Where you need data-sharing agreements with practices, draft a pragmatic agreement and an onboarding playbook you can hand to practice managers. For go-live, plan communications, training materials and support channels; practices will want to know who picks up the phone if something doesn’t work on day one. The onboarding team should stay in place for the first few production deployments to absorb lessons quickly, close the loop with reviewers, and feed improvements back into your submission. Nothing makes a stronger case than a safe, well-supported first rollout.
Teams new to NHS assurance often underestimate how specific the SCAL answers need to be. Generic statements such as “we encrypt all data” or “we comply with GDPR” will not satisfy a reviewer. What they need is evidence you understand the risks in your particular product and have implemented proportionate, testable controls. The most persuasive submissions weave together a clear narrative: here is the clinical purpose; here are the exact data items we need and why; here is the user journey; here are the hazards and mitigations; here is how our code and operations make those mitigations real; and here is the proof it works under normal and exceptional conditions. When reviewers can follow that thread from purpose to proof, approvals accelerate.
Another avoidable pitfall is treating third-party dependencies as a black box. If your solution relies on an external vendor for authentication, messaging or analytics, reviewers will ask how you assure that vendor’s compliance, security and resilience. Be ready with contractual safeguards, technical controls and exit plans. Similarly, if you are integrating with multiple GP system suppliers, avoid writing your submission around a single supplier’s quirks; make clear how your design generalises and where it has supplier-specific branches. Doing this up front will save rework when you expand to additional interfaces later.
Clarity in user identity and access control is a recurring weak spot. In health IT, not all users are equal: a GP partner, a receptionist, and a patient may interact with the same product but see different data and features. Your role model should be explicit and tested. Explain how roles are provisioned, how they are verified, and how you prevent privilege creep over time. If you support bring-your-own-device or remote access, show how you enforce device security baselines and handle lost devices. Don’t forget audit: define what you log, how long you retain it, how you protect logs from tampering, and how you surface meaningful audit reports to practices.
Finally, remember that reviewers and integrators are allies trying to protect patients, staff and systems. The fastest route through assurance is openness. If you have a known limitation—perhaps a feature still in development or a residual risk you have accepted—state it plainly and describe your mitigation plan. Papering over rough edges invites deeper scrutiny and delay. Conversely, teams that present a candid, well-structured submission, answer questions quickly, and demonstrate that they fix issues in days not months, tend to move through with fewer cycles.
To make these ideas tangible, here is a focused set of tips that consistently help teams succeed:
Preparing for the NHS IM1 SCAL and onboarding is best viewed as a disciplined, multi-disciplinary project rather than a compliance hurdle. Success hinges on three habits. First, treat clinical safety and information governance as design inputs that influence your architecture, user experience and operating model from the outset. Second, write a technical story that is both precise and human: reviewers should be able to picture your system in use and see how your controls protect patients and data. Third, run the onboarding process with the same craft you apply to product delivery: a clear owner, a visible plan, regular communication, and a focus on unblocking quickly.
If you already have an enterprise-grade security posture, leverage it—bring your vulnerability management, incident response, and change control evidence into focus around the integration. If you are maturing those practices, the SCAL is a powerful forcing function; doing the work properly will improve your product and operations beyond this single integration. In either case, approach reviewers as partners in safety. Clarity, completeness and candour travel a long way.
When you press “submit”, what should you expect? If you’ve followed the guidance above, your reviewers should receive a coherent set of documents that tell a single story: a legitimate clinical purpose; a minimal, well-governed data footprint; an architecture that is robust under load and failure; safety controls that are designed, implemented, tested and monitored; and operational readiness for real practices and patients. That is the blueprint for a smooth onboarding and, more importantly, for a solution worthy of trust in primary care.
As your integration goes live and grows, keep the loop tight. Monitor incidents and near misses, treat them as learning opportunities, and feed improvements back into your safety case and technical hardening. Refresh your evidence on a sensible cadence so the next change request or capability expansion doesn’t spark a frantic scramble. Over time, you’ll find that assurance becomes part of how your organisation thinks and builds, not a last-minute obstacle. That shift—from compliance as an event to safety as a habit—is what makes IM1 onboarding not just achievable, but transformative for your product and your users.
Is your team looking for help with IM1 integration? Click the button below.
Get in touch