امنیت داده بیمار در سامانه‌های سلامت

تیم آرادتیم مهندسی

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

سابقهٔ بیماری کسی را نمی‌شود عوض کرد.

این تفاوت، همهٔ تصمیم‌های امنیتی در سامانه‌های سلامت را جابه‌جا می‌کند: دادهٔ سلامت برگشت‌ناپذیر است و ارزشش برای سوءاستفاده با گذشت زمان کم نمی‌شود. پروندهٔ ده سال پیش، امروز هم می‌تواند علیه کسی استفاده شود.

چه چیزی حساس حساب می‌شود

فراتر از تشخیص و درمان:

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

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

اصولی که باید در معماری باشند

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

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

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

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

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

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

مسئله‌ای که در تئوری راحت است و در واقعیت پزشکی پیچیده: بیماری بیهوش به اورژانس می‌رسد و پزشکی که «پزشک او» نیست باید فوراً سوابقش را ببیند.

اگر راهی برایش نگذارید، بیمارستان دورش می‌زند — با حساب مشترک، با رمزی که همه می‌دانند. و از آن لحظه، کل مدل دسترسی شما تزئینی است.

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

محیط آزمایش، شایع‌ترین نشت

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

دادهٔ واقعی بیماران در محیط آزمایش. دلیلش همیشه موجه است — «برای تست واقعی لازم داریم» — و نتیجه‌اش این است که دادهٔ حساس روی سروری با کمترین حفاظت، با دسترسی کل تیم توسعه و پیمانکار، قرار می‌گیرد.

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

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

نگهداری و حذف

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

چقدر نگه می‌داریم؟ سوابق پزشکی الزامات نگهداری قانونی دارند؛ لاگ‌ها و داده‌های جانبی نه. نگه‌داشتن همه‌چیز برای همیشه، ساده‌ترین تصمیم است و بدترین.

چطور حذف می‌کنیم؟ حذف واقعی شامل پشتیبان‌ها هم می‌شود. اگر معماری‌تان حذف را در نظر نگرفته باشد، «حذف شد» یعنی یک پرچم در پایگاه داده و داده هنوز هست.

تیم، که معمولاً حلقهٔ ضعیف است

بیشتر نشت‌های واقعی، حملهٔ پیچیده نیستند. اینها هستند:

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

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

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

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

و یک نکتهٔ آخر

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

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

پروژه یا ایده‌ای دارید؟

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

مشاوره رایگان

پروژه‌تان را با هم بررسی کنیم

جلسهٔ اول رایگان است و معمولاً همان یک جلسه روشن می‌کند پروژه چقدر کار دارد.

چطور با شما تماس بگیریم؟

برای هماهنگی سریع‌تر — اگر تماس تلفنی را ترجیح نمی‌دهید، همان شماره را در پیام‌رسان پیام می‌دهیم.

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

در حال ارسال…

درخواست شما ثبت شد.

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