Bug #713
openConsultation Screen Should Be Reworked Per Department
0%
Description
Summary
The OPD consultation screen currently appears to be a single, generic layout used the same way across every department, regardless of how that department actually practices. The ask is to rework the consultation screen so it is reworked/configured per department — each department getting the sections, fields and patient-handling model that fit its own clinical workflow, rather than one generic screen for all departments. Fertility/IVF needing a couple-level (husband + wife as one unit) consultation view, reported separately, is one concrete example of this broader gap.
Impact
A one-size-fits-all consultation screen forces doctors in specialised departments to work around a generic form that doesn’t match their actual clinical process — either leaving irrelevant fields unused, or lacking fields, sections or record-linking that their specialty actually needs. This slows consultations down, risks department-specific data not being captured anywhere in the system, and pushes doctors toward workarounds (paper notes, manually cross-referencing separate patient records, as in the Fertility case) instead of the system supporting how they actually work.
Environment
Clinq HMS, OPD Consultation screen, across departments. General observation by description; not yet tied to a specific tenant or walked through live department-by-department.
Steps to Reproduce
Current behavior (not a crash, a design gap): 1. Open an OPD consultation under one department (e.g. General Medicine). 2. Open an OPD consultation under a different, clinically distinct department (e.g. Fertility/IVF, Obstetric & Gynaecology). 3. Observe that the consultation screen’s layout, sections and fields are the same in both cases, regardless of how different the two departments’ actual clinical workflows are.
Expected vs Actual
Expected: The consultation screen should be reworked/configurable per department, so each department’s doctors see sections, fields and patient-handling (such as linked-patient/couple handling for Fertility) suited to their own clinical workflow, instead of one generic form used everywhere.
Actual: All departments currently appear to use the same consultation screen, with no department-specific layout or workflow differences.
Notes
This is a design/enhancement request rather than a defect — the generic consultation screen is working as built, it just isn’t tailored per department. Flagging this since it’s a gap rather than broken behaviour.
This is the broader, general version of the earlier report “Fertility Department Needs a Couple-Level Consultation Screen,” which is one specific, already-described example of this gap (Fertility/IVF needing a couple-unit view). That report should be treated as the first concrete spec under this larger direction, not a separate, unrelated item.
S- Updated by SK - 4 days ago
Triaged (2026-11-09), not resolved. This is the same cluster as #712, #687 and #654 - this ticket is the generalized reframe of the Fertility couple-consultation gap, and it says so itself ("reported separately, is one concrete example of this broader gap"). Confirmed via code check (see #712's note) that no per-department consultation configuration exists today - the OPD consultation screen is generic, with only the existing Obstetric & Gynaecology tab as a department-specific variant. Fertility has none.
Parked per the user's call, to be scoped together with #712/#695/#687/#654 via a brainstorm/spec session rather than piecemeal. Left assigned to SK, status unchanged.
S- Updated by SK - 3 days ago
- Status changed from New to Resolved
- Assignee changed from SK - to Roshni Harish.
- Resolved By set to SK -
Closing as satisfied: the consultation screen already has a per-department rework mechanism, the CONSULTATION_MODULES registry in nuvita-opd (apps/portal/src/lib/consultation-modules.ts) - adding a tab for a department is a one-entry addition, not a new framework. The Obstetric & Gynaecology tab was the first concrete example; the new Fertility tab (#687, shipped on dev) is the second. No general-purpose work remains for this ticket; any future department needing its own consultation content follows the same pattern.