بلاکچین در سلامت و پرونده‌های پزشکی

بلاکچین در سلامت؛ از پرونده الکترونیک پزشکی تا امنیت داده و تحول خدمات درمانی

شناسه مقاله: ۱۴۷
دسته‌بندی: دانشنامه بلاکچین، سلامت دیجیتال و فناوری‌های نوظهور
سطح آموزشی: مقدماتی تا پیشرفته

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

۱. چرا تحول دیجیتال سلامت به مسئله اعتماد وابسته است؟

نظام سلامت مجموعه‌ای از سازمان‌های مستقل اما به‌هم‌پیوسته است.

بیمار ممکن است ابتدا به پزشک عمومی مراجعه کند، سپس آزمایش بدهد، تصویربرداری انجام دهد، در بیمارستان بستری شود و پس از ترخیص، خدمات مراقبت در منزل دریافت کند.

هر مرحله اطلاعات جدیدی تولید می‌کند.

این اطلاعات ممکن است شامل موارد زیر باشند:

• سوابق بیماری و تشخیص‌ها

• نتایج آزمایشگاهی

• تصاویر پزشکی

• داروهای تجویزشده

• سوابق بستری و جراحی

• حساسیت‌های دارویی

• خدمات پرستاری

• اطلاعات بیمه و پرداخت

• سوابق استفاده از تجهیزات پزشکی

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

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

۲. پرونده الکترونیک سلامت چیست؟

پرونده الکترونیک سلامت (Electronic Health Record یا EHR) مجموعه‌ای ساختاریافته از اطلاعات مرتبط با سلامت فرد است که می‌تواند در طول زمان و میان ارائه‌دهندگان خدمات مورد استفاده قرار گیرد.

در کنار آن، پرونده الکترونیک پزشکی (Electronic Medical Record یا EMR) معمولاً بیشتر به سوابق ثبت‌شده در یک مرکز یا محیط درمانی اشاره دارد؛ هرچند کاربرد این اصطلاحات در کشورها و محصولات مختلف یکسان نیست.

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

بلاکچین به‌تنهایی این قابلیت‌ها را ایجاد نمی‌کند.

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

بنابراین طراحی پرونده الکترونیک سلامت باید از نیازهای بالینی و استانداردهای اطلاعاتی آغاز شود.

۳. مسئله پراکندگی داده‌های پزشکی

فرض کنیم بیماری در سه مرکز درمانی سابقه مراجعه دارد.

مرکز اول اطلاعات آزمایشگاهی او را نگهداری می‌کند.

مرکز دوم سوابق تصویربرداری دارد.

مرکز سوم مسئول پیگیری درمان است.

اگر این سامانه‌ها به یکدیگر متصل نباشند، ممکن است پزشک به اطلاعات کامل دسترسی نداشته باشد.

نتایج احتمالی عبارت‌اند از:

• تکرار آزمایش‌های غیرضروری

• تأخیر در تصمیم‌گیری

• افزایش هزینه

• دشواری پیگیری درمان

• اختلاف اطلاعات دارویی

• افزایش بار اداری

راهکار اصلی، ایجاد قابلیت تعامل‌پذیری میان سامانه‌هاست.

بلاکچین تنها زمانی می‌تواند ارزش اضافه ایجاد کند که مسئله‌ای مشخص در هماهنگی یا اعتماد میان سازمان‌ها وجود داشته باشد.

۴. بلاکچین چگونه می‌تواند به سلامت کمک کند؟

بلاکچین می‌تواند لایه‌ای مشترک برای ثبت برخی رویدادها و شواهد فراهم کند.

برای مثال:

۱. ثبت اینکه کدام سازمان سندی را صادر کرده است.

۲. ثبت زمان صدور یا تغییر وضعیت یک مجوز.

۳. ثبت اثرانگشت رمزنگاری‌شده یک سند.

۴. ثبت رویدادهای دسترسی یا درخواست تبادل اطلاعات.

۵. هماهنگی وضعیت تأیید میان سازمان‌های مستقل.

اما باید میان ثبت اطلاعات و صحت اطلاعات تفاوت گذاشت.

اگر یک مرکز درمانی داده نادرستی وارد کند، ثبت آن روی بلاکچین، داده را از نظر پزشکی صحیح نمی‌کند.

همچنین اگر یک فرد بدون مجوز حرفه‌ای، اطلاعاتی ثبت کند، اعتبار رمزنگاری آن اطلاعات به معنای اعتبار حرفه‌ای صادرکننده نیست.

