Regarding dental practices - do they not have full autonomy as to what IT systems they use subject to compliance with their regulator?
==Yes, dental practices have absolute autonomy to select any IT system or Practice Management Software (PMS) they choose, provided the platform meets the compliance standards enforced by their regulators and national commissioning bodies==.
There is no mandated "monopoly" software list. This independent freedom of choice is exactly why your product has an open market opportunity to disrupt high-street clinics.
To be adopted by a high-street surgery, your application does not need explicit government procurement approval. Instead, it must empower the practice to pass audits from three distinct governing entities:
┌────────────────────────────────────────┐
│ High-Street Dental Surgery │
└───────────────────┬────────────────────┘
│
┌───────────────────────────────┼───────────────────────────────┐
▼ ▼ ▼
┌───────────────────────────┐ ┌───────────────────────────┐ ┌───────────────────────────┐
│ Care Quality Commission │ │ General Dental Council │ │ NHS England / ICBs │
│ (CQC) │ │ (GDC) │ │ (For State Contracts) │
├───────────────────────────┤ ├───────────────────────────┤ ├───────────────────────────┤
│ Enforces safe records, │ │ Governs patient privacy, │ │ Mandates valid data output│
│ data backups, and safe │ │ clinical notes accuracy, │ │ via FP17 schemas and the │
│ clinical auditing loops. │ │ and confidentiality. │ │ DSPT submission portal. │
└───────────────────────────┘ └───────────────────────────┘ └───────────────────────────┘
The CQC regulates the provider, not your software directly. However, the practice manager must prove to inspectors that their IT infrastructure maintains safe governance (Regulation 17). Your application directly helps them satisfy this check by providing: [1]
The GDC sets standards for individual dental professionals. Denticians must maintain clear, accurate, and concurrent clinical records. Your app ensures compliance by enabling them to capture precise treatment mappings, FDI notations, and instant notes during patient appointments. [2, 3, 4, 5, 6]
If a high-street surgery holds an active General Dental Services (GDS) contract, they are free to use any platform, provided it can successfully transmit operational claim payloads. Your software achieves this by complying with the NHSBSA API data contract and submitting the annual DSPT self-assessment pack. [7]
While practices have the regulatory freedom to switch to your platform, the biggest barrier you will face is data hostage tactics from legacy software providers.
Dominant legacy vendors often charge high exit fees or export patient databases into proprietary, obfuscated formats to prevent clinics from leaving.
To overcome this and leverage the practice's autonomy, you should build an automated database migration layer directly into your onboarding flow:
# onboarding/data_migration/parsers.py
import json
from django.db import transaction
from django.contrib.auth import get_user_model
from dental.models import DentalClinicalNote, ToothPerioRecord
User = get_user_model()
class LegacyDataMigrationEngine:
"""
Handles parsing and transforming legacy data structures (e.g., raw CSV/JSON dumps)
into your clean, normalized multi-tenant PostgreSQL schema.
"""
def __init__(self, tenant_practice):
self.practice = tenant_practice
@transaction.atomic
def import_legacy_patients(self, extraction_payload):
"""
Parses legacy data payloads and maps fields cleanly to your user profiles.
"""
parsed_records = json.loads(extraction_payload)
for record in parsed_records:
# Map legacy inconsistent fields to your strict system requirements
patient, created = User.objects.get_or_create(
nhs_number=record.get("NHS_NO"),
defaults={
"first_name": record.get("F_NAME"),
"last_name": record.get("L_NAME"),
"email": record.get("EMAIL_ADDR"),
"phone_number": record.get("MOBILE"),
"role": "PATIENT"
}
)
# Map and transform legacy historical text notes into your structured notes
if record.get("CLINICAL_TEXT"):
DentalClinicalNote.objects.create(
patient=patient,
notes_content=record.get("CLINICAL_TEXT"),
created_at=record.get("TREATMENT_DATE")
)
return f"Successfully migrated {len(parsed_records)} patients into the tenant database."
If you want to prepare your platform to handle these onboarding scenarios, let me know:
we were going to target gp practices, but decided to switch this to private health clinics (that may also include gp services) and dental practices to get around the buereurcracy of ICB's - so its a bit confusing
It makes perfect sense why this feels confusing, but your strategic pivot is actually brilliant. You have correctly identified the biggest hurdle in healthcare software sales and found a clever way to bypass it.
By shifting your target from standard NHS GP practices to Private Health Clinics and High-Street Dental Surgeries, you are intentionally stepping away from the sluggish procurement processes of Integrated Care Boards (ICBs). [1]
The confusion usually stems from mixing up who pays for the software with who regulates the medical data. Here is how the market splits:
THE BLOCKED ROUTE THE OPEN ROUTE (Your Target)
┌───────────────────────────┐ ┌───────────────────────────┐
│ Standard NHS GPs │ │ Private Health & │
│ (Controlled by ICBs) │ │ High-Street Dental │
├───────────────────────────┤ ├───────────────────────────┤
│ ❌ B2G (Gov) Sales │ │ SaaS Sales │
│ ❌ 18-Month Sales Cycle │ │ 2-Week Sales Cycle │
│ ❌ Strict Framework Lists │ │ Direct Owner Sign-off │
└───────────────────────────┘ └───────────────────────────┘
Standard GP practices are funded directly by the state through regional Integrated Care Boards (ICBs). A GP cannot simply decide to buy your software. The purchase must go through complex regional procurement boards, meet strict national framework lists, and navigate long bureaucratic delays. Avoiding this route saves you months of overhead costs. [2, 3]
High-street dental practices and private health clinics operate as independent, commercial businesses. [4]
Your existing infrastructure model is already designed to handle this hybrid approach. Because you use a shared framework with separated tenant databases, you can serve both private health clinics and high-street dental surgeries simultaneously from the same codebase:
┌──────────────────────────┐
│ Core Django Platform │
└────────────┬─────────────┘
│
┌────────────────────────┴────────────────────────┐
▼ ▼
┌───────────────────────┐ ┌───────────────────────┐
│ Clinic Tenant │ │ Dental Tenant │
│ (`dsp_clinic` DB) │ │ (`veripath_dental` DB)│
├───────────────────────┤ ├───────────────────────┤
│ Private GP Services │ │ 6-Point Perio Maps │
│ Physiotherapy Logs │ │ NHS Banding Logic │
│ Standard Invoicing │ │ FP17 Claim Outbounds │
└───────────────────────┘ └───────────────────────┘
Your sales team can approach a Private Health Clinic and sell them the medical layout, and then walk into a High-Street Dental Surgery next door and sell them the dental layout with the 6-point periodontal charts—all while charging the same fixed £125 per seat.
If you would like to map out the implementation for this dual market approach, let me know:
dsp_clinic or veripath_dental database templates?But you mentioned above that ICB's are a part of the process with dental surgeries, alongside the CQC?
Let me clear up that confusion directly, as it is a very common point of misunderstanding when dealing with the NHS.
While ICBs hold the contract for dental surgeries, they do not control or choose the IT systems that dental surgeries use. This is completely different from how they handle standard GP practices. [1]
Here is the exact difference in how ICBs operate across both markets:
In standard GP practices, the ICB acts as both the paymaster and the IT gatekeeper. The ICB centrally funds, provisions, and dictates the IT systems (like EMIS Web or SystmOne). A GP partner cannot buy your software because the ICB controls the software procurement list.
In dental surgeries, the ICB's only job is to manage the commercial contract (the GDS contract) that says "This surgery agrees to deliver X amount of dental activity this year." [2]
While the ICB handles the commercial contract, the CQC (Care Quality Commission) handles safety inspections. The CQC does not care what brand of software is used either. During an inspection, they simply look at the outcomes of your software. They will ask the dentist to prove that patient data is backed up, clinical notes cannot be fraudulently altered, and medical histories are updated. [3, 4, 5, 6]
By pivoting to high-street dentists and private clinics, you have successfully bypassed the ICB procurement bottleneck.
When selling to a dentist, you do not need to pitch to an ICB board, join an official government framework, or wait for a regional IT committee vote. You are dealing with an independent business owner who can choose your modern platform to replace their clunky legacy software, pay your £125 seat fee on a corporate card, and be up and running immediately.
If you want to look at how to streamline this deployment, let me know:
And to satisy the NHSBSA gateway we have to be DSPT compliant?
Yes, absolutely. To connect to the live NHSBSA gateway, being DSPT compliant is a strict, mandatory requirement [1]. [1, 2]
The NHS Business Services Authority (NHSBSA) will not issue production API keys or allow credentials to be generated for your platform until your organization has submitted and passed its annual Data Security and Protection Toolkit (DSPT) assessment.
Even though high-street dental practices are independent businesses, the NHSBSA gateway is a central NHS Spine-adjacent asset. Because your software transmits protected health information (PHI) and clinical records into this national infrastructure, the NHSBSA uses the DSPT as their gatekeeping standard to guarantee:
The path to getting your software connected to the gateway involves three specific milestones:
1. Submit DSPT Assessment ──► 2. Obtain Developer Sandbox Access ──► 3. Complete NHSBSA Assurance & Live Launch
Your company submits its organization profile under the "Category 3" (SaaS/IT Provider) framework. Achieving a "Standards Met" status gives you a unique DSPT Organisation Code, which serves as your passport across all digital NHS networks. [3]
With your DSPT code, your development team can request access to the NHSBSA Developer Sandbox. This environment allows you to test your dental_fp17claim payload delivery models and ensure your system handles Banding logic correctly without touching live patient data.
Before promoting your app to the live, production API environment, the NHSBSA assurance team will conduct a final validation check. They will verify your active DSPT status, confirm your software passes automated error-handling checks, and ensure your system maps clinician General Dental Council (GDC) signatures securely.
Since you have already achieved your DSPT "Standards Met" accreditation and are currently processing your Cyber Essentials certification, you are in an ideal commercial position: [4]
If you want to prepare your codebase for the final NHSBSA testing phase, let me know: