Informazioni sullo schema DICOM di BigQuery

Questa pagina illustra lo schema della tabella BigQuery creata durante l'esportazione di metadati DICOM in BigQuery.

Terminologia

Per comprendere lo schema e i suoi componenti, acquisisci familiarità con la termine terminologia DICOM. In particolare, questa pagina utilizza diversi termini descritti nella sezione 3.10 Strutture di dati e definizioni di codifica.

Panoramica

L'API Cloud Healthcare genera automaticamente lo schema BigQuery utilizzando i dati esportati e il dizionario DICOM. Lo schema contiene solo colonne per gli elementi di dati DICOM presenti nei metadati. L'unica eccezione è Person Name VR (Nome persona).

Quando esporti metadati DICOM, l'API Cloud Healthcare tenta di esportare tutti gli elementi di dati nei metadati. Per informazioni sugli incidenti in cui si verifica il problema, consulta l'articolo sui tipi in conflitto e non corrispondenti.

Elementi di dati standard e privati

DICOM fornisce elementi di dati standard conformi a una specifica predefinita. Per un elenco di questi elementi di dati, consulta la sezione Registry di DICOM Data Elements.

Nei casi in cui devi comunicare dati che non sono conformi agli elementi standard, puoi utilizzare gli elementi di dati privati.

Elementi di dati standard

I seguenti comportamenti si applicano agli elementi di dati standard. Per il comportamento degli elementi privati, consulta la sezione Elementi di dati privati.

Nomi di colonna

I nomi delle colonne nello schema BigQuery generato dipendono dalla parola chiave dell'elemento dati. Ad esempio, se i metadati DICOM contengono un elemento dati la cui parola chiave è InstanceCreationDate, lo schema generato ha una colonna corrispondente denominata InstanceCreationData.

Comportamento dell'elemento di dati DICOM standard

La tabella seguente mostra un elenco di rappresentazioni dei valori (VR) e delle relative abbreviazioni. Per qualsiasi elemento di dati esportato in BigQuery che contiene una di queste VR, l'elemento di dati utilizza il tipo di dati BigQuery trovato in "Data type":

VR Tipo di dati
  • Entità applicazione (AE)
  • Stringa di età (AS)
  • Stringa di codice (CS)
  • Stringa lunga (LO)
  • Testo lungo (LT)
  • Stringa corta (SH)
  • Testo breve (ST)
  • Caratteri illimitati
  • Identificatore univoco (UI/UID)
  • URI (Universal Resource Identifier) o URI (Universal Resource Locator)
  • Testo illimitato (UT)
Stringa
Data (DA) Date
Ora (TM) Ora
Data e ora Timestamp
  • Stringa decimale (DS)
  • Stringa intero (IS)
Stringa
Nome della persona Struct (record)
  • virgola mobile singolo (FL)
  • Doppio punto in virgola mobile
Punti in virgola mobile
  • Tag attributo
  • Firmato a lungo (SL)
  • Short firmato (SS)
  • Firma estesa senza link (UL)
  • Short senza firma (USA)
Intero
Sequenza di elementi Struct (record)

Modalità nulle e ripetute

A seconda del valore Multiplicity (VM) di un elemento dati, la relativa colonna BigQuery ha una delle due modalità: NULLABLE o REPEATED.

Se un elemento di dati ha un valore VM 1, che indica che l'elemento di dati è univoco, l'elemento di dati utilizza la modalità NULLABLE. Per qualsiasi altro valore della VM, l'elemento dati utilizza la modalità REPEATED.

Ad esempio, come illustrato in Registry di DICOM Data Elements, la parola chiave SOPInstanceUID ha un valore VM 1. Di conseguenza, quando viene esportata in BigQuery, la relativa modalità è NULLABLE e la rappresentazione nella tabella è la seguente (se rappresentata come JSON):

"SOPInstanceUID": "0.0.000.000000.0.000.0000.0000000.0000.0000000000.000",

Al contrario, la parola chiave ImageType ha un valore VM 2-n. Di conseguenza, quando viene esportata in BigQuery, la relativa modalità è REPEATED e la rappresentazione nella tabella è la seguente (se rappresentata come JSON):

"ImageType": [
  "ORIGINAL",
  "PRIMARY",
  "OTHER",
  "..."
],

VR escluse

I dati binari non vengono esportati nella tabella BigQuery generata, quindi non vengono esportati gli elementi dati contenenti le seguenti VR. ma verranno elencate in una colonna separata (denominata DroppedTags.TagName) nella tabella BigQuery di destinazione.

  • Altri byte (OB)
  • Doppio
  • Numero in virgola mobile (OF)
  • Titolo lungo (OL)
  • Altra parola
  • Sconosciuto (ONU)

Nome persona VR

Ogni colonna nello schema di BigQuery con nome Persona (PN) Persona contiene sempre tre colonne secondarie, indipendentemente dal fatto che queste contengano dati. Le tre colonne secondarie sono:

  • Alfabetico
  • Ideografico
  • Fonetico

Ogni colonna secondaria contiene le proprie cinque colonne secondarie:

  • Cognome
  • Nome
  • Secondo nome
  • Prefisso
  • Nome suffisso

