Sistem kontrol dan model data akses FHIR

Ringkasan model data

Model data untuk kontrol akses direpresentasikan oleh Resource izin. Aturan ini mendefinisikan aturan yang berlaku dan data di mana aturan diterapkan.

Aturan akses dinyatakan melalui 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 dapat menerapkan izin yang berada dalam status aktif. Izin di negara bagian lainnya tidak akan 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 ke false.

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

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 atau deny.

  • 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 darurat

  • Lingkungan: 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, atau Immunization.

  • 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 keamanan R, label tersebut akan berlaku untuk semua resource yang berlabel R atau lebih rendah. Jika izin menolak label keamanan R, izin tersebut akan berlaku untuk semua resource yang setidaknya sensitif seperti R.

    • ActCode: string yang sama persis dengan kode keamanan.

Alur kerja akses

authorization_flow

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

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}: properti actor tempat resource type disediakan bersama dengan ID. Contoh type 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 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 merupakan anggota dari kumpulan nilai FHIR Destination of Use (v3) atau ekstensinya. Contoh penggunaan value meliputi:

    • TREAT
    • ETREAT
    • HRESCH
  • env/{type}/{value}: properti environment dengan type dan value adalah string kustom tanpa taksonomi yang telah ditentukan. 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: 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 satu actor.
  • 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 satu actor dan satu env.

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.

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.

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 untuk semua resource yang cocok 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 formula berikut.

Kontrol akses bersama

if resource does not exist
  if resource is a patient-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:
    return "permit"
  else:
    return "deny"
end

Penyimpanan FHIR memeriksa izin izin pada tingkat resource, bukan pada tingkat referensi. Misalnya, pasien yang diidentifikasi oleh Patient/f001 memungkinkan Praktisi mengakses seluruh resource MedicationRequest mereka, tetapi tidak ke resource Patient/f001 itu sendiri karena privasi pasien. Dalam skenario ini, Praktisi yang diberi izin dapat melihat seluruh resource MedicationRequest yang menyertakan kolom subject yang merujuk ke resource Patient/f001, tetapi tidak dapat melihat konten resource Patient/f001 meskipun dengan _include melalui penelusuran.

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:

  1. Cloud Healthcare API memeriksa izin di Google Cloud

    akun layanan yang dikonfigurasi di proxy. Jika akun layanan memiliki izin IAM yang benar di penyimpanan FHIR, permintaan akan dilanjutkan.

  2. 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 dan ApplyAdminConsents 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 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.executeBundle, atau fhir.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 dengan fhir.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.

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

Langkah selanjutnya