Privacy, Ethics, and Institutional Review Considerations

This vignette offers considerations for using the engager package with privacy-supporting defaults and ethical practices for educational data analysis. It is not a FERPA source, it is not legal advice, and the package does not guarantee FERPA compliance. Users and institutions remain responsible for policy review, authorization, disclosure decisions, retention, and legal compliance.

External FERPA References

This vignette is not a summary of FERPA requirements. For FERPA interpretation, you might start with official U.S. Department of Education resources and/or your institution’s policies:

Student Privacy Policy Office FERPA overview: https://studentprivacy.ed.gov/ferpa
“What is FERPA?” FAQ: https://studentprivacy.ed.gov/faq/what-ferpa
Directory information FAQ: https://studentprivacy.ed.gov/faq/may-educational-agency-or-institution-disclose-directory-information-without-prior-consent
School official and legitimate educational interest FAQ: https://studentprivacy.ed.gov/faq/under-ferpa-may-educational-agency-or-institution-disclose-education-records-any-its-employees

When using this package with student data, consider confirming through local policy review that your workflow, data access, disclosure decisions, retention plan, and output sharing are authorized.

Privacy-Supporting Design

The package includes privacy-supporting defaults intended to reduce accidental exposure of student identifiers:

library(engager)

# Check current privacy level
getOption("engager.privacy_level")

By default, the package sets privacy level to "mask", which masks common identifier fields in package summaries, plots, and writers.

Privacy Levels

The package supports multiple privacy levels that can be considered during local review:

1. Privacy Strict (`"privacy_strict"`)

The broadest built-in masking option:

options(engager.privacy_level = "privacy_strict")

This level masks: - Student names and IDs - Email addresses - Phone numbers - Addresses - Social security numbers - Birth dates - Parent/guardian names - Instructor names and IDs

2. Privacy Standard (`"privacy_standard"`)

A broader masking option for many instructional workflows:

options(engager.privacy_level = "privacy_standard")

This level masks: - Student names and IDs - Email addresses - Phone numbers - Instructor names and IDs

3. Basic Mask (`"mask"`)

The package default for basic identifier masking:

options(engager.privacy_level = "mask")

This level masks: - Student names and IDs - Email addresses

4. No Masking (`"none"`)

Turns off package masking. This is usually not appropriate for student data unless local review has authorized identifiable outputs:

options(engager.privacy_level = "none")

Setting the option does not modify existing objects. Supported masking and output helpers may warn when they run with this value; inspect their results before storing or sharing them.

Privacy Review Functions

The package provides functions that can support privacy review. These functions identify common risks and apply masking or anonymization, but they do not make a legal determination.

Data Validation

You can review data for possible privacy risks:

# Sample data with PII
sample_data <- tibble::tibble(
  student_id = c("12345", "67890"),
  preferred_name = c("Alice Johnson", "Bob Smith"),
  email = c("alice@university.edu", "bob@university.edu"),
  participation_score = c(85, 92)
)

# Run a privacy-oriented technical review
validation_result <- review_privacy_risks(sample_data)
print(validation_result$passed)
print(validation_result$recommendations)

Data Masking and Transformation

anonymize_educational_data() applies masking, hashing, or pseudonymization transformations to recognized columns. Hashing requires an explicit non-empty salt. Missing and blank identifiers remain missing or blank. These technical operations do not by themselves establish that re-identification is impossible or that an output satisfies a legal or institutional definition of anonymized data.

# Structured-field masking
masked_data <- anonymize_educational_data(sample_data, method = "mask")

# Hashing transform
hashed_data <- anonymize_educational_data(sample_data, method = "hash", hash_salt = "institution_salt")

# Pseudonymization transform
pseudonymized_data <- anonymize_educational_data(sample_data, method = "pseudonymize")

Aggregation is intentionally not exposed through this helper in v0.1.0. Remove row-level identifiers before aggregating and review the result before sharing it.

Privacy Reporting

You can generate privacy review reports:

# Sample data with identifier-like fields
sample_data <- tibble::tibble(
  student_id = c("12345", "67890"),
  preferred_name = c("Alice Johnson", "Bob Smith"),
  email = c("alice@university.edu", "bob@university.edu"),
  participation_score = c(85, 92)
)

# Generate privacy review report
report <- engager::generate_privacy_review_report(sample_data)

# Save report to a temporary file
report_file <- tempfile(fileext = ".json")
written_report <- engager::generate_privacy_review_report(
  sample_data,
  output_file = report_file,
  report_format = "json"
)
unlink(report_file)

