How to Configure Tiered Letter Disposition in E-Office for Hospitals and Clinics
Single-level disposition can cause letters to stall for days. Learn how to build tiered disposition in E-Office: parent-child structure, routing rules, SLAs per tier, and automatic escalation.
Letters pile up on the secretariat desk, while the Head of Installation thinks the letter is still with the Director, and the Director thinks it has been forwarded to the Department Head. This condition commonly occurs in hospitals and clinics that have just moved physical letters to E-Office without designing a tiered disposition flow. From a small audit at a type C hospital with 12 work units in DIY, an average of 350 incoming letters per month was recorded, and 41% of them exceeded the internal SLA of 3 working days. The average waiting time was 4.7 days, with the highest point actually occurring at the second level, not the first level. The root cause is not the application, but the configuration: disposition is made one level, without parent-child relations, without deadlines per tier, and without escalation. This article discusses how to build neat tiered letter disposition in E-Office, from data structure to automatic escalation rules.
Concept of Tiered Disposition and Its Data Structure
Single-level disposition only answers the question "who reads this letter". Tiered disposition answers "who follows up on what, in what order, and within what time limit". Technically, each disposition sheet is one data row that points to the previous disposition row through the parent_id column. That chain forms the tiers: the initial recipient creates a disposition to the Head of Unit (level 1), the Head of Unit forwards to the Department Head (level 2), the Department Head forwards to the Director (level 3) with a copy to the Quality Committee.
The minimum table structure that needs to be prepared on MySQL 8 or PostgreSQL 14 is disposisi(id, surat_id, parent_id, dari_jabatan_id, ke_jabatan_id, level, status, instruksi, deadline, selesai_at). The level column should be calculated at insert, not manually input, to be consistent. Status uses a clear enumeration: new, read, processed, completed, rejected, and forwarded. Without explicit status, disposition compliance reports will always be ambiguous.
One thing that is often overlooked: tiered disposition does not mean it must be rigidly sequential. In many E-Offices, the Director needs to receive parallel copies without blocking the flow below. Therefore, separate the approval path (sequential) and copies (parallel, read-only). Store copies in a separate table disposisi_tembusan(disposisi_id, jabatan_id) so that the main chain query remains clean.
As an illustration, of 350 letters per month, about 60% only need two levels, 30% three levels, and 10% involve cross-units (for example, a BPJS letter that must stop by Casemix, Finance, then the Director). A good configuration allows these three patterns to coexist without data duplication.
Configuration in the E-Office Admin Panel: Practical Steps
Before touching the disposition menu, first fix the three master data that form its foundation. First, position master — distinguish structural positions (Department Head, Head of Installation) from functional positions (Doctor, Nurse, Pharmacist). Second, work unit master with an explicit superior-subordinate hierarchy. Third, user-to-position mapping, because one person at a type C hospital often holds two positions at once. Without correct mapping, routing rules will point to the wrong user.
The next step is to create a routing rule based on letter classification, not based on the sender's name. Example of a real rule: the classification "External Letter – Regulation" always goes to level 1 the relevant Head of Unit, level 2 the relevant Department Head, level 3 the Director; while "Internal Letter – Meeting Invitation" only level 1 and a copy to the Secretariat. Store this rule in the table routing_rule(klasifikasi_id, urutan, jabatan_id, sla_jam, is_tembusan). The table approach is much easier to audit than conditional logic embedded in code.
After the rules are ready, set the SLA per tier and delegation mechanism. Practical recommendation: level 1 gets 1 working day (8 hours), level 2 gets 2 working days (16 hours), level 3 gets 1 working day. Delegation must have a start and end date — do not use permanent delegation, because BPJS audits and accreditation usually question who signed on a certain date. Finally, enable layered notifications: email when a disposition comes in, a reminder on D-1 before the deadline, and escalation to the direct superior when the deadline is passed.
Validating the Disposition Chain with Recursive Queries
After the configuration runs, do not immediately trust the UI display. Validate chain integrity with a recursive query, because the most common problem is a disposition whose parent_id points to a different letter, or a chain that breaks in the middle so the letter stops without a clear status. Run the following query on a database copy before go-live.
WITH RECURSIVE rantai AS (
SELECT id, surat_id, parent_id, ke_jabatan_id, level, status, 1 AS urutan
FROM disposisi WHERE surat_id = 1024 AND parent_id IS NULL
UNION ALL
SELECT d.id, d.surat_id, d.parent_id, d.ke_jabatan_id, d.level, d.status, r.urutan + 1
FROM disposisi d JOIN rantai r ON d.parent_id = r.id
WHERE d.surat_id = r.surat_id
)
SELECT urutan, level, ke_jabatan_id, status
FROM rantai ORDER BY urutan;
If the result stops before the expected last level, it means there is a row that failed to be created — usually because the user in that position is inactive. For escalation scheduling, the Laravel 10 scheduler (php artisan schedule:work) with a daily job at 07:30 is sufficient; avoid per-minute cron that burdens the E-Office database, which usually runs on one server with SIMRS.
Best Practices
- Calculate
levelanddeadlinein the application; do not let users fill them in manually — the main source of dirty data is free-form input. - Apply idempotency when creating dispositions: one letter may only have one root disposition (
parent_id IS NULL), constrained by a unique index. - Separate the sequential approval path from parallel copies into different tables so SLA reports are not distorted.
- Create a weekly compliance dashboard containing the number of overdue dispositions per unit, and review it in management meetings.
- Test negative scenarios before go-live: a user resigning in the middle of the chain, an expired delegation, and a letter with two classifications at once.
FAQ
Must tiered dispositions be strictly sequential?
No. Only the approval path must be sequential. Copies, information, and coordination should be parallel so a letter is not held up just because one party has not read it yet.
What is the ideal SLA per disposition level?
For hospitals and clinics, 8 hours for level 1, 16 hours for level 2, and 8 hours for level 3 are realistic. Measure a 2-week baseline first before setting the final numbers.
How should officials on leave or transferred be handled?
Use the date-limited delegation feature, not permanent user replacement. During a transfer, deactivate the user-position mapping and route ongoing dispositions to the new official through a reallocation process.
Can this configuration be applied to older versions of E-Office?
Yes, as long as the disposition table can still have columns parent_id, level, and deadline added. If that is not possible, create a companion table and synchronize it via triggers or a scheduled job.
A correct tiered disposition configuration turns E-Office from merely a digital archive into an operational control tool: every letter has a clear owner, deadline, and audit trail. If your IT team is preparing E-Office, SIMRS, SIM Klinik, or BPJS/SatuSehat integration and needs technical assistance, we provide IT consulting and application development for the Yogyakarta (DIY) and Magelang, Central Java areas — including correspondence configuration audits, routing rule design, and implementation of automatic escalation integrated with existing systems.
This article is part of the knowledge base of Nugroho Setiawan, an IT consultant in Jogja (Yogyakarta). Related solutions: Clinic Management System BPJS & SatuSehat Integration E-Office. Need a free consultation?
Komentar
Belum ada komentar. Jadilah yang pertama!
Saya membantu konsultasi IT & pengembangan aplikasi untuk rumah sakit, klinik, dan bisnis di Yogyakarta (DIY), Magelang, dan sekitarnya.