Wellington Soares R. de Barros

Controle de Dose de Radiação Aplicado ao SistemaCatarinense de Telemedicina

Florianópolis, Santa Catarina

28 de fevereiro de 2013

Wellington Soares R. de Barros

Controle de Dose de Radiação Aplicado ao SistemaCatarinense de Telemedicina

Trabalho de conclusão de curso apresentadocomo parte dos requisitos para obtenção do graude Bacharel em Ciências da Computação

Orientador:

Prof. Dr. rer.nat. Aldo von Wangenheim

UNIVERSIDADE FEDERAL DE SANTA CATARINA

Florianópolis, Santa Catarina

28 de fevereiro de 2013

Agradecimentos

Agradeço ao professor Aldo von Wangenheim, meu orientador, pelo apoio na realização

deste trabalho.

Aos membros da banca, Harley Wagner, Matheus Savi, pelo apoio, críticas e sugestões.

Ao Cloves Barcellos, Richard Martini, Thiago Coelho Prado, que ajudaram na compreensão

e interpretação dos padrões de comunicação DICOM.

Aos colegas do LABTELEMED, principalmente o Felipe Duarte que me auxiliou nessa

etapa final; e aos demais colegas de trabalho, Cristina Ruby, Tiago Steinmetz, Alexandre Mar-

quez, Luiz Felipe Kohler, Anderson Bragiatto e João Siquerolli PQD; que de forma direta ou

indireta também colaboraram.

Resumo

A tomografia computadorizada é um dos principais métodos de exames radiológicos. Entre-tanto, deve-se observar que por haver exposição à radiação ionizante no processo de aquisiçãodas imagens, este procedimento apresenta riscos inerentes, e sua utilização deve ser resultadode uma análise entre o custo e o benefício promovido pelo procedimento. Para dar subsídio deinformações às pessoas envolvidas com o processo, os dados de dosimetria provenientes dos ex-ames médicos são dados de grande importância a serem armazenados.Contudo, atualmente háuma heterogeneidade no armazenamento destes. Desde equipamentos que não armazena essainformação, até equipamentos que armazena de maneira incompleta e proprietária. Entretanto,já há soluções e esforços por parte dos fabricantes de equipamentos médicos para armazenar demaneira padronizada, isto é, arquivosestruturados e esquematizados pelo grupo DICOM, tal ar-quivo denominado Radiation Dose Structured Report (RDSR). Neste trabalho são apresentadosos conceitos necessários para realizar a implantação do controle de dose de radiação, desde oprocesso de análise dos dados disponíveis,a aquisição e uniformização dos dados, e a geraçãodos arquivos estruturados. Concomitantemente, estes dados são indexados para realizar umpós-processamento com o intuito de explorar melhor essa fonte de informação. E por último,o trabalho utiliza como objeto de estudo, a viabilidade de implantação no Sistema Catarinensede Telemedicina. Os resultados obtidos são uma aplicação modular, pronta para auxiliar nacaptação dos dados de dosimetria para fornecer uma base de informação e embasar estatísti-cas e técnicas de mineração de dados; como também os passos e processos necessários paraacomodar o recebimento e armazenamento destes arquivos estruturados em um ambiente hos-pitalar informatizado. E por fim, as dificuldades e desafios a serem enfrentadas na implantaçãodo controle de dose de radiação em um Sistema de Telemedicina em larga escala.

Palavras-chave: Tomografia Computadorizada, Dose Radiação, DICOM, RDSR, Telemedic-ina

Abstract

The computerized tomography is one of the main methods of radiologic study. However, itmust be noted that since there is exposure to ionizing radiation in the process of acquiring theimages, this procedure presents inherent risks, and its utilization must result from an analysis ofthe pros and cons promoted by the procedure. To give a subsidy of information to the people in-volved in the process, the dosimetry data from the medical examinations is information of greatimportance to be stored. Although, currently there is a heterogeneity in the storage process ofthese information. From equipments that does not support, to ones that stores the information inan incomplete and proprietary way. However, there are solutions and efforts made by manufac-turers of the equipment to store in a standard way, in essence, files structured and schematizedby the DICOM group, also known as Radiation Dose Structured Report (RDSR). In this paperare presented the concepts necessary to perform the implementation of the radiation dosagecontrol, from the analysis process of the available data, to the acquisition and uniformization ofthe data and generation of structured files. Simultaneously, these data are indexed to realize apost-processing with the aim to better explore this source of information. And finally, this paperutilizes as the object of study, the feasibility of implementation on the Sistema Catarinense deTelemedicina. The obtained results are a modular application, ready to assist in the captationof dosimetry data to supply an information base and to base statistics and techniques of datamining; as well as the necessary steps and processes to accommodate the reception and storageof these structured files in a computerized hospital environment. And finally, the difficulties andchallenges to face in the implantation of the radiation dose control in a large scale telemedicinesystem.

Key-words: Computed Tomography, Radiation Dose, DICOM, RDSR, Telemedicine

Lista de Abreviaturas e Siglas

AAPM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . American Association of Physicists in Medicine

ACR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . American College of Radiology

ANVISA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Agência Nacional de Vigilância Sanitária

API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Application Programming Interface

CNEN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Comissão Nacional de Energia Nuclear

DICOM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Digital Imaging and Communications in Medicine

DICOM SR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . DICOM Structured Reporting

Gy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Grays

ICRP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . International Commission on Radiological Protection

IHE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Integrating the Healthcare Enterprise

IOD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Information Object Definition

IOM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Information Object Module

MR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ressonância Magnética

NEMA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . National Electrical Manufacturers Association

PACS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Picture Archiving and Communication System

RCTM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Rede Catarinense de Telemedicina

RDSR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Radiation Structured Report

RSL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Revisão Sistemática da Literatura

SIIM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Society for Imaging Informatics in Medicine

STT/SC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Sistema Catarinense de Telemedicina

Sv . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Sievert

TC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Tomografia Computadorizada

US . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ultrassonografia

Sumário

Lista de Figuras

Lista de Tabelas

1 Introdução p. 13

1.1 Contextualização . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 13

1.2 Problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 17

1.3 Justificativa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 17

1.4 Cenário de Aplicação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 18

1.4.1 Cenário 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 18

1.4.2 Cenário 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 18

1.5 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 19

1.5.1 Objetivos Gerais . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 19

1.5.2 Objetivos Específicos . . . . . . . . . . . . . . . . . . . . . . . . . . p. 19

1.6 Resultados Esperados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 19

1.7 Limitações do Trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 20

1.8 Estrutura do Trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 20

2 Revisão Bibliográfica p. 21

2.1 Conceitos Fundamentais . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 21

2.1.1 Sistema Catarinense de Telemedicina . . . . . . . . . . . . . . . . . p. 21

2.1.2 Grandezas e Unidades Dosimétricas . . . . . . . . . . . . . . . . . . p. 23

2.1.3 PACS - Servidor Imagens Médicas . . . . . . . . . . . . . . . . . . . p. 25

2.1.4 DICOM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 26

2.1.5 Tecnologia de OCR - Optical character recognition . . . . . . . . . . p. 33

2.2 Revisão Sistemática . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 33

2.2.1 Questão de Pesquisa . . . . . . . . . . . . . . . . . . . . . . . . . . p. 33

2.2.2 Definições da bases de dados e termos de pesquisa . . . . . . . . . . p. 34

2.2.3 Critérios de Inclusão e Exclusão . . . . . . . . . . . . . . . . . . . . p. 36

2.2.4 Seleção dos Estudos . . . . . . . . . . . . . . . . . . . . . . . . . . p. 37

2.2.5 Extração dos Dados . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 37

2.2.6 Detalhamento dos Trabalhos Relacionados . . . . . . . . . . . . . . p. 38

3 Desenvolvimento p. 45

3.1 Ferramenta Geradora . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 45

3.1.1 Visão Geral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 45

3.1.2 Etapa 1 - Análise dos Dados . . . . . . . . . . . . . . . . . . . . . . p. 47

3.1.3 Etapa 2 - Extração dos Dados . . . . . . . . . . . . . . . . . . . . . p. 48

3.1.4 Etapa 3 - Geração Arquivo de Saída . . . . . . . . . . . . . . . . . . p. 53

3.2 Alteração no PACS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 59

3.3 Implantação no STT - Estudo de Viabilidade . . . . . . . . . . . . . . . . . . p. 61

4 Conclusão p. 66

5 Trabalhos Futuros p. 68

Referências Bibliográficas p. 69

Apêndice A -- DICOM - IOD CT - Campos Extraídos p. 73

Apêndice B -- RPT - 204 p. 77

B.0.1 AAPM - RPT 204 . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 77

Anexo A -- DICOM - Suplemento 127: CT Radiation Dose Reporting (Dose SR) p. 81

Anexo B -- Código Fonte - Trecho do Cód. Ferramenta Geradora de CSV/RDSR p. 105

Lista de Figuras

1.1 Célula após sofrer radiação. . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 14

2.1 Visão Geral do Sistema Catarinense de Telemedicina. . . . . . . . . . . . . . p. 22

2.2 Página inicial Portal de Telemedicina. . . . . . . . . . . . . . . . . . . . . . p. 23

2.3 Exemplos da utilização do padrão DICOM. . . . . . . . . . . . . . . . . . . p. 26

2.4 Hierarquia da informação no contexto DICOM. . . . . . . . . . . . . . . . . p. 29

2.5 Estrutura interna de um arquivo DICOM. . . . . . . . . . . . . . . . . . . . p. 30

2.6 Abstração do conjunto de elementos ordenados crescentemente pelas respec-

tivas TAG. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 31

2.7 Processo alto nível para comunicação DICOM. . . . . . . . . . . . . . . . . p. 32

2.8 Exemplo do processo de extração de dados através de OCR. . . . . . . . . . p. 33

2.9 Diagrama exibindo o processo automatizado realizado pela aplicação DIRA. . p. 38

2.10 Gráfico exibindo a relação das medidas de CTDIvol e o tamanho do Phantom.

Exames realizados em um aparelho 16-MDCT (Sensation, Siemens Health-

care). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 39

2.11 Diagrama exibindo o processo automatizado realizado pela aplicação RADI-

ANCE. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 40

2.12 Imagem exibindo a diferença entre os DoseSheets de cada fabricante. (A):

Philips; (B): Toshiba; (C): Siemens. . . . . . . . . . . . . . . . . . . . . . . p. 41

2.13 RADIANCE - esquema do banco de dados. . . . . . . . . . . . . . . . . . . p. 42

2.14 RADIANCE - análise de exames por tomógrafo. . . . . . . . . . . . . . . . p. 42

2.15 Diagrama do processo automatizado realizado pela aplicação PERMOSS. . . p. 43

2.16 Software PERMOS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 44

3.1 Visão Geral do Sistema. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 46

3.2 Amostra de um dump de todos os arquivos de um exame arbitrário. . . . . . . p. 48

3.3 Fluxograma de execuçao da ferramenta cycRDSR. . . . . . . . . . . . . . . p. 49

3.4 Diagrama UML - Hierarquia de classes para modularizar a etapa de extração

dos dados. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 52

3.5 Grafo exibindo a relação entre as centenas de nodos do arquivo RDSR. . . . . p. 53

3.6 Intercomunicação de informação entre dois processos distintos. . . . . . . . . p. 56

3.7 Fluxograma - Etapas do processo para armazenamento do CSV. . . . . . . . . p. 58

3.8 Tomógrafos que suporta o envio de RDSR. . . . . . . . . . . . . . . . . . . . p. 59

3.9 Conexão DICOM mal sucedida. . . . . . . . . . . . . . . . . . . . . . . . . p. 60

3.10 Fluxograma de execuçao da ferramenta cycRDSR. . . . . . . . . . . . . . . p. 61

3.11 Integração do cycRDSR no Sistema Catarinense de Telemedicina. . . . . . . p. 63

3.12 Possível campo para exibir as informações de dosimetria na janela de exame. p. 64

3.13 Análise entre protocolos utilizados em diferentes instituições. . . . . . . . . . p. 65

B.1 CTDIvol mensurado com dosímetros nos phantom em comparação com o

valor exibido no aparelho. . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 78

B.2 Conversão entre medidas AP e LAT. . . . . . . . . . . . . . . . . . . . . . . p. 79

B.3 Exemplo de mensuracao de AP e LAT. . . . . . . . . . . . . . . . . . . . . . p. 80

Lista de Tabelas

1.1 Tabela de comparação entre radiação de exames médicos e a radiação natural p. 15

A.1 Tabela com o conteúdo de um arquivo de TC - (CT IOD) . . . . . . . . . . . p. 73

A.2 Tabela com os campos referentes ao IOM - GENERAL . . . . . . . . . . . . p. 74

A.3 Tabela com os campos referentes ao IOM - STUDY . . . . . . . . . . . . . . p. 74

A.4 Tabela com os campos referentes ao IOM - SERIES . . . . . . . . . . . . . . p. 74

A.5 Tabela com os campos referentes ao IOM - EQUIPMENT . . . . . . . . . . p. 75

A.6 Tabela com os campos referentes ao IOM - PATIENT . . . . . . . . . . . . . p. 75

A.7 Tabela com os campos referentes ao IOM - CT IMAGE . . . . . . . . . . . . p. 76

13

1 Introdução

1.1 Contextualização

Existem diversas modalidades de exames médicos, diferenciando-se entre elas pelas re-

spectivas tecnologias e técnicas utilizadas. Dentre todas modalidades, há um sub-grupo que se

assemelham por compartilhar a utilização do raio-X para realizar captação da(s) imagem(ns),

como a Radiografia, a Mamografia, a Fluoroscopia e a Tomografia Computadorizada. Geral-

mente esses exames são utilizados para identificar fraturas de ossos, pneumonia, tumores, blo-

queios intestinais, pedra nos rins, problemas cardíacos, lesões do diafragma, etc; os benefícios

e vantagens da realização desses exames são imensos (FDA, 2009). Entretanto, não há como

ignorar que essa eficácia clínica e a popularização dos equipamentos estão resultando em um

grande aumento na solicitação e realização deste sub-grupo de exames, expondo cada vez mais

a população à radiação ionizante (JR et al., 2007).

Conforme (RADIATION, 2006), de maneira simplista, os raios-X são ondas eletromagnéti-

cas que transportam energia de um ponto a outro. Esse fenômeno do transporte é denominado

radiação. Exemplificando, essas ondas atravessam roupas, tecidos, orgãos; e a interação desta

energia presente na onda com o corpo humano poderá promover alterações físico químicas no

meio intracelular, a mensuração da energia depositada em um tecido biológico é chamada de

dose de radiação absorvida.

Em suma, a dose de radiação absorvida (efeito biológico) é mensurada em grays (Gy) ,

enquanto que a dose de radiação equivalente utiliza a unidade do Sistema Internacional de

Unidades (SI), isto é, em sievert (Sv) . Contudo, para os raios X e γ (Gama), 1 Gy é equivalente

a 1 Sv (BRENNER; HRICAK, 2010).

Apenas para deixar mais didático o processo de compreensão deste trabalho, segue abaixo

um simples infográfico presente em uma reportagem do jornal "Folha de S.Paulo", datada de

25/06/2011, sobre como a radiação é utilizada para gerar imagens do interior do paciente atrav-

essa as células do corpo, e dependendo da intensidade e do tempo de exposição, podem ou não

14

danificar estas células. Como se poder visualizar na figura 1.1 (FOLHA, 2011).

Figura 1.1: Célula após sofrer radiação.

Fonte:FOLHA. Médicos pedem menos tomografias para evitar radiação. 2011. Disponívelem:<http://www1.folha.uol.com.br/equilibrioesaude/934875-medicos-pedem-menos-tom ografias-para-evitar-radiacao.shtml>.

Um estudo realizado em 2009, estimou que 29.000 futuros cânceres (aproximadamente 2%

do total de cânceres diagnosticados anualmente nos Estados Unidos) poderiam ser relacionados

a realização de exames de Tomografia Computadorizada nos EUA em 2007 (GONZALEZ et

al., 2009).

Mesmo que não possa inferir o risco de câncer baseado na exposição à radiação, é altamente

importante considerar que deve haver a conscientização sobre o perigo associado à radiação

ionizante. Mesmo que o risco de adquirir câncer associado a um exame radiológico seja mais

baixo que o risco natural, é inaceitável fazer o paciente ter risco adicionado se isto não for

beneficiar o paciente (VERDUN et al., 2008).

Os efeitos da radiação podem ser categorizado em efeitos determinístico e estocásticos

(acumulativos). A probabilidade do efeito acumulativo em um paciente, pode ser prevista con-

hecendo o histórico de valores de dose de radiação. Este é o principal motivo para haver um

histórico dose de radiação para cada paciente (MILLER et al., 2004).

Conforme (HUDA; METTLER, 2011), a média de radiação médica de dose efetiva (DE)

entregue a população americana em 2006 foi de aproximadamente 3.0mSv, um aumento de

600% em uma única geração. E a perspecitva é de que os exames de CT continuaram sendo

o principal contribuinte. A comparação entre a radiação de natural de fundo e a radiação de

exames médicos pode ser visualizada na tabela 1.1.

15

Tabela 1.1: Tabela de comparação entre radiação de exames médicos e a radiação natural

Procedimento: Dose Efe-

tiva da

Radiação

Comparação

com a radi-

ação natural de

fundo:

Região Abdominal:

Tomografia Computadorizada (CT) - Abdômen 10 mSv 3 anos

Tomografia Computadorizada (CT) - Tronco 10 mSv 3 anos

Osso:

Radiografia da Extremidade 0.001 mSv Menos de 1 dia

Tórax:

Tomografia Computadorizada (CT) - Tórax 8 mSv 3 anos

Radiografia-Tórax 0.1 mSv 10 dias

Exame Feminino:

Mamografia 0.7 mSv 3 meses

Fonte: (FDA, 2009) apud RadiologyInfo.org; Courtesy: American College of Radiology andRadiological Society of North America

No Brasil, o órgão que faz adequações nas recomendações internacionais e as adotam para

regulamentar o uso da radiação, é a Comissão Nacional de Energia Nuclear (CNEN) . Em

setembro de 1973, a CNEN elaborou as Normas básicas de proteção radiológica, cuja atual-

ização mais recente é o documento NN-3.01, “Diretrizes básicas de proteção radiológica”, de

janeiro de 2005. Esta norma é uma tradução com adaptação da International Commission on

Radiological Protection (ICRP) Publicação 60 de 1990. A recomendação mais recente relativa

à proteção radiológica está na ICRP Publicação 103: The 2007 Recommendations of the In-

ternational Commission on Radiological Protection, a qual substituiu a ICRP Publicação 60 de

1990. Sendo que a ICRP é a comissão da Sociedade Internacional de Radiologia, a qual tem por

missão elaborar guias de proteção radiológica e estabelecer limites de exposição às radiações

ionizantes.(OKUNO, 2009).

Contudo, vale ressaltar que este documento do CNEN não estipula limites de doses para

pacientes nas exposições médicas. Isto é, não há um valor absoluto sobre a quantidade máxima

de dose que um paciente pode receber em um exame. Mas a Portaria 453/98 do Ministério da

Saúde/ANVISA , estabelece níveis de referência de radiodiagnóstico a serem seguidas. Espera-

se que, boas práticas e técnicas sejam utilizadas para que tais níveis não sejam ultrapassados

16

(OLIVEIRA; KHOURY, 2003).

Segundo (RON, 2003), o acesso ao histórico do paciente pode influenciar diretamente o

pedido de realização de novos exames. Pois em certos casos, esta informação irá auxiliar o

médico a chegar em um consenso sobre a exposição à radiação acumulada do paciente.

O conjunto de históricos sintetizará uma base de informações que terá um grande potencial a

ser explorado. No entanto, estas informações devem estar armazenadas de maneira padronizada.

Atualmente, há diversos padrões para manipulação, de informações clínicas, mas para radiolo-

gia digital, o principal padrão é o Digital Imaging Communications in Medicine (DICOM)

(AZEVEDO-MARQUES; SALOMÃO, 2009).

Com a finalidade de padronizar o armazenamento de informações médicas mais complexas,

no ano de 2000, o comitê DICOM definiu mais um formato de arquivo, o DICOM Struc-

tured Reporting (DICOM SR)(CLUNIE, 2000). Sendo que em 2008, foi lançado uma sub-

categoria de DICOM SR para armazenar dados de dosimetria, o Radiation Dose Structured

Report (RDSR).

Algumas informações de dose estão presentes nos cabeçalhos dos arquivos (imagens) DI-

COM. Dependendo do fabricante, modelo, versão do software; esses dados podem estar em

campos públicos e/ou em campos privados ou até mesmo omitidos. Além disso, esta infor-

mação está somente associada com a imagem deste arquivo, isto é, se as imagens forem apa-

gadas, consecutivamente estas informações também serão perdidas. E devido a esses proble-

mas, surgiu a necessidade de criar um padrão para armazenar, gerenciar, visualizar, transferir

estes dados. Em 2007, foi lançado como parte do padrão DICOM a primeira geração de RDSR,

inicialmente para armazenamento de informações referentes a procedimentos de fluoroscopia

(NEMA, 2012). Sendo que em 2008, já estava presente no padrão, estruturas similares para

suportar os dados de mamografia e Tomografia Computadorizada (TC). O RDSR é um objeto

DICOM que pode ser criado e gerenciado separadamente da criação e armazenamento das ima-

gens. Todos os dados presentes no RDSR, seguem um padrão e uma estrutura, ou seja, os dados

são armazenados em campos públicos ("conhecidos"), cada campo com seu respectivo identifi-

cador (TAG). Outro ponto relevante a ser destacado é que o RDSR é um arquivo independente,

mesmo se as imagens geradas durante a realização do exame forem descartadas, o RDSR irá

registrar os dados de radiação referente ao procedimento realizado.

Já o Sistema Catarinense de Telemedicina (STT/SC) , projeto realizado pelo grupo de

pesquisa INCOD da Universidade Federal de Santa Catarina, é um sistema estadual para ar-

mazenamento e visualização de exames. Um dos seus principais objetivos é fornecer o ar-

mazenamento de imagens DICOM advindas de aparelhos médicos conectados à Rede Catari-

17

nense de Telemedicina (RTCM). A RCTM conecta diferentes instituições de saúde, como hos-

pitais, postos de saúde, e outras unidades de saúde de cuidados básicos(WANGENHEIM et

al., 2010). Esse armazenamento de aquivos DICOM é feito através de um servidor de im-

agens médicas — o principal componente do Picture Archiving and Communication System

(PACS) —; no contexto do STT/SC, este servidor utiliza um software projetado e construído

pelo próprio grupo de pesquisa, tal software é o CyclopsDCMServer.

1.2 Problema

Atualmente a Rede Catarinense de Telemedicina (RCTM) não possui um registro sobre

as informações referentes a dose de radiação ionizante que cada paciente foi exposto ao ser

submetido a um exame médico. Destacando-se os seguintes entraves:

• o servidor PACS da RCTM não possui estrutura necessária para armazemanento e geren-

ciamento do RDSR;

• os dados de dose utilizam unidades e/ou padrões diferentes entre os fabricantes;

• antigos equipamentos não exportam valores de doses no arquivo DICOM, apenas exibe

os valores no monitor junto ao equipamento.

1.3 Justificativa

Conforme (APPLEGATE; THOMAS, 2011), ultimamente há um aumento da conscienti-

zação sobre o risco acumulativo da radiação ionizante em exames médicos. Com isso, tem

aumentado a discussão sobre a necessidade de haver um registro de dose de radiação. Um ex-

emplo prático disso, é uma lei que entrará em vigor no estado da California (USA), obrigando

o armazenamento das informações de radiação nos exames de TC. Mesmo não havendo uma

obrigatoriedade na legislação brasileira, é importante que o Sistema Catarinense de Telemedic-

ina esteja preparado para colaborar e participar desta evolução na coleta de informações sobre o

registro de doses de radiação. Segundo (IHE, 2012), o perfil do Integrating the Healthcare En-

terprise (IHE) define que armazenar os valores de dose entregue aos pacientes pode contribuir

para diversos segmentos:

• Para as instalações (clínicas/hospitais) que expõe os pacientes à radiação vai ser possível

monitorar esse registro de dose, e realizar a verificação das suas políticas, procedimentos

e realmente conferir se os protocolos são adequados e sendo seguido de forma adequada;

18

• Para os físicos médicos, o monitoramento do registro de dose podem auxiliá-los na com-

preensão de como as mudanças nas técnicas e protocolos afetam a dose de radiação e a

qualidade de imagem. Isto irá permitir eles manterem as doses dos paciente tão baixos

quanto razoavelmente alcançável (ALARA);

• Para os médicos dos pacientes, os dados fornecidos pelo monitoramento do registro de

dose podem ajudar a determinar — em consulta com o físico médico — se o benefício a

partir da informação do exame superam qualquer risco pequeno que pode ser associado

com a aquisição de imagem;

• Para as sociedade e as agências reguladoras, uma coleção de registro de dose pode ser

útil na definição ou revisão das diretrizes de dose radiação em exames médicos. Muitos

