Dental website development using 1C-Bitrix

Dental Clinic Website Development on 1C-Bitrix

A dental clinic is not a general clinic with "dental" as a footnote. The specifics are significant: the patient doesn't come for a single appointment but for a treatment plan spanning multiple visits and procedures, the cost of which they want to understand in advance. A gallery of before/after work is the primary argument when choosing a clinic. Booking is tied not simply to a doctor but to a doctor of a specific specialty, and the schedule depends on the cabinet's equipment.

On 1C-Bitrix, a dental website is built from infoBlocks of services, doctors, cases, and a custom treatment plan calculator. The calculator is the most non-trivial part—we'll examine it in detail.

Treatment Plan Cost Calculator

A patient comes to the dental clinic's website with a specific problem: a tooth aches, needs a crown, wants to straighten their bite. But the final cost is composed of a chain of procedures: consultation → diagnostics (CBCT scan) → treatment → prosthetics. The calculator must assemble this chain and show a cost range.

Data Structure

Foundation—infoBlock Services with hierarchical sections by specialty:

• Therapeutics (cavity treatment, pulpitis, periodontitis treatment)
• Orthodontics (braces, aligners)
• Implantology (implant placement, abutment, implant crown)
• Oral surgery (extraction, bone grafting, sinus lift)
• Prosthodontics (veneers, crowns, bridges, dentures)
• Pediatric dentistry
• Hygiene and whitening

Each service has properties:

The key property is LINKED_SERVICES. It determines which procedures are automatically included in the plan. For example, when "Nobel Biocare implant placement" is selected, these are automatically added: CBCT scan, implant consultation, anesthesia, abutment, temporary crown. Each of these links has an IS_REQUIRED_STEP flag—whether it's mandatory or optional (patient can decline the temporary crown).

Calculator Logic

The calculator is a JavaScript component (React or Vue, embedded in Bitrix template) that receives data from an API.

Step-by-step workflow:

1. Problem selection—patient chooses from: "Tooth ache," "Need crown," "Want implants," "Straighten teeth," "Cleaning." Each problem maps to a set of base services
2. Clarification—for implantology: how many teeth, which zone (anterior/posterior), is there bone tissue (this determines sinus lift necessity). For orthodontics: metal/ceramic braces or aligners
3. Plan formation—system assembles procedure chain, pulls related services, calculates overall price range
4. Result—table with treatment stages, cost of each stage, total "from" and "to" amounts, approximate number of visits

API endpoint is implemented as a custom Bitrix component, returning JSON. Request: GET /api/calculator/?problem=implant&count=2&zone=chewing. Response contains an array of stages with prices.

Additional Calculator Features

• Option comparison. For prosthetics: metal-ceramic vs zirconia vs E-max. Three columns with different prices and characteristics
• Save plan. Authorized user saves plan in personal account. Unauthorized user receives an email link (plan saved in Highload block SavedPlans with unique hash)
• Send plan for consultation. "Discuss with doctor" button—data goes to Bitrix CRM as a lead with plan details

Crucial point: the calculator shows a range, not exact price. Exact cost is determined only after doctor examination. This is both legally correct and reduces claims.

Service Catalog by Specialty

A dental clinic's service catalog differs from general medical in that patients search not by procedure name (they don't know they need "root resection") but by problem. Therefore, navigation is dual:

• By specialty—infoBlock sections: therapeutics, oral surgery, prosthodontics, orthodontics, pediatric, aesthetic
• By problem—separate infoBlock Problems with service bindings: "Tooth ache" → cavity treatment, pulpitis treatment, extraction; "Missing tooth" → implant, bridge, removable denture

For SEO, each specialty is a separate landing page with unique text written under a specialist's supervision. Component catalog.section displays specialty services, catalog.element shows service detail.

Before/After Case Gallery

This is one of the primary conversion elements of a dental website. Patients want to see real results, not stock photos.

InfoBlock CaseGallery with properties:

• PHOTO_BEFORE—before photo (type F, file)
• PHOTO_AFTER—after photo
• DOCTOR_ID—doctor binding (type E)
• SERVICE_ID—service binding (multiple E)
• DESCRIPTION—clinical case description
• TREATMENT_DURATION—treatment duration
• PATIENT_AGE—age group (without PII)
• TAGS—tags for filtering: veneers, implants, braces

Display component is custom, with an interactive before/after slider (user-draggable handle). Frontend uses JS library like image-compare-viewer.

Gallery filtering: by doctor, by specialty, by type. Implemented via AJAX loading with filter parameters in CIBlockElement::GetList().

Patient consent for photo publication is a mandatory legal requirement. The infoBlock can store a consent flag, but the document itself—in protected storage, inaccessible from the website.

Online Doctor Booking

Dental booking is more complex than general clinic for two reasons:

1. Cabinet binding. Not every cabinet is equipped for implantology or orthodontics. Doctor schedule depends on availability of a cabinet with needed equipment
2. Visit duration varies. Consultation—30 minutes, implant placement—1.5 hours, braces application—2 hours. Schedule slots must account for chosen service duration

Highload schedule block is supplemented with fields UF_CABINET_ID (cabinet binding) and UF_SLOT_DURATION (duration in minutes). When "Implant placement" service (120 minutes) is selected, system shows only time windows where an appropriate cabinet is available for needed duration.

Integration with dental MIS (IDENT, StomPRO, 1C:Dentistry) operates on similar principle: schedule synchronization via API, MIS booking creation upon website confirmation.

Moderated Reviews

InfoBlock Reviews:

• PATIENT_NAME—name (without surname, for confidentiality)
• REVIEW_TEXT—review text
• RATING—rating 1 to 5
• DOCTOR_ID—doctor binding
• SERVICE_IDS—service bindings
• SOURCE—review source: website, Yandex, Google, ProDoctors
• EXTERNAL_LINK—link to original (for aggregated reviews)

All reviews left through website form are created with ACTIVE = N. Administrator reviews and activates. For Schema.org—Review markup with itemReviewed type Physician or MedicalOrganization.

Aggregating reviews from external platforms via cron task that parses Yandex.Maps or Google Places API and adds new reviews to infoBlock with source marking.

Implementation Timeline