References/Resource Request

referenceplatformCARE 3.0+

Platform

Concepts

Tagging

References

File Upload

Meta Artifact Report & Templates Resource Request Resource Category Tagging

Favorites

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: [https://github.com/ohcnetwork/care/blob/develop/care/emr/models/resource_request.py care/emr/models/resource_request.py]
• Spec: [https://github.com/ohcnetwork/care/blob/develop/care/emr/resources/resource_request/spec.py care/emr/resources/resource_request/spec.py]

Models

Model	Purpose
ResourceRequest	An inter-facility request for a resource (transfer, supply, or assistance), tracked from origin through approval and assignment
ResourceRequestComment	A free-text comment thread entry attached to a ResourceRequest

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

ResourceRequest fields

Facilities

Field	Type	Notes
origin_facility	FK → Facility (PROTECT)	Required. The facility raising the request. Set once on create (when is_update is false) and never reassigned. related_name="resource_requesting_facilities".
approving_facility	FK → Facility (SET_NULL)	Nullable. The facility responsible for approving. related_name="resource_approving_facilities".
assigned_facility	FK → Facility (SET_NULL)	Nullable. The facility the request is assigned to or fulfilled by. Required when assigned_to is set. related_name="resource_assigned_facilities".

Request details

Field	Type	Required	Default	Notes
emergency	bool (BooleanField)	Yes (spec)
title	str (CharField(255))	Yes
reason	str (TextField)	Yes (spec)
status	StatusChoices enum (CharField(100))	Yes
category	CategoryChoices enum (CharField(100))	Yes
priority	int (IntegerField)	Yes (spec)

Referring contact

Field	Type	Required	Default	Notes
referring_facility_contact_name	str (TextField)	Yes (spec)
referring_facility_contact_number	str (CharField(14))	Yes (spec)

Assignment & patient

Field	Type	Notes
is_assigned_to_user	bool (BooleanField)	Defaults to False; 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 assigned_facility, and the user must belong to that facility (see [[#validation}}
related_patient	FK → Patient (CASCADE)	Nullable, defaults to None. Links the request to a patient where one applies. Set only on create.

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

Value
pending
approved
rejected
cancelled
transportation_to_be_arranged
transfer_in_progress
completed

CategoryChoices values

Value
patient_care
comfort_devices
medicines
financial
supplies
other

Resource specs (API schema)

Every spec builds on EMRResource ([https://github.com/ohcnetwork/care/blob/develop/care/emr/resources/base.py 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

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

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

Spec	Role	Fields beyond base
ResourceRequestCommentBaseSpec	shared	comment: str. __exclude__s request.
ResourceRequestCommentCreateSpec	write · create	No extra fields — the parent ResourceRequest is bound from the URL, not the body.
ResourceRequestCommentListSpec	read · list	Adds created_by, created_date; populates created_by via serialize_audit_users.
ResourceRequestCommentRetrieveSpec	read · detail	Subclasses ResourceRequestCommentListSpec with no changes.

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 Care'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.

Platform

Concepts

Tagging

References

File Upload · Meta Artifact · Report & Templates · Resource Request · Resource Category · Tagging · Favorites

Related

• Reference: References/Base models & conventions

Open Healthcare Network's flagship product: an open-source, FHIR-native electronic medical record (EMR) and healthcare operating system.

Electronic Medical Record — the digital record of a patient's clinical information.