ایمنی (Safety)

 

نخست، آسیب نرسان (First, Do No Harm)

تکلیف مراقبت (Duty of Care) مهم‌ترین مسئولیت تمامی حرفه‌های بالینی است. این مفهوم به مسئولیت اخلاقی و قانونی یک فرد یا سازمان برای خودداری از انجام هر اقدامی اشاره دارد که به‌طور معقول قابل پیش‌بینی باشد که به دیگران آسیب برساند. این اصل یکی از بنیادی‌ترین اصول اخلاق زیستی (Bioethics) است و به‌طور جهانی مورد پذیرش قرار گرفته است.

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

• ثبت اطلاعات در پرونده بیمار اشتباه.
• ناتوانی در جلوگیری از تجویز مقادیر خطرناک داروها.

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

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

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

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

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

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

 

اصول ایمنی

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

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

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

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

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

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

در سال ۲۰۰۰، گزارش تأثیرگذاری با عنوان «انسان جایزالخطاست» (To Err is Human) توسط مؤسسه پزشکی منتشر شد که برآورد می‌کرد سالانه تا ۹۸ هزار نفر در بیمارستان‌های آمریکا در نتیجه خطاهای پزشکی جان خود را از دست می‌دهند]1[. این گزارش تأکید می‌کرد که مشکل، افراد نامناسب نیستند؛ بلکه افراد خوب و توانمندی هستند که در سامانه‌های مراقبت سلامت فعالیت می‌کنند و این سامانه‌ها باید بسیار ایمن‌تر شوند. گزارش تکمیلی بعدی پیشنهاد کرد که مردم باید بتوانند اطمینان داشته باشند که مراقبت سلامت ایمن دریافت خواهند کرد. تحقق این هدف مستلزم وجود نظام ارائه خدمات سلامت است که هم از وقوع خطاها جلوگیری کند و هم زمانی که خطاها رخ می‌دهند، از آن‌ها درس بگیرد. این امر مستلزم وجود سامانه‌های اطلاعات سلامت است که:

- دسترسی فوری به اطلاعات کامل بیمار و ابزارهای پشتیبان تصمیم‌گیری را برای پزشکان و بیماران آنان فراهم کنند؛ و

- اطلاعات مربوط به ایمنی بیمار را به‌عنوان محصول جانبی فرآیند مراقبت جمع‌آوری کرده و از این اطلاعات برای طراحی نظام‌های ارائه خدماتی که حتی ایمن‌تر باشند استفاده نمایند [2].

برای مطالعه یک مرور جدیدتر و با دسترسی آزاد در زمینه ایمنی بیمار، به اثر وینسنت و آمالبرتی (Vincent and Amalberti) مراجعه کنید [3].

 

تعاریف

مراقبت ایمن یا Safe care شامل اتخاذ تصمیمات بالینی مبتنی بر شواهد به‌منظور بیشینه‌سازی پیامدهای سلامت و به حداقل رساندن احتمال آسیب است. باید از خطاهای ناشی از اقدام نادرست (Commission) و خطاهای ناشی از عدم اقدام (Omission) اجتناب شود.

رویداد نامطلوب (Adverse Event( رویدادی است که در نتیجه یک اقدام یا عدم اقدام، و نه به دلیل بیماری یا وضعیت زمینه‌ای بیمار، موجب آسیب ناخواسته به بیمار شود.

خطا (Error) عبارت است از شکست در تکمیل یک اقدام برنامه‌ریزی‌شده به شیوه موردنظر (یعنی خطای اجرا( یا استفاده از یک برنامه نادرست برای دستیابی به یک هدف (یعنی خطای برنامه‌ریزی(. همچنین شامل عدم انجام اقدامی است که بدون برنامه‌ریزی قبلی اما به‌طور ضروری باید انجام می‌شد (خطای ناشی از حذف یا Omission).

 

نزدیک به خطا (Near Miss) عبارت است از یک خطای ناشی از اقدام یا عدم اقدام که می‌توانست به بیمار آسیب برساند، اما به دلایل زیر آسیب جدی رخ نداده است:

تصادف یا شانس؛ برای مثال بیمار دارویی با منع مصرف دریافت کرده است اما دچار عارضه دارویی نشده است.

پیشگیری؛ برای مثال یک دوز بالقوه کشنده دارو تجویز شده است اما پرستار پیش از تجویز دارو متوجه خطا شده است.

کاهش اثرات آسیب (Mitigation)؛ برای مثال دوز کشنده دارو تجویز شده است اما به‌موقع شناسایی شده و با استفاده از پادزهر خنثی گردیده است.

 

تأثیر تغییر

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

Fig. 4.1 Change in adverse events before and after change

 

بیشتر تغییرات عمدی در فرآیندهای بالینی ناشی از نظام‌مند کردن بخشی از فرآیند با استفاده از فناوری جدید یا به‌کارگیری روشی نوین هستند. نمونه‌های متداول عبارت‌اند از:

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

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

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

صرف‌نظر از میزان برنامه‌ریزی و آزمون‌های انجام‌شده، سامانه‌های مراقبت بالینی فرآیندهایی پیچیده و انطباق‌پذیر هستند و رفتارهای نوظهور (Emergent Behaviour) از خود بروز می‌دهند. بنابراین مدیران باید انتظار داشته باشند که گونه‌های جدیدی از رویدادهای نامطلوب پدیدار شوند.

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

 

• سامانه اعزام آمبولانس از روشی مبتنی بر یادداشت‌های چسبان (Post-it Notes) روی دیوار به یک سامانه خبره تغییر یافت. این تغییر بلافاصله موجب کاهش زمان انتظار آمبولانس‌ها و کاهش مرگ‌ومیر و عوارض ناشی از تأخیر شد. با این حال، برخی از وضعیت‌ها توسط سامانه خبره از اولویت کافی برخوردار نشدند و در نتیجه برخی بیماران با زمان‌های انتظار بسیار طولانی‌تری مواجه شدند.
• یک سامانه مدیریت دارو مبتنی بر اسکن بارکد در یک بیمارستان مستقر شد. بلافاصله میزان خطاهای ناشی از تجویز یا مصرف نادرست دارو به‌طور چشمگیری کاهش یافت. اما از آنجا که سامانه به‌صورت کاملاً یکنواخت عمل می‌کرد، خطاهای پیکربندی باعث شدند که یک داروی اشتباه به‌طور مکرر و سیستماتیک برای بیماران تجویز یا مصرف شود.

 

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

یکی از ویژگی‌های مشترک این خطاها آن است که از نوع «خطاهای ناشی از اقدام» (Sins of Commission) هستند و ممکن است برای حامیان و بانیان تغییر، هزینه بیشتری نسبت به «خطاهای ناشی از عدم اقدام» (Sins of Omission) که جایگزین آن‌ها شده‌اند، ایجاد کنند. این موضوع به معنای آن نیست که تغییر نباید انجام شود؛ بلکه به این معناست که حامیان تغییر باید برنامه‌های اقتضایی مناسبی برای شناسایی چنین رویدادهایی داشته باشند و در مدیریت آن‌ها رویکردی فعال و پیشگیرانه اتخاذ کنند.

 

فرهنگ (Culture)

این موضوع ما را بار دیگر به بحث فرهنگ بازمی‌گرداند. یکی از جنبه‌های بسیار مهم این مسئله آن است که یکی از رایج‌ترین تغییرات در فرآیندهای بالینی، یکپارچه‌سازی دو سامانه بالینی متفاوت است. این اقدام می‌تواند برخی از مشکلات ایمنی شناسایی‌شده در فرآیند تحویل و انتقال مراقبت (Clinical Hand-over) را برطرف کند؛ فرآیندی که به‌خوبی به‌عنوان یکی از علل اصلی بروز رویدادهای نامطلوب شناخته شده است.

هر سامانه اطلاعاتی دارای نوعی «واپاشی عملکردی» یاDegeneracy  است. این وضعیت زمانی ایجاد می‌شود که کاربران، دانشی غیررسمی درباره شکاف میان نحوه واقعی استفاده از سامانه در عمل و قابلیت‌های رسمی سامانه اطلاعاتی در اختیار داشته باشند. نمونه‌ای از این وضعیت، استفاده از تاریخ خاص «1 ژانویه 1901» برای نشان دادن «تاریخ تولد نامشخص» است.

میزان دژنراسی موجود در یک سامانه را می‌توان به‌طور تقریبی از طریق میانگین تعداد یادداشت‌های چسبان (Post-it Notes) در هر نقطه دسترسی به سامانه برآورد کرد؛ البته باید توجه داشت که با گسترش دسترسی به سامانه‌ها از طریق هر نوع دستگاه، کاربرد این شاخص دشوارتر شده است؛ در عین حال، خطرات ناشی از چنین دژنراسی‌هایی نیز افزایش یافته‌اند.

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

حامیان پروژه‌های یکپارچه‌سازی باید مسیرهای مشخص، تمرین‌شده و آماده‌ای برای تشدید و رسیدگی (Escalation Pathway) به مسائل نوظهور داشته باشند و این موضوع باید بخشی از هر برنامه پروژه مربوط به پیاده‌سازی تبادل داده باشد.

 

پروتکل لندن (London Protocol)

یکی از ارکان اساسی هر سازمانی که بر ایمنی تمرکز دارد، بررسی و تحلیل رویدادهای نامطلوب پس از گزارش شدن آن‌ها است. البته در عمل، افراد به ندرت یک «رویداد نامطلوب» را گزارش می‌کنند. در عوض، معمولاً شکایتی درباره بیماری‌زایی (Morbidity) یا مرگ‌ومیر (Mortality( غیرمنتظره مطرح می‌شود. سپس بررسی‌های بیشتر ممکن است نشان دهد که این وضعیت در واقع یک رویداد نامطلوب بوده است.

پروتکل لندن که در کالج امپریال لندن (Imperial College London) توسعه یافته است، یک پروتکل رسمی برای بررسی چنین گزارش‌هایی به‌منظور تعیین این موضوع است که آیا آن‌ها واقعاً رویداد نامطلوب محسوب می‌شوند یا خیر و همچنین علل زمینه‌ای آن‌ها چه بوده است. این پروتکل به‌صورت رایگان در دسترس است [4]. این روش همچنین با نام‌های ALARM و ALARME نیز شناخته می‌شود]3[.

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

 

Fig. 4.2 London Protocol conceptual framework [4]

 

Fig. 4.3 London Protocol flowchart

 

مبنای مفهومی این چارچوب آن است که یک حادثه تنها زمانی رخ می‌دهد که مشکلات ارائه مراقبت (Care Delivery Problems یا CDPs) -یعنی نقص در فرآیند ارائه مراقبت- توسط لایه‌های دفاعی‌ای که سازمان ایجاد کرده است، مهار یا پیشگیری نشوند. با این حال، مشکلات ارائه مراقبت خود علت ریشه‌ای حادثه نیستند؛ بلکه این مشکلات در نتیجه عوامل مؤثری (Contributory Factors) ایجاد می‌شوند که سبب بروز مشکلات ارائه مراقبت می‌شوند، اما مانعی در برابر آن‌ها ایجاد نمی‌کنند. در اغلب موارد، این عوامل را می‌توان به مشکلاتی در مدیریت و فرآیندهای سازمانی ردیابی کرد. البته باید توجه داشت که همه حوادث را نمی‌توان به چنین مشکلاتی نسبت داد؛ همان‌گونه که پیش‌تر بیان شد، طبابت و مراقبت بالینی ذاتاً با خطر همراه است (در نهایت همه انسان‌ها روزی خواهند مرد).

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

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

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

 

طراحی نرم‌افزار (Application Design)

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

• نرم‌افزارها (در بسیاری موارد( به‌شدت قابل پیکربندی هستند.
• کاربران می‌توانند خود تصمیم بگیرند که چگونه از نرم‌افزار استفاده کنند.
• طراحان معمولاً بازخورد نظام‌مند و مفید اندکی درباره مسائل ایمنی دریافت می‌کنند.

در واقع، طراحان نرم‌افزارها معمولاً تنها زمانی درباره مسائل ایمنی چیزی می‌شنوند که یک شکست یا حادثه بزرگ به نرم‌افزار آن‌ها نسبت داده شود؛ و واکنش اولیه آن‌ها اغلب چیزی شبیه به این است:

«شما واقعاً از سامانه به آن شکل استفاده می‌کردید؟»

با وجود این، نرم‌افزارها در بسیاری از موارد یکی از مهم‌ترین عوامل مؤثر بر ایمنی کلی سامانه هستند و هرچه سامانه‌های اطلاعاتی جامع‌تر و فراگیرتر می‌شوند، این موضوع اهمیت بیشتری پیدا می‌کند (جدول 4.1).

برای درک اینکه چرا فروشندگان و تولیدکنندگان نرم‌افزار چنین نگرشی دارند، کافی است به درخواست‌های پیشنهاد (RFP) مربوط به سامانه‌های بالینی نگاه کنیم و وزن اختصاص‌یافته به قیمت، کارکردها و ایمنی را با یکدیگر مقایسه نماییم؛ در اغلب موارد، ایمنی با فاصله زیاد در رتبه سوم قرار می‌گیرد. البته ناملموس بودن مفهوم ایمنی نیز کمکی به این موضوع نمی‌کند. پیامد این وضعیت آن است که فروشندگان معمولاً ایمنی را در مقایسه با قیمت و قابلیت‌های عملکردی در اولویت قرار نمی‌دهند.

 

در اینجا یک سه‌گانۀ دشوار وجود دارد:

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

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

 

 

 

جدول 4.1 - مسائل ایمنی در سامانه‌های اطلاعاتی

 

شرح	مسئله
بیشتر توصیه‌ها و راهنماهای ایمنی بر نقطه ارائه مراقبت متمرکز هستند. دانش رسمی اندکی درباره طراحی ایمن نرم‌افزارها و اشتراک‌گذاری تجربیات در این زمینه وجود دارد.	تمرکز (Focus)
طراحان نرم‌افزارها در خصوص اینکه چه چیزی ایمن محسوب می‌شود، توصیه‌های متناقضی دریافت می‌کنند.	تعارض (Conflict)
شکاف دانش و تجربه میان طراح نرم‌افزار و کاربر نرم‌افزار بسیار گسترده است.	شکاف حوزه‌ای (Domain Gap)
حلقه بازخورد از مرحله شناسایی خطا تا منشأ آن دچار گسست است؛ کاربران اغلب از مشکلات آگاه هستند، اما این اطلاعات را با طراحان نرم‌افزار در میان نمی‌گذارند.	حلقه گسسته (Broken Loop)
نظام سلامت آخرین ایستگاه است؛ خطاهای رخ‌داده در حوزه سلامت به یک سامانه بیرونی منتقل نمی‌شوند تا در آنجا آشکار شوند. این موضوع مشکل گسست حلقه بازخورد را تشدید می‌کند.	آخرین ایستگاه (Last Stop)
تحول در طراحی سامانه‌ها با سرعت کمی انجام می‌شود. ممکن است یک تغییر عمده در طراحی، از مرحله ایده اولیه تا تبدیل شدن به یک راهکار اثبات‌شده در بازار، یک دهه زمان ببرد. در مقابل، ملاحظات ایمنی بالینی مستلزم تغییرات فوری یا دست‌کم واکنش به رویدادهای نامطلوب در بازه‌های زمانی بسیار کوتاه‌تر هستند.	سرعت طراحی (Design Speed)
کاربران تصور می‌کنند فروشندگان نرم‌افزار به ایمنی اهمیت نمی‌دهند. فروشندگان معتقدند کاربران حاضر نیستند برای ایمنی هزینه پرداخت کنند.	شکاف ادراکی (Perception Gap)
اطلاعات بالینی به‌خوبی توصیف و ساختاربندی نشده‌اند. این وضعیت با نظام‌هایی مانند حسابداری دوطرفه که قرن‌ها پیش سامان‌دهی شده‌اند متفاوت است. نرم‌افزارها در اینجا صرفاً در حال خودکارسازی راهکارهای دستی موجود نیستند، بلکه از ابتدا در حال ایجاد شیوه‌های جدید کار هستند. افزون بر این، استانداردهای اطلاعاتی مورد استفاده در نرم‌افزارها به دلیل پیچیدگی ذاتی اطلاعات پشتیبان مراقبت سلامت، پیچیده، تخصصی و دشوارفهم هستند.	مقاومت اطلاعاتی (Information Resistance)

چک‌لیست ایمنی  FHIR

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

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

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

برخی از مهم‌ترین موضوعات ایمنی در FHIR در ادامه به اختصار مورد بحث قرار می‌گیرند.

 

 

Fig. 4.4 FHIR safety checklist

 

چرخه عمر کامل (Full Life-Cycle)

برای هر منبع (Resource) که سامانه من با آن کار می‌کند، سامانه من چرخه عمر کامل آن را مدیریت می‌کند (کدهای وضعیت، مسائل مربوط به اعتبار زمانی رکوردها، و وضعیت ثبت‌های اشتباه).

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

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

 

اصلاح‌کننده‌ها (Modifiers)

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

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

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

 

ModifierExtensions

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

Assert object.hasNoModifiers: "Object at path %p has Unknown modifier extensions"

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

«هیچ Modifier Extensionای به این برنامه ارسال نکنید».

همانند بسیاری از راه‌حل‌های کم‌هزینه، این روش احتمالاً به اندازه بررسی واقعی Extensionها در سراسر برنامه مؤثر نخواهد بود.

 

Must Support

سامانه من از عناصری که در پروفایل‌های مرتبط با سامانه به‌عنوان «must-support» مشخص شده‌اند پشتیبانی می‌کند. راهنماهای پیاده‌سازی (Implementation Guides) می‌توانند عناصری را به‌عنوان must-support علامت‌گذاری کنند. این بدان معناست که اگرچه آن عنصر اختیاری است، اما برنامه کاربردی باید بتواند آن را به‌درستی ایجاد یا خواندن کند. اینکه «به‌درستی» دقیقاً چه معنایی دارد، بسیار متفاوت است. بنابراین راهنماهای پیاده‌سازی باید هنگام تعیین یک عنصر به‌عنوان must-support دقیقاً مشخص کنند منظورشان چیست و برنامه‌هایی که ادعای انطباق دارند باید تمامی الزامات تعیین‌شده را رعایت کنند.

 

شناسایی توزیع‌شده منابع (Distributed Resource Identification)

سامانه من مستند کرده است که شناسایی توزیع‌شده منابع در زمینه‌های استفاده مرتبط چگونه عمل می‌کند و منابع درون‌گنجانده‌شده (Contained Resources) در کجا و چرا استفاده می‌شوند. بسیاری از مسائل ایمنی بالینی که در عمل رخ می‌دهند ناشی از عدم هم‌راستایی سامانه‌ها در نحوه عملکرد شناسه‌ها و شناسایی منابع هستند. در بستر FHIR این خطر به‌ویژه شدید است، زیرا توسعه رابط‌ها و اتصال سامانه‌ها به یکدیگر بسیار آسان است.

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

 

منابع جاری (Current Resources)

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

 

خطاهای HTTP  

هنگامی که سامانه‌های دیگر از طریقAPIهای RESTful یا عملیات‌ها (Operations) خطاهای HTTP بازمی‌گردانند (احتمالاً با استفاده از OperationOutcome)، سامانه من آن‌ها را بررسی کرده و به‌درستی مدیریت می‌کند. نادیده گرفتن خطاها یا مدیریت نادرست آن‌ها یکی از مشکلات عملیاتی رایج در یکپارچه‌سازی سامانه‌ها است. پیاده‌سازان FHIR باید به‌طور صریح سامانه خود را ممیزی کنند تا اطمینان حاصل شود که کد وضعیت HTTP همواره بررسی می‌شود و خطاهای موجود در OperationOutcomeها به‌درستی مدیریت می‌شوند.

 

بیانیه قابلیت‌ها (Capability Statement)

سامانه من یک بیانیه انطباق شامل StructureDefinitionها، ValueSetها، OperationDefinitionها و موارد مشابه منتشر می‌کند تا سایر پیاده‌سازان بدانند سامانه چگونه عمل می‌کند. اگرچه سرورها ناگزیر از انتشار یک بیانیه انطباق هستند، اما میزان جزئیات آن به انتخاب پیاده‌ساز بستگی دارد. هرچه جزئیات بیشتری منتشر شود، یکپارچه‌سازی سامانه‌ها آسان‌تر خواهد بود.

 

اعتبارسنجی (Validation)

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

• نحو نامعتبر به دلیل انجام نادرست  Escape
• کدهای اشتباه
• ناسازگاری میان متن روایی و داده‌ه

در اکوسیستم FHIR برخی از سرورهای عمومی تمامی منابع را با دقت اعتبارسنجی می‌کنند، در حالی که برخی دیگر این کار را انجام نمی‌دهند. در Connectathonها معمولاً مشاهده می‌شود که پیاده‌سازان اعلام می‌کنند پیاده‌سازی آن‌ها کامل است، زیرا در برابر یک سرور فاقد اعتبارسنجی کار می‌کند و اهمیتی نمی‌دهند که در برابر سرورهای اعتبارسنجی‌کننده عمل نمی‌کند. از خدمات اعتبارسنجی (که در ادامه معرفی می‌شوند( برای اطمینان از معتبر بودن واقعی منابع خود استفاده کنید و مطمئن شوید که از یک DOM (مدل شیء سند) استفاده می‌کنید یا در Escape  کردن تمامی رشته‌ها نهایت دقت را به خرج می‌دهید.

 

قوانین ضمنی (Implicit Rules)

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

 

رضایت آگاهانه (Consent)

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

 

رمزنگاری (Encryption)

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

FHIR الزامی برای رمزنگاری تمامی تبادلات تعیین نکرده است، اگرچه بسیاری از پیاده‌سازان معتقدند که باید چنین الزامی وجود داشته باشد. برخی موارد استفاده معتبر برای عدم استفاده از رمزنگاری وجود دارد، مانند توزیع اصطلاح‌نامه‌ها (Terminology Distribution) و موارد مشابه. پیاده‌سازان باید اطمینان حاصل کنند که سامانه‌هایشان از امنیت کافی برخوردار هستند.

 

برچسب‌های امنیتی (Security Labels)

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

 

متن روایی (Narrative)

سامانه من می‌تواند متن‌های روایی را به‌درستی نمایش دهد (در مواردی که مورد استفاده قرار می‌گیرند). منابع می‌توانند شامل متن، داده یا هر دو باشند. سامانه‌ها الزامی ندارند که بتوانند متن روایی را نمایش دهند؛ آن‌ها همواره می‌توانند صرفاً داده‌ها را پردازش کنند. با این حال، در بسیاری از موارد، به‌ویژه برای منابع بالینی، بهتر است به کاربر امکان مشاهده متن روایی اصلی منبع (یا در بسیاری از موارد، منابع) داده شود. این قابلیت ممکن است در زبان قابل فهم برای کاربر با عنوانی نظیر «مشاهده سند اصلی» ارائه شود. مشخصات FHIR در این زمینه الزام صریحی تعیین نکرده است، زیرا رفتار صحیح در این خصوص بسیار وابسته به شرایط است. پیاده‌سازان باید خود درباره رفتار مناسب در این زمینه قضاوت کنند.

 

 

 

منابع و مأخذ مورد استفاده:

 

1. Institute of Medicine. To err is human: building a safer health system. Washington, DC: National Academy Press; 2000.

2. Institute of Medicine. Patient safety: achieving a new standard for care. Washington, DC: National Academy Press; 2004.

3. Vincent C, Amalberti R. Safer healthcare: strategies of the real world. Springer Open; 2016.

4. Taylor-Adams S, Vincent C. Systems analysis of clinical incidents: the London protocol. Clin Risk. 2004;10(6):211–20.