marwan/hospital-management
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
hospital-management/motamarat_project.md
Marwan Alwali 263292f6be update
2025-11-04 00:50:06 +03:00

9.1 KiB
Raw Permalink Blame History

Prompt for Django Agent – Motamarat Project

Objective

Develop a complete Django-based system for managing CME/CPD activities, requests, approvals, and registry workflows in alignment with the Motamarat Project BRD. The solution should include full backend (Django + DRF) implementation, frontend templates using ColorAdmin, and workflow automation based on roles and statuses.

1. Project Overview

The Motamarat Project is a CME/CPD management and accreditation system designed for hospital educational departments. It manages:

  • Requests for CME/CPD activities.
  • Multi-level approvals (Department → CME Head → Specialist → Coordinator → Requester).
  • Conversion of approved requests into accredited CPD Activities.
  • Scientific programs, speaker management, financial forecasting, and attendance tracking.
  • Integration with Mustamir, SCFHS, and Motamarat for accreditation and announcement.

2. App Structure

Create three main Django apps:

  1. cme_requests – for activity requests and approval workflows.
  2. cpd_registry – for accredited activities and their detailed management.
  3. cme_plans – for yearly planning and pre-approved activities per CoE.

A shared core_cme app may contain reusable models, enums, mixins, and integrations.

3. Implementation Sequence

Follow this exact order when generating the project:

  1. models.py
  2. signals.py (if needed)
  3. utils.py (for validation, workflow logic, integrations)
  4. forms.py
  5. views.py
  6. urls.py
  7. Templates list
  8. DRF layer (serializers.py, api_views.py, routers & urls)

4. Core Models (models.py)

4.1 Common Models

  • TimeStampedModel, SoftDeleteModel – abstract base classes.
  • ChoiceEnums – include enums for event types, delivery methods, languages, status, sub-status, sites, etc.
  • Lookup Tables – Country, City, Specialty, TargetAudience, Department, SubDepartment, etc.

4.2 CME Requests

CMEActivityRequest

  • request_number (unique)
  • requester (FK User)
  • title_ar, title_en
  • event_type, is_repeated, repeated_accreditation_no
  • aims_outcomes, goals_objectives (JSON, list ≤50 words)
  • learning_methods, evaluation_method
  • professional_fields, target_audiences (M2M)
  • learning_gap, needs_assessment_tools
  • specialty, subspecialty, language, other_language
  • proposed_date, remarks
  • international_speakers (Yes/No + count 1–20)
  • location (country, city, venue_type, capacity)
  • delivery_method, estimated_expenses, estimated_income
  • collaboration details, attachments
  • workflow fields: status, sub_status, assigned_to

4.3 Approvals

  • DepartmentApproval (FK request, approver, decision, comment)
  • CMEHeadReview (FK request, editor, JSON of changes, added_approvers)
  • AdditionalApproval (FK request, approver, decision, comment)
  • CMECoordinatorProcess (conference date reservation, Mustamir payload)
  • RequesterDateApproval (decision, comment)
  • RequestAttachment (FK request, file, type)

4.4 CPD Registry

CPDActivity

  • category, date_of_event, scfhs_request_no, accreditation_no
  • status (Approved/Rejected/Cancelled)
  • hours, motamarat_status, announcement_status
  • request_number, requester_name, request_date
  • committee_chairman, duration_days (1–5), assigned_to, site
  • comments, timestamps

OrganizingCommitteeMember, Speaker, ScientificProgramItem, FinancialForecast, AnnouncementRequest, AttendanceBatch, Attendance

Each sub-model should include validation and relationships per BRD.

4.5 CME Plans

CMEPlanSubmission – yearly CoE submissions. CMEPlannedEvent – nested planned events under a submission.

5. Signals (signals.py)

  • Auto-generate request_number on save.
  • Validate 6-week rule for proposed_date.
  • Send email notifications for each step transition.
  • On completion, auto-create CPDActivity from CMEActivityRequest.
  • When accreditation_no or hours are added → notify requester.
  • On speaker finalization → send info email.

6. Utils (utils.py)

Submodules:

  • choices.py – all enumerations.
  • validators.py – 6-week rule, ranges, conditionals.
  • workflow.py – finite-state transitions.
  • finance.py – budget and net distribution logic.
  • integrations.py – API stubs for Mustamir, SCFHS, Motamarat.
  • emails.py – templated notifications.

7. Forms (forms.py)

