Integration Compliance & Assurance Standards

Purpose of this Page

This page explains what is not permitted when integrating with our interfaces and outlines the minimum assurance requirements partners must meet before going live.

Audience

• Partners and vendors building solutions that integrate with our platform
• Technical, product, and clinical safety teams responsible for architecture, security, and risk

1. Areas for Further Attention

1.1 Middleware and Re-Brokering of Our APIs

We do not allow integrations that introduce a middleware layer whose purpose is to:

• Consume our APIs and re-expose them as a separate product or service
• Act as an intermediary platform that other third parties integrate into, using our data and APIs as the upstream source
• Aggregate or transform data from our APIs in a way that creates an opaque, onward-facing interface outside of agreed patterns

In practice:

• Third parties must not build an interface or platform that consumes our APIs and then sell that interface to other third parties as their primary route to integrate.

Integrations must:

• Connect directly to our approved interfaces
• Follow our documented patterns and contractual terms, rather than creating a secondary “hub” or brokerage layer

1.2 Robotic Process Automation (RPA) and UI Automation

We do not allow the use of RPA or similar UI automation technologies to integrate with our systems. This includes:

• Screen-scraping or computer-vision tools that “read” the user interface
• Automated scripts that simulate clicks, keystrokes, or navigation
• Any solution relying on optical or layout-based recognition of UI elements

Why:

• The clinical system UI can change at any time without notice
• Automated UI workflows can silently fail, mis-select fields, or act on the wrong patient
• This creates unacceptable clinical safety and data quality risks

All integrations must use our published APIs and formal integration routes.

1.3 Use of Artificial Intelligence (AI)

AI may be permitted, but additional scrutiny is required.

You must:

• Declare any AI/ML models that use data from our platform
• Provide details on:
  • Purpose of the model
  • High-level design and architecture placement
  • Training and inference data (including patient data usage)
  • Data flows in/out of the model
  • Validation, governance, and monitoring processes

We will assess:

• Clinical safety and risk of harm
• Data protection and privacy risks
• Risk of bias, clarity of decision-making, and clinical relevance

Approval is not guaranteed and may require extra documentation or review sessions.

1.4 Patient-Facing Applications

Our Partner API is not approved for use in patient-facing applications—that is, applications where the patient is the end user and can view their own clinical data directly (e.g., patient portals, mobile apps).

Specifically, you must not:

• Use the Partner API as the primary data source for apps or portals that present clinical information directly to patients.

Why: The Partner API is intended for controlled, assured use cases, such as:

• System-to-system integrations
• Clinician-facing workflows
• Partner solutions within a governed clinical environment

These use cases are covered by our clinical safety and assurance model. Patient-facing solutions are not in scope of this model and therefore are not permitted via the Partner API.

If you are interested in building a patient-facing application, you must:

• Utilise our dedicated Patient Facing Service API (PFS).

2. Assurance Prerequisites

To complete our assurance process and be approved for integration, partners must have the following:

2.1 Data Protection Impact Assessment (DPIA)

Your DPIA should cover:

• Lawful basis for processing
• Categories of personal and special category data
• Data flows and storage locations
• Privacy risks and mitigations

We will request a copy during review.

2.2 Data Security and Protection Toolkit (DSPT)

You must have an up-to-date submission for NHS Data Security and Protection Toolkit (DSPT) that is appropriate for your organisation type and role.

At a minimum, we expect that:

• Your DSPT status is current (not expired or significantly overdue)
• Any high-risk or critical gaps identified in your DSPT self-assessment have clear remediation plans
• Your DSPT scope covers the systems and services involved in your integration of our platform

2.3 Penetration Testing (Annual)

• Be performed by an independent third-party supplier accredited under CREST or CHECK
• We do not accept internal-only testing or testing by non-accredited providers
• Scope includes all components involved in integration
• Evidence of latest test (summary report, remediation plan) on request
• Critical/high-risk vulnerabilities must be mitigated before go-live and medium risks must have mitigations planned and be evidenced

2.4 Clinical Safety & DCB0129 Compliance

Your product must meet NHS clinical safety expectations and comply with DCB0129, including:

• Hazard Log: Structured register of hazards, likelihood/severity, mitigations
• Safety Case: Evidence-backed argument that the product is safe for clinical use
• DCB0129 Compliance: Documented clinical risk management process, CSO appointment, supporting documentation

3. What to Do Next

Before starting technical integration:

• Review your architecture
• Confirm there is no unsupported middleware, RPA or UI automation
• Identify and document AI models using our data
• Review our available APIs and services to ensure they are appropriate and sufficient for your use case
  • If the available APIs do not fully support your requirements, please discuss this with us rather than introducing workarounds

Ensure prerequisites are in place:

• DPIA
• Annual penetration test
• Hazard log
• Safety case
• DCB0129 compliance
• DSPT up-to-date

Contact us early if:

• Unsure about middleware/RPA
• Using AI and need feasibility feedback
• Working towards prerequisites and need timeline discussion