Compreender o esquema DICOM do BigQuery

Esta página explica o esquema da tabela do BigQuery criada quando exporta metadados DICOM para o BigQuery.

Terminologia

Para compreender o esquema e os respetivos componentes, familiarize-se com a terminologia DICOM. Em particular, esta página usa vários termos encontrados em 3.10 DICOM Data Structures and Encoding Definitions.

Vista geral

A Cloud Healthcare API gera automaticamente o esquema do BigQuery com os dados que está a exportar e o dicionário DICOM. O esquema contém apenas colunas para elementos de dados DICOM que existem nos metadados. A única exceção é o nome da pessoa na RV.

Ao exportar metadados DICOM, a Cloud Healthcare API tenta exportar todos os elementos de dados nos metadados. Para obter informações sobre o que acontece se surgir um problema, consulte o artigo Tipos em conflito e com incompatibilidade.

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 destes elementos de dados, consulte o Registo de elementos de dados DICOM.

Nos casos em que tem de comunicar dados que não estão em conformidade com os elementos padrão, pode usar elementos de dados privados.

Elementos de dados padrão

Os seguintes comportamentos aplicam-se aos elementos de dados padrão. Para o comportamento dos elementos de dados privados, consulte Elementos de dados privados.

Nomes das colunas

As colunas no esquema do BigQuery gerado são denominadas de acordo com a palavra-chave do elemento de dados. Por exemplo, se os metadados DICOM contiverem um elemento de dados cuja palavra-chave seja InstanceCreationDate, o esquema gerado tem uma coluna correspondente denominada InstanceCreationDate.

Comportamento do elemento de dados DICOM padrão

A tabela seguinte mostra uma lista de representações de valores (VRs) e as respetivas abreviaturas. Para qualquer elemento de dados exportado para o BigQuery que contenha um destes VRs, o elemento de dados usa o tipo de dados do BigQuery encontrado em "Tipo de dados":

RV Tipo de dados
  • Entidade de aplicação (AE)
  • Age String (AS)
  • String de código (CS)
  • Long String (LO)
  • Texto longo (LT)
  • String curta (SH)
  • Texto curto (TC)
  • Carateres ilimitados (UC)
  • Identificador único (UI/UID)
  • Identificador de recursos universal (UR) ou localizador de recursos universal (URI/URL)
  • Mensagens de texto ilimitadas (UT)
 String
Data (DA) Data
Time (TM) Hora
Data/hora (DT) Data/hora
  • String decimal (DS)
  • String de número inteiro (IS)
 String
Nome da pessoa (PN) Struct (Record)
  • Floating Point Single (FL)
  • Vírgula flutuante dupla (FD)
 Vírgula flutuante
  • Etiqueta de atributo (AT)
  • Signed Long (SL)
  • Vídeo curto com interpretação em língua gestual (SS)
  • Unsigned Long (UL)
  • Vídeo curto sem assinatura (EUA)
 Inteiro
Sequência de itens (SQ) Struct (Record)

Modos anuláveis e repetidos

Consoante o valor de multiplicidade (VM) de um elemento de dados, a respetiva coluna do BigQuery tem um de dois modos: NULLABLE ou REPEATED.

