Admin: Add Navbox platform (via update-page on MediaWiki MCP Server)

2026-07-06T04:24:18Z

Add Navbox platform (via update-page on MediaWiki MCP Server)

← Older revision		Revision as of 09:54, 6 July 2026
Line 230:		Line 230:
	* Send <code>referring_facility_contact_number</code> in a format <code>mobile_or_landline_number_validator</code> accepts.		* Send <code>referring_facility_contact_number</code> in a format <code>mobile_or_landline_number_validator</code> accepts.
	* <code>related_patient</code> cascades on patient deletion. <code>origin_facility</code> is <code>PROTECT</code>-ed, so it can't be deleted while requests reference it or changed once the request exists.		* <code>related_patient</code> cascades on patient deletion. <code>origin_facility</code> is <code>PROTECT</code>-ed, so it can't be deleted while requests reference it or changed once the request exists.

			{{Navbox platform}}

	{{Related}}		{{Related}}

Admin: OHC identity seed

2026-07-04T22:45:36Z

OHC identity seed

New page

{{Doc header
|type=reference
|domain=platform
|title=Resource Request
|order=4
|introduced=3.0
|model=ResourceRequest
|reference=References/Base models & conventions
}}

<code>ResourceRequest</code> 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: <code>status</code>, <code>category</code>, and <code>priority</code> are open <code>CharField</code>/<code>IntegerField</code> 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: [<nowiki/>https://github.com/ohcnetwork/care/blob/develop/care/emr/models/resource_request.py <code>care/emr/models/resource_request.py</code>]
* Spec: [<nowiki/>https://github.com/ohcnetwork/care/blob/develop/care/emr/resources/resource_request/spec.py <code>care/emr/resources/resource_request/spec.py</code>]

== Models ==

{| class="wikitable"
|-
! Model
! Purpose
|-
| <code>ResourceRequest</code>
| An inter-facility request for a resource (transfer, supply, or assistance), tracked from origin through approval and assignment
|-
| <code>ResourceRequestComment</code>
| A free-text comment thread entry attached to a <code>ResourceRequest</code>
|}

Both extend [[References/Base models & conventions|<code>EMRBaseModel</code>]], the shared Care EMR base that adds <code>external_id</code>, audit fields (<code>created_by</code>, <code>updated_by</code>, <code>created_date</code>, <code>modified_date</code>), and soft-delete semantics.

== <code>ResourceRequest</code> fields ==

=== Facilities ===

{| class="wikitable"
|-
! Field
! Type
! Notes
{{Field|model=ResourceRequest|section=Facilities|name=origin_facility|type=FK → Facility (PROTECT)|notes=Required. The facility raising the request. Set once on create (when <code>is_update</code> is false) and never reassigned. <code>related_name="resource_requesting_facilities"</code>.}}
{{Field|model=ResourceRequest|section=Facilities|name=approving_facility|type=FK → Facility (SET_NULL)|notes=Nullable. The facility responsible for approving. <code>related_name="resource_approving_facilities"</code>.}}
{{Field|model=ResourceRequest|section=Facilities|name=assigned_facility|type=FK → Facility (SET_NULL)|notes=Nullable. The facility the request is assigned to or fulfilled by. Required when <code>assigned_to</code> is set. <code>related_name="resource_assigned_facilities"</code>.}}
|}

=== Request details ===

{| class="wikitable"
|-
! Field
! Type
! Required
! Default
! Notes
{{Field|model=ResourceRequest|section=Request details|name=emergency|type=bool (BooleanField)|notes=Yes (spec)}}
{{Field|model=ResourceRequest|section=Request details|name=title|type=str (CharField(255))|notes=Yes}}
{{Field|model=ResourceRequest|section=Request details|name=reason|type=str (TextField)|notes=Yes (spec)}}
{{Field|model=ResourceRequest|section=Request details|name=status|type=StatusChoices enum (CharField(100))|notes=Yes}}
{{Field|model=ResourceRequest|section=Request details|name=category|type=CategoryChoices enum (CharField(100))|notes=Yes}}
{{Field|model=ResourceRequest|section=Request details|name=priority|type=int (IntegerField)|notes=Yes (spec)}}
|}

=== Referring contact ===

{| class="wikitable"
|-
! Field
! Type
! Required
! Default
! Notes
{{Field|model=ResourceRequest|section=Referring contact|name=referring_facility_contact_name|type=str (TextField)|notes=Yes (spec)}}
{{Field|model=ResourceRequest|section=Referring contact|name=referring_facility_contact_number|type=str (CharField(14))|notes=Yes (spec)}}
|}

=== Assignment & patient ===

{| class="wikitable"
|-
! Field
! Type
! Notes
{{Field|model=ResourceRequest|section=Assignment & patient|name=is_assigned_to_user|type=bool (BooleanField)|notes=Defaults to <code>False</code>; signals that a user-level assignment exists. The spec classes never expose it.}}
{{Field|model=ResourceRequest|section=Assignment & patient|name=assigned_to|type=FK → User (SET_NULL)|notes=Nullable. The user the request is assigned to. Requires <code>assigned_facility</code>, and the user must belong to that facility (see [[#validation}}
{{Field|model=ResourceRequest|section=Assignment & patient|name=related_patient|type=FK → Patient (CASCADE)|notes=Nullable, defaults to <code>None</code>. Links the request to a patient where one applies. Set only on create.}}
|}

== Enum values ==

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

=== <code>StatusChoices</code> values ===

{| class="wikitable"
|-
! Value
|-
| <code>pending</code>
|-
| <code>approved</code>
|-
| <code>rejected</code>
|-
| <code>cancelled</code>
|-
| <code>transportation_to_be_arranged</code>
|-
| <code>transfer_in_progress</code>
|-
| <code>completed</code>
|}

=== <code>CategoryChoices</code> values ===

{| class="wikitable"
|-
! Value
|-
| <code>patient_care</code>
|-
| <code>comfort_devices</code>
|-
| <code>medicines</code>
|-
| <code>financial</code>
|-
| <code>supplies</code>
|-
| <code>other</code>
|}

== Resource specs (API schema) ==

Every spec builds on <code>EMRResource</code> ([<nowiki/>https://github.com/ohcnetwork/care/blob/develop/care/emr/resources/base.py <code>base.py</code>]), which supplies <code>serialize</code> (DB object → pydantic, the read path) and <code>de_serialize</code> (pydantic → DB object, the write path), plus the <code>perform_extra_serialization</code> / <code>perform_extra_deserialization</code> hooks. <code>__exclude__</code> names the fields the base (de)serializer skips, leaving them to be handled by hand — FK resolution, for instance.

=== <code>ResourceRequest</code> specs ===

{| class="wikitable"
|-
! Spec
! Role
! Fields beyond base
|-
| <code>ResourceRequestBaseSpec</code>
| shared
| <code>id</code>, <code>emergency</code>, <code>title</code>, <code>reason</code>, <code>referring_facility_contact_name</code>, <code>referring_facility_contact_number</code>, <code>status</code>, <code>category</code>, <code>priority</code>. <code>__exclude__</code>s the five FK fields (<code>origin_facility</code>, <code>approving_facility</code>, <code>assigned_facility</code>, <code>related_patient</code>, <code>assigned_to</code>).
|-
| <code>ResourceRequestCreateSpec</code>
| write · create & update
| Adds the FKs as <code>UUID4</code> external ids: <code>origin_facility</code> (required), <code>approving_facility</code>, <code>assigned_facility</code>, <code>related_patient</code>, <code>assigned_to</code> (all optional). Resolves each external id to a DB object in <code>perform_extra_deserialization</code>.
|-
| <code>ResourceRequestListSpec</code>
| read · list
| <code>origin_facility: dict</code>, <code>assigned_facility: dict | None</code>, <code>created_date</code>, <code>modified_date</code>. Inlines <code>origin_facility</code>/<code>assigned_facility</code> via <code>FacilityReadSpec</code>.
|-
| <code>ResourceRequestRetrieveSpec</code>
| read · detail
| Everything in List plus <code>approving_facility</code>, <code>related_patient</code> (via <code>PatientListSpec</code>), <code>assigned_to</code> (via <code>UserSpec</code>, cache-backed), <code>created_by</code>, <code>updated_by</code>.
|}

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

==== Validation ====

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

==== Server-side behaviour (<code>perform_extra_deserialization</code>) ====

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

==== Read serialization (<code>perform_extra_serialization</code>) ====

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

=== <code>ResourceRequestComment</code> specs ===

{| class="wikitable"
|-
! Spec
! Role
! Fields beyond base
|-
| <code>ResourceRequestCommentBaseSpec</code>
| shared
| <code>comment: str</code>. <code>__exclude__</code>s <code>request</code>.
|-
| <code>ResourceRequestCommentCreateSpec</code>
| write · create
| No extra fields — the parent <code>ResourceRequest</code> is bound from the URL, not the body.
|-
| <code>ResourceRequestCommentListSpec</code>
| read · list
| Adds <code>created_by</code>, <code>created_date</code>; populates <code>created_by</code> via <code>serialize_audit_users</code>.
|-
| <code>ResourceRequestCommentRetrieveSpec</code>
| read · detail
| Subclasses <code>ResourceRequestCommentListSpec</code> with no changes.
|}

== Related models ==

=== <code>ResourceRequestComment</code> ===

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

<syntaxhighlight lang="text">request → FK ResourceRequest (PROTECT, required)
comment → TextField (default "")</syntaxhighlight>
== Methods & save behaviour ==

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

== API integration notes ==

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

{{Related}}

References/Resource Request - Revision history

Admin: Add Navbox platform (via update-page on MediaWiki MCP Server)

Admin: OHC identity seed