Descripción del esquema DICOM de BigQuery

En esta página se explica el esquema de la tabla de BigQuery que se crea al exportar metadatos DICOM a BigQuery.

Terminología

Para entender el esquema y sus componentes, familiarízate con la terminología DICOM. En concreto, en esta página se usan varios términos que se encuentran en la sección 3.10 Estructuras de datos y definiciones de codificación de DICOM.

Información general

La API Cloud Healthcare genera automáticamente el esquema de BigQuery a partir de los datos que exportas y del diccionario DICOM. El esquema solo contiene columnas de elementos de datos DICOM que están en los metadatos. La única excepción es el nombre de persona de alquiler vacacional.

Al exportar metadatos DICOM, la API Cloud Healthcare intenta exportar todos los elementos de datos de los metadatos. Para obtener información sobre qué ocurre si surge un problema, consulta Tipos en conflicto y no coincidentes.

Elementos de datos estándar y privados

DICOM proporciona elementos de datos estándar que se ajustan a una especificación predefinida. Para ver una lista de estos elementos de datos, consulta el registro de elementos de datos DICOM.

En los casos en los que debas comunicar datos que no se ajusten a los elementos estándar, puedes usar elementos de datos privados.

Elementos de datos estándar

Los siguientes comportamientos se aplican a los elementos de datos estándar. Para obtener información sobre el comportamiento de los elementos de datos privados, consulta Elementos de datos privados.

Nombres de columna

Las columnas del esquema de BigQuery generado se denominan según la palabra clave del elemento de datos. Por ejemplo, si los metadatos DICOM contienen un elemento de datos cuya palabra clave es InstanceCreationDate, el esquema generado tendrá una columna correspondiente llamada InstanceCreationDate.

Comportamiento estándar de los elementos de datos DICOM

En la siguiente tabla se muestra una lista de representaciones de valores (VRs) y sus abreviaturas. En el caso de los elementos de datos exportados a BigQuery que contengan uno de estos VRs, el elemento de datos usará el tipo de datos de BigQuery que se indica en "Tipo de datos":

RV Tipo de datos
  • Entidad de aplicación (AE)
  • Cadena de edad (AS)
  • Cadena de código (CS)
  • Cadena larga (LO)
  • Texto largo (LT)
  • Cadena corta (SH)
  • Texto breve (TB)
  • Caracteres ilimitados (UC)
  • Identificador único (UI/UID)
  • Identificador de recursos universal (UR) o localizador de recursos universal (URI o URL)
  • Mensajes de texto ilimitados
String
Fecha (DA) Fecha
Hora (TM) Hora
Fecha y hora (DT) Marca de tiempo
  • Cadena decimal (DS)
  • Cadena de números enteros (IS)
Cadena
Nombre de la persona (PN) Struct (registro)
  • Punto flotante simple (FL)
  • Punto flotante doble (FD)
Punto flotante
  • Etiqueta de atributo (AT)
  • Signed Long (SL)
  • Signed Short (SS)
  • Entero largo sin signo (UL)
  • Shorts sin firmar (EE. UU.)
Entero
Secuencia de elementos (SQ) Struct (registro)

Modos anulables y repetidos

En función del valor de multiplicidad (VM) de un elemento de datos, su columna de BigQuery tiene uno de estos dos modos: NULLABLE o REPEATED.

Si un elemento de datos tiene un valor de VM de 1, lo que indica que el elemento de datos es único, el elemento de datos utiliza el modo NULLABLE. Para cualquier otro valor de VM, el elemento de datos usa el modo REPEATED.

Por ejemplo, tal como se muestra en el registro de elementos de datos DICOM, la palabra clave SOPInstanceUID tiene un valor VM de 1. Por lo tanto, cuando se exporta a BigQuery, su modo es NULLABLE y su representación en la tabla es la siguiente (cuando se representa como JSON):

"SOPInstanceUID": "0.0.000.000000.0.000.0000.0000000.0000.0000000000.000",

Por el contrario, la palabra clave ImageType tiene un valor de VM de 2-n. Por lo tanto, cuando se exporta a BigQuery, su modo es REPEATED y su representación en la tabla es la siguiente (cuando se representa como JSON):

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

VRs excluidas

Los datos binarios y de formato largo no se exportan a la tabla de BigQuery generada, por lo que no se exportan los elementos de datos que contienen los siguientes VRs. En su lugar, las siguientes VRs se incluyen en una columna independiente (llamada DroppedTags.TagName) de la tabla de destino de BigQuery.

  • Otro Double (OD)
  • Otro flotante (OF)
  • Otro (largo)
  • Otro byte (OB)
  • Otra palabra (OW)
  • Desconocido (UN)
  • Etiquetas de secuencia (SQ) que contengan más de 1 MiB de datos aproximadamente
  • Attribute (AT), Floating Point Double (FD), Floating Point Single (FL), Unsigned Long (UL) o Unsigned Short (US), si Value Multiplicity (VM) es mayor que 512.
    • Por motivos de compatibilidad, las etiquetas de las instancias ya insertadas en la API Cloud Healthcare pueden incluirse en la columna DroppedTags.TagName si la multiplicidad de valores es superior a 64.

