چرا نقش‌های وردپرس در سایت‌های روانشناسی نیاز به تنظیمات درمانی دارند؟

نقش‌های وردپرس در سایت‌های روانشناسی به‌دلیل ماهیت محرمانه پرونده درمانی، رابطه دوتایی درمانگر-مراجع، و الزامات قانونی حفاظت از داده سلامت، نیازمند تنظیمات درمانی اختصاصی هستند. یک درمانگر نباید به پرونده همه مراجعان دسترسی داشته باشد؛ باید فقط به مراجعان تخصیص‌یافته خودش دسترسی داشته باشد. یک مراجع نباید به پرونده سایر مراجعان یا به داده پرداخت آن‌ها نفوذ کند. بدون تنظیمات درمانی، اعتماد درمانی از بین می‌رود و کل پلتفرم مشمول نقض قوانین حفاظت از داده سلامت می‌شود.

سایت‌های روانشناسی با داده‌های سلامت روانی سر و کار دارند که حساس‌ترین دسته داده شخصی محسوب می‌شود. مدل نقش پیش‌فرض وردپرس برای تفکیک رابطه درمانگر-مراجع طراحی نشده و نمی‌تواند محرمانگی پرونده را تضمین کند. بدون تنظیمات درمانی، خطر نشت داده، نقض قوانین حفاظت از داده، و از دست رفتن اعتماد مراجع وجود دارد. راه‌حل عملی، تعریف نقش‌های سفارشی، رمزنگاری پرونده درمانی، و ثبت دقیق رضایت آگاهانه مراجع است. این مقاله معماری کامل نقش‌ها، دسترسی‌های داده درمانی، و نکات امنیتی این حوزه را بررسی می‌کند.

در پروژه‌ای که برای یک کلینیک روان‌درمانی طراحی می‌کردم، نخستین بحران از یک نکته کوچک شروع شد: یک درمانگر توانست پرونده مراجع دیگری را ببیند. آن شب دریافتیم که در روانشناسی، محرمانگی نه یک قابلیت، بلکه پیش‌شرط اخلاقی درمان است و هر نقص در آن، می‌تواند به از دست رفتن مجوز حرفه‌ای منجر شود.

چرا نقش‌های پیش‌فرض وردپرس کافی نیستند؟

وردپرس شش نقش پیش‌فرض دارد که حول مدیریت محتوا ساخته شده‌اند. در سایت روانشناسی، این نقش‌ها با شکاف‌های جدی روبه‌رو می‌شوند:

• نبود تفکیک پرونده درمانی: هر مراجع یک پرونده اختصاصی دارد که باید فقط در اختیار درمانگر تخصیص‌یافته باشد.
• نبود رابطه دوتایی درمانگر-مراجع: دسترسی باید بر اساس این رابطه تعریف شود، نه فقط بر اساس نقش.
• نبود مدیریت رضایت: دسترسی به پرونده باید فقط با رضایت آگاهانه و قابل لغو مراجع فعال باشد.
• ریسک نقض قوانین داده سلامت: داده سلامت روانی مشمول سخت‌گیرانه‌ترین قوانین حریم خصوصی است.

در سایت روانشناسی، دسترسی نادرست به پرونده، یک اشتباه فنی نیست؛ یک نقض اخلاقی و حقوقی است.

برای درک مفاهیم پایه نقش و دسترسی، مطلب مدیریت نقش‌ها و دسترسی‌ها در وردپرس را ببینید. همچنین اگر به انتخاب افزونه مدیریت کاربران فکر می‌کنید، مطلب انتخاب افزونه مدیریت کاربران وردپرس راهنمای دقیقی است.

نقش‌های ضروری در سایت روانشناسی

مراجع (Client)

دسترسی به جلسات شخصی، مشاهده فاکتور خودش، ثبت رضایت یا لغو آن، بدون هیچ دسترسی به پرونده سایر مراجعان.

درمانگر (Therapist)

دسترسی به پرونده مراجعان تخصیص‌یافته، ثبت یادداشت بالینی، تنظیم زمان جلسات، بدون دسترسی به داده پرداخت مراجعان.

