Auditoria Pós - Programação

Transcrição

1 Auditoria Pós - Programação Julho

2 Índice 1. Introdução Visão do Processo Serviço Dataset Formulário Principal AuditoriaPos Arquitetura do Formulário HTML Auditorias_v Processo Configuração de Processos Itens importantes: Aba Informações Gerais Aba Versão Aba Workflow Graphical Designer Aba Avançado Formulário Regras de Triagem Arquitetura do Formulário HTML Config_Auditorias Cadastrar Usuário/Colaborador Cadatstro de Colaborador Cadastro de Grupos de Usuários Versão 1.0

3 1. 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. Para melhor compreendimento do processo acesse os dois manuais a seguir: 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 apiecmintegration.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. Versão 1.0 3

4 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. 3. 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. 4 Versão 1.0

5 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-ecmauditoryproxygen snapshot.jar disponível em <Diretório Programas>\ecm\Auditorias\public_html\proxygen\. No campo URL deverá ser informado a url de conexão com o AppServer seguindo o seguinte modelo Appserver://<servidor>:<porta>/<serviço>. No campo Objeto Remoto deverá ser informado o valor com.datasul.ems.healthcare.integration.ecmauditory. ECMPosAuditory. Versão 1.0 5

6 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. 4. Dataset 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. 6 Versão 1.0

7 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(); Versão 1.0 7

8 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 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. 5. Formulário Principal AuditoriaPos 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 8 Versão 1.0

9 knockout 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 Versão 1.0 9

10 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 _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 10 Versão 1.0

11 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. Versão

12 Na etapa 3 Descrição Principal das Fichas, deve-se selecionar o campo ds_anexo_principal. O conteúdo desse campo será apresentado como o valor de uma coluna na lista de tarefas. 12 Versão 1.0

13 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 Versão

14 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. 6. Arquitetura do Formulário HTML Auditorias_v2 O formulário HTML é composto por: Framework Visual Bootstrap na versão ( - Esse framework disponibiliza recursos visuais que embelezam o formulário e facilitam o desenvolvimento das telas. Biblioteca Javascript jquery ( - essa biblioteca é rica em recursos que facilitam a manipulação dos componentes HTMLs. Biblioteca Knockout ( - essa biblioteca possibilita utilizarmos o conceito MVVM (Model View View- Model). Esse padrão possibilita criarmos Data-Binding com a tela, ou seja, quando o valor é alterado no model o mesmo é atualizado automaticamente na tela e vice-versa. Detalhes sobre o padrão podem ser obtidos em ( Biblioteca ecm_datasets.js ou vcxmlrpc.js Bibliotecas fornecidas pelo ECM que possibilitam realizar chamadas aos Datasets por meio do formulário javascript. A biblioteca vcxmlrpc.js foi depreciada devido a bugs e por orientação da Equipe do ECM devemos utilizar a biblioteca ecm_datasets.js. Script auditorycontroller.js Esse script contém todas as funções javascripts necessárias para que as informações possam ser manipuladas em tela. Esse script utiliza-se dos frameworks citados acima para controlar o formulário. 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, databinding 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. 7. 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. 14 Versão 1.0

15 8. 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. Versão

16 8.1 Itens importantes: Aba Informações Gerais Código: Código único do processo. Descrição: Descrição do processo. Ativo?: Indicador que habilita o processo. Categoria: Permite informar a categoria do processo a fim de determinar um agrupador na tela. 16 Versão 1.0

17 8.1.2 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. Versão

18 8.1.3 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. 18 Versão 1.0

19 8.1.4 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: AuditoriaMedica Grupo dos Auditores Médicos. AuditoriaEnfermagem Grupo dos Auditores Enfermeiros. AuditoriaAdministrativa Grupo dos Auditores Administrativos. Reanalise Grupos dos Auditores de Reanalise. De acordo com a regra de auditoria, o sistema automaticamente, durante o processamento da atividade Triagem verifica o tipo da regra e encaminha para a atividade correspondente de acordo com a seguinte regra: Se o tipo da regra for Administrativa encaminha para a tarefa Auditoria Administrativa associando aos usuários do grupo AuditoriaAdministrativa. Se o tipo da regra for Médica encaminha para a tarefa Auditoria Médica associando aos usuários do grupo AuditoriaMedica Se o tipo da regra for Enfermagem encaminha para a tarefa Auditoria Enfermagem associando aos usuários do grupo AuditoriaEnfermagem. Os grupos de reanálise somente é utilizado quando a atividade do processo é encaminhada para uma tarefa de Reanálise. A partir desse momento o ECM está configurado para receber e gerenciar as tarefas de auditoria. As solicitações geradas a partir do ERP TOTVS 11 serão apresentadas na Central de Tarefas do usuário acessada através do menu Documentos/Central de Tarefas. Versão

20 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. 9. 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\ : config_auditorias_controller.js config_auditorias.html ajax-loader.gif jquery.js 20 Versão 1.0

21 knockout 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á ser realizado 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 Versão

22 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 _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 22 Versão 1.0

23 Após realizado o upload, o arquivo config_auditorias.html deverá ser marcado como Principal. Apenas esse arquivo deve estar marcado como Principal os demais devem estar marcados como Anexo. Para o campo Descrição recomendamos que seja utilizado o nome Regras de Configuração de Triagem para Auditoria. Versão

24 No campo Nome do Serviço de Dados deverá ser atribuído obrigatoriamente o valor config_auditorias_modelo como nome do serviço. Recomendamos que o campo cd_prestador_principal seja utilizado para descrição das fichas. Após isso clique em Confirmar para concluir o processo de inclusão do formulário. Nesse ponto teremos a seguinte estrutura: Clique sobre a pasta Regras de Configuração de Triagem para Auditoria em seu interior adicione uma nova ficha. O sistema apresentará a seguinte tela para inclusão de regra de Triagem: 24 Versão 1.0

25 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. 10. Arquitetura do Formulário HTML Config_Auditorias O formulário HTML é composto por: Framework Visual Bootstrap na versão ( - Esse framework disponibiliza recursos visuais que embelezam o formulário e facilitam o desenvolvimento das telas. Biblioteca Javascript jquery ( - Essa biblioteca é rica em recursos que facilitam a manipulação dos componentes HTMLs. Biblioteca ecm_datasets.js ou vcxmlrpc.js Bibliotecas fornecidas pelo ECM que possibilitam realizar chamadas aos Datasets por meio do formulário javascript. A biblioteca vcxmlrpc.js foi depreciada devido a bugs e por orientação da Equipe do ECM devemos utilizar a biblioteca ecm_datasets.js. 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. Versão

26 11. Cadastrar Usuário/Colaborador 11.1 Cadatstro 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. 26 Versão 1.0

27 11.2 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. Versão

28 Por padrão o processo de AuditoriaPós utiliza os seguintes grupos de auditorias: AuditoriaMedica Grupo dos Auditores Médicos. AuditoriaEnfermagem Grupo dos Auditores Enfermeiros. AuditoriaAdministrativa Grupo dos Auditores Administrativos. Reanalise Grupos dos Auditores de Reanalise. SegundaOpiniao Grupo dos Auditores de Segunda Opinião. 28 Versão 1.0