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
copyright © atech 2004
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
copyright © atech 2004
– Tecnologias Críticas
Índice
•
•
•
•
•
•
•
•
•
•
•
copyright © atech 2004
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
Motivação
Executar criticamente verificações
sobre procedimentos médicos
produzindo…
Informações relevantes à tomada de decisão
(autorização/rejeição de procedimentos médicos)
copyright © atech 2004
Idéia Central do Componente
Regra 1
OK
Procedimento
Médico
NOK
Regra 2
Regra 3
Resultado 1
Resultado 2
Máquina de Decisão
copyright © atech 2004
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 das regras de negócio que definem as
críticas a serem executadas sobre os procedimentos médicos,
constituindo o repositório de regras.
copyright © atech 2004
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.
copyright © atech 2004
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 de identificaçã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
procedimentos de 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.
copyright © atech 2004
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.
copyright © atech 2004
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).
copyright © atech 2004
Amplitude do Componente
Componente
Gestão de Críticas
Sistemas
Autorizadores
Procedimentos
Médicos
Engine
Máquina de Decisão
Regras
Regras
Base
de
Dados
copyright © atech 2004
. Views do Componente
. Tabelas de Negócio
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:
 Session Façade
 Client Façade
 Value Object
copyright © atech 2004
Implementação do Componente
Detalhando a implementação, os destaques são as classes:
 MaquinaDecisaoEngine.java
 Regra.java
 MaquinaDecisaoResult.java
copyright © atech 2004
Classe MaquinaDecisaoEngine
MaquinaDecisaoEngine
+
execute(String, Map, Map) : MaquinaDecisaoResult
 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
copyright © atech 2004
Classe Regra
cd Engine
Regra
+
+
+
setIdRegra(Integer) : void
getIdRegra() : Integer
execute(MaquinaDecisaoContext) : RegraResult[]
 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
copyright © atech 2004
Classe MaquinaDecisaoResult
cd Engine
MaquinaDecisaoResult
-
resultadoRegras: List
+
+
+
addRegraResult(RegraResult) : void
hasFails() : boolean
getResultadoRegras() : List of RegraResult
 Encapsula o resultado de execução da máquina de decisão
e disponibiliza esses resultados através de métodos
copyright © atech 2004
Dinâmica de Execução
execute
Sistema Autorizador
Procedimentos Médicos
Execução de Regras
MaquinaDecisaoResult.java
Regra.java
MaquinaDecisaoEngine.java
copyright © atech 2004
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 dados capazes 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ência entre 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.
copyright © atech 2004
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
copyright © atech 2004
Perguntas/Dúvidas
copyright © atech 2004
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
copyright © atech 2004