Nesta página, explicamos o esquema da tabela do BigQuery que é criada ao exportar metadados do DICOM para o BigQuery.
Terminologia
Para entender o esquema e os componentes dele, familiarize-se com a terminologia DICOM. Especificamente, esta página usa vários termos encontrados em 3.10 Estruturas de dados DICOM e definições de codificação.
Visão geral
A API Cloud Healthcare gera automaticamente o esquema do BigQuery usando os dados que você está exportando e o dicionário DICOM. O esquema contém apenas colunas para elementos de dados DICOM que existem nos metadados. A única exceção é a VR do nome da pessoa.
Ao exportar metadados DICOM, a API Cloud Healthcare tenta exportar todos os elementos de dados nos metadados. Para informações sobre o que acontece se ocorrer um problema, consulte Tipos conflitantes e incompatíveis.
Elementos de dados padrão e privados
O DICOM fornece elementos de dados padrão que estão em conformidade com uma especificação predefinida. Para ver uma lista desses elementos de dados, consulte Registro de elementos de dados DICOM.
Nos casos em que você precisa comunicar dados que não estão em conformidade com os elementos padrão, é possível usar elementos de dados particulares.
Elementos de dados padrão
Os comportamentos a seguir se aplicam a elementos de dados padrão. Para saber mais sobre o comportamento de elementos de dados particulares, consulte Elementos de dados particulares.
Nomes de coluna
As colunas no esquema do BigQuery gerado são nomeadas de acordo com a palavra-chave do elemento de dados. Por exemplo, se os metadados DICOM contiverem um elemento de dados com a palavra-chave InstanceCreationDate, o esquema gerado terá uma coluna correspondente chamada InstanceCreationDate.
Comportamento padrão do elemento de dados DICOM
A tabela a seguir mostra uma lista de representações de valor (VRs, na sigla em inglês) e suas abreviações. Para qualquer elemento de dados exportado para o BigQuery que contenha uma dessas VRs, o elemento de dados usa o tipo de dados do BigQuery encontrado em "Tipo de dados":
| VR | Tipo de dado |
|---|---|
|
String |
| Data (DA) | Data |
| Horário (TM) | Hora |
| Data/Hora (DT) | Carimbo de data/hora |
|
String |
| Nome da pessoa (PN) | Struct (Record) |
|
Ponto flutuante |
|
Número inteiro |
| Sequência de itens (SQ) | Struct (Registro) |
Modos nulos e repetidos
Dependendo do valor de multiplicação de valores (VM, na sigla em inglês) de um elemento de dados, a coluna do BigQuery tem um dos dois modes: NULLABLE ou REPEATED.
Se um elemento de dados tiver um valor de VM de 1, que indica que o elemento de dados é exclusivo, o elemento de dados usa o modo NULLABLE. Para qualquer outro valor de VM, o elemento de dados usa o modo REPEATED.
Por exemplo, conforme mostrado no Registro de elementos de dados DICOM, a palavra-chave SOPInstanceUID tem um valor de VM de 1. Como resultado, quando ele é exportado para o BigQuery, o modo é NULLABLE e a representação na tabela é semelhante a esta (quando representada como JSON):
"SOPInstanceUID": "0.0.000.000000.0.000.0000.0000000.0000.0000000000.000",
Por outro lado, a palavra-chave ImageType tem um valor de VM de 2-n.
Como resultado, quando ele é exportado para o BigQuery, o modo é REPEATED e a representação na tabela é semelhante a esta (quando representada como JSON):
"ImageType": [
"ORIGINAL",
"PRIMARY",
"OTHER",
"..."
],
VRs excluídas
Dados binários e longos não são exportados para a tabela gerada do BigQuery. Portanto, os elementos de dados que contêm as RVs a seguir não são exportados. Em vez disso, as RVs a seguir são incluídas em uma coluna separada (chamada DroppedTags.TagName) na tabela de destino do BigQuery.
- Outro (DO)
- Outro flutuante (OF)
- Outro longo (OL)
- Outro byte (OB)
- Outra palavra (OW)
- Desconhecido (UN)
- Tags de sequência (SQ) contendo mais de aproximadamente 1 MiB de dados
- Atributo (AT), duplo de ponto flutuante (FD), de ponto flutuante único (FL), longo não assinado (UL) ou Short não assinado (EUA), se a multiplicidade do valor (VM) for maior que 64
VRs do nome da pessoa
Cada coluna do esquema do BigQuery com um VR do Nome da pessoa (PN, na sigla em inglês) sempre contém três subcolunas, independentemente de as subdados conterem dados. As três subcolunas são:
- Alfabética
- Ideográfica
- Fonética
Cada uma das três sub-colunas tem suas próprias cinco sub-colunas:
- FamilyName
- GivenName
- MiddleName
- NamePrefix
- NameSuffix
Por exemplo, considere a tag pública "OperatorsName (0008,1070)", que tem uma VR do nome da pessoa (PN). Suponha que o valor de OperatorsName seja "Darcy Smith". O esquema conterá uma coluna OperatorsName cque contém as sub-colunas listadas anteriormente, mas apenas Alphabetic.FamilyName (Smith) e Alphabetic.GivenName (Darcy) terão valores.
Elementos de dados privados
Algumas implementações estratégicas podem exigir o armazenamento de dados personalizados que não se encaixam na estrutura de elementos de dados públicos. Como alternativa, você pode usar elementos de dados particulares.
Os elementos de dados particulares com uma VR de SQ (sequência de itens) têm o mesmo comportamento dos elementos de dados padrão. Elementos de dados particulares com uma VR de SQ são chamados de sequências de dados particulares.
Os elementos de dados particulares que não têm uma VR de SQ são aninhados em uma coluna chamada OtherElements e convertidos em strings. Esses elementos de dados particulares são chamados de dados privados sem sequência. Para consultar elementos de dados privados não sequenciais, a consulta precisa pesquisar na coluna OtherElements do elemento.
A coluna OtherElements contém duas subcolunas, "Data" e "Tag". A coluna "Data" é a representação de string do valor do elemento de dados particular.
É sempre do tipo REPEATED. A coluna Tag usa o formato "Tag_ HEX", em que HEX é uma string hexadecimal do número da tag.
Colunas LastUpdated e Type
As colunas LastUpdated e Type são adicionadas à tabela do BigQuery
criada quando você exporta metadados DICOM. Essas colunas não são elementos de dados padrão
ou particulares e não correspondem ao registro de
elementos de dados DICOM.
O comportamento dessas colunas é o seguinte:
- A coluna
LastUpdatedcontém um valor de carimbo de data/hora que mostra quando a instância DICOM foi inserida ou excluída do armazenamento DICOM. - A coluna
Typecontém uma string que mostra o tipo de operação que ocorreu. Os valores possíveis sãoCREATEouDELETE.
Tipos conflitantes e incompatíveis
Se ocorrer um conflito de tipo, como quando uma tag pública é usada com um tipo incorreto, ela será tratada como se fosse uma tag particular. O valor do elemento de dados é aninhado em uma coluna chamada OtherElements, e o valor é convertido em uma string.
Por exemplo, digamos que os metadados DICOM contenham uma tag com:
- Um número de tag "(4010.0,017)"
- Uma VR de SL (longa com sinal)
- Um valor de 32
(4010,1017) é o mesmo número de tag que "Mass", que é um nome de tag público na especificação DICOM que tem uma VR de FL. A operação de exportação espera que um elemento de dados com o número de tag "(4010.01017)" seja o nome da tag pública "Mass" com uma vr de FL. Portanto, a operação de exportação espera a conversão do valor do elemento de dados em um flutuante (conforme mostrado na tabela em Comportamento do elemento de dados DICOM padrão).
Um conflito de tipos ocorre porque todas as tags com uma VR de SL usam o tipo de dados inteiro. Portanto, a tag é convertida em uma tag privada e adicionada à coluna OtherElements.
Se um nome de tag pública sem sequência for usado para dados sequenciais, ocorrerá uma incompatibilidade de tipo. Como resultado, a sequência é tratada como se fosse um elemento de dados particular. Em vez de usar o nome da tag pública como o nome da coluna no esquema do BigQuery, o número de instâncias do nome da tag pública é usado. O número hexadecimal é do tipo string.
Exemplos: como consultar elementos de dados públicos e privados
Considere o snippet a seguir de um esquema representado como JSON. O esquema foi criado após a exportação de dados DICOM para o 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"
}
...
]
A amostra a seguir mostra como consultar o elemento de dados públicos SOPInstanceUID.
Para acessar o valor da coluna, execute a seguinte consulta:
#standardSQL SELECT SOPInstanceUID FROM `PROJECT_ID.DATASET_ID.TABLE_ID`
A execução da consulta retorna uma saída semelhante a esta:
[
...
{
"SOPInstanceUID": "0.0.000.000000.0.000.0000.0000000.0000.0000000000.000"
},
...
]
Veja na amostra a seguir como consultar dados particulares sem sequência.
Execute a seguinte consulta na coluna OtherElements, que está dentro da coluna Tag_12345678. Observe o uso do operador UNNEST, que é obrigatório porque você está consultando um RECORD.
#standardSQL SELECT Tag_12345678.OtherElements AS OtherElements FROM `PROJECT_ID.DATASET_ID.TABLE_ID`, UNNEST(Tag_12345678) AS Tag_12345678
A execução da consulta retorna uma saída semelhante à seguinte, dependendo da quantidade e do tipo de dados na coluna Tag_12345678.OtherElements:
[
{
"OtherElements": [
{
"Tag": "Tag_12345678",
"Data": [
"DATA"
]
}
]
},
{
"OtherElements": [
{
"Tag": "Tag_12345678",
"Data": [
"DATA"
]
}
]
},
{
"OtherElements": [
{
"Tag": "Tag_12345678",
"Data": [
"DATA"
]
}
]
}
]
A seguir
Saiba mais sobre as operações do SQL padrão do BigQuery e veja exemplos.