CENTRO FEDERAL DE EDUCAÇÃO TECNOLÓGICA DO

CENTRO FEDERAL DE EDUCAÇÃO TECNOLÓGICA DO PARANÁ
Programa de Pós-Graduação em Engenharia Elétrica e Informática Industrial
DISSERTAÇÃO
Apresentada ao CEFET-PR
Para obtenção do título de
MESTRE EM CIÊNCIAS
por
JAIME DE BRITTO
COMPUTAÇÃO MÓVEL NA TELEMEDICINA E ENSINO MÉDICO À
DISTÂNCIA: APLICAÇÃO EM ONCOLOGIA PEDIÁTRICA
Banca Examinadora:
Presidente e Orientador:
Prof. Dr. HEITOR SILVÉRIO LOPES
CEFET-PR
Examinadores
Prof. Dr. EDSON EMÍLIO SCALABRIN
Prof. Dr. HILTON JOSÉ SILVA DE AZEVEDO
MSc. EDSON MICHALKIEWICZ
PUCPR
CEFET-PR
UFPR
Curitiba, 28 de Fevereiro de 2002
iii
AGRADECIMENTOS
Ao Prof. Dr. Heitor Silvério Lopes pelo valoroso e compreensivo trabalho na
orientação de meus estudos nestes últimos dois anos.
Ao Dr. Edson Michalkiewicz, coordenador do programa International Outreach, pela
oportunidade de desenvolver este trabalho, pelo seu interesse, participação, paciência e
confiança, que fizeram com que os objetivos iniciais fossem atingidos.
Aos colegas de mestrado, pelas trocas de experiências durante o transcorrer do curso.
Aos professores da banca examinadora, que dispuseram de seu precioso tempo para
analisar esta pequena contribuição para a pesquisa.
Ao Prof. Dr. Shigehiro Funayama e à Sigeco Funayama , meus sogros, pelas palavras de
incentivo nos momentos de desânimo.
Aos meus pais, pela sólida base de amor, caráter e educação que me foi proporcionada.
E por fim, a minha amada esposa, Engª Patricia Funayama de Britto, não só por seu
carinho e compreensão, mas também pelas valiosas contribuições durante o desenvolvimento
deste trabalho.
iii
iv
iv
v
SUMÁRIO
1
INTRODUÇÃO.......................................................................................................... 1
1.1 - Motivações............................................................................................................ 1
1.2 - Objetivos............................................................................................................... 3
2
EDUCAÇÃO À DISTÂNCIA ................................................................................... 5
2.1 - Histórico da educação à distância......................................................................... 5
2.2 - Regulamentação da EAD no Brasil ...................................................................... 6
2.3 - Fundamentos......................................................................................................... 7
2.3.1 - Telemedicina.................................................................................................. 8
2.3.2 - Telemedicina e Educação à Distância ......................................................... 11
2.3.3 - O Problema do uso da Informática no ensino à distância............................ 15
2.3.4 - PBL (Problem-Based Learning).................................................................. 16
2.3.5 - PBL na medicina.......................................................................................... 19
2.4 - Ferramentas disponíveis para suporte ao Ensino à Distância ............................. 21
2.4.1 - Telnet ........................................................................................................... 22
2.4.2 - FTP .............................................................................................................. 22
2.4.3 - E-Mail .......................................................................................................... 23
2.4.4 - CHAT ........................................................................................................... 24
2.4.5 - Vídeoconferência......................................................................................... 26
2.4.6 - FAQ ............................................................................................................. 28
2.4.7 - WWW .......................................................................................................... 28
2.5 - A necessidade de gerenciamento das informações discutidas ............................ 29
3
FUNDAMENTOS TECNOLÓGICOS .................................................................... 31
3.1 - A utilização de computadores de mão na medicina............................................ 31
3.1.1 - QRx (epocrates) ........................................................................................... 33
3.1.2 - Qid ............................................................................................................... 34
3.1.3 - Physicians Drug Handbook ......................................................................... 34
3.1.4 - PDR2001...................................................................................................... 34
3.1.5 - ABX Guide .................................................................................................. 34
3.1.6 - Tarascon....................................................................................................... 35
3.2 - Sistemas operacionais para PDAs....................................................................... 35
v
vi
3.2.1 - PalmOS® ..................................................................................................... 37
3.2.2 - Windows CE® e Pocket PC® ..................................................................... 38
3.3 - Características básicas ........................................................................................ 39
3.4 - Programação para PalmOS® .............................................................................. 40
3.4.1 - Tamanho da Tela ......................................................................................... 41
3.4.2 - Rápido Tempo de Resposta Esperado ......................................................... 41
3.4.3 - Conectividade com o PC ............................................................................. 41
3.4.4 - Métodos de Entrada ..................................................................................... 42
3.4.5 - Memória....................................................................................................... 43
3.4.6 - Sistema de Arquivos .................................................................................... 43
3.4.7 - Compatibilidade Backward ......................................................................... 44
3.5 - Linguagens de programação para PalmOS......................................................... 44
3.6 - Arquivos PDB..................................................................................................... 47
3.6.1 - Conceitos ..................................................................................................... 47
3.6.2 - Estrutura Física ............................................................................................ 48
3.7 - Arquivos PRC e Runtimes .................................................................................. 53
3.8 - Sincronização...................................................................................................... 54
3.9 - Conduits .............................................................................................................. 55
3.10 - O sincronismo dos dados via Internet............................................................... 57
4
IMPLEMENTAÇÃO ............................................................................................... 59
4.1 - Introdução ........................................................................................................... 59
4.2 - A base de dados centralizada .............................................................................. 60
4.3 - O servidor de aplicação....................................................................................... 61
4.4 - O sistema de captação remota de dados.............................................................. 63
4.5 - O sistema de sincronismo de dados entre os PDAs e a base de dados ............... 68
4.6 - A execução do sistema cliente no computador pessoal ...................................... 76
4.6.1 - Relatórios emitidos pelo sistema ................................................................. 83
4.7 - Segurança............................................................................................................ 84
5
DISCUSSÃO E CONCLUSÕES ............................................................................. 87
5.1 - Discussão ............................................................................................................ 87
5.2 - Conclusões .......................................................................................................... 89
5.3 - Trabalhos Futuros ............................................................................................... 91
vi
vii
6
ANEXO I.................................................................................................................. 93
7
ANEXO II .............................................................................................................. 111
8
ANEXO III ............................................................................................................. 131
9
ANEXO IV ............................................................................................................. 151
10
REFERÊNCIAS BIBLIOGRÁFICAS ............................................................... 155
vii
viii
viii
ix
LISTA DE ILUSTRAÇÕES
Figura 1: Cenário a ser automatizado pela ferramenta proposta ................................................ 4
Figura 2: home page (http://www.cbmi.upmc.edu/) para um curso virtual de neurobiologia . 12
Figura 3: Transmissão de vídeos em RealVideo através da internet........................................ 12
Figura 4: Classe virtual interativa (http:ils.paho.org) usando o NetMeeting............................ 13
Figura 5: Questionário interativo de avaliação na Internet (www.nib.unicamp.br). ................ 14
Figura 6: Imagem de um Palm com sistema operacional PalmOS .......................................... 38
Figura 7: Imagem de um PDA HP Jornada com Windows CE ................................................ 39
Figura 8: Área do PDA destinada a entrada de dados (Graffiti) .............................................. 42
Figura 9: Caixa de diálogo disponibilizando um teclado para facilitar a entrada de dados .....43
Figura 10: Imagem de uma sincronização entre o PDA e o PC ............................................... 54
Figura 11: Esquema de sincronismo de dados adotado pela ferramenta em desenvolvimento 58
Figura 12: Modelo lógico do dados.......................................................................................... 61
Figura 13: Telas iniciais do sistema PALM-TUTOR............................................................... 63
Figura 14: Entrada de dados facilitada por calendários, listas e caixas de seleção. ................. 64
Figura 15: Telas de lista e cadastro de consultas...................................................................... 66
Figura 16: Telas de lista e cadastro de discussões.................................................................... 66
Figura 17: Telas de lista e cadastro de cirurgias....................................................................... 66
Figura 18: Telas do cadastro de cirurgias................................................................................. 67
Figura 19: Telas de lista e cadastro de diagnósticos................................................................. 67
Figura 20: Janela de log informando que houve conflito de sincronismo nos registros ..........71
Figura 21: Fluxograma do esquema de sincronismo da tabela de pacientes. ........................... 75
Figura 22: Telas inicial e de acesso ao PALM-TUTOR para PC............................................. 76
Figura 23: Tela inicial do PALM-TUTOR para PC................................................................. 77
Figura 24: Janela de acesso ao dados das consultas do paciente selecionado.......................... 79
Figura 25: Janela de acesso ao dados dos diagnósticos do paciente selecionado..................... 79
Figura 26: Janela de acesso às discussões referentes ao paciente selecionado ........................ 80
Figura 27: Janela de acesso ao dados das cirurgias efetuadas no paciente selecionado...........80
Figura 28: Janela de acesso ao dados dos DAV implantados no paciente selecionado ...........81
Figura 29: Janela de acesso ao dados das complicações dos DAVs do paciente selecionado . 81
Figura 30: Janela de cadastro de pacientes............................................................................... 82
ix
x
Figura 31: Janela de cadastro de usuários ................................................................................ 82
Figura 32: Janela de alteração de senha do usuário corrente.................................................... 82
Figura 33: Tela de configuração do Windows para acesso a objetos DCOM.......................... 85
x
xi
LISTA DE TABELAS
Tabela 1: Exemplos de software de referência médica para PDAs.......................................... 33
Tabela 2: Comparação entre os computadores de mão mais populares ................................... 36
Tabela 3: Comparativo de ferramentas de programação para PDAs........................................ 46
Tabela 4: Estrutura Física do PDB ........................................................................................... 48
Tabela 5: Estrutura do Header ................................................................................................. 49
Tabela 6: Estrutura do Record List ........................................................................................... 51
Tabela 7: Estrutura das entradas de registros ........................................................................... 51
Tabela 8: Atributos do registro................................................................................................. 52
Tabela 9: Estrutura da Category Data...................................................................................... 53
Tabela 10: Dicionário de dados da tabela de usuários.............................................................. 95
Tabela 11: Dicionário de dados da tabela de pacientes ............................................................ 96
Tabela 12: Dicionário de dados da tabela de consultas ............................................................ 98
Tabela 13: Dicionário de dados da tabela de diagnósticos..................................................... 100
Tabela 14: Dicionário de dados da tabela de cirurgias........................................................... 102
Tabela 15: Dicionário de dados da tabela de Dispositivos de acesso vascular ...................... 105
Tabela 16: Dicionário de dados da tabela de complicações do DAV .................................... 109
xi
xii
xii
xiii
LISTA DE ABREVIATURAS
API
– Application Program Interface
Art
– Artigo
CCITT
– Comitée Consultatif International Téléphonique et Télégraphique
CDK
– Conduit Development Kit
CEFET-PR
– Centro Federal de Educação Tecnológica do Paraná
CLSID
– Class Identifier
COM
– Component Object Model
COM+
– Component Object Model Plus
CORBA
– Common Object Request Broker
CU-SeeME
– See You, See Me
DBF
– Data Base File
DCOM
– Distributed Component Object Model
DLL
– Dynamic Link Library
DNA
– Distributed InterNet Application
EAD
– Ensino à distância
E-Mail
– Electronic Mail
FTP
– File Tranfer Protocol
HP
– Hewlett Packard
HTML
– Hyper Text Modeling Language
HTTP
– Hyper Text Transfer Protocol
ICQ
– I Seek You
ID
– Identifier
IDE
– Interactive Development Environment
IP
– Internet Protocol
IRC
– Internet Relay Chat
IrCOMM
– Infrared Communication
ISP
– Internet Service Provider
Mac
– Macintosh
MEC
– Ministério da Educação e do Desporto
MSMQ
– Microsoft® Message Queuing
MTS
– Manager Transaction Security
xiii
xiv
PBL
– Problem-Based Learning
PC
– Personal Computer
PCMCIA
– Personal Computer Memory Card International Association
PDA
– Personal Digital Assistant
PDB
– Palm Data Base
POSE
– PalmOS Emulator
PRC
– Palm Resource
RAD
– Rapid Application Development
RAM
– Random Access Memory
RFC
– Request For Comment
RMI
– Remote Method Invocation
ROM
– Read Only Memory
RPC
– Remote Procedure Call
SGBD
– Sistema Gerenciador de Banco de Dados
SO
– Sistema Operacional
TCP
– Transmission Control Protocol
TCP/IP
– Transmission Control Protocol/Internet Protocol
VB
– Visual Basic
VCL
– Visual Component Library
WWW
– World Wide Web
xiv
xv
RESUMO
O presente trabalho está relacionado à instrumentação e a coordenação da coleta
remota de informações sobre oncologia pediátrica e à consolidação e disponibilização de uma
base de dados centralizada na Internet.
O sistema implementado é uma colaboração ao programa International Outreach do
St. Jude Hospital. Este programa busca disseminar os avanços atingidos pelos países
desenvolvidos no tratamento de oncologia pediátrica para os países em desenvolvimento.
Com a intenção de facilitar o treinamento à distância de especialistas em oncologia pediátrica
no Brasil, um sistema de acompanhamento no tratamento de pacientes nos locais de
atendimento foi implementado para computadores de mão do tipo PDA, com principal
característica a portabilidade, gerenciados pelo sistema operacional PalmOS®, com ambiente
gráfico, baseado em eventos.
As informações são armazenadas em registros com
identificação única, no formato PDB, e transferidas para a base de dados corporativa na
internet através da tecnologia hotsync, sincronização controlada por conduit de dupla via.
Uma aplicação cliente para computadores pessoais, modelo desktop, integra este projeto para
ultrapassar as limitações dos PDAs, no que diz respeito a determinadas entradas de dados e à
impressão de relatórios.
O servidor que provê acesso à base de dados corporativa foi construído sobre o
sistema de objetos distribuídos Microsoft DCOM, que fornece comunicação do tipo
Cliente/Servidor e possui características de programação orientada a objetos.
A adaptabilidade foi requisito de projeto para extensão de uso a outras áreas de estudo,
utilizando a mesma estrutura sistêmica.
Com os dados oriundos dos atendimentos dos pacientes pelos especializandos e das
orientações do coordenador do grupo a respeito destes atendimentos, busca-se, futuramente,
montar uma sólida base de conhecimento sobre procedimentos clínicos envolvidos na
oncologia pediátrica e de suas características regionais no país.
O sistema encontra-se em fase de testes, sendo prevista a sua implantação no decorrer
do primeiro semestre de 2002.
xv
xvi
ABSTRACT
This dissertation is related to the remote acquisition about pediatric cancer, so as
create a consolidated database and make it available. The required instrumentation and control
software for this purpose were developed.
The implemented system is a collaborative work with the International Outreach
program of St. Jude Hospital (Memphis, Tn). This program fosters the dissemination of the
recent advances in pediatric oncology treatment in developed countries to third-world
countries. In order to make easier the task of training specialists in pediatric oncology in
Brazil, a system to in-site following patient was developed for personal digital assistants
(PDAs), which are portable, managed by PalmOS®, a graphical and events-based operating
system. Information is stored in registers uniquely identified, in PDB standard format, and
transferred to the database by means of Hotsync technology. Synchronism is controlled by a
two-way conduit. A client application for desktop computers was implemented to overcome
some PDA’s limitations, specifically limited data entries and printed reports.
The server which provides access to the corporative database was built using DCOM,
a distributed object system that implements client/server communication and that has objectoriented programming features.
The major project requirement was adaptability. The objective is to extend the use of
the same system structure to other medical areas of research.
The information obtained from patients treatment and from the coordinator’s
orientations will be used to create a solid knowledge base regarding pediatric oncology,
including regional characteristics inherent to Brazil.
xvi
1
CAPÍTULO 1
1
INTRODUÇÃO
1.1 - MOTIVAÇÕES
Existe uma tendência evidente das instituições e profissionais de saúde em buscar
alternativas para melhorar os processos de diagnóstico. Tais alternativas visam minimizar os
riscos para os pacientes, bem como reduzir os custos e o tempo despendidos. Em medicina,
particularmente, seu objetivo fim e a complexidade inerente aos assuntos envolvidos
ressaltam a importância de ferramentas computacionais que auxiliem nas tomadas de
decisões, padronizando os diagnósticos e evitando a subjetividade.
Neste sentido, o St. Jude Children’s Research Hospital (Memphis, Tennesee, EUA)
pretende construir um ambiente clínico e de ensino/aprendizado integrado, sem limitação de
distância ou língua, através de um programa conhecido como International Outreach. Este
programa transfere o progresso no tratamento de câncer infantil, atingido pelos países
desenvolvidos, para aqueles com recursos limitados. Em 2001, o programa contou com três
novos afiliados internacionais, em um total de treze países, incluindo o Brasil,
especificamente nas cidades de Curitiba e Recife.
Embora seja complexo conceituar com exatidão o mal denominado câncer, nenhuma
pessoa, leiga ou especialista no assunto, deixa de ter noção da gravidade deste problema que,
segundo estudo do International Outreach, atingiu em 1999 mais de 10 milhões de pessoas no
mundo, levando a uma estatística de 6 milhões de mortes. As estimativas para 2020 são de 20
milhões de casos de câncer no mundo, com 12 milhões de vítimas da doença. Especificamente
na oncologia pediátrica, verifica-se o aparecimento de 240 mil novos casos a cada ano.
Apesar dos avanços nas terapias e do conseqüente aumento das taxas de sobrevivência
para crianças com câncer em países desenvolvidos (aproximadamente 75%), menos de 30%
das crianças do mundo tem acesso aos modernos tratamentos. Observa-se, portanto, através
dos valores percentuais, que, tão importante quanto pesquisar novos tratamentos é, difundir
esse conhecimento.
2
No Brasil, diferenças regionais, recursos médicos inadequados, falta de especialistas e
restrições socioeconômicas apresentam variações no tratamento oncológico entre uma região
e outra, semelhantes às variações verificadas entre países desenvolvidos e em
desenvolvimento.
O International Outreach expande a missão do St. Jude Hospital globalmente,
fornecendo uma estrutura para facilitar consultas médicas, aprendizado e ensino, e eventuais
pesquisas. Portanto, a tecnologia de ponta tem um papel vital para tornar esta colaboração
internacional possível.
A Coordenação Brasileira do International Outreach, através da educação, do
treinamento e da transferência de conhecimento e tecnologia, objetiva aumentar a
sobrevivência de crianças com câncer e identificar novas oportunidades de pesquisa.
O ambiente atual de intercâmbio adotado, para ensino médico, pode ser descrito como
a seguir. O paciente é atendido por um médico participante do programa International
Outreach, de especialização em cirurgia oncológica pediátrica, nas cidades de Curitiba e
Recife. O médico preenche uma ficha cadastral, fichas de atendimento e situação, analisa a
condição do paciente, efetua um diagnóstico e, posteriormente, prescreve um tratamento.
Cada um destes passos é informado, através de correio eletrônico, ao coordenador do
programa, responsável por centralizar e gerenciar essas informações. Cabe também ao
coordenador, auxiliar no tratamento do paciente, orientando o especializando em práticas
médicas atualizadas, verificando eventuais erros de diagnóstico e indicando tratamentos
adequados – auxílio este também implementada através do correio eletrônico.
Este procedimento evita o isolamento do médico atendente, que pode receber
informações do coordenador, ou através deste, de outros médicos participantes do programa.
No entanto, é de senso comum, a necessidade de um aperfeiçoamento do intercâmbio,
buscando principalmente, a padronização das informações para facilitar a análise e para a
formação de um banco de dados, rapidez e facilidade na transferência de conhecimento para o
atendente e para o grupo.
A melhoria do procedimento de coleta dos dados do paciente, eliminando a
necessidade de transcrição de formulários para meio magnético; a padronização das
informações em formulários eletrônicos e a disponibilização do conhecimento consolidado
em um meio acessível, como a Internet (e o acesso a suas facilidades inerentes) faz-se
necessária.
3
Este trabalho, viabilizado pelo laboratório de Bioinformática do CEFET-PR, é uma
colaboração ao International Outreach, no sentido de que permite a difusão do conhecimento
fornecido pelo programa a várias outras entidades oncológicas nacionais, utilizando a
telemedicina para ensino à distância, apoiada pela metodologia PBL (Problem-Based
Learning).
1.2 - OBJETIVOS
Propõe-se com este trabalho, o desenvolvimento de uma ferramenta computacional
que auxilie o coordenador do programa International Outreach no Brasil a desenvolver suas
atividades de ensino, acompanhamento, apoio e avaliação de novos cirurgiões oncológicos
por todo o país, de qualquer local onde ele se encontre, aplicando os principais conceitos da
metodologia PBL e da teledidática (ramificação da didática dedicada ao ensino à distância),
oferecendo treinamento à distância e integrando globalmente os esforços no combate ao
câncer infantil, a figura 1 demonstra o cenário a ser automatizado pela ferramenta proposta.
Neste sentido, visando facilitar as atividades dos estudantes e do coordenador, são
integradas algumas das ferramentas disponíveis para educação à distância pela internet com
um sistema móvel de captação/disponibilização de dados, que permitem aos estudantes
efetuar os registros necessários de suas atividades em uma base de dados centralizada,
podendo posteriormente utilizar estas informações para consultas entre si e o restante do
grupo. Ao orientador, é oferecida a facilidade de acessar informações atualizadas do que foi e
está sendo feito por seus alunos, podendo intervir sempre que achar conveniente.
São usados PDAs (Personal Digital Assistants) para automatizar a coleta remota de
informações dos pacientes que estão sendo tratados e dos procedimentos que são ou serão a
eles aplicados. Estas informações são então, disponibilizadas através de um banco de dados na
Internet ao restante do grupo de estudantes para uma possível discussão e ao coordenador do
programa para acompanhamento, apoio e avaliação das atividades desenvolvidas. Esta técnica
permite ainda ao coordenador intervir no tratamento ao paciente, com sugestões, ou até
mesmo, instruções de o que deve ser feito, e avaliar a curva de aprendizado dos
especializandos ao longo do tempo.
4
Discussão c/ o
restante do grupo
(opcional).
Dados do paciente, procedimentos adotados, etc.
Críticas, sugestões, procedimentos a executar,
avaliação, etc.
Coordenador do grupo
Estudante,
durante
o
atendimento ao paciente.
Discussão c/ o
restante do grupo
(opcional).
Figura 1: Cenário a ser automatizado pela ferramenta proposta
5
CAPÍTULO 2
2
EDUCAÇÃO À DISTÂNCIA
Com o crescimento explosivo da Internet, da comunicação e do reconhecimento do
potencial das redes de computadores em atuar na globalização e fornecimento de informação
para pacientes e profissionais da Saúde, o interesse na informática e a sua influência na
sociedade cresceram de forma acentuada. Assim, a reflexão sobre o impacto da utilização dos
computadores na atuação dos profissionais da Saúde impõe uma reanálise dos tópicos
presentes no contexto diário desses profissionais. A formação desses profissionais é uma
questão a ser refletida e a adequada incorporação das novas tecnologias computacionais na
sua vida prática é um dos enfoques dos pesquisadores em Informática na Saúde e Engenharia
Biomédica.
2.1 - HISTÓRICO DA EDUCAÇÃO À DISTÂNCIA
A educação à distância (EAD) tem uma longa história de sucessos e fracassos
(KEEGAN, 1991). Sua origem está nas experiências de educação por correspondência
iniciadas no final do século XVIII e com largo desenvolvimento a partir de meados do século
XIX (chegando atualmente a utilizar várias mídias, desde o material impresso a simuladores
on-line com grande interação entre o aluno e o centro produtor, quer fazendo uso de
inteligência artificial, ou mesmo de comunicação síncrona entre professores e alunos).
Hoje, mais de 80 países, nos cinco continentes, adotam a educação à distância em
todos os níveis de ensino, em programas formais e não formais, atendendo a milhões de
estudantes. A educação à distância tem sido usada para treinamento e aperfeiçoamento de
professores em serviço. Programas não formais de ensino têm sido largamente utilizados para
adultos nas áreas da saúde, tanto pela iniciativa privada quanto pela governamental. No
momento, é crescente o número de instituições e empresas que desenvolvem programas de
treinamento de recursos humanos através da modalidade da educação à distância. As
universidades européias à distância têm incorporado em seu desenvolvimento histórico as
novas tecnologias de informática e de telecomunicações. Um exemplo foi o desenvolvimento
da Universidade à Distância de Hagen (Alemanha), que iniciou seu programa com material
6
escrito em 1975. Atualmente, oferece material didático em áudio e videocassetes, videotexto
interativo e videoconferências. Tendências similares podem ser observadas nas universidades
abertas da Inglaterra, da Holanda e na Espanha.
No Brasil, desde a fundação do Instituto RádioMonitor, em 1939 e depois do Instituto
Universal Brasileiro, em 1941, várias experiências foram iniciadas e levadas a termo com
relativo
sucesso
(GUARANYS
e
CASTRO,
1979).
As
experiências
brasileiras,
governamentais e privadas foram muitas e representaram, nas últimas décadas, a mobilização
de grandes contingentes de recursos. Os resultados do passado não foram suficientes para
gerar um processo de aceitação governamental e social da modalidade de educação a distância
no Brasil, entretanto, a realidade brasileira já mudou e o governo criou leis e estabeleceu
normas para a modalidade de educação à distância neste país.
2.2 - REGULAMENTAÇÃO DA EAD NO BRASIL
A Educação a Distância no Brasil foi normatizada pela Lei de Diretrizes e Bases da
Educação Nacional (Lei 9394/96 de 20/12/1996), em 10/02/1998, através do decreto 2494/98.
De acordo com o Art. 2º do Decreto n.º 2494/98, "os cursos a distância que conferem
certificado ou diploma de conclusão do ensino fundamental para jovens e adultos, do ensino
médio, da educação profissional e de graduação serão oferecidos por instituições públicas ou
privadas especificamente credenciadas para esse fim (...)".
Assim, as propostas de cursos nestes níveis deverão ser encaminhadas ao órgão do
sistema municipal ou estadual responsável pelo credenciamento de instituições e autorização
de cursos – a menos que se trate de instituição vinculada ao sistema federal de ensino,
quando, então, o credenciamento deverá ser feito pelo Ministério da Educação e do Desporto
(MEC).
No caso de cursos de graduação e educação profissional em nível tecnológico, a
instituição interessada deve credenciar-se junto ao MEC, solicitando, para isto, a autorização
para cada curso que pretenda oferecer.
Os programas de mestrado e doutorado na modalidade à distância, no Brasil, ainda são
objeto de regulamentação específica. Os cursos de pós-graduação lato sensu, chamados de
"especialização", até recentemente eram considerados livres, ou seja, independentes de
autorização para funcionamento por parte do MEC. Porém, com o Parecer n.º 908/98
(aprovado em 02/12/98) e a Resolução nº 3 (de 05/10/99) da Câmara de Educação Superior do
7
Conselho Nacional de Educação que fixam condições de validade dos certificados de cursos
presenciais de especialização, tornou-se necessária a regulamentação de tais cursos na
modalidade a distância.
2.3 - FUNDAMENTOS
Diversos pesquisadores têm procurado definir o que é a Educação à Distância (EAD),
a seguir são apresentadas algumas destas definições:
(KEEGAN et al., 1991):
Educação à distância é uma forma sistematicamente organizada de autoestudo onde o
aluno se instrui a partir do material de estudo que lhe é apresentado, o acompanhamento e a
supervisão do sucesso do estudante são levados a cabo por um grupo de professores. Isto é
possível através da aplicação de meios de comunicação capazes de vencer longas distâncias.
Ou ainda:
Educação/ensino à distância é um método racional de partilhar conhecimento,
habilidades e atitudes, através da aplicação da divisão do trabalho e de princípios
organizacionais, tanto quanto pelo uso extensivo de meios de comunicação. A reprodução de
materiais técnicos de alta qualidade é o seu principal propósito, os quais tornam possível
instruir um grande número de estudantes ao mesmo tempo, enquanto esses materiais durarem.
É uma forma industrializada de ensinar e aprender.
Segundo Moore e Kearsley (1996), ensino à distância pode ser definido como a
família de métodos instrucionais onde as ações dos professores são executadas à parte das
ações dos alunos, incluindo aquelas situações continuadas que podem ser feitas na presença
dos estudantes. Porém, a comunicação entre o professor e o aluno deve ser facilitada por
meios impressos, eletrônicos, mecânicos ou outros.
Keegan (1991) resume os elementos centrais dos conceitos anteriormente citados:
•
separação física entre professor e aluno, que a distingue do ensino presencial;
•
influência da organização educacional (planejamento, sistematização, plano,
organização dirigida etc.), que a diferencia da educação individual;
•
utilização de meios técnicos de comunicação para unir o professor ao aluno e
transmitir os conteúdos educativos;
8
•
previsão de uma comunicação de mão dupla, onde o estudante se beneficia de um
diálogo e da possibilidade de iniciativas de dupla via;
•
possibilidade de encontros ocasionais com propósitos didáticos e de socialização.
De acordo com Chaves (1999), a EaD, no sentido fundamental da expressão, é o
ensino que ocorre quando o professor e o aluno estão separados (no tempo ou no espaço). No
sentido que a expressão assume hoje, enfatiza-se mais a distância no espaço e se propõe que
ela seja contornada através do uso de tecnologias de telecomunicação e de transmissão de
dados, voz e imagens (incluindo dinâmicas, isto é, televisão ou vídeo). Não é preciso ressaltar
que todas essas tecnologias, hoje, convergem para o computador.
2.3.1 - Telemedicina
Define-se como telemedicina a utilização de recursos de informática e telemática
(redes de computadores conectados por meios de telecomunicação) para a transmissão remota
de dados médicos e para o controle de equipamentos biomédicos à distância.
A telemedicina é uma inovação considerável que promete, por si só, revolucionar a
prática médica no futuro. Ela já é uma realidade presente em numerosas áreas de
especialização na assistência à saúde em diversos países, consistindo ainda em novidade para
outros, como o Brasil.
A telemedicina se iniciou praticamente com as primeiras aplicações na exploração
espacial pelos americanos (missão Mercury), entre 1960 e 1964, através da telemetria
fisiológica, ou seja, o envio de dados contínuos de monitoração dos astronautas em órbita.
Estas aplicações sugeriram que a telemedicina podia tornar-se uma importante área no campo
da saúde, o que logo começou a ocorrer no setor civil, em diversos países, tais como
Inglaterra, Itália, Canadá, Suécia e Japão, já na década de 70. Mais recentemente, com a
gigantesca expansão das redes telemáticas em todo o mundo, como Internet e Bitnet, com o
desenvolvimento acelerado dos sistemas de telecomunicação digital de alta velocidade (redes
de fibras ópticas) e com a queda do preço de microcomputadores e estações de trabalho de
alto desempenho, acelerou-se e facilitou-se o desenvolvimento de sistemas de telemedicina
em todo o mundo (MACERATINI e SABBATINI, 1994).
As aplicações da telemedicina podem ser classificadas em cinco tipos fundamentais:
9
•
Telediagnóstico – envio remoto de dados de sinais e imagens médicas ou dados
laboratoriais, para finalidades de diagnóstico;
•
Telemonitoração – acompanhamento de pacientes à distância, monitorando
parâmetros vitais e proporcionando serviços automáticos e semi-automáticos de
vigilância e alarme;
•
Teleterapia – controle de equipamentos à distância, tais como hemodialisadores;
•
Telefonia social – aplicações dos modernos recursos de telefonia convencional à
assistência dinâmica, telecomunicação para pessoas deficiente (como surdos, cegos
e mudos), apoio à medicina preventiva, e suporte a pessoas idosas (telesocorro);
•
Teledidática – aplicação das redes telemáticas na implementação de cursos
médicos à distância.
A Telemedicina sempre se desenvolveu à medida que a tecnologia se desenvolvia
juntamente com o aperfeiçoamento dos meios de comunicação. Inicialmente, se utilizava
meios analógicos, mas foram suplantados progressivamente por técnicas de comunicação
mais modernas através de meios digitais sendo apenas possível após o desenvolvimento
acentuado da eletrônica.
O primeiro relato conhecido de telemedicina ocorreu na Europa durante as grandes
pragas que assolavam o continente durante a idade média, em que por causa dos riscos de
contaminação um médico se posicionou na beira de um rio enquanto um agente comunitário
se posicionou na outra beira do rio, comunicando através da voz, o agente descrevia ao
médico os sintomas e a evolução da doença que assolava a cidade.
Carta - este provavelmente foi o primeiro meio de comunicação utilizando a escrita
para prática da medicina à longas distâncias, sendo realizado principalmente entre os próprios
médicos para troca de experiências e relatos de casos assim como informações e notícias
sobre epidemias sendo que a sua origem remonta na própria origem do papel no Egito antigo
onde já seriam escritos com hieróglifos os processos de mumificação.
Telégrafo - (sinais através de fios) começou nos meados do século XIX e era usado
para medicina à distância. Por exemplo, o laudo de um raio-x pode ser transmitido através de
telégrafos. Em um famoso episódio o telégrafo foi utilizado para instruir um carteiro em como
fazer uma incisão perineal e subseqüentemente uma colecistomia suprapúbica em um
paciente com sério trauma pélvico localizado em uma região de difícil acesso ao noroeste da
Austrália.
10
Telefone - tem sido usado como meio de comunicação de voz no trabalho médico
desde a sua invenção no final do século XIX e ainda é largamente utilizado para esse
propósito nos dias de hoje. Outra utilização do telefone comum é a criação de redes baseadas
em linhas telefônicas para transmissão de dados como o Eletrocardiograma (ECGs) utilizando
um modem de computador e/ou uma máquina de fax já foi usado em casos de emergência na
zona rural. Atualmente, as informações médicas são largamente utilizadas utilizando para
tanto redes de comunicação global como a Internet.
Radio - comunicação através de rádio foi possível em meados do final do século XIX
primeiramente através do código morse e posteriormente através da voz. Durante a 2º guerra
mundial, nos anos de 1946 o rádio foi utilizado para conectar médicos em estações costeiras
ou frentes de batalha, com hospitais de retaguarda ou navios em busca de apoio e informações
logísticas.
Televisão e monitores – os sistemas de circuito fechado foram usados em 1950 em
consultas entre especialistas e pacientes no Instituto de Psiquiatria em Nebraska. Também foi
usado para avaliação médica de viajantes no aeroporto internacional de Boston por médicos
situados no hospital. Posteriormente, veio o desenvolvimento de tecnologias de
videoconferência. Atualmente, com a queda dos custos muitos dos equipamentos de
comunicação são baseados atualmente em Personal Computers (PCs)
Comunicação sem-fio (Wireless) - O desenvolvimento dos telefones celulares e
pesquisas atuais sobre transmissão de vídeo de imagens de ambulâncias assim como um
eletrocardiograma de emergência através da telefonia celular. Comunicação sem-fio inclui
também o uso de satélites de comunicação, sendo que nas primeiras implementações de
telemedicina, no terceiro mundo, foi utilizada a internet via sistema de satélites de baixo
custo.
Nos anos 60 ocorreram as primeiras aplicações com o uso de vídeo, e o grande
impulso ocorreu com o advento dos vôos espaciais, com os experimentos da NASA, com
envio de sinais fisiológicos dos Astronautas em órbita para os centros espaciais da Terra
(HISTÓRIA DA TELEMEDICINA, 2002).
11
2.3.2 - Telemedicina e Educação à Distância
Com a Internet, novos paradigmas têm aparecido, e suas surpreendentes possibilidades
estão capturando a imaginação e interesse de educadores ao redor do mundo, levando-os a
repensar a natureza do ensino e aprendizagem médica. Somente recentemente, educadores
começaram a desafiar a adequação deste modelo para a aprendizagem e a entender quais são
as bases tecnológicas necessárias para implementar o ensino à distância.
Existem duas grandes vertentes para as diferentes tecnologias de ensino à distância,
que dizem respeito ao parâmetro "tempo" no processo de ensino e aprendizado:
•
Tecnologias assíncronas: são aquelas nas quais o estudante e o professor não
interagem em tempo real. Um bom exemplo é um show de slides, desenvolvido em
PowerPoint e colocado na Internet, com ou sem a voz e a imagem do professor. O
aluno assiste quando quiser, e não necessita da presença do professor. O correio
eletrônico é outro exemplo, e este é interativo: o aluno faz e responde perguntas,
envia dúvidas, recebe textos, envia trabalhos, enfim, interage com o professor. No
ensino à distância existe um predomínio das tecnologias assíncronas, pois elas
permitem que o aluno progrida ao seu próprio ritmo, e recorra ao professor
somente quando necessário. Além disso, permite o ensino em massa.
•
Tecnologias síncronas: neste caso ocorre uma interação em tempo real entre o
professor e o aluno. As salas de chat (bate-papo eletrônico) e as videoconferências
interativas são bons exemplos. São tecnologias mais complexas, e que limitam o
aluno e o professor, tanto no tempo (têm data e hora marcada), quanto no tamanho
da classe possível.
Um curso à distância ministrado pela internet pode usar muitas das funções
disponíveis, como correio eletrônico, FTP (File Transfer Protocol), chat, vídeo e áudio, etc.
Normalmente, ele é implementado na forma de um conjunto de páginas de hipertexto (textos
vinculados a outras páginas), conforme demonstra a figura 2, disponíveis na World Wide Web,
as quais dão acesso à sua estrutura e seqüência.
12
Figura 2: home page (http://www.cbmi.upmc.edu/) para um curso virtual de
neurobiologia
A implementação na WWW também tem a vantagem de dar acesso estruturado a
recursos de multimídia. O curso deve ser dividido idealmente em módulos interdependentes,
pois isso facilita o estudo. Cada módulo tem um conjunto de recursos on-line, tais como
artigos, anotações de aula, revistas eletrônicas e livros multimídia, listas de sites da web, show
de slides (com e sem narração), videoclips, softwares para download, simulações clínicas
interativas e questionários interativos, a figura 3 exibe um exemplo de transmissão de vídeo
pela internet.
Figura 3: Transmissão de vídeos em RealVideo através da internet
13
Além disso, a home-page deve conter um conjunto de objetivos gerais e educacionais,
uma lista das avaliações obrigatórias e eletivas e uma descrição das atividades e recursos as
quais é recomendável ao aprendiz acessar, enquanto ele estiver estudando o módulo. Uma
lista dos professores e alunos, com links de acesso às suas home pages pessoais e endereços
de email completam o elenco de informações gerais sobre o curso. A interação com os tutores,
pode ser fornecida de forma assíncrona, via links de correio eletrônico e uma lista de
discussão; e uma interface de uma sala virtual interativa baseada na web, onde as atividades
sincrônicas podem ocorrer, a figura 4 exemplifica estes recursos .
Figura 4: Classe virtual interativa (http:ils.paho.org) usando o NetMeeting.
O controle acadêmico pode ser realizado de diversas maneiras. Seu objetivo é aferir o
aproveitamento do aluno, controlar as suas obrigações (entrega de trabalhos, conclusão dos
módulos, freqüência nos chats, etc.) e geralmente é implementado através de programas,
colocados no servidor onde está sediado o curso. Os estudantes podem ter acesso protegido
por senha, e o programa de controle acadêmico mantém uma base de dados com todos os
dados do progresso dos aprendizes e da avaliação, notas, etc. Os módulos podem ser
organizados de acordo com uma árvore de precedência e a transição de um módulo a outro é
permitida automaticamente (ou não), de acordo com os seus pré-requisitos. A figura 5
apresenta um exemplo de questionário de avaliação.
14
Figura 5: Questionário interativo de avaliação na Internet (www.nib.unicamp.br).
Atualmente existem na internet centenas de aplicativos que permitem a criação e
gerenciamento de cursos pela WWW: editores de páginas em HTML, programas gráficos,
módulos de chat, grupos de notícias, questionários interativos e listas de discussão, programas
de conversão de áudio e vídeo, etc (McCORMACK e JONES, 1997).
Entretanto, embora as características técnicas e abordagens educacionais utilizadas nos
cursos à distância através da Internet possam ser consideradas apropriadas e efetivas para
fornecer aprendizagem centrada no estudante, particularmente quando existem dificuldades de
oferecer este curso a uma audiência ampla e geograficamente dispersa, toda investigação
sobre as possibilidades de interação entre as áreas da Educação e da Informática, conhecida
no Brasil como Informática na Educação1 precisa ser contextualizada dentro de um momento
1
Outras denominações também são usadas como sinônimo. Por exemplo, “Informática Educativa”, “Informática
Aplicada à Educação” e “Tecnologia Educacional”. A Sociedade Brasileira de Computação adota a expressão
“Informática na Educação”.
15
histórico. É impossível compreender adequadamente como a Informática pode auxiliar a
Educação sem definir, antes, de que Educação se está tratando.
2.3.3 - O Problema do uso da Informática no ensino à distância
Com o crescimento explosivo da Internet, da comunicação e do reconhecimento do
potencial desta rede em atuar na formação de cursos à distância, o interesse nos computadores
e a sua influência na sociedade cresceram de forma acentuada. Assim, é prudente refletir
sobre o impacto da utilização dos computadores na educação e repensar nos tópicos presentes
no contexto diário dos profissionais desta área. A adequada incorporação das novas
tecnologias computacionais no ensino é uma das principais questões a ser considerada em
qualquer programa de EAD, principalmente na questão de o que o aluno entende por
educação e o que ele espera que estas novas tecnologias facilitem o seu aprendizado.
Segundo Komosinski (KOMOSINSKI, 2000), o “problema” é que não existe uma
Teoria da Educação única, monolítica. Gadotti (GADOTTI, 1995) fala em diferentes
“pensamentos pedagógicos”, Aranha (ARANHA, 1996) em diferentes “concepções de
educação” e Cambi (CAMBI, 1999) em diferentes “idéias pedagógicas”. Todos esses conceitos
(ou transformações) surgidos ao longo da história da humanidade, não ocorreram pela
“vontade do acaso”, nem foram gerados e implantados “artificialmente” por teóricos da área.
Ao contrário, a história da pedagogia (ou história da educação como defende Cambi) sempre
esteve (e ainda está) intrinsecamente ligada à história da civilização.
Se as afirmações anteriores são triviais para uma pessoa com conhecimento e/ou
formação em Ciências Humanas, o mesmo não se pode dizer para aqueles com conhecimento
e/ou formação exclusivos em Ciências Exatas. Para esta última, o conhecimento correto e
pertinente para sustentar, do ponto de vista conceitual, a introdução de tecnologias na
educação deriva, muitas vezes, de crenças e valores obtidos na sua vivência pessoal (como
estudante e professor) e, na melhor das hipóteses, da sua análise pontual (não histórica) da
realidade. Talvez isto aconteça porque os ritmos das transformações na Informática e na
Educação sejam totalmente diferentes. Há, por conta disso, uma ingênua convicção de
neutralidade das diversas tecnologias.
Um exemplo bastante concreto e atual sobre os perigos da inserção aparentemente
neutra e acrítica da tecnologia é o caso da educação à distância. Com o advento da Internet,
16
abriu-se a possibilidade técnica de disponibilizar disciplinas e cursos inteiros que estão a
disposição do estudante vinte e quatro horas por dia, sete dias por semana. Vende-se então,
muitas vezes literalmente, a idéia que o processo educativo é totalmente individualizado, onde
o estudante define o seu ritmo de aprendizagem, segundo os seus interesses. Em outras
palavras, o estudante é livre para gerenciar totalmente a forma como irá envolver-se com a
disciplina ou curso. Merkle (MERKLE, 2000) caracteriza bem a ingenuidade daqueles que
acreditam que a tecnologia por si só garantiria a qualidade superior desta modalidade de
educação, citando diversos problemas que podem ocorrer quando se juntam as ciências
humanas às exatas, como em áreas como a “Interação Ser Humano Computador”.
A questão fundamental aqui é a afirmação de que este modelo de educação, isto é, o
ensino à distância associado à aprendizagem individualizada, seria fruto de uma possibilidade
tecnológica que antes não existia (as redes de computador, tipicamente por meio da Internet).
No entanto, Komosinski (KOMOSINSKI, 2000) estabelece uma correlação entre este modelo
e a concepção de educação conhecida por escola nova, surgida no final do século XIX. A
escola nova surgiu como um contraponto à escola tradicional que valorizava o ensino
intelectualista e livresco e centrado no professor (ARANHA, 1996). Será que todos os
defensores da educação à distância concordariam em vincular idéias pedagógicas do final
século XIX com tecnologias do final do século XX?
Na melhor das hipóteses, unir Educação e Informática sem conhecer um pouco da
história da primeira faz com que não sejam aproveitados os resultados (positivos e negativos)
de inúmeras experiências realizadas.
Uma metodologia que vem sendo aplicada com sucesso em cursos à distância que se
utilizam da informática é o PBL. Segundo (OSTWALD et al., 1993), a metodologia PBL
provou ser apropriada a cursos oferecidos a distância, oferecendo uma solução para a
dicotomia potencial que pode existir entre os aspectos acadêmicos e vocacionais de
programas de ensino.
2.3.4 - PBL (Problem-Based Learning)
Problem-Based Learning (PBL) é um método instrucional no qual os estudantes
aprendem buscando soluções a problemas do mundo real. Apesar de existirem variações, os
elementos básicos do PBL permanecem os mesmos: um problema real é apresentado;
17
trabalhando sós ou em grupos, os estudantes identificam e estudam o que eles precisam saber
a mais para encontrar uma solução; as habilidades e conhecimento adquiridos através do
estudo individualizado são aplicados ao problema, avaliados e reforçados por discussões em
grupo; as habilidades do estudante em raciocinar e aplicar o conhecimento são desafiadas; e
este aprendizado é integrado aos conhecimentos anteriores dos estudantes (O'NEIL e
WRIGHT, 1995).
Métodos de aprendizado baseados em problemas podem variar entre certas dimensões
práticas:
•
Propósito primário – PBL pode ser muito útil em um número de disciplinas e para uma
variedade de propósitos, tais como estimulação de aprendizado de conteúdo e/ou do
processo de raciocínio em uma disciplina em particular; desenvolvendo técnicas de
solução de problemas em um determinado domínio; e desenvolvendo uma apreciação e
entendimento de múltiplas perspectivas possíveis em situações da “vida real”. Outros
propósitos, tais como aprendizado cooperativo, comunicação e relacionamento
interpessoal, auto-aprendizado direcionado, e auto-avaliação também fazem parte do
propósito primário.
•
Cenário Educacional – PBL pode ser utilizado em tutoriais para pequenos grupos com um
tutor facultativo (o cenário mais comum é o utilizado nas faculdades de medicina); grupos
de aprendizado cooperativo (nenhum professor presente); ensino de métodos de casos
(grande grupo de discussão); leituras baseadas em casos; problemas baseados em
laboratório (não apenas uma tarefa passo a passo programada); e estudo independente (por
exemplo, estudo direcionado);
•
Formato do caso – Cenários de casos (ou problemas) podem variar significantemente em
tamanho e detalhes fornecidos. Apesar de casos impressos apresentarem maior facilidade
e menor custo de preparação, na medicina existe um aumento no desenvolvimento de
simulações de casos apresentados através do uso de tecnologias de vídeo e de
computadores de pacientes reais e simulados.
•
Suporte ao estudante - Existe uma grande variabilidade no suporte fornecido aos
estudantes em situações PBL. Estas variações referem-se à experiência do tutor
(experiente versus não experiente); o grau de estrutura na discussão e trabalho através dos
casos; o grau para o qual os estudantes são direcionados na identificação e perseguição
dos objetivos e/ou tarefas de aprendizado; e, se os estudantes são providos com todos os
18
recursos necessários ou precisam desenvolver técnicas de obtenção das informações
necessárias.
•
Avaliação do estudante – Estudantes são geralmente avaliados em dois estágios: durante o
processo tutorial e no fim do curso ou programa. O progresso do estudante usualmente é
avaliado por um membro do corpo docente, mas auto-avaliação e avaliação dupla também
podem tornar-se uma regra. Estudantes podem ser avaliados em termos de sua capacidade
de aquisição de conhecimento e raciocínio, aprendizado cooperativo e técnicas
interpessoais. Uma série de métodos de avaliação é empregada: de exames orais e escritos
até análise de estudos de casos. Em alguns programas, a avaliação é focada em testes de
memória ou conhecimento, enquanto outros enfatizam o teste de técnicas cognitivas de
mais alto nível, tal como a aplicação e integração do conhecimento.
Nos processos PBL, os estudantes engajam-se em atividades e interações associadas
com uma gama de resultados positivos para os quais:
•
Usam o conhecimento que já possuem para entender e estruturar novas informações;
•
São mais capazes de transferir o conhecimento adquirido em um contexto prático para
outra aplicação;
•
Aprendem a natureza multidisciplinar do conhecimento, uma vez que problemas da “vida
real” não recaem em uma única disciplina;
•
Aprendem a integrar conhecimento teórico e aplicado;
•
Desenvolvem responsabilidade por seu próprio aprendizado, bem como para assistir
outros membros do grupo no seu aprendizado;
•
Têm a oportunidade de examinar a informação a partir de diferentes perspectivas,
aumentando, portanto, a compreensão e assimilação.
•
Aprendem a avaliar os limites de seus conhecimentos, preparando-se para engajar no
aprendizado de longa duração, auto-direcionado, que serão necessários para manter a
continuidade dos seus conhecimentos e habilidades;
•
Aprendem a usar as habilidades de resolução de problemas necessárias para lidar com
situações complexas e dinâmicas, onde os algoritmos de rotina ou de reconhecimento de
padrões não são mais adequados;
•
Desenvolvem habilidades de trabalho em grupos compostos por diferentes tipos de
indivíduos;
•
Aprendem a comunicar-se claramente para diversas audiências.
19
O PBL representa uma mudança significativa da abordagem tradicional baseada em
leitura e transforma radicalmente o papel do professor que deve servir como um escritor de
casos, especialista em recursos, palestrante, monitor de laboratório, escritor de exames,
coordenador de curso e membro de comitê. Entretanto, a maneira mais freqüente e exigente
de participar no PBL envolve servir como um tutor para um grupo de estudantes. O papel do
tutor modifica-se no tempo à medida que os estudantes adquirem as habilidades e o
conhecimento necessários (KAUFMAN, 1999). As três fases do papel do tutor são:
•
Modelagem – Na fase inicial, o tutor modela o processo de raciocínio dos estudantes,
demonstrando a eles as questões que devem ser perguntadas para lidar com o problema,
garantindo que os estudantes considerem cada passo em seu raciocínio e que as questões
de aprendizado sejam geradas e registradas;
•
Treinamento – Na segunda fase, o tutor intervém com menor freqüência, auxiliando
quando o estudante pula um passo importante ou parece estar perdido;
•
Desaparecimento
–
Finalmente,
o
tutor
retira-se
progressivamente
(atuando
principalmente como uma “rede de segurança”) à medida que os estudantes tornam-se
mais habilidosos e mais responsáveis por seu próprio aprendizado.
Quando se fala em aplicação do PBL, em qualquer domínio, mas principalmente em
especializações médicas - quando o profissional já está atuando e a abrangência do programa
não mais é de nível regional, chegando algumas vezes até o nível mundial - fatalmente será
necessária a utilização de técnicas de ensino à distância. No caso do PBL aplicado ao ensino
de medicina, a telemedicina fornece várias ferramentas para este problema.
2.3.5 - PBL na medicina
O currículo médico tradicional, baseado na divisão de disciplinas e em ciclos básico,
clínico e profissionalizante, que a maioria das escolas médicas adota, surgiu na década de 20,
nos Estados Unidos, proposto pela Comissão Flexner. Esta Comissão fora encarregada de
verificar quais escolas médicas atuantes naquele país no início do século poderiam continuar
seus trabalhos. Como resultado a comissão propôs que um currículo médico deveria constar
de alguns anos de aprendizado de ciências ditas básicas da medicina, tais como a anatomia, a
fisiologia, a histologia, a anatomia patológica e a bioquímica, alguns anos de formação clínica
e que as escolas deveriam dispor de um hospital para estágio dos alunos. Naquela época não
20
havia a residência obrigatória, tal como existe hoje. Daquela época em diante modificações
extremamente importantes ocorreram na medicina, com poucas alterações na estrutura do
currículo. A modificação mais importante foi, sem dúvida, a incorporação da residência
médica, primeiro de um ano, geralmente de 2 anos nas últimas duas décadas. As disciplinas
pré-residência ficaram comprimidas nos primeiros 4 anos do curso e continuaram aumentando
seus conteúdos.
Deve-se, ainda, levar em consideração o seguinte: parte do que era ensinado no curso
médico, naquela época, é hoje ensinado no curso secundário; as ciências básicas aumentaram
em número e em volume de conhecimentos (algumas ciências básicas daquela época eram
rudimentares em relação às atuais, tais como a genética, a imunologia, a bacteriologia, a
bioquímica, para citar algumas), as disciplinas clínicas se multiplicaram por inúmeras
especialidades e o conhecimento aumentou em progressão geométrica e hoje assume
características explosivas.
O número de publicações e os meios de divulgação de conhecimentos acompanhou
este crescimento. O resultado foi uma compressão absurda de informações nos quatro
primeiros anos de curso, com sobrecarga do cognitivo e pulverização do conhecimento. Dois
dos principais problemas deste método hoje clássico são a falta de integração entre as
disciplinas, principalmente entre as do ciclo básico e as do ciclo clínico e a excessiva
autonomia do docente frente à sua disciplina. As formas de controle desta autonomia, através
das ementas e programas aprovados pelos órgãos colegiados, raramente conseguem impedir
que os docentes incorporem, a cada ano, mais conteúdo, de forma indisciplinada e
relativamente anárquica. As avaliações, acompanhando estes problemas, são muito
freqüentes, geralmente restritas à esfera cognitiva, coordenadas apenas pelo docente que as
faz, segundo seu critério de importância.
Desde a década de 50 currículos alternativos têm sido propostos para controlar estes
males, geralmente com pouco sucesso e vida mais ou menos efêmera. Há, hoje, um consenso
entre os educadores que o aprendizado deveria ser mais centrado no aluno, que deveria dispor
de mais carga horária para atividades de pesquisa e de estudo.
A partir da década de 70 uma melhoria do conhecimento da psicologia do aprendizado
do adulto tem surgido, mostrando a importância de sua participação ativa na incorporação do
conhecimento, a importância de sua experiência prévia e do uso desta experiência como
elemento motivador para o aprendizado. A fisiologia da memória e seu desenvolvimento
21
recente, favoreceu também a compreensão da importância da experiência prévia na aquisição
de novos conhecimentos.
O PBL se desenvolveu dentro deste contexto e tem acompanhado suas mudanças. O
elemento central no aprendizado é o aluno. Ele é exposto a situações motivadoras nos grupos
tutoriais, onde, através dos problemas, é levado a definir objetivos de aprendizado cognitivo
sobre os temas do currículo. Estágios e atividades laboratoriais completam sua formação antes
do internato médico, que é semelhante aos das escolas que adotam o método tradicional (PBL,
2002).
Segundo Piola (2001), cresce a adesão dos cursos de medicina ao método de ensino
baseado em problemas, o PBL (Problem Based Learning). Três novos cursos de medicina que
começam a funcionar este ano adotam o novo método. São os cursos da Uniderp, em Campo
Grande, Mato Grosso do Sul, da Faculdade de Medicina do Governo do Distrito Federal, em
Brasília, e da Universidade Estadual de Santa Cruz, da Bahia. Inovadora, a experiência
acadêmica teve início no Brasil na Faculdade de Medicina de Marília (SP) e na UEL
(Universidade Estadual de Londrina), no Paraná. A Universidade Federal da Bahia e a PUCPR também já aderiram ao novo método. Estudam optar pelo PBL os cursos da Escola
Paulista de Medicina e da PUC-SP
2.4 - FERRAMENTAS DISPONÍVEIS PARA SUPORTE AO ENSINO À DISTÂNCIA
Dentre os principais serviços e ferramentas disponibilizados na Internet, tem-se alguns
que surgiram junto com a rede. Através de décadas de aperfeiçoamento, suas interfaces foram
aprimoradas, mas seu funcionamento básico continua sendo o mesmo. A seguir são mostradas
detalhadamente, segundo os conceitos disponibilizados em (WEBOPEDIA, 2001), tais
características.
Salienta-se a importância de tais ferramentas, como forma de fomento e apoio ao
ensino à distância. Uma equipe que deseje desfrutar destes benefícios deve dispor de um ou
mais grupos de tais serviços. Seus usos são os mais variados, abordando utilizações que vão
de um simples chat entre um grupo de estudantes, até uma importante reunião virtual de
todos os membro de um grupo de pesquisa. Os benefícios de tais métodos também se aplicam
a um professor que necessite estender seus métodos de ensino a alunos geograficamente
distantes.
22
2.4.1 - Telnet
É um programa de emulação de terminal para redes TCP/IP (Transmission Control
Protocol/Internet Protocol) como a Internet. Ao ser executado em um computador, o
programa Telnet faz uma conexão com um outro servidor através da rede. Por meio desta
ligação, os comandos digitados localmente serão executados como se o fossem feitos na
máquina remota, ou seja, o console do servidor. Fica-se desta forma, apto a assumir o controle
de um servidor e manter comunicação com outros servidores da rede.
Para iniciar uma sessão Telnet, deve-se obter permissão de acesso a um servidor,
através do uso de um username e password válidos - em um processo conhecido como
logon/login - onde, após a identificação ser validada, o usuário pode realizar suas tarefas ou,
em caso contrário, este não terá seu acesso permitido ao computador desejado.
Este serviço é uma das maneiras mais comuns para controlar remotamente vários
servidores, como por exemplo, web servers.
2.4.2 - FTP
O FTP (File Transfer Protocol) é um dos serviços mais clássicos disponíveis para a
transferência de arquivos pelas redes de computadores. É definido pela RFC (Request For
Comment) 959, publicada em 1985 e provê as facilidades necessárias para transferência
"para" e "de" sistemas remotos de computadores.
Normalmente, um usuário que precise transferir um arquivo necessita de certos
privilégios para obter o acesso desejado a sistemas de arquivos remotos. A facilidade,
conhecida como anonymous FTP, trabalha via um tipo especial de conta de usuário para
visitantes públicos, implementada no sistema remoto.
As conexões estabelecidas utilizam o protocolo TCP. Geralmente os servidores FTP
utilizam a porta 21 para a espera de requisições de conexão. A escolha do número de portas
para as conexões de dados depende de comandos emitidos pela conexão de controle.
Convencionalmente, o cliente envia uma mensagem de controle a qual indica o número da
porta na qual o cliente está preparado para aceitar um pedido de conexão de dados de entrada.
Quando uma transferência está sendo estabelecida, esta é sempre iniciada pelo cliente,
porém ou o cliente ou o servidor podem escolher aquele que irá enviar os dados. Assim como
23
o usuário pode transferir os arquivos desejados, o mecanismo de transferência de dados é
também usado para a transferência de listas de diretórios do servidor para o cliente.
Para fins de colaboração, um servidor FTP pode servir como repositório centralizado
de informações para um grupo de trabalho ou de estudos. Através do uso de download, é
possível obter-se dados deste servidor na forma de arquivos, ou, ao invés disso, através de um
upload é possível gravar informações nesta máquina, de forma que, sempre que necessário,
estas estejam disponíveis.
2.4.3 - E-Mail
Abrevia a descrição de Electronic Mail, que é a transmissão de mensagens através de
redes de comunicação. As mensagens podem ser notas inseridas pelo teclado ou arquivos
eletrônicos armazenados em disco. Muitos mainframes, minicomputadores e redes de
computadores possuem um sistema de e-mail. Alguns sistemas de correio eletrônico são
confinados a um único sistema de computador ou rede, mas outros possuem gateways para
outros sistemas de computadores, habilitando os usuários a enviar correio eletrônico para
qualquer lugar do mundo. Companhias que são completamente computadorizadas fazem uso
intensivo de e-mail, porque é rápido, flexível e confiável.
A maioria dos sistemas de e-mail inclui um editor de textos rudimentar, para a
composição de mensagens, mas muitos permitem que se edite as mensagens utilizando
qualquer tipo de editor. Pode-se enviar uma mensagem para um repositório pela especificação
do endereço deste. Também é possível enviar a mesma mensagem para vários usuários ao
mesmo tempo. Isto é chamado broadcasting.
As mensagens enviadas são armazenadas em caixas postais eletrônicas até que o
destinatário vá buscá-las. Para obter acesso a um correio qualquer, deve-se checar a caixa
postal eletrônica periodicamente, embora muitos sistemas emitam um alerta quando chega
uma nova correspondência. Esta, após ser lida, pode ser armazenada, respondida ou apagada.
As cópias de memorandos podem ser impressas em papel, se considerados importantes.
Todos os serviços on-line e de ISP (Internet Service Provider) oferecem e-mail, e a
maioria também suporta gateways que permitem a troca de correspondência com usuários de
outros sistemas. Usualmente, em poucos segundos ou minutos a mensagem chega a seu
destino. Esta é uma maneira particularmente efetiva de comunicação com um grupo, devido à
24
possibilidade de enviar uma mensagem ou documento através de broadcast para todos do
grupo, imediatamente.
Embora diferentes sistemas de e-mail utilizem diferentes formatos, existem alguns
padrões emergindo, que tornam possível para usuários de todos os sistemas trocar mensagens.
O CCITT (Comité Consultatif International Téléphonique et Télégraphique) desenvolveu o
padrão X.400, o qual tenta prover uma maneira universal de endereçamento de mensagens. O
padrão de endereçamento de fato utilizado é o usado pelo sistema Internet, porque quase todos
os sistemas de e-mail têm um gateway Internet.
Nos anos recentes, o uso de e-mail tem crescido. De acordo com algumas estimativas,
existem 25 milhões de usuários enviando 15 bilhões de mensagens por ano. Tais estimativas
possuem um crescimento impressionante, com tais valores sendo constantemente
incrementados (WEBOPEDIA, 2001).
Uma das aplicações importantes relacionadas à utilização do e-mail, são as listas de
discussão (mailing list), identificadas por um único nome, como [email protected].
Quando uma mensagem de e-mail é enviada para a lista, esta é automaticamente
enviada para todos os endereços desta lista.
Muitos clientes de e-mail suportam listas, as quais permitem o envio de mensagens
para grupos definidos pelo usuário. Em adição, existem servidores de listas que as
administram de forma centralizada para grupos de usuários.
Este recurso permite, a grupos que possuam relações através de assuntos de interesse,
a possibilidade de partilhar informações que somente são interessantes a esta comunidade.
Exemplos disto são as listas de discussões de assuntos técnicos ou aquelas disponibilizadas
em uma escola para um grupo específico de alunos ou para uma disciplina em particular. Para
fazer parte destes tipos de lista é necessário enviar um pedido de inscrição e, em determinados
casos, a algum processo de seleção.
2.4.4 - CHAT
Existem diversos sistemas de troca de mensagens síncronas no estilo conversação,
entre os mais populares, estão o IRC (Internet Relay Chat) e o ICQ (I Seek You).
O IRC é um sistema de conversa desenvolvido por Jarkkro Oikarinen, na Finlândia,
nos anos 80. Tem se tornado muito popular à medida que um maior número de pessoas tem
25
acesso à Internet, devido ao fato de que habilita pessoas conectadas, a partir de qualquer
lugar, a participar de discussões de forma instantânea. Além disso, não possui limite quanto a
um número máximo de conexões.
Para participar de uma discussão em um IRC é necessário um cliente IRC e acesso à
Internet. Um cliente IRC é um programa que funciona localmente e envia e recebe mensagens
"para" e "de" um servidor IRC. O servidor IRC, por sua vez, é responsável por enviar todas as
mensagens para todos os participantes de uma discussão. Pode haver muitas discussões ao
mesmo tempo, sendo que cada uma delas transita por um único canal.
É uma das ferramentas de colaboração mais simples e acessível, visto que, na maior
parte dos casos, a troca de informações baseia-se em pequenos textos enviados pelas partes
que estão conectadas a um canal. Sua utilização atende a necessidades bastante variadas,
como um departamento de uma empresa, uma aula virtual e até mesmo como meio de
descontração, pois existem canais de chat dedicados a assuntos de vão de carros e motos até a
importantes pesquisas científicas.
O ICQ é um programa de mensagens instantâneas, fácil de utilizar, desenvolvido pela
companhia Mirabilis LTD. Deve ser pronunciado em letras separadas, de forma que o som
fica parecido com "I-Seek-You", sendo similar a outros programas, como alguns da empresa
America OnLine. É utilizado como uma ferramenta de conferência por indivíduos em rede
para conversar, enviar correios eletrônicos, executar transferência de arquivos, participar de
jogos de computador, entre outros.
Uma vez instalado no computador cliente, pode-se criar listas de amigos, familiares,
associados em negócios etc., os quais também devem possuir o ICQ em seus computadores. É
através destas listas que as pessoas são achadas e notificadas quando entram ou saem da rede.
Também são permitidos o envio de mensagens, conversas em tempo real, etc.
O ICQ pode ser considerado como sendo uma forma avançada de IRC, visto que,
disponibiliza mais opções que o segundo. Tais incrementos tendem a oferecer melhor suporte
à colaboração através da Internet.
26
2.4.5 - Vídeoconferência
Uma videoconferência consiste em uma discussão em grupo ou pessoa-a-pessoa na
qual os participantes estão em locais diferentes, mas podem ver e ouvir uns aos outros como
se estivessem reunidos em um único local.
Os sistemas interpessoais de videoconferência possibilitam a comunicação em tempo
real entre grupos de pessoas, independente de suas localizações geográficas, em áudio e vídeo
simultaneamente.
Esses sistemas permitem que se trabalhe de forma cooperativa, compartilhando
informações e materiais de trabalho sem a necessidade de locomoção geográfica.
A maioria das videoconferências atuais envolve o uso de uma sala em cada localidade
geográfica, dotada de uma vídeo-câmera especial e facilidades para apresentação de
documentos.
Em alguns sistemas, simula-se uma reunião como se todos os participantes estivessem
na mesma sala, ao redor de uma mesa. Em geral, a videoconferência tradicional requer
interconexão especial através do telefone com grande largura de banda.
Com os avanços da tecnologia, proporcionando processadores mais rápidos e melhores
esquemas de compressão de dados, um novo tipo de videoconferência, a conferência desktop,
tornou-se viável. Ao contrário das videoconferências em salas especiais, exigindo
equipamentos especiais e caros, a videoconferência em desktop pode ser realizada através da
inclusão de software e hardware em computadores padrão.
Uma alternativa mais simples é a áudioconferência (MOORE, 1998), uma reunião
semelhante, mas somente com conexão de voz. Como em uma videoconferência, é necessário
algum tipo especial de gerenciamento, controle e garantia de segurança.
Segundo SANTOS (1998), o uso da videoconferência apresenta uma série de
vantagens:
•
economia de tempo, evitando o deslocamento físico para um local especial;
•
economia de recursos, com a redução dos gastos com viagens;
•
mais um recurso de pesquisa, já que a reunião pode ser gravada e disponibilizada
posteriormente.
27
Além destes aspectos, os softwares que apóiam a realização da videoconferência, em
sua maioria, permitem também, através da utilização de ferramentas de compartilhamento de
documentos:
•
Visualização e alteração de documentos pelos integrantes do diálogo em tempo
real;
•
Compartilhamento de aplicações;
•
Compartilhamento de informações (transferência de arquivos).
Os softwares de vídeo conferência mais populares são o CU-SeeMe e o Microsoft
NetMeeting.
2.4.5.1 •
CU-SeeMe
Oferece uma forma simples de videoconferência onde cada usuário conecta-se a
outros usuários em uma sessão de chat pré-combinada (WIEGLER, 1998);
•
Conecta várias pessoas diferentes de uma vez só;
•
Permite uso de recursos de áudio, vídeo, chat e compartilhamento de dados;
•
Pode ser usado na internet ou qualquer rede TCP/IP para conferências.
Uma versão gratuita deste software é disponibilizada pela Cornell University em
http://www.cu-seeme.net/squeek/cupc/cu-seemev10.zip e uma versão comercial é vendida
pela empresa WhitePine, Inc em http://www.wpine.com/.
2.4.5.2 -
Microsoft NetMeeting
•
Ferramenta para comunicação em tempo real, desenvolvido pela Microsoft;
•
Permite comunicação entre indivíduos, através da internet ou intranet;
•
Efetua transferência de áudio, vídeo e dados;
•
É gratuito (download na Microsoft em www.microsoft.com);
•
Opera com dois ou mais indivíduos em uma reunião.
Várias universidades e empresas utilizam estes produtos, visto suas flexibilidades e
praticidade de utilização. Existem, atualmente, indicativos de que o processo de Educação a
Distância, com o auxílio da videoconferência, está seguindo um caminho irreversível e, se já
não o é, brevemente será uma tendência. Exemplos disto são projetos existentes nos países da
28
América do Norte e Europa que, entre outras, visam aumentar significativamente as
velocidades das conexões de rede a fim de dar suporte ao tráfego de dados com características
de tempo real, provenientes de videoconferências com motivos educacionais.
Percebe-se cada vez mais que está utilizando-se da Internet para auxiliar e aprimorar o
ensino, esta utilização tende a aumentar ainda mais, com o advento da Internet2. A Internet2 é
uma iniciativa norte-americana, voltada para o desenvolvimento de tecnologias e aplicações
avançadas de redes Internet para a comunidade acadêmica e de pesquisa. A iniciativa envolve
mais de 180 universidades norte-americanas, além de agências do governo e indústria e visa o
desenvolvimento de novas aplicações como telemedicina, bibliotecas digitais, laboratórios
virtuais, dentre outras que não são viáveis com a tecnologia Internet atual (RNP2, 2002).
2.4.6 - FAQ
FAQ é o acrônimo de Frequently Asked Questions. FAQs são compilações de
informações, usualmente resultantes de questões que são constantemente perguntadas e
respondidas em um grupo de discussão. Os membros do grupo de discussão têm acesso às
perguntas e respostas da FAQ e as utilizam para adquirirem conhecimento a respeito de um
determinado assunto, através das informações que estão sendo compartilhadas. Algumas
vezes uma FAQ é compilada como o resultado de pesquisa extensiva em um assunto
específico. Antes de se elaborar uma pergunta para o grupo de discussões, deve-se procurar na
lista de FAQs por uma questão semelhante que possa esclarecer a dúvida. Se a resposta para o
problema não for encontrada, pode-se postar a pergunta para o restante do grupo onde as
pessoas que tiverem conhecimento do assunto a responderão.
2.4.7 - WWW
É uma definição ampla, que pode ser resumida como sendo um sistema de servidores
Internet, que suportam especialmente documentos formatados. Estes documentos são
formatados em uma linguagem chamada HTML (Hiper Text Modeling Language), que
suporta referências para outros documentos, que podem ser arquivos gráficos, de áudio e
vídeo. Isto permite a navegação de um documento a outro através dos chamados links
selecionáveis. Não são todos os servidores Internet que fazem parte da World Wide Web.
29
As aplicações chamadas web browsers facilitam o acesso através da rede WWW. Dois
dos mais populares navegadores são o Netscape Navigator e o Microsoft Internet Explorer
(WEBOPEDIA, 2001). Geralmente, as aplicações para groupware (classe de software que
auxilia um grupo de usuários em uma mesma rede a organizar suas atividades) e EAD
utilizam a WWW como meio para a troca de informações, visto esta oferecer baixos custos e
multimídia.
2.5 - A NECESSIDADE DE GERENCIAMENTO DAS INFORMAÇÕES DISCUTIDAS
Todas estas ferramentas anteriormente mencionadas podem ser amplamente utilizadas
para apoio ao Ensino à Distância. No entanto, se forem utilizadas isoladamente, com o passar
do tempo e com o aumento das interações entre o grupo, torna-se difícil o gerenciamento e a
organização das importantes informações que surgem. Além do mais, como tais ferramentas
são de uso genérico, é comum o “re-trabalho” dos participantes, como por exemplo, a escrita
por repetidas vezes de informações básicas quanto a questionamentos e soluções de
problemas anteriormente ocorridos e já solucionados. A seguir, apresentam-se alguns
problemas, decorrentes do uso isolado das ferramentas da internet no ensino à distância.
No e-mail, alunos e professores trocam mensagens entre si, referentes às suas
atividades de ensino/aprendizado. Entretanto, estas mensagens ficam armazenadas de forma
desorganizada, isoladamente por usuário, sendo difícil a sua recuperação para futuras
consultas à medida que o número de mensagens aumenta.
Na videoconferência e no chat, alunos e professores discutem sincronamente, questões
referentes a um determinado assunto, mas estas discussões devem ser gravadas para que não
se percam quando a sessão é encerrada.
Páginas HTTP que apenas contêm textos informativos, não registram a evolução dos
alunos durante o decorrer do curso. E quando registram, não acompanham os resultados de
uma aplicação prática da matéria estudada.
Conforme o tipo de curso que está sendo ministrado, uma determinada ferramenta
pode ou não ser aplicável no ensino à distância. No caso específico deste trabalho, como o
treinamento dos alunos é feito de forma prática, existe a necessidade de um acompanhamento
das atividades que estão sendo desenvolvidas pelos alunos. Este acompanhamento envolve o
registro destas atividades, das dúvidas (questionamentos que os alunos elaboram) e das
orientações redigidas pelo coordenador. Estes dados precisam ser facilmente recuperados
30
pelos alunos, em pesquisas de casos semelhantes e pelo coordenador, para avaliação do
aprendizado de seus alunos. Como solução para isto, desenvolve-use um sistema que mescla
características de um formulário HTTP, com e-mail, onde todos os dados, referentes às
atividades de ensino, estão armazenados de forma organizada e facilmente recuperável. Por se
tratar de um ambiente onde os alunos atuam efetivamente em atividades médicas práticas,
houve a necessidade de se disponibilizar as informações em um sistema móvel, permitindo ao
aluno registrar suas atividades e consultar as orientações do coordenador no local onde estiver
efetuando o treinamento.
31
CAPÍTULO 3
3
FUNDAMENTOS TECNOLÓGICOS
3.1 - A UTILIZAÇÃO DE COMPUTADORES DE MÃO NA MEDICINA
Erros médicos podem resultar do acesso inadequado a informações apropriadas
(KOHN et al., 1999). Além disto, médicos freqüentemente encontram-se resolvendo questões
clínicas e tomando decisões que requerem pronto acesso a recursos clínicos e não-clínicos
(EBELL e BARRY, 1998). Adicionar uma determinada medicação produzirá uma interação
droga-droga? Como se ajusta esta dosagem de medicação baseada na função renal do
paciente? Como se deve agendar as consultas com o paciente, dada a disponibilidade do
médico?
Possuir a informação prontamente disponível no ponto de tratamento pode ser
extremamente útil, em vista da crescente quantidade de informações médicas disponíveis, do
aumento das expectativas, para seguir guias e restrições de formulários, e das limitações de
tempo colocadas sobre os médicos. Computadores de mão podem melhorar a eficiência. A
disponibilização de dados prévios sugere que também pode-se ajudar a evitar erros médicos e
alcançar melhores resultados com o paciente (ROTHSCHILD et al., 2000).
Conhecidos como Handhelds, palm-tops ou PDAs, computadores pocket-sized estão
se tornando comuns na área médica. À medida que a tecnologia evolui, mais aplicativos
tornam-se disponíveis. Também, as demandas da prática médica aumentam dia-a-dia e os
médicos estão reconhecendo os benefícios de dispor de informações no ponto do atendimento
(EMBI, 2001).
Médicos podem usar PDAs para acessar informações de referência, fazer cálculos
médicos, melhorar o agendamento e as consultas e acompanhar os dados do paciente, tudo no
ponto de atendimento. A tabela 1 demonstra algumas aplicações para PDAs, desenvolvidas
para estas finalidades.
Atualmente, os PDAs possuem várias limitações, incluindo o pequeno tamanho da
tela, entrada de dados lenta, memória limitada e poucas características de segurança para
proteger dados sensíveis. Porém, os PDAs poderão tornar-se ferramentas vitais na prática da
medicina, já que estão ajudando os clínicos a efetuar o atendimento de forma mais eficiente e
32
talvez até a fornecer melhores cuidados ao paciente. Se as tendências atuais continuarem, eles
tornar-se-ão, na prática médica, portais de acesso wireless para sistemas de registros médicos
de pacientes, fornecendo recursos para a prática de medicina baseada em evidência e
ferramentas para agrupar e gerenciar dados no atendimento ao paciente, consultas e pesquisa
clínica (DUNCAN e SHABOT, 2000a; 2000b; LAPINSKY et al., 2000; SHABOT et al.,
2000).
PDAs têm sido utilizados na medicina desde o final dos anos 80. Os primeiros
modelos, como o Apple Newton Message Pad podia fazer muitas coisas e parecia promissor,
mas seu tamanho relativamente grande, curta vida da bateria, e reconhecimento de escrita
pobre levaram a um declínio de sua popularidade na medicina e foi logo descontinuado.
Na metade dos anos 90 houve a introdução de outros PDAs que, desde então,
tornaram-se os principais concorrentes deste mercado. Dispositivos tais como o Palm Pilot
(lançado em 1996) resolveu muitos dos problemas que condenaram os modelos antigos.
Sendo menores, mais baratos e mais fáceis de usar e possuindo um vida de bateria
significativamente mais longa, estes dispositivos foram rapidamente adotados pelos
profissionais que atuam em campo, incluindo alguns médicos. Hoje, escolas médicas,
programas de residência, grupos de médicos e sistemas de saúde estão vendo o benefício
potencial destes dispositivos para melhorar a educação e a prática dos cuidados médicos e
estão investindo no conceito. (HO et al., 2000; BASS, 2000; WOFFORD et al., 1998)
33
Tabela 1: Exemplos de software de referência médica para PDAs
Títulos
Plataforma
Tamanho (MB)2
Custo3
REFERÊNCIAS DE DROGAS GERAIS
PalmOS
1.1
PDR 2001
PalmOS
ou 6.3
$130
(www.franklin.com)
Franklin
ou 2.1
$75
qRx
Gratuito
(www.epocrates.com)
eBookman
Physicians Drug Handbook
PalmOS
(www.handheldmed.com)
Pocket PC
Tarascon ePharmacopoeia
PalmOS
0.8
Gratuito
ou 0.9
Gratuito
(www.medscape.com)
REFERÊNCIA DE DROGAS ANTIMICROBIAIS
ABX Guide
PalmOS
(http://hopkins-abxguide.org/)
Pocket PC
5
qID
PalmOS
0.5
Gratuito
(www.epocrates.com)
3.1.1 - QRx (epocrates)
Este aplicativo é um dos mais utilizados na linha PalmOS, possui diversos recursos
para o dia a dia da medicina, possibilitando consultas rápidas e diminuindo efeitos nocivos da
terapia indiscriminada.
•
É gratuito, tem uma boa quantidade de medicamentos;
•
Possui uma função chamada Multi-Check que possibilita a verificação de
interações medicamentosas em pouco tempo;
2
•
Possui doses pediátricas;
•
Tem um resumo dos mecanismos de ação de cada droga.
Se mais que um valor for fornecido para o tamanho, o de cima representa o tamanho de memória necessário
para dispositivos PalmOS e o de baixo para Windows CE/Pocket PC.
3
Preços em Dólar americano, de acordo com informações de venda dos web sites das companhias em 07 de
janeiro de 2002
34
3.1.2 - Qid
Versão do QRx para doenças infecciosas.
3.1.3 - Physicians Drug Handbook
Contém informações sobre mais que 5.000 drogas, entretanto, não possui informações
pediátricas. O acesso aos dados é rápido e amigável, através de hyperlinks. Pode ser
executado em cartões de expansão de memória.
3.1.4 - PDR2001
Fornece importantes informações a respeito da droga consultada, tais como
informação exata da prescrição da droga. A busca pode ser pelo tipo de droga ou pelo nome
genérico. Pode-se também, comparar drogas dentro de classes tais como antihistamínicos,
antidepressivos, agentes de antireumáticos.
3.1.5 - ABX Guide
Programa com características similares ao Sanford Guide, famoso livro de
informações sobre terapia de doenças infecciosas.
Possui diversas formas de localizar a antibioticoterapia e informações sobre as drogas.
Oferece atualização mensal através da internet.
Para sua instalação é necessário o cadastro na página acima e o download de um
arquivo .exe. Após o download basta clicar duas vezes no arquivo e ele instalará o programa,
como se fosse um FTP (que possibilita a atualização dos arquivos) ao término, basta fazer o
sincronismo entre o palm e o PC.
35
3.1.6 - Tarascon
Programa distribuído pelo portal Medscape, tem a mesma intenção do epocrates, com
uma interface agradável e acesso rápido aos principais medicamentos disponíveis. Ocupa
menos espaço que o epocrates. Existe um problema para os usuários do Brasil, pois quando o
usuário se associa no Medscape com a nacionalidade brasileira, o programa não fica
disponível.
3.2 - SISTEMAS OPERACIONAIS PARA PDAS
Assim como os computadores pessoais (PCs) possuem diferentes sistemas
operacionais (p. ex., Windows® e MacOS®), também os PDAs. Desde a descontinuação do
Apple Newton, os principais concorrentes entre os PDAs são a Palm4 e a Microsoft5.
Embora dispositivos que rodam os sistemas operacionais
Microsoft Pocket-PC®
(anteriormente Windows CE®) estejam em largo uso, a maioria dos PDAs executam o Palm
Operating System (PalmOS®) (CHESSANOW, 2000). Existe significativamente mais
software médico disponível para o PalmOS® que para qualquer outro sistema operacional de
PDAs, tornando-o o atual favorito.
Naturalmente, o mercado pode mudar rapidamente e é difícil prever qual sistema
operacional permanecerá como o mais popular a longo prazo. Como qualquer aquisição de
computador, durante o processo de escolha, deve-se considerar as reais necessidades e avaliar
as características e softwares disponíveis para os diversos modelos. A tabela 2 demonstra
algumas destas características.
4
5
www.palmos.com
www.microsoft.com
36
Tabela 2: Comparação entre os computadores de mão mais populares
Modelos
Memória (MB)6
Baterias7
Base Expansível
Peso Conexão c/
(OZ) Computador
8
Características9 Custo10
DISPOSITIVOS RODANDO PALMOS®
Palm (www.palm.com)
m100
2
Não
Alkaline 6–7 Serial
K
$129
m105
8
Não
Alkaline 6–7 Serial
K
$199
IIIc
8
Não
Li+ ion
6–7 Serial
C,K
$299
Vx
8
Não
Li+ ion
4
K
$299
VIIx
8
Não
Alkaline 6–7 Serial
K,W
$399
m500
8
Sim
m505
8
Sim
Lipolymer
Lipolymer
Serial
4
USB
K
$399
4
USB
C,K
$449
Visor (www.handspring.com)
Visor
2
Sim
Alkaline 5.4 USB
K,M
$169
Deluxe
8
Sim
Alkaline 5.4 USB
K,M
$199
Platinum11
8
Sim
Alkaline 5.4 USB
K,M
$299
Edge
8
Sim
Li+ ion
4.8 USB
K,M
$399
Prism
8
Sim
Li+ ion
6.9 USB
C,K,M
$449
K
$250
Handera (www.handera.com)
TRG pro
6
8
Sim
Alkaline 6
Serial
Dispositivos PalmOS® e Windows® manipulam a memória diferentemente: 8 megabytes (Mb) no PalmOS®
podem manipular a mesma quantidade de dados que 16 Mb no dispositivos Windows Pocket PC®.
7
Baterias alcalinas duram entre 20 e 30 horas. Baterias de Li + íon são recarregáveis e duram entre 6 e 7 horas
por carga; Baterias de Li-polymer são recarregáveis e duram entre 8 e 12 por carga.
8
Dispositivos PalmOS® são compatíveis tanto com computadores tipo IBM PC quanto com computadores
Macintosh (com adaptadores opcionais), porém, dispositivos Windows Pocket PC® não são compatíveis com
Macintosh. Adptadores Universal Serial Bus (USB) estão disponíveis para dispositivos seriais e vice-versa.
9
C: tela colorida; K: teclado externo opcional disponível; M: microfone built-in; W: capacidade de comunicação
wireless built-in; todos os modelos listados possuem comunicação infra-vermelho, sincronização e
reconhecimento de escrita, e possuem softwares de gerenciamento de informações pessoais (PIM) para
manipular agenda, contatos, tarefas, notas e e-mail.
10
Preços em Dólar americano, de acordo com informações de venda dos web sites das companhias em 07 de
janeiro de 2002.
11
“Platinum” possui um processador mais rápido que “Deluxe”.
37
Handera 330
8
Sim
Alkaline12 6
Serial
K,M
$350
Sony (www.sony.com)
Clié
8
Sim
Li+ ion
4.3 USB
K
$300
Color Clié
8
Sim
Li+ ion
5.6 USB
C,K
$500
6.3 Serial
K,M
$349
6.3 Serial
C,K,M
$499
DISPOSITIVOS RODANDO WINDOWS POCKET PC®
Compaq (www.compaq.com)
IPAQ 3150
32
Sim
IPAQ 3600
32
Sim
Lipolymer
Lipolymer
Casio (Cassiopeia)
E-115
32
Sim
Li+ ion
9
Serial
C
$400
E-125
32
Sim
Li+ ion
9
USB
C,M
$550
Hewlett Packard (www.hp.com/jornada)
Jornada 525
16
Sim
Li-polymer 9.1 USB
C,K,M
$359
Jornada 548
32
Sim
Li-polymer 9.1 USB
C,K,M
$449
3.2.1 - PalmOS®
O Sistema Operacional (SO) PamlOS® da Palm Inc. foi desenvolvido para controle
dos dispositivos da própria Palm. Este SO utiliza ambiente gráfico, baseado em eventos. Ele
efetua o gerenciamento de memória e sistema de arquivos, provê comunicação via rede,
modem, saída serial e infravermelho (irCOMM), permite o sincronismo com o PC (Hotsync)
o seu teclado pode ser on-screen (a imagem de um teclado aparece na tela e o usuário pode
selecionar as teclas para escrever) ou Graffiti® writing (existe uma área no dispositivo onde o
usuário escreve palavras caracter a caracter), suporta telas coloridas e permite a instalação e a
execução de novos aplicativos.
O sistema de segurança do PalmOS pode ser por bloqueio automático do dispositivo,
senha e/ou criptografia de dados.
12
Bateria de Lithium íon disponível.
38
Estão inclusas as seguintes aplicações: Agenda (Datebook), índices de endereços e
telefônico (Address), anotações (Memopad), lista de tarefas (To do List), programa para email, calculadora e sistema para controle de despesas.
O PalmOS, devido às características do dispositivo Palm, o mesmo ainda não suporta
gravação de voz e microfone. A figura 6 apresenta a interface inicial deste sistema
operacional, onde constam os ícones de acesso aos sistemas instalados no dispositivo.
Figura 6: Imagem de um Palm com sistema operacional PalmOS
3.2.2 - Windows CE® e Pocket PC®
O sistema operacional Windows® CE da Micosoft Inc. é licenciado para vários
fabricantes de computação móvel, como Cássio, HP (Hewlett Packard) e Compaq, que
criaram assim várias opções de Pocket-PC® (denominação utilizada pela Microsoft para
identificar essa linha).
Apesar da semelhança entre as funções da linha PalmOS e Windows CE, os
equipamentos com o sistema da Microsoft possuem alguns recursos adicionais, como
gravador de mensagens faladas.
A crítica feita ao Windows CE dos Pocket-PC (que na verdade é uma versão diferente
do sistema Windows CE do handheld com teclado) é a sua grande complexidade. O sistema
da Microsoft também precisa de maior quantidade de memória e sistemas mais rápidos, pois é
mais "pesado". Em função disso, é comum se encontrar na linha Palm equipamentos com
2MB e 4MB e os da linha Windows CE com 16MB ou 32MB (STOEFFLER, 2001).
A abordagem de ter muitas opções logo nas primeiras telas, indicam que o Windows
CE foi uma adaptação do Windows 95/98, conforme demonstra a figura 7, o que pode não ser
a melhor escolha para um equipamento de mão. Apesar da semelhança no nome, o sistema
Windows CE não executa programas do Windows 3.1/95/98/NT (STOEFFLER, 2001).
39
Figura 7: Imagem de um PDA HP Jornada com Windows CE
Os aplicativos que acompanham os equipamentos Pocket-PC são os do próprio
Windows CE, e mais algum adicionado pelo fabricante daquele modelo.
Programas desenvolvidos para a plataforma Palm não funcionam no Windows CE e
vice-versa. Existe, entretanto, um emulador para rodar os softwares do Palm no Windows CE,
mas o desempenho fica prejudicado. Muitos programas estão disponíveis para as duas
plataformas, entretanto.
A disponibilidades de telas coloridas, por enquanto, pode ser uma vantagem para os
dispositivos com o sistema PocketPC. Os críticos, entretanto, dizem que com isso os
equipamentos ficam pesados demais para serem práticos (STOEFFLER ,2001).
A Philips e Heverex recentemente cancelaram a produção de equipamentos com o
sistema da Microsoft.
3.3 - CARACTERÍSTICAS BÁSICAS
Computadores PDAs compartilham diversas características que os tornam bem
adequados aos profissionais que atuam em campo. Sendo pequenos e leves, são fáceis de
manipular e mais prováveis de serem levados de um lugar para outro do que um computador
do tipo laptop. Eles ligam instantaneamente, tornando-os convenientes para acessar as
informações que contêm sempre que for necessário. Todos os handhelds populares possuem
software built-in para gerenciar informações pessoais, tais como: uma agenda (calendar),
cadastro telefônico (phone book), lista de coisas a fazer (to-do list), bloco de notas (notepad) e
ainda a capacidade de trocar e-mail com o PC.
A maioria dos sistemas são controlados com uma caneta especial, denominada
“Stylus”, e possuem software de reconhecimento de escrita para entrada de texto. Com um
40
pouco de prática, a maioria das pessoas pode entrar texto de forma relativamente fácil e
precisa, embora vagarosamente. Modelos de PDAs populares não possuem teclados built-in,
mas teclados externos estão disponíveis para alguns. Muitos também oferecem a habilidade de
gravar voz, embora nenhum software de reconhecimento de voz esteja disponível para
quaisquer dispositivos até o momento. A habilidade de transferir informações através de
infravermelho a outros dispositivos permite fácil intercâmbio de informações entre PDAs.
Além disto, informações podem ser transferidas entre handhelds e PCs (de/para), um
processo denominado sincronização ou “Hotsyncing”. Embora handhelds possam certamente
ser usados independentemente, seu poder real é desencadeado quando usado em conjunto com
PCs. Através da sincronização, os dados do PDA podem ser armazenados e gerenciados no
PC, e aplicações de terceiros podem ser instaladas a partir do PC para o PDA. Modems – dos
tipos padrão e wireless – também estão disponíveis para todos os dispositivos populares,
aumentando ainda mais as maneiras pelas quais as informações podem ser agrupadas e
distribuídas.
3.4 - PROGRAMAÇÃO PARA PALMOS®
Já em 1999, os dispositivos compatíveis com a plataforma PalmOS mantinham uma
participação de aproximadamente 73% no mercado americano e mais de 50% no mercado
mundial (SABBATINI, 1999). Apesar dos esforços da Microsoft, ainda é grande a presença
destes dispositivos no mercado. Devido a este fato, focou-se os estudos nesta plataforma.
A maioria dos programadores para Palm provavelmente já escreveu uma aplicação
desktop – uma aplicação que é executada em um computador desktop tal como um PC
(Personal Computer) ou um Macintosh. Escrever aplicações para handhelds, especificamente
para dispositivos da plataforma Palm Computing, é um pouco diferente de escrever aplicações
desktop porque o dispositivo da plataforma Palm Computing é projetado de maneira diferente.
Também, usuários simplesmente interagem com o dispositivo diferentemente do que com os
computadores desktop (PALM COMPUTING INC, 2000a).
Esta seção descreve como essas diferenças afetam o projeto de uma aplicação
PalmOS.
41
3.4.1 - Tamanho da Tela
A tela do dispositivo PalmOS é apenas 160x160 pixels, portanto a quantidade de
informação que se pode exibir de uma vez é limitada.
Por essa razão, deve-se projetar a interface com o usuário com cuidado, com diferentes
prioridades e objetivos dos usados para telas comuns. Deve-se procurar um equilíbrio entre
fornecer informação suficiente e superpopular a tela. Note-se ainda, que os tamanhos das
telas de dispositivos PalmOS futuros podem variar.
3.4.2 - Rápido Tempo de Resposta Esperado
Em um PC, os usuários não se importam de aguardar alguns segundos enquanto uma
aplicação carrega, porque planejam usar a aplicação por um período de tempo estendido.
Por contraste, um usuário Palm padrão usa uma aplicação Palm de 15 a 20 vezes por
dia por períodos de tempo muito mais curtos, geralmente apenas alguns segundos.
A
velocidade é, portanto, um objetivo crítico de projeto para organizadores PDA e não é
limitada à velocidade de execução do código.
O tempo total necessário para navegar,
selecionar e executar comandos pode ter um grande impacto na eficiência geral. (Deve-se
considerar também que o PalmOS não fornece o cursor de espera.)
Para maximizar o desempenho, a interface com o usuário deve minimizar a navegação
entre janelas, abertura de caixas de diálogos e assim por diante. O layout das telas da
aplicação deve ser simples para que o usuário possa selecionar o produto e usá-lo
efetivamente após um curto período de tempo. É especialmente útil se a interface com o
usuário da aplicação for consistente com outras aplicações do dispositivo, de forma que os
usuários trabalhem com padrões familiares.
3.4.3 - Conectividade com o PC
A conectividade com o PC é um componente integrante do dispositivo da plataforma
Palm Computing. O dispositivo vem com um suporte (Craddle) que se conecta a um PC, e
42
com um software para o PC que fornece backup e sincronização one-button (ao toque de um
botão) de todos os dados no dispositivo com o PC do usuário.
Muitas aplicações PalmOS possuem uma aplicação correspondente no PC.
Para
compartilhar dados entre a aplicação do dispositivo e a aplicação no PC, é necessário escrever
um conduit. Um conduit é um plug-in para a tecnologia Hotsync, que é executado quando o
botão Hotsync é pressionado. Um conduit sincroniza dados entre a aplicação no PC e a
aplicação do dispositivo handheld.
3.4.4 - Métodos de Entrada
Usuários de PDAs normalmente não possuem teclado ou mouse (embora seja possível
conectar um teclado ao dispositivo). Os usuários inserem dados no dispositivo usando uma
caneta. Eles podem escrever através do Graffiti (área do palm destinada a escrever letras ou
símbolos, um a um, com uma caneta especial) – conforme indica a figura 8, ou da caixa de
diálogo de teclado exibida na tela do dispositivo – figura 9.
Enquanto o Graffiti (strokes) e a caixa de diálogo de teclado são maneiras úteis de
entrada de dados, não são tão convenientes quanto utilizar o PC completo com seu teclado e
mouse. Portanto, não se deve solicitar aos usuários que insiram muitos dados no dispositivo
propriamente dito.
Figura 8: Área do PDA destinada a entrada de dados (Graffiti)
43
Figura 9: Caixa de diálogo disponibilizando um teclado para facilitar a entrada de dados
3.4.5 - Memória
O dispositivo PalmOS possui espaço de pilha e espaço de armazenamento limitados.
Versões diferentes do dispositivo possuem entre 512K e 8MB de memória dinâmica e de
armazenamento. O dispositivo não possui uma unidade de disco nem suporte PCMCIA
(Personal Computer Memory Card International Association).
Devido à limitação de espaço e bateria de alimentação, a otimização é crítica. Para
tornar a aplicação tão rápida e eficiente quanto possível, otimiza-se primeiramente o espaço
de pilha, em segundo lugar, a velocidade e em terceiro, o código.
3.4.6 - Sistema de Arquivos
Ainda devido ao limitado espaço de armazenamento e, para tornar a sincronização
com o PC mais eficiente, o PalmOS não usa o sistema de arquivos tradicional. Os dados são
armazenados em pedaços de memória denominados registros, que são agrupados em bases de
dados. Uma base de dados é análoga a um arquivo. A diferença é que os dados são divididos
em múltiplos registros ao invés de serem armazenados em um espaço contíguo.
Para
economizar espaço, edita-se a base de dados na memória de armazenamento, ao invés de criála em RAM e então gravá-la para armazenar.
44
3.4.7 - Compatibilidade Backward
Diferentes versões do dispositivo da plataforma Palm Computing estão disponíveis, e
cada uma executa uma versão diferente do PalmOS.
Não é esperado que os usuários
atualizem suas versões do PalmOS tão rapidamente quanto o fariam para um sistema
operacional para PC. Atualizações do sistema operacional são projetadas de forma que se
pode facilmente manter compatibilidade backward com versões anteriores e, portanto, a
aplicação poderá estar disponível para vários usuários.
3.5 - LINGUAGENS DE PROGRAMAÇÃO PARA PALMOS
Diversas ferramentas estão disponíveis para ajudar os desenvolvedores a construir,
testar e corrigir aplicações PalmOS. A ferramenta oficial PalmOS e a mais largamente usada
é o Ambiente de Desenvolvimento Interativo (IDE) CodeWarrior13 da 3Com Corporation. A
documentação para o CodeWarrior IDE é fornecida com o CodeWarrior.
Como na maioria das aplicações, a interface do usuário está geralmente contida em um
ou mais arquivos de recursos (códigos fonte).
Para corrigir e testar a aplicação, existem diversas ferramentas disponíveis:
•
O Code Warrior Debugger manipula a correção no nível de programa fonte.
Pode-se usá-lo com uma aplicação executando no dispositivo PalmOS, ou pode-se
usá-lo em conjunto com uma das ferramentas de correção a seguir.
•
O PalmOS Emulator (POSE) testa a aplicação no computador desktop antes de
carregá-lo no dispositivo.
•
No Macintosh, pode-se construir uma versão Simulator da aplicação para testá-la.
Esta é uma aplicação stand-alone Mac OS que executa a aplicação PalmOS em um
computador Macintosh.
•
O Palm Debugger é uma ferramenta do nível assembly. Pode-se usá-la para entrar
comandos no dispositivo Palm.
Pode-se separar as ferramentas de desenvolvimento em categorias, onde os principais
termos
de
comparação
são
FLEXIBILIDADE
desenvolvimento (RHODES e McKEEHAND, 2001).
13
www.codewarrior.com
x
FACILIDADE/RAPIDEZ
de
45
Na categoria FÁCIL e RÁPIDO, porém pouco flexível, e ainda sujeito a runtime
presente no PDA, ficaram, entre outros, o Satelite Forms14, o CASL Tools15 e o Pendragon
Forms16. São ferramentas para desenvolvedores bem acostumados a desenvolver sistemas em
Delphi, Visual Basic e semelhantes.
Na categoria FLEXÍVEL, porém com uma curva lenta de aprendizado, com o prérequisito de muito conhecimento em linguagem C, estão o CodeWarrior , o GCC17 e o
FalchNet18.
Não existe "a melhor" ferramenta. Existe, sim, a ferramenta mais adequada para um
determinado projeto. Antes de se escolher, a análise do projeto, como um todo, deve ser
realizada pensando em todos os parâmetros possíveis (RHODES e McKEEHAND, 2001), tais
como tamanho e desempenho do aplicativo versus facilidade e rapidez de desenvolvimento
Normalmente os aplicativos desenvolvidos em linguagem C terão um tamanho bem
menor do que os demais. Se for bem escrito, seu desempenho poderá ser bem melhorado.
Entretanto, o desenvolvimento em C requer tempo e habilidades de programação que nem
sempre estão disponíveis. Se o programador conseguir montar uma biblioteca de funções, o
problema do tempo será reduzido. A flexibilidade da linguagem C nos dá um poder muito
grande, como, por exemplo, acessar todas as funções do PalmOS. O desenvolvedor deve estar
bem consciente desta escolha, pois o nível de dificuldade é bem maior comparado aos das
ferramentas RAD (Rapid Application Development), o que implica no fator TEMPO, que é
tão importante na hora de dimensionar o prazo de um projeto.
A tabela 3 faz um comparativo entre as ferramentas mais populares de
desenvolvimento para dispositivos PalmOS. Vale a regra: quanto maior a facilidade e rapidez
de desenvolvimento, maior a possibilidade de se ter um aplicativo superdimensionado, ou um
aplicativo não tão grande, porém sujeito a trabalhar com runtime.
14
www.pumatech.com
www.caslsoft.com
16
www.pendragon-software.com
17
www.palmos.com
18
www.falch.net
15
46
Tabela 3: Comparativo de ferramentas de programação para PDAs
Nome
Code
Preço em US$ em Possui
Flexibili- Facilidade
15/12/01
Runtime
dade
/Rapidez
R$ 850,00
---------
Grande
Lenta
LINK
www.bestcompany.co
m.br
Warrior
(11) 3666-7288 – São
Paulo
www.metrowerks.co
m
GCC (PRC Gratuito
---------
Grande
Lenta
www.PalmOS.com
Rápida
www.pda.com.br
Tools)
Satelite
Enterprise- $1240
Sim
Média/
Forms
(distrib. livre)
83 K
Grande
Enterprise+Server
Paulo
Até 10 licenças
[email protected]
$ 1450
www.pumatech.com
Pendragon $ 149 +
Forms
(11) 5068-2077 – São
Sim
Pequena
Rápida
www.Pendragonsoftware.com
Média de $ 45 p/ 166 K
licença adicional
Distribution
Toolbox $ 995
CASL
$ 64,95
Sim
Rápida
www.caslsoft.com
Pequena
Rápida
www.pdatoolbox.com
Grande
Lenta
www.falch.net
43 K
Tools
PDA
Média
US$ 25
-------
Toolbox
FalchNet
US$
149
para --------
desenvolvimento
de
aplicações
comerciais
47
3.6 - ARQUIVOS PDB
O Palm Database (PDB) é o formato padrão que o PalmOS utiliza para
armazenamento de dados, na forma de registros. Nesta sessão, serão explicados o modo como
são armazenados os dados dentro do PDB, as estruturas internas e os conceitos envolvidos na
sua utilização (PALM COMPUTING INC, 2001b).
3.6.1 - Conceitos
•
Primeiramente, não se deve confundir os arquivos que são gravados no PC, de extensão
PDB, com o formato de armazenamento de dados do PalmOS, o Palm Database (PDB).
Os arquivos gravados no PC têm esta extensão para associá-los ao gerenciador de Hotsync
do Palm (software responsável pela comunicação entre o PDA e o PC), possibilitando a
instalação dos bancos de Dados no Palm e o backup deles depois de um Hotsync. No
PalmOS, não há arquivos ou extensões. Todos os dados armazenados são gravados na
memória, através de formatos específicos para cada tipo de utilização. Até mesmo os
programas PRC (Palm Resource) são bancos de dados com um formato específico. O que
determina e diferencia o tipo do banco de dados armazenado, são as informações do
Header, indicando se aquele banco de dados é um banco de registros ou um resource.
•
Outro conceito importante a destacar é que o formato padrão dos bancos de dados é
detalhado como se fosse uma estrutura seqüencial, exatamente como são gravados os
arquivos PDB no PC, provenientes de um Hotsync. Na realidade, a forma como o PalmOS
armazena os bancos de dados na memória pode variar em função da quantidade de
memória disponível e versão do sistema operacional. Naturalmente, se for decidido gerar
um Arquivo PDB no PC com a estrutura aqui detalhada e enviá-lo ao Palm, será
perfeitamente possível, pois durante o processo do Hotsync, o PalmOS alocará os recursos
necessários para armazenar o banco de dados na memória e torná-lo disponível para as
aplicações.
•
Para quem está habituado a outras plataformas e linguagens de programação, é comum
tentar associar um banco de dados a um arquivo DBF ou Paradox. Isso não é possível no
PalmOS. O banco de dados do Palm não possui conceito de campos, índices e chave
primária (apesar de existir um identificador único do registro). O PDB é uma estrutura
48
seqüencial de registros que podem ser classificados na hora da inserção de um novo
registro ou mesmo depois, através de uma função do conjunto de bibliotecas do PalmOS.
O desenvolvedor é responsável por determinar como os dados serão gravados nos
registros e o tamanho de cada registro (porque os registros não precisam ter o mesmo
tamanho). Só como um exemplo, para classificar um arquivo, é necessária uma função
Callback, isto é, uma função provida pelo desenvolvedor, que o PalmOS chama durante
uma operação de classificação de registros.
3.6.2 - Estrutura Física
O formato PDB é composto de blocos com tamanho variável, exceto o Header que
contém sempre 72 bytes19. Cada bloco representa um conjunto de informações dentro do
banco de dados, como mostra a tabela 4.
Tabela 4: Estrutura Física do PDB
Header do banco de dados (Tamanho Fixo 72 bytes)
Lista de Entradas de Registros (Tamanho variável)
AppInfo Block (Opcional, Tamanho Variável)
SortInfo Block (Opcional, Tamanho Variável)
Entradas de Registros (Tamanho Variável)
3.6.2.1 -
Header
No Header, são gravadas informações que identificam o banco de dados no PalmOS e
estão detalhadas as localizações dos blocos de informações dentro do banco de dados. A
estrutura apresentada na tabela 5, detalha cada parte do Header, começando pela posição 1,
como o primeiro byte do bloco.
19
Alguns desenvolvedores citam que o Header do banco de dados Palm contém 78 bytes. Isso é devido à
utilização de apenas uma Record List por banco de dados. Na documentação oficial da Palm, encontra-se
detalhada a Record List da maneira que foi mostrado aqui. Por questão de flexibilidade e porque pode haver mais
de uma Record List em um banco de dados (raro, mas possível), detalhou-se o Header com 72 bytes (que são
realmente fixos dentro de um banco de dados Palm) e a estrutura da Record List separadamente.
49
Tabela 5: Estrutura do Header
Posição
Tamanho
Conteúdo
1 a 32
32
Nome genérico do banco de dados. Exemplo: "banco_generico".
Os bytes que não forem usados após o nome devem ser
preenchidos com zero. Este nome aparece na lista "info", de
bancos de dados instalados no Palm.
33 a 34
2
Flags do banco de dados. 16 bits contendo detalhes sobre
características do banco de dados no PalmOS.
0x0002 – Somente para leitura
0x0004 – AppInfoBlock modificada
0x0008 – Se marcado, o Hotsync fará o backup do banco de
dados
0x0010 – OK para instalar sobre uma cópia já existente no Palm
0x0020 – Força reset do Palm após instalar
0x0040 – Não permite envio do banco via infravermelho
(beaming)
35 a 36
2
Versão do banco de dados, informada pelo desenvolvedor.
37 a 40
4
Data de criação do banco de dados.
Observação sobre datas no PalmOS: O PalmOS armazena datas
computadas em segundos desde zero hora de 01/01/1904. No
Windows, a função time(), retorna segundos desde zero hora de
01/01/1970. Assim, para converter uma data obtida da função
time() da API do Windows para uma data do PalmOS, é
necessário acrescentar o valor fixo decimal 2082844800 ao valor
obtido de time().
41 a 44
4
Data de modificação do banco de dados. Segue a regra de datas
acima.
45 a 48
4
Data do último backup. Segue a regra de datas acima.
49 a 52
4
Número de Modificações no banco de dados.
53 a 56
4
Posição absoluta a partir do início do Header do banco de dados,
identificando a localização do AppInfo Block. Se não houver
50
AppInfo Block no arquivo, os quatro bytes são preenchidos com
zero.
57 a 60
4
Posição absoluta a partir do início do Header do banco de dados,
identificando a localização do SortInfo Block. Se não houver
SortInfo Block no arquivo, os quatro bytes são preenchidos com
Zero.
61 a 64
4
PDB Type. Quatro caracteres identificando o tipo do banco de
dados. Esta informação mais o identificador do criador do
arquivo, é a forma mais comum de abrir o banco de dados
utilizando as funções da API do PalmOS.
65 a 68
4
Creator ID. Identificador único do criador do banco de dados.
Quando se pretende criar uma aplicação e distribuí-la para outros
Palm Devices, é altamente recomendado o registro de um ID
único na Palm, pois ele identificará cada desenvolvedor nesta
plataforma. Se for utilizada qualquer identificação, poderão
ocorrer conflitos em unidades que utilizem programas de outros
desenvolvedores com o mesmo Creator ID.
69 a 72
4
Unique ID Seed. Raramente utilizado, serve para armazenar um
número de identificador único para o PDB. Somente 3 bytes são
utilizados, sendo que o quarto byte serve apenas para alinhamento
dos bytes. Normalmente contém zeros, pois não há documentação
disponível para sua utilização.
3.6.2.2 -
Lista de Entradas de Registros (Record List)
A Record List funciona como um índice seqüencial, ou relação de todos os registros
gravados no banco de dados. Contém entradas informando a posição absoluta (em bytes) dos
registros a partir do início do Header. A primeira entrada corresponde ao primeiro registro do
banco de dados, e assim por diante. Cada entrada de registro tem oito bytes. O detalhamento
se encontra na tabela 6.
51
Tabela 6: Estrutura do Record List
Posição
Tamanho
Conteúdo
1a4
4
Posição absoluta (em bytes) a partir do início do Header onde
começa a próxima Record List (Como foi dito anteriormente, é
raro, porém possível). Normalmente contém zeros.
5a6
2
Número
de
entradas
de
registros
na
Record
List
(Conseqüentemente, número de registros no banco de dados).
Observação importante: se o banco de dados estiver vazio, as
duas próximas posições (7 a 8) devem ser preenchidas com
zeros, indicando final do banco de dados.
7
8
Primeira entrada de registro com tamanho de oito bytes. Os
registros são identificados seqüencialmente a partir do primeiro
até o último.
3.6.2.3 -
Entradas de Registros
Os registros que foram apontados na Record List são colocados logo após o último
bloco de dados específicos da aplicação (AppInfo/SortInfo) se houver. Como já foi dito os
registros não tem formato, nem padrão de gravação, tamanho, etc (são conhecidos como Raw
Data). A única consistência é que a posição absoluta (em bytes) do registro dentro do PDB
seja indicada na sua entrada correspondente na Record List.
Tabela 7: Estrutura das entradas de registros
Posição
Tamanho
Conteúdo
1a4
4
Posição absoluta (em bytes) a partir do início do Header
onde começa o registro no banco de dados.
5
1
Atributos do registro (vide tabela 8).
6a8
3
Identificador
único
do
registro
(Unique
ID).
Este
identificador é estabelecido automaticamente pelo PalmOS
quando o registro é criado. É possível alterar o valor do
Unique ID, porém não há garantias que esse número seja
preservado no próximo Hotsync.
52
3.6.2.4 -
Atributos do Registro
Tabela 8: Atributos do registro
Bit
Significado
0,1,2,3 Identificam a categoria à qual o registro pertence (vide seção 3.6.2.5 sobre
categorias)
4
Registro marcado como Unique (privado)
5
Registro marcado como Busy (ocupado pelo sistema operacional)
6
Registro marcado como Dirty (modificado recentemente)
7
Registro marcado como Deleted (apagado, porém não removido ainda).
3.6.2.5 -
AppInfo Block
O AppInfo Block é uma área que pode ser utilizada dentro de um banco de dados para
guardar qualquer tipo de informação que o desenvolvedor achar necessário. Por exemplo: no
formato PDB não há definições de campos ou tipos de dados. Para suprir essa dificuldade, é
comum utilizar o AppInfo Block para gravar informações da estrutura de campos. Isso fica a
critério do desenvolvedor, não há nenhuma função do PalmOS para tal finalidade.
Outra característica do AppInfo Block é que nele é gravado o conjunto de categorias de
um banco de dados. Categorias (category data) são classificações que são aplicadas a
registros de um banco de dados. Cada registro pode ser associado a uma categoria e o PalmOS
dispõe de rotinas que permitem filtrar a busca de registros por categoria. Um exemplo típico
do uso de categorias é a aplicação Address do Palm. Nesta aplicação, é possível classificar os
registros como Business, Personal, QuickList, etc. São permitidas 16 categorias por banco de
dados, sendo que normalmente a primeira da lista é criada com o nome "unfilled", para indicar
que o registro não foi classificado em nenhuma categoria (default). A tabela 9 demonstra a
estrutura da category data dentro do appinfo block.
53
Tabela 9: Estrutura da Category Data
Posição
Tamanho
Conteúdo
1
2
16 bits indicando qual das 16 categorias foi renomeada. É um
controle para a aplicação de Hotsync que houve mudança nas
categorias.
3
256
Array de 16 strings terminadas em zero (null terminated), com 16
bytes cada string, representando o nome de cada uma das 16
categorias do banco de dados. Se forem classificadas menos do que
16 categorias, deve-se inicializar as outras com zero.
259
16
Array de 16 bytes representando o código de identificação de cada
categoria (ID). Normalmente é inicializado com valores de 1 a 16.
275
1
Último código de categoria utilizado (ID).
276
1
Um byte não utilizado (somente para alinhamento de bytes dentro
da estrutura).
O PalmOS dispõe de rotinas de inicialização da Category Data em sua API, porém, se
o desenvolvedor estiver gerando um arquivo PDB com sua própria ferramenta, deve estar
atento para gerar a estrutura das categorias na ordem correta.
Dentro do AppInfo Block, logo após o bloco de categorias, o desenvolvedor pode
colocar os dados específicos de sua aplicação.
3.6.2.6 -
SortInfo Block
O SortInfo Block é uma área dentro do PDB destinada a aplicações específicas do
desenvolvedor. Não tem formato predefinido, nem tamanho. Sua localização é dada pela
posição absoluta dentro do banco de dados, através do campo específico no Header do PDB.
A maioria das aplicações não usa o SortInfo Block e algumas publicações informam que
versões antigas do Hotsync não suportam o backup do SortInfo Block dos bancos de dados.
3.7 -
ARQUIVOS PRC E RUNTIMES
PRC é a extensão do aplicativo desenvolvido para rodar no Palm. Em linguagem
simplificada, é equivalente ao .EXE do Windows/DOS do PC.
54
Algumas ferramentas simplesmente geram um PRC, após o processo de compilação,
que é instalado diretamente no Palm através do Hotsync, evitando o uso de runtimes. Outras
ferramentas trabalham com runtime, ou seja, em modo interpretado. Geralmente o runtime é
instalado no Palm durante o processo de instalação da própria ferramenta. As aplicações são
desenvolvidas na ferramenta, que normalmente são arquivos com uma extensão nativa da
própria ferramenta e, por si só, estes arquivos não executarão no PalmOS, eles necessitam do
runtime. Nem sempre o arquivo gerado fica visível, mas o importante é que ele é transportado
para o Palm durante o próximo Hotsync, juntando-se ao runtime da ferramenta. Ao ser
executado, o runtime aciona o aplicativo, interpretando os comandos e executando-o.
3.8 - SINCRONIZAÇÃO
Acompanha todo Palm uma base para sincronismo (Craddle), que pode ser ligada a
um PC com Windows, ou Mac, e permite transferir os dados entre o Palm e o computador. O
processo é bem simples. Coloca-se o Palm na base e aperta-se o botão de sincronismo. O
Palm é ligado e os dados são atualizados.
No sincronismo o próprio sistema se encarrega de manter tanto o Palm como o PC,
atualizados com as últimas versões de todos as informações. É possível também instalar
novos programas durante esse processo.
O Palm Desktop, que acompanha o Palm, permite visualizar e alterar os dados no
computador. No sincronismo as informações alteradas são copiadas para o Palm, deixando
sempre os dois lados com a última versão dos dados. A figura 10 simula uma sincronização
entre o PDA e o PC.
Figura 10: Imagem de uma sincronização entre o PDA e o PC
55
Uma das obrigações de quem desenvolve aplicações para Palm é de transportar os
dados armazenados nele para seu sistema corporativo na retaguarda, por exemplo, no caso de
captação de pedidos por vendedores externos. O método tradicional de executar esta tarefa é
usar uma aplicação chamada Conduit, que é executada durante a operação de sincronismo
(Hotsync).
O desenvolvedor deve desenvolver esta aplicação Conduit para ser distribuída junto
com seu sistema para o Palm.
3.9 - CONDUITS
Conduits são a porta de comunicação do PalmOS com o mundo exterior. São
aplicações que rodam em um PC (rodando Windows, MacOS, Linux), e devem ser registradas
no processo de Hotsync do Palm (PALM COMPUTING INC., 2001c).
Quando o Palm é colocado na base (Craddle) e aperta-se o botão de sincronização, o
Hotsync Manager, ativo no PC, inicia várias tarefas de troca de dados com o Palm: realiza o
backup dos bancos de dados do Palm para o PC, instala novos bancos de dados e aplicações,
faz a sincronização dos dados do Address Book, Memo Pad, entre outros. Além de fazer as
sincronizações que já estão programadas em sua funcionalidade básica, ele executa outras
aplicações de Conduit, desenvolvidas externamente e registradas no sistema de Hotsync20.
Os processos de backup dos bancos de dados do Palm (PDB) e instalação de novos
bancos de dados são o exemplo mais simples de sincronização. Todos os bancos de dados
armazenados no Palm têm flags indicando se ele faz parte do processo normal do Hotsync,
isto é, da próxima vez que for executada uma sincronização, o Hotsync copiará este banco de
dados para o PC, no diretório de backup da aplicação de Hotsync.
Já o processo de sincronização do Address Book e Memo Pad, é mais elaborado. Estes
bancos de dados não têm o flag de backup marcado, portanto, não fazem parte do processo
normal de backup do Hotsync. Eis o motivo: suponha que o usuário utilizou o Palm Desktop
para incluir um novo contato no Address Book e alterou um outro contato diretamente em seu
Palm. Efeito: a aplicação de Hotsync não pode simplesmente copiar o banco de dados do
20
Dependendo da ferramenta, o desenvolvedor ficará sujeito a trabalhar com o Conduit nativo dela, ou seja, toda
a troca de dados que desejar fazer, estará sujeita às regras da ferramenta. Com isso, perde-se muita flexibilidade.
56
Palm para o PC nem do PC para o Palm. Nenhum dos bancos de dados (do PC ou do Palm)
contém a informação mais atualizada, pois parte dela está no PC e parte está no Palm. Aqui, a
funcionalidade do Conduit é vital: verificar por registros incluídos ou alterados no Palm e
sincronizá-los no PC e vice-versa. Mas, e se o mesmo registro for modificado no Palm e no
PC? Qual base de dados está mais atualizada? Não há método padrão para resolver estes
conflitos de informações. Por exemplo, o Conduit do Address Book do Palm, quando encontra
uma situação como esta, cria os dois registros em conflito no Palm e no PC, e envia uma
mensagem através do log do Hotsync, solicitando que o usuário tome uma atitude, fazendo as
correções necessárias ou apagando um dos registros, e faça a sincronização novamente.
Para aplicações desenvolvidas no PalmOS, deve-se determinar qual a forma de tratar
situações como esta. Uma solução seria colocar datas de modificação nos registros dos bancos
de dados para poder ter uma forma de comparar os registros no momento da sincronização.
Esta solução é valida para dados que normalmente não sofrem alterações nos dois lados ao
mesmo tempo. Um exemplo disso poderia ser um banco de dados de itens de pedidos:
raramente seria alterada a quantidade do item, em função de uma solicitação do cliente em seu
Palm e alguém tivesse feito outra alteração de quantidade no desktop. Como é uma
informação que não muda constantemente, a adoção de datas para controle de sincronização
de registros poderia ser cabível neste exemplo.
Hoje, as plataformas móveis e, em especial, o Palm, está se tornando um padrão para
empresas que necessitam de controles e aplicações de campo, isto é, elas têm colaboradores
que trabalham externamente, coletando pedidos, fazendo pesquisas, etc., e necessitam que
estas informações sejam atualizadas no banco de dados da empresa. Uma aplicação de
Hotsync não está limitada a trocar dados entre um desktop e o Palm. Poderia-se desenvolver
um Conduit que fizesse a sincronização de dados de um Palm diretamente para o banco de
dados rodando no Mainframe da corporação, localizado até mesmo em outro país (PALM
COMPUTING INC., 2000c).
A Palm dispõe de um software chamado Network Hotsync que faz com que um Palm
possa ser sincronizado via rede, diretamente para seu computador, onde quer que ele esteja. O
usuário pode estar na filial de empresa em que trabalha e esta filial esteja ligada em rede com
o local onde ele trabalha, na matriz da empresa. Ele pode utilizar um computador da filial para
ativar o Hotsync Manager, que está rodando em seu computador, na matriz.
57
3.10 - O SINCRONISMO DOS DADOS VIA INTERNET
O Hotsync Manager funciona apenas quando a sincronização dos dados é feita dentro
de uma rede local. Se a sincronização necessitar ser feita de pontos externos, duas soluções
podem ser implementadas. Uma delas é disponibilizar, na rede onde se encontrar o servidor
de banco de dados, um servidor de acesso remoto (RAS – Remote Access Server). Nesta
solução, os usuários, através de modems, discam para este servidor, efetuam a conexão com o
Hotsync Manager, e sincronizam seus dados. Entretanto, se os usuários estiverem localizados
em cidades diferentes e distantes, o custo das ligações telefônicas inviabiliza esta solução. A
segunda solução – e a adotada neste trabalho – efetua o sincronismo dos dados através de uma
conexão com a internet. Este tipo de solução exige o desenvolvimento de sistemas adicionais,
conforme será explicado no capítulo 4, mas reduz o custo das ligações telefônicas, uma vez
que, se for utilizada uma conexão com a internet do tipo discada para um provedor localizado
na mesma cidade que o usuário, a tarifação será apenas local. A figura 11 representa o
esquema de sincronismo de dados adotado pela ferramenta desenvolvida neste trabalho e é
explicada a seguir:
Os médicos especilizandos utilizarão os PDAs para registrarem suas atividades
durante o atendimento aos pacientes, estas atividades envolvem consultas, diagnósticos,
procedimentos cirúrgicos, implantes de cateteres e suas complicações. Adicionalmente, consta
nesta aplicação, um formulário onde o médico pode formular dúvidas a respeito de um
determinado procedimento.
Ao final do dia, o PDA será acoplado a um craddle que está conectado a um PC com
acesso à internet, neste momento inicia-se o sincronismo com a base de dados na internet. O
sincronismo inicia um conduit que será responsável pela conexão entre a base de dados do
PDA e a base de dados corporativa na internet, efetuando o controle no fluxo em duas vias
dos dados, através da tecnologia Cliente/Servidor.
Quando o coordenador do grupo sincronizar o seu PDA, ele receberá em seu
dispositivo todas atividades que foram registradas no servidor por seu alunos, inclusive os
questionamentos que eles formularam. De posse destes dados, o coordenador pode analisar os
procedimentos que estão sendo aplicados aos pacientes, efetuar sugestões, corrigir possíveis
erros e responder aos questionamentos de seus alunos. Após uma nova sincronização, todas
estas informações são registradas na base de dados na internet, as quais serão repassadas aos
respectivos alunos da próxima vez que eles fizerem o sincronismo de seus PDAs.
58
Cliente
Internet
Cliente
Figura 11: Esquema de sincronismo de dados adotado pela ferramenta em desenvolvimento
59
CAPÍTULO 4
4
IMPLEMENTAÇÃO
4.1 - INTRODUÇÃO
O programa International Outreach no Brasil tem como objetivo disseminar seus
conhecimentos no tratamento de Oncologia Pediátrica para as diversas regiões do país,
efetuando treinamento à distância para médicos que desejam se especializar nesta área. Para
tanto, o coordenador do programa necessita ter o controle dos principais procedimentos
efetuados pelos especializandos participantes do programa, no tratamento a seus pacientes nas
diversas regiões do país, a fim de poder cumprir com suas tarefas de orientação,
acompanhamento e avaliação. Para tanto foi disponibilizada uma base de dados centralizada
com informações sobre os pacientes admitidos, suas consultas, seus diagnósticos e as
cirurgias às quais foram submetidos e suas complicações. Para evitar atrasos na atualização de
todas estas informações, uma técnica de captação remota de dados, através de computação
móvel (PDA), foi implementada, permitindo aos usuários alimentar o sistema no local do
atendimento e no momento em que os fatos ocorrerem. Um sistema semelhante ao
implementado para o PDA foi desenvolvido para computadores pessoais, com a diferença
que, neste último, o usuário acessa os dados diretamente na base centralizada, através de uma
conexão com a Internet, podendo, além de incluir, alterar e excluir dados normalmente, gerar
diversos relatórios de seu interesse. Como os dados captados pelos PDAs estão em bases
locais nestes dispositivos e como a base centralizada pode ser alterada pela aplicação
disponível no computador pessoal, foi desenvolvida uma aplicação de sincronismo destas
bases de dados, de forma que as informações fossem atualizadas nas diversas pontas do
processo. Para atingir os objetivos propostos, foi necessário o desenvolvimento de cinco
camadas de software. São elas:
•
Base de dados centralizada;
•
Servidor de aplicação para prover acesso à base da dados centralizada para os
computadores pessoais executando o sistema cliente ou para o sistema de
sincronismo da dados dos PDAs;
•
Sistema de captação remota de dados executado em PDA;
60
•
Sistema de sincronismo de dados entre os PDAs e a base de dados centralizada.
•
Sistema cliente executado no computador pessoal;
4.2 - A BASE DE DADOS CENTRALIZADA
O sistema gerenciador de banco de dados (SGBD) adotado foi o Interbase®21, devido
a características tais como: facilidade de implementação, custo zero (freeware), alto
desempenho, portabilidade, conectividade com diversos protocolos de rede – entre eles o
TCP/IP, capacidade de gerenciar Terabytes de informação, entre outras.
Devido à necessidade de manter no PDA uma estrutura de dados semelhante à base de
dados centralizada e como no PDA cada tabela representa uma base de dados, obrigando o
desenvolvedor a implementar todos os relacionamentos e restrições explicitamente, o modelo
físico de dados não foi normalizado, pois buscou-se uma quantidade mínima de tabelas. O
modelo lógico de dados é mostrado na figura 12 e o dicionário de dados encontra-se no anexo
1. Os dados foram modelados de forma a facilitar a implementação dos sistemas de captação
remota no PDA e de sincronismo.
Como existe a necessidade de controlar quem é o usuário proprietário de um
determinado registro, todas as tabelas estão relacionadas com a tabela de usuário, um usuário
pode ter zero ou vários registros, um registro somente pode pertencer a um usuário.
Todas as discussões, cirurgias, diagnósticos e consultas referem-se a um determinado
paciente. Um paciente pode ter zero ou mais diagnósticos, consultas cirurgias ou discussões.
Um registro de qualquer uma destas tabelas pertence a um único paciente.
Uma cirurgia pode ter zero ou vários DAVs (dispositivos de acesso vascular), um
DAV relaciona-se a uma única cirurgia. Cada DAV pode apresentar zero ou várias
complicações, uma complicação refere-se a um único DAV.
21
www.interbase.com
61
.
Figura 12: Modelo lógico do dados
4.3 - O SERVIDOR DE APLICAÇÃO
A aplicação servidora coordena e processa as requisições das aplicações clientes
manipulando todos os detalhes de definição dos conjuntos de dados e interações com o
servidor de banco de dados.
Como tanto a aplicação servidora quanto o SGBD estão localizados remotamente aos
clientes - fora dos domínios de uma rede local, houve a necessidade de se estabelecer uma
forma de comunicação entre estas camadas. A solução adotada, devido ao seu baixo custo, foi
a internet, através do protocolo HTTP (Hiper Text Transfer Protocol).
O HTTP provê uma semântica de funcionamento parecida com o uso de RPC (Remote
Procedure Call), funcionando sobre TCP/IP. O funcionamento destas aplicações é o seguinte:
1. O cliente estabelece uma conexão com o servidor;
2. O cliente faz uma requisição;
3. O servidor processa a requisição, retornando uma resposta ao cliente e fechando a
conexão.
62
Existem diversas formas de se suportar a comunicação de objetos entre diferentes
computadores através da internet, sendo as mais utilizadas o CORBA (Common Object
Request Broker) e o DCOM (Distributed Component Object Model).
Para o desenvolvimento do sistema proposto, optou-se pela utilização do DCOM
devido às seguintes características:
•
A implementação de objetos sob COM é bastante simples;
•
Os objetos podem ser implementados nas mais variadas linguagens existentes no
mercado tais como Visual Basic®, C++, Delphi®;
•
É uma implementação pronta e utilizável;
•
Os objetos criados e não mais utilizados são automaticamente eliminados da
memória pelas bibliotecas do COM (Garbage Collectors);
•
Não há a necessidade de instalação de drivers nas máquinas cliente. Todo o
trabalho de comunicação entre cliente e servidor é realizado pelo Windows;
•
Baixa curva de aprendizado;
Este modelo de objetos distribuídos é parte vital da arquitetura de distribuição de
aplicativos da Microsoft® chamada de Windows DNA (Distributed InterNet Application) que
ainda é composto de outras ferramentas tais como MTS (Manager Transaction Security) e
MSMQ (Microsoft Message Queuing)). No Windows 2000 todas estas ferramentas (DCOM,
MTS e MSMQ) se fundem para formar o COM+ (COM plus).
Para estarem aptas a criar um objeto remoto, as bibliotecas do DCOM precisam saber
o nome do servidor. Para isso, DCOM provê dois mecanismos básicos que permitem ao
cliente definir o nome do servidor quando o objeto tem de ser criado:
1.
Uma configuração fixa no sistema de registro do Windows.
2.
Passagem da localização do objeto como um parâmetro nas funções utilizadas
para criação do objeto.
O primeiro mecanismo é extremamente útil para manter transparente a localização do
objeto. Os clientes não precisam saber se um componente está rodando localmente ou
remotamente. Como o nome do servidor remoto faz parte da configuração do componente na
máquina cliente, tudo o que a aplicação cliente tem que saber é o CLSID (Class ID) do
componente e realizar uma simples chamada do método CreateObject. Então as bibliotecas
COM criam transparentemente o objeto correto no servidor pré-configurado.
63
Atualmente, várias linguagens geram código para COM. Entre elas destacam-se Visual
Basic® , C++, Delphi® e Microfocus Cobol®.
4.4 - O SISTEMA DE CAPTAÇÃO REMOTA DE DADOS
Grande parte do trabalho de um profissional da área de saúde é feita em “campo”. No
caso de médicos e enfermeiros, muitas de suas atividades em um hospital são desenvolvidas à
beira de leitos, em salas de cirurgias e em consultórios.
Todas estas atividades geram informações que devem ser registradas, não só para fins
científicos, mas também para fins administrativos e legais.
Muitas vezes também, o profissional necessita de informações anteriores do paciente
para submetê-lo a determinado procedimento.
Para evitar que estas informações sejam captadas em papel e posteriormente
transcritas para um meio informatizado – o que geraria um grande retrabalho – e para
disponibilizar ao médico informações atualizadas do paciente, foi desenvolvido um sistema de
captação/disponibilização remota de dados para computação móvel. Este sistema é executado
em dispositivos PDA, compatíveis com o sistema operacional PalmOS.
A linguagem de programação adotada, seguindo os conceitos já citados de Rhodes e
McKeehand (2001), foi a linguagem C, através da ferramenta FalchNet®.
Já na tela inicial, após a tela de informações do sistema, o sistema apresenta ao usuário
a lista de pacientes já cadastrados, ordenados por ordem alfabética, e as ações que podem ser
executadas para o paciente selecionado, como mostrado na figura 13.
Figura 13: Telas iniciais do sistema PALM-TUTOR
64
Como já foi citado na seção 3.6.1, o sistema de arquivos do PalmOS não suporta
banco de dados – embora algumas empresas como a Oracle® e a IBM® já tenham
disponibilizado ferramentas de desenvolvimento para esta plataforma que simulem um banco
de dados, porém o custo destas ferramentas tornam qualquer projeto inicial inviável.
Todos os relacionamentos e restrições entre as tabelas (cada tabela é uma base de
dados), inclusive validação de campos, foram programados diretamente na codificação do
sistema, consumindo a maior parte do esforço de programação do aplicativo.
Procurou-se também, otimizar a entrada de dados, conforme mostrado na figura 14,
uma vez que não será utilizado teclado e as entradas serão feitas através do Graffiti.
Entretanto, como muitos dos campos são do tipo texto livre e a escrita no Palm requer
habilidade, a entrada de dados não ficou muito amigável. Os campos que possuíam valores
discretos foram disponibilizados em listas e valores lógicos são fornecidos através de caixas
de seleção. Para dados do tipo data, aparece um calendário sempre que o usuário seleciona um
campo que deva conter dados deste formato.
Figura 14: Entrada de dados facilitada por calendários, listas e caixas de seleção.
As figuras 15 a 19 mostram as telas da versão para PDAs do sistema PALM-TUTOR.
A partir da tela inicial (figura 13), o usuário seleciona um determinado paciente da lista e em
seguida seleciona a função que deseja executar para o paciente selecionado. Após selecionar a
função desejada, é apresentado ao usuário uma tela contendo uma lista de todos os registros
daquela função para o paciente selecionado. Por exemplo, ao selecionar a função consulta,
será apresentada uma lista de todas as consultas às quais o paciente selecionado foi
submetido. Estas telas são: lista de consultas, lista de discussões, lista de cirurgias e lista de
diagnósticos. Estas telas disponibilizam ao usuário as opções de editar ou excluir um
65
determinado registro da lista, criar um novo registro e voltar para a tela inicial. Estas listas são
criadas a partir de uma busca seqüencial pelo código do paciente selecionado e ordenadas
através do algoritmo quicksort. Como a posição do registro na lista não corresponde à sua
posição na base de dados do PDA, foi necessária a inclusão na lista da posição em que o
registro se encontra armazenado. É a partir desta posição que localiza-se o registro para
edição ou exclusão.
As telas de cadastro e edição de consultas, cirurgias, discussões e diagnósticos são
acessadas através de suas respectivas listas. Estas telas são compostas de campos de entrada
de texto livre, campos numéricos, campos de data, listas, check boxes e botões de ações.
Campos do tipo data são criados com a data atual do sistema, caso o usuário deseje mudar,
basta clicar no campo para ser apresentado um calendário onde é possível selecionar a data
desejada. Campos numéricos somente aceitam valores numéricos. Campos de texto livre
possuem barras de rolagem que aparecem e desaparecem conforme a necessidade. Ao
selecionar o botão de retorno, o usuário é questionado se deseja gravar os dados registrados
ou alterados. O processo de gravação consiste em capturar os valores dos campos em
variáveis previamente alocadas do tipo string, alocar espaço suficiente na memória do
dispositivo e efetuar a gravação destas variáveis seqüencialmente na memória. O processo de
recuperação deste registro para edição segue o caminho inverso, é preciso localizar o registro,
dividi-lo em fragmentos, de forma que cada fragmento represente a informação de um
determinado campo e atribuir estes fragmentos a seus respectivos campos na tela de edição.
As telas de consultas, diagnósticos e cirurgias capturam as atividades referentes ao
atendimento ao paciente. Como a tabela de cirurgia possui muitos campos, foi necessário a
construção de cinco telas para captar todos estes dados. Para efetivar a gravação do registro, o
usuário deve navegar até a última tela, preenchendo todos os campos requeridos, entretanto,
pode-se retornar à lista de cirurgias, sem efetivar a gravação do registro, de qualquer uma das
cinco telas.
A tela de discussão é utilizada para a orientação das atividades de atendimento ao
paciente. É através dela que o aluno deverá elaborar seus questionamentos ao coordenador e é
através dela também que o coordenador responderá aos questionamentos dos alunos e efetuar
as suas sugestões e orientações.
66
Figura 15: Telas de lista e cadastro de consultas
Figura 16: Telas de lista e cadastro de discussões
Figura 17: Telas de lista e cadastro de cirurgias
67
Figura 18: Telas do cadastro de cirurgias
Figura 19: Telas de lista e cadastro de diagnósticos
Apesar de todas as qualidades do PDA em relação à mobilidade, restam ainda algumas
limitações com este tipo de dispositivo. Neste trabalho, o principal problema encontrado foi
com relação à impressão das informações cadastradas.
É possível imprimir dados de um PDA, entretanto, todo o controle da impressora fica a
cargo do desenvolvedor do sistema, bit a bit, inviabilizando a geração de relatórios complexos
e bem elaborados, com recursos tais como: imagens, fontes variadas e pesquisa de
informações em várias tabelas. Além disto, somente impressoras com comunicação serial ou
por infravermelho podem ser utilizadas.
A necessidade de impressão de diversos relatórios, inclusive alguns deles nos padrões
do hospital, é uma realidade. Entretanto, a emissão destes relatórios normalmente se dá em
um momento específico, conforme a sua necessidade.
68
Como o usuário deverá diariamente sincronizar os dados de seu PDA com a base de
dados centralizada na internet e como o aplicativo responsável por este sincronismo será
executado em um ou diversos PCs com plataforma Windows® disponíveis no ambiente
hospitalar, aproveitou-se esta restrição para disponibilizar nestes mesmos computadores uma
versão do sistema para esta plataforma, semelhante ao desenvolvido para o PDA.
O sistema desenvolvido para o PC disponibiliza, além das funcionalidades da versão
para PDA, opções de impressão de diversos relatórios, além da possibilidade de
complementação das informação colhidas no PDA, com dados menos relevantes, através da
interface amigável que é o teclado do PC e não mais do Graffite do PDA.
4.5 - O SISTEMA DE SINCRONISMO DE DADOS ENTRE OS PDAS E A BASE DE
DADOS
Conforme apresentado no capítulo 3, todos os dados contidos no PDA são locais.
Portanto, quando esses dados precisam ser consultados por diversas pessoas, torna-se
necessário construir uma base de dados corporativa centralizada e manter todos os PDAs que
utilizam estes dados sincronizados com a base. Para efetuar essa sincronização é necessário o
desenvolvimento de um aplicativo denominado conduit.
Conduit é o nome usado pela Palm Inc. para descrever os programas que controlam a
sincronização entre bases de dados em dispositivos PDA e bases de dados em computadores
pessoais ou servidores. A Palm Inc. fornece kits (CDK – Conduit Development Kit) de
desenvolvimento para conduits Windows e Mac usando C/C++ e Java, bem como qualquer
ambiente de desenvolvimento habilitado COM em Windows. Existem algumas ferramentas
de terceiros disponíveis, que fazem uso de bibliotecas do CDK e, portanto, exigem que este
seja instalado juntamente com a ferramenta de desenvolvimento.
Existem três tipos principais de conduit que podem ser escritos:
•
conduits de uma via (one-way) que sobrescrevem ou anexam dados existentes no
PDA ou no PC/servidor;
•
conduits de dupla via completa (full two-way) que finalizam com os mesmos dados
nos dois lados da linha de sincronismo;
•
conduits baseados em transação – estes realizam um processamento adicional dos
registros. Um exemplo seria quando os dados são coletados no PDA e utilizados
69
para criar transações com uma grande base de dados. O mesmo pode ser verdade
na direção reversa, onde um determinado subconjunto de dados é enviado ao PDA.
Conduits de uma via (one-way) são mais fáceis de construir e tendem a ser mais
robustos.
Existem dois tipos de sincronismo de dupla via (two-way) que o Gerenciador de
HotSync da Palm Inc. pode fazer:
Sincronismos lentos, onde o conduit não foi anteriormente executado com o PDA
corrente, ou o último sincronismo não ocorreu com o PC em uso. Esse tipo de sincronismo
indica que o conduit deve examinar cada registro do PDA e, possivelmente, cada registro do
PC também. As flags de modificado/apagado/arquivado não são confiáveis pois o último
sincronismo as desmarcou na base de dados do PDA.
Sincronismos rápidos, onde o último sincronismo foi entre o par de dispositivos em
questão e as flags de ambas bases de dados são confiáveis.
modificados/apagados/arquivados necessitam ser manipulados.
Apenas os registros
Isso significa que o
sincronismo é, normalmente, mais rápido, devido ao reduzido conjunto de registros a serem
lidos do PDA.
Durante o desenvolvimento do conduit, deparou-se com as seguintes características e
limitações:
•
Um conduit é capaz de abrir qualquer base de dados no PDA.
•
Apenas uma base de dados pode estar aberta.
•
Um conduit pode criar e apagar bases de dados.
•
Não é possível atribuir ou alterar o identificar único para um registro na base de
dados no PDA.
O PalmOS® realiza esta tarefa, garantindo um id único no
dispositivo.
•
Não é possível controlar a posição na qual os registros são adicionados a uma base
de dados no PDA.
•
É possível escrever mensagens para o log de sincronização no PDA e no PC.
•
Pode existir apenas um conduit por id creator (“apelido” formado por quatro
dígitos que identifica uma aplicação executando no PDA; a Palm Inc. efetua o
controle das aplicações registradas, a fim de evitar conflitos no dispositivo) .
•
Os registros das bases de dados podem ser de até 65505 bytes. Podem existir
apenas 64k registros em uma base de dados. Qualquer avanço nessas direções
70
requer o uso de file streaming ou algum tipo de manipulação para dividir os dados
em diversos registros (se os registros individuais forem muito longos) ou para
empacotar diversos registros (se existem muitos registros).
•
O conduit notifica a aplicação desktop/servidora quando executa ou finaliza,
usando um outro tipo de DLL (Dynamic Link Library) denominada Notifier. Esta
permite ao programa desktop recusar entradas do usuário durante o sincronismo.
Todas as DLLs de conduit possuem uma lista de funções de ponto de entrada que
podem ser obrigatoriamente implementadas ou opcionais. Esses pontos de entradas são
chamados para obter informações do conduit como o nome e a versão, e para exibir a caixa de
diálogo de configuração.
A mais importante função de ponto de entrada é a chamada OpenConduit. Quando o
gerenciador de HotSync está pronto para sincronizar os dados, percorrerá a lista de conduits
chamando a função OpenConduit. Para essa função, é passado um conjunto de propriedades
sobre o processo de sincronismo, que muitas ferramentas expõem como propriedades de um
componente VCL (Visual Component Library) ou ActiveX. Entre as informações passadas
incluem-se o tipo de sincronismo (rápido, lento, sincronização em duas vias, PDA sobrescreve
PC, PC sobrescreve PDA, não fazer nada), informações sobre diretórios, nomes de bases de
dados no PC estabelecidas quando da instalação do conduit, nome do usuário e tipo de
conexão (cabo ou modem). Geralmente, a função OpenConduit executa as seguintes tarefas:
•
Verifica se o conduit está configurado para não fazer nada. Neste caso, finaliza.
•
Registra a si próprio com a API Sync Manager. Esses métodos são usados para
realizar diversas manipulações de dados no PDA, abrir e fechar bases de dados, ler
e escrever registros.
•
Envia uma mensagem Sync started para o log do HotSync indicando que o
sincronismo iniciou para o conduit corrente.
•
Verifica o tipo de sincronismo requerido.
•
Sincroniza os dados de acordo com a solicitação.
•
Se o processo de sincronismo possuir erros, ou produzir mensagens que o usuário
deva ver, estes são adicionados ao log do sincronismo. Erros fatais devem enviar
uma mensagem Sync aborted.
•
Se o sincronismo finaliza com sucesso, envia uma mensagem Sync finished ao log.
•
Remove o registro do conduit com a API Sync Manager.
71
•
Opcionalmente, retorna um código de erro da função OpenConduit. Normalmente,
esse procedimento não é necessário.
As dificuldades deste processo estão relacionadas à manipulação da estrutura do
registro do PDA e à decisão da lógica do sincronismo. Porém, a parte mais difícil de escrever
um conduit é decidir sobre a lógica de sincronização. Em casos onde o registro foi modificado
no PDA e no PC, o conduit da aplicação deve ser capaz de determinar que mudanças foram
feitas no mesmo registro em cada base de dados e decidir qual a ação apropriada. Essa não é
uma situação incomum. Cada programa que trabalha em situações onde pode existir mais de
uma cópia de dados, e cada cópia pode ser modificada sem referência às outras, antes destas
cópias serem consolidadas em um só conjunto de dados, deve enfrentar tais decisões.
Existem muitas estratégias que podem ser utilizadas, dependendo das circunstâncias.
A solução implementada foi manter os dados inalterados tanto no PDA quanto na base de
dados servidora e gerar uma mensagem no log de sincronismo (conforme mostra a figura 20),
informando ao usuário qual registro gerou o conflito e quais ações devem ser tomadas.
Além disso, a lógica de sincronismo determinará fortemente se os objetivos do projeto
do conduit serão atingidos. Cada conduit deve possuir as seguintes metas:
•
Execução rápida;
•
Perda de dados zero;
•
Ausência de interação com o usuário;
•
Resolução de conflitos.
Figura 20: Janela de log informando que houve conflito de sincronismo nos registros
72
Existem três técnicas para implementar quaisquer estratégias de resolução de conflitos:
•
Identificação única de registros no PDA e na base de dados do servidor;
•
Mapeamento dos registros do PDA para a base de dados do servidor;
•
Detecção de registros criados/modificados/apagados.
Adotou-se a técnica de identificação única de registros juntamente com a detecção de
registros criados/modificados/apagados.
Para identificação única de registros, tanto no PDA quanto na base de dados do
servidor, criou-se o seguinte esquema de geração de chaves primárias:
•
<COD_USUARIO> + <ANO> + <MÊS> + <DIA> + <HORA> + <MINUTO> +
<SEGUNDO> + <MILISEGUNDOS> como, por exemplo, um novo registro
inserido pelo o usuário de código 4, às 16:45:35:345h do dia 16/01/2001, terá a
seguinte chave primária: 420010116164535345.
De forma que, independentemente de onde esteja sendo criado este registro, quer seja
no PDA ou seja na base de dados do servidor, o seu número identificador será único e não
precisará ser alterado quando o sincronismo for executado.
A detecção de registros criados/modificados/apagados é feita no PDA utilizando-se as
flags geradas pelo próprio sistema operacional, e na base de dados servidora através de
campos lógicos que identificam quais ações foram executadas em cada registro. Esta
abordagem, não apenas identifica conflitos nos registros como também otimiza o processo de
sincronismo, uma vez que apenas registros que sofreram alguma ação são sincronizados.
Existe ainda, um conjunto de considerações extra a serem feitas quando da
sincronização com uma base de dados servidora. Uma consideração é a questão da segurança
da base de dados. Verificou-se que uma das questões mais freqüentemente feitas nos grupos
de discussão é como identificar unicamente o dispositivo PDA. Freqüentemente pensa-se em
utilizar este identificador único como parte do login ou dos procedimentos de segurança em
um conduit. Enquanto dispositivos PDA atuais possuem um ID, os antigos não possuem esta
característica. Entretanto, a melhor abordagem é identificar o usuário ao invés do dispositivo.
A solução adotada foi armazenar as informações para o login no PC em entradas do
Registry. Estas configurações podem ser modificadas por uma caixa de configuração
personalizada.
Possuir muitos usuários também aumenta as opções na decisão da lógica de
sincronismo. Pode ser possível ter modificações feitas por determinados usuários
73
sobrescrevendo àquelas feitas por outros. A fim de solucionar esta questão, cada registro
possui um campo que identifica o usuário proprietário, e apenas este possui permissão de
alterar ou excluir os dados nele contidos.
Outro problema é que a base de dados do servidor normalmente é muito maior do que
o PDA pode manipular. A questão de decidir qual subconjunto de registros deve ser carregado
no PDA deve ser abordada. Como no presente trabalho a base de dados está começando a ser
formada, inicialmente, todos os dados serão carregados no PDA. À medida em que estas
informações não são mais necessárias, serão excluídas do dispositivo pelo próprio usuário,
permanecendo apenas na base de dados servidora. Caso haja alguma alteração nestes dados,
eles são automaticamente recarregados no PDA.
Bases de dados grandes e complexas normalmente contém tabelas lookup (tabelas que
possuem campos que se referenciam a registros de outras tabelas através de chaves
estrangeiras). A sincronização deste tipo de tabela é sempre complexa para qualquer
abordagem de sincronismo, pois deve-se identificar se existem duplicidades e resolver as
referências nos registros. Supondo uma tabela contendo uma lista de cidades referenciadas na
entrada de endereços em outra tabela. Os usuários adicionam a mesma cidade a suas listas em
PDAs separados. Então, os registros dos PDAs referenciarão a mesma cidade usando
identificadores diferentes. Como o domínio deste tipo de dado normalmente é discreto, o
problema foi solucionado adotando-se a política de não permitir a inclusão/alteração deste
tipo de registro no PDA, executando-se as ações necessárias apenas na base de dados
servidora e replicando-se para os PDAs.
Permanece ainda, o problema de que os usuários do sistema não encontram-se todos
em uma determinada região e as distâncias regionais entre eles é bastante grande. Para
solucionar este problema, conforme citado no item 4.2, utilizou-se a internet, através de um
servidor de aplicação remoto, para disponibilizar o acesso à base de dados centralizada de
forma barata e segura.
O fluxograma da figura 21 representa o processo de sincronismo da tabela de
pacientes. A lógica é descrita resumidamente a seguir:
•
sincroniza-se primeiramente os dados do PDA para a base de dados servidora;
•
todo registro marcado como criado é registrado no servidor;
•
caso o registro esteja marcado como alterado, procura-se pelo registro no servidor
para sincronizar as alterações;
74
•
se o registro não for encontrado, ele é incluído no servidor;
•
caso o registro seja localizado, mas esteja marcado como alterado, é registrado um
conflito no log de sincronismo;
•
após verificados todos os registros da tabela do PDA, sincroniza-se os dados do
servidor para o PDA;
•
todo registro marcado como criado é registrado no PDA;
•
caso o registro esteja marcado como alterado, procura-se pelo registro no PDA
para sincronizar as alterações;
•
se o registro não for encontrado, ele é incluído no PDA;
•
caso o registro seja localizado, mas esteja marcado como alterado, é registrado um
conflito no log de sincronismo;
•
os registros marcados como excluídos, são primeiramente excluídos do PDA;
•
antes de excluir um registro do PDA que mantém relacionamento com outros
registros, deve-se procurar em todas as tabelas por registros relacionados com
aquele marcado para exclusão e excluí-los.
•
zera-se as flags de controle de sincronismo.
75
OpenConduit
Conexão com
internet
estebelecida?
Não
Não
Solicita
conexão
Fecha base
de dados de
diagnóstico no
PDA
Fecha base
de dados de
cirurgia no
PDA
Sim
Sim
Não
Fim da
base?
Fim da
base?
Sim
Posiciona no
próximo registro
da base de dados
de diagnóstico no
PDA
Sim
Efetuar
conexão?
Conecta ao
servidor de
aplicação
remoto
Não
Posiciona no
próximo registro
da base de
dados de
cirurgia no PDA
Não
Fim
Abre a base
de pacientes
no PDA
Erro?
Sim
Sim
Exclui registro
na base do
PDA
cirurgia é
do paciente
excluído?
Posiciona no primeiro
registro da base de
dados de diagnóstico
no PDA
Posiciona no
primeiro registro
da base de dados
de cirurgia no
PDA
Abre a base de dados
de diagnóstico no PDA
Abre a base de
dados de cirurgia
no PDA
Sim
Inclui na base
servidora
Sim
Pesquisa na
base de dados
servidora
Não
Não
Localizado?
Fim da
base?
Sim
Abre a base
de dados de
consulta no
PDA
Posiciona no primeiro
registro da base de dados
de consulta no PDA
Sim
Gera mensagem de
conflito no log de
sincronismo
Pesquisa na
base do PDA
pelo paciente a
ser excluído
Registro
novo?
Sim
Inclui na base
do PDA
Erro?
Pesquisa na
base de dados
do PDA
Localizado?
Sim
Altera base de
dados do PDA
Fecha base de
paciente do
PDA
Sim
Exclui paciente
da base de
paciente doPDA
Posiciona no
primeiro registro
da base de dados
de discussão no
PDA
Abre a base de
dados de
discussão no PDA
Não
Sim
Posiciona novamente
no primeiro registro da
base de dados no
servidor
Não
Posiciona no
próximo
registro da
base no
servidor
discussão é
do paciente
excluído?
Abre a base de
dados de paciente
no PDA
Não
Sim
paciente
localizado
Sim
Não
Registro
modificado?
Exclui registro
na base do
PDA
Altera registro
na base
servidora
Não
Sim
Posiciona no
primeiro
registro da
base servidora
Não
Consulta é
do paciente
excluído?
Registro alterado
tembém na base
servidora?
Fim da
base?
Posiciona no
próximo registro
da base de dados
de discussão no
PDA
Não
Sim
Fim da
base?
Exclui registro
na base do
PDA
Sim
Não
Posiciona no
próximo registro
da base de
dados de
consulta no PDA
Não
Posiciona no
próximo
registro da
base no PDA
Sim
Fecha base
de dados de
discussão no PDA
Sim
Não
Registro
modificado?
Exclui registro
na base do
PDA
Não
Erro?
Fecha base
de dados de consulta
no PDA
Registro
Novo?
Sim
Gera
mensagem de
erro no log de
sincronismo
Sim
Posiciona no
primeiro registro
da base no PDA
Não
diagnóstico é
do paciente
excluído?
Abre a base
pacientes no
servidor
Registro
excluído?
Não
Posiciona no
próximo registro
da base no
servidor
Não
Fecha a base
de pacientes
do PDA
Não
Fim da
base?
Sim
Não
Fim da
base?
sim
Fim
Figura 21: Fluxograma do esquema de sincronismo da tabela de pacientes.
76
4.6 - A EXECUÇÃO DO SISTEMA CLIENTE NO COMPUTADOR PESSOAL
Conforme comentado anteriormente, os PDAs possuem diversas limitações que não
permitem executar, nestes dispositivos, aplicações que exijam grande quantidade de entrada
de dados ou emissão de relatórios complexos, entre outras.
Em face à esta realidade, e com o objetivo de suprir essas limitações, desenvolveu-se
uma aplicação semelhante para a plataforma Windows na arquitetura IBM PC.
Com isto, permite-se que o usuário que usufrua da principal vantagem do PDA, que é
a possibilidade de transportar e ter acesso rápido às informações do paciente em todos os seus
pontos de atendimento; e das facilidades da interface do PC, onde é possível efetuar pesquisas
mais elaboradas, cadastrar dados de forma mais amigável e imprimir os relatórios de suas
atividades com qualidade e padronização.
Um dos requerimentos iniciais do desenvolvimento deste trabalho foi a necessidade de
uma interface homem-máquina amigável. Isto se justifica por uma razão básica, que é o perfil
do usuário, pois estima-se que os médicos que vão utilizar o sistema tenham, em geral,
conhecimentos mínimos de informática. Assim sendo, o sistema foi projetado de forma a
conduzir o usuário e requerer apenas interações simples.
Outro requerimento, também básico, é a questão de segurança no acesso ao sistema.
Principalmente por se tratar de uma aplicação que fornece acesso a dados através da internet.
Quando o sistema é iniciado, após a conexão com o sistema servidor de aplicação ser
efetuada (através de um usuário e senha temporários codificados no próprio sistema cliente),
uma tela de informações do sistema e em seguida de informações de acesso (figura 22) são
mostradas ao usuário, solicitando que sejam fornecidos um usuário e uma senha de acesso ao
sistema. Somente após validadas estas informações o servidor de aplicação libera à aplicação
cliente o acesso aos dados, iniciando realmente a aplicação.
Figura 22: Telas inicial e de acesso ao PALM-TUTOR para PC
77
A partir da tela principal do sistema (mostrada na figura 23), além de efetuar a manutenção
dos usuários do sistema (somente para o usuário administrador) e dos pacientes, é possível acessar as
seguintes funções para um paciente selecionado:
•
Consultas: tem a finalidade de servir como acesso aos dados das consultas efetuadas com
o paciente selecionado;
•
Diagnósticos: permite o acesso aos dados dos diagnósticos do paciente selecionado;
•
Discussões: refere-se às discussões efetuadas entre o aluno e o coordenador a respeito do
tratamento aplicado ao paciente selecionado;
•
Cirurgias: acessa
dados referentes às cirurgias às quais o paciente selecionado foi
submetido, dispositivos de acesso vascular (DAV) implantados durante uma determinada
cirurgia e complicações advindas do implante de um determinado DAV;
Figura 23: Tela inicial do PALM-TUTOR para PC
Por solicitação do coordenador do programa Outreach no Brasil (para o qual o sistema está
sendo desenvolvido), foram definidos dois níveis de usuário: usuário avançado (tipo A) e usuário
básico (tipo B).
As operações de manutenção de usuários e exclusão de pacientes ficaram a cargo somente de
usuários tipo “A”.
78
Usuários do tipo “A” também têm o privilégio de acessar, sem restrições, os dados de todos os
pacientes cadastrados no sistema, independentemente de propriedade, enquanto que usuários do tipo
“B” somente podem acessar dados de pacientes que são de sua propriedade.
As figuras 24 a 31 mostram as janelas de entrada, consulta e alteração de dados do sistema de
Telemedicina no Ensino à Distância, incluindo dados sobre os pacientes, consultas, cirurgias,
diagnósticos, discussões a respeito de determinados casos e usuários do sistema. Os campos do tipo
chave primária – para todas as tabelas, exceto para a de usuário são gerados automaticamente pelo
sistema, seguindo o mesmo conceito implementado na versão para o PDA: <COD_USUARIO> +
<DATA> + <HORA> + <MINUTO> + <SEGUNDO> + <MILISEGUNDOS>. Como não
existe cadastro de usuários no PDA, sendo os usuários cadastrados diretamente na base pelo sistema
cliente, pôde-se adotar uma geração de códigos seqüencial. Embora sejam mostrados na tela, as
datas de cadastramento são registradas automaticamente, seguindo o relógio do dispositivo.
Todos os campos possuem validação dos dados digitados, p. ex., não é possível digitar
caracteres em campos numéricos. Nas janelas, disponibilizou-se ao usuário uma grade com
todos os registros a que ele possui acesso, ordenadas por ordem alfabética – no caso do
paciente – e por ordem decrescente de data de cadastro – nos demais casos, permitindo a fácil
localização do registro desejado. Nas telas, há sempre a opção de cancelamento das alterações
efetuadas (antes da confirmação) e impressão do registro corrente ou outras informações,
conforme o caso (vide seção 4.6.1).
A figura 32 demonstra a tela onde o usuário pode alterar a sua senha de acesso ao
PALM-TUTOR.
O sistema comporta-se como se os dados acessados estivessem locais, embora este
acesso seja remoto. Para isto, utilizou-se a técnica cached update, que simula tabelas locais
para otimizar o acesso aos dados. Esta técnica cria tabelas virtuais no sistema local,
replicando nestas os dados localizados no servidor que foram solicitados. Para evitar perda de
dados, imediatamente após haver alguma alteração nos dados locais, persiste-se as alterações
no servidor.
79
Figura 24: Janela de acesso ao dados das consultas do paciente selecionado
Figura 25: Janela de acesso ao dados dos diagnósticos do paciente selecionado
80
Figura 26: Janela de acesso às discussões referentes ao paciente selecionado
Figura 27: Janela de acesso ao dados das cirurgias efetuadas no paciente selecionado
81
Figura 28: Janela de acesso ao dados dos DAV implantados no paciente selecionado
Figura 29: Janela de acesso ao dados das complicações dos DAVs do paciente selecionado
82
Figura 30: Janela de cadastro de pacientes
Figura 31: Janela de cadastro de usuários
Figura 32: Janela de alteração de senha do usuário corrente
83
4.6.1 - Relatórios emitidos pelo sistema
O sistema emite, além dos relatórios das atividades diárias do médico, exigidos e
padronizados pelo IMIP (Instituto Materno-Infantil de Pernambuco), alguns outros que serão
úteis para controle das atividades desenvolvidas e comprovação documental da atividade
curricular do participante do programa. Os relatórios emitidos pelo sistema são os seguintes
(exemplos de todos os relatórios emitidos pelo sistema encontram-se no anexo 2):
•
Relatórios do paciente (impresso a partir da tela principal):
o Geral – demonstra todo o histórico de um determinado paciente durante
o seu tratamento, incluindo todas as consultas, diagnósticos e cirurgias;
o Todas as consultas – demonstra todas as consultas efetuadas com um
determinado paciente;
o Por tipo de consulta – após o usuário informar o tipo de consulta, é
gerado um relatório demonstrando todas as vezes que o paciente
compareceu para uma consulta daquele tipo e os dados que foram
gerados a partir delas.
•
Relatórios gerais (impresso a partir da tela principal):
o Lista de pacientes – lista os dados de todos os pacientes cadastrados,
com finalidade acadêmica. Se o usuário for do tipo “A”, serão listados
todos os pacientes, caso contrário, somente serão listados os pacientes
de propriedade do usuário;
o Lista de cirurgias – lista de todas as cirurgias que o usuário participou
como cirurgião, primeiro ou segundo auxiliar. Será utilizada como
documento de comprovação de atividade curricular;
•
Relatório da cirurgia selecionada – relatório com finalidade administrativa e
acadêmica, que compreende todos os dados registrados de uma determinada
cirurgia, inclusive os DAVs que foram implantados e a complicações ocorridas
para cada DAV (caso hajam). Emitido a partir da tela de cirurgias;
•
Relatório da consulta selecionada – relatório com finalidade administrativa e
acadêmica, que compreende todos os dados registrados de uma consulta
efetuada e é emitido a partir da tela de consultas;
84
•
Relatório do diagnóstico selecionado – relatório com finalidade administrativa
e acadêmica, que compreende todos os dados referentes a um certo diagnóstico
e é emitido a partir da tela de diagnósticos;
•
Relatório da discussão selecionada – relatório com finalidade acadêmica,
compreende todos os dados de uma discussão a respeito de um determinado
caso e é emitido a partir da tela de discussões.
4.7 - SEGURANÇA
Por se tratar de dados corporativos acessados através de um servidor de Internet,
alguns quesitos de segurança devem ser considerados.
Apesar dos dados estarem sendo acessados remotamente, o acesso ao SGBD é
efetuado localmente, através da utilização da camada de software intermediária, denominada
servidora de aplicação. Os clientes estabelecem uma conexão com a aplicação servidora e
solicitam os acessos aos dados de que necessitam; a servidora de aplicação conecta-se ao
SGDB e acessa os dados solicitados, retornando aos clientes os resultados das operações
efetuadas.
O SGDB está instalado em um computador com sistema operacional Windows 2000
Server, localizado no laboratório de Bioinformática do CEFET-PR, ao qual, somente pessoas
autorizadas têm acesso.
O módulo cliente para PC do PALM-TUTOR possui um mecanismo de validação de
usuário e senha, evitando que pessoas não autorizadas acessem o sistema.
O módulo cliente para PDA do PALM-TUTOR somente acessa os dados corporativos
através do conduit de sincronismo, o qual somente responde às requisições desta aplicação
específica, além de contar também com um usuário e senha internamente codificados.
Como a servidora de aplicação é um objeto do tipo DCOM, qualquer aplicação externa
pode acessá-la, bastando para isto conhecer a sua CLSID. Entretanto, por ser uma
implementação que se torna um componente do sistema operacional, pode-se utilizar todos os
recursos de segurança do próprio Windows 2000. A figura 33 demonstra a configuração das
permissões de acesso à aplicação através do sistema operacional. Estes usuários e senhas
podem ser solicitados no momento em que um usuário solicita uma conexão à servidora de
85
aplicação, porém, a fim de evitar a divulgação de senhas de acesso ao sistema operacional e,
por conseqüência à rede interna do CEFET-PR, optou-se por codificar estes usuários e senhas
internamente. Desta forma, existem duas validações de usuários e senhas antes que a
aplicação seja executada: as transparentes ao usuário, que identificam se a aplicação é
autorizada a solicitar uma conexão; e as solicitadas ao usuário, que verificam se este está
autorizado a utilizar aquela aplicação.
Figura 33: Tela de configuração do Windows para acesso a objetos DCOM
Infelizmente, existe um elo fraco neste sistema de segurança, que reside no PDA. Este
dispositivo não provê recursos de segurança, contando apenas com uma senha facilmente
burlável de inicialização do dispositivo.
De posse deste dispositivo, qualquer pessoa não autorizada terá acesso aos dados nele
registrados. Se o invasor possuir acesso à máquina onde está instalado o conduit de
sincronismo, o acesso aos dados corporativos do usuário que descuidou-se do PDA, será
igualmente permitido. Cabe então, exclusivamente ao usuário, zelar pelo PDA, como se fosse
86
o fiel portador da chave de um cofre, pois qualquer pessoa que tenha acesso à esta chave e
tenha acesso ao local onde o cofre se encontra, terá acesso ao seu interior.
87
CAPÍTULO 5
5
DISCUSSÃO E CONCLUSÕES
5.1 - DISCUSSÃO
Neste capítulo, procura-se apresentar as contribuições oferecidas pelo estudo
realizado, discutindo as aplicações que podem ser dadas ao modelo apresentado e suas
restrições.
Dentro de seus objetivos iniciais, este trabalho contribui para o programa International
Outreach do St. Jude Hospital22, permitindo que o seu coordenador no Brasil dissemine seus
conhecimentos em Oncologia Pediátrica para médicos especializandos nesta área que atuam
em diversas regiões do país.
Atualmente, o programa conta com apenas um aluno por ano, o qual encontra-se em
Recife-PE. Apesar do número reduzido de usuários, a utilização do PALM-TUTOR não é
desabonada, pois a orientação das atividades desenvolvidas por este aluno deve ser
plenamente satisfeita e o registro de todas as informações que dela derivarem em uma forma
organizada e segura é um fator primordial para o levantamento das deficiências regionais e o
aprimoramento do programa de especialização. Deve-se considerar ainda que, ao término do
curso, o especializando é substituído por um novo aluno, o qual deverá dar continuidade ao
tratamento dos pacientes do aluno anterior. Com todo o histórico dos atendimentos registrado
em um sistema de fácil consulta, torna-se mais fácil a cada novo aluno a continuidade destes
trabalhos. Novos alunos poderão, ainda, utilizar-se de registros anteriores e aplicar este
conhecimento no atendimento a casos semelhantes.
Infelizmente, a conclusão do trabalho coincidiu com a troca de alunos do programa,
ficando a avaliação de suas interfaces e funcionalidades restrita ao coordenador do programa.
Com respeito aos dados sobre a melhoria no sistema de ensino, somente após alguns meses de
ampla utilização do PALM-TUTOR é que será possível extrair tais informações. Contudo, o
simples fato de possuir as atividades registradas em um meio que evita retrabalhos de
digitação e facilita a consulta, sugere que a tarefa de orientação dos alunos tende a ser
facilitada.
22
http://www.stjude.org/newhp/international_outreach.html
88
Apesar deste trabalho ter sido desenvolvido para um programa de especialização em
Oncologia Pediátrica, ele pode ser facilmente estendido a outras áreas da saúde, não só para o
ensino, como também na forma de prontuários eletrônicos.
Durante o desenvolvimento e a implementação da ferramenta, deparou-se com
diversas dificuldades. Por se tratar de uma tecnologia ainda nova no Brasil, a computação
móvel apresenta-se cara não somente em seus dispositivos, mas também em suas ferramentas
de desenvolvimento que, apesar do preço, nem sempre cumprem com o papel desejado e
apresentam uma série de limitações. A falta de literatura técnica sobre o assunto também é um
agravante. Em função do orçamento disponível foram utilizadas ferramentas de baixo custo
ou gratuitas que exigem um grande esforço de programação e um bom conhecimento da
linguagem, consumindo grande parte do tempo do projeto.
Por se tratar de um projeto piloto, a ferramenta apresenta algumas restrições, que são
listadas a seguir:
•
O servidor de aplicação não aceita conexões concorrentes, pois é necessário
gerenciar cada instância de conexão de forma a manter a integridade dos
dados. Como atualmente são apenas dois usuários e a utilização maior do
sistema será através da aplicação do PDA, optou-se por deixar a
implementação do acesso concorrente para trabalhos futuros;
•
Em conexões com a internet, através de linhas discadas e de baixa velocidade,
não foi possível persistir campos com mais de 255 caracteres, ficando este
valor estipulado como limite máximo para entradas em campos de texto livre;
•
As tabelas não foram normalizadas segundo os conceitos de SGBD, devido à
falta de suporte a banco de dados da ferramenta utilizada para desenvolvimento
da aplicação do PDA, restringindo o uso de campos do tipo table lookup e
causando redundância de dados;
•
O servidor web Apache não proveu recursos para a comunicação entre as
aplicações clientes e servidora através do protocolo HTTP, o que exigiu a
utilização de um servidor HTTP especificamente desenvolvido para este fim,
denominado Kudzo (KUDZO, 2002). Como o Kudzo utiliza a porta de
comunicação 81, há a necessidade de configurar o firewall do cliente, caso este
esteja acessando o servidor através de uma rede local. A utilização do servidor
web Microsoft IIS resolve este problema, porém, devido aos recentes
89
problemas de segurança deste servidor web, optou-se por não utilizá-lo no
momento.
5.2 - CONCLUSÕES
O sistema PALM-TUTOR permite ao coordenador do programa International
Outreach no Brasil gerenciar a orientação dos especializandos em Cirurgia Oncológica
Pediátrica, em um ambiente de ensino à distância baseado em PBL, com a utilização de
recursos de telemedicina.
Como em qualquer curso que incorpora tecnologias, esta ferramenta deve ser
continuamente acompanhada. A equipe responsável pelo projeto deve acompanhar a aplicação
do curso e garantir a sua operacionalidade durante todo o período em que ele está ocorrendo,
atuando da seguinte maneira:
•
Corrigindo problemas e implementando a comunicação;
•
Adicionando material ao curso;
•
Resolvendo problemas técnicos e operacionais.
A avaliação do PALM-TUTOR está sendo feita segundo os conceitos citados em The
Johns Hopkins University School of Hygiene and Public Health, (1997), considerando os
seguintes tipos de avaliação:
•
Avaliação formativa: processo de avaliação realizado no decorrer de um programa
instrucional visando aperfeiçoá-lo.
•
Avaliação somativa: processo de avaliação final de um programa instrucional
visando julgá-lo.
As avaliações formativas devem ser conduzidas durante as etapas de design e de
produção. Estas avaliações são feitas pelo usuário e levam em consideração questões como a
verificação da simplicidade da navegação, o entendimento do conteúdo, a efetividade do
design instrucional e a análise do tempo necessário para o término da unidade de estudo. Estas
observações podem resultar em modificações no design instrucional quando o sistema for
finalizado.
Avaliações somativas devem ser conduzidas após o final do curso. Os estudantes
devem ser questionados quanto à efetividade do programa, a respeito da sua simplicidade e
sugestões para possíveis implementações. Isto deverá ser compilado e resumido ao docente
90
responsável para futuras versões do curso. Dentre as atividades de avaliação deste docente,
pode-se citar as seguintes:
•
Monitoração do curso;
•
Análise do desempenho do docente;
•
Análise do uso das mídias pelos alunos;
•
Teste da qualidade do material;
•
Efetividade do programa a distância;
No anexo 4, consta a avaliação formativa do principal usuário do sistema, o
coordenador do programa International Outreach no Brasil.
Ao final das atividades deste trabalho, chegou-se às seguintes conclusões:
As ferramentas públicas de desenvolvimento para Palm apresentaram grande
versatilidade, entretanto, a falta de suporte a banco de dados compromete o desenvolvimento
de aplicações que utilizam grande quantidade de dados. A forma de sincronismo de dados
entre o PDA e uma base corporativa precisa ser mais amigável.
Dispositivos handhelds são excelentes organizadores pessoais, permitindo o
desenvolvimento de aplicações semelhantes às que rodam em PCs, dando grande flexibilidade
e mobilidade aos profissionais que atuam em campo e que necessitam registrar suas
atividades.
O uso do PALM-TUTOR eliminou o retrabalho dos alunos, no sentido em que
registram apenas uma vez as suas atividades. Estes registros são utilizados tanto para geração
dos relatórios exigidos pelo hospital, quanto para avaliação e orientação das atividades dos
alunos pelo coordenador.
O coordenador do programa International Outreach teve suas atividades facilitadas
com o registro organizado das atividades de seus alunos. Com o registro de suas orientações,
futuros alunos poderão consultá-las para casos semelhantes, reduzindo, ao longo do tempo, a
quantidade de questionamentos.
Além de sua utilização para o PALM-TUTOR, o PDA pode ser utilizado para diversas
outras aplicações médicas, justificando plenamente o seu investimento.
Finalizando, outros caminhos foram abertos, a partir da disponibilidade de
informações organizadas e gerenciadas em bases. Embora o fruto deste trabalho tenha sido
um sistema integrador, vislumbra-se algumas possibilidades vinculadas mais ao conhecimento
91
especialista e à mineração de dados – a Coordenação Brasileira, além de tornar-se uma
disseminadora tecnológica, será então uma “formadora” de conhecimento.
5.3 - TRABALHOS FUTUROS
A fim de facilitar o acesso dos usuários à aplicação cliente para PC, sugere-se a
implementação desta camada de software para serem executados em navegadores como o
Internet Explorer e o Netscape. Tal implementação pode ser feita de duas formas. Uma delas é
compilar a aplicação como um componente ActiveX da Microsoft, o que pode ser facilmente
feito com poucas modificações no sistema atual. O problema desta abordagem é a necessidade
de utilização do servidor web Microsoft IIS. Outra solução seria migrar o sistema para o
ambiente JAVA, o que o tornaria independente de plataforma, mas exigiria o
desenvolvimento da aplicação a partir do zero.
A comunicação entre as aplicações clientes e servidora, pode gerar diversas linhas de
pesquisa. A utilização de outros protocolos além do HTTP, implementações CORBA e JAVA
RMI e, principalmente, a permissão de acessos concorrentes são algumas delas.
A migração do sistema do PDA para uma linguagem de desenvolvimento de
aplicações para PDA com suporte a banco de dados, permitiria uma redução na redundância
de dados através da normalização, além de expandir as fronteiras do sistema para uma
aplicação mais robusta, mais amigável e mais perto das necessidades do usuário.
Resolvidos os problemas de falta de recursos e limitações do sistema, a ferramenta
pode ser estendida a um sistema hospitalar de prontuário eletrônico totalmente informatizado,
permitindo que todas as pessoas envolvidas no atendimento a um determinado paciente
tenham acesso imediato às informações de que necessitam para esta atividade, podendo
inclusive acompanhá-los de suas próprias casas.
92
93
6
ANEXO I
DICIONÁRIO DE DADOS
94
95
Tabela 10: Dicionário de dados da tabela de usuários
Nome
Tipo
Tamanho
Conteúdo
Usu_Id
Numérico
32 bits
Domínio:
{1- 2147483647}
Usu_Usuário
Caracter
10
Descrição
Identificador
único
do
usuário
Texto livre
Identificador para acesso
Domínio:
ao sistema
{A-Z,a-z,0-9}
Usu_Nome
Caracter
15
Texto livre
Nome do usuário
Domínio: {A-Z,a-z}
Usu_Tipo
Caracter
1
A, B
A = coordenador
B = aluno
Usu_Cidade
Caracter
25
Texto livre
Cidade onde o usuário
Domínio: {A-Z,a-z} atua
Usu_Senha
Caracter
20
Texto livre
Senha
Domínio:
sistema
{A-Z,a-z,0-9}
de
acesso
ao
96
Tabela 11: Dicionário de dados da tabela de pacientes
Nome
Tipo
Tamanho
Conteúdo
Pac_Id
Numérico
64 bits
Domínio:
{1 - (2^63–1)}
Usu_id
Numérico
32 bits
Domínio:
{1- 2147483647}
Unique_Id
Numérico
32 bits
Domínio:
{1- 2147483647}
Descrição
Identificador
único
do
paciente
Relacionamento
externo
com a tabela de usuários
Identificador
PDA,
único
atribuído
no
pelo
PalmOS
Pac_Cehope
Numérico
32 bits
Domínio:
{1- 2147483647}
Pac_ImipID
Pac_Nome
Numérico
Caracter
32 bits
75
Domínio:
Numero do cadastro do
paciente no CEHOPE
Número do cadastro do
{1- 2147483647}
paciente no IMIP
Texto livre
Nome do Paciente
Domínio: {A-Z,a-z}
Pac_NomeMae
Caracter
75
Texto livre
Nome da mão do paciente
Domínio: {A-Z,a-z}
Pac_Sexo
Caracter
1
M, F
Pac_Dt_Adm
Data
8
Mm/dd/aa
Sexo do paciente
Data
de
admissão
do
paciente
Pac_Dt_Nacto
Data
8
Mm/dd/aa
Data de nascimento do
paciente
Pac_Dt_Entr
Data
8
Mm/dd/aa
Data
de
registro
do
paciente no sistema
Criado
Caracter
1
S, N
Utilizado para identificar
se o registro foi criado
depois
do
último
sincronismo
Modificado
Caracter
1
S, N
Utilizado para identificar
se
o
modificado
registro
depois
foi
do
97
último sincronismo
Apagado
Caracter
1
S, N
Utilizado para identificar
se o registro foi apagado
depois
do
sincronismo
último
98
Tabela 12: Dicionário de dados da tabela de consultas
Nome
Tipo
Tamanho
Conteúdo
Descrição
Cons_Id
Numérico
64 bits
Domínio:
Identificador único da
{1 - (2^63–1)}
Usu_Id
Numérico
32 bits
Domínio:
{1- 2147483647}
consulta
Relacionamento
externo com a tabela
de usuários
Pac_Id
Numérico
64 bits
Domínio:
{1 - (2^63–1)}
Relacionamento
externo com a tabela
de pacientes
Cons_Dt_Entr
Data
8
Mm/dd/aa
Data de cadastro da
consulta no sistema
Cons_Dt_Cons
Data
8
Mm/dd/aa
Data da consulta
Cons_Tipo
Caracter
25
Texto livre
Tipo da consulta
Domínio:
{A-Z,a-z,0-9}
Cons_Descricao
Caracter
255
Texto livre
Descrição da consulta
Domínio:
{A-Z,a-z,0-9}
Cons_Plano
Caracter
75
Texto livre
Plano de atendimento
Domínio:
{A-Z,a-z,0-9}
Cons_UniqueID
Numérico
32 bits
Domínio:
Identificador único no
{1- 2147483647}
PDA, atribuído pelo
PalmOS
Cons_Criado
Caracter
1
S, N
Utilizado
para
identificar
se
o
registro
foi
criado
depois
do
último
sincronismo
Cons_Modificado
Caracter
1
S, N
Utilizado
para
99
identificar
se
o
registro
foi
modificado depois do
último sincronismo
Cons_Apagado
Caracter
1
S, N
Utilizado
para
identificar
se
o
registro foi apagado
depois
do
sincronismo
último
100
Tabela 13: Dicionário de dados da tabela de diagnósticos
Nome
Tipo
Tamanho
Conteúdo
Descrição
Dx_Id
Numérico
64 bits
Domínio:
Identificador único da
{1 - (2^63–1)}
tabela de diagnósticos
Domínio:
Relacionamento
{1- 2147483647}
externo com a tabela
Usu_Id
Numérico
32 bits
de usuário
Pac_Id
Numérico
64 bits
Domínio:
Relacionamento
{1 - (2^63–1)}
externo com a tabela
de paciente
Dx_Data
Data
8
Mm/dd/aa
Data do diagnóstico
Dx_Dt_Entr
Data
8
Mm/dd/aa
Data de cadastro do
diagnóstico no
sistema
Dx_Descricao
Caracter
75
Texto livre
Descrição
do
Domínio:
diagnóstico
{A-Z,a-z,0-9}
Dx_Classe
Caracter
75
Texto livre
Classe do diagnóstico
Domínio:
{A-Z,a-z,0-9}
Dx_Prioridade
Dx_TipoEstad
Numérico
Caracter
8 bits
75
Domínio:
Prioridade
{1-127}
tratamento
Texto livre
de
Tipo de estadiamento
Domínio:
{A-Z,a-z,0-9}
Dx_Confirmado
Caracter
1
S, N
S
=
diagnóstico
confirmado
N
=
diagnóstico
suspeito
Dx_Ativo
Caracter
1
S, N
S = câncer ativo
N = câncer não ativo
101
Dx_UniqueId
Numérico
32 bits
Domínio:
Identificador único no
{1- 2147483647}
PDA, atribuído pelo
PalmOS
Dx_Criado
Caracter
1
S, N
Utilizado
para
identificar
se
o
registro
foi
criado
depois
do
último
sincronismo
Dx_Modificado
Caracter
1
S, N
Utilizado
para
identificar
se
o
registro
foi
modificado depois do
último sincronismo
Dx_Apagado
Caracter
1
S, N
Utilizado
para
identificar
se
o
registro foi apagado
depois
do
sincronismo
último
102
Tabela 14: Dicionário de dados da tabela de cirurgias
Nome
Tipo
Tamanho
Conteúdo
Descrição
Cir_Id
Numérico
64 bits
Domínio:
Identificador único da
{1 - (2^63–1)}
Usu_Id
Numérico
32 bits
Domínio:
{1- 2147483647}
cirurgia
Relacionamento
externo com a tabela
de usuários
Pac_Id
Numérico
64 bits
Domínio:
{1 - (2^63–1)}
Relacionamento
externo com a tabela
de pacientes
Cir_Dt_Entr
Data
8
Mm/dd/aa
Data de cadastro da
cirurgia no sistema
Cir_Data
Data
8
Mm/dd/aa
Cir_TeleTransm
Caracter
1
S, N
Data da cirurgia
S
=
cirurgia
transmitida
N
=
cirurgia
não
transmitida
Cir_Gravado
Caracter
1
S, N
S = cirurgia gravada
N
=
cirurgia
não
gravada
Cir_Asa
Cir_Porte
Numérico
Numérico
16 bits
16 bits
Domínio:
Envergadura
do
{1-32767}
paciente
Domínio:
Porte do paciente
{1-32767}
Cir_Cirurgião
Caracter
25
Texto livre
Nome do cirurgião
Domínio:{A-Z,a-z} que efetuou a cirurgia
Cir_CirResp
Caracter
25
Texto livre
Nome do cirurgião
Domínio:{A-Z,a-z} responsável
pela
cirurgia
Cir_Aux1
Caracter
25
Texto livre
Nome
do
primeiro
Domínio:{A-Z,a-z} auxiliar da cirurgia
103
Cir_Aux2
Caracter
25
Texto livre
Nome
do
segundo
Domínio:{A-Z,a-z} auxiliar da cirurgia
Cir_Anestesia
Caracter
25
Texto livre
Tipo de anestesia
Domínio:
{A-Z,a-z,0-9}
Cir_Anestesista
Caracter
25
Texto livre
Nome do anestesista
Domínio:{A-Z,a-z}
Cir_TpCir
Numerico
16 bits
Domínio:
Tempo de cirurgia
{1-32767}
Cir_TpAnest
Numerico
16 bits
Domínio:
Tempo de anestesia
{1-32767}
Cir_NomeCir
Caracter
255
Texto livre
Nome da cirurgia
Domínio:
{A-Z,a-z,0-9}
Cir_Indicacao
Caracter
255
Texto livre
Indicação da cirurgia
Domínio:
{A-Z,a-z,0-9}
Cir_Achado
Caracter
255
Texto livre
Achado
operatório
Domínio:
durante a cirurgia
{A-Z,a-z,0-9}
Cir_Clipagem
Caracter
255
Texto livre
Tipo
de
clipagem
Domínio:
utilizada na cirurgia
{A-Z,a-z,0-9}
Cir_Acidentes
Carácter
255
Texto livre
Acidentes
Domínio:
ocorreram durante a
{A-Z,a-z,0-9}
Cir_VolTransf
Cir_Sangram
Cir_Desc
Numerico
Numerico
Caracter
16 bits
16 bits
255
que
cirurgia
Domínio:
Volume de transfusão
{1-32767}
de sangue
Domínio:
Volume
{1-32767}
sangramento
Texto livre
Descrição da cirurgia
Domínio:
de
104
{A-Z,a-z,0-9}
Cir_GrauCont
Caracter
30
Texto livre
Grau
de
Domínio:
Contaminação
{A-Z,a-z,0-9}
Cir_UniqueID
Numerico
32 bits
Domínio:
Identificador único no
{1- 2147483647}
PDA, atribuído pelo
PalmOS
Cir_Criado
Caracter
1
S, N
Utilizado
para
identificar
se
o
registro
foi
criado
depois
do
último
sincronismo
Cir_Modificado
Caracter
1
S, N
Utilizado
para
identificar
se
o
registro
foi
modificado depois do
último sincronismo
Cir_Apagado
Caracter
1
S, N
Utilizado
para
identificar
se
o
registro foi apagado
depois
do
sincronismo
último
105
Tabela 15: Dicionário de dados da tabela de Dispositivos de acesso vascular
Nome
Tipo
Tamanho
Conteúdo
Descrição
DAV_Id
Numérico
64 bits
Domínio:
Identificador único da
{1 - (2^63–1)}
tabela de dispositivos
de acesso vascular
Usu_Id
Numérico
32 bits
Domínio:
{1- 2147483647}
Relacionamento
externo com a tabela
de usuários
Cir_Id
Numérico
64 bits
Domínio:
{1 - (2^63–1)}
Relacionamento
externo com a tabela
de cirurgias
DAV_DtEntr
Data
8
Mm/dd/aa
Data de cadastro do
implante
DAV_Data
Data
8
Mm/dd/aa
Data do implante
DAV_TipoDav
Caracter
25
Texto livre
Tipo de DAV
Domínio:
{A-Z,a-z,0-9}
DAV_Marca
Caracter
25
Texto livre
Marca do DAV
Domínio:
{A-Z,a-z,0-9}
DAV_Modelo
Caracter
25
Texto livre
Modelo do DAV
Domínio:
{A-Z,a-z,0-9}
DAV_Calibre
Caracter
10
Texto livre
Calibre do DAV
Domínio:
{A-Z,a-z,0-9}
DAV_CatPrev
Caracter
1
S, N
S
=
havia
outros
cateteres implantados
anteriormente
no
paciente
N
=
não
havia
106
cateteres implantados
no paciente
DAV_NbCatPrev
Numerico
8 bits
Domínio:
Número de cateteres
{1-127}
implantados
anteriormente
no
paciente
DAV_Febre24h
Caracter
1
S, N
S = ocorreu febre nas
24 horas posteriores
ao implante
N = não ocorreu febre
nas
24
horas
posteriores
ao
implante
DAV_DtEmog
Data
8
Mm/dd/aa
Data em que foi feito
o
exame
de
hemograma
DAV_Hg
Caracter
10
Texto livre
Exame
Domínio:
hemoglobina
de
{A-Z,a-z,0-9}
DAV_Neutrof
Caracter
10
Texto livre
Exame de neutrófilos
Domínio:
{A-Z,a-z,0-9}
DAV_Plaq
Caracter
10
Texto livre
Exame de plaquetas
Domínio:
{A-Z,a-z,0-9}
DAV_Ambiente
Caracter
25
Texto livre
Ambiente durante o
Domínio:
implante
{A-Z,a-z,0-9}
DAV_TpAcesso
Caracter
25
Texto livre
Tipo de acesso do
Domínio:
DAV
{A-Z,a-z,0-9}
DAV_LadoIns
Caracter
10
Texto livre
Lado de inserção do
107
Domínio:
DAV
{A-Z,a-z,0-9}
DAV_LocalIns
Caracter
25
Texto livre
Local de inserção do
Domínio:
DAV
{A-Z,a-z,0-9}
DAV_Vaso
Caracter
25
Texto livre
Vaso utilizado pelo
Domínio:
DAV
{A-Z,a-z,0-9}
DAV_PontaDAV
Caracter
25
Texto livre
Tipo da ponta do
Domínio:
DAV
{A-Z,a-z,0-9}
DAV_DtRetirada
Data
8
Mm/dd/aa
Data de retirada do
DAV
DAV_MotRetir
Caracter
75
Texto livre
Motivo de retirada do
Domínio:
DAV
{A-Z,a-z,0-9}
DAV_Obs
Caracter
75
Texto livre
Observações
gerais
Domínio:
sobre o implante
{A-Z,a-z,0-9}
DAV_UniqueId
Numerico
32 bits
Domínio:
Identificador único no
{1- 2147483647}
PDA, atribuído pelo
PalmOS
DAV_Criado
Caracter
1
S, N
Utilizado
para
identificar
se
o
registro
foi
criado
depois
do
último
sincronismo
DAV_Modificado
Caracter
1
S, N
Utilizado
identificar
para
se
registro
o
foi
modificado depois do
último sincronismo
108
DAV_Apagado
Caracter
1
S, N
Utilizado
para
identificar
se
o
registro foi apagado
depois
do
sincronismo
último
109
Tabela 16: Dicionário de dados da tabela de complicações do DAV
Nome
Tipo
Tamanho
Conteúdo
Descrição
Com_Id
Numérico
64 bits
Domínio:
Identificador único
{1 - (2^63–1)}
da
tabela
de
complicações
do
DAV
Usu_Id
Numérico
32 bits
Domínio:
{1- 2147483647}
Relacionamento
externo
com
a
tabela de usuários
Dav_Id
Numérico
64 bits
Domínio:
{1 - (2^63–1)}
Relacionamento
externo
com
a
tabela de DAV
Com_Data
Data
8
Mm/dd/aa
Data
da
complicação
Com_DtEntr
Data
8
Mm/dd/aa
Data de registro da
complicação
no
sistema
Com_Hemorr
Caracter
1
S, N
S
=
ocorreu
hemorragia
N = Não ocorreu
hemorragia
Com_Hemat
Caracter
1
S, N
S
=
ocorreu
hematoma
N = Não ocorreu
hematoma
Com_Desloc
Caracter
1
S, N
S
=
ocorreu
deslocamento
N = Não ocorreu
deslocamento
Com_Exterioriz
Caracter
1
S, N
S
=
ocorreu
exteriorização
do
110
DAV
N = não ocorreu
exteriorização
do
DAV
Com_Outras
Caracter
75
Texto livre
Outras
Domínio:
complicações
{A-Z,a-z,0-9}
Com_UniqueID
Numérico
32 bits
do
DAV
Domínio:
Identificador único
{1- 2147483647}
no PDA, atribuído
pelo PalmOS
Com_Criado
Caracter
1
S, N
Utilizado
identificar
para
se
o
registro foi criado
depois do último
sincronismo
Com_Modificado
Caracter
1
S, N
Utilizado
identificar
para
se
registro
o
foi
modificado depois
do
último
sincronismo
Com_Apagado
Caracter
1
S, N
Utilizado
identificar
para
se
o
registro foi apagado
depois do último
sincronismo
111
7
ANEXO II
RELATÓRIOS EMITIDOS PELO SISTEMA DE TELEMEDICINA NO ENSINO À
DISTÂNCIA
112
113
CPGEI – ENGENHARIA BIOMÉDICA
LABORTATÓRIO DE BIOINFORMÁTICA
RELATÓRIO DE DISCUSSÃO – RDISC
.
IDENTIFICAÇÃO DO PACIENTE
Nome: Calmon de Britto
Nome da mãe: Anunciata de Britto
CEHOPE: 3030
Sexo: Masc
IMIP: 3030
Data de Nascto: 17/01/61
DISCUSSÃO
Data/Hora do Relatório:
08/02/02 11:23:31
.
Data da discussão: 23/05/01
Discussão:
Parece-me ...
Classe: orientação
Corrigido? N
Problema Técnico? S
.
.
Paciente: Calmon de Britto
1/1
114
115
CPGEI – ENGENHARIA BIOMÉDICA
LABORTATÓRIO DE BIOINFORMÁTICA
RELATÓRIO DE CIRURGIA – RCIR
.
IDENTIFICAÇÃO DO PACIENTE
Nome: Calmon de Britto
Nome da mãe: Anunciata de Britto
CEHOPE: 3030
Sexo: Masc
IMIP: 3030
Data de Nascto: 17/01/61
Data/Hora do Relatório:
08/02/02 11:23:31
.
INFORMAÇÕES SOBRE A CIRURGIA
Teletransmitido?
Asa: I
N
Gravado? N
Data da cirurgia: 01/01/01
Porte da cirurgia: Pequena
Grau de contaminação: Limpa
Cirurgião: Jaime de Britto
Anestesia: Geral
Cirurgião responsável: Celso Vasconcelos
Anestesista: Maria Souza
Primeiro auxiliar: Joaquim dos Santos
Segundo auxiliar:
Relator: Jaime de Britto
Tempo de cirurgia: 89 minutos
Tempo de anestesia: 98 minutos
.
.
CIRURGIA
Nome da cirurgia realizada:
Cirurgia ....
Indicação da cirurgia:
Cirurgia aplicada devido ....
Achado operatório:
Não houve
Acidentes/complicações:
Não houveram
Transfusão: 897
Sangramento: 897
Descrição:
A cirurgia transcorreu ....
.
Paciente: Calmon de Britto
1/1
116
117
CPGEI – ENGENHARIA BIOMÉDICA
LABORTATÓRIO DE BIOINFORMÁTICA
RELATÓRIO GERAL – RGERAL
.
IDENTIFICAÇÃO DO PACIENTE
Nome: Calmon de Britto
Nome da mãe: Anunciata de Britto
CEHOPE: 3030
Sexo: Masc
IMIP: 3030
Data de Nascto: 17/01/61
Data/Hora do Relatório:
08/02/02 11:23:31
.
CONSULTAS
Data da consulta: 23/05/01
Tipo de consulta: Anatomia patológica
Descrição: Paciente apresentando....
.
Data da consulta: 22/05/01
Tipo de consulta: Outra imagem
Descrição: Paciente apresentando....
.
Data da consulta: 01/01/01
Tipo de consulta: Primeira hx e exame
Descrição: Paciente apresentando....
.
DIAGNÓSTICOS
.
Data do diagnóstico: 23/05/01
Classe: Benigno
Prioridade: 2
Estadio:
Tipo de estad: Não há
Confirmado? N
Ativo? N
Descrição: Tumor....
.
Data do diagnóstico: 23/05/01
Classe: Benigno
Prioridade: 2
Estadio:
Tipo de estad: Não há
Confirmado? N
Descrição: Tumor....
Ativo? N
.
.
Paciente: Calmon de Britto
1/2
118
119
.
.
CIRURGIAS
Data da cirurgia: 22/01/01
Asa: I
Gravado? N
Porte da cirurgia: Pequena
Teletransmitido? N
Grau de contaminação: Limpa
Cirurgião: Acimar Gonçalves
Anestesia: Geral
Cirurgião responsável: Celso Vasconcelos
Anestesista: João Osório
Primeiro auxiliar: Jaime de Britto
Segundo auxiliar: José da Silva
Relator: Jaime de Britto
Tempo de cirurgia: 95 minutos
Tempo de anestesia: 118 minutos
Nome da cirurgia realizada: Cirurgia ....
Data da cirurgia: 22/01/01
Asa: I
Gravado? N
Porte da cirurgia: Pequena
Cirurgião: Jaime de Britto
.
Teletransmitido? N
Grau de contaminação: Limpa
Anestesia: Geral
Cirurgião responsável: Celso Vasconcelos
Anestesista: Maria Souza
Primeiro auxiliar: Joaquim dos Santos
Segundo auxiliar:
Relator: Jaime de Britto
Tempo de cirurgia: 89 minutos
Tempo de anestesia: 98 minutos
Nome da cirurgia realizada: Cirurgia ....
.
.
DISCUSSÃO
Data da discussão: 23/05/01
Classe: orientação
Corrigido? N
Problema Técnico? N
Discussão:
Deve-se solicitar ...
.
Data da discussão: 23/05/01
Classe: orientação
Corrigido? N
Problema Técnico? S
Discussão:
Parece-me ...
.
.
Paciente: Calmon de Britto
2/2
120
121
CPGEI – ENGENHARIA BIOMÉDICA
LABORTATÓRIO DE BIOINFORMÁTICA
LISTA DE TODAS AS CIRURGIAS DO ESPECIALISTA
IDENTIFICAÇÃO DO ESPECIALISTA
.
Nome: Jaime de Britto
Data/Hora do Relatório:
08/02/02 11:23:31
CIRURGIAS EM PARTICIPOU COMO CIRURGIÃO
.
.
Cehope: 3030
Imip: 3030
Nome da cirurgia: Cirurgia ....
.
CIRURGIAS EM PARTICIPOU COMO PRIMEIRO AUXILIAR
.
Cehope: 6458
Imip: 3523
Nome da cirurgia: Cirurgia para....
.
.
Paciente: Calmon de Britto
1/1
122
123
CPGEI – ENGENHARIA BIOMÉDICA
LABORTATÓRIO DE BIOINFORMÁTICA
RELATÓRIO DE CONSULTA – RCONS
.
IDENTIFICAÇÃO DO PACIENTE
Nome: Calmon de Britto
Nome da mãe: Anunciata de Britto
CEHOPE: 3030
Sexo: Masc
IMIP: 3030
Data de Nascto: 17/01/61
ANAMNESE
Data/Hora do Relatório:
08/02/02 11:23:31
.
Data da consulta: 01/01/01
Tipo de consulta: Primeira hx e exame
Descrição: Paciente queixou-se....
Plano:
Aplicação ....
.
.
Paciente: Calmon de Britto
1/1
124
125
CPGEI – ENGENHARIA BIOMÉDICA
LABORTATÓRIO DE BIOINFORMÁTICA
RELATÓRIO DE TODAS AS CONSULTAS DO PACIENTE
IDENTIFICAÇÃO DO PACIENTE
.
Nome: Calmon de Britto
Nome da mãe: Anunciata de Britto
CEHOPE: 3030
Sexo: Masc
IMIP: 3030
Data de Nascto: 17/01/61
Data/Hora do Relatório:
08/02/02 11:23:31
Data da consulta: 23/05/01
Tipo de consulta: Anatomia patológica
Descrição: Paciente apresentando....
Plano:
O tratamento ....
.
Data da consulta: 22/05/01
Tipo de consulta: Outra imagem
Descrição: Paciente apresentando....
Plano:
O tratamento ....
.
Data da consulta: 01/01/01
Tipo de consulta: Primeira hx e exame
Descrição: Paciente queixou-se....
Plano:
Aplicação ....
.
.
Paciente: Calmon de Britto
1/1
126
127
CPGEI – ENGENHARIA BIOMÉDICA
LABORTATÓRIO DE BIOINFORMÁTICA
RELATÓRIO POR TIPO DE CONSULTA – RTIPOCONS
IDENTIFICAÇÃO DO PACIENTE
.
Nome: Calmon de Britto
Nome da mãe: Anunciata de Britto
CEHOPE: 3030
Sexo: Masc
IMIP: 3030
Data de Nascto: 17/01/61
Data/Hora do Relatório:
08/02/02 11:23:31
Data da consulta: 01/01/01
Tipo de consulta: Primeira hx e exame
Descrição: Paciente queixou-se....
Plano:
Aplicação ....
.
.
Paciente: Calmon de Britto
1/1
128
129
CPGEI – ENGENHARIA BIOMÉDICA
LABORTATÓRIO DE BIOINFORMÁTICA
RELATÓRIO DE DISCUSSÃO – RDISC
.
IDENTIFICAÇÃO DO PACIENTE
Nome: Calmon de Britto
Nome da mãe: Anunciata de Britto
CEHOPE: 3030
Sexo: Masc
IMIP: 3030
Data de Nascto: 17/01/61
Data/Hora do Relatório:
08/02/02 11:23:31
.
ADENDUM
Data do diagnóstico: 23/05/01
Descrição:
Tumor ....
Classe: Benigno
Prioridade: 2
Estadio:
Tipo de estad: Não há
Confirmado? N
Ativo? N
.
.
Paciente: Calmon de Britto
1/1
130
131
8
ANEXO III
MANUAL DE INSTALAÇÃO DO PALM-TUTOR
132
133
MANUAL DE INSTALAÇÃO
CEFET-PR
134
APRESENTAÇÃO
-
Palm é marca registrada da Palm Inc. e neste manual representa todos os dispositivos
PDA (Personal Digital Assistance) compatíveis com o sistema operacional PalmOS.
-
Windows é marca registrada da Microsoft Co. e neste manual representa a família de
sistemas operacionais desta plataforma para computadores pessoais e corporativos.
O sistema de telemedicina é composto de cinco módulos:
•
Base de dados centralizada em um servidor na Internet;
•
Um módulo servidor de aplicação que provê a conexão do sistema cliente com
a base centralizada;
•
Uma versão do módulo cliente para Palm (PDA);
•
Uma versão do módulo cliente para Desktop (computador pessoal);
•
Um módulo de sincronismo entre o Palm e a base de dados centralizada
(servidor);
Este manual contempla a instalação dos módulos:
•
Cliente para Desktop;
•
Módulo de sincronismo entre o Palm e o servidor;
A Base de dados e o módulo servidor são instalados e mantidos por um administrador
do sistema, não havendo portanto necessidade de distribuição do sistema.
O módulo cliente para Palm será distribuído separadamente.
REQUISITOS MÍNIMOS PARA OS MÓDULOS CONTEMPLADOS POR
ESTE MANUAL:
•
Processador Pentium;
•
64 Mb de memória Ram;
135
•
Acesso à Internet;
•
Software Palm desktop instalado;
•
Sistema Operacional:
o Windows 98 ou superior;
o Windows NT 4.0;
o Windows 2000;
o Windows XP.
136
INSTALANDO O SISTEMA
1) No Windows, execute o Explorer;
2) Procure pelo arquivo “Setup.exe” na mídia de distribuição do sistema;
3) Clique duas vezes com o botão esquerdo do mouse neste arquivo para iniciar a
instalação;
4) Aparecerá a seguinte caixa de mensagem, clique no botão “Next” para continuar;
137
5) Na próxima caixa de mensagem, é possível selecionar o diretório onde será instalado o
sistema. O diretório padrão de instalação é “C:\Arquivos de Programas\CEFETPR\Telemedicina”, caso deseje escolher outro diretório clique no botão “Browse”,
caso contrário clique no botão “Next”;
Atenção: Caso a intenção seja instalar a aplicação de sincronismo entre o Palm o
servidor, tome nota do caminho completo do diretório escolhido para posterior
configuração do sistema.
6) Selecione o tipo de instalação e clique no botão “Next”, considerando que a opção:
a) “Typical” instala o sistema completo (a versão do sistema para desktop e a
aplicação de sincronismo entre o Palm e o servidor);
b) “Compact” instala apenas a versão do sistema para desktop;
c) “Custom” permite selecionar quais módulos serão instalados;
138
7) Digite o nome do grupo de programas que aparecerá no menu Iniciar do Windows;
8) A caixa de diálogo a seguir apresenta um resumo das escolhas feitas durante a
instalação, confira estas informações e, se concordar, clique no botão “Next” para
iniciar a cópia dos arquivos para seu computador, caso contrário, clique no botão
“Back” para retornar até o ponto desejado e refazer a escolha desejada;
139
9) O sistema será instalado e configurado em seu computador, ao final aparecerá a
seguinte caixa de diálogo, clique em “Finish” para encerrar a instalação;
10) Caso tenha selecionada a opção “Typical” ou na opção “Custom” tenha escolhido
instalar o módulo de sincronismo entre o Palm e o servidor, será necessário registrar o
140
conduit de sincronismo e configurar o usuário de sincronismo, para maiores
informações veja as seções “Registrando o conduit de sincronismo” e “Configurando o
usuário de sincronismo” a seguir.
141
REGISTRANDO O CONDUIT DE SINCRONISMO
1) Clique no botão Iniciar do Windows, em seguida selecione o grupo do sistema
Telemedicina e então, a opção “Configuração do Conduit”;
2) Na janela a seguir, clique no botão “Add...”;
142
3) Na Caixa de texto “Conduit”, digite o diretório de instalação do sistema, seguido por
“\Sinc_Telem.dll”. Por exemplo, se o sistema foi instalado no diretório
“C:\Telemedicina”, você deve digitar “C:\Telemedicina\Sinc_Telem.dll”;
4) Na caixa de texto “Creator ID”, digite “TMED”, todas as letras maiúsculas;
143
5) Na caixa de texto “Name”, digite “Telemedicina” e em seguida, clique no botão “Ok”;
6) O conduit deve aparecer na lista de conduits registrados, clique em “Exit” para
encerrar o registro do conduit.
144
CONFIGURANDO A FORMA DE SINCRONISMO
1) Na barra de tarefas, clique no ícone “Hotsync” e em seguida selecione a opção
“Custom...”;
2) Clique duas vezes no conduit “Telemedicina”;
145
3) Selecione a opção “Synchronise the files” e em seguida clique no botão “Ok”;
4) Clique no botão “Done” para encerrar a configuração do conduit.
146
CONFIGURANDO O USUÁRIO DE SINCRONISMO
1) Clique no botão Iniciar do Windows, em seguida selecione o grupo do sistema
Telemedicina e então, a opção “Configuração do usuário”;
2) Na caixa de texto “Usuário”, digite o usuário que foi fornecido junto com os arquivos
de instalação do sistema e em seguida clique em “Ok”.
SINCRONIZANDO O PALM COM O SERVIDOR NA INTERNET
147
Após instalado e configurado o conduit, a sincronização é automática, bastando
pressionar o botão de Hotsync de seu craddle. Durante o sincronismo, o sistema tentará
estabelecer uma conexão Dial-Up (conexão com a internet), caso ela não esteja estabelecida.
Selecione o provedor de acesso à internet que desejar e em seguida clique no botão
“Conectar”. Caso não deseje sincronizar os dados do sistema de Telemedicina, clique no
botão “Cancelar”, entretanto, recomenda-se que a sincronização do sistema de Telemedicina
seja feita diariamente.
148
ACESSANDO A VERSÃO DO SISTEMA DE TELEMEDICINA PARA
DESKTOP
1) Clique no botão Iniciar do Windows, em seguida selecione o grupo do sistema
Telemedicina e então, o atalho “Telemedicina”;
2) O sistema tentará estabelecer uma conexão Dial-Up (conexão com a internet), caso ela
não esteja estabelecida. Selecione o provedor de acesso à internet que desejar e em
seguida clique no botão “Conectar”.
149
3) Digite o usuário e a senha fornecidos com os arquivos de instalação do sistema e em
seguida clique no botão “OK”.
150
151
9
ANEXO IV
AVALIAÇÃO FORMATIVA DO SISTEMA PALM-TUTOR, EFETUADA PELO
COORDENADOR DO PROGRAMA INTERNATIONAL OUTREACH NO BRASIL
152
153
DECLARAÇÃO
Declaro para os devidos fins que fui usuário na fase Beta-teste de software
desenvolvido pelo mestrando Jaime Brito, desenhado para ser utilizado em um ambiente de
ensino a distância com coletas de informações na plataforma Palm, sincronização com banco
de dados através da Internet em servidor remoto e acesso destas informações do banco de
dados através de software desenvolvido para desktop na plataforma Windows.
Informo que achei os três componentes do sistema (Palm, sincronização e desktop)
funcionais de forma que cumpre com as necessidades e resolve as dificuldades encontradas
até então. As principais dificuldades eram que o especializando (do curso de ensino a
distância) tinha que repetir coleta de informações duas vezes (uma no prontuário médico do
seu hospital e outra nos formulários do programa de ensino a distância). O orientador a
distância recebia os formulários e digitava todas as informações em um banco de dados.
Portanto a mesma informação era processada 3 vezes. Com o sistema desenvolvido pelo
mestrando Jaime Brito, o especializando coletará informação apenas uma vez, diretamente no
Palm, fará a sincronização com o banco de dados remoto, e então, utilizando o aplicativo do
desktop poderá imprimir relatórios para ser utilizado no prontuário médico do hospital local.
O orientador a distância tem acesso a estas informações automaticamente. Elimina-se o
preenchimento dos formulários para ensino a distância e o trabalho do orientador em digitar
as informações no banco de dados. Este sistema diminuirá para 1/3 as atividades de coleta e
armazenamento de informação de ensino a distância. O sistema também disponibiliza campo
para discussão acadêmica, facilitando a interação entre o especializando e orientador na forma
assincrônica (modelo store-forward).
Este sistema foi utilizado por mim por um período de 2 meses onde foram depurados
alguns pequenos problemas e está inteiramente funcional. Ele tem uma fácil navegação, que é
intuitiva tanto no Palm quanto no Desktop. No entanto o sistema ainda não foi testado com o
especializando a distância, para completar os últimos ajustes, se fizer necessário.
154
Gostaria de reafirmar que o sistema desenvolvido pelo mestrando Jaime Brito tem o
potencial de trazer um grande acréscimo no programa de ensino à distância envolvendo
médicos e o sistema PBL. Saliento ainda que é de minha opinião que o sistema tem
funcionalidade suficiente para ser utilizado para ensino a distância em outras especialidades
médicas ou não médicas.
Por ser verdade, dato e dou fé,
Curitiba, 07 de Fevereiro de 2002.
Dr. Edson L. Michalkiewicz, MSc.
Cirurgia Oncológica Pediátrica
Orientador do Programa de Ensino a distância em Cirurgia Oncológica Pediátrica.
155
10 REFERÊNCIAS BIBLIOGRÁFICAS
ARANHA, M. L. A. Filosofia da Educação. 2 ed. São Paulo: Editora Moderna, 1996.
BASS, S. G., Wireless computing: medical students and mobile medicine. MD Computing,
v. 17, p. 27, 2000.
CAMBI, F. História da Pedagogia. 1 ed. São Paulo: UNESP, 1999.
CHAVES, E. Conceitos Básicos: Educação a Distância. EdutecNet: Rede de Tecnologia na
Educação, 1999. http://www.edutecnet.com.br/.
CHESSANOW, N., PDAs for Doctors: Know your needs, pick a device to fit. Med
Economics, v. 77, p. 81-88, 2000.
DUNCAN, R. G., SHABOT, M. M. An enterprise web viewing system for clinical and
administrative data. Proceedings of the AMIA Symposium, Los Angeles, p. 1169,
Nov, 4–8, 2000a.
DUNCAN, R. G., SHABOT, M. M. Secure remote access to a clinical data repository using a
wireless personal digital assistant (PDA). Proceedings of the AMIA Symposium,
Los Angeles, p. 210-214, Nov, 4–8, 2000b.
EMBI, P. J. Information at hand: Using handheld computers in medicine. Cleveland Clinic
Journal Of Medicine, v. 68, n. 10, p. 840, Oct. 2001.
EBELL, M. H., BARRY, H. C., InfoRetriever: rapid access to evidence-based information on
a handheld computer. MD Computing, v. 15, p. 289-297, 1998.
GADOTTI, M. História das Idéias Pedagógicas. 3 ed. São Paulo: Ática, 1995.
GRIMES R. Professional DCOM Programming, Olton, Birmingham, Canada: Wrox Press,
1997.
GUARANYS, L .R., CASTRO, C.M. O ensino por correspondência: uma estratégia de
desenvolvimento educacional no Brasil. Brasília: IPEA, 1990.
HISTÓRIA
DA
TELEMEDICINA.
http://www.virtual.epm.br/material/tis/curr-
med/temas/med5/med5t12000/tele/hist_ria_da_telemedicina.html. (Fev/2002).
HO, W. L., FORMAN, J., KANNRY, J. Portable digital assistant use in a medicine teaching
program. Proceedings of the AMIA Symposium, Los Angeles, p. 1031, Nov, 4–8,
2000.
156
KEEGAN, S.D; HOLMBERG B.; MOORE, M,; PETERS, O.; DOHMEM, G. Distance
Education International Perspectives. London: Routllege, 1991.
KEEGAN, D. Foundations of Distance Education. 2nd edition. London: Routledge, 1991.
KOHN, L. T., CORRIGAN, J. M., DONALSON, M. S. To err is human: building a safer
health care system. Institute of Medicine Report. Washington DC: National
Academy Press, Nov, 29, 1999.
KOMOSINSKI, L. J. Um Novo Significado para a Educação Tecnológica Fundamentado
na Informática como Artefato Mediador da Aprendizagem. Tese de Doutorado
(Programa de Pós-Graduação em Engenharia de Produção) – Universidade Federal de
Santa Catarina, Florianópolis (SC), 2000, 146 p.
LAPINSKY, S., MEHTA, S., VARKUL, M., STEWART, T. Qualitative analysis of handheld
computers in critical care. Proceedings of the AMIA Symposium, Los Angeles, p.
1060, Nov, 4–8, 2000.
KAUFMAN, D. Developing tutoring skills in Problem-Based Learning. Workshop
presented to faculty at the Catholic University of Paraná, Curitiba, Mar, 1998.
KUDZO. Chad's Kudzu World. http://www.hower.org/Kudzu/ (Jan/2002).
MACERATINI, R., SABBATINI, R. Telemedicina: A Nova Revolução. Revista
Informédica, v. 1, n. 6, p. 5-9, Mar. 1994.
MCCORMACK, C., JONES, D. Building a Web-Based Education System. Wiley, 1997.
MERKLE, L. E. O interagir Humano-Computacional: mapeando relações heterodisciplinares.
Revista da Ciência da Informação, v. 1, n. 2, p. ?-?, Abril, 2000.
MOORE, M., KEARSLEY, G. Distance Education: a Systems View. Belmont (USA):
Wadsworth Publishing Company, 1996, 290 p.
MOORE,
K.
Audioconferencing
in
Distance
Education.
http://www.knight-
moore.com/html/ajde8-1.html. (Dez/2001).
O'NEIL, M. C., WRIGHT A. Problem-Based Learning. Focus on University Teaching and
Learning, v. 5, n. 2, p. 1-4, Nov./Dec., 1995.
OSTWALD, M..J, CHEN, S. E., VARMAN, B., Mc GEORGE, W .D. The application of
problem-based learning to distance education. In: Distance Education for the
Twenty-First Century. 1st ed., Brisbane: ICDE and QUT Press, cap. 4, p. 300-305,
1993.
157
PALM COMPUTING INC. Developing Enterprise Applications for the Palm Computing.
Article ID: 1128,
March
2000.
Disponível
em:
http://oasis.palm.com/dev/kb/papers/1128.cfm. Acesso em: 10-04-2001a.
PALM COMPUTING INC. Palm OS® Memory and Database Management.
Article ID: 2029,
February
2001.
Disponível
em:
http://oasis.palm.com/dev/kb/papers/2029.cfm#header. Acesso em: 12-04-2001b.
PALM COMPUTING INC. HotSync 3.0 & Conduits. Article ID: 1138, June 2000.
Disponível em: http://oasis.palm.com/dev/kb/papers/1138.cfm#header. Acesso em 1204-2001c.
PBL.
Problem
Based
Learning-
Centro
de
Ciências
da
Saúde
–
UEL.
http://www.uel.br/ccs/pbl/GERAL.HTM (Fev/2002).
PIOLA, G. Aprendiz. http://www.uol.com.br/aprendiz/n_colunas/g_piolla/id270301.htm
(Fev/2002).
RHODES, N.; McKEEHAND, J. Palm™ Programming: The Developer’s Guide. 2nd Ed.,
Cambridge: O’Reilly & Associates, p. 63-79, 2001.
RNP2. O projeto Internet2. http://www.rnp.br/rnp2/rnp2-internet2.html. (Fev/2002).
ROGERSON, D. Inside COM, Washington: Microsoft Press, 1996.
ROTHSCHILD, J. M., LEE, T.H., BAE, T., YAMAMOTO, R., HORSKY, J., BATES, D.
W., Survey of physicians’ experience using a handheld drug reference guide.
Proceedings of the AMIA Symposium, Los Angeles, p. 1125, Nov, 4–8, 2000.
SABBATINI, R. Na palma da mão. Jornal Correio Popular, Campinas, Brasil, 17-12-1999.
SANTOS, N., Educação à distância e as novas tecnologias de Informação e
Aprendizagem.
http://www.engenheiro2001.org.br/programas/980201a2.htm.
(Dez/2001).
SHABOT, M. M., LOBUE, M., CHEN, J. Wireless clinical alerts for physiologic, laboratory
and medication data. Proceedings of the AMIA Symposium, Los Angeles, p. 789793, Nov, 4–8, 2000.
STOEFFLER, W. Palm Sized Computer Operating Systems: Windows CE vs. Palm OS:
an Objective Comparison. Disponível em: http://www.edecap.com/white.htm.
Acesso em: 20-04-2001.
158
THE JOHNS HOPKINS UNIVERSITY SCHOOL OF HYGIENE AND PUBLIC HEALTH.
A Faculty Resource Guide to DIstance Learning at the School of Hygiene and Public
Health, 1997. http://distance.jhsph.edu/more/DisEdFacGuide.pdf (Fev.2002)
WEBOPEDIA: Online Dictionary for Computer and Internet Terms. Disponível por WWW
em http://webopedia.internet.com/. (Jan. 2002).
WIEGLER, W., DONHAM, P. Cu-SeeMe 3.1 – User Guide. WHITE PINE Softwares,
1998.
WOFFORD, M. M., SECAN, R., HERMAN, C., MORAN, W. P., WOFFORD, J. L. Clinical
documentation: the handheld computer as a survival tool. MD Computing, v.15, p.
352-354, 1998.