MÁRIO AUGUSTO GOMES
DESENVOLVIMENTO DE UM SISTEMA DE LAUDOS
HISTOPATOLÓGICOS BASEADO NA PLATAFORMA
MICROSOFT .NET 2.0
DESENVOLVIMENTO DE UM SISTEMA DE LAUDOS HISTOPATOLÓGICOS BASEADO NA PLATAFORMA
MICROSOFT .NET 2.0
Dissertação apresentada à Faculdade de Odontologia de São José dos Campos, Universidade Estadual Paulista “Júlio de Mesquita Filho”, como parte dos requisitos para obtenção do título de MESTRE, pelo Programa de Pós-Graduação em BIOPATOLOGIA BUCAL, Área Patologia.
Orientadora: Profa. Tit. Yasmin Rodarte Carvalho Co-orientador: Prof. Adj. Luiz Eduardo Blumer Rosa
G585d Gomes, Mário Augusto.
Desenvolvimento de um sistema de laudos histopatológicos baseado na plataforma microsoft .net 2.0 / Mário Augusto Gomes. __ São José dos Campos : [s.n.], 2011
74f. : il.
Dissertação (Mestrado em Biopatologia Bucal) – Faculdade de Odontologia de São Jose dos Campos, Universidade Estadual Paulista, 2011.
Orientador: Profa. Dra. Yasmin Rodarte Carvalho Co-orientador: Luiz Eduardo Blumer Rosa
1. Informática em Saúde. 2. Informática em Patologia. 3. Diagnóstico. I. Carvalho, Yasmin Rodarte. II. Universidade Estadual Paulista. Faculdade de Odontologia de São José dos Campos. III. Título
616.0783
Ficha catalográfica elaborada pelo Serviço Técnico de Biblioteca e Documentação da Faculdade de Odontologia de São José dos Campos – UNESP
AUTORIZAÇÃO
Autorizo a reprodução e divulgação total ou parcial deste trabalho, por qualquer meio convencional ou eletrônico, desde que citada a fonte.
São José dos Campos, 11 de abril de 2011. Assinatura :
BANCA EXAMINADORA
Profa. Titular Yasmin Rodarte Carvalho (Orientador) Faculdade de Odontologia de São José dos Campos UNESP - Univ Estadual Paulista
Prof. Dr. Decio dos Santos Pinto Júnior Faculdade de Odontologia de São Paulo Universidade de São Paulo - USP
Prof. Dr. Ivan Torres Pisa Escola Paulista de Medicina Universidade Federal de São Paulo - UNIFESP
Dedico este trabalho aos meus pais, por me darem a vida e à minha amada esposa, Ana, por fazê-la ter sentido.
À minha querida filha Isabela, presente em todos os meus momentos.
À Universidade Estadual Paulista “Júlio de Mesquita Filho”, nas pessoas
do diretor e vice-diretor da Faculdade de Odontologia de São José dos Campos, Prof. Adj. José Roberto Rodrigues e Prof. Dr. Carlos Augusto Pavanelli.
Ao Programa de Pós-graduação em Biopatologia Bucal, na pessoa da coordenadora Profa. Adj. Cristiane Yumi Koga Ito, pelo trabalho e atenção quando sempre precisei.
Ao Prof. Tit. Antonio Olavo Cardoso Jorge, pela coragem em acreditar em nosso trabalho.
À Universidade Federal de São Paulo, todos os professores e tutores do Curso de Especialização em Informática em Saúde, em especial, ao Prof. Dr. Ivan Torres Pisa e Prof. Dr. Carlos José Reis de Campos por todos os ensinamentos que recebi.
Às secretárias da Pós-graduação, Rosemary, Erena e Bruno pela prontidão em nos atender sempre.
Ao analista de sistemas, Cleber Wander Fernandes Pinheiro, pelo suporte nos momentos mais complicados.
"Nós, homens do conhecimento, não nos conhecemos;
de nós mesmo somos desconhecidos."
RESUMO ... 09
ABSTRACT... 10
LISTA DE FIGURAS ... 11
LISTA DE QUADROS ... 14
LISTA DE ABREVIATURAS E SIGLAS ... 15
1 INTRODUÇÃO ... 16
2 REVISÃO DA LITERATURA ... 18
2.1 Sociedade da Informação e a Patologia ... 18
2.2 Sistemas de Informação em Saúde ... 25
2.3 Tecnologia da Informação ... 28
2.4 Desenvolvendo Sistemas de Informação em Saúde ... 30
2.5 Engenharia de Software ... 31
2.6 Linguagens de Programação ... 34
2.7 Ferramentas de Desenvolvimento ... 37
2.8 Sistema Gerenciador de Banco de Dados e Banco de Dados .. 38
2.9 Arquitetura de desenvolvimento em três camadas ... 40
2.10 A Tecnologia Microsoft .NET Framework® ... 40
2.11 Licenças de Software ... 43
3 PROPOSIÇÃO ... 45
4 MATERIAIS E MÉTODOS ... 46
4.1 Materiais ... 46
4.2 Métodos ... 47
5 RESULTADOS ... 53
5.1 Definição de metas e prioridades ... 53
5.6 Tecnologia utilizada e programação ... 99
5.7 Definição de problemas, resistências ... 108
5.7 Infraestrutura e financiamento ... 109
6 DISCUSSÃO ... 111
6.1 Definição de metas e prioridades ... 113
6.2 Estruturação e padronização de termos ... 116
6.3 Indicadores importantes e dados relevantes para utilização no setor ... 118
6.4 Fluxos de informação, coleta e recursos humanos ... 119
6.5 Modelagem de dados ... 121
6.6 Tecnologia utilizada e programação ... 121
6.7 Definição de problemas, resistências, infraestrutura e financiamento ... 127
7 CONCLUSÃO ... 130
8 REFERÊNCIA ... 131
APÊNDICE ... 135
RESUMO
O objetivo deste trabalho foi desenvolver um sistema informatizado de laudos histopatológicos baseado na plataforma .NET 2.0. Este software construído para o Sistema Operacional Microsoft Windows® utilizou a plataforma Microsoft Framework® 2.0 com a camada de resistência de dados Microsoft SQL Server® 2005. Outros recursos como Microsoft Report View® foram utilizados como ferramenta para geração de relatórios estatísticos, sócio-epidemiológicos e de gerenciamento do serviço de exames anatomopatológicos da Faculdade de Odontologia de São José dos Campos - UNESP. Para a realização deste software foram levantadas, na literatura, pesquisas nas áreas de Engenharia de Software, Patologia Bucal, Tecnologia da Informação e Comunicação em Saúde, Gestão em Serviços de Saúde, Sistema de Informação em Saúde, Diagnóstico Oral e Técnicas de Programação. O software desenvolvido teve a finalidade de suprir a demanda acadêmica na produção científica e aprimorar o serviço prestado à comunidade, além de constituir-se numa ferramenta pedagógica para os alunos da Pós-graduação em Biopatologia Bucal, Área Patologia.
ABSTRACT
The objective of this study was to develop a computerized system based on Microsoft NET 2.0, using histopathological examinations.This software built for Microsoft Windows operating system used the Microsoft ® Framework ® 2.0 with a layer of resistance to Microsoft SQL Server ® 2005. Other features like Microsoft Report View ® was used as a tool for generating statistical reports, epidemiological and social-service management of pathological examinations of the Faculty of Dentistry of São José dos Campos - UNESP. For the realization of this software have been raised in the literature research in the areas of Software Engineering, Oral Pathology, Information Technology and Communication in Health, Health Services Management, Information Technology in Health, Oral Diagnosis and Programming Techniques. The developed software was designed to meet the demand in the academic scientific production and improve service to the community, and building up a teaching tool for students of the Postgraduate Dental Biopathology Area Pathology.
Figura 1 - Ciclo Clássico de Software ... 48
Figura 2 - Imagem do Microsoft Visual Studio .NET... 51
Figura 3 - Fluxo de trabalho do Examinador ... 57
Figura 4 - Fluxo de tarefas do Técnico de Laboratório ... 58
Figura 5 - Fluxo de trabalho do Professor da Patologia ... 59
Figura 6 - Exemplo de documento UML de casos de uso ... 63
Figura 7 - Sequência de digitação de laudos antigos por digitador .... 78
Figura 8 - Sequência básica de processos para Laudo Histopatológico e Avaliação de Aluno ... 79
Figura 9 - Fluxo de preenchimento da requisição de exame ... 80
Figura 10 - Formulário de Requisição de Exame (Entrada)... 81
Figura 11 - Formulário de Requisição de Exame (profissional solicitante)... 82
Figura 12 – Formulário de Requisição (Paciente) ... 82
Figura 13 – Formulário de Requisição (história médica) ... 83
Figura 14 – Formulário de Requisição (história de tabagismo) ... 83
Figura 15 – Formulário de Requisição (história de etilismo) ... 84
Figura 16 – Formulário de Requisição (história de uso de drogas ilícitas) ... 84
Figura 17 – Formulário de Requisição (história de hábitos) ... 85
Figura 18 – Formulário de Requisição (história familiar) ... 85
Figura 19 - Formulário de Requisição (medicamentos em uso pelo paciente) ... 86
Figura 20 – Formulário de Requisição (detalhes da biópsia) ... 86
Figura 21 – Formulário de Requisição (características da lesão) ... 87
Figura 25 – Formulário de Requisição (Emissão de Recibo) ... 89 Figura 26 – Formulário de Rotina Examinador (Verificação de
requisição “aguardando exame macroscópico”) ... 90 Figura 27 – Formulário de Detalhes de Rotina Examinador (exame
macroscópico, dados da requisição) ... 90 Figura 28 – Formulário de Detalhes de Rotina Examinador (exame
macroscópico) ... 91 Figura 29 – Formulário de Rotina Técnico de Laboratório
(Verificação de requisição “aguardando lâminas”) ... 92 Figura 30 – Formulário de Detalhes de Rotina Examinador – Exame
Microscópico (Relatório Aula de Diagnóstico) ... 93 Figura 31 – Formulário de Detalhes de Rotina Examinador – Exame
Microscópico ... 93 Figura 32 – Formulário de Rotina Professor
(Verificação de avaliação) ... 94 Figura 33 – Formulário de Detalhes de Professor – Avaliação
Macroscópica ... 94 Figura 34 – Formulário de Detalhes de Professor – Avaliação
Microscópica ... 95 Figura 35 – Formulário de Detalhes de Professor –
Devolutiva ao Aluno ... 95 Figura 36 – Formulário de Detalhes de Professor – Diagnóstico ... 96 Figura 37 - Formulário de geração, impressão e exportação de laudo .. 97 Figura 38 - Exemplo de Relatório de Produtividade ... 97 Figura 39 – Exemplo de Relatório Estatístico Epidemiológico
Figura 44 - Formulário de envio de emails para Examinador ... 103 Figura 45 - Formulário de Cadastro de Profissionais Solicitantes ... 103 Figura 46 - Formulário de avaliação, devolutiva e diagnóstico (exame
macroscópico) ... 104 Figura 47 - Formulário de avaliação, devolutiva e diagnóstico (exame
microscópico) ... 104 Figura 48 - Formulário de avaliação, devolutiva e diagnóstico
(devolutiva) ... 105 Figura 49 - Formulário Relatório de Avaliação Coletiva de
Examinadores ... 105 Figura 50 - Formulário de avaliação, devolutiva e diagnóstico
(vinculação de imagens) ... 106 Figura 51 - Formulário de acesso ao website de Patologia ... 106 Figura 52 - Formulário de cadastro de profissionais solicitantes
(Google Maps®) ... 107 Figura 53 - Formulário de emissão de recibo ... 107 Figura 54 - Formulário de impressão de laudo ... 108 Figura 55 - Esquema de Ambiente Computadorizado do Sistema
de Laudos Histopatológicos ... 110 Figura 56 – Apresentação do gráfico de Sistemas Operacionais
mais utilizados por usuários ... 125 Figura 57 – Apresentação do gráfico de versões de Sistemas
Quadro 1 – Cronograma para Ciclo de Vida de Software... 49
Quadro 2 - Controle do ciclo de desenvolvimento... 50
Quadro 3 – Gerência de Riscos... 51
Quadro 4 – Resultado do Cronograma de Desenvolvimento... 54
CID = Código Internacional das Doenças CRL = Common Language Runtime
EULA = End User License Agreement
GPL = General Public License
HIPRIS = HistopathologicalReporting Information System IDE = Integred Development Environment
IIS = Internet Information Services (Serviços de Informação de Internet)
PDF = Portable Document File
PEP = Prontuário Eletrônico do Paciente
RAD = Rapid Application Development
SAD = Sistema de Apoio à Decisão
SGBDR = Sistema Gerenciador de Banco de Dados Relacionais SOAP = Subjetivo, Objetivo, Avaliação e Plano de Tratamento SQL = Structured Query Language
Durante a história da humanidade, é possível identificar mudanças de paradigmas que alteraram definitivamente a forma como a sociedade se organizava. Estas mudanças foram tão intensas que foram chamadas de revoluções. De fato, é notável como a Revolução Agrícola e a Revolução Industrial afetaram a história da humanidade, gerando novas tecnologias, assim como novos problemas e desafios que surgiram como reflexos destas próprias revoluções. Um exemplo disto são as discussões atuais sobre a utilização exagerada de recursos naturais resultantes destas revoluções e que, provavelmente, desencadearão uma nova revolução, a Revolução Ambiental.
Nos dias de hoje, vivencia-se a Revolução do uso da Informação a partir das tecnologias disponibilizadas para sociedade moderna. Estas tecnologias e estes novos equipamentos também influenciam o modo como esta sociedade se comunica, percebe e interage com o mundo. Pode-se afirmar que todos os aspectos da vida cotidiana envolvem a organização de informação como componente atuante na melhoria dos processos. Desta forma, pela maneira como o homem se organiza, social e economicamente utilizando-se destas novas tecnologias, associadas às suas necessidades pessoais de comunicação e de compreensão do mundo, novos paradigmas de interação são criados e, a partir destes, a relação do indivíduo com o mundo é novamente transformada.
ferramentas para gestores de serviços de saúde. Aliado a este aumento na oferta destas informações, também houve um incremento da exigência quanto à quantidade e qualidade das informações emitidas pelos serviços de diagnóstico. Consequentemente, estes fatores aumentaram as demandas dos clínicos por mais informações nos laudos histopatológicos (Tilakaratna; Silva, 2000).
No laboratório de Patologia da Faculdade de Odontologia de São José dos Campos/UNESP há um grande número de exames histopatológicos (12000 até dezembro de 2010), os quais contêm um grande volume de informação não disponível de forma rápida, dinâmica, padronizada, compilada e contextualizada. Isto leva à perda de informações importantes quanto à etiopatogenia e epidemiologia das doenças em âmbito regional, dificultando o retorno que se espera a partir deste conhecimento para a sociedade.
2.1 Sociedade da Informação e a Patologia
Uma Sociedade da Informação está em construção devido à consequência da explosão informacional gerada por transmissões de dados de baixo custo, velocidades de transmissão crescentes, popularização e queda de custos de componentes computadorizados. Ela está se organizando com o uso intensivo de processos de informação, comunicação e compartilhamento de dados em um nível global antes nunca imaginado. Porém, apesar desta construção ser evidente, ela não ocorre de forma homogênea em todos os segmentos da sociedade contemporânea. Segundo Sigulem (2009), a integração se faz de forma gradual em diferentes setores da sociedade e da economia.
Muito embora esta integração não seja homogênea, é possível perceber um padrão evolutivo na integração destas tecnologias em seus processos, nos diferentes segmentos. De acordo com Falsarella e Chaves (1995), a evolução da informatização numa organização ocorre em seis estágios de Nolan:
b) Estágio de Contágio: Há a proliferação de automação em atividades manuais, porém, sem a integração das informações entre os setores;
c) Estágio de Controle: O uso de Sistemas de Informação é explosivo. O usuário, antes resistente, se torna a força propulsora e exige da organização mais recursos para a informática;
d) Estágio de Integração: Em resposta à exigência de melhor gestão, os Sistemas de Informação passam a ser orientados para atender necessidades gerenciais. A qualidade da informação e a integração entre elas passam a ser prioridade;
e) Estágio de Administração dos Dados: Os Sistemas de Informação passam a ser organizados de forma global e demandam cuidados para que Sistemas Setoriais ou Especializados não causem redundâncias;
f) Estágio de Maturidade: A informação passa a ser considerada como patrimônio da organização. O usuário se torna participativo, responsável e o crescimento da informática na organização é ordenado.
A fase denominada “novidade interessante” se refere ao
período em que se insere no setor um ou mais equipamentos informatizados, sendo usados superficialmente e não atingindo uma massa crítica, ou seja, não provocando uma transformação nos processos ou uma reengenharia no setor. Num segundo momento, na fase
identificada como “cavalo de Tróia”, o setor já utiliza os equipamentos informatizados com mais intensidade, como um editor de texto, planilhas etc., porém, a tecnologia ainda não está integrada aos processos. Esta
fase evolui com o tempo até atingir uma “massa crítica”, isto é, até o
momento em que o setor percebe a necessidade de integração total de seus processos com a tecnologia da informação. Contudo, o esforço e os custos para esta integração e reorganização dos processos produtivos e de fluxos são muito altos, pois, nesta fase, a tecnologia é utilizada de forma não integrada em todas as camadas do setor, não sendo a informação compartilhada nem estruturada. No terceiro momento, a tecnologia provoca uma total reengenharia do setor onde se inseriu. Tem-se como exemplo, na história contemporânea, o Setor Industrial o qual foi totalmente transformado no final da década de 80 pela utilização da tecnologia da informação. Ao se observar a indústria atualmente automobilística, é difícil imaginá-la sem a automação industrial ou sem os robôs e softwares inseridos e integrados tanto na fabricação de automóveis como na gestão de seus recursos materiais e humanos (Sigulem, 2009).
Nos anos 90, o Setor Financeiro também passou pelo processo de informatização e por sua completa reengenharia. No cotidiano, convive-se com os caixas eletrônicos, transações bancárias pela internet ou compras e vendas de ações acompanhadas em “tempo
real” em qualquer lugar do mundo onde se tenha uma conexão de internet (Sigulem, 2009).
interessante”, ou, nos ambientes mais organizados, na fase de “cavalo de
Tróia”. Até o momento, o setor saúde ainda não foi capaz de se integrar
completamente à tecnologia de informação, muito embora este setor seja um enorme coletor, gerador, processador e armazenador de informação. Ainda é possível, por exemplo, deparar-se com serviços de saúde com registros de informações do paciente (prontuários) em papel, sem nenhuma infraestrutura informatizada. A falta de uma infraestrutura informatizada não só das unidades de saúde, mas em nível central de muitas Secretarias Municipais, causam um baixo desempenho dos gestores de saúde, pois estes não possuem mecanismos que facilitam o conhecimento sociodemográfico da população de sua área de abrangência, bem como o perfil de morbidade ou avaliações de desempenho de serviços e equipes de saúde (Tomasi et al., 2003).
Tomasi et al.(2003) destacaram a importância do desenvolvimento de softwares no setor saúde ao afirmar:
É preciso que seja incentivado o desenvolvimento de ferramentas próprias, especialmente aquelas de fácil manejo pelas equipes de saúde, o que representa um avanço no preenchimento da lacuna existente. Estas ferramentas imprimiriam maior especificidade no conhecimento das realidades locais, favorecendo a definição de prioridades na alocação de recursos humanos, materiais e financeiros.
Apesar de se encontrar esta dificuldade em alguns setores da saúde, verifica-se que, na história, o prontuário médico tem evoluído bastante desde 1969, quando Laurence Weed (1968) descreveu o que chamou de Registro Médico Orientado ao Problema (
Problem-Oriented Medical Record), o qual propôs a organização do registro
médico SOAP:
c) A (Avaliação)-Resultados de exames e conclusões diagnósticas;
d) P (Planejamento)-Conduta e tratamento.
Weed (1968) ainda recomendou que os registros do prontuário fossem indexados de acordo com os problemas médicos. Cada elemento de registro é categorizado por cada problema de saúde a que se refere, além da data e da hora. Neste caso, o médico não perde a conduta lógica do problema e a evolução do quadro (Kmeteuk Filho, 2003).
A partir dessa padronização da estrutura do prontuário e de seu aprimoramento com o passar dos anos, o Institute of Medicine dos Estados Unidos encomendou, em 1991, um estudo com especialistas para definir o PEP (Prontuário Eletrônico do Paciente). Além disso, este comitê tinha a tarefa de propor melhorias em relação à expansão de informações levando em consideração o aparecimento de novas tecnologias. O relatório foi publicado como livro, “The Computer-based
Patient Record – An Essencial Technology for Health Care”, e foi um
marco sobre prontuário eletrônico do paciente na época (Costa, 2001). Desde então, muitos foram os aprimoramentos sobre o assunto. O Prontuário Eletrônico do Paciente (PEP) tem, atualmente, uma vasta literatura e, numa breve consulta ao web site Google Acadêmico, usando como pesquisa o termo “prontuário eletrônico”, encontra-se mais de cinco mil ocorrências.
Embora se encontre muita informação atualmente sobre prontuário de pacientes ou prontuários eletrônicos de pacientes, não se encontra muita informação específica sobre o item “Avaliação” (A) do modelo SOAP (Prontuário Orientado a Problema) isoladamente, com exceção dos sistemas de informação em saúde que dão suporte ao item
físicos e anamneses. Na patologia cirúrgica, os laudos histopatológicos têm sido tradicionalmente considerados como o padrão ouro na medicina para diagnóstico e base para tratamento dos pacientes (Mammen, 2009).
Como se sabe, Anatomia Patológica é a ciência subordinada à Patologia, que estuda as alterações morfológicas das doenças (Montenegro; Franco, 2008). Estas lesões podem ser submetidas a biópsias e estudadas pelo ramo da Patologia chamada de Patologia Cirúrgica. A biópsia é compreendida como o exame anatomopatológico realizado em peças cirurgicamente retiradas de paciente vivo, baseadas no exame macroscópico e microscópico do material.
Segundo Montenegro e Franco (2008), na metodologia da biópsia, os procedimentos básicos são:
a) Preenchimento adequado da requisição da biópsia;
b) Amostragem do material; c) Fixação;
d) Identificação;
e) Exame macroscópico; f) Exame microscópico; g) Diagnóstico das biópsias.
Após o estudo macro e microscópico, o patologista emite um laudo anatomopatológico, que além dos dados clínicos, descrições macroscópicas e microscópicas, contém um diagnóstico final (Montenegro; Franco, 2008).
central de informações muito relevantes para o gerenciamento multidisciplinar do tratamento do paciente (Mammen, 2009).
Falhas simples, como erros de endereços ou erros nas transcrições das entidades patológicas chaves nos laudos histopatológicos de câncer, atrasam os cuidados do paciente e aumentam os custos no tratamento. Além disso, as condutas de tratamento são afetadas pela qualidade das informações como: registros de tumores, genomas, registros de bioinformática sobre cânceres utilizados como informação por clínicos e pelas indústrias farmacêuticas (Mammen, 2009).
Por todos estes fatores, Mammen (2009) considera ser agora o momento em que os patologistas devam considerar uma padronização e estruturação de seus laudos, para que, desta forma, providenciem um melhor atendimento aos seus pacientes. Na Índia, a informatização está mudando a rotina dos laboratórios de medicina, influenciando largamente a patologia anatomopatológica e providenciando processamento de textos e armazenamento de dados. Apesar disto, poucos centros avançados possuem um sistema de gerenciamento de laboratório, embora Bansal et al. já tivessem desenvolvido, desde 1991,
um software específico para relatórios histopatológicos. Este software,
batizado de HIPRIS (Histopathological Reporting Information System), foi desenvolvido para auxiliar no acompanhamento de casos, encontrar número de casos em um determinado período, alertar o aumento no número de lesões em um determinado paciente ou qualquer outro parâmetro relevante.
Na Índia, a maior deficiência era o mau acompanhamento dos pacientes e um inadequado armazenamento destes registros (Bansal et al., 1991).
Contribui ainda a este cenário o aumento do conteúdo de informação nos laudos histopatológicos, acrescendo o trabalho dos histopatologistas. Tradicionalmente, a carga de trabalho dos histopatologistas é aferida pelo número de espécimes que são manipuladas anualmente. Porém, com o aumento da demanda pelos clínicos por maior informação nos laudos histopatológicos, houve também uma elevação na quantidade de informações a serem contidas nestes laudos, ou seja, uma melhora qualitativa no laudo para o clínico,
contribuindo para uma sobrecarga de trabalho “velada” para o histopatologista (Tilakaratina; Silva, 2000).
2.2 Sistemas de Informação em Saúde
Define-se Sistema de Informação como sistemas que permitem a coleta, o armazenamento, o processamento, a recuperação e a disseminação de informações (Falsarella; Chaves, 1995).
O Sistema de Informação em Saúde é constituído pela informatização dos processos que compõem a gerência em saúde. Como se sabe, gerenciar um serviço de saúde é cuidar dos aspectos organizacionais e funcionais como qualquer empreendimento ou empresa. Este gerenciamento requer lidar com aspectos administrativos como finanças, estoques de materiais, recursos humanos, equipamentos e fluxos. Porém, na área da saúde há, além disso, outros aspectos gerados pela própria peculiaridade da área, como: atendimento prestado; ato clínico; levantamento das morbidades; estatísticas acadêmicas etc. (Carvalho; Eduardo, 1998).
Um conjunto de componentes inter-relacionados que coletam, processam, armazenam e distribuem a informação para apoiar o processo de tomada de decisão e auxiliar no controle das organizações de saúde. Assim, os sistemas de informação em saúde congregam um conjunto de dados, informações e conhecimento utilizados na área de saúde para sustentar o planejamento, o aperfeiçoamento e o processo decisório dos múltiplos profissionais da área da saúde envolvidos no atendimento aos pacientes e usuários do sistema de saúde.
Considerando estes fatores, o desenho para implantação de um Sistema de Informação em Saúde exige uma fundamentação clínica e epidemiológica, planejamento, programação e avaliação em saúde, assim como conhecimentos em Sistemas de Informação e Tecnologia de Informação (Carvalho; Eduardo, 1998).
A natureza dos Sistemas de Informação em Saúde, segundo Carvalho e Eduardo (1998), pode ser classificada em:
a) Sistemas de Informações Estatístico-epidemiológicas;
b) Sistemas de Informações Clínicas;
c) Sistemas de Informações Administrativas.
aquelas que apoiam a gestão do serviço prestado, não sendo específicas ao setor saúde (Carvalho; Eduardo, 1998).
O conjunto dessas naturezas compõe, segundo Carvalho e Eduardo (1998), o Sistema de Apoio de Decisão em Saúde. Este Sistema é uma ferramenta que os administradores deverão adotar como suporte para uma nova conduta e modelo de administração. É importante ressaltar que os SADs (Sistemas de Apoio à Decisão) são atualmente classificados como aqueles que possuem funções específicas, não vinculadas aos sistemas existentes, e que buscam tais informações numa base de dados para, desta forma, retirar subsídios para o processo de tomada de decisão (Falsarella; Chaves, 1995).
A análise da informação obtida por estas ferramentas é suporte para uma tomada de decisão racional e eficiente. Como descrito por Tomasi et al. (2003), a dificuldade dos gestores de muitas Secretarias Municipais em gerenciar a saúde de sua região é provavelmente creditada à ausência destas ferramentas de apoio, ou a recursos humanos que não as utilizam de forma correta.
A responsabilidade da gerência no planejamento, programação, coordenação e supervisão dos programas em saúde deve ser pautada nos objetivos da instituição. Estes objetivos devem atingir metas de eficácia e eficiência técnica, mas, sobretudo, a melhoria da qualidade do atendimento do usuário de saúde (Carvalho; Eduardo, 1998).
para definir o diagnóstico anatomopatológico, seria emitido um alerta sobre a necessidade de “follow up” do paciente por cinco anos. Por outro lado, em caso de neoplasias malignas de glândulas salivares este “follow
up” seria sugerido pelo período de dez a quinze anos. Outro exemplo interessante seria sobre o alerta de interações medicamentosas em sistemas de prontuário eletrônico de paciente. Neste caso, o alerta ao profissional evitaria os efeitos indesejáveis destas interações em prescrições médicas.
2.3 Tecnologia da Informação
Informação pode ser definida como o significado atribuído pelo homem a um determinado dado. Uma vez interpretado esse significado, esta informação provoca uma decisão que consequentemente gerará uma ação (Carvalho; Eduardo, 1998).
A tecnologia da Informação, por sua vez, é a terminologia que designa técnicas relativas ao processamento das informações, através de meios informatizados que se utilizam de hardwares e
softwares (Carvalho; Eduardo, 1998).
Carvalho e Eduardo (1998) definem hardware como um conjunto de dispositivos de entrada, processamento e saída de dados. Estes dispositivos eletrônicos utilizam sistemas numéricos binários, os quais utilizam somente dois algarismos: “0” e “1”. Muito embora pareça
pouco, este tipo de abordagem possui muitas vantagens, pois qualquer valor diferente de “0” e “1” será completamente desprezado pelo circuito eletrônico, conferindo, assim, confiabilidade e funcionalidade (Torres, 1999).
que, em geral, são escritos para execução de alguma tarefa específica, a qual este hardware não poderia executar sozinho (Mackenzie; Sharkey, 2003).
Atualmente, a maioria dos computadores se utiliza de um sistema operacional. Este sistema operacional pode ser definido comoum programa ou um conjunto de programas cuja função é servir de interface entre um computador e o usuário (Angeloni, 2002). Além disso, ele gerencia todas as operações básicas que envolvem o uso de unidades de disco, memória, monitor, impressora, teclado, mouse além das placas periféricas de recurso (como as de vídeo, áudio, modems etc), bem como outros programas e serviços. Assim, a programação que era feita no passado, sem existência dos sistemas operacionais, deveria levar em conta cada componente de hardware instalado naquela arquitetura daquele computador em particular. Portanto, o processo de programação era realmente não produtivo, pois pouquíssimo tempo poderia ser dispensado na finalidade real do aplicativo, uma vez que grande parte deste tempo era destinada à programação no gerenciamento dos recursos (Mackenzie; Sharkey, 2003).
Para evitar todo este esforço e permitir uma programação dedicada à finalidade de seu projeto, linguagens de níveis superiores foram criadas acima do sistema operacional (Microsoft Windows®, distribuições Linux etc). Estas linguagens permitem o uso de instruções mais avançadas e complexas, que são, então, convertidas em diversas instruções em linguagem de máquina. O processo de conversão de linguagem de alto nível em linguagem de máquina é conhecido como compilação. Os programas que fazem esta conversão são chamados compiladores (Mackenzie; Sharkey, 2003).
2.4 Desenvolvendo Sistemas de Informação em Saúde
Carvalho e Eduardo em seu livro, Sistemas de Informação em Saúde para Municípios (1998), descreve com muitos detalhes os conceitos para o desenvolvimento de softwares para área da saúde. Nas últimas décadas, houve uma mudança significativa na tecnologia da Informática e nas ferramentas de desenvolvimento as quais, na atualidade, são consideradas muito mais produtivas. Todavia, o mecanismo de entendimento sobre “como fazer” permanece o mesmo. A própria peculiaridade do Setor Saúde impõe uma forma de análise e um conjunto de pré-requisitos de desenvolvimento bem específicos:
a) Definir metas e prioridades para todos os envolvidos;
b) Relacionar os indicadores importantes e dados relevantes para utilização no setor;
c) Estabelecer fluxos de informação, coleta e recursos humanos;
d) Modelagem de dados;
e) Estruturação e padronização de termos; f) Programação de formulários;
g) Escolha de tecnologia utilizada; h) Definir problemas e resistências;
2.5 Engenharia de Software
A Engenharia de software é conhecida como o paradigma de utilização de princípios sólidos de engenharia para obtenção de um
software economicamente viável. Além disso, ele deve ser confiável e
deve funcionar eficientemente em máquinas reais (Falbo, 2005).
Portanto, para atingir este objetivo, faz-se necessário tratar aspectos relacionados ao estabelecimento de processos, métodos, técnicas, ferramentas e ambientes de suporte ao desenvolvimento de
software. Entretanto, definir processos no desenvolvimento de softwares
não é uma tarefa fácil, pois deve ser analisado caso a caso. Esta análise tem como base o tipo de aplicação, a tecnologia utilizada no desenvolvimento, localização, finalidade, além da equipe envolvida na construção e utilização do software (Falbo, 2005).
O desenvolvimento de softwares é contido dentro de um projeto. O projeto é constituído por um conjunto de atividades, com um responsável pelo projeto, datas de início/fim, recursos e equipe. O conjunto de atividades guarda entre si relação de paralelismo, dependências e decomposição em atividades mais elementares (Paula Filho, 2007).
Estas atividades, segundo Falbo (2005), podem ser classificadas quanto ao seu propósito:
a) Atividades de desenvolvimento; b) Atividades de gerência de projeto; c) Atividades de garantia da qualidade.
da organização das atividades, estruturando as atividades em fases e como estas fases estão relacionadas. Muito embora os processos tenham que ser elaborados caso a caso, o ciclo de vida de softwares envolve pelo menos as seguintes fases:
a) Planejamento;
b) Análise e especificação de requisitos; c) Projeto;
d) Implementação; e) Testes;
f) Entrega e Implantação; h) Operação;
i) Manutenção.
Sendo assim, a escolha do modelo de processo é dependente das próprias características do projeto. Os principais modelos de ciclo de vida podem ser agrupados em três categorias básicas: modelos sequenciais, modelos incrementais e modelos evolutivos. Os modelos sequenciais organizam o processo em uma sequência de fases em forma linear. Estão entre eles os modelos
clássicos e em “V”. Os modelos incrementais são utilizados quando o tamanho do sistema a ser desenvolvido é de tal forma tão grande que impede a utilização de um modelo sequencial, sobretudo quando há a necessidade de implementação rápida, geralmente, quando a solicitação é feita pelo usuário final. Portanto, no modelo incremental o sistema é desenvolvido de forma modular e tomando-se por base a sua funcionalidade. As versões ou subsistemas são implementados a cada ciclo, acrescendo novas funcionalidades. Dentre os modelos incrementais poderíamos citar a variação modelo RAD (Rapid Application
Development), no qual é estipulado um período máximo de noventa dias
Os modelos evolutivos ou evolucionários são aqueles em que o software evolui ao longo do tempo, não mantendo relação direta com a versão anterior. Este modelo é usado quando se lida com incertezas, ou seja, quando o modelo e a concepção sofrem, no decorrer do tempo, alterações importantes. Desta forma, as primeiras versões são caracterizadas como protótipos das anteriores e são úteis como base técnica para a reanálise do projeto denominada de prototipação (Falbo, 2005).
Como dito anteriormente, um dos fatores importantes na construção de um software de qualidade é o processo de seu desenvolvimento, bem como sua implantação. Neste aumento de demanda na qualidade, a utilização de normas tem sido frequente. Espinha (2007) define muito bem esta questão quando diz:
Modelos como CMMI-DEV e MPS. BR e normas como a ISO/IEC 15504 e 12207 definem um conjunto de boas práticas e características que devem estar presentes em um processo para que este possa ser gerenciado e resulte na entrega de produtos de qualidade. Entretanto, como têm o objetivo de serem aplicáveis a quase todo tipo de organização, estes modelos ou normas muitas vezes não definem como estas boas práticas e características devem ser implementadas e implantadas. Uma das maiores dificuldades que as organizações que iniciam um programa de melhoria de processos enfrentam é a dificuldade de adaptar este conjunto de boas práticas para a sua realidade, identificando quais áreas são mais relevantes e devem ser abordadas com maior urgência. Cada organização possui políticas, crenças e uma cultura específica, que deve ser levada em conta para que as melhorias sejam bem aceitas e realmente contribuam com um desenvolvimento mais eficiente.
diretamente relacionada à qualidade dos processos envolvidos em seu desenvolvimento, conclui-se que quaisquer riscos nos processos irão resultar em riscos na qualidade do produto final desenvolvido. Diante disto, ações de gerência de riscos nos processos são imprescindíveis para a garantia da qualidade final do produto (Espinha, 2007).
As principais atividades da gerência de riscos são: identificação do risco, planejamento de ações e controle dos processos (Espinha, 2007).
Processos de avaliação na gerência de riscos também constituem numa estratégia e se utilizam de ferramentas de avaliação de processos para este fim. Essa avaliação é constituída por um ou mais componentes e cada componente possui um checklist associado. Cada controle ou componente possui uma estrutura: nome do controle, justificativa, ameaças, recomendações, referências, probabilidades, severidade e agrupamento. Desta forma, define-se um critério de prioridades para o desenvolvimento de um software para uma organização (Espinha, 2007).
2.6 Linguagens de Programação
ser convertido ou traduzido em código de máquina, por meio de uma compilação ou interpretação. A este processo denomina-se tradução. Quando a tradução do código fonte ocorre antes de o programa ser executado pelo computador, pode-se dizer que houve a compilação. Esta metodologia necessita de programas, chamados compiladores, para realizar tal tarefa. Os programas compilados têm a vantagem de serem reutilizados várias vezes sem a necessidade de uma nova compilação. De outro modo, na metodologia de interpretação, o código fonte é traduzido à medida que é executado pelo processador, ou seja, o computador lê um trecho do código fonte e o executa em seguida, sistematicamente (Pisa, 2010).
Existem ainda metodologias híbridas, onde são utilizadas linguagens que são compiladas e interpretadas posteriormente, como ocorre nas linguagens Java® e na plataforma Microsoft® .NET. Estas tecnologias utilizam compiladores para traduzir o código em linguagens intermediárias, sendo, posteriormente, interpretado por máquinas virtuais próprias.
Como apontado por Pisa (2010), conceitualmente, pode-se dividir atualmente as técnicas de programação em:
a) Técnica de Programação Linear: é utilizada em problemas de otimização, onde estes são todos lineares. É uma técnica de solução de um problema que requer a determinação dos valores para as variáveis de decisão que aperfeiçoam um objetivo a ser alcançado sem violar um conjunto de limitações ou restrições; b) Técnica de Programação Modular: é um
c) Técnica de Programação Estruturada: é a forma de programação onde se utiliza estruturas simples como funções e sub-rotinas. Ela é decomposta em estruturas lógicas de sequência, decisão e interação.
d) Técnica de Programação Orientada a Objeto: é um paradigma de programação para análise, projeto, programação de softwares, baseado na interação de componentes chamados objetos. Estes objetos derivam de estruturas lógicas chamadas classes. As classes determinam aos objetos comportamentos, estados e relacionamentos com outros objetos. Deste modo, este tipo de abordagem facilita a comunicação e o entendimento do modelo lógico, pois tem bases conceituais e origem no campo de estudo da cognição. Esta técnica influenciou a área de inteligência artificial e da linguística no campo da abstração de conceitos do mundo real.
Dentre as linguagens de programação, destaca-se no Wikipédia (2011):
b) C#: é uma linguagem de programação orientada a objetos, fortemente tipada, desenvolvida pela Microsoft® como parte da plataforma .NET. A sua sintaxe orientada a objetos foi baseada no C++, mas inclui muitas influências de outras linguagens de programação, como Object Pascal e Java;
c) Visual Basic .NET®: é uma linguagem de programação orientada a objetos, desenvolvida pela Microsoft® como parte da plataforma .NET. A linguagem evoluiu do Basic e Visual Basic tornando-se de orientada a eventos (estruturada) a orientada a objetos;
d) C: é uma linguagem imperativa e procedural, para implementação de sistemas. É compilada, fornecendo acesso de baixo nível à memória e baixos requerimentos do hardware.
De um modo geral, as linguagens de programação têm o objetivo de aumentar a produtividade do programador e facilitar a criação de um software mais simples tanto do ponto de vista sintático como semântico (Mackenzie; Sharkey, 2003).
2.7 Ferramentas de desenvolvimento
código fonte e seu nome. Como resultado final, um programa “executável”
era produzido e poderia ser testado para a verificação de erros. Na existência de erros, o programador deveria fazer as correções de código no editor de texto e novamente compilar o arquivo. O ciclo se repetiria até o final do processo (Mackenzie; Sharkey, 2003).
Com o passar do tempo, as linguagens foram evoluindo assim como as ferramentas de compilação. Surge, então, o conceito de Ambiente Integrado de Desenvolvimento ou conhecido como IDE
(Integred Development Environment). O IDE combina, numa única
interface para o programador, componentes de edição, depuração e
compilação (Mackenzie; Sharkey, 2003).
As características e ferramentas mais comuns encontradas nos IDEs atualmente são: editor, compilador, linker, depurador, modelagem, geração de códigos, testes automatizados, distribuidor e refatoração. Como exemplos de IDE pode-se destacar: Delphi®, Eclipse®, MonoDevelop®, Microsoft Visual Studio.NET®, dentre outros (Wikipédia, 2011).
2.8 Sistema Gerenciador de Banco de Dados e Banco de Dados
Um tipo de software importante para muitas aplicações é o banco de dados. Ele pode ser definido como a camada de desenvolvimento em que são armazenadas as informações no sistema ou aplicativo (Costa, 2001).
A aplicação banco de dados é um software com propósito específico, de projeto e implementação do próprio usuário ou por empresas independentes. Os componentes front-end são projetados por empresas de softwares ou terceiros com a finalidade de gerenciamento e como ferramenta de consultas no banco de dados. Já o componente sistema gerenciador de banco de dados tem como função gerenciar os dados armazenados. Este não somente fornece a interface com o usuário para criar o banco de dados, encontrar e modificar os dados, mas também para fornecer componentes de sistema para gerenciar estes dados armazenados. Um sistema de banco de dados precisa fornecer recursos como: variedade de interface de usuário, independência física de dados, independência lógica de dados, otimização de consultas, integridade de dados, controle concorrente, backup e recuperação, e por fim, segurança e autorização (Petkovic, 2001).
Cada sistema gerenciador de banco de dados fornece algum tipo de controle de usuários por meio de autorizações, através das quais concedem ou revogam privilégios para usuário dos sistemas. Para o uso de um banco de dados é necessário ter um modelo de dados. Este modelo é uma coleção de conceitos, de seus relacionamentos e suas regras que são usados para representar dados em situações do mundo real. No modelo de dados relacional, os dados são tabelas e seus relacionamentos. Sendo assim, do ponto de vista do usuário, um banco de dados relacional contém apenas tabelas, nas quais existem uma ou mais colunas e nenhuma ou várias linhas. Em uma determinada posição de linha e coluna existe apenas um valor (Petkovic, 2001).
A linguagem do banco de dados relacional é chamada de
Structured Query Language. A origem do Structured Query Language é
baseada no projeto do Sistema R, projetado e implementado pela IBM® na década de 80. Ao contrário das demais linguagens, a Structured Query
Language foi projetada apenas para trabalhar com o conjunto de registros
2.9 Arquitetura de desenvolvimento em três camadas
Na programação atual envolvendo banco de dados, o desenvolvimento de sistemas em camadas facilita a programação e manutenção do aplicativo numa distribuição cliente-servidor. (Ricarte, 2011) Nesta arquitetura, a aplicação é organizada em três unidades de distribuição:
a) Camada de interface com usuário;
b) Camada de negócios, com a lógica da aplicação;
c) Camada de dados, com funcionalidade de armazenamento e recuperação.
2.10 A Tecnologia Microsoft .NET Framework®
Microsoft .NET® é uma estratégia desenvolvida pela Microsoft® para encorajar a comunicação entre sistemas e organizações. Esta estratégia é composta por ferramentas de desenvolvimento, clientes, servidores, serviços de Web Services e experiências de seus usuários (Microsoft®, 2007).
Para Mackenzie e Sharkey (2003), a tecnologia .NET representa toda uma gama de tecnologias e conceitos para o desenvolvimento de aplicativos.
camadas de desenvolvimento de software acima do sistema operacional. Ela fornece um rico nível de integração com tecnologias de apresentação, tecnologias para componentes, tecnologias de acesso a dados e é vista pela Microsoft® como uma plataforma. Esta plataforma dá suporte tanto ao desenvolvimento de aplicações desktop quanto de aplicações para
internet (Mackenzie; Sharkey, 2003).
Para a Microsoft® o .NET Framework® consiste em componentes de modulação e simplificação do desenvolvimento de aplicativos e distribuição. Ele é composto por dois componentes principais: CRL (Common Language Runtime) e a biblioteca de classes
.NET Framework® (Microsoft, 2007).
O CRL é um componente fundamental do .NET
Framework, pois o compilador transforma o código da linguagem de alto
nível escolhida pelo programador, o insere dentro do módulo de gerenciamento onde o CRL está instalado no computador cliente, e, assim, pode executá-lo. Desta forma, o código executado nesta plataforma é totalmente gerenciado, podendo incluir também o garbage
collector, que é responsável por todo o gerenciamento de recursos do
sistema utlizado pelo aplicativo. Um exemplo disto é a liberação automática de memória randômica quando esta já não está sendo mais utilizada pelo aplicativo (Microsoft, 2007).
A biblioteca de classes do .NET Framework® é compreendida como uma imensa coleção de classes disponíveis para a implementação em uma aplicação quando se utiliza programação orientada a objetos. Estas classes dão suporte e funcionalidade para o desenvolvimento de aplicativos tanto para Web, Windows®, banco de dados, aparelhos celulares, Servidores, Web Services, entre outros.
a) Compilação do código fonte para uma linguagem que o CRL compreenda. Por exemplo, o compilador .NET traduz um código escrito pelo programador em Visual Basic em uma linguagem intermediária, MSIL (Microsoft
Intermediate Language®).
b) Traduz o código MSIL para uma linguagem de máquina no computador cliente onde o aplicativo deverá ser executado. Para isso, o .NET Framework utiliza um processo conhecido
como compilação “just-in-time” (JIT) quando um código é executado.
c) A linguagem de máquina é executada utilizando-se da infraestrutura do CRL. O Carregador CRL é responsável pelo carregamento e iniciação do código. O código do programador é, então, carregado sob demanda e as seções não utilizadas do programa não ocupam alocação na memória randômica.
A arquitetura de segurança do .NET Framework® é um importante fator que se deve considerar no desenvolvimento de aplicativos. Desta forma, o .NET Framework® inclui uma série de aprimoramentos para implemantação em aplicativos como: permissões, segurança por tipos, política de seguranças , seguranças baseadas em regras, segurança win32 (camada de segurança adicional às plataformas 32bits) e segurança no acesso de código.
suporte ao namespace System.Security.Cryptography que é usado para serviços de criptografia no desenvolvimento de sistemas para ocultamento de dados críticos.
2.11 Licenças de Software
Licença de software pode ser definida como as ações permitidas (ou proibidas) pelo detentor dos direitos de criação do software (programador ou empresa) concedidas ou impostas ao seu usuário. Entende-se como usuário qualquer entidade legal, pessoa física,
empresas ou “ambiente doméstico”, dando origem à expressão end user
license agreement - EULA (Wikipédia, 2011).
Desta forma, os softwares podem ser classificados quanto a sua licença em: softwares proprietários ou softwares livres. Os
softwares proprietários são aqueles em que o código fonte, modificação,
distribuição, cópia e redistribuição são determinados pelo seu criador ou detentor dos direitos autorais. Por outro lado, os softwares livres, ou conhecidos como Open-Sources, são aqueles que satisfazem as seguintes condições: não restrição à sua distribuição, acesso completo ao código fonte e sua versão compilada, permitem alterações e derivações do programa, exigem documentação adequada caso modificados, não possuem discriminação na distribuição, dentre outros (Kon, 2001).
Muito embora se tenha vários tipos de licenças na categoria Open-Source, cada uma delas possui diferenças em suas concepções e nem todas satisfazem totalmente as exigências da categoria fielmente. Algumas licenças possuem ainda diferenças em suas próprias versões. Como exemplo, pode-se destacar a licença GPL
(General Public License), atualmente a mais utilizada, como uma licença
2007. Atualmente, a versão 3, iniciada em 2007, estabelece novas regras, se adequando aos problemas de utilização de certificações digitais, sobretudo, em caso de medias digitais. É importante ressaltar que as versões 2 e 3 são incompatíveis do ponto de vista de migração automática entre estas licenças (Sabino; Kon, 2009).
Na Legislação Brasileira, a Lei nº 9.609, de 19 de fevereiro de 1998, popularmente conhecida como “Lei Antipirataria”,
O objetivo deste projeto é desenvolver um software para gestão e geração de dados epidemiológicos para o laboratório de Patologia da Faculdade de Odontologia de São José dos Campos –
UNESP, utilizando-se do Microsoft .NET Framework® 2.0.
Esta pesquisa foi submetida e aprovada pelo Comitê de Ética e Pesquisa da Faculdade de Odontologia de São José dos Campos (091/2009-PH/CEP - Anexo A).
4.1 Materiais
Foram utilizados os seguintes materiais no desenvolvimento do projeto:
a) Computador para Desenvolvimento com processador que possui suporte à virtualização; b) Sistema Operacional Microsoft Windows 7
Ultimate® atualizado;
c) Servidor de Dados e Estação de Trabalho; d) SGBDR (Sistema Gerenciador de Banco de
Dados Relacionais) Microsoft SQL SERVER EXPRESS® 2005 para uso versão final;
e) Microsoft Report Viewer Redistributable® 2005 SP1 em todas as máquinas clientes;
f) Microsoft Framework® 2.0 Redistributable e suas atualizações em todas as máquinas;
g) Microsoft Virtual PC® 2007; h) Roteador Wireless;
j) Sistema de Desenvolvimento Microsoft Visual Studio®.NET 2005 Versão Professional;
k) Sistema de Documentação Visual de Projetos e Apresentação, Microsoft Office Visio® 2010;
l) Engine de processamento de mapas do
Google® (Google Maps®);
m) Tabelas de dados estruturados do Cartão Nacional de Saúde (Cartão SUS) – CNS;
n) Acervo dos laudos histopatológicos do Laboratório de Patologia da Faculdade de Odontologia de São José dos Campos –
UNESP.
No que confere aos Recursos Humanos, contou-se para o desenvolvimento do projeto:
a) Aluno da Pós-Graduação atuando como programador e Analista de Sistema;
b) Orientador e Co-orientador;
c) Equipe do setor (Professores da Patologia e Técnico de Laboratório);
d) Alunos da Pós-Graduação atuando como Examinadores.
4.2 Métodos
Software. Este método pode se apoiar em várias abordagens utilizando-se do ciclo de vida do software (Costa, 2001).
O modelo clássico do ciclo de vida de software é a base para os demais tipos variantes de ciclo (figura 1).
Figura 1 - Ciclo Clássico de Software
Com base no modelo clássico do ciclo de vida de
software, tem-se como o próximo passo a elaboração de um cronograma
Quadro 1 – Cronograma para ciclo de vida de software
CICLOS MESES
Definição dos problemas Tempo utilizado para coleta de dados.
Análise Tempo destinado à análise de
desenvolvimento, modelagem de dados e análise de riscos.
Projeto Tempo destinado ao refinamento da
análise e definições do tipo de projeto. Codificação Tempo utilizado para a codificação do
projeto e cada subsistema, depuração.
Testes Período destinado aos testes de
utilização e implantação.
Os ciclos de desenvolvimento podem ser descritos como:
a) Ciclo de Definição do Problema: coleta de informações para elaboração e planejamento das demais etapas. Tem como objetivos compreender os fluxos e processos, auxiliar na documentação do projeto, observar metas, atores, objetivos, prioridades e risco;
b) Ciclo de análise: faz-se a análise dos problemas encontrados, a escolha da técnica da análise e a modelagem de dados;
c) Ciclo de projeto: é a etapa em que se define como o sistema será feito, dando um refinamento à etapa de análise;
d) Ciclo de codificação: quando se traduz as fases anteriores em um código fonte utilizado posteriormente pelo compilador;
anteriormente, tanto na sua utilização como em sua implantação.
Inicialmente, reuniões periódicas foram agendadas com a equipe e com os orientadores do projeto para avaliação de fluxos e construção do modelo lógico, estratégias de dicionarização e padronização de termos, metas, gerenciamento de riscos, políticas de acesso, políticas de segurança, acompanhamento de prazos, planejamento estratégico de desenvolvimento, de testes e implantação dentre outros. Os itens das reuniões determinaram o planejamento a ser seguido e as dificuldades nas etapas e as estratégias de enfrentamento.
Foi utilizado um quadro para controle de cada ciclo do desenvolvimento, estruturado em ciclos, fases e tarefas (quadro 2).
Quadro 2 - Controle do ciclo de desenvolvimento
Ciclo Fase Tarefa
Definição de Problema Concepção Tarefa de concepção Elaboração Tarefa de elaboração Liberação Tarefa de liberação
Análise Concepção Tarefa de concepção
Elaboração Tarefa de elaboração Construção Tarefa de construção Liberação Tarefa de liberação
Projeto Concepção Tarefa de concepção
Elaboração Tarefa de elaboração Construção Tarefa de construção Liberação Tarefa de liberação Codificação Concepção Tarefa de concepção
Elaboração Tarefa de elaboração Construção Tarefa de concepção Liberação Tarefa de liberação
Testes Concepção Tarefa de concepção
Na gerência de riscos foi elaborado um quadro estruturado por identificação do risco, ações e controle de processos (quadro 3).
Quadro 3 – Gerência de Riscos
Tipo de Risco Ações Controle
Nome do risco Ações para evitar ou
minimizar risco Fase de implementação
Para a programação, ultilizou-se a linguagem Visual Basic em um Ambiente de Desenvolvimento Integrado (Integrated Development
Environment) e, como paradigma de programação, a orientação a objetos.
A ferramenta de desenvolvimento utilizada para este fim foi a Microsoft Visual Studio® .NET 2005 (Figura 2).
O aplicativo foi desenvolvido em três camadas e foi utilizada a inteface “Windows form®”, ou formulários Windows®. Embora o aplicativo seja do tipo desktop, este tem acesso a Web por meio de controles para navegação de internet e envio de emails quando configurado.
Para a camada de resistência de dados foram utilizadas programações em linguagem SQL por meio de procedimentos armazenados para todas as consultas e manipulações de dados.
Após o desenvolvimento, para testes a realização de foram digitados dados contidos nos laudos histopatológicos pertencentes ao acervo da Disciplina, autorizados pelos responsáveis legais pelo arquivo. Essa digitação foi realizada nos limites físicos da Disciplina de Patologia, no Campus da Universidade, sendo que nenhum laudo deixou o espaço físico acima citado. Não houve rasura, anotação ou adulteração destes documentos.
O sigilo e inviolabilidade dos dados têm a proteção da própria arquitetura do banco de dados (acesso restrito à camada de resistência de dados). Porém, como proteção adicional, foram ainda utilizados os métodos de criptografia simétrica, técnicas de identificação, autenticação e políticas de permissão de acesso de usuários na camada
de interface de usuários e na camada de negócios.
A digitação dos laudos antigos foi feita pelo autor da pesquisa e por pessoal autorizado pelos responsáveis pelo acervo supracitado com o objetivo de cumprir com a metodologia de testes, de acordo com o ciclo de vida do software.
Devido à natureza do projeto, não há resíduo que comprometa o meio ambiente ou a saúde de todos os envolvidos.
Tanto a programação quanto a modelagem de dados e a documentação foram executadas pelo autor do trabalho. As licenças de
softwares utilizadas para o desenvolvimento foram licenças proprietárias
Os resultados obtidos foram organizados considerando os pré-requisitos indicados por Carvalho e Eduardo (1998), com a finalidade de se obter melhor entendimento e facilidade no acompanhamento da discussão.
5.1 Definição de metas e prioridades
No processo de desenvolvimento, foram feitas reuniões regulares com a equipe e orientadores com a finalidade de análise, discussão e avaliação. Obteve-se, como resultado, as seguintes metas:
a) Construir uma ferramenta informatizada que possa auxiliar na organização dos dados contidos em cerca de doze mil laudos anatomopatológicos (até o momento) do acervo do Laboratório de Patologia da Faculdade de Odontologia do Campus de São José dos Campos - UNESP;
b) Obter um software que possa organizar o fluxo dos processos envolvidos na elaboração do laudo anatomopatológico emitido pelo Laboratório de Patologia;
d) Obter relatórios de gestão, sócio demográficos, estatísticos e acadêmicos com facilidade e rapidez;
e) Obter uma ferramenta automatizada de avaliação de laudos histopatológicos construídos por alunos da Pós-graduação em Biopatologia Bucal que cursam a Disciplina de Diagnóstico em Patologia Bucal;
f) Construir uma ferramenta de acesso fácil à enciclopédia eletrônica de patologia em construção pelos alunos da Pós-graduação em Biopatologia Bucal, área de Patologia;
g) Facilitar a obtenção de informação sobre as atividades anuais da Disciplina para a Universidade e demais órgãos de financiamento.
Diante das metas e prioridades apresentadas, foi produzido o cronograma, planejamento e controles para gerência de riscos de acordo com o ciclo de vida de softwares.
O quadro de cronograma (quadro 4) apresenta os ciclos e o tempo previsto no desenvolvimento de cada um deles, sendo que os prazos levam em consideração a equipe de desenvolvimento.
Quadro 4 – Resultado do cronograma de desenvolvimento
CICLOS MESES
Definição dos problemas 3
Análise 3
Projeto 3
Codificação 12
Em virtude de o aplicativo ter origem acadêmica, o desenvolvimento foi executado por uma única pessoa (autor da dissertação), e esta acumulou todas as tarefas durante o processo. Em geral, para o desenvolvimento um projeto dentro de uma organização, é utilizada uma equipe com um grande número de pessoas e suas tarefas são distribuídas entre seus componentes. Desta forma, o impacto no desenvolvimento do software pode ser bastante reduzido, chegando até a produção de software RAD.
De fato, é importante ressaltar que o cronograma não é linear, e que algumas de suas etapas ocorreram simultaneamente. O controle dos ciclos de desenvolvimento foi estruturado conforme descrito no Apêndice A.
As definições de prioridades foram obtidas como resultados das reuniões supracitadas, orientadas pelas metas elencadas. Neste sentido, o software foi dividido em três segmentos lógicos:
a) Modelo lógico para a digitação de laudos antigos;
b) Modelo lógico para o novo fluxo do serviço; c) Modelo lógico para apoiar o aprendizado e
produção científica da Disciplina.
Para cada modelo lógico, uma ou mais prioridades foram estipuladas de acordo com sua finalidade específica.
No modelo lógico para a digitação dos laudos antigos, a prioridade foi de manter uma compatibilidade máxima com o dado contido no laudo antigo, registrado em papel.
No modelo lógico para apoiar o aprendizado e a produção científica, as prioridades resultantes foram: gerar uma coleta de dados estatísticos epidemiológicos de uma forma rápida e simples, garantir uma devolutiva ao aluno quanto ao seu desempenho, auxiliando seu aprendizado em Patologia.
5.2 Estruturação e padronização de termos
Inicialmente, foram inicialmente identificados como atores neste processo: profissional solicitante, examinador, professor da Patologia, digitador, profissional de informática e técnico de laboratório.
No processo de dicionarização dos atores obtivemos, inicialmente os seguintes resultados:
a) Profissional solicitante: é o profissional da área de saúde, médico ou cirurgião dentista, que por meio de uma biópsia e requisição, solicita laudo anatomopatológico, tanto por intermédio dos professores da patologia quanto por examinadores ou técnicos de laboratório;
b) Executante: é o profissional que analisa o exame e estuda o caso, sendo, geralmente, o aluno da Pós-graduação em Biopatologia Bucal matriculado no crédito de Diagnóstico em Patologia Bucal. Pode também cadastrar e editar informações de profissionais solicitantes, pacientes, profissões de pacientes, novos endereços (ruas, bairros, cidades); acompanhar o trabalho da rotina; pesquisar
status de laudos; inserir e gravar anotações no
patologia e acompanhar a rotina de trabalho no escopo de sua atuação;
c) Digitador: elemento que digita no sistema os laudos antigos em papel. Pode cadastrar e editar examinadores, profissionais solicitantes, pacientes, profissões de pacientes e novos endereços (rua, bairros, cidades) no sistema; d) Professor da Patologia: professor das
disciplinas de Patologia Geral e Patologia Bucal
que avalia as descrições, macroscópicas/microscópicas e diagnósticos do examinador e emite o laudo anatomopatológico com descrições e diagnósticos finais. Pode cadastrar e editar informações de pacientes, profissionais solicitantes, outros professores da patologia, professores responsáveis pelas requisições e técnicos de laboratório. Além disso, pode cadastrar e editar categorias de patologias, nomes de doenças e suas antigas denominações, descritas no trabalho como
alias das patologias. O professor da patologia
pode acessar diversos relatórios estatísticos, relatórios sócio demográficos, relatórios de gestão dos processos, relatórios de avaliação dos examinadores (tanto em grupo como individual), pesquisar laudos, pesquisar no
website de patologia (intranet) e acessar
e) Técnico do laboratório: profissional que processa a inclusão do material e confecção de lâminas anatomopatológicas após exame macroscópico executado. Pode também, cadastrar e editar informações de profissionais solicitantes, seu próprio cadastro, cadastro de pacientes, profissões de pacientes; preencher solicitações de exames no sistema a pedido do profissional solicitante; informar ao sistema a entrega de laudos; realizar pesquisas sobre
status de laudos e acompanhar a rotina de
trabalho no escopo de sua atuação;
f) Informática: profissionais que acessam o sistema para diagnóstico de rede, testes em banco de dados e configurações de email.
Figura 6- Exemplo de documento UML de casos de uso
A etapa seguinte foi definir os requisitos do sistema baseados nos atores, casos de uso, requisitos funcionais e requisitos não funcionais. Os requisitos funcionais são aqueles que descrevem o comportamento do sistema, ou aquilo que deve ser feito pelo sistema. Por outro lado, os requisitos não funcionais compreendem as propriedades, métodos e eventos do sistema.
Como resultado se obteve os seguintes requisitos:
Profissional solicitante requisita laudo anatomopatológico e gerencia suas informações:
