Comprendre le schéma BigQuery DICOM

Cette page explique le schéma de la table BigQuery créée lors de l'exportation des métadonnées DICOM vers BigQuery.

Terminologie

Pour comprendre le schéma et ses composants, familiarisez-vous avec la terminologie DICOM. En particulier, cette page utilise plusieurs termes trouvés dans 3.10 Structures de données et définitions d'encodage DICOM.

Présentation

L'API Cloud Healthcare génère automatiquement le schéma BigQuery à l'aide des données que vous exportez et du dictionnaire DICOM. Le schéma ne contient que des colonnes pour les éléments de données DICOM qui existent dans les métadonnées. La seule exception est VR du Nom de la Personne.

Lors de l'exportation des métadonnées DICOM, l'API Cloud Healthcare tente d'exporter tous les éléments de données dans les métadonnées. Pour en savoir plus sur les conséquences d'un problème, consultez la section Types de conflits et de non-concordance.

Éléments de données standards et privés

DICOM fournit des éléments de données standards conformes à une spécification prédéfinie. Pour obtenir la liste de ces éléments de données, consultez le Registre d'éléments de données DICOM.

Dans le cas où vous devez communiquer des données qui ne sont pas conformes aux éléments standards, vous pouvez utiliser des éléments de données privés.

Éléments de données standards

Les comportements suivants s'appliquent aux éléments de données standards. Pour plus d'informations sur le comportement des éléments de données privés, consultez la section Éléments de données privés.

Noms de colonne

Les colonnes du schéma BigQuery généré sont nommées en fonction du mot clé de l'élément de données. Par exemple, si les métadonnées DICOM contiennent un élément de données dont le mot clé est "InstanceCreationDate", le schéma généré possède une colonne nommée "InstanceCreationDate".

Comportement de l'élément de données DICOM standard

Le tableau suivant présente une liste de Représentations de valeurs (VR, Value Representations) et leurs abréviations. Pour les éléments de données exportés vers BigQuery contenant l'une de ces VR, l'élément de données utilise le type de données BigQuery situé sous "Type de données" :

VR Type de données
  • Entité d'application (AE, Application Entity)
  • Chaîne d'âge (AS, Age String)
  • Chaîne de code (CS, Code String)
  • Chaîne longue (LO, Long String)
  • Texte long (LT, Long Text)
  • Chaîne courte (SH, Short String)
  • Texte court (ST, Short Text)
  • Caractères illimités (UC, Unlimited Characters)
  • Identifiant unique (UI/UID, Unique Identifier)
  • Identifiant de ressource universel (UR, Universal Resource Identifier) ou Localisaeur de ressource universel (URI/URL, Universal Resource Locator)
  • Texte illimité (UT, Unlimited Text)
 Chaîne
Date (DA) Date
Heure (TM, Time) Time
Date/Heure (DT, Date Time) Temporel
  • Chaîne Décimal (DS, Decimal String)
  • Chaîne Entier (IS, Integer String)
 Chaîne
Nom de la Personne (PN, Person Name) Type "Struct (Record)"
  • Virgule flottante simple (FL, Floating Point Single)
  • Virgule flottante double (FD, Floating Point Double)
 Virgule flottante
  • Tag d'attribut (AT, Attribute Tag)
  • Signé long (SL, Signed Long)
  • Signé court (SS, Signed Short)
  • Non signé long (UL, Unsigned Long)
  • Non signé court (US, Unsigned Short)
 Entier
Séquence d'éléments (SQ, Sequence of Items) Type "Struct (Record)"

Modes Nullable et Repeated

Selon la valeur de la Multiplication de valeur (VM, Value Multiplicity) d'un élément de données, sa colonne BigQuery comporte l'un des deux modes : NULLABLE ou REPEATED.

Si un élément de données a une valeur de VM de 1, ce qui indique qu'il est unique, il utilise le mode NULLABLE. Pour toute autre valeur de VM, l'élément de données utilise le mode REPEATED.

