Privacy, Ethics, and Institutional Review Considerations

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:

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

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

During Analysis

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

After Analysis

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

Institutional Review Checklist

This checklist may help support institutional privacy review:

Pre-Analysis

During Analysis

Post-Analysis

Ongoing

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.