Skip to content
Orchid CRM Docs

Client Profiles

What this module does

When someone applies to be an egg donor or gestational carrier, they create a Profile — a rich, structured document that gets shared with intended parents during the matching process. A profile is not a simple form submission; it is a curated presentation of a person’s life, background, medical history, and values.

This module manages:

  • The creation and editing of all profile types (ED, GC, SD, IP)
  • Profile visibility and approval workflows
  • Photos, videos, and documents attached to profiles
  • Custom agency-defined profile sections
  • How profiles are rendered for intended parents

Business value

The profile is the product that an agency sells to intended parents. A high-quality, well-structured profile is what makes an intended parent choose one candidate over another. The profile module ensures that all the information agencies need is captured, validated, and presented consistently.

Key files

  • Directoryorchid/
    • Directorymodels/
      • profile.py 74 KB — 27 model classes for all profile types
      • mixins.py ProfileBase and DocumentMixin
    • Directoryapi/
      • profiles.py 137 KB — all profile CRUD operations
    • Directoryutils/
      • profiles.py 54 KB — profile utility functions
    • Directoryviews/
      • user.py 150 KB — includes profile editing in the user portal
    • Directoryinfo/
      • prebuilt_forms.py 98 KB — pre-built profile question definitions
  • Directorytemplates/
    • macros_profiles.html 303 KB — profile rendering macros

Profile types

Orchid has four distinct user roles with profiles, each with different data structures:

Egg Donor (ED) Profile — EDProfile

The most complex profile type. Contains:

  • Personal information (age, height, weight, eye/hair color)
  • Education history (EDEducation records)
  • Ethnicity (EDEthnicity records — can be multi-ethnic)
  • Family medical history (EDFamilyMember records with conditions)
  • Test results (EDTestResult — genetic carrier screening, etc.)
  • Documents (EDProfileDocument — medical records, ID)
  • Photos (EDProfileImage) and videos (EDProfileVideo)

Gestational Carrier (GC) Profile

Similar structure to ED, covering:

  • Medical clearance history
  • Previous pregnancies and deliveries (GCProfileDelivery)
  • Documents (GCProfileDocument), photos (GCProfileImage), videos (GCProfileVideo)

Sperm Donor (SD) Profile

Similar structure for SD-specific information.

Intended Parent (IP) Profile

Less complex — captures the IP’s preferences and background for matching. Includes IPProfileDocument, IPProfileImage, IPProfileVideo.

Data model

erDiagram
    ProfileBase {
        int user_id
        string profile_type
        bool is_approved
        bool is_visible
    }
    EDProfile {
        int user_id
        int age
        int height_in
        int weight_lbs
        string eye_color
        string hair_color
        string education_level
    }
    EDEducation {
        int profile_id
        string school_name
        string degree
        int graduation_year
    }
    EDEthnicity {
        int profile_id
        string ethnicity_code
    }
    EDFamilyMember {
        int profile_id
        string relationship
        string conditions
    }
    EDTestResult {
        int profile_id
        string test_name
        string result
    }
    EDProfileImage {
        int profile_id
        string s3_key
        bool is_primary
    }
    UserCustomProfile {
        int user_id
        int section_id
    }
    UserCustomProfileAnswer {
        int custom_profile_id
        int question_id
        text answer
    }


    ProfileBase ||--o| EDProfile : "is"
    EDProfile ||--o{ EDEducation : "has"
    EDProfile ||--o{ EDEthnicity : "has"
    EDProfile ||--o{ EDFamilyMember : "has"
    EDProfile ||--o{ EDTestResult : "has"
    EDProfile ||--o{ EDProfileImage : "has"
    ProfileBase ||--o| UserCustomProfile : "extends"
    UserCustomProfile ||--o{ UserCustomProfileAnswer : "has"

Profile visibility and approval

A profile goes through a visibility pipeline before an IP can see it:

Created → Incomplete → Complete → Submitted for review → Approved → Visible

Key flags on ProfileBase:

  • is_approved — whether the agency has approved the profile
  • is_visible — whether the profile is currently shown in matching

Agency staff approve profiles from the admin panel. Only approved, visible profiles appear in the matching queue.

Custom profile sections — UserCustomProfile

In addition to the standard profile fields, agencies can define custom sections with their own questions. This uses the UserCustomProfile, UserCustomProfileSection, and UserCustomProfileAnswer models.

Custom sections are defined per agency and per profile type. The questions are typically multiple-choice or free-text.

Profile keys — ProfileKey

The ProfileKey model controls which profile fields are visible or required for each agency. It acts as a per-agency schema override:

# Example: check if a field should be shown
key = models.ProfileKey.query.filter_by(
    agency_id=g.agency.id,
    profile_type='ED',
    field_name='education_level'
).first()
if key and key.is_visible:
    # render the field

prebuilt_forms.py — the question bank

orchid/info/prebuilt_forms.py (98 KB) is a large Python file that defines profile question banks as nested dictionaries. These are used when an agency builds their intake form from pre-defined question types.

This file is both configuration and code. Changes to it affect which questions are available when agencies configure their intake forms.

Profile rendering

Profile pages use templates/macros_profiles.html (303 KB) — one of the largest template files in the codebase. This file contains the Jinja2 macros that render every section of every profile type.

When working on profile display:

  1. Find the relevant macro in macros_profiles.html
  2. Check ProfileKey for visibility settings
  3. Check the model for data availability

Gotchas