Written by Technical Team | Last updated 18.09.2026 | 17 minute read
For a digital health supplier approaching the latter stages of an IM1 integration, the witness test is the point at which the integration stops being assessed primarily as a collection of APIs, documents and test evidence and starts being demonstrated as a functioning product.
The exact test approach can vary according to the principal clinical system supplier, the IM1 interfaces being used and the use case that has been agreed through the IM1 assurance process. An EMIS integration will not necessarily be demonstrated in exactly the same way as a SystmOne integration, and the scenarios required for a transactional integration will differ from those for an extraction-based integration.
The practical approach, however, is consistent. The supplier needs to demonstrate the release-ready product operating against the relevant clinical system, show how the approved interfaces are invoked, prove that patient context is handled correctly, exercise both successful and unsuccessful journeys, and demonstrate the controls around clinical data, user permissions and auditability.
A well-prepared IM1 witness test should therefore look less like a presentation and more like a controlled technical walkthrough of the real product.
At 6B, we recommend preparing for the witness test by treating every significant IM1 interaction as a testable user journey. For each journey, the team should know the starting state, the user performing the action, the API operation expected to occur, the result expected in the product, the effect expected in EMIS Web or the other principal clinical system, and the evidence available to demonstrate what happened.
Here is how an IM1 witness test typically unfolds in practice.
The session should begin with the exact version of the product that is intended to progress through assurance.
This matters operationally. Witness testing should not require engineers to switch between development branches, demonstrate functionality from mock-ups or explain that a particular control will be added before release. The application being demonstrated should behave like the product that will be deployed once the integration progresses into live use.
Before sharing the main workflows, the team should establish what is being demonstrated. This usually means identifying the product, the relevant environment, the clinical system being integrated with and the IM1 capabilities included within the agreed scope.
For an EMIS IM1 integration, for example, the team may have developed against one or more of the interfaces available within the agreed integration model. The witness session should be organised around the specific functionality included within that product’s approved use case rather than around every capability technically exposed by EMIS.
The same principle applies to SystmOne and other supported clinical systems. The witness test should follow the actual integration scope.
A useful approach is to have a simple test matrix available throughout the session. Each row represents a workflow that needs to be demonstrated and connects that workflow to the relevant integration operation and expected result.
The team should also have the appropriate test users and test patients prepared before the session begins. If role-based access is part of the product, more than one user may be required so that different permission levels can be demonstrated. If patient matching, patient context or clinical write-back is being tested, the corresponding records within the clinical system should already contain the information needed to make the test meaningful.
The witness environment should be treated as controlled infrastructure. The team should know which application instance is being used, which version has been deployed, which configuration is active and which clinical-system environment the product is communicating with.
Before moving into individual API scenarios, it is useful to have the following ready:
Once that baseline is established, the session can move from describing the integration to demonstrating it.
The core of an IM1 witness test is an end-to-end demonstration of the product using the interfaces that are intended for live operation.
The most effective way to do this is through real user journeys.
Rather than opening a developer console and manually invoking an API, the demonstrator should normally start from the action a genuine product user would perform. That might be selecting a patient, opening a clinical workflow, retrieving information, recording an observation, submitting information back into the clinical record, booking an appointment or performing another operation covered by the integration.
The witness should be able to see how that action flows through the product and into the clinical system.
Suppose a clinician opens the third-party application and requests information about the patient currently selected within EMIS Web. The demonstration should show the user action inside the product, the retrieval of the appropriate patient context, the call made through the integration, the information returned and the resulting information shown to the clinician.
If the product subsequently writes information into EMIS Web, the demonstration should continue rather than stopping when the API returns success.
The corresponding EMIS patient record should be opened and the resulting entry inspected. The team should be able to demonstrate that the expected information has been filed against the correct test patient and that the content appearing within EMIS corresponds to the action approved in the third-party product.
This distinction is important during preparation. An API returning a successful response is not the same demonstration as proving the complete product workflow.
The same approach should be repeated for each operation included within the go-live scope.
For example, depending on the integration, the session could include workflows involving retrieval of patient information, appointment functionality, patient context, filing documents, recording clinical information or other supported transactions.
Each should be demonstrated through the product rather than treated as an isolated API test.
The person driving the demonstration should also understand the boundary between the application’s own logic and the IM1 operation. If an assessor asks what causes a particular call to occur, the team should be able to identify the triggering action clearly.
Likewise, if the product retrieves information automatically at a particular point in a workflow, the team should be able to show when that retrieval happens and how the user can request refreshed information when required.
Refreshing is an important practical test. A product may retrieve clinical information correctly on initial load but continue displaying locally cached information afterwards. Where the workflow requires current clinical-system data, the witness test may therefore include changing or identifying information within the clinical system and requesting a refresh from the third-party product.
The new state should then be reflected correctly.
A good preparation technique is to create a script for every API-enabled journey containing four stages: initial state, user action, expected integration behaviour and observable result.
That script should still allow the demonstrator to respond naturally to questions. Witness tests can expose weaknesses when a team has rehearsed only a single sequence of clicks and cannot explain what the product is doing underneath them.
The developers supporting the session should therefore understand the integration path sufficiently well to trace a transaction from the user interface through the application’s integration layer and into the clinical system.
Patient identity is one of the areas where an apparently small implementation detail can become a significant witness-test scenario.
The application needs to behave predictably not only when the expected patient is available but also when patient context cannot be established.
Consider a workflow that uses patient matching. The straightforward scenario demonstrates the product successfully obtaining the intended patient and retrieving the appropriate information.
The more revealing scenario is what happens when no matching patient can be returned.
The application should move into a safe state. It should not attempt to infer another patient, reuse an inappropriate previous patient or continue the workflow using stale patient information. Instead, the product should return no patient data and provide the user with an appropriate message or instruction.
Preparing the witness test therefore means constructing both states deliberately.
Another scenario can involve current-patient context. Where an integration obtains the identifier of the patient currently selected within the clinical system, the team should demonstrate how the application responds to changing context.
For an EMIS integration, this can include behaviour when more than one EMIS client is open.
This is not a scenario to discover for the first time during the witness test.
The development team should already have tested how the applicable interface behaves, how the product determines the patient it should act upon and what happens where the context is ambiguous or unavailable.
The witness demonstration should make the outcome visible.
Patient context should also be traced across the application. If a user moves from one patient to another, the previous patient’s information should not remain available in a way that could lead to an incorrect action. Cached information, background requests and asynchronous user-interface components all need to respect the active patient context.
Write-back workflows receive an additional level of scrutiny because the integration is changing the primary clinical record.
The demonstration should start before submission occurs.
If the application has generated or collected clinical information that will be filed into EMIS Web, the clinician should be shown the information inside the third-party product and given the opportunity to review it.
Where the approved workflow requires clinician approval, filing should only occur after that explicit action.
The demonstrator can then submit the information, allow the IM1 transaction to complete and move into EMIS Web to confirm the resulting record.
The complete chain should be visible: information prepared, information reviewed, submission approved, transaction performed and record updated.
Key IM1 witness test point: For an EMIS IM1 or SystmOne integration, a successful API response is only part of the evidence. Suppliers should be ready to demonstrate the complete end-to-end clinical workflow, including the correct patient context, clinician review where required, the IM1 transaction itself, and verification that the expected data has been written to or retrieved from the principal clinical system.
If the product allows the information to be edited before filing, this can be demonstrated as part of the same journey. An assessor should be able to see that the data finally written to the record corresponds to the data actually approved by the clinician.
Coded information also needs to be exercised properly.
Where the product files coded clinical data, the implementation should use the coding required for the relevant workflow, including appropriate SNOMED CT concepts where applicable. The team should know which code is being submitted rather than relying only on the human-readable description presented within the user interface.
During testing, it can be useful to inspect both the submitted data and the resulting entry in the clinical system. This provides a much stronger demonstration than showing that a label such as “blood pressure” or “smoking status” appears on screen.
Several clinical-data scenarios are particularly useful to rehearse before the witness session:
The important preparation technique is to test transitions, not just static states. Many patient-safety problems emerge when the user changes patient, refreshes data, goes backwards in a workflow, opens a second clinical-system window or retries an interrupted transaction.
A witness test should include failures deliberately.
Teams sometimes prepare extensively for the successful demonstration and treat failure handling as something that can simply be described. A stronger approach is to create reproducible failure conditions and demonstrate exactly how the product responds.
An API call can fail for many reasons. The underlying cause may be connectivity, authentication, permissions, unavailable data, validation or a clinical-system response that prevents the requested transaction.
The important behaviour at product level is that the user receives an appropriate response and the application remains in a known state.
User-facing errors should be written for the person performing the workflow. Raw exception messages, stack traces, internal identifiers or opaque technical responses should not be used as the primary instruction presented to a clinician or administrator.
The message should make it clear what the user can do next.
That could mean trying again, selecting a patient, correcting information, contacting an administrator or stopping the workflow.
At the same time, the application should retain enough technical information within its logging and monitoring systems for the support team to investigate the transaction.
This creates two different layers of error handling: a safe and useful message for the end user, and sufficiently detailed diagnostic evidence for the technical team.
Audit evidence can then be demonstrated alongside those transactions.
The team should be able to trace significant integration actions through the product’s logs. The exact fields recorded will depend on the architecture and data-handling model, but an investigator should be able to establish the relevant transaction, when it occurred, which authorised user initiated it, the type of operation involved and whether it completed successfully.
Sensitive data should not simply be dumped into logs unnecessarily. Auditability and data minimisation should be designed together.
Authentication can also be tested through actual login behaviour. The witness session may require the team to demonstrate both successful and unsuccessful authentication and explain the controls applied by the product.
If multi-factor authentication forms part of the agreed implementation, it should be demonstrated in the same production-like user journey. Password controls, account behaviour and unsuccessful access attempts should match the product configuration being taken through assurance rather than a separate development configuration.
Session behaviour should be equally concrete.
If the application has an inactivity timeout, the team should know exactly how it behaves. A session reaching the timeout should not leave an apparently active clinical workflow indefinitely available. The product should transition into the intended logged-out, locked or re-authentication state while handling any unsaved information in the manner designed for the application.
Role-based access control is best demonstrated using different accounts.
For example, if a clinician can perform an operation that an administrative user cannot, log in as each role and attempt the relevant workflow. Showing a permissions configuration page is less persuasive than demonstrating enforcement.
The important distinction is between hiding an action in the interface and preventing the underlying operation. The application should enforce authorisation at the appropriate technical boundary rather than depending entirely on whether a button is visible.
The same principle applies to actions exposed through IM1. Booking, cancelling, filing or retrieving sensitive information should occur only within workflows and roles authorised for those operations.
A witness test may also explore how the solution technically interacts with the clinical system. Where the product is approved to use formal interfaces, the team should be able to demonstrate that the integration operates through those interfaces and does not depend on screen scraping, robotic process automation or simulated interaction with the clinical-system user interface.
This is particularly important for products that include desktop components, browser extensions or workflow automation. The engineering team should understand precisely which integration mechanism is responsible for each action and be able to distinguish an approved interface interaction from UI automation.
A witness test does not need to end the moment the final successful transaction has been demonstrated.
The final stage should reconcile the session against the agreed test scope.
For each required scenario, the team should be able to confirm what was demonstrated, what result was observed and what supporting evidence exists. If screenshots, logs, test records or other evidence are required as part of the agreed assurance approach, they should correspond to the same product version and workflows demonstrated during the session.
Any issue identified should be captured precisely.
A vague note such as “patient matching needs fixing” is much less useful than recording the exact starting state, user action, response, expected behaviour and observed behaviour. The latter allows the development team to reproduce the problem and gives the assurance process a clear basis for reviewing the eventual correction.
Where a change is required, the team should also consider whether it affects only the observed defect or alters the wider assured workflow. Fixing an error message, for example, is different from changing when a transaction is triggered or introducing a new automated clinical action.
After remediation, the affected test should be repeated in the same controlled manner.
The integration team should maintain alignment between the product implementation, the test evidence and the description of the solution within the SCAL assurance documentation. If those three things describe different behaviours, the discrepancy tends to surface during technical questioning.
This is one reason effective IM1 witness-test preparation is highly technical. The people supporting the session need to understand the product beyond the visible user interface.
They need to know which IM1 operations are being called, when they are called, what context is supplied, how responses are handled, how permissions are enforced, how transactions are logged and how the resulting state can be verified within the principal clinical system.
At 6B, we prepare integrations for witness testing by working backwards from those observable behaviours.
We map the approved IM1 scope to the actual product journeys, turn each journey into repeatable positive and negative scenarios, verify the integration behaviour in the supported test environment, inspect the resulting clinical-system state and make sure that the evidence available during the session reflects the implementation being demonstrated.
For an EMIS IM1 witness test, that can mean moving repeatedly between the customer’s application, the integration layer, technical logs and EMIS Web itself. For SystmOne or another principal clinical system, the interface details differ, but the preparation method remains similar: test the real workflow, control the starting state, know which interface is being exercised, inspect the result and deliberately test what happens when the ideal path breaks.
The best indicator that a product is ready for its IM1 witness test is therefore not that the team has a polished demonstration.
It is that the team can change the patient, change the user, force an error, refresh the data, inspect the logs, repeat a transaction and still explain exactly how the product behaves.
That is the level of preparation required to turn a functioning IM1 integration into a demonstrable, supportable release candidate ready to progress through assurance.
Is an IM1 witness test always required?
Not necessarily. NHS England’s IM1 assurance process allows for test evidence to be agreed or for a witness test to be undertaken. The exact assurance approach is agreed with the relevant provider supplier during the Supported Test Phase, so requirements can differ depending on the product, IM1 interfaces and clinical-system integration involved.
What happens after an IM1 witness test is completed?
Completing the IM1 witness test is an assurance milestone rather than the final go-live step. Once the required assurance has been accepted, NHS England can issue a Recommended to Connect, after which the provider supplier issues a Plan to Connect and the product can progress towards deployment across the relevant clinical-system estate.
Does passing an IM1 witness test mean a product can immediately go live?
No. A successful IM1 witness test does not by itself provide immediate production access. The wider IM1 assurance process must be completed, including acceptance of the Supplier Conformance Assessment List (SCAL), the appropriate connection steps and the provider supplier’s arrangements for moving the assured integration into live use.
Can the same IM1 assurance cover both EMIS Web and TPP SystmOne?
A supplier can apply to integrate with more than one IM1 provider supplier, but EMIS Web and TPP SystmOne use their own provider-specific APIs and integration arrangements. NHS England states that consumer suppliers pair with the specific API for each GP system supplier, and a Model Interface Licence is executed with each relevant provider supplier. Testing and assurance should therefore account for the individual integrations being taken live.
Does an IM1 integration need further assurance after it has gone live?
It can. NHS England requires suppliers to raise a Request for Change (RFC) when an assured IM1 product changes from its originally approved use case or when significant functionality is introduced. Depending on the change, further assurance may be required before the updated functionality can be deployed into live use.
Is your team looking for help with IM1 integration? Click the button below.
Get in touch