109456_Rodrigo - riuni

UNIVERSIDADE DO SUL DE SANTA CATARINA
RODRIGO ROSA
BUSINESS INTELLIGENCE EM SISTEMAS DE DIAGNÓSTICO MÉDICO POR IMAGEM
Florianópolis
2014
RODRIGO ROSA
BUSINESS INTELLIGENCE EM SISTEMAS DE DIAGNÓSTICO MÉDICO POR IMAGEM
Trabalho de Conclusão de Curso apresentado ao Curso
de Graduação em Sistemas de Informação da
Universidade do Sul de Santa Catarina, como requisito
parcial à obtenção do título de Bacharel em Sistemas de
Informação.
Orientador: Prof. Aran Bey Tcholokian Morales, Dr Eng.
Florianópolis
2014
RODRIGO ROSA
BUSINESS INTELLIGENCE EM SISTEMAS DE DIAGNÓSTICO MÉDICO POR IMAGEM
Este Trabalho de Conclusão de Curso foi julgado
adequado à obtenção do título de Bacharel em Sistemas
de Informação e aprovado em sua forma final pelo
Curso de Graduação em Sistemas de Informação da
Universidade do Sul de Santa Catarina
AGRADECIMENTOS
Ao Prof. Aran Morales, por me conduzir e orientar em todas as etapas envolvidas
no desenvolvimento deste trabalho.
À Prof. Maria Inês, coordenadora da disciplina, por sempre atender prontamente
os questionamentos e dúvidas a ela direcionados.
A minha família e, principalmente, aos meus pais: Ana e Francisco, por toda
educação, dedicação e sacrifício feito para que eu chegasse até aqui.
A minha namorada Karoline, pela compreensão, pelo apoio e por estar presente
em todos os momentos de minha vida.
Aos colegas e amigos, que contribuíram de alguma forma no desenvolvimento
deste trabalho.
“Nós continuamos seguindo em frente,
abrindo novas portas e fazendo coisas
novas, porque somos curiosos e a
curiosidade continua nos conduzindo por
novos caminhos” (Walt Disney).
RESUMO
O cenário atual é marcado pela presença de grandes centros especializados em
medicina diagnóstica por imagem que utilizam sistemas de auxílio ao diagnóstico médico por
imagem, como PACS. Este trabalho tem como objetivo desenvolver um sistema de apoio à
decisão com dados existentes nesse tipo de sistema. Para tanto, utilizam-se informações do
sistema da empresa Pixeon, uma das maiores empresas no segmento. O referencial teórico
aborda conceitos da arquitetura de sistemas de Business Intelligence (BI), como Data
Warehouse (DW), Modelagem dimensional, ferramentas ETL e OLAP. Também são
apresentadas as teorias que envolvem a área da saúde, como conceitos de radiologia e da
utilização de sistemas de informação nas áreas médicas. A metodologia ICONIX para
levantamento de requisitos e a criação do modelo dimensional do Data Warehouse, fomentam
a modelagem do sistema. O protótipo consiste na criação de um Data Warehouse e na
extração para visualização em ferramentas analíticas. Utilizaram-se ferramentas como DB
Designer Fork 4 e Enterprise Architect para modelagem do sistema; Microsoft SQL Server
2012 para armazenamento do banco de dados operacional e dimensional; Pentaho Data
Integration (Kettle) para aplicação dos processos de extração, transformação e carga de dados
(ETL), e Microsoft Excel para visualização e análise dos dados. O protótipo foi validado
comparando a quantidade de laudos apresentada no Data Warehouse com a quantidade obtida
através da consulta SQL realizada diretamente no banco de dados operacional. Observa-se,
com o desenvolvimento do protótipo, que é possível aplicar uma arquitetura de Business
Intelligence em sistemas de PACS.
Palavras-chave: Business Intelligence. Data Warehouse. PACS. Radiologia. Sistemas de
Apoio à Decisão.
LISTA DE ABREVIATURAS E SIGLAS
BI – Business Intelligence
CI – Competitive Intelligence
CRM – Customer Relationship Management
DM – Data Marts
DW – Data Warehouse
EHR – Eletronic Health Record
ERP – Enterprise Resource Planning
ETL – Extract Transform and Load
HIS – Hospital Information System
KMS – Knowledge Management System
OLAP – On-line Analyzing Processing
PACS – Picture Archiving and Communication System
PET/CT – Positron Emission Tomography
RIS – Radiology Information System
RM – Ressonância Magnética
RX – Raios-X
SQL – Structured Query Language
TC – Tomografia Computadorizada
USG – Ultrassonografia
UML - Unified Modeling Language
LISTA DE ILUSTRAÇÕES
Figura 1 – Fluxo de Dados e Informações ................................................................................ 17
Figura 2 – Valor do BI como Suporte aos Processos Decisórios ............................................. 18
Figura 3 – Nível do BI nas Organizações ................................................................................. 19
Figura 4 – Modelo Estrela ........................................................................................................ 23
Figura 5 – Tabela de Fatos ....................................................................................................... 24
Figura 6 – Tabela Dimensional ................................................................................................ 25
Figura 7 – Granularidade: Alto Nível x Baixo Nível ............................................................... 27
Figura 8 – Processos ETL......................................................................................................... 29
Figura 9 – Cubo de Dados ........................................................................................................ 30
Figura 10 – Operação de Slice and Dice .................................................................................. 32
Figura 11 – Operação de Pivot ................................................................................................. 33
Figura 12 – Fluxo de Funcionamento PACS ............................................................................ 38
Figura 13 – Business Intelligence no mercado. ........................................................................ 41
Figura 14 – Tempo Médio de Espera para Exames de Mamografia ........................................ 42
Figura 15 – Fluxograma de Etapas ........................................................................................... 45
Figura 16 – Visões de um Sistema de Software ....................................................................... 49
Figura 17 – Diagramas UML ................................................................................................... 50
Figura 18 – Processo ICONIX ................................................................................................. 52
Figura 19 – Requisitos Funcionais ........................................................................................... 54
Figura 20 – Requisitos Não Funcionais .................................................................................... 54
Figura 21 – Diagrama de Casos de Uso ................................................................................... 55
Figura 22 – Diagrama de Robustez - UC01_01 ....................................................................... 57
Figura 23 – Diagrama de Robustez UC02_01 .......................................................................... 57
Figura 24 – Diagrama de Sequência - UC01_01 ...................................................................... 58
Figura 25 – Diagrama de Sequência - UC01_05 ...................................................................... 59
Figura 26 – Diagrama de Sequência - UC02_01 ...................................................................... 59
Figura 27 – Modelo Dimensional ............................................................................................. 60
Figura 28 – Diagrama da Solução ............................................................................................ 65
Figura 29 – Fluxo de Carga DI_TEMPO ................................................................................. 67
Figura 30 – Fluxo de Carga DI_MEDICO ............................................................................... 68
Figura 31 – Fluxo de Carga DI_PACIENTE............................................................................ 68
Figura 32 – Fluxo de Carga DI_ESTUDO ............................................................................... 69
Figura 33 – Fluxo de Carga FT_LAUDO ................................................................................ 70
Figura 34 – Fluxo de Carga FEX_DW_XLS ........................................................................... 71
Figura 35 – Fluxo de Controle.................................................................................................. 71
Figura 36 – Quantidade de Laudos (DW) ................................................................................ 72
Figura 37 – Consulta SQL ........................................................................................................ 73
Figura 38 – Quantidade de Laudos (SQL)................................................................................ 73
Figura 39 – Laudos por Período ............................................................................................... 74
Figura 40 – Laudos por Modalidade ........................................................................................ 75
Figura 41 – Laudos por Médico ............................................................................................... 76
Figura 42 – Exames por Período .............................................................................................. 76
Figura 43 – Exames por Modalidade ........................................................................................ 77
Figura 44 – Exames por Descrição e Modalidade .................................................................... 78
SUMÁRIO
1 INTRODUÇÃO ............................................................................................................................. 11
1.1 PROBLEMÁTICA .......................................................................................................................12
1.2 OBJETIVOS .................................................................................................................................13
1.2.1 Objetivo Geral ..........................................................................................................................13
1.2.2 Objetivos Específicos ...............................................................................................................14
1.3 JUSTIFICATIVA .........................................................................................................................14
1.4 ESTRUTURA DO TRABALHO .................................................................................................15
2 FUNDAMENTAÇÃO TEÓRICA ............................................................................................... 16
2.1 SISTEMAS DE BUSINESS INTELLIGENCE..............................................................................16
2.1.1 Data Warehouse .......................................................................................................................20
2.1.2 Modelagem Dimensional .........................................................................................................22
2.1.2.1 Modelo Estrela ....................................................................................................................... 22
2.1.2.2 Tabela de Fatos....................................................................................................................... 23
2.1.2.3 Tabelas Dimensionais ............................................................................................................ 25
2.1.2.4 Granularidade ......................................................................................................................... 26
2.1.3 ETL (Extract Transform and Load) ........................................................................................27
2.1.4 OLAP (On-Line Analytics Processing)....................................................................................30
2.1.4.1 Operações Drill-Up e Drill-Down.......................................................................................... 31
2.1.4.2 Operações Slice and Dice ....................................................................................................... 32
2.1.4.3 Operações Pivot...................................................................................................................... 33
2.2 RADIOLOGIA .............................................................................................................................33
2.2.1 Sistemas de Informação na Área Médica ..............................................................................34
2.2.2 Sistemas de Comunicação e Arquivamento de Imagens (PACS) ........................................36
2.2.2.1 Vantagens e Benefícios .......................................................................................................... 38
2.2.2.2 Mercado.................................................................................................................................. 39
2.2.3 Business Intelligence em PACS ...............................................................................................40
3 MÉTODO....................................................................................................................................... 44
3.1 CARACTERIZAÇÃO DO TIPO DE PESQUISA .......................................................................44
3.2 ETAPAS .......................................................................................................................................45
3.3 DELIMITAÇÕES .........................................................................................................................46
4 MODELAGEM ............................................................................................................................. 47
4.1 UML .............................................................................................................................................48
4.1.1 Artefatos ...................................................................................................................................50
4.2 ICONIX ........................................................................................................................................51
4.3 ARQUITETURA PROPOSTA.....................................................................................................53
4.3.1 LEVANTAMENTO DE REQUISITOS ................................................................................53
4.3.1.1 Requisitos Funcionais ............................................................................................................ 53
4.3.1.2 Requisitos Não Funcionais ..................................................................................................... 54
4.3.1.3 Diagrama de Casos de Uso..................................................................................................... 55
4.3.2 DIAGRAMA DE ROBUSTEZ ...............................................................................................56
4.3.3 DIAGRAMA DE SEQUÊNCIA .............................................................................................58
4.3.4 MODELO DIMENSIONAL ...................................................................................................60
5 DESENVOLVIMENTO ............................................................................................................... 62
5.1 TECNOLOGIAS E FERRAMENTAS .........................................................................................62
5.1.1 DB Designer Fork ....................................................................................................................62
5.1.2 Structured Query Language (SQL) .........................................................................................62
5.1.1 Microsoft SQL Server 2012.....................................................................................................63
5.1.2
5.1.3
5.2
5.3
5.4
5.4.1
5.4.2
5.5
5.5.1
5.5.2
5.5.3
5.5.4
5.5.5
5.5.6
5.6
Pentaho Data Integration - Kettle ..........................................................................................63
Microsoft Excel 2013................................................................................................................63
SOLUÇÃO PROPOSTA ..............................................................................................................64
HISTÓRICO DE DESENVOLVIMENTO ..................................................................................66
VALIDAÇÕES .............................................................................................................................66
Carga do Modelo DW ..............................................................................................................67
Validação da Carga do DW ....................................................................................................72
RESULTADOS E ANÁLISES .....................................................................................................74
Quantidade de Laudos por Período .......................................................................................74
Quantidade de Laudos por Modalidade ................................................................................75
Quantidade de Laudos por Médico ........................................................................................75
Quantidade de Exames por Período .......................................................................................76
Quantidade de Exames por Modalidade................................................................................77
Quantidade de Exames por Descrição ...................................................................................78
CONSIDERAÇÕES .....................................................................................................................79
6 CONCLUSÕES E TRABALHOS FUTUROS............................................................................ 80
6.1 CONCLUSÕES ............................................................................................................................80
6.2 TRABALHOS FUTUROS ...........................................................................................................81
REFERÊNCIAS .................................................................................................................................. 82
11
1
INTRODUÇÃO
A denominação de Business Intelligence (BI) surgiu na década de 80, através da
empresa Gartner Group, e pode ser definida como um processo inteligente de coleta,
organização, análise, compartilhamento e monitoramento de dados, transformando-os em
informações capazes de apoiar o processo de decisão nos negócios (PRIMAK, 2008 pag. 2-3).
Segundo Barbieri (2001), BI pode ser definido como um guarda-chuva conceitual,
uma vez que essa arquitetura representa a habilidade de estruturar, acessar e explorar
informações. Essas informações são usualmente armazenadas em Data Warehouse e Data
Marts, possibilitando, assim, desenvolver percepções, entendimentos e conhecimentos
importantes no processo decisório das organizações.
No final de 1996, o interesse do setor corporativo por soluções de BI ocorreu de
maneira mais expressiva, quando o conceito passou a ser disseminado como uma evolução do
Executive Information Systems (EIS) - sistema criado no final da década de 70- baseado em
estudos e trabalhos desenvolvidos por pesquisador do MIT (Massachusets Institute of
Technology), com o objetivo principal de fornecer informações empresariais a partir de uma
base de dados (PRIMAK, 2008 pag. 3).
Angeloni e Reis (2006) definem BI como um conjunto de metodologias para
gestão, implementadas através de softwares. Esses softwares são usados como ferramentas
capazes de integrar, em um só lugar, as informações necessárias ao processo decisório,
proporcionando, assim, ganhos nos processos gerenciais e auxiliando na tomada de decisão
pela alta administração das organizações. Desta maneira, pode ser criado o conceito de
Inteligência de Negócio ou Inteligência Empresarial. Resume-se BI como a transformação de
dados em conhecimentos, que auxiliam no processo decisório podendo gerar vantagens
competitivas para as organizações.
Levantamentos realizados pela RSR Research (2011), apontaram que 94% das
empresas pesquisadas consideram muito relevante ou relevante, o uso do BI como fonte de
controle dos processos internos e análise de performance dos indicadores apresentados contra
os indicadores planejados. Ainda segundo a mesma instituição, 87% das organizações
afirmaram que consideram o BI muito relevante ou relevante como ferramenta de apoio para
conhecer seus clientes e tomar decisões estratégicas. Entretanto, mesmo com o mercado em
crescimento, apenas 45% das empresas pesquisadas utilizam ferramentas com essa finalidade
em seus negócios.
12
Liu e Wang (2011) destacam o papel da tecnologia da informação na área médica
detalhando, em particular, a área de diagnóstico por imagem, especialmente nos processos de
aquisição, armazenamento, visualização e interpretação de imagens, além de melhorar a
comunicação entre os profissionais da saúde.
Uma pesquisa de mercado realizada pela empresa de consultoria Frost&Sullivan
levando em consideração um cenário com pouco mais de 24 mil centros médicos, que
dispõem de serviços de diagnóstico por imagem, apontou que apenas 7% possuíam sistemas
de comunicação e arquivamento de imagens em funcionamento (BROERING, 2013 A). Estes
são importantes ferramentas de apoio ao fluxo de trabalho desses centros, fornecendo maior
agilidade na distribuição e análise de exames radiológicos, conhecidos por sua sigla em inglês
PACS (Picture Archiving and Communication System). Considerando somente dezesseis dos
maiores concorrentes nacionais e internacionais do segmento, apenas 19% dispõem de
módulos e ferramentas de BI em operação.
Percebe-se, então, que o número de empresas na área da saúde que faz uso do BI
ainda é baixo, principalmente na área da radiologia que dispõe, em território brasileiro, de
mais de 34 mil centros com serviço de diagnóstico por imagem (CNES DATASUS, 2013).
1.1
PROBLEMÁTICA
O cenário atual é marcado pela presença de grandes centros especializados em
medicina diagnóstica por imagem que utilizam sistemas de auxílio ao diagnóstico médico por
imagem, usualmente sistemas de comunicação e arquivamento de imagens (Picture Archiving
and Communication System). Esse tipo de sistema permite um processo automatizado de
envio de informações entre todas as etapas de execução de exames radiológicos pela
instituição. O fluxo de trabalho passa a ser mais simplificado e eficiente, permitindo análises
mais rápidas das imagens radiológicas geradas pelos equipamentos.
Esses sistemas visam o aumento da qualidade dos serviços prestados em todas as
etapas da execução de exames radiológicos, bem como maior eficiência, agilidade e redução
de custos, gerando uma simplificação do fluxo do trabalho, eliminando o tempo gasto com a
logística de distribuição das imagens que podem ser analisadas mais rapidamente e,
13
consequentemente, contribuem para que a entrega dos laudos, realizados pela equipe médica,
seja antecipada.
Entretanto, percebe-se que os dados gerados durante o fluxo de trabalho não são
aproveitados para fins estatísticos por grande parte dos sistemas existentes. A ausência desses
dados faz com que não seja possível apresentar relatórios importantes para a administração do
hospital ou clínica, como quantidade de exames realizado por modalidade, ou qual o tempo
médio gasto na execução de cada exame.
Informações como essas podem auxiliar o processo decisório da instituição,
fazendo com que seja possível atuar de maneira mais assertiva nas etapas que envolvem a
realização de exames de diagnóstico por imagem.
Nesse sentido, tendo como objetivo tornar possível a disponibilização desses
dados resume-se a hipótese de pesquisa a ser analisada no presente trabalho da seguinte
maneira: Como disponibilizar as clínicas e aos hospitais informações estratégicas para
auxiliar no processo decisório utilizando os dados existentes em PACS?
1.2
OBJETIVOS
No presente capítulo são abordados os objetivos da pesquisa.
1.2.1 Objetivo Geral
Este trabalho tem como objetivo construir um sistema de apoio ao processo decisório,
capaz de disponibilizar, através de dados existentes em sistemas de diagnóstico médico por
imagem, informações estratégicas para clínicas e hospitais.
14
1.2.2 Objetivos Específicos

