De-identifikasi gambar medis melalui Cloud Healthcare API

Pengantar

Dokumen ini menjelaskan cara peneliti, data scientist, tim IT, atau organisasi layanan kesehatan dan ilmu hayati dalam menggunakan Cloud Healthcare API untuk menghapus informasi identitas pribadi (PII) dan informasi kesehatan terlindungi (PHI) dari data Digital Imaging and Communications in Medicine (DICOM). Proses ini, yang dikenal sebagai de-identifikasi, membantu memastikan privasi pasien serta mempersiapkan data DICOM untuk digunakan dalam penelitian, berbagi data, dan machine learning.

Tutorial berikut, Penggunaan Cloud Healthcare API untuk melakukan de-identifikasi gambar medis, akan memandu Anda melalui dua kasus penggunaan untuk de-identifikasi data gambar medis dengan menggunakan Cloud Healthcare API.

Cara kerja de-identifikasi data DICOM

Gambar medis yang diakuisisi untuk tujuan klinis dapat memiliki kegunaan sekunder yang penting untuk proyek penelitian dan pengajaran perpustakaan. Namun, Anda mungkin perlu menghapus atau mengubah elemen data sensitif (PII atau PHI) dari gambar DICOM sebelum menganalisis atau membagikan data tersebut kepada kolaborator yang berwenang.

Diagram berikut menunjukkan beberapa pipeline gambar medis dari sumber lokal yang dialihkan ke Google Cloud dan kemudian diubah menjadi anonim oleh Cloud Healthcare API operasi de-identifikasi.

Pipeline de-identifikasi DICOM.

Pertama, Anda mengupload gambar medis berformat DICOM ke Cloud Storage, kemudian ke Cloud Healthcare API. Sebagai alternatif, Anda dapat mengupload gambar DICOM secara langsung ke Cloud Healthcare API. Gambar medis, yang tersimpan di penyimpanan DICOM di Cloud Healthcare API, akan dialihkan dengan proses de-identifikasi Cloud Healthcare API guna menganonimkan gambar dan metadata terkait.

Misalnya, sebagai peneliti medis, Anda perlu memiliki akses ke gambar x-ray patah tulang belakang pasien di pengarsipan gambar lokal dan sistem komunikasi (PACS). Anda dapat memindahkan data piksel gambar ke Cloud Storage dengan menggunakanStorage Transfer Service, Transfer Appliance, atau salah satu produk konektivitas hybrid. Selanjutnya, Anda dapat menyalin atau memindahkan data dari Cloud Storage ke Cloud Healthcare API. Setelah data berhasil dipindahkan ke Cloud Healthcare API, Anda dapat menggunakan data tersebut sebagai data cadangan, melihatnya dari jarak jauh, atau mengizinkannya untuk diakses oleh layanan dan aplikasi cloud pihak ketiga yang telah disetujui.

Dalam skenario lain, Anda dapat mengirim gambar DICOM yang telah dide-identifikasi ke AutoML Vision untuk melatih model yang dapat membantu tim layanan kesehatan dalam mendeteksi patah tulang belakang di sinar x-ray. Dengan cara ini, Anda dapat membangun alat pendukung keputusan klinis dengan menggunakan data Anda sendiri.

Cloud Healthcare API

Cloud Healthcare API menawarkan solusi terkelola untuk menyimpan dan mengakses data layanan kesehatan di Google Cloud, sehingga memberikan penghubung penting antara sistem layanan kesehatan yang sudah ada dan aplikasi yang dihosting di Google Cloud.

Dalam proyek Google Cloud, data yang diserap melalui Cloud Healthcare API akan disimpan dalam set data, yang berada di lokasi geografis yang sesuai dengan wilayah Google Cloud. Cloud Healthcare API mendukung wilayah yang terdaftar di Wilayah. Untuk daftar produk Google Cloud dan wilayah tempat produk tersebut diimplementasikan, lihat Lokasi cloud.

Karena setiap modalitas data layanan kesehatan—misalnya, DICOM, Fast Healthcare Interoperability Resources (FHIR), dan HL7v2—memiliki perbedaan struktural dan pemrosesan, set data dibagi menjadi penyimpanan khusus modalitas.

