نمونه‌کارها / ریوایز مقاله و پاسخ به داوران / CASE 04

CASE 04 · ANONYMIZED Evidence-based Case Study

پردازش تصویر پزشکی و تصویربرداری سه‌بعدی

Longitudinal 3D Imaging · Multimodal Deep Learning · Evaluation Integrity

نمونه‌ای از ریوایز فنی که تمرکز آن فقط بر بهبود متن نبود؛ ریسک Data Leakage در داده‌های طولی کنترل شد، annotation بین دیتاست‌ها همسان‌سازی شد، Registration QC از ارزیابی اصلی جدا شد و ادعاهای بالینی به سطحی محدود شدند که شواهد واقعاً پشتیبانی می‌کردند.

حوزه3D Medical Imaging

نوع پروژهRevision & Response to Reviewers

ریسک محوریLeakage · Domain Shift

ارزیابیHeld-out Patient-level Test

Paired Longitudinal CBCT–IOS Data

CBCT volume + IOS/tooth labels → patient-level longitudinal pairing

CBCT Volume

IOS / Tooth Labels

Longitudinal patient pairing

Patient-level Split FDI Harmonization Registration QC Clinical Claim Control

این Case Study به‌صورت ناشناس‌شده بازسازی شده است. عنوان مقاله، نام نویسندگان، ژورنال، Submission ID و هر جزئیات قابل شناسایی در نسخه عمومی حذف شده‌اند.

کامنت داوراستخراج نگرانی واقعی

تحلیل و تشخیصریسک روش‌شناختی

تصمیم علمیانتخاب اصلاح قابل دفاع

اصلاح مقالهروش، نتایج و محدودیت‌ها

پاسخ به داورPoint-by-point و مستند

اعتبارسنجی نهاییسازگاری ادعا و شواهد

PROOF OF EXPERTISE

در این پروژه دقیقاً چه کاری انجام شد؟

این Case فقط خلاصه تغییرات مقاله نیست. مسیر زیر نشان می‌دهد کامنت داور چگونه به تشخیص روش‌شناختی، اصلاح واقعی Manuscript و یک پاسخ Point-by-Point قابل ردیابی تبدیل شد.

01 · DIAGNOSEشناسایی ریسک Temporal Leakage در داده طولی

02 · REDESIGNشفاف‌سازی Patient-level Split و کنترل Subject Overlap

03 · HARMONIZEیکسان‌سازی Annotationها و توضیح Domain Shift

04 · SAFEGUARDجداکردن Primary Evaluation از QC Sensitivity Analysis

05 · CONTROL CLAIMSمحدودکردن ادعای Clinical Validation به Technical Feasibility

تحلیل متخصص پشت یک کامنت

Potential temporal leakage → optimistic test performance

درخواست ظاهری داورتوضیح دهید patient-level split چگونه انجام شده و test set چه کیس‌هایی دارد.

مسئله واقعیاگر sessionهای یک بیمار بین subsetها پخش شوند، عملکرد test می‌تواند بیش‌برآورد شود.

تصمیم علمیSubject-exclusive split قبل از preprocessing/training + بررسی مستقل overlap.

کنترل کیفیتحفظ metal artifact، missing/extracted teeth و prosthetic/denture findings در held-out test set.

نمونه‌ای از ساختار پاسخ نهایی به داور

REVIEWER COMMENT

Please clarify how the patient-level split was performed and whether the independent test set contains challenging non-ideal cases.

RESPONSE

We clarified that patient-level splitting was performed using anonymized subject identifiers before preprocessing, augmentation, model training, or hyperparameter tuning. All sessions belonging to the same subject were assigned exclusively to one subset, and the absence of subject overlap was independently checked. We also clarified that the held-out test set intentionally retained challenging cases including artifacts, missing/extracted teeth, and prosthetic or denture-related findings.

Where changed: Section 3.1 · Tables 1–2

✓ کامنت داور کامل پوشش داده شد ✓ تغییر مقاله با پاسخ Cross-check شد ✓ Section/Table location مشخص شد ✓ Claim فراتر از Evidence نرفت ✓ ارزیابی اصلی از QC جدا شد ✓ اصطلاحات و منطق پاسخ یکپارچه ماند

ردیابی پاسخ: جلوگیری از Data Leakage در داده طولی

مهم‌ترین پرسش این نبود که «تقسیم داده انجام شده یا نه»؛ داور می‌خواست بداند آیا sessionهای یک بیمار می‌توانند ناخواسته بین train و test پخش شده باشند.

1 · REVIEWER CONCERN

Patient-level Split دقیقاً چگونه انجام شد؟

داور درباره مبنای تقسیم بیماران و همچنین حضور کیس‌های دشوار مانند metal artifact، missing/extracted teeth و prosthetic/denture findings در test set سؤال داشت.

2 · EXPERT INTERPRETATION

ریسک اصلی: Temporal Leakage

تمام sessionهای یک subject باید فقط در یک subset باشند.
Split باید قبل از preprocessing، augmentation و tuning انجام شود.
Test set باید کیس‌های غیرایده‌آل را حفظ کند.

3 · MANUSCRIPT REVISION

تعریف صریح پروتکل Split

تقسیم با anonymized subject identifiers.
Train / Validation / Test در سطح بیمار.
کنترل مستقل برای نبود subject overlap.
Challenging-case distribution برای held-out test set.

4 · RESPONSE TO REVIEWER

پاسخ از ادعا به پروتکل قابل ممیزی تبدیل شد