destes grupos têm expressado o desejo de estabelecer padrões de níveis de prática ou a

dose de referência com base em um entendimento quantitativo da prática atual, no entanto

que o encontraram dificuldade em coletar esses dados;

• Para os físicos, físicos médicos, tecnólogos; este tipo de dado pode ser vital para desen-

volver uma compreensão mais detalhada dos impactos da exposição à radiação sobre a

saúde.

1.4 Cenário de Aplicação

Apenas para exemplificar a utilização dos valores de dosimetria, segue abaixo dois cenários

de aplicação.

1.4.1 Cenário 1

Cada unidade de saúde, que faça parte do STT/SC e realiza exames de TC, vai poder analisar

e inferir novas informações de dosimetria. E consecutivamente, conseguir ter mais subsídios

para analisar e verificar suas políticas e protocolos de TC.

1.4.2 Cenário 2

Imaginando um paciente que no último ano teve a necessidade de realizar diversos exames

médicos, dentre eles algumas TC. Quando este paciente realizar uma nova consulta médica,

pode ser que seu médico sinta a necessidade de solicitar mais uma TC para prover o diagnóstico.

Então, este profissional de saúde, poderá através do resultado desse trabalho consultar os valores

19

de radiação no histórico do paciente. Com base nesses valores, o mesmo vai poder realizar uma

escolha mais coesa e correta e talvez cancelar a escolha de solicitar este exame de TC. E assim

solicitar que o paciente faça outro tipo de exame como a Ultrassonografia (US) ou Ressonância

Magnética (MR), desde que tal exame consiga ser suficiente para fornecer o diagnóstico.

1.5 Objetivos

1.5.1 Objetivos Gerais

Desenvolver as etapas necessárias para realizar a extração e armazenamento padronizado

das informações de dosimetria. Adaptar a estrura do STT/SC para armazenar essas informações,

como também, analisar uma abordagem de como essas informações poderiam ser integradas a

atual arquitetura e conjuntura do sistema.

1.5.2 Objetivos Específicos

• Obj.1. Desenvolver uma ferramenta, doravante denominada "Cyclops Radiation Dose",

capaz de extrair as informações de dosimetria de um exame — considerando um exame

como um conjunto de um ou mais arquivos que armazenam as imagens médicas —, e

manipular tais informações para convergir na geração de um único arquivo RDSR. Além

disso, de maneira paralela, criar um arquivo de texto para auxiliar um outro trabalho que

fará um pós-processamento nessas informações;

• Obj.2. Desenvolver novos serviços na Application Programming Interface (API) do servi-

dor PACS utilizado no STT/SC (Cyclops DCMServer) para prover o suporte à comuni-

cação e ao armazenamento de um RDSR;

• Obj.3. Realizar um estudo viabilidade da integração entre o Portal de Telemedicina e

Cyclops DCMServer com a ferramenta proposta "Cyclops Radiation Dose".

1.6 Resultados Esperados

Espera-se que após o término deste trabalho, exista uma ferramenta genérica extratora de

dados de dosimetria, que possa auxiliar no pós-processamento e análise dos protocolos em-

pregados em exames de TC, de uma instituição de saúde arbitrária. Além disso, que a infra-

estrutura do STT/SC esteja preparada para armazenar tais dados padronizados. E por fim, que

20

haja subsídios suficientes para direcionar esforços e modificações no STT/SC para que seja

possível utilizar os demais resultados deste trabalho.

1.7 Limitações do Trabalho

De acordo com (PINA et al., 2009), entre os métodos de diagnósticos por imagem que

utiliza radiação ionizante, a TC é o exame que proporciona maior dose para o paciente. Com

base nisso, este presente trabalho limitou seu escopo para atender o controle de radiação de TC.

Sendo assim, não são abordados os exames das seguintes modalidades: mamografia, radiografia

e fluoroscopia.

1.8 Estrutura do Trabalho

Este trabalho está estruturado na seguinte maneira:

• no capítulo 1 foi apresentado a Introdução do trabalho, a contextualização, a definição do

problema, a justificativa, os objetivos e os cenários de aplicação;

• no capítulo 2 será apresentado a Revisão Bibliográfica, subdivido em duas partes, a

primeira parte descrevendo os conceitos necessários para a compreensão do trabalho, isto

é, um resumo dos temas relevantes, como: DICOM, PACS, RDSR, TC, Radiação, entre

outros; e a segunda parte contendo a revisão sistemática e as respectivas explanações dos

artigos correlatos ao presente trabalho;

• no capítulo 3 será apresentado o Desenvolvimento, detalhando as etapas da para realiza-

ção dos objetivos. Ou seja, desde da arquitetura da ferramenta extratora dos dados de

dosimetria, as etapas e processos envolvidos, e a integração com outros sistemas;

• no capítulo 4 será apresentado a conclusão, descrevendo uma discussão sobre a eficácia

da ferramenta extratora dos dados, os processo de uniformização dos dados, além disso,

os resultados da análise sobre o processo de integração da aplicação no STT;

• no capítulo 5, será apresentado a discussão sobre possíveis Trabalhos Futuros.

21

2 Revisão Bibliográfica

Este capítulo apresenta a seção de fundamentação teórica necessária para a compreensão

do presente trabalho. Para que seja compreensível certas etapas e processos de implementação

discutida no próximo capítulo, há uma ênfase na diferenciação dos tipos de tomógrafos, for-

mas de mensurar os valores de dosimetria, a codificação interna dos arquivos de tomografia, a

forma de comunicação realizada no protocolo DICOM. Sendo que no final deste capitulo, há a

apresentação da revisão sistemática proposta em (KITCHENHAM, 2004).

2.1 Conceitos Fundamentais

2.1.1 Sistema Catarinense de Telemedicina

O Sistema Catarinense de Telemedicina (STT/SC), é um projeto desenvolvido e mantido

pelo grupo INCOD da UFSC. De acordo com (MACEDO et al., 2008), o sistema é constituído

por um conjunto de serviços para auxílio a saúde. Como pode ser observado na figura 2.1.

22

Figura 2.1: Visão Geral do Sistema Catarinense de Telemedicina.

Neste modelo de telemedicina adotado, os hospitais dos municípios, realizam os exames

nos pacientes, tais como: eletrocardiogramas, hemodinâmicas, cintilografias, tomografias e

ressonâncias; e os envia para um banco de dados centralizado, no Hospital Universitário(MACEDO

et al., 2008).

Fornecendo resultados de mais de 45.000 exames mensais (média 2012) a 268 dos 293 mu-

nicípios catarinenses, conectando 300 instituições que realizam envio de exames a uma única in-

stância do servidor PACS CyclopsDICOMServer — outro serviço integrante da infra-estrutura

do STT/SC—, servidor de imagens médicas desenvolvido pelo mesmo grupo (NOBRE; WAN-

GENHEIM, 2010).

Cada instituição vinculada ao sistema possui uma "bridge"(um servidor que intermedeia a

conexão entre o equipamento e o sistema), essa fica responsável em receber, armazenar e dis-

tribuir as imagens enviadas pelo diferentes equipamentos presentes na instituição. A informação

é temporariamente armazenada na "bridge", assim reduzindo ataques externos e mantendo a a

segurança no processo de comunicação (WANGENHEIM et al., 2009) .

Um do serviços é o Portal de Telemedicina, uma ferramenta de interface para auxílio ao

trabalho dos profissionais de saúde, como pode ser visto na . Uma de suas funcionalidade é

a visualização de exames remotamente, possibilitando a realização de telediagnósticos direta-

mente pela internet (GIULIANO et al., ).

23

Figura 2.2: Página inicial Portal de Telemedicina.

2.1.2 Grandezas e Unidades Dosimétricas

As medições de radiação em tomografia computadorizada é um procedimento complexo,

pois as grandezas e as metodologias de dosimetria e os instrumentos de medição são diferentes

da radiologia convencional (BASTOS, 2006).

A padronização das grandezas usadas para a caracterização da radioatividade, quanto a

interação e efeitos, é feito pela Comissão Internacional de Unidades e Medidas de Radiação

(ICRU - International Commission on Radiation Units and Measurements); que define as grandezas

físicas básicas; e pela Comissão Internacional de Proteção Radiológica (ICRP - International

Commission on Radiological Protection); que é responsável pela definição das grandezas de

radioproteção (CASTRO, 2005).

De acordo com a (RECOMMENDATIONS, 1990), as três principais grandezas de proteção

recomendadas são:

• Dose Absorvida Média em um Órgão ou Tecido (DT);

• Dose Equivalente em um Órgão ou Tecido (HT,R);

• Dose Efetiva (E).

CTDI =1h

∫∞

−∞

D(z)dz

24

Dose Absorvida no Órgão - DT

A grandeza física básica é a dose absorvida, DT (MCCOLLOUGH et al., 2011). Sendo

a energia média depositada pela radiação ionizante em um um órgão ou tecido definido, T,

dividida pela massa daquele órgão, dada pela expressão,

DT =dedm

onde de é a energia média depositada pela radiação ionizante em um meio de massa dm.

A dose absorvida é expressa em J/kg no Sistema Internacional de Unidades e o nome espe-

cial para esta unidade é o gray (Gy). Sendo grays (1 Gy = 1 J/kg) ou rads (1 rad = 100 erg/g).

A conversão entre rads e grays é

100rad = 1Gy.

A dose absorvida não descreve onde a radiação foi absorvida, nem reflete a radiosensibili-

dade, ou o risco de detrimento causado nesses tecidos irradiados.

Conforme (DONNELLY et al., 2001), a estimativa é um processo na etapa na avaliação do

detrimento à saúde, relacionado à determinada prática, quais sejam:

• Efeitos determinísticos: dose absorvida nas regiões mais irradiadas, como por exemplo a

superfície do corpo;

• Efeitos estocásticos: a dose média absorvida em tecidos ou órgãos individualmente de

acordo com a ICRP 60.

Dose Equivalente

Como existe diferentes tipos de radiação, o resultado poderia ser diferente para uma mesma

dose absorvida. Sendo assim, foi necessário criar um conceito para comparar os efeitos devido

ao diferentes tipos de radiação. Algumas radiações são mais efetivas do que outras em causar

efeitos estocásticos. Por isso foi criado a grandeza dose equivalente HT, que é a dose absorvida

média em um órgão ou tecido, (DT,R), multiplicada por um fator de peso adimensional da

radiação, wR, relativo ao tipo e energia da radiação incidente R, ou seja:

HT = DT,R×wR

25

A dose equivalente é expressa em J/kg no Sistema Internacional de Unidades. Para evitar

confusão com a dose absorvida, a unidade para a dose equivalente recebe o nome especial de

sievert (Sv).

Os fatores de peso da radiação wR foram estipulados pela ICRP-60 com base nos valores

da Eficácia Biológica Relativa (RBE) da radiação na indução de efeitos estocásticos a baixas

doses. Como já supracitadao, no caso dos Raio-X e Gama, esse fator de conveersão é um. No

entanto, como esse termo aparecerá futuramente, era necessário exibir esta breve definição.

Dose Efetiva

Os valores de dose efetiva não são calculados ou simulados neste neste trabalho, mas para

efeitos de compreensão dos campos necessários na geração do arquivo RDSR, segue a diferen-

ciação entre este termo e os demais termos já citados acima.

Dose Efetiva, antigamente referenciada como Dose Equivalente, leva em consideração o

local onde a dose de radiação está sendo absorvida, isto é, qual tecido ou orgão está sendo

irradiado. E isto reflete nos resultados dos riscos estocáticos causados pela radiação em um

paciente de TC. O cálculo da dose efetiva é realizado com uma média ponderada referente a

cada orgão irradiado:

E = ∑wt.Ht

onde wT é o fator de peso do tecido T e HT é a dose equivalente a ele atribuída.

No Sistema Internacional de Unidades, a dose efetiva é expressa em J/kg, mas recebe o

nome especial de sievert (Sv). E a conversão entre rems e sievert é: 100 rem equivale 1 Sv.

Os valores de wT para os órgãos ou tecidos considerados para o cálculo da dose efetiva,

estipulados pela publicação no 60 da ICRP (ICRP, 1991),

2.1.3 PACS - Servidor Imagens Médicas

De acordo com (DELLANI, 2001), PACS (Picture Archiving and Communications Sys-

tem) são sistemas formados por aparelhos de diagnóstico médico — aparelhos que fornecem

imagens digitais, como CT, US e MR —, estações de trabalho para processamento das imagens

e servidores de armazenamento de imagens médicas digitais; todos interconectados. A função

do PACS é facilitar a visualização, impressão e outras operações com as imagens armazenadas

26

nos servidores.

O servidor de imagens médicas digitais é o principal componente do PACS. É neste servidor

que as imagens médicas digitais e informações relacionadas produzidas nos diversos aparelhos

de diagnóstico médico de um PACS são armazenadas (DELLANI, 2001).

Segundo (AZEVEDO-MARQUES; SALOMÃO, 2009), um sistema de arquivamento e co-

municação voltado para o diagnóstico por imagem que permite o pronto acesso às imagens

médicas em formato digital em qualquer setor de um hospital. O conceito de PACS foi definido

por um consórcio integrado pela American National Association of Electric Machines (NEMA),

Radiology Society of North America (RSNA) e um conjunto de empresas e universidades dos

Estados Unidos da América.

2.1.4 DICOM

Segundo (PIANYKH, 2011), o protocolo DICOM (Digital Imaging Communications in

Medicine) representa anos de esforços para criar padronizações universais na área de infor-

mação médica digital. Em linhas gerais, pode-se conceituar como um conjunto de definições

para haver um padrão na transferência e comunicação entre equipamentos médicos e computa-

dores; como também a padronização no armazenamento dessas informações digitais na área

médica, figura 2.3.

(a) Mapeamento do "mundo real"para o for-mato de um arquivo DICOM.

(b) Comunicação entre dois equipamentos uti-lização o padrão DICOM de comunicação.

Figura 2.3: Exemplos da utilização do padrão DICOM.

Fonte: (PIANYKH, 2011), página 8.

Conforme (DELLANI, 2001), atualmente o DICOM é o padrão de fato para PACS, sendo

suportado pela grande maioria dos aparelhos de imagens de diagnóstico médico. O fato de um

aparelho suportar o protocolo DICOM, garante que este equipamento possa ser integrado em

um PACS já existente, Sua abrangência no PACS vai desde a codificação dos dados das ima-

gens, a definição de diversas classes de serviços, como armazenamento, recuperação, pesquisa

27

e impressão de imagens, formatos utilizados no armazenamento das imagens em meios re-

movíveis, processos de negociação de associações para a transmissão dos dados das imagens

através de redes, etc. O padrão DICOM define essas regras sobre a hierarquia dos objetos DI-

COM, a forma como os arquivos devem ser armazenados, como deve ocorrer a comunicação

entre equipamentos, etc; através de um conjunto de documentos do NEMA. Segundo (NEMA,

2011a), estes documentos estão separados pelos diferentes assuntos que cada um aborda. No

total são dezesseis documentos, totalizando mais de 10.000 páginas. Esses arquivos continuam

em crescente desenvolvimento, isto é, o processo de adições ao padrão é contínuo, Supplements

e Change Proposals são publicados no DICOM website desde a última versão (2011). Segue

abaixo a lista de arquivos da última versão:

• PS 3.1 - Introduction and Overview: breve introdução ao padrão DICOM e ao conteúdos

dos demais documentos;

• PS 3.2 - Conformance: define os princípios para todas as implementações que desejam

estar em conformidade com o padrão DICOM;

• PS 3.3 - Information Object Definitions: descreve como os objetos de informação são

construídos (IOD, IOM, Datasets);

• PS 3.4 - Service Class Specifications: contém a especificação das Classes de Serviço

(SOPClass);

• PS 3.5 - Data Structures and Encoding: especifica o método de codificação e decodifi-

cação respectivamente ao realizar a transmissão e a recepção dos dados;

• PS 3.6 - Data Dictionary: uma lista com todas as TAG correspondentes aos atributos dos

objetos de informação que fazem parte do padrão;

• PS 3.7 - Message Exchange: descreve os serviços DICOM comumente referenciados

como DIMSE-C e DIMSE-N;

• PS 3.8 - Network Communication Support for Message Exchange: especifica o processo

de negociação de associação (handshake), protocolos da camada superior, transporte dos

dados.

• PS 3.9 - Point to Point Communication Support for Message Exchange: especifica a uti-

lização do padrão DICOM sobre conexões ponto-a-ponto;

• PS 3.10 - Media Storage and File Format for Media Exchange;

28

• PS 3.11 - Media Storage Application Profiles;

• PS 3.12 - Media Formats and Physical Media for Media Interchange:

• PS 3.13 - Print Management Point-to-Point Communication Support:

• PS 3.14 - Grayscale Standard Display Function;

• PS 3.15 - Security Profiles;

• PS 3.16 - Content Mapping Resource;

• PS 3.17 - Explanatory Information;

• PS 3.18 - Web Access to DICOM Persistent Objects (WADO).

Neste presente trabalho, são utilizados somente três documentos, sendo eles: PS-3.3 2011,

PS-3.6 2011 e PS-3.16 2011.

Histórico

Apenas contextualizando o histórico do padrão, este foi desenvolvido de maneira conjunta

entre a comunidade científica e os fabricantes de equipamentos médicos — relacionados com

a geração das imagens médicas. Em 1983, o Colégio Americano de Radiologia (American

College of Radiology - ACR) e a Associação Nacional dos Fabricantes de Produtos Elétri-

cos (National Electrical Manufacturers Association - NEMA), decidiram se unir para criar um

padrão capaz de possibilitar a transferência de imagens e troca de informações independente do

fabricante do equipamento. E so ano de 1985 o padrão ACR-NEMA — antiga nomenclatura

do padrão — foi publicado em sua versão 1.0, sendo a primeira que aceitava a realização da

comunicação de dados sem utilizar uma forma proprietária vinculada a algum fabricante. A

versão 1.0 foi substituída pela versão 2.0 em 1988, essa versão incluía as principais definições

independente da terminologia, estrutura de dados e codificação. Só no ano de 1993, foi apre-

sentada a versão 3.0, denominada Digital Imaging and Communications in Medicine (DICOM),

nessa versão foi adicionado o uso do protocolo TCP/IP para possibilitar a comunicação inde-

pendente do fabricante do equipamento. A estrutura de dados também foi alterada para suportar

um modelo que comporta identificadores únicos para serviços e objetos como imagens, dados

de pacientes, formato wave ou laudos estruturados (BIDGOOD; HORII, 1992).

29

Hierarquia da Informação

Independente do armazenamento em arquivo, o padrão DICOM define uma hierarquia do

objeto paciente no contexto DICOM, como pode ser visto na figura 2.4. Sendo que um paciente

pode possuir um ou mais estudos — nesse contexto, estudo seria um exame de TC. E cada

exame pode possuir uma ou mais séries — sendo que esta, é um conjuntos de imagens com

características em comum, e.g, Série de imagens do Tórax com contraste. E por fim cada série

pode possuir uma ou mais instâncias, sendo estas imagens ou objetos DICOM SR (PIANYKH,

2011 apud JUNIOR, 2012, p. 35).

Figura 2.4: Hierarquia da informação no contexto DICOM.

Fonte: (NEMA, 2011b apud JUNIOR, 2012)

Classe de Serviços - Service-Object Pair(SOP)

O SOP Class é definido com um conjunto identificador de Information Object Definition

(IOD) and a DICOM Service Elements (DIMSE). As definições dos SOP Class contém regras

semânticas que delimita e descreve o uso de serviços no DIMSE ou atributos do IOD. Exemplo

de elementos de serviços: Store, Get, Find, Move, etc. Examples of Objects are CT images,

MR images, but also include schedule lists, print queues, etc.

O Objeto DICOM

Na figura 2.5, pode-se ter uma visão genérica de como funciona internamente o armazena-

mento de arquivos DICOM, sejam eles resultantes dos exames de tomografia computadorizada,

ultra-sonografia, ressonância magnética, mamografia, radiografia, entre outras modalidades; o

30

arquivo possui a imagem (matriz de pixel) e mais um conjunto de campos, doravante DICOM

HEADERS, que contém as informações do exame, do paciente, do equipamento, da imagem,

entre outras.

Figura 2.5: Estrutura interna de um arquivo DICOM.

Fonte: (PIANYKH, 2011). Página 242.

Conforme (NEMA, 2011b), a estrutura interna é diretamente relacionada a classe de arquivo

que está sendo armazenada. doravante SOPClass. Devido o contexto deste trabalho, segue

abaixo apenas como é internamente um arquivo de SOPClass CT Image Storage. O padrão

DICOM define os Information Object Definition (IOD), que possui seus respectivos módulos,

estes por sua vez denominados Information Object Module (IOM). No apêndice A é descrito

o IOD de TC, isto é, o conjunto de módulos e respectivos campos que compõem cada arquivo

resultado de um exame de TC.

E cada IOM é constituído por um conjunto de data element obrigatórios e opcionais que são

identificados unicamente no padrão e agrupados de acordo com similaridade. Dessa maneira,

cada data element, é identificado pelo grupo (G) ao qual pertence e o elemento dentro desse

grupo (E), resultando assim em um identificador seguindo o formato hexadecimal (0xGGGG,

0xEEEE), por exemplo, o identificador (0010, 0010) é mapeado para o nome do paciente

(PRADO, 2012 apud NEMA, 2011b).

31

Figura 2.6: Abstração do conjunto de elementos ordenados crescentemente pelas respectivasTAG.

Fonte: (NEMA, 2011c).

Como supracitado, o padrão DICOM define diversos serviços, no entanto, um equipa-

mento e/ou software não necessita implementar todos esses serviços. Sendo assim, para saber

quais sao os servicos atendidos, os fabricantes de equipamentos e/ou software produzem doc-

umentos chamados Conformance Statements. Estes contém exatamente todas as informações

necessárias como os tipos de modalidades que são suportadas, sintaxes de transferência de da-

dos, serviços que podem requisitar ou serem requisitados e quais possíveis extensões estão

disponíveis.(PRADO, 2012).

Comunicação

Além de definir o formato dos arquivos de imagens médicas, o grupo DICOM também de-

fine um protoloco de comunicação se baseando em padrões já existentes. Há um conjunto de

documentos que abordam somente este processo, porém, de maneira sucinta, pode-se dizer que

há diversas classes de serviço definidas através de serviços chamados DIMSE (DICOM Mes-

sage Service Element). Estes serviços são encapsulados na camada de aplicação — tendo como

referência as camadas OSI —, a qual se encontra sobre a camada de transporte. O protocolo

de transporte escolhido pelo comitê foi o TCP (Transfer Control Protocol), pois de acordo com

a sua definição, este protocolo fornece um canal de comunição confiável que assegura que os

dados transferidos cheguem ao destino (PRADO, 2012).

Ainda de acordo com (NEMA, 2011b apud PRADO, 2012), os elementos que se comuni-

32

cam através do protocolo DICOM são denominados entidades de aplicação Application Entity

(AE).

No documento que descreve das regras referentes as classes de serviços (NEMA, 2011c),

está definido as regras que devem ser estabelecidas durante a comunicação de duas entidades.

A entidade que provê os serviços é denominada SCP (Service Class Provider), enquanto que a

entidade que requisita o serviço é chamado de SCU (Service Class User).

A relação de fluxo normal entre duas entidades ocorre em três etapas, conforme ilustrado

na figura 2.7. Conforme será abordado durante o desenvolvimento, no início da comuni-

cação são verificados quais operações podem ser executadas e quais serviços (SOPClass) estão

disponíveis.

Figura 2.7: Processo alto nível para comunicação DICOM.

Fonte: (NEMA, 2011c). Adaptado e traduzido.

33

2.1.5 Tecnologia de OCR - Optical character recognition

Conforme (HIRAYAMA et al., 2011), a grosso modo, a tecnologia de OCR (Optical char-

acter recognition) são ferramentas e/ou técnicas que conseguem converter diferentes tipos de

documentos, como papéis escaneados e imagens; para um um arquivo de dados editável. Isto

é, um software de OCR consegue "ler"uma imagem e separar as letras da imagem, colocandos

em palavras, e permitindo trabalhar e utilizar os dados que estavam "impressos"na imagem.

Um exemplo disso é a extração dos valores contidos em alguns Dose Sheet. Como pode ser

visto na figura 2.8

(a) Imagem Dose Sheet. (b) Informações extraídas no formato texto.

Figura 2.8: Exemplo do processo de extração de dados através de OCR.

2.2 Revisão Sistemática

Como já supracitado, a revisão foi realizada utilizando o método da Revisão Sistemática da

Literatura (RSL) descrito em (KITCHENHAM, 2004). Segundo esse documento, é necessário

estabelecer critérios imutáveis de pesquisa com o intuito de identificar, avaliar e compreender

toda literatura relevante de um dado tema. De certa forma, acaba sendo o processo de realizar

uma série de etapas para tornar a pesquisa reprodutível. E neste trabalho, a revisão sistemática

tem como foco como realizar o controle de dose radiaçao, sendo as sub-áreas, extração e ar-

mazenamento de dados de dosimetria referentes a exames de TC.

