Clinical care

Resource Request

ResourceRequest represents an inter-facility request for a resource and tracks it from the originating facility through approval and assignment. You touch it whenever a facility needs something another facility can provide. The Django model is…

3.1 · versioned documentation · 6 min read

ResourceRequest represents an inter-facility request for a resource (transfer, supply, or assistance) and tracks it from the originating facility through approval and assignment. You touch it whenever a facility needs something another facility can provide.

The Django model is only storage: status, category, and priority are open CharField/IntegerField columns with no model-level choices. The Pydantic resource specs give the fields their shape — pinning them to enums, running validation, resolving foreign keys, and splitting the read and write schemas.

Sources:

• Model: care/emr/models/resource_request.py
• Spec: care/emr/resources/resource_request/spec.py

Models

Both extend EMRBaseModel, the shared MANSOQ EMR base that adds external_id, audit fields (created_by, updated_by, created_date, modified_date), and soft-delete semantics.

ResourceRequest fields

Facilities

Request details

Referring contact

Assignment & patient

Enum values

The spec layer pins status and category to string enums defined in spec.py. The Django columns are plain CharFields, so these values hold only through the API — anything written directly to the database bypasses them.

StatusChoices values

CategoryChoices values

Resource specs (API schema)

Every spec builds on EMRResource (base.py), which supplies serialize (DB object → pydantic, the read path) and de_serialize (pydantic → DB object, the write path), plus the perform_extra_serialization / perform_extra_deserialization hooks. __exclude__ names the fields the base (de)serializer skips, leaving them to be handled by hand — FK resolution, for instance.

ResourceRequest specs

There is no separate UpdateSpec. ResourceRequestCreateSpec covers both create and update, branching on the is_update flag.

Validation

• validate_assigned_to_user (model validator, mode="after"): once assigned_to is set, assigned_facility becomes required, and the assigned user must be a member of that facility (checked via FacilityOrganizationUser). Either gap raises ValueError.

Server-side behaviour (perform_extra_deserialization)

• origin_facility external id → Facility object, only on create (is_update false). It is never reassigned on update.
• approving_facility, assigned_facility, assigned_to external ids → their DB objects whenever present, on create or update.
• related_patient external id → Patient object, only on create.
• Every lookup uses get_object_or_404 on external_id, so an unknown id returns 404.

Read serialization (perform_extra_serialization)

• id is emitted as the string external_id.
• origin_facility (and assigned_facility, approving_facility where present) are inlined via FacilityReadSpec.
• related_patient via PatientListSpec; assigned_to via UserSpec, resolved from cache (model_from_cache keyed on assigned_to_id).
• created_by / updated_by come from serialize_audit_users.

ResourceRequestComment specs

Related models

ResourceRequestComment

A comment entry on a resource request. The FK uses PROTECT, so deleting a comment leaves the request untouched.

request → FK ResourceRequest (PROTECT, required)
comment → TextField (default "")

Methods & save behaviour

• Read path: <Spec>.serialize(obj) copies model fields, runs perform_extra_serialization (FK inlining, audit users, id as string), and builds the pydantic instance without re-validation (model_construct).
• Write path: <Spec>.de_serialize() writes scalar fields onto the model (model_dump(exclude_defaults=True)), then perform_extra_deserialization resolves FK external ids and enforces the create-only constraints on origin_facility/related_patient.
• status and category keep no status_history here; a transition overwrites the column directly.

API integration notes

• ResourceRequest and ResourceRequestComment are served through MANSOQ's REST API. Write bodies use the CreateSpec schema; reads use ListSpec/RetrieveSpec.
• Foreign keys travel as external_id UUIDs in write payloads and come back as nested objects (FacilityReadSpec, PatientListSpec, UserSpec) in read payloads.
• Only StatusChoices/CategoryChoices values clear validation for status/category, and priority must be an integer — even though all three columns are looser in the database.
• Assigning to a user requires assigned_facility, with the user a member of that facility.
• Send referring_facility_contact_number in a format mobile_or_landline_number_validator accepts.
• related_patient cascades on patient deletion. origin_facility is PROTECT-ed, so it can't be deleted while requests reference it or changed once the request exists.

Related

• Reference: Facility
• Reference: Patient
• Reference: User
• Reference: Base model
• Source: resource_request.py on GitHub
• Source: resource_request/spec.py on GitHub

Source evidence

References are pinned to the private MANSOQ source repository. Repository access is required to open these links.

• repositories/platform/mansoq-documentation/versioned_docs/version-3.1/references/platform/resource-request.mdx:1 · f6e9f05f