Clinical Admin Platform (CAIMS)
Healthcare Administration · R Shiny · SQLite · RBAC · Burkina Faso
Case Study # Clinical Admin Platform (CAIMS)
Healthcare Administration · Burkina Faso · R Shiny Enterprise Application
✓ Live Deployment ✓ RBAC + MFA ✓ Full Audit Trail ✓ SQLite Backend
Platform at a Glance
4 User Roles (RBAC)
3 Core Modules
100% Audit Trail Coverage
∞ Timestamped Records
1. Problem Statement
A Burkina Faso healthcare-affiliated institution required a structured, auditable system for managing clinical administrative functions — replacing a combination of Excel workbooks and paper-based records that created data integrity risks, duplicated effort, and produced no reliable audit trail.
The institution needed: - Centralised patient/client records accessible across multiple clinical roles - Appointment and scheduling management with conflict detection - Role-appropriate access (clinician, admin, manager, viewer) - A full audit trail of every data entry, edit, and deletion - PDF report generation for institutional administration
2. Solution Architecture
CAIMS (Clinical Administration and Information Management System) is a modular R Shiny application with an embedded SQLite database, deployed on shinyapps.io with RBAC and MFA.
2.1 Technology Stack
| Component | Technology | Purpose |
|---|---|---|
| Application | R Shiny + bslib | Reactive UI and server logic |
| Database | SQLite via DBI / RSQLite | Embedded data persistence |
| Connection Management | pool | Multi-user connection pooling |
| Tables | DT | Interactive, filterable data tables |
| Reporting | R Markdown + LaTeX | PDF administrative report generation |
| Authentication | Custom RBAC + TOTP MFA | Role-based access and MFA |
| Deployment | shinyapps.io | Production hosting |
2.2 Modules
📋 Records Module
Centralised client/patient record management with structured data fields, search and filter, and full edit history maintained via created_by / updated_by / timestamped audit columns.
📅 Scheduling Module
Appointment booking with conflict detection, calendar view, status tracking (booked / confirmed / completed / cancelled), and automated availability checks across practitioners and rooms.
📄 Reporting Module
Automated PDF report generation via R Markdown and LaTeX — daily appointment sheets, client activity summaries, and administrative audit reports exportable on demand.
2.3 Security Architecture
- 4-tier RBAC: Admin (full platform access and user management), Clinician (record creation and scheduling), Admin Staff (scheduling and report access), Viewer (read-only dashboards)
- TOTP-based MFA on all accounts with QR code enrollment
- Parameterised SQL throughout — no string interpolation in database queries
- Environment-variable credential management — no secrets in source code
- Full audit log: every INSERT, UPDATE, and DELETE timestamped with user reference
3. Outcomes
✅ Operational Outcomes
- Centralised authoritative record system replacing Excel and paper
- Conflict detection eliminating double-booking (previously a recurring issue)
- Automated report generation replacing manual spreadsheet assembly
- Single-screen daily schedule view for all practitioners
🔒 Governance Outcomes
- Full audit trail on every data record — timestamp, user, action
- Role-appropriate access preventing clinical staff from accessing administrative data
- MFA enforcement on all accounts
- PDF reports replacing ad-hoc manual documents for institutional administration
4. Lessons Learned
Connection pooling is essential from Sprint 1 in multi-user clinical environments. With multiple practitioners accessing records simultaneously, SQLite without pool produced connection errors. Minimum pool size of 2, maximum of 8, resolved all concurrent-access issues.
Scheduling conflict logic requires a dedicated data model. Appointment conflict detection cannot be done reliably in application logic alone — it requires a well-designed database schema with indexed time ranges and a consistent booking-status field. The schema was redesigned in Sprint 3 to address edge cases in recurring appointment patterns.
PDF report layouts need institutional sign-off before build. Clinical report formats are regulated by institutional policy. BRASS now requires layout approval before the reporting module build begins.