Sog’liqni saqlash almashinuvi standartlari: FHIR bo’yicha maxfiylik roziligi

IHE FHIRni amalga oshirish bo'yicha qo'llanma bo'yicha Maxfiylik roziligi ustida ishlashga rozi bo'ldi. Bu men ishora qilgan ishdir IHE FHIR Maxfiylik roziligi IG. Men uni BPPCm deb atashdan juda xursandman, garchi bu nomdagi "FHIR"dan unchalik mamnun emasman, chunki bu nom yechim emas, balki hal qilinayotgan muammoni tushunishga undashi kerak. Ammo biz ko'plab alternativalarni sinab ko'rdik va "PCF" eng yaxshi ko'rinardi.

Amalga oshirish bo'yicha qo'llanma ustida ishlashni boshladim. ga amal qilishingiz mumkin github repoyoki CI qurish. Hozir ko'p narsa ko'rinmaydi, lekin siz ushbu maqolani o'qiganingizda, men ancha oldinda bo'lishim mumkin.

Menda bir nechta savollar bor va bir nechta fikr-mulohazalarni so'rayman ...

Qadam toshining etuklik darajalari

Men ko'pincha Maxfiylik roziligini ba'zi qadamlar bilan yondashadigan narsa deb hisoblayman. Maxfiylik roziligining yakuniy xususiyatlari aslida juda murakkab va ularga erishish haqiqatan ham imkonsizdir. Bir qadamda erishish, albatta, mumkin emas. Shunday qilib, men ba'zi "qadam toshlarini" qurdim, boshqalardan "etuklik darajalari" so'raganini eshitdim. Siz buni qanday desangiz ham, oddiy foydalanish holatlari mavjud va tobora murakkabroq. Oddiy foydalanish holati hech kim uchun maqbul bo'lmasligi kerak, lekin oddiydan boshlash infratuzilmani ishga tushiradi va keyingi bosqichga tayyor bo'ladi.

FIR Rozilik bizga Ruxsat berish yoki Rad etish qoidalarini kodlashning oson usullarini beradi. Rozilik aslida murakkablik emas, ko'proq amalga oshirish murakkablikdir.

Shunday qilib, men to'rtta darajani ishlab chiqdim, ularning har biri avvalgisiga asoslanadi:

1. Ular so'zsiz rozi bo'lishadi -- shunchaki tizim faylda rozilik bo'lmaganda foydalanish uchun standart siyosatni boshqarishi mumkinligini e'lon qiladi. Ushbu standart siyosatni qo'llab-quvvatlash quyidagilarni o'z ichiga oladi: barchasini rad etish, bundan mustasno shisha sindirishfaqat davolash uchun ruxsat, har qanday boshqa ruxsat uchun ruxsat.
2. Aniq asosiy rozilik -- oz sonli maqsadlarda foydalana olmaydigan/olmaydigan va himoya qilinishi kerak bo'lgan ma'lumotlar to'g'ridan-to'g'ri yoki mualliflik muddati bo'yicha aniqlanishi mumkin bo'lgan muayyan agentlarni aniqlashga ruxsat berish uchun bir necha bemorga xos parametrlar bilan aniq rozilikni qo'llab-quvvatlash. .
3. Aniq oraliq rozilik -- nomli PurposeOfUse tadqiqot loyihalarini qo'llab-quvvatlash, ushbu ma'lumotlar muallifi tomonidan aniqlangan ma'lumotlar va Encounter yoki CarePlan kabi aniqlangan ob'ektlar bilan aloqasi bo'yicha aniqlangan ma'lumotlar.
4. Aniq kengaytirilgan rozilik -- Ma'lumotlar sezgirligini belgilashni qo'llab-quvvatlash. Bu a ni amalga oshirishni talab qiladi Xavfsizlik yorlig'i xizmati, lekin buning uchun Aktyorni aniqlamaydi. Kutish shundan iboratki, a Xavfsizlik yorlig'i xizmati Bu yanada samimiy tizim dizayni bo'lib, uni mavhum aktyor sifatida amalga oshirish mumkin emas. Ushbu yondashuv bir nechta arxitekturani yaratishga imkon beradi.

Men taklifimda ta'kidlaganimdek, menimcha, bundan tashqari etuklik ham borki, oxir-oqibat yaqinlashish mumkin. Ammo hozircha bu ancha ilg'or foydalanish holatlari real emas. Men uchun eng qiziq narsa - qoldiq majburiyatlarni va rad etishlarni targ'ib qilish qobiliyati. Shunday qilib, mening maqsadim ushbu qulay echimlarga e'tibor qaratish va keyinroq foydalanish holatlari ustida ishlashdir. Men ko'proq narsani talab qiladigan haqiqiy foydalanish holatlari borligini bilaman, men faqat taraqqiyotga intilaman.

E'tibor bering, hatto bu zinapoyalar ham mantiqiy bo'lmasligi mumkin... shuning uchun menga fikringizni bildiring.

Aktyor gimnastikasi

Rozilikni olishda ishtirok etadigan aktyorlar juda oddiy. Bu yaratish, o'qish, yangilash, o'chirish va qidirishning RESTful interfeysi. Rozilik resursi zinapoyalar uchun profillanadi, lekin bu ham juda oddiy FHIR profili.

Ishtirokchi FHIR Client ilovasi ishtirokchi FHIR Server bilan odatdagi FHIR REST o'zaro ta'sirini qanday qilib yaxshilash mumkinligini, mijoz hech qanday dasturni qo'llamasligini diagramma qilishdir.

olinmasligi kerak bo'lgan ma'lumotlar. Mendagi tizim dizayni muhandisi tizim dizaynini ko'rsatishni xohlaydi, lekin bu mavhum aktyorlarning diagramma modellashtirishi emas. Bunga qo'shing, buning mumkin bo'lgan yechimi tizim darajasida juda murakkab diagramma bo'lgan OAuth-dan foydalanishdir.

Men rozilik asosida kirishni boshqarish qarorini qabul qiladigan aktyorni ushbu qarorni amalga oshiradigan aktyordan ajratishni xohlayman. Bu Access Control tizimidagi odatiy abstraksiya va oAuth uchun ham asosiy hisoblanadi. Ammo bu juda g'alati mavhum aktyorlarni yaratadi.

Bundan tashqari, ushbu rozilik qarorlari mijoz ilovasiga so'rov yuborishga va foydalanuvchiga foydalanuvchi identifikatori asosida so'rov yuborishga imkon beruvchi kirishni boshqarish bo'yicha predikat qarorlariga asoslanadi. Mening tushunishimcha, buni tushuntirish uchun "Cascading oAuth" atamasi ishlatiladi. SMART-on-FHIR-da buning oddiy shakli shundan iboratki, SMART kirishni boshqarish qarori Open-ID-Connect bilan oAuth o'zaro ta'siriga asoslanadi. Shunday qilib, ruxsat olish nazoratini qo'shish bunga yana bir qatlam yoki "kaskad" qo'shiladi.

Yordam bering

Shunday qilib, bu menga yordam berish uchun iltimos. Ushbu etuklik darajalari foydali va to'g'rimi? Qanday qilib ijro tomonini yaxshiroq diagrammalashim mumkin?