Auf dieser Seite wird das Schema der BigQuery-Tabelle erläutert, die erstellt wird, wenn Sie DICOM-Metadaten nach BigQuery exportieren.
Terminologie
Machen Sie sich mit der DICOM-Terminologie vertraut, um das Schema und seine Komponenten zu verstehen. Insbesondere werden auf dieser Seite mehrere Begriffe verwendet, die in 3.10 DICOM-Datenstrukturen und Codierungsdefinitionen enthalten sind.
Überblick
Die Cloud Healthcare API generiert automatisch das BigQuery-Schema mit den Daten, die Sie exportieren, und dem DICOM-Wörterbuch. Das Schema enthält nur Spalten für DICOM-Datenelemente, die in den Metadaten vorhanden sind. Die einzige Ausnahme ist Person Name VR.
Beim Exportieren von DICOM-Metadaten versucht die Cloud Healthcare API, alle Datenelemente in den Metadaten zu exportieren. Informationen dazu, was bei einem aufgetretenen Problem geschieht, finden Sie unter Widersprüchliche und nicht übereinstimmende Typen.
Standardmäßige und private Datenelemente
DICOM stellt Standard-Datenelemente bereit, die einer vordefinierten Spezifikation entsprechen. Eine Liste dieser Datenelemente finden Sie unter Registrierung von DICOM-Datenelementen.
Wenn Sie Daten kommunizieren müssen, die nicht den Standardelementen entsprechen, können Sie private Datenelemente verwenden.
Standardmäßige Datenelemente
Die folgenden Verhaltensweisen gelten für Standard-Datenelemente. Informationen zum Verhalten privater Elemente finden Sie unter Private Datenelemente.
Spaltennamen
Die Spalten im generierten BigQuery-Schema werden entsprechend dem Suchbegriff des Datenelements benannt. Wenn die DICOM-Metadaten beispielsweise ein Datenelement mit dem Schlüsselwort InstanceCreationDate enthalten, hat das generierte Schema eine entsprechende Spalte mit dem Namen InstanceCreationDate.
Verhalten von standardmäßigen DICOM-Datenelementen
Die folgende Tabelle zeigt eine Liste der Wertedarstellungen (Value Representations, VR) und ihre Abkürzungen. Für jedes Datenelement, das nach BigQuery exportiert wird und eines dieser VR-Elemente enthält, verwendet das Datenelement den BigQuery-Datentyp unter "Datentyp":
| VR | Datentyp |
|---|---|
|
String |
| Datum (DA) | Datum |
| Zeit (TM) | Zeit |
| Datum und Uhrzeit (DT) | Timestamp |
|
String |
| Name der Person (PN) | Struct (Datensatz) |
|
Gleitkomma |
|
Ganzzahl |
| Reihenfolge der Elemente (SQ) | Struct (Datensatz) |
Wiederholte Modi und Modi mit zulässigen Nullwerten
Abhängig vom Wert der Value Multiplicity (VM) eines Datenelements hat seine BigQuery-Spalte einen von zwei modes: NULLABLE oder REPEATED.
Wenn ein Datenelement einen VM-Wert von 1 hat, was darauf hinweist, dass das Datenelement nur einmal vorkommt, verwendet das Datenelement den Modus NULLABLE. Bei jedem anderen VM-Wert wird das Datenelement im Modus REPEATED verwendet.
Wie in der Registry von DICOM-Datenelementen dargestellt, hat das SOPInstanceUID-Keyword einen VM-Wert von 1. Beim Export nach BigQuery lautet der Modus demnach NULLABLE und die Darstellung in der Tabelle sieht so aus (bei einer Darstellung im JSON-Format):
"SOPInstanceUID": "0.0.000.000000.0.000.0000.0000000.0000.0000000000.000",
Umgekehrt hat der Suchbegriff ImageType einen VM-Wert von 2-n.
Beim Export nach BigQuery lautet der Modus also REPEATED und die Darstellung in der Tabelle sieht so aus (bei einer Darstellung im JSON-Format):
"ImageType": [
"ORIGINAL",
"PRIMARY",
"OTHER",
"..."
],
Ausgeschlossene VRs
Binär- und lange Daten werden nicht in die generierte BigQuery-Tabelle exportiert. Daher werden Datenelemente, die die folgenden VRs enthalten, nicht exportiert. Stattdessen sind die folgenden VRs in der BigQuery-Zieltabelle in einer separaten Spalte (DroppedTags.TagName) enthalten.
- Sonstiges (OD)
- Anderes Float (OF)
- Anderes Long (OL)
- Anderes Byte (OB)
- Anderes Wort (OW)
- Unbekannt (UN)
- Sequenz-Tags (SQ) mit mehr als etwa 1 MiB Daten
- Attribut (AT), Gleitkommazahl mit doppelter Gleitkommazahl (FD), Gleitkommazahl, Single (FL), ohne Vorzeichen, lang (UL) oder unsignierter Kurzfilm (US), wenn die Wertmultiplizität (VM) größer als 64 ist
Person Name VR
Jede Spalte im BigQuery-Schema mit der Person Name (PN) VR enthält immer drei untergeordnete Spalten, unabhängig davon, ob die untergeordneten Spalten Daten enthalten. Die drei untergeordneten Spalten sind:
- Alphabetisch
- Ideographisch
- Phonetisch
Jede der drei untergeordneten Spalten hat jeweils fünf untergeordnete Spalten:
- FamilyName
- GivenName
- MiddleName
- NamePrefix
- NameSuffix
Betrachten Sie beispielsweise das öffentliche Tag "OperatorsName (0008,1070)", das einen "VR eines Person Name" (PN) enthält. Angenommen, der Wert von OperatorsName lautet "Darcy Smith". Das Schema enthält die Spalte "OperatorsName" mit den zuvor aufgeführten untergeordneten Spalten. In diesem Fall enthalten nur "Alphabetic.FamilyName" (Smith) und "Alphabetic.GivenName (Darcy)" Werte.
Private Datenelemente
Bei einigen klinischen Implementierungen müssen Sie möglicherweise benutzerdefinierte Daten speichern, die nicht in die Struktur öffentlicher Datenelemente passen. Alternativ können Sie private Datenelemente verwenden.
Private Datenelemente mit einer VR von SQ (Abfolge von Elementen) haben das gleiche Verhalten wie Standarddatenelemente. Private Datenelemente mit einer VR von SQ werden als private Datensequenzen bezeichnet.
Private Datenelemente, die kein VR von SQ enthalten, werden in einer Spalte namens OtherElements verschachtelt und in Strings umgewandelt. Diese privaten Datenelemente werden als private Daten ohne Sequenz bezeichnet. Wenn Sie private Nicht-Sequenz-Datenelemente abfragen möchten, müssen Sie in der Spalte OtherElements des Elements suchen.
Die Spalte OtherElements enthält die beiden untergeordneten Spalten "Daten" und "Tag". Die Spalte "Daten" ist die Stringdarstellung des Werts des privaten Datenelements.
Der Typ ist immer REPEATED. Die Spalte "Tag" hat das Format "Tag_HEX". Dabei ist HEX ein Hexadezimalstring der Tag-Nummer.
Spalten "LastUpdated" und "Type"
Die Spalten LastUpdated und Type werden der BigQuery-Tabelle hinzugefügt, die beim Exportieren von DICOM-Metadaten erstellt wird. Diese Spalten sind keine Standard- oder privaten Datenelemente und entsprechen nicht der Registry der DICOM-Datenelemente.
Diese Spalten verhalten sich wie folgt:
- Die
LastUpdated-Spalte enthält einen Zeitstempel-Wert, der angibt, wann die DICOM-Instanz in den DICOM-Speicher eingefügt oder aus diesem gelöscht wurde. - Die
Type-Spalte enthält einen String, der angibt, welche Art von Vorgang aufgetreten ist. Mögliche Werte sindCREATEundDELETE.
Widersprüchliche und nicht übereinstimmende Typen
Wenn ein Typkonflikt auftritt, z. B. wenn ein öffentliches Tag mit einem falschen Typ verwendet wird, wird das öffentliche Tag wie ein privates Tag verwendet. Der Wert des Datenelements wird unter der Spalte OtherElements verschachtelt und der Wert wird in einen String konvertiert.
Angenommen, die DICOM-Metadaten enthalten ein Tag mit:
- Eine Tag-Nummer "(4010,1017)"
- Ein VR von SL (Signed Long)
- Der Wert 32
(4010,1017) ist die gleiche Tag-Nummer wie "Mass", ein öffentlicher Tag-Name in der DICOM-Spezifikation, die einen VR von FL hat. Der Exportvorgang erwartet, dass ein Datenelement mit der Tag-Nummer "(4010,1017)" der öffentliche Tag-Name "Mass" mit einem VR von FL ist. Daher erwartet der Exportvorgang, dass der Wert des Datenelements in eine Gleitkommazahl umgewandelt wird, wie in der Tabelle unter Standardverhalten der DICOM-Datenelemente gezeigt.
Ein Typkonflikt tritt auf, weil alle Tags mit einem VR von SL den Datentyp "Ganzzahl" verwenden. Das Tag wird daher in ein privates Tag konvertiert und der Spalte OtherElements hinzugefügt.
Wenn ein öffentlicher Tag-Name, der keine Sequenz ist, für Sequenzdaten verwendet wird, tritt eine Typabweichung auf. Daher wird die Sequenz so behandelt, als sei sie ein privates Datenelement. Anstatt den öffentlichen Tag-Namen als Spaltennamen im BigQuery-Schema zu verwenden, wird die Hexadezimalzahl des öffentlichen Tag-Namens verwendet. Die Hexadezimalzahl ist vom Typ String.
Beispiele: Öffentliche und private Datenelemente abfragen
Betrachten Sie das folgende Snippet eines Schemas, das als JSON dargestellt wird: Das Schema wurde nach dem Export von DICOM-Daten in BigQuery erstellt.
[
...
{
"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"
}
...
]
Das folgende Beispiel zeigt, wie Sie das öffentliche Datenelement SOPInstanceUID abfragen.
Führen Sie die folgende Abfrage aus, um auf den Wert der Spalte zuzugreifen:
#standardSQL SELECT SOPInstanceUID FROM `PROJECT_ID.DATASET_ID.TABLE_ID`
Die Abfrage liefert eine Ausgabe ähnlich der folgenden:
[
...
{
"SOPInstanceUID": "0.0.000.000000.0.000.0000.0000000.0000.0000000000.000"
},
...
]
Im folgenden Beispiel wird gezeigt, wie private Daten ohne Sequenz abgefragt werden.
Führen Sie die folgende Abfrage für die Spalte OtherElements aus, die sich in der Spalte Tag_12345678 befindet. Beachten Sie die Verwendung des Operators UNNEST, der erforderlich ist, da Sie eine RECORD-Abfrage ausführen.
#standardSQL SELECT Tag_12345678.OtherElements AS OtherElements FROM `PROJECT_ID.DATASET_ID.TABLE_ID`, UNNEST(Tag_12345678) AS Tag_12345678
Die Abfrage gibt abhängig vom Umfang und Typ der Daten in der Spalte Tag_12345678.OtherElements eine Ausgabe ähnlich der folgenden zurück:
[
{
"OtherElements": [
{
"Tag": "Tag_12345678",
"Data": [
"DATA"
]
}
]
},
{
"OtherElements": [
{
"Tag": "Tag_12345678",
"Data": [
"DATA"
]
}
]
},
{
"OtherElements": [
{
"Tag": "Tag_12345678",
"Data": [
"DATA"
]
}
]
}
]
Nächste Schritte
Weitere Informationen zu BigQuery-Standard-SQL-Vorgängen und Beispiele ansehen