Halaman ini diterjemahkan oleh Cloud Translation API.

Model data dan sistem kontrol akses FHIR

Halaman ini menjelaskan cara menggunakan sistem kontrol akses FHIR Cloud Healthcare API untuk mengelola dan mengamankan data kesehatan Anda. Anda dapat menggunakan kontrol akses FHIR untuk menentukan kebijakan izin, mengontrol akses data berdasarkan peran dan konteks pengguna, serta menerapkan kebijakan ini di penyimpanan FHIR.

Ringkasan model data

Model data untuk kontrol akses diwakili oleh resource Izin. Mereka menentukan aturan yang berlaku dan data yang menjadi target penerapan aturan.

Aturan akses dinyatakan melalui resource FHIR Consent. FHIR Consent adalah jenis FHIR Resource yang mencatat pilihan konsumen layanan kesehatan. Kebijakan 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 berupa pasien layanan kesehatan, siapa pun yang bertindak atas nama pasien layanan kesehatan, atau individu lain yang menyetujui perjanjian izin.

Tindakan yang dicatat dalam Izin FHIR dapat bersifat luas dan berkaitan dengan lebih dari sekadar data catatan kesehatan elektronik (EHR) konsumen, tetapi untuk tujuan izin dalam Cloud Healthcare API, fokusnya adalah pada tindakan yang terkait dengan akses data dan penegakan tindakan tersebut terbatas pada pembacaan data FHIR dari penyimpanan FHIR.

Resource Izin memiliki status yang menunjukkan status izin saat ini. Meskipun penyimpanan FHIR dapat berisi banyak izin dalam berbagai status, Cloud Healthcare API hanya menerapkan izin yang berstatus aktif. Izin dalam status lainnya tidak memengaruhi penegakan. Jika izin diberikan atas nama pasien, izin tersebut dicatat sebagai izin yang diberikan oleh penampil.

Jenis kebijakan

Cloud Healthcare API mendukung jenis kebijakan izin berikut:

Izin pasien: terkait dengan Pasien yang 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 terikat ke subset atau semua resource di toko yang ditentukan oleh kriteria resource. Kebijakan admin menetapkan kebijakan default untuk semua resource pengikatan di toko.
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 Pasien (STU3, R4) atau Pertemuan (STU3, R4) sebagai dasar kompartemen.
- Penyimpanan FHIR tempat kebijakan diterapkan harus memiliki disableReferentialIntegrity yang ditetapkan ke false. Hubungi Dukungan Cloud untuk menggunakan fitur ini bagi penyimpanan FHIR dengan integritas non-referensial.

Anda dapat menggabungkan jenis kebijakan di tingkat resource yang sama untuk mengizinkan atau menolak akses ke resource. Jika izin pasien tidak ada, kebijakan Admin dapat menyetujui akses ke resource.

Petunjuk izin adalah petunjuk yang dienkode dalam Izin FHIR yang mengizinkan atau menolak akses data ke entitas yang berwenang seperti penerima izin atau pengakses. Satu FHIR Consent dapat mengenkode beberapa petunjuk izin. Setiap direktif menyediakan hal berikut:

Jenis penegakan: petunjuk permit atau deny.
Tindakan: izin yang dicakup oleh arahan ini. Hanya access yang didukung untuk memberikan akses hanya baca.
Kriteria pengakses: sekumpulan atribut yang mengidentifikasi peminta API yang tercakup dalam arahan.
Kriteria resource: serangkaian atribut yang mengidentifikasi resource yang tercakup dalam arahan.

Kriteria akseoris

Cloud Healthcare API mendukung tiga properti pengakses untuk digunakan dalam petunjuk izin dan untuk mencocokkan pengakses yang membuat permintaan akses data. Harus ada kecocokan 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:

Aktor: merepresentasikan individu, grup, atau peran akses yang mengidentifikasi pengakses atau karakteristik pengakses.
Tujuan: menunjukkan maksud penggunaan data.
Lingkungan: merepresentasikan ID abstrak yang menjelaskan lingkungan atau kondisi saat pengakses bertindak.

Misalnya, pengakses dapat diwakili oleh properti berikut:

Pelaku: Practitioner/123
Tujuan: ETREAT atau akses untuk tujuan perawatan darurat
Lingkungan: Application/abc

Dalam contoh ini, properti ini merepresentasikan dokter yang mengakses data saat melakukan perawatan darurat menggunakan aplikasi software bernama abc.

provision.actor dan provision.purpose didefinisikan sebagai bagian dari standar FHIR, sedangkan Lingkungan adalah https://g.co/fhir/medicalrecords/Environment. Perhatikan bahwa link ini tidak dapat diselesaikan.

