Hintergrundinformationen zum BigQuery-DICOM-Schema

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.

Übersicht

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 enthalten, dessen Keyword InstanceCreationDate ist, hat das generierte Schema eine entsprechende Spalte namens 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":

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 Modi: 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 Langformatdaten werden nicht in die generierte BigQuery-Tabelle exportiert, sodass Datenelemente mit den folgenden VRs nicht exportiert werden. Stattdessen werden die folgenden VRs in einer separaten Spalte namens DroppedTags.TagName in der BigQuery-Zieltabelle aufgeführt.

• Sonstiges (OD)
• Anderes Float (OF)
• Anderes Long (OL)
• Anderes Byte (OB)
• Anderes Wort (OW)
• Unbekannt (UN)
• Sequenz-Tags (SQ), die mehr als etwa 1 MiB Daten enthalten
• „Attribut“ (AT), „Gleitkomma doppelt“ (FD), „Gleitkomma einfach“ (FL), „Unsigned Long“ (UL) oder „Unsigned Short“ (US), wenn die Wertvielfachheit (VM) größer als 512 ist.
  • Aus Gründen der Abwärtskompatibilität können Tags von Instanzen, die bereits in die Cloud Healthcare API aufgenommen wurden, in der Spalte DroppedTags.TagName enthalten sein, wenn die Multiplizität des Werts 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 standardmäßigen oder privaten Datenelemente und entsprechen nicht der Registrierung von DICOM-Datenelementen.

Das Verhalten dieser Spalten ist so:

• 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 sind CREATE und DELETE.

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