# MIKA De-ID Local - product requirements

Status: **LOCAL / SYNTHETIC DATA ONLY**  
Version: 0.2  
Date: 2026-08-27

## 1. Purpose

MIKA De-ID Local helps a patient create a new review copy of a medical document with direct identifiers removed before the patient submits that copy to a protected MIKA workflow.

The product supports medical navigation. It does not diagnose, prescribe treatment, determine clinical-trial eligibility, prove enrollment, or replace a clinician or coordinator. The source document remains under the patient's control.

## 2. Intended user

- A patient or authorized representative using a personal Windows or macOS computer
- Later, an authorized MIKA coordinator using the same local review workflow

## 3. Primary user journey

1. The user selects a PDF or photograph.
2. The application opens it locally without uploading it.
3. Every page is rendered to pixels.
4. Native PDF text, OCR text, and barcodes are analyzed locally.
5. Proposed redactions are displayed without exporting detected source text.
6. The user adds, removes, or adjusts redaction regions.
7. The user confirms every page.
8. The application creates a new raster-only PDF in a temporary location.
9. The result is reopened, structurally inspected, rendered again, OCR-scanned again, and barcode-scanned again.
10. Only a passing copy is moved to the user-selected destination.
11. A log-safe verification report is written next to the output.
12. The user independently decides whether to submit the cleaned copy to MIKA.

## 4. In scope for v0.2

- PDF, JPEG, PNG, TIFF, and optional HEIC/HEIF input
- Russian and English printed text
- Direct identifier patterns
- Contextual name, date of birth, address, insurance, and medical-record rules
- QR and one-dimensional barcode regions
- Manual redaction rectangles
- Page-by-page confirmation
- New raster-only PDF generation
- Structural and OCR/barcode re-verification
- Log-safe JSON analysis and verification reports
- Synthetic test documents

## 5. Explicitly out of scope for v0.2

- DICOM
- Guaranteed handwriting recognition
- Automated face and signature classification
- Cloud OCR or cloud language models
- Direct upload to MIKA
- Background synchronization
- Account linking
- Re-identification
- Preservation of digital signatures
- Legal certification of anonymity
- Diagnosis, treatment, triage, eligibility, or enrollment decisions

## 6. Functional requirements

### Input

- Reject missing, empty, encrypted, malformed, oversized, and over-page-limit files.
- Determine PDF by file signature, not only the extension.
- Apply image decompression limits.
- Never overwrite the source.

### Detection

- Analyze native PDF words and rendered pixels.
- Run OCR locally for every page, including PDFs with native text.
- Detect all configured direct identifier classes, including labelled surname/FIO fields and surname-plus-initial forms.
- Detect barcodes without recording decoded content in exported reports.
- Mark exact clinical event dates as visible review candidates but keep them unselected for redaction by default.
- Flag low OCR confidence and unreadable pages.

### Review

- Show the full page image.
- Show each finding by category and region.
- Preserve every `REVIEW` category by default; only an explicit user action may add it to the redaction set.
- Allow a selected finding to be disabled, with page confirmation invalidated.
- Allow manual regions to be added, with page confirmation invalidated.
- Require confirmation of every page.
- Never mark an unreadable page as safe automatically.

### Output

- Create a new file; do not modify or append to the source.
- Redact pixels with an opaque fill plus margin.
- Copy no source PDF object, text layer, annotation, form, attachment, JavaScript, filename, or metadata.
- Produce no searchable OCR layer in v0.2.
- Use neutral application metadata only.
- Refuse existing output paths.

### Verification

- Reopen with a strict PDF parser.
- Require the expected page count.
- Require zero annotations, fields, embedded files, JavaScript, and active actions.
- Require zero extractable text in raster-only mode.
- Render the output again.
- Run independent OCR and barcode detection again.
- Block release if a critical residual category is detected.
- Verify that the source hash did not change during processing.

## 7. Non-functional requirements

- Local-only processing without a network dependency
- No document text in logs or crash reports
- No analytics on processing screens
- No administrator privileges for normal use
- Deterministic category policy per release
- Signed installers and signed updates before patient release
- Reproducible dependency and model manifests
- Russian-language interface and documentation
- Clear failure states and no false success
- Open distribution under `AGPL-3.0-only`, with NPO NT copyright and exact Corresponding Source paired with every future binary
- In-application copyright, licence, source-access, and no-warranty notice
- No implication that open software makes patient documents or medical datasets public

## 8. Success criteria

The prototype succeeds when it can process the locked synthetic corpus end to end, preserve every source byte, remove all annotated direct identifiers in the corpus, reject incomplete capabilities, create a structurally clean raster PDF, and pass manual visual inspection.

Production success additionally requires a lawful representative dataset, independent security and privacy review, clinical utility review, signed distribution, controlled pilot evidence, and the release gates in `RELEASE_GATES.md`.