Semua perintah izin harus menentukan actor yang akan diterapkan, tetapi tidak selalu perlu menentukan purpose atau environment. Misalnya, jika tidak ada environment yang ditentukan dalam perintah izin, maka perintah tersebut cocok dengan environment apa pun yang belum tercakup oleh perintah izin lainnya.

Kriteria resource

Cloud Healthcare API mendukung elemen berikut sebagai bagian dari resource izin:

Jenis resource (STU3, R4): mewakili jenis yang terikat dengan kebijakan izin, misalnya, Encounter, Observation, atau Immunization.
ID Resource (STU3, R4): mewakili ID yang terikat dengan kebijakan izin.
Sumber data: merepresentasikan asal resource sebagaimana diidentifikasi oleh resource meta.source (hanya tersedia di R4).
Tag data: merepresentasikan 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 didukung:
- Kerahasiaan: nilai hierarkis yang diberi peringkat dari tidak dibatasi hingga paling dibatasi: U, L, M, N, R, V. Jika izin mengizinkan label keamanan R, izin tersebut berlaku untuk semua resource yang diberi label R atau lebih rendah. Jika izin menolak label keamanan R, maka izin tersebut berlaku untuk semua resource yang setidaknya sama sensitifnya dengan R.
- ActCode: string yang sama persis dengan kode keamanan.

Alur kerja akses

authorization_flow

