پلتفرم مدیریت و بهره‌برداری از داده‌های پژوهشی و بالینی

چکیده

مسئله اصلی: نه کمبود داده، نیاز به مدیریت و حکمرانی یکپارچه داده

رویکرد تحلیل: استفاده از مدل مدیریت ریسک ساختاریافته BowTie برای شناسایی:

• عدم تحقق/عدم پیاده‌سازی پلتفرم
• نشت/دسترسی غیرمجاز داده
• مدیریت و استفاده از داده‌های حساس انسانی اخلاق، مدیریت و انطباق با داده‌ها
• شکست در هماهنگی و تقسیم مسئولیت‌ها

عدم تحقق/عدم پیاده‌سازی پلتفرم

flowchart LR

%% --- Hazard ---
subgraph HZ["Hazard"]
    H["پیچیدگی مدیریت داده‌های پزشکی در مقیاس ملی"]
end

%% --- Threats ---
subgraph TH["Threats / Causes"]
    T1["مقاومت سازمانی"]
    T2["عدم استانداردسازی"]
    T3["کمبود منابع"]
    T4["چالش‌های حقوقی"]
end

%% --- Preventive Barriers ---
subgraph PB["Preventive Barriers"]
    P1["Data Governance Framework"]
    P2["استانداردهای ملی (FHIR/OMOP)"]
    P3["تأمین بودجه و فازبندی"]
    P4["چارچوب حقوقی شفاف"]
end

%% --- Top Event ---
subgraph TE["Top Event"]
    TE1["عدم استقرار پلتفرم داده"]
end

%% --- Mitigative Barriers ---
subgraph MB["Mitigative Barriers"]
    M1["اجرای MVP / پایلوت"]
    M2["بازطراحی تدریجی"]
    M3["بهینه‌سازی با AI"]
end

%% --- Consequences ---
subgraph CS["Consequences"]
    C1["تداوم پراکندگی داده"]
    C2["عقب‌ماندگی در AI پزشکی"]
    C3["کاهش بهره‌وری علمی"]
end

%% --- Connections ---
H --> T1
H --> T2
H --> T3
H --> T4

T1 --> P1
T2 --> P2
T3 --> P3
T4 --> P4

P1 --> TE1
P2 --> TE1
P3 --> TE1
P4 --> TE1

TE1 --> M1
TE1 --> M2
TE1 --> M3

M1 --> C1
M2 --> C2
M3 --> C3

%% --- Styles ---
style H fill:#ffcc00,stroke:#333,stroke-width:3px
style T1 fill:#99ccff
style T2 fill:#99ccff
style T3 fill:#99ccff
style T4 fill:#99ccff
style P1 fill:#99ff99
style P2 fill:#99ff99
style P3 fill:#99ff99
style P4 fill:#99ff99
style TE1 fill:#ff3333,color:#fff,stroke-width:3px
style M1 fill:#ffcc99
style M2 fill:#ffcc99
style M3 fill:#ffcc99
style C1 fill:#cccccc
style C2 fill:#cccccc
style C3 fill:#cccccc

نشت/دسترسی غیرمجاز داده

flowchart LR

%% --- Hazard ---
subgraph HZ["Hazard"]
    H["تمرکز داده‌های حساس پزشکی"]
end

%% --- Threats ---
subgraph TH["Threats"]
    T1["حمله سایبری"]
    T2["عدم استانداردسازی"]
    T3["خطای انسانی"]
end

%% --- Preventive Barriers ---
subgraph PB["Preventive Barriers"]
    P1["رمزنگاری TLS/AES"]
    P2["کنترل دسترسی RBAC"]
    P3["استانداردسازی داده"]
end

%% --- Top Event ---
subgraph TE["Top Event"]
    TE1["نشت/دسترسی غیرمجاز داده"]
end

%% --- Mitigative Barriers ---
subgraph MB["Mitigative Barriers"]
    M1["IDS/IPS"]
    M2["پاسخ به حادثه + پشتیبان گیری"]
end

%% --- Consequences ---
subgraph CS["Consequences"]
    C1["نقض حریم خصوصی"]
    C2["اختلال پژوهشی"]
end

%% --- Connections ---
H --> T1
H --> T2
H --> T3

T1 --> P1
T2 --> P3
T3 --> P2

P1 --> TE1
P2 --> TE1
P3 --> TE1

TE1 --> M1
TE1 --> M2

M1 --> C1
M2 --> C2

%% --- Styles ---
style H fill:#ffcc00,stroke:#333,stroke-width:3px
style T1 fill:#99ccff
style T2 fill:#99ccff
style T3 fill:#99ccff
style P1 fill:#99ff99
style P2 fill:#99ff99
style P3 fill:#99ff99
style TE1 fill:#ff6666,color:#fff,stroke-width:3px
style M1 fill:#ffcc99
style M2 fill:#ffcc99
style C1 fill:#cccccc
style C2 fill:#cccccc

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

flowchart LR

%% --- Hazard ---
subgraph HZ["Hazard"]
    H["ریسک حاکمیت و استفاده از داده انسانی"]
end

%% --- Threats ---
subgraph TH["Threats / Causes"]
    T1["ابهام مالکیت داده"]
    T2["شکست مدیریت رضایت"]
    T3["عدم انطباق با IRB"]
    T4["استفاده ثانویه غیرمجاز"]
end