Realizar a pesquisa bibliográfica sobre o tema abordado;

Modelar um banco de dados dimensional para armazenamento dos dados da aplicação;

Extrair dados quantitativos contidos no sistema de PACS;

Testar e avaliar os resultados obtidos;

Disponibilizar informações obtidas em forma de gráficos com indicadores
institucionais em uma ferramenta analítica.
1.3
JUSTIFICATIVA
Atualmente, grande parte dos PACS carecem de informações estatísticas sobre
dados existentes no sistema, tornando ocultas informações relevantes ao processo de gestão
da instituição. Implementar esse tipo de análise permite a obtenção de informações úteis que
apoiam o processo decisório das instituições médicas como, por exemplo: saber qual o
médico mais eficiente ou ineficiente da equipe, sendo possível tomar decisões estratégicas
mais inteligentes na escolha da equipe; saber qual modalidade de exame é a mais executada,
deixando claro se existe ou não a necessidade de adquirir mais equipamentos para suprir a
demanda de atendimentos, e medir o tempo gasto entre cada etapa da realização do exame,
sendo possível identificar e corrigir os pontos mais ineficientes do processo.
Desta forma, o conjunto de dados disponíveis nestas instituições pode ser
utilizado para aplicação de um sistema que os transforme em informações qualitativas
importantes para o apoio à tomada de decisão pelos seus administradores, possibilitando
realizar controles e ajustes mais assertivos na organização, principalmente nos setores de
radiologia e seus envolvidos.
15
1.4
ESTRUTURA DO TRABALHO
Este trabalho está estruturado em seis capítulos. No capítulo 1 são apresentados os
problemas encontrados e as justificativas deste trabalho.
No capítulo dois é apresentada a fundamentação teórica e são abordados os temas
que apoiam a pesquisa.
No capítulo três é apresentado o método utilizado, caracterizando o tipo de
pesquisa.
No capítulo quatro é apresentada a modelagem do sistema.
No capítulo cinco é apresentado o protótipo construído, seus resultados e
validações.
No capítulo seis as conclusões da pesquisa são apresentadas e também são feitas
recomendações para trabalhos futuros.
16
2
FUNDAMENTAÇÃO TEÓRICA
No presente capítulo são abordados os conceitos teóricos relacionados ao
trabalho. São contextualizados conceitos referentes à área de Business Intelligence, Data
Warehouses, Modelagem Dimensional, ETL (Extract Transform and Load) e OLAP (On-line
Analytical Processing). Também são enfatizados os conceitos referentes à Radiologia, aos
Sistemas de Informação Radiológica (Radiology Information Systems) e aos Sistemas de
Comunicação e Arquivamento de Imagens (Picturing Archiving and Communication
Systems).
2.1
SISTEMAS DE BUSINESS INTELLIGENCE
Business Intelligence (BI) pode ser considerado um guarda-chuva de conceitos,
elaborados com o intuito de estruturar, acessar e explorar informações distribuídas em
diversas fontes de dados, possibilitando desenvolver percepções, entendimentos e
conhecimentos importantes, auxiliando no processo decisório das organizações (BARBIERI,
2001).
Segundo Atre e Moss (2003) BI não pode ser considerado um produto ou sistema,
mas sim uma arquitetura que fornece suporte ao processo decisório, através de operações
integradas, capaz de prover aos tomadores de decisões, de maneira simplificada, informações
relevantes ao negócio. No entanto, Inmon (1997) classifica como Sistemas de Apoio a
Decisão (SAD) todo processamento analítico ou informacional que atenda e auxilie a tomada
de decisão dos gestores.
BI está sendo visto como uma abordagem mais evoluída da modelagem de dados,
sendo capaz de disponibilizar as informações de maneira correta e estruturada, possibilitando
a extração de diversas fontes como a obtenção através de técnicas de CI (Competitive
Intelligence) e/ou KMS (Knowledge Management Systems), permitindo a aplicação de
transformações e o armazenamento em estruturas dimensionais de modelagem de dados,
como Data Warehouses e/ou Data Marts, independente de sua origem. Posteriormente, essas
17
informações podem ser interpretadas por ferramentas OLAP (On-Line Analytical Processing)
e/ou utilizadas em ferramentas de Data Mining. (BARBIERI, 2001).
O fluxo de dados e informações de um BI, de forma simplificada e contemplando
apenas parte de seus componentes, é apresentado na Figura 1.
Figura 1 – Fluxo de Dados e Informações
Fonte: Adaptado de Fortulan e Gonçalves (2005 pag. 57).
Harrison (2002) afirma que aumentar o capital intelectual de uma organização,
através de uma tecnologia de informação bem formulada, é uma necessidade competitiva, que
possibilita vantagens mercadológicas importantes. Essa estratégia fornece armas capazes de
alavancar os negócios e, consequentemente, abalar seus concorrentes.
Nesse sentido, tornar-se competitivo em tempos atuais, exige, cada vez mais, que
as organizações possuam ferramentas capazes de extrair conhecimento de diversas fontes.
Esse conhecimento é necessário para entender as necessidades de seus clientes e as mudanças
no mercado, possibilitando assim vantagens estratégicas em situações menos favoráveis
(HEINRICHS e LIM, 2003 pag. 106).
Atre e Moss (2003) descrevem a necessidade de ferramentas de BI para obtenção
de vantagens comerciais, da seguinte forma:
18
Nos competitivos dias atuais e no aumento da incerteza mundial, a qualidade e a
conveniência da organização de uma aplicação de Business Intelligence (BI) pode
significar não só a diferença entre lucro e perda, mas também a diferença entre
sobrevivência e falência.
A RSR Research (2011), ao obter informações sobre qual o valor do BI como
ferramenta de suporte aos processos de negócio das organizações inseridas no mercado
varejista, apresenta o gráfico contido na figura 2.
Figura 2 – Valor do BI como Suporte aos Processos Decisórios
Fonte: Tradução nossa de RSR Research (2011)
Observa-se, conforme a Figura 2, que 62% das empresas pesquisadas
classificaram como “muito relevante” o uso de análises provenientes de sistemas de apoio a
decisão para deter maior controle dos processos internos, e comparar indicadores de
performance atuais contra o que foi planejado; contra apenas 5% que classificam como
“Pouco ou Não Relevante” a importância desses mesmos dados. Também conceituam como
“muito relevante” (57%) a importância do BI para entender o comportamento dos clientes, a
fim de apoiar estratégias de negócio e a construção de uma política de fidelização. Também,
percebe-se a preocupação com o uso do BI para realizar ações mais rápidas em situações de
19
mudança e evitar problemas futuros. Ainda 42% das empresas concordam que ambos os
fatores são “muito relevantes” para apoio aos processos gerenciais.
Contudo, Lobo (2002) ressalta que BI não é um conceito de gerenciamento de
informações, essas atribuições devem ser preenchidas por ferramentas Supply Chain, ERP e
CRM, que têm como objetivo organizar os processos dos negócios. BI é o apoio a essas
ferramentas, permitindo que a informação seja difundida e analisada pelos administradores do
negócio.
RSR Research (2011) aborda, ainda, o crescimento de soluções de Business
Intelligence nas organizações, conforme Figura 3.
Figura 3 – Nível do BI nas Organizações
Fonte: Tradução nossa de RSR Research (2011)
Percebe-se então, conforme a Figura 3, que o interesse no desenvolvimento e
aplicação dessas soluções é crescente. Das organizações pesquisadas, 80% já possuem ou
estão trabalhando para possuir ferramentas de inteligência corporativa, reforçando a
necessidade de acesso a uma quantidade maior de informações de negócio.
20
2.1.1 Data Warehouse
Inicialmente, os bancos de dados foram concebidos com o objetivo de realizar
processamento de dados operacionais e analíticos, porém o foco sempre se voltou em atender
a necessidade de realizar processamentos operacionais mesmo com a existência de usuários
para ambos os casos. Devido à progressão do tema, surgiu a necessidade da criação de bancos
de dados distintos, surgindo assim o chamado data warehouse (GRAY; WATSON, 1999).
Segundo Kimball e Ross (2002), a informação é um dos principais ativos das
organizações, sendo mantida, normalmente, em sistemas operacionais, que podem ser
definidos, de maneira superficial, como sistemas responsáveis pela entrada dos dados; e data
warehouse, que representam a saída dos dados.
Inmon (1997) define DW como: “[...] um conjunto de dados baseado em assuntos,
integrado, não volátil e variável em relação ao tempo, de apoio às decisões gerenciais.”
Usuários de sistemas de operação, garantem que a “engrenagem” da organização esteja
sempre girando, realizando operações vitais para o processo organizacional, como registros de
vendas, clientes e relatórios. Normalmente esse tipo de usuário trabalha com apenas uma
informação por vez, repetidamente, sempre executando as mesmas funções. No outro lado, os
usuários de DW desempenham o papel de analisar de que forma a “engrenagem” da
organização está girando, agrupando os dados de acordo com períodos específicos e
comparando com datas anteriores. Esses usuários nunca lidam com apenas uma informação
por vez, pois as análises exigem, muitas vezes, a realização de buscas em centenas de
milhares de dados simultaneamente, que podem ser comprimidos e escalonados, de modo que
gerem informações passíveis de interpretação e capazes de fornecer respostas aos
questionamentos iniciais (KIMBALL; ROSS, 2002, pag. 2).
Os autores esclarecem, também, que um DW deve existir para responder
questionamentos comuns e recorrentes na gestão dos negócios. Deste modo, apontam alguns
requisitos que devem ser atendidos:

