Histórico da Página
...
Desenvolvimento de Novas Funcionalidades ao Processo Auditoria Pós na ferramenta ECM
Produto: | Gestão de Planos de Saúde |
Módulo: | HAT - Atendimento ao Público |
Versão: | 12.1.x |
Assuntos: |
Introdução
Este manual apresentará as informações necessárias para o desenvolvimento de novas funcionalidades ao processo de Auditoria Pós na ferramenta ECM.
1. Qual a Visão do Processo?
O processo Auditoria Pós tem início por meio do programa api-regras-auditoria-movimentos.p. Esse programa é executado após a criação ou alteração de um documento do Revisão de Contas. Considera-se, também, como sendo uma alteração qualquer sobre um movimento.
A api-regras-auditoria-movimentos.p valida o documento / movimentos contra as regras cadastradas no programa ViewControlProcessRulesMain e caso uma regra seja atendida a api executa ação determinada pela regra.
Existem duas ações possíveis: Liberação Automática ou Pendente de Auditoria. A primeira valida automaticamente os movimentos para pagar e os libera para o faturamento, todas as glosas são validadas nesse processo. A última, através da api-ecmintegration.p, inicializa o processo no ECM por meio de uma chamada ao WebService WorkflowEngineService. Maiores detalhes podem ser obtidos no documento "Guia de Referência Utilização de Webservices.pdf" disponível na pasta de instalação do TOTVS ECM.
Na chamada do Webservice WorkflowEngineService, a API envia as seguintes informações nos seguintes campos:
Campos que possuem a chave do Documento em Auditoria:
- cd_unidade
- cd_unidade_prestadora
- cd_transacao
- nr_serie_doc_original
- nr_doc_original
- nr_doc_sistema
Campo mensagem a ser exibida na lista de tarefas:
- ds_anexo_principal – Esse campo possui o código do prestador executante / principal. E informações que identificam o lote de importação caso exista.
Campo indicador da ação da regra:
- papel_workflow – Indica se a regra envia para auditoria Administrativa, Médica ou Enfermagem.
Campos enviam uma cópia das informações referentes à Guia de Autorização, Documento e Movimentos:
- tmp_guiautor
- tmp_docrecon
- tmp_moviproc
- tmp_movimen_proced_compl
- tmp_mov_insu
- tmp_movimen_insumo_comp
Os campos recebem essas informações, pois quando o processo é inicializado a primeira ação realizada é processar a atividade de "Triagem" essa atividade utiliza-se desses campos possibilitando a verificação das regras de triagem e assim enviar para o Grupo de Auditoria desejado.
Todos os campos enviados na chamada do Webservice são automaticamente atribuídos nos campos, do formulário HTML, cujo tipo é "hidden" e o valor da propriedade "name" corresponde com o nome da variável acima.
Quando o Webservice é invocado, internamente o ECM cria uma ficha com o registro que armazena as informações dessa execução, atribui os valores aos campos enviados e em seguida, executa o evento "beforeStateEntry" cadastrado no processo. Esse evento verifica a etapa em que o processo se encontra e executa a ação correspondente a cada etapa.
Após, o evento "afterStateEntry" é executado. Esse evento inicializa a variável "historyMovto" do formulário de forma a indicar em qual etapa o processo se encontra. Essa informação é utilizada pelo formulário para que o mesmo saiba quais funcionalidades devem estar disponíveis naquele momento.
Nesse momento temos uma tarefa cadastrada e pendente para o grupo de Auditoria correspondente.
Por padrão os grupos de auditoria são:
- AuditoriaMedica.
- AuditoriaAdministrativa.
- AuditoriaEnfermagem.
- Reanalise.
Porém, esses grupos podem ser modificados conforme a regra de triagem informada.
Quando o usuário entra na tarefa para a realização da auditoria, o formulário por meio dos Datasets, chamado o serviço do appserver cadastrado e executa a procedure desejada da fachada fchsauecmposauditory.p para obter as informações desejadas.
2. Como é realizado o cadastro de Serviço?
O cadastro de Serviço acessado no menu Painel de Controle/Serviço permite a configuração dos dados de conexão com o AppServer utilizado. No caso desse projeto, esse serviço deve ser cadastrado obrigatoriamente com o nome "Auditoria" pois esse nome é utilizado em todos os Datasets do projeto.
Esse cadastro utiliza-se do cadastro de Ambientes para associar as bibliotecas Java que devem ser utilizadas para a conexão com o AppServer correspondente. Além disso, nesse cadastro, deve-se realizar o upload do jar contendo as classes do Proxygen que comunicará com o programa progress desejado, no caso o arquivo datasul-healthcare-integration-ecmauditory-proxygen-11.5.7-SNAPSHOT.jar disponível em "<Diretório Programas>\ecm\Auditorias\public_html\proxygen\".
...
Maiores detalhes podem ser obtidos no documento Guia de Integração "ECM.pdf" disponível na pasta de instalação do TOTVS ECM.
Importante:
Quando ocorrer uma alteração nas tabelas temporárias ou alterada a assinatura de uma procedure do programa Fchsauecmposauditory.p. Será necessário gerar novamente o Proxygen dessa fachada e realizado o upload do mesmo nesse cadastro.
...
3. Como é realizado o cadastro de Datasets?
O cadastro de Datasets acessado através do menu Painel de Controle / Dataset é responsável por fornecer o acesso as funções disponibilizadas por meio dos Serviços. Os processos e os formulários para obter acesso as informações utilizam-se dos Datasets para chamar as rotinas progress via AppServer.
Para o processo de Auditoria deve-se cadastrar os seguintes datasets, o conteúdo dos mesmos encontra-se disponível em "<Diretorio Programas>\ecm\Auditorias\public_html\datasets\":
- ApplyAuditoryRestriction - Simula a aplicação de uma Glosa Fracionada.
- ChangeMoviment - Simula a Troca de um movimento.
- GetAuditoryAssociatedGuides - Pesquisa as guias associadas a guia principal
- GetAuditoryBenefsModule - Pesquisa os Módulos do Beneficiário.
- GetAuditoryBenefsRealizationHistory - Pesquisa o Histórico de Realizações do Beneficiário.
- GetAuditoryGuideHistory - Pesquisa o Histórico da Guia.
- GetAuditoryRestriction - Pesquisa as Glosas referente ao Movimento
- GetAuditoryValues - Realiza a pesquisa das informações da conta que está em Auditoria.
- GetCoverage - Pesquisa os módulos de cobertura do beneficiário.
- GetMoviments - Pesquisa os movimentos para realizar a troca do movimento. Realiza pesquisa de procedimento ou insumo ou tipo de insumo.
- GetProvider - Pesquisa os Prestadores.
- GetRestrictions - Pesquisa a Glosa do sistema.
- GetUnity - Pesquisa as unidades.
- RollbackReleased - Realiza o bloqueio dos movimentos
- SaveDocument - Efetiva a persistência ou simulação das informações.
- ValidateRestriction - Realiza a validação de Glosa.
Todo o Dataset é formado pela assinatura function createDataset (fields, constraints, sortFields) padrão. Essa função por padrão deve retornar um objeto do tipo Dataset. Por meio da função DatasetBuilder.newDataset() existente na API pode-se criar o Dataset a ser retornado ao formulário. O dataset funciona como uma temp-table, por meio da função addColumn pode-se definir os campos da "temp-table" e por meio da função addRow é possível adicionar um registro ao mesmo.
Para realizar a chamada ao AppServer deve-se utilizar os seguintes comandos que fazem a conexão com o mesmo:
var servico = ServiceManager.getService("Auditoria");
var serviceHelper = servico.getBean();
var remoteObj = serviceHelper.createManagedObject("fchsauecmposauditory");
remoteObj.FCHSearchRecords ( <Parâmetros da procedure>);
A passagem de parâmetros deve seguir respeitando o tipo existente no proxygen. Assim como na camada Java do TOTVS 11, o proxygen retorna um objeto do tipo ResultSetHolder e que deve possui os campos da temporária progress e seus valores devem ser obtidos lendo-os na ordem determinada pela tabela temporária.
Exemplo:
while (rs.next()) {
var obj = new Object();
obj.errorSequence = "" + rs.getObject("errorSequence");
obj.errorNumber = "" + rs.getObject("errorNumber");
obj.errorDescription = "" + rs.getObject("errorDescription");
obj.errorParameters = "" + rs.getObject("errorParameters");
obj.errorType = "" + rs.getObject("errorType");
obj.errorHelp = "" + rs.getObject("errorHelp");
obj.errorSubType = "" + rs.getObject("errorSubType");
list.push(obj);
}
O valor recebido pela função progress é adicionado ao objeto Dataset que será enviado à tela.
Como as funções progress retornam diversas temporárias sendo que algumas contendo mais do que um valor, utilizamos o Dataset da seguinte forma:
Utilizamos um campo do Dataset para indicar qual conjunto de informação nos referimos e atribuímos ao campo à informação no formato JSON por meio do comando JSON.stringify.
O formato JSON é muito utilizado em sistemas WEB como substituto ao XML nas chamadas ajax por ser mais leve para trafegar informação. Maiores informações referentes ao padrão JSON podem ser obtidos em http://json.org/.
Observação: Toda a vez que um ocorre uma mudança de proxygen, os Datasets que utilizam a temporária ou função alterada necessitam ser modificados pra que possa contemplar as alterações.
...
4. Como criar o Formulário para armazenamento das informações?
Processo acessado através do menu Documentos/Navegação de Documentos.
Todo o Processo de Workflow necessita de um formulário base para a sua execução e armazenamento das informações. Um formulário é uma página html que utiliza-se de recursos de javascript, css e imagens para fornecer uma melhor experiência aos usuários.
No ECM um formulário é um fichário que contém em seu interior todos os componentes html (página html, scripts javascripts, css e imagens) utilizados pelo formulário.
Para fins de organização, recomendamos que no diretório raiz seja criada uma pasta "Formulários" e dentro dela seja criada uma pasta "Auditoria". No interior da pasta "Auditoria" deve-se criar um fichário com o nome "Formulário Processo Auditoria".
Deve ser realizado o upload dos seguintes arquivos existentes na pasta "<Diretorio Programas>\ecm\Auditorias\public_html\":
- auditorycontroller.js
- auditorias_v2.html
- ajax-loader.gif
- jquery.js
- knockout-3.0.0.js
- html5.js
- json2.js
- html5.js
- bootstrap-tooltip.js
- accounting.min.js
- bootstrap.css
- docs.css
- bootstrap-affix.js
- bootstrap-alert.js
- bootstrap-button.js
- bootstrap-carousel.js
- bootstrap-collapse.js
- bootstrap-dropdown.js
- bootstrap-modal.js
- bootstrap-popover.js
- bootstrap-responsive.css
- bootstrap-scrollspy.js
- bootstrap-tab.js
- bootstrap-transition.js
- bootstrap-typeahead.js
- respond.min.js
- Deverá realizar o upload das imagens contidas no diretório "<Diretorio Programas>\ecm\Auditorias\public_html\imgs\":
- message.png
- treatment.png
- undo.png
- trash.png
- money_add.png
- package_medical.png
- via_acesso_diferente.png
- via_acesso_mesma.png
- via_acesso_principal.png
- anestesista_not.png
- anestesista.png
- auxiliar.png
- demais.png
- insumo.png
- principal.png
- procedimento.png
- apply.png
- glyphicons-halflings.png
- glyphicons_367_expand.png
- glyphicons_369_collapse_top.png
- up.png
- down.png
- 1378257226_list-error.png
- Gnome-Document-Open-Recent-32.png
- Dialog-Apply-32.png
- Gnome-Dialog-Warning-32.png
- clock_32.png
- clock_down_48.png
- contract_clock_48_hot.png
- diagnostic.png
- info_24.png
- ok_24.png
- warning.png
- Add-Files-To-Archive-32.png
- Add-Files-To-Archive-Blue-32.png
- Add-Files-To-Archive-Yellow-32.png
...
Após realizado o upload o arquivo auditorias_v2.html deve ser marcado como Principal. Apenas esse arquivo deve estar marcado como Principal os demais devem estar marcados como Anexo.
...
Na etapa 6 | Eventos, deve-se adicionar o evento "displayFields". O conteúdo desse evento está no arquivo "displayFields.js". Esse evento é importante, pois atribui ao formulário o um indicador para que o mesmo saiba se está sendo apenas consultado ou se deve abrir em modo de edição, ou seja, para que a auditoria seja realizada. Isso é utilizado para bloquear as ações que podem ser realizadas no formulário quando o mesmo é apenas visualizado.
Exemplo: Quando um usuário consulta a tarefa sem assumi-la, o formulário não deve permitir que seja feita qualquer alteração.
5. Qual a Arquitetura do Formulário HTML Auditorias v2?
O formulário HTML é composto por:
...
Quando é realizado o upload de um formulário html ao ECM, o mesmo analisa todos os campos do tipo input que existam no mesmo e, caso seja adicionado novos ou a ordem dos mesmos for alterada ou ainda algum campo seja removido o ECM detecta que ocorreu uma alteração e gera uma nova versão desse formulário. Desta forma, as solicitações já existentes não irão sofrer nenhuma alteração. Apenas as próximas solicitações é que receberão os campos novos.
As pequenas alterações realizadas no formulário como, por exemplo, modificar cores, adicionar chamadas a funções js, data-binding a campos já existentes não fazem com que uma nova versão do formulário seja gerada.
As alterações realizadas no arquivo "auditorycontroller.js" não fazem com que uma nova versão do formulário seja gerada. Apenas alterações no arquivo "auditorias_v2.html" podem a vir gerar uma nova versão interna do formulário no ECM.
Processo
A Importação de Processos é acessada através do menu Processos / Importação de Processos.
Esse processo possibilita importar o processo configurado e que fora exportado. Por meio desse cadastro é possível importar o processo disponibilizado na pasta "<Diretorio Programas>\ecm\Auditorias\public_html\processo\ auditoriapos.xml"
Esse processo permite importar novos processos assim como sobrepor processos já existentes pelo que deseja importar.
Configuração de Processos
Nesse processo acessado através do menu Processos / Configuração de Processos podemos modificar os processos já cadastrados ou ainda criar novos processos.
Itens Importantes
Aba Informações Gerais
Código: Código único do processo.
...
Categoria: Permite informar a categoria do processo a fim de determinar um agrupador na tela.
Aba Versão
Versão: Esse campo indica qual a versão do processo que está sendo alterada. Para alterar a versão corrente de um processo, clique em "Nova Versão", no qual possibilitará editar o processo. Para que as alterações realizadas estejam disponíveis clique em "Liberar Versão". Quando uma solicitação é aberta ela surge numa versão de processo e encerra-se nessa mesma versão. Então, quando gerada uma nova versão do processo, apenas as próximas solicitações sofrerão as alterações realizadas.
Fichário: Código do Fichário (formulário) a ser utilizado pelo processo.
Aba Workflow Graphical Designer
Essa tela permite o desenho do processo seguindo o padrão BPM. Constitui-se o processo como um conjunto de atividades interligadas conforme a necessidade. Cada atividade possibilita informar as Instruções e que aparecerão ao usuário quando a solicitação estiver nessa atividade.
O campo Mecanismo de Atribuição permite informar a forma em que a atividade será atribuída, ou seja, pode ser atribuída a um usuário específico, a um grupo de usuários, a um papel de usuário.
Aba Avançado
Essa aba adicionará os eventos de formulários que possibilita a realização de controles e validações sobre o fluxo conforme a necessidade.
Na sub-aba Propriedades deve existir a propriedade AutomaticTasks informando o código de sequência das atividades que deverão ser automáticas, ou seja, que não necessitam de ação do usuário no formulário.
A sub-aba Eventos possibilita o cadastro dos eventos de controle do processo. No processo auditoriapos, os eventos utilizados são "afterStateEntry" e "beforeStateEntry". Os conteúdos desses eventos já são preenchidos quando o processo é importado/sobreposto. Mas está disponibilizado na pasta "<Diretorio Programas>\ecm\Auditorias\public_html\eventos\". Os arquivos javascripts desse diretório estão nomeados de acordo com o nome do evento utilizado.
Maiores detalhes podem ser obtidos no documento "Guia de Referência Customização de Workflow.pdf" disponível na pasta de instalação do TOTVS ECM.
Após ter importado o processo "auditoriapos.xml" e verificado se os eventos foram importados, devemos liberar a versão do processo para que o mesmo fique disponível para uso.
Esse processo jamais poderá ser inicializado diretamente pelo TOTVS ECM. A solicitação é gerada pelo ERP TOTVS devido a ação de uma das regras de auditoria sobre algum documento/movimento.
Por padrão o processo de Auditoria Pós utiliza os seguintes grupos de auditorias:
...
A lista de Tarefas a concluir agrupa as tarefas assumidas pelo usuário logado e estão pendentes de seu parecer.
A lista Tarefas em pool apresentam as tarefas conforme os grupos que o usuário participa. Desta forma, o usuário pode encontrar uma tarefa referente ao grupo de auditoria que participa e assume a tarefa. Quando um usuário assume a tarefa, a mesma é enviada para a lista de Tarefas a concluir do mesmo.
Observações: Para que o cliente possa customizar os grupos de usuários de auditoria criando grupos específicos de usuários para auditar determinados prestadores deve-se então criar uma parametrização de Regra de Direcionamento das Auditorias.
Formulário Regras de Triagem
Processo acessado através do menu Documentos/Navegação de Documentos.
O controle das regras de direcionamento das auditorias se dá por meio de regras cadastradas nas fichas. As fichas são registros de parametrização oriundos de um formulário. Um formulário é uma página html que utiliza-se de recursos de javascript, css e imagens para fornecer uma melhor experiência aos usuários.
No ECM um formulário é um fichário que contém em seu interior todos os componentes html (página html, scripts javascripts, css e imagens) utilizados pelo formulário.
Para fins de organização, recomendamos que no diretório raiz seja criada uma pasta "Formulários" e dentro dela seja criada uma pasta "Auditoria". No interior da pasta "Auditoria" deve-se criar um fichário com o nome "Regras de Configuração de Triagem para Auditoria", deverá ser realizado o upload dos seguintes arquivos existentes na pasta "<Diretorio Programas>\ecm\Auditorias\public_html\":
...
A regra permite especificação do grupo de auditoria que deseja ser utilizado conforme o Prestador Principal e o Prestador Executante.
Ou seja, quando o Prestador Principal for o informado e o Prestador Executante for o informado a regra será aplicada e irá sobrepor os grupos padrões pelos informados nessa parametrização.
Marque a opção Ativar para habilitar a regra.
Para salvar a regra deve-se concluir clicando no "V" existente no canto superior direito.
Arquitetura do Formulário HTML Config. Auditorias
O formulário HTML é composto por:
...
Script config_auditorias_controller.js – Esse script contém todas as funções javascripts necessárias para controlar os zooms para os grupos disponíveis no ECM.
Cadastrar Usuário / Colaborador
Cadastro de Colaborador
Esse cadastro acessado em Painel de controle/ Colaboradores possibilita gerenciar as informações de um usuário além de permitir associá-lo aos grupos o qual o mesmo irá pertencer.
Cadastro de Grupos de Usuários
Esse cadastro é acessado em Painel de Controle / Grupos de Usuários possibilita o cadastro dos grupos pelos quais os usuários irão pertencer. Os grupos podem ser utilizados nos processos como um mecanismo de atribuição.
...