Use this article to understand how the SERV component represents reportable regular services associated with a PLAN in a SIRAS archived transaction.
SERV is a reporting representation of the services associated with an accepted/current plan. It is not the same thing as a provider's Service Log.
Contents
| What SERV Represents | How Services Reach SERV |
| Which Services Are Reported | How SERV Connects to PLAN |
| Service Information | When SERV Is Omitted |
| SERV vs. Service Logs | Examples |
| Review and Correct | Related Help |
What the SERV Component Represents
SERV preserves the reportable regular services associated with a PLAN component. In SIRAS, the student's current plan-service information is maintained in the service area near the bottom of the MIS Summary. When an applicable plan event is archived for reporting, the archive preserves the reportable plan/service state for that event.
SERV is stored as part of the dated archived transaction when the event includes an applicable reportable PLAN and regular services.
How Services Reach a SERV Component
For a typical accepted IEP plan, think of the service information as moving through these layers:
- The IEP team develops or changes services in the meeting event.
- Those meeting values remain proposed/pending until the applicable Parent Response and finalization workflow allows them to become Current.
- With Accepts the Plan (Signed Consent), applicable approved service changes become part of the Current service set shown on the MIS Summary.
- The finalized meeting creates/preserves the dated archived transaction for the event.
- When the event has a reportable PLAN, the applicable reportable regular services are represented through SERV.
The actual meeting type, outcome, Parent Response, participation status, and archive components determine what is reportable. An unaccepted proposed plan should not become the student's new participating PLAN/SERV set.
For how Parent Response affects Current data, see Parent Response - Impact Table. For the Current-versus-archive model, see Data Record - Current Data.
Which SIRAS Services Are Reported
| SIRAS service category | CALPADS SERV treatment |
|---|---|
| Regular services | Reported when associated with the applicable PLAN. |
| ESY services | Not submitted as CALPADS SERV records through this component. |
| Supplemental services | Not submitted as CALPADS SERV records through this component. |
How SERV Connects to PLAN
SERV records are tied to a PLAN by the Plan Effective Date. The PLAN and its reportable services should therefore be reviewed together.
- A new participating PLAN normally has at least one associated regular service.
- The CALPADS SERV effective date is derived from the Plan Effective Date.
- Changing only a local Service Start Date does not replace the need for the correct Plan Effective Date.
- When a PLAN is not reportable, its SERV records should not be reported as the student’s participating service set.
The PLAN and SERV records should share the governing Plan Effective Date.
Service Information to Review
Review the applicable:
- service code and description;
- provider;
- service location;
- frequency;
- duration;
- local Service Start and End Dates;
- Regular, ESY, or Supplemental category; and
- Plan Effective Date governing CALPADS reporting.
When SERV Is Omitted
SERV is not included when:
- the event does not create a reportable PLAN;
- the student was found not eligible;
- the offered plan was not accepted and is not the participating plan;
- the archive is intentionally MEET-only or SWDS-only; or
- the service belongs only to an ESY or Supplemental category not reported as CALPADS SERV.
SERV Is Not the Same as a Service Log
| Plan service / SERV | Service Log |
|---|---|
| Describes the service associated with the student's plan and, when applicable, the service information represented in a CALPADS SERV component. | Documents an actual service session or related provider activity after/during implementation of the plan. |
| Maintained as plan/service information on the MIS Summary and preserved in the applicable archived plan transaction. | Maintained in the separate Service Log area. |
| Can be part of SEDS/CALPADS reporting when the event includes an applicable PLAN + SERV. | Does not itself create a CALPADS SERV record. |
For provider documentation of delivered service sessions, see Service Log Help.
Examples Retained from the Prior Article
Review and Correct SERV Information
- Verify the accepted plan and Plan Effective Date.
- Review the Regular services associated with that plan.
- Open the archived transaction and confirm that PLAN and SERV are both included when appropriate.
- Resolve missing, duplicate, or inconsistent services in the correct source.
- Correct the archive when the historical service set is wrong.
- Return the applicable transaction to Pending and verify CALPADS acceptance.
See Plan Effective Date, Service Start Date, and CALPADS SERV Reporting for date behavior.