Diagram berikut menunjukkan cara Cloud Healthcare API mengatur data klinis berdasarkan lokasi, set data, dan penyimpanan.

Pengaturan data klinis Cloud Healthcare API.

Setiap set data berisi satu penyimpanan atau lebih yang melayani modalitas yang sama atau modalitas yang berbeda, sesuai kebutuhan aplikasi. Penggunaan beberapa penyimpanan dalam set data yang sama mungkin lebih cocok digunakan jika aplikasi memproses berbagai jenis data. Misalnya, Anda mungkin ingin memisahkan data berdasarkan sumber, seperti rumah sakit, klinik, atau departemen. Sebuah aplikasi dapat mengakses set data atau penyimpanan sebanyak yang diperlukan tanpa terjadi penurunan performa. Penting untuk mendesain keseluruhan set data dan arsitektur penyimpanan untuk memenuhi tujuan organisasi Anda secara luas, seperti kedekatan resource komputasi atau pengguna akhir, partisi, atau kontrol akses.

Diagram berikut menunjukkan dua set data yang berisi penyimpanan HL7v2, DICOM, dan FHIR .

Arsitektur set data dengan penyimpanan HL7v2 dan DICOM.

Anda dapat menyalin gambar DICOM ke penyimpanan DICOM atau menyimpannya dalam set data dari berbagai sumber. Untuk informasi selengkapnya, lihat Cara membuat dan mengelola penyimpanan DICOM.

Melakukan de-identifikasi data DICOM

Cloud Healthcare API mencakup alat de-identifikasi yang dapat menyamarkan (menghapus) atau mengubah konten sensitif secara skalabel dalam teks dan gambar, berdasarkan konfigurasi yang ditentukan.

Alat ini beroperasi pada teks dan gambar yang dienkode dalam format rekam medis tertentu, seperti DICOM dan FHIR. Saat Anda menggunakan instance DICOM, komponen untuk panggilan API de-identifikasi meliputi:

  • Sumber: Set data atau penyimpanan DICOM yang berisi satu atau beberapa instance DICOM dengan data sensitif. Tutorial berikut menggunakan set data, tetapi Anda dapat mengubah contoh tersebut agar dapat berfungsi pada satu penyimpanan DICOM.
  • Hal yang harus dilakukan untuk de-identifikasi: Parameter konfigurasi inilah yang menentukan cara memproses set data. Anda dapat mengonfigurasi operasi de-identifikasi DICOM untuk melakukan de-identifikasi metadata instance DICOM dengan menggunakan kata kunci tag, dengan menyamarkan teks sisipan dalam gambar DICOM, atau keduanya.
  • Tujuan: De-identifikasi tidak memengaruhi set data asli atau datanya. Sebagai gantinya, salinan data asli yang diproses ditulis ke set data baru atau penyimpanan DICOM, yang disebut tujuan. Tutorial berikut menggunakan set data, tetapi Anda dapat mengubah contoh tersebut agar dapat berfungsi di penyimpanan DICOM.

Dua gambar berikut menunjukkan contoh gambar x-ray sebelum dan sesudah de-identifikasi, yang tujuannya untuk menghapus atau mengubah semua metadata dan teks sisipan yang berkaitan dengan gambar tersebut.

Gambar pertama menunjukkan gambar x-ray dengan sampel data PII dan PHI yang muncul di metadata dan teks sisipan.

Ambil sampel gambar x-ray yang sebelum melalui proses de-identifikasi (dengan data sampel).

Gambar kedua menunjukkan gambar x-ray yang sama dengan semua sampel metadata PII dan PHI yang dihapus atau disamarkan.

Ambil sampel gambar x-ray yang setelah melalui proses de-identifikasi (dengan data sampel).

Setelah melakukan de-identifikasi, semua metadata gambar akan dihapus, dan semua teks sisipan yang ada dalam gambar akan disamarkan dengan tanda persegi panjang buram. Konfigurasi de-identifikasi ini berguna ketika Anda hanya memerlukan data piksel gambar untuk analisis lebih lanjut, pelatihan model machine learning (ML), atau inferensi.

