SISTEMA DE MARCAÇÃO E CONTROLE

DE CONSULTAS PARA ATENDIMENTO NO

HOSPITAL CENTRAL DO EXÉRCITO
SIMCC – HCE

MANUAL DO SISTEMA
VERSÃO 1.0.0

Rio de Janeiro
2011
Sumário
CAPÍTULO 1 – INTRODUÇÃO.........................................................................................................3
1.1 – Motivação...............................................................................................................................3
1.2 – SIMCC: Apresentação............................................................................................................3
CAPÍTULO 2 – TECNOLOGIAS UTILIZADAS...............................................................................5
2.1 – Sistema Ubuntu Server ..........................................................................................................5
2.2 – Linguagem PHP......................................................................................................................5
2.3 – Banco de dados Oracle...........................................................................................................6
2.4 – Framework CodeIgniter..........................................................................................................6
2.5 – Biblioteca jQuery....................................................................................................................6
CAPÍTULO 3 – O SISTEMA DE MARCAÇÃO E CONTROLE DE CONSULTAS........................7
3.1 – Arquitetura e estrutura do sistema..........................................................................................7
3.2 – Requisitos mínimos.................................................................................................................9
3.3 – Procedimento de instalação e configuração............................................................................9
3.3.1 – Preparação do ambiente base........................................................................................10
3.3.2 – Instalação do sistema.....................................................................................................12
3.3.3 – Configuração do sistema...............................................................................................13
3.4 – Integração com o banco de dados.........................................................................................14
3.4.1 – Ajustes de chamadas a procedimentos..........................................................................14
3.4.2 – Ajuste de chamadas a esquemas de dados distintos......................................................17
3.4.3 – O método simple_stored_procedure.............................................................................18
3.4.4 – O método display_error_friendly..................................................................................19
3.4.5 – Carga de especialidades................................................................................................19
3.5 – Procedimentos de manutenção e backup..............................................................................20
CAPÍTULO 4 – SOLUÇÃO DE PROBLEMAS...............................................................................21
4.1 – Problemas comuns................................................................................................................21
4.2 – Problemas conhecidos...........................................................................................................22
CAPÍTULO 5 – REFERÊNCIAS......................................................................................................23
APÊNDICE........................................................................................................................................24
- Diagrama de classe do sistema....................................................................................................24
CAPÍTULO 1 – INTRODUÇÃO

1.1 – Motivação
O Hospital Central do Exército – HCE é uma instituição bicentenária, responsável pelo
atendimento médico da comunidade militar na região do Rio de Janeiro, muito bem referenciada
pela sua qualificada equipe médica.

Com o passar do tempo a demanda por atendimento no HCE cresceu e, por uma série de
fatores, hoje acaba por gerar uma sobrecarga nos setores de atendimento. Essa demanda excessiva
faz com que os pacientes não sejam prontamente atendidos e piora as condições de trabalhos dos
setores que atendem diretamente o público.

A direção do HCE, ciente desse panorama, deseja modificá-lo. A primeira medida é fazer
com que a marcação de consultas para as clínicas do hospital sejam realizadas nas Policlínicas
Militares. As Policlínicas Militares são células de atendimento de primeiro nível que tem áreas bem
definidas de atuação. Essas áreas foram concebidas de forma a distribuir a demanda, evitando o
estrangulamento de qualquer ponto do sistema de atendimento. A marcação de consultas nas
Policlínicas, além de desonerar o HCE deste serviço, proporcionará uma maior comodidade aos
pacientes, pois estes agora poderão agendar suas consultas mais perto de casa, sem ter que se
deslocar até o Hospital.

A marcação de consultas será feita na forma de distribuição de senhas para uma certa
especialidade em uma determinada data. O objetivo deste projeto é o de viabilizar a geração dessas
senhas por parte das Policlínicas sob determinados critérios e de acordo com a disponibilidade do
hospital.

1.2 – SIMCC: Apresentação

O Sistema de Marcação e Controle de Consultas – SIMCC foi concebido de forma a

possibilitar a geração de senhas a partir das Policlínicas Militares atendendo a uma série de
requisitos. São eles:

– O sistema deveria ser web de forma a possibilitar de maneira fácil o seu uso pelas diversas
policlínicas.

3
 – O sistema só poderia se acessado mediante login, que identificasse todo e qualquer agente
que estivesse operando o sistema. Esse agente deveria ter uma associação com sua unidade
de origem (funcionário do HCE ou de uma das policlínicas).

