Informazioni sullo schema DICOM di BigQuery

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

Terminologia

Per comprendere lo schema e i suoi componenti, familiarizza con la Terminologia DICOM. In particolare, questa pagina utilizza diversi termini trovati nella sezione 3.10 Strutture di dati e definizioni di codifica DICOM.

Panoramica

L'API Cloud Healthcare genera automaticamente lo schema BigQuery utilizzando i dati che stai esportando e il dizionario DICOM. Lo schema contiene solo le colonne per gli elementi dei dati DICOM esistenti nei metadati. L'unica eccezione è il nome della persona in VR.

Durante l'esportazione dei metadati DICOM, l'API Cloud Healthcare tenta di esportare tutti gli elementi dei dati nei metadati. Per informazioni su cosa succede in caso di problemi, consulta Tipi in conflitto e non corrispondenti.

Elementi di dati standard e privati

DICOM fornisce elementi di dati standard che sono conformi a una specifica predefinita. Per un elenco di questi elementi di dati, consulta Registry degli elementi di dati DICOM.

Nei casi in cui devi comunicare dati non 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 informazioni sul comportamento dei dati privati, consulta la pagina Private Data Elements.

Nomi delle colonne

Le colonne nello schema BigQuery generato sono denominate in base alla 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 InstanceCreationDate.

Comportamento degli elementi di dati DICOM standard

La seguente tabella mostra un elenco di rappresentazioni dei valori (VR) e le relative abbreviazioni. Per ogni elemento di dati esportato in BigQuery che contiene una di queste VR, l'elemento di dati utilizza il tipo di dati BigQuery disponibile in "Tipo di dati":

VR Tipo di dati
  • Entità dell'applicazione (AE)
  • Stringa età (AS)
  • Stringa di codice (CS)
  • Stringa lunga (LO)
  • Testo lungo (LT)
  • Stringa corta (SH)
  • Testo breve (ST)
  • Caratteri illimitati (UC)
  • Identificatore univoco (UI/UID)
  • Universal Resource Identifier (UR) o Universal Resource Locator (URI/URL)
  • Testo illimitato (UT)
 Stringa
Data (DA) Date
Tempo (TM) Ora
Data e ora (DT) Timestamp
  • Stringa decimale (DS)
  • Stringa intera (IS)
 String
Nome della persona (PN) Struct (record)
  • Singolo punto in virgola mobile (FL)
  • Virgola mobile doppia (FD)
 Virgola mobile
  • Tag attributo (AT)
  • Firmato lungo (SL)
  • Short firmato
  • Senza firma lunga (UL)
  • Short senza firma (Stati Uniti)
 Numero intero
Sequenza di elementi (SQ) Struct (record)

Modalità nulla e ripetute

A seconda del valore di moltiplicazione dei valori (VM) di un elemento dati, la relativa colonna BigQuery ha una delle due modes: NULLABLE o REPEATED.

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

Ad esempio, come mostrato nel Registry degli elementi di dati DICOM, la parola chiave SOPInstanceUID ha un valore VM di 1. Di conseguenza, quando viene esportato in BigQuery, la sua modalità è NULLABLE e la sua rappresentazione nella tabella è simile alla seguente (se rappresentata in formato JSON):

"SOPInstanceUID": "0.0.000.000000.0.000.0000.0000000.0000.0000000000.000",

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

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

VR escluse

I dati binari e nel formato lungo non vengono esportati nella tabella BigQuery generata, quindi gli elementi dei dati contenenti i seguenti VR non vengono esportati. I seguenti VR sono invece inclusi in una colonna separata (chiamata DroppedTags.TagName) nella tabella BigQuery di destinazione.

  • Altro doppio (OD)
  • Altro numero in virgola mobile (OF)
  • Altro lungo (OL)
  • Altro byte (OB)
  • Altra parola (OW)
  • Sconosciuto (UN)
  • Tag sequenza (SQ) contenenti più di circa 1 MiB di dati
  • Attributo (AT), Floating Point Double (FD), Floating Point Single (FL), Unfirmato lungo (UL) o Non firmato Short (US), se la moltiplicazione del valore (VM) è maggiore di 512.
    • Per motivi legacy, i tag delle istanze già importate nell'API Cloud Healthcare potrebbero essere inclusi nella colonna DroppedTags.TagName se la moltiplicazione dei valori è maggiore di 64.

VR nome persona

Ogni colonna nello schema BigQuery con un VR nome persona (PN) contiene sempre tre colonne secondarie, indipendentemente dal fatto che le colonne secondarie contengano dati o meno. Le tre colonne secondarie sono:

  • Alfabetico
  • Ideografica
  • Fonetico

Ognuna delle tre colonne secondarie ha cinque colonne secondarie:

  • FamilyName
  • GivenName
  • MiddleName
  • NamePrefix
  • NameSuffix

Ad esempio, considera 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 sottocolonne elencate in precedenza, ma solo Alphabetic.FamilyName (Smith) e Alphabetic.DatenName (Darcy) conterranno valori.

Elementi di dati privati

Alcune implementazioni cliniche potrebbero richiedere di archiviare dati personalizzati che non si adattano alla struttura degli elementi di dati pubblici. In alternativa, puoi utilizzare elementi di dati privati.

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

Gli elementi di dati privati che non hanno una VR di SQ sono nidificati in una colonna denominata 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 query deve cercare all'interno della colonna OtherElements dell'elemento.

La colonna OtherElements contiene due colonne secondarie "Dati" e "Tag". La colonna di dati è la rappresentazione in formato stringa del 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 di tag.

LastUpdated e Type colonne

Le colonne LastUpdated e Type vengono aggiunte alla tabella BigQuery creata quando esporti i metadati DICOM. Queste colonne non sono elementi di dati standard o privati e non corrispondono al Registro di sistema di elementi di dati DICOM.

Il comportamento di queste colonne è il seguente:

  • La colonna LastUpdated contiene un valore timestamp che mostra quando l'istanza DICOM è stata inserita o eliminata dall'archivio DICOM.
  • La colonna Type contiene una stringa che mostra il tipo di operazione eseguita. I valori possibili sono CREATE o DELETE.

Tipi in conflitto e non corrispondenti

Se si verifica un conflitto di tipo, ad esempio quando un tag pubblico viene utilizzato con un tipo errato, il tag pubblico viene considerato come un tag privato. Il valore dell'elemento dei dati è nidificato in una colonna denominata OtherElements e viene convertito in una stringa.

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

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

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

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

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

Esempi: 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 una query per l'elemento di dati pubblici SOPInstanceUID. Per accedere al valore della colonna, esegui questa query:

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

La 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 questa query sulla colonna OtherElements che si trova all'interno della colonna Tag_12345678. Tieni presente l'utilizzo dell'operatore UNNEST, necessario perché stai eseguendo una query su un 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 SQL standard di BigQuery e visualizza esempi.