Sog’liqni saqlash almashinuvi standartlari: Break-Glass

Mendan Break-Glass qanday ishlashini tushuntirishni so'rashdi. Faqatgina javob yo'q, chunki kontekst juda muhim.

Break-Glassni aniqlang

Vakolatli klinik shaxslar tomonidan bemor maxfiyroq maʼlumotlarga kirish uchun qoʻllaniladigan usul, agar shifokor maxfiy maʼlumotlar yoritishga yordam berishi mumkin boʻlgan xavfsizlik xavotiri borligini tibbiy baholaganida, ular maxfiyroq saqlashni xohlaydi.

• Faqat davolashda qo'llaniladigan holatlarda qo'llaniladi. To‘lov/to‘lov holatlari uchun Break-Glass-ni ishga tushirish noo‘rin.
• Favqulodda yordam xonasidan foydalanish uchun emas. Favqulodda yordam xonasi bemorni barqarorlashtirishga e'tibor qaratadi va bu ko'pincha tarixiy ma'lumotlarning to'liq yo'qligida amalga oshirilishi mumkin. Bundan tashqari, ma'lumotlar mavjud bo'lganda, tez yordam xonasidagi klinisyenlar allaqachon yuqori imtiyozlarga ega bo'lishadi.
• Faqat vakolatli foydalanuvchilar tomonidan qo'llaniladi. Hamma klinisyenlarga ham bunday vakolat berilmaydi.
• Tibbiy xavfsizlik muammosi. Klinisyen tibbiy xavfsizlik to'g'risida qaror qabul qilishi kutilmoqda. Bu tashvish ko'pincha Break-Glassni chaqirish uchun oqilona deb topiladi.
• Post tahlili. Break-Glass hodisalari juda kamdan-kam sodir bo'lishi kerak, lekin ular sodir bo'lganda, faoliyatning shaffofligini ta'minlash uchun Audit jurnaliga tayanish kerak. Shunday qilib, Audit jurnali Break-Glass faoliyati davomida batafsilroq bo'lishi mumkin. Break-Glass faoliyati post tahliliga sabab bo'lishi kerak, bunda Audit jurnali Break-Glass deklaratsiyasi zarur va maqsadga muvofiq bo'lganligi tekshiriladi.
• Bemor Maxfiylik roziligi davolash uchun ba'zi ma'lumotlarni cheklaydi. E'tibor bering, agar davolanish uchun hech qanday cheklovlar bo'lmasa, Break-Glass qo'llanilmaydi, chunki bu qo'shimcha ma'lumotlarga kirishga olib kelmaydi.
• Bemor Maxfiylik roziligi Break-Glassni taqiqlamaydi. U joylashgan joyda ba'zi sozlamalar mavjud bemorga ko'rsatishga ruxsat beriladi ular ma'lumotlar oshkor bo'lishidan ko'ra, xavfsizlik muammolariga duch kelishni afzal ko'rishadi. Aksariyat sozlamalar o'z klinisyenlariga ko'proq ishonib, bunday narsalarga ruxsat bermaydi.

Shunday qilib, biz shuni bilamizki, bu erda shisha sindirish qo'llaniladi, bemor shisha sindirishga ruxsat bergan, bu klinisyenning ba'zi ma'lumotlarini ko'r qilish zarurati bor va klinisyenning e'lon qilish uchun ruxsati bor. shisha sindirish; shuning uchun faqat hozir biz alohida bir narsa qilishimiz kerak.

Umuman olganda, hal qilishning turli usullari mavjud.

• EHRning ichki mantig'i. Agar foydalanish holati EHR dan tashqariga chiqishi kerak bo'lmasa, standartlashtirilgan yechimga ehtiyoj qolmaydi.
• Ba'zi ish jarayoni mexanizmi. Break-Glass Xavfsizlik qatlamiga hech qanday aloqasi bo'lmagan usullarda qo'llab-quvvatlanishi mumkin. Ushbu yechimlar Break-Glassni boshqa klinik oqimlar orqali o'tadigan yo'l sifatida davolashga moyildir.

Shunday qilib, Xavfsizlik qatlami yechimlari foydalanishga e'tibor qaratadi

• PurposeOfUse of BTG (Break-the-Glass). Odatda, klinik oqimlardan foydalaniladi DAVOLASH Maqsaddan foydalanish so'rovning oddiy davolashdan foydalanish holati tomonidan qo'zg'atilganligini va qaytarilgan ma'lumotlar normal davolashdan foydalanish holatlari uchun ishlatilishini ko'rsatish uchun. BTG Break-Glass tegishli tarzda e'lon qilinganligini ko'rsatish uchun qo'shimcha Maqsad bo'ladi.

Foydalanuvchi Break-Glass-dan foydalanish mumkinligini qanday biladi?

Ushbu bo'limda foydalanuvchi Break-Glass-dan "foydalanish" mumkinligini qanday bilishi ko'rib chiqiladi. Nazariy jihatdan, ruxsatsiz foydalanuvchilarga ular uchun ko'r bo'lgan ma'lumotlar borligi aytilmaydi. Shunday qilib, faqat Break-Glassni e'lon qilish huquqiga ega bo'lgan foydalanuvchilar oddiy ishlov berishda ularga ko'r bo'lgan ma'lumotlar mavjudligi to'g'risida xabardor qilinadi.