– O sistema deveria ter 3 perfis de usuário: Super Administrador, Administrador e atendente,

com permissões distintas.

– O sistema deveria carregar a disponibilidade das consultas a partir do banco de dados do

sistema de gerencia já em operação no HCE.

– O sistema não deveria registrar qualquer informação a respeito do médico que fará um
determinado atendimento, uma vez que sempre será agendada uma consulta para uma
determinada especialidade em uma data especificada.

– O sistema deveria carregar as informações do usuário na tela de forma que um atendente

pudesse fazer uma validação, certificando-se de que aquele prontuário carregado realmente
pertence ao usuário em questão, minimizando ao máximo o problema com homônimos.

– Para o caso de pacientes sem prontuário no HCE o sistema deveria possibilitar um pré-
cadastramento, com o respectivo agendamento. O comprovante de agendamento deveria
indicar ao paciente a necessidade de comparecer um pouco mais cedo para efetuar o seu
cadastramento e consequente registro de prontuário.

– O sistema deveria prover uma forma de consultar, ou mesmo imprimir, a agenda de

atendimentos do dia.

– O sistema deveria permitir o cadastramento de usuário e unidades. As especialidades

deveriam ser carregadas do banco de dados da aplicação já existente.

– O sistema deveria possibilitar a alocação dinâmica e priorização de vagas para as diversas

unidades.

– O sistema deveria fornecer alguns tipos de relatórios gerenciais.

Todos os requisitos foram atendidos na implementação do sistema, viabilizando a um

paciente a marcação de consulta na unidade mais próxima de sua casa.

4
CAPÍTULO 2 – TECNOLOGIAS UTILIZADAS

2.1 – Sistema Ubuntu Server

Sistema Linux amplamente utilizado em

sua versão Desktop. A sua adoção nas
plataformas corporativas caminha a passos
largos, sendo que essa distribuição conta com o
suporte da empresa Canonical. É um sistema totalmente Open Source, sendo os seus softwares
componentes distribuídos nas mais diversas licenças. O sistema passou por um procedimento de
configuração para a instalação dos componentes que permitem ao servidor efetuar conexões com
bancos de dados Oracle (funcionalidade não nativa devida a questões de licenciamento). A versão
do sistema utilizada foi a 10.04 LTS com suporte oficial disponível até abril de 2015.

2.2 – Linguagem PHP

Linguagem de desenvolvimento
interpretada no servidor, orientada a objeto e
voltada para aplicações web permitindo torná-las
mais dinâmicas. Esta linguagem atualmente é
utilizada por muitos sites importantes o que
proporciona uma confiabilidade em alto nível. Frequentemente, a equipe mantenedora da mesma
libera atualizações e correções de erros, estas características diminuem o risco da linguagem ser
descontinuada. Além disso, existem vários frameworks que implementam funções que facilitam de
maneira considerável o desenvolvimento de ferramentas mais complexas sem a necessidade de se
dispor de muito tempo e esforço. O PHP é distribuído sob a licença PHP Licence v3.01 que é
considerada uma licença de código aberto (Open Source), certificada pela Open Source Initiative. A
versão do PHP utilizada é a 5.3.

5
2.3 – Banco de dados Oracle

Sistema gerenciador de banco de dados mais

utilizado em âmbito corporativo. Detêm o estado da
arte das tecnologias relacionadas aos mais diversos
tipos de banco de dados, desde os que servem à
sistemas de informação até aqueles que tratam de dados espaciais. O banco de dados Oracle foi
adotado nesse projeto pois é o banco utilizado pelo HCE, em sua versão 10g Enterprise.

2.4 – Framework CodeIgniter

O CodeIgniter é um conjunto de bibliotecas que

permitem o desenvolvimento de sistemas complexos
em conformidade com o padrão MVC (Model-View-
Controller) com grande agilidade e segurança. Ele
possui extensa documentação e é compatível com
uma grande variedade de configurações de
servidores PHP, sendo também compatível com
diversos banco de dados. O CodeIgniter é considerado uma ferramenta Open Source regida pelo
CodeIgniter Licence Agreement disponível em http://codeigniter.com/user_guide/license.html. O
sistema foi desenvolvido na versão 2.1.0 do framework.

2.5 – Biblioteca jQuery

A jQuery é uma biblioteca na linguagem

