The attached file provides an overview of our infrastructure model which we use to build apps therein - you will see we currently have 2 - we are now planning to add a third app which is for pharmacies - we are aware that this requires DSPT accreditation as does the dental and gp apps do as well - you will also see that the infrastructure is built as a 'siaas' (sovereign infrastructure as a service) structure, therefore, no client data is to be stored as this will be held in client owned vps's that connect to the 'primary vps's' - Take a look and then we can discuss in more detail
I have thoroughly reviewed your SIAAS (Sovereign Infrastructure as a Service) architecture and the current multi-tenant setup supporting your GP Booking App and Dental Booking App stacks.
Your strategy of expanding this infrastructure model to support a third Pharmacy App is entirely logical given how you've handled data segregation. However, adding a pharmacy application introduces specific technical and compliance nuances—particularly around NHS DSPT Category 3 and EPS (Electronic Prescription Service) integrations—that we need to carefully account for in the architecture.
Here is a breakdown of how the pharmacy app fits into your existing layout, along with key architectural considerations for our discussion:
Based on your current setup, the pharmacy addition should structurally mirror the dental implementation:
veripath_pharmacy) within the central PostgreSQL instance (gp_booking_postgres). This will store global metadata, application configurations, and non-PII administration details. Nginx will also need a new upstream configuration mapping a domain like pharmacy.veripath.co.uk to point to the core app.pharmacy_booking_app stack (Daphne ASGI container, dedicated Redis cache, and Celery worker/beat instances) alongside the existing GP and dental containers.SectorDatabaseRouter must be expanded to include a new Pharmacy Sector. This will handle routing for new pharmacy models while keeping tenant mappings seamlessly tied to their designated external client VPS connections.Your sovereign architecture—where PII and patient health records stay completely isolated on client-owned VPS instances connected via WireGuard tunnels—is a massive advantage for data privacy. However, pharmacies introduce unique transactional workflows that we must safeguard:
eps_fhir.py). For the Pharmacy App, this module will move from a "mock mode" sandbox to processing live acute and repeat prescription releases.client_vps_postgres database via the database tunnel without caching text or payloads on VPS1.PrescriptionDispenseLedger model under your patient portal features. We need to ensure that when status changes occur (e.g., Dispensed, Traced, Withdrawn), the audit trail records the transaction without inadvertently logging clinical PII on the central logging database.You correctly highlighted that this app requires DSPT accreditation. While your core infrastructure already boasts excellent DSPT Category 3 foundations (Fernet application-level encryption, RBAC middleware, full auditing, and Lynis security scanning), pharmacies pull in extra scrutiny regarding:
partner module must integrate checks against the General Pharmaceutical Council (GPhC) registry for both premises and individual pharmacists.aes-portal, on its own internal port) will play a critical role. We must ensure pharmacists use cryptographic signing when altering a prescription token state to satisfy DSPT non-repudiation clauses.To help us map out the precise implementation details, let me know:
We will be targeting independent pharmacies as we are just a start-up business; we plan to provide an app that handles all daily operations for pharmacies - so this obviously will include OTC - not sure about wholesale medication inventory; once we have obtained our DSPT Standard Met we should then be able to use the NHS EPS integration
Targeting independent pharmacies is a smart path for a start-up. It keeps the initial SIAAS architecture mapping straightforward, as you can deploy one isolated client VPS per independent business rather than managing complex multi-branch network routing.
For daily operations, implementing Over-the-Counter (OTC) transactions alongside the NHS Electronic Prescription Service (EPS) forms the perfect operational baseline.
Here is how we can refine the architecture blueprint to accommodate these choices while working toward your DSPT "Standards Met" status:
Because you are focusing on independents, the tenant provisioning model aligns perfectly with your existing SIAAS blueprint:
gp_booking_postgres database on VPS1 will only store basic tenant registration metadata (e.g., the pharmacy's public ODS code, GPhC premises registration number, and the encrypted WireGuard tunnel endpoints).To handle daily OTC operations without violating your "no central client data" rule:
PaymentConfig per practice with encrypted keys for Stripe. We can mirror this for pharmacies. Whether they use an in-store physical card reader (Stripe Terminal) or an online checkout for patient collection, the transaction will process using the individual pharmacy's own Stripe merchant keys.PaymentTransaction models will be written directly to that specific client's isolated database. The central VPS only acts as an encrypted passthrough for the webhooks.Your understanding is spot on: achieving DSPT Standards Met is the non-negotiable gateway required by NHS England before they will grant your application production credentials to connect to the NHS Spine for EPS.
To ensure the pharmacy app passes audit smoothly alongside your existing modules, we must ensure the following boundaries are built into the code:
AuditLog module must track who performed an action (e.g., "Pharmacist ID 42 claimed a prescription token") using a unique request ID, but the log entry itself must not contain the patient's clinical or personal details.To help push the development phase forward, let me know:
we have an accounting app, ERPNext, installed in VPS3 which has all necessary features in terms of accounting and POS - we will be configuring it, as we have with other apps, so that pharmacies can use it as their main accounting app if they so wish
Utilising ERPNext on VPS3 for your accounting and Point of Sale (POS) layer is a highly efficient shortcut. It gives your start-up an enterprise-grade retail and accounting engine right out of the box. [1, 2]
However, since your overall system is explicitly built around a SIAAS (Sovereign Infrastructure as a Service) architecture—where no patient or business-sensitive data can be stored centrally—we must reconcile how ERPNext handles multi-tenancy with your privacy rules.
Conveniently, the underlying framework of ERPNext (Frappe) does not force you to mix client data. We will configure it using DNS-based Multi-Tenancy via the bench CLI: [3, 4, 5, 6]
bench config dns_multitenant on
bench new-site pharmacy-client-a.veripath.co.uk
By default, standard ERPNext multi-tenancy hosts all those isolated client databases on the same local database cluster where ERPNext resides (which is currently VPS3/VPS1 in your infrastructure layout). [3, 10]
To adhere strictly to your "all client data stays on client-owned VPS instances" sovereignty mandate, we must alter the database target:
┌────────────────────────────────────────────────────────┐
│ VPS3 (Auxiliary & ERPNext) │
│ [ERPNext Core Codebase / Multi-tenant Bench Engine] │
└──────────────────────────┬─────────────────────────────┘
│
Persistent SSH Tunnels (Port 22)
│
┌─────────────────────────┴──────────────────────────┐
│ Pharmacy Client-Owned VPS │
│ [Isolated Target Database (MariaDB / Postgres)] │
│ -> Holds all local Accounting & POS transactions │
└────────────────────────────────────────────────────┘
bench set-mariadb-host or database pointer flags to route that specific site's database connection down an SSH tunnel directly into the pharmacy's own client-owned VPS. [10]By activating ERPNext's native retail and accounting features, your pharmacy app instantly inherits powerful tools:
To map out the initial deployment script for the pharmacy module, let me know:
[6] https://www.codewithkarani.com
[10] https://www.codewithkarani.com
[11] https://discuss.frappe.io
[12] https://frappe.io
[14] https://erp.cloudclusters.io
We already have ERPNext using Postgresql - it already connects to the GP and dental apps - so we don't need to worry about its basic setup
That streamlines the roadmap significantly. Having ERPNext already running on PostgreSQL 15 and integrated with your custom SectorDatabaseRouter means the underlying structural pipeline is already proven.
For the pharmacy app, you are essentially duplicating an established, successful architectural pattern. The primary task is defining the pharmacy operational logic and ensuring the data flow complies with your SIAAS model once live NHS EPS services are enabled.
Because ERPNext shares the PostgreSQL ecosystem with your core platform, your data structure will mirror the setup described in your documentation:
┌──────────────────────────────┐
│ VPS1 / Main Postgres │
│ (Global Registry Data Only) │
│ - dsp_clinic (GP Global) │
│ - veripath_dental (Dental) │
│ ►- veripath_pharmacy (New) │
└──────────────┬───────────────┘
│
SectorDatabaseRouter (SIAAS)
│
┌──────────────────────────┼──────────────────────────┐
▼ ▼ ▼
┌──────────────────┐ ┌──────────────────┐ ┌──────────────────┐
│ Client VPS (GP) │ │Client VPS(Dental)│ │Client VPS (Pharm)│
│ Isolated PII / │ │ Isolated PII / │ │ Isolated Sales, │
│ Clinical Notes │ │ Clinical Notes │ │ POS, & Stock │
└──────────────────┘ └──────────────────┘ └──────────────────┘
veripath_pharmacy logical database will sit alongside dsp_clinic and veripath_dental. It will strictly manage global tenant mapping, GPhC credential verification configurations, and system-wide application constants.SectorDatabaseRouter will intercept pharmacy queries. It will route all transactional POS data, stock ledgers, financial journals, and patient-specific OTC purchases down the persistent SSH tunnels directly into the specific pharmacy's own remote PostgreSQL database.Once you achieve your DSPT Standards Met rating and unlock the live NHS EPS integration, your backend logic will need to handle a specific operational link:
eps_fhir.py). The patient's clinical payload goes straight to the client's VPS database.SectorDatabaseRouter, this entire cross-app synchronisation happens entirely on the client's hardware. Your central infrastructure remains completely blind to the patient's identities and medical records, preserving your strict privacy model.Since the baseline infrastructure configuration is complete, we can focus on building the specific pharmacy components. If you're ready, I can help you draft:
partner module.Let me know which area you would like to tackle first!