Written by Technical Team | Last updated 15.06.2026 | 25 minute read
For a digital health innovator, a pilot with a Primary Care Network can feel like the decisive moment when a promising product finally meets real general practice. It is where assumptions about users, workflows, data, integration and value are tested against the operational pressures of primary care in England. A successful pilot can produce the evidence, relationships and implementation model needed for wider adoption. A poorly designed one can consume months of effort without establishing whether the solution works, whether practices will use it or whether anyone can justify paying for it.
The difference rarely comes down to the quality of the technology alone. Primary care pilots succeed when the innovator understands that a PCN is not a single customer, a GP practice is not a controlled testing environment, and integration with EMIS Web or TPP SystmOne is not merely a technical task. The pilot must be constructed as a small-scale service transformation programme involving clinical leadership, operational redesign, information governance, supplier dependencies, patient safety, workforce engagement and measurable outcomes.
This article explains how to design and run such a pilot: from choosing the right problem and PCN, through preparing EMIS and SystmOne integration, to achieving adoption, measuring value and converting the work into a scalable proposition.
The strongest PCN pilots begin with an operational or clinical problem that the network already recognises, not with a product seeking somewhere to be tested. This distinction matters because general practice teams have little spare capacity for exploratory innovation. A proposition that sounds interesting but does not relieve a material pressure will struggle to attract attention once implementation begins.
Start by identifying the problem in terms that matter to practices. “Improving digital engagement” is too broad. “Reducing the number of unsuccessful telephone attempts made by care coordinators during long-term condition recall” is more useful. “Using artificial intelligence to support triage” describes a category of technology. “Helping the duty team identify high-risk online requests earlier while reducing time spent manually re-entering patient information” describes a practical objective.
A PCN may be interested in a problem for several reasons. It may affect patient safety, staff workload, access, continuity, health inequalities, contractual delivery, income protection or the network’s ability to make effective use of its multidisciplinary workforce. A compelling pilot usually addresses more than one of these dimensions, but its primary purpose should remain clear. When a pilot attempts to solve access, prevention, demand management, population health, workforce productivity and patient satisfaction simultaneously, it becomes almost impossible to implement or evaluate properly.
Before agreeing a scope, examine how the problem appears in different member practices. PCNs are collaborative structures, but their constituent practices remain distinct organisations with their own partnerships, contracts, staff, processes and cultures. One practice may centralise incoming requests through an experienced navigation team; another may direct almost everything to a duty GP. One may use EMIS Web with carefully maintained templates and protocols; another may have accumulated years of inconsistent coding. A third may use SystmOne and rely heavily on local reports, shared units or established workflow rules. The visible problem may therefore be shared across the PCN while its causes differ considerably by practice.
Conduct structured discovery rather than relying on one enthusiastic clinical director or transformation lead. Interview a representative group that includes GPs, practice managers, reception or care navigation staff, nurses, pharmacists, care coordinators, digital and transformation leads, and the people responsible for reporting or information governance. Observe the existing workflow where possible. Ask staff to show how work enters the practice, how decisions are made, what gets recorded, what is duplicated, where delays occur and how exceptions are handled. What people say happens and what actually happens are often different.
Discovery should produce a clearly bounded problem statement, an agreed target population or workflow, and a baseline. It should also expose the cost of the status quo. That cost does not need to be expressed solely in pounds. It may include avoidable appointments, repeated administrative contacts, delayed interventions, clinician minutes, incomplete coding, poor patient reach, excessive hand-offs, unfilled capacity or unreliable reporting.
A practical pilot hypothesis might be: “Introducing the solution across three member practices will reduce the administrative time required to identify, contact and book eligible patients for a specified pathway, without increasing clinical risk or worsening access for digitally excluded patients.” This is testable. It identifies a setting, a workflow, an expected benefit and an important balancing condition.
At this stage, agree what the pilot is not intended to prove. A three-practice pilot cannot demonstrate that a product will perform identically across every configuration of EMIS and SystmOne in England. Nor can a short pilot prove long-term population outcomes. It can, however, test workflow fit, usability, technical reliability, implementation effort, staff adoption, short-term service indicators and the plausibility of a wider business case.
The central discipline is to resist designing the pilot around the product’s full feature set. The first deployment should focus on the smallest combination of capabilities capable of producing meaningful value. Every additional workflow, patient cohort, integration route or user group increases the number of dependencies and makes failure harder to diagnose. A narrow pilot that generates decisive evidence is more valuable than an ambitious pilot that produces inconclusive results.
Not every PCN that expresses interest is ready to run a successful pilot. Innovators often mistake enthusiasm for implementation capacity. A clinical director may understand the opportunity and genuinely want to proceed, yet still lack protected time, operational support or authority over the relevant practice workflows. The best pilot partner is not necessarily the most digitally advanced network. It is the one with a sufficiently important problem, credible leadership, usable data, engaged practices and the ability to make decisions.
Assess readiness at network and practice level. At PCN level, determine who owns the problem, who can approve expenditure, who leads transformation and how decisions involving member practices are made. At practice level, identify whether partners and managers support the pilot, whether frontline staff can participate in design and training, and whether each practice is willing to change the relevant workflow. A network-level agreement without practice-level commitment is a common source of stalled deployments.
The pilot needs a delivery coalition rather than a single sponsor. At a minimum, this normally includes a senior clinical sponsor, an operational lead, a practice representative from each participating site, an information governance contact and a named implementation lead from the innovator. Depending on the product, it may also require an integrated care board digital representative, medicines optimisation lead, data protection officer, clinical safety officer, IT support provider or interface supplier.
Each participant should have an explicit role. The clinical sponsor protects clinical intent, helps resolve professional concerns and gives the work legitimacy. The operational lead coordinates practice activity and ensures decisions translate into action. Practice champions identify local workflow differences and support colleagues. The innovator’s implementation lead owns the delivery plan and should be empowered to resolve problems rather than simply report them.
Agree governance before mobilisation. The pilot should have a concise written charter covering the problem, participating sites, intended users, patient population, intervention, duration, success measures, decision-making process and escalation route. It should state what the PCN will provide, what the supplier will provide and which dependencies sit outside either party’s direct control. The document does not need to become a bureaucratic programme manual, but it must remove ambiguity.
The commercial arrangement also needs clarity. “Free pilot” can sound attractive, but free activity is not costless to a practice. Staff time, configuration, training, data work and workflow disruption all carry an opportunity cost. In addition, an entirely free pilot can create weak commitment because neither party has defined what will happen if the product succeeds.
A good pilot agreement answers the following questions:
The post-pilot proposition should be discussed before the pilot begins. This is not about forcing an early procurement commitment. It is about ensuring there is a plausible route to continuation. Establish who would be the likely contracting body: the PCN, a lead practice, a federation, the ICB or another provider. Understand which budget could fund the service and whether that budget is recurrent. A pilot funded through a temporary transformation pot may produce excellent results but still fail to convert if the ongoing buyer has not been identified.
Choose participating practices deliberately. Starting with only the most enthusiastic practice may make implementation easier, but it can produce misleading evidence. Conversely, beginning with the most resistant or operationally troubled site can overwhelm the pilot before the product has been stabilised. A useful cohort often includes an engaged early adopter and one or two practices representing more typical conditions. Where the PCN contains both EMIS and SystmOne practices, consider whether the pilot genuinely needs to cover both systems from day one. Demonstrating both may strengthen scalability, but it effectively creates two technical and operational implementation tracks.
Finally, build trust by being precise about risk and uncertainty. Primary care leaders are accustomed to suppliers making expansive claims about saving time, releasing appointments or transforming access. Credibility increases when the innovator distinguishes between what is already proven, what is expected and what the pilot is intended to discover. A transparent account of limitations will usually strengthen sponsorship rather than weaken it.
Integration is frequently described as though it were a binary product feature: the solution either “integrates with EMIS” or “integrates with SystmOne”. In practice, integration has multiple layers. The product may need to authenticate users, identify patients, read structured data, launch within context, write coded entries, create tasks, attach documents, manage appointments, update contact details or return information for filing. Each function can involve different interfaces, permissions, assurance requirements, commercial arrangements and local configuration.
Define the minimum integration needed to achieve the pilot outcome. A product does not always need broad read-and-write access to the full record. For some workflows, contextual launch and reliable patient matching may be enough. For others, the ability to write structured coded data is central to the value proposition. In a recall product, for example, merely generating a list outside the clinical system may leave practice staff with substantial manual checking and coding. In a patient questionnaire workflow, uploading a PDF may technically place information in the record but provide less operational value than recording relevant structured responses and creating a clear review task.
Build an integration matrix before committing to deployment. For every required workflow, record the trigger, data inputs, user actions, system outputs, destination within the patient record, coding requirements, permissions, failure behaviour and audit requirements. Document the position for EMIS Web integration and SystmOne integration separately. Avoid assuming that equivalent-looking functions behave identically across the two systems.
For example, “create a task for a clinician” is not a complete integration requirement. Which user or team should receive it? What happens when a practice names teams differently? Is the task associated with the correct patient? Does it contain enough context to act safely? Can it be reassigned? Does the practice have an existing protocol for monitoring uncompleted tasks? How is urgency represented? What happens if the write fails after the patient has submitted information? These details determine whether integration supports the workflow or creates a new risk.
The integration route must be confirmed early. Depending on the use case, this may involve national interoperability services such as GP Connect, IM1 pairing arrangements, supplier-specific partner interfaces or other assured mechanisms. Do not build the pilot plan around assumed access while commercial, technical or assurance conversations are unresolved. Interface availability, onboarding requirements and lead times can become the critical path.
EMIS and SystmOne also sit within different local environments. Practices may have distinct role profiles, smartcard arrangements, organisational groups, templates, document categories, appointment books, task configurations and data-sharing settings. A function that works in a test environment may behave differently when applied to the practice’s real configuration. Integration testing must therefore include both technical conformance and end-to-end workflow testing at each pilot site.
Use representative test cases, including exceptions. A happy-path test might confirm that an eligible patient is identified, contacted, responds and has information written to the correct record. That is necessary but insufficient. The test plan should also consider duplicate records, changed practice registration, missing or invalid contact details, deceased patients, proxy access, safeguarding flags, incorrect identifiers, unexpected clinical responses, write failures, temporary system unavailability, user permission problems and patients who respond after the workflow has closed.
Identity matching deserves particular attention. NHS number is important but should not be treated as an infallible shortcut. The solution must use an appropriate matching approach and make uncertainty visible. A misfiled result is not a minor data-quality problem; it is a patient safety incident. Where human review is part of the process, the interface should make the identifiers needed for safe verification easy to see.
Structured data introduces further considerations. SNOMED CT coding should reflect the clinical meaning of the event, not simply what is convenient for reporting. Codes must be agreed with clinical users, and the innovator should understand whether an entry indicates that an assessment was offered, completed, reviewed or acted upon. These are not interchangeable. Avoid writing codes that could imply clinical judgement where the system has only collected information.
The product should preserve provenance. A clinician looking at the record later should be able to understand where information came from, when it was collected, whether it was patient-reported, whether it was generated by an algorithm and whether it has been reviewed. If an AI-supported function has summarised or classified information, the record should not obscure the distinction between source material and generated output.
Workflow integration matters as much as record integration. A product can write perfectly into EMIS or SystmOne yet still fail because staff must monitor a separate dashboard. Every new inbox, worklist or portal competes with established routines. The pilot should make explicit which system is the operational source of truth and how users know that work requires attention. Where a separate interface is unavoidable, reduce the number of occasions staff must switch into it and consider notifications, single sign-on or contextual launch.
Information governance and clinical safety must run in parallel with technical development. Determine the roles of controller and processor, the lawful basis for each data use, data flows, storage locations, sub-processors, retention periods, access controls and incident arrangements. Complete or support the relevant data protection impact assessment. Ensure that data used for direct care is distinguished from data used for evaluation, product improvement or analytics. Do not assume that approval for one purpose automatically permits another.
The clinical safety case should describe how the technology could contribute to harm and how those risks are controlled within the complete service. Hazard analysis must include human factors and implementation conditions, not only software defects. A technically correct alert that is routinely overlooked is still unsafe. A patient questionnaire that creates urgent responses outside staffed hours may introduce risk even if every response is transmitted accurately. The safety case should align with the actual pilot configuration, user roles and escalation pathway.
Complete a short technical and operational readiness review before go-live. At a minimum, confirm that:
Key takeaway: A successful Primary Care Network pilot depends on more than connecting a digital health product to EMIS Web or TPP SystmOne. Primary care EHR integration must support the complete clinical workflow, including accurate patient matching, structured data, safe task routing, clear escalation processes and minimal additional administration for GP practice teams. Test the technology and the end-to-end service at every participating practice before expanding the pilot.
Integration should ultimately make the new service feel like part of general practice rather than an additional digital layer placed on top of it. The relevant test is not “Did the API call succeed?” It is “Did the right person receive the right information, in the right place, at the right time, with enough context to act safely and with less work than before?”
A pilot begins before the software goes live. The mobilisation period should be used to turn a generic product into a defined local service. Map the future-state workflow with each participating practice, identifying who performs every step, how patients enter the pathway, where clinical responsibility sits and what happens when the process deviates from the expected route.
Avoid creating one standard operating procedure that assumes all practices work alike. There should be a common pilot model, but local variations need to be recorded. One practice may route responses to a central care coordination team, while another may require them to enter a named GP’s workflow. One may contact patients centrally at PCN level; another may insist on practice-branded messages. Standardise what is necessary for safety, data quality and evaluation while allowing controlled flexibility in operational delivery.
Training should be role-specific and workflow-based. A GP does not need the same session as a receptionist or care coordinator. Demonstrate realistic cases from start to finish and explain what users should do when something goes wrong. A feature tour is not training. Staff need to know when to use the system, what not to use it for, how to recognise an urgent or failed case, and where responsibility passes to another person.
Keep training concise, but reinforce it. General practice teams experience absence, turnover, competing priorities and variable attendance. Provide short recordings, one-page guides and in-product support. Identify a champion in each practice who can answer basic questions and spot emerging workarounds. Make onboarding available for staff who join after go-live rather than treating training as a one-off event.
Use a controlled launch. A pilot rarely benefits from opening immediately to every eligible patient or every staff member. Begin with a limited cohort, a defined session or a small number of users. Check the entire pathway in live conditions, review data quality and watch the work arrive in practice systems. Expand only when the process is stable.
During the opening phase, provide intensive but structured support. Establish a single route for reporting issues and classify them by severity. Separate software faults from configuration problems, user misunderstandings, process gaps and enhancement requests. Without this discipline, the supplier may build features to compensate for a local workflow problem, while practices may attribute every implementation difficulty to the technology.
Monitor adoption through behaviour, not attendance or log-ins alone. A user can attend training and sign in without incorporating the product into routine work. Examine whether eligible cases are entering the pathway, whether staff complete the expected actions, whether outputs are reviewed promptly and whether practices revert to previous methods. Variation between sites can reveal both implementation problems and valuable design lessons.
Speak to non-users as well as champions. The most enthusiastic staff members often provide useful feedback, but they may tolerate friction that prevents broader adoption. Ask reluctant users what they believe the product adds, what makes them hesitate, whether it duplicates existing work and what would need to change for them to use it consistently. Resistance may reflect poor communication, but it can also expose a genuine safety concern or a mismatch with practice priorities.
Pay attention to workload displacement. A tool may save GP time while adding work for reception staff, or reduce outbound calls while increasing the volume of digital responses needing review. It may improve coding but require more exception handling. The relevant outcome is the net effect across the pathway, including work shifted to the PCN, practice, patient or another provider.
Patient experience also needs active design. Messages should be clear about who is contacting the patient, why, what will happen with their information and when they should seek urgent help. The digital journey should be accessible, mobile-friendly and proportionate to the task. Avoid long forms that collect information simply because the technology can. Every question should have a defined purpose.
Digital exclusion should be handled as a service-design issue rather than a disclaimer. Determine how patients without smartphones, data, confidence, literacy, English proficiency or private access will receive an equivalent service. A digital pathway does not have to be used by everyone, but it should not inadvertently remove access from those who cannot use it. Monitor participation across relevant demographic and deprivation groups where lawful and feasible.
For patient-facing tools, consider the consequences of convenience. Making it easier to submit information can uncover previously unmet need, which may be clinically valuable but operationally demanding. A successful interface can therefore increase workload in the short term. Capacity planning should account for the likely volume, timing and complexity of responses rather than assuming digital collection automatically reduces demand.
The pilot team should meet regularly, but meetings should focus on decisions. Review adoption, incidents, unresolved issues, patient feedback, workflow performance and upcoming changes. Maintain a simple decision log. When the product or workflow is altered, record why, which sites are affected and whether the change influences evaluation. Constant unrecorded adjustment makes it difficult to know what was actually tested.
Create a clear pause mechanism. Each practice should know how to stop new activity without losing existing work, and the criteria for doing so should be agreed in advance. Reasons might include a clinical safety concern, persistent record-writing failures, excessive unreviewed workload or unexpected patient impact. A pause is not necessarily a failed pilot; it is evidence that governance is functioning.
The supplier’s implementation behaviour will influence commercial confidence as much as the product. PCN leaders notice whether issues are acknowledged quickly, whether commitments are documented, whether staff are treated respectfully and whether the innovator understands the pressure practices are under. A pilot is therefore also a test of whether the company can become a dependable NHS supplier.
Evaluation should be designed before go-live, not assembled at the end from whatever data happens to be available. Start with the pilot hypothesis and create a small set of measures covering implementation, activity, outcomes, experience, safety and economics. Too many metrics dilute attention; too few create an incomplete picture.
Implementation measures explain whether the intervention was delivered as intended. They might include the proportion of participating practices live by the planned date, staff trained, eligible patients entered into the pathway, technical success rates and completion of required workflow steps. These measures are essential because an apparent lack of outcome may result from poor implementation rather than an ineffective product.
Outcome measures should reflect the original problem. For an access solution, relevant indicators might include time to first review, proportion of requests resolved through a particular route, avoidable hand-offs or patient-reported ease of access. For a recall pathway, measures could include contact rates, completion rates, time from identification to intervention and staff time per completed patient. For medicines work, they might involve identification, review and resolution of relevant cases rather than only the number of alerts generated.
Include balancing measures. A reduction in telephone calls may be less impressive if it produces more complaints or missed vulnerable patients. Faster triage may be unsafe if urgent requests are misclassified. Increased uptake may create an unsustainable review backlog. Balancing measures protect the evaluation from presenting a local optimisation as a whole-service improvement.
Establish the baseline using the most comparable data available. Historical practice data can be useful, but account for seasonality, changes in staffing, campaigns and other concurrent initiatives. Where possible, compare participating practices or cohorts thoughtfully rather than assuming that raw before-and-after differences are caused by the product. The objective of most PCN pilots is not an academic randomised trial, but the evaluation still needs enough rigour to support a purchasing decision.
Quantitative data should be combined with qualitative evidence. Interviews, short surveys, observations and structured feedback can explain why performance differs between practices. A time-saving estimate becomes more credible when staff can describe which steps disappeared and which remained. Patient feedback can identify whether non-completion reflects usability, trust, accessibility or lack of perceived relevance.
Time measurement requires care. Asking staff whether a product saves time tends to produce unreliable estimates. Use observed samples, workflow timestamps or short time-and-motion exercises where practical. Include exception handling, reconciliation, training and system administration. Distinguish between gross time released in one role and net time released across the service.
The economic case should be realistic. Converting every minute saved into a cash saving can overstate value because released time does not automatically reduce expenditure. It may instead create capacity, reduce overtime, improve responsiveness or allow staff to complete neglected work. These are legitimate benefits, but they should be described accurately.
A useful business case separates different forms of value: cash-releasing savings, capacity released, income protected or enabled, avoided cost, quality improvement, risk reduction and patient benefit. It should state the assumptions used, the expected range rather than only a best-case figure, and the implementation resources required to reproduce the result elsewhere.
Review evidence throughout the pilot rather than waiting for the final week. An early dashboard can identify poor uptake, technical failures or inconsistent data collection. However, avoid changing targets retrospectively simply because initial results are disappointing. Changes to measures or scope should be justified and recorded.
Plan three formal decision points. The first follows mobilisation and confirms readiness to launch. The second occurs after an initial live period and determines whether to continue, pause, adjust or expand. The final review assesses whether the product should stop, continue in a limited form, roll out across the PCN or move into a broader procurement discussion.
The final evaluation should distinguish product performance from pilot performance. The technology may work, but implementation may be too demanding. Adoption may be high, but the measurable benefit may be insufficient. The clinical outcome may be promising, but integration costs may make the model unviable. Conversely, a difficult early implementation may still reveal a valuable proposition once the deployment model is improved.
Scaling across a PCN is not the same as repeating the first installation several times. The innovator should turn pilot learning into a standard deployment package containing technical prerequisites, workflow templates, governance materials, training resources, configuration checklists, support processes and a measurement framework. Identify which elements are fixed and which can be adapted locally.
For EMIS and SystmOne deployments, document system-specific implementation paths. Record the interface dependencies, permissions, mapping decisions, known limitations, testing scripts and common configuration issues for each platform. Do not bury this knowledge in the heads of one engineer and one implementation manager. Repeatability is a core part of product maturity.
Consider the support model at scale. A pilot may survive through daily attention from founders, engineers and senior clinicians. That model will not support dozens of practices. Determine which issues can be handled through self-service guidance, first-line support or automated diagnostics, and which need specialist intervention. Monitor the support burden per practice because it directly affects commercial viability.
The evidence package should be tailored to future decision-makers. A clinical director may focus on patient benefit and network priorities. A practice manager may want to understand workload, training and disruption. An ICB digital team will examine architecture, standards and information governance. A finance lead will challenge assumptions in the return-on-investment model. A compelling case combines these perspectives without pretending that one metric answers every question.
A successful pilot should conclude with a decision, not merely a presentation. Confirm whether the PCN is adopting the solution, extending the evaluation, changing the model or stopping. If adoption is agreed, define the contracting route, rollout sequence, price, service levels, governance arrangements and evaluation after scale-up. If the decision is to stop, conduct a structured review and preserve the lessons.
The most valuable outcome may be a sharper understanding of where the product does and does not fit. A pilot can reveal that the best buyer is a federation rather than a PCN, that value is concentrated in larger practices, that the workflow needs centralised delivery, or that full record integration is essential to adoption. Such findings are not failures. They prevent the company from scaling an inaccurate proposition.
Ultimately, a strong PCN pilot creates confidence on four fronts. Practices gain confidence that the solution can operate safely within everyday work. The PCN gains confidence that it supports a meaningful network priority. The innovator gains confidence that implementation and economics are repeatable. Future buyers gain confidence that the claimed benefits are based on evidence rather than aspiration.
That confidence is earned through disciplined problem selection, committed local leadership, careful EMIS and SystmOne integration, operationally realistic implementation and honest evaluation. The purpose of a pilot is not to prove that the product is perfect. It is to determine, with enough rigour to support action, whether the product can become a dependable part of primary care.
Is your team looking for help with bespoke software development? Click the button below.
Get in touch