2.2.1 Questão de Pesquisa

A pesquisa deste trabalho foi realizada para obter os estudos relacionados com o controle

de radiação, principalmente os que possuam relação com o processo de extração dos dados

34

de dosimetria e/ou a maneira como é realizada o armazenamento destas informações em um

ambiente PACS.

As questões de pesquisa foram:

Q1. Quais as abordagem existentes para extrair a dose de radiação nos exames de TC?

Q2. Quais as maneiras existentes para armazenar estes dados de maneira padronizada?

2.2.2 Definições da bases de dados e termos de pesquisa

Os motores de busca escolhidos para realizar as pesquisas com as palavras-chave referentes

as questões da pesquisa são:

• ACM Digital Library

• IEEExplore

• Science Direct

• Pubmed

• American Journal of Physical Medicine & Rehabilitation

• Radiology RSNA

• Oxford Journals

As pesquisas — quando foi possível filtrar pelo critério de data — realizadas cobriram os

trabalhos publicados de 2006 até o primeiro semestre de 2012. Mesmo que o principal enfoque

foi sobre a utilizaçã do RDSR, o qual foi lançado em 2009, também se tentou verificar os

trabalhos que de certa forma geram um documento estruturado não padronizado. Os termos tem

correlação diretamente com as questões de pesquisa. Nos motores de busca que não possuiam

busca avançada, tentou-se colocar o termo mais genérico. Concomitantemente, a pesquisa foi

delimitada somente ao título, abstract e palavras-chave. Sendo que os portais de pesquisa da

ACM Digital Library, IEEEXplore e ScienceDirect foram utilizados inicialmente. No entanto,

não foi encontrado um conjunto significativo de artigos correlatos. Por isso, houve uma nova

pesquisa envolvendo outros portais como: Pubmed, American Journal of Physical Medicine &

Rehabilitation, Radiology RSNA e Oxford Journals. E de maneira complementar, há um artigo

que iria ser apresentado no SIIM2012 — encontro anual da Society for Imaging Informatics

35

in Medicine realizado em 2012 —, e que havia de ser incluído para corroborar a expansão e

complitude do tema, haja vista que este artigo possui informação mais atualizada.

Segue abaixo cada pesquisa e a respectiva quantidade de estudos encontrados:

IEEEXplore 210 resultados

( " D i a g n o s t i c Imaging " OR " Rad io logy " OR " Medica l Imaging "

OR "X−Ray " OR " Tomography " OR "CT E x a m i n a t i o n s " )

AND ( " Dose " OR " R a d i a t i o n " OR( " R a d i a t i o n "

AND ( " Dose T r a c k i n g " OR " M o n i t o r i n g " OR " C o n t r o l "

OR " Dose " OR " Dosage " OR " R e g i s t e r " OR " H i s t o r y "

OR " Dose E x t r a c t i o n " OR " Rep or t " ) ) ) OR " Dose Index

R e g i s t r y " OR " Dos imet ry " OR " Dose Records "

OR " Dose E x t r a c t i o n " " Dose r e g i s t r i e s "

OR " R a d i a t i o n S t r u c t u r e d Rep or t " OR "RDSR"

Science Direct 118 resultados

pub−d a t e > 2006 and t i t l e ( ( " D i a g n o s t i c Imaging "

OR " Rad io logy " OR " Medica l Imaging "

OR "X−Ray " OR " Tomography " OR "CT " )

AND ( " R a d i a t i o n " AND ( " Dose " OR " Dose T r a c k i n g "

OR " M o n i t o r i n g " OR " C o n t r o l " OR " R e g i s t e r "

OR " H i s t o r y " OR " Dose E x t r a c t i o n "

OR " R ep or t " ) ) OR " Dose Index R e g i s t r y " ,

OR " Dose Records " OR " D o s e c E x t r a c t i o n "

OR " Dose r e g i s t r i e s " OR " R a d i a t i o n S t r u c t u r e d Re por t "

OR "RDSR" ) [ J o u r n a l s ( Computer Sc ience , Medic ine and D e n t i s t r y ) ]

ACM 49 resultados

( ( T i t l e : D i a g n o s t i c ) AND ( T i t l e : Imaging ) )

OR ( T i t l e : Rad io logy ) OR ( ( T i t l e : Medica l )

AND ( T i t l e : Imaging ) ) OR ( T i t l e :X−Ray )

OR ( T i t l e : Tomography ) OR ( T i t l e : CT ) )

AND ( ( A b s t r a c t : Dose ) OR ( A b s t r a c t : R a d i a t i o n )

36

OR( ( A b s t r a c t : R a d i a t i o n ) AND ( ( ( A b s t r a c t : Dose )

AND ( A b s t r a c t : T r a c k i n g ) ) OR ( A b s t r a c t : M o n i t o r i n g )

OR ( A b s t r a c t : C o n t r o l ) OR ( A b s t r a c t : Dose )

OR ( A b s t r a c t : Dosage ) OR ( A b s t r a c t : R e g i s t e r )

OR ( A b s t r a c t : H i s t o r y ) OR ( A b s t r a c t : Dose E x t r a c t i o n )

OR ( A b s t r a c t : Rep o r t ) ) ) ) OR ( ( ( T i t l e : Dose )

AND ( T i t l e : Index ) AND ( T i t l e : R e g i s t r y ) )

OR ( T i t l e : Dos ime t ry ) OR ( ( T i t l e : R a d i a t i o n )

AND ( T i t l e : S t r u c t u r e d ) AND ( T i t l e : Re po r t ) ) )

OR ( Keywords :RDSR)

Pubmed 403 resultados

R a d i a t i o n Dose [ T i t l e ] AND CT[ T i t l e ]

American Journal of Physical Medicine & Rehabilitation 33 Resultados

R a d i a t i o n Dose

Radiology RSNA 108 resultados

R a d i a t i o n Dose ( a s p h r a s e ) i n t i t l e .

Oxford Journals - Radiation Protection Dosimetry 102 resultados

R a d i a t i o n Dose ( a s p h r a s e ) i n t i t l e

2.2.3 Critérios de Inclusão e Exclusão

Foram incluídos artigos escritos na língua vernácula ou língua inglesa relacionados com a

extração, ou o armazenamento ou o uso do padrão DICOM SR para arquivar dados de dosime-

tria. Foi levado em consideração artigos de conferências ou publicados em journals. Sendo

que estes artigos não necessariamente precisam estar indexados por algum motor de busca. A

primeira forma de de realizar o filtro dos resultados, foi partir para a leitura somente do título.

Quando percebido correlação, era realizado a leitura do abstract do artigo. Com isso, houve a

seleção de doze artigos. E como etapa posterior, foi realizado a leitura completa de cada um

desses artigos.

37

2.2.4 Seleção dos Estudos

Como alguns portais de busca possuiam a limitação de não possuir busca avançada, em

alguns casos foi necessário incluir o termo mais genérico para não deixar algum artigo excluso

de maneira despercebida. Sendo assim, a pesquisa retornou mais 700 artigos. Dentre estes

artigos, 5 foram selecionados como importantes para a pesquisa. Houve casos que dois artigos

pelos mesmos autores referenciam a mesma abordagem, como foi o caso de (COOK et al.,

2010) e (COOK et al., 2011). Nesse caso somente um dos artigos foi selecionado.

2.2.5 Extração dos Dados

Os dados foram dispostos na forma de tabela de forma sumarizada para análise dos estudos

selecionados durante a condução da revisão sistemática.

Para cada um dos artigos aprovados, foram extraídas as seguintes informações:

Referência. Referência do estudo;

Técnica. Se a técnica de extração é baseada na leitura do Dose Sheet com o uso de de OCR;

ou se apenas é lido diretamente do Dicom Header quando presentes, e como foram com-

plementadas quando houve necessidade;

Dose Efetiva. Se há a geração do valores de dose efetiva;

Geração de RDSR. Se utiliza o padrão DICOM RDSR para armazenamanto destes dados.

A tabela 2.2.5 exibe estas informações de maneira agrupada e mais clara de compreender.

Autores (Ano) Título Técnica DoseEfetiva RDSR

SHIH et al. Automated Framework for

Digital Radiation Dose In-

dex Reporting From CT

Dose Reports

DoseSheet

OCR

Sim -

JAHNEN et al. Automatic Computed

Tomography Patient

Dose Calculation Using

DICOM Header Metadata

Dicom

Header

(CT-EXpo)

- -

COOK et al. RADIANCE: An Auto-

mated, Enterprisewide So-

lution for Archiving and

Reporting CT Radiation

Dose Estimates1

DoseSheet

OCR

Sim Sim

38

Autores (Ano) Título Técnica DoseEfetiva RDSR

LI; ZHANG; LIU Automated Extraction of

Radiation Dose Informa-

tion From CT Dose Report

Images

DoseSheet

OCR

- -

SODICKSON et al. Automated Body Size

Extraction Using Axial

CT Images to Calcu-

late Water-Equivalent

Diameter

DoseSheet

OCR

- Sim

2.2.6 Detalhamento dos Trabalhos Relacionados

Nesses últimos 2 anos, foram desenvolvidos algumas soluções para prover uma ferramenta

que auxilie na geração de registros de dose de radiação.

Em 2011, um grupo de trabalho (SHIH et al., 2011) descreveu sobre o desenvolvimento

de uma ferramenta para TC, doravante DIRA (Dose Index Reporting Application), capaz de

extrair informações de radiação, dentre elas o maior foco, o CTDI. E como resultado, ter a

possibilidade de automatizar o controle de qualidade, promover a conscientização de proteção,

e sintetizar um registro de cada paciente, podendo correlacionar seu respectivo nível de saúde

com a exposição(oes) já sofrida(s). Um fato a ser destacado, é que a extração ocorre analisando

o Dose Sheet presente em cada exame, e foi utilizado apenas Dose Sheet que não contém in-

formações digitais, isto é, sendo necessário fazer o uso de OCR. O processo para extrair as

informações está descrito abaixo, na figura 2.9.

Figura 2.9: Diagrama exibindo o processo automatizado realizado pela aplicação DIRA.

Fonte: (SHIH et al., 2011). Página 1172.

De maneira geral, na primeira etapa, o PACS envia o DoseSheet — referenciado pelos

autores como CT dose report — através de um DICOM C-STORE à aplicação DIRA, e o

RIS realiza o envio do peso e altura através de HL7. Na segunda etapa, a aplicação executa

um processo de extrair os valores presentes no DoseSheet. Na terceira etapa, é realizado o

processo de inferir o valores de dose do paciente, pois o valor de dose obtido na etapa an-

terior (Manufacturer-generated CTDI) é altamente dependente ao tamanho do Phantom, não

refletindo exatamente o tamanho do paciente. Isto é feito em duas sub-etapas, primeiramente é

39

correlacionado tamanho e peso do paciente com uma tabela de CTDI/Phantom. Além disso, se

o exame for um CT abdominal, há a mensuração das dimensões anteroposterior (AP) e e lateral

(LAT). Na última etapa, as informações extraídas são armazenadas em um banco de dados para

correlações futuras, como por exemplo, dose efetiva.

Figura 2.10: Gráfico exibindo a relação das medidas de CTDIvol e o tamanho do Phantom.Exames realizados em um aparelho 16-MDCT (Sensation, Siemens Healthcare).

Fonte: (SHIH et al., 2011). Página 1173.

Os resultados obtidos foram satisfatórios, a aplicação conseguiu 100% de êxito ao ler os

518 dos 518 Dose Sheets testados. Além disso, a ferramenta se apresentou genérica o suficiente

para extrair informações de exames que não possuem dados no DICOM Header e DICOM SR.

No entanto, esta aplicação acaba sendo um pouco dependente da implementação RIS que deve

fornecer os dados de altura e peso, haja vista que tais informações podem não estar presentes

no PACS.

Em 2011, um outro grupo de trabalho (COOK et al., 2011) também descreveu sobre o

desenvolvimento de uma ferramenta mais completa para TC, doravante RADIANCE (Radiation

Dose Intelligent Analytics for CT Examinations). Devido o fato deste trabalho ser o trabalho

mais similar com o presente trabalho, será abordado com mais enfase todas as etapas.

Esta ferramenta é capaz de extrair informações de radiação, similar ao trabalho descrito an-

teriormente. No entanto, com anuâncias que os diferem. Os autores projetaram uma ferramenta

open-source que extrai informações de diferentes DoseSheets, sejam eles da Philips, Toshiba,

Siemens, GE ou NeuroLogica; e com base nos valores extraídos gera um arquivo RDSR e faz a

indexação das informações em um banco de dados para futuras análises. O processo geral para

extrair as informações está descrito na figura abaixo, 2.11.

40

Figura 2.11: Diagrama exibindo o processo automatizado realizado pela aplicação RADI-ANCE.

Fonte: (COOK et al., 2010).

Resumindo, a primeira etapa é referente ao procedimento da aplicação se conectar ao PACS

para buscar o DoseSheet (DICOM) de um dado exame. Após a aquisição do arquivo, é realizado

com o auxílio de uma ferramenta OCR, a conversão do DoseSheet (JPG) para um arquivo texto

American Standard Code for Information (ASCII). E utilizando outra ferramenta, o DCMTK,

para gerar um arquivo XML contendo o valor do cabeçalho do DoseSheet (DICOM). Desta-

cando o problema que ocorre ao obter o DoseSheet, alguns fabricantes usam um único Series

Number para identificar o DoseSheet, como por exemplo, série 501 para o Siemens Medical

Systems, série 999 para GE Medical Systems, e o mais recente, série 9000 para o Toshiba Med-

ical Systems. Nenhum DoseSheet gerado pela Philips Medical Systems ou Toshiba antes de

2009 são numerados. Já na segunda etapa, ocorre o processo de realizar a leitura e análise das

saídas geradas na etapa anterior. A análise do conteúdo ASCII, é feita de acordo com o fab-

ricante do tomógrafo responsável pelo exame, como se pode observar na figura 2.12, os Dose

Sheet de cada fabricante tem diferenças de posicionamento, conteúdo, tamanho dos caracteres,

tipografia, etc; As informações extraídas são: kilovoltage, x-ray tube milliamperes, reference

milliamperes, CTDIvol, e DLP. Ainda nesta mesma etapa, de maneira concomitante, também

ocorre a leitura do arquivo XML, extraindo valores como data do exame, código do exame

(examination code), descrição (study description), fabricante e modelo do equipamento, insti-

tuição, identificação e data de nascimento do paciente.

41

Figura 2.12: Imagem exibindo a diferença entre os DoseSheets de cada fabricante. (A): Philips;(B): Toshiba; (C): Siemens.

Figura adapatada com base em (COOK et al., 2010) e (COOK et al., 2011).

Na terceira etapa, os dados adquiridos na etapa anterior são armazenados em um banco de

dados relacional. Mas antes deste armazenamento, é necessário fazer certas correções em erros

intrínsecos ao processo da utilizado pela específica ferramenta de OCR. Como por exemplo,

trocar valores como "0I20"para "0120", haja vista que erroneamente foi adicionado um caracter

"I"no lugar do "1". Ainda nesta etapa, também é estimado novos dados, como o valor de dose

efetiva, isto é realizado multiplicando o o valor total de DLP por um fator k — definido no

documento 60 da International Commission on Radiologic Protection — dependente da região

do corpo que foi realizado o exame.

E o último processo dessa etapa é gerar um arquivo RDSR para o exame. Isto é realizado

utilizando um pacote JAVA, o PixelMed DICOM Toolkit. O RADIANCE preenche um doc-

umento com base nos valores armazenados no banco e gera um automaticamente o RDSR e

o envia para o ACR DIR. Esta automatização do processo elimina a etapa de entrada manual

de dados agilizando o processo. O conteúdo de outros arquivos RDSR também poderiam ser

importados para o banco de dados, dando a possibilidade coexistir dentro do sistema, tanto os

tomógrafos que exportam RDSR como os que não exportam.

Sobre o processo de indexação, foi utilizado a terceira forma normal para normalização dos

dados, consecutivamente havendo diversas separações de entidades que se relacionam. Como

por exemplo, a separação por Paciente (Pacient), que possibilitará um histórico individual por

paciente. Segue abaixo na figura 2.13 o esquema do banco de dados.

Já a última etapa é referente ao pós-processamento, que seria a etapa de análise aos dados

extraídos e inferidos nas etapas anteriores.

42

Figura 2.13: RADIANCE - esquema do banco de dados.

Fonte: (COOK et al., 2011).

Com base nos dados, pôde ser feita diversas análises dos dados de dosimetria de TC. Como

verificar o nível de radiação associado a cada tomógrafo para o mesmo protocolo de aquisição,

figura 2.14. Os valores de dose de radiação são de grande importância para melhorar o processo

de aquisiçaõ de imagens. Podendo comparar os níveis de radiação dos exames realizados com

os níveis de referência presentes na literatura.

Figura 2.14: RADIANCE - análise de exames por tomógrafo.

Fonte: (COOK et al., 2011).

Um outro trabalho publicado no ano de 2011, (JAHNEN et al., 2011), com parceria do min-

istério da saúde de Luxemburgo, também relatou o desenvolvimento de uma ferramenta para

extrair dados de dosimetria de TC. No entanto, o principal objetivo era auxiliar no controle

43

