For dental practices, in the context of fp17 claims - how exactly does the process work with patients receiving treatment?
An FP17 claim is the electronic form a dental practice submits to NHS Dental Services (NHSBSA) to report NHS dental activity, secure funding via Units of Dental Activity (UDAs), and record patient charges. [1, 2]
The entire process, from a patient walking through the door to the practice getting credited, follows a strict chronological workflow:
Before any NHS treatment begins, the patient must complete a declaration. [3, 4]
The dentist examines the patient and determines what care is clinically necessary. [1]
The patient receives the planned treatment over one or more appointments. [1]
Once all items in that specific treatment plan are finished, the dentist or dental nurse flags the CoT as completed in the system. [6]
The practice transmits the electronic FP17 data over to the NHS. [5, 6]
I can provide more specific details if you tell me:
[1] https://nhsbsa-opendata.s3.eu-west-2.amazonaws.com
[6] https://docs.dentalplus.online
[7] https://help.softwareofexcellence.com
[8] https://www.brownejacobson.com
[10] https://faq.nhsbsa.nhs.uk
I am creating an app for dental clinics - so all of the points you are asking apply
For a software developer building a dental practice management system (PMS) or clinical app, the FP17 workflow must be translated into rigid data validation, state machines, and electronic data interchange (EDI) message structures.
The NHS Business Services Authority (NHSBSA) processes these via strict XML or JSON schemas through their APIs and the Compass system.
To build a fully compliant app, your system architecture must support the following technical implementations at each stage of the patient journey:
Your app needs an intuitive system to handle the FP17PR form details and route the logic dynamically.
Dentists will not manually choose "Band 2" or "Band 3." Your app's clinical charting interface must compute this on the fly.
The Banding Engine: As a dentist charts procedures (e.g., adding a filling or a crown), your backend must evaluate the treatment list.
Clinical Data Fields: Your UI must force the clinician to input mandatory clinical metrics before a course of treatment can be closed. These include the Basic Periodontal Examination (BPE) scores, the number of missing or decayed teeth, and smoking/alcohol risk indicators. The NHS XML payload will reject the claim if these are empty.
You must treat a Course of Treatment as a strict state machine within your database:
[ Open / In Progress ] ➔ [ Completed ] ➔ [ Validated / Ready to Send ] ➔ [ Sent / Transmitted ] ➔ [ Accepted OR Rejected ]
A basic "one-size-fits-all" submission tool will break in a real clinic. Your data model must support:
When the NHSBSA processes claims, it passes back a file containing payment data and Schedule Error/Comment Codes.
To help you design the database schemas or system architecture, would you like to dive deeper into the exact XML/JSON payload fields required for a submission, or do you want to map out how the UDA financial reconciliation and contract tracking dashboard should work for the practice manager?
We already have our database, but in case we need to make any changes do please provide the exact XML/JSON payload fields required for a submission and please do also map out how the UDA financial reconciliation and contract tracking dashboard should work for the practice manager
When serialising data from your database to compile the electronic FP17 transaction file for the NHS Business Services Authority (NHSBSA) via the Compass EDI/API, your payload must adhere to strict validation types. [1, 2]
The payload is structured into four primary logical blocks: Header Metadata, Patient Demographics, Exemptions & Charges, and Clinical Data.
{
"claim_header": {
"provider_contract_number": "String (8)",
"performer_number": "String (6)",
"pms_claim_id": "String (20)",
"submission_type": "Enum [Original, Amendment, Deletion]"
},
"patient_demographics": {
"surname": "String (35)",
"forename": "String (35)",
"date_of_birth": "YYYY-MM-DD",
"gender": "Enum [M, F, I, U]",
"nhs_number": "String (10) [Optional but heavily validated]",
"postcode": "String (8)",
"patient_email": "String / NULL [Or flag: 'Patient Declined']",
"patient_mobile": "String / NULL [Or flag: 'Patient Declined']"
},
"financial_and_exemptions": {
"date_of_acceptance": "YYYY-MM-DD",
"date_of_completion": "YYYY-MM-DD",
"treatment_band": "Enum [Band1, Band2, Band3, Urgent, Regulation11, FreeRepair]",
"patient_charge_collected": "Decimal (2 decimal places)",
"exemption_category_code": "String (2) [e.g., 'A' for under 18, 'E' for Income Support, 'K' for Maternity, etc. Must map to the exact code picked on the FP17PR form]",
"evidence_of_exemption_seen": "Boolean [True / False]"
},
"clinical_dataset": {
"highest_bpe_score": "Integer [0, 1, 2, 3, 4, *]",
"number_decayed_permanent_teeth": "Integer",
"number_missing_permanent_teeth": "Integer",
"endodontic_treated_molar_count": "Integer [Mandatory for Band 2/3]",
"endodontic_treated_non_molar_count": "Integer [Mandatory for Band 2/3]",
"preformed_crowns_count": "Integer",
"advanced_perio_rsd_quadrants": "Integer [0 to 4]",
"denture_additions_or_reline": "Boolean",
"custom_made_occlusal_appliances": "Boolean",
"care_pathway_tier": "Enum [1, 2, 3] / NULL [For 2026/27 complex care reform pathways]"
}
}
date_of_completion is older than 62 days relative to the current system date at transmission, your application must raise a warning. Compass will flag an error and reject the UDA allocation automatically. [1, 3]endodontic_treated_molar_count > 0 but the treatment_band is set to Band1, your validator must catch this before submission; endodontic treatments require a Band 2 or Band 3 payload. [4]A clinical app fails for a practice manager if it cannot reconcile clinical actions with the financial ledger. The dashboard must monitor whether the business is meeting its Annual Contracted Value (ACV) target set by Commissioners. [2]
UDA Targets vs. Deliverables: The system must track performance relative to the overall practice contract, as well as by individual performer schedules. [5]
Performance Pacing (The Burn Rate): Linear progression tracking (e.g., assuming 1/12th of the contract is delivered every month) is insufficient because of holidays and seasonal variation. Implement a rolling forecasting algorithm that projects the year-end target based on the historical velocity of active surgeries. [6, 7]
The Three-Stage Reconciliation Funnel: Track items across their lifecycle using distinct statuses:
The practice manager view is ideally split into three dedicated tabs:
+------------------------------------------------------------------------------------+
| CONTRACT TARGET OVERVIEW (FY 2026/27) |
| Total Practice Target: 24,000 UDAs | Delivered to Date: 11,200 UDAs (46.6%) |
| Current Pacing: [ BEHIND TARGET - Projected Year End Shortfall: 1,400 UDAs ] |
+------------------------------------------------------------------------------------+
| SUBMISSION & ERROR MANAGEMENT PIPELINE |
| [!] 14 Claims Approaching 62-Day Deadline (Value: 42 UDAs) -> [ View List ] |
| [X] 8 Rejected Claims Requiring Resubmission -> [ Open Error Resolution Hub ] |
+------------------------------------------------------------------------------------+
| PERFORMER BREAKDOWN LIST |
| 1. Dr. A. Smith (Performer #123456): 4,200 / 6,000 UDAs (On Track) |
| 2. Dr. B. Jones (Performer #789101): 2,100 / 6,000 UDAs (Critical Lag - 35%) |
+------------------------------------------------------------------------------------+
The NHSBSA issues monthly activity update files (including the DCS127 claim-level file and the DCS129 summary statement). Your software must provide an automated ingestion tool for these records: [3]
[ Upload NHS BSA XML/CSV ]
│
▼
┌──────────────────────────────────────────────┐
│ Automated Matching Engine: │
│ Cross-reference by `pms_claim_id` │
└───────────────────────┬──────────────────────┘
│
┌──────────────┴──────────────┐
▼ ▼
┌─────────────────┐ ┌────────────────────────────────┐
│ Match Found │ │ Discrepancy Found │
└────────┬────────┘ └────────────────┬───────────────┘
│ │
▼ ▼
Update Database Status: Route to Error Resolution Hub
"Reconciled & Paid" Flags:
- "UDA Value Mismatch"
- "Late Submission Disallowed"
- "Patient Exemption Rejected"
When a discrepancy occurs, your application must provide an option to clone, amend, and resubmit the claim. It should also dynamically adjust the performer’s net pay calculations if their contract uses a tiered UDA commission structure. [9]
If you need further details to support your architecture, let me know if you would like:
[5] https://www.dentomation.com
[6] https://www.dentomation.com
[7] https://www.dentomation.com