Comprender el esquema DICOM de BigQuery

En esta página, se explica el esquema de la tabla de BigQuery que se crean al exportar Metadatos de DICOM a BigQuery.

Terminología

Para comprender el esquema y sus componentes, familiarízate con la terminología de DICOM. En particular, esta página utiliza varios términos que se encuentran en 3.10 Estructuras de Datos de DICOM y Definiciones de Codificación.

Descripción general

La API de Cloud Healthcare genera automáticamente BigQuery con los datos que exportas y el diccionario DICOM. El esquema solo contiene columnas para los elementos de datos de DICOM que existen en los metadatos. La única excepción es la RV de nombre de persona.

Cuando se exportan metadatos de DICOM, la API de Cloud Healthcare intenta exportar todos los elementos de datos en los metadatos. Para obtener información sobre lo que ocurre si ocurre un problema consulta Tipos de conflicto y no coincidencia.

Elementos de datos privados y estándar

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

En los casos en los que debas comunicar datos que no cumplan con el 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 datos privados sobre el comportamiento de los elementos, consulta Elementos de datos privados.

Nombres de columnas

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

Comportamiento de elemento de datos DICOM estándar

En la siguiente tabla, se muestra una lista de representaciones de valores (VR) y sus abreviaciones. Para cualquier dato exportado a BigQuery que contiene una de estas VR el elemento de datos usa el tipo de datos de BigQuery que se encuentra en “Tipo de datos”:

VR	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 corto (ST) Personajes ilimitados Identificador único (UI/UID) Identificador universal de recursos (UR) o localizador universal de recursos (URI/URL) Texto ilimitado (UT)	String
Fecha (DA)	Fecha
Hora (TM)	Hora
Fecha y hora (DT)	Marca de tiempo
Cadena decimal (DS) Cadena de números enteros (IS)	String
Nombre de la persona (PN)	Estructura (registro)
Punto flotante simple (FL) Doble punto flotante (FD)	Punto flotante
Etiqueta de atributo (AT) Firmado largo (SL) Firmado corto (SS) Sin firma largo (UL) Sin firma corto (US)	Número entero
Secuencia de elementos (SQ)	Estructura (registro)

Modos repetibles y con nulabilidad

Según el valor de la multiplicidad de valores (VM) de un elemento de datos, su La columna de BigQuery tiene uno de dos modes: NULLABLE o REPEATED.

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

Por ejemplo, como se muestra en el Registro de elementos de datos de DICOM, haz lo siguiente: la palabra clave SOPInstanceUID tiene un valor de VM de 1. Como resultado, Cuando se exporta a BigQuery, su modo es NULLABLE. y su representación en la tabla es similar a 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. Como resultado, cuando se exporta a BigQuery, su modo se REPEATED y su representación en la tabla se ve de la siguiente manera (cuando representado como JSON):

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

RV excluidas

Los datos binarios y de formato largo no se exportan al BigQuery generado de modo que los elementos de datos que contengan las siguientes VR no se exporten. En cambio, las siguientes VR se incluyen en una columna independiente (llamada DroppedTags.TagName) en la tabla de BigQuery de destino.

• Otro doble (OD)
• Otro valor de número de punto flotante (OF)
• Otro formato largo (OL)
• Otros bytes (OB)
• Otra palabra (OW)
• Desconocido (ONU)
• Etiquetas de secuencia (SQ) que contienen más de aproximadamente 1 MiB de datos
• Atributo (AT), número de punto flotante doble (FD), número de punto flotante simple (FL), número entero sin signo largo (UL) o número entero sin signo corto (US), si la multiplicidad de valores (VM) es superior a 512.
  • Por motivos heredados, es posible que las etiquetas de instancias que ya se transfirieron a la API de Cloud Healthcare se incluyan en la columna DroppedTags.TagName si la Multiplicidad de valores es superior a 64.

RV de nombre de persona

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