Break-Glassni e'lon qilish uchun FHIR texnik echimlari

Ayni paytda biz bilamizki, klinik foydalanuvchi Break-Glassni e'lon qilish huquqiga ega va Break-Glass-dan foydalanish maqsadga muvofiqligi haqida klinik qarorga keldi. O'ylaymanki, oxirgi foydalanuvchi ilovasi boshqa klinik tashkilotdan sog'liqni saqlash ma'lumotlarini so'ragan klinik tashkilotdan FHIR orqali ma'lumotlarga kirishda bu boshqacha ko'rinadi.

Biznesdan biznesga

“Biznes-to-biznes” holatida, ikkala biznes ham Federatsiyalangan kirishni boshqarishni taʼminlagan Ishonchli tizimning bir qismi boʻlsa, tashabbuskor tashkilot oʻsha tashkilot ichida oʻz foydalanuvchisining Shishani sindirish huquqiga ega ekanligini tekshiradigan mantiqqa ega boʻladi va bu foydalanuvchi uchun Break-Glass e'lon qilish uchun ba'zi mexanizm. Shunday qilib, “Biznes-to-biznes” misolida “O‘zaro ishlash” darajasida namoyon bo‘ladigan yagona narsa shundan iboratki, so‘ralayotgan tashkilot xavfsizlik tokeni Break-Glass-dan oddiy ishlov berish uchun boshqacha ko‘rinishi kerak. Bu PurposeOfUse-ga juda mos keladi.

1. OAuth. OAuth oqimi Klinisyen Break-Glass ruxsatini so'rash va olish uchun foydalanadigan foydalanuvchi interfeysini taqdim qilishi mumkin. Chiqarilgan token qandaydir token noaniq tarzda normal yoki shisha sindirilganligini bildiradi (ko‘p tokenlar OAuth organi va resurs xizmatidan tashqari hamma uchun noaniq).

• BTG PurposeOfUse yordamida OAuth. OAuth-ni FHIR bilan ishlatish bo'yicha IHE Amalga oshirish qo'llanmasida JWT-da PurposeOfUse-ni kodlash uchun JWT mexanizmlari mavjud.

• Buning afzalligi shundaki, Break-Glass deklaratsiyasi keyinchalik normal holatga qaytadi. Bu klinisyen tomonida ko'rilgan oqimga rioya qilishga intiladi, ya'ni klinisyen har bir FHIR so'rovi/javobiga ta'sir qilmaydi; ularga ko'plab FHIR so'rovlari/javoblari bo'yicha olingan ma'lumotlar to'plami taqdim etiladi; keyin ular Break-Glass e'lon qiladi va keyin ko'proq FHIR so'rovi/javoblari sodir bo'ladi.
• Bu oddiygina bo'lishi mumkin AuditEvent Bu Break-Glass e'lon qilinganligini ko'rsatadi. Majburiy ijro punkti shu tariqa qaraydi AuditEvent ajoyib bo'lgan Break-Glass deklaratsiyasi uchun.
• Bundan tashqari, ba'zi boshqa FHIR Resursdan foydalanilgan bo'lishi mumkin.
• Bundan tashqari, hech qanday FHIR resursi ishlatilmasligi mumkin, lekin ba'zi bir FHIR bo'lmagan mexanizm
• Ehtimol, OAuth avtorizatsiya qarori nuqtasi

• Ushbu mexanizm xavfsizlik mexanizmidan foydalanmaydi, shuning uchun uni xavfsizlik yechimi sifatida ko'rmaslik kerak. Buni qo'shish uchun FHIR API-ni buzish juda oson bo'lar edi.
• E'tibor bering, ushbu yechim TREAT kabi boshqa PurposeOfUse indikatorlarini tashish uchun ham ishlatilishi mumkin

Yakuniy foydalanuvchi-mijoz

Men buni ajrataman, chunki Yakuniy foydalanuvchi-mijoz ko'pincha OAuth avtorizatsiya xizmati tomonidan boshqariladi. O'ylaymanki, biznesdan biznesga yechimlarning aksariyati shu yerda bo'lishi mumkin. O'ylaymanki, OAuth avtorizatsiya xizmati Break-Glassni e'lon qilish va Break-Glass sababini aniqlashda foydalanuvchi tajribasiga ko'proq jalb qilinishi mumkin. Foydalanuvchi/ilova OAuth avtorizatsiya xizmatiga Break-Glass UX ni ilgari surilishi kerakligini qanday ko'rsatishi haqida aniq bilmayman. Men bu borada OAuth mutaxassislariga murojaat qilaman.

Xulosa

Bitta yechim yo'qligidan juda afsusdaman. Men shuni ta'kidlaymanki, bitta aniq yechim yo'qligining sababi jamoat joylarida bu oqim haqida ko'p muhokama qilinmasligi bilan bog'liq. O'ylaymanki, agar jamoatchilik muhokamasi bo'lsa, biz ulardan ba'zilarini nega boshqalar kabi yaxshi emasligi haqida oqilona yo'q qilishimiz mumkin va men o'ylamagan echimlarni topishimiz mumkin edi.