%% --- Preventive Barriers ---
subgraph PB["Preventive Barriers"]
    P1["Data Governance Framework"]
    P2["Consent Management System"]
    P3["IRB Workflow Integration"]
    P4["Policy-based Access Control"]
end

%% --- Top Event ---
subgraph TE["Top Event"]
    TE1["نقض الزامات اخلاقی/حقوقی"]
end

%% --- Mitigative Barriers ---
subgraph MB["Mitigative Barriers"]
    M1["Audit Trail"]
    M2["Access Revocation"]
    M3["Compliance Response"]
end

%% --- Consequences ---
subgraph CS["Consequences"]
    C1["توقف پروژه ملی"]
    C2["از دست رفتن اعتماد"]
    C3["ریسک حقوقی"]
end

%% --- Connections ---
H --> T1
H --> T2
H --> T3
H --> T4

T1 --> P1
T2 --> P2
T3 --> P3
T4 --> P4

P1 --> TE1
P2 --> TE1
P3 --> TE1
P4 --> TE1

TE1 --> M1
TE1 --> M2
TE1 --> M3

M1 --> C1
M2 --> C2
M3 --> C3

%% --- Styles ---
style H fill:#ffcc00,stroke:#333,stroke-width:3px
style T1 fill:#99ccff
style T2 fill:#99ccff
style T3 fill:#99ccff
style T4 fill:#99ccff
style P1 fill:#99ff99
style P2 fill:#99ff99
style P3 fill:#99ff99
style P4 fill:#99ff99
style TE1 fill:#ff3333,color:#fff,stroke-width:3px
style M1 fill:#ffcc99
style M2 fill:#ffcc99
style M3 fill:#ffcc99
style C1 fill:#cccccc
style C2 fill:#cccccc
style C3 fill:#cccccc

ساختار (Execution / Integration / Data Flow)

flowchart LR

%% --- Hazard ---
subgraph HZ["Hazard"]
    H["پیچیدگی و شکنندگی جریان داده"]
end

%% --- Threats ---
subgraph TH["Threats / Causes"]
    T1["شکست ETL"]
    T2["ناسازگاری Semantic / Mapping"]
    T3["خطای API Integration"]
    T4["کیفیت پایین داده"]
end

%% --- Preventive Barriers ---
subgraph PB["Preventive Barriers"]
    P1["ETL استاندارد + Validation"]
    P2["Canonical Model (FHIR/OMOP)"]
    P3["API Gateway + SLA"]
    P4["Data Quality Rules"]
end

%% --- Top Event ---
subgraph TE["Top Event"]
    TE1["Failure در Data Pipeline"]
end

%% --- Mitigative Barriers ---
subgraph MB["Mitigative Barriers"]
    M1["Monitoring & Alerting"]
    M2["Rollback / Recovery"]
    M3["Failover Pipelines"]
end

%% --- Consequences ---
subgraph CS["Consequences"]
    C1["عدم استفاده سیستم"]
    C2["نتایج پژوهشی غلط"]
    C3["از دست رفتن اعتماد"]
end

%% --- Connections ---
H --> T1
H --> T2
H --> T3
H --> T4

T1 --> P1
T2 --> P2
T3 --> P3
T4 --> P4

P1 --> TE1
P2 --> TE1
P3 --> TE1
P4 --> TE1

TE1 --> M1
TE1 --> M2
TE1 --> M3

M1 --> C1
M2 --> C2
M3 --> C3

%% --- Styles ---
style H fill:#ffcc00,stroke:#333,stroke-width:3px
style T1 fill:#99ccff
style T2 fill:#99ccff
style T3 fill:#99ccff
style T4 fill:#99ccff
style P1 fill:#99ff99
style P2 fill:#99ff99
style P3 fill:#99ff99
style P4 fill:#99ff99
style TE1 fill:#ff3333,color:#fff,stroke-width:3px
style M1 fill:#ffcc99
style M2 fill:#ffcc99
style M3 fill:#ffcc99
style C1 fill:#cccccc
style C2 fill:#cccccc
style C3 fill:#cccccc

شکست در هماهنگی و تقسیم مسئولیت‌ها

flowchart LR

%% --- Hazard ---
subgraph HZ["خطر"]
    H["پیچیدگی مدیریت چندذی‌نفعی در پروژه ملی"]
end

%% --- Threats ---
subgraph TH["علل / تهدیدها"]
    T1["ابهام در نقش‌ها"]
    T2["تعارض تصمیم‌گیری"]
    T3["نبود چارچوب RACI"]
    T4["ضعف پاسخگویی"]
end

%% --- Preventive Barriers ---
subgraph PB["موانع پیشگیرانه"]

    subgraph U1["🏥 دانشگاه علوم پزشکی"]
        P1["حکمرانی داده"]
        P2["سیاست‌های اخلاقی و دسترسی"]
        P3["تصویب نقش‌ها (RACI)"]
        P4["کمیته راهبری و اخلاق"]
    end

    subgraph E1["🧑‍💻 بخش مهندسی"]
        P5["پیاده‌سازی سیستم نقش‌ها"]
        P6["کنترل دسترسی نرم‌افزاری"]
        P7["داشبورد پایش پروژه"]
    end

    subgraph S1["🔗 مشترک"]
        P8["SLA و استاندارد همکاری"]
        P9["مالکیت هر کنترل ریسک"]
    end

end

%% --- Top Event ---
subgraph TE["رویداد مرکزی"]
    TE1["شکست در هماهنگی اجرایی پروژه"]
end

%% --- Mitigative Barriers ---
subgraph MB["موانع کاهش پیامد"]

    subgraph U2["🏥 دانشگاه علوم پزشکی"]
        M1["حل اختلاف در کمیته راهبری"]
        M2["اصلاح سیاست‌ها"]
        M3["نظارت اخلاقی و قانونی"]
    end

    subgraph E2["🧑‍💻 بخش مهندسی"]
        M4["اصلاح فنی سریع سیستم"]
        M5["گزارش خطا و مانیتورینگ"]
        M6["بازیابی نسخه پایدار"]
    end

    subgraph S2["🔗 مشترک"]
        M7["پایش شاخص‌های عملکرد"]
        M8["جلسات بازبینی دوره‌ای"]
    end

end

%% --- Consequences ---
subgraph CS["پیامدها"]
    C1["تأخیر پروژه"]
    C2["شکست استقرار سامانه"]
    C3["کاهش اعتماد سازمانی"]
end

%% --- Connections ---
H --> T1
H --> T2
H --> T3
H --> T4

T1 --> P1
T2 --> P4
T3 --> P3
T4 --> P5

P1 --> TE1
P2 --> TE1
P3 --> TE1
P4 --> TE1
P5 --> TE1
P6 --> TE1
P7 --> TE1
P8 --> TE1
P9 --> TE1

TE1 --> M1
TE1 --> M4
TE1 --> M7

M1 --> C1
M4 --> C2
M7 --> C3

%% --- Styles ---
style H fill:#ffcc00,stroke:#333,stroke-width:3px
style TE1 fill:#ff3333,color:#fff,stroke-width:3px

style T1 fill:#99ccff
style T2 fill:#99ccff
style T3 fill:#99ccff
style T4 fill:#99ccff

style P1 fill:#99ff99
style P2 fill:#99ff99
style P3 fill:#99ff99
style P4 fill:#99ff99
style P5 fill:#99ff99
style P6 fill:#99ff99
style P7 fill:#99ff99
style P8 fill:#99ff99
style P9 fill:#99ff99

style M1 fill:#ffcc99
style M4 fill:#ffcc99
style M7 fill:#ffcc99

style C1 fill:#cccccc
style C2 fill:#cccccc
style C3 fill:#cccccc

مقدمه و چکیده

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

در وضعیت فعلی، داده‌های پژوهشی حاصل از پایان‌نامه‌ها، کارآزمایی‌های بالینی و مطالعات دانشگاهی، علاوه بر پراکندگی، در قالب‌های غیرهمگن و بعضاً غیراستاندارد ذخیره می‌شوند. این مسئله نه‌تنها امکان تجمیع و مقایسه داده‌ها را محدود می‌کند، بلکه مانع از شکل‌گیری پژوهش‌های چندمرکزی و تحلیل‌های کلان‌داده در سطح ملی می‌شود. تجربه‌های موفق داخلی نیز نشان داده‌اند که حرکت به‌سوی دیجیتالی‌سازی و یکپارچه‌سازی داده‌ها، نقش مؤثری در ارتقای کیفیت پژوهش ایفا می‌کند.

در همین راستا، این سامانه می‌تواند پژوهش‌های دانشگاهی را از «فرآیندهای کاغذی و ابزارهای جزیره‌ای» رها سازد و با ایجاد یک زیرساخت یکپارچه، امکان بهره‌گیری نظام‌مند از تجارب پیشین را فراهم آورد. به‌عنوان نمونه، پلتفرم «ربیت» در دانشگاه شهید بهشتی طی پنج سال گذشته موفق به دیجیتالی‌سازی بیش از ۳۰۰ پروژه پژوهشی و یکپارچه‌سازی فرم‌های پزشکی شده است؛ تجربه‌ای که نشان‌دهنده ظرفیت بالای چنین رویکردهایی در سطح ملی است.

بر این اساس، هدف از طراحی و استقرار «سامانه ملی یکپارچه داده‌های پژوهش پزشکی»، ایجاد بستری متمرکز، امن و هوشمند برای گردآوری، استانداردسازی و به‌اشتراک‌گذاری داده‌های پژوهشی در کشور است. این سامانه با فراهم‌سازی یک موتور جستجوی پیشرفته و رابط کاربری کارآمد، به پژوهشگران امکان می‌دهد داده‌های مورد نیاز خود را بر اساس معیارهای هدفمند جستجو و استخراج کنند. اتصال به سامانه‌های اطلاعات بیمارستانی (HIS) و پرونده الکترونیک سلامت (EHR)، در کنار به‌کارگیری الگوریتم‌های پیشرفته بازیابی اطلاعات، زمینه دسترسی سریع، دقیق و هدفمند به داده‌ها را فراهم می‌سازد.

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

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

🔷 نکات کلیدی

• مسئله اصلی: پراکندگی و بلااستفاده ماندن داده‌های پژوهش پزشکی در کشور
• نیاز حیاتی: دسترسی به داده‌های باکیفیت و ساختاریافته برای پژوهش‌های نوین (AI، ML، پردازش تصویر پزشکی)
• شکاف موجود: نبود زیرساخت ملی یکپارچه برای تجمیع و اشتراک داده‌ها
• راهکار پیشنهادی: طراحی «سامانه ملی یکپارچه داده‌های پژوهش پزشکی»
• ویژگی کلیدی سامانه:
  • موتور جستجوی پیشرفته و هدفمند
  • اتصال به HIS و EHR
  • دسترسی سریع و آنلاین به داده‌ها
• مزیت مهم: حفظ کامل حریم خصوصی با ناشناس‌سازی داده‌ها
• تغییر پارادایم: حذف فرآیندهای حضوری و کاغذی → دسترسی دیجیتال و هوشمند
• تجربه های داخلی:
  • پلتفرم ربیت
  • دیجیتالی‌سازی بیش از ۳۰۰ پروژه در دانشگاه شهید بهشتی
    • پرشین کوهورت
• کوهورت دانشگاه علوم پزشکی مشهد و دیگر شهرها
• ارزش افزوده ملی:
  • امکان پژوهش‌های چندمرکزی
  • افزایش کیفیت و سرعت تولید علم
  • بهره‌برداری مجدد از داده‌ها
• خروجی نهایی: حرکت به سمت پزشکی داده‌محور و بهبود نظام سلامت کشور

flowchart LR
    direction LR
    P["مسئله اصلی:<br/>پراکندگی و بلااستفاده ماندن داده‌ها"] --> G["شکاف موجود:<br/>نبود زیرساخت ملی یکپارچه"]
    G --> N["نیاز حیاتی:<br/>دسترسی به داده‌های باکیفیت (AI/ML)"]
    N --> S["راهکار پیشنهادی:<br/>سامانه ملی یکپارچه داده‌ها"]
    
    S --> F["ویژگی کلیدی:<br/>جستجوی پیشرفته، اتصال HIS/EHR"]
    S --> M["مزیت مهم:<br/>حفظ حریم خصوصی (ناشناس‌سازی)"]
    S --> C["تغییر پارادایم:<br/>دسترسی دیجیتال (حذف کاغذ)"]
    S --> E["تجربه موفق:<br/>پلتفرم ربیت"]
    
    F & M & C & E --> V["ارزش افزوده ملی:<br/>پژوهش چندمرکزی، استفاده مجدد"]
    V --> O["خروجی نهایی:<br/>پزشکی داده‌محور و بهبود سلامت"]

    style P fill:#ffcccc,stroke:#333
    style G fill:#ffcc99,stroke:#333
    style N fill:#ffffcc,stroke:#333
    style S fill:#ccffcc,stroke:#333,stroke-width:2px
    style F fill:#e6f3ff,stroke:#333
    style M fill:#e6f3ff,stroke:#333
    style C fill:#e6f3ff,stroke:#333
    style E fill:#d9d9d9,stroke:#333
    style V fill:#99ccff,stroke:#333
    style O fill:#66b3ff,stroke:#333,color:#000

flowchart TD
    direction TB
    Main["<b>اهداف سامانه ملی یکپارچه داده‌های پژوهش پزشکی</b>"]
    
    Main --> O1["۱. دسترسی آسان و سریع<br/>حذف مراجعه حضوری"]
    Main --> O2["۲. حفظ حریم شخصی<br/>ارائه داده‌های ناشناس‌شده"]
    Main --> O3["۳. جستجوی هدفمند<br/>فیلترهای پیچیده و دقیق"]
    Main --> O4["۴. تحلیل داده‌ها<br/>ابزارهای آماری و نموداری"]
    Main --> O5["۵. امنیت داده‌ها<br/>رمزنگاری و کنترل دسترسی"]
    Main --> O6["۶. قابلیت توسعه<br/>پذیرش قابلیت‌های نوین آینده"]
    Main --> O7["۷. ارزیابی سازمانی<br/>سنجش عملکرد مراکز درمانی"]
    Main --> O8["۸. جامعیت داده‌ها<br/>جمع‌آوری سراسری و چندمرکزی"]

    style Main fill:#004d40,stroke:#333,color:#fff
    style O1 fill:#e0f7fa,stroke:#333
    style O2 fill:#e0f2f1,stroke:#333
    style O3 fill:#fff3e0,stroke:#333
    style O4 fill:#f3e5f5,stroke:#333
    style O5 fill:#ffebee,stroke:#333
    style O6 fill:#e0e0e0,stroke:#333
    style O7 fill:#fff9c4,stroke:#333
    style O8 fill:#e1f5fe,stroke:#333

بیان مسئله

مسئله اصلی، نه کمبود داده، بلکه عدم مدیریت صحیح داده است.

flowchart LR
    direction LR
    A["تولید داده‌های بالینی"] --> B["پراکندگی و ناهمگونی"]
    B --> C["عدم استاندارد متادیتا"]
    C --> D["عدم قابلیت جستجو"]
    D --> E["عدم استفاده مجدد"]
    E --> F["اتلاف منابع پژوهشی"]
    F --> G["کاهش بهره‌وری علمی"]
    
    G -.->|"نیاز مبرم"| H["شکاف در پژوهش‌های نوین (AI/ML)"]

    style G fill:#cc0000,color:#fff
    style H fill:#ffcc00,stroke:#333,stroke-width:2px

تحلیل عمیق چالش‌ها

مدیریت داده در دانشگاه‌های علوم پزشکی یک مشکل تک‌بعدی نیست؛ این چالش دارای لایه‌های مختلفی است که باید در راهکار نهایی در نظر گرفته شوند:

flowchart TD
    Root["چالش‌های مدیریت داده پژوهشی"]
    
    Root --> L1["لایه داده"]
    Root --> L2["لایه فرآیند"]
    Root --> L3["لایه امنیت"]
    Root --> L4["لایه سازمانی"]

    L1 --> D1["ناهمگونی قالب‌های ذخیره‌سازی"]
    L2 --> D2["فرآیندهای کاغذی"]
    L3 --> D3["نگرانی‌های حریم خصوصی"]
    L4 --> D4["عدم همکاری بین‌مرکزی"]

    style Root fill:#333,color:#fff
    style L1 fill:#e0f7fa
    style L2 fill:#e8f5e9
    style L3 fill:#fff3e0
    style L4 fill:#ffebee

راهکار پیشنهادی

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

اهداف و ویژگی‌های کلیدی سامانه

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

flowchart TD
    Root["<b>سامانه ملی داده‌ها</b>"]
    
    %% شاخه اول: اهداف
    Root --> O["اهداف راهبردی"]
    O --> O1["دسترسی آسان و سریع"]
    O1 --> O1a["حذف مراجعه حضوری"]
    O --> O2["حفظ حریم خصوصی"]
    O2 --> O2a["ناشناس‌سازی هویت بیماران"]
    O --> O3["جستجوی هدفمند"]
    O3 --> O3a["فیلترهای پیچیده و دقیق"]
    O --> O4["تحلیل داده‌ها"]
    O4 --> O4a["ابزارهای آماری و نموداری"]

    %% شاخه دوم: ویژگی‌ها
    Root --> F["ویژگی‌های فنی"]
    F --> F1["اتصال به HIS و EHR"]
    F --> F2["امنیت و رمزنگاری"]
    F --> F3["قابلیت توسعه آینده"]
    F --> F4["جامعیت داده‌های سراسری"]

    %% شاخه سوم: خروجی‌ها
    Root --> V["خروجی‌ها"]
    V --> V1["پژوهش چندمرکزی"]
    V --> V2["پزشکی داده‌محور"]
    V --> V3["ارزیابی عملکرد مراکز"]

    %% استایل‌دهی برای زیبایی
    style Root fill:#f9f,stroke:#333,stroke-width:4px
    style O fill:#ccffcc,stroke:#333
    style F fill:#e6f3ff,stroke:#333
    style V fill:#ffe6cc,stroke:#333

ذی‌نفعان و موارد کاربرد

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

flowchart TD
    subgraph Stakeholders ["ذی‌نفعان اصلی"]
        direction TB
        D["پژوهشگران و دانشجویان"]
        U["اساتید و دانشگاه‌ها"]
        M["وزارت بهداشت"]
    end

    Sys["سامانه ملی یکپارچه داده‌ها"]
    E["کمیته اخلاق"]

    %% تعاملات اصلی
    D -- "۱. بارگذاری داده" --> Sys
    Sys -- "۲. دریافت داده و DOI" --> D

    U -- "۳. درخواست پژوهش مشترک" --> Sys
    Sys -- "۴. گزارش های کلان" --> U

    M -- "۵. سیاست گذاری و نظارت" --> Sys

    %% فرآیند اخلاق (خطوط چین‌دار برای تفکیک)
    D -.->|"۶. ارسال پروپوزال"| E
    E -.->|"۷. تایید مجوز اخلاق"| Sys

    style Sys fill:#f9f,stroke:#333,stroke-width:3px
    style E fill:#ffcccc,stroke:#333
    style Stakeholders fill:#f4f4f4,stroke:#999,color:#000
    style D fill:#e1f5fe
    style U fill:#e8f5e9
    style M fill:#fff3e0

انواع داده‌ها و ساختارها

flowchart TD
    Root["انواع داده ها و ساختارها"]

    %% گروه‌بندی در دو ستون برای عمودی شدن نمودار
    subgraph S1 [ ]
        direction TB
        A["الف: داده های بالینی"]
        B["ب: تصویربرداری پزشکی"]
        C["ج: داده های ژنومی"]
    end

    subgraph S2 [ ]
        direction TB
        D["د: پرسشنامه و نظرسنجی"]
        E["ه: نتایج آزمایشگاهی"]
        F["و: متادیتا"]
    end

    %% اتصال ریشه به گروه‌ها
    Root --> S1
    Root --> S2

    %% زیرشاخه‌ها (استانداردها)
    A --> A1["FHIR / OMOP CDM"]
    B --> B1["DICOM"]
    C --> C1["FASTQ / VCF"]
    D --> D1["CSV / JSON"]
    E --> E1["LOINC / SNOMED"]
    F --> F1["DataCite / DCAT"]

    style Root fill:#f9f,stroke:#333,stroke-width:3px
    style A fill:#e1f5fe,stroke:#333
    style B fill:#e8f5e9,stroke:#333
    style C fill:#fff3e0,stroke:#333
    style D fill:#f3e5f5,stroke:#333
    style E fill:#ffebee,stroke:#333
    style F fill:#fff9c4,stroke:#333

جدول استانداردها و واژه‌نامه‌های داده‌های سلامت

برای اطمینان از سازگاری و قابلیت تبادل داده‌ها، استانداردهای زیر باید رعایت شوند:

استاندارد / واژه‌نامه	دامنه / نوع داده	توضیحات عمده
HL7 FHIR	داده‌های بالینی	استاندارد اکسچینج RESTful برای داده‌های سلامت؛ منابع (Resources) مانند Patient, Observation, Encounter, Condition, Procedure, Medication. رایج‌ترین استاندارد تعامل‌پذیری نوین در سیستم‌های سلامت.
DICOM	تصاویر پزشکی	استاندارد بین‌المللی برای فرمت و تبادل تصاویر (CT/MRI/X-ray) و متادیتای آنها. پشتیبانی از DICOMweb برای دسترسی REST-based.
ISO 13606 / OpenEHR	پرونده الکترونیک سلامت	استاندارد دو-مدل برای تبادل EHR. در مطالعه‌های ایرانی به‌عنوان چارچوب مرجع EHR توصیه شده است.
OMOP CDM	داده‌های مشاهده‌ای بالینی	مدل داده مشترک جامعه OHDSI برای یکسان‌سازی ساختار داده‌های بزرگ بالینی و تحلیل‌های مقیاس‌پذیر. واژه‌نامه‌های متناظر (SNOMED, RxNorm, LOINC) برای یکسان‌سازی مفاهیم استفاده می‌شوند.
MIABIS	متادیتای زیست‌نمونه‌ها	استاندارد حداقلی اطلاعات برای توصیف بانک‌های زیستی و مجموعه‌های نمونه در سطح کلان. شامل ویژگی‌های biobank، collection، donor و sample.
ICD-10/11	تشخیص‌های بیماری	طبقه‌بندی بین‌المللی بیماری‌ها برای کدگذاری تشخیص‌ها (مثلاً در منابع FHIR Condition یا جدول OMOP). ICD-11 از سال ۲۰۲۲ رسماً جایگزین شده است.
SNOMED CT	مفاهیم بالینی	مجموعه جامع برای توصیف علائم، بیماری‌ها، فرایندها و سایر مفاهیم بالینی. در صورت دسترسی، برای دقت معنایی و تعامل‌پذیری بالاتر مفید است.
LOINC	آزمون‌های آزمایشگاهی	شناسه‌های استاندارد برای نام‌گذاری تست‌های آزمایشگاهی و نتایج آنها (مثلاً در FHIR Observation یا OMOP Measurement).
FAIR Principles	کلیت مدیریت داده	اصول هدایتگر علمی: Findable (قابل یافت)، Accessible (قابل دسترسی)، Interoperable (سازگار)، Reusable (قابل‌استفاده‌ی مجدد). برای داده و ابزار معتبر است.

مدل‌های فراداده و ره‌گیری منشاء

flowchart TD
    Root["چارچوب مدیریت و استانداردسازی داده"]

    %% گروه‌بندی در دو ستون برای عمودی ماندن نمودار
    subgraph S1 [ ]
        direction TB
        M["۱. متادیتای توصیفی"]
        P["۲. مدیریت منشا (Provenance)"]
    end

    subgraph S2 [ ]
        direction TB
        B["۳. استاندارد زیست نمونه"]
        C["۴. کاتالوگ و استناد"]
    end

    %% اتصال ریشه به گروه‌ها
    Root --> S1
    Root --> S2

    %% زیرشاخه‌ها (جزئیات فنی)
    M --> M1["استاندارد: DataCite / DCAT"]
    M --> M2["هدف: توصیف کامل مجموعه داده"]

    P --> P1["استاندارد: W3C PROV / FHIR"]
    P --> P2["هدف: ردیابی فرآیند و اصالت"]

    B --> B1["استاندارد: MIABIS Core"]
    B --> B2["سطوح: مشخصات کلان و فردی"]

    C --> C1["ابزار: CKAN / Dataverse"]
    C --> C2["شناسه: DOI (یافت پذیری)"]

    %% استایل‌دهی
    style Root fill:#f9f,stroke:#333,stroke-width:3px
    style M fill:#e1f5fe,stroke:#333
    style P fill:#e8f5e9,stroke:#333
    style B fill:#fff3e0,stroke:#333
    style C fill:#f3e5f5,stroke:#333

ناشناس‌سازی و ارزیابی ریسک شناسایی مجدد

برای حفظ حریم خصوصی افراد، داده‌های حساس باید پیش از اشتراک امن شوند. روش‌های ناشناس‌سازی متنوع است:

K-گمنامی (k-Anonymity)

داده‌ها با کلیدواژه‌های شناسایی (مثل سن، جنس، کد پستی) گروه‌بندی و تعمیم می‌یابند تا هر رکورد حداقل با k-1 نفر دیگر همگروه شود. این روش ساده است اما در صورت تغییرپذیری بالا (داده‌های نادر) ناکارآمد می‌شود.

حریم خصوصی تفاضلی (Differential Privacy)

افزودن نویز تصادفی به نتایج پرس‌وجو یا آمارهای خروجی جهت مخفی‌کردن داده‌های فردی. این رویکرد تضمین ریاضیاتی می‌دهد اما به محاسبات پیچیده نیاز دارد و ممکن است تحلیل را مختل کند.

پارسونیم‌سازی و هویت‌زدایی (Pseudonymization)

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

قوانین Safe Harbor

حذف صریح چندین فیلد شناساگر طبق استانداردهایی مانند HIPAA (مثلاً نام، شماره ملی، محل دقیق، تاریخ تولد کامل، شماره تلفن، ایمیل). این روش مبتنی بر چک‌لیست است و اجرای آن نسبتاً ساده است.

هر روش مزایا و معایب خود را دارد. بنابراین پیش از انتشار داده‌ها باید خطر بازشناسایی (با سناریوهایی مثل پیوند با پایگاه‌های عمومی) توسط آزمون‌های آماری یا ابزارهای تحلیل ارزیابی شود. اسناد علمی و تجربی نشان می‌دهند رعایت اصول «حداقل‌دسترسی» و ناشناس‌سازی مبتنی بر ریسک، رکن اساسی اشتراک ایمن داده‌های پزشکی است.

ملاحظات حقوقی، اخلاقی و حریم خصوصی در ایران

قوانین حریم خصوصی در ایران

• ایران فاقد قانون جامع حفاظت از داده‌ها است
• قوانین پراکنده موجود شامل:
  • قانون تجارت الکترونیک: اطلاعات سلامت به عنوان «اطلاعات حساس» تعریف شده است
  • منشور حقوق شهروندی (۱۳۹۶)
  • الزام اخذ مجوز از کمیته اخلاق برای پژوهش‌های پزشکی

مدل‌های رضایت

• عمدتاً «رضایت آگاهانه کتبی و موردی» استفاده می‌شود
• در مطالعات بزرگ مانند PERSIAN از «رضایت عام» برای استفاده‌های ثانویه استفاده می‌شود
• پیش‌فرض: نیاز به مجوز IRB و حذف یا رمزنگاری داده‌های هویتی

انتقال داده به خارج کشور

• مقررات صریحی وجود ندارد
• داده‌های سلامت «بسیار حساس» تلقی می‌شوند
• هرگونه انتقال برون‌مرزی نیازمند مجوز از مراجع ذی‌صلاح (مانند شورای عالی فضای مجازی یا وزارتخانه‌ها) است

---

امنیت، کنترل دسترسی و میزبانی

الزامات امنیتی فنی

• رمزنگاری در حین انتقال (TLS/SSL)
• رمزنگاری در حال سکون (AES-256)
• کنترل دسترسی مبتنی بر نقش (RBAC)
• احراز هویت قوی (SSO)
• لاگینگ جامع (Audit log)
• استراتژی دفاع در عمق
• استانداردهای ISO/IEC 27001, 27017

مقایسه میزبانی (امنیت و پایداری داده)

میزبانی سازمانی (On-Premise)

• کنترل فیزیکی کامل
• مالکیت داده
• نیاز به سخت‌افزار اضافی برای مقیاس‌پذیری
• هزینه اولیه بالا
• وابستگی به زیرساخت داخلی برای تداوم سرویس

میزبانی ابر داخلی (Cloud)

• افزایش پویای منابع (مقیاس‌پذیری)
• هزینه اشتراکی
• مدیریت آسان‌تر
• نیاز به اطمینان از ارائه‌دهنده داخلی

نکته مهم: به دلیل تحریم‌ها، ابر ملی یا دیتاسنتر دانشگاهی اولویت دارد.

اصل ۳-۲-۱ پشتیبان‌گیری (ضامن عدم از دست رفتن داده)

• ۳ نسخه پشتیبان
• در ۲ نوع رسانه متفاوت
• ۱ نسخه برون‌سازمانی (off-site)

بازیابی کامل حتی پس از فاجعه فیزیکی یا سایبری امکان‌پذیر است.

مطالعه PERSIAN Cohort (الگوی عملی)

• معماری on-premise سه‌لایه:
  • پایگاه داده MSSQL
  • سرور اپلیکیشن
  • ذخیره‌سازی سرد آنهیلز (برای زیست‌نمونه‌ها)
• اقدامات امنیتی:
  • فایروال سخت‌افزاری
  • بکاپ‌های چندگانه
  • کدگذاری افراد با شناسه یکتا

پیشنهاد معماری ترکیبی برای سامانه ملی

• داده‌های فوق‌حساس ← دیتاسنتر داخلی
• خدمات عمومی‌تر (تحلیل کلان داده، بکاپ افزونه) ← ابر خصوصی داخلی
• هدف: حفظ امنیت و جلوگیری از گم شدن داده‌های بحرانی

---

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

ساختار مدیریتی (Governance)

نقش‌ها

• مالک داده (Data Owner)
• متولی داده (Data Steward)
• مدیر سیستم

سیاست‌ها

• تعیین زمان، مکان و نحوه اشتراک‌گذاری داده

فرایندها

• تأیید درخواست داده
• رسیدگی به تخلفات
• بروزرسانی مقررات

کمیته نظارت

• نمایندگان وزارت بهداشت
• دانشگاه‌ها
• متخصصان IT

مدیریت رضایت (Consent Management)

• ثبت نحوه و دامنه رضایت هر مشارکت‌کننده (سیستم مبتنی بر پروفایل)

انواع رضایت

• رضایت برای پروژه خاص
• رضایت عام برای پژوهش‌های مشابه
• حق بازپس‌گیری رضایت در هر زمان

مدل‌های تأمین مالی و پایداری

مدل ترکیبی پیشنهادی:

• بودجه دولتی: وزارت بهداشت / وزارت علوم
• حمایت دانشگاهی: تأمین زیرساخت
• خدمات سفارشی: نگهداری داده اختصاصی برای پروژه‌ها با هزینه دریافتی
• انگیزه غیرمالی: امتیازات پژوهشی، گواهی‌های درون‌سامانه برای دانشجویان

---

فاز اجرایی پروژه (Execution Plan)

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

عنوان طرح

«طراحی و پیاده‌سازی سامانه ملی مدیریت و اشتراک‌گذاری داده‌های پزشکی با رویکرد مرحله‌ای و تأکید بر حریم خصوصی، امنیت و حاکمیت داده»

ایده اصلی

شروع با داده‌های ساده و کم‌ریسک (آزمایشگاهی، پرسشنامه) ← توسعه تدریجی به داده‌های بالینی، تصویری و ژنومی

استانداردهای مورد استفاده

FHIR، DICOM، OMOP و سایر استانداردهای بین‌المللی

معماری پیشنهادی

مقیاس‌پذیر با API، ETL، ذخیره‌سازی ترکیبی (ابر داخلی + on-premise)

حریم خصوصی

توجه جدی به ناشناس‌سازی، رمزنگاری، کنترل دسترسی (RBAC)، رضایت‌محوری

ساختار اجرایی (تیم‌ها)

تیم پزشکی

تعریف داده و اعتبار علمی

تیم مهندسی

طراحی و پیاده‌سازی

کمیته مشترک

سیاست‌گذاری و حل تعارض

زمان‌بندی

• کل پروژه: حدود ۳۰ ماه
• پایلوت اولیه (MVP): حدود ۶ ماه

معیارهای موفقیت

• کیفیت و کامل بودن داده‌ها
• عملکرد سیستم (API، دسترس‌پذیری)
• میزان استفاده پژوهشی از داده‌ها

رویکرد کلی

چهار فاز مرحله‌ای: از داده‌های ساده به پیچیده (تصویری و ژنومی) با شاخص‌های کیفیت و پذیرش در هر فاز

بخش اجرایی یکپارچه

در زیر متن شما به صورت چند جدول مجزا با عناوین مناسب در قالب Markdown ارائه شده است:

---

1. ساختار اجرایی پروژه

رکن	نقش	مسئولیت‌ها
تیم پزشکی (Data Owner)	تعریف، تأمین و اعتبارسنجی داده‌ها	شناسایی منابع داده (بیمارستان، آزمایشگاه) • تعریف ساختار داده و Data Dictionary • تعیین سطح حساسیت و سیاست دسترسی • تضمین کیفیت علمی داده‌ها
تیم مهندسی (System Builder)	طراحی و پیاده‌سازی سامانه	طراحی معماری (API، پایگاه‌داده، ETL) • پیاده‌سازی Backend و Frontend • توسعه سیستم امنیت (OAuth2، RBAC، Encryption) • استقرار و نگهداری سیستم
کمیته مشترک (Governance)	راهبری کلان	تصویب سیاست‌های داده و حریم خصوصی • حل اختلاف بین تیم‌ها • پایش پیشرفت و کیفیت پروژه

2. فازبندی اجرایی (Operational Phases)

فاز	مدت	فعالیت‌ها	خروجی
فاز ۱: تحلیل و طراحی اولیه	ماه ۱–۲	مستند نیازمندی‌ها • انتخاب Datasetهای اولیه (آزمایشگاهی + پرسشنامه) • طراحی معماری اولیه (SQL + API + ETL)	مستند نیازمندی‌ها، معماری اولیه
فاز ۲: توسعه MVP	ماه ۳–۴	توسعه API و Backend • پیاده‌سازی احراز هویت • ایجاد پایگاه‌داده و ETL	نسخه اولیه سیستم (MVP)
فاز ۳: آماده‌سازی و ورود داده	ماه ۲–۴ (همزمان)	پاک‌سازی و استانداردسازی داده‌ها (LOINC، FHIR) • ناشناس‌سازی (Pseudonymization)	Datasetهای استاندارد و قابل استفاده
فاز ۴: استقرار و پایلوت	ماه ۵–۶	استقرار در محیط واقعی • اجرای پایلوت روی ۱–۲ Dataset • ارزیابی عملکرد سیستم	گزارش پایلوت، بهبود سیستم

---

3. مسیر توسعه بلندمدت (پس از MVP)

فاز کلان	هدف	محتوا / فناوری
فاز ۲ کلان	افزودن داده‌های بالینی و تصویری	DICOM، ICD
فاز ۳ کلان	ورود داده‌های ژنومی و Big Data	داده‌های ژنوم، کلان‌داده
فاز ۴ کلان	استقرار ملی و مقیاس‌پذیری کامل	Cloud / Hybrid

---

4. شاخص‌های کلیدی عملکرد (KPIs)

شاخص	هدف / معیار
نرخ تکمیل داده	> 80%
انطباق با استانداردها	FHIR / LOINC
زمان پاسخ API	< ۲ ثانیه
تعداد Datasetهای ثبت‌شده	—
تعداد کاربران و پروژه‌های پژوهشی	—
میزان استفاده مجدد از داده‌ها	—

---

5. مدیریت ریسک

ریسک	راهکار
مقاومت در اشتراک داده	ایجاد مشوق‌های پژوهشی
نگرانی امنیتی	پیاده‌سازی RBAC و Audit
کیفیت پایین داده	تعریف فرآیند QC
عدم هماهنگی تیم‌ها	فعال‌سازی کمیته مشترک

---

6. اصول حریم خصوصی (طی فازهای مختلف)

مرحله	رویکرد / تکنیک
فاز اول	داده‌های ناشناس و کم‌ریسک
فازهای بعدی	Pseudonymization • k-anonymity • Differential Privacy (برای داده‌های حساس مانند ژنوم)