O DW deve permitir o acesso fácil as informações da organização: O conteúdo de
um data warehouse deve ser compreensível, intuitivo e claro para qualquer usuário
analítico. Deve ser legível, com conteúdo armazenado de maneira organizada,
21
possibilitando que os usuários realizem, de maneira simplificada, o cruzamento de
vários tipos de dados de maneira otimizada.

O DW deve apresentar as informações da organização de maneira consistente:
Os dados devem ser armazenados de maneira consistente, independentemente da
origem, de modo que sejam disponibilizados apenas quando já está pronto para ser
consumido. Informações iguais de fontes diferentes devem ser combinadas, evitando a
redundância, porém informações diferentes de fontes diferentes, devem ser rotuladas,
de modo que possam ser identificadas com facilidade. Garantir a coesão dos dados é
prover informações de qualidade.

O DW deve estar preparado para mudanças: Mudanças fazem parte do dia-a-dia,
são inerentes aos processos do negócio e às necessidades do usuário. Constantemente
existem mudanças de tecnologia, processos e regras de negócio. O DW deve estar
preparado para aceitar quaisquer mudanças, garantindo que não sejam perdidos os
dados existentes e que os mesmos sirvam para responder novos questionamentos.

O DW deve fornecer segurança às informações contidas nele: Informações
preciosas sobre a organização são armazenadas no DW. De modo geral, existirão
informações corporativas de vendas, informações de clientes e detalhes de processos
do negócio. Por esse motivo, torna-se necessário que exista uma preocupação especial
com a segurança da informação, provendo soluções efetivas de controle de acessos de
usuários.

O DW deve servir à organização como ferramenta ao apoio decisório:
Informações inseridas em um DW devem ser relevantes para a organização, de modo
que sirva como apoio à decisão. Essa é a premissa fundamental para a existência de
um data warehouse.

O DW deve ser aceito pela comunidade empresarial: De nada importa se a solução
foi modelada e construída de maneira excepcional se não é disseminada a utilização
dessa ferramenta. A aceitação do DW está diretamente relacionada a sua simplicidade
e usabilidade, por isso deve ser desenhado com o objetivo de evidenciar que o uso da
ferramenta trará benefícios corporativos.
22
2.1.2 Modelagem Dimensional
A modelagem dimensional tem como objetivo fornecer a visualização dos dados,
de maneira intuitiva e simplificada. Um modelo dimensional bem formulado deve ser
compreensível e navegável, de modo que usuários analíticos não encontrem dificuldades na
utilização do modelo. Também, deve ser entendido como uma forma mais simples de
modelagem de dados, quando comparado a um modelo Entidade Relacionamento (ER)
(MORALES, 2013).
Para Machado (2004, pag. 79), a modelagem multidimensional pode ser vista
como um conjunto de medidas que descrevem aspectos comuns do negócio, sendo utilizada,
em grande parte, como forma de reestruturar dados e apresentá-los de forma que possam ser
analisados.
Um exemplo de modelagem de dados é o modelo estrela que será apresentado na
seção a seguir.
2.1.2.1 Modelo Estrela
O esquema em estrela (star schema) é considerado a forma mais simples de
modelagem em soluções de data warehouse. Recebe o nome de estrela, devido ao
posicionamento das tabelas no esquema lembrarem uma estrela. Neste modelo a tabela de
fatos é centralizada (centro da estrela), e as tabelas de dimensão são distribuídas em sua volta
(pontas da estrela) (ORACLE, 2002). Um esquema em estrela é um projeto de banco de dados
lógico que está incluído nas aplicações de apoio à decisão IBM (2013 A).
Exemplo de modelagem ou esquema estrela, pode ser observado na figura 4.
23
Figura 4 – Modelo Estrela
Fonte: Tradução nossa de Kimball e Ross (2002)
A empresa Oracle (2013), líder mundial em fornecimento de sistemas de gestão
de banco de dados, afirma que a maneira natural de se modelar um data warehouse é através
da aplicação do modelo estrela, pois essa modelagem possibilita um relacionamento entre
tabelas de fato e tabelas de dimensão através de uma ligação simples (JOIN). Queries de
pesquisa serão simples neste modelo, proporcionando performance ao banco e um tempo de
resposta reduzido.
2.1.2.2 Tabela de Fatos
Para Barbieri (2001, pag. 81), tabelas de fato contém vários fatos, que servem
para armazenar medidas numéricas associadas a eventos de negócio. Também possuem
24
chaves compostas e primária, formadas pelas chaves primárias das dimensões com que elas se
relacionam. Contém dados normalmente aditivos e relativamente estáticos. (BARBIERI,
2001, pag. 81).
Tabela de fatos pode ser considerada a tabela principal nos modelos dimensionais.
A tabela de fatos é responsável pelo armazenamento das medidas (variáveis de desempenho)
do negócio. Os dados de medidas são a maior parte de um Data Mart (DM), sendo assim,
essas informações não devem ser replicadas em vários pontos da empresa (KIMBALL;
ROSS, 2002 pag. 16).
Exemplos de atributos típicos de tabela de fatos podem ser observados na figura 5,
apresentada em sequência.
Figura 5 – Tabela de Fatos
Fonte: Adaptado de Kimball e Ross (2002)
Cada linha em uma tabela de fatos representa uma medida. Todas as medidas em
uma tabela de fatos devem possuir a mesma granularidade. Medidas são, normalmente,
valores numéricos e mensuráveis, porém, ainda que raro, podem ser adotados valores textuais.
No entanto, essa pratica não é recomendada, pois é inviável realizar análises com valores
textuais livres, como descrição, por exemplo. (KIMBALL; ROSS, 2002 pag. 17-18).
Tabela de fatos tendem a ser profundas no que se refere a quantidade de linhas,
porém compactas em número de atributos. Nesse sentido, deve ser levado em conta o espaço
utilizado por esse tipo de tabela. Qualquer tabela de fatos terá duas ou mais chaves
estrangeiras, utilizadas para realizar ligações com as chaves primárias das tabelas
dimensionais. Isso serve para garantir a integridade das referências. Normalmente, a tabela de
fatos também possui a sua chave primaria, que é composta pelas chaves estrangeiras das
tabelas dimensionais. Tabelas que efetuam relacionamentos de N*N ou muitos para muitos,
devem ser tabelas de fatos. Todas as outras serão tabelas dimensionais. (KIMBALL; ROSS,
2002 pag. 18).
25
2.1.2.3 Tabelas Dimensionais
Tabelas dimensionais, também chamadas de dimensões, contém a descrições do
negócio e, se bem concebidas, devem possuir muitos atributos, responsáveis por descrever os
dados contidos em cada linha da tabela. Também são utilizados para restringir e/ou agrupar os
dados em cada consulta. Podem ser utilizados vários tipos de dados em tabelas dimensionais.
Ao contrário das tabelas de fatos, tabelas dimensionais são largas em número de colunas,
porém compactas em quantidades de linhas. Cada dimensão possuí uma chave primária única,
responsável pela ligação com a tabela de fatos (KIMBALL; ROSS, 2002 pag. 19).
Segundo Barbieri (2001 pag. 81), tabelas de dimensão representam entidades de
negócios, servindo como armazenamento de informações como tempo, local, produto, cliente,
etc. Tabelas dimensionais possuem relacionamento 1*N com a tabela de fatos e têm um
número bem inferior em quantidade de linhas. Possuem múltiplas colunas de informação que
podem representar a hierarquia, bem como uma chave primaria para garantir a unicidade,
chave essa que participa da tabela de fatos como chaves estrangeira. Tabelas dimensionais
devem ser entendidas como as tabelas que realizam a filtragem dos valores aplicados na
manipulação dos fatos.
Exemplo de atributos de tabelas dimensionais são apresentados na figura a seguir.
Figura 6 – Tabela Dimensional
Fonte: Adaptado de Kimball e Ross (2002)
Pode-se perceber, conforme figura 3, que tabelas dimensionais são, em grande
parte, formadas por atributos textuais, esses atributos agregam informações as análises e
enriquecem a informação.
26
A qualidade e a eficiência de um DW estão diretamente ligadas à qualidade e
profundidade dos atributos das tabelas dimensionais. Quanto maior o tempo gasto para
proporcionar atributos intuitivos e bem descritos, melhor será a solução de DW. Também é
importante, para garantir a qualidade do DW, que os atributos sejam preenchidos de forma
correta e precisa. Garantir a qualidade dos valores de cada coluna da tabela dimensional,
significa otimizar o uso da solução e, consequentemente, um DW melhor (KIMBALL; ROSS,
2002, pag. 19-20).
Conforme Kimball e Ross (2002, pag. 20):
Tabelas dimensionais são os pontos de entrada para a tabela fato. Atributos de
dimensão robustos significam uma melhor capacidade de produzir análises e
fatiamentos robustos. As dimensões representam a interface do data warehouse para
o usuário.
Atributos em tabelas dimensionais são a principal fonte para aplicação de
restrições e agrupamentos. Em consultas ou relatórios, os atributos são identificados por
palavras. Por exemplo, Quando um usuário decide verificar a quantidade da receita obtida na
venda de produtos, na última semana, por determinadas marcas; essas informações devem
constar como atributos dimensionais (KIMBALL; ROSS, 2002, pag. 19).
2.1.2.4 Granularidade
A granularidade se refere ao grau de detalhe e sumarização das unidades de dados
contidas em um data warehouse. Quanto mais detalhe existir, menor será o nível de
granularidade. Quanto menos detalhe existir, maior será o nível de granularidade. Nesse
sentido, a granularidade pode ser considerada como um dos aspectos mais importantes no
design de uma solução DW. Entretanto, também é considerada um dos principais obstáculos
no design em um ambiente de DW, pois lida diretamente com o volume de dados inseridos na
aplicação (INMON 2002, pag. 44).
Na maioria dos casos o conteúdo disponibilizado ao DW, possuí níveis altos de
granularidade, sendo necessário que os desenvolvedores gastem muito tempo realizando a
27
divisão do conteúdo em grãos menores. No entanto, os dados inseridos no DW tendem a
possuir níveis baixos de granularidade (INMON, 2002, pag. 44).
O diagrama da Figura 7 apresenta as diferenças e características entre os níveis de
granularidade de dados.
Figura 7 – Granularidade: Alto Nível x Baixo Nível
Fonte: Tradução nossa de Inmon (2002, pag. 49)
Para Inmon (2002, pag. 45) os dados granulares encontrados no data warehouse
são a chave para a capacidade de reutilização, uma vez que podem ser usados de diversas
maneiras por muitas pessoas. Isso significa que os mesmos dados podem ser disponíveis em
um DW podem ser aproveitados de formas diferentes por vários tipos de setores. Possibilitar
que a informação seja vista conforme a necessidade do usuário, garante que não haja
discrepâncias nos dados analisados por departamentos diferentes, tornando a organização
muito mais sólida de uma maneira simples.
2.1.3 ETL (Extract Transform and Load)
Para que possam ser realizadas análises de negócio, é necessário que sejam
copiados os dados, disponíveis em diversas fontes operacionais, para um data warehouse.
Esse processo de extração de dados de sistemas operacionais, transformação e inclusão em
28
um DW é normalmente chamado de ETL, sigla do inglês para Extract Transform and Load. A
metodologia ETL é conhecida há muito tempo e não é uma exclusividade de ambientes de
data warehouse. Diversas aplicações possuem a necessidade de realizar integrações de dados
e compartilhamento de informações entre dois ou mais sistemas. Nesse sentido, diversos
mecanismos que desempenham essa função são chamados de ETL (ORACLE, 2002).
Para Turban et al. (2010 pag. 47), o processo ETL é o coração no lado técnico do
DW, sendo utilizado para extrair dados através de leituras de uma ou mais bases de dados.
Transformar e normalizar estes dados conforme desejado, de modo que se adeque as
necessidades do DW ou de outra base de dados. Por fim, carrega-los dentro do DW,
concluindo o processo de inserção dos dados extraídos.
Segundo Barbieri (2001, pag. 74), a etapa ETL representa o processo de
transformação da modelo fonte de dados para o modelo dimensional. Se tratando de Business
Intelligence, os mecanismos ETL, além de prover a integração entre diversos sistemas e
normalizar as informações entre eles, devem lidar com um volume elevado de dados em
ambientes de DW (ORACLE, 2002).
A corporação explica, ainda, o processo ETL da seguinte forma:
1) Extração: São escolhidos os dados desejados, disponíveis nas diversas
fontes de dados. Muitas vezes, não é possível identificar nessa etapa todos
os dados que serão utilizados, ocasionando uma carga de dados maior do
que a necessária. Uma filtragem mais refinada deve ser feita nos próximos
passos do processo.
2) Transformação: São aplicados filtros e transformações nos dados
extraídos. Nessa etapa os dados de diferentes fontes podem ser
normalizados, recebendo nomes idênticos para informações idênticas.
Também podem ser enriquecidos e agrupados, gerando uma qualidade
maior nas informações disponibilizadas. Esse processo pode ser realizado,
muitas vezes, no momento da extração dos dados. Porém, isso dependerá
da capacidade da aplicação de origem e seus recursos disponíveis para
processar as informações.
3) Transporte: Uma vez realiza a extração e a transformação dos dados,
esses registros devem ser transportados fisicamente para o sistema de
destino, como data warehouse e data marts, por exemplo.
29
A figura a seguir descreve os processos envolvidos na operação de ferramentas
ETL.
Figura 8 – Processos ETL
Fonte: Turban et. Al (2010, pag. 48)
A Figura 8 evidencia o processo ETL, que compreende uma séria de etapas desde
a extração dos dados de diversas fontes; aplicação de transformações, normalizações e
limpezas; até o carregamento dessas informações em modelos dimensionais especializados,
como DW e/ou DM.
Para Inmon (2002, pag. 122), software ETL servem para automatizar os processos
de conversão, reformatação e integração de dados operacionais, provenientes de diversas
fontes. Somente em circunstâncias incomuns e raras será viável construir e manter os dados
em um data warehouse manualmente.
Brown (2004) apud Turban et al. (2010 pag. 48-49) aponta alguns critérios
importantes que devem ser levados em conta no momento de escolher uma ferramenta de
ETL:

A ferramenta deve possuir a habilidade de ler e escrever em diversos tipos
de arquiteturas de dados.

Capturar e disponibilizar meta-dados automaticamente.

Possuir interfaces de fácil manipulação e uso, tanto para desenvolvedores,
quanto para usuários funcionais.
30
2.1.4 OLAP (On-Line Analytics Processing)
Processamento analítico on-line (OLAP), assim como sugere o nome, se refere ao
processamento analítico de dados no decorrer das transações. Ferramentas OLAP são capazes
de prover analises de dados de acordo com as necessidades do negócio, (TURBAN et. al.,
2005, pag. 88). Representa a característica de se trabalhar os dados como operadores
dimensionais, possibilitando uma forma múltipla e combinada de análise (THOMSEN, 2002,
pag. 5).
OLAP de data marts são extensões da arquitetura de um data warehouse, cujo
papel é facilitar a mineração de dados. Opera, normalmente, utilizando dados com altos níveis
de sumarização, ao contrário do que é encontrado em ambientes de DW (INMON, 1996 pag.
50).
O processo principal em um OLAP é relacionado ao conceito de cubo. Cubo é
uma estrutura multidimensional que permite análises de dados de maneira ágil e eficiente,
além de possuir a capacidade de manipulação e análise de dados com multi-perspectivas
(TURBAN et al. 2010, pag. 57).
A Figura 9 apresenta um exemplo do conceito de cubo de dados.
Figura 9 – Cubo de Dados
Fonte: MICROSOFT (2007)
31
Para Kimball e Ross (2002, pag. 395) Cubos são estruturas de informações em três
dimensões, basicamente divididas em produto, mercado e tempo, conforme
apresentado na figura 9. Usando OLAP, um analista pode navegar através do banco de
dados e tela para um subconjunto específico dos dados (e sua progressão ao longo do tempo),
alterando as orientações da data e as definições dos cálculos analíticos. Estes tipos de
navegação iniciada pelo usuário dos dados através da especificação de slice (rotações) e drill
down/up (agregação e desagregação) são às vezes chamados de "slice and dice". Operações
OLAP comumente incluem slice and dice, drill-down, roll-up, e pivot. (TURBAN et al. 2010,
pag. 57).
Boas informações são essenciais para que sejam tomadas boas decisões de
negócio. Desta forma, OLAP, assim como qualquer outra forma de processamento de
informações, deve oferecer informações existentes, oportunas, precisas e inteligíveis.
(THOMSEN, 2002, pag. 8).
OLAP deve servir como apoio ao processo decisório, fornecendo respostas aos
questionamentos dos negócios. (TURBAN et al. 2010, pag. 57).
Execução de OLAP tendem a ser lentas, complexas e com consultas de grande
escala, por esse motivo são necessários recursos operacionais favoráveis, como
multiprocessadores, capacidade elevada de armazenamento de dados, e banco de dados
especializados (TURBAN et al. 2010, pag. 57).
2.1.4.1 Operações Drill-Up e Drill-Down
Drill-Up realizam operações de agregação em um cubo de dados, através da
elevação do nível da hierarquia. Esta operação reduz a dimensão dos dados. Uma massa de
dados apresentada por Localização x Quantidade x Produto, pode ser agrupada por
Localização, por País ao invés de Cidade, por exemplo. Já Drill-Down, são operações
contrarias ao Drill-Up, pois descem na hierarquia, navegando para um nível maior de detalhes
na análise dos dados. Adicionam dimensões. (WAND, 2013).
Para TURBAN et al. (2010, pag. 58), as duas operações representam a técnica em
OLAP que permite que o usuário navegue entre dados mais sumarizados (drill-up) para dados
mais detalhados (drill-down) e vice-versa.
32
2.1.4.2 Operações Slice and Dice
Representa uma fatia de um subconjunto de uma matriz multidimensional,
normalmente com duas dimensões. (TURBAN et al. 2010, pag. 58). Operações de Slice
fatiam o cubo de dados selecionando uma dimensão. Já operações de Dice, fatiam o cubo em
duas ou mais dimensões, gerando um cubo secundário, derivado do cubo inicial de dados
(WAND, 2013).
A Figura 10, apresentada em sequência, exemplifica algumas operações Slice and
Dice.
Figura 10 – Operação de Slice and Dice
Fonte: Tradução nossa de TURBAM et al. (2010, pag. 58)
33
2.1.4.3 Operações Pivot
Representam operações de rotação dos eixos de um cubo de dados, fornecendo
alternativas melhores de apresentação (WAND, 2013). São usados para modificar a
orientação dimensional de um relatório (TURBAN et al. 2010, pag. 58).
Um exemplo de operação Pivot pode ser observado na figura a seguir.
Figura 11 – Operação de Pivot
Fonte: O Autor (2014)
Observa-se, na figura 11, que a houve apenas uma mudança na apresentação das
informações, sem alterar o conteúdo analisado.
2.2
RADIOLOGIA
A história da Radiologia tem início em 1895, a partir dos experimentos do físico
alemão Wilhelm Conrad Roentgen, que deu início ao uso experimental de raios-X (RX).
Roentgen Realizou a primeira radiografia utilizando a mão esquerda de sua esposa, Anna
Bertha Roentgen, colocada em cima de um chassi com filme fotográfico, que recebia uma
fonte de radiação proveniente de um tubo, por 15 minutos. Após o término, com a revelação
34
do filme, foi possível observar os ossos e tecidos moles menos densos da mão de sua esposa
(SRP, 2013).
As descobertas de Roentgen revolucionaram a medicina, pois tornou-se possível a
visão do interior dos pacientes. A evolução desses métodos incrementou as pesquisas e
serviços de diagnóstico do ser humano (SPR, 2013). A evolução da radiologia teve mais um
marco na década de 1950, com o surgimento da ultrassonografia (USG), tornando-se popular
em 1960, e tendo as primeiras maquinas de visualização em tempo real nos anos de 1970. Já
em 1972 foi apresentado o primeiro equipamento de tomografia computadorizada (TC),
baseado nos princípios inventados por Godfrey Hounsfield. (BIR, 2013). Em 1983 surge a
Ressonância Magnética (RM) para uso diagnóstico.
Desde a invenção dos computadores até as últimas décadas, mesmo que
lentamente, foram feitos progressos na área de saúde, visando melhorar a qualidade e a
eficiência do atendimento ao paciente. Isso se deve a mudanças na tecnologia em diversos
aspectos das especialidades médicas, como por exemplo, a radiologia. Especialmente no que
se refere a aquisição de imagens, armazenamento, visualização e interpretação; e a melhor
melhora na comunicação entre profissionais da saúde, médicos e pacientes. O sonho do
passado, em ter um centro radiológico totalmente digital, já é a realidade de hoje (LIU;
WANG, 2011, pag. 1).
2.2.1 Sistemas de Informação na Área Médica
Profissionais da área da saúde e governantes buscam frequentemente melhorar os
serviços médicos prestados, além de reduzir os custos operacionais. Nesse sentido, a
tecnologia de informação tem um papel importante nesta área. A informação está presente nos
dias de hoje de maneira muito mais efetiva que em tempos passados (LIU; WANG, 2011).
O’Brien e Marakas (2008 apud ZWICKER; PEREZ, 2009, pag. 178), definem
sistemas de informação como a integração de pessoas, dados, software, hardware e redes de
comunicação. Sendo capaz de receber os dados coletados e transformá-los e organizá-los em
informações úteis para a sociedade e organizações.
Nas últimas duas décadas, houveram diversas mudanças na área de radiologia,
como o surgimento de diversas modalidades de diagnóstico por imagem, como a ressonância
35
magnética (RM); tomografia computadorizada (TC) e tomografia computadorizada de
emissão pósitrons (PET/CT), exigindo formas melhores de otimizar os cuidados com os
pacientes. Nos últimos 15 anos houve um aumento significativo do uso de sistemas de
informação para prover mais qualidade no atendimento ao paciente. Alguns sistemas
informáticos ganharam destaques nesses ambientes, como distribuição e armazenamento de
imagens (PACS); associados a sistemas de gestão clínica e hospitalar, como EHR (Eletronic
Health Record) e RIS/HIS (Radiology/Hospital Information System). Dessa forma tornando
muito mais eficiente o fluxo de trabalho dessa área (LIU; WANG, 2011 pag. 1).
Blois e Shortliffe (1990 apud SBIS, 2013), definem a informática na área da saúde
como "um campo de rápido desenvolvimento científico que lida com armazenamento,
recuperação e uso da informação, dados e conhecimento biomédicos para a resolução de
problemas e tomada de decisão".
A utilização de modernos sistemas de informações está sendo difundida cada vez
mais, exigindo que diferentes grupos de trabalho atuem de forma colaborativa e integrada em
prol de objetivos em comum (LARSEN; MCGUIRE, 1998 apud ZWICKER; PEREZ, 2009,
pag. 176). O uso de SI na área de saúde representa bem este tipo de situação, uma vez que
diferentes grupos de pessoas como médicos, enfermeiros e outros profissionais, atuam
buscando a melhora nos atendimentos prestados aos pacientes. Contudo, sistemas de
informação voltados para a área médica, precisam satisfazer diferentes tipos de usuários e
lidar com a mudança de processos e métodos de trabalho profundamente enraizados nesse
ambiente profissional. Implantar novos sistemas pode ser um obstáculo, gerando desconforto
e um bloqueio (CHO; MATHIASSEN; NILSSON, 2008 apud ZWICKER; PEREZ, 2009,
pag. 176).
A aquisição de equipamentos complexos de diagnóstico por imagem é comum na
área médica, exigindo que tais equipamentos sejam operados por profissionais altamente
habilitados e dedicados ao seu uso. O uso do equipamento constitui a atividade-fim desses
profissionais os quais não intervém em rotinas organizacionais. As eventuais dificuldades de
adoção desses sistemas podem ser associadas ao treinamento desses profissionais (TULU;
HORAN; BURKHARD, 2005 apud ZWICKER; PEREZ, 2009, pag. 176).
Para Chiasson e Davidson (2004 apud ZWICKER; PEREZ, 2009, pag. 177), o
surgimento de oportunidades para o desenvolvimento e aprimoramento de teorias de sistemas
de informação na área de saúde, deve-se ao seu contexto único e peculiar, com usuários de
alto nível profissional, cuja liberdade de ação e autonomia pode ser fundamental.
36
Helms, Moore e Ahmadi (2008 apud ZWICKER; PEREZ, 2009, pag. 179)
mostram o potencial existente no uso de sistemas de informação na área da saúde,
incrementando a segurança do paciente e gerando maior eficiência operacional. Contudo, o
uso desses sistemas também apresenta fraquezas relevantes, como a falta de integração e a
resistência dos usuários quanto o uso de novas tecnologias ou mudanças nos processos, por
exemplo.
SI na área da saúde envolvem uma gama de aplicações de diversos tipos e
funções, desde sistemas típicos de gestão de informações a sistemas de automatização e apoio
de tarefas de diagnóstico. (SBIS, 2006 apud ZWICKER; PEREZ, 2009, pag. 179).
Nos dias de hoje, a TI consome fatia significante de recursos das instituições de
saúde, gerando despesas sem gerar receitas diretamente. Entretanto, a implantação de PACS,
RIS e outros sistemas de informação clínica é cada vez mais necessária e reconhecida, pois
geram uma melhoria continua nas operações clínicas. Além disso, Agências governamentais
no mundo inteiro estão realizando investimento para implementar sistemas para um melhor
acesso das informações e uma gestão mais eficiente dos atendimentos. Todos estes
contribuem diariamente para o rápido desenvolvimento de PACS e RIS em sistemas de saúde
em todo o mundo. (LIU; WANG, 2011, pag. 7).
2.2.2 Sistemas de Comunicação e Arquivamento de Imagens (PACS)
Antes do uso de computadores em medicina, Raio-X (RX) era a única modalidade
médica disponível com produção de imagens. Nos anos de 1960 e 1970, foram introduzidas
técnicas de medicina nuclear, modalidades de ultrassonografia e tomografia computadorizada.
Em 1980, surgiu a ressonância magnética (RM). O surgimento dessas ferramentas, associado
ao desenvolvimento acelerado da tecnologia, contribuiu com o surgimento de técnicas
avançadas de diagnóstico por imagem para uso clínico. Ao contrário dos métodos de imagem
anteriores, TC e RM foram desenvolvidos para uso em computadores, através da
disponibilização de imagens digitalmente, por isso, desempenharam um papel fundamental na
formação da imagem. Além disso, os avanços na informática também contribuíram
significativamente para o rápido desenvolvimento da radiologia digital entre as décadas de 70
e 90. Durante os anos 80 e 90, quase todas as modalidades de imagem em radiologia passaram
37
utilizar imagens em formato digital, substituindo o formato analógico. Esta transição foi
fundamental para o sucesso dos sistemas de comunicação e arquivamento de imagens
(PACS), criando uma integração de todos os registros, incluindo as imagens digitais (LIU;
WANG, 2011, pag. 1).
Apesar do reconhecimento de muitas pessoas a respeito do uso de sistemas de
informação para a pratica da medicina, o conceito de digitalização de imagens médicas e
comunicação digital só começou a se popularizar no início da década de 1980. Nos primeiros
PACS, as imagens eram armazenadas em um sistema centralizado, havia pouca ou nenhuma
integração com sistemas de informação radiológica (RIS). Os dados de imagem eram
distribuídos para as estações de trabalho individuais quando necessário, e vários esquemas de
busca de dados de exames anteriores foram implementadas manualmente por falta de
integração com RIS. É importante ressaltar que avanços tecnológicos têm permitido
transferências de imagem mais rápidas e inteligentes, tornando o uso de PACS mais prático e
acessível para o uso clínico. Outros pontos importantes se referem aos avanços da resolução e
de iluminação da imagem em dispositivos de vídeo comuns, através de placas de vídeo
potentes e monitores eficientes, desempenhando papel fundamental para o uso de PACS no
ambiente clínico. (LIU; WANG, 2011, pag. 2-4).
Para Liu e Wang (2011 pag. 6), as atribuições de um PACS podem variar, porém,
de modo geral, devem incluir funções de exibição de imagens, arquivamento de dados e
componentes de gerenciamento. Muitas vezes dispõe, também, de recursos de impressão de
imagens radiológicas em impressoras comuns ou especializadas. Os autores explicam ainda,
no que se refere a expectativa de um usuário no uso de um PACS:
Para usuários em geral, o componente mais obvio de um PACS é a visualização de
imagens e a estação de trabalho de visualização, que geralmente consiste de um
computador de mesa com vários monitores apropriados. Isto é o que a maioria dos
usuários PACS deseja ver e interagir. Na verdade, um PACS é muito mais complexo
do que as estações de trabalho colocadas em torno de uma instituição de saúde.
A figura apresentada
em
sequência descreve
algumas das
principais
funcionalidades e o fluxo da informação em sistemas de comunicação e arquivamento de
imagens (PACS), conforme visão da empresa Pixeon, uma das maiores empresas brasileira no
ramo de tecnologia para medicina diagnóstica.
38
Figura 12 – Fluxo de Funcionamento PACS
Fonte: Broering (2013 B).
A figura 12 demostra o processo de um PACS. Seu início é tipicamente
determinado pela aquisição das imagens provenientes de equipamentos de diagnóstico por
imagem. Essas informações são armazenadas e disponibilizadas para interpretação. As
informações geradas e/ou armazenadas também podem ser integradas com sistemas de gestão
de informação e/ou disponibilizadas através de diversos meios, como em mídias digitais,
impressões, internet, etc.
2.2.2.1 Vantagens e Benefícios
Segundo Liu e Wang (2011 pag. 6), os maiores benefícios desses sistemas
consistem em aumento da eficiência nos processos de aquisição, visualização e interpretação
das imagens radiológicas, melhorando significativamente a qualidade no atendimento do
paciente. Comparado com outros sistemas, PACS permite um gerenciamento muito mais fino
dos dados das imagens, prevenindo contra perdas das imagens, antes guardadas em filmes.
Também reduz custos e elimina riscos ambientais envolvidos na manipulação e
processamento dos filmes com produtos químicos. Porém, a implantação inicial tende a ser
39
cara, exigindo gastos com a aquisição do sistema e adequação de infraestrutura. Também são
necessários gastos com equipes de suporte de TI.
Antes da adoção de PACS, clínicas e hospitais mantiveram, por muitos anos, um
fluxo de trabalho radiológico definido a estruturado, baseado no processo de visualização e
manipulação das imagens por meio de filmes. Esse fluxo permaneceu relativamente inalterado
durante anos. Nesse ambiente, ordens de serviço e fluxo de informações eram feitos,
principalmente, através de trilhas de papel e imagens médicas capturadas em filmes,
geralmente com uma cópia por imagem. Esse fluxo limitava o acesso às imagens reais dos
exames, tanto pelos médicos solicitantes, quanto para os pacientes; ao menos que existissem
cópias dos filmes, o que era caro e ineficiente. A grande quantidade de filmes com imagens
era disponibilizada, amplamente, apenas ao médico radiologista, que interpretava as imagens.
Caso os filmes fossem perdidos, por algum motivo, era necessário que o exame fosse refeito,
gerando novas imagens, que deveriam passar pelo fluxo de trabalho novamente. Além de ser
um processo custoso financeiramente, gerava grande insatisfação por parte dos pacientes
(LIU; WANG, 2011, pag. 6).
2.2.2.2 Mercado
Atualmente, existem centenas de PACS comerciais disponíveis no mercado em
todo o mundo. Grandes fabricantes de equipamentos de imagem emergiram como os
principais fornecedores de PACS. No entanto, existem grandes quantidades de pequenas e
médias empresas no segmento, mesmo sem possuir a capacidade de instalação como grandes
fabricantes de equipamento de diagnóstico médico por imagem. Contudo, essas empresas
tendem a ser flexíveis, oferecendo ideias inovadoras e utilizando tecnologias avançadas (LIU;
WANG, 2011, pag. 7).
Pesquisa realizada pela empresa de consultoria Frost&Sullivan, sobre o número
de centros médicos que dispõem de serviços de diagnóstico por imagem em território
brasileiro, identificou que existiam pouco mais de 24 mil destes centros em operação, dos
quais, apenas 7% possuíam sistemas de comunicação e arquivamento de imagens (PACS)
(BROERING, 2013 B). Atualmente existem mais de 34 mil hospitais e/ou clínicas com
40
centros radiológicos em funcionamento no Brasil, independentemente do tamanho das
intuições em números de equipamentos. (CNES DATASUS, 2013).
2.2.3 Business Intelligence em PACS
A Saúde é uma das áreas onde há maior necessidade de informação para a tomada
de decisões. O crescimento da Informática na área da saúde pode ser atribuído, em grande
parte, aos avanços nas tecnologias de computação e comunicação, além da crescente
convicção de que o conhecimento médico e a grande quantidade de informações nesses
ambientes não podem ser gerenciadas manualmente. Também, devido à certeza de que os
processos de acesso ao conhecimento e tomada de decisão desempenham papel central na
Medicina moderna (SBIS, 2013).
Médicos radiologistas precisam, frequentemente, localizar determinados casos
estudados, para fins educacionais, de pesquisa, ou para identificar grupos de pacientes com
doenças específicas. Localizar este tipo de material pode ser uma tarefa difícil, complicada e
demorada. Em muitos casos, sendo necessária a realização de buscas individuais nos registros
de cada paciente. Sistemas de PACS são ricas fontes de dados, contendo diversas informações
referentes ao histórico dos exames realizados pelo paciente. Além disso, quando integrados a
sistemas de gestão, podem fornecer informações completas sobre todo o histórico do paciente
(RUBIN; DESSER, 2008, pag. 210).
Arquitetura de Business Intelligence já provou ser uma solução que realiza
melhoras significativas em vários segmentos, e a área de saúde não é diferente (DALY et al.
2008). Contudo, percebe-se conforme figura 13, que a fatia do mercado referente à área da
saúde ainda é muito baixa.
41
Figura 13 – Business Intelligence no mercado.
Fonte: Gartner (2009 apud MORALES 2013).
Daly et al. (2009) aborda a necessidade de uma melhoria e alteração nos processos
da radiologia, evidenciando a necessidade da substituição dos métodos antiquados:
Departamentos de radiologia hoje são confrontados com muitos desafios para
melhorar a eficiência operacional, desempenho e qualidade. Muitas organizações
contam com métodos antiquados, baseados em papel para rever o seu desempenho
histórico e entender suas operações. Com o aumento das cargas de trabalho
geograficamente dispersa aquisição de imagens e sites de leitura e rápida evolução
das tecnologias, esta abordagem é cada vez mais insustentável. (DALY et al. 2009).
Ainda, Segundo Daly et al. (2009), relatórios em papel podem responder apenas
uma pequena lista de perguntas que devem ser identificadas previamente. Ademais, tempo e o
esforço necessários para construir relatórios, aplicar filtros e organizar as informações, assim
como o tempo gasto, em seguida, para definir as medidas e tomar as decisões, é extremamente
lento com processos baseados em papel. Esse tipo de relatório, também não possui
granularidade para aprofundar os dados em certas medidas, impossibilitando que seja possível
visualizar os dados originais. Essa capacidade de conseguir visualizar os dados reais oferecem
um alto nível de confiança na compreensão de dados e tomada de decisões posteriores.
Em ambientes tradicionais, com relatórios em papel, muitas perguntas não podem
ser respondidas de imediato, exigindo uma preparação futura e alocação muito tempo. Ao
42
fornecer a capacidade de buscar dados, visualizar, e manipular conforme a necessidade,
através de ferramentas de BI, utilizando de painéis de visualização (dashboards), o tempo de
ação é reduzido, tornando muito mais eficiente à correção de eventuais problemas. Essa
tecnologia também permite que a visualização de informações estratégicas importantes seja
feita de maneira mais rápida e objetiva (DALY et al., 2009).
A Figura 14 apresenta um exemplo de como a implementação de BI nesta área
pode facilitar a visualização de indicadores importantes para o entendimento dos recursos
utilizados em certas operações do negócio:
Figura 14 – Tempo Médio de Espera para Exames de Mamografia
Fonte: Daly et al, 2009.
Dados apresentados, dinamicamente, em forma de gráficos, são considerados
muito mais atrativos e efetivos, uma vez que refletem a realidade de maneira muito mais
rápida e visual. Através de gráficos como apresentado na figura 13, fica muito mais viável e
possível identificar possível problemas e gargalos nos processos de realização de exames, por
exemplo.
Nos tempos atuais, a gestão do setor de radiologia sofre pressão para utilizar
menos recursos e prover mais qualidade. Nesse sentido, os profissionais de radiologia acabam
por procurar formas de obter mais eficiência e produtividade, sem sacrificar a qualidade.
Business Intelligence é uma ferramenta que, comprovadamente, pode ajudar empresas a se
tornar mais competitivas. Através do uso de sistemas de apoio a decisão é possível capturar
43
informações rotineiras utilizadas como indicadores de qualidade, de forma automatizada,
proporcionando uma melhora na compreensão das operações de cada departamento.
Daly et al. (2009) afirmam ainda que:
Para uma liderança comprometida com a excelência dos serviços e qualidades, o uso
de dashboards pode ser uma ferramenta poderosa para ajudar a melhorar o
desempenho na radiologia. Esforços contínuos de qualidade são amplamente
reconhecidos como elementos cruciais para um departamento de radiologia bem
sucedido. No entanto, os comitês e liderança de qualidade muitas vezes não têm as
ferramentas para conduzir eficazmente as alterações e permanecer relevante.
Ainda, segundo os autores, um painel gráfico fornece bons níveis de transparência
nas operações rotineiras, fortalecendo um método de gestão mais eficaz. Ele também significa
uma redução de esforços e tempo gasto na obtenção dos mesmos dados, quando comparados a
outros métodos.
44
3
MÉTODO
Neste capítulo são abordados os conceitos referentes à natureza da pesquisa
realizada, sua abordagem, seus objetivos e procedimentos técnicos utilizados. Também são
definidas as etapas do trabalho e os limites da pesquisa.
3.1
CARACTERIZAÇÃO DO TIPO DE PESQUISA
De acordo com conceitos extraídos de Silva e Menezes (2005, pag. 20), uma
pesquisa aplicada busca resolver um problema específico. Desta forma, esta pesquisa pode ser
classificada como uma pesquisa aplicada, pois tem como objetivo gerar conhecimentos
através de uma arquitetura de Business Intelligence, que será aplicada e dirigida à solução de
um problema específico.
Ainda, baseado em conceitos expostos por Silva e Menezes (2005, pag. 20), no
que se refere a abordagem do problema, a presente pesquisa se enquadra como uma pesquisa
qualitativa, pois visa a obtenção de dados existentes em sistemas de comunicação e
arquivamento de imagens (PACS), sem que haja a necessidade de traduzir essas informações
em dados estatísticos. O principal foco desta pesquisa é fornecer os insumos necessários para
demostrar a importância da implementação de um processo de BI em PACS.
No que se refere aos objetivos, a pesquisa pode ser considerada, baseado em
conceitos obtidos pela literatura de Silva e Menezes (2005, pag. 21), como exploratória, pois
visa entender melhor o ambiente dos CDI e tornar explícitos quaisquer problemas existentes.
Além de evidenciar padrões encontrados nestes tipos de estabelecimento.
Os procedimentos técnicos adotados nesta pesquisa, podem ser classificados, de
acordo com informações extraídas de Silva e Menezes (2005, pag. 21), como um estudo de
caso, tendo em vista que objetiva obter um conhecimento profundo e detalhado sobre os
procedimentos adotados em um centro de diagnóstico por imagem.
45
3.2
ETAPAS
As etapas deste trabalho estão segmentadas conforme fluxograma apresentado em
sequência.
Figura 15 – Fluxograma de Etapas
Fonte: O Autor (2014).