JavaScript que simplifica a confecção de páginas
com características dinâmicas, ou seja, que
apresentam eventos em tempo real como animações e
formulários inteligentes. O sistema foi desenvolvido
com a versão 1.6.2 da biblioteca, que é licenciada sob
a GPLv2, sendo considerada Open Source.

6
CAPÍTULO 3 – O SISTEMA DE MARCAÇÃO E CONTROLE DE CONSULTAS

3.1 – Arquitetura e estrutura do sistema

O sistema de Marcação e Controle de Consultas foi concebido com a utilização do

framework CodeIgniter. Este framework implementa o padrão MVC (Model-View-Controller)
separando as classes de Modelo, de Interface e Controladoras de forma bem definida. Abaixo a
estrutura do framework e da aplicação:

As classes do sistema são colocadas nos diretórios

controllers, models e views contidos na pasta
application.

As configurações do sistema são realizadas na pasta

config (principalmente nos arquivos config.php e
database.php).

Toda a aparência do sistema é definida nos arquivos

contidos na pasta template.

A pasta logs armazena as ações da aplicação de acordo

com a configuração definida no arquivo config.php.

Outros arquivos modificados e/ou criados, estendendo o

framework, para o funcionamento do sistema:

../core/MY_Controller.php
../helpers/utils_helper.php
../libraries/authentication.php

7
A pasta controllers tem os controladores das funções do
sistema. Eles são responsáveis por receber as
solicitações das views, solicitar os dados pertinentes aos
respectivos models e retornar para as views. Cada
controlador é nomeado de acordo com a sua função e
estendem a classe My_Controller.

A pasta models tem as classes de modelo do sistema.

Elas são responsáveis por interagir com o banco de
dados. As classes de modelo estendem a classe
CI_Model.

A pasta views tem as classes de visualização ou

interface do sistema. Elas são responsáveis por interagir
com o usuário e invocar os respectivos controladores.
Bem como receber os dados resultantes do
processamento e exibi-los.

8
 Falando da arquitetura em termos de escopo externo, temos basicamente um servidor de
aplicação que recebe requisições dos clientes através de um endereço de internet e que se comunica
com o servidor de banco de dados para atendê-las. O diagrama abaixo ilustra a arquitetura da
solução:

Figura: Diagrama da arquitetura básica do sistema SIMCC

3.2 – Requisitos mínimos

O sistema SIMCC é extremamente leve. Para uma demanda de 10 a 15 máquinas um

servidor com 1.0 GHz de frequência, 1 GB de RAM e 30 GB de HD é suficiente. Com o aumento
do número de cliente pode ser necessária uma expansão.

3.3 – Procedimento de instalação e configuração

Todo o processo de desenvolvimento e testes do sistema foi realizado na plataforma Linux,

por isso as instruções de instalação são para esta plataforma, embora não seja complicado
configurar um ambiente para a plataforma Windows. Só para referência, na plataforma Windows
seria necessário:

9
 – Instalar um ambiente com Apache e PHP para Windows. O XAMP é uma das opções.
– Instalar o Oracle Instant Client 10.2 ou superior.
– Procurar o arquivo "php_oci8.dll" e colocar o diretório onde encontrá-lo no PATH do
sistema.
– Procurar o arquivo "php.ini" do XAMP e colocar (ou "descomentar") a linha
"extension=php_oci8.dll”.
– Reiniciar o XAMP.
– Acessar o endereço: http://localhost/xampp/phpinfo.php e certificar-se que o driver "oci8"
aparece na lista de módulos suportados.
Nas condições acima o ambiente estará apto a executar o SIMCC.
As seções seguintes descrevem em detalhes o procedimento de instalação para o sistema
Ubuntu Server 10.04.3 LTS de 64 bits.

3.3.1 – Preparação do ambiente base

– Instale o Apache, o suporte a PHP e as ferramentas de compilação básicas:

$ sudo apt-get install apache2 php5 php5-pear build-essential

– Baixe o Oracle Instant Client para a versão do banco de dados utilizada, ou uma
versão superior (são necessários 2 pacotes, o Basic e o SDK). Coloque os arquivos no
seguinte diretório:

/usr/lib/oracle/<versão>/client64

Para a versão 11.2 (consideraremos essa versão de agora em diante) do cliente o diretório é:

/usr/lib/oracle/11.2/client64

Nesse diretório deve existir um subdiretório lib onde devem estar as bibliotecas
compartilháveis. São arquivos com extensão “so”. Para os passos seguintes funcionarem é preciso
criar dois links simbólicos. O primeiro com o seguinte comando:

