وبلاگ

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

این همچنین پیامدهای مهمی برای حفظ حریم خصوصی و امنیت دارد.

جاناتان کولمن، مدیر راه حل های ریسک امنیتی و اطلاعات افسر ارشد اطلاعات گفت: “این امکان وجود دارد که یک حادثه امنیتی TEFCA نیز یک حادثه امنیتی HIPAA باشد، و ممکن است یک حادثه امنیتی HIPAA ممکن است یک حادثه امنیتی TEFCA باشد یا نباشد.” امنیت در پروژه سکویا، واحد هماهنگ کننده شناخته شده TEFCA.

در HIMSS24 ماه گذشته، کلمن به همراه Zoe Barber، مدیر خط مشی Sequoia، واکنش TEFCA و جریان های گزارش رویداد را بررسی کردند، با تمرکز بر مناطق در حال توسعه که می توانند نهادهای ناسازگار را تحت پوشش HIPAA قرار دهند.

انعطاف پذیری جدید، الزامات امنیتی جدید

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

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

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

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

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

«پیش از این، ما یک الزام سختگیرانه داشتیم که شما فقط می‌توانید با یکی شرکت کنید [qualified health information network]اما اکنون ما آن را کمی باز می کنیم تا امکان مشارکت بین چندین QHIN را فراهم کنیم – تا زمانی که از یک سیستم متفاوت استفاده می کنید.

رمزگذاری برای HIE، BA و موارد دیگر

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

به روز رسانی پیش نویس TEFCA برای نظر عمومی در ژانویه منتشر شد و دوره نظر در فوریه بسته شد. میکی تریپاتی، هماهنگ کننده ملی ONC، گفت HealthcareIT News در ژانویه، ورود TEFCA 2.0 در ابتدای نقشه راه همکاری ONC در سال 2024 خواهد بود.

کلمن خاطرنشان کرد: برای فعال کردن تبادل FHIR، RCE به احراز هویت دو سطحی نیاز دارد.

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

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

پروتکل های گزارش رویداد

کلمن گفت که برای گزارش رویداد، برای این نهادها بسیار مهم است که بدانند آیا باید از پروتکل گزارش‌دهی حوادث امنیتی TEFCA و همچنین پروتکل‌های گزارش رویداد HIPAA که در اختیار دارند، پیروی کنند، «یا فقط از آنها پیروی کنند، به عنوان مثال. پروتکل های گزارش رویداد HIPAA.”

او گفت که چهار معافیت “مشابه” با قوانین امنیتی HIPAA مدل‌سازی شده‌اند — “راه‌حل‌هایی که وجود دارند که به هیچ وجه قصد جایگزینی آنها را ندارند.”

او گفت: «همه QHINها باید از قانون امنیتی HIPAA پیروی کنند، همانطور که شرکت‌کنندگان و شرکت‌کنندگان فرعی، حتی اگر نهادهای HIPAA نباشند»، و الزامات اضافی برای پوشش امنیت سایبری QHIN وجود دارد که باید توسط شخص ثالث مستقل تأیید شود.

به عنوان مثال، گواهی HITRUST “بسیار جامع، زمان بر و بسیار کامل” است، به ویژه در مورد نیازهای تعمیر و نگهداری گواهی.

کلمن گفت: «این کار کوچکی نیست.

او گفت که QHIN ها “باید فعالانه در مورد هر آنچه در برنامه اقدام اصلاحی یا برنامه اقدام و نقاط عطف آنها وجود دارد به جلو حرکت کنند و باید به نقاط ضعفی که شناسایی می کنند رسیدگی کنند.”

آنها همچنین موظفند این اطلاعات را با شرکت کنندگان و شرکت کنندگان فرعی به اشتراک بگذارند، “به طوری که اکوسیستم فناوری در مجموع بتواند واقعاً سطح بهترین شیوه های امنیتی را بالا ببرد و بهترین شیوه های امنیتی را اجرا کند.”

کلمن گفت: برای نهادهایی که تحت پوشش HIPAA نیستند، “این همه اطلاعات قابل شناسایی فردی است که آنها نگهداری می کنند، نه فقط اطلاعات TEFCA”.

“از آنجایی که آنها OCR ندارند… ما می خواهیم مطمئن شویم که آنها کار درست را انجام می دهند و اطلاعات سلامتی خود را در معرض خطر و در حال انتقال رمزگذاری می کنند.”

توضیح داده می‌شود که وقتی شرکت‌کننده‌ای که تحت تأثیر یک حادثه امنیتی TEFCA قرار گرفته است، گزارش مورد نیاز آن حادثه را به QHIN خود می‌دهد، “QHIN موظف است این موضوع را به RCE و سایر QHINهایی که تحت تأثیر نقض یا حادثه هستند گزارش کند.” کلمن

علاوه بر این، نهادهای آسیب دیده ملزم خواهند بود با اطلاع دادن به شرکت کنندگان و زیرمجموعه های خود گزارش دهند. او گفت، این الزامات تنزل رتبه TEFCA تضمین می کند که “ما ارتباطات خوبی را – به موقع – به دست می آوریم – به طوری که کسانی که باید بدانند در اسرع وقت مطلع شوند.”

یک حادثه TEFCA، یک حادثه HIPAA، یا هر دو؟

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

او گفت: اگر حادثه ای بر اطلاعات قابل شناسایی فردی تأثیر بگذارد و اطلاعات رمزگذاری نشده باشد، “آنگاه به طور خودکار یک حادثه امنیتی TEFCA است.”

او گفت: «نه تنها یک حادثه امنیتی TEFCA وجود دارد، بلکه آنها شرایط مشارکت خود در TEFCA را نقض می‌کنند، زیرا در انتقال و در حالت استراحت رمزگذاری نمی‌کنند. “این یک نه بزرگ است.”

او گفت در عین حال، اگر اطلاعات شناسه فردی رمزگذاری شده باشد، همچنان ممکن است یک حادثه امنیتی TEFCA باشد.

این زمانی است که یک حادثه بر هر داده سلامتی تأثیر می گذارد، و آن داده ها در سیستمی مانند پرونده الکترونیک سلامت گنجانده شده است، “بر اساس تعاریف، این دیگر اطلاعات TEFCA نیست.” “اکنون این اطلاعات HIPAA است، درست است؟”

او سپس بحث کرد که چگونه یک حادثه می تواند یک حادثه امنیتی TEFCA باشد – حتی زمانی که شامل اطلاعات TEFCA نمی شود.

“اگر بر توانایی آن سازمان برای مشارکت در تبادل TEFCA تأثیر منفی بگذارد، اگر آنها دیگر قادر به پاسخگویی به سؤالات نباشند – حتی اگر چیزی تحت تعریف TEFCA از اطلاعات فاش نشده باشد – همچنان بر توانایی آنها برای مشارکت تأثیر می گذارد.”

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

کلمن گفت: «هر دو مجاز به دریافت اطلاعات بهداشتی هستند. هنگامی که ارائه دهنده دریافت کننده هیچ کاری بیشتر با اطلاعات بیمار انجام نمی دهد و آن را پاک می کند، این یک حادثه TEFCA نیست.

او گفت: «با این حال، اگر یکی از آن معافیت ها را رعایت نمی کند و همچنین در آستانه سایر حوادث امنیتی، سایر حوادث قابل گزارش قرار می گیرد، پس این چیزی است که ما دوست داریم در مورد آن بدانیم. “بنابراین این یک حادثه امنیتی TEFCA و همچنین یک حادثه امنیتی HIPAA می شود” که در آن اعلان تکراری به بیماران فردی مورد نیاز نیست.

آندریا فاکس سردبیر ارشد Healthcare IT News است.
ایمیل: [email protected]
Healthcare IT News یک نشریه HIMSS Media است.