Written by Technical Team | Last updated 09.01.2026 | 10 minute read
Developed by TPP and used in around 50% of GP practices in England, SystmOne is a critical system underpinning healthcare delivery across primary, community, and secondary care. It provides clinicians and care teams with secure, role-based access to patient information, ensuring that the right data is available at the right time to support safe and effective decision-making. For developers and digital health companies, understanding the difference between the Demo and Live environments in SystmOne integration is not just a technical necessity—it is fundamental to building safe, reliable, and compliant healthcare software.
Both environments play an essential role in the journey from concept to live deployment, but they serve very different purposes. Knowing how and when to use each environment effectively can significantly influence the success, safety, and adoption of an integrated digital health solution.
The Demo environment is designed as a safe and controlled testing ground for digital health innovators. It closely mirrors the structure, behaviour, and technical constraints of the Live SystmOne system, but crucially, it uses entirely fictitious patient data. This approach allows developers to experiment, test XML messaging requests, and refine their SystmOne integration without any risk of accessing, exposing, or compromising real patient information.
One of the most valuable characteristics of the Demo environment is its stability. It provides a consistent and predictable test bed where third-party developers can validate that their applications connect successfully, authenticate correctly, exchange data as expected, and handle SystmOne responses in a robust and fault-tolerant way. Because the Demo environment is maintained and updated in parallel with the Live system, developers can be confident that the behaviours they observe during testing will closely reflect what happens in production.
Beyond technical reassurance, the Demo environment supports responsible innovation. It enables development teams to explore new clinical workflows, assess usability impacts, and iterate rapidly without introducing risk into real clinical settings. For early-stage digital health companies, this environment is often where ideas are proven or refined before further investment is made.
In practice, working with the Demo environment involves installing a SystmOne client configured specifically to connect to the Demo servers rather than the Live infrastructure. Innovators are typically issued login credentials for a fictitious organisation, ensuring that access remains tightly controlled and aligned with expected usage patterns. This setup closely reflects the way real GP practices and care organisations interact with SystmOne in Live.
Using the SystmOne Client Integration API, developers send XML requests over a TCP socket to interact with the system. This low-level, message-based integration model requires careful attention to XML schema definitions, message sequencing, and error handling. The Demo environment allows teams to gain hands-on experience with these requirements early in the development lifecycle.
Core functions such as searching for patient records, retrieving demographics, validating identifiers, and testing data input workflows can all be exercised safely in Demo. Although the underlying data is fictional, it adheres to the same structure, constraints, and validation rules as live patient information. This allows developers to test not only whether a request works, but also whether their application correctly interprets and processes responses. Thorough testing at this stage is critical to ensuring that, once an application transitions to the Live environment, it behaves predictably and securely.
While the Demo environment provides the foundation for development and testing, the ultimate goal for innovators is deployment into the Live SystmOne environment. The Live environment is the production system relied upon daily by healthcare professionals across the UK. It contains real patient data and supports time-critical clinical workflows, making reliability and safety paramount.
Moving from Demo to Live is not simply a configuration change. It represents a significant regulatory, governance, and compliance milestone. Applications must demonstrate that they handle XML messaging correctly, respect function-level throttling rules, and meet stringent security and information governance standards. This often involves formal assurance processes, detailed technical documentation, and evidence of robust testing.
For many innovators, this transition also includes engagement with NHS stakeholders, such as integrated care boards, commissioning bodies, or clinical safety officers. These groups need confidence that the integration supports clinical workflows safely, does not introduce undue risk, and aligns with national digital health standards. As a result, time invested in high-quality Demo testing often pays dividends by smoothing the path to Live approval.
Key takeaway for SystmOne integrations: Always build and fully validate your integration in the SystmOne Demo environment before progressing to Live. Thorough Demo testing helps ensure XML messaging works as expected, reduces the risk of throttling issues, and supports compliance with NHS and GDPR requirements when accessing real patient data in the Live SystmOne environment.
Both SystmOne environments are aligned in functionality, but the day-to-day realities of building, testing, and getting approved differ in ways that can affect timelines, clinical safety, and performance.
The table below summarises the most important differences between the SystmOne Demo environment and the Live environment, so you can plan your SystmOne integration, XML messaging approach, and go-live readiness more effectively.
| Integration area | Demo environment | Live environment |
|---|---|---|
| Primary purpose | Stable test bed for development and validation against SystmOne behaviour. | Production system used by healthcare professionals to support real care delivery. |
| Data used | Fictitious patient data, structured like real records for realistic testing. | Real patient data, requiring strict information governance and confidentiality controls. |
| Access setup | TPP-provided SystmOne client configured for Demo plus credentials for a fictitious organisation. | Access is tightly controlled within live healthcare organisations and operational workflows. |
| Version alignment | Updated in parallel with Live, supporting confidence that code tested in Demo will behave similarly. | Updated in parallel with Demo, but operational impact means changes must be handled carefully. |
| Throttling expectations | Used to confirm your application respects function limits and handles delays gracefully. | Throttling directly affects clinical workflow performance; inefficient calls risk disruption. |
| Testing approach | TPP requires use of a test harness during interface testing to validate correct behaviour. | Testing must reflect real-world load and safety constraints before wider rollout. |
| Audit trail and troubleshooting | Messages are audited and can be reviewed in SystmOne via the Client Integration Message Audit screen. | Auditing is still essential, but issues carry higher risk and require tighter operational controls. |
| Governance pathway (typical) | Focus on technical validation, XML schema compliance, and safe workflow design. | May require formal assurance steps such as conformance processes and clinical safety obligations. |
One of the most important technical considerations when integrating with the Live environment is managing throttling and performance. SystmOne enforces strict limits on how frequently certain XML functions can be called in order to protect overall system stability and ensure fair usage across thousands of organisations.
For example, the GetPatientRecord function is typically limited to one request every thirty seconds, unless usage is restricted to demographics or a limited subset of recent data. Other functions may be limited to one request per second. In the Demo environment, developers can explore how their applications behave under these constraints and design accordingly.
In Live, performance optimisation becomes critical. An inefficient integration that repeatedly calls the same functions unnecessarily can slow down clinical workflows, frustrate users, or even risk breaching throttling limits. To avoid this, digital health innovators should design applications with intelligent caching strategies, selective data retrieval, and efficient XML parsing. By requesting only the data that is genuinely needed and reusing previously retrieved information where appropriate, applications can remain compliant while still delivering timely value to clinicians.
Security is a core concern in both the Demo and Live environments, but the consequences of failure are far greater in Live. In Demo, the use of fictitious data provides a safe space to test integrations, validate authentication flows, and refine data handling without the risk of harming real patients. However, the same technical standards apply, meaning poor security practices identified in Demo are likely to cause serious issues later.
In the Live environment, every XML request and response may relate directly to patient care. Any mishandling of data—whether through insecure transmission, improper access controls, or inadequate logging—can have significant legal, ethical, and clinical consequences. The SystmOne Client Integration API enforces structured XML schemas, strict validation, and role-based access to help mitigate these risks.
Innovators must ensure their applications comply with NHS information governance requirements and GDPR obligations. This includes encrypting data in transit, securing credentials, implementing audit trails, and ensuring that patient information is only accessed when there is a legitimate clinical or operational need. Addressing these considerations early in Demo testing helps avoid costly redesigns later.
For digital health innovators, the Demo environment is far more than a simple sandbox. It is a vital stage in the lifecycle of a SystmOne integration, providing the opportunity to uncover issues, refine workflows, and build confidence before any interaction with real patient data occurs.
By testing rigorously in Demo, development teams can identify edge cases, handle error conditions gracefully, and validate that their XML messaging logic behaves as expected under realistic conditions. This thorough preparation reduces the risk of defects emerging in Live, accelerates approval processes, and builds trust with healthcare providers who rely on the system daily.
Because the Demo and Live environments are closely aligned in terms of functionality and constraints, lessons learned during Demo testing translate directly into production readiness. This alignment allows innovators to plan development cycles more effectively and reduces the likelihood of unexpected issues during deployment.
For many digital health innovators, the distinction between Demo and Live environments may initially appear to be a procedural detail. In reality, it is one of the most important aspects of successful SystmOne integration. The Demo environment provides the secure foundation for experimentation, learning, and refinement, enabling teams to innovate responsibly. The Live environment is where those innovations demonstrate their value in real-world healthcare settings, supporting clinicians and improving patient care.
By understanding how both environments operate—and the critical role XML messaging plays in each—developers can design integrations that are not only technically robust but also clinically meaningful. Thorough testing in Demo, careful optimisation for Live, and a deep understanding of the SystmOne Client Integration API empower digital health companies to create solutions that enhance interoperability, improve efficiency, and support the NHS on its ongoing digital transformation journey.
How long does it typically take to move from the SystmOne Demo environment to Live?
There is no fixed timeline. Progression from Demo to Live depends on the maturity of the integration, successful technical testing, documentation quality, and completion of required assurance steps such as clinical safety and information governance. For well-prepared teams, this can take weeks; for more complex integrations, several months is common.
Do developers need NHS approval before accessing the SystmOne Demo environment?
Access to the Demo environment is usually coordinated through TPP as part of the SystmOne Client Integration process. While full NHS approval is not required at this stage, developers are expected to have a legitimate use case and follow TPP’s integration standards from the outset.
Can the SystmOne Demo environment be used for user acceptance testing (UAT)?
Yes. Many digital health companies use the Demo environment for structured UAT with clinicians and stakeholders. Because workflows and data structures closely match Live, Demo is suitable for validating usability, clinical fit, and integration behaviour before real patient data is involved.
Is the SystmOne Demo environment suitable for load or volume testing?
The Demo environment is not designed for high-volume or stress testing. While it is ideal for functional and workflow testing, performance testing at scale should be approached cautiously and discussed with TPP, as excessive load can affect shared Demo infrastructure.
What ongoing responsibilities exist once an integration is live in SystmOne?
After go-live, developers are responsible for maintaining compatibility with SystmOne updates, monitoring XML messaging performance, handling incidents safely, and ensuring continued compliance with NHS clinical safety and data protection requirements. Live deployment is not a one-off milestone but an ongoing operational commitment.
Is your team looking for help with SystmOne integration? Click the button below.
Get in touch