A primeira etapa compreende a fundamentação teórica da pesquisa,
apresentando conceito sobre a teoria de Business Intelligence e radiologia.
Aborda os conceitos de modelagem dimensional, data warehouse,
granularidade, ferramentas ETL e ferramentas OLAP. Também serão
apresentados conceitos de radiologia, sistemas de informação aplicados à área
da saúde e Business Intelligence na radiologia, consolidando o capítulo 2.

Na segunda etapa, são estudadas as ferramentas necessárias para a extração e
transformação de dados de PACS, bem como a realização da carga de dados
no data warehouse. Também serão estudadas ferramentas para a
46
disponibilização das informações extraídas e onde serão analisadas as
informações obtidas.

A terceira etapa compreenderá a definição das ferramentas estudadas que
serão utilizadas na implementação do sistema de apoio a decisão. Também se
define os requisitos da pesquisa, as regras de negócio escolhidas a suas
respectivas granularidades, que farão parte do Business Intelligence.

A elaboração do modelo dimensional; criação do data warehouse;
implementação da ferramenta escolhida para extração, transformação e carga
de dados, serão aplicadas na etapa quatro.

Na etapa cinco, será apresentado o protótipo construído, os resultados obtidos
e suas validações. Serão feitas as recomendações para o processo de análises
de dados e tomada de decisão.

