hospital-management/current_prompt.md

Agent Instructions:
You are a senior Django architect and full-stack developer. This is a very large, mission-critical project—do not dump all code at once. Follow this strict phased plan-and-approve workflow to minimize hallucination and ensure accuracy:

Phase 1 – Planning

1. Produce a high-level outline of every app/module, its responsibilities, and the key models, views/endpoints, HTMX interactions, Celery tasks, HL7 and DICOM/PACS interfaces, AI analytics hooks, and compliance/multitenancy considerations.
2. Pause and wait for my confirmation before proceeding.

Phase 2 – Scoping & Approval (per app)
For each confirmed app (one at a time):

1. List all models, fields, relationships, and choice enums in full detail.
2. List required UI views (with HTMX attributes) and REST API endpoints/URLs.
3. List any Celery tasks, HL7/DICOM integration points, IoT hooks, and AI rule triggers.
4. Pause and wait for my “👍 go ahead with [app_name]” before generating any code.

Phase 3 – Implementation (per app)
When I approve an app:

1. Generate models.py for that app only.
2. Pause for my review and approval.
3. Generate serializers.py and/or forms.py, then pause for review.
4. Generate views.py, templates/, and any necessary HTMX snippets, then pause for review.
5. Generate static asset scaffolding (SASS partials, HTMX/JS modules) and pause for review.

Phase 4 – Shared Tooling & Final Integration
After all apps are complete:

1. Generate Webpack (or Django-Webpack-Loader) setup, SCSS/JS bundling, and django-compressor config.
2. Generate Celery configuration with Redis broker and example tasks (including HL7/DICOM polling, IoT data ingestion, AI analytics jobs).
3. Generate the hl7_interface and pacs_interface apps: models, utilities, management commands, and Celery tasks for HL7 v2.x and DICOM messaging.
4. Generate DRF API docs (Swagger) config, pytest setup, and GitHub Actions CI workflow.
5. Generate example Gunicorn + Nginx deployment snippets with multitenancy and SSL/TLS, and notes on GDPR/HIPAA compliance (encryption at rest, audit logs, consent management).
6. Provide a comprehensive README covering:
   • Python virtualenv setup
   • npm install && npm run build
   • manage.py migrate, superuser setup
   • ColorAdmin license integration
   • HTMX usage guidelines
   • HL7/DICOM endpoint configuration
   • IoT device onboarding
   • AI risk-scoring configuration
   • Multitenancy setup
   • Compliance controls (2FA, encryption, consent capture)

---

Project Specification
Project name: hospital_management
UI theme: ColorAdmin template (all CSS/JS centralized—no inline or per-template scripts/styles)
Dynamic behavior: HTMX for all interactive features
Messaging: Optional inbound/outbound HL7 and DICOM/PACS interfaces
Analytics: AI-driven predictive risk scoring hooks in decision_support
Security & Compliance:

• Two-factor authentication, encryption at rest, GDPR/HIPAA audit trails
• Consent management, digital signatures, detailed audit logs
• Tenant-scoped data isolation for multi-hospital support

Apps, Models & Fields

1. accounts

   • User (extends AbstractUser): username, email, first_name, last_name, password, role (choices: Admin, Doctor, Nurse, LabTech, Pharmacist, Receptionist, Patient, EMS), is_active, date_joined, tenant
   • TwoFactorDevice: user FK, device_type, secret_key, confirmed
   • SocialAccount (django-allauth)

2. core

   • AuditLogEntry: user FK, action, timestamp, object_type, object_id, change_detail
   • HL7Utility & DICOMUtility modules (no models; parsing/building functions)

3. patients

   • PatientProfile: user FK (Patient), medical_record_number, date_of_birth, gender, blood_type, allergies (text), address, phone, emergency_contact FK, insurance_info FK
   • EmergencyContact: patient FK, name, relationship, phone, email
   • InsuranceInfo: patient FK, provider, policy_number, group_number, coverage_start_date, coverage_end_date
   • ConsentForm: patient FK, form_type, document (FileField), signed_at, signed_by FK

4. appointments

   • AppointmentRequest: patient FK, doctor FK, department, requested_datetime, status (Pending/Confirmed/Cancelled), created_at, updated_at
   • SlotAvailability: doctor FK, date, start_time, end_time, is_available
   • WaitingQueue: appointment FK, position, created_at
   • VirtualCare scheduled via TelemedicineSession: patient FK, provider FK, session_url, start_time, end_time, status

5. inpatients

   • Ward: name, floor, capacity, department
   • Bed: ward FK, bed_number, bed_type (choices: General/ICU/Private), status
   • Admission: patient FK, ward FK, bed FK, admitted_at, admitted_by FK, reason, status
   • DischargeSummary: admission FK, summary_text, discharged_at, discharged_by FK
   • Transfer: admission FK, from_ward FK, to_ward FK, transferred_at, reason
   • SurgerySchedule: patient FK, surgeon FK, or_block FK, scheduled_at, duration, status

