Skip to main content

The Coal to the Engine

Unveiling the Second Stage of EDORA’s Core Engine

This is part 2 of the core engine explanation find Part One Here

 The journey to create a transformative system like the EDORA Client Case Management System is not simply about technology—it’s about crafting a vision. At its heart, EDORA revolves around one unifying concept: the "Need." This abstract entity is the fuel driving every interaction, every relationship, and every action within the system. Tonight, we delve deeper into how this "Need" operates, focusing on its workflows, relationships, and the technical schemas that bring it to life.

The "Need" isn’t just a request or a problem to solve. It’s a carefully nurtured process that moves through a lifecycle of interactions, bridging clients, caseworkers, providers, specialists, and the system itself. By creating an intricate yet flexible framework, EDORA aims to ensure that no "Need" is left unmet.

Understanding the Lifecycle of a "Need"

Every "Need" begins with its submission, a moment that captures the spark of purpose within EDORA. A "Need" might originate from:

  • Clients, requesting support for themselves or their families.
  • Caseworkers, advocating for clients based on observed or reported issues.
  • Providers, identifying gaps in services or anticipating client requirements.
  • The System, leveraging analytics to proactively identify unmet needs.

At this stage, the "Need" is an idea—a raw piece of coal waiting to ignite the engine.

Once submitted, the system transitions to validation. This phase is crucial, ensuring the "Need" is legitimate, actionable, and supported by available resources. Validation examines eligibility criteria, such as income thresholds or residency requirements, and evaluates resource constraints. The system’s intelligence plays a key role here, automating much of the process while flagging ambiguous cases for human review. Validation transforms the "Need" from an idea into a defined entity, ready for action.

Following validation, the "Need" enters the assignment phase. Here, EDORA’s dynamic framework connects the "Need" with the resources and expertise required to address it. Providers are chosen based on their capacity, location, and specialization. Specialists are assigned to milestones, matched to the specific attributes of the "Need." This process is adaptive; as conditions change, assignments can shift to maintain efficiency and effectiveness.

Progress is monitored through milestones. Each milestone represents a checkpoint in the "Need’s" lifecycle, ensuring transparency and accountability. Whether it’s an initial assessment, the delivery of resources, or the completion of services, milestones provide clear progress markers. The system ensures that stakeholders—clients, caseworkers, and providers—remain informed at every step.

Finally, the "Need" reaches resolution. This marks the culmination of efforts across all entities. The system logs outcomes, evaluates performance, and updates all relevant data, closing the loop while paving the way for continuous improvement. Resolution is not merely the end of a process; it’s the beginning of a deeper understanding of how EDORA can better serve its users.

Building Relationships Within EDORA

Relationships are the connective tissue of EDORA’s workflows. Every action relies on seamless coordination between clients, caseworkers, providers, specialists, and the system itself. These entities are not isolated; they form an evolving web of interactions centered on the "Need."

Caseworkers act as facilitators, ensuring that the "Need" remains on track. Providers oversee resources, managing capacity and ensuring that services align with expectations. Specialists execute tasks tied to milestones, bringing expertise to the forefront of action. The system, meanwhile, orchestrates these interactions, serving as both a conductor and a record keeper, ensuring transparency, accountability, and efficiency.

Transparency and Accountability

One of EDORA’s most defining features is its commitment to transparency. Every action, decision, and interaction is logged, creating a complete record of the "Need’s" journey. Validation attempts are meticulously documented, ensuring that the reasons behind approvals or denials are clear. Milestones track not just completion but also the methods and timelines involved.

This transparency fosters accountability among all entities. Providers can evaluate resource utilization and identify bottlenecks. Caseworkers can track patterns in unmet needs, refining their approaches. The system itself learns and adapts, using analytics to predict future requirements and optimize existing workflows. Transparency isn’t just a feature; it’s a principle embedded within EDORA’s DNA.

The Path Forward

While EDORA’s workflows and schemas represent significant progress, this is just the beginning. The system is designed to evolve, incorporating feedback from real-world applications and insights from the Open Source Community. Collaboration is essential to ensure that EDORA remains adaptable to diverse needs and continues to fulfill its purpose as a tool for empowerment.

The next section of this post offers a glimpse into the technical foundation of EDORA. Here, we present detailed database schemas and real-world examples, illustrating how these workflows translate into actionable data structures.

Schema and Real-World Examples

Here's the detailed table schema for each entity in EDORA followed by a real-world data record example:Here’s the schema and real-world examples rewritten in markdown-style formatting for easy readability and inclusion in the blog post:

Schema and Real-World Examples

ValidationHistory

Tracks all validation attempts for a "Need."

  • ValidationID: INT (PK) - Unique identifier for each validation attempt.
  • NeedID: INT (FK) - References the associated "Need."
  • ValidationTimestamp: DATETIME - When the validation was attempted.
  • Validator: VARCHAR - Entity performing the validation (e.g., System).
  • ValidationStatus: VARCHAR - Outcome of the validation (e.g., Passed, Failed).
  • Notes: TEXT - Additional details or reasons for failure.