/usr/lib/oracle/11.2/client64/lib$ sudo ln -s libclntsh.so.11.1 libclntsh.so

* Note que o link simbólico é realizado no diretório /usr/lib/oracle/11.2/client64/lib.

Para fazer o segundo link antes crie o seguinte diretório: /usr/include/oracle/11.2

Agora desse diretório execute o comando:
/usr/include/oracle/11.2$ sudo ln -s /usr/lib/oracle/11.2/client64/sdk/include client64

10
 Para finalizar esse passo é preciso fazer com que o sistema carregue as bibliotecas desse
diretório. Isso pode ser feito através da criação de um arquivo chamado instantclient11g.conf com o
caminho onde as bibliotecas estão disponíveis, ou seja: /usr/lib/oracle/11.2/client64/lib. Esse
arquivo deve ser colocado no diretório /etc/ld.so.conf.d. Para carregar as bibliotecas execute o
comando ldconfig.

– Instale o driver OCI8 (provê ao PHP o suporte ao Oracle):

$ sudo pecl install oci8

* Tecle <ENTER> para todas as perguntas.

Para o driver funcionar é necessária a instalação de uma biblioteca adicional:

$sudo apt-get install libaio1

– Habilite o driver OCI8 no PHP:

Crie um arquivo chamado Oracle10g.ini no diretório /etc/php5/apache2/conf.d com o

seguinte conteúdo:

extension=oci8.so

– Reinicie o servidor Apache2:

$ sudo service apache2 restart

– Teste o sistema:

Crie um arquivo chamado teste.php no diretório /var/www com o seguinte conteúdo:

<?php
phpinfo();
?>

Acesse: http://<ip_do_servidor>/teste.php

Procure na página pelo conteúdo da figura a seguir. Se encontrar o servidor foi configurado
corretamente. Se não encontrar procure nos arquivos de log do servidor Apache, localizados no
diretório /var/log/apache2 por mensagens de erro que esclareçam o problema. Lembre-se que
sempre que alterar alguma configuração no servidor Apache é preciso reiniciá-lo.

11
 Figura: Servidor com suporte ao Oracle configurado corretamente

É bastante recomendável o uso de um certificado SSL com o sistema. No capítulo 5 existe

um link com informações que auxiliam na geração do certificado através do OpenSSL e sua
instalação do servidor Apache. Lembrando que certificados auto-assinados precisam ser instalados
manualmente nos navegadores de cada cliente, ou emitirão alertas de confiabilidade. A aquisição de
um certificado reconhecido é indicada.
Uma vez instalado o certificado é preciso lembrar de ajustar o parâmetro base_url do
sistema, de modo que os endereços gerados por ele sejam exclusivamente via URLs seguras. O
procedimento de configuração do parâmetro mencionado será explicado no próximo item.

3.3.2 – Instalação do sistema

Descompacte o arquivo simcc-<versão>.tar.gz com o comando:

$ tar -zxvf simcc-<versão>.tar.gz

Mova a pasta simcc para a raiz do servidor web:

$ mv simcc /var/www

12
 Importe o banco de dados fornecido em um dump SQL para o esquema desejado. Vamos
supor para fins de ilustração o esquema simcc no banco de dados de IP 192.168.1.10 e SID des.
Vamos supor também o servidor no IP 192.168.1.11.

3.3.3 – Configuração do sistema

A configuração do sistema é bastante simples. Só é preciso definir o endereço de acesso e as

informações para a conexão com o banco de dados.
O endereço de acesso é definido no arquivo /var/www/simcc/application/config/config.php
através da diretiva abaixo:

$config['base_url'] = 'http://192.168.1.11/simcc/';

* Caso o sistema tenha um registro de DNS é preferível colocá-lo, pois após o primeiro
acesso o framework usa o valor da variável base_url para montar os endereços para
redirecionamento.

As informações de conexão com o banco de dados são definidas no arquivo

/var/www/simcc/application/config/database.php através das configurações abaixo:

$db['default']['hostname'] = '(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)
(HOST=192.168.1.11)(PORT=1521))
(CONNECT_DATA=(SID=des)))';
$db['default']['username'] = 'usuario';
$db['default']['password'] = 'senha';
…...... as demais configurações não se alteram .........

Após efetuar as configurações apresentadas até aqui já é possível entrar no sistema. Acesse o
endereço informado no parâmetro base_url e use como usuário admin e senha também admin. Não
esqueça de trocar a senha de administrador no primeiro acesso. Isso pode ser feito no menu
usuários.

