یک فایل پراکنده اکسل ممکن است برای ثبت اولیه ساده باشد، اما با چند مرکز، مراجعه تکراری و افراد واردکننده متعدد، کنترل نسخه و خطا دشوار می‌شود. REDCap بستری برای ساخت فرم و مدیریت داده پژوهشی است که معمولاً از طریق مؤسسه عضو و استقرار محلی آن ارائه می‌شود. این راهنما درباره طراحی پژوهشی و کنترل داده است؛ تصویرهای آن شماتیک آموزشی‌اند و اسکرین‌شات یک سامانه واقعی محسوب نمی‌شوند.
REDCap چیست و چگونه به آن دسترسی می‌گیریم؟
REDCap از طریق شبکه مؤسسات همکار برای کاربردهای پژوهشی توسعه یافته است. داشتن نرم‌افزار بدون هزینه مجوز برای مؤسسه واجد شرایط، به معنی حساب عمومی رایگان برای هر فرد یا نبود هزینه میزبانی و پشتیبانی نیست. ابتدا از واحد پژوهش، فناوری اطلاعات یا مرکز داده دانشگاه بپرسید آیا استقرار تأییدشده وجود دارد و چه فرایندی برای ایجاد پروژه لازم است.
امکانات و مجوزهای کاربر به نسخه، تنظیمات و سیاست مؤسسه بستگی دارد. این متن تأیید نمی‌کند که هر نصب، برای نگهداری هر نوع داده حساس مجاز است. الزامات محل پژوهش، رضایت و مصوبه اخلاق را بررسی کنید؛ نام یک استاندارد خارجی به‌تنهایی تکلیف حفاظت داده در ایران را تعیین نمی‌کند.
قبل از فرم، فرهنگ داده بسازید
برای هر متغیر نام فنی، عنوان فارسی، نوع، گزینه‌ها، واحد، زمان سنجش و قاعده گمشده را بنویسید. نام‌هایی مانند q1 و q2 بدون فرهنگ داده در تحلیل بعدی مبهم می‌شوند. بهتر است نام فنی کوتاه و پایدار و برچسب خوانا باشد؛ تغییر نام متغیر پس از شروع گردآوری می‌تواند خروجی و دستورهای تحلیل را مختل کند.
| نام فنی | عنوان | نوع و قاعده | زمان |
|---|---|---|---|
| study_id | شناسه پژوهشی | یکتا، بدون نام بیمار | ورود |
| age_years | سن به سال | عدد با دامنه متناسب پروتکل | خط پایه |
| visit_done | مراجعه انجام شد؟ | گزینه‌های ازپیش‌تعریف‌شده | هر مراجعه |
| outcome_score | نمره پیامد | براساس دستور ابزار واقعی | زمان تعریف‌شده پیامد |
شناسه پژوهشی با ناشناس‌سازی کامل یکسان نیست. اگر فایل اتصال شناسه به هویت وجود دارد، دسترسی و نگهداری آن باید جدا و محدود باشد. از قراردادن نام، کد ملی یا شماره تماس در نام رکورد یا فایل خروجی بدون ضرورت و مجوز پرهیز کنید.
انتخاب نوع فیلد و اعتبارسنجی
برای گزینه‌های محدود، فیلد انتخابی معمولاً از متن آزاد قابل کنترل‌تر است. واحد را کنار برچسب بنویسید و تاریخ را با قالب روشن بگیرید. دامنه معتبر باید به پروتکل و ابزار مربوط باشد؛ گذاشتن یک محدوده دلخواه ممکن است مقدار واقعی را غیرمجاز کند. هشدار نرم‌افزار باید امکان بررسی را فراهم کند، نه اینکه ورود اطلاعات واقعی را بی‌دلیل متوقف کند.
«پاسخ نمی‌دهد»، «نامشخص»، «انجام نشده» و صفر واقعی را از هم تفکیک کنید. اجباری‌کردن همه فیلدها می‌تواند کاربر را به انتخاب پاسخ غیرواقعی سوق دهد. قاعده فقدان داده باید با تحلیل آینده سازگار باشد؛ مدیریت داده گمشده را ببینید.
منطق شاخه‌ای را با سناریو آزمایش کنید
Branching logic کمک می‌کند پرسش وابسته فقط در شرایط مرتبط نمایش داده شود. مثلاً اگر یک مراجعه انجام نشده، فیلد نمره آن مراجعه نباید الزاماً مانند مراجعه انجام‌شده ظاهر شود. اما پنهان‌شدن فیلد لزوماً به معنی پاک‌شدن مقدار قبلی نیست؛ رفتار نسخه و تنظیمات را با داده آزمایشی کنترل کنید.
سناریوهای تغییر پاسخ، بازگشت به فرم، مقدار نامعلوم و اصلاح بعدی را آزمایش کنید. اگر منطق اشتباه باشد، ممکن است بخش مهمی از داده هرگز جمع‌آوری نشود. فرمول محاسبه نمره را نیز با چند نمونه دستی، شامل مرزها و داده ناقص، مقایسه کنید؛ یک خروجی عددی به معنی درست‌بودن فرمول نیست.
مطالعه طولی و فرم تکرارشونده
وقتی زمان‌های مشخصی مثل خط پایه و پیگیری دارید، ساختار طولی می‌تواند رویدادهای سنجش را سازمان دهد. وقتی تعداد رخدادها یا مراجعات برای هر فرد متفاوت است، ابزارهای تکرارشونده ممکن است مناسب باشند. این دو ساختار را براساس طراحی انتخاب کنید، نه فقط براساس راحتی ساخت فرم.
در خروجی، شناسه فرد، نام رویداد و شماره تکرار باید قابل تشخیص باشند. تحلیلگر باید بداند هر ردیف نماینده چیست؛ چند ردیف یک فرد را نباید مستقل فرض کرد. این هماهنگی را پیش از شروع گردآوری با برنامه تحلیل انجام دهید.
نقش‌ها، ثبت تغییر و خروجی داده
هر عضو تیم فقط دسترسی لازم برای وظیفه‌اش داشته باشد. واردکننده داده، ناظر و تحلیلگر الزاماً به یک سطح دسترسی یا اطلاعات هویتی نیاز ندارند. قابلیت‌های ثبت فعالیت و تغییر، اگر درست پیکربندی و استفاده شوند، به پیگیری اصلاحات کمک می‌کنند؛ وجود آن‌ها مسئولیت بازبینی را حذف نمی‌کند.
پیش از خروجی‌گرفتن، دامنه فیلدها و اطلاعات شناسایی را کنترل کنید. API یا ارسال خودکار داده نیازمند مجوز و حفاظت کلید است؛ کلید را در فایل عمومی، پیام‌رسان یا کد مخزن قرار ندهید. مسیر پشتیبان‌گیری، بازیابی و پایان نگهداری داده را از مسئول استقرار بپرسید.
از محیط آزمایشی تا گردآوری واقعی
- فرم را ابتدا با داده ساختگی و بدون هویت واقعی بسازید.
- چند نفر از تیم سناریوهای عادی و استثنا را اجرا کنند.
- فرمول، منطق شاخه‌ای، نقش‌ها و خروجی را کنترل کنید.
- فرهنگ داده و دستور ورود را نهایی کنید.
- فرایند تأیید انتقال به مرحله واقعی را طبق سیاست مؤسسه طی کنید.
- تغییرهای بعدی را نسخه‌بندی و اثرشان بر داده قبلی را بررسی کنید.
اگر ابزار یا پیامد پژوهش تغییر می‌کند، فقط اصلاح فرم کافی نیست؛ اثر آن بر پروتکل، اخلاق و ثبت مطالعه را نیز بررسی کنید. در اصلاح پروتکل مصوب و تعریف پیامد کارآزمایی این هماهنگی توضیح داده شده است.
خروجی خوب این مرحله چیست؟
یک فرم زیبا کافی نیست. خروجی قابل دفاع شامل فرهنگ داده، فرم آزمایش‌شده، راهنمای ورود، نقش‌های روشن، سابقه تغییر و نمونه خروجی قابل تحلیل است. اگر هرکدام غایب باشد، مشکل ممکن است پس از ماه‌ها گردآوری آشکار شود. برای هماهنگی سؤال، ابزار و برنامه داده می‌توانید از مشاوره پروپوزال استفاده کنید؛ دسترسی فنی و تأیید نگهداری اطلاعات باید از مؤسسه مسئول گرفته شود.
منابع و مطالعه بیشتر
- REDCap: معرفی نرم‌افزار و قابلیت‌ها.
- REDCap: پروژه و شبکه مؤسسات همکار.
- منابع آموزشی رسمی REDCap؛ مسیر آموزش و راهنمای استقرار مؤسسه را نیز بررسی کنید.
بازبینی محتوایی: ۱۳ آبان ۱۴۰۵. تصویر اصلی، ترکیب‌بندی مفهومی اختصاصی است؛ نمودارها و مثال‌های عددی آموزشی‌اند و داده واقعی پژوهش یا تصویر مستند یک مؤسسه معرفی نشده‌اند.