6. emr

   • Encounter: patient FK, encounter_date, provider FK, encounter_type, notes
   • VitalSigns: encounter FK, recorded_at, temperature, heart_rate, bp_systolic, bp_diastolic, respiratory_rate, oxygen_saturation
   • ProblemList: patient FK, description, onset_date, status, notes
   • CarePlan: encounter FK, goal, interventions, status
   • ClinicalNote: encounter FK, note_type, content, created_at, created_by FK

7. billing

   • Invoice: patient FK, date_issued, due_date, total_amount, status
   • ChargeItem: invoice FK, description, code, quantity, unit_price, total_price
   • Payment: invoice FK, amount, method, paid_at, transaction_id
   • InsuranceClaim: invoice FK, claim_number, status, submitted_at, adjudicated_at

8. pharmacy

   • Medication: name, code, description, unit, dosage_form
   • Prescription: patient FK, prescriber FK, prescribed_at, status
   • DispenseRecord: prescription FK, medication FK, quantity, dispensed_at, dispenser FK
   • StockItem: medication FK, batch_number, expiration_date, quantity_on_hand, minimum_threshold

9. laboratory

   • LabTest: name, code, description, specimen_type, department
   • Specimen: lab_test FK, patient FK, collected_at, collected_by FK, status
   • Result: specimen FK, result_value, units, reference_range, result_date, verified_by FK
   • LISIntegrationLog: message_id, direction, payload, status, processed_at

10. radiology

    • RadiologyOrder: patient FK, imaging_type, ordered_by FK, order_date, priority, status
    • ImagingStudy: order FK, modality, study_date, images_count, report_status
    • RadiologyReport: study FK, report_text, dictated_by FK, dictated_at, approved_by FK, approved_at
    • DICOMStudy: study_instance_uid, patient_fk, modality, study_date, series_data (JSON)

11. inventory

    • SupplyItem: name, sku, description, category, unit, reorder_level, location
    • PurchaseOrder: supplier FK, order_date, expected_date, status, total_amount
    • StockTransaction: item FK, transaction_type, quantity, transaction_date, reference

12. decision_support

    • CDSSRule: name, trigger_event, condition_expression, action, active
    • AlertLog: rule FK, patient FK, triggered_at, message, status
    • AI hooks: risk_scoring_config (JSON), last_run, score_thresholds

13. reporting

    • CustomReport: name, description, owner FK, query_definition (JSON), created_at, updated_at
    • DashboardWidget: name, report FK, widget_type, settings (JSON), position

14. hl7_interface

    • HL7Endpoint: name, host, port, protocol, is_active, last_checked
    • HL7MessageLog: endpoint FK, direction, message_type, raw_message, parsed_message, sent_at, received_at, status

15. pacs_interface

    • PACSConnection: name, ae_title, host, port, is_active
    • PACSLog: connection FK, direction, dicom_uid, raw_payload, processed_at, status

16. operating_theatre

    • ORBlock: name, theater_number, department, available_slots (JSON)
    • EquipmentReservation: device FK, or_block FK, reserved_from, reserved_to, status

17. assets

    • MedicalDevice: name, serial_number, category, location, status, last_maintenance
    • MaintenanceLog: device FK, performed_at, performed_by FK, notes
    • IoTSensorReading: device FK, timestamp, data (JSON)

18. ems

    • DispatchRequest: caller_info, location, priority, status, created_at
    • Ambulance: identifier, capacity, status, location
    • CrewMember: user FK, ambulance FK, role
    • TripLog: dispatch FK, ambulance FK, start_time, end_time, patient_fk

19. nutrition

    • MealPlan: patient FK, date, meals (JSON), dietary_restrictions
    • DietaryOrder: patient FK, meal_type, order_time, status
    • KitchenTask: plan FK, task_description, assigned_to FK, status, completed_at

20. security

    • EncryptionKey: key_name, key_type, created_at, rotation_date
    • AuditLogEntry (enhanced for GDPR/HIPAA as above)

---

Shared Tooling, Interactivity & Deployment

• Assets: SCSS in assets/scss/ → static/dist/main.css; JS in assets/js/ → static/dist/main.js via Webpack + Babel; django-compressor for compression.
• HTMX: All dynamic features use hx-* attributes—no per-template JS.
• API: DRF ModelViewSets under /api/v1/, secured with JWT/OAuth2, Swagger UI at /api/docs/.
• Background: Celery+Redis for notifications, HL7/DICOM messaging, IoT ingestion, AI scoring.
• Testing/CI: pytest + GitHub Actions for lint/test/build.
• Deployment: Gunicorn+Nginx configs, multitenancy notes, SSL/TLS, GDPR/HIPAA compliance checklist, 2FA setup, consent management, and monitoring guidance.

Ensure phased execution and strictly pause for approvals at each step. Good luck!