۵. چرا نباید اطلاعات پزشکی را مستقیماً روی بلاکچین ذخیره کرد؟

اطلاعات سلامت بسیار حساس‌اند.

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

محرمانگی

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

دشواری حذف

در برخی شبکه‌ها، حذف کامل داده ثبت‌شده دشوار یا ناممکن است.

اصلاح سوابق

پرونده پزشکی ممکن است به اصلاح یا تکمیل نیاز داشته باشد.

حجم داده

تصاویر پزشکی و داده‌های آزمایشگاهی می‌توانند بسیار حجیم باشند.

محدودیت دسترسی

همه مشارکت‌کنندگان نباید به تمام اطلاعات بیماران دسترسی داشته باشند.

مخاطرات رمزنگاری بلندمدت

رمزنگاری فعلی، تضمین نامحدود برای محرمانگی داده‌های حساس در تمام آینده نیست.

به همین دلیل، معماری مناسب معمولاً داده بالینی را در مخازن امن خارج از زنجیره نگهداری می‌کند.

۶. معماری ترکیبی؛ داده خارج از زنجیره، شواهد روی زنجیره

یکی از الگوهای قابل بررسی، معماری Hybrid یا ترکیبی است.

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

لایه اول: سامانه‌های بالینی

HIS، EHR، LIS، RIS و PACS.

لایه دوم: تبادل اطلاعات

APIها و استانداردهای تبادل داده مانند HL7 FHIR.

لایه سوم: مدیریت هویت

احراز هویت کاربران، سازمان‌ها و نقش‌های حرفه‌ای.

لایه چهارم: مدیریت مجوز

بررسی اینکه چه کسی، برای چه هدفی و در چه زمانی مجاز به دسترسی است.

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

ثبت شواهد منتخب، وضعیت مجوزها یا رویدادهای قابل ممیزی.

لایه ششم: نظارت و امنیت

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

این ساختار باید متناسب با قوانین و نیازهای واقعی پروژه طراحی شود.

۷. هش اطلاعات پزشکی چه کاربردی دارد؟

هش رمزنگاری‌شده (Cryptographic Hash) خروجی یک تابع ریاضی است که از داده ورودی تولید می‌شود.

اگر محتوای یک سند تغییر کند، هش آن نیز با احتمال بسیار بالا تغییر خواهد کرد.

فرض کنیم یک آزمایشگاه گزارش پزشکی صادر می‌کند.

سامانه می‌تواند هش گزارش را محاسبه و در یک دفترکل مشترک ثبت کند.

بعداً می‌توان هش نسخه ارائه‌شده را با هش ثبت‌شده مقایسه کرد.

اگر دو مقدار برابر باشند، این موضوع می‌تواند شاهدی برای یکسان بودن محتوای سند با نسخه‌ای باشد که هش آن ثبت شده است.

اما هش به‌تنهایی اثبات نمی‌کند که:

• آزمایش واقعاً انجام شده است.

• نتیجه از نظر علمی صحیح است.

• صادرکننده صلاحیت حرفه‌ای دارد.

• سند متعلق به بیمار ادعاشده است.

همچنین هش داده‌های کم‌تنوع یا قابل حدس ممکن است خود منشأ خطر افشای اطلاعات باشد؛ بنابراین نباید هر داده حساسی را بدون طراحی امنیتی هش و منتشر کرد.

۸. مدیریت رضایت بیمار با بلاکچین

رضایت بیمار یکی از موضوعات مهم در تبادل اطلاعات سلامت است.

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

برای مثال، بیمار اجازه می‌دهد متخصص قلب، نتایج آزمایشگاهی شش ماه گذشته را مشاهده کند.

یک سامانه مدیریت رضایت می‌تواند اطلاعات زیر را ثبت کند:

• هویت بیمار

• هویت دریافت‌کننده مجوز

• دامنه داده مجاز

• هدف استفاده

• زمان شروع

• مدت اعتبار

• وضعیت لغو یا تغییر رضایت

در معماری بلاکچینی، می‌توان شواهد مربوط به صدور یا تغییر وضعیت رضایت را ثبت کرد.

اما ثبت رضایت روی بلاکچین، به‌تنهایی به معنای معتبر بودن حقوقی یا اخلاقی آن نیست.

رضایت باید آگاهانه، قابل فهم و مطابق الزامات قانونی باشد.