Person Name VR

Cada columna del esquema de BigQuery con un VR de nombre de persona (PN) siempre contiene tres subcolumnas, independientemente de si las subcolumnas contienen datos. Las tres subcolumnas son las siguientes:

  • Alfabético
  • Ideográfico
  • Fonético

Cada una de las tres subcolumnas tiene cinco subcolumnas:

  • FamilyName
  • GivenName
  • MiddleName
  • NamePrefix
  • NameSuffix

Por ejemplo, considera la etiqueta pública "OperatorsName (0008,1070)", que tiene un VR de nombre de persona (PN). Supongamos que el valor de OperatorsName es "Darcy Smith". El esquema contendrá una columna OperatorsName con las subcolumnas que se han indicado anteriormente, pero solo Alphabetic.FamilyName (Smith) y Alphabetic.GivenName (Darcy) contendrán valores.

Elementos de datos privados

En algunas implementaciones clínicas, es posible que tengas que almacenar datos personalizados que no se ajusten a la estructura de los elementos de datos públicos. Como alternativa, puedes usar elementos de datos privados.

Los elementos de datos privados con un VR de SQ (Sequence of Items) tienen el mismo comportamiento que los elementos de datos estándar. Los elementos de datos privados con un VR de SQ se denominan secuencias de datos privados.

Los elementos de datos privados que no tienen un VR de SQ se anidan en una columna llamada OtherElements y se convierten en cadenas. Estos elementos de datos privados se denominan datos privados no secuenciales. Para consultar elementos de datos privados que no sean de secuencia, la consulta debe buscar en la columna OtherElements del elemento.

La columna OtherElements contiene dos subcolumnas: "Datos" y "Etiqueta". La columna Datos es la representación de cadena del valor del elemento de datos privado. Siempre es de tipo REPEATED. La columna "Etiqueta" usa el formato "Tag_HEX", donde HEX es una cadena hexadecimal del número de etiqueta.

Columnas LastUpdated y Type

Las columnas LastUpdated y Type se añaden a la tabla de BigQuery que se crea al exportar metadatos DICOM. Estas columnas no son elementos de datos estándar ni privados, y no se corresponden con el registro de elementos de datos DICOM.

El comportamiento de estas columnas es el siguiente:

  • La columna LastUpdated contiene una marca de tiempo que indica cuándo se insertó o eliminó la instancia DICOM en el almacén DICOM.
  • La columna Type contiene una cadena que muestra el tipo de operación que se ha producido. Los valores posibles son CREATE o DELETE.

Tipos en conflicto o que no coinciden

Si se produce un conflicto de tipos, por ejemplo, cuando se usa una etiqueta pública con un tipo incorrecto, la etiqueta pública se trata como si fuera una etiqueta privada. El valor del elemento de datos se anida en una columna llamada OtherElements y se convierte en una cadena.

Por ejemplo, supongamos que los metadatos DICOM contienen una etiqueta con lo siguiente:

  • Un número de etiqueta ("4010,1017")
  • Una VR de SL (Signed Long)
  • Un valor de 32

(4010,1017) es el mismo número de etiqueta que "Mass", que es un nombre de etiqueta pública en la especificación DICOM que tiene un VR de FL. La operación de exportación espera que un elemento de datos con el número de etiqueta "(4010,1017)" sea el nombre de etiqueta pública "Mass" con un VR de FL. Por lo tanto, la operación de exportación espera convertir el valor del elemento de datos en un número de coma flotante (como se muestra en la tabla de Comportamiento estándar de los elementos de datos DICOM

Se produce un conflicto de tipos porque todas las etiquetas con un valor de retorno de SL usan el tipo de datos entero. Por lo tanto, la etiqueta se convierte en una etiqueta privada y se añade a la columna OtherElements.

Si se usa un nombre de etiqueta pública que no es de secuencia para datos de secuencia, se produce un error de tipo. Por lo tanto, la secuencia se trata como si fuera un elemento de datos privado. En lugar de usar el nombre de la etiqueta pública como nombre de columna en el esquema de BigQuery, se usa el número hexadecimal del nombre de la etiqueta pública. El número hexadecimal es de tipo cadena.

Ejemplos: consultar elementos de datos públicos y privados

Veamos el siguiente fragmento de un esquema representado como JSON. El esquema se creó después de exportar datos DICOM a 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"
  }
  ...
]

En el siguiente ejemplo se muestra cómo consultar el elemento de datos públicos SOPInstanceUID. Para acceder al valor de la columna, ejecuta la siguiente consulta:

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

Al ejecutar la consulta, se devuelve un resultado similar al siguiente:

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

En el siguiente ejemplo se muestra cómo consultar datos privados que no son de secuencia. Ejecuta la siguiente consulta en la columna OtherElements, que se encuentra en la columna Tag_12345678. Ten en cuenta el uso del operador UNNEST, que es obligatorio porque estás consultando un RECORD.

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

Al ejecutar la consulta, se devuelve un resultado similar al siguiente, en función de la cantidad y el tipo de datos de la columna Tag_12345678.OtherElements:

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

Siguientes pasos

Consulta más información sobre las operaciones de SQL estándar de BigQuery y ejemplos.