Data Retention Review

The exported review interface can record a retention period as part of a technical review. It does not enforce an institutional records schedule or decide which records may be retained or disposed of:

# Add date column for retention checking
sample_data_with_dates <- sample_data %>%
  dplyr::mutate(session_date = as.Date(c("2024-01-15", "2024-02-20")))

# Include retention context in the technical review
retention_review <- review_privacy_risks(
  sample_data_with_dates,
  check_retention = TRUE,
  retention_period = "academic_year"
)

print(retention_review$retention_check$retention_period_days)
print(retention_review$recommendations)

Compare record dates with the institution-approved schedule in the authorized records-management system, and have the appropriate owner approve any disposal.

Institutional Review Considerations

The package cannot know which institutional role, policy, or legal framework applies to a particular dataset. Instead of treating institution type as a compliance decision, use the review context only to surface different technical prompts for local review.

For a classroom or program-improvement workflow, one review might look like:

classroom_review <- review_privacy_risks(
  sample_data,
  institution_type = "educational"
)

print(classroom_review$institution_guidance)

For a research workflow, use the research context as a reminder to consider IRB, consent, publication, and data-sharing expectations:

research_review <- review_privacy_risks(
  sample_data,
  institution_type = "research"
)

print(research_review$institution_guidance)

If a workflow has both instructional and research uses, treat that as a reason to document both review paths rather than as a stronger package-level claim:

combined_review <- review_privacy_risks(
  sample_data,
  institution_type = "mixed"
)

print(combined_review$institution_guidance)

Data Handling Practices to Consider

1. Data Classification

Consider classifying the data before analysis:

Public Data: Results approved for public release after aggregation or de-identification review
Internal Data: Student records for legitimate educational purposes
Confidential Data: Personally identifiable information requiring special protection

2. Access Controls

Consider access controls that match the data classification:

Limit access to authorized personnel only
Use role-based access controls
Document all data access and usage
Implement secure authentication

3. Data Storage

Plan storage and transfer practices for sensitive data:

Use encrypted storage for sensitive data
Implement secure backup procedures
Use secure transmission protocols
Regularly audit data access

4. Data Disposal

Follow local retention and disposal procedures:

Implement automated data disposal
Document disposal procedures
Verify removal according to the approved local procedure
Maintain disposal audit trails

Instructor Review Prompts

Before Analysis

Review Institutional Policies: Consider reviewing your institution’s educational records and data handling policies
Document Authorization: Confirm or record the authorization path for accessing student data
Plan Data Handling: Decide how data will be protected, retained, and disposed of
Document Procedures: Keep local procedures for data handling

During Analysis

Prefer Privacy Defaults: Prefer privacy-supporting settings unless local review authorizes otherwise
Review Data: Use privacy review functions as technical checks
Limit Access: Keep access aligned with documented educational need
Monitor Usage: Track how data is being used when local policy calls for it

After Analysis

Review Results: Check whether outputs contain identifiers or small-cell disclosure risks
Secure Storage: Store results according to local policy
Dispose of Data: Follow institutional disposal procedures
Document Process: Maintain non-sensitive records of the analysis review

Institutional Adoption Considerations

This package is intended to support institutionally authorized educational analysis. Before using it with transcripts, rosters, or other student records, consider confirming that the planned workflow has been reviewed under your local policies. The package can reduce accidental disclosure through masking and review helpers, but it does not determine whether a use is legally permitted.

1. Review Authorization

Before importing data, consider:

Identify the educational purpose for the analysis.
Identifying who is authorized to access the transcript and roster data.
Review whether students, instructors, teaching assistants, or guests are represented in the data.
Considering whether additional institutional review is needed for research, assessment, reporting, or cross-course comparison.
Document the local approval path without storing sensitive raw data in the package project or public repositories.

2. Prepare a Local Data Environment

Choose local storage and access controls that match your institution’s data classification:

Prefer keeping raw transcripts and rosters outside package source directories.
Avoid committing raw transcripts, rosters, generated summaries, review logs, or analysis outputs that include identifiers.
Use institution-approved storage, encryption, retention, and sharing practices for raw data and intermediate outputs.
Limit access to people with a documented educational need.

3. Configure Privacy Defaults

Before processing data, consider setting and recording the intended privacy level:

library(engager)

options(engager.privacy_level = "mask")
getOption("engager.privacy_level")