Na etapa seis apresentam-se as conclusões da pesquisa e dos resultados
obtidos com a aplicação do Business Intelligence. Serão incluídas as
observações do autor sobre a presente pesquisa e suas recomendações para
trabalhos futuros.
3.3
DELIMITAÇÕES
O sistema de Business Intelligence desenvolvido neste trabalho está limitado à
aplicação de algumas regras de negócio referentes ao sistema de comunicação e arquivamento
de imagens (PACS). Serão desenvolvidos apenas os requisitos necessários para atender as
validações e objetivos propostos por esta pesquisa. Também serão utilizados dados fictícios
e/ou modificados, gerados apenas para os objetos estudados, de acordo com a relevância
destes para o desenvolvimento do trabalho, que será concebido como um protótipo e não
possuí obrigações comerciais com o sistema utilizado na aplicação do estudo de caso.
47
4
MODELAGEM
Sistemas de informação são formados por uma combinação de pessoas, dados,
processos, interfaces, redes de comunicação e tecnologias. Estes elementos interligados
operam com o objetivo de prover suporte aos processos de negócio e as informações que
estão inseridas dentro de uma organização empresarial. Também, no que se refere ao ponto de
vista estratégico, estes sistemas visam promover vantagens competitivas no mercado atual.
Nesse sentido, a construção de sistemas de informação demanda um planejamento inicial.
Essa necessidade leva ao conceito de Modelo, que é parte fundamental no desenvolvimento
de sistemas, pois representa uma idealização do projeto que será desenvolvido (BEZERRA,
2007 pag. 1-2).
Bezerra (2007 pag. 4) define modelagem de software como:
Utilização de notações gráficas e textuais com o objetivo de construir modelos que
representam as partes essenciais de um sistema, considerando-se várias perspectivas
diferentes e complementares.
Várias razões justificam a utilização de modelos no desenvolvimento de sistemas
e, para Bezerra (2007 pag. 3), algumas dessas razões que merecem destaque são:
1. Gerenciamento da complexidade: um dos principais motivos na adoção
de modelos de desenvolvimento de software é devido a limitação do ser
humano em lidar com complexidades. No desenvolvimento de um sistema,
várias partes diferentes podem ser desenvolvidas, cada uma com um
modelo específico e com perspectivas diferentes, de modo que cada
modelo descreva apenas as partes interessantes e relevantes para a
resolução de cada problema.
2. Comunicação entre pessoas envolvidas: o desenvolvimento de um
sistema pode envolver a execução de uma grande quantidade de
atividades, executadas por vários envolvidos. A utilização de modelos
fornece suporte à difusão de informações entre os indivíduos envolvidos
no processo de desenvolvimento de cada uma das atividades.
48
3. Redução de custos no desenvolvimento: o desenvolvimento de um
sistema é realizado por seres humanos, por isso, estarão sempre sujeitos a
erros, que podem acometer qualquer etapa do desenvolvimento. Contudo,
a utilização de modelos ajuda a prever e corrigir estes erros antes que o
desenvolvimento da aplicação tenha sido iniciado, tornando o processo de
correção muito mais barato, uma vez que a etapa de modelagem é mais
barata que a etapa de desenvolvimento.
4. Previsão de comportamentos futuros: modelar um sistema ajuda a
entender o comportamento de uma aplicação, sendo possível experimentar
uma série de modelagens diferentes para a resolução de um mesmo
problema, tornando muito mais assertiva a escolha do processo.
4.1
UML
A Unified Modeling Language (UML) teve seu início definido quando Jim
Rumbaugh e Grady Booch tentaram combinar os métodos Booch e OMT (Object Modeling
Language) de modelagem orientada a objetos. Posteriormente, o criador do método
Objectory, Ivar Jacobson, juntou-se a Jim e Grady, para a geração da primeira versão da
linguagem UML; concebida para visualização, especificação, construção e documentação de
softwares em desenvolvimento, permitindo a realização de modelagens de elementos,
relacionamento, mecanismos de extensibilidade e diagramas. Em 1997 a UML foi
incorporada pela OMG (Object Management Group), um grupo sem fins lucrativos
responsável por, entre outras coisas, manter e definir a linguagem (SAMPAIO, 2013).
Os autores da UML descrevem que um sistema pode ter cinco visões distintas e
independentes, conforme demonstrado na figura a seguir:
49
Figura 16 – Visões de um Sistema de Software
Fonte: Adaptado de Bezerra (2007 pag. 16).
Cada visão destacada na Figura 15, representa um aspecto específico no sistema,
sendo classificadas por Booch et al. (2000 apud BEZERRA 2007 pag. 15) do seguinte modo:
1. Visão de Casos de Uso: descreve a interação entre sistemas e agentes
externos, sendo criada inicialmente, servindo como um direcionamento
para o desenvolvimento das outras visões.
2. Visão de Projeto: enfatiza as características comportamentais e estruturais
que suportam as funcionalidades externas do sistema.
3. Visão de Implementação: aborda o gerenciamento de versões do sistema,
sendo construídas através da segmentação em módulos e subsistemas.
4. Visão de Implantação: Corresponde a distribuição física do sistema e a
integração entre as partes envolvidas.
5. Visão de Processo: apresenta as características de paralelismo,
sincronização e desempenho do sistema.
50
4.1.1 Artefatos
Processos de desenvolvimento que utilizam UML como linguagem de suporte a
criação de modelos, envolvem a criação de diversos documentos, gráficos ou textuais,
chamados pela terminologia da UML de artefatos. São esses artefatos que compõem as visões
de um sistema. (BEZERRA, 2007 pag. 16).
O autor afirma ainda que:
A UML é uma linguagem de modelagem visual, ou seja, é um conjunto de notações
e semântica correspondente para representar visualmente uma ou mais perspectivas
de um sistema.
Os diversos tipos de diagramas existentes na linguagem, bem como o
relacionamento existente entre esses componentes são descritos na figura a seguir.
Figura 17 – Diagramas UML
Fonte: Baseado em Bezerra (2007 pag. 17).
51
4.2
ICONIX
A metodologia ICONIX surgiu alguns anos após a criação da UML, sendo
formada com o objetivo de sintetizar e reunir as melhores técnicas existentes nas linguagens
que formaram a UML: Object Modeling Technique (OMT) de Jim Rumbaugh, Objectory de
Ivar Jacobson e Booch de Grady Booch. (ROSENBERG; STEPHENS; COLLINS-COPE,
2006 pag. 40).
De acordo com Rosenberg, Stephens e Collins-cope (2006 pag. 40), a sintetização
de métodos orientados a objetos é válida, pois as forças e fraquezas de cada um deles parecem
completar um ao outro. OMT era útil para o problema domínio de modelagem, mas não era
tão forte para o detalhamento da solução. O método Booch era forte em detalhamento, mas
pouco intuitivo em nível de análise. Já o método Objectory formou um conceito de um
modelo mais dinâmico do que o Booch e o estendeu para um passo-a-passo que leva a utilizar
a vista dos casos de uso com o diagrama de sequência, permitindo uma visão do
comportamento em tempo de execução. Tanto o método OMT quanto Booch são fortes na
criação de modelos estáticos, enquanto o método Objectory é principalmente focado em
tempo modelos que fornecem visões em tempo de execução e o comportamento dinâmico.
ICONIX fornece um processo lógico de baixo nível, permitindo ir de um caso de
uso para código. O que ele não aborda especificamente é a organização de alto nível de um
projeto, algo que metodologias ágeis tendem abordar. O processo ICONIX visa prover
métodos para escrever requisitos e casos de uso de modo que seja mais fácil verificar se o
código está de acordo com os requisitos levantados. Além disso, a metodologia é focada em
evitar a paralização de análises, sendo uma metodologia contrária a demanda de produção que
obriguem que todos os passos sejam atendidos antes de evoluir para a próxima etapa, com
isso, ICONIX é leve e interativa, focada em produzir códigos fonte o mais rápido possível,
sem deixar de lado os benéficos de uma modelagem bem realizada (ROSENBERG;
STEPHENS; COLLINS-COPE, 2006 pag. 41).
Para Rosenberg, Stephens e Collins-cope (2006 pag. 42), tudo na metodologia
ICONIX tem um propósito primário, sendo assim é focada na construção dos seguintes
diagramas:
52

Diagrama de Caso de Uso: Definir os requisitos de comportamento do
sistema;

Modelo de Domínio: Descreve o relacionamento dos objetos envolvidos;

Diagrama de Robustez: Remove as ambiguidades que possam existir no
diagrama de caso de uso;

