Model data dan sistem kontrol akses FHIR

Pratinjau

Halaman ini menjelaskan fitur Pratinjau yang dapat berubah sewaktu-waktu dan mungkin memiliki dukungan terbatas. Perubahan pada produk dan fitur pra-GA mungkin tidak kompatibel dengan versi pra-GA lainnya. Untuk mengetahui informasi selengkapnya, lihat Persyaratan Penawaran Pra-GA untuk Cloud Healthcare API dan deskripsi tahap peluncuran.

Ringkasan model data

Model data untuk kontrol akses diwakili oleh Resource izin. Aturan ini menentukan aturan yang berlaku dan data mana yang akan diterapkan aturan tersebut.

Izin FHIR

Aturan akses dinyatakan melalui resource Izin FHIR. Izin FHIR adalah jenis Resource FHIR yang merekam pilihan konsumen layanan kesehatan. Kebijakan ini mengizinkan atau menolak sekumpulan aktor untuk melakukan tindakan yang memengaruhi konsumen untuk tujuan tertentu dari lingkungan yang ditentukan selama jangka waktu tertentu. Misalnya, konsumen dapat berupa pasien layanan kesehatan, siapa pun yang bertindak atas nama pasien layanan kesehatan, atau individu lain yang menandatangani perjanjian izin.

Tindakan yang dicatat dalam Izin FHIR mungkin bersifat luas dan menangani 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 membaca data FHIR dari penyimpanan FHIR.

Resource Izin memiliki status yang menunjukkan status izin saat ini. Meskipun penyimpanan FHIR dapat berisi banyak izin dalam status yang berbeda, Cloud Healthcare API hanya menerapkan izin yang berada dalam status aktif. Izin di negara bagian lainnya tidak berpengaruh pada penegakan. Jika izin diberikan atas nama pasien, izin tersebut dicatat sebagai diberikan oleh pemain.

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 terikat ke sebagian atau semua resource di penyimpanan yang ditentukan oleh kriteria resource. Kebijakan admin menetapkan kebijakan default untuk semua resource binding di toko.

• Kebijakan cascading 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.

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 referensi.

Perintah izin

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

• Jenis penegakan: petunjuk permit atau deny.

• Tindakan: izin yang tercakup dalam perintah ini. Hanya access yang didukung untuk memberikan akses hanya baca.

• Kriteria pengakses: kumpulan atribut yang mengidentifikasi peminta API yang tercakup dalam perintah.

• Kriteria resource: kumpulan atribut yang mengidentifikasi resource yang tercakup dalam 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 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: mewakili individu, grup, atau peran akses yang mengidentifikasi pengakses atau karakteristik pengakses.

• Tujuan: mewakili niat penggunaan data.

• Lingkungan: mewakili ID abstrak yang menjelaskan lingkungan atau kondisi tempat pengakses bertindak.

Misalnya, pengakses dapat direpresentasikan oleh properti berikut:

• Pelaku: Practitioner/123

• Tujuan: ETREAT atau akses untuk tujuan perawatan darurat

• Lingkungan: Application/abc

Dalam contoh ini, properti ini mewakili 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. Perhatikan bahwa link ini tidak dapat di-resolve.

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

Kriteria resource

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

• Jenis resource (STU3, R4): mewakili jenis yang menjadi tempat kebijakan izin terikat, misalnya, Encounter, Observation, atau Immunization.

• ID Resource (STU3, R4): mewakili ID yang menjadi tempat kebijakan izin terikat.

• Sumber data: mewakili asal resource seperti yang diidentifikasi oleh resource meta.source (hanya tersedia di R4).

• Tag data: mewakili label kustom resource seperti yang dijelaskan dalam resource meta.tag (STU3, R4).

• Label keamanan: mewakili 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, izin tersebut akan berlaku untuk semua resource yang setidaknya sama sensitifnya dengan R.

  • ActCode: pencocokan string persis pada kode keamanan.

Catatan: Contoh cara berbagai kebijakan dapat direpresentasikan melalui Resource izin dapat ditemukan di Dokumen Cara Kerja.

Mengakses alur kerja

Gambar ini mengilustrasikan perjalanan menyeluruh permintaan ke penyimpanan yang mengaktifkan 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. Nilai untuk properti ini harus cocok dengan huruf besar/kecil yang diberikan dalam izin agar dapat memengaruhi penentuan akses penegakan.

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

Misalnya, cakupan izin untuk permintaan data tertentu dapat berupa hal 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 tersebut ada 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 Request consent scope sebagai bagian dari permintaan data pengakses.

Meminta cakupan izin

Permintaan FHIR menggunakan header permintaan HTTP FHIR untuk menerima cakupan izin pengakses. Cakupan izin ini berisi kumpulan nilai actor, purpose, dan environment untuk mencerminkan identitas, kualifikasi, intent penggunaan, dan batasan lingkungan saat ini dari pengakses. Mungkin ada lebih dari satu properti yang mewakili cakupan izin pengakses 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 hal berikut:

  • 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 di-resolve ke projects/PROJECT_ID/locations/us-central1/datasets/DATASET_ID/fhirStores/STORE_ID/fhir/Practitioner/123.

• purp/v3/{value}: properti purpose dengan value adalah anggota kumpulan nilai Tujuan Penggunaan FHIR (v3) atau ekstensiannya. Contoh value meliputi:

  • TREAT
  • ETREAT
  • HRESCH