Se um elemento de dados tiver um valor de VM de 1, o que indica que o elemento de dados é único, 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 Registo de elementos de dados DICOM, a palavra-chave SOPInstanceUID tem um valor VM de 1. Como resultado, quando é exportado para o BigQuery, o respetivo modo é NULLABLE, e a respetiva representação na tabela tem o seguinte aspeto (quando representado 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 é exportado para o BigQuery, o respetivo modo é REPEATED e a respetiva representação na tabela tem o seguinte aspeto (quando representado como JSON):

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

Registos de visualização excluídos

Os dados binários e de formato longo não são exportados para a tabela do BigQuery gerada, pelo que os elementos de dados que contêm os seguintes VRs não são exportados. Em alternativa, os VRs seguintes são incluídos numa coluna separada (denominada DroppedTags.TagName) na tabela de destino do BigQuery.

  • Outro duplo (OD)
  • Outro flutuador (OF)
  • Outro longo (OL)
  • Outros bytes (OB)
  • Outra palavra (OW)
  • Desconhecido (UN)
  • Etiquetas de sequência (SQ) que contêm mais de aproximadamente 1 MiB de dados
  • Attribute (AT), Floating Point Double (FD), Floating Point Single (FL), Unsigned Long (UL) ou Unsigned Short (US), se a Value Multiplicity (VM) for superior a 512.
    • Por motivos de compatibilidade com versões anteriores, as etiquetas de instâncias já carregadas na Cloud Healthcare API podem ser incluídas na coluna DroppedTags.TagName se a multiplicidade de valores for superior a 64.

Person Name VR

Cada coluna no esquema do BigQuery com um VR de nome de pessoa (PN) contém sempre três subcolunas, independentemente de as subcolunas conterem dados. As três subcolunas são:

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

Cada uma das três subcolunas tem as suas próprias cinco subcolunas:

  • FamilyName
  • GivenName
  • MiddleName
  • NamePrefix
  • NameSuffix

Por exemplo, considere a etiqueta pública "OperatorsName (0008,1070)", que tem um VR de Person Name (PN). Suponhamos que o valor de OperatorsName é "Darcy Smith". O esquema vai conter uma coluna OperatorsName com as subcolunas indicadas anteriormente, mas apenas Alphabetic.FamilyName (Smith) e Alphabetic.GivenName (Darcy) vão conter valores.

Elementos de dados privados

Algumas implementações clínicas podem exigir que armazene dados personalizados que não se enquadram na estrutura dos elementos de dados públicos. Em alternativa, pode usar elementos de dados privados.

Os elementos de dados privados com um VR de SQ (Sequence of Items) têm o mesmo comportamento que os elementos de dados padrão. Os elementos de dados privados com um VR de SQ são denominados sequências de dados privados.

Os elementos de dados privados que não têm um VR de SQ estão aninhados numa coluna denominada OtherElements e são convertidos em strings. Estes elementos de dados privados são denominados dados privados não sequenciais. Para consultar elementos de dados privados que não sejam de sequência, a consulta tem de pesquisar na coluna OtherElements do elemento.

A coluna OtherElements contém duas subcolunas: "Dados" e "Etiqueta". A coluna de dados é a representação de string do valor do elemento de dados privado. É sempre do tipo REPEATED. A coluna Etiqueta usa o formato "Tag_HEX", em que HEX é uma string hexadecimal do número da etiqueta.

Colunas LastUpdated e Type

As colunas LastUpdated e Type são adicionadas à tabela do BigQuery criada quando exporta metadados DICOM. Estas colunas não são elementos de dados padrão nem privados e não correspondem ao registo de elementos de dados DICOM.

O comportamento destas colunas é o seguinte:

  • A coluna LastUpdated contém um valor de data/hora que mostra quando a instância DICOM foi inserida ou eliminada do arquivo DICOM.
  • A coluna Type contém uma string que mostra o tipo de operação que ocorreu. Os valores possíveis são CREATE ou DELETE.

Tipos em conflito e com incompatibilidade

Se ocorrer um conflito de tipo, como quando uma etiqueta pública é usada com um tipo incorreto, a etiqueta pública é tratada como se fosse uma etiqueta privada. O valor do elemento de dados está aninhado numa coluna denominada OtherElements e o valor é convertido numa string.

Por exemplo, suponhamos que os metadados DICOM contêm uma etiqueta com:

  • Um número de etiqueta "(4010,1017)"
  • Um RV de SL (Signed Long)
  • Um valor de 32

(4010,1017) é o mesmo número de etiqueta que "Massa", que é um nome de etiqueta público na especificação DICOM que tem um VR de FL. A operação de exportação espera que um elemento de dados com o número de etiqueta de "(4010,1017)" seja o nome da etiqueta pública "Massa" com um VR de FL. Por conseguinte, a operação de exportação espera converter o valor do elemento de dados num número de vírgula flutuante (como mostrado na tabela em Comportamento padrão do elemento de dados DICOM

Ocorre um conflito de tipos porque todas as etiquetas com um VR de SL usam o tipo de dados integer. Por conseguinte, a etiqueta é convertida numa etiqueta privada e adicionada à coluna OtherElements.

Se for usado um nome de etiqueta pública não sequencial para dados de sequência, ocorre uma incompatibilidade de tipo. Como resultado, a sequência é tratada como se fosse um elemento de dados privado. Em vez de usar o nome da etiqueta pública como o nome da coluna no esquema do BigQuery, é usado o número hexadecimal do nome da etiqueta pública. O número hexadecimal é do tipo string.

Exemplos: consultar elementos de dados públicos e privados

Considere o seguinte fragmento 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"
  }
  ...
]

O exemplo seguinte mostra como consultar o elemento de dados públicos SOPInstanceUID. Para aceder ao valor da coluna, execute a seguinte consulta:

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

A execução da consulta devolve um resultado semelhante ao seguinte:

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

O exemplo seguinte mostra como consultar dados privados não sequenciais. Execute a seguinte consulta na coluna OtherElements, que se encontra na coluna Tag_12345678. Tenha em atenção a utilização do operador UNNEST, que é obrigatório porque está a consultar 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 devolve um resultado semelhante ao seguinte, consoante a quantidade e o 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"
        ]
      }
    ]
  }
]

O que se segue?

Saiba mais sobre as operações do SQL padrão do BigQuery e veja exemplos.