En esta página, se explica el esquema de la tabla de BigQuery que se crea cuando se exportan 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 usa varios términos que se encuentran en 3.10 Estructura de datos y definiciones de codificación de DICOM.
Descripción general
La API de Cloud Healthcare genera automáticamente el esquema de BigQuery con los datos que estás exportando 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 sucede 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 obtener una lista de estos elementos de datos, consulte Registro de elementos de datos de DICOM.
En los casos en los que debes 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 conocer el comportamiento de los elementos de datos privados, consulta Elementos de datos privados.
Nombres de columnas
Las columnas en el esquema de BigQuery generado se nombran según la palabra clave del elemento de datos. Por ejemplo, si los metadatos de DICOM contienen un elemento de datos cuya palabra clave es InstanceCreationDate, 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 las representaciones de valores (VR) y sus abreviaturas. Para cualquier elemento de datos exportado a BigQuery que contenga una de estas RV, el elemento de datos usa el tipo de datos de BigQuery que se encuentra en "Tipo de datos":
VR | Tipo de datos |
---|---|
|
String |
Fecha (DA) | Fecha |
Hora (TM) | Hora |
Fecha y hora (DT) | Marca de tiempo |
|
String |
Nombre de la persona (PN) | Estructura (registro) |
|
Punto flotante |
|
Número entero |
Secuencia de ítems (SQ) | Estructura (registro) |
Modos repetibles y con nulabilidad
Según el valor de multiplicidad de valores (VM) de un elemento de datos, su columna de BigQuery tiene uno de los dos modes: NULLABLE
o REPEATED
.
Si un elemento de datos tiene un valor de VM de 1, que indica que el elemento de datos es único, utiliza 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, 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 es REPEATED
y su representación en la tabla es similar a la siguiente (cuando se representa como JSON):
"ImageType": [
"ORIGINAL",
"PRIMARY",
"OTHER",
"..."
],
VR excluidas
Los datos binarios y de formato largo no se exportan a la tabla de BigQuery generada, por lo que los elementos de datos que contienen las siguientes RV no se exportan. En cambio, las siguientes RV se incluyen en una columna separada (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)
- Otro bytes (OB)
- Otra palabra (OW)
- Desconocido (ONU)
- Etiquetas de secuencia (SQ) que contienen más de aproximadamente 1 MiB de datos
- Atributo (AT), doble punto flotante (FD), punto flotante único (FL), largo sin firma (UL) o Short sin firma (EE.UU.), si el valor de multiplicidad (VM) es mayor que 64
RV de nombre de persona
Cada columna en el esquema de BigQuery con un nombre de persona (PN) RV siempre contiene tres subcolumnas, sin importar si las subcolumnas contienen algún dato. 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 pueden requerir que almacenes 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 una VR de SQ (secuencia de elementos) 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 strings. 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”. La columna 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.
LastUpdated
y Type
columnas
Las columnas LastUpdated
y Type
se agregan a la tabla de BigQuery que se crea cuando exportas metadatos de DICOM. Estas columnas no son elementos de datos estándar ni privados, y no corresponden al registro de elementos de datos de DICOM.
El comportamiento de estas columnas es el siguiente:
- La columna
LastUpdated
contiene un valor de timestamp que muestra cuándo se insertó o borró la instancia de DICOM en el almacén de DICOM. - La columna
Type
contiene una string que muestra qué tipo de operación ocurrió. Los valores posibles sonCREATE
oDELETE
.
Tipos de encabezados que no coinciden y que son contradictorios
Si ocurre un conflicto de tipo, como cuando se usa una etiqueta pública con un tipo incorrecto, la etiqueta pública se trata como si fuera una privada. El valor del elemento de datos se anida 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).
Un conflicto de tipos se produce porque cualquier etiqueta con un VR de SL usa el tipo de datos de número entero. Por lo tanto, la etiqueta se convierte en una privada y se agrega a la columna 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 fuera 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: Consultar elementos de datos públicos y privados
Considera el siguiente fragmento de un esquema representado como JSON. El esquema se creó después de exportar 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 ejecutes la consulta, se mostrará 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 está dentro de la columna Tag_12345678
. Ten en cuenta el uso del operador 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 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.