• env/{type}/{value}: properti environment dengan type dan value adalah string kustom tanpa taksonomi yang telah ditentukan sebelumnya. Contoh type dan value meliputi:

  • 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: Break the glass (atau BTG) memungkinkan Anda, sebagai pengguna manusia, melewati pemeriksaan izin jika terjadi keadaan darurat. Akun ini hanya boleh digunakan dalam keadaan darurat dan tunduk pada peninjauan pasca-audit. Oleh karena itu, btg memerlukan setidaknya satu actor.
• bypass: Mengizinkan pengguna tepercaya (seperti administrator) atau aplikasi tepercaya (seperti pipeline pelatihan ML) untuk beroperasi di penyimpanan FHIR tanpa otorisasi izin. Oleh karena itu, bypass memerlukan minimal satu actor dan satu env.

Catatan: Permintaan yang menggunakan btg atau bypass dianotasi secara berbeda di consentMode log audit. Untuk memfasilitasi pemeriksaan tata kelola data, kedua hak istimewa khusus ini hanya boleh digunakan untuk tujuan yang dimaksudkan.

Penerapan akses dan penentuan akses

Di lingkungan layanan kesehatan yang kompleks, di mana beberapa kebijakan dan izin bersama-sama, menerapkan akses dan menentukan izin akses dapat menjadi tugas yang berat. Berbagai pemangku kepentingan mungkin memiliki ekspektasi dan persyaratan yang berbeda terkait penggunaan dan pengungkapan informasi pasien. Untuk menavigasi medan yang rumit ini, Anda memerlukan pemahaman yang jelas tentang cara penerapan akses dan logika yang mendasarinya 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 dapat memiliki resource Izin dalam jumlah berapa pun, tetapi hingga 200 resource Izin active akan diterapkan dalam satu waktu. Lihat Batasan dan keterbatasan untuk mengetahui detail selengkapnya.

Semua perintah izin diekstrak dari resource Izin active untuk pengguna tertentu guna membuat kumpulan aturan izin gabungan.

Properti perintah izin

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

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

• Semua resource akan ditolak aksesnya 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 atau kompartemen pertemuan: akses akan 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 pengakses untuk kriteria resource yang dapat diidentifikasi (yaitu jenis resource dan ID resource), error "resource not found" akan ditampilkan.

    • Untuk kasus lainnya, akses akan ditolak.

• Kebijakan admin adalah kebijakan default yang digunakan untuk mencocokkan resource di Play Store.

• Resource yang bukan milik pasien mana pun hanya ditentukan oleh kebijakan admin.

• Resource yang berada di kompartemen pasien (STU3, R4) atau kompartemen pertemuan (STU3, R4) memerlukan minimal satu perintah izin izin per kebijakan admin atau pasien atau kebijakan cascading admin dan tidak ada perintah izin tolak dari kebijakan admin dan pasien dan kebijakan cascading admin. Kondisi ini diperlukan dari semua pasien yang disebutkan di resource yang akan diakses oleh pemohon.

  • Beberapa referensi mungkin mendukung beberapa peserta pasien. Misalnya, Janji temu memberikan daftar peserta yang mungkin adalah pasien. Semua pasien yang disebutkan di resource tersebut harus mengizinkan akses ke pengakses menggunakan perintah izin, jika tidak, resource tidak akan ditampilkan. Jika resource memiliki izin dari kebijakan cascading pertemuan, dengan pertemuan ini mereferensikan pasien melalui kolom subject (STU3, R4), 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 izin di tingkat per resource. Setiap referensi dalam resource tidak di-resolve dan di-cascade untuk tujuan pemeriksaan akses izin. Misalnya, pertimbangkan pasien yang diidentifikasi oleh Patient/f001 yang memungkinkan Praktisi mengakses seluruh resource MedicationRequest-nya, tetapi tidak 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 perintah permit dan deny. Jika dua perintah yang bertentangan cocok dengan 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 berbasis izin ke penyimpanan FHIR, kontrol akses terjadi dalam urutan berikut:

1. Cloud Healthcare API memeriksa izin di 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.

2. Jika penerapan izin diaktifkan di konfigurasi penyimpanan FHIR dan header HTTP yang mendukung izin ada, 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 perintah izin yang diambil oleh eksekusi terbaru ApplyConsents dan ApplyAdminConsents.

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

Aturan berikut berlaku saat membuat permintaan berbasis izin ke penyimpanan FHIR:

• Berikan minimal satu cakupan izin actor yang relevan untuk tindakan 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 yang membaca beberapa resource menerima "Akses izin ditolak atau resource yang diakses tidak ada" untuk setiap resource tanpa izin izin (lihat contoh di Mendapatkan resource FHIR dengan cakupan izin).

  • fhir.search melewati resource tanpa izin izin dan tidak menampilkan error akses izin ditolak, bahkan untuk penelusuran menurut _id (lihat contoh di Menelusuri resource FHIR dengan cakupan izin).

  • 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 izin pada resource Pasien atau Pertemuan yang diminta.

Penentuan akses izin

Perintah izin memiliki maksimal satu actor, maksimal satu purpose, dan maksimal satu environment, sedangkan cakupan izin dapat memiliki beberapa dari masing-masing. Beberapa perintah izin tidak menentukan ketiga properti pengakses, dalam hal ini, nilai properti cakupan izin apa pun dapat cocok, bergantung pada aturan resolusi konflik. Akibatnya, cakupan izin dapat cocok dengan lebih dari satu perintah izin.

Jika cakupan izin 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 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

Langkah selanjutnya

• Pelajari cara menerapkan akses di penyimpanan FHIR