Ad esempio, prendi in considerazione il tag pubblico "OperatorsName (0008,1070)," che ha un VR di nome persona (PN). Supponiamo che il valore di OperatorsName sia "Darcy Smith". Lo schema conterrà una colonna OperatorsName contenente le colonne secondarie elencate in precedenza, ma solo Alphabetic.FamilyName (Smith) e Alphabetic.GivenName (Darcy) conterrà valori.

Elementi di dati privati

Alcune implementazioni cliniche potrebbero richiedere l'archiviazione di dati personalizzati che non rientrano nella struttura degli elementi di dati pubblici. In alternativa, puoi utilizzare elementi di dati privati.

Gli elementi di dati privati con un valore VR di tipo SQ (Sequenza di elementi) hanno lo stesso comportamento degli elementi di dati standard. Gli elementi di dati privati con una VR di tipo SQ vengono chiamati sequenze di dati privati.

Gli elementi di dati privati senza VR di SQ sono nidificati sotto una colonna OtherElements e vengono convertiti in stringhe. Questi elementi di dati privati sono chiamati dati privati non in sequenza. Per eseguire query su elementi di dati privati non in sequenza, la tua query deve cercare nella colonna OtherElements dell'elemento.

La colonna OtherElements contiene due colonne secondarie, "Data" e " &Tag". La colonna Dati è la rappresentazione della stringa per il valore dell'elemento di dati privati. È sempre di tipo REPEATED. La colonna Tag utilizza il formato "Tag_HEX", dove HEX è una stringa esadecimale del numero del tag.

Tipi in conflitto e non corrispondenti

In caso di conflitto di tipo, ad esempio quando un tag pubblico viene utilizzato con un tipo non corretto, il tag pubblico viene trattato come se fosse un tag privato. Il valore dell'elemento di dati è nidificato in una colonna chiamata OtherElements e il valore viene convertito in una stringa.

Ad esempio, supponiamo che i metadati DICOM contengano un tag con:

  • Un numero di tag "(4010,1017)"
  • Una VR di SL (con firma lunga)
  • Un valore pari a 32

(4010,1017) ha lo stesso numero di tag di "Mass," ovvero un nome di tag pubblico nella specifica DICOM che ha un VR di FL. L'operazione di esportazione prevede un elemento di dati con il numero tag "&Mt" (4010,1017) come nome di tag pubblico "VR" Pertanto, l'operazione di esportazione prevede di convertire il valore dell'elemento di dati in un numero in virgola mobile (come mostrato nella tabella a Comportamento standard degli elementi dati DICOM)

Si verifica un conflitto di tipo perché tutti i tag con una VR di SL utilizzano il tipo di dati interi. Il tag viene quindi convertito in un tag privato e aggiunto alla colonna OtherElements.

Se per i dati di sequenza viene utilizzato un nome di tag pubblico non in sequenza, si verifica un tipo non corrispondente. Di conseguenza, la sequenza viene trattata come se fosse un elemento di dati privato. Anziché utilizzare il nome tag pubblico come nome colonna nello schema BigQuery, viene utilizzato il numero esadecimale del nome tag pubblico. Il numero esadecimale è di tipo stringa.

Esempi: esecuzione di query su elementi di dati pubblici e privati

Considera il seguente snippet di uno schema rappresentato come JSON. Lo schema è stato creato dopo aver esportato i dati DICOM in 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"
  }
  ...
]

L'esempio seguente mostra come eseguire query sull'elemento di dati pubblici SOPInstanceUID. Per accedere al valore della colonna, esegui la query seguente:

#standardSQL
SELECT
  SOPInstanceUID
FROM
  `PROJECT_ID.DATASET_ID.TABLE_ID`

L'esecuzione della query restituisce un output simile al seguente:

[
  ...
  {
    "SOPInstanceUID": "0.0.000.000000.0.000.0000.0000000.0000.0000000000.000"
  },
  ...
]

L'esempio seguente mostra come eseguire query per dati privati non in sequenza. Esegui la seguente query sulla colonna OtherElements, che si trova all'interno della colonna Tag_12345678. Nota l'utilizzo dell'operatore UNNEST, che è obbligatorio perché stai inviando query a RECORD.

#standardSQL
SELECT
  Tag_12345678.OtherElements AS OtherElements
FROM
  `PROJECT_ID.DATASET_ID.TABLE_ID`,
  UNNEST(Tag_12345678) AS Tag_12345678

L'esecuzione della query restituisce un output simile al seguente, a seconda della quantità e del tipo di dati nella colonna Tag_12345678.OtherElements:

[
  {
    "OtherElements": [
      {
        "Tag": "Tag_12345678",
        "Data": [
          "DATA"
        ]
      }
    ]
  },
  {
    "OtherElements": [
      {
        "Tag": "Tag_12345678",
        "Data": [
          "DATA"
        ]
      }
    ]
  },
  {
    "OtherElements": [
      {
        "Tag": "Tag_12345678",
        "Data": [
          "DATA"
        ]
      }
    ]
  }
]

Passaggi successivi

Scopri di più sulle operazioni standard di BigQuery e consulta gli esempi.