Written by Technical Team | Last updated 09.01.2026 | 10 minute read
Integration with established Electronic Health Record (EHR) systems is increasingly important for digital health innovators and public health organisations. As digital health services mature, expectations around interoperability, data quality, and real-time information sharing continue to rise. Increasingly, GP records contain the fullest and most up-to-date single view of a patient, encapsulating consultations, observations, diagnoses, medications, test results, referrals, discharge events, appointments, and longitudinal clinical history across care settings.
For many digital health solutions, access to this comprehensive dataset is fundamental. Whether the goal is to support remote monitoring, population health management, clinical decision support, or preventative care, seamless EHR integration enables products to move beyond siloed data and into real-world clinical workflows.
A significant EHR system in England is SystmOne, from TPP. SystmOne is used in almost half of all GP Practices in England and is also widely adopted across community services, mental health, urgent care, and other healthcare settings. This breadth of adoption means SystmOne often acts as a shared care record, holding a comprehensive clinical record for each associated patient and enabling information to flow between multiple organisations involved in a patient’s care.
At 6B, we specialise in assisting digital health innovators and public health organisations to navigate the complexities of integrating with SystmOne. Our focus is not just on technical connectivity, but on ensuring organisations can leverage this robust data source effectively, safely, and in a way that aligns with NHS standards, governance requirements, and clinical realities.
In this post, we take a brief look at the various SystmOne integration paths, some of the common SystmOne integration requirements we come across, and additional considerations that teams should be aware of when planning and delivering an integration.
Key takeaway: Successful SystmOne integration isn’t just about connecting to IM1 APIs — it’s about meeting NHS expectations for interoperability, information governance and clinical safety. Building in patient matching safeguards, data minimisation, and a plan for IM1 assurance early will reduce delays, prevent rework, and help your digital health product fit into real GP workflows.
There is more than one way to integrate with SystmOne, and the “best” approach depends on what you are trying to achieve. Some routes are optimised for real-time, patient-level workflows, while others are designed for cross-organisation interoperability or scheduled bulk analytics.
The table below summarises the most common integration pathways teams consider, what each is best suited for, and the practical constraints that often shape architecture, assurance effort, and delivery timelines.
| Integration route | Best suited for | How data moves | Key constraints to plan for |
|---|---|---|---|
| IM1 Client Integration API (TPP SystmOne) | Deep integration into SystmOne-held GP records for specific organisations, including patient search, targeted record retrieval, and writing structured entries back into the clinical record. | Transactional, patient-level access. Typically used for read and write workflows that must align with real GP operations and auditability. | Pairing and assurance are required, and implementations must be designed around supplier constraints such as request throttling and performance safeguards. This often drives caching, queueing, and careful UX around “freshness” of data. |
| GP Connect | Interoperability across care settings where users need to view or update a GP record, or manage appointments, in a standardised way that works across multiple GP system suppliers. | Standards-based access to GP data and functions via nationally defined capabilities, commonly including HTML viewing, structured record access, updates, and appointment-related interactions where enabled. | Capability availability can depend on local enablement and configuration, and consuming systems must align closely to the national capability definitions. This route is usually preferred when you need a more supplier-agnostic approach than a single-vendor API. |
| IM1 Bulk (Strategic Reporting Extracts / Data Extracts) | Population health analytics, service evaluation, reporting, research support, and other secondary uses that need large-scale structured datasets rather than real-time clinical workflows. | Scheduled extracts, typically up to daily. Data is provided as structured files (commonly CSV tables) intended for ETL into a data platform, warehouse, or analytics environment. | Not real-time and usually not appropriate for point-of-care decisioning. Operational setup is required to run and manage extracts securely, and teams must implement robust handling for volume, retention, access control, and downstream data governance. |
Patient data in SystmOne can be accessed through the IM1 Client Integration API. This API provides a controlled, standards-based way for approved third-party applications to interact with patient records held within SystmOne.
The PatientSearch function enables external applications to locate patients within an organisation’s patient list. This function is highly flexible, allowing searches using various parameters such as date of birth, postcode, first name, surname, telephone number, and gender. To protect patient confidentiality and minimise the risk of incorrect matches, a minimum of two search criteria must be provided to initiate a search.
From a practical perspective, designing an effective patient search flow is critical. Applications must balance usability with safety, ensuring that users can find the correct patient quickly without exposing unnecessary personal data. In many implementations, PatientSearch is combined with local application logic that further validates results before allowing access to the full patient record.
After locating a patient utilising PatientSearch, the GetPatientRecord function allows the retrieval of detailed patient records. This function can extract the entire record or a filtered subset based on specified criteria such as clinical type, date range, or event category. This flexibility allows applications to retrieve only the data they genuinely need, reducing data volumes and supporting data minimisation principles.
It is important to note that GetPatientRecord is throttled to once every 30 seconds per patient, except for demographics-only requests or recent updates. This limitation has architectural implications: integrations often need to cache data locally, design asynchronous workflows, or carefully plan when and how often full record retrievals occur to avoid performance issues.
Posting patient data back to SystmOne is facilitated through the UpdatePatientRecord function of the IM1 Client Integration API. This function supports adding new content to patient records, encompassing both clinical and non-clinical information.
Typical use cases include recording observations captured in a digital health application, adding structured questionnaires, updating care plans, or creating administrative entries such as tasks and appointments. Crucially, UpdatePatientRecord does not overwrite existing data; instead, it appends new entries, preserving the integrity and auditability of the clinical record.
The UpdatePatientRecord function allows for comprehensive updates to patient records, but it also comes with responsibilities. All submitted data must be clinically coded correctly, attributed to the appropriate clinician or organisation, and comply with SystmOne’s data models. Poorly structured or incorrectly coded data can reduce clinical usefulness and, in some cases, be rejected during assurance.
From a governance perspective, organisations must also ensure they have appropriate patient consent models in place and that data flows are clearly documented in Data Protection Impact Assessments (DPIAs) and information sharing agreements.
Bulk data extraction from SystmOne is a crucial feature for organisations that require comprehensive data analysis and reporting at scale. Common use cases include population health analytics, service evaluation, quality improvement programmes, and statutory reporting.
This capability is delivered through the IM1 Bulk SystmOne Strategic Reporting Extracts, often referred to as the Data Extracts API. Data can be extracted nightly, providing a daily incremental extract of patient data in CSV format. These extracts typically include a wide range of tables covering demographics, encounters, clinical events, prescribing, and other structured data.
To enable and receive data extracts, organisations must first configure their SystmOne environment. This typically involves close collaboration between technical teams, information governance leads, and clinical stakeholders, and includes:
Once configured, SystmOne Strategic Reports automatically export CSV files to a specified location each night. The download process is managed by a ‘Gateway PC’ or a cloud server running SystmOne, ensuring data security and redundancy via a secure TCP channel. The extracted files can then be processed, transformed, and transferred to another location for further analysis, often into a data warehouse or analytics platform.
Because these extracts contain large volumes of sensitive patient data, robust security controls, access monitoring, and retention policies are essential parts of any bulk data extraction solution.
A common path to integrate with SystmOne is via IM1 integration, and integrating with IM1 involves several formal stages to implementation that can take several months from start to finish. Planning for this timeline early is critical, particularly for organisations with fixed delivery milestones or funding constraints.
Below are the key stages to IM1 integration conformance:
Find out more about the IM1 integration process on the NHS England website here: https://digital.nhs.uk/services/gp-it-futures-systems/im1-pairing-integration.
Beyond the technical APIs, successful SystmOne integration depends on several broader factors. These include clinical engagement, usability within existing workflows, performance under real-world conditions, and ongoing support and maintenance.
Clinical safety is a particularly important consideration. Integrations must be supported by a Clinical Safety Officer (CSO) and appropriate hazard logs, ensuring that risks associated with data latency, partial records, or incorrect data interpretation are identified and mitigated.
Scalability and resilience are also key. As user numbers grow, integrations must handle increased load without breaching API limits or impacting user experience. This often requires thoughtful system architecture, queuing mechanisms, and monitoring.
How long does SystmOne integration typically take from start to go-live?
Timelines vary depending on scope and readiness, but most organisations should plan for several months end to end. Factors that influence duration include assurance evidence quality, clinical safety documentation maturity, and how early information governance and pairing requirements are addressed.
Can startups and SMEs integrate with SystmOne, or is it only for large suppliers?
Smaller digital health companies can and do integrate with SystmOne, provided they meet NHS assurance, security, and clinical safety standards. Early architectural planning and realistic resourcing are especially important for SMEs to avoid delays during assurance.
What are the most common reasons SystmOne integrations fail assurance?
Frequent issues include unclear clinical ownership, weak patient matching logic, insufficient data minimisation, and gaps in information governance documentation such as DPIAs. Technical implementation alone is rarely the cause of failure.
Is SystmOne integration suitable for patient-facing apps?
Yes, but only when carefully designed. Patient-facing solutions must handle consent models, data latency, and user expectations around record completeness. Many successful implementations use SystmOne data to support clinicians rather than exposing raw GP records directly to patients.
How does SystmOne integration support NHS digital transformation goals?
When implemented correctly, SystmOne integration supports interoperability, reduces duplication, and enables safer data sharing across care settings. This aligns with NHS priorities around joined-up care, prevention, and using data more effectively to improve outcomes.
At 6B, we have extensive experience developing integrations with SystmOne via IM1, via GP Connect, as well as other integration routes across the NHS ecosystem. We provide comprehensive, end-to-end support for digital health innovators looking to integrate with SystmOne, from initial feasibility assessment and architecture design through to assurance, live deployment, and post-go-live optimisation.
Our team understands not just the technical APIs, but the governance, clinical safety, and operational realities that underpin successful NHS integrations. This enables us to help organisations avoid common pitfalls, reduce time to market, and deliver solutions that genuinely add value to clinicians and patients.
This post has provided a high-level overview of SystmOne integration. If your team is considering SystmOne integration, please contact 6B for assistance and leverage our expertise to implement your SystmOne integration quickly, securely, and compliantly.
Is your team looking for help with SystmOne integration? Click the button below.
Get in touch