---
title: "Privacy, Ethics, and Institutional Review Considerations"
output: rmarkdown::html_vignette
vignette: >
  %\VignetteIndexEntry{Privacy, Ethics, and Institutional Review Considerations}
  %\VignetteEngine{knitr::rmarkdown}
  %\VignetteEncoding{UTF-8}
---

```{r setup, include=FALSE}
knitr::opts_chunk$set(collapse = TRUE, comment = "#>")
```

# 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:

```r
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:

```r
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:

```r
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:

```r
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:

```r
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:

```r
# 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.

```r
# 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:

```{r privacy-reporting-example}
# 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:

```r
# 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:

```r
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:

```r
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:

```r
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
- [ ] Review official FERPA sources and institutional policies
- [ ] Document authorization or local review path
- [ ] Set up secure data environment
- [ ] Configure privacy defaults

### During Analysis
- [ ] Use privacy-supporting functions
- [ ] Review data for privacy risks
- [ ] Limit data access
- [ ] Monitor data usage

### Post-Analysis
- [ ] Review whether outputs are masked, aggregated, or otherwise appropriate
- [ ] Secure result storage
- [ ] Dispose of raw data
- [ ] Document procedures

### Ongoing
- [ ] Regular technical privacy reviews
- [ ] Staff training updates
- [ ] Policy reviews
- [ ] Security assessments

## 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:

```r
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:

```r
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:

```r
# 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:

```r
# 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:

```r
# 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**.