With this statement that just came out today from LeRoy Rooker, what will be Instructure’s take on this interpretation of FERPA? What will your institution's take be on this interpretation?
Essentially, LeRoy Rooker’s statement is that an institution can allow a student to see other students in a course for which the student is officially registered, but cannot allow a student to see (or be seen by) other students in another (cross-listed) class in the LMS. To me, it sounds like the door remains open for true cross-listed, in-person courses (like a Psychology and Neuroscience course which are really one-in-the-same, but some students register as PSY and others as NEU) since those students meet at the same time in the same physical classroom with each other. But this new interpretation seems to shut down courses where one instructor teaches 4 sections of the same Accounting course and simply wants to cross-list those into one course shell in Canvas for the sake of their own convenience and the students would not normally see each other in the physical classroom since they are 4 separate Accounting classes.
Thoughts? Comments? Alternate interpretations of LeRoy's answer? How will you adapt in Canvas?
Solved! Go to Solution.
"I can think of many reasons why a student in Class A would not want to be identified by students in Class B, but reasons do not matter, .."
Kelly, out of curiosity, might you be able to give some reasons?
In a physical classroom, a student in class A can be identified by any other student in Class A, and this doesn't seem to be a problem. Also, a student in Class B can walk by the Class A classroom and see who is in it. In fact, anyone can walk by a classroom and see who is in it. (Will schools need to cover all classroom windows?)
Yes, reasons do not matter, but if there is not solid logic behind the reason, maybe the rule should be challenged.
(I am probably the only one who does not understand this, so I look forward to some explanations. I anticipate being sorry that I asked.)
I am in agreement with this comment. There is simply little logic behind these interpretations. FERPA does trump convenience, but let's apply FERPA logically. Any student in a course on campus could be identified as being in that course by someone simply seeing them in a classroom. Our student email systems within the whole college allows any student to message any other student. There is nothing isolating about students being in separate courses.
The entire conversation hinges on whether a student might be in danger or find offense in being in a course with another student that would be dangerous to them. When a student enrolls in a course, they don't know who will be in that course when the course finally meets. If they fear associating with another student, then they might look at the course roster after they have registered. The student doesn't have control over the registration process, nor would we alter the entire process for a single student. The essential element is does the student have the ability to know who is in the class and can they freely decide to change their situation if they find a problem. This interpretation is about students having the knowledge and the ability to keep themselves safe.
Just as students won't know who is registered in a course before or after they register, if courses were merged, there is no way that they would know. Just as a student would solve the issue by looking at a roster of their registered class and make a decision for their own safety, they can look at the roster for a merged set of sections and make a decision as to their safety. It is the exact same process. How do we extend danger to merged sections but not use the same logic for a student simply registering for a single course? Something is not logical here. I believe that the only issue for the student would be awareness. If the college or instructor clearly states that several sections will be or are merged and that you could be associating with students in other sections of the same course, you have now given the student the same awareness that they would have had from simply registering for any single section of a course.
Please someone shoot down my logic. Have I missed something? It seems like we are trying to use FERPA to eliminate the fraction of a gram of danger for a student. I am committed to that reduction as well, but it is not possible to do that in the real world. The answer is to give students the knowledge that they need to keep themselves safe. The solution to this issue is to make students aware and if they find an issue to help them resolve that problem by every means possible.
Having worked in compliance for many years in a past life (with much experience in the HIPAA privacy regs) , and having further researched this provision of FERPA, I believe this interpretation to be accurate. Faculty convenience does not trump FERPA privacy protections. I can think of many reasons why a student in Class A would not want to be identified by students in Class B, but reasons do not matter, what matters is the student's right to opt out of directory disclosure. A simple expediency might be to give the student a pseudonym, but the choice to do so would still rest with the student. We need to seriously rethink cross-listing. A solution that cross-listed courses be listed in the course schedule is workable and acceptable if students are advised clearly that the rosters will be combined and available for student review. In our student FERPA notices we should mention the possibility of course cross-listing (if we do that), and what it means in regards to the availability of student directory information. If unsure of this interpretation and the actions needed, we should consult with our AAGs and document their opinions, keeping that documentation on file. I will be opening conversations with our Registrar (our Keeper-of-all-things-FERPA). when I return to work next week. We do manually cross-list, and our policies and procedures will need to change, and I would rather have the bad news come to faculty from her, than from us.
When you manually enroll a user into a course in Canvas, we have the option of making that user only see other users in their own section. Unfortunately, that same option doesn't seem to exist for cross-listed sections. Instructure may need to create that as an option for cross-listed courses ASAP and allow institutions to set that as the default. That would at least keep students in Class A from seeing students in Class B in cross-listed courses, and would give institutions the power to enforce or at least default that privacy-first behavior.
@jared , I don't know why your post just disappeared, but I might make one more suggestion to yours. Canvas could expand the "can interact with users in their section only" functionality to entire sections instead of making that a new-enrollment-only option as it exists right now. With that box checked, you are already half-way to a great solution to this problem. The problem now is that this can only be selected on a user-by-user basis upon enrollment creation either through the +People button in a course GUI or through essentially the same process via the API. It cannot be done to an entire section, it cannot be done to everyone by default, and it cannot be done through the SIS Import process -- which makes it great for some things like keeping a TA limited to just their section of students, but makes it impractical to address this campus-wide FERPA privacy concern.
Very interesting; thanks for bringing this up. I would love to hear other perspectives confirming or challenging this interpretation of FERPA. In the meantime...
First, it's worth stating the problem that convenience cross-listing in Canvas solves:
Teaching multiple sections of the same course is more time-consuming than it needs to be when all sections have the same content and same activities. (I specify convenience cross-listing, because I think @John_Lowe is right: Officially cross-listed sections from different departments or with different course numbers seem to be, conceptually, the same class.)
We're actually pretty close to enabling this, I think. I need to dig a little bit more, but as John points out, you can, in fact, restrict students from seeing students outside their section, if you check the right box at the right time E.g. this feature request (open for voting Jul 6): " modifiedtitle="true" title="Edit Section: Restricting students to see own section only. Enhancing Canvas based on that capability seems like the easiest solution, but I will need to look into this before I confirm.
Finally, I want to note that it may be possible to address this FERPA concern without technology at all, if institutions were willing to change how they define courses and sections, and make it clear to students that signing up for any section of a course means you could have classmates from any of x sections. Maybe some institutions do this already. I bring this up not to avoid a Canvas solution, but because this FERPA interpretation may be further reaching that just convenience cross-listing in the LMS.
For the sake of discussion, @jared , if you still have a draft of your original ideas, some of those were really good too. Would you be willing to post it back again that lists the other ideas like the individual privacy flag and others? Others might think some of those are better than the one I proposed. Even I am really intrigued by the idea on an individual privacy setting that is included in the SIS load.
Certainly, as best I can remember them!
One thing that occurred to me is that even though the current "limit_privileges_to_course_section" capability could get the job done, it's actually backwards and "greedy" -- it would need to be used to restrict all users in a section from seeing all users in other sections. What this interpretation of FERPA requires is that a single user can be "unlisted" from students in other sections. Maybe lawyers would decide in favor of that, for simplicity's sake, the all-or-nothing approach is required (i.e. pseudonymous participation doesn't properly protect identity).
But it would get the job done. And implementations of this could be...
As for my other ideas:
1. In Canvas, a user could be marked as "private" -- probably starting with SIS import, but perhaps as a separate process via the API. Canvas would need to then automagically make that user pseudonymous to users in other sections. This may be problematic; hiding a user would create gaps, and if the user is not pseudonymous to classmates in their own section, there's the risk that a peer would refer to them by name, in a discussion post, for example.
2. In Canvas, user could make themselves pseudonymous in their Profile, showing only their "Screen Name" to other students. Though this solution overreaches, it seems pretty easy, as I think currently the Screen Name is the default representation of a user -- until someone clicks on their Profile. This could use some testing.
3. In Canvas, a teacher could manage the content from a "master" course to multiple sections more easily, eliminating much of the need of cross-listing. We're actually doing some research on this right now in ProductLand, though this particular FERPA challenge has not yet been part of the conversation.
That was from memory hope I didn't miss anything golden.
@jared 's comments illustrate a very good point that is the same with HIPAA and health care as it is with FERPA and student privacy - the best privacy protections are not technological; but rather stem from policy, procedures, and training. Technology that supports policy and procedures can be very helpful, but can never replace a considerate policy, well written and enforced procedures and damn good training.
If this section-based privacy-wall gets implemented, will this option be the default? Meaning that the professor who wants to deliberately expose students across sections has to do the deliberate action to tear down the privacy-wall between sections (uncheck a box in section settings I presume) essentially making this a privacy-first setting. As Kelley mentions, training and institutional policies are incredibly important, but it will be far easier for us to train professors how to violate privacy when there is a legitimate educational need rather than hoping that everyone else remembers their training and remembers where to go to select a checkbox likely buried in section settings to protect privacy if the technology can default to the higher privacy settings first. Or at least allow individual institutions to set whether or not that privacy-wall is enabled by default in the Account or Sub-Account settings.
UPDATE: We can negotiate royalty payments later if you end up calling this feature "privacy-wall".