tqwhite
commented
11 months ago tl;dr: Yes but maybe not where you suggest.
It is certainly true that there are boxes that need to be checked and that there needs to be a place to record them and that this is one of those. It is less certain that the record of that event needs to transit in a data portability model but, I think I will declare that I am a universalist. If it is in a database, it should be in the standard.
I am less certain that it should be in "Individualized Program". I think it could be that the Student Personal should have a 'BoxesChecked' element. Or, it could be that Individualized Program should have a 'boxes checked' element. Perhaps there it might be called, "ProcessAcknowledgements". Some thought about how to deal with similar actions, eg, InvitedToSomething2023, InvitedToSomething2024, etc.
You might think it belongs in the IEP but, it's doesn't. Transition services are required for the same students but not the same thing. It's much more like a series of practical classes (the CMERDC transition product included a tutorial on brushing one's teeth but also using a bank or taking a bus or getting to work on time). If I were still had ambition, I could see developing a Transition element.
I can't find "Individualized Program" on the website. If it exists, the argument for putting it there could be that the database column is on a record in a StudentPrograms table with a definition like, studentRefId, programName, wasInvitedFlag, acceptedFlag, showedUpFlag. It would be easy to think of transporting them together. And, if that "Individualized Program" thing was in the StudentPersonal, I could go for IndividualizedProgram/Program/[ProgramName, WasInvitedFlag, etc].
If not, I would put it into StudentPersonal but change it to RequiredNotifications/Programs/Program/[ProgramName, WasInvitedFlag, etc]. I would construct it with the subordinate element listPrograms so that we could add Warnings, LegalNotices, or other kinds of required notification that we don't necessarily want to track or that may not generate additional data. (Though that makes me think that the the Program element probably should have a ProgramRefId (optional) element in case it does.)
If Individualized Program exists and is elsewhere, I don't like putting the WasInvited flag there. WasInvited is a characteristic of the student themself, not of the program, ie, StudentPersonal. The 'Program' was not invited and, if the student didn't participate, there is no reason to have a Program object.
jackie-hughes
This is for capturing needs not currently supported by the CEDS model. Please do not send or share actual data as examples in this issue or in attachments.
Author(s) Deborah Donovan
Authoring Organization(s) Mississippi Department of Education
Email address ddonovan@mdek12.org
Use Case Title Student and Agency IEP invitations to IEP meetings for transition planning
Use Case Description Proposed Element: Student Invitation for Transition Planning Definition: An indication that the student was invited to the IEP meeting where transition services are to be discussed Option Set: Yes, No
Proposed Element: Agency Invitation for Transition Planning Definition: An indication that, if appropriate, a representative of any participating agency that is likely to be responsible for providing or paying for transition services, including, if appropriate, pre-employment transition services, was invited to the IEP team meeting with the prior consent of the parent or student who has reached the age of majority Option Set: Yes, No
Use Case Background Need this information to ensure compliance with Indicator 13 of the IDEA Annual Performance Report. Reference Section 300.321 (b)
Location of Element in the Domain Entity Schema K12 Student > Individualized Program