# OpenScar Pilot Registry SOP

This SOP turns OpenScar Starter from a public skeleton into a small retrospective pilot workflow. It is designed for a plastic surgery team preparing 20-50 de-identified scar or keloid cases for research and workflow testing.

OpenScar remains a research and workflow-support framework. This SOP does not authorize diagnosis, treatment selection, patient-specific risk prediction, or public release of identifiable clinical content.

## Pilot Objective

Build a small, internally governed registry that can answer three practical questions:

1. Can routine scar and keloid records be converted into the OpenScar six-table schema?
2. Which fields are reliably available in retrospective records, and which require prospective collection?
3. Can clinician-reviewable AI workflows summarize lesion trajectory, treatment exposure, image quality, and outcome labels without using direct identifiers?

## Minimum Cohort

Target 20-50 retrospective cases.

Recommended first cohort:

- Adults or adolescents with postoperative scars, hypertrophic scars, or keloids managed in plastic surgery.
- At least one baseline clinical note and one follow-up note.
- At least one intervention or active observation period.
- At least one clinical image if photo governance allows de-identified internal research review.

Exclusions for the first pilot:

- Cases requiring emergency wound care interpretation.
- Cases with unclear consent or governance status for research export.
- Full-face identifiable images unless the pilot has explicit governance approval.
- Records where direct identifiers cannot be separated from the research table.

## Source Material

Acceptable internal sources:

- Structured EHR fields.
- De-identified clinic notes.
- De-identified procedure records.
- Secure image archive pointers.
- Existing scar scale forms, if available.

Do not place names, phone numbers, full birth dates, medical record numbers, exact calendar dates, full addresses, or unredacted full-face images into the OpenScar research export.

## Data Flow

1. Assign a de-identified `patient_id`.
2. Assign stable `lesion_id` values before entering visits, images, treatments, or outcomes.
3. Convert exact dates into `visit_date_offset_days` and `follow_up_days_from_baseline`.
4. Enter the six CSV tables in `data/templates/`.
5. Review image governance before recording any `image_uri`.
6. Run template and mock-data validators before building downstream scripts.
7. Keep a separate protected linkage file outside this repository if re-identification is required for approved internal review.

## Quality Gates

Each pilot case should pass these minimum checks:

- One patient row.
- At least one lesion row linked to the patient.
- At least two visit rows linked to the lesion.
- At least one image row or a documented reason image data is unavailable.
- At least one treatment row or a documented observation-only pathway.
- One outcome row with `outcome_confidence`.

Image quality should be marked conservatively. If angle, focus, lighting, or privacy redaction is uncertain, use `unknown` or `needs_review` rather than guessing.

## Review Roles

Suggested roles for a small team:

- Clinical abstractor: extracts structured values from records.
- Plastic surgery reviewer: resolves scar type, anatomic site, treatment exposure, and outcome label.
- Data steward: checks de-identification, file organization, and schema consistency.
- AI workflow reviewer: tests ScarClaw skills only on synthetic or approved de-identified material.

One person can hold multiple roles in an early pilot, but the review decisions should be explicit.

## Pilot Outputs

By the end of the pilot, create:

- A de-identified six-table registry export.
- A missingness summary by field.
- A list of fields that need prospective capture.
- A short image-quality summary.
- Three clinician-reviewed sample case summaries.
- A decision on whether to expand the schema or keep the first public interface stable.

## Stop Conditions

Pause the pilot if:

- Direct identifiers are found in research exports.
- Consent or governance status is ambiguous.
- The team starts using OpenScar outputs as patient-specific treatment recommendations.
- Image files cannot be governed securely.

## Next Extension

After this SOP works for 20-50 cases, the next useful extension is a prospective intake form that captures missing retrospective fields at the point of care.