OpenDentalFork
Context
OpenDentalFork is a community-maintained branch derived from earlier open-source releases of Open Dental. The codebase keeps a pragmatic focus: chairside charting, scheduling, basic billing, and patient records backed by MySQL. In dental networks where a full enterprise EHR feels heavy or cost-prohibitive, the fork is used as a lean EMR/PM core that can hand off imaging to external DICOM viewers and archive studies in a small PACS. It is not a drop-in clone of current commercial editions—feature sets vary by fork and build—so admins usually pilot it in a lab, lock down a known-good version, and standardize around that.
Technical Profile (Table)
| Area | Details |
| Platform / Stack | Windows workstations; server on Windows Server or Linux (VM/metal). App written in C#/.NET with MySQL backend. |
| Database | MySQL 5.7/8.0; typical clinic size runs comfortably on a single instance; supports nightly dumps and point-in-time via binlogs. |
| Core modules | Patients, appointments, odontogram, treatment plans, progress notes, basic billing/claims, reporting. |
| Dental imaging | Stores links to files; launches an external viewer (e.g., Weasis, HorliX). No embedded 3D CBCT planning. |
| Interoperability | CSV/SQL export. HL7/claim formats depend on fork; production use usually pairs with lightweight ETL. |
| Auth & roles | App-level users/roles; AD/LDAP not native. Recommend per-user accounts and audited privileges. |
| Multisite | Single database with role-based separation; WAN/VPN or RDS for remote chairs. Latency matters—prefer app server near DB. |
| Security | Encrypted backups; OS-level hardening; database users with least privilege; optional disk encryption on servers/laptops. |
| Backup / DR | mysqldump + binlogs or physical snapshots; verify restores monthly; keep image store and DB backups in lockstep. |
| Deployment model | Small to mid-size dental groups (5–20 chairs). Uses external PACS (e.g., Orthanc) when imaging archives are required. |
| Licensing | Open-source under legacy terms inherited from the base project; community policies differ by fork—pin the license per release. |
| Admin overhead | Low to moderate: DB upkeep, backups, report templates, and occasional schema diffs between builds. |
Installation Guide
1. Prepare the Database
– Install MySQL Server (5.7 or 8.0) on a dedicated VM or physical server.
– Create a database with UTF-8 encoding and enable binary logs.
– Define a restricted application user with least privileges.
2. Server Application Setup
– Obtain the current OpenDentalFork release from the community repository.
– Deploy the server build on Windows Server (or Linux with Mono/.NET runtime, depending on fork).
– Run the installer or copy binaries; configure config.xml (or equivalent) to point at the MySQL instance.
3. Client Deployment
– Install the OpenDentalFork client on each workstation (Windows recommended).
– In client settings, specify the database host, port, and database name.
– Verify login with admin credentials created during setup.
4. First-Time Configuration
– Import procedure codes, fee schedules, and provider data.
– Configure storage paths for X-rays, photos, and documents.
– Register external viewer integrations (e.g., Weasis for DICOM).
5. Backup and Maintenance
– Schedule nightly mysqldump and weekly snapshot backups.
– Mirror the image repository to secure storage.
– Test a full restore at least once per quarter.
6. Security Hardening
– Apply OS-level patches and database security best practices.
– Enforce per-user accounts with appropriate roles inside the app.
– Optionally use VPN or RDP broker for remote chairside access.
Scenarios (Dental-specific)
– A teaching clinic standardizes OpenDentalFork for student rotations: fast odontogram updates, simple reporting, no vendor lock-in.
– A small private network (two locations over IPsec VPN) keeps a single MySQL instance on a hardened Linux VM; imaging is routed to Orthanc with Weasis at chairside.
– An NGO runs a mobile setup: laptops replicate to a hub server in the evening; CSV exports feed compliance reports and donor metrics.
Workflow (Admin View)
1. Stage a VM for the database (dedicated vCPU/RAM; SSD storage; regular snapshots).
2. Install MySQL, set UTF-8, enable binlogs, create a restricted app user; baseline with mysqldump.
3. Deploy OpenDentalFork client/server build; point the app to the DB; run schema init/migrations.
4. Configure users, roles, and required picklists (procedure codes, fee schedules, providers).
5. Define storage paths for images; register external viewer associations (e.g., Weasis for DICOM, standard viewer for photos).
6. Wire up backups: nightly DB dump + weekly full snapshot; mirror the image store; test a full restore on a cold standby.
7. Harden endpoints (OS patching, controlled USB, AV/EDR, least-privilege). Add VPN/RDP broker for remote operators if needed.
8. Freeze the working build (hash & archive installers); document upgrade rules and a rollback plan.
Strengths / Weak Points
Strengths
– Lean, familiar workflows for dental staff; quick charting and scheduling.
– Runs on modest hardware; simple to virtualize and back up.
– Open database enables reporting and ETL without black boxes.
– Plays well with external imaging stacks (e.g., Orthanc + Weasis).
Weak Points
– Feature parity varies by fork/build; governance depends on the community.
– No native AD/LDAP; access control lives inside the app.
– Limited first-party DICOM/CBCT tooling; relies on external viewers.
– Upgrades require discipline (schema diffs, template drift, API changes).
Why It Matters
Dental IT teams often need an EMR/PM core that is stable, comprehensible, and scriptable. OpenDentalFork fits that niche: it keeps the essentials—charting, scheduling, billing—while leaving imaging to purpose-built tools. In environments where cost control, data portability, and straightforward backups outrank glossy feature sets, the fork provides a workable center of gravity for a small dental network—practical, transparent, and easy to recover when things go sideways.