همچنین لغو رضایت لزوماً به معنای حذف قانونی تمام پردازش‌های قبلی نیست؛ حدود آن به مقررات و مبنای قانونی پردازش بستگی دارد.

۹. کنترل دسترسی در پرونده پزشکی

همه کارکنان نظام سلامت نباید به اطلاعات یکسان دسترسی داشته باشند.

برای مثال:

کنترل دسترسی باید بر اساس اصولی مانند حداقل دسترسی ضروری و تفکیک وظایف طراحی شود.

داشتن کلید رمزنگاری یا آدرس بلاکچینی به‌تنهایی جایگزین احراز هویت حرفه‌ای نیست.

۱۰. دسترسی اضطراری به اطلاعات بیمار

یکی از مسائل مهم در طراحی سامانه سلامت، دسترسی اضطراری است.

فرض کنید بیمار بیهوش به اورژانس منتقل شده و امکان اعلام رضایت ندارد.

پزشک ممکن است برای جلوگیری از آسیب جدی، به اطلاعاتی مانند حساسیت دارویی نیاز داشته باشد.

اگر سامانه صرفاً بر تأیید آنلاین بیمار متکی باشد، ممکن است ارائه خدمت مختل شود.

بنابراین باید سازوکار دسترسی اضطراری (Break-Glass Access) در چارچوب قانون پیش‌بینی شود.

این سازوکار می‌تواند شامل موارد زیر باشد:

• احراز هویت حرفه‌ای فرد درخواست‌کننده

• ثبت دلیل اضطراری

• محدودسازی دامنه دسترسی

• ثبت رویداد

• بررسی پس از دسترسی

• رسیدگی به سوءاستفاده احتمالی

بلاکچین ممکن است در ثبت شواهد دسترسی نقش داشته باشد، اما تصمیم‌گیری حیاتی نباید به تأخیر نامعلوم شبکه وابسته شود.

۱۱. استاندارد HL7 FHIR چه نقشی دارد؟

FHIR مخفف Fast Healthcare Interoperability Resources است.

این استاندارد از خانواده استانداردهای HL7 برای تبادل اطلاعات سلامت طراحی شده است.

FHIR از ساختارهای مشخصی برای نمایش داده‌های بالینی و اداری استفاده می‌کند.

برای مثال:

• Patient

• Observation

• Encounter

• MedicationRequest

• DiagnosticReport

• Practitioner

• Consent

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

اگر دو سامانه نتوانند معنای داده‌های یکدیگر را درک کنند، ثبت هش آن داده‌ها روی دفترکل مشکل را حل نخواهد کرد.

همچنین استفاده از FHIR به‌تنهایی تعامل‌پذیری کامل را تضمین نمی‌کند؛ پروفایل‌های اجرایی، واژگان استاندارد و قواعد تبادل نیز اهمیت دارند.

۱۲. نقش استانداردهای بالینی

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

SNOMED CT

برای نمایش مفاهیم بالینی در بسیاری از سامانه‌های اطلاعات سلامت استفاده می‌شود.

LOINC

برای شناسایی انواع مشاهدات و آزمون‌های آزمایشگاهی و بالینی کاربرد دارد.

ICD

برای طبقه‌بندی بیماری‌ها و مسائل مرتبط با سلامت استفاده می‌شود.

DICOM

استانداردی مهم برای مدیریت و تبادل تصاویر پزشکی و اطلاعات مرتبط است.

این استانداردها جایگزین بلاکچین نیستند و بلاکچین نیز جایگزین آن‌ها نمی‌شود.

۱۳. بلاکچین در تبادل اطلاعات میان بیمارستان‌ها

فرض کنیم سه بیمارستان قصد دارند برخی اطلاعات بیماران را در چارچوب قانونی با یکدیگر تبادل کنند.

مدل پیشنهادی می‌تواند چنین باشد:

۱. بیمارستان مبدأ سند پزشکی را در مخزن امن نگهداری می‌کند.

۲. سامانه هویت و مجوز درخواست دسترسی را بررسی می‌کند.

۳. بیمارستان مقصد در صورت داشتن مجوز، سند را از مسیر امن دریافت می‌کند.

۴. رویداد دسترسی در سامانه ممیزی ثبت می‌شود.

۵. در صورت وجود نیاز واقعی به ثبت مشترک، شواهد منتخب در دفترکل توزیع‌شده ثبت می‌شوند.

در این مدل، داده پزشکی الزاماً از بلاکچین عبور نمی‌کند.

این تفکیک برای حفظ محرمانگی و کارایی اهمیت دارد.

۱۴. بلاکچین در پزشکی از راه دور

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

در این خدمات، موضوعاتی مانند هویت بیمار و پزشک، ثبت مشاوره، نسخه الکترونیک و تبادل اطلاعات اهمیت دارند.

بلاکچین ممکن است برای ثبت شواهد مربوط به برخی رویدادها بررسی شود؛ مانند:

• تأیید هویت ارائه‌دهنده خدمت

• ثبت صدور گواهی

• ثبت مجوز تبادل اطلاعات

• ثبت سابقه ارجاع میان سازمان‌ها

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

بنابراین ایجاد یک پلتفرم پزشکی از راه دور الزاماً مستلزم بلاکچین نیست.

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

در مدل‌های مراقبت در منزل، بیمار ممکن است از خدمات چند ارائه‌دهنده استفاده کند.

برای مثال:

• پزشک

• پرستار

• آزمایشگاه

• فیزیوتراپیست

• مرکز تأمین تجهیزات

• شرکت خدمات سلامت دیجیتال

هماهنگی این خدمات نیازمند ثبت دقیق رویدادها و مسئولیت‌هاست.

یک سامانه مشترک می‌تواند زمان ارائه خدمت، هویت ارائه‌دهنده، وضعیت ارجاع و تأیید دریافت خدمت را ثبت کند.

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

اما برای بسیاری از مراکز مراقبت در منزل، سامانه متمرکز با کنترل دسترسی و ثبت رویداد مناسب ممکن است اقتصادی‌تر باشد.

۱۶. پایش از راه دور بیمار و اینترنت اشیای پزشکی

پایش از راه دور بیمار (Remote Patient Monitoring یا RPM) از تجهیزات و حسگرها برای جمع‌آوری اطلاعات مرتبط با وضعیت سلامت استفاده می‌کند.

برای مثال:

• فشار خون

• ضربان قلب

• قند خون

• اکسیژن خون

• وزن

• فعالیت بدنی

این داده‌ها ممکن است با تناوب بالا تولید شوند.

ثبت تمام داده‌های خام روی بلاکچین معمولاً از نظر هزینه، تأخیر و محرمانگی مناسب نیست.

در عوض، می‌توان داده‌ها را در زیرساخت تخصصی ذخیره کرد و در صورت نیاز، شواهد منتخب درباره منشأ، یکپارچگی یا انتقال داده را ثبت کرد.

مسئله مهم

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

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

۱۷. رهگیری دارو با بلاکچین

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

یک سامانه رهگیری می‌تواند به بررسی منشأ و مسیر دارو کمک کند.

نمونه فرایند

۱. تولیدکننده شناسه دارو را ثبت می‌کند.

۲. اطلاعات بچ و بسته‌بندی تأیید می‌شوند.

۳. شرکت توزیع‌کننده دریافت محموله را ثبت می‌کند.

۴. داروخانه دریافت کالا را تأیید می‌کند.

۵. در صورت فراخوان، مسیر توزیع قابل بررسی است.

بلاکچین ممکن است در ثبت مشترک برخی رویدادها استفاده شود.

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

برای نمونه، قانون DSCSA در ایالات متحده الزامات رهگیری و امنیت زنجیره تأمین دارو را مطرح می‌کند، ولی استفاده از بلاکچین را به‌عنوان تنها راهکار الزامی نمی‌سازد.

۱۸. کاربرد در تجهیزات پزشکی

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

ثبت تاریخچه معتبر این رویدادها می‌تواند برای تولیدکننده، مرکز درمانی و نهاد نظارتی ارزشمند باشد.

مثال: دستگاه آزمایشگاهی

فرض کنیم یک دستگاه آزمایشگاهی در بیمارستان نصب شده است.

پرونده دیجیتال دستگاه می‌تواند شامل موارد زیر باشد:

• شناسه دستگاه و مدل

• شماره سریال

• تولیدکننده

• تاریخ نصب

• گواهی‌های مرتبط

• سوابق کالیبراسیون

• سوابق تعمیر

• تعویض قطعات

• وضعیت فراخوان

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

اما ثبت اطلاعات روی بلاکچین به معنای تأیید عملکرد یا انطباق قانونی دستگاه نیست.

۱۹. کاربرد در پژوهش‌های بالینی

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