Create Django forms for each model with conditional fields and validation logic:

  • CMEActivityRequestForm
  • DepartmentApprovalForm, CMEHeadReviewForm, AdditionalApprovalForm
  • CMECoordinatorConferenceForm, RequesterDateApprovalForm, EventConfirmForm
  • CPDActivityForm, SpeakerForm, ScientificProgramForm
  • FinancialForecastFormset, AnnouncementForm, AttendanceForm
  • CMEPlanSubmissionForm, CMEPlannedEventForm

8. Views (views.py)

CME Requests App

Use Django CBVs:

  • Create, List, Detail, Update views for requests.

  • Workflow actions as separate form views:

    • SubmitRequestView
    • DepartmentApprovalView
    • CMEHeadReviewView
    • AdditionalApprovalView
    • ConferenceDateConfirmView
    • RequesterDateApprovalView
    • EventConfirmView
    • CompleteRequestView (creates CPDActivity)

CPD Registry App

  • Manage CPDActivity and related objects (committee, speakers, program, finances, announcement, attendance).
  • Actions: send to Motamarat, speaker emails, attendee reminders.

CME Plans App

  • CRUD for CMEPlanSubmission.
  • HeadReviewView, SpecialistDesignView, CompletePlanView.

9. URLs (urls.py)

CME Requests

requests/
requests/new/
requests/<pk>/submit/
requests/<pk>/approve/
requests/<pk>/review/
requests/<pk>/conference-date/
requests/<pk>/complete/

CPD Registry

activities/
activities/<pk>/speakers/
activities/<pk>/program/
activities/<pk>/finances/
activities/<pk>/announcement/
activities/<pk>/attendance/

CME Plans

plans/
plans/<pk>/review/
plans/<pk>/design/
plans/<pk>/complete/

10. Templates

Organize templates under respective apps:

cme_requests

  • request_form.html
  • request_detail.html
  • request_list.html
  • dept_approval.html
  • head_review.html
  • additional_approval.html
  • conference_date.html
  • requester_date.html
  • event_confirm.html
  • request_timeline.html

cpd_registry

  • activity_list.html
  • activity_detail.html
  • speakers.html
  • program.html
  • finances.html
  • announcement.html
  • attendance.html
  • certificate.html

cme_plans

  • plan_form.html
  • plan_list.html
  • plan_detail.html
  • plan_review.html
  • plan_design.html

Include shared email templates under emails/.

11. DRF Layer

serializers.py

  • CMEActivityRequestSerializer (nested approvals)
  • DepartmentApprovalSerializer, CMEHeadReviewSerializer, etc.
  • CPDActivitySerializer (nested models)
  • SpeakerSerializer, ScientificProgramSerializer, FinanceSerializer
  • AnnouncementSerializer, AttendanceSerializer
  • CMEPlanSubmissionSerializer, CMEPlannedEventSerializer

api_views.py

Implement ViewSets with custom workflow actions:

  • CMEActivityRequestViewSet – handles submission & approval steps.
  • CPDActivityViewSet – handles registry and notifications.
  • CMEPlanSubmissionViewSet – handles plan reviews.
  • LookupViewSet – provides dropdown data.

routers & urls

router.register('requests', CMEActivityRequestViewSet)
router.register('activities', CPDActivityViewSet)
router.register('plans', CMEPlanSubmissionViewSet)
router.register('lookups', LookupViewSet)

Use nested routers for committee/speakers/programs/attendance.

12. Integration Points

  • Mustamir API – for submission and status tracking.
  • Motamarat API – for event announcement.
  • SCFHS API – for accreditation status and CME hours.
  • Email/Notification Service – for workflow communication.

13. Automation & Validations

  • Enforce 6-week lead time before event.
  • Conditional field rendering in templates and API.
  • Auto emails at workflow transitions.
  • Auto creation of CPDActivity after final approval.
  • Attendance reminders (D-1 and event day 06:30).

14. Deliverables

  • Django project scaffold with modular apps.
  • DRF API endpoints with nested routes.
  • Admin panel customization for each model.
  • ColorAdmin templates for all forms and lists.
  • Email notification system integrated via Celery.
  • Integration stubs for external systems.
  • Documentation for setup and environment variables.

15. Environment & Dependencies

  • Django 5.x, DRF 3.15+
  • PostgreSQL
  • Celery + Redis (for async tasks)
  • django-filter, drf-nested-routers
  • requests (for integrations)
  • ColorAdmin theme for frontend

16. Testing & QA

  • Unit tests for models, serializers, and views.
  • Workflow integration tests.
  • API tests for each endpoint.
  • Validation of lead time, financials, and conditional rules.

17. Expected Outcome

The agent should generate a fully functional Django + DRF project implementing all workflows, validations, and integrations described above. The system must be modular, production-ready, and compliant with the BRD's described business logic for the Motamarat Project.