13
3.4 – Integração com o banco de dados

O sistema SIMCC foi desenvolvido em um ambiente com 2 esquemas de dados. Um deles

de escopo local armazena as informações do modelo interno do sistema e o de escopo externo
contém as informações do sistema corporativo do HCE, tais como dados de pacientes e de
consultas.
Afim de tornar o desenvolvimento mais independente e de garantir maior segurança aos
dados institucionais do HCE foi adotado o seguinte esquema de trabalho:

• Leitura no esquema de dados de escopo local: liberada.

• Escrita no esquema de dados de escopo local: liberada.
• Leitura no esquema de dados de escopo externo: liberada.
• Escrita no esquema de dados de escopo externo: através de procedimentos*.
* Os procedimentos são de responsabilidade da equipe do HCE.

Por conta desta particularidade serão necessárias algumas adaptações no código do sistema,
estas adaptações serão esclarecidas nas seções a seguir.

3.4.1 – Ajustes de chamadas a procedimentos

Afim de minimizar qualquer impacto sobre o cronograma do projeto foram definidos dois
procedimentos básicos que contém interfaces pactuadas com a equipe do HCE. São eles:

PROCEDURE AGENDAR (P_NRP IN VARCHAR2, P_DATACONSUL IN VARCHAR2,

P_ESPECIALIDADE IN VARCHAR2, ID_UNIDORIG VARCHAR2, SALA OUT VARCHAR2,
TURNO OUT VARCHAR2, NTRANS OUT VARCHAR2)

Responsável pela inserção dos dados de agendamento no esquema corporativo do HCE.

PROCEDURE C_AGENDACONSUL (P_NRP IN VARCHAR, P_DATACONSUL IN VARCHAR,

P_ESPECIALIDADE IN VARCHAR, RETORNO OUT CHAR)

Responsável pelo cancelamento dos agendamentos realizados pelo sistema SIMCC no

esquema corporativo do HCE.

14
 O sistema funciona perfeitamente com o uso dos procedimentos relacionados anteriormente.
O procedimento AGENDAR cria dados fictícios de consultas e os armazena na tabela
PROCTEMP, especialmente criada para este fim. De forma análoga o procedimento
C_AGENDACONSUL cancela uma determinada consulta eliminando os seus dados na tabela
PROCTEMP.

Quando os procedimentos definitivos forem finalizados, será preciso alterar a chamada dos
procedimentos dentro do sistema. Esse procedimento será explicado a seguir.

Começando pelo procedimento AGENDAR. Ele é chamado no método save_scheduling da

classe agenda_model (arquivo /var/www/simcc/application/models/agenda_model.php). O trecho
de código abaixo corresponde à chamada do procedimento:

$cod_esp = $nrp = $sala = $ntrans = '0';

$turno = 'I';
$cod_esp = $data_scheduling['CODESP'];
$nrp = $data_patient['NRP'];
$cod_setor = $data_scheduling['CODSETOR'];
$cod_unidorig = $data_scheduling['CODUNIORIG'];
$dataconsul = trim($data_scheduling['DATACONSULTA']);

$params = array(
array('name'=>':p_nrp', 'value'=>$nrp,'length'=>10, 'type'=>SQLT_CHR),
array('name'=>':p_dtconsulta', 'value'=>$dataconsul, 'length'=>10, 'type'=>SQLT_CHR),
array('name'=>':p_codesp', 'value'=>$cod_esp, 'length'=>4, 'type'=>SQLT_CHR),
array('name'=>':p_unidorig', 'value'=>$cod_unidorig, 'length'=>1, 'type'=>SQLT_CHR),
array('name'=>':p_out_sala', 'value'=>&$sala, 'length'=>4, 'type'=>SQLT_CHR),
array('name'=>':p_out_turno', 'value'=>&$turno, 'length'=>1, 'type'=>SQLT_CHR),
array('name'=>':p_out_ntrans', 'value'=>&$ntrans, 'length'=>5, 'type'=>SQLT_CHR)
);

$retproc = FALSE;
$errormsg = "";

try{
$retproc = $this->db->simple_stored_procedure('','AGENDAR',$params);
}
catch(Exception $e){
$errormsg = $e->getMessage();
}