در پژوهش چندمرکزی، هماهنگی میان مراکز می‌تواند دشوار باشد.

بلاکچین ممکن است برای ثبت شواهد منتخب کاربرد داشته باشد؛ از جمله:

• نسخه پروتکل پژوهش

• زمان ثبت برخی رویدادهای پژوهشی

• سوابق تغییرات اسناد

• وضعیت مجوز دسترسی به داده

• تأییدهای میان مراکز

محدودیت مهم

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

پژوهش همچنان به تصویب کمیته اخلاق، رضایت معتبر، کنترل کیفیت داده و نظارت علمی نیاز دارد.

۲۰. بلاکچین و یکپارچگی داده‌های پژوهشی

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

ثبت هش نسخه‌های مشخص از اسناد می‌تواند به بررسی یکپارچگی کمک کند.

برای مثال، پژوهشگر می‌تواند هش نسخه نهایی پروتکل را ثبت کند.

بعداً می‌توان بررسی کرد که نسخه ارائه‌شده با نسخه ثبت‌شده مطابقت دارد یا خیر.

اما این سازوکار به‌تنهایی از جعل داده پیش از ثبت جلوگیری نمی‌کند.

همچنین استفاده از داده‌های بیماران باید مطابق مقررات، رضایت‌ها و مجوزهای مربوط باشد.

۲۱. کاربرد در بیمه سلامت

در فرایند بیمه سلامت، چند سازمان ممکن است در ثبت و تأیید خدمات نقش داشته باشند:

• مرکز درمانی

• بیمه‌گر پایه

• بیمه‌گر تکمیلی

• شرکت ارزیابی خسارت

• نهاد نظارتی

یک سامانه مشترک می‌تواند به هماهنگی وضعیت اسناد و درخواست‌های پرداخت کمک کند.

برای مثال، ثبت تأیید ارائه خدمت یا وضعیت رسیدگی به یک مطالبه می‌تواند اختلاف اطلاعاتی را کاهش دهد.

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

۲۲. قراردادهای هوشمند در خدمات سلامت

قرارداد هوشمند می‌تواند برخی قواعد مشخص را به‌صورت خودکار اجرا کند.

مثال آموزشی

یک مرکز درمانی با تأمین‌کننده تجهیزات قرارداد دارد.

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

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

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

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

۲۳. هویت دیجیتال پزشکان و ارائه‌دهندگان خدمات

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

برای مثال، سامانه می‌تواند امکان بررسی وضعیت یک گواهی صادرشده توسط مرجع معتبر را فراهم کند.

اما باید میان سه موضوع تفاوت گذاشت:

هویت فرد: شخص چه کسی است؟

صلاحیت حرفه‌ای: آیا مجوز معتبر برای ارائه خدمت دارد؟

اختیار دسترسی: آیا در این موقعیت مشخص مجاز به مشاهده اطلاعات بیمار است؟

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

۲۴. بلاکچین و هویت غیرمتمرکز

هویت غیرمتمرکز (Decentralized Identity) و گواهی‌های قابل راستی‌آزمایی (Verifiable Credentials) از مفاهیم مرتبط با مدیریت هویت دیجیتال هستند.

در یک مدل احتمالی، نهاد دارای صلاحیت می‌تواند گواهی دیجیتالی صادر کند و طرف دریافت‌کننده بتواند اصالت آن را بررسی کند.

اما این مدل الزاماً به ذخیره اطلاعات شخصی روی بلاکچین نیاز ندارد.

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

۲۵. آیا بیمار می‌تواند مالک داده‌های پزشکی خود باشد؟

در ادبیات سلامت دیجیتال، گاهی از اصطلاح «مالکیت داده بیمار» استفاده می‌شود.

اما این اصطلاح از نظر حقوقی و فنی باید با دقت بررسی شود.

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

این حقوق الزاماً با مالکیت اقتصادی یک دارایی یکسان نیستند.

بلاکچین نیز به‌تنهایی حقوق قانونی جدیدی ایجاد نمی‌کند.

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

۲۶. محرمانگی داده‌های سلامت

حفاظت از اطلاعات سلامت باید در تمام مراحل چرخه عمر داده رعایت شود.

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

اصول مهم

• حداقل‌سازی داده

• محدودسازی هدف پردازش

• احراز هویت مناسب

• کنترل دسترسی

• رمزنگاری متناسب

• ثبت و بررسی رویدادها

• مدیریت رخدادهای امنیتی