Gambar ini mengilustrasikan perjalanan permintaan end-to-end ke penyimpanan yang mengaktifkan kontrol akses FHIR. Token eksternal dengan cakupan izin (kiri) digunakan oleh aplikasi (#3) saat membuat permintaan ke FHIR store dengan kontrol akses diaktifkan (kanan).

Saat membuat permintaan akses data, pengakses beroperasi dalam Cakupan Izin tertentu yang merepresentasikan properti actor, purpose, dan environment yang terkait dengan permintaan HTTP FHIR. Nilai untuk properti ini harus cocok dengan huruf besar/kecil dengan nilai yang diberikan dalam izin agar memengaruhi penentuan akses penegakan.

Accessor dapat memiliki beberapa ID actor yang relevan untuk membuat penentuan akses. Demikian pula, ada beberapa purposes atau environments yang relevan dalam konteks izin tertentu. Oleh karena itu, semua properti aksesor yang relevan harus diberikan sebagai bagian dari permintaan HTTP FHIR untuk merepresentasikan aksesor tersebut dengan benar untuk tujuan izin.

Misalnya, cakupan izin untuk permintaan data tertentu dapat berupa berikut:

actor/Practitioner/444 actor/Group/999 purp/v3/TREAT purp/v3/ETREAT env/App/abc

Ini merepresentasikan perawat atau dokter yang dikenal sebagai praktisi 444 yang merupakan anggota grup 999 yang merepresentasikan praktisi dari departemen dalam rumah sakit tertentu. Praktisi hadir untuk memberikan perawatan rutin, tetapi mungkin juga menangani perawatan darurat sebagai bagian dari tindakan ini. Praktisi menggunakan aplikasi software yang disebut abc.

Cakupan izin diberikan sebagai Cakupan izin permintaan sebagai bagian dari permintaan data aksesor.

Meminta cakupan izin

Permintaan FHIR menggunakan header permintaan HTTP FHIR untuk menerima cakupan izin pengakses. Cakupan izin ini berisi serangkaian nilai actor, purpose, dan environment untuk mencerminkan identitas, kualifikasi, maksud penggunaan, dan batasan lingkungan saat ini dari pengakses saat beroperasi. Mungkin ada lebih dari satu setiap properti ini yang merepresentasikan cakupan izin akseptor pada satu waktu.

Entri cakupan izin izin didefinisikan sebagai berikut:

actor/{type}/{ID}: properti actor tempat resource type disediakan bersama dengan ID. Contoh type mencakup:
- Practitioner
- Group
- Patient
Misalnya, jika penyimpanan dengan format projects/PROJECT_ID/locations/us-central1/datasets/DATASET_ID/fhirStores/STORE_ID memanggil API, referensi lokal ke aktor Practitioner/123 akan diselesaikan menjadi projects/PROJECT_ID/locations/us-central1/datasets/DATASET_ID/fhirStores/STORE_ID/fhir/Practitioner/123.
purp/v3/{value}: properti purpose dengan value adalah anggota set nilai FHIR Purpose of Use (v3) atau ekstensinya. Contoh value mencakup:
- TREAT
- ETREAT
- HRESCH
env/{type}/{value}: properti environment dengan type dan value berupa string kustom tanpa taksonomi yang telah ditentukan sebelumnya. Contoh type dan value 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: Fitur Break the glass (atau BTG) memungkinkan Anda, sebagai pengguna manusia, melewati pemeriksaan izin jika terjadi keadaan darurat. Fitur ini hanya boleh digunakan dalam keadaan darurat dan tunduk pada peninjauan pasca-audit. Akibatnya, btg memerlukan setidaknya satu actor.
bypass: Memungkinkan pengguna tepercaya (seperti administrator) atau aplikasi tepercaya (seperti pipeline pelatihan ML) beroperasi di penyimpanan FHIR tanpa otorisasi izin. Oleh karena itu, bypass memerlukan setidaknya satu actor dan satu env.

Penerapan akses dan penentuan akses

Dalam lingkungan layanan kesehatan yang kompleks dengan beberapa kebijakan dan izin yang ada bersamaan, penerapan akses dan penentuan izin akses dapat menjadi tugas yang sulit. Berbagai pemangku kepentingan mungkin memiliki ekspektasi dan persyaratan yang berbeda-beda terkait penggunaan dan pengungkapan informasi pasien. Untuk memahami lanskap yang rumit ini, Anda harus memahami dengan jelas cara akses diterapkan dan logika yang mendasarinya yang mengatur penentuan akses.

Kebijakan izin gabungan

Konsumen layanan kesehatan, seperti pasien atau administrator, dapat memiliki beberapa petunjuk izin yang terdapat dalam satu resource Izin. Resource izin dapat berisi campuran permit dan deny provision.type direktif. Secara default, pengguna dapat memiliki sejumlah resource Izin, tetapi hingga 200 resource Izin active diterapkan dalam satu waktu. Lihat Batasan dan keterbatasan untuk mengetahui detail selengkapnya.

Semua arahan izin diekstrak dari active Resource izin untuk pengguna tertentu guna membuat serangkaian aturan izin gabungan.

Properti direktif izin

Penerapan izin dibatasi maksimal satu tujuan dan maksimal satu lingkungan per entri penyediaan.

Aturan berikut menjelaskan prinsip untuk kontrol akses bersama atas izin pasien, kebijakan admin, dan kebijakan bertingkat admin:

Semua resource ditolak aksesnya secara default jika tidak ada direktif 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 patient-compartment atau encounter-compartment: akses ditolak.
- Atau:
  - Jika ada kebijakan admin yang menolak kriteria pengakses terlepas dari kriteria resource lainnya, akses akan ditolak.
  - Jika ada kebijakan admin yang mengizinkan kriteria akses untuk kriteria resource yang dapat diidentifikasi (yaitu jenis resource dan ID resource), error "resource tidak ditemukan" akan ditampilkan.
  - Untuk semua kasus lainnya, akses ditolak.
Kebijakan admin adalah kebijakan default yang digunakan untuk mencocokkan resource di toko.
Resource yang tidak dimiliki oleh pasien mana pun ditentukan hanya oleh kebijakan admin.
Resource yang ada di kompartemen pasien (STU3, R4) atau kompartemen pertemuan (STU3, R4) memerlukan setidaknya satu perintah izin persetujuan per pasien atau kebijakan admin atau kebijakan berjenjang admin dan tidak ada perintah izin penolakan dari pasien dan kebijakan admin dan kebijakan berjenjang admin. Kondisi ini diperlukan dari semua pasien yang disebutkan dalam resource agar dapat diakses oleh pemohon.
- Beberapa resource dapat mendukung beberapa peserta pasien. Misalnya, Appointment menyediakan daftar peserta yang mungkin adalah pasien. Semua pasien yang disebutkan dalam resource tersebut harus mengizinkan akses ke pengakses menggunakan direktif izin, jika tidak, resource tidak akan ditampilkan. Jika resource memiliki izin dari kebijakan berjenjang pertemuan, yang merujuk pasien melalui kolom subject (STU3, R4), maka resource tersebut dianggap diizinkan oleh pasien.

Aturan yang dijelaskan diringkas oleh kode semu berikut:

Kontrol akses bersama

if resource does not exist
  if resource is a patient-compartment or encounter-compartment resource:
    return "deny"
  else:
    if there is any admin policy denies access for accessor criteria regardless of resource criteria other than resource type and resource ID:
      return "deny"
    else if there is any admin policy permits access for accessor criteria based on the identifiable resource criteria:
      return "resource not found"
    else:
      return "deny"
else:
  let patients = list of patient references named in the patient compartment eligible fields of the requested resource
  if there is any matching deny from either patients's consents or admin policy or admin cascading policy:
    return "deny"
  if there is matching admin policy permits access:
    return "permit"
  if all patients have matching patient consents or admin cascading consent that permit access or are subject of encounters which permit the access through encounter cascading policy:
    return "permit"
  else:
    return "deny"
end

Penyimpanan FHIR memeriksa izin persetujuan di tingkat per resource. Setiap referensi dalam resource tidak di-resolve dan dikaskade untuk tujuan pemeriksaan akses izin. Misalnya, pertimbangkan pasien yang diidentifikasi oleh Patient/f001 yang memungkinkan Praktisi mengakses seluruh resource MedicationRequest miliknya, 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, misalnya, saat melakukan penelusuran FHIR menggunakan _include.

Penyelesaian konflik

Konflik dapat terjadi antara berbagai arahan permit dan deny. Jika dua perintah yang bertentangan cocok dengan suatu resource, konflik akan diselesaikan menggunakan model deny menang atas permit.

Hanya izin active yang disertakan untuk penerapan izin.

Logika penerapan akses resource

Saat membuat permintaan yang mendukung izin ke penyimpanan FHIR, kontrol akses terjadi dalam urutan berikut:

Cloud Healthcare API memeriksa izin pada Google Cloud akun layanan (atau akun utama) yang dikonfigurasi di proxy. Jika akun layanan memiliki izin IAM yang benar untuk melakukan metode FHIR yang diminta di penyimpanan FHIR, permintaan akan dilanjutkan.
Jika penegakan izin diaktifkan dalam konfigurasi penyimpanan FHIR dan header HTTP yang mendukung izin ada, maka Cloud Healthcare API akan menerapkan kebijakan akses izin untuk resource Kompartemen Pasien. Penerapan kebijakan akses izin didasarkan pada cakupan izin yang diberikan dalam permintaan, sesuai dengan arahan izin yang diambil oleh eksekusi ApplyConsents dan ApplyAdminConsents terbaru.

Catatan: Jika konfigurasi penyimpanan FHIR menentukan penanganan header izin sebagai REQUIRED_ON_READ, kontrol akses izin akan diterapkan (dan ditolak) meskipun tanpa header yang mendukung izin.

Aturan berikut berlaku saat membuat permintaan yang mendukung izin ke penyimpanan FHIR:

Berikan setidaknya satu cakupan izin actor yang relevan untuk tindakan pemberian izin yang dilakukan.
Berikan cakupan purpose dan environment 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.Encounter-everything, fhir.executeBundle, atau fhir.search), penerapan izin berlaku untuk setiap resource. Namun, ada perbedaan kecil antara metode akses multi-resource ini:
- fhir.executeBundle membaca beberapa resource menerima "Akses izin ditolak atau resource yang diakses tidak ada" untuk setiap resource tanpa izin persetujuan (lihat contoh di Mendapatkan resource FHIR dengan cakupan izin).
- fhir.search melewati resource tanpa izin persetujuan dan tidak menampilkan error akses ditolak persetujuan, bahkan untuk penelusuran berdasarkan _id (lihat contoh di Menelusuri resource FHIR dengan cakupan persetujuan).
- fhir.Patient-everything dan fhir.Encounter-everything berperilaku serupa dengan fhir.search, kecuali bahwa keduanya menampilkan "Akses izin ditolak atau resource yang diakses tidak ada" jika pemanggil tidak memiliki izin persetujuan pada resource Pasien atau Kunjungan yang diminta.

Petunjuk izin memiliki paling banyak satu actor, paling banyak satu purpose, dan paling banyak satu environment, sedangkan cakupan izin dapat memiliki beberapa setiap jenisnya. Beberapa petunjuk izin tidak menentukan ketiga properti pengakses, sehingga nilai properti cakupan izin apa pun dapat cocok, bergantung pada aturan penyelesaian konflik. Akibatnya, cakupan izin dapat cocok dengan lebih dari satu petunjuk izin.

Jika cakupan izin permintaan mencakup dua entri atau lebih dengan jenis cakupan izin yang sama (actor, purpose, atau environment), maka cakupan izin mungkin cocok dengan beberapa petunjuk izin. Beberapa petunjuk izin tidak menentukan purpose atau environment. Oleh karena itu, cakupan izin juga harus dicocokkan dengan petunjuk izin yang tidak menentukan jenis cakupan ini.

Misalnya, menyetel cakupan izin ke actor/Practitioner/123 actor/Group/999 purp/v3/TREAT env/App/abc akan cocok dengan salah satu dari petunjuk 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

Langkah berikutnya

Pelajari cara menerapkan akses di penyimpanan FHIR.