Misalnya, Anda mungkin ingin melatih model klasifikasi gambar untuk menentukan adanya patah tulang pada gambar x-ray. Untuk melatih model ini, Anda memerlukan sampel gambar dalam jumlah besar—baik sampel yang berisi gambar patah tulang maupun yang tidak. Namun, dalam model ini, Anda tidak perlu informasi sensitif apa pun, seperti jenis kelamin, umur, atau tanggal lahir pasien, karena informasi ini tidak relevan.

Atau Anda mungkin ingin menganalisis perkembangan penyakit tertentu pada sekelompok pasien seiring bertambahnya usia mereka. Dalam hal ini, Anda perlu mengetahui informasi seperti umur dan jenis kelamin pasien serta tanggal setiap penelitian, karena informasi ini relevan dengan analisis klinis. Anda memiliki opsi untuk menyimpan beberapa metadata, sekaligus menyamarkan informasi identifikasi lain tentang pasien, seperti nama dan nomor rekam medis mereka.

Praktik terbaiknya adalah mengubah tanggal dalam penelitian apa pun sehingga linimasa relatif terjaga, tetapi mencocokkan tanggal tersebut dengan informasi pasien hampir tidak mungkin dilakukan. Untuk informasi selengkapnya, lihat perubahan tanggal.

Akses yang diperlukan dan peran Identity and Access Management

Di Google Cloud, akses ke resource dikelola melalui peran Identity and Access Management (IAM). Akses ke Cloud Healthcare API mengharuskan akun (IAM) Anda memiliki peran yang sesuai dengan fungsi yang ingin dijalankan.

Anda dapat menggunakan akun pengguna (akun yang Anda gunakan untuk mengakses Google Cloud Console) atau akun layanan IAM. Tutorial berikut menggunakan akun layanan, untuk menampilkan gambar medis, Anda harus menggunakan akun pengguna. Informasi umum yang disajikan disini berlaku untuk semua jenis akun.

Untuk membuat set data tujuan, Anda harus memiliki setidaknya izin untuk mengakses set data sumber healthcare.datasets.deidentify dan izin untuk mengakses proyek Google Cloud healthcare.datasets.create. Peran IAM Healthcare Dataset Administrator mencakup kedua izin ini.

Untuk informasi tentang cara mengontrol akses ke set data dan penyimpanan DICOM, lihat Kontrol akses untuk resource Cloud Healthcare API. Untuk informasi tentang izin yang diperlukan pada metode set data, lihat Kontrol akses atau Cloud Healthcare API.

Gambar medis untuk pelihat

Pelihat DICOM berikut terintegrasi dengan Cloud Healthcare API, dan Anda dapat menggunakannya untuk melihat gambar sebelum dan sesudah de-identifikasi:

Agar versi pelihat berfungsi dengan baik, kredensial login Anda harus memiliki peran healthcare.dicomViewer.

Struktur API

Anda dapat mengakses dan mengelola data dalam set data dan penyimpanan Cloud Healthcare API dengan menggunakan REST API yang mengidentifikasi setiap penyimpanan berdasarkan proyek, lokasi, set data, jenis penyimpanan, dan nama penyimpanan Google Cloud. Cloud Healthcare API menerapkan standar modalitas per set untuk akses yang konsisten dengan standar industri di tiap modalitas masing-masing. Misalnya, Cloud Healthcare API secara native menyediakan operasi untuk membaca penelitian dan seri DICOM yang konsisten dengan DICOMweb.

Operasi yang mengakses penyimpanan khusus modalitas yang menggunakan jalur permintaan terdiri dari jalur dasar dan jalur permintaan khusus modalitas. Operasi administratif—yang umumnya hanya beroperasi di lokasi, set data, dan penyimpanan data—mungkin hanya dapat menggunakan akses jalur dasar.

Untuk mereferensikan penyimpanan tertentu dalam set data Cloud Healthcare API, gunakan jalur dasar yang terstruktur seperti berikut ini:

 /projects/project/locations/location/datasets/dataset/store-type/store-name

Ganti kode berikut:

  • project: proyek Google Cloud Anda
  • location: area tempat resource Anda berada
  • dataset: nama set data Anda
  • store-type: jenis penyimpanan data
  • store-name: nama penyimpanan data Anda

Berikut adalah contoh jalur dasar:

/projects/MyProj/locations/us-central1/datasets/dataset1/dicomStores/dicomstore1

