1 / 21

Fundação Aplicações de Tecnologias Críticas - Atech Rua do Rocio, 313 - 11º andar

Sistemas de Informação para a Gestão da Saúde. Fundação Aplicações de Tecnologias Críticas - Atech Rua do Rocio, 313 - 11º andar 04552-000 - Vila Olímpia -São Paulo/SP Tel.: (011) 3040.7318 - Fax: (011) 3040.7400.

syshe
Download Presentation

Fundação Aplicações de Tecnologias Críticas - Atech Rua do Rocio, 313 - 11º andar

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Sistemas de Informaçãopara a Gestão da Saúde Fundação Aplicações de Tecnologias Críticas - Atech Rua do Rocio, 313 - 11º andar 04552-000 - Vila Olímpia -São Paulo/SP Tel.: (011) 3040.7318 - Fax: (011) 3040.7400

  2. Componente de Gestão de Críticas e Repositório de Regras – experiência APAC/SMS Karina Passos1, Lúcia Beatriz de Área Leão Alves1 1Atech – Tecnologias Críticas

  3. Índice • Motivação • Idéia Central do Componente • Construindo o Componente • Máquina de Decisão • Repositório de Regras • Amplitude do Componente • Arquitetura Geral do Componente • Implementação do Componente • Dinâmica de Execução • Preocupações – Projeto/Implementação • Resultados/Conclusões

  4. produzindo… Motivação Executar criticamente verificações sobre procedimentos médicos Informações relevantes à tomada de decisão (autorização/rejeição de procedimentos médicos)

  5. Regra 1 NOK OK Regra 3 Regra 2 Resultado 2 Resultado 1 Máquina de Decisão Idéia Central do Componente Procedimento Médico

  6. Construindo o Componente • O esforço para desenvolvimento do componente ficou distribuido da seguinte forma: Definição dos mecanismos de manutenção e execução de máquinas de decisão. Identificação dasregras de negócio que definem as críticas a serem executadas sobre os procedimentos médicos, constituindo o repositório de regras.

  7. Máquina de Decisão Uma máquina de decisão é constituida pelo encadeamento de regras que definem as críticas a serem executadas sobre um procedimento médico, formando uma estrutura de árvore. O encadeamento das regras é definido com base nos tipos de retorno que uma regra pode assumir ( OK, NOK, ALERTA ). Parâmetros de identificação são atributos que identificam univocamente uma máquina de decisão. Parâmetros de execução são atributos cujos valores são utilizados na execução das regras que constituem a máquina de decisão.

  8. Exemplo de Máquina de Decisão • No contexto do projeto APAC (Autorização de Procedimentos de Alta Complexidade), a configuração da máquina de decisão ocorre em função da funcionalidade “Avaliação de Laudo Médico” e do parâmetro deidentificação “tipo de laudo médico”. A título de exemplo: No momento da avaliação de um laudo médico de quimioterapia, serão executadas todas as críticas relacionadas aos procedimentosde quimioterapia, sendo que o médico autorizador poderá usar os resultados produzidos pela execução das críticas para autorizar ou rejeitar os procedimentos solicitados no laudo médico.

  9. Repositório de Regras As regras são os elementos atômicos que constituem a máquina de decisão. O repositório de regras é composto por regras pré-definidas, que podem ser utilizadas por um ou mais processos de decisão. A execução da regra tem como entrada de dados: parâmetros de execução da máquina de decisão OU dados provenientes de visões de banco de dados. O índice de reaproveitamento de uma regra pertencente ao repositório é alto, uma vez que uma regra de verificação pode se aplicar a várias situações.

  10. Exemplos de Regras • No contexto do projeto APAC (Autorização de Procedimentos de Alta Complexidade) podem ser citadas as seguintes regras: • crítica sobre o limite clínico do procedimento (verifica se o • número de execuções está dentro do limite clínico estabelecido • pela AMB). • crítica sobre a compatibilidade de procedimento médico • com CID. • crítica sobre a competência da APAC (verifica se existe outra • APAC autorizada nos últimos “n” meses para o mesmo • procedimento).

  11. Amplitude do Componente

  12. Arquitetura Geral do Componente • Modelo de três camadas, utilizando-se a tecnologia J2EE: •  camada de apresentação: JSP com Framework Struts •  camada de lógica de negócio: Session Beans •  camada de persistência de dados: Entity Beans • Arquitetura definida pelo Framework: • Searcher: componente de busca • Cache: componente para se fazer cache de informações, visando melhor performance para a solução • Design Patterns: • SessionFaçade • ClientFaçade • ValueObject

  13. Implementação do Componente • Detalhando a implementação, os destaques são as classes: •  MaquinaDecisaoEngine.java • Regra.java • MaquinaDecisaoResult.java

  14. Classe MaquinaDecisaoEngine • Dispara o processamento de uma máquina de decisão • O método execute(…) é a interface entre o componente de gestão de críticas e qualquer sistema autorizador de procedimentos médicos

  15. Classe Regra • Classe base para todas as classes que implementam as regras do repositório • Cada classe que herda da classe base Regra.java deve implementar o seu método execute(…) • O método execute(…) é o ponto de partida para a execução de uma regra

  16. Classe MaquinaDecisaoResult • Encapsula o resultado de execução da máquina de decisão e disponibiliza esses resultados através de métodos

  17. execute Dinâmica de Execução Sistema Autorizador Procedimentos Médicos Execução de Regras MaquinaDecisaoResult.java Regra.java MaquinaDecisaoEngine.java

  18. Preocupações – Projeto/Implementação • Performance: uso de cache para minimizar a instanciação das classes que implementam as regras. • Isolamento do Componente: uso de visões de banco de dadoscapazes de retornar os dados necessários para a execução das regras, evitando desta forma o acesso direto às tabelas de negócio. Com essa independênciaentre regras e tabelas de negócio, potencializando o crescimento e amadurecimento de um repositório de regras que possa ser aplicado a qualquer sistema autorizador de procedimentos médicos, independentemente do modelo de dados adotado por cada sistema.

  19. Resultados/Conclusões Vantagens! • facilidade para se incorporar novas regras ao repositório de regras • ganho de qualidade e produtividade, uma vez que regras que estejam no repositório já foram amplamente exercitadas • é um componente capaz de produzir informações relevantes a um processo de tomada de decisão Desafios! • construção de um repositório de regras • delinear o escopo de uma regra e suas variáveis externas não é uma tarefa trivial

  20. Perguntas/Dúvidas

  21. Fundação Aplicações de Tecnologias Críticas - Atech Rua do Rocio, 313 - 11º andar 04552-000 - Vila Olímpia -São Paulo/SP Tel.: (011) 3040.7300 - Fax: (011) 3040.7400

More Related