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!