nacional de níveis de referência (DRLs - Diagnostic Reference Level. Este sistema, doravante

PERMOS (Performance and Monitoring Server), baseia-se numa abordagem híbrida, fazendo

a extração de alguns dados contidos no cabeçalho DICOM, e utiliza-se desses dados para ali-

mentar outros sofwares, como por exemplo: CT-EXPO, ImpactDose e CT Dose; para conseguir

atingir o objetivo de estimar a dose do paciente.

Assim como os demais trabalhos já citados, o processo de funcionamento do PerMos é

baseado em 3 etapas, mais precisamente três etapas: Aquisição dos Metadados (DICOM Head-

ers), Processamento dos Dados e Estimação dos Dados e Representação. Apenas para elucidar

como estas etapas se comportam, na figura 2.16 é possível analisar a interação entre estas etapas.

Figura 2.15: Diagrama do processo automatizado realizado pela aplicação PERMOSS.

Fonte: (JAHNEN et al., 2011).

Na etapa de Aquisição dos metadados, os usuários do sistema devem realizar o envio das

imagens para a aplicação, isto pode ser feito através de um DICOM C-STORE através do

PACS, ou a própria aplicação buscar o exame desejado através de uma pesquisa sucedida de

um DICOM C-GET. Assim que as imagens são recebidas, é verificado se as imagens são da

modalidade CT, as imagens são anonimizadas, e os metadados são extraídos e as imagens são

deletadas.

A segunda etapa consiste em processar os dados, primeiro tem que harmonizar as infor-

mações, pois mesmo que o padrão DICOM defina campos bem delimitados para armazenar

as informações, talvez por razões históricas, há fabricantes e modelos que diferem onde ar-

mazenam algumas informações. Como por exemplo, o campo Table Feed é armazenado na

DICOM Tag (0x01F1,1028) por um fabricante, enquanto outro fabricante armazena no campo

(0x0009,0042).

Além disso, nesta etapa ocorre o preenchimento de informações não presentes no metada-

44

dos a partir de valores presentes. Foi escolhido a utilização do CT-Expo porque ainda está em

desenvolvimento e suporta todos os modelos do contexto do trabalho. Este processo é feito

de maneira automática, com base em valores como kVp, modelo e fabricante do equipamento,

corrente, já se consegue inferir mais informações como: Pitch, Exposure, Scan Length. A duas

etapas manuais é quando faltam valores nos metadados (DICOM Headers) e a categorização da

série em SCAN, RECONSTRUCTION, DOSEINFO e TOPOGRAM; pois o software não sabe

decidir de maneira automática.

Figura 2.16: Software PERMOS.

Fonte: (JAHNEN et al., 2011).

A última etapa é responsável é a utilização de ferramentas de Data Mining para extrair

informações não perceptíveis individualmente.

Os resultados deste trabalho foram usado na pesquisa nacional do país de Luxemburgo.

Sendo utilizado em cinco hospitais com diferentes infra-estruturas e totabilizando oito tomó-

grafos (três equipamentos da General Eletric, cinco equipamentos Siemens). Os dados foram

coletados dos seis protocolos mais frequentes: brain, facial bones/sinus, cervical spine, chest,

abdome e lumbar spine; totalizando 1100 exames. Como planejado, conseguiu-se calcular CT-

DIvol, CTDIw e DLP automaticamente baseando nos metadados (DICOM Header).

45

3 Desenvolvimento

Este capítulo apresenta os métodos utilizado para implementação dos objetivos. A primeira

seção explora a etapa do desenvolvimento da ferramenta geradora de RDSR. A seção seguinte

explora como é realizado a exportação dos dados para um padrão intermediário, de tal maneira

que possa abranger e auxiliar outros trabalhos que necessitam analisar os valores uniformizados

encontrados nos arquivos DICOM de exames TC. Já na terceira seção, pretende-se explicar

como e quais mudanças foram feitas no servidor PACS (cyclopsDCMServer) para armazenar

um arquivo RDSR arbitrário. E por fim, as propostas de alterações no STT/SC para incorporar

a utilização do RDSR.

3.1 Ferramenta Geradora

Segundo (CLUNIE, 2010), todos os novos equipamentos começarão a codificar as infor-

mações de dose no DICOM Radiation Dose Structured Report (RDSR). No entanto, ainda

haverá os antigos equipamentos que não foram atualizados, e poderão nunca ser. Assim sendo

necessário criar um pseudo RDSR, isto é, preenchendo os campos que sejam passíveis de ex-

tração e/ou inferência. Geralmente, os arquivos DICOM possuem apenas técnicas (kVP, mA),

e as informações de dose estão presente somenente em imagens, ou seja, requer intervenção

humana para compreensão. Nesta seção será apreesentado o desenvolvimento da ferramenta

responsável na extração dos dados de dosimetria, isto é, exibindo as etapas de extração, uni-

formização dos possíveis fluxos suportados, e a geração do arquivo RDSR.

3.1.1 Visão Geral

A ferramenta geradora do RDSR/CSV, foi construída visando reaproveitar a base do soft-

ware cyclopsDCMServer, com a finalidade de agregar apenas mais um módulo ao sistema já

existe, de tal forma que não impactasse profundamente no modelo atual de funcionamento.

Apenas recapitulando, o cyclopsDCMServer foi implementado através de API C++ das bib-

liotecas disponibilizadas em ambiente GNU/Linux.

46

Figura 3.1: Visão Geral do Sistema.

Como se pode observar na 3.1, em suma, um tómografo envia um exame — no caso deste

presente trabalho, assume que um exame é constituído por imagem(ns) e opcionalmente um ar-

quivo de DoseSheet — ao servidor de imagens médicas presente no PACS, no caso do STT/SC,

o cyclopsDCMServer. Supondo que já houve o término do envio deste exame, ou seja, a garan-

tia de que todos os arquivos do exame já estão presentes no servidor, a ferramenta desenvolvida

tem como objetivo realizar a análise do exame, e assim sintetizar os arquivos resultantes deste

análise, isto é, o RDSR e os CSV. As próximas sub-seções exibem como é realizado o desen-

volvimento da ferramenta.

47

3.1.2 Etapa 1 - Análise dos Dados

As tecnologias e técnicas empregadas nos trabalhos correlatos, abordam a elaboração de

regras bem definidas sobre quais os passos a serem seguidos, e que valores são previstos. O

objetivo desta primeira etapa é gerar subsídios para a modelagem e implementação da segunda

etapa. Devido ao fato de existir a possibilidade dos arquivos DICOM serem heterogêneos, isto

é, arquivos podem possuir diferenças dependendo do software, modelo e fabricante do equipa-

mento gerador do arquivo; foi necessário criar uma etapa para realizar a análise dos dados

presentes em um conjunto de exames. Para realizar esta análise, foi utilizado a ferramenta dcm-

dump pertencente ao conjunto de ferramentas da biblioteca DCMTK Toolkit (OFFIS, 2012).

Como se pode visualizar no código abaixo, foi automatizado o processo de realizar o dump de

todos arquivos .dcm dentro de um diretório — e seus respectivos sub-diretórios.

1 echo ‘pwd ‘ > dump . t x t

2

3 f o r ARQUIVO i n ‘ d i r −d ∗ ‘ ;

4 do

5 NOME= ‘ echo "$ARQUIVO" | sed ’ s / \ . [ ^ \ . ] ∗$ / / ’ ‘

6 EXTENSAO= ‘ echo "$ARQUIVO" | sed ’ s / . ∗ \ . / / ’ ‘

7 i f [ "$EXTENSAO" == "dcm" ] ; t h e n

8 dcmdump $NOME" . "$EXTENSAO | p a s t e −s −d ’ \ t ’>>dump . t x t

9 f i

10 done

codigo–fonte/cycdcmdump.sh

O propósito é utilizar esta etapa apenas para visualizar quais dados estão presentes no ar-

quivo DICOM. Ou seja, se os dados estão contidos em campos privados ou públicos, se certos

dados estão omissos ou vazios, etc. Com base em um conjunto de amostras, é possível decidir

qual a melhor abordagem possível para extrair os dados de dosimetria. Como pode ser visual-

izado na imagem 3.2, este pré-processamento fornece uma fonte comparativa necessária para a

próxima etapa.

48

Figura 3.2: Amostra de um dump de todos os arquivos de um exame arbitrário.

3.1.3 Etapa 2 - Extração dos Dados

Nesta etapa é realizada a extração dos dados presentes nos exames de TC. Isto é, extraindo

os campos que há interesse em obter, e que estejam presentes no exame gerado pelo software

e/ou modelo e/ou fabricante. Primeiramente, é feito a varredura em um diretório — e até seus

sub-diretórios — especificado pelo usuário, realizando a coleta do caminho de todos os arquivos

a serem lidos. Após esse processo, para evitar incoerência, são descartados os arquivos que

possuem modalidade diferente de TC, e arquivos de outro exame, uma vez que ao ler o primeiro

arquivo, já temos a identificação única do exame que está sob análise.

Ao iniciar o processo de leitura de um único arquivo, a ferramenta tem fluxos bem definidos

de acordo com o tipo e conteúdo do arquivo. Para ficar mais claro o entendimento, segue o

fluxograma 3.3 de execução para cada arquivo.

49

Figura 3.3: Fluxograma de execuçao da ferramenta cycRDSR.

Valores Extraídos - DICOM Headers

No total foram extraídos oitenta e três campos, alguns campos obrigatórios e que sempre

vão estar presentes nos arquivos, outros campos que são opcionais, isto é, nem sempre vão pos-

suir valores ou estarem presentes nos arquivos. Enfim, foram extraídos os campos necessários

relacionados com a geração do RDSR, contudo, também foram extraídos os campos adicionais

para serem armazenados e dar auxílio a um outro trabalho paralelo a este.

50

No apêndice A, é possível visualizar e compreender a descrição de todos os campos extraí-

dos. Mas de maneira geral, segue abaixo um resumo de alguns campos agrupados por categoria.

Exame - Study

• Identificação única. Exemplo: 1000.5121.1221.54.....114;

• Data e hora da realização. Exemplo: 05/02/2012 13:25:10;

• Descrição do Exame. Exemplo: CT Lombar;

• Accession Number. Exemplo: 123.

Série - Series

• Identificação única. Exemplo: 1000.5121.1221.54.....111;

• Número da série. Exemplo: 2;

• Modalidade. Exemplo: CT;

• Protocolo. Exemplo: EXAME LOMBAR ESPESSURA 5;

• Nome do Operador. Exemplo: João da Silva;

• Descrição. Exemplo: Série com Constraste;

• Parte do Corpo Examinada. Exemplo: Lombar.

Equipamento

• Fabricante. Exemplo: Philips;

• Modelo. Exemplo: Brilliance 6;

• Nome da Instituição. Exemplo: Hospital Universitário;

• Nome da Estação. Exemplo: Equipamento X;

• Nome do Departamento. Exemplo: Setor da Radiologia;

• Versão do Software. Exemplo: 3.5.

51

Paciente

• Nome do Paciente. Exemplo: Maria da Silva;

• Data de Nascimento. Exemplo: 01/05/1970;

• Sexo. Exemplo: Masculino;

• Peso. Exemplo: 82kg.

Imagem

• Dimensões da Imagem. Exemplo: 512px de largura, 512px de altura;

• Espessura do Corte. Exemplo: 4mm;

• KVP. Exemplo: 20mA;

• Corrente. Exemplo: 20mA;

• CTDIVol. Exemplo: 20Gy.

Uniformização dos Dados

Para deixar o sistema modular, foi utilizado uma hierarquia de classes com o intuito de criar

uma classe genérica que pressupõem que todos os campos desejados estejam na TAG definida

pelo padrão DICOM. E como há disparidade entre modelos de tomógrafo, há a possibilidade

de criar classes para cada modelo e versão estendendo a classe genérica, e quando necessário,

alguns métodos são sobrescritos. Para maior compreensão, segue abaixo a figura 3.4

52

Figura 3.4: Diagrama UML - Hierarquia de classes para modularizar a etapa de extração dosdados.

Identificação do Módulo Após a leitura do primeiro arquivo, é feito a verificação se o

arquivo pertence as modelos/fabricantes testados, caso sim, há códigos específicos para extrair

toda e qualquer informação relevante no contexto de dosimetria. Caso o modelo e/ou fabricante

não seja suportado, nesta etapa deve abortar a execução e exibir uma mensagem ao usuário

dizendo que o exame a ser processado não poderá ser totalmente será totalmente lido.

Carregamento Dinâmico do Módulo No momento em que se faz a leitura dos respectivos

campos: Fabricante, Modelo e Versão do Software; é possível fazer a intersecção com os valores

suportados pela aplicação e carregar o módulo mais apropriado a para realizar a leitura dos

53

arquivos.

3.1.4 Etapa 3 - Geração Arquivo de Saída

Como já descrito anteriormente, a ferramenta tem como objetivo armazenar os dados extraí-

dos em dois formatos, na forma de RDSR para prover interoperabilidade, e na forma de arquivo

texto (CSV) para auxiliar trabalhos futuros na etapa de pós-processamento das informações com

ferramentas estatísticas.

Arquivo RDSR

Seguindo normas e diretrizes estabelecidas para composição de documentos estruturados

por (CLUNIE, 2000) e pelo suplemento 127 do padrão DICOM (NEMA, 2012), nesta etapa se

deve agrupar as informações préviamente extraídas para sintetizar um arquivo DICOM RDSR.

Haja vista que na etapa anterior foi extraído o máximo de informações de dosimetria disponíveis

nos arquivos processados, é necessário apenas desenvolver mais um módulo. Este módulo

fornece à aplicação uma interface para geração e codificação das informações na forma estru-

turada.

Figura 3.5: Grafo exibindo a relação entre as centenas de nodos do arquivo RDSR.

Cabeçalho

• Nome paciente;

54

• Instituição;

• Nome do físico médico;

• fabricante/modelo aparelho.

Nodo Raiz

• Data da Irradiação;

• Study Instance UID.

Nodo Sumário

• Total de irradiações;

• DLP Total;

• Dose efetiva Total;

• Responsável;

• Método de mensuração da dose efetiva;

• Modelo do Paciente;

• Comentário;

• Dispositivo.

Nodo Evento de Irradiação

• Protocol;

• Scanning Length;

• Collimation Width;

• Pitch;

• KVP;

• Maximum Tube Current;

55

• Ray TUbe Current;

• Exposure Time per Rotation;

• CTDIVol;

• CTDIw Phantom;

• CTDIfreeair Factor;

• CTDIFreeAir;

• DLP;

• Dose Efetiva;

• Dose Efetiva, fator de conversão.

Seguindo a mesma abordagem desenvolvida pelos trabalhos correlatos, é inviável a apli-

cação manipular diretamente o stream de bytes referente as informações. Haja a vista que não

é o foco do trabalho interferir ou modificar este processo. Sendo assim, foi utilizado ferra-

menta de terceiros para viabilizar a escrita em disco do arquivo no formato estruturado. Esta

ferramenta foi o PixelMed (CLUNIE, 2012), desenvolvida por um dos idealizadores do arquivo

DICOM estruturado (CLUNIE, 2000).

Contudo, foi utilizado apenas uma "biblioteca" da ferramenta PixelMed que foi desen-

volvida para linguagem Java. E como a aplicação cycRDSR foi desenvolvida em C++, teve

que haver um intercomunicador entre as duas aplicações. Para realizar esta transferência de

informação entre as aplicações, houve a necessidade de serializar os dados em um aplicação,

e criar uma "mini-aplicação"apenas com a finalidade ler esses dados serializados e enviar ao

PixelMed. Para não comprometer o fluxo da aplicação como um todo, este processo foi real-

izado de maneira automática e sistematizada, assim sendo indiferente ao utilizador da aplicação

cycRDSR como pode ser visto na figura 3.6.

56

Figura 3.6: Intercomunicação de informação entre dois processos distintos.

Arquivo CSV

Para realizar o armazenamento dos dados em um arquivo CSV, isto é, armazenar de tal

maneira que esses arquivos fiquem indexados e facilite um pós-processamento sobre os seus re-

spectivos conteúdos. Foi definido um conjunto de regras a serem seguidas durante o armazena-

mento, como se pode notar no fluxograma abaixo 3.7. Supondo um conjunto de exames, per-

tencentes a uma instituição arbitrária, no mesmo local onde está sendo executado a aplicação

cycRDSR, após o fim da execução, haverá 2*n + 1*m arquivos CSV preenchidos, onde n é o

número de exames processados, e m é o número de protocolos distintos processados durante a

execução. Para haver diferenciação entre os arquivos, estabeleceu-se padrões na nomenclatura.

A cada exame processado, será gerado dois arquivos. O arquivo denominado "RESUMO",

o qual será preenchido com as principais informações extraídas de cada irradiação presente

neste exame, ou seja, cada linha neste arquivo representa uma série ORIGINAL. E o segundo

arquivo a ser preenchido, é um arquivo contendo exatamente todos os campos de todos os ar-

quivos processados, isto é, cada linha neste arquivo contém o conteúdo presente em um arquivo

DICOM lido, seja este pertencente a uma série reconstruída, série original, etc. Lembrando que

o foco do pós-processamento não necessita do Nome do Paciente, este campo foi anonimizado,

isto é, Paciente1, Paciente2, Paciente3, ..., PacienteN.

O padrão de nomenclatura utilizado foi:

"TC2_LOCAL_DATAEXTRACAO_PACIENTEN"

57

onde,

• LOCAL é o nome ou identificação da instituição;

• DATAEXTRACAO é a data em que está sendo realizado o processo;

• PACIENTEN é a identificação única do paciente anonimizado.

A cada processamento de um exame, o conteúdo do arquivo "RESUMO", vai ser adicionado

ao arquivo "RESUMO GERAL", sendo este responsável por agrupar todas as informações de

uma maneira com que haja relação entre os respectivos exames inclusos. De maneira análoga,

para facilitar a identificação na etapa de pós-processamento, estabeleceu que o nome do arquivo

"RESUMOGERAL"será:

"TC1_LOCAL_DATAEXTRACAO_PROTOCOLO"

onde,

• LOCAL é o nome ou identificação da instituição;

• DATAEXTRACAO é a data em que está sendo realizado o processo;

• PROTOCOLO é a identificação única do protocolo utilizado na respectiva instituição

responsável pelo exame.

Segue abaixo um fluxograma 3.7 para melhor compreensão do fluxo de armazenamento das

informações no formato CSV.

58

Figura 3.7: Fluxograma - Etapas do processo para armazenamento do CSV.

59

3.2 Alteração no PACS

Segundo (MEDIMGRADDOSEINFORMATICS, 2012), atualmente são poucos equipa-

mentos que suportam a geração e envio do arquivo RDSR ao PACS. Como pode ser visto na

figura 3.8, até o momento somente os equipamentos da GE possuem suporte.

Figura 3.8: Tomógrafos que suporta o envio de RDSR.

Fonte: (MEDIMGRADDOSEINFORMATICS, 2012). Acessado em outubro de 2012.

Como visto no capítulo anterior, comunicação DICOM, no início da comunicação entre

duas entidades existe a etapa de Handshake, isto é, a etapa necessária que precede as trocas de

mensagens. De maneira resumida, o cliente SCU inicia a conexão enviando um A-ASSOCIATE

REQUEST, o servidor SCP por sua vez responde o cliente com um A-ASSOCIATE ACCEPT,

enviando também a lista dos serviços suportados. Nesta etapa, o cliente SCU pode fazer a

intersecção dos dois conjuntos e verificar o resultado desta operação. Este processo pode ser

visto na figura 3.9, sendo que a conexão foi abortada devido a o resultado da intersecção ser

vazio.

60

Figura 3.9: Conexão DICOM mal sucedida.

Com as devidas modificações na API do cyclopsDCMServer, e fazendo o uso de uma fer-

ramenta (doravante storescu) para simular o envio de um arquivo RDSR — ferramenta do con-

junto de ferramentas (OFFIS, 2012).

ua identificação e a lista de serviços que a entidade que faz papel de servidor (Provider)

envia uma lista de SOPClass, a qual representa todos os serviços suportados pelo servidor.

O servidor por sua vez continua a conexão caso o SOPClass esteja contido no conjunto de

SOPClass providos pelo SCP. Isso pode ser visto na figura 3.10.

61

Figura 3.10: Fluxograma de execuçao da ferramenta cycRDSR.

3.3 Implantação no STT - Estudo de Viabilidade

Mesmo que a ferramenta geradora de RDSR/CSV desenvolvida neste trabalho visa atender

o conceito de flexibilidade durante a extração e o armazenamento dos dados de dosimetria, o

processo de implantação da mesma no fluxo de trabalho do PACS é uma tarefa que deve levar

em consideração as especificidades do sistema. Isto é, necessita realizar um processo de análise

da infra-estrutura e consecutivamente a necessidade de realizar modificações no PACS.

De acordo com (HUSSEIN et al., 2004), o processo de implantação da utilização do DI-

COM SR em um sistema médico acaba incluindo as seguinte etapas:

• definir aspectos como a apresentação do arquivo estruturado ao usuário (visualização e

impressão);

• síntese de uma interface para entrada das informações por parte do usuário;

62

• a estrutura de dados utilizada para armazenar esas informações.

No caso deste trabalho, o segundo aspecto é executado de maneira automática pela ferra-

menta geradora do RDSR. Sendo assim, o processos necessários para a incorporação da fer-

ramenta são: a análise da arquitetura do STT/SC, o mapeamento do modelo relacional, e as

formas e maneiras de visualização dos dados.

Devido a arquitetura atual possuir as bridges que enviam assim que possível os exames ao

repositório central, vide figura 3.11. Este poderia ficar encarregado de executar a ferramenta

cycRDSR assim que o exame é armazenado, no entanto, como não é possível saber o término do

envio do exame, seria necessário criar uma política de temporização para executar a ferramenta

em um tempo fixo após o recebimento da última imagem. No entanto, essa temporização deve

ser reiniciada sempre que receber uma nova imagem. E caso ocorra algum problema com a

bridge e seja enviado apenas parte do exame, e necessário que a aplicação apague qualquer

informação de dosimetria daquela exame, e execute novamente a ferramenta cycRDSR.

63

Figura 3.11: Integração do cycRDSR no Sistema Catarinense de Telemedicina.

Dado a atual conjuntura do portal de Telemedicina, os dados de dosimetria de cada exame

poderia ser exibido na respectiva janela. Como se pode observar na figura 3.12, uma possível

localização de exibição dos dados sumariados.

64

Figura 3.12: Possível campo para exibir as informações de dosimetria na janela de exame.

STT/SC - Janela de visualização de um exame arbitrário.

Além disso, essas informações individuais exibidas em cada exame podem ter pouca sig-

nificância. Ou seja, seria necessário criar uma parte do sistema responsável em agrupar essas

informações nas mais diversas maneiras e assim sintetizar gráficos e estatísticas baseando a

comparação entre equipamentos, protocolos, pacientes, etc. No entanto, para criar a relação

entre pacientes e histórico de informação de dosimetria, é necessário haver o identificado único

do paciente. Além disso, para correlacionar os demais parâmetros de maneira sistematizada,

é de certa forma uma barreira, segundo (MORIN; COOMBS; CHATFIELD, 2011) — um

projeto que tem como objetivo criar um centro nacional de coleta de dados de dosimetria —

, um dos principais problemas ao tentar agrupar os dados advindos de diferentes instituições

é não padronização na descrição dos exames TC. como por exemplo, um exame de cabeça

em um paciente adulto pode ser descrito como: "Head 1Brain_without (Adult)", ou como

"Head1_HEAD_WO_Adult". Como cada instituição presente no STT/SC pode possuir difer-

entes nomenclaturas para o mesmo exame, haveria a necessidade de criar um mapeamento

entre as nomenclaturas dos protocolos. Para melhor ilustração, um exemplo de comparação

65

entre exames abordados em outro estudo pode ser visualizado na figura 3.13, sendo possível ver

a diferença entre os mesmos exames realizados em diferentes instituições.

Figura 3.13: Análise entre protocolos utilizados em diferentes instituições.

Fonte (MORIN; COOMBS; CHATFIELD, 2011). IVCON significa intravenoso com contraste, e WO significasem contraste.

66

4 Conclusão

Nesse trabalho foi apresentada uma abordagem intermediária para o desenvolvimento da

ferramenta geradora de RDSR. Isto é, foi implementado a maneira que atende os casos de ar-

quivos DICOM que possuem as informações de dosimetria em seus respectivos cabeçalhos.

Sendo assim, diferentemente dos trabalhos correlatos, não é possível utilizar esta ferramenta

para ler (através de OCR) informações de dosimetria presentes na imagem do arquivo Dose

Sheet. Além disso, deve-se lembrar que inicialmente se procurou abranger todos os equipamen-

tos de tomografia que fazem parte do Sistema Catarinense de Telemedicina. No entanto, até o

momento é suportado apenas o equipamento presente em duas instituições, porém, a aplicação

foi projetada de forma modular, assim facilitando adicionar suporte a mais equipamento(s) e/ou

modelo(s). E concomitantemente, mesmo que de maneira simplória no âmbito da Computação,

houve o desenvolvimento de uma etapa para armazenar as informações extraídas em um con-

junto de arquivos, assim sendo possível dar início a um projeto paralelo a este, com intuito de

realizar um pós-processamento nos dados de dosimetria. Como por exemplo para elucidar, o

nível de radiação utilizado em cada protocolo de TC em diferentes instituições.

Porém, a geração de arquivo RDSR com base em informações presentes em arquivos DI-

COM, pode não ter resultado satisfatório, haja vista a não padronização de armazenamento

das informações de dosimetria presente no arquivo DICOM (imagem). Sendo assim, a melhor

abordagem para obter as informações completas de dosimetria dos exames seria a utilização de

equipamentos de tomografia que estejam em conformidade com a classe de serviço referente ao

envio de RDSR.

Na etapa de recebimento do arquivo RDSR no servidor, foram realizados experimentos que

simularam — comportamento análogo a um moderno aparelho de tomografia — o envio de

arquivos RDSR ao PACS do STT (Cyclops DCMServer). Com isso, foi possível verificar que

as modificações realizadas foram suficientes para fazer o servidor aceitar arquivos deste tipo,

no entanto, não foi implementado qualquer alteração no servidor que realizasse a indexação ou

extração de dados destes arquivos.

E por fim, a análise de viabilidade da integração da ferramenta geradora de RDSR com o

67

Sistema Catarinense de Telemedicina, sendo este analisado sob o ponto de vista de um único

sistema, criando assim a necessidade de implementar uma forma de correlacionar o significado

de protocolo e/ou descrição do estudo entre as instituições envolvidas. Pois não seria correto

comparar dados heterogêneos. E no âmbito do histórico do paciente, seria necessário o uso

de identificação única do paciente dentro de todas as unidades para que haja a convergência

dessas informações. Além disso, seria necessário estudar que valores e informações deveriam

ser indexadas para prover de maneira automatizada relatórios, estatísticas, etc.

68

5 Trabalhos Futuros

Como a ferramenta desenvolvida não suporta a extração das informações de DoseSheet que

requer utilização de OCR, ou seja, a ferramenta não suporta analisar os dados de dosimetria

presentes na maioria tomógrafos legados. Seria de grande colaboração adicionar e integrar

ferramenta OCR para possibilitar o suporte a estes equipamentos.

Outro ponto interessante, seria utilizar técnicas de reconhecimento de padrões para melhor

estimar o valor de CTDI nos exames de abdômen (TC). Isto seria através da mensuração lat-

itudinal do abdômen identificado dentro de um exame, e fazendo uso da tabela provida pelo

RPT204, é possível aproximar a um valor mais próximo do real, haja vista que o tamanho do

paciente influencia na quantidade de dose absorvida.

Além disso, embora o servidor de imagens médicas (cyclopsDCMServer) do STT/SC foi

adaptado para receber e armazenar os arquivos RDSR. Ainda há uma lacuna a ser preenchida

que é a definição dos valores a serem indexados para facilitar um pós-processamento.

Já no contexto exclusivo do STT/SC, algo que indiretamente iria colaborar para a criação

do histórico de radiação do paciente, seria a definição de regras e políticas para fazer uma

identificação única do paciente dentro de todo o sistema como um todo. Além disso, como sug-

ere o (MORIN; COOMBS; CHATFIELD, 2011), deveria ser utilizado o vocabulário do RSNA

RadLex (LANGLOTZ, 2006) para uma tradução dos nomes de protocolos entre as diversas in-

stituições que fazem parte do sistema. Assim, seria possível construir uma grande base de dados

com valores homogêneos.

69

Referências Bibliográficas

APPLEGATE, K.; THOMAS, K. Pediatric ct—the challenge of dose records. PediatricRadiology, Springer, v. 41, p. 523–527, 2011.

AZEVEDO-MARQUES, P. de; SALOMÃO, S. Pacs: sistemas de arquivamento e distribuiçãode imagens. Revista Brasileira de Física Médica, v. 3, n. 1, p. 131–9, 2009.

BASTOS, A. de L. Doses e risco de radiação em estudo tomográfico do tórax com tecnologiade quatro cortes. Dissertação (Mestrado) — CDTN - Centro de Desenvolvimento daTecnologia Nuclear, 2006.

BAUHS, J. et al. Ct dosimetry: Comparison of measurement techniques and devices1.Radiographics, Radiological Society of North America, v. 28, n. 1, p. 245–253, 2008.

BIDGOOD, W.; HORII, S. Introduction to the acr-nema dicom standard. Radiographics,Radiological Society of North America, v. 12, n. 2, p. 345–355, 1992.

BOONE, J. et al. Size-specific dose estimates (ssde) in pediatric and adult body ctexaminations. Report of AAPM Task Group, v. 204, 2011.

BRENNER, D.; HRICAK, H. Radiation exposure from medical imaging. JAMA: The Journalof the American Medical Association, Am Med Assoc, v. 304, n. 2, p. 208, 2010.

CASTRO, R. C. de. Cálculo de dose equivalente em órgãos de pacientes devido a fotonêutronsgerados em aceleradores lineares clínicos. Dissertação (Mestrado) — Universidade Federal doRio de Janeiro, 2005.

CLUNIE, D. DICOM structured reporting. [S.l.]: PixelMed Publishing, 2000.

CLUNIE, D. Extracting, Managing and Rendering DICOM Radiation Dose In-formation from Legacy Contemporary CT Modalities. [S.l.], 2010. Disponível em:<http://www.dclunie.com/papers/D20800ClunieRadiationDose.pd f >.

CLUNIE, D. Pixelmed. [S.l.], 2012. Disponível em:<http://www.dclunie.com/pixelmed/software/>.

COMMISSION, I. E. et al. Particular requirements for the safety of x-ray equipment forcomputed tomography. IEC publication, v. 60601, p. 2–44.

COOK, T. et al. Automated extraction of radiation dose information for ct examinations.Journal of the American College of Radiology, Elsevier, v. 7, n. 11, p. 871–877, 2010.

COOK, T. et al. Informatics in radiology: Radiance: An automated, enterprise-wide solutionfor archiving and reporting ct radiation dose estimates. Radiographics, Radiological Society ofNorth America, v. 31, n. 7, p. 1833–1846, 2011.

70

DELLANI, P. Desenvolvimento de um servidor de imagens médicas digitais no formatoDICOM. Dissertação (Mestrado) — Universidade Federal de Santa Catarina, 2001.

DONNELLY, L. et al. Minimizing radiation dose for pediatric body applications of single-detector helical ct strategies at a large children’s hospital. American Journal of Roentgenology,Am Roentgen Ray Soc, v. 176, n. 2, p. 303–306, 2001.

FDA. Reducing Radiation from Medical X-rays. [S.l.], 2009. Disponível em:<http://www.fda.gov/downloads/ForConsumers/ConsumerUpdates/UCM185316.pdf>.

FOLHA. Médicos pedem menos tomografias para evitar radiação. [S.l.], 2011. Disponível em:<http://www1.folha.uol.com.br/equilibrioesaude/934875-medicos-pedem-menos-tomografias-para-evitar-radiacao.shtml>.

GIULIANO, I. et al. Emissão de laudos eletrocardiográficos a distância: Experiência da redecatarinense de telemedicina. SciELO Brasil.

GONZALEZ, A. Berrington de et al. Projected cancer risks from computed tomographic scansperformed in the united states in 2007. Archives of internal medicine, Am Med Assoc, v. 169,n. 22, p. 2071, 2009.

HIRAYAMA, J. et al. Development of template-free form recognition system. In: IEEE.Document Analysis and Recognition (ICDAR), 2011 International Conference on. [S.l.], 2011.p. 237–241.

HUDA, W.; METTLER, F. Volume ct dose index and dose-length product displayed duringct: what good are they? Radiology, Radiological Society of North America, v. 258, n. 1, p.236–242, 2011.

HUSSEIN, R. et al. Dicom structured reporting part 2. problems and challenges inimplementation for pacs workstations1. Radiographics, Radiological Society of NorthAmerica, v. 24, n. 3, p. 897–909, 2004.

IHE. Radiation Exposure Monitoring. [S.l.], 2012. Disponível em:<http://wiki.ihe.net/index.php>.

JAHNEN, A. et al. Automatic computed tomography patient dose calculation using dicomheader metadata. Radiation protection dosimetry, NTP, v. 147, n. 1-2, p. 317–320, 2011.

JR, E. A. et al. American college of radiology white paper on radiation dose in medicine.Journal of the American College of Radiology: JACR, v. 4, n. 5, p. 272, 2007.

JUNIOR, C. L. B. Concepção, desenvolvimento e implantação de uma ferramenta para usode laudo estruturado no padrão DICOM SR em sistemas de telemedicina de larga escala.Dissertação (Mestrado) — Universidade Federal de Santa Catarina, 2012.

KITCHENHAM, B. Procedures for performing systematic reviews. [S.l.], 2004. v. 33.

LANGLOTZ, C. Radlex: A new method for indexing online educational materials1.RadioGraphics, Radiological Society of North America, v. 26, n. 6, p. 1595–1597, 2006.

LI, X.; ZHANG, D.; LIU, B. Automated extraction of radiation dose information from ct dosereport images. American Journal of Roentgenology, Am Roentgen Ray Soc, v. 196, n. 6, p.W781–W783, 2011.

71

MACEDO, D. et al. Replicaçao assíncrona entre bancos de dados médicos distribuídos. EscolaRegional de Bancos de Dados, 2008.

MCCOLLOUGH, C. et al. The measurement, reporting, and management of radiation dose inct. Report of AAPM Task Group, v. 23, p. 1–28, 2008.

MCCOLLOUGH, C. et al. Ct dose index and patient dose: they are not the same thing.Radiology, Radiological Society of North America, v. 259, n. 2, p. 311–316, 2011.

MEDIMGRADDOSEINFORMATICS. Group to discuss and share informationabout informatics solutions to monitoring and reducing onizing radiation doseto patients undergoing medical imaging procedures. [S.l.], 2012. Disponível em:<https://sites.google.com/site/medimgraddoseinformatics/>.

MILLER, D. et al. Quality improvement guidelines for recording patient radiation dose in themedical record. LINKOPING STUDIES IN SCIENCE AND TECHNOLOGY-DISSERTATIONS-, LINKOEPING UNIVERSITY, p. 423–430, 2004.

MORIN, R.; COOMBS, L.; CHATFIELD, M. Acr dose index registry. Journal of the AmericanCollege of Radiology, v. 8, n. 4, p. 288, 2011.

NEMA. Conformance. [S.l.], 2011. Disponível em:<http://medical.nema.org/Dicom/2011/11_01pu.pdf>.

NEMA. Information Object Definitions. [S.l.], 2011. Disponível em:<http://medical.nema.org/Dicom/2011/11_03pu.pdf>.

NEMA. Message Exchange. [S.l.], 2011. Disponível em:<http://medical.nema.org/Dicom/2011/11_07pu.pdf>.

NEMA. Supplement 127 - Dicom - NEMA. [S.l.], 2012. Disponível em:<ftp://medical.nema.org/medical/dicom/final/sup127 f t.pd f >.

NOBRE, L.; WANGENHEIM, A. von. Software gratuito: uma opção para o radiologista.Radiol Bras, SciELO Brasil, v. 43, n. 5, 2010.

OFFIS. DCMTK - DICOM Toolkit. [S.l.], 2012. Disponível em:<http://dicom.offis.de/dcmtk.php.en>.

OKUNO, E. Epidemiologia do câncer devido a radiações ea elaboração de recomendações.Revista Brasileira de Física Médica, v. 3, n. 1, p. 43–55, 2009.

OLIVEIRA, M.; KHOURY, H. Influência do procedimento radiográfico na dose de entrada napele de pacientes em raios x pediátricos. Radiol Bras, SciELO Brasil, v. 36, n. 2, p. 105–9,2003.

PIANYKH, O. Digital Imaging and Communications in Medicine (DICOM): A practicalintroduction and survival guide. [S.l.]: Springer, 2011.

PINA, D. de et al. Controle de qualidade e dosimetria em equipamentos de tomografiacomputadorizada. SciELO Brasil, 2009.

72

PRADO, T. C. Otimização da Persistência de Dados em PACS empregando Modelos de DadosHierárquicos Indexados. Dissertação (Mestrado) — Universidade Federal de Santa Catarina,2012.

RADIATION, N. R. C. U. C. to Assess Health Risks from Exposure to Low Level of I. Healthrisks from exposure to low levels of ionizing radiation: BEIR VII Phase 2. [S.l.]: Natl AcademyPr, 2006.

RECOMMENDATIONS, I. Icrp publication 60. Annals of ICPR, v. 21, n. 1-3, 1990.

RON, E. Cancer risks from medical radiation. Health physics, v. 85, n. 1, p. 47, 2003.

SHIH, G. et al. Automated framework for digital radiation dose index reporting from ctdose reports. American Journal of Roentgenology, Am Roentgen Ray Soc, v. 197, n. 5, p.1170–1174, 2011.

SODICKSON, A. et al. Automated Body Size Extraction Using Axial CT Images to CalculateWater-Equivalent Diameter. [S.l.], 2012.

VERDUN, F. et al. Quality initiatives radiation risk: What you should know to tell yourpatient1. Radiographics, Radiological Society of North America, v. 28, n. 7, p. 1807, 2008.

WANGENHEIM, A. et al. Caminhos para a implantação de telemedicina em larga escala: Aexperiência de santa catarina. Latin American Journal of Telehealth, v. 3, n. 1, 2010.

WANGENHEIM, A. von et al. Ways to implement large scale telemedicine: The santa catarinaexperience. Latin-American Journal of Telehealth, v. 3, p. 364–376, 2009.

73

APÊNDICE A -- DICOM - IOD CT - CamposExtraídos

Tabela A.1: Tabela com o conteúdo de um arquivo de TC - (CT IOD)

IE Módulo Referência Usage

Patient Patient C.7.1.1 M

Clinical Trial Subject C.7.1.3 U

General Study C.7.2.1 M

Patient Study C.7.2.2 U

Clinical Trial Study C.7.2.3 U

General Series C.7.3.1 M

Clinical Trial Series C.7.3.2 U

Frame of Reference C.7.4.1 M

Equipment General Equipment C.7.5.1 M

Image General Image C.7.6.1 M

Image Plane C.7.6.2 M

Image Pixel C.7.6.3 M

Contrast/bolus C.7.6.4 C - Required if con-

strast media was used in

this image

Device C.7.6.12 U

Specimen C.7.6.22 U

CT Image C.8.2.1 M

Overlay Plane C.9.2 U

VOI LUT C.11.2 U

SOP Common C.12.1 M

74

Tabela A.2: Tabela com os campos referentes ao IOM - GENERALCampo TAG Tipo DescriçãoSOP Class UID (0008,0016) 1 -SOP Instance UID (0008,0018) 1 -Specific Character Set (0008,0005) 1C -Instance Creation Date (0008,0012) 3 -Instance Creation Time (0008,0013) 3 -Instance Creator UID (0008,0014) 3 -

Tabela A.3: Tabela com os campos referentes ao IOM - STUDYCampo TAG Tipo DescriçãoStudy Instance UID (0020,000D) 1 Identificador único do exameStudy Date (0008,0020) 2 Data do início do exameStudy Time (0008,0030) 2 Hora do início do exameReferring Physician’s Name (0008,0090) 2 Nome do médico executorStudy ID (0020,0010) 2 Identificador único do exameAccession Number (0008,0050) 2 Número identicador do exame no

RISStudy Description (0008,1030) 3 Descrição do exame realizado

Tabela A.4: Tabela com os campos referentes ao IOM - SERIES

Campo TAG Tipo Descrição

Modality (0008,0060) 1 Tipo de equipamento para aquisição

dos dados das imagens capturadas

das séries

Series Instance UID (0020,000E) 1 Identificador único da série

Series Number (0020,0011) 2 Número identificador da série

Series Date (0008,0021) 3 Data do início da série

Series Time (0008,0031) 3 Hora do início da série

Protocol Name (0018,1030) 3 Descrição definida pelo usuário que

representa os parâmetros e condi-

coes das séries executadas, comu-

mente denominado protocolo.

Series Description (0008,103E) 3 Descrição das séries

Operators’ Name (0008,1070) 3 Nome do operador da série

Body Part Examined (0018,0015) 3 Texto descritivo da parte do corpo

examinado

Patient Position (0018,5100) 2C Posicão do paciente em relação ao

equipamento

75

Tabela A.5: Tabela com os campos referentes ao IOM - EQUIPMENTCampo TAG Tipo DescriçãoManufacturer (0008,0070) 2 Fabricante do equipamentoInstitution Name (0008,0080) 3 Nome da instituicãoInstitution Address (0008,0081) 3 Endereco da instituicãoStation Name (0008,1010) 3 Nome da estaçãoInstitutional Department Name (0008,1040) 3 Identificação do Departamento den-

tro da InstituiçãoManufacturer’s Model Name (0008,1090) 3 Nome do modelo do equipamentoDevice Serial Number (0018,1000) 3 Identificador único do equipamentoSoftware Versions (0018,1020) 3 Versão do software do equipamentoGantry ID (0018,1008) 3 Identificador do gantrySpatial Resolution (0018,1050) 3 ResoluçãoDate of Last Calibration (0018,1200) 3 Data do última calibraçãoTime of Last Calibration (0018,1201) 3 Hora da última calibração

Tabela A.6: Tabela com os campos referentes ao IOM - PATIENTCampo TAG Tipo DescriçãoPatient’s Name (0010,0010) 2 Nome completo do pacientePatient ID (0010,0020) 2 Identificador do pacientePatient’s Birth Date (0010,0030) 2 Data de nascimento do pacientePatient’s Sex (0010,0040) 2 Sexo do pacientePatient Weight (0010,1030) 2 Peso do paciente

76

Tabela A.7: Tabela com os campos referentes ao IOM - CT IMAGECampo TAG Tipo DescriçãoImage Type (0008,0008) 1 Caracteristicas de identificação da

imagemKVP (0018,0060) 2 Medida de Peak Kilo VoltageAcquisition Number (0020,0012) 2 Número da AquisiçãoScan Options (0018,0022) 3 Parâmetros da sequencia de digi-

taçãoData Collection Diameter (0018,0090) 3 Diamêtro em mm da região que os

dados são coletadosData Collection Center (Patient) (0018,9313) 3 Distância (X,Y e Z) em mm até o

centro da região que os dados foramcoletados.

Reconstruction Diameter (0018,1100) 3 Diâmetro em mm da região a qualos dados foram utilizados para criara reconstrucão da imagem

Reconstruction Target Center (0018,9318) 3 -Distance Source to Detector (0018,1110) 3 -Distance Source to Patient (0018,1111) 3 Distância em mm da fonte ao

isocentro (centro do campo devisão)

Gantry/Detector Tilt (0018,1120) 3 -Table Height (0018,1130) 3 A distância em mm do topo da mesa

do paciente ao centro de rotacãoRotation Direction (0018,1140) 3 -Exposure Time (0018,1150) 3 -X-Ray Tube Current (0018,1151) 3 -Exposure (0018,1152) 3 -Exposure in µAs (0018,1153) 3 -Filter Type (0018,1160) 3 -Focal Spot (0018,1190) 3 -Convolution Kernel (0018,1210) 3 -Revolution Time (0018,9305) 3 -Single Collimation Width (0018,9306) 3 -Total Collimation Width (0018,9307) 3 -Table Speed (0018,9309) 3 -Table Feed per Rotation (0018,9310) 3 -Spiral Pitch Factor (0018,9311) 3 -Exposure Modulation Type (0018,9323) 3 -Estimated Dose Saving (0018,9324) 3 -CTDIvol (0018,9345) 3 -CTDI Phantom Type Code Sequence (0018,9346) 3 -Rows 0028,0010 -Columns 0028,0011 -

77

APÊNDICE B -- RPT - 204

B.0.1 AAPM - RPT 204

Conforme (BOONE et al., 2011), o RPT 204 é o relatório de número 204 produzido pela

AAPM com o título: Size-Specific Dose Estimates (SSDE) in Pediatric and Adult Body CT Ex-

aminations. Contextualizando, em 2008, foi criado a Alliance for Radiation Safety in Pediatric

Imaging ("Alliance"), uma aliança entre the American Association of Physicists in Medicine

(AAPM), a American College of Radiology (ACR), a American Society of Radiologic Technol-

ogists (ASRT) e a Society for Pediatric Radiology (SPR) para unificar os esforços na redução

de radiação em exame médicos infantis. Atualmente, a Alliance esforça-se na otimização, isto

é, um balanço entre dose de radiação e qualidade do exame. E para auxiliar os pediatras ra-

diologistas, fisícos médicos, técnicos em radiologia, etc; a "Alliance" desenvolveu um estudo

para facilitiar a criação de uma ferramenta computacional para estimar a dose de radiação du-

rante os exames pediátricos de CT. No entantos, esses estudos acabaram de certa forma também

auxiliando a a realaização da estimativa em demais exames de CT para pacientes de qualquer

tamanho.

Apenas resumindo e contextualizando as informações supracitadas, segundo (MCCOL-

LOUGH et al., 2008 apud BOONE et al., 2011), atualmente os tomógrafos apresentam o CT-

DIvol e o DLP. Ambos os valores são exibidos antes e depois do exame ser realizado, isto tem

acontecido desde 2002 (COMMISSION et al., ). O CTDIvol foi desenvolvido para fornecer

um método padronizado para fornecer uma medida de comparação entre os níveis de radiação

entre diferentes tomógrafos utilizando phantom como referência. O DLP, é o produtos entre o

CTDIvol (mGy) e comprimento da região irradiada (scan length) (cm), relacionando o total de

radiação transmitida ao phantom de referêcia. Ambos valores (CTDIvol e DLP) são sensíveis

as mudanças de parâmetros, como a voltagem, a corrente, o tempo de rotação do gantry, pitch;

mas são independente do tamanho do paciente.

Em geral, para os exames com filtro ou protocolo referente a cabeça são utilizados os phan-

tom de 16cm, enquanto que os exames para o resto do corpo (tórax, abdômen) utilizam os

78

phantom de 32cm. Até o momento, para corpos de crianças, alguns fabricantes utilizam phan-

tom de 16cm, enquanto que alguns outros fabricantes utilizam phantom de 32cm para calcular o

CTDIvol e DLP. E para mensurar precisamente essas medidas para um paciente individual, ou

até para compara com outros valores, o diâmetro do phantom do específico tomógrafo, modelo

e versão de software; devem ser conhecidos. Em alguns casos, o diâmetro utilizado até é ex-

ibido no console do aparelho, mas não está presente no arquivo DICOM. Já em equipamentos

mais antigos essa informação pode estar omissa.

A dose recebida pelo paciente é dependente do tamanho do paciente e da radiação emitida

pelo aparelho. No entanto, o CTDIvol forncedio é referente somente ao valor emitido pelo

equipamento. Ou sjea, não leva em consideração o tamanho do paciente, e portanto não ajuda

estimar o a dose do paciente (BAUHS et al., 2008). Isto é preocupante nos exames de pacientes

pediátricos, pois poderia subestimar a dose do paciente em até três vezes menos se for usado

um phantom de 32cm como referência.

Em suma, o task group 204 desenvolveu um conjunto de fatores que podem ser aplica-

dos aos valores de CTDIvol exibido pelos aparelhos. Estes fatores levam em consideração o

tamanho do paciente, portanto sendo importante para CT pediátricos.

Figura B.1: CTDIvol mensurado com dosímetros nos phantom em comparação com o valorexibido no aparelho.

79

Medidas

Como pode ser observado na figura B.3, o objetivo é obter o diâmetro do círculo que possua

a mesma área do corte transverssal do paciente na imagem de CT.

Figura B.2: Conversão entre medidas AP e LAT.

Dimensão Lateral A dimensão lateral (LAT) é a medida de uma extremidade até a outra

extremidade da parte do corpo escaneada. Esta medida pode ser calculada através das imagens

de scout, topogram, scanogram — os nomes diferem entre os fabricantes.

Dimensão Anterior Posterior A dimensão Anterior Posterios é a "espessura"da seção do

corpo do paciente a ser escaneada. Por exemplo, a medida entre a superfície do abdômen até a

superfície a região lombar.

LAT + AP Esta medida é a soma das medidas AP e Lateral. Sendo que as análises mostram

que a soma dessas duas dimensões são linearmentes relacionadas ao diâmetro efetivo.

Diâmetro Efetivo O diâmetro efetivo (effective diameter) representa o diâmetro de um corte

tranverssal do paciente em uma imagem de CT, este corte podendo estar localizado em uma

posição arbirtária no eixo Z.

80

Figura B.3: Exemplo de mensuracao de AP e LAT.

r1 =LAT

2

r2 =AP2

Onde a área da elipse é computada através:

A = πr1r2

Sendo que a área do corte transverssal, A, o diâmetro efetivo é computado por:

EffectiveDiameter =√

AP×LAP

81

ANEXO A -- DICOM - Suplemento 127: CTRadiation Dose Reporting (Dose SR)

2

4

6

Digital Imaging and Communications in Medicine (DICOM)

Supplement 127: CT Radiation Dose Reporting (Dose SR) 8

10

12

14

16

18

20

DICOM Standards Committee 22

1300 N. 17th Street, Suite 1752

Rosslyn, Virginia 22209 USA 24

26

Version: Final Text

Nov 02, 2007, 28

Developed pursuant to DICOM Work Item 2004-04-C 30

Supplement 127: CT Radiation Dose Reporting (Dose SR) Page 2

Table of Contents 30

Scope and Field .....................................................................................................................................................3 Changes to NEMA Standards Publication PS 3.3-2007 .....................................................................................4 32

Changes to NEMA Standards Publication PS 3.16-2007...................................................................................7 CT RADIATION DOSE SR IOD TEMPLATES..............................................................................................8 34

TID 10011 CT Radiation Dose ....................................................................................................8 TID 10012 CT Accumulated Dose Data .....................................................................................9 36 TID 10013 CT Irradiation Event Data .......................................................................................11 CID 10011 Effective Dose Evaluation Method .........................................................................15 38 CID 10013 CT Acquisition Type ................................................................................................15 CID 10014 Contrast Imaging Technique ..................................................................................15 40 CID 10015 CT Dose Reference Authorities..............................................................................16

Changes to NEMA Standards Publication PS 3.17-2007.................................................................................22 42

ANNEX AA: Radiation Dose Reporting Use Cases (Informative) ....................................................................23 44

Supplement 127: CT Radiation Dose Reporting (Dose SR) Page 3

46

Scope and Field

This supplement to the DICOM standard introduces a template for Diagnostic X-ray CT Dose Reporting in 48 DICOM. The concepts of Structured Reporting will be used in this context.

This document is a Supplement to the DICOM Standard. It is an extension to the following parts of the 50 published DICOM Standard:

PS 3.3 Information Object Definitions 52

PS 3.16 Content Mapping Resource PS 3.17 Explanatory Information 54

The supplement was developed by WG21 (Computed Tomography). In this supplement, radiation-related 56 aspects of CT have been addressed with the advice of the International Electrotechnical Commission Subcommittee 62B (Diagnostic Imaging Equipment) Maintenance Team 38 (Computed Tomography). This 58 report is based upon measurements in accordance with IEC 60601-2-44.

The Computed Tomography X-ray dose report is based on the SOP class of “X-ray Radiation Dose SR”. 60 Specific templates for the recording of the dose and the acquisition parameters in a CT environment have been developed. 62

64

Supplement 127: CT Radiation Dose Reporting (Dose SR) Page 4

66

68

70

72

Changes to NEMA Standards Publication PS 3.3-2007

Digital Imaging and Communications in Medicine (DICOM) 74

Part 3: Information Object Definitions

76

Supplement 127: CT Radiation Dose Reporting (Dose SR) Page 5

Item #01: Change PS3.3 Section A.35.8.3.1.1: 76

A.35.8.3.1 X-ray Radiation Dose SR IOD Content Constraints 78

A.35.8.3.1.1 Template The document may be constructed from Baseline TID 10001 "Projection X-ray Radiation Dose " or 80 Baseline TID 10011 "CT Radiation Dose" (defined in PS3.16) invoked at the root node.

Note: This IOD may be used with other Templates defined for Dose Reporting. Such other Templates may be 82 specialized for specific modalities or future dose measurement techniques.

84

Supplement 127: CT Radiation Dose Reporting (Dose SR) Page 6

Item #02: Change PS3.3 Section A.35.8.3.1.3: 86

A.35.8.3.1.3 Relationship Constraints …… 88

Table A.35.8-2

RELATIONSHIP CONTENT CONSTRAINTS FOR X-RAY RADIATION DOSE SR IOD 90

Source Value Type Relationship Type (Enumerated Values)

Target Value Type

… … …. CONTAINER HAS OBS CONTEXT DATETIME, CODE, TEXT,

UIDREF, PNAME … … ….

Change PS 3.3, C.8.15.3.8 92

C.8.15.3.8 CT Exposure Macro Table C.8-124 specifies the attributes of the CT Exposure Functional Group Macro. 94

Table C.8-124 CT EXPOSURE MACRO ATTRIBUTES 96

Attribute Name Tag Type Attribute Description …

Note: The dose that a patient receives in a given procedure should be found in the Radiation Module 98 of the relevant Modality Performed Procedure Step IOD may be reported in one or more instances of the Radiation Dose Report SOP Class using the CT Radiation Dose Template TID 10011. 100

102

104

Supplement 127: CT Radiation Dose Reporting (Dose SR) Page 7

104

106

Changes to NEMA Standards Publication PS 3.16-2007 108

Digital Imaging and Communications in Medicine (DICOM)

Part 16: Content Mapping Resource 110

Supplement 127: CT Radiation Dose Reporting (Dose SR) Page 8

Item #03: Add new Section to Annex A

CT RADIATION DOSE SR IOD TEMPLATES 112

The templates that comprise the CT Radiation Dose SR are interconnected as in Figure A-x.1

114

Figure A.x-1: CT Radiation Dose SR IOD Template Structure 116

TID 10011 CT Radiation Dose 118

This template defines a container (the root) with subsidiary content items, each of which corresponds to a single CT X-ray irradiation event entry. There is a defined recording observer (the system or person 120 responsible for recording the log, generally the system). Accumulated values shall be kept for a whole Study or at least a part of a Study, if the Study is divided in the workflow of the examination, or a performed 122 procedure step. Multiple CT Radiation Dose objects may be created for one Study.

TID 10011 124 CT RADIATION DOSE

Type: Extensible 126

NL Rel with Parent

VT Concept Name VM Req Type

Condition Value Set Constraint

1 CONTAINER EV (113701, DCM, “X-ray Radiation Dose Report”)

1 M

2 > HAS CONCEPT MOD

CODE EV (121058, DCM, ”Procedure reported”)

1 M EV (P5-08000,SRT, “Computed Tomography X-ray”)

3 > INCLUDE DTID (1002) Observer Context

1-n M

4 > HAS OBS CONTEXT

DATETIME EV (113809, DCM, “Start of X-ray Irradiation”)

1 M

TID 10011 CT Radiation Dose

TID 1002 Observer Context

TID 10012 CT Accumulated Dose Data

TID 10013 CT Irradiation Event Data

Supplement 127: CT Radiation Dose Reporting (Dose SR) Page 9

5 > HAS OBS CONTEXT

DATETIME EV (113810, DCM, “End of X-ray Irradiation”)

1 M

6 > HAS OBS CONTEXT

CODE EV (113705, DCM, “Scope of Accumulation”)

1 M DCID (10000) Scope of Accumulation

7 >> HAS PROPERTIES

UIDREF DCID (10001) UID Types

1 M

8 > CONTAINS INCLUDE DTID (10012) CT Accumulated Dose Data

1 M

9 > CONTAINS INCLUDE DTID (10013) CT Irradiation Event Data

1-n M

10 > CONTAINS TEXT EV (121106, DCM, “Comment”)

1 U

Content Item Descriptions 128

Row 3 The observer context may include both a Person Observer identification, as well as the identity of the equipment providing the values for the irradiation event (Device Observer identification), if not inherited.

Row 4 Start, Date Time of the first CT Irradiation Event of the accumulation Row 5 End, Date Time of the last CT Irradiation Event of the accumulation

TID 10012 CT Accumulated Dose Data 130

This general template provides detailed information on CT X-ray dose value accumulations over several irradiation events from the same equipment and over the scope of accumulation specified for the report 132 (typically a Study or a Performed Procedure Step).

134

TID 10012 CT ACCUMULATED DOSE DATA 136

Type: Extensible NL Rel with

Parent VT Concept Name VM Req

Type Condition Value Set Constraint

1 CONTAINER EV (113811, DCM, ”CT Accumulated Dose Data”)

1 M

2 > CONTAINS NUM EV (113812, DCM, “Total Number of Irradiation Events”)

1 M Units = EV ({events} UCUM, “events”)

3 > CONTAINS NUM EV (113813, DCM, “CT Dose Length Product Total”)

1 M Units = EV (mGycm, UCUM, “mGycm”)

4 > CONTAINS NUM EV (113814, DCM, “CT Effective Dose Total”)

1 U Units = EV (mSv, UCUM, “mSv”)

5 >> HAS PROPERTIES

TEXT EV (121406,DCM, “Reference Authority”)

1 MC XOR row 6

Supplement 127: CT Radiation Dose Reporting (Dose SR) Page 10

6 >> HAS PROPERTIES

CODE EV (121406,DCM, “Reference Authority”)

1 MC XOR row 5 DCID (10015) CT Dose Reference Authority

7 >> HAS CONCEPT MOD

CODE EV (G-C036,SRT, “Measurement Method”)

1 M DCID (10011) Effective Dose Evaluation Method

8 >> HAS PROPERTIES

TEXT EV (113815,DCM, “Patient Model”)

1 MC IF the value of row 7 equals (113800, DCM, “DLP to E conversion via MC computation”) or equals (113801, DCM, “CTDIfreeair to E conversion via MC computation”)

9 >> HAS PROPERTIES

CONTAINER EV (113816, DCM, “Condition Effective Dose measured”)

1 MC IF the value of row 7 equals (113802, DCM, “DLP to E conversion via measurement”) or equals (113803, DCM, “CTDIfreeair to E conversion via measurement”)

10 >>> CONTAINS TEXT EV (113817,DCM, “Effective Dose Phantom Type”)

1 M

11 >>> CONTAINS TEXT EV (113818, DCM, “Dosimeter Type”)

1 M

12 > CONTAINS TEXT EV (121106, DCM, “Comment”)

1 U

138

Content Item Descriptions

Row 2 Total Number of CT irradiation events . A CT irradiation event is one continuous irradiation procedure and is defined through consistent acquisition parameters. In the case of dose modulation the calculations are based on the effective parameters (e.g. the effective mA recorded in the Mean X-ray Tube Current), and these acquisition parameters are consistent.

Row 3 The Dose Length Product (DLP) is calculated for every irradiation event. The Dose Length Product Total is the sum of the DLP values. The calculation is based on the CTDIvol result of each irradiation event.

Row 4 Effective dose (E, in units of mSv) evaluated as a total over the scope is defined in Row 6 of template TID 10011. Effective dose is defined by the reference in Rows 5 or 6 of this template. It may be calculated from a product of DLP and an ‘Effective Dose Conversion Factor’ (E/DLP). Or it may be calculated from a product of the Mean CTDIfree air and the ratio E/CTDIfree air. The ratios E/DLP or E/CTDIfree air may be evaluated either from computer simulations applying Monte Carlo (MC) sampling techniques or from dosimetric measurements in an anthropomorphic phantom, e.g., the Alderson-Rando phantom.. The specific method used is identified in Rows 7 through 11.

Row 5 - 6 Reference of the base publication defining the Effective Dose, either as a coded value, or a textual bibliographic reference. ICRP Publication 60 shall be referenced using the assigned coded value.

Row 7 Description of the method used for Effective Dose evaluations. Row 8 Description of the reference-patient mathematical or computational model used when

Effective Dose is derived via Monte Carlo simulations of radiation transport in such models. Examples of publications which specify particular reference patient models are NUREG/CR-1159, ORNL/NUREG/TM-367 (1980); NRPB-R186 (1985); GSF-Bericht S-885 (1986); Fill et al., Health Physics Vol. 86 (3): 253-272 (2004).

Row 9 Description of the condition Effective Dose measured

Supplement 127: CT Radiation Dose Reporting (Dose SR) Page 11

140

142

TID 10013 CT Irradiation Event Data This template conveys the dose and equipment parameters of a single irradiation event. 144

A CT irradiation event is the occurrence of irradiation being applied to a patient in single continuous time-frame between the start (release) and the stop (cease) of the irradiation. Any on-off switching of the 146 radiation source during the event shall not be treated as separate events; rather the event includes the time between start and stop of radiation as triggered by the user, e.g., a single sequence of scanning 148 comprised of multiple slices acquired with successive tube rotations and table increments shall be treated as a single irradiation event. Depending on the examination workflow and the anatomical target region the 150 CT irradiation event data may split into multiple instances of this template for better dose estimation. The irradiation event is the “smallest” information entity to be recorded in the realm of Radiation Dose reporting. 152 Individual Irradiation Events are described by a set of accompanying physical parameters that are sufficient to understand the “quality” of irradiation that is being applied. This set of parameters may be 154 different for the various types of equipment that are able to create irradiation events.

TID 10013 156 CT IRRADIATION EVENT DATA

Type: Extensible 158

NL Rel with Parent

VT Concept Name VM Req Type

Condition Value Set Constraint

1 CONTAINER EV (113819, DCM, ”CT Acquisition”)

1 M

2 > CONTAINS TEXT EV (125203, DCM, “Acquisition Protocol”)

1 U

3 > CONTAINS CODE EV (123014 , DCM, ”Target Region”)

1 M DCID (4030) CT and MR Anatomy Imaged

4 > CONTAINS CODE EV (113820, DCM, “CT Acquisition Type”)

1 M DCID (10013) CT Acquisition Types

5 > CONTAINS CODE (G-C232, SRT, “Procedure Context”)

1 U DCID (10014) Contrast Imaging Technique

6 > CONTAINS UIDREF EV (113769, DCM, “Irradiation Event UID”)

1 M

7 > CONTAINS NUM EV (113821, DCM, “X-ray Filter Aluminium Equivalent”)

1 U Units = EV (mm, UCUM, “mm”)

8 > CONTAINS CONTAINER EV (113822, DCM, “CT Acquisition Parameters”)

1 M

9 >> CONTAINS NUM EV (113824, DCM, “Exposure Time”)

1 M Units = EV (s, UCUM, “s”)

10 >> CONTAINS NUM EV (113825, DCM, “Scanning Length”)

1 M Units = EV (mm, UCUM, “mm”)

11 >> CONTAINS NUM EV (113826, DCM, “Nominal Single Collimation Width”)

1 M Units = EV (mm, UCUM, “mm”)

12 >> CONTAINS NUM EV (113827, DCM, “Nominal Total Collimation Width”)

1 M Units = EV (mm, UCUM, “mm”)

Supplement 127: CT Radiation Dose Reporting (Dose SR) Page 12

13 >> CONTAINS NUM EV (113828, DCM, “Pitch Factor”)

1 MC IF row 4 equals (P5-08001, SRT, “Spiral Acquisition”) or equals (113804, DCM, “Sequenced Acquisition”)

Units = EV ({ratio}, UCUM, “ratio”)

14 >> CONTAINS NUM EV (113823, DCM, “Number of X-ray Sources”)

1 M Units = EV ({X-ray sources}, UCUM, “X-ray sources”)

15 >> CONTAINS CONTAINER EV (113831, DCM, “CT X-ray Source Parameters”)

1-n M

16 >>> CONTAINS TEXT EV (113832, DCM, “Identification Number of the X-ray Source”)

1 M

17 >>> CONTAINS NUM EV (113733, DCM, “KVP”)

1 M Units = EV (kV, UCUM, “kV”)

18 >>> CONTAINS NUM EV (113833, DCM, “Maximum X-ray Tube Current”)

1 M Units = EV (mA, UCUM, “mA”)

19 >>> CONTAINS NUM EV (113734, DCM, “Mean X-ray Tube Current”

1 M Units = EV (mA, UCUM, “mA”)

20 >>> CONTAINS NUM EV (113834, DCM, “Exposure Time per Rotation”)

1 MC IF row 4 does not equal (113805, DCM, “Constant Angle Acquisition”)

Units = EV (s, UCUM, “s”)

21 > CONTAINS CONTAINER EV (113829, DCM, “CT Dose”)

1 MC IF row 4 does not equal (113805, DCM, “Constant Angle Acquisition”)

22 >> CONTAINS NUM EV (113830, DCM, “Mean CTDIvol ”)

1 M Units = EV (mGy, UCUM, “mGy”)

23 >> CONTAINS CODE EV (113835, DCM, “CTDIw Phantom Type”)

1 M DCID (4052) Phantom Devices

24 >> CONTAINS NUM EV (113836, DCM, “CTDIfreeair Calculation Factor”)

1 U Units = EV (mGy/mAs, UCUM, “mGy/mAs”)

25 >> CONTAINS NUM EV (113837, DCM, “Mean CTDIfreeair”)

1 U Units = EV (mGy, UCUM, “mGy”)

26 >> CONTAINS NUM EV (113838, DCM, “DLP”)

1 M Units = EV (mGycm, UCUM, “mGycm”)

27 >> CONTAINS NUM EV (113839, DCM, “Effective Dose”)

1 U Units = EV (mSv, UCUM, “mSv”)

28 >>> HAS CONCEPT MOD

CODE EV (G-C036, SRT, “Measurement Method“)

1 MC IF row 27 is present DCID (10011) “Effective Dose Evaluation Method”)

29 >>>>

HAS PROPERTIES

NUM EV (113840, DCM, “Effective Dose Conversion Factor”)

1 MC IF row 28 is present and equals (113800, DCM, “DLP to E conversion via MC computation”) or equals (113802, DCM, “DLP to E conversion via measurement”)

Units = EV (mSv/mGycm, UCUM, “mSv/mGycm”)

30 > CONTAINS TEXT EV (121106, DCM, “Comment”)

1 U

Supplement 127: CT Radiation Dose Reporting (Dose SR) Page 13

Content Item Descriptions 160

Row 2 User-defined type of clinical acquisition protocol for creating images or image-derived measurements. May be taken from Protocol Name (0018,1030) or from Performed Procedure Step Description (0040,0254).

Row 3 The target region is the anatomy exposed. Row 4 Description of the method used during acquisition of this CT irradiation event, may be

derived from Acquisition Type (0018,9302). Row 5 The acquisition was performed with or without contrast medium application. Row 7 Thickness of an equivalent filter constructed from aluminum. Row 9 Total time the patient has received X-ray exposure during the irradiation event. Row 10 For Spiral scanning, the scanning length is normally the table travel in mm during the

tube loading. For Sequenced scanning, the scanning length is the table travel between consecutive scans times the number of scans. For Stationary and Free scanning, the scanning length is the nominal width of the total collimation.

Row 11 The value of the nominal width (referenced to the location of the isocenter along the z axis) of a single collimated slice in mm.

Row 12 The value of the nominal width (referenced to the location of the isocenter along the z axis) of the nominal total collimation in mm over the area of active X-ray detection (z-coverage).

Row 13 Pitch Factor: For Spiral Acquisition, the Pitch Factor is the ratio of the Table Feed per Rotation to the Nominal Total Collimation Width. For Sequenced Acquisition, the Pitch Factor is the ratio of the Table Feed per single sequenced scan to the Nominal Total Collimation Width.

Row 15 CT X-ray source parameters related to the acquisition. For each X-ray source an item must be present.

Row 16 Identification Number of the X-ray source. Identifies the particular X-ray source (in a multi-source CT system) for which the set of X-ray source parameter values is reported.

Row 17 KVP value as measured/recorded by system. Row 19 Mean tube current as measured/recorded by system. Row 20 Exposure time as measured/recorded by the system per rotation. Row 21 CT Dose for one acquisition Row 22 “Mean CTDIvol” refers to the average value of the CTDIvol applied within this acquisition.

CTDIvol is the volume CTDIw, where CTDIw is the weighted computed tomography dose index 100 as defined in IEC 60601-2-44. For Sequenced and Spiral scanning, CTDIvol = CTDIw/Pitch Factor. For Stationary and Free scanning, CTDIvol = CTDIw × Cumulative Exposure Time/ Exposure Time Per Rotation. See also CTDIvol (0018,9345) and Spiral Pitch Factor (0018,9311) in the Enhanced CT Information Object Description (PS 3.3).

Row 23 The type of phantom used for CTDI measurement according to IEC 60601-2-44 (e.g. Head 16 cm diameter PMMA, Body 32 cm diameter PMMA).

Row 24 The CTDIfree air Calculation Factor is the CTDIfree air per mAs, expressed in units of mGy/mAs. The CTDIfree air Calculation Factor may be used in one method calculating Dose. For example, for this acquisition, Effective Dose = Mean X-ray Tube Current × Cumulative Exposure Time × CTDIfree air Calculation Factor × (Effective Dose/ CTDIfree air).

Supplement 127: CT Radiation Dose Reporting (Dose SR) Page 14

Row 25 Mean CTDIfree air is the mean CTDI for this acquisition, evaluated free-in-air according to IEC 60601-2-44. Mean CTDIfree air = Mean X-ray Tube Current × Cumulative Exposure Time × CTDIfree air Calculation Factor. The CTDIfree air may be used in one method of calculating Effective Dose.

Row 26 For Spiral scanning, DLP = CTDIvol × Scanning Length. For Sequenced scanning, DLP = CTDIvol × Nominal Total Collimation Width × Cumulative Exposure Time / Exposure Time per Rotation. For Stationary and Free scanning, DLP = CTDIvol × Nominal Total Collimation Width (according to IEC 60601-2-44).

Row 27 Effective Dose in mSv of the single continuous time-frame of the irradiation computed as described in TID 10012.

Row 29 The Effective Dose Conversion Factor is the ratio of the Effective Dose to the DLP, expressed in units of mSv/mGycm, and it is used as a factor in one method of estimating Effective Dose. Monte Carlo Simulations (or dosimetric measurements in an anthropomorphic phantom, e.g., the Alderson-Rando phantom) may be used as a basis for the evaluation of Effective Dose Conversion Factors.

Supplement 127: CT Radiation Dose Reporting (Dose SR) Page 15

Item #04: Add the following CID’s to Part 16 Annex B: 162

CID 10011 Effective Dose Evaluation Method

Context ID 10011 164 Effective Dose Evaluation Method

Type: Extensible Version: 20071031 166

Coding Scheme Designator (0008,0102)

Code Value (0008,0100)

Code Meaning (0008,0104)

DCM 113800 DLP to E conversion via MC computation DCM 113801 CTDIfreeair to E conversion via MC computation DCM 113802 DLP to E conversion via measurement DCM 113803 CTDIfreeair to E conversion via measurement

168

CID 10013 CT Acquisition Type

Context ID 10013 170 CT Acquisition Type

Type: Extensible Version: 20071031 172

Coding Scheme Designator (0008,0102)

Code Value (0008,0100)

Code Meaning (0008,0104)

DCM 113804 Sequenced Acquisition SRT P5-08001 Spiral Acquisition DCM 113805 Constant Angle Acquisition DCM 113806 Stationary Acquisition DCM 113807 Free Acquisition

CID 10014 Contrast Imaging Technique 174

Context ID 10014 Contrast Imaging Technique 176

Type: Extensible Version: 20071031

Coding Scheme Designator (0008,0102)

Code Value (0008,0100)

Code Meaning (0008,0104)

SRT P5-00100 Diagnostic radiography with contrast media SRT P5-0808E CT without contrast

178

Supplement 127: CT Radiation Dose Reporting (Dose SR) Page 16

CID 10015 CT Dose Reference Authorities 180

Context ID 10015 CT Dose Reference Authorities 182

Type: Extensible Version: 20071031

Coding Scheme Designator (0008,0102)

Code Value (0008,0100)

Code Meaning (0008,0104)

DCM 113808 ICRP Pub 60 184

186

Item #05: Add the following Definitions to Annex D

DICOM Code Definitions (Coding Scheme Designator “DCM” Coding Scheme Version “01”) 188

Code Value

Code Meaning Definition

… 113800 DLP to E conversion via MC

computation Effective Dose evaluation from the product of Dose Length Product (DLP) and the Effective Dose Conversion Factor (E/DLP in units of mSv/mGy-cm), where the ratio is derived by means of Monte Carlo computations.

113801 CTDIfreeair to E conversion via MC computation

Effective Dose evaluation from the product of the Mean CTDIfree air and the ratio E/CTDIfree air (mSv/mGy), where the ratio is derived by means of Monte Carlo computations

113802 DLP to E conversion via measurement Effective Dose evaluation from the product of Dose Length Product (DLP) and the Effective Dose Conversion Factor (E/DLP in units of mSv/mGy-cm), where the ratio is derived by means of dosimetric measurements with an anthropomorphic phantom

113803 CTDIfreeair to E conversion via measurement

Effective Dose evaluation from the product of the Mean CTDIfree air and the ratio E/CTDIfree air (mSv/mGy), where the ratio is derived by means of dosimetric measurements with an anthropomorphic phantom

Supplement 127: CT Radiation Dose Reporting (Dose SR) Page 17

113804 Sequenced Acquisition The CT acquisition was performed by acquiring single or multi detector data while rotating the source about the gantry while the table is not moving. Additional slices are acquired by incrementing the table position and again rotating the source about the gantry while the table is not moving.

113805 Constant Angle Acquisition The CT acquisition was performed by holding the source at a constant angle and moving the table to obtain a projection image (e.g. localizer).

113806 Stationary Acquisition The CT acquisition was performed by holding the table at a constant position and acquiring multiple slices over time at the same location.

113807 Free Acquisition The CT acquisition was performed while rotating the source about the gantry while the table movement is under direct control of a human operator or under the control of an analysis application (e.g. fluoro).

113808 ICRP Pub 60 Reference authority 1990 Recommendations of the International Commission on Radiological Protection (ICRP Publication 60, published as the Annals of the ICRP Vol. 21, No. 1-3, Pergamon Press, 1991)

113809 Start of X-ray Irradiation Start, DateTime of the first X-ray Irradiation Event of the accumulation within a Study

113810 End of X-ray Irradiation End, DateTime of the last X-ray Irradiation Event of the accumulation within a Study

113811 CT Accumulated Dose Data X-ray dose accumulated over multiple CT irradiation events, e.g., for a study or a performed procedure step.

113812 Total Number of Irradiation Events Total number of events during the defined scope of accumulation

113813 CT Dose Length Product Total The total dose length product defined scope of accumulation

113814 CT Effective Dose Total The total Effective Dose at the defined scope of accumulation

113815 Patient Model Identification of the reference-patient model used when Effective Dose is evaluated via Monte Carlo calculations or from a Dose Length Product conversion factor based on Monte Carlo calculations

113816 Condition Effective Dose measured References the physical phantom and the type of dosimeter used when measurements are done to establish Effective Dose Conversion Factors (E/DLP) or ratios E/CTDIfree air

113817 Effective Dose Phantom Type Type of Effective Dose phantom used

Supplement 127: CT Radiation Dose Reporting (Dose SR) Page 18

113818 Dosimeter Type Type of dosimeter used 113819 CT Acquisition General description of the CT Irradiation event 113820 CT Acquisition Type Method of the CT acquisition 113821 X-ray Filter Aluminum Equivalent Thickness of an equivalent filter in mm in

Aluminum 113822 CT Acquisition Parameters General description of the acquisition parameters 113823 Number of X-ray Sources Number of X-ray sources 113824 Exposure Time Total time the patient has received X-ray

exposure during the irradiation event 113825 Scanning Length Length of the table travel during the entire tube

loading, according to IEC 60601-2-44 NOTE: Scanning Length might be longer than the programmed acquisition length

113826 Nominal Single Collimation Width The value of the nominal width referenced to the location of the isocenter along the z axis of a single row of acquired data in mm

113827 Nominal Total Collimation Width The value of the nominal width referenced to the location of the isocenter along the z axis of the total collimation in mm over the area of active X-ray detection

113828 Pitch Factor For Spiral scanning: Pitch Factor = (Table Feed per Rotation (mm))/(Nominal Total Collimation Width (mm)) For Sequenced scanning: Pitch Factor = (Table Feed per single Sequenced scan (mm))/(Nominal Total Collimation Width (mm))

113829 CT Dose General description of CT dose values 113830 Mean CTDIvol “Mean CTDIvol” refers to the average value of the

CTDIvol associated with this acquisition. 113831 CT X-ray Source Parameters Identification, tube-potential, tube-current, and

exposure-time parameters associated with an X-ray source during an acquisition.

113832 Identification of the X-ray Source Identifies the particular X-ray source (in a multi-source CT system) for which the set of X-ray source parameter values is reported.

113833 Maximum X-ray Tube Current Maximum X-ray tube current 113834 Exposure Time per Rotation The exposure time for one rotation of the source

around the object in s 113835 CTDIw Phantom Type A label describing the type of phantom used for

CTDIW measurement according to IEC 60601-2-44 (Head 16 cm diameter PMMA, Body 32 cm diameter PMMA)

Supplement 127: CT Radiation Dose Reporting (Dose SR) Page 19

113836 CTDIfreeair Calculation Factor The CTDIfree air Calculation Factor is the CTDIfree air per mAs, expressed in units of mGy/mAs. The CTDIfree air Calculation Factor may be used in one method calculating Dose.

113837 Mean CTDIfreeair The average value of the free-in-air CTDI associated with this acquisition.

113838 DLP Dose Length Product (DLP), expressed in mGy-cm, is an index characterizing the product of the CTDIvol and the length scanned. For Spiral scanning, DLP = CTDIvol × Scanning Length. For Sequenced scanning, DLP = CTDIvol × Nominal Total Collimation Width × Cumulative Exposure Time / Exposure Time per Rotation. For Stationary and Free scanning, DLP = CTDIvol × Nominal Total Collimation Width.

113839 Effective Dose Effective dose in mSv 113840 Effective Dose Conversion Factor Effective Dose per DLP, reference value for

Effective Dose calculation, expressed in mSv/mGycm

190

Supplement 127: CT Radiation Dose Reporting (Dose SR) Page 20

190

Item #06: Code Definitions extended 192

DICOM Code Definitions (Coding Scheme Designator “DCM” Coding Scheme Version “01”) Code Value

Code Meaning Definition

113690 IEC Head Dosimetry Phantom A label describing the type of Phantom used for CTDI measurement in head modes according to IEC 60601-2-44 (Head 16 cm diameter Polymethyl methacrylate PMMA)

113691 IEC Body Dosimetry Phantom A label describing the type of Phantom used for CTDI measurement in body modes according to IEC 60601-2-44 (Body 32cm diameter Polymethyl methacrylate PMMA)

194

196

Supplement 127: CT Radiation Dose Reporting (Dose SR) Page 21

196

Item #07: Extend new reference to PS3.16 section 2 “Normative references” 198

RFC 3066 Tags for the Identification of Languages, Internet Engineering Task Force 200 IEC 60601-2-44 Medical Electrical Equipment – Part 2-44: Particular Requirements for the Safety of X-ray Equipment for Computed Tomography 202

204

Supplement 127: CT Radiation Dose Reporting (Dose SR) Page 22

204

206

208

Changes to NEMA Standards Publication PS 3.17-2007

Digital Imaging and Communications in Medicine (DICOM) 210

Part 17: Explanatory Information

212

Supplement 127: CT Radiation Dose Reporting (Dose SR) Page 23

Item #08: Add text to “Radiation Dose Reporting Use Cases Annex AA” 212

ANNEX AA: Radiation Dose Reporting Use Cases (Informative)

AA.2 DEFINITIONS 214 ..

Accumulated Dose Values 216

Accumulated Dose Values describe the integrated results of performing multiple irradiation events. The scope of accumulation is typically a study or a performed procedure step. Multiple Radiation Dose 218 objects may be created for one Study or one Radiation Dose object may be created for multiple performed procedures. 220

105

ANEXO B -- Código Fonte - Trecho do Cód.Ferramenta Geradora de CSV/RDSR

#include "GenIODCT.hpp"

extern "C" {#include <unistd.h>}

#include <iostream>#include <fstream>

//Log#include "log/Log.hpp"

//Scan Folder#define BOOST_FILESYSTEM_NO_DEPRECATED#include "boost/filesystem/operations.hpp"#include "boost/filesystem/path.hpp"#include "boost/filesystem/convenience.hpp"#include "boost/progress.hpp"

//parser#include "dicom/InitializeDICOM.h"#include "dicom/File.h"#include "dicom/IOD.h"#include "dicom/DataElement.h"#include "dicom/SequenceItem.h"#include "dicom/dataelement/SQDataElement.h"#include <algorithm>#include <boost/scoped_ptr.hpp>

#include <boost/algorithm/string/split.hpp>#include <boost/algorithm/string/trim.hpp>

#include "dimp/DCM2Dimp.hpp"

//persistence//#include "util/sdsqlite.h"//#include "database/database.h"//#include "database/data_object/cliente.h"

//rand#include <time.h>

//boost date#include <boost/date_time/posix_time/posix_time.hpp>#include <boost/date_time/posix_time/posix_time_io.hpp>

//boost split#include <boost/algorithm/string.hpp>

//include rdsr_template - protobuf#include "rdsr_template_ct.pb.h"

namespace fs = boost::filesystem;

struct strctEquipment { std::string mManufacturer; std::string mInstitutionName; std::string mInstitutionAddress; std::string mStationName; std::string mInstitutionalDepartmentName; std::string mManufacturerModelName; std::string mDeviceSerialNumber;

std::string mSoftwareVersions; std::string mGantryID; std::string mSpatialResolution; std::string mDateofLastCalibration; std::string mTimeofLastCalibration;};

struct strctPatient { std::string mPatientName; std::string mPatientID; std::string mPatientBirthDate; std::string mPatientSex; std::string mPatientAge; std::string mPatientWeight;};

struct strctImage { std::string mSOPInstanceUID; std::string mSpecificCharacterSet; std::string mInstanceCreationDate; std::string mInstanceCreationTime; std::string mInstanceCreatorUID; std::string mInstanceNumber; std::string mPatientOrientation; std::string mContentDate; std::string mContentTime; std::string mImageType; std::string mAcquisitionNumber; std::string mIrradiationEventUID; std::string mImageOrientationPatient; std::string mImagePositionPatient; std::string mSliceThickness; std::string mSliceLocation; std::string mKVP; std::string mScanOptions; std::string mDataCollectionDiameter; std::string mDataCollectionCenterPatient; std::string mReconstructionDiameter; std::string mReconstructionTargetCenter; std::string mDistanceSourcetoDetector; std::string mDistanceSourcetoPatient; std::string mGantryDetectorTilt; std::string mTableHeight; std::string mRotationDirection; std::string mExposureTime; std::string mXRayTubeCurrent; std::string mExposure; std::string mExposureinusa; std::string mFilterType; std::string mFocalSpot; std::string mConvolutionKernel; std::string mRevolutionTime; std::string mSingleCollimationWidth; std::string mTotalCollimationWidth; std::string mTableSpeed; std::string mTableFeedperRotation; std::string mSpiralPitchFactor; std::string mExposureModulationType; std::string mEstimatedDoseSaving; std::string mCTDIvol; std::string mCTDIPhantomTypeCodeSequence; std::string mFilterMaterial;

std::string mRows; std::string mColumns;};

struct strctSeries { std::string mModality; std::string mSeriesInstanceUID; std::string mSeriesNumber; std::string mSeriesDate; std::string mSeriesTime; std::string mProtocolName; std::string mSeriesDescription; std::string mOperatorsName; std::string mBodyPartExamined; std::string mPatientPosition; std::vector<strctImage> mImages;};

struct strctStudy { std::string mStudyInstanceUID; std::string mStudyDate; std::string mStudyTime; std::string mReferringPhysiciansName; std::string mStudyID; std::string mAccessionNumber; std::string mStudyDescription; strctEquipment mEquipment; strctPatient mPatient; std::map<std::string, strctSeries> mSeries;};

/*class ShowDataElement{ public: void operator()(const std::pair<cyc::dicom::Tag, cyc::dicom::DataElement*>& dataElementValuesPair) { cyc::dicom::DataElement *de = dataElementValuesPair.second; if(de && de->getLength()) { if(de->getVr().compare("SQ") == 0) { for(int i = 0; i < tabulationCount; ++i) std::cout << "\t"; std::cout << "(" << de->getTag().toString() << ") - " << de->getType() << " - " << de->getVr() << " " << de->getName() << std::endl; std::vector<cyc::dicom::SequenceItem*>* sequenceItens = dynamic_cast<cyc::dicom::SQDataElement*>(de)->getSequenceItemValue(); for(std::vector<cyc::dicom::SequenceItem*>::iterator it = sequenceItens->begin(); it != sequenceItens->end(); ++it) { std::map<cyc::dicom::Tag, cyc::dicom::DataElement*>* dataElementsValue = (*it)->getDataElementsValues(); std::map<cyc::dicom::Tag, cyc::dicom::DataElement*>::const_iterator deIt = dataElementsValue->begin(); std::map<cyc::dicom::Tag, cyc::dicom::DataElement*>::const_iterator deEnd = dataElementsValue->end(); ++tabulationCount; std::for_each(deIt, deEnd, ShowDataElement()); --tabulationCount; } }

else { for(int i = 0; i < tabulationCount; ++i) std::cout << "\t"; std::cout << "(" << de->getTag().toString() << ") " << de->getVr() << " " << de->getName(); if(de->getName().compare("pixelData")) std::cout << ": " << de->getValue().at(0) << std::endl; else std::cout << std::endl; } } }

private: static int tabulationCount; }; */

static void printValue(const std::vector<std::string>& v, std::ostream& out) { unsigned int i, count; count = v.size() - 1; for (i = 0; i < v.size(); i++) { if (i == 0) out << "("; out << v.at(i); (i == count) ? out << ")" : out << " "; }}

static void mergeValue(const std::vector<std::string>& v, std::string* s) { unsigned int i, count; count = v.size() - 1; for (i = 0; i < v.size(); i++) { std::string temp = v.at(i); boost::trim(temp); s->append(temp); if (i != count) s->append(" "); }}

static bool printProcess = false;//define a empty stringstd::string EMPTY_STRING("-");

static bool populateValue(cyc::dicom::IOD *iod, const cyc::dicom::Tag& tag, std::string& value) {

bool fail = false;

cyc::dicom::DataElement *de; de = iod->getDataElementFromDictionary(tag); if (de != NULL && de->getLength()) { mergeValue(de->getValue(), &value); } else { value = EMPTY_STRING; fail = true; }

if (de != NULL && printProcess) { std::cout << ".Tag: (" << de->getTag().toString() << ")\t" << "VR:"

<< de->getVr() << "\t" << "Type:" << de->getType() << "\t" << "Length:" << de->getLength() << "\t" << "Length:" << de->getValue().size() << "\t - .......\t" << "Value:" << value << "\n"; } else { std::cout << "#Tag: " << tag.toString() << " - \t \t \t \t \t \t - ....... \tValue: --- \n"; }

return fail;

}

static bool sortfc(const strctImage& a, const strctImage& b) { return (boost::lexical_cast<int>(a.mInstanceNumber) < boost::lexical_cast< int>(b.mInstanceNumber));}

namespace cycRDSR {namespace RDSR {

GenIODCT::GenIODCT() {}

GenIODCT::~GenIODCT() {}

void GenIODCT::StartUp(const std::string& file_path, std::map<std::string, std::string> tag_map) {

//setting the internal vars m_tag_map = tag_map; m_study_path = file_path;

cyc::util::Debug("GenIODCT") << "RDSR startup!" << cyc::util::EndLog;

//TODO: C_FIND & C_MOVE

//varrer o diretório e criar um list de files this->ScanDir(this->m_study_path, this->m_list_files);

this->ParseAllFiles();

/* -- database --*/ /* //std::cout << "Hello, world!\n"; Database* db; db = new Database(); std::cout << "Teste" << "\n"; Cliente *c = new Cliente(); //initialize random seed: srand ( time(NULL) );

c->setNome("Joe 01 08 06"); c->setIdade(rand() % 10 + 1); db->insereCliente(c); delete c;

std::vector<Cliente*> vector_cliente = db->listaClientes("Joe");

unsigned int i; for(i=0;i< vector_cliente.size(); i++)

std::cout << "Cliente (" << i << ")" << vector_cliente[i]->getNome() << " - Idade" << vector_cliente[i]->getIdade() << "\n";

delete db;*/

}

void GenIODCT::ScanDir(std::string path_dir, std::vector<std::string>& list_file) {

std::cout << "\n\n============= SCAN ============\nIn: " << path_dir << "\n\n";

bool onlyDCMFiles = true; std::vector<std::string> list_subdir;

//varrer o diretório //using sample: http://www.boost.org/doc/libs/1_39_0/libs/filesystem/example/simple_ls.cpp

//boost::progress_timer t( std::clog );

fs::path full_path(fs::initial_path<fs::path>()); full_path = fs::system_complete(fs::path(path_dir));

unsigned long file_count = 0; unsigned long dir_count = 0; unsigned long other_count = 0; unsigned long err_count = 0;

if (!fs::exists(full_path)) { //std::cout << "\nNot found: " << full_path.file_string() << std::endl;

}

if (fs::is_directory(full_path)) { //std::cout << "\nIn directory: "<< full_path.directory_string() << "\n\n";

fs::directory_iterator end_iter;

for (fs::directory_iterator dir_itr(full_path); dir_itr != end_iter; ++dir_itr) { try {

if (fs::is_directory(dir_itr->status())) { ++dir_count; //std::cout << dir_itr->path().filename() << " [directory]\n"; list_subdir.push_back(path_dir + dir_itr->path().filename()); // "/" } else if (fs::is_regular_file(dir_itr->status())) { ++file_count; //std::cout << dir_itr->path().filename() << "\n";

fs::path path_file(dir_itr->path().filename()); //std::cout << path_file.extension() << "\n"; if (path_file.extension() == ".dcm") list_file.push_back(path_dir + "/" + dir_itr->path().filename()); else { if (!onlyDCMFiles)

list_file.push_back(path_dir + "/" + dir_itr->path().filename()); }

} else { ++other_count; //std::cout << dir_itr->path().filename() << " [other]\n"; }

} catch (const std::exception & ex) { ++err_count; std::cout << dir_itr->path().filename() << " " << ex.what() << std::endl; } }

//std::cout << "\n" << file_count << " files\n" << dir_count << " directories\n" << other_count << " others\n" << err_count << " errors\n\n\n\n";

} else // must be a file { //std::cout << "\nFound: " << full_path.file_string() << "\n"; }

unsigned int i; std::vector<std::string>::size_type size = list_subdir.size();

for (i = 0; i < size; i++) { this->ScanDir(list_subdir[i], list_file); }

}

/** * @brief One line documentation * * A more detailed documentation * * @param arg1 the first function argument * @param arg2 the second function argument * * @return descrition for the function return value */void GenIODCT::ParseAllFiles() {

//initialize DICOM cyc::dicom::initializeDICOM();

std::cout << "The content of my \"list_of_files\" is: ";

std::vector<std::string>::size_type size = this->m_list_files.size();

//dir = file in wrong place std::string pathIgnoredFiles("./ignored_files/"); if (!boost::filesystem::exists(pathIgnoredFiles)) boost::filesystem::create_directory(pathIgnoredFiles);

//dir = temp (gbi file) std::string pathTemp("./temp/"); if (!boost::filesystem::exists(pathTemp)) boost::filesystem::create_directory(pathTemp);

//dir = outputs files std::string pathOutput("./output/"); if (!boost::filesystem::exists(pathOutput)) boost::filesystem::create_directory(pathOutput);

//READ THE STUDY'S FILE std::string elmStudyInstanceUID(""); struct strctStudy mStudy;

unsigned int i; for (i = 0; i < size; i++) {

std::cout << " * " << this->m_list_files[i] << "\n";

try {

cyc::dicom::File file; std::string path_file = this->m_list_files[i]; // path_study/name_file.ext cyc::dicom::IOD *iod = dynamic_cast<cyc::dicom::IOD*> (file.readFrom(path_file)); //

cyc::dicom::DataElement *de;

//DECLARATIONS - MAIN FIELDS std::string elmSOPClassUID; std::string tempElmStudyInstanceUID;

//checks if the IOD is CT IMAGE //0x0008,0x0016 de = iod->getDataElementFromDictionary(cyc::dicom::Tag(0x0008, 0x0016)); (de != NULL && de->getLength()) ? elmSOPClassUID = de->getValue().at(0) : elmSOPClassUID = EMPTY_STRING; boost::trim(elmSOPClassUID); if (elmSOPClassUID.compare(ClassUID::CT_Image_Storage) != 0) { //NOT IMAGE CT continue;// jump this file }

//Is that an intruse file? //0x0020,0x000D de = iod->getDataElementFromDictionary(cyc::dicom::Tag(0x0020, 0x000D)); (de != NULL && de->getLength()) ? tempElmStudyInstanceUID = de->getValue().at(0) : tempElmStudyInstanceUID = EMPTY_STRING; boost::trim(tempElmStudyInstanceUID);

if (i == 0) { //is it first dicom file? elmStudyInstanceUID = tempElmStudyInstanceUID; } else {

//Does it file has the same StudyInstaceUID?

if (elmStudyInstanceUID.compare(tempElmStudyInstanceUID) != 0) {

std::cout << "elmStudyInstanceUID: = " << elmStudyInstanceUID << "\n"; std::cout << "tempElmStudyInstanceUID: = " << tempElmStudyInstanceUID << "\n\n\n\n";

//remove this file of current directory std::cout << "path_file: = " << path_file << "\n"; //ex: /home/well/Documentos/HospUniversitario/PatienteTeste/1.2.840.113704.1.111.536.1340108957.12797.dcm std::vector<std::string> parts_of_path; boost::split(parts_of_path, path_file, boost::is_any_of("/")); std::string file_name = parts_of_path.back(); std::cout << "file name: = " << file_name << "\n"; //just remember (fs = boost:filesystem) fs::path src(path_file); fs::path dest(pathIgnoredFiles + file_name); //fs::copy_file(src,dest,fs::copy_option::overwrite_if_exists); //delete file //if (fs::exists(src)) // fs::remove(src); continue;// jump this file } }

//variables for each file /* -- GENERAL STUDY MODULE ATTRIBUTES */ //std::string elmStudyInstanceUID;// because I must assert read only files of same study std::string elmStudyDate, elmStudyTime, elmReferringPhysiciansName, elmStudyID; std::string elmAccessionNumber, elmStudyDescription; /* -- GENERAL SERIES MODULE ATTRIBUTES */ std::string elmModality, elmSeriesInstanceUID, elmSeriesNumber, elmSeriesDate; std::string elmSeriesTime, elmProtocolName, elmSeriesDescription, elmOperatorsName; std::string elmBodyPartExamined, elmPatientPosition; /* -- GENERAL EQUIPMENT MODULE ATTRIBUTES */ std::string elmManufacturer, elmInstitutionName, elmInstitutionAddress; std::string elmStationName, elmInstitutionalDepartmentName, elmManufacturerModelName; std::string elmDeviceSerialNumber, elmSoftwareVersions, elmGantryID; std::string elmSpatialResolution, elmDateofLastCalibration, elmTimeofLastCalibration; /* -- GENERAL IMAGE MODULE ATTRIBUTES */ std::string elmInstanceNumber, elmPatientOrientation, elmContentDate; std::string elmContentTime, elmImageType, elmAcquisitionNumber, elmIrradiationEventUID; /* -- GENERAL IMAGE PLANE MODULE ATTRIBUTES */ std::string elmImageOrientationPatient, elmImagePositionPatient; std::string elmSliceThickness, elmSliceLocation; /* -- GENERAL PATIENT MODULE ATTRIBUTES */ std::string elmPatientName, elmPatientID, elmPatientBirthDate; std::string elmPatientSex, elmPatientAge, elmPatientWeight; /* -- GENERAL CT IMAGE MODULE ATTRIBUTES */ std::string elmKVP, elmScanOptions, elmDataCollectionDiameter; std::string elmDataCollectionCenterPatient, elmReconstructionDiameter; std::string elmReconstructionTargetCenter, elmDistanceSourcetoDetector, elmDistanceSourcetoPatient; std::string elmGantryDetectorTilt, elmTableHeight,

elmRotationDirection; std::string elmExposureTime, elmXRayTubeCurrent, elmExposure; std::string elmExposureinusa, elmFilterType, elmFocalSpot; std::string elmConvolutionKernel, elmRevolutionTime, elmSingleCollimationWidth; std::string elmTotalCollimationWidth, elmTableSpeed, elmTableFeedperRotation; std::string elmSpiralPitchFactor, elmExposureModulationType, elmEstimatedDoseSaving; std::string elmCTDIvol, elmCTDIPhantomTypeCodeSequence; std::string elmFilterMaterial, elmRows, elmColumns; /* -- GENERAL MODULE ATTRIBUTES */ //std::string elmSOPClassUID; std::string elmSOPInstanceUID, elmSpecificCharacterSet, elmInstanceCreationDate; std::string elmInstanceCreationTime, elmInstanceCreatorUID;

// -- PROCESS TO GET THE VALUES -- //0x0008,0x0020 populateValue(iod, cyc::dicom::Tag(0x0008, 0x0020), elmStudyDate); //0x0008,0x0030 populateValue(iod, cyc::dicom::Tag(0x0008, 0x0030), elmStudyTime); //0x0008,0x0090 populateValue(iod, cyc::dicom::Tag(0x0008, 0x0090), elmReferringPhysiciansName); //0x0020,0x0010 populateValue(iod, cyc::dicom::Tag(0x0020, 0x0010), elmStudyID); //0x0008,0x0050 populateValue(iod, cyc::dicom::Tag(0x0008, 0x0050), elmAccessionNumber); //0x0008,0x1030 populateValue(iod, cyc::dicom::Tag(0x0008, 0x1030), elmStudyDescription); //0x0008,0x0060 populateValue(iod, cyc::dicom::Tag(0x0008, 0x0060), elmModality); //0x0020,0x000E populateValue(iod, cyc::dicom::Tag(0x0020, 0x000E), elmSeriesInstanceUID); //0x0020,0x0011 populateValue(iod, cyc::dicom::Tag(0x0020, 0x0011), elmSeriesNumber); //0x0008,0x0021 populateValue(iod, cyc::dicom::Tag(0x0008, 0x0021), elmSeriesDate); //0x0008,0x0031 populateValue(iod, cyc::dicom::Tag(0x0008, 0x0031), elmSeriesTime); //0x0018,0x1030 populateValue(iod, cyc::dicom::Tag(0x0018, 0x1030), elmProtocolName); //0x0008,0x103E populateValue(iod, cyc::dicom::Tag(0x0008, 0x103E), elmSeriesDescription); //0x0008,0x1070 populateValue(iod, cyc::dicom::Tag(0x0008, 0x1070), elmOperatorsName); //0x0018,0x0015 populateValue(iod, cyc::dicom::Tag(0x0018, 0x0015), elmBodyPartExamined); //0x0018,0x5100 populateValue(iod, cyc::dicom::Tag(0x0018, 0x5100), elmPatientPosition); //0x0008,0x0070 populateValue(iod, cyc::dicom::Tag(0x0008, 0x0070),

elmManufacturer); //0x0008,0x0080 populateValue(iod, cyc::dicom::Tag(0x0008, 0x0080), elmInstitutionName); //0x0008,0x0081 populateValue(iod, cyc::dicom::Tag(0x0008, 0x0081), elmInstitutionAddress); //0x0008,0x1010 populateValue(iod, cyc::dicom::Tag(0x0008, 0x1010), elmStationName); //0x0008,0x1040 populateValue(iod, cyc::dicom::Tag(0x0008, 0x1040), elmInstitutionalDepartmentName); //0x0008,0x1090 populateValue(iod, cyc::dicom::Tag(0x0008, 0x1090), elmManufacturerModelName); //0x0018,0x1000 populateValue(iod, cyc::dicom::Tag(0x0018, 0x1000), elmDeviceSerialNumber); //0x0018,0x1020 populateValue(iod, cyc::dicom::Tag(0x0018, 0x1020), elmSoftwareVersions); //0x0018,0x1008 populateValue(iod, cyc::dicom::Tag(0x0018, 0x1008), elmGantryID); //0x0018,0x1050 populateValue(iod, cyc::dicom::Tag(0x0018, 0x1050), elmSpatialResolution); //0x0018,0x1200 populateValue(iod, cyc::dicom::Tag(0x0018, 0x1200), elmDateofLastCalibration); //0x0018,0x1201 populateValue(iod, cyc::dicom::Tag(0x0018, 0x1201), elmTimeofLastCalibration); //0x0020,0x0013 populateValue(iod, cyc::dicom::Tag(0x0020, 0x0013), elmInstanceNumber); //0x0020,0x0020 populateValue(iod, cyc::dicom::Tag(0x0020, 0x0020), elmPatientOrientation); //0x0008,0x0023 populateValue(iod, cyc::dicom::Tag(0x0008, 0x0023), elmContentDate); //0x0008,0x0033 populateValue(iod, cyc::dicom::Tag(0x0008, 0x0033), elmContentTime); //0x0008,0x0008 populateValue(iod, cyc::dicom::Tag(0x0008, 0x0008), elmImageType); //0x0020,0x0012 populateValue(iod, cyc::dicom::Tag(0x0020, 0x0012), elmAcquisitionNumber); //0x0008,0x3010 populateValue(iod, cyc::dicom::Tag(0x0008, 0x3010), elmIrradiationEventUID); //0x0020,0x0037 populateValue(iod, cyc::dicom::Tag(0x0020, 0x0037), elmImageOrientationPatient); //0x0020,0x0032 populateValue(iod, cyc::dicom::Tag(0x0020, 0x0032), elmImagePositionPatient); //0x0018,0x0050 populateValue(iod, cyc::dicom::Tag(0x0018, 0x0050), elmSliceThickness); //0x0020,0x1041 populateValue(iod, cyc::dicom::Tag(0x0020, 0x1041), elmSliceLocation);

//0x0010,0x0010 populateValue(iod, cyc::dicom::Tag(0x0010, 0x0010), elmPatientName); //0x0010,0x0020 populateValue(iod, cyc::dicom::Tag(0x0010, 0x0020), elmPatientID); //0x0010,0x0030 populateValue(iod, cyc::dicom::Tag(0x0010, 0x0030), elmPatientBirthDate); //0x0010,0x0040 populateValue(iod, cyc::dicom::Tag(0x0010, 0x0040), elmPatientSex); //0x0010,0x1010 populateValue(iod, cyc::dicom::Tag(0x0010, 0x1010), elmPatientAge); //0x0010,0x1030 populateValue(iod, cyc::dicom::Tag(0x0010, 0x1030), elmPatientWeight); //0x0018,0x0060 populateValue(iod, cyc::dicom::Tag(0x0018, 0x0060), elmKVP); //0x0018,0x0022 populateValue(iod, cyc::dicom::Tag(0x0018, 0x0022), elmScanOptions); //0x0018,0x0090 populateValue(iod, cyc::dicom::Tag(0x0018, 0x0090), elmDataCollectionDiameter); //0x0018,0x9313 populateValue(iod, cyc::dicom::Tag(0x0018, 0x9313), elmDataCollectionCenterPatient); //0x0018,0x1100 populateValue(iod, cyc::dicom::Tag(0x0018, 0x1100), elmReconstructionDiameter); //0x0018,0x9318 populateValue(iod, cyc::dicom::Tag(0x0018, 0x9318), elmReconstructionTargetCenter); //0x0018,0x1110 populateValue(iod, cyc::dicom::Tag(0x0018, 0x1110), elmDistanceSourcetoDetector); //0x0018,0x1111 populateValue(iod, cyc::dicom::Tag(0x0018, 0x1111), elmDistanceSourcetoPatient); //0x0018,0x1120 populateValue(iod, cyc::dicom::Tag(0x0018, 0x1120), elmGantryDetectorTilt); //0x0018,0x1130 populateValue(iod, cyc::dicom::Tag(0x0018, 0x1130), elmTableHeight); //0x0018,0x1140 populateValue(iod, cyc::dicom::Tag(0x0018, 0x1140), elmRotationDirection); //0x0018,0x1150 populateValue(iod, cyc::dicom::Tag(0x0018, 0x1150), elmExposureTime); //0x0018,0x1151 populateValue(iod, cyc::dicom::Tag(0x0018, 0x1151), elmXRayTubeCurrent); //0x0018,0x1152 populateValue(iod, cyc::dicom::Tag(0x0018, 0x1152), elmExposure); //0x0018,0x1153 populateValue(iod, cyc::dicom::Tag(0x0018, 0x1153), elmExposureinusa); //0x0018,0x1160 populateValue(iod, cyc::dicom::Tag(0x0018, 0x1160), elmFilterType); //0x0018,0x1190 populateValue(iod, cyc::dicom::Tag(0x0018, 0x1190), elmFocalSpot); //0x0018,0x1210 populateValue(iod, cyc::dicom::Tag(0x0018, 0x1210), elmConvolutionKernel);

//0x0018,0x9305 populateValue(iod, cyc::dicom::Tag(0x0018, 0x9305), elmRevolutionTime); //0x0018,0x9306 populateValue(iod, cyc::dicom::Tag(0x0018, 0x9306), elmSingleCollimationWidth); //0x0018,0x9307 populateValue(iod, cyc::dicom::Tag(0x0018, 0x9307), elmTotalCollimationWidth); //0x0018,0x9309 populateValue(iod, cyc::dicom::Tag(0x0018, 0x9309), elmTableSpeed); //0x0018,0x9310 populateValue(iod, cyc::dicom::Tag(0x0018, 0x9310), elmTableFeedperRotation); //0x0018,0x9311 populateValue(iod, cyc::dicom::Tag(0x0018, 0x9311), elmSpiralPitchFactor); //0x0018,0x9323 populateValue(iod, cyc::dicom::Tag(0x0018, 0x9323), elmExposureModulationType); //0x0018,0x9324 populateValue(iod, cyc::dicom::Tag(0x0018, 0x9324), elmEstimatedDoseSaving); //0x0018,0x9345 populateValue(iod, cyc::dicom::Tag(0x0018, 0x9345), elmCTDIvol); //0x0018,0x9346 populateValue(iod, cyc::dicom::Tag(0x0018, 0x9346), elmCTDIPhantomTypeCodeSequence); //0x0018,0x7050 populateValue(iod, cyc::dicom::Tag(0x0018, 0x7050), elmFilterMaterial); //0x0028,0x0010 populateValue(iod, cyc::dicom::Tag(0x0028, 0x0010), elmRows); //0x0028,0x0011 populateValue(iod, cyc::dicom::Tag(0x0028, 0x0011), elmColumns); //0x0008,0x0018 populateValue(iod, cyc::dicom::Tag(0x0008, 0x0018), elmSOPInstanceUID); //0x0008,0x0005 populateValue(iod, cyc::dicom::Tag(0x0008, 0x0005), elmSpecificCharacterSet); //0x0008,0x0012 populateValue(iod, cyc::dicom::Tag(0x0008, 0x0012), elmInstanceCreationDate); //0x0008,0x0013 populateValue(iod, cyc::dicom::Tag(0x0008, 0x0013), elmInstanceCreationTime); //0x0008,0x0014 populateValue(iod, cyc::dicom::Tag(0x0008, 0x0014), elmInstanceCreatorUID);

/* -- END --*/

//Populate Struct with var content

if (i == 0) {//first file

mStudy.mAccessionNumber = elmAccessionNumber; mStudy.mReferringPhysiciansName = elmReferringPhysiciansName; mStudy.mStudyDate = elmStudyDate;

mStudy.mStudyDescription = elmStudyDescription; mStudy.mStudyID = elmStudyID; mStudy.mStudyInstanceUID = elmStudyInstanceUID; mStudy.mStudyTime = elmStudyTime;

mStudy.mEquipment.mManufacturer = elmManufacturer; mStudy.mEquipment.mInstitutionName = elmInstitutionName; mStudy.mEquipment.mInstitutionAddress = elmInstitutionAddress; mStudy.mEquipment.mStationName = elmStationName; mStudy.mEquipment.mInstitutionalDepartmentName = elmInstitutionalDepartmentName; mStudy.mEquipment.mManufacturerModelName = elmManufacturerModelName; mStudy.mEquipment.mDeviceSerialNumber = elmDeviceSerialNumber; mStudy.mEquipment.mSoftwareVersions = elmSoftwareVersions; mStudy.mEquipment.mGantryID = elmGantryID; mStudy.mEquipment.mSpatialResolution = elmSpatialResolution; mStudy.mEquipment.mDateofLastCalibration = elmDateofLastCalibration; mStudy.mEquipment.mTimeofLastCalibration = elmTimeofLastCalibration;

mStudy.mPatient.mPatientName = elmPatientName; mStudy.mPatient.mPatientID = elmPatientID; mStudy.mPatient.mPatientBirthDate = elmPatientBirthDate; mStudy.mPatient.mPatientSex = elmPatientSex; mStudy.mPatient.mPatientAge = elmPatientAge; mStudy.mPatient.mPatientWeight = elmPatientWeight;

}

std::map<std::string, strctSeries>::iterator itSerie; std::pair<std::map<std::string, strctSeries>::iterator, bool> ret; std::map<std::string, strctImage>::iterator itImage; itSerie = mStudy.mSeries.find(elmSeriesInstanceUID); if (itSerie == mStudy.mSeries.end()) {

struct strctSeries tmpSerie; tmpSerie.mBodyPartExamined = elmBodyPartExamined; tmpSerie.mModality = elmModality; tmpSerie.mOperatorsName = elmOperatorsName; tmpSerie.mPatientPosition = elmPatientPosition; tmpSerie.mProtocolName = elmProtocolName; tmpSerie.mSeriesDate = elmSeriesDate; tmpSerie.mSeriesDescription = elmSeriesDescription; tmpSerie.mSeriesInstanceUID = elmSeriesInstanceUID; tmpSerie.mSeriesNumber = elmSeriesNumber; tmpSerie.mSeriesTime = elmSeriesTime;

ret = mStudy.mSeries.insert( std::pair<std::string, strctSeries>( elmSeriesInstanceUID, tmpSerie)); itSerie = ret.first; }

//std::map<std::string,strctImage>* currentVectorImages = &(itSerie->second.mImages); std::vector<strctImage>* currentVectorImages = &(itSerie->second.mImages); struct strctImage tmpImage;

tmpImage.mSOPInstanceUID = elmSOPInstanceUID;

tmpImage.mSpecificCharacterSet = elmSpecificCharacterSet; tmpImage.mInstanceCreationDate = elmInstanceCreationDate; tmpImage.mInstanceCreationTime = elmInstanceCreationTime; tmpImage.mInstanceCreatorUID = elmInstanceCreatorUID;

tmpImage.mInstanceNumber = elmInstanceNumber; tmpImage.mPatientOrientation = elmPatientOrientation; tmpImage.mContentDate = elmContentDate; tmpImage.mContentTime = elmContentTime; tmpImage.mImageType = elmImageType; tmpImage.mAcquisitionNumber = elmAcquisitionNumber; tmpImage.mIrradiationEventUID = elmIrradiationEventUID; tmpImage.mImageOrientationPatient = elmImageOrientationPatient; tmpImage.mImagePositionPatient = elmImagePositionPatient; tmpImage.mSliceThickness = elmSliceThickness; tmpImage.mSliceLocation = elmSliceLocation;

tmpImage.mKVP = elmKVP; tmpImage.mScanOptions = elmScanOptions; tmpImage.mDataCollectionDiameter = elmDataCollectionDiameter; tmpImage.mDataCollectionCenterPatient = elmDataCollectionCenterPatient; tmpImage.mReconstructionDiameter = elmReconstructionDiameter; tmpImage.mReconstructionTargetCenter = elmReconstructionTargetCenter; tmpImage.mDistanceSourcetoDetector = elmDistanceSourcetoDetector; tmpImage.mDistanceSourcetoPatient = elmDistanceSourcetoPatient; tmpImage.mGantryDetectorTilt = elmGantryDetectorTilt; tmpImage.mTableHeight = elmTableHeight; tmpImage.mRotationDirection = elmRotationDirection; tmpImage.mExposureTime = elmExposureTime; tmpImage.mXRayTubeCurrent = elmXRayTubeCurrent; tmpImage.mExposure = elmExposure; tmpImage.mExposureinusa = elmExposureinusa; tmpImage.mFilterType = elmFilterType; tmpImage.mFocalSpot = elmFocalSpot; tmpImage.mConvolutionKernel = elmConvolutionKernel; tmpImage.mRevolutionTime = elmRevolutionTime; tmpImage.mSingleCollimationWidth = elmSingleCollimationWidth; tmpImage.mTotalCollimationWidth = elmTotalCollimationWidth; tmpImage.mTableSpeed = elmTableSpeed; tmpImage.mTableFeedperRotation = elmTableFeedperRotation; tmpImage.mSpiralPitchFactor = elmSpiralPitchFactor; tmpImage.mExposureModulationType = elmExposureModulationType; tmpImage.mEstimatedDoseSaving = elmEstimatedDoseSaving; tmpImage.mCTDIvol = elmCTDIvol; tmpImage.mCTDIPhantomTypeCodeSequence = elmCTDIPhantomTypeCodeSequence; tmpImage.mFilterMaterial = elmFilterMaterial; tmpImage.mRows = elmRows; tmpImage.mColumns = elmColumns;

currentVectorImages->push_back(tmpImage);

} catch (cyc::dicom::DICOMException &exception) {

std::cout << exception.what() << std::endl;

}

/* -- TAGS - -- */ /*

Name Description Length AE Application Entity 16 Bytes Maximum AS Age String 4 Bytes Fixed AT Attribute Tag 4 Bytes Fixed CS Code String 16 Bytes Maximum DA Date 8 Bytes Fixed DS Decimal String 16 Bytes Maximum DT Date Time 26 Bytes Maximum FL Floating Point Single 4 Bytes Fixed FD Floating Point Double 8 Bytes Fixed IS Integer String 12 Bytes Maximum LO Long String 64 Bytes Maximum LT Long Text 10240 Bytes Maximum OB Other Byte String Unlimited OF Other Float String Unlimited OW Other Word String Unlimited PN Person Name 64 Bytes Maximum SH Short String 16 Bytes Maximum SL Signed Long 4 Bytes Fixed SQ Sequence of Items Unlimited SS Signed Short 2 Bytes Fixed ST Short Text 1024 Bytes Maximum TM Time 16 Bytes Maximum UI Unique Identifier 64 Bytes Maximum UL Unsigned Long 4 Bytes Fixed UN Unknown Unlimited US Unsigned Short 2 Bytes Fixed UT Unlimited Text Unlimited

=================================================== =================== SAMPLES ======================= =================================================== */

}//for-end (parse files iterator)

/* -- GENERATE CSV, ONE IMAGE AS ONE LINE -- */

std::string pathCSVfile(pathOutput); std::ostringstream msg; const boost::posix_time::ptime now = boost::posix_time::second_clock::local_time(); boost::posix_time::time_facet* const f = new boost::posix_time::time_facet( "%Y_%m_%d_%H_%M_%S"); msg.imbue(std::locale(msg.getloc(), f)); msg << now;

//std::vector<std::string> directories; //pathCSVfile += ("/" + msg.str() + "/"); //std::string studyInstanceUID; //pathCSVfile += ("/" + studyInstanceUID+ "/"); //pathCSVfile += ("/" + serieInstanceUID + "/"); /* boost::split(directories, pathCSVfile, boost::is_any_of("/")); std::string path; for(std::vector<std::string>::const_iterator it = directories.begin(); it != directories.end(); ++it) { path += *it + '/'; if(!boost::filesystem::exists(path)) boost::filesystem::create_directory(path);

} */

std::string strdate(msg.str()); pathCSVfile += (std::string("temp_study_data_" + strdate + "_.csv"));

//check if file exist bool printHeader = true; //if (!boost::filesystem::exists("extracted_data.txt" ) ) //{ // std::cout << "Can't find the file!" << std::endl; // printHeader = true; //}

std::ofstream myOutputFile; myOutputFile.open(pathCSVfile.c_str(), std::ios::out | std::ios::app);

myOutputFile << "\"" << "StudyInstanceUID" << "\"," << "\"" << "StudyDate" << "\"," << "\"" << "StudyTime" << "\"," << "\"" << "ReferringPhysiciansName" << "\"," << "\"" << "StudyID" << "\"," << "\"" << "AccessionNumber" << "\"," << "\"" << "StudyDescription" << "\"," << "\"" << "Modality" << "\"," << "\"" << "SeriesInstanceUID" << "\"," << "\"" << "SeriesNumber" << "\"," << "\"" << "SeriesDate" << "\"," << "\"" << "SeriesTime" << "\"," << "\"" << "ProtocolName" << "\"," << "\"" << "SeriesDescription" << "\"," << "\"" << "OperatorsName" << "\"," << "\"" << "BodyPartExamined" << "\"," << "\"" << "PatientPosition" << "\"," << "\"" << "Manufacturer" << "\"," << "\"" << "InstitutionName" << "\"," << "\"" << "InstitutionAddress" << "\"," << "\"" << "StationName" << "\"," << "\"" << "InstitutionalDepartmentName" << "\"," << "\"" << "ManufacturerModelName" << "\"," << "\"" << "DeviceSerialNumber" << "\"," << "\"" << "SoftwareVersions" << "\"," << "\"" << "GantryID" << "\"," << "\"" << "SpatialResolution" << "\"," << "\"" << "DateofLastCalibration" << "\"," << "\"" << "TimeofLastCalibration" << "\"," << "\"" << "InstanceNumber" << "\"," << "\"" << "PatientOrientation" << "\"," << "\"" << "ContentDate" << "\"," << "\"" << "ContentTime" << "\"," << "\"" << "ImageType" << "\"," << "\"" << "AcquisitionNumber" << "\"," << "\"" << "IrradiationEventUID" << "\"," << "\"" << "ImageOrientationPatient" << "\"," << "\"" << "ImagePositionPatient" << "\"," << "\"" << "SliceThickness" << "\"," << "\"" << "SliceLocation" << "\"," << "\"" << "PatientName" << "\"," << "\"" << "PatientID" << "\"," << "\"" << "PatientBirthDate" << "\"," << "\"" << "PatientSex" << "\"," << "\"" << "PatientAge" << "\"," << "\"" << "PatientWeight" << "\"," << "\"" << "KVP" << "\"," << "\"" << "ScanOptions" << "\"," << "\"" << "DataCollectionDiameter" << "\"," << "\"" << "DataCollectionCenterPatient" << "\"," << "\"" << "ReconstructionDiameter" << "\"," << "\"" << "ReconstructionTargetCenter" << "\"," << "\"" << "DistanceSourcetoDetector" << "\"," << "\"" << "DistanceSourcetoPatient" << "\"," << "\"" << "GantryDetectorTilt" << "\"," << "\"" << "TableHeight" << "\"," << "\"" << "RotationDirection" << "\"," << "\"" << "ExposureTime" << "\"," << "\"" << "XRayTubeCurrent" << "\"," << "\"" << "Exposure" << "\"," << "\"" << "Exposureinusa" << "\"," << "\"" << "FilterType" << "\"," << "\"" << "FocalSpot" << "\"," << "\"" << "ConvolutionKernel" << "\"," << "\"" << "RevolutionTime" << "\"," << "\"" << "SingleCollimationWidth" << "\"," << "\"" << "TotalCollimationWidth" << "\"," << "\"" << "TableSpeed"

<< "\"," << "\"" << "TableFeedperRotation" << "\"," << "\"" << "SpiralPitchFactor" << "\"," << "\"" << "ExposureModulationType" << "\"," << "\"" << "EstimatedDoseSaving" << "\"," << "\"" << "CTDIvol" << "\"," << "\"" << "CTDIPhantomTypeCodeSequence" << "\"," << "\"" << "FilterMaterial" << "\"," << "\"" << "Rows" << "\"," << "\"" << "Columns" << "\"," << "\"" << "SOPInstanceUID" << "\"," << "\"" << "SpecificCharacterSet" << "\"," << "\"" << "InstanceCreationDate" << "\"," << "\"" << "InstanceCreationTime" << "\"," << "\"" << "InstanceCreatorUID" << "\"\n";

//iterator on structs to generate for (std::map<std::string, strctSeries>::iterator itSerie = mStudy.mSeries.begin(); itSerie != mStudy.mSeries.end(); itSerie++) {

strctSeries* currentSerie = &itSerie->second; std::vector<strctImage>::iterator it; std::vector<strctImage>* img = &currentSerie->mImages;

std::sort(img->begin(), img->end(), sortfc);

for (it = img->begin(); it < img->end(); it++) {

myOutputFile << "\"" << mStudy.mStudyInstanceUID << "\"," << "\"" << mStudy.mStudyDate << "\"," << "\"" << mStudy.mStudyTime << "\"," << "\"" << mStudy.mReferringPhysiciansName << "\"," << "\"" << mStudy.mStudyID << "\"," << "\"" << mStudy.mAccessionNumber << "\"," << "\"" << mStudy.mStudyDescription << "\"," <<

"\"" << currentSerie->mModality << "\"," << "\"" << currentSerie->mSeriesInstanceUID << "\"," << "\"" << currentSerie->mSeriesNumber << "\"," << "\"" << currentSerie->mSeriesDate << "\"," << "\"" << currentSerie->mSeriesTime << "\"," << "\"" << currentSerie->mProtocolName << "\"," << "\"" << currentSerie->mSeriesDescription << "\"," << "\"" << currentSerie->mOperatorsName << "\"," << "\"" << currentSerie->mBodyPartExamined << "\"," << "\"" << currentSerie->mPatientPosition << "\"," <<

"\"" << mStudy.mEquipment.mManufacturer << "\"," << "\"" << mStudy.mEquipment.mInstitutionName << "\"," << "\"" << mStudy.mEquipment.mInstitutionAddress << "\"," << "\"" << mStudy.mEquipment.mStationName << "\"," << "\"" << mStudy.mEquipment.mInstitutionalDepartmentName << "\"," << "\"" << mStudy.mEquipment.mManufacturerModelName << "\"," << "\"" << mStudy.mEquipment.mDeviceSerialNumber << "\"," << "\"" << mStudy.mEquipment.mSoftwareVersions << "\"," << "\"" << mStudy.mEquipment.mGantryID << "\"," << "\"" << mStudy.mEquipment.mSpatialResolution << "\"," << "\"" << mStudy.mEquipment.mDateofLastCalibration << "\"," << "\"" << mStudy.mEquipment.mTimeofLastCalibration << "\"," <<

"\"" << (*it).mInstanceNumber << "\"," << "\"" << (*it).mPatientOrientation << "\"," << "\"" << (*it).mContentDate << "\"," << "\"" << (*it).mContentTime << "\"," << "\"" << (*it).mImageType << "\"," << "\"" << (*it).mAcquisitionNumber << "\"," << "\"" << (*it).mIrradiationEventUID << "\"," << "\""

<< (*it).mImageOrientationPatient << "\"," << "\"" << (*it).mImagePositionPatient << "\"," << "\"" << (*it).mSliceThickness << "\"," << "\"" << (*it).mSliceLocation << "\"," << "\"" << mStudy.mPatient.mPatientName << "\"," << "\"" << mStudy.mPatient.mPatientID << "\"," << "\"" << mStudy.mPatient.mPatientBirthDate << "\"," << "\"" << mStudy.mPatient.mPatientSex << "\"," << "\"" << mStudy.mPatient.mPatientAge << "\"," << "\"" << mStudy.mPatient.mPatientWeight << "\"," << "\"" << (*it).mKVP << "\"," << "\"" << (*it).mScanOptions << "\"," << "\"" << (*it).mDataCollectionDiameter << "\"," << "\"" << (*it).mDataCollectionCenterPatient << "\"," << "\"" << (*it).mReconstructionDiameter << "\"," << "\"" << (*it).mReconstructionTargetCenter << "\"," << "\"" << (*it).mDistanceSourcetoDetector << "\"," << "\"" << (*it).mDistanceSourcetoPatient << "\"," << "\"" << (*it).mGantryDetectorTilt << "\"," << "\"" << (*it).mTableHeight << "\"," << "\"" << (*it).mRotationDirection << "\"," << "\"" << (*it).mExposureTime << "\"," << "\"" << (*it).mXRayTubeCurrent << "\"," << "\"" << (*it).mExposure << "\"," << "\"" << (*it).mExposureinusa << "\"," << "\"" << (*it).mFilterType << "\"," << "\"" << (*it).mFocalSpot << "\"," << "\"" << (*it).mConvolutionKernel << "\"," << "\"" << (*it).mRevolutionTime << "\"," << "\"" << (*it).mSingleCollimationWidth << "\"," << "\"" << (*it).mTotalCollimationWidth << "\"," << "\"" << (*it).mTableSpeed << "\"," << "\"" << (*it).mTableFeedperRotation << "\"," << "\"" << (*it).mSpiralPitchFactor << "\"," << "\"" << (*it).mExposureModulationType << "\"," << "\"" << (*it).mEstimatedDoseSaving << "\"," << "\"" << (*it).mCTDIvol << "\"," << "\"" << (*it).mCTDIPhantomTypeCodeSequence << "\"," << "\"" << (*it).mFilterMaterial << "\"," << "\"" << (*it).mRows << "\"," << "\"" << (*it).mColumns << "\"," << "\"" << (*it).mSOPInstanceUID << "\"," << "\"" << (*it).mSpecificCharacterSet << "\"," << "\"" << (*it).mInstanceCreationDate << "\"," << "\"" << (*it).mInstanceCreationTime << "\"," << "\"" << (*it).mInstanceCreatorUID << "\"\n"; } }

//closing handler myOutputFile.close();

cyc::dicom::finalizeDICOM();

/*-- Google Protobuffer*/

//*-- Google Protobuffer --*/ // Verify that the version of the library that we linked against is // compatible with the version of the headers we compiled against. GOOGLE_PROTOBUF_VERIFY_VERSION;

cycrdsr::ListFilesRDSRCT list; { // Read the existing address book. std::fstream input("temp_file.gbi", std::ios::in | std::ios::binary);

if (!input) { std::cout << "temp_file.gbi" << ": File not found. Creating a new file." << std::endl; } else if (!list.ParseFromIstream(&input)) { std::cerr << "Failed to parse address book." << std::endl; } }

cycrdsr::FileRDSRCT* file = list.add_file();

cycrdsr::Header* h = file->mutable_header();

h->set_accessionnumber(mStudy.mAccessionNumber); h->set_studydate(mStudy.mStudyDate); h->set_studytime(mStudy.mStudyTime); h->set_institutionname(mStudy.mEquipment.mInstitutionName); h->set_institutionaddress(mStudy.mEquipment.mInstitutionAddress); h->set_studydescription(mStudy.mStudyDescription); h->set_manufacturer(mStudy.mEquipment.mManufacturer); h->set_manufacturersmodelname(mStudy.mEquipment.mManufacturerModelName); h->set_stationname(mStudy.mEquipment.mStationName); h->set_studyinstanceuid(mStudy.mStudyInstanceUID); h->set_patientname(mStudy.mPatient.mPatientName); h->set_patientid(mStudy.mPatient.mPatientID); h->set_patientbirthdate(mStudy.mPatient.mPatientID); h->set_patientweight(mStudy.mPatient.mPatientWeight); h->set_patientssex(mStudy.mPatient.mPatientSex); h->set_patientsage(mStudy.mPatient.mPatientAge); h->set_referringphysicianname(mStudy.mReferringPhysiciansName);

cycrdsr::CTRadiationDose* c = file->mutable_ctrd(); c->set_startdatefirstctirradiation(""); c->set_enddatefirstctirradiation(""); c->set_scopeofaccumulation(""); c->set_comment("");

//iterator on structs to generate csv file for (std::map<std::string, strctSeries>::iterator itSerie = mStudy.mSeries.begin(); itSerie != mStudy.mSeries.end(); itSerie++) {

strctSeries* currentSerie = &itSerie->second; std::vector<strctImage>::iterator it; std::vector<strctImage>* img = &currentSerie->mImages;

std::sort(img->begin(), img->end(), sortfc);

std::string lacquisitionprotocol(""); std::string ltargetregion(""); std::string lctacquisitiontype(""); std::string lexposuretime(""); std::string lscanninglength(""); std::string lnominalsinglecollimationwidth(""); std::string lnominaltotalcollimationwidth(""); std::string lpitchfactor(""); std::string lnumberofxraysources(""); std::string lidentificationnumberofthexraysource(""); std::string lkvp(""); std::string lmaximumxraytubecurrent(""); std::string lxraytubecurrent(""); std::string lexposuretimeperrotation(""); std::string lxrayfilteraluminumequivalent("");

std::string lmeanctdivol(""); std::string lctdiwphantomtype(""); std::string lctdifreeaircalculationfactor(""); std::string lctdimeanctdifreeair(""); std::string ldlp("");

for (it = img->begin(); it < img->end(); it++) {

if (it == img->begin()) {

lacquisitionprotocol = currentSerie->mProtocolName; lkvp = (*it).mKVP; lxraytubecurrent = (*it).mXRayTubeCurrent; lmeanctdivol = (*it).mCTDIvol; } }

cycrdsr::CTRadiationDose_CTIrradiationEventData* ie = c->add_ctied(); ie->set_acquisitionprotocol(lacquisitionprotocol); ie->set_targetregion(ltargetregion); ie->set_ctacquisitiontype(lctacquisitiontype); ie->set_exposuretime(lexposuretime); ie->set_scanninglength(lscanninglength); ie->set_nominalsinglecollimationwidth(lnominalsinglecollimationwidth); ie->set_nominaltotalcollimationwidth(lnominaltotalcollimationwidth); ie->set_pitchfactor(lpitchfactor); ie->set_numberofxraysources(lnumberofxraysources); ie->set_identificationnumberofthexraysource(lidentificationnumberofthexraysource); ie->set_kvp(lkvp); ie->set_maximumxraytubecurrent(lmaximumxraytubecurrent); ie->set_xraytubecurrent(lxraytubecurrent); ie->set_exposuretimeperrotation(lexposuretimeperrotation); ie->set_xrayfilteraluminumequivalent(lxrayfilteraluminumequivalent); ie->set_meanctdivol(lmeanctdivol); ie->set_ctdiwphantomtype(lctdiwphantomtype); ie->set_ctdifreeaircalculationfactor(lctdifreeaircalculationfactor); ie->set_ctdimeanctdifreeair(lctdimeanctdifreeair); ie->set_dlp(ldlp); ie->set_effectivedose(""); ie->set_effectivedoseconversionfactor(""); ie->set_xraymodulationtype(""); ie->set_comment(""); ie->set_personparticipant(""); ie->set_devicename(""); ie->set_devicemanufacturer("");

}

std::string lTotalNumberOfIrradiationEvents; std::string lCtDoseLengthProductTotal("");

cycrdsr::CTRadiationDose_CTAccumulatedDoseData* ad = c->mutable_ctadd(); ad->set_totalnumberofirradiationevents(lTotalNumberOfIrradiationEvents); ad->set_ctdoselengthproducttotal(lCtDoseLengthProductTotal); ad->set_cteffectivedosetotal(""); ad->set_referenceauthoritycode(""); ad->set_referenceauthoritytext(""); ad->set_measurementmethod(""); ad->set_patientmodel(""); ad->set_conditioneffectivedosemeasured(""); ad->set_effectivedosephantomtype("");