Real-World Example:

  • ValidationID: 501
  • NeedID: 101
  • ValidationTimestamp: "2024-12-01 08:30:00"
  • Validator: "System"
  • ValidationStatus: "Passed"
  • Notes: "Eligibility rules met for emergency housing."

ResourceTracking

Monitors the availability of resources tied to a "Need."

  • ResourceID: INT (PK) - Unique identifier for the resource record.
  • NeedID: INT (FK) - References the associated "Need."
  • ProviderID: INT (FK) - References the associated provider.
  • ResourceType: VARCHAR - Type of resource (e.g., Housing Slot).
  • Description: TEXT - Detailed explanation of the resource.
  • Capacity: INT - Maximum capacity available.
  • Utilized: INT - Number of resources currently utilized.
  • AvailabilityStatus: VARCHAR - Status of the resource (e.g., Available, Limited, Unavailable).
  • LastChecked: DATETIME - Timestamp for when availability was last verified.
  • Remarks: TEXT - Additional comments or notes.

Real-World Example:

  • ResourceID: 301
  • NeedID: 101
  • ProviderID: 201
  • ResourceType: "Emergency Housing"
  • Description: "3 beds in a safe, temporary housing facility."
  • Capacity: 10
  • Utilized: 7
  • AvailabilityStatus: "Limited"
  • LastChecked: "2024-12-11 09:00:00"
  • Remarks: "Two slots opening by the weekend."

EligibilityRules

Stores program-specific eligibility criteria for dynamic validation.

  • RuleID: INT (PK) - Unique identifier for the eligibility rule.
  • NeedType: VARCHAR - Category of the "Need" (e.g., Housing, Therapy).
  • Criteria: TEXT - Specific conditions for eligibility.
  • CreatedAt: DATETIME - When the rule was created.
  • UpdatedAt: DATETIME - Last update timestamp.

Real-World Example:

  • RuleID: 801
  • NeedType: "Housing Assistance"
  • Criteria: "Income ≤ $30,000; Residency in County A."
  • CreatedAt: "2024-01-01 12:00:00"
  • UpdatedAt: "2024-06-15 14:30:00"

Milestones

Tracks progress through specific checkpoints tied to a "Need."

  • MilestoneID: INT (PK) - Unique identifier for each milestone.
  • NeedID: INT (FK) - References the associated "Need."
  • Description: VARCHAR - Description of the milestone.
  • Status: VARCHAR - Status of the milestone (e.g., Pending, Completed).
  • DueDate: DATE - Expected completion date.
  • CompletedDate: DATE - Actual completion date.
  • AssignedEntityID: INT (FK) - Entity responsible for the milestone.
  • Remarks: TEXT - Additional comments or notes.

Real-World Example:

  • MilestoneID: 201
  • NeedID: 101
  • Description: "Initial Assessment Completed"
  • Status: "Completed"
  • DueDate: "2024-12-05"
  • CompletedDate: "2024-12-04"
  • AssignedEntityID: 401
  • Remarks: "Assessment successfully passed."

Specialists

Tracks individuals with expertise tied to specific "Needs."

  • SpecialistID: INT (PK) - Unique identifier for the specialist.
  • Name: VARCHAR - Name of the specialist.
  • Specialization: VARCHAR - Area of expertise (e.g., Housing, Therapy).
  • AvailabilityStatus: VARCHAR - Availability of the specialist (e.g., Available, Unavailable).
  • ProviderID: INT (FK) - References the provider employing the specialist.

Real-World Example:

  • SpecialistID: 801
  • Name: "Dr. Jane Smith"
  • Specialization: "Therapy Services"
  • AvailabilityStatus: "Available"
  • ProviderID: 201

Providers

Tracks organizations offering services to fulfill "Needs."

  • ProviderID: INT (PK) - Unique identifier for the provider.
  • Name: VARCHAR - Name of the provider.
  • ServicesProvided: JSON - List of services offered.
  • Capacity: INT - Maximum capacity for service fulfillment.

Real-World Example:

  • ProviderID: 201
  • Name: "Safe Haven Shelter"
  • ServicesProvided: ["Emergency Housing", "Counseling"]
  • Capacity: 50

SpecialistAssignments

Links specialists to specific "Needs" and providers.

  • AssignmentID: INT (PK) - Unique identifier for the assignment.
  • SpecialistID: INT (FK) - References the assigned specialist.
  • ProviderID: INT (FK) - References the provider overseeing the assignment.
  • ClientID: INT (FK) - References the associated client.
  • NeedID: INT (FK) - References the associated "Need."
  • StartDate: DATE - Date the assignment began.
  • EndDate: DATE - Date the assignment ended or is expected to end.

Real-World Example:

  • AssignmentID: 701
  • SpecialistID: 801
  • ProviderID: 201
  • ClientID: 301
  • NeedID: 101
  • StartDate: "2024-12-02"
  • EndDate: "2024-12-15"

By sharing this vision and these foundational elements, EDORA seeks not just to inform but to inspire. We invite developers, human services professionals, and open-source contributors to join us in shaping the future of case management. Together, we can ensure that every "Need" is met with dignity, precision, and care.