A primeira parte do código é responsável pela preparação dos argumentos que serão
submetidos ao procedimento. O vetor params contém os argumentos com suas propriedades (valor,
tamanho e tipo). Os parâmetros de entrada são passados por cópia e os de saída por referência
(simbolo “&” antes da variável). Ao final o método simple_stored_procedure é chamado para
executar o procedimento, submetendo o vetor params. Note que o procedimento é executado em um
bloco try/catch de forma a capturar eventuais mensagens de erro retornadas pelo procedimento.

15
Essas mensagens serão exibidas pelo sistema.
Se o procedimento tiver seu nome alterado ou for armazenado em um esquema diferente do
padrão do sistema será preciso alterar a chamada. Supondo um novo procedimento
AGENDAMENTO hospedado no esquema SISHCE, a chamada ficaria assim:

$retproc = $this->db->simple_stored_procedure('SISHCE','AGENDAMENTO',$params);

O procedimento C_AGENDACONSUL é chamado de forma bastante similar. Ele é

chamado no método clear_consultation da classe agenda_model (arquivo
/var/www/simcc/application/models/agenda_model.php). O trecho de código abaixo corresponde à
chamada do procedimento:
$dataconsul = trim($date);

$query = $this->db->query("SELECT NRP FROM $this->table3 WHERE DATACONSULTA =

TO_DATE('{$date}', 'DD-MM-YYYY') AND IDUNIESP = {$id_uniesp} AND SENHA = {$passw}");
$nrp = $query->row()->NRP;

$query = $this->db->query("SELECT CODESP FROM $this->table2 WHERE ID = {$id_uniesp}");

$cod_esp = $query->row()->CODESP;

$retproc = '1';

$params = array(
array('name'=>':p_nrp', 'value'=>$nrp,'length'=>10, 'type'=>SQLT_CHR),
array('name'=>':p_dtconsulta', 'value'=>$dataconsul, 'length'=>10, 'type'=>SQLT_CHR),
array('name'=>':p_codesp', 'value'=>$cod_esp, 'length'=>4, 'type'=>SQLT_CHR),
array('name'=>':p_out_ret', 'value'=>&$retproc, 'length'=>1, 'type'=>SQLT_CHR)
);

$errormsg = "";

try{
$this->db->simple_stored_procedure('','C_AGENDACONSUL',$params);
}
catch(Exception $e){
$errormsg = $e->getMessage();
log_message('error',$errormsg);
}

O procedimento para alteração é exatamente o mesmo que o exemplificado anteriormente.

16
3.4.2 – Ajuste de chamadas a esquemas de dados distintos

Com o uso de 2 esquemas de banco de dados o sistema SIMCC teve que trabalhar com duas
definições de bancos de dados. Essa estrutura provavelmente permanecerá após a instalação, devido
a arquitetura dos sistemas corporativos do HCE. Por isso, mostraremos onde e como alterar as
chamadas aos esquemas externos à aplicação SIMCC.
As instâncias de banco de dados são registradas no arquivo
/var/www/simcc/application/config/database.php como mencionado no item 3.2.3. O framework
provê acesso facilitado à instância default registrada no arquivo de configuração. Mas outras
instâncias podem ser registradas. Foi esse o caso da instância de banco de dados correspondente ao
esquema de escopo externo ao sistema, que chamamos de sishce. Para poder utilizá-la a seguinte
configuração foi realizada:

$db['sishce']['hostname'] = '(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=192.168.1.9)
(PORT=1521))(CONNECT_DATA=(SID=des)))';
$db['sishce']['username'] = 'usuario';
$db['sishce']['password'] = 'senha';
$db['sishce']['database'] = ''; // not used by this Oracle driver
$db['sishce']['dbdriver'] = 'oci8';
$db['sishce']['dbprefix'] = "";
$db['sishce']['pconnect'] = TRUE;
$db['sishce']['db_debug'] = FALSE;
$db['sishce']['cache_on'] = FALSE;
$db['sishce']['cachedir'] = "";
$db['sishce']['char_set'] = "utf8";
$db['sishce']['dbcollat'] = "utf8_general_ci";

Com a instância sishce configurada, basta iniciá-la da seguinte forma:

$db2 = $this->load->database('sishce', TRUE);

Na classe onde o comando acima foi realizado estarão disponíveis as instâncias do banco de
dados padrão (variável $db) e a instância sishce (variável $db2).
Em um projeto corretamente estruturado no modelo MVC a manipulação das instâncias de
banco de dados serão feitas exclusivamente nas classes de modelo. Então o lugar correto para
buscar pela inicialização de instâncias extras de banco é no diretório
/var/www/simcc/application/models.
Particularmente no sistema SIMCC a instância de escopo externo foi utilizada nas classes
definidas nos arquivos pacientes_model.php, especialidade_model.php e agenda_model.php.