Contoh jalur sebelumnya merujuk pada penyimpanan DICOM Cloud Healthcare API di proyek Google Cloud MyProj, di wilayah US-central, dalam set data yang disebut dataset1, dan diberi nama sebagai dicomstore1.

Untuk mengakses data, Anda perlu menggabungkan jalur dasar dengan jalur permintaan yang diformat sesuai standar modalitas yang cocok. Misalnya, permintaan DICOMWeb ke penyimpanan DICOM mungkin terlihat seperti ini:

 base-path/dicomWeb/studies/{study_id}/series?PatientName={patient_name}

Bagian jalur base-path mewakili jalur dasar khusus ke permintaan ini. Sedangkan bagian jalur {study_id} mengidentifikasi penelitian DICOM tertentu dan nama pasien yang telah ditentukan {patient_name}. Pada contoh sebelumnya, spesifikasi jalur ini konsisten dengan struktur jalur standar DICOMWeb.

De-identifikasi menggunakan konfigurasi tag dan penyamaran gambar

De-identifikasi data DICOM mencakup dua proses:

  • Melakukan de-identifikasi metadata DICOM
  • Menyamarkan teks sisipan dalam gambar

Dalam Cloud Healthcare API, de-identifikasi metadata didasarkan pada tag DICOM, dan penyamaran teks sisipan dilakukan melalui opsi TextRedactionMode.

Menggunakan tag dan profil untuk melakukan de-identifikasi

Anda dapat melakukan de-identifikasi instance DICOM dengan menggunakan kata kunci tag dalam metadata DICOM. Metode pemfilteran tag berikut tersedia di objek DicomConfig:

  • keepList: Daftar tag yang perlu disimpan. Menghapus semua tag lainnya.
  • removeList: Daftar tag yang akan dihapus. Menyimpan semua tag lainnya.
  • TagFilterProfile: Profil pemfilteran tag yang menentukan tag mana yang harus disimpan atau dihapus.

Tag atribut minimum DICOM

Tag berikut adalah atribut minimum instance DICOM yang valid dalam Cloud Healthcare API:

  • StudyInstanceUID
  • SeriesInstanceUID
  • SOPInstanceUID
  • TransferSyntaxUID
  • MediaStorageSOPInstanceUID
  • MediaStorageSOPClassUID
  • PixelData
  • Rows
  • Columns
  • SamplesPerPixel
  • BitsAllocated
  • BitsStored
  • Highbit
  • PhotometricInterpretation
  • PixelRepresentation
  • NumberOfFrames

keepList

Untuk menggunakan metode pemfilteran tag keepList, Anda perlu menyediakan daftar tag nama. Hanya tag ini yang satu-satunya dipertahankan dalam resource yang telah dide-identifikasi. Saat Anda menentukan tag keeplist dalam objek DicomConfig, tag atribut minimum DICOM akan ditambahkan secara default.

Jika tidak ada tag keeplist yang disediakan, tag DICOM dalam set data tidak akan dihapus. Umumnya, saat tag disimpan, tag tidak akan mengalami perubahan pada output jika dibandingkan dengan aslinya. Namun, tag StudyInstanceUID, SeriesInstanceUID, SOPInstanceUID, dan MediaStorageSOPInstanceUID dibuat ulang dengan nilai baru yang unik pada outputnya.

removeList

Anda dapat menentukan tag removeList dalam objek DicomConfig. Operasi de-identifikasi hanya akan menghapus tag tertentu dalam daftar. Jika tidak ada tag removeList yang diberikan, operasi de-identifikasi akan berlangsung seperti biasa, tetapi tidak ada tag DICOM dalam set data tujuan yang disamarkan.

Tag atribut minimum DICOM tidak dapat ditambahkan ke removeList.

TagFilterProfile

Dibandingkan menentukan tag yang akan disimpan atau dihapus, Anda dapat menggunakan alternatif lain dengan memanfaatkan profil TagFilterProfile. Profil yang telah ditentukan ini akan menentukan cara tag ditangani dan diubah. Misalnya, profil MINIMAL_KEEP_LIST_PROFILE hanya menyimpan tag yang diperlukan untuk menghasilkan resource DICOM yang valid dan menghapus semua tag lainnya. Untuk informasi selengkapnya, lihat dokumentasi TagFilterProfile.