Consider "privacy_standard" or "privacy_strict" when your local review calls for broader masking. These are package setting names, not compliance labels. Use "none" only for a documented, authorized reason and review all outputs before sharing them.

4. Review Inputs and Outputs

The package’s privacy review helpers can support technical checks; they are not legal determinations:

validation <- review_privacy_risks(your_data)
validation$recommendations

Before sharing or storing results outside the restricted working environment, consider:

Inspect output files for names, email addresses, student IDs, meeting IDs, course identifiers, and small-cell disclosure risks.
Prefer write_metrics() for CSV exports; it omits raw transcript/comment text by default because free-text comments can include spoken names or contextual identifiers.
Prefer masked, aggregated, or pseudonymized outputs for routine sharing.
Review plots and exported privacy-review artifacts, not just CSV files.
Record a non-sensitive summary of the review decision.

5. Retain and Dispose of Data

Follow local policy for retention and disposal. A local process might include:

Keep raw transcripts and rosters only as long as authorized.
Remove local generated outputs when they are no longer needed.
Avoid using package examples, vignettes, test fixtures, or repositories as storage locations for real student data.
Preserve only non-sensitive validation evidence in release or project notes.

6. Suggested Local Sign-Off Record

For an institutional deployment or other formal review, a local record can answer these questions without including raw student data:

What data source was reviewed?
Who performed the privacy review?
Which privacy level and masking workflow were used?
Were raw identifiers found in shared outputs?
What retention or disposal action is required?
Who approved use under institutional policy?

This sign-off record is best kept with the institution or authorized review owner. It does not show that the package guarantees legal compliance.

Troubleshooting Common Issues

Privacy Level Not Working

If privacy masking isn’t working as expected:

# Check current privacy level
getOption("engager.privacy_level")

# Reset the documented session option
options(engager.privacy_level = "mask")

# Verify with sample data
test_data <- tibble::tibble(name = "Test Student")
ensure_privacy(test_data)

Privacy Validation Failing

If privacy validation is flagging issues:

# Check what PII was detected
validation_result <- review_privacy_risks(your_data)
print(validation_result$pii_detected)

# Mask recognized structured identifier columns
masked_data <- anonymize_educational_data(your_data, method = "mask")

# Re-validate
review_privacy_risks(masked_data)

Data Retention Questions

If the technical review raises retention questions:

# Record the retention context in the exported review interface
retention_review <- review_privacy_risks(
  your_data,
  check_retention = TRUE,
  retention_period = "academic_year"
)

# Review technical prompts, then apply the institution-approved schedule
print(retention_review$recommendations)

Ethical Use Principles

1. Educational Purpose

This package is best used to support educational outcomes:

Focus on participation equity
Identify students who need support
Improve teaching effectiveness
Support student success

2. Avoid Surveillance

Avoid using this package for surveillance:

Avoid tracking individual students without educational purpose
Avoid using data for punitive measures
Focus on positive interventions
Respect student privacy

3. Transparency

Consider transparency around data use:

Inform students about data collection
Explain how data will be used
Provide opt-out options when possible
Document all data usage

4. Beneficence

Center student benefit in data use:

Use insights to improve teaching
Provide targeted support
Identify systemic issues
Promote equitable participation

Resources

FERPA Resources

Student Privacy Policy Office FERPA overview: https://studentprivacy.ed.gov/ferpa
What is FERPA? FAQ: https://studentprivacy.ed.gov/faq/what-ferpa
Directory information FAQ: https://studentprivacy.ed.gov/faq/may-educational-agency-or-institution-disclose-directory-information-without-prior-consent
School official and legitimate educational interest FAQ: https://studentprivacy.ed.gov/faq/under-ferpa-may-educational-agency-or-institution-disclose-education-records-any-its-employees

Institutional Resources

Contacting your institution’s privacy, records, or FERPA officer
Reviewing institutional data handling policies
Consulting with your institutional review board (IRB)
Attending FERPA training sessions

Package Resources

Package documentation: ?engager
Privacy masking: ?ensure_privacy and getOption("engager.privacy_level")
Privacy review functions: ?review_privacy_risks, ?anonymize_educational_data
Report generation: ?generate_privacy_review_report

Conclusion

Privacy review can be important when working with student data. This package provides tools that support privacy-conscious workflows, but responsibility for authorization, legal interpretation, and institutional policy compliance remains with the user and their institution. Consider reviewing official sources and institutional policies, and consult appropriate institutional officials when needed.

A useful working posture is privacy by design, with local review before sharing.

Privacy, Ethics, and Institutional Review Considerations