تقسیم در سطح بیمار پیش از هر preprocessing، augmentation، training یا hyperparameter tuning انجام شد؛ تمام sessionهای یک فرد فقط به یک subset اختصاص یافتند و نبود هم‌پوشانی subjectها جداگانه بررسی شد.

نگرانی داور	ریسک علمی	اقدام انجام‌شده	محل اصلاح	Evidence
Patient-level split و test composition	Temporal leakage و test set بیش‌ازحد آسان	Subject-exclusive split + independent overlap check + challenging cases	Section 3.1 · Tables 1–2	Leakage Control
اختلاف annotation بین دو dataset	Label inconsistency و cross-dataset bias	Mapping به FDI + manual review موارد ambiguous/missing/unmatched	Section 3.1 · Section 5.2 · Discussion	FDI Mapping
Registration QC و exclusion bias	بهبود مصنوعی metric با حذف registrationهای دشوار	Primary evaluation روی full held-out set؛ QC-filtered فقط sensitivity analysis	Sections 5.1, 5.4, 5.8	All-case Primary
نبود convergence analysis	نامشخص بودن stability و overfitting behavior	Train/validation loss + validation Dice + TLC در 5 run مستقل	Sections 5.5, 5.7 · Figures 5a, 5b, 8	5-run Stability
ادعای universality / clinical validation	Overclaim فراتر از شواهد public datasets	بازنویسی به technical feasibility + نیاز به larger multi-center validation	Abstract · Introduction · 5.2 · Discussion · Conclusion	Claim Control

Evidence 01 — معماری درست Patient-level Split

این بخش عمداً نشان می‌دهد که واحد تقسیم «تصویر یا session» نیست؛ واحد تقسیم، subject است.

TRAIN Subject A · تمام sessionها

←

VALIDATION Subject B · تمام sessionها

←

TEST Subject C · تمام sessionها + challenging cases

قانون کلیدی: هیچ subject نباید در بیش از یک subset ظاهر شود؛ این کنترل قبل از preprocessing، augmentation، training و hyperparameter tuning انجام می‌شود.

Evidence 02 — Annotation Harmonization بین Datasetها

اختلاف annotation صرفاً یک مسئله ظاهری نیست؛ می‌تواند مستقیماً cross-dataset evaluation را منحرف کند.

Dataset-specific labels

A-01A-02missing?unmatched

→

FDI harmonized labels

1112manual review

موارد ambiguous، missing یا unmatched به‌صورت دستی بازبینی و اصلاح شدند؛ با این حال residual annotation/acquisition differences همچنان به‌عنوان منبع بالقوه Domain Shift در مقاله حفظ شدند.

Registration QC بدون دست‌کاری ارزیابی اصلی

حذف registrationهای دشوار می‌تواند نتیجه را غیرواقعی بهتر نشان دهد. پاسخ حرفه‌ای این بود که QC به ابزار حساسیت تبدیل شود، نه فیلتر پنهان برای metric اصلی.

Primary Results

Full independent held-out test set
پیش از QC-based filtering؛ شامل کیس‌های دشوار.

≠

QC Sensitivity Analysis

QC-filtered results فقط برای خروجی‌های registration-dependent و به‌عنوان sensitivity analysis گزارش می‌شوند.

شواهد همگرایی آموزش (Training Convergence)

نمودارهای این بخش عمداً شماتیک اما استاندارد رسم شده‌اند: Loss باید روند نزولی و Dice/TLC روند افزایشی داشته باشند. اعداد واقعی بدون منبع بازسازی نشده‌اند؛ هدف، نمایش دقیق منطق Evidence است.

Training / Validation Loss

Training loss Validation loss

نمای شماتیک ساختار گزارش است؛ هدف، نمایش منطق و جهت تغییرات است نه بازسازی اعداد واقعی بدون منبع.

Validation Dice / Temporal Label Consistency

Validation Dice Validation TLC

در پاسخ واقعی، این تحلیل بر training loss، validation loss، validation Dice و validation TLC در پنج اجرای مستقل بنا شده بود.

کنترل ادعا: از «Clinical Universality» تا «Technical Feasibility»

یکی از حرفه‌ای‌ترین بخش‌های ریوایز، کم‌کردن ادعا در جایی بود که شواهد برای deployment بالینی کافی نبود.

ادعای بیش‌ازحد گسترده

تعمیم مستقیم نتایج به محیط‌های بالینی، scannerهای مختلف، acquisition protocolهای متفاوت و جمعیت‌های مستقل.

←

ادعای اصلاح‌شده و قابل دفاع

روش به‌عنوان technical feasibility روی دو public paired CBCT–IOS dataset معرفی شد؛ cross-dataset evaluation به‌عنوان technical robustness under dataset shift تفسیر شد و نه prospective clinical validation. نیاز به larger multi-center validation پیش از clinical deployment صریحاً ذکر شد.

چرا این پاسخ سطح حرفه‌ای را نشان می‌دهد؟

چون بخش‌های حساس روش ارزیابی و ادعا به‌صورت مستقل audit شده‌اند.

⛓

Leakage Prevention

Sessionها با subject-level split از هم جدا شدند.

⌘

Label Harmonization

Annotationها به FDI نگاشت و موارد مبهم بازبینی شدند.

◎

Evaluation Integrity

QC فیلتر نتیجه اصلی نشد؛ sensitivity analysis باقی ماند.

✓

Clinical Claim Control

نتیجه از universality به technical feasibility محدود شد.

این صفحه یک Case Study عمومی و ناشناس‌شده است. هیچ تضمینی درباره پذیرش مقاله ارائه نمی‌شود و مسئولیت علمی نهایی مقاله با نویسندگان است.