سرپرست بالینی (Clinical Supervisor)

مشاهده یادداشت‌های درمانگران زیرمجموعه، اما فقط با رضایت صریح مراجع و در بازه مشخص.

مدیر پذیرش (Intake Coordinator)

مدیریت تخصیص درمانگر به مراجع، زمان‌بندی جلسه اول، بدون دسترسی به محتوای جلسات.

مدیر کلینیک (Clinic Manager)

مدیریت عملیاتی، گزارش‌های تجمیعی، بدون دسترسی مستقیم به محتوای بالینی.

چالش‌های داده درمانی

پیش از ورود به پیاده‌سازی، باید چالش‌های خاص داده درمانی را دقیق بشناسیم. این چالش‌ها ماهیت اخلاقی و حقوقی دارند، نه فقط فنی.

۱. محرمانگی مطلق پرونده

درمانگر قانوناً موظف به محرمانگی است. در معماری سیستم، این یعنی حتی مدیر سرور نیز نباید بدون رضایت مراجع به محتوای پرونده دسترسی داشته باشد. این نیازمند رمزنگاری در سمت سرور با کلید اختصاصی هر درمانگر است. برای مطالعه بیشتر درباره متادیتای کاربر، مطلب کار با User Meta در وردپرس را ببینید.

۲. رابطه دوتایی

رابطه درمانی همیشه دوتایی است. مدل نقش وردپرس بر پایه گروه‌بندی است، نه بر پایه رابطه دوتایی. برای پر کردن این شکاف، باید از یک لایه واسط استفاده شود که این رابطه را نگهداری کند. مطلب پیاده‌سازی درست Custom Post Type نقطه شروع مناسبی است.

۳. رضایت آگاهانه

هر دسترسی به پرونده باید مبتنی بر رضایت آگاهانه مراجع باشد. این رضایت باید قابل لغو باشد و تاریخچه کامل آن نگهداری شود. هرچه دسترسی به داده، باید توسط یک جدول Consent پشتیبانی شود.

۴. داده سلامت و GDPR

داده سلامت روانی در سخت‌گیرانه‌ترین دسته داده GDPR قرار می‌گیرد. این یعنی هرگونه دسترسی، حتی توسط کارکنان داخلی، باید لاگ شود و به مراجع قابل گزارش باشد. مطلب انطباق با GDPR در پروژه وردپرس مرور دقیقی از الزامات ارائه می‌دهد.

۵. کنترل دسترسی بر اساس زمان

دسترسی درمانگر به پرونده، پس از پایان رابطه درمانی باید محدود شود. این نیازمند یک لایه کنترل زمان‌محور است که در نقش پیش‌فرض وردپرس وجود ندارد.

تنظیمات درمانی برای هر نقش

پیاده‌سازی با PHP

ابتدا CPT پرونده درمانی را می‌سازیم. برای مطالعه بیشتر، مطلب پیاده‌سازی درست Custom Post Type را ببینید.

function wk_register_therapy_record_cpt() {
    register_post_type('wk_therapy_record', array(
        'label' => 'پرونده‌های درمانی',
        'public' => false,
        'show_ui' => true,
        'capability_type' => 'wk_therapy_record',
        'capabilities' => array(
            'read_post' => 'read_wk_therapy_record',
            'edit_post' => 'edit_wk_therapy_record',
            'edit_posts' => 'edit_wk_therapy_records',
            'edit_others_posts' => 'edit_others_wk_therapy_records',
        ),
        'map_meta_cap' => true,
        'supports' => array('title', 'author', 'custom-fields'),
    ));
}
add_action('init', 'wk_register_therapy_record_cpt');

سپس نقش‌های سفارشی را می‌سازیم. برای درک بهتر هوک‌ها، مطلب هوک‌های وردپرس را ببینید.

