Halaman ini menjelaskan skema tabel BigQuery yang dibuat saat mengekspor metadata DICOM ke BigQuery.
Terminologi
Untuk memahami skema dan komponennya, pahami terminologi DICOM. Khususnya, halaman ini menggunakan beberapa istilah yang ada di 3.10 DICOM Data Structures and Encoding Definitions.
Ringkasan
Cloud Healthcare API otomatis membuat skema BigQuery menggunakan data yang Anda ekspor dan kamus DICOM. Skema hanya berisi kolom untuk elemen data DICOM yang ada dalam metadata. Satu-satunya pengecualian adalah VR Nama Orang.
Saat mengekspor metadata DICOM, Cloud Healthcare API akan mencoba mengekspor semua elemen data dalam metadata. Untuk mengetahui informasi tentang apa yang terjadi jika masalah muncul, lihat Jenis yang bentrok dan tidak cocok.
Elemen data standar dan pribadi
DICOM menyediakan elemen data standar yang sesuai dengan spesifikasi yang telah ditentukan sebelumnya. Untuk mengetahui daftar elemen data ini, lihat Registry of DICOM Data Elements.
Jika Anda harus mengomunikasikan data yang tidak sesuai dengan elemen standar, Anda dapat menggunakan elemen data pribadi.
Elemen data standar
Perilaku berikut berlaku untuk elemen data standar. Untuk perilaku elemen data pribadi, lihat Elemen data pribadi.
Nama kolom
Kolom dalam skema BigQuery yang dihasilkan diberi nama sesuai dengan kata kunci elemen data. Misalnya, jika metadata DICOM berisi elemen data yang kata kuncinya adalah InstanceCreationDate, maka skema yang dihasilkan memiliki kolom terkait bernama InstanceCreationDate.
Perilaku elemen data DICOM standar
Tabel berikut menampilkan daftar Representasi Nilai (VR) dan singkatan masing-masing. Untuk elemen data yang diekspor ke BigQuery yang berisi salah satu VR ini, elemen data menggunakan jenis data BigQuery yang ditemukan di bagian "Jenis data":
| VR | Jenis data |
|---|---|
|
String |
| Tanggal (DA) | Date |
| Waktu (TM) | Waktu |
| Tanggal Waktu (DT) | Stempel waktu |
|
String |
| Nama Orang (PN) | Struktur (Kumpulan data) |
|
Titik mengambang |
|
Bilangan Bulat |
| Urutan Item (SQ) | Struct (Kumpulan data) |
Mode nullable dan berulang
Bergantung pada nilai Multiplisitas Nilai (VM) elemen data, kolom BigQuery-nya memiliki salah satu dari dua mode: NULLABLE atau REPEATED.
Jika elemen data memiliki nilai VM 1, yang menunjukkan bahwa elemen data
bersifat unik, elemen data menggunakan mode NULLABLE. Untuk nilai VM lainnya,
elemen data menggunakan mode REPEATED.
Misalnya, seperti yang ditunjukkan dalam Registry of DICOM Data Elements,
kata kunci SOPInstanceUID memiliki nilai VM 1. Akibatnya,
saat diekspor ke BigQuery, modenya adalah NULLABLE,
dan representasinya dalam tabel terlihat seperti berikut (saat direpresentasikan sebagai
JSON):
"SOPInstanceUID": "0.0.000.000000.0.000.0000.0000000.0000.0000000000.000",
Sebaliknya, kata kunci ImageType memiliki nilai VM 2-n.
Akibatnya, saat diekspor ke BigQuery, modenya adalah
REPEATED, dan representasinya dalam tabel terlihat seperti berikut (saat
direpresentasikan sebagai JSON):
"ImageType": [
"ORIGINAL",
"PRIMARY",
"OTHER",
"..."
],
VR yang dikecualikan
Data biner dan panjang tidak diekspor ke tabel BigQuery yang dibuat, sehingga elemen data yang berisi VR berikut tidak diekspor. Sebagai gantinya,
VR berikut disertakan dalam kolom terpisah (disebut
DroppedTags.TagName) di tabel BigQuery tujuan.
- Ganda Lainnya (OD)
- Float Lainnya (OF)
- Lainnya Panjang (OL)
- Byte Lainnya (OB)
- Kata Lain (OW)
- Tidak diketahui (UN)
- Tag Sequence (SQ) yang berisi lebih dari sekitar 1 MiB data
- Atribut (AT), Floating Point Double (FD), Floating Point Single (FL),
Unsigned Long (UL), atau Unsigned Short (US), jika Multiplisitas Nilai (VM) lebih besar dari 512.
- Karena alasan lama, tag instance yang sudah di-ingest ke
Cloud Healthcare API mungkin disertakan dalam kolom
DroppedTags.TagNamejika Multiplisitas Nilai lebih besar dari 64.
- Karena alasan lama, tag instance yang sudah di-ingest ke
Cloud Healthcare API mungkin disertakan dalam kolom
VR Nama Orang
Setiap kolom dalam skema BigQuery dengan VR Nama Orang (PN) selalu berisi tiga subkolom, terlepas dari apakah subkolom tersebut berisi data atau tidak. Tiga subkolom tersebut adalah:
- Alfabetis
- Ideografis
- Fonetik
Setiap subkolom dari tiga subkolom memiliki lima subkolomnya sendiri:
- FamilyName
- GivenName
- MiddleName
- NamePrefix
- NameSuffix
Misalnya, pertimbangkan tag publik "OperatorsName (0008,1070)", yang memiliki VR Nama Orang (PN). Misalkan nilai OperatorsName adalah "Darcy Smith". Skema akan berisi kolom OperatorsName yang berisi subkolom yang tercantum sebelumnya, tetapi hanya Alphabetic.FamilyName (Smith) dan Alphabetic.GivenName (Darcy) yang akan berisi nilai.
Elemen data pribadi
Beberapa penerapan klinis mungkin mengharuskan Anda menyimpan data kustom yang tidak sesuai dengan struktur elemen data publik. Sebagai alternatif, Anda dapat menggunakan elemen data pribadi.
Elemen data pribadi dengan VR SQ (Urutan Item) memiliki perilaku yang sama dengan elemen data standar. Elemen data pribadi dengan VR SQ disebut urutan data pribadi.
Elemen data pribadi yang tidak memiliki VR SQ disarangkan di bawah kolom
yang disebut OtherElements dan dikonversi menjadi string. Elemen data pribadi ini disebut data pribadi non-urutan. Untuk
membuat kueri elemen data pribadi non-urutan, kueri Anda harus menelusuri dalam
kolom OtherElements elemen.
Kolom OtherElements berisi dua subkolom, "Data" dan "Tag". Kolom Data adalah representasi string dari nilai elemen data pribadi.
Nilainya selalu berjenis REPEATED. Kolom Tag menggunakan format
"Tag_HEX" dengan HEX adalah string hex dari nomor tag.
Kolom LastUpdated dan Type
Kolom LastUpdated dan Type ditambahkan ke tabel BigQuery yang dibuat saat Anda mengekspor metadata DICOM. Kolom ini bukan elemen data standar atau pribadi, dan tidak sesuai dengan Registry of DICOM Data Elements.
Perilaku kolom ini adalah sebagai berikut:
- Kolom
LastUpdatedberisi nilai stempel waktu yang menunjukkan kapan instance DICOM disisipkan ke atau dihapus dari penyimpanan DICOM. - Kolom
Typeberisi string yang menunjukkan jenis operasi yang terjadi. Kemungkinan nilainya adalahCREATEatauDELETE.
Jenis yang bertentangan dan tidak cocok
Jika terjadi konflik jenis, seperti saat tag publik digunakan dengan jenis yang salah, tag publik diperlakukan seolah-olah itu adalah tag pribadi. Nilai elemen data disarangkan di bawah kolom yang disebut OtherElements dan nilai dikonversi menjadi string.
Misalnya, metadata DICOM berisi tag dengan:
- Nomor tag "(4010,1017)"
- VR SL (Signed Long)
- Nilai 32
(4010,1017) adalah nomor tag yang sama dengan "Mass", yang merupakan nama tag publik dalam spesifikasi DICOM yang memiliki VR FL. Operasi ekspor mengharapkan elemen data dengan nomor tag "(4010,1017)" menjadi nama tag publik "Mass" dengan VR FL. Oleh karena itu, operasi ekspor diharapkan mengonversi nilai elemen data menjadi float (seperti yang ditunjukkan dalam tabel di Perilaku elemen data DICOM standar
Konflik jenis terjadi karena semua tag dengan VR SL menggunakan jenis data
integer. Oleh karena itu, tag dikonversi menjadi tag pribadi dan ditambahkan ke kolom
OtherElements.
Jika nama tag publik non-urutan digunakan untuk data urutan, akan terjadi ketidakcocokan jenis. Akibatnya, urutan diperlakukan seolah-olah merupakan elemen data pribadi. Daripada menggunakan nama tag publik sebagai nama kolom dalam skema BigQuery, angka hex dari nama tag publik digunakan. Bilangan hex adalah jenis string.
Contoh: Membuat kueri elemen data publik dan pribadi
Pertimbangkan cuplikan skema berikut yang ditampilkan sebagai JSON. Skema dibuat setelah mengekspor data DICOM ke BigQuery.
[
...
{
"name": "SOPInstanceUID",
"type": "STRING"
},
{
"fields": [
{
"fields": [
{
"mode": "REQUIRED",
"name": "Tag",
"type": "STRING"
},
{
"mode": "REPEATED",
"name": "Data",
"type": "STRING"
}
],
"mode": "REPEATED",
"name": "OtherElements",
"type": "RECORD"
}
],
"mode": "REPEATED",
"name": "Tag_12345678",
"type": "RECORD"
}
...
]
Contoh berikut menunjukkan cara membuat kueri untuk elemen data publik SOPInstanceUID.
Untuk mengakses nilai kolom, jalankan kueri berikut:
#standardSQL SELECT SOPInstanceUID FROM `PROJECT_ID.DATASET_ID.TABLE_ID`
Menjalankan kueri akan menampilkan output yang mirip dengan berikut ini:
[ ... { "SOPInstanceUID": "0.0.000.000000.0.000.0000.0000000.0000.0000000000.000" }, ... ]
Contoh berikut menunjukkan cara membuat kueri untuk data pribadi non-urutan.
Jalankan kueri berikut terhadap kolom OtherElements yang ada di dalam kolom Tag_12345678. Perhatikan penggunaan operator UNNEST, yang diperlukan karena Anda membuat kueri RECORD.
#standardSQL SELECT Tag_12345678.OtherElements AS OtherElements FROM `PROJECT_ID.DATASET_ID.TABLE_ID`, UNNEST(Tag_12345678) AS Tag_12345678
Menjalankan kueri akan menampilkan output yang mirip dengan berikut, bergantung pada jumlah dan jenis data dalam kolom Tag_12345678.OtherElements:
[ { "OtherElements": [ { "Tag": "Tag_12345678", "Data": [ "DATA" ] } ] }, { "OtherElements": [ { "Tag": "Tag_12345678", "Data": [ "DATA" ] } ] }, { "OtherElements": [ { "Tag": "Tag_12345678", "Data": [ "DATA" ] } ] } ]
Skema JSON
Anda dapat mengekspor metadata instance DICOM ke dalam tabel BigQuery dengan skema yang lebih sederhana, tempat metadata instance lengkap disimpan sebagai satu kolom JSON. Hal ini dapat berguna jika Anda lebih suka bekerja dengan struktur JSON mentah metadata DICOM dalam BigQuery. Fungsi ini juga berguna jika jumlah tag unik di semua instance DICOM melebihi jumlah maksimum kolom yang diizinkan dalam tabel BigQuery.
Untuk mengaktifkan skema JSON, tetapkan kolom schema_json di BigQueryDestination. Untuk mengetahui detail selengkapnya tentang cara mengonfigurasi skema, lihat BigQueryDestination.
Jika skema JSON diaktifkan, tabel BigQuery akan memiliki kolom berikut:
| Nama Kolom | Jenis | Deskripsi |
|---|---|---|
StudyInstanceUID |
STRING | Tag DICOM (0020,000D). |
SeriesInstanceUID |
STRING | Tag DICOM (0020,000E). |
SOPInstanceUID |
STRING | Tag DICOM (0008,0018). |
SourceDicomStore |
STRING | Nama penyimpanan DICOM sumber. Kolom ini hanya disertakan jika opsi includeSourceStore ditetapkan ke benar (true) dalam konfigurasi ekspor. |
Type |
STRING | Menunjukkan jenis operasi yang memicu ekspor (misalnya, CREATE, DELETE). |
LastUpdated |
TIMESTAMP | Stempel waktu update terakhir pada instance di penyimpanan DICOM. |
Metadata |
JSON | Semua tag DICOM untuk instance, disimpan dalam satu objek JSON. |
DroppedTags |
STRING BERULANG | Daftar tag yang dihilangkan selama konversi, biasanya tag biner atau tag yang sangat besar. |
StorageClass |
STRING | Kelas penyimpanan instance (misalnya, STANDARD, NEARLINE). |
BlobStorageSize |
INTEGER | Ukuran penyimpanan blob dalam byte. |
StructuredStorageSize |
INTEGER | Ukuran penyimpanan terstruktur dalam byte. |
Contoh: Membuat kueri kolom JSON Metadata
Berikut contoh cara membuat kueri tag DICOM tertentu dari kolom Metadata dengan mengikuti dukungan data JSON BigQuery. Kueri ini memilih tag PatientID dan PatientAge:
#standardSQL SELECT Metadata.PatientID AS patient_id, Metadata.PatientAge AS patient_age FROM `PROJECT_ID.DATASET_ID.TABLE_ID`;
Menjalankan kueri akan menampilkan output yang mirip dengan berikut ini:
/*-------------+---------------*
| patient_id | patient_age |
+--------------+---------------+
| "John-Doe" | "042Y" |
*--------------+---------------*/
Anda dapat menyesuaikan kueri untuk mengekstrak tag DICOM lain dari kolom JSON Metadata sesuai kebutuhan.
Langkah berikutnya
Pelajari lebih lanjut operasi SQL standar BigQuery dan lihat contohnya.