UNIVERSIDADE DO SUL DE SANTA CATARINA RODRIGO ROSA BUSINESS INTELLIGENCE EM SISTEMAS DE DIAGNÓSTICO MÉDICO POR IMAGEM

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 Pentaho Data Integration - Kettle...63 5.1.3 Microsoft Excel 2013...63 5.2 SOLUÇÃO PROPOSTA...64 5.3 HISTÓRICO DE DESENVOLVIMENTO...66 5.4 VALIDAÇÕES...66 5.4.1 Carga do Modelo DW...67 5.4.2 Validação da Carga do DW...72 5.5 RESULTADOS E ANÁLISES...74 5.5.1 Quantidade de Laudos por Período...74 5.5.2 Quantidade de Laudos por Modalidade...75 5.5.3 Quantidade de Laudos por Médico...75 5.5.4 Quantidade de Exames por Período...76 5.5.5 Quantidade de Exames por Modalidade...77 5.5.6 Quantidade de Exames por Descrição...78 5.6 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 ETL. A figura a seguir descreve os processos envolvidos na operação de ferramentas 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 sequência. As etapas deste trabalho estão segmentadas conforme fluxograma apresentado em 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 Requisitos UC01_01 Executar ETL Este caso de uso tem por objetivo permitir RF01 ao usuário a invocação de fluxos ETL. UC01_02 Extrair Dados Este caso de uso tem por objetivo permitir RF01 a extração de dados operacionais pela ferramenta ETL. UC01_03 Transformar Este caso de uso tem por objetivo permitir RF01 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 RF01 a carga, pela ferramenta ETL, de dados operacionais no Data Warehouse. UC01_05 Exportar Dados Este caso de uso tem por objetivo permitir RF01, RF02 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. 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). de uso UC01_05. A figura 25 determina a sequência de atividades estabelecida para atender o caso

59 Figura 25 Diagrama de Sequência - UC01_05 Fonte: O Autor (2014). 26. O caso de uso UC02_01 tem sua sequência de atividades apresentada pela figura Figura 26 Diagrama de Sequência - UC02_01 Fonte: O Autor (2014).

60 4.3.4 MODELO DIMENSIONAL figura 27, a seguir. A modelagem dimensional, desenvolvida para este protótipo, é apresentada na 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 Descrição 1) Exame Radiológico Procedimento no qual o paciente é submetido para extração de imagens utilizadas no auxílio ao diagnóstico médico. 2) PACS Aurora Sistema de comunicação e arquivamento de imagens radiológicas geradas pelos equipamentos. 3) Servidor Operacional Servidor com banco de dados SQL Server 2012 com dados operacionais do PACS Aurora. 4) Ferramenta ETL 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 Servidor de Data Warehouse, com modelo dimensional, em SQL Server 2012. 6) Análise de Dados 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 etapas. O processo de desenvolvimento do protótipo decorreu conforme as seguintes 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 em cada ano. A figura 39, abaixo, apresenta a quantidade de laudos gerados no sistema por mês 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).