Diagrama de Sequência: Define comportamentos e associa as funções às
classes.
A metodologia ICONIX trabalha com 4 marcos de desenvolvimento, demostrados
conforme figura apresentada em sequência.
Figura 18 – Processo ICONIX
Fonte: Rosenberg, Stephens e Collins-cope (2006 pag. 45).
53
4.3
ARQUITETURA PROPOSTA
Nesta seção apresenta-se a arquitetura proposta para o desenvolvimento do
projeto. Serão definidos os requisitos do sistema: funcionais e não funcionais. Também serão
apresentados os diagramas de Casos de Uso, Domínio, Robustez e Sequência; seguindo os
preceitos definidos pela metodologia ICONIX.
4.3.1 LEVANTAMENTO DE REQUISITOS
Bezerra (2007, pag. 20), afirma que o levantamento de requisitos é a etapa que
visa o entendimento do problema aplicado ao desenvolvimento de software, aonde usuários e
desenvolvedores devem a mesma visão do problema que deve ser solucionado.
4.3.1.1 Requisitos Funcionais
Segundo Bezerra (2007, pag. 21.), requisitos funcionais são responsáveis por
definir as funcionalidades de um sistema.
Os requisitos funcionais levantados para a este projeto são apresentados na figura
19, em sequência.
54
Figura 19 – Requisitos Funcionais
Fonte: O Autor (2014).
4.3.1.2 Requisitos Não Funcionais
Segundo Bezerra (2007, pag. 21), requisitos não funcionais são responsáveis por
declarar características qualitativas, de acordo com a funcionalidades propostas e que um
sistema deve atender.
Os requisitos não funcionais levantados neste projeto são apresentados na figura
20, em sequência.
Figura 20 – Requisitos Não Funcionais
Fonte: O Autor (2014).
55
4.3.1.3 Diagrama de Casos de Uso
Esta técnica de modelagem faz parte da UML e é parte integrante da especificação
de requisitos, pois molda os requisitos funcionais de um sistema. A técnica de modelagem de
casos de uso possui notação gráfica simples e linguagem natural, facilitando a comunicação
entre desenvolvedores e usuários. Modelos de casos de uso são compostos por casos de uso,
atores e o relacionamento entre eles. (BEZERRA, 2008, pag. 46).
Para Bezerra (2008, pag. 46), casos de uso especificam as interações do sistema e
seus agentes externos. Devem ser definidos todas as funcionalidades do sistema, sem que
sejam expostos detalhes de estrutura e de seu comportamento interno.
Os casos de uso levantados neste projeto são apresentados na figura 21, em
sequência.
Figura 21 – Diagrama de Casos de Uso
Fonte: O Autor (2014).
A tabela 1, disponibilizada em sequência, especifica e documenta os casos de uso
apresentados na figura 21.
56
Tabela 1 – Especificação de Casos de Uso
Caso de Uso
Descrição
UC01_01 – Executar ETL
Este caso de uso tem por objetivo permitir
ao usuário a invocação de fluxos ETL.
UC01_02 – Extrair Dados
Este caso de uso tem por objetivo permitir
a extração de dados operacionais pela
ferramenta ETL.
UC01_03 – Transformar
Este caso de uso tem por objetivo permitir
Dados
a transformação e normalização de dados
operacionais pela ferramenta ETL.
UC01_04 – Carregar Dados
Este caso de uso tem por objetivo permitir
a carga, pela ferramenta ETL, de dados
operacionais no Data Warehouse.
UC01_05 – Exportar Dados
Este caso de uso tem por objetivo permitir
a exportação, em formato CSV, de dados
extraídos do DW.
UC02_01 – Analisar Dados
Este caso de uso tem por objetivo permitir
que o usuário realize a análise de dados
contidos em planilha.
Requisitos
RF01
RF01
RF01
RF01
RF01, RF02
RF03, RF04
Fonte: O Autor (2014).
4.3.2 DIAGRAMA DE ROBUSTEZ
Diagramas de robustez envolvem uma análise sob as etapas definidas para cada
caso de uso, identificando as classes necessárias para que estes sejam atendidos. Essas classes
podem ser categorizadas em três tipos diferentes: boundary, entity e control. (IBM, 2014 B).
Está seção apresenta os diagramas de robustez modelados para este trabalho,
iniciando pela figura 22, modelada para definir as etapas do caso de uso UC01_01.
57
Figura 22 – Diagrama de Robustez - UC01_01
Fonte: O Autor (2014).
Figura 23 – Diagrama de Robustez UC02_01
Fonte: O Autor (2014).
A figura 23, apresentada em anteriormente, determina as etapas que devem ser
atendidas pelo caso de uso UC02_01.
58
4.3.3 DIAGRAMA DE SEQUÊNCIA
Diagramas de sequência são utilizados com o intuito de detalhar os cenários de
implementação existentes no sistema. Esses diagramas representam a interação entre os
objetos, determinando operações e resultados esperados por cada objeto. (IBM, 2014 B).
Os objetos envolvidos em um diagrama de sequência são apresentados através
linhas verticais, denominadas de lifelines. Linhas verticais determinam o fluxo de mensagens
adotado pelo sistema. As interações inseridas neste diagrama devem seguir uma ordem
cronológica, iniciando no topo do diagrama, até a parte mais baixa. (IBM, 2014 B).
Os diagramas de sequência elaborados para este projeto, serão apresentados na
figura 24.
Figura 24 – Diagrama de Sequência - UC01_01
Fonte: O Autor (2014).
A figura 25 determina a sequência de atividades estabelecida para atender o caso
de uso UC01_05.
59
Figura 25 – Diagrama de Sequência - UC01_05
Fonte: O Autor (2014).
O caso de uso UC02_01 tem sua sequência de atividades apresentada pela figura
26.
Figura 26 – Diagrama de Sequência - UC02_01
Fonte: O Autor (2014).
60
4.3.4 MODELO DIMENSIONAL
A modelagem dimensional, desenvolvida para este protótipo, é apresentada na
figura 27, a seguir.
Figura 27 – Modelo Dimensional
Fonte: O Autor (2014).
A Figura 27 representa o modelo físico do modelo dimensional, que será aplicado
na criação do DW. As entidades são descritas na tabela apresentada em sequência.
Tabela 2 – Solução Proposta
Entidade
DI_TEMPO_LAUDO
DI_TEMPO_ESTUDO
DI_ESTUDO
Descrição
Contém dados de calendário a partir das
datas de criação do primeiro e do último
laudo existente no sistema.
Contém dados de calendário a partir das
datas de criação do primeiro e do último
estudo existente no sistema.
Contém dados de todos os estudos existentes
no sistema.
61
DI_STATUS_LAUDO
DI_MEDICO
DI_PACIENTE
FT_LAUDO
Contém dados sobre todos os status de
produção de um laudo existentes no sistema.
Contém dados sobre todos os médicos
cadastrados no sistema.
Contém dados de todos os pacientes
cadastrados no sistema.
Tabela principal do DW. Contém dados
sobre laudos, agrupados por todas as
dimensões, e que foram produzidos no
sistema.
A tabela FT_LAUDO é a principal tabela do DW e se conecta com as outras
tabelas através de chaves estrangeiras de cada uma.
62
5
DESENVOLVIMENTO
No presente capítulo a solução é apresentada. São descritos os processos e
ferramentas utilizados para a concepção do protótipo. Por fim, são expostos os resultados
obtidos e suas validações, bem como as conclusões observadas.
5.1
TECNOLOGIAS E FERRAMENTAS
Nesta seção são apresentadas as tecnologias e ferramentas utilizadas no processo
de desenvolvimento do protótipo.
5.1.1 DB Designer Fork
DB Designer Fork é um fork da ferramenta DBDesigner 4 e integra
relacionamentos de entidades em uma interface gráfica, habilitada para executar consultas e
exportar scripts de linguagem SQL para Oracle, SQL Server, MySQL, FireBird, SQLite e
PostgreSQL. Essa ferramenta se destaca pelo seu fácil manuseio, permitindo que modelos
sejam criados e alterados rapidamente.
5.1.2 Structured Query Language (SQL)
Linguagem de consulta estruturada padrão para pesquisa em banco de dados
relacionais. Diferencia-se pela sua simplicidade, o que determina uma menor curva de
aprendizado para iniciantes na tecnologia. A linguagem SQL é focada no resultado e na forma
com que esses são apresentados.
63
5.1.1 Microsoft SQL Server 2012
O SQL Server 2012 é um sistema de gerenciamento de banco de dados (SGBD)
mantido pela Microsoft Corporation. Essa ferramenta atende aos requisitos para manter uma
alta disponibilidade do serviço, além de oferecer novas tecnologias na memória do xVelocity
que ajuda a habilitar o desempenho de consultas em Data Warehousing e Business
Intelligence (MICROSOFT, 2014).
Trata-se de uma ferramenta robusta que possui a vantagem de ser amplamente
integrável com ferramentas conhecidas como o Microsoft Excel, permitindo que os dados
existentes no banco de dados sejam visualizados dinamicamente nesta aplicação. Neste
trabalho o SQL Server 2012 foi utilizado para gerenciar a base de dados operacional do
sistema de PACS e o Data Warehouse construído.
5.1.2 Pentaho Data Integration - Kettle
PDI Kettle é uma ferramenta Extract, Transform and Load (ETL) desenvolvida
pela Pentaho, possuí licença livre e ótimo desempenho para extração e carga de grandes
volumes de dados. Além disso, possui inúmeras funções disponíveis capazes de atender os
mais variados cenários. Por se tratar se uma ferramenta com licença gratuita de fácil
manipulação e com grande poder de processamento, optou-se por utilizá-la no processo de
desenvolvimento do protótipo.
5.1.3 Microsoft Excel 2013
O Excel é uma ferramenta desenvolvida pela Microsoft Corporation, faz parte do
pacote Office, sendo um conhecido editor de planilhas disponível para Windows e Macintosh.
Possuí interface intuitiva e permite fácil manipulação, organização e análise de dados através
64
de tabelas e gráficos dinâmicos. Por ser uma aplicação desenvolvida pela Microsoft, a versão
atual oferece vários recursos para análise dinâmica de dados existentes em servidores OLAP.
Deste modo, por ser uma ferramenta conhecida no meio corporativo e por possuir fácil
integração com o SQL Server, o Excel foi escolhido como ferramenta para análise de dados
neste protótipo.
5.2
SOLUÇÃO PROPOSTA
A solução proposta consiste na criação de um Data Warehouse (DW) e na
apresentação dos dados através de uma ferramenta de análise de dados. Para tanto, utilizam-se
as seguintes ferramentas: Microsoft SQL Server 2012 Enterprise Core Edition, para
armazenamento da base relacional e dimensional; Structured Query Language (SQL) para
preparação e extração de dados; Pentaho Data Integration, para o processo de ETL, e
Microsoft Excel 2013, como ferramenta de análise de dados.
A figura 28, apresentada em sequência, apresenta o relacionamento entre os
artefatos envolvidos na solução.
65
Figura 28 – Diagrama da Solução
Fonte: O Autor (2014).
Para um melhor entendimento do diagrama, o quadro abaixo apresenta a descrição
dos itens elencados na figura 28.
Tabela 3 – Solução Proposta
Item
1) Exame Radiológico
2) PACS Aurora
3) Servidor Operacional
4) Ferramenta ETL
Descrição
Procedimento no qual o paciente é submetido para
extração de imagens utilizadas no auxílio ao
diagnóstico médico.
Sistema de comunicação e arquivamento de imagens
radiológicas geradas pelos equipamentos.
Servidor com banco de dados SQL Server 2012 com
dados operacionais do PACS Aurora.
Ferramenta ETL Data Integration da Pentaho utilizado
para efetuar o processo de extração, transformação e
carga entre o banco de dados operacional e o DW.
66
5) Servidor Data Warehouse
6) Análise de Dados
Servidor de Data Warehouse, com modelo dimensional,
em SQL Server 2012.
Computador pessoal para análise de dados do DW
através da ferramenta Microsoft Excel.
Fonte: O Autor (2014).
5.3
HISTÓRICO DE DESENVOLVIMENTO
O processo de desenvolvimento do protótipo decorreu conforme as seguintes
etapas.
1. Modelagem do esquema dimensional do DW através da ferramenta DB
Designer Fork. Nesta etapa foram definidas as entidades e seus atributos,
além dos tipos de dados, chaves e restrições.
2. Elaboração dos fluxos de extração e carga de dados na ferramenta Pentaho
Data Integration (Kettle). Os fluxos foram desenvolvidos com consultas
SQL que já retornam resultados normalizados e agrupados ao ETL, que
por sua vez carrega as informações no DW.
3. Análise dos resultados carregados no DW através da ferramenta Excel da
Microsoft, permitindo que os dados sejam analisados e manipulados
dinamicamente por um usuário analítico habilitado sem conhecimento
profundo em informática.
5.4
VALIDAÇÕES
No presente tópico são apresentados os processos de carga de dados e suas
validações, realizadas através da comparação dos dados operacionais com os dados obtidos
com a execução do DW.
67
5.4.1 Carga do Modelo DW
A solução desenvolvida, de acordo com os objetivos propostos é apresentada
neste tópico. O protótipo consiste na utilização conjunta das ferramentas e tecnologias
descritas anteriormente na massa de dados operacionais de um PACS Aurora, da empresa
Pixeon.
A figura 29, exibida em sequência, apresenta a interface de carga da dimensão
tempo, onde são criados os registros temporais do DW. Este fluxo consiste na extração da
data do primeiro e do último estudo e laudo realizado no sistema no momento da execução, e
na execução de scripts SQL para geração automática das dimensões DI_TEMPO_ESTUDO e
DI_TEMPO_LAUDO.
Figura 29 – Fluxo de Carga DI_TEMPO
Fonte: O Autor (2014).
O fluxo de carga da dimensão médico envolve o processo de coleta e extração das
informações dos médicos cadastrados no sistema PACS Aurora e a carga dos dados no DW.
A estrutura deste fluxo é apresentada na figura 30.
68
Figura 30 – Fluxo de Carga DI_MEDICO
Fonte: O Autor (2014).
Na figura 31 o fluxo de carga da dimensão DI_PACIENTE é apresentado. Este
processo consiste na extração de informações, já agrupadas, sobre os pacientes cadastrados no
sistema PACS Aurora.
Figura 31 – Fluxo de Carga DI_PACIENTE
Fonte: O Autor (2014).
O fluxo de carga da dimensão estudos, que recebe informações de todos os
estudos realizados no PACS Aurora, é exibido na figura 32. Esse processo consiste na
extração de informações dos exames/procedimentos realizados dentro do sistema para carga
da tabela DI_ESTUDO do DW.
69
Figura 32 – Fluxo de Carga DI_ESTUDO
Fonte: O Autor (2014).
A figura 33 apresenta o fluxo desenvolvido para efetuar a carga da tabela fato.
Esta tabela recebe informações agrupadas sobre os laudos elaborados no módulo de laudos do
PACS Aurora. As informações extraídas são cruzadas com as dimensões previamente
carregadas, finalizando o processo de carga do DW.
70
Figura 33 – Fluxo de Carga FT_LAUDO
Fonte: O Autor (2014).
Após a finalização dos processos de carga as informações já estão disponíveis
para análise no banco de dados dimensional. Entretanto, dados armazenados neste formato
demandam conhecimento técnico específico para que sejam acessados, por isso, visando
facilitar o processo de análise, o fluxo de extração apresentado na figura 34 foi desenvolvido.
71
Figura 34 – Fluxo de Carga FEX_DW_XLS
Fonte: O Autor (2014).
Os processos de carga apresentados anteriormente têm sua execução gerenciada
por um fluxo de controle de transformações. Este fluxo permite que a execução dos processos
de carga seja encadeada, garantindo assim que o fluxo seguinte só seja inicializado em caso
de êxito na execução do fluxo anterior. Ademais, a existência desse processo facilita a
operação do ETL. Sua estrutura pode ser observada na figura 35.
Figura 35 – Fluxo de Controle
Fonte: O Autor (2014).
72
5.4.2 Validação da Carga do DW
Para validar a solução construída, optou-se pela aplicação um comparativo dos
dados extraídos através de consultas SQL na base de dados operacional, em relação aos dados
existentes no arquivo de planilha obtido através da extração realizada no DW. Como
referência para a validação são comparados os resultados do número total de laudos gerados
no sistema de em cada ano de operação.
A figura 36 exibe a contagem da quantidade de laudos encontrada na planilha
gerada através do protótipo implementado.
Figura 36 – Quantidade de Laudos (DW)
Fonte: O Autor (2014).
Os mesmos resultados são observados quando a consulta é realizada diretamente
no banco de dados operacional, conforme pode ser observado na figura 37.
73
Figura 37 – Consulta SQL
Fonte: O Autor (2014).
Os resultados obtidos, quando exportados para a planilha, apresentam o resultado
demonstrado pela figura 38.
Figura 38 – Quantidade de Laudos (SQL)
Fonte: O Autor (2014).
Como os resultados apresentados pela extração feita no DW são equivalentes aos
resultados coletados com a consulta realizada diretamente na base de dados operacional,
pode-se inferir que os resultados são íntegros.
74
5.5
RESULTADOS E ANÁLISES
Esta seção apresenta os resultados obtidos de acordo com os requisitos levantados
no Capítulo 4. Os indicadores foram obtidos através da análise do banco de dados de uma
instância de PACS Aurora. A massa de dados apresentada sofreu alterações nos valores
descritivos originais. Este processo foi adotado para manter o sigilo dos envolvidos,
impossibilitando que os resultados sejam associados a terceiros. Resultados quantitativos
foram preservados, de modo que os valores obtidos representam dados reais da utilização do
sistema.
5.5.1 Quantidade de Laudos por Período
A figura 39, abaixo, apresenta a quantidade de laudos gerados no sistema por mês
em cada ano.
Figura 39 – Laudos por Período
Fonte: O Autor (2014).
Percebe-se um aumento gradual na produção de laudos a cada ano de operação do
PACS Aurora em relação ao mesmo período do ano anterior.
75
5.5.2 Quantidade de Laudos por Modalidade
A figura em sequência apresenta a quantidade de laudos gerados no sistema em
determinada modalidade.
Figura 40 – Laudos por Modalidade
Fonte: O Autor (2014).
Observa-se que a maior fatia da produção de laudos se concentra em exames de
radiografia computadorizada (CR).
5.5.3 Quantidade de Laudos por Médico
A quantidade de laudos gerados por cada médico cadastrado no sistema é
apresentada em sequência, na figura 41.
76
Figura 41 – Laudos por Médico
Fonte: O Autor (2014).
A Figura 41 evidencia a produção de cada médico desde o início da operação do
PACS Aurora. Este tipo de informações é extremamente útil no ambiente radiológico, tendo
que vista que, em grande parte das instituições, o pagamento desse tipo de profissional é
baseado em sua produção mensal.
5.5.4 Quantidade de Exames por Período
A Figura 42, exposta a seguir, apresenta a quantidade de exames armazenados
pelo PACS Aurora em cada mês dos anos de operação.
Figura 42 – Exames por Período
Fonte: O Autor (2014).
77
Percebe-se um aumento na execução de exames até meados de 2013, quando a
quantidade atinge seu pico. Após este período existe uma estabilização da quantidade de
exames executados, totalizando uma média de 6500 exames por mês entre Dez/2013 e
Abr/2014.
5.5.5 Quantidade de Exames por Modalidade
A Figura 43 exibe a quantidade de exames executados em cada modalidade de
estudo.
Figura 43 – Exames por Modalidade
Fonte: O Autor (2014).
Podemos observar que os exames de menor complexidade, como radiografia
computadorizada (CR) e ultrassonografia (US), ocupam a maior parcela dos exames
executados no período, alcançando uma fatia de 78,19% do total.
78
5.5.6 Quantidade de Exames por Descrição
Na imagem 44 são apresentados os indicadores da quantidade de exames
executados com determinada descrição. Devido ao elevado número de descrições existentes,
foram selecionados os três procedimentos mais executados em cada modalidade.
Figura 44 – Exames por Descrição e Modalidade
Fonte: O Autor (2014).
A porcentagem apresentada para cada tipo de exame foi obtida através da
quantidade de exames executados em relação ao total de exames de cada modalidade.
79
5.6
CONSIDERAÇÕES
A aplicação do protótipo permitiu que dados contidos no sistema de PACS fossem
disponibilizados em forma de indicadores para usuários analíticos. Com isso, observa-se a
quantidade de exames executados em determinado período, modalidade, descrição. Também é
possível, com a concepção deste protótipo, extrair a quantidade de laudos produzidos em
determinado período, modalidade e por profissional.
80
6
CONCLUSÕES E TRABALHOS FUTUROS
Este capítulo apresenta as conclusões obtidas com o desenvolvimento deste
trabalho. Também são apresentadas sugestões para trabalhos futuros que possam contribuir
com o desenvolvimento do tema abordado.
6.1
CONCLUSÕES
Embora este trabalho tenha sido desenvolvido como um protótipo, observe-se a
importância de um sistema de apoio ao processo decisório em sistemas de diagnóstico médico
por imagem, como o PACS. Deste modo, foi possível atender os objetivos gerais e específicos
definidos neste trabalho.
Os conhecimentos em data warehouse e modelagem de dados foram aplicados
para a concepção do modelo dimensional proposto no primeiro objetivo específico: Modelar
um banco de dados dimensional para armazenamento dos dados da aplicação.
O conhecimento em banco de dados relacionais, linguagem SQL e ferramentas de
Extração Transformação e Carga de dados (ETL) foram de extrema importância para atender
com sucesso os objetivos definidos no segundo objetivo específico: Extrair os dados
quantitativos contidos no sistema de PACS. Os mesmos conhecimentos foram
fundamentais para atender o último objetivo: Disponibilizar as informações obtidas em
forma de gráficos com indicadores institucionais em uma ferramenta analítica.
Os resultados obtidos com a arquitetura desenvolvida fortalecem a importância
deste tipo de ferramenta para facilitar e simplificar o processo decisório de uma companhia.
81
6.2
TRABALHOS FUTUROS
A limitação de tempo para o desenvolvimento do trabalho não permitiu que
fossem exploradas todas as ferramentas disponíveis para uma arquitetura de Business
Intelligence. Também não foi possível contemplar todas as análises que podem ser coletadas
com sistemas de PACS. Deste modo, recomenda-se que as análises levantadas sejam cruzadas
com sistemas de gestão existentes em clínicas e hospitais, possibilitando um acompanhamento
de todo o processo envolvido na execução de um exame.
82
REFERÊNCIAS
ANGELONI, Maria T.; REIS, Eduardo S. Business Intelligence como Tecnologia de
Suporte à Definição de estratégias para melhoria da qualidade do ensino. In: Encontro da
ANPAD, 2006, Salvador. XXX Encontro Nacional de Pós-Graduação em Administração,
2006. vol.1. p. 16 paginas
ATRE, Shaku; MOSS, Larissa T. Business Intelligence Roadmap: The Complete Project
Lifecycle for Decision-Support Applications. Boston: Addison Wesley, 1ª ed. 2003.
BARBIERI, Carlos. BI – Business Intelligence: Modelagem e Tecnologia. Rio de Janeiro:
Axcel Books, 2001.
BEZERRA, E. Princípios de análise e projeto de sistemas com UML. Rio de Janeiro:
Campus, 2ª ed. 2007.
BRITISH INSTITUTE OF RADIOLOGY (UK). History of radiology. Disponível em:
<http://www.bir.org.uk/patients-public/history-of-radiology/>. Acesso em: 05 out. 2013.
BROERING, Felipe. Informações para o TCC do Rodrigo. [Mensagem pessoal] Mensagem
recebida por: <Rodrigo Rosa>. Em: 02 set. 2013. A.
BROERING, Felipe. Fluxo do PACS. [Mensagem pessoal] Mensagem recebida por:
<Rodrigo Rosa>. Em: 07 out. 2013. B.
CNES DATASUS. Serviço Especializado: Serviço de Diagnóstico por Imagem.
Disponível em:
<http://cnes.datasus.gov.br/Mod_Ind_Especialidades_Listar.asp?VTipo=121&VListar=1&VE
stado=00&VMun=00&VTerc=00&VServico=&VClassificacao=&VAmbu=&VAmbuSUS=&
VHosp=&VHospSus=>. Acesso em: 01 set. 2013.
DALY, Mark et al. Informatics in Radiology: Automated Web-based Graphical Dashboard
for Radiology Operational Business Intelligence. Disponível em: <http://intlradiographics.rsna.org/content/29/7/1897.full>. Acesso em: 07 out. 2013.
FORTULAN, Roberto M.; GONÇALVES, Eduardo F. V. Uma Proposta de Aplicação de
Business Intelligence no Chão-de-Fábrica. vol. 12, pag. 55-66, 2005
GRAY, P.; WATSON, H. J. The new DSS: data warehouses, OLAP, MDD and KDD.
1999
HARRISON, Thomas H. Intranet Data Warehouse. 1ª ed. São Paulo, Berkeley Brasil, 1998.
HEINRICHS, John. H.; LIM, Jeen-Su. Integrating web-based data mining tolls with
business models for knowledge management. Decision Support Systems, vol. 35, pag. 103112, 2003.
83
IBM. Star schema access. Disponível em:
<http://publib.boulder.ibm.com/infocenter/dzichelp/v2r2/index.jsp?topic=%2Fcom.ibm.db2z9
.doc.perf%2Fsrc%2Ftpc%2Fdb2z_starschemaaccess.htm>. Acesso em: 30 set. 2013. A.
IBM. Robustness Diagram or Ideal Object Diagram. Disponível em:
http://pic.dhe.ibm.com/infocenter/rsysarch/v11/index.jsp?topic=%2Fcom.ibm.sa.oomethod.do
c%2Ftopics%2Fc_Ideal_Object_Diagram.html. B.
INMON, William H. The Data Warehouse and Data Mining. Communications of the
ACM, 1996, vol. 39.
INMON, William H. Como Construir o Data Warehouse. Rio de Janeiro, Campus, 1ª ed.
1997.
INMON, William H. Building the Data Warehouse. Wiley, 3ª ed. 2002.
KIMBALL, Ralph; ROSS, Margy. The Data Warehouse Toolkit: The complete guide to
dimensional modeling. Wiley, 2ª ed. 2002.
LOBO, Ana Paula. BI Quer Lugar Cativo no Investimento Corporativo. Computer world,
362ª ed. 2002.
MACHADO, Felipe Nery Rodrigues. Tecnologia e Projeto de Data Warehouse: uma visão
multidimensional. São Paulo. Érica, 1ª ed. 2004.
MICROSOFT. Fundamentos e Modelagem de Bancos de Dados Multidimensionais.
Disponível em: < http://msdn.microsoft.com/pt-br/library/cc518031.aspx>. Acesso em: 03 out
2013.
MICROSOFT. Server and Cloud Platform. Disponível em: <http://www.microsoft.com/ptbr/server-cloud/products/sql-server/#fbid=olPE1UFUHvm>. Acesso em: 07 mai. 2014.
MORALES, Aran Bey Tcholakian. Sistemas de Apoio a Decisão: Inteligência nos Negócios
- Business Inteligente. Disponível em:
<http://aran.ispeople.org/sad/Aula_3_SAD_Alunos.pdf>. Acesso em: 28 set. 2013. UNISUL:
Sistemas de Informação.
ORACLE CORPORATION. Overview of Extraction, Transformation, and Loading.
Disponível em:
<http://docs.oracle.com/cd/B10501_01/server.920/a96520/ettoverv.htm#12348>. Acesso em:
29 set. 2013.
ORACLE CORPORATION. Data Warehousing Schemas. Disponível em: <
http://docs.oracle.com/cd/B10501_01/server.920/a96520/logical.htm>. Acesso em: 29 set.
2013.
PRIMAK, Fábio V. Decisões com B.I. (Business Intelligence). Rio de Janeiro: Ciência
Moderna, 1ª ed. 2008.
RSR RESEARCH. The Intelligent Retailer’s Word of Insight: Benchmark Report 2011.
Disponível em: < http://www.rsrresearch.com/2011/11/16/the-intelligent-retailers-world-ofinsight >. Acesso em: 01 set. 2013.
84
RUBIN, Daniel L.; DESSER, Terry S. A Data Warehouse for Integrating Radiologic and
Pathologic Data. Disponível em: <http://www.stanford.edu/~rubin/pubs/JACRRadBank.pdf>. Acesso em: 07 out. 2013.
ROSENBERG, Doug; STEPHENS, Matt; COLLINS-COPE, Mark. Agile development with
ICONIX process. New York: Springer-Verlag, 1ªed. 2006.
SAMPAIO, Marcus Costa. Material sobre UML: Disciplina Sistemas de Informação II.
Disponível em: <http://www.dsc.ufcg.edu.br/~jacques/cursos/map/html/uml/>. Acesso em: 23
nov. 2013.
SILVA, Edna Lúcia da; MENEZES, Estera Muszkat. Metodologia da pesquisa e elaboração
de dissertação. 4ª Edição. Florianópolis: UFSC, 2005.
SOCIEDADE BRASILEIRA DE INFORMÁTICA E SAÚDE (Brasil). O que é Informática
em Saúde? Disponível em: <http://www.sbis.org.br/>. Acesso em: 05 out. 2013.
SOCIEDADE PAULISTA DE RADIOLOGIA. Histórico da Radiologia: Evolução da
Radiologia. Disponível em: <http://www.spr.org.br/a-spr/historico-da-radiologia/>. Acesso
em: 05 out. 2013.
THOMSEN, Erik. OLAP: Construindo sistemas de informações multidimensionais. Rio
de Janeiro: Campus, 1ª ed. 2002.
TURBAN, Efraim et al. Administração de Tecnologia da Informação: Teoria e Prática.
Rio de Janeiro: Campus, 3ª ed. 2005.
TURBAN, Efraim et al. Business Intelligence: A Managerial Approach. Hall; 2ª ed. 2010.
WANG. Data Warehouse and OLAP II. Disponível em:
<http://www.csun.edu/~twang/595DM/Slides/Week6.pdf>. Acesso em: 04 out. 2013. Data
Ciências de Computação, Data Mining. Universidade do Estado da Califórnia.
YU, Liu; WANG, Jihong. PACS and Digital Medicine. CRC Press; 1ª ed. 2011.
ZWICKER, Ronaldo; PEREZ, Gilberto. Fatores Determinantes da Adoção de Sistemas de
Informação na Área de Saúde: Um Estudo Sobre o Prontuário Médico Eletrônico. Revista de
Administração Mackenzie, Vol. 11, 2010. Disponível em:
<http://www.scielo.br/pdf/ram/v11n1/08.pdf>. Acesso em: 05 out. 2013.