function wk_register_therapy_roles() {
    add_role('wk_client', 'مراجع', array(
        'read' => true,
        'read_own_therapy_record' => true,
        'read_own_invoices' => true,
    ));

    add_role('wk_therapist', 'درمانگر', array(
        'read' => true,
        'edit_wk_therapy_records' => true,
        'edit_others_wk_therapy_records' => true,
        'read_wk_clinical_notes' => true,
        'edit_wk_clinical_notes' => true,
        'schedule_wk_sessions' => true,
    ));

    add_role('wk_clinical_supervisor', 'سرپرست بالینی', array(
        'read' => true,
        'read_wk_clinical_notes' => true,
        'review_wk_therapy_records' => true,
    ));

    add_role('wk_intake_coordinator', 'مدیر پذیرش', array(
        'read' => true,
        'assign_wk_therapists' => true,
        'manage_wk_schedules' => true,
    ));
}
add_action('init', 'wk_register_therapy_roles');

برای اعتبارسنجی و پاک‌سازی داده‌های ورودی، مطلب اعتبارسنجی داده‌ها در کدنویسی وردپرس را ببینید. همچنین برای پاک‌سازی، مطلب پاک‌سازی داده‌ها در کدنویسی وردپرس مرور دقیقی ارائه می‌دهد. برای محافظت از فرم‌های درمانی در برابر CSRF، مطلب نانس وردپرس و امنیت فرم را ببینید.

پرونده درمانی و محرمانگی

پرونده درمانی حساس‌ترین دارایی یک سایت روانشناسی است. روش ذخیره‌سازی باید رمزنگاری سمت سرور با کلید اختصاصی هر درمانگر باشد:

function wk_save_clinical_note($record_id, $therapist_id, $note) {
    if (!current_user_can('edit_wk_clinical_notes')) {
        return new WP_Error('forbidden', 'دسترسی غیرمجاز');
    }
    $key = wk_get_therapist_key($therapist_id);
    $iv = random_bytes(12);
    $tag = '';
    $cipher = openssl_encrypt($note, 'aes-256-gcm', $key, OPENSSL_RAW_DATA, $iv, $tag);
    update_post_meta($record_id, 'wk_clinical_note', base64_encode($cipher));
    update_post_meta($record_id, 'wk_clinical_iv', base64_encode($iv));
    update_post_meta($record_id, 'wk_clinical_tag', base64_encode($tag));
}

نکته کلیدی: کلید رمزنگاری هر درمانگر باید در یک Vault جدا ذخیره شود، نه در دیتابیس وردپرس. اگر کلید در همان دیتابیس باشد، رمزنگاری بی‌اثر است.

برای مدیریت فایل‌های پیوست پرونده، مطلب توابع وردپرس برای کار با فایل‌ها را ببینید. همچنین مطلب فیلدهای سفارشی ACF و کاربردهای واقعی آن برای ساختاردهی داده درمانی مفید است.

امنیت، رضایت و حریم خصوصی

سه لایه امنیتی ضروری است:

1. رمزنگاری پرونده درمانی با کلید اختصاصی هر درمانگر.
2. ثبت رضایت آگاهانه مراجع و لاگ کامل هر دسترسی.
3. احراز هویت چندلایه برای همه نقش‌ها، بدون استثنا.

برای مطالعه بیشتر درباره کدنویسی امن، مطلب نوشتن کد PHP امن برای وردپرس را ببینید. برای امن‌سازی نشست‌ها، مطلب امن‌سازی نشست‌های کاربری راهنمای دقیقی است. فعال‌سازی احراز هویت دو مرحله‌ای، مطلب فعال‌سازی احراز هویت دو مرحله‌ای 2FA در وردپرس را ببینید.

از منظر حقوقی، داده سلامت روانی در سخت‌گیرانه‌ترین دسته قرار می‌گیرد. استاندارد بین‌المللی Psychotherapy در ویکی‌پدیا توضیحات جامعی درباره اصول اخلاقی این حوزه دارد و می‌تواند مرجع شروع باشد.

پرسش‌های پرتکرار درباره تنظیمات نقش درمانی

آیا می‌توانم از نقش Author برای درمانگر استفاده کنم؟

خیر. Author به همه پست‌های خودش دسترسی دارد، اما هیچ مکانیزمی برای تفکیک پرونده درمانی از سایر محتوا وجود ندارد. باید نقش سفارشی با Capability اختصاصی بسازید.

