The IFSP Is the Database

The Homefront portal has five distinct features: AI-assisted session notes, service authorization tracking, report due date automation, a supervisor dashboard, and a billing denial audit trail. They look like separate tools. They are not. Every one of them reads from the same document: the child's Individualized Family Service Plan.

The IFSP is the governing document for a First Steps child. It names the eligible conditions, the family's stated outcomes, the specific measurable goals for each service type, the services authorized (occupational therapy, physical therapy, speech, developmental), the authorized frequency and duration, and the authorization period. Every billing decision, every session note requirement, and every compliance obligation traces back to it.

Here is what that means for each feature.

Session note AI. When a provider opens a session note for a child, the assistant reads that child's current IFSP goals before it drafts anything. It is not pulling from a generic template or a training set of sample goals. It is reading the specific language from that child's plan. That is why the drafted note references the right goal: the assistant knows what goals are active, what the measurable criteria are, and what service type the session is for. When the IFSP is updated at a six-month review and the goal language changes, the next session note reflects the new language. Nothing has to be reconfigured.

Authorization tracking. Authorized units per service type per child live on the IFSP. The portal reads them. Every time a provider logs a completed session, the portal decrements the count. When a provider tries to log a session against an exhausted or expired authorization, the error surfaces at documentation time. The authorization data comes from the IFSP. It does not live in a separate spreadsheet that has to be maintained in parallel.

Report due dates. First Steps report cycles are not calendar-based. They derive from the child's enrollment date, the IFSP review schedule, and the service authorization periods. These vary per child. The portal generates due dates from the IFSP records, not from a fixed template. When an IFSP review happens and a new authorization period starts, the report schedule shifts accordingly.

Supervisor dashboard. The dashboard shows each provider's active caseload, upcoming report deadlines, and last documented session date. The caseload count comes from active IFSP enrollments. The deadlines come from the authorization and review schedule on each child's plan. The supervisor is not looking at a static list someone maintained. They are looking at a live read of the actual case records.

Billing denial audit trail. When a claim is denied, the denial usually names an IFSP reference: wrong authorization, expired auth period, session type not on the plan, goal language not cited in the note. The portal's documentation ties back to the IFSP record that existed when the session was logged. The audit trail is not reconstructed from memory. It is the original IFSP data, the authorization state at time of service, and the session note that referenced the plan's goals.

The pattern: agencies typically store IFSPs as PDFs and manage everything downstream in spreadsheets. Authorizations in one sheet, due dates in another, provider caseloads in a third. The same data exists in multiple places, and the spreadsheet version is always behind the PDF. Every discrepancy between them is a potential billing error or a missed deadline.

The portal has one record per child. The IFSP is not a file that gets attached and forgotten. It is the schema everything else reads. Update the IFSP, and the session note assistant, the authorization counter, the report schedule, and the supervisor view all update with it. That is not five features. It is one data model, surfaced five ways.