Par exemple, comme indiqué dans le registre d'éléments de données DICOM, le mot clé "SOPInstanceUID" a une valeur de VM de 1. Par conséquent, lorsqu'il est exporté vers BigQuery, son mode est NULLABLE et sa représentation dans la table se présente comme suit (lorsqu'elle est représentée au format JSON) :

"SOPInstanceUID": "0.0.000.000000.0.000.0000.0000000.0000.0000000000.000",

À l'inverse, le mot clé "ImageType" a une valeur de VM de 2-n. Par conséquent, lorsqu'il est exporté vers BigQuery, son mode est REPEATED et sa représentation dans la table se présente comme suit (lorsqu'elle est représentée au format JSON) :

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

VR exclues

Les données binaires et longues n'étant pas exportées vers la table BigQuery générée, les éléments de données contenant les VR suivantes ne sont pas exportés : Au lieu de cela, les VR suivantes sont incluses dans une colonne distincte (appelée DroppedTags.TagName) dans la table BigQuery de destination.

  • Autre Double (OD, Other Double)
  • Autre float (OF, Other Float)
  • Autre long (OL, Other Long)
  • Autre octet (OB, Other Byte)
  • Autre mot (OW, Other Word)
  • Inconnu (UN, Unknown)
  • Tags de séquence (SQ) contenant approximativement plus de 1 Mio de données
  • Attribut (AT), virgule flottante double (FD), virgule flottante simple (FL), entier long non signé (UL) ou entier court non signé (US), si la multiplicité des valeurs (VM) est supérieure à 512.
    • Pour des raisons historiques, les balises d'instances déjà ingérées dans l'API Cloud Healthcare peuvent être incluses dans la colonne DroppedTags.TagName si la multiplicité des valeurs est supérieure à 64.

VR du nom de la personne

Chaque colonne du schéma BigQuery avec une VR du Nom de la personne (PN, Person Name) contient toujours trois sous-colonnes, que les sous-colonnes contiennent ou non des données. Les trois sous-colonnes sont les suivantes :

  • Alphabétique
  • Idéographique
  • Phonétique

Chacune des trois sous-colonnes possède cinq sous-colonnes :

  • FamilyName
  • GivenName
  • MiddleName
  • NamePrefix
  • NameSuffix

Par exemple, considérons le tag public "OperatorsName (0008,1007)", qui possède un VR du Nom de la personne (PN, Person Name). Supposons que la valeur de "OperatorsName" soit "Darcy Smith". Le schéma contiendra une colonne "OperatorsName" contenant les sous-colonnes répertoriées précédemment, mais seules les colonnes Alphabetic.FamilyName (Smith) et Alphabetic.GivenName (Darcy) contiendront des valeurs.

Éléments de données privés

Certaines implémentations cliniques peuvent nécessiter le stockage de données personnalisées qui ne correspondent pas à la structure des éléments de données publics. Vous pouvez également utiliser des éléments de données privés.

Les éléments de données privés avec une VR de Séquence d'éléments (SQ, Sequence of Items) ont le même comportement que les éléments de données standards. Les éléments de données privés avec une VR de SQ sont appelés séquences de données privées.

Les éléments de données privés qui n'ont pas de VR de SQ sont imbriqués dans une colonne appelée OtherElements et sont convertis en chaînes. Ces éléments de données privées sont appelés données privées non séquentielles. Pour interroger des éléments de données privés non séquentiels, votre requête doit effectuer une recherche dans la colonne OtherElements de l'élément.

La colonne OtherElements contient deux sous-colonnes, "Data" et "Tag". La colonne Data est la représentation sous forme de chaîne de la valeur de l'élément de données privé. Il s'agit toujours du type REPEATED. La colonne Tag utilise le format "Tag_ HEX", où HEX est une chaîne hexadécimale du numéro de tag.

Colonnes LastUpdated et Type

Les colonnes LastUpdated et Type sont ajoutées à la table BigQuery créée lorsque vous exportez des métadonnées DICOM. Ces colonnes ne sont pas des éléments de données standards ou privés, et elles ne correspondent pas au registre des éléments de données DICOM.

Le comportement de ces colonnes est le suivant :

  • La colonne LastUpdated contient une valeur d'horodatage qui indique le moment où l'instance DICOM a été insérée dans le magasin DICOM ou supprimée de celui-ci.
  • La colonne Type contient une chaîne indiquant le type d'opération. Les valeurs possibles sont CREATE ou DELETE.

Types de conflits et d'erreurs de correspondances

En cas de conflit de type, par exemple lorsqu'un tag public est utilisé avec un type incorrect, le tag public est traité comme s'il s'agissait d'un tag privé. La valeur de l'élément de données est imbriquée dans une colonne appelée OtherElements et la valeur est convertie en chaîne.

Par exemple, supposons que les métadonnées DICOM contiennent un tag avec :

  • Un numéro de tag "(4010,1017)"
  • Une VR de SL (Signed Long)
  • Une valeur de 32

(4010,017) est identique au numéro de tag "Mass", qui est un nom de balise public dans la spécification DICOM ayant une VR de FL. L'opération d'exportation attend un élément de données avec le numéro de tag "(4010,1017)" comme nom de tag public "Mass" avec une VR de FL. Par conséquent, l'opération d'exportation s'attend à convertir la valeur de l'élément de données en float (comme indiqué dans le tableau de la section Comportement de l'élément de données DICOM standard).

Un conflit de type se produit car tous les tags avec une VR de SL utilisent le type de données "Entier". Le tag est donc converti en tag privé et ajouté à la colonne OtherElements.

Si un nom de tag public non séquentiel est utilisé pour les données de séquence, une erreur de non concordance de type se produit. Par conséquent, la séquence est traitée comme s'il s'agissait d'un élément de données privé. Au lieu d'utiliser le nom de tag public comme nom de colonne dans le schéma BigQuery, le nombre hexadécimal du nom de tag public est utilisé. Le nombre hexadécimal est de type "chaîne".

Exemples : Interroger des éléments de données publics et privés

Prenons l'exemple suivant d'un schéma représenté au format JSON. Le schéma a été créé après l'exportation des données DICOM vers 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'exemple suivant montre comment interroger l'élément de données public SOPInstanceUID. Pour accéder à la valeur de la colonne, exécutez la requête suivante :

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

L'exécution de la requête renvoie un résultat semblable à celui-ci :

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

L'exemple suivant montre comment interroger des données privées non séquentielles. Exécutez la requête suivante sur la colonne OtherElements qui se trouve dans la colonne Tag_12345678. Notez l'utilisation de l'opérateur UNNEST, qui est requis car vous interrogez un RECORD.

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

L'exécution de la requête renvoie un résultat semblable au suivant, en fonction de la quantité et du type de données figurant dans la colonne Tag_12345678.OtherElements :

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

Étape suivante

Apprenez-en plus sur les opérations SQL standards de BigQuery et consultez des exemples.