چگونه محرمانگی پرونده را تضمین کنم؟

با رمزنگاری AES-256-GCM در سمت سرور و ذخیره کلید در Vault جداگانه. بدون این لایه، حتی مدیر سرور می‌تواند محتوای پرونده را ببیند.

آیا سرپرست بالینی باید به پرونده دسترسی داشته باشد؟

فقط با رضایت صریح مراجع و در بازه مشخص. این دسترسی باید لاگ شود و به مراجع قابل گزارش باشد.

چگونه داده پرداخت را از درمانگر جدا کنم؟

با نگهداری داده پرداخت در CPT جداگانه و نقش اختصاصی. درمانگر فقط به فاکتور خودش دسترسی داشته باشد، نه به فاکتور مراجع.

آیا GDPR برای سایت روانشناسی ایران هم اعمال می‌شود؟

اگر مراجعان اروپایی دارید، بله. حتی بدون آن، رعایت اصول GDPR به‌عنوان استاندارد طلایی توصیه می‌شود. مطلب GDPR و تأثیر آن بر وب‌سایت‌های ایرانی را ببینید.

اشتباهات رایج

نگاه معماری در سطح سیستم‌های درمانی

در سطح معماری سیستم، سایت روانشناسی با یک محدودیت بنیادین وردپرس روبه‌روست: مدل نقش وردپرس بر پایه «گروه‌بندی کاربران» است، در حالی که در روانشناسی، رابطه درمانگر-مراجع یک رابطه دوتایی و منحصربه‌فرد است. این یعنی نیازمند یک لایه ABAC (Attribute-Based Access Control) هستیم که فراتر از نقش، ویژگی‌های رابطه را نیز در نظر بگیرد.

رویکرد پیشنهادی، معماری «Relationship-Based Access Control» است. دسترسی بر اساس ترکیب (کاربر، نقش، مراجع، جلسه، رضایت، زمان) تعیین می‌شود. هر تصمیم دسترسی از یک Policy Engine مرکزی استعلام می‌شود. این معماری هم منعطف است و هم قابل ممیزی.

نکته دوم، بحث «Zero-Knowledge Storage» است. برای محرمانگی مطلق، باید پرونده‌ها به‌گونه‌ای ذخیره شوند که حتی سرور نتواند آن‌ها را بخواند. این نیازمند رمزنگاری سمت کاربر با کلید مشتق‌شده از رمز عبور است. در این معماری، اگر سرور به‌طور کامل نفوذ شود، محتوای پرونده‌ها فاش نمی‌شود.

نکته سوم، بحث «Consent Management» است. هر دسترسی سرپرست باید مبتنی بر رضایت صریح و قابل لغو مراجع باشد. یک سیستم Consent حرفه‌ای باید بتواند رضایت‌ها را با دانه‌بندی دقیق (مثلاً فقط یادداشت‌های جلسه ششم) ثبت کند و به مراجع گزارش دقیق دهد.

پیشنهادهای عملی برای پیاده‌سازی

سه توصیه عملی که در پروژه‌های واقعی مؤثر بوده‌اند:

1. کلید رمزنگاری را در یک Vault جدا (مثل HashiCorp Vault) نگهداری کنید، نه در دیتابیس.
2. هر تصمیم دسترسی را در یک لاگ تغییرناپذیر ذخیره کنید تا در صورت شکایت، قابل ارائه باشد.
3. یک Endpoint عمومی برای تأیید رضایت طراحی کنید تا مراجع بتواند هر زمان وضعیت دسترسی‌ها را ببیند.

اگر این چالش‌ها را در یک پروژه واقعی تجربه کرده‌اید، برای ما جالب است بدانید کدام بخش بیشترین زمان را گرفت: طراحی مدل دسترسی، رمزنگاری پرونده، یا مدیریت رضایت. تجربه خود را در دیدگاه‌ها بنویسید؛ به‌خصوص اگر راه‌حل متفاوتی پیدا کرده‌اید که می‌تواند برای خواننده بعدی مفید باشد.