17
 Abaixo um exemplo do uso da instância sishce retirada do arquivo pacientes_model.php:
/**
* Obtém o nrp do paciente na tabela de paciente no hce através do nome
*/
function get_nrp_by_name($nome){

$db2 = $this->load->database('sishce', TRUE);

$db2->select('NRP');
$db2->from($this->table);
$db2->where('NOME',$nome);
$query = $db2->get();

return $query->row()->NRP;

}
Caso seja necessária a mudança de banco de dados ou mesmo a sua descentralização é
possível adaptar o sistema sem muita dificuldade. Pode-se alterar as definições de registro no
arquivo de configuração de base de dados ou ainda adicionar novas instâncias carregando-as antes
de utilizá-las na própria função presente no modelo, como no exemplo acima.

3.4.3 – O método simple_stored_procedure

O método simple_stored_procedure foi implementado de forma a simplificar a execução de

procedimentos no banco de dados Oracle.
O método para execução de procedimentos de banco de dados do framework CodeIgniter é
o stored_procedure. Ocorre que no decorrer do desenvolvimento do sistema a execução desse
método gerou problemas diversos e carecia de uma forma razoável de retorno do texto dos erros
gerados pelos procedimentos. Se fez necessária então a extensão do framework com a inclusão de
um novo método.
O simple_stored_procedure difere do método original do framework basicamente no que se
refere ao bind dos parâmetros submetidos. Ao invés de submeter a tarefa de realização do bind dos
parâmetros para a função _bind_params e a execução do procedimento para a função query, a nova
função faz o bind e a execução diretamente utilizando as funções do driver OCI8. Além disso, a
simple_stored_procedure repassa os erros gerados através da geração de um objeto Exception
facilmente interceptado e manipulado por um bloco try/catch, o que facilita a exibição do erro
correspondente.
Todas as execuções de procedimentos de banco de dados do sistema SIMCC foram
realizadas através do método simple_stored_procedure, portanto é preciso ter atenção em um

18
possível upgrade do framework no futuro. Para referência o a função foi incluída no arquivo
../simcc/system/database/drivers/oci8/oci8_driver.php

3.4.4 – O método display_error_friendly

O método display_error_friendly foi implementado como uma forma menos invasiva de

mudar o comportamento do framework CodeIgniter no que se refere ao retorno de erros
ocasionados por falhas de comunicação com o banco de dados.

O comportamento padrão do framework é o de apenas registrar no arquivo de logs os

eventuais erros de comunicação, sem gerar qualquer retorno para o usuário. Esse comportamento
pode ser alterado habilitando-se a diretiva db_debug no arquivo de configuração database.php.
Ocorre que, ao se habilitar o modo debug para o banco de dados, os erros são reportados ao usuário
através do método display_error do CodeIgniter. Esse método retorna informações sensíveis que,
além de não ajudarem em nada ao usuário, podem comprometer a segurança da aplicação.

Por este motivo, o método display_error_friendly foi criado. Ele é basicamente uma réplica
do método padrão que não captura as informações desnecessárias e usa um template de exibição
distinto chamado error_db_friendly. Este template corresponde ao arquivo
../simcc/application/errors/error_db_friendly.php). O que ocorre na prática então é que em uma
situação de uso normal do sistema (db_debug = FALSE) o método alternativo é chamado invocando
uma mensagem voltada para o usuário, enquanto em uma situação de contingência (db_debug =
TRUE) o método padrão é chamado, gerando uma mensagem voltada aos desenvolvedores.

Para referência, tanto o método display_error_friendly, quanto o chaveamento entre as

situações de modo normal e modo de contingência foram implementados no arquivo
../simcc/system/database/DB_driver.php.

3.4.5 – Carga de especialidades

Durante a execução do projeto considerou-se as especialidades como dados derivados do

sistema corporativo do HCE. Portanto, a tabela ESPECIALIDADE do modelo do SIMCC é a
imagem dos dados da tabela de especialidades do HCE. Caso haja alguma alteração uma carga
manual deverá ser realizada. Lembrando que os códigos já existentes não devem ser alterados.

19
3.5 – Procedimentos de manutenção e backup

Os procedimentos de manutenção do sistema são absolutamente triviais. Basta manter o

sistema atualizado através do comando abaixo:

$ sudo apt-get update && apt-get upgrade