• Alfabético(a)
• Ideográfico
• Fonético(a)

Cada una de las tres subcolumnas tiene sus propias cinco subcolumnas:

• FamilyName
• GivenName
• MiddleName
• NamePrefix
• NameSuffix

Por ejemplo, considera la etiqueta pública "OperatorsName (0008,1070)", que tiene una RV del nombre de la persona (PN). Supongamos que el valor de OperatorsName es “Darch Smith”. El esquema contendrá una columna OperatorsName que contiene las subcolumnas enumeradas anteriormente, pero solo Alphabetic.FamilyName (Smith) y Alphabetic.GivenName (Darny) contendrán valores.

Elementos de datos privados

Algunas implementaciones clínicas podrían requerir que almacene datos personalizados no encaja en la estructura de los elementos de datos públicos. Como alternativa, puedes usar elementos de datos privados.

Los elementos de datos privados con una VR de SQ (secuencia de elementos) tienen la misma comportamiento como elementos de datos estándar. Datos privados los elementos con una RV de SQ se denominan secuencias de datos privados.

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

La columna OtherElements contiene dos subcolumnas, “Datos” y “Etiqueta”. El La columna de datos es la representación de cadena del valor del elemento de datos privados. Siempre es del tipo REPEATED. La columna Etiqueta usa el formato “Etiqueta_HEX” en el que HEX es una string hexadecimal del número de etiqueta.

Columnas LastUpdated y Type

Las columnas LastUpdated y Type se agregan a la tabla de BigQuery que se crea cuando exportas metadatos de DICOM. Estas columnas no son estándares datos privados o sensibles, y no corresponden al Registro de Elementos de los datos de DICOM.

El comportamiento de estas columnas es el siguiente:

• La columna LastUpdated contiene un valor de marca de tiempo que muestra cuándo se insertó o borró la instancia de DICOM del almacén de DICOM.
• La columna Type contiene una cadena. que muestra qué tipo de operación ocurrió. Los valores posibles son CREATE. o DELETE.

Tipos de encabezados que no coinciden y que son contradictorios

Si se produce un conflicto de tipo, 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 de el elemento de datos es anidada en una columna llamada OtherElements, y el valor se convierte en una string.

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

• Un número de etiqueta "(4010,1017)"
• Una RV de SL (Firmado largo)
• Un valor de 32

(4010,1017) es el mismo número de etiqueta que "Mass", que es un nombre de etiqueta público en la especificación DICOM que tiene una RV 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 público de etiqueta "Mass" con una RV de FL. Por lo tanto, la operación de exportación espera convertir el valor del elemento de datos en un número de punto flotante (como se muestra en la tabla en Comportamiento estándar del elemento de datos de DICOM).

Se produce un conflicto de tipo porque cualquier etiqueta con una RV o SL usa el número entero el tipo de datos. Por lo tanto, la etiqueta se convierte en una etiqueta privada y se agrega al OtherElements.

Si se usa un nombre de etiqueta público sin secuencia para los datos de secuencia, se produce un error de coincidencia de tipo. Como resultado, la secuencia se trata como si eran un elemento de datos privados. En lugar de usar el nombre público de etiqueta como el nombre de columna en el esquema de BigQuery, se usa el número hexadecimal del nombre de etiqueta público. El número hexadecimal es del tipo cadena.

Ejemplos: Consulta elementos de datos públicos y privados

Considera el siguiente fragmento de un esquema representado como JSON. El esquema se creó después de la exportación Datos de 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`

Cuando ejecutas la consulta, se muestra 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 secuencias. Ejecuta la siguiente consulta en la columna OtherElements, que se dentro de la columna Tag_12345678. Observa el uso de UNNEST que es necesario porque consultas un RECORD.

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

Cuando ejecutas la consulta, se muestra un resultado similar al siguiente, según según 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"
        ]
      }
    ]
  }
]

¿Qué sigue?

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