This is a case study about a management system for a network of multi-specialty medical centres. By agreement with the client we do not name the company and do not publish screens showing personal data of patients, staff or enquiries. Everything below is architecture and mechanics, not someone else's data.
The problem
A medical centre network runs four different worlds at once: acquisition and scheduling, clinical care, staffing and finance. Usually they drift apart across three spreadsheets and a messenger. Marketing does not know whether an enquiry ever became an appointment. A branch manager cannot see nursing workload. A physician keeps prescriptions in a personal file. And the owner learns about an unprofitable month after it has closed.
Being multi-specialty amplifies every one of these gaps. Therapy, rehabilitation, diagnostics, psychology and dietetics follow different protocols, with different appointment lengths and different specialist hourly costs. A single generic booking record cannot express that difference.
What the first phase covers
- Centres and places: branches, rooms, day and inpatient places, patient placement;
- CRM and admission: enquiries, events, statuses, the enquiry-to-patient transition;
- HRM: candidates, employees, qualifications, shift schedule and workload;
- Individual care plan: needs, severity degrees, prescriptions and the staff tasks they generate;
- Contracts: contract, annex, payer type and printable documents;
- Management and P&L: dashboard, plan versus actual, revenue and costs.
The core: turning an assessment into a work schedule
The most substantial part of the project is neither the patient card nor the calendar. It is the chain that links a person's condition to concrete tasks for concrete specialists.
Clinical condition is described by need tables. The production configuration holds sixteen of them, containing ninety-six individual needs: mobility, nutrition, cognitive status, fall risk, pain and so on.
Every need has severity degrees: two hundred and seventeen in the reference book. A degree carries a score and belongs to a level group: low, moderate, high, critical. That replaces a subjective "this patient is difficult" with a reproducible scale.
Then comes the recommendation layer: three hundred and forty-nine rules of the form "this degree of this need requires this prescription". It is what turns an assessment into a plan: the system proposes prescriptions with priority and a mandatory flag, and the physician accepts or rejects them.
Prescriptions come from a catalogue of medical and service actions: one hundred and seventy-four entries, each with its own duration in minutes, cost, individual-or-group flag and frequency rule.
Who is allowed to perform a prescription
The action catalogue is linked to a qualifications reference: twenty-one of them, from junior nurse to physician. The system holds one hundred and four action-to-qualification links, each with two parameters: whether the qualification is mandatory and the minimum experience in months.
The system will not schedule a procedure for someone not entitled to perform it. Each scheduled task also stores the reason it was assigned, so six months later nobody has to guess why a patient received that particular procedure.
The care plan as a document, not a task list
The individual plan is a versioned document: version number, validity period, goal and expected outcome, mandatory review date, total assessment score and two signature marks: from the service recipient and from the provider, with an attached file.
Where the money is
Every scheduled task carries planned and actual cost, planned and actual duration. Every employee carries a rate and an employment type. Every branch carries capacity and additional costs. P&L is assembled from these fields continuously, from work actually performed, rather than at month end.
The contract holds payer type, price per day and price per contract, prepayment, discount percentage and signed/paid marks. Self-payers, insurers and corporate clients are served by one model.
The role model as a product, not a checkbox
The system has twelve roles: superadministrator, director, system administrator, owner, centre administrator, HR manager, marketer, physician, nursing staff, accountant, investor and candidate.
A role limits pages and actions, while the branch binding limits visible business objects. A physician sees the clinic and not the P&L; HR sees staff and not patients. The single source of truth about what each role sees is covered by an automated test.
From candidate to employee
The employment form is open to guests. The candidate goes through an interview, and on hiring a single transaction activates the employee profile, records the hire date, binds them to a branch and replaces the access role. The employee also carries a qualification, the same one the system uses to decide which prescriptions may be scheduled for them.
Built-in training
Every signed-in user has a training button in the header. It opens instructions for their specific role. A test verifies that every role has instructions and that every step leads only to a screen that role can reach.
Production security
The service gateway exposes only actions from an explicit registry, each with its own list of roles and permitted HTTP methods; mutating actions are accepted only via POST with a CSRF token. Developer tools are disabled in production and blocked in robots.txt. The database is on the mandatory backup list and is snapshotted every three hours.
Next step
This architecture transfers to any network with sites, staff and people in care: multi-specialty clinics, rehabilitation and diagnostic centres, sanatoriums, dental chains. We start with a role map and one end-to-end scenario: from enquiry to a closed shift.
Where to see it
The project has no public address: it runs locally or in a closed environment. We show it in a scheduled demonstration.
A similar solution: platFORMA - an advanced system for your company's departments.