Além disso, o backup da pasta /var/www/simcc é aconselhável, pois alguns logs são
armazenados na pasta /var/www/simcc/application/logs. O backup do banco de dados já deve ser
um procedimento habitual e nem precisa ser mencionado.

Os logs de escopo da aplicação são criados em arquivos identificados pela data, na forma
log-yyyy-mm-dd.php. É aconselhável a criação de um CRONJOB para apagar arquivos antigos. Os
logs do servidor web e do restante do sistema já são rotacionados automaticamente pelo serviço
logrotate.

20
CAPÍTULO 4 – SOLUÇÃO DE PROBLEMAS

4.1 – Problemas comuns

– Sistema redireciona para endereço errado:

Verifique a configuração no arquivo /var/www/simcc/application/config/config.php. A

diretiva $config['base_url'] deve apontar para o endereço do sistema.

– Agendamento com problemas:

Verifique os logs no diretório /var/www/simcc/application/. Erros, ou mesmo uma demora

na resposta do banco de dados, podem provocar efeitos colaterais no agendamento. Isto ocorre por
conta da interface dinâmica do sistema, embora nos testes realizados as oscilações do banco não
tenham provocado efeitos colaterais graves, mesmo assim essa hipótese não pode ser excluída.
No caso do erro não aparecer de forma evidente nos logs, pode-se aumentar o nível
informações fazendo com que o sistema fique em modo debug. Para isso altere no arquivo
database.php o parâmetro de configuração $db['default']['db_debug'] para o valor TRUE.
Lembrando que o sistema exibirá os erros na tela, portanto use esse recurso com cautela.

– Sistema não abre no navegador X:

O sistema foi desenvolvido tendo como base de testes o navegador Mozilla Firefox, portanto
até o momento só é possível garantir o perfeito funcionamento do sistema neste navegador.
Trabalhos de compatibilização com o Google Chrome e Opera estão em curso. No entanto, apesar
de erros de formatação, o sistema ainda assim funciona nos principais navegadores. A exceção é o
Microsoft Internet Explorer que sabidamente apresentam problemas diversos com interfaces
dinâmicas, não sendo aprovado no teste ACID3 (http://www.acidtests.org/). Por isso, ele não será
suportado.

– Sistema lento:

O sistema SIMCC é bastante leve. Então é provável que a lentidão do sistema tenha relação
com o banco de dados ou com a rede. De qualquer modo, a reinicialização do serviço apache pode
ajudar.

21
 – Sistema não gera logs de aplicação:

Verifique se as permissões do diretório de logs (../simcc/applications/logs) possibilitam a

escrita pelo servidor web (usuário www-data). Na dúvida, estando no diretório do simcc execute o
comando:
…/simcc$ chown www-data:www-data applications/logs

* Será necessário gerar algum evento para que o arquivo seja criado.

– Sistema apresenta a mensagem: “É necessário efetuar o login para acessar essa

página”:

Por medida de segurança o sistema inibe o acesso de usuários que ficam ociosos (não
efetuam nenhuma ação no sistema) por duas horas. Efetue login novamente.
O tempo de expiração de uma sessão é configurável. Basta alterar o parâmetro
$config['sess_expiration'] = 7200; (tempo em segundos) localizado no arquivo config.php. Colocar
o valor 0 (zero) nesse parâmetro desativa a expiração de sessão (não recomendado).

4.2 – Problemas conhecidos

Os problemas listados abaixo são de alguma forma inerentes a tecnologia, sendo portanto
inevitáveis até o momento. Nenhum deles impede o uso do sistema com qualidade e estão listados
abaixo apenas para referência do suporte:

– Sistema gera erro ao se excluir dois itens quaisquer em seguida:

Esse erro ocorre por uma limitação da tecnologia empregada. Basta aguardar, entre uma
ação de exclusão e a ação seguinte, até que a confirmação da exclusão desapareça.

22
CAPÍTULO 5 – REFERÊNCIAS

– Ubuntu
http://www.ubuntu.com

– PHP
http://www.php.net

– Oracle
http://www.oracle.com

– Jquery
http://jquery.com

– CodeIgniter
http://codeigniter.com

– Instalação do ambiente da aplicação:

http://www.oracle.com/technetwork/articles/technote-php-instant-084410.html

– Instalação de certificados SSL:

https://help.ubuntu.com/10.04/serverguide/C/certificates-and-security.html

23
APÊNDICE

- Diagrama de classe do sistema

24