Ringkasan model data
Model data untuk kontrol akses direpresentasikan oleh Resource izin. Aturan tersebut menentukan aturan yang berlaku dan data mana yang diterapkan aturan tersebut.
Izin FHIR
Aturan akses dinyatakan melalui resource Izin FHIR. Izin FHIR adalah jenis Resource FHIR yang mencatat pilihan konsumen layanan kesehatan. Metode ini mengizinkan atau menolak sekumpulan aktor untuk melakukan tindakan yang memengaruhi konsumen untuk tujuan tertentu dari lingkungan tertentu selama jangka waktu tertentu. Misalnya, konsumen dapat adalah pasien perawatan kesehatan, siapa pun yang bertindak atas nama pasien perawatan kesehatan, atau individu lain yang menyepakati perjanjian izin.
Tindakan yang dicatat dalam Izin FHIR mungkin bersifat luas dan tidak hanya menangani data catatan kesehatan elektronik (EHR) konsumen. Namun, untuk tujuan izin dalam Cloud Healthcare API, fokusnya adalah pada tindakan yang terkait dengan akses data dan penerapan tindakan tersebut terbatas pada pembacaan data FHIR dari penyimpanan FHIR.
Resource Izin memiliki status yang menunjukkan status izin saat ini. Meskipun penyimpanan FHIR mungkin berisi banyak izin di berbagai status, Cloud Healthcare API hanya menerapkan izin yang berstatus aktif. Izin di negara bagian lainnya tidak berpengaruh pada penegakan kebijakan. Jika izin diberikan atas nama pasien, izin tersebut akan dicatat sebagai diberikan oleh artis.
Jenis kebijakan
Cloud Healthcare API mendukung jenis kebijakan izin berikut:
Izin pasien: dikaitkan dengan Pasien menggunakan
Consent.patient
(STU3, R4) dan mengikat data sebanyak yang ditentukan oleh kompartemen pasien (STU3, R4).Kebijakan admin: tidak terkait dengan Pasien mana pun dan harus memiliki URL ekstensi
https://g.co/fhir/medicalrecords/ConsentAdminPolicy
. Jenis kebijakan ini dapat mengikat ke subset atau semua resource di app store yang ditentukan berdasarkan kriteria resource. Kebijakan Admin menetapkan kebijakan default untuk semua resource binding di Play Store.Kebijakan bertingkat admin: jenis kebijakan Admin yang memerlukan URL ekstensi
https://g.co/fhir/medicalrecords/CascadingPolicy
dan URL ekstensi kebijakan Admin. Anda dapat mengikat jenis kebijakan ini ke kompartemen resource yang cocok dengan kriteria resource. Memiliki batasan berikut:- Hanya mendukung resource Pasien.
- Penyimpanan FHIR tempat kebijakan diterapkan harus memiliki
disableReferentialIntegrity
yang ditetapkan kefalse
.
Anda dapat menggabungkan jenis kebijakan pada level resource yang sama untuk mengizinkan atau menolak akses ke resource. Jika izin pasien tidak ada, kebijakan Admin dapat menyetujui akses ke referensi.
Perintah izin
Perintah izin adalah petunjuk yang dienkode dalam Izin FHIR yang mengizinkan atau menolak akses data ke entitas resmi seperti grantee atau accessor. Satu Izin FHIR dapat mengenkode beberapa perintah izin. Setiap perintah menyediakan hal-hal berikut:
Jenis penerapan: petunjuk
permit
ataudeny
.Tindakan: izin yang tercakup dalam perintah ini. Hanya
access
yang didukung untuk memberikan akses hanya baca.Kriteria akses: sekumpulan atribut yang mengidentifikasi pemohon API yang tercakup dalam perintah.
Kriteria resource: sekumpulan atribut yang mengidentifikasi resource yang dicakup oleh perintah.
Kriteria pengakses
Cloud Healthcare API mendukung tiga properti pengakses untuk digunakan dalam perintah izin dan untuk dicocokkan dengan pengakses yang membuat permintaan akses data. Harus ada pencocokan persis yang peka huruf besar/kecil agar perintah diterapkan pada pengakses sebagai bagian dari penentuan akses yang ditawarkan oleh server FHIR.
Properti ini dienkode sebagai berikut:
Pelaku: mewakili individu, grup, atau peran akses yang mengidentifikasi aksesor atau karakteristik pengakses.
Tujuan: mewakili maksud penggunaan data.
Environment: mewakili ID abstrak yang menjelaskan lingkungan atau kondisi yang digunakan pengakses.
Misalnya, pengakses dapat diwakili oleh properti berikut:
Pelaku:
Practitioner/123
Tujuan:
ETREAT
atau akses untuk perawatan daruratLingkungan:
Application/abc
Dalam contoh ini, properti ini merepresentasikan dokter yang mengakses data saat melakukan perawatan darurat menggunakan aplikasi software yang disebut abc
.
provision.actor
dan
provision.purpose
ditentukan sebagai bagian dari standar FHIR, sedangkan Lingkungan adalah
https://g.co/fhir/medicalrecords/Environment
. Perlu diperhatikan bahwa link ini tidak dapat diselesaikan.
Semua perintah izin harus menentukan actor
untuk diterapkan, tetapi tidak harus selalu menentukan purpose
atau environment
. Misalnya, jika tidak ada environment
yang ditentukan dalam perintah izin, perintah tersebut akan cocok dengan environment
apa pun yang belum tercakup dalam perintah izin lainnya.
Kriteria sumber daya
Cloud Healthcare API mendukung elemen berikut sebagai bagian dari resource izin:
Jenis resource (STU3, R4): menunjukkan jenis yang dikaitkan oleh kebijakan izin, misalnya,
Encounter
,Observation
, atauImmunization
.ID Resource (STU3, R4): mewakili ID yang dikaitkan oleh kebijakan izin.
Sumber data: merepresentasikan asal resource seperti yang diidentifikasi oleh resource
meta.source
(hanya tersedia di R4).Tag data: menampilkan label kustom resource seperti yang dijelaskan dalam resource
meta.tag
(STU3, R4).Label keamanan: merepresentasikan label keamanan yang menentukan resource yang terpengaruh seperti yang diidentifikasi di kolom
meta.security
(STU3, R4). Sistem kode berikut ini didukung:Kerahasiaan: nilai hierarki yang diurutkan dari tidak dibatasi hingga yang paling dibatasi:
U
,L
,M
,N
,R
,V
. Jika izin mengizinkan label keamananR
, label tersebut akan berlaku untuk semua resource yang berlabelR
atau lebih rendah. Jika izin menolak label keamananR
, izin tersebut akan berlaku untuk semua resource yang setidaknya sensitif sepertiR
.ActCode: string yang sama persis dengan kode keamanan.
Alur kerja akses
Gambar ini mengilustrasikan perjalanan permintaan ke penyimpanan yang mendukung kontrol akses FHIR. Token eksternal dengan cakupan izin (kiri) digunakan oleh aplikasi (#3) saat membuat permintaan ke penyimpanan FHIR dengan kontrol akses diaktifkan (kanan).
Cakupan izin
Saat membuat permintaan akses data, pengakses beroperasi dalam
Cakupan Izin tertentu yang mewakili properti actor
, purpose
, dan environment
yang terkait dengan permintaan HTTP FHIR apa pun. Nilai untuk properti ini harus peka huruf besar/kecil dengan nilai yang diberikan dalam izin agar dapat memengaruhi penentuan akses penegakan kebijakan.
Aksesor dapat memiliki beberapa ID actor
yang relevan untuk menentukan
akses. Demikian pula, bisa saja ada beberapa purposes
atau environments
yang relevan dalam konteks izin tertentu. Oleh karena itu,
semua properti pengakses yang relevan harus diberikan sebagai bagian dari permintaan HTTP FHIR
agar dapat merepresentasikan pengakses tersebut dengan benar untuk tujuan izin.
Misalnya, cakupan izin untuk permintaan data tertentu mungkin sebagai berikut:
actor/Practitioner/444 actor/Group/999 purp/v3/TREAT purp/v3/ETREAT env/App/abc
Ini mewakili perawat atau dokter yang dikenal sebagai praktisi 444
yang merupakan anggota
grup 999
yang mewakili praktisi dari departemen dalam
rumah sakit tertentu. Praktisi di sana ada untuk memberikan perawatan rutin, tetapi
mungkin juga menangani perawatan darurat sebagai bagian dari tindakan tersebut. Praktisi menggunakan aplikasi software yang disebut abc
.
Cakupan izin disediakan sebagai Cakupan permintaan izin sebagai bagian dari permintaan data pengakses.
Minta cakupan izin
Permintaan FHIR menggunakan header permintaan HTTP FHIR untuk menerima cakupan izin
aksesor. Cakupan izin ini berisi kumpulan nilai actor
, purpose
, dan
environment
untuk mencerminkan identitas, kualifikasi,
intent penggunaan, dan batasan lingkungan pengakses saat ini tempat pengakses beroperasi.
Mungkin ada lebih dari satu dari setiap properti ini yang mewakili
cakupan izin pengakses pada satu waktu.
Entri cakupan izin izin ditentukan sebagai berikut:
actor/{type}/{ID}
: propertiactor
tempat resourcetype
disediakan bersama denganID
. Contohtype
meliputi:Practitioner
Group
Patient
Misalnya, jika penyimpanan berformat
projects/PROJECT_ID/locations/us-central1/datasets/DATASET_ID/fhirStores/STORE_ID
memanggil API, referensi lokal ke aktorPractitioner/123
akan di-resolve keprojects/PROJECT_ID/locations/us-central1/datasets/DATASET_ID/fhirStores/STORE_ID/fhir/Practitioner/123
.purp/v3/{value}
: propertipurpose
denganvalue
merupakan anggota dari kumpulan nilai FHIR Destination of Use (v3
) atau ekstensinya. Contoh penggunaanvalue
meliputi:TREAT
ETREAT
HRESCH
env/{type}/{value}
: propertienvironment
dengantype
danvalue
adalah string kustom tanpa taksonomi yang telah ditentukan. Contohtype
danvalue
mencakup:App/my_app_1
Net/VPN
Selain itu, header permintaan HTTP FHIR juga dapat menerima cakupan khusus, seperti
btg
dan bypass
yang ditentukan sebagai berikut:
btg
: Dengan siap pakai (atau BTG), Anda, sebagai pengguna manusia, dapat melewati pemeriksaan izin jika terjadi keadaan darurat. Alat ini hanya boleh digunakan dalam keadaan darurat dan tunduk pada tinjauan pasca-audit. Oleh karena itu,btg
memerlukan setidaknya satuactor
.bypass
: Memungkinkan pengguna tepercaya (seperti administrator) atau aplikasi tepercaya (seperti pipeline pelatihan ML) untuk beroperasi di penyimpanan FHIR tanpa otorisasi izin. Oleh karena itu,bypass
memerlukan setidaknya satuactor
dan satuenv
.
Penerapan akses dan penentuan akses
Dalam lingkungan layanan kesehatan yang kompleks dengan banyak kebijakan dan izin yang berdampingan, menerapkan akses dan menentukan izin akses dapat menjadi tugas yang sulit. Berbagai pemangku kepentingan mungkin memiliki ekspektasi dan persyaratan yang berbeda terkait penggunaan dan pengungkapan informasi pasien. Mengelola lanskap yang rumit ini memerlukan pemahaman yang jelas tentang cara penerapan akses dan logika dasar yang mengatur penentuan akses.
Kebijakan izin gabungan
Konsumen layanan kesehatan, seperti pasien atau administrator, mungkin memiliki beberapa perintah izin yang terdapat dalam satu resource Izin. Resource izin dapat berisi campuran perintah provision.type permit
dan deny
. Secara default, pengguna mungkin memiliki sejumlah resource Izin, tetapi maksimal 200 resource Izin active
diterapkan sekaligus. Lihat
Batasan dan batasan untuk detail selengkapnya.
Semua perintah izin diekstrak dari resource Izin active
bagi pengguna tertentu untuk membuat kumpulan aturan izin gabungan.
Properti perintah izin
Penerapan izin terbatas pada maksimal satu tujuan dan maksimal satu lingkungan per entri penyediaan.
Aturan berikut menjelaskan prinsip-prinsip untuk kontrol akses bersama atas izin pasien, kebijakan admin, dan kebijakan beruntun admin:
Akses semua resource ditolak secara default jika tidak ada perintah yang cocok.
Jika resource yang diminta tidak ada, hanya jenis resource dan ID resource yang dapat diidentifikasi. Semua kriteria resource lainnya dan pemilik resource tidak diketahui, aturan berikut berlaku dalam urutan listingan:
Jika jenis resource termasuk dalam kompartemen pasien: akses ditolak.
Atau:
Jika ada kebijakan admin yang menolak kriteria pengakses terlepas dari kriteria resource lainnya, akses tersebut akan ditolak.
Jika ada kebijakan admin yang mengizinkan kriteria pengakses untuk kriteria resource yang dapat diidentifikasi (yaitu jenis resource dan ID resource), error "resource tidak ditemukan" akan ditampilkan.
Untuk kasus lainnya, akses akan ditolak.
Kebijakan admin adalah kebijakan default yang digunakan untuk mencocokkan resource di Play Store.
Referensi yang bukan milik pasien mana pun ditentukan hanya oleh kebijakan admin.
Referensi yang berada di kompartemen pasien (STU3, R4) memerlukan setidaknya satu perintah izin per pasien atau kebijakan admin atau kebijakan bertahap admin dan tidak ada perintah penolakan izin dari pasien dan kebijakan admin dan kebijakan bertingkat admin. Kondisi ini diperlukan dari semua pasien yang disebutkan pada resource yang akan diakses oleh pemohon.
- Beberapa referensi mungkin mendukung beberapa peserta pasien. Misalnya, Janji Temu menyediakan daftar peserta yang mungkin adalah pasien. Semua pasien yang disebutkan dalam resource tersebut harus mengizinkan akses ke pengakses menggunakan perintah izin. Jika tidak, resource tidak akan ditampilkan.
Aturan yang dijelaskan diringkas dalam kode pseudo berikut:
Kontrol akses bersama
ifresource
does not exist ifresource
is a patient-compartment resource: return "deny" else: if there is any admin policy denies access foraccessor criteria
regardless ofresource criteria
other than resource type and resource ID: return "deny" else if there is any admin policy permits access foraccessor criteria
based on the identifiableresource criteria
: return "resource not found" else: return "deny" else: letpatients
= list of patient references named in the patient compartment eligible fields of the requestedresource
if there is any matching deny from eitherpatients
's consents or admin policy or admin cascading policy: return "deny" if there is matching admin policy permits access: return "permit" if allpatients
have matching patient consents or admin cascading consent that permit access: return "permit" else: return "deny" end
Penyimpanan FHIR memeriksa izin izin di tingkat per resource. Referensi apa pun dalam resource tidak diselesaikan dan diturunkan untuk tujuan pemeriksaan akses izin.
Misalnya, pertimbangkan pasien yang diidentifikasi oleh Patient/f001
yang memungkinkan
Praktisi mengakses seluruh resource MedicationRequest
mereka, tetapi bukan
resource Patient/f001
itu sendiri karena privasi pasien. Dalam skenario ini, Praktisi dapat melihat seluruh resource MedicationRequest
yang mencakup
kolom subject
yang merujuk ke resource Patient/f001
, tetapi tidak dapat melihat
konten resource Patient/f001
bahkan, misalnya, saat melakukan
penelusuran FHIR menggunakan _include
.
Resolusi konflik
Konflik dapat terjadi di antara berbagai perintah permit
dan deny
. Jika dua
perintah yang bertentangan cocok dengan suatu resource, konflik tersebut akan diselesaikan menggunakan
model deny
lebih dari permit
.
Hanya active
izin yang disertakan untuk penerapan izin.
Logika penerapan akses resource
Saat membuat permintaan berdasarkan izin ke penyimpanan FHIR, kontrol akses akan terjadi dalam urutan berikut:
Cloud Healthcare API memeriksa izin pada akun layanan Google Cloud (atau akun utama) yang dikonfigurasi di proxy. Jika akun layanan memiliki izin IAM yang benar untuk menjalankan metode FHIR yang diminta di penyimpanan FHIR, permintaan akan dilanjutkan.
Jika penerapan izin diaktifkan di konfigurasi penyimpanan FHIR dan header HTTP berbasis izin ada, Cloud Healthcare API akan menerapkan kebijakan akses izin untuk resource Kompartemen Pasien. Penegakan kebijakan akses izin didasarkan pada cakupan izin yang diberikan dalam permintaan, sesuai dengan perintah izin yang dicatat oleh eksekusi
ApplyConsents
danApplyAdminConsents
terbaru.
Aturan berikut berlaku saat membuat permintaan berdasarkan izin ke penyimpanan FHIR:
Berikan setidaknya satu cakupan izin
actor
yang relevan untuk tindakan pemberian izin yang diambil.Berikan cakupan
purpose
danenvironment
tambahan yang relevan untuk tindakan pemberian izin yang dilakukan.Jika jumlah entri cakupan izin melebihi batas yang didukung, error akan ditampilkan.
Jika Anda memanggil metode yang mengakses beberapa resource (misalnya, metode
fhir.Patient-everything
,fhir.executeBundle
, ataufhir.search
), penerapan izin akan berlaku untuk setiap resource. Namun, ada perbedaan kecil antara metode akses multi-resource ini:fhir.executeBundle
yang membaca beberapa resource akan menerima pesan "Akses izin ditolak atau resource yang diakses tidak ada" untuk resource individual tanpa izin izin (lihat contoh di bagian Mendapatkan resource FHIR dengan cakupan izin).fhir.search
melewati resource tanpa izin izin dan tidak menampilkan error akses izin ditolak, bahkan untuk penelusuran berdasarkan_id
(lihat contoh di bagian Menelusuri resource FHIR dengan cakupan izin).fhir.Patient-everything
berperilaku mirip denganfhir.search
, kecuali bahwa metode ini menampilkan "Akses izin ditolak atau resource yang diakses tidak ada" jika pemanggil tidak memiliki izin izin pada resource Pasien yang diminta.
Penentuan akses izin
Perintah izin memiliki maksimal satu actor
, maksimal satu purpose
, dan maksimal satu environment
, sedangkan cakupan izin masing-masing dapat memiliki kelipatan. Beberapa perintah izin tidak menentukan ketiga properti pengakses, sehingga nilai properti cakupan izin apa pun dapat cocok, bergantung pada aturan penyelesaian konflik. Akibatnya, cakupan izin mungkin cocok dengan lebih dari satu perintah izin.
Jika cakupan izin suatu permintaan menyertakan dua entri atau lebih dari jenis cakupan izin yang sama (actor
, purpose
, atau environment
), cakupan izin mungkin cocok dengan beberapa perintah izin. Beberapa perintah izin tidak menentukan purpose
atau environment
. Oleh karena itu, cakupan izin juga harus dicocokkan dengan perintah izin yang tidak menentukan jenis cakupan ini.
Misalnya, menetapkan cakupan izin ke actor/Practitioner/123
actor/Group/999 purp/v3/TREAT env/App/abc
akan cocok dengan salah satu perintah izin permit
atau deny
berikut:
actor/Practitioner/123 purp/v3/TREAT env/App/abc
actor/Practitioner/123 purp/v3/TREAT
actor/Practitioner/123 env/App/abc
actor/Practitioner/123
actor/Group/999 purp/v3/TREAT env/App/abc
actor/Group/999 purp/v3/TREAT
actor/Group/999 env/App/abc
actor/Group/999