Tag´s Extensíveis ($GP{} e $GF{})
O IW ofere um importante recurso que permite que novas tag´s sejam desenvovidas dinâmicamente. Para acrescentar novas tag´s
ao IW deve-se utilizar o conceito de tag parametrizável
do IW cuja sintaxe descrevemos a seguir :
TAG $GP{}
Funcionalidade : Oferece a possibilidade de inserção de informações em
formato “tabela” em substituição à tag em templates xml e na ficha
sintética.
Sintaxe: $GP{nome_comando_sql_espec|dimensao_1|dimensao_2|...|dimensao_n}
onde :
nome_comando_sql_espec : Trata-se de um nome que um comando sql especializado que deve ser cadastrado na tabela IFRSQLCOMMAND do IW (por uma simples convenção esse comando deve ser cadastrado com a coluna FORMID = 1551. Esse comando deverá receber como parâmetro o número de um atendimento (ID da tabela CAPADMISSION) e tipicamente irá retornar algumas colunas que serão apresentadas dinamicamente em formato de tabela na ficha sintética.
Dimensao_1 : refere-se à largura
que será destinada à primeira coluna na tabela dinâmica (em % da largura
total da tabela)
Dimensao_2 : refere-se à largura que será destinada à segunda
coluna na tabela dinâmica (em % da largura total da tabela)
...
Dimensao_n : refere-se à largura que
será destinada à n-ésima coluna na tabela
dinâmica (em % da largura total da tabela)
Exemplo
passo a passo de desenvolvimento de uma nova TAG $GP{}:
No nosso
exemplo vamos desenvolver uma tag que irá apresentar
uma tabela com as seguintes informações:
- coluna 1 (15% da largura da tabela): data da visita
- coluna 2 (20% da largura da tabela): nome do profissional seguido do nome da
sua especialidade entre parêntesis
- coluna 3 (65% da largura da tabela): concatenação das informações “Síntese da
evolução clínica” e “Condutas Metas e Orientações” dos relatórios de avaliação
e/ou evolução clínica das diversas especialidades.
Vamos adotar o nome “EVOL_CLIN_COMB” para o comando SQL que irá recuperar os dados para a nossa tag. Sendo assim a sintaxe da tag ficaria sendo :
$GP{EVOL_CLIN_COMB|15|20|65}
O primeiro passo para a implementação da tag será elaborar o comando SQL que fará a recuperação dos dados tal qual especificado. Para o desenvolvimento do comando sql utilize e interface menu- ferramentas – Sql & Debug (disponível para usuários administradores com status de desenvolvedor). A figura a seguir ilustra essa interface:
A sintaxe para
o comando sql para a tag do
nosso exemplo ficou sendo :
|
select b.eventdate as dataevento,
(a.ProfessionalName || '(' || a.SCSpecialityName
|| ')' ) as profissional , CASE WHEN (b.CLINIC_DESCR is null) THEN '' WHEN (b.CLINIC_DESCR
is not null) THEN ('Evolução Clínica:
' || b.CLINIC_DESCR || '<br><br>') ELSE 'Error' END || CASE WHEN (b.CONDUTA_META is null) THEN '' WHEN (b.CONDUTA_META
is not null) THEN ('Condutas Metas e Orientações: ' || b.CONDUTA_META)
ELSE 'Error' END as evolucao |
IMPORTANTE:
I) Ao final do comando sql deve-se acrescentar a
expressão “|ID” ( ou seja, um caracter
“pipe” seguido do termo ID) exatamente como
demonstrado no exemplo logo acima. Essa sintaxe é fundamental para que , em tempo de execução do comando, o ID da internação
(ID da tabela CAPADMISSION) seja passado corretamente como parâmetro para o
módulo executor do comando SQL.
II) Uma “segunda sintaxe igualmente aceita pela IW :
Ao invés de usar o caracter “?” ilustrado no comando
acima utilize a expressão $P{ID} exatamente no lugar da ? e
retire o |ID ao final do comando. Essa segunda sintaxe é particularmente
útil em situações onde se deseja usar um comando tipo
“union” com duas sub-querys
onde se deseja utilizar o filtro por ID nas duas sub-querys.
A título de ilustração o comando ilustrado acima ficaria da seguinte forma
nessa segunda sintaxe:
|
select b.eventdate as dataevento,
(a.ProfessionalName || '(' || a.SCSpecialityName
|| ')' ) as profissional , CASE WHEN (b.CLINIC_DESCR is null) THEN '' WHEN (b.CLINIC_DESCR
is not null) THEN ('Evolução Clínica:
' || b.CLINIC_DESCR || '<br><br>') ELSE 'Error' END || CASE WHEN (b.CONDUTA_META is null) THEN '' WHEN (b.CONDUTA_META
is not null) THEN ('Condutas Metas e Orientações: ' || b.CONDUTA_META)
ELSE 'Error' END as evolucao |
Para cadastrar um novo comando sql customizado acesse a seguinte interface : menu-administrador-(20) Cfg Comandos SQL. A ilustração a seguir ilustra essa interface:
Para cadastrar esse comando SQL clique no botão “Novo” e informe valores para os atributos obrigatórios “Nome” e “Comand sql” , e opcionalmente informe um valor para o atributo “Descrição”. Nota: O atributo “Parâmetros” tipicamente é usado em outros contexto de processamento por exemplo para limitar um número máximo de registros para paginação (recurso não aplicável ao tipo de comando SQL requerido por esse tipo de tag).
Notas:
(a) Deve-se cadastrar as traduções para os nomes das colunas que irão retornar
no comando sql. Utilize a categoria de tradução
“GLOBAL” para efetivar essas traduções. Acesse menu-administrador- (05)
Configurar traduções – (2) Configurar Traduções. Use o botão “Novo” para
inserir um novo termo no dicionário global do IW e em seguida cadatre a tradução desejada para o novo termo.
(b) Para que as traduções globais tenham efeito será necessário re-iniciar o jboss
no(s) servidor(es) de aplicação do IW.
TAG $GF{}
Funcionalidade : Oferece a possibilidade de inserção de informações
simples (campos isolados) em substituição à tag em templates xml e na ficha
sintética.
Sintaxe: $GF{nome_comando_sql_espec|<nome_coluna_especifica>}
onde:
nome_comando_sql_espec : Trata-se do nome do comendo sql
customizado para a tag. Utilize a mesma interface
F00172 já ilustrada anteriormente para proceder o cadastro do comando sql. Esse comando deverá receber como parâmetro o número de
um atendimento (ID da tabela CAPADMISSION) e tipicamente irá retornar uma ou
várias colunas . Apenas uma das colunas retornadas do
comando poderá ser renderizada em cada instância de uso da TAG no template.
nome_coluna_especifica : Trata-se do nome da
coluna cujo valor retornado será exibido no lugar da TAG.
Exemplo passo a passo de desenvolvimento de uma nova TAG $GF{}:
No exemplo que se
segue vamos implementar uma tag genérica para apresentação
em do “nome do médico solicitante do home care” com seu respectivo “CRM”.
Informação técnica requerida para essa tag : O IW armazena o cadastro dos médicos de referência de um paciente na tabela denominada GLBPHYSICIAN e armazena o ID do registro do médico nessa tabela na coluna IDPHYSICIANREQ da CAPDMISSION.
Sendo assim, o comando sql para obtenção dos atributos desejados ficaria sendo:
SELECT
B.NAME AS NOMEMEDICO, B.REGISTRYNUMBER AS CRM FROM
CAPADMISSION A, GLBPHYSICIAN B
WHERE
A.IDPHYSICIANREQ = B.ID
A.ID=?|ID
Vamos
acionar a interface F0172 e proceder o cadastramento desse comando SQL,
conforme ilustrado abaixo :
A sintaxe final para essa tag fico sendo então:
$GF{MEDICO_SOLICITANTE,NOMEMEDICO}
:
Essa tag será substituída pelo nome do médico
solicitante e ,
$GF{MEDICO_SOLICITANTE,CRM} : Essa tag será
substituída pelo CRM do médico solicitante.
TAG GPLIST{}
Funcionalidade: Oferece a
possibilidade de inserção de informações tipo lista (campos enumerados).
Exemplo: Exibição de uma lista de diagnósticos de enfemagem
de um paciente. Notas: Na apresentação das informações nesssa
tag “não serão introduzidas molduras” de tabelas nada
disso, mas tão somente um ordinal (contador numérico) precedento
os nomes das opções (ex.: nomes de diagnósticos de enfermagem. Em termos de
processamento, o IW irá basicamente executar o comando sql
endereçao pelos parâmetros <formid>
e <keyindex> (esse comando terá que devolver
uma única coluna com uma lista de valores (string)).
Sintaxe: $GPLIST{<formid>,<keyindex>}
onde:
<formid>: id do form no IW onde está cadastrado o comando sql que será executado no processamento da tag. Nota: Nesse comando deve necessariamente conter um parâmetro $P{ID} que em tempo de processsamento será substituído pelo “ID” da admissão associada ao paciente no contexto de processamento da tag.
<keyindex> : número do KEYINDEX no cadastro do comando sql. Exemplo: -6
Exemplo de sintaxe: $GPLIST{172,-6}
Exemplo de comando sql para retornar a relação de
nomes de diagnósticos de enfermagem de um paciente:
select b.codename
from CAPDIAGNOSTICNURSE a, scccode
b where IDADMISSION = $P{ID} and
b.id = a.SCDIAGNOSTICNURSE
TAG GPL{}
Funcionalidade: Oferece um comportamento bastante semelhante
ao da TAG GP{} com um layout simplificado: Não será exibido um título (TITLE) e
também não será exibido um a linha de “cabeçalho da tabela” (TABLE HEADER).
Sintaxe: $GPL{<formid>,<keyindex>}
Configurando Caixas de Seleção (combo box) populadas dinamicamente
Através
desse recurso é possível desenvolver templates que
referenciem caixas de seleção com as opções do combo box não são previamente
declaradas no código html do template
(em tempo de desenho do template). Nessa abordagem o
IW irá acessar um serviço (execução de um comando sql
configurável) para obter as opções da caixa de seleção.
Exemplo de utilização: Esse tipo de recurso é utilizado nos templates padronizados disponibilizados na instalação
default do IW-Health para popular as opções de planos de atenção. A imagem
abaixo ilustra um template denominado “PGDC –
Reclassificação do Risco”:
Nesse template destacamos a caixa de seleção denominada “Plano de
Atenção” que apresenta a relação de possíveis planos de atenção no qual um
paciente monitorado poderá estar inscrito dentro de uma empresa de gerenciamento
de doentes crônicos. A relação de opções que aparecem na caixa de seleção,
nesse caso, não foram declaradas “em tempo de desenho do template”
mas foram obtidas dinâmicamente mediante a execução
de um serviço.
Sintaxe html específica: Para utilizar essa funcionalidade, a
seguinte sintaxe deve ser usado no código fonte do template :
<select name="$evol_riskclassification" size="1"
iwselect="true" keyindex="-4" iwmode="value" formid="172"></select>
Onde:
name="$evol_riskclassification" :
trata-se da variável (se relaciona com o nome da coluna na tabela dinâmica)
onde será armazenado o código do plano de atenção (nesse exemplo, essa
informação será gravada na coluna denominada RISKCLASSIFICATION na tabela
dinâmica associada ao template.
Size="1" :
Nesse tipo de
recurso pode-se deixar a tag size
com valor default = 1 , pois o tamanho da caixa de seleção será ajustada
automaticamente com base no comprimento dos nomes de planos de atenção que
retornarem dinamicamente do serviço.
iwselect="true" : Essa tag (trata-se de uma tag
exclusivamente desenvolvida pela Incoway, ou seja, não faz parte da linguagem html standard) deverá ser declarada necessariamente com
valor = “true” (exatamente como ilustrado nesse
exemplo). É justamente a presença dessa tag que irá
ativar o comportamento diferenciado do IW fazendo com que seja executado um
comando sql para obtenção da relação de opções da
caixa de seleção.
iwmode="value" :
Essa tag ativa o comportamento de valoração do índice
(valor que será gravado na tabela dinâmica) por “valor” (ou seja, desativa a
valoração posicional ). A utilização desse recurso exige que seja utilizado iwmode="value" conforme
ilustrado nesse exemplo.
Keyindex="-4" formid="172": Essas tag´s cojuntamente “endereçam” o comando sql que será utilizado. Nesse exemplo estamos utilizando um comando sql padronizado (que é fornecido pela Incoway na instalação default e também é atualizado regularmente nas trocas de versão). Para visualizar esse comando sql acesse a interface F0172 (menu – Administrador – (20) Cfg Comando Sql). A figura a seguir ilustra essa interface , que é utilizada para cadastramento de comandos sql customizados e/ou visualização de comandos sql padronizados fornecidos pela Incoway:
Copiamos abaixo o código desse comando sql :
SELECT keyindex as id , translation as name , 0 as defaultvalue
from ifrconstantitem a, ifrconstant
b where a.idconstant = b.id and b.name =
'K_MONIT_CLASSIFIC_GERAL_RISCO' and a.keyindex not in
(select distinct riskclassification from
GLBRISKCTREXCEPT where idcontract = $P{IDCONTRACT} )
order by keyindex
IMPORTANTE: Um comando sql , para ser utilizado nesse tipo de recurso terá que “necessariamente” retornar 3 colunas denominadas da seguinte forma:
id : Trata-se da coluna que terá que retornar os valores de keyindex (valores) a serem populados na caixa de seleção (esses valores, não ficam visíveis na apresentação do html ao usuário, mas são esses valores que serão gravados na tabela dinâmica). Notem que nesse exemplo estamos passando o valor da coluna KEYINDEX da constante denominada K_MONIT_CLASSIFIC_GERAL_RISCO (constante onde ficam armazenados os códigos e nomes dos planos de atenção no IW).
name : Trata-se do texto
que será apresentado para os usuários referente a cada opção que será
apresentada na caixa de seleção. Notem que nesse exemplo estamos passando o
valor da coluna TRANSLATION referente à constante denominada
K_MONIT_CLASSIFIC_GERAL_RISCO (constante onde ficam armazenados os códigos e
nomes dos planos de atenção no IW).
defaultvalue : Nessa coluna deve
ser retornar o valor de keyindex correspondente ao
valor “default” a ser setado pelo IW na caixa de
seleção. Notem que nesse exemplo estamos passando o valor default = 0 (que
corresponde à opção “.” de plano de atenção).
Nota técnica complementar : Notem também que
nesse comando sql foi declarado o seguinte “inner select” : “.. and a.keyindex
not in (select distinct riskclassification from GLBRISKCTREXCEPT where idcontract = $P{IDCONTRACT} )”. Essa parte do comando
faz com que “não retornem” no resultado do comando aqueles planos de atenção
que tenham sido declarados na tabela GLBRISKCTREXCEPT. Essa funcionalidade
permite que possamos “expurgar” planos de atenção de determinados contratos
específicos de forma bastante prática e dinâmica.
Nota: Para acessar a
interface de cadastramento de excessões de planos de
atenção versus contratos acesse : menu – Configuração
– (06) Cfg – Gerenc
Crônicos - (00) Cfg Planos Atenção - (3) Cfg Pl. Atenção Ativos.
Populando dinamicamente as opções de um combo
box através de uma função plugada java
O IW oferece também mecanismo que permitem que uma função plugada java possa modificar o domínio de opções exibido por um
componentes html tipo combo box (<select>).
Para popular a relação de opções de um combo box (componente <select> do html) deve-se
basicamente utilizar a seguinte sintaxe na codificação da função plugada java:
htmlVariables.put(“$SelectOptions_<nome_variavel>”,
“valor_1|descricao_opcao_1|valor_2|descricao_opcao_2|.....|valor_n|descricao_opcao_n”);
Exemplo: htmlVariables.put(“$SelectOptions_riskclassification”, “10|Gerenciamento
Nível1|10|Gerenciamento Nível2”);
Caso Exemplo: O enunciado a seguir formula um problema onde é aplicável o
uso da funcionalidade população dinâmica de conteúdos de combo boxe em templates
No contexto dos processos PGDC (Programas de gerenciamento de doenças e casos) vamos
supor que sua empresa seja uma Operadora e utilize o IW-Health para gerenciar o
direcionamento de pacientes a prestadores terceirizados da seguinte forma:
O conceito de gerenciamento prevê basicamente 3 níveis de graus de risco de
pacientes, sendo que para cada grau de risco foi dimensionado um “plano de
atenção” específico. Ou seja, são praticados 3 planos de atenção a saber:
- Plano Grau Risco I
- Plano Grau Risco II
- Plano Grau Risco III
Os pacientes poderão ser ainda direcionados para 3 prestadores distintos
(designados genericamente de : Prestador A , Prestador
B e Prestador C) sendo que nem todos os prestadores estão qualificados para
atender pacientes em todos os graus de risco. Vamos supor que seja adotada a
seguinte matriz de designação de pacientes a prestadores :
Prestador A : Atende somente o “Plano Grau de Risco I”
Prestador B : Atende “Plano Grau Risco I” e “Plano Grau Risco II” e
Prestador C : Atende “Plano Grau Risco II” e “Plano Grau Risco III”.
Diante desse cenário, o recurso de popular dinamicamente as opções de uma
variável combo box em templates poderá ser utilizado
de modo que a função de cálculo do “grau de risco dos pacientes” faça a
valoração do combo box associado à variável RISKCLASSIFICATION (planos de
atenção) de modo a apresentar somente opções válidas de “Prestador / Plano de
atenção”.
Nota Geral : O exemplo acima ilustra bem a forma de utilização e o dinamismo que esse tipo de implementação de templates oferece. Embora toda a construção do exemplo tenha sido elaborada em torno da edição de “Planos de atenção” em pacientes do PGDC essa funcionalidade é totalmente genérica e poderá ser utilizada em inúmeras outras situações a critério da sua empresa. Para realizar configuração de novas funcionaldades utilizando-se esse tipo de recurso é necessário que o usuário tenha status de “Administrador” no IW.
Tags Especiais - Pré-definidas - Codificadas
Essas tags são processadas diretamente pela camada cliente do IW (código java puro) e implementam conceitos pré-definidos (não customizáveis).
O quadro
abaixo apresenta a relação de tag´s pré-definidas
codificadas:
|
Nome da Tag |
Sintaxe |
Conceito |
|
Prescrição
Médica |
$PR{} |
Contexto de
processamento: Somente no Painel de Relatórios semanais (**) |
|
Prescrição Médica somente
itens cobrados das seguradoras |
$PR_PAYER{} |
Contexto de processamento: Somente no Painel de Relatórios semanais (**) A presença
dessa tag em um template
provoca a substituição da mesma por tabelas contendo
todas as prescrições médicas cujas respecitvas
abrangências estejam compreendidas dentro do período que o usuário selecionar
no momento da geração do relatório. Nota:
Somente itens da prescrição médica cuja responsabilidade de pagamento seja =
seguradora serão exibidos. |
|
Prescrição
de Enfermagem |
$NURSE_PR{} |
Contexto de processamento: Somente no Painel de Relatórios semanais (**) A presença
dessa tag em um template
provoca a substituição da mesma por tabelas contendo
todas as prescrições de enfermagem cujas respectivas abrangências estejam
compreendidas dentro do período que o usuário selecionar no momento da
geração do relatório. |
|
Diagnósticos
de Enfermagem |
$NURSE_DIAGS{} |
A presença
dessa tag em um template
provoca a substituição da mesma por tabelas contendo
os diagnósticos de enfermagem do paciente. Essa informação independe do
período que o usuário seleciona no momento de geração do relatório. |
|
Ranking
Home Care |
$SCORE{} |
A presença
dessa tag em um template
provoca a substituição da mesma pelas seguintes informações
: (a) Escore de classificação e (b) classificação da complexidade do
paciente de acordo com o escore técnico adotado pela empresa de home care (exemplo: Nead ou ABMID). |
|
Plano
Terapêutico |
$PL{} |
A presença
dessa tag em um template
provoca a substituição da mesma por tabelas contendo
o descritivo do plano terapêutico do paciente (que consiste basicamente na
relação de especialidades clínicas com suas respectivas frequências) dentro
do período que o usuário selecionar no momento da geração do relatório |
|
Evoluções Clínicas
por Especialidade |
$E{<Especialidade Profissional>} |
Contexto de
processamento: Somente no Painel de Relatórios semanais (**) |
|
Evoluções
Clínicas por Template |
$EVOL_TEMPLATE{<idTemplate>} |
Contexto de
processamento: Somente no Painel de Relatórios semanais (**) Exemplo: $EVOL_TEMPLATE{15} A tag acima elenca as evoluções que usaram o template de ID=15 no período selecionado. |
|
Intercorrências |
$I{} |
Contexto de
processamento : relatório semanal (**) , fichas sintéticas em geral (PGDC,
HC, Hospital) |
|
Ocorrências |
$EX{} |
Contexto de
processamento : relatório semanal (**) , fichas sintéticas em geral (PGDC,
HC, Hospital) |
|
Diagnósticos |
$DIAGS{} |
A presença
dessa tag em um template
provoca a substituição da mesma por tabela contendo
informações relativas aos diagnósticos registrados no painel de
"Informações Monitoramento" para o respectivo paciente. Essa
informação independe do período que o usuário seleciona no momento de geração
do relatório. |
|
Exames (em
relatórios periódicos) (**) |
$TEST{} |
Contexto de
processamento: Somente no Painel de Relatórios semanais (**) |
|
Exames
(ficha sintética pacientes PGDC) |
$RESULT_TESTS{} |
Contexto de processamento : Ficha sintética de pacientes atendidos em regime PGDC. Apresenta
um quadro com os resultados de exames em um período padronizado
correspondente aos últimos 12 meses. |
|
Orçamentos |
$BUDGET{} |
A presença dessa tag em um template provoca a substituição da mesma por tabela contendo informações relativas aos Orçamentos registrados no painel de " Orçamentos" para o respectivo paciente e cujos inícios estejam compreendidos dentro do período que o usuário selecionar no momento da geração do relatório |
|
Medicamentos
Usados |
$MEDIC_USE{} |
A presença
dessa tag em um template
provoca a substituição da mesma por tabela contendo
informações relativas aos Medicamentos Usados registrados no painel
"Informações Monitoramento" para o respectivo paciente. Essa
informação independe do período que o o
usuário seleciona no momento de geração do relatório. |
|
Equipamentos |
$EQUIPS{} |
A presença
dessa tag em um template
provoca a substituição da mesma por tabela contendo
informações relativas aos Equipamentos Instalados no Domicílio durante o
atendimento do respectivo paciente. Essa informação independe do período que
o usuário seleciona no momento de geração do relatório. |
|
Data
Corrente |
$TODAY{} |
A presença
dessa tag em um template
provoca a substituição da mesma pela data corrente. |
|
Data
Corrente (com horário) |
$TODAY_DATE_TIME{} |
A presença
dessa tag em um template
provoca a substituição da mesma pela data corrente com horário. |
|
Data
Corrente (sem apresentar horário) |
$TODAY_DATE_ONLY{} |
A presença
dessa tag em um template
provoca a substituição da mesma pela data corrente sem mostrar o horário |
|
Horário
Corrente (inclusive segundos) |
$TODAY_TIME_ONLY{} |
A presença
dessa tag em um template
provoca a substituição da mesma pelo horário corrente inclusive com os
segundos. |
|
Horário
Corrente (sem apresentar segundos) |
$TODAY_TIME_ONLY_NOSECS{} |
A presença
dessa tag em um template
provoca a substituição da mesma pelo horário corrente (sem apresentar
segundos) |
|
Período do
Relatório |
$REPORT_PERIOD{} |
A presença dessa tag em um template provoca a substituição da mesma pelo período de abrangência do relatório. Esse
período é informado pelo usuário no momento da emissão do relatório. |
|
Internações hospitalares de pacientes monitorados. |
$MONIT_ADMISSIONS{} |
Obtém a relação de registros de internação hospitalares realizados “manualmente” através do prontuário eletrônico (acesso pelo painel “histórico de utilização” ou através do sinalizador denominado “Internação” posicionado no cabeçalho da interface de prontuário eletrônico F01039) Nota técnica : Obtém filtragem de registros com as seguintes características - coluna “eventype” in
(2,3,4,5,6,7) Importante : Os registros de internações advindos de processos de importação de dados de contas médicas não são considerados no processamento dessa tag. |
|
Quadro
Clínico |
$DIAG_DESCR{} |
Obtém a descrição do quadro clínico do pacientes monitorados. Aplicável a pacientes de PGDC. Nota Técnicas o IW irá obter o nome da tabela dinâmica através do parâmetro global (interface 151) denominado “CAP_TD_MONITPROTOCOL” e obterá o valor da coluna denominada “quadroclinico” mais recente que tenha sido registrado no último ano (data corrente – 365 dias). |
|
Evoluções clinicas de pacientes do PGDC |
$CLINDESC{} |
Apresenta uma tabela com uma síntese da descrição das evoluções clínicas registradas durante o último ano (data corrente – 365 dias). Nota técnica: IW irá obter o nome da tabela dinâmica através do parâmetro global (interface 151) denominado “CAP_TD_MONITPROTOCOL” . O conteúdo da síntese da evolução clínica será formado pela concatenação das colunas denominadas “clinic_descr” e “callproactivedescr” obtidas dos registros com “eventdate” dentro do últimos 365 dias. |
|
Grupos de
variáveis clínicas (ficha sintética PGDC) |
$VARDIN{} |
Contexto de
processamento : Ficha sintética de pacientes
atendidos em regime de monitoramento (PGDC) |
|
Consultas
interdisciplinares realizadas (ficha sintética PGDC) |
$CONSULINTER{} |
Contexto de
processamento : Ficha sintética de pacientes
atendidos em regime de monitoramento (PGDC) |
|
Chamadas de
call center pró-ativas
realizadas (ficha sintética PGDC) |
$CALLDONE{} |
Contexto de processamento : Ficha sintética de pacientes atendidos em regime de monitoramento (PGDC) Apresenta uma tabela com doze colunas (uma coluna referente a cada mês do último ano) com a marcação das chamadas de call center pró ativas realizadas. |
|
Atividades/Orientações
formais realizadas (ficha sintética PGDC) |
$ACTIVIT_DONE{} |
Contexto de processamento : Ficha sintética de pacientes atendidos em regime de monitoramento (PGDC) Apresenta
uma tabela com a marcação das “atividades/orientações formais” realizadas no
contexto de monitoramento (PGDC) nos últimos 365 dias |
|
Atividades/Orientações
formais programadas (ficha sintética PGDC) |
$PROG_ACTIVITIES{} |
Contexto de processamento : Ficha sintética de pacientes atendidos em regime de monitoramento (PGDC) Apresenta uma tabela com a marcação das “atividades/orientações formais” programadas para o pacientes no contexto de monitoramento (PGDC) |
|
Consultas
interdisciplinares programadas (ficha sintética PGDC) |
$PROG_CONSULT{} |
Contexto de processamento : Ficha sintética de pacientes atendidos em regime de monitoramento (PGDC) Apresenta uma tabela com a marcação das “atividades/orientações formais” programadas para o paciente no contexto de monitoramento (PGDC) |
|
Avaliações
de especialistas programadas para o paciente (ficha sintética PGDC) |
$PROG_AVAL{} |
Contexto de processamento : Ficha sintética de pacientes atendidos em regime de monitoramento (PGDC) Apresenta uma tabela com a marcação das consultas interdisciplinares tipo “avaliação” programadas para o paciente de monitoramento. |
|
Exames
solicitados para o paciente (PGDC ou Home Care ou Hospital) |
$PROG_TESTS{} |
Contexto de
processamento : Ficha sintética de pacientes HC,
PGDC ou Hospital. |
|
Médicos do
paciente (ficha sintética PGDC) |
$OTHERMEDICS{} |
Contexto de processamento : Ficha sintética de pacientes atendidos em regime de monitoramento (PGDC) Exibe quadro com a relação de médicos de referência do paciente crônico monitorado. |
|
Perguntas Pró-ativas (ficha sintética PGDC) |
$QUESTION_DYNAMIC{} |
Contexto de processamento : Ficha sintética de pacientes atendidos em regime de monitoramento (PGDC) Exibe as
perguntas pró-ativas
ativas para o paciente a serem realizadas nas chamadas de call
center pró-ativo. |
|
Foto do
paciente (fichas sintéticas PGDC, HC ou Hospital) |
PATIENT_PHOTO_URL{} |
Baseado no
Objeto IwPatient, obtido pelo serviço GetPatient. Utiliza o servidor de aplicação do IW para
obter a imagem da foto do paciente. |
(**) IMPORTANTE: O conceito de
relatórios semanais baseados em templates foi
substituído pela funcionalidade que permite a geração de relatórios periódicos
em lista baseados em “Dicionário de Dados Clínicos”. As tag´s
desenvolvidas para o contexto de “Relatórios Semanais” são mantidas no IW
apenas para compatibilidade com versões anteriores.
Orientações Técnicas para Edição de Templates
Este
documento visa orientar os desenvolvedores de IW-Templates.
Com as informações presentes aqui é possível melhorar a qualidade do código e
poupar tempo no processo que vai desde a criação do template
até sua colocação em produção.
De modo geral podemos dividir nas seguintes fases o processo de criação de um
novo template:
1. Edição do template
2. Codificação de BeanShell Scripts (funções plugadas) se necessário
3. Testes
4. Colocação em produção
1. Edição de Templates
Usar somente imagens nos formatos .gif, .jpg e .png
tanto na elaboração do template como na inserção
dinâmica de imagem em tempo de execução do template
no IwCare.
Imagens no formato .bmp não são aceitas, pois não podem ser visualizadas nos
componentes visuais do IWCARE.
1.
Não usar o editor Word e nem o Frontpage
da Microsoft.
Eles geram HTML complexo e desnecessário. Isso causa instabilidades nos
componentes visuais.
Recomendamos o uso do DreamWeaver (Comercial)
ou Nvu (Gratuito).
2.
Cada
template pode ser editado em duas versões. Uma para
ser usada dentro do IWCare em diversos "paineis" do prontuário (Evoluções Clinicas,
Impressos, Exames, Avaliações, etc...) e outra para ser acessada diretamente
via browser quando o servidor de aplicações assim o permitir. (Inclusive
dispositivos pequenos como PocketPCs, iPhones, etc.
Se o template será acessado apenas dentro do IWCare a Aba "Desktop" do editor de templates precisa ser usada.
Se o template será acessado apenas via Browser apenas
a aba "Pocket" precisa ser editada.
Se o template será acessado nos dois contextos
(dentro do Iw e Via Browser) as duas abas do editor Desktop" e Pocket
precisam ser definidas. As mesmas variáveis (campos de formulário HTML)
precisam estar presentes em ambos e com os mesmos nomes (atributo name). Cada um terá um layout adequado ao respectivo
uso. Em tese, o layout definido na aba pocket deve ter o seu conteúdo distribuido mais verticalmente para poder ser visualizado
de modo adequado nos browsers de dispositivos pequenos como celulares tipo
iPhone ou mesmo os diversos modelos de PDA's com
browsers embutidos. Mas se o uso do template nesses
dispositivos pequenos não for um objetivo, o template
na aba pocket pode ter o mesmo layout na aba Desktop sendo observadas apenas
algumas diferenças de codificação de templates
inerentes a arquitetura de cada tipo de uso e que
serão todas elas pontuadas nesse documento.
3.
Todas
as Variáveis de Template (
Campos de formulário HTML - Inputs, Selects e Textareas ) precisam ter seus nomes com prefixo "$evol_" e definidos no atributo name
da respectiva tag. IMPORTANTE: (a) Não
usar o atributo id para essa finalidade, (b) Os nomes das variaveis precisam necessariamente estar em “letras
minúscula”. O Atributo id nunca pode estar definido para nenhum dos campos.
Alguns editores de HTML, como o DreamWeaver, costumam
introduzir automaticamente o atributo id em todos os campos com o mesmo
conteúdo do atributo name. Caso isso ocorra esses
atributos id inseridos automaticamente precisam ser deletados.
4.
Evitar
o uso excessivo de tags FORM em um único template. Procure definir apenas uma TAG FORM sempre que possivel. E quando se tratar de templates
editados na aba "Pocket" nenhuma tag FORM
pode ser usada.
5.
Todas
as variáveis dentro de um mesmo template precisam ter
nomes únicos. A presença de variáveis com nomes iguais provoca erros de difícil
detecção. ATENÇÃO ESPECIAL DEVE SER TOMADA NESSE SENTIDO. Tanto nomes
únicos como o uso do prefixo padrão (item 2) são importantíssimos.
6. Os campos do tipo <SELECT>,
renderizados como combobox nos formulários possuem um
atributo especial que somente o IW é capaz de interpretar e que serve para
modificar como o IW valora a variável. Esse atributo chama-se iwmode e pode assumir apenas dois valores: positional e value.
Quando esse atributo está com valor igual a positional
o editor HTML do IW associa um valor numérico à variável, correspondente ao
valor posicional da opção que o usuário selecionou (
começando sempre de zero).
Se existem 4 opções de valores e o usuário selecionou a primeira. O valor
numérico zero será atribuído à variável. Caso ele selecione a segunda opção,
será atribuído o valor 1 e assim sucessivamente. Esse é o comportamento dafault do Editor do IW caso o atributo iwmode
não esteja definido. Isso para mater compatibilidade
retroativa com os templates já existentes e que não
usam esse novo atributo.
Exemplo de código:
<select name="$evol_fuma" size=1 iwmode="positional">
<option>.</option>
<option>sim</option>
<option>não</option>
</select>
Quando o atributo iwmode="value" o editor do IW associa o valor que estiver
colocado no atributo value da TAG
<OPTION> que foi selecionada.
No caso acima se o usuário na execução do template
selecionar a opção não será atribuído o valor 2 a variável $evol_fuma. mesmo que exista um atributo value
presente na tag <option>
ele não será levado em consideração. O que vale nesse modo operacional é a
posição da resposta na lista de opções.
<select name="$evol_fuma" size=1 iwmode="value">
<option value="126">.</option>
<option value="127>sim</option>
<option value="128">não</option>
</select>
Nesse segundo caso, se o usuário selecionar a opcao
sim será atribuida a string
"127" à variável $evol_fuma ($evol_fuma="127"), porque "127" é o
valor do atributo value da tag
option selecionada.
Obs: Esse recurso descrito acima foi implementado em
12/2008.
7.
Os
Templates definidos na Aba Pocket não podem ter no
seu corpo nenhuma tag Html
FORM, apenas definições de campos de formulários.
A Tag FORM nesse caso é adicionada dinamicamente pelo
servidor de aplicação quando remete o template para o
browser. O servidor devolve todo o conteúdo do template
dentro de uma única tag FORM que abraça todos os
campos presentes no template.
8. Não usar mais JOptionPane para exibir mensagens dentro de funções
plugadas
dos templates. Em síntese,
dentro de funções plugadas é proibido qualquer código java de camada visual. A funcionalidade de envio de
mensagens de erro para o usuário deve agora usar variáveis especiais dedicadas
a essa funcionalidade. As variaveis são "displayError" e "displayMessage".
Elas devem ser colocadas via metodo "put" dentro da HashMap hmHtmlVariables que é único meio de
comunicação correto da função plugada com o ambiente externo.
A seguir um exemplo de como fica o código usando-se as variáveis de mensagens:
JOptionPane.showMessageDialog(
ctl.getApp(),
"Valor Inválido");
Deve ficar assim agora:
htmlVariables.put("displayError",
"Valor Inválido");
Os templates já desenvolvidos que usam o JOptionPane nao precisam ser
alterados, pois antes da execução o IW Templates
reescreve essas linhas e as transforma para o novo formato. Mas, de agora em
diante, JOptionPane não deve mais ser usado em
funções plugadas.
9.
Chamadas de serviço IW dentro de funções plugadas:
Com entrada em produção da versão do IWTemplates que
disponibiliza execução de funções plugadas em templates
exibidos nos Browsers de Micros e também de PDAs atuais (como iPhones , PocketPcs, etc)
Agora o IwTemplates possibilita a chamada de funções
plugadas nas aplicações IWWEB acessadas diretamente via browser de micros ou de
dispositivos PDA's
Dentro dessas funções plugadas pode-se chamar serviços para executar comandos
SQL.
O seguinte exemplo é deixado como referência para uso.
Usar apenas as classes e metodos mostrados nesse
exemplo. Evite usar outras classes e métodos pois não poderão funcionar
quando a função plugada for disparada via Palm/Browser.
String cSqlText =
"select * from ifrproject " ;
//Calcular data final de filtro no início do proximo mes
Recordset rsParameters =
new Recordset();
rsParameters.appendField("idpatient",
Field.LONG);
Row rParameters = rsParameters.newRow();
Long idpatient = ( (Long) patient.getAttribValue("idpatient"));
rParameters.getField("idpatient").setValue(idpatient.longValue());
//Executar comando SQL
UserParamRecordset userParam
= ctl.getUserParam();
ServiceSubmiter ss = new ServiceSubmiter();
ss.setUrlService(userParam.getUrlService());
ss.setProjectName("BOSetDpcExec");
ss.setClassName("MtsSetExeDpcTable");
ss.setServiceName("ExecuteSQL");
ss.addParameter(new RecordsetParameter("userParam", userParam));
ss.addParameter(new RecordsetParameter("rsParameters", new Recordset()));
ss.addParameter(new StringParameter("cmdSQL", cSqlText));
Recordset rsResult = ss.submit();
10.
Para
favorecer a robustez na apresentação de caracteres acentuados, deve-se
preferencialmente utilizar os caracteres acentuados padronizados do html. Exemplo: é = é ã
= ã e assim por diante. Templates redigidos com esse cuidado possuirão menor
probabilidade de incidência de erros em processamento de caracteres acentuados.
11.
Todos os templates devem ser
intensamente testados antes de serem colocados em produção.
As recomendações
de TESTES devem ser rigorosamente seguidas para evitar retrabalhos em tempo
de produção.
Exemplos de Código para Funções Plugadas
Exemplos de código para escrever funções plugadas de Consistência em Tenplates:
1.
Exemplo 1:
Testar se uma data é válida
try {
String streventdate = ((String) htmlVariables.get("$evol_eventdate")).trim();
java.text.SimpleDateFormat sdf
= new java.text.SimpleDateFormat("dd/MM/yyyy");
sdf.setLenient(false);
sdf.parse(streventdate);
htmlVariables.put("ConsistResult",
Boolean.TRUE);
}
catch (Exception ex) {
htmlVariables.put("ConsistResult",
Boolean.FALSE);
htmlVariables.put("displayError",
"Preenchimento inválido da data de Inclusão ou ela deve estar
vazia");
return htmlVariables;
}
2.
Exemplo 2:
Testa se uma data é válida e se não é uma data futura em relação à data
corrente do servidor:
try {
String streventdate = ((String) htmlVariables.get("$evol_eventdate")).trim();
java.text.SimpleDateFormat sdf
= new java.text.SimpleDateFormat("dd/MM/yyyy");
sdf.setLenient(false);
java.util.Date d = sdf.parse(streventdate);
Calendar c = Calendar.getInstance();
c.setTime(d);
if (scriptUtil.isFuture(c))
{
throw new Exception("Data
Futura - Relativo dia/mes/ano no Servidor");
}
htmlVariables.put("ConsistResult",
Boolean.TRUE);
}
catch (Exception ex) {
htmlVariables.put("ConsistResult",
Boolean.FALSE);
if (ex instanceof
java.text.ParseException) {
htmlVariables.put("displayError",
"Data Inclusão Inválida ou não preenchida");
}
else {
htmlVariables.put("displayError",
ex.getMessage());
}
return htmlVariables;
}
Utilizando Componente “Calendário” para editar campos tipo Data
O exemplo de
código html abaixo implementa um campo um campo
editável seguido de um botão que gatilha um
componente java tipo calendário para edição mais
confortável de campos tipo data:
<input disabled="true"
name="$evol_eventdate"
type="text" size="10" />
<input type="submit"
value="IwCalendar"
name="$evol_*editarEventDate" />
Nesse template deverá ser declarada a função plugada
que irá implementar a chamada do componente tipo de calendário em tempo de
edição do template. Essa função, no exemplo de código
acima deverá ter nome = “*editar_eventdate” e deverá
ter uma única linha de código que é a seguinte:
return scriptUtil.inputDate("Entre com data da Visita","$evol_eventdate", htmlVariables, 0);
A figura a seguir ilustra a declaração dessa função:
IMPORTANTE: Deverá ser declarada uma função plugada “para cada campo
tipo data existente no template”. Lembrando que o
nome da função deverá ser ajustado bem como o código da função de modo a
endereçar corretamente qual variável será editada pela função. Ou seja, no
exemplo acima criamos uma função para edição da variável “$evol_eventdate”,
vamos supor que no mesmo template existisse uma outra
variável denominada “$evol_data_img_ant” (data da
última fotografia da ferida do paciente), nesse caso deveria ser declarada uma
outra função denominada “*editar_data_img_ant” cuja
linha de código deveria ser = return scriptUtil.inputDate("Entre com data da
Visita","$evol_data_img_ant", htmlVariables, 0); .
A imagem a seguir ilustra a imagem desse conjunto no contexto de edição de um template:
Quando o usuário clicar no botão (ícone com imagem sugestiva de um calendário) ao lado do campo “Data da Avaliação” ilustrado acima irá aparecer o componente de edição de datas ilustrado logo abaixo.