Kami merekomendasikan profil TagFilterProfile sebagai metode pemfilteran tag, terutama untuk pengguna nonteknis, karena profil yang dipilih sebelumnya berarti Anda tidak perlu meninjau dan memahami semua tag DICOM dan konten mereka.

Profil yang sering digunakan

Anda dapat melakukan salah satu kasus penggunaan de-identifikasi yang umum di industri— menghapus tags berdasarkan profil kerahasiaan atribut Standar DICOM—dengan menggunakan profil ATTRIBUTE_CONFIDENTIALITY_BASIC_PROFILE.

Profil lain yang sering digunakan adalah DEIDENTIFY_TAG_CONTENTS, profil yang memeriksa metadata di dalam konten tag dan menggantikan teks sensitif. Saat menggunakan profil DEIDENTIFY_TAG_CONTENTS, Anda juga dapat menerapkan konfigurasi, seperti jenis informasi dan transformasi dasar. Jenis informasi dan transformasi dasar tidak dapat diterapkan ke profil lainnya.

Anda dapat menggunakan jenis informasi untuk menentukan data yang dipindai saat melakukan de-identifikasi dengan tags. Jenis informasi meliputi jenis data sensitif, seperti nama, alamat email, nomor telepon, nomor identifikasi, atau nomor kartu kredit pasien. Untuk informasi selengkapnya, lihat pendeteksi InfoTypes dan infoType.

Transformasi dasar adalah aturan yang Anda gunakan untuk mengubah nilai input. Anda dapat menyesuaikan cara tag DICOM yang dide-identifikasi dengan transformasi dasar untuk tiap jenis informasi. Misalnya, Anda dapat melakukan de-identifikasi nama akhir pasien dan menggantinya dengan rangkaian tanda bintang. Untuk mengetahui informasi tentang transformasi dasar, lihat opsi transformasi dasar.

Tutorial berikut memberikan kasus penggunaan untuk profil MINIMAL_KEEP_LIST_PROFILE.

Jenis informasi default

Secara default, profil DEIDENTIFY_TAG_CONTENTS menangani jenis informasi berikut:

  • AGE
  • CREDIT_CARD_NUMBER
  • DATE
  • EMAIL_ADDRESS
  • IP_ADDRESS
  • LOCATION
  • MAC_ADDRESS
  • PERSON_NAME
  • PHONE_NUMBER
  • SWIFT_CODE
  • US_DRIVERS_LICENSE_NUMBER
  • US_PASSPORT
  • US_SOCIAL_SECURITY_NUMBER
  • US_VEHICLE_IDENTIFICATION_NUMBER
  • US_INDIVIDUAL_TAXPAYER_IDENTIFICATION_NUMBER

Jika Anda hanya ingin mengubah jenis informasi dalam daftar sebelumnya, Anda dapat menggunakan profil DEIDENTIFY_TAG_CONTENTS tanpa parameter tambahan.

Menyamarkan teks sisipan dari gambar

Cloud Healthcare API dapat menyamarkan teks sisipan yang sensitif dari gambar. Data sensitif, seperti PII atau PHI, akan dideteksi oleh Cloud Healthcare API, yang kemudian akan disamarkan dengan tanda persegi panjang buram. Cloud Healthcare API menampilkan gambar DICOM yang sama sebagai input, tetapi teks apa pun yang telah diidentifikasi dan menurut Anda teks tersebut mengandung informasi sensitif, maka akan disamarkan.

Anda dapat menyamarkan teks sisipan dari gambar dengan menentukan opsi TextRedactionMode di dalam objek ImageConfig:

  • REDACT_ALL_TEXT: Menyamarkan semua teks sisipan dari gambar DICOM dalam set data.
  • REDACT_SENSITIVE_TEXT: Menyamarkan teks sisipan yang sensitif dari gambar DICOM dalam set data.

Saat menentukan REDACT_SENSITIVE_TEXT, Anda akan menyamarkan default infoTypes dan custom infoType sebagai ID pasien. Informasi seperti nomor rekam medis (MRN) akan disamarkan dari gambar.

Untuk mengetahui informasi selengkapnya tentang konfigurasi penyamaran gambar, lihat cara menyamarkan teks sisipan dari gambar.

Langkah selanjutnya