• نگهداری و حذف مطابق مقررات

در پروژه‌های بین‌المللی، مقرراتی مانند GDPR در اتحادیه اروپا و HIPAA در ایالات متحده می‌توانند بسته به شرایط فعالیت اهمیت داشته باشند.

الزامات این مقررات متفاوت‌اند و نباید آن‌ها را به تمام کشورها تعمیم داد.

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

۲۷. تعارض تغییرناپذیری با اصلاح اطلاعات پزشکی

یکی از ویژگی‌های بسیاری از بلاکچین‌ها، دشواری تغییر تاریخچه ثبت‌شده است.

اما اطلاعات پزشکی ممکن است نیازمند اصلاح باشند.

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

در چنین شرایطی، معماری مناسب باید امکان اصلاح داده در سامانه اصلی و ثبت تاریخچه تغییرات را فراهم کند.

در دفترکل مشترک نیز می‌توان به‌جای تلاش برای حذف تاریخچه، رویداد اصلاح یا ابطال را ثبت کرد.

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

۲۸. مخاطرات امنیتی

استفاده از بلاکچین، سامانه سلامت را در برابر تمام حملات ایمن نمی‌کند.

افشای کلید خصوصی

ممکن است به ثبت عملیات غیرمجاز منجر شود.

خطای قرارداد هوشمند

ممکن است فرایندهای خودکار را مختل کند.

ضعف احراز هویت

می‌تواند امکان دسترسی افراد فاقد صلاحیت را فراهم کند.

خطای اتصال سامانه‌ها

ممکن است داده اشتباه یا ناقص میان مراکز منتقل شود.

حمله به مخازن خارج از زنجیره

داده‌های بالینی ممکن است همچنان در معرض باج‌افزار و نفوذ باشند.

اختلال شبکه

ممکن است دسترسی به خدمات وابسته را محدود کند.

در نتیجه، معماری امنیت باید همه اجزای سامانه را پوشش دهد.

۲۹. ایمنی بیمار مقدم بر معماری فناوری است

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

برای مثال، تأخیر در دسترسی به اطلاعات حساسیت دارویی می‌تواند خطرناک باشد.

بنابراین سامانه‌های بالینی نباید برای تصمیم‌های فوری به نهایی‌شدن تراکنش در یک شبکه با تأخیر نامعلوم وابسته شوند.

الزامات مهم

• دسترسی اضطراری

• تداوم خدمت

• نسخه پشتیبان

• مسیر جایگزین

• پایش و هشدار

• بازیابی پس از بحران

• آزمون امنیت

• ارزیابی خطرات بالینی

این الزامات باید پیش از بهره‌برداری واقعی بررسی و آزمون شوند.

۳۰. بلاکچین عمومی یا خصوصی در سلامت؟

بلاکچین عمومی

ممکن است برای ثبت شواهد عمومی و غیرحساس کاربردهای محدودی داشته باشد.

اما انتشار داده شخصی یا اطلاعات قابل ارتباط با بیمار روی شبکه عمومی مخاطرات مهمی ایجاد می‌کند.

بلاکچین خصوصی

می‌تواند کنترل بیشتری بر عضویت و دسترسی فراهم کند.

بلاکچین کنسرسیومی

ممکن است برای همکاری میان چند سازمان مستقل مناسب باشد.

بااین‌حال، خصوصی بودن شبکه به‌تنهایی محرمانگی اطلاعات را تضمین نمی‌کند.

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

۳۱. نمونه معماری یک شبکه سلامت منطقه‌ای

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

معماری می‌تواند شامل موارد زیر باشد:

سامانه‌های مبدأ: پرونده الکترونیک و سامانه‌های بالینی هر مرکز.

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

مدیریت هویت: احراز هویت بیمار، پزشک و سازمان.

موتور مجوز: بررسی مبنای قانونی و شرایط دسترسی.

دفترکل مشترک: ثبت وضعیت و شواهد منتخب مربوط به مجوزها.

داشبورد نظارت: بررسی رویدادها، اختلافات و رخدادهای امنیتی.

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

بیمار به متخصص جدید مراجعه می‌کند.

متخصص درخواست مشاهده نتیجه آزمایش مشخصی را ثبت می‌کند.

سامانه هویت و مجوز را بررسی می‌کند.

در صورت مجاز بودن، نتیجه از مخزن امن آزمایشگاه منتقل می‌شود.

رویداد دسترسی ثبت می‌شود.

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

در این مدل، بلاکچین نقش مکمل دارد، نه جایگزین سامانه‌های درمانی.

۳۲. چه زمانی بلاکچین ارزش اضافه ایجاد می‌کند؟

برای تصمیم‌گیری، باید چند پرسش پاسخ داده شود:

۱. آیا چند سازمان مستقل در فرایند مشارکت دارند؟

۲. آیا میان این سازمان‌ها مسئله واقعی اعتماد یا اختلاف اطلاعاتی وجود دارد؟

۳. آیا ثبت مشترک و قابل ممیزی ضروری است؟

۴. آیا یک نهاد مرکزی مورد اعتماد نمی‌تواند مسئله را ساده‌تر حل کند؟

۵. آیا داده‌ها به‌صورت استاندارد قابل تبادل‌اند؟

۶. آیا الزامات محرمانگی قابل رعایت‌اند؟

۷. آیا منافع اقتصادی قابل اندازه‌گیری هستند؟

۸. آیا ساختار حاکمیت و مسئولیت‌ها روشن است؟

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

۳۳. چه زمانی نباید از بلاکچین استفاده کرد؟

بلاکچین معمولاً انتخاب مناسبی نیست اگر:

• هدف فقط ذخیره پرونده‌های پزشکی باشد.

• یک سازمان به‌تنهایی تمام داده‌ها را مدیریت کند.

• داده‌ها باید به‌صورت گسترده اصلاح یا حذف شوند.

• زمان پاسخ بسیار کوتاه و حیاتی باشد.

• محرمانگی داده با معماری پیشنهادی سازگار نباشد.

• استانداردهای تبادل داده هنوز پیاده‌سازی نشده باشند.

• مدل حاکمیت میان سازمان‌ها وجود نداشته باشد.

• راهکار متمرکز یا تبادل داده استاندارد با هزینه کمتر همان نیاز را پاسخ دهد.

۳۴. مدل اقتصادی پروژه

در یک پروژه واقعی، باید هزینه‌ها و منافع مقایسه شوند.

هزینه‌ها

• توسعه و یکپارچه‌سازی

• زیرساخت و نگهداری

• امنیت اطلاعات

• مدیریت هویت

• آموزش

• انطباق حقوقی

• حاکمیت شبکه

• پشتیبانی و تداوم خدمت

منافع احتمالی

• کاهش زمان بررسی مجوزها

• کاهش اختلاف اطلاعاتی

• تسریع ممیزی

• کاهش برخی فرایندهای دستی

• افزایش قابلیت رهگیری رویدادها

مثال فرضی

فرض کنیم یک شبکه درمانی سالانه ۲۰۰ هزار درخواست تبادل اطلاعات میان مراکز پردازش می‌کند.

هزینه اداری متوسط هر درخواست در وضعیت فعلی ۳۰ هزار تومان است.

هزینه سالانه:

۲۰۰٬۰۰۰ × ۳۰٬۰۰۰ = ۶ میلیارد تومان

اگر سامانه جدید هزینه هر درخواست را به ۲۰ هزار تومان کاهش دهد، صرفه‌جویی ناخالص سالانه برابر با ۲ میلیارد تومان خواهد بود.

اما اگر هزینه نگهداری سالانه سامانه ۱٫۲ میلیارد تومان باشد، منفعت عملیاتی خالص پیش از سایر هزینه‌ها حدود ۸۰۰ میلیون تومان خواهد بود.

این محاسبه صرفاً آموزشی است.

همچنین باید مشخص شود که چه بخشی از صرفه‌جویی ناشی از استانداردسازی و یکپارچه‌سازی است و چه بخشی واقعاً به استفاده از بلاکچین وابسته است.

۳۵. شاخص‌های کلیدی ارزیابی پایلوت

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

۳۶. نقشه راه شش‌ماهه اجرای پایلوت

ماه اول: شناخت مسئله

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

ماه دوم: طراحی حاکمیت

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

ماه سوم: طراحی معماری

انتخاب استانداردهای تبادل، مدل هویت، زیرساخت امنیت و نقش احتمالی دفترکل.

ماه چهارم: توسعه نمونه اولیه

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

ماه پنجم: آزمون

بررسی امنیت، عملکرد، محرمانگی، دسترسی اضطراری و تجربه کاربری.

ماه ششم: ارزیابی

مقایسه نتایج با وضعیت موجود و راهکارهای غیربلاکچینی.

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

۳۷. آینده بلاکچین در سلامت

چند روند می‌توانند بر آینده این حوزه اثر بگذارند.

تعامل‌پذیری داده‌های سلامت

گسترش استانداردهای تبادل داده می‌تواند زمینه همکاری بهتر میان سامانه‌ها را فراهم کند.

هویت دیجیتال

گواهی‌های قابل راستی‌آزمایی ممکن است در شناسایی برخی ارائه‌دهندگان خدمات نقش داشته باشند.

مدیریت رضایت

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

پژوهش چندمرکزی

ابزارهای ثبت منشأ داده و سوابق پردازش ممکن است به قابلیت ممیزی پژوهش کمک کنند.

هوش مصنوعی سلامت

با گسترش کاربرد هوش مصنوعی، موضوعاتی مانند منشأ داده، مجوز استفاده و پاسخ‌گویی اهمیت بیشتری پیدا می‌کنند.

اما بلاکچین به‌تنهایی کیفیت مدل‌های هوش مصنوعی، محرمانگی داده‌های آموزشی یا ایمنی تصمیم‌های بالینی را تضمین نمی‌کند.

۳۸. پرسش‌های متداول

آیا بلاکچین می‌تواند جایگزین پرونده الکترونیک سلامت شود؟

خیر. بلاکچین معمولاً می‌تواند نقش مکمل در برخی فرایندهای هماهنگی و ممیزی داشته باشد.

آیا اطلاعات بیماران باید روی بلاکچین ثبت شوند؟

ثبت مستقیم اطلاعات حساس معمولاً انتخاب مناسبی نیست و به ارزیابی جدی حقوقی و امنیتی نیاز دارد.

آیا بلاکچین امنیت داده پزشکی را تضمین می‌کند؟

خیر. امنیت به معماری کامل سامانه، کنترل دسترسی، رمزنگاری، عملیات و رفتار کاربران وابسته است.

آیا بیمار می‌تواند مجوز دسترسی به اطلاعات خود را لغو کند؟

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

آیا بلاکچین برای بیمارستان‌های کوچک مناسب است؟

در بسیاری از موارد، توسعه پرونده الکترونیک استاندارد و اتصال امن به سامانه‌های دیگر اولویت بالاتری دارد.

آیا بلاکچین می‌تواند از جعل تجهیزات پزشکی جلوگیری کند؟

می‌تواند به ثبت و بررسی سوابق کمک کند، اما اصالت فیزیکی کالا به شناسه معتبر، کنترل زنجیره تأمین و بازرسی وابسته است.

جمع‌بندی

بلاکچین در نظام سلامت زمانی می‌تواند ارزش ایجاد کند که مسئله‌ای واقعی در هماهنگی، اعتماد و ثبت مشترک رویدادها میان سازمان‌های مستقل وجود داشته باشد.

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

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

برای مدیران سلامت، اولویت تصمیم‌گیری باید چنین باشد:

ابتدا ایمنی بیمار، سپس محرمانگی و اعتبار داده، پس از آن تعامل‌پذیری و در نهایت انتخاب فناوری مناسب.

پرسش راهبردی این نیست که «چگونه پرونده پزشکی را روی بلاکچین قرار دهیم؟» بلکه باید پرسید:

«در کدام فرایند چندسازمانی نظام سلامت، ثبت مشترک و قابل ممیزی می‌تواند اعتماد، کیفیت خدمت و کارایی اقتصادی را بهبود دهد؛ بدون آنکه امنیت و حقوق بیمار به خطر بیفتد؟»

منابع 

۱. HL7 International — FHIR Specification
https://hl7.org/fhir/

۲. World Health Organization — Global Strategy on Digital Health 2020–2025
https://www.who.int/

۳. NIST — Blockchain Technology Overview, NISTIR 8202
https://csrc.nist.gov/pubs/ir/8202/final

۴. U.S. Department of Health & Human Services — HIPAA
https://www.hhs.gov/hipaa/

۵. European Commission — Data Protection and GDPR
https://commission.europa.eu/

۶. U.S. FDA — Drug Supply Chain Security Act
https://www.fda.gov/

۷. DICOM Standard
https://www.dicomstandard.org/

۸. SNOMED International
https://www.snomed.org/

۹. LOINC
https://loinc.org/

۱۰. W3C — Verifiable Credentials Data Model
https://www.w3.org/TR/vc-data-model-2.0/

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