Clinic Operations Platform
I built a clinic operations platform connecting appointment management with inventory, invoicing, and financial reporting for home visits, clinics, and corporate services.
I worked directly with the client to define requirements, design and build the application from scratch, and handle deployment and ongoing support.
- MY ROLE
- Web Application Developer
- PROJECT STATUS
- Client project
Client names and website links are withheld for confidentiality. Project titles are descriptive.
My role
Worked directly with the client to define operational requirements and design the application.
Built the Ruby on Rails and PostgreSQL application, covering appointments, inventory, invoicing, doctor commissions, and reporting.
Handled deployment on AWS using Docker and Kamal, followed by ongoing support and improvements.
Development process
- Research & technology selection
- System design
- Development
- Testing & optimization
Key features
Appointments and service delivery
Home visits, clinic appointments, and corporate services, with support for multiple patients, services, and follow-up visits.
Inventory and logistics
Stock reservations, stock requests, and delivery notes across partners, warehouses, and pharmacies.
Payments and costs
Invoice-service integration, manually recorded payments, doctor commissions, service costs, and financial reports.
Access and reporting
Role-based access for operational teams, with dashboards and downloadable reports.
Technical details
- Core stack
- Ruby on Rails · PostgreSQL
- Frontend
- HTML · CSS · JavaScript · Hotwire · Tailwind CSS · Flowbite
- Infrastructure
- AWS · Docker
- Deployment
- Kamal
The application uses AWS and Docker, with Kamal for deployment. My responsibilities also include ongoing support and improvements.
The interface combines Tailwind CSS and Flowbite components. Turbo and Stimulus handle interactive updates, while ViewComponent organizes reusable Rails views.
Separate appointment and payment states
Appointment progress and payment status are tracked independently. Ticket totals are recalculated when relevant data changes, rather than on every save.
Stock planning and allocation
Stock needs are calculated separately from stock reservation. Allocation follows the service type and can reserve stock for all remaining doses in a course.
Domain-specific service objects
Ticketing, stock, and invoicing actions use dedicated service objects with a consistent result format for success status, data, and errors.
Workflow testing
Tests cover payments, stock, permissions, and reports. Selected tasks run as background jobs.
Diagram
This diagram explains the project’s structure. It is not a screenshot of the original application.