Otimização de Atendimento Hospitalar Baseada em AI v2P

OTIMIZAÇÃO DA ASSISTÊNCIA MÉDICA
EM UNIDADES HOSPITALARES E DE
PRONTO ATENDIMENTO
07/04/2016
Uma abordagem baseada
em AI com redes Bayesianas
Uma alternativa baseada em softwares
adaptativos para enfrentar o desafio de
proporcionar uma assistência médica
eficaz, definindo melhor a delicada
fronteira entre pronto atendimento e
internação hospitalar.
Otimização da assistência médica em unidades hospitalares e de pronto atendimento
Otimização da assistência médica em

unidades hospitalares e de pronto
atendimento
Uma abordagem baseada em AI com redes Bayesianas
I - Histórico e contextualização
As persistentes insuficiências e inadequações do atendimento público de saúde levaram, ao longo de quase
um século, à criação de vários níveis e redes de atendimento. Além dos hospitais generalistas, foram criados
os especializados em trauma-ortopedia, os postos de saúde e, mais recentemente as UPAs, estas concebidas
com o objetivo de aumentar a capilaridade do atendimento médico público, servindo como uma combinação
de triagem com atendimento ambulatorial, filtrando e absorvendo casos mais graves do que os normalmente
atendidos pelos postos de saúde, mas que não demandam estruturas (nem os longos e burocráticos processos)
hospitalares, e redirecionando apenas os casos que as exigem.
Entretanto, a crônica deficiência de estrutura de atendimento nos hospitais impede que os casos mais severos
e complexos possam ser a eles encaminhados, e assim muitos pacientes que demandam uma estrutura
hospitalar acabam permanecendo nas UPAs em um regime não-declarado de internação, sem possibilidade de
receberem atendimento adequado e impedindo, pela superlotação de leitos e assentos, o tratamento
ambulatorial que as unidades podem prestar com propriedade e qualidade.
Ao criar capacidade técnica para uma “internação por default”, a desvirtualização das UPAs tornou-se
inevitável: Pacientes, hospitais e postos de saúde previsivelmente as usariam como válvula de escape,
minando a proposta original e simplesmente aumentando a capilaridade dos problemas pré-existentes de falta
de estrutura nas redes de hospitais e postos de saúde, o que dificulta ainda mais a solução dos mesmos, em
consequência do aumento da complexidade de gestão e da redução do efeito de escala.
A proposta que se segue é a de gerenciar a logística do atendimento na rede integrada (hospitais, UPAs, postos
de saúde), de forma a minimizar ou até mesmo eliminar os problemas aqui relatados.
II – Objetivos da presente proposta de solução

Nossa proposta de solução é de fato uma combinação de ferramentas adaptativas de AI (essencialmente redes
neurais otimizadas por algoritmos genéticos) que alimentam um mecanismo de decisão Bayesiano, conforme
descreveremos ao longo do texto. Com isso, objetivamos atacar o problema supracitado através de:
➢ Agilização e aumento de precisão no processo de triagem e diagnóstico do paciente;
➢ Sugestão imediata de tratamento local ou de redirecionamento (para hospitais ou postos de saúde);
➢ Previsão da evolução do caso e do tempo e custo de permanência do paciente.
Direitos autorais reservados para Ward Systems e IntelliSearch – Experteam Consultoria Ltda. - Página 1
III – Estrutura macro da aplicação

A solução é constituída por duas camadas principais, ilustradas abaixo. A mais fundamental absorve todas as
demandas adaptativas, ou seja, a necessidade de adaptação dinâmica, inerente à evolução de patologias (do
ponto de vista coletivo) com o tempo. Nela estão concentradas as ferramentas de AI baseadas em redes
neurais otimizadas por algoritmos genéticos. A camada superior, composta por um mecanismo Bayesiano,
recebe vários inputs, inclusive da camada adaptativa, e elabora sugestões seguindo uma linha metodológica
de análise de decisão. Ela serve também de interface entre usuários (médicos, enfermeiros e administradores
hospitalares) e os componentes da camada adaptativa.
Acesso por
laptops e
dispositivos
móveis Camada
de decisão
Decisão Base integrada de
(mecanismo disponibilidades
Bayesiano) de recursos
Modelo de Modelo
Modelo Camada
inferência de preditivo de
categorizador adaptativa
permanência e evolução do
da patologia
custo caso
Figura 1
Outros inputs importantes para a camada de decisão vêm de bases de dados externas, contendo informações
sobre disponibilidades de recursos e estatísticas do sistema de saúde envolvido.
Prosseguimos com o detalhamento de cada componente da solução, em uma descrição bottom-up, que
consideramos mais adequada para o correto entendimento.
IV – Componentes da solução
IV.1 – Modelo categorizador de patologia

Módulo central na camada adaptativa, o categorizador de patologia é essencial para todo o processo que
culmina com decisões adequadas a cada caso.
O desafio de categorizar uma doença a partir de uma anamnese muitas vezes incompleta (limitada a um relato
apenas dos sintomas que afligem o paciente no momento da consulta) e um histórico clínico frequentemente
fragmentado ou completamente ausente/indisponível, é por si só intimidador.
Abordagens do tipo check list, fluxograma ou árvore de decisão com alternativas rígidas e fixas frequentemente
conduzem a pré-diagnósticos errados e consequentemente a um direcionamento indevido do paciente.
Apenas ilustrando com um exemplo simplificado e hipotético, para fins de entendimento, imaginemos o
fluxograma a seguir como ferramenta de pré-diagnóstico.
Página 2 - Direitos autorais reservados para Ward Systems e IntelliSearch – Experteam Consultoria Ltda.
Dengue
S
Febre? Pele
avermerllhada
?
S S
S
Dores N
musculares
Sintomas ?
respiratórios? N Gripe
N
N Resfriado Dores
abdominais S
?
Sintomas
gástricos? S
N
Figura 2
Se a unidade estiver atendendo uma amostra de população com cor de pele que não seja clara (por exposição
regular ao sol ou por pigmentação natural), ou que esteja sendo afetada por uma mutação de vírus, a
vermelhidão na pele pode não ser um sintoma, ou então pode não ser detectável. Isso levaria a um pré-
diagnóstico errado e consequentemente a um direcionamento inadequado. A ligação entre a saída negativa
de febre alta para o teste sobre sintomas gástricos também pode ser enganosa, especialmente se um paciente
com dengue estiver ainda na curva ascendente de temperatura, ou que tenha tomado um medicamento com
propriedades antitérmicas sem ter noção do fato.
As limitações desses métodos decorrem de 3 fragilidades básicas:
➢ São totalmente determinísticos e não adaptativos, portanto, mesmo pequenas mudanças (em
frequência) ou lacunas no quadro típico de sintomas levam a um caminho lógico completamente
errado;
➢ O encadeamento rígido por arborização impede que vários aspectos (situados em ramos diferentes da
árvore), sejam analisados em conjunto. No exemplo acima, se o paciente apresentar sintomas
respiratórios e febre alta, a verificação de sintomas gástricos não é acrescida ao fluxo, o que poderia
ser importante para distinguir, por exemplo, dengue de zika;
➢ A hierarquia/priorização necessariamente imposta pela estrutura em árvore pode levar, em muitos
casos, a uma inversão do que seria a sequência adequada. Ex.: em alguns casos, a verificação de
sintomas gástricos deve anteceder a de sintomas respiratórios e não o contrário.
As soluções com base em métodos adaptativos, como os sistemas de redes neurais artificiais (ANNs), não são
enganadas por mudanças ou por desvios prematuros na ramificação da árvore fixa, e a análise subjacente
sempre leva em consideração todos os fatores relevantes que tiverem sido colhidos na anamnese.
Utilizamos, como núcleo da nossa solução, para a categorização da patologia, o NeuroShell Classifier, da Ward
Systems, pela sua flexibilidade, ilimitada capacidade adaptativa e precisão dos resultados obtidos. É uma
ferramenta com mais de 15 anos de mercado, sofrendo constantes atualizações e aperfeiçoamentos, com
milhares de clientes totalmente satisfeitos, inclusive todos os que o utilizam em aplicações de health care. Em
alguns casos, na fase de treinamento da rede neural, suplementamos o NS Classifier com o Chaos Hunter,
também da Ward Systems, igualmente testado e robusto.
Descreveremos a seguir a utilização, com base em exemplos de telas do sistema. A primeira, abaixo, mostra
as variáveis utilizadas no treinamento da rede neural. Na primeira tela define-se quais as variáveis
independentes de input do modelo e a dependente (de output quando em produção). No jargão de

modelagem, usamos variáveis independentes e a variável dependente, embora, a priori, não possamos afirmar
que as variáveis de input sejam independentes entre si. Mas como estamos tratando de modelos por redes
neurais, não lineares e não regressivos, o fato de que as variáveis de input tenham alguma forma de
interdependência (desde que não sejam determinantes uma da outra) não interfere na qualidade (capacidade
preditiva e/ou classificatória) final do modelo.
Note-se que todas as variáveis têm valores numéricos, o que é imperativo em se tratando de ANNs. Algumas
são variáveis com domínio dentro do conjunto dos Reais (as contínuas), outras apenas números inteiros
(discretas ou categóricas) e outras ainda. Booleanas (binárias). Muitos inputs de uma anamnese são
alfanuméricos, e uma das funções da interface que mencionamos no tópico III é justamente a de traduzir dados
alfabéticos/alfanuméricos em numéricos (e vice-versa, ao apresentar resultados ao usuário). Além disso,
mesmo para dados originalmente numéricos, a interface aplica normalização dos respectivos domínios. Assim,
por exemplo, pressões sistólicas e diastólicas devem ser convertidas em números num intervalo contínuo de 0
a 1, em vez de aplicadas como input pelo seu valor nominal em mmHg.
Um dos valores agregados pela IntelliSearch é o conjunto de metodologias de transformação e normalização
de dados embutidas na citada interface.
Na tela abaixo, também foi selecionado o treinamento da rede neural usando otimização por algoritmos
genéticos, reduzindo assim a tendência a “overfitting” da rede neural ao conjunto de dados utilizados no ciclo
específico de treinamento, tornando mais generalizante, com tal otimização, a capacidade preditiva da rede.
O modelo de treinamento no NS Classifier é o de uma rede neural probabilística (PNN), que usa algoritmos
genéticos para escolher os pesos de cada input.
Figura 3
Os dados na tela seguinte ilustram bem a tipologia das variáveis e seus domínios. A variável de “output” (em
tempo de produção) ou dependente (a coluna mais da direita), no caso a categoria da patologia (patology-
group) é uma variável categórica: valores discretos inteiros de 1 a 6, cada um deles representando uma
categoria. Ex.: 1 significa patologia cardiovascular, 2 respiratória, 3 endócrina e assim por diante.
Nas variáveis de input “independentes”, compondo todas as demais colunas com exceção da primeira à
esquerda (mera identificação do paciente), ilustramos alguns exemplos, mais especificamente:
• Variáveis discretas categóricas, como o histórico cardiovascular (hist-card) e o tipo de vermelhidão

(localizada) exibido (rash);
• Variáveis discretas não-categóricas, tipicamente contagens, alimentadas pelo seu valor nominal, como
o número de visitas prévias do paciente à unidade (prev-visit), e o número de sintomas respiratórios
relatados pelo paciente (resp-signs);
• Variáveis contínuas alimentadas pelo seu valor nominal, como idade (age) e número de dias já sob
observação na unidade, internado ou não (days-in);
• Variáveis Booleanas (binárias), como se o paciente apresenta ou não febre (fever) ou dores abdominais
(ab-pain) ou teve passagem anterior com os mesmos sintomas, sem diagnóstico (prev-hist);
• Variáveis contínuas que passam por normalização do domínio de valores, como o score clínico (clin-
score) e contagens de série vermelha e branca do hemograma (ind4 e ind5).
Figura 4
Note-se que este é um exemplo extremamente simplificado, com finalidades ilustrativas e didáticas apenas,
por isso com poucas variáveis. Não existe limite para o número de variáveis de input (independentes) embora
deva haver, para cada rede, apenas uma variável dependente de output. Caso se queira modelar mais de uma
variável, pode-se utilizar redes diferentes, em paralelo ou em sequência (quando o output de uma for usado
como input de outra). De fato, em aplicações para classificação de patologias, a abordagem mais comum é a
de mais de uma rede, a primeira classificando em grandes categorias, como a aqui ilustrada. O output dessa
rede (uma das seis categorias), serve de input nas redes seguintes (uma para cada categoria) que definiriam a
subcategoria da patologia. Ex. a primeira rede define a categoria como endócrina e a segunda (usando o
resultado da primeira como input) define como sendo distúrbio da tireoide.
Importante notar que os dados alimentados à rede, para o efetivo treinamento da mesma, são dados
realmente observados, inclusive os da variável dependente, a categoria da patologia. Ou seja, o paciente com
id 828 efetivamente foi diagnosticado como portador de uma patologia da categoria 5 (gastrenterológica).
Uma vez alimentados os dados históricos, o próximo passo é a realização do treinamento da rede neural com tal amostra
de dados. Como selecionamos a opção com otimização por algoritmos genéticos, um dos gráficos disponíveis para o
acompanhamento do processo de treinamento é o histograma de importância relativa das variáveis de input
(independentes), ilustrado abaixo. Esse gráfico é importante pois dá um feedback essencial a quem está projetando o
modelo, visto que ele pode indicar variáveis que estão sendo pouco significativas na capacidade preditiva da variável
dependente (a categorização da patologia no caso), o que pode servir de base para substituí-las por outras que sejam mais
determinantes.
Figura 5
Note-se que aqui fica bem ilustrada a capacidade adaptativa da rede neural. Após adicionar mais dados à rede,
eventualmente de casos mais recentes, a variável vermelhidão (rash) mostra (fig. 6) uma substancial queda de
importância na determinação da categoria da patologia. Os pesos relativos das demais variáveis também
mudaram. Isso acontece simplesmente, e de forma automática, por adição de dados ao ciclo de treinamento
da rede, que “aprende”, sem que tenhamos que refletir em código de programas.
Figura 6
O treinamento da rede é tão mais demorado e demandante de recursos computacionais quanto maior a
amostra de dados (linhas e colunas). Para agilizar o processo de treinamento, o processamento pode ser
distribuído numa rede local, por várias CPUs, de forma automática ou manual.
Após realizado o treinamento da rede, submetemos a mesma a um teste da sua capacidade
preditiva/classificatória da patologia do paciente. A matriz de classificação é uma forma ilustrativa da
qualidade da predição e está exibida a seguir. Quanto melhor a capacidade preditiva da rede, mais as
contagens se concentram na diagonal de fundo rosado.
Figura 7
São exibidos também os percentuais de falsos-positivos, falsos-negativos, suas contrapartes e os coeficientes
de sensitividade e especificidade. Outo gráfico importante é a curva ROC, ilustrada a seguir. Quanto melhor a
capacidade preditiva/classificatória do modelo, mais o vértice da curva aproxima-se do canto superior
esquerdo do gráfico.
Figura 8
O treinamento da rede deve ser executado periodicamente, com frequência mensal ou próxima disso, sempre acrescendo
novos dados e eventualmente descartando variáveis que se vão mostrando inexpressivas. É a repetição do processo de
treinamento, com a exposição da rede a novos dados, que acionam a característica adaptativa das redes neurais, que
literalmente vão “aprendendo com a própria experiência” e assim aumentando sua capacidade preditiva/classificatória.
Uma vez concluído o treinamento, se o desenvolvedor estiver satisfeito com os resultados, ele pode salvar a matriz de
classificação e a curva ROC para efeito de documentação de controle do ciclo de treinamento, bem como as estatísticas
finais, ilustradas no relatório ilustrado a seguir, que pode ser impresso, salvo em PDF ou exportado para Excel, por exemplo.
Figura 9
Finalmente, ele pode salvar a rede (em formato run-time executável) para utilização dentro da aplicação.
Figura 10
O módulo run-time (extensão .net), além de poder ser usado como rotina de qualquer aplicação (que deverá
passar a ele os parâmetros ou seja, os valores das variáveis independentes (dados e sintomas do paciente),
pode ser executado também diretamente pelo run-time launcher (NeuroShell Fire) da Ward Systems, conforme
ilustrado a seguir, o que pode ser útil em testes adicionai,s antes da entrada em produção da rede neural.
Figura 11
IV.2 – Modelo de inferência de permanência e custo

Por questões didáticas, abordaremos agora o módulo que infere o tempo de permanência do paciente e o
respectivo custo.
Ao contrário do classificador de patologia, cuja variável de output (“dependente”) é categórica (6 classificações
diferentes), portanto com um domínio discreto, aqui estamos lidando com variáveis de output contínuas
(domínio contido no conjunto dos números Reais). Daí a necessidade de utilizarmos o NeuroShell Predictor
e/ou o Chaos Hunter, ferramentas adequadas para esse tipo de output. Apresentaremos a seguir um exemplo
ilustrativo, para inferência do tempo de permanência do paciente sob regime de observação/internação,
também simplificado para efeitos didáticos.
Como no caso do módulo de categorização da patologia, para iniciarmos o processo de treinamento da rede
neural, importamos os dados e selecionamos quais serão inputs e outputs, bem como o método de
treinamento (rede neural pura ou otimizada por algoritmos genéticos). Informamos isso numa janela de
configuração idêntica à ilustrada na figura 3 (pág. 4).
Neste caso, as 13 variáveis de input ou “independentes”, exibidas com as 13 colunas na planilha (2 a 14) a
seguir (fig. 12), são:
• Variáveis discretas categóricas, como o segmento de renda (seg-renda), a natureza da ocupação
profissional (natureza), se o paciente tem plano de saúde e qual o tipo de cobertura (indplan1);
• Variáveis discretas não-categóricas, tipicamente contagens, alimentadas pelo seu valor nominal, como
o número de visitas à unidade, pelo mesmo paciente, que incorreram em extensão do período de
observação além do previsto (ind2);
• Variáveis contínuas alimentadas pelo seu valor nominal, como idade (seg-idade) e número de dias já
sob observação na unidade, internado ou não (days-in);
• Variáveis Booleanas (binárias), uma delas sobre a condição corrente de emprego e se tem
antecedentes de atendimento (seguido de internação) com os mesmos sintomas;
• Variáveis contínuas que passam por normalização do domínio de valores, como o score clínico (ind3)
e pressão arterial diastólica e sistólica (ind4 e ind5 respectivamente).
• A variável “Gravidade” sintetiza a expectativa com relação à evolução do quadro do paciente. No
sistema em produção, essa variável será fornecida como output (preditivo) do módulo “Modelo
preditivo de evolução do caso”, apresentado no próximo tópico. Aqui, entretanto, na fase de
treinamento da rede neural, o valor alimentado nesta coluna deverá ser o efetivamente observado.
• De forma análoga, a variável “pathology-group”, nesta fase uma variável de input (independente),
quando em produção, será o output preditivo do módulo categorizador de patologia, descrito no
tópico anterior. Aqui, na fase de treinamento da rede neural, o valor alimentado nesta coluna deverá
ser o da categoria de patologia efetivamente observada para o paciente em questão.
A variável permanência, output deste modelo quando em produção, é o valor preditivo para o número de dias
de permanência do paciente na unidade ou no sistema de saúde como um todo. Aqui, para efeitos de
treinamento da rede, deverá ser alimentado o valor efetivamente observado.
Figura 12
Alimentado o histórico de dados para treinamento, pode-se escolher qual o parâmetro de medida que será
utilizado para avaliar a capacidade preditiva do modelo, no caso, optando por minimizar o erro médio
quadrado (MSE). Essas mesmas opções, ilustradas a seguir (fig. 13) estão disponíveis também no NeuroShell
Classifier (usado no categorizador de patologia) e no Chaos Hunter.
Figura 13
O passo seguinte é a execução do ciclo de treinamento da rede neural que, como no caso dos outros módulos,
gera, entre outras informações, o gráfico de importância relativa dos inputs, de significativa utilidade para a
gestão do modelo (inclusão de novas variáveis e exclusão de antigas que deixam de contribuir). O gráfico é
estruturalmente idêntico ao da fig. 6 na página 6.
Figura 14
Outro gráfico importante para o acompanhamento do ciclo de treinamento é o “learning level” que mostra a
evolução do parâmetro escolhido para medir a capacidade preditiva do modelo (no nosso caso, o erro médio
quadrado). Quando a curva se torna assintótica, após várias gerações de redes neurais moduladas pelo
algoritmo genético, o operador pode interromper o treinamento, não apenas para poupar tempo e capacidade
de processamento, como para reduzir a tendência a “overfitting” da rede neural ao conjunto de dados usado
para treinamento, tornando-a mais generalizante.
Figura 15
Após a conclusão do ciclo de treinamento, a rede pode ser testada, aplicando-a não apenas aos dados usados
para o treinamento, mas a um conjunto maior, preferivelmente disjunto daquele utilizado até então (“out-of-
sample”). O gráfico abaixo compara o valor previsto contra o efetivamente observado em cada linha da
amostra testada (in-sample, out-of-sample ou ambas as amostras conjugadas).
Figura 16
Outro gráfico que ajuda a visualizar a capacidade preditiva do modelo é o gráfico de dispersão a seguir. Para
modelos cujo output (var. Dependente) é uma variável contínua, ele é o análogo da matriz de classificação,
que é usada para modelos cujo output é uma variável discreta (categórica) como é o caso do categorizador de
patologia abordado no tópico anterior (vide fig. 10 na pág. 8).
Figura 17
Os dois gráficos acima (figuras 16 e 17), exibem os resultados dos testes de uma rede neural cujo ciclo de
treinamento foi interrompido após apenas 3 gerações criadas pelo algoritmo genético. Para ilustrar o efeito de
um ciclo mais longo de treinamento sobre os mesmos dados, apresentamos a seguir os gráficos similares que
resultam dos testes de uma rede cujo treinamento passou por 32 gerações (o ciclo da figura 15), usando os
mesmos dados, demonstrando o ganho na capacidade preditiva (“fitting”) bem significativo.
Figura 18
Figura 19
Quando o modelo atingir um nível de desempenho (capacidade preditiva) considerado adequado pelo
desenvolvedor, basta salvar a rede, na forma de módulo executável conforme ilustrado na figura 10 (página
8).
Aqui ilustramos um modelo preditivo para o tempo de permanência do paciente. Para um modelo que se
proponha a prever o custo, uma segunda rede será necessária, já que a variável de output (dependente) é
outra. Certamente terá também um conjunto diferente de variáveis de input, mas a estrutura e o
funcionamento serão análogos aos aqui exemplificados.
IV.3 – Modelo preditivo de evolução do caso

A proposta deste modelo é a de gerar uma medida da expectativa de agravamento do caso de um determinado
paciente, tendo já obtido a categoria e subcategoria da patologia que o acomete, além de outros dados clínicos
e do seu histórico médico, que servirão de input (variáveis independentes). Como a variável de output
(dependente) – indicador da gravidade máxima esperada, será contínua, as ferramentas da Ward Systems
apropriadas são o NeuroShell Predictor, já demonstrado, ou o Chaos Hunter.
Considerando que o funcionamento difere muito pouco do módulo descrito no tópico anterior, e não há nada
novo do ponto de vista conceitual, usaremos o exemplo a seguir para demonstrar as funcionalidades do Chaos
Hunter, ainda não exibidas neste documento.
Para a seleção de variáveis de input (independentes) e de output (dependente), o procedimento é idêntico ao
do NeuroShell Classifier e ao do NeuroShell Predictor, conforme ilustrado na figura a seguir.
A única diferença é que o Chaos Hunter permite um método simples de normalização de dados, por subtração
da média, que melhora a capacidade preditiva para domínios muito amplos. Entretanto, nossa experiência
recomenda processos de normalização específicos para cada variável, e a IntelliSearch dispõe de um leque de
funções de normalização de dados que se mostram extremamente produtivas não apenas em melhoria da
predição (redução de MSE) como também na performance do ciclo de treinamento (torna-se bem mais rápido).
Figura 20
As dezesseis variáveis de input utilizadas no ciclo de treinamento seguem, com as respectivas descrições
resumidas:
1. age Idade do paciente (variável contínua – valor nominal)
2. stable Se o paciente está estável (variável binária S/N)
3. active Se o paciente está consciente e ativo (variável binária S/N)
4. bilirubin Nível de bilirrubina (variável contínua normalizada)

Se o paciente é hipoglicêmico recorrente, hipoglicêmico circunstancial, pré-
diabético controlado, pré-diabético sem controle, diabético tipo 1 controlado,
5. glicemic-status diabético tipo II controlado, diabético tipo I sem controle, diabético tipo II sem
controle (variável discreta/categórica)
6. cardiac-status Status cardiovascular do paciente (variável discreta/categórica)
7. resp-status Status respiratório do paciente (variável discreta/categórica)
8. gastric-status Status gastrointestinal do paciente (variável discreta/categórica)
9. nephr-status Status renal do paciente (variável discreta/categórica)
10. histopath-status Status histopatológico do paciente (variável discreta/categórica)
11. average fever Valor médio da febre (variável contínua normalizada)
12. avrg-score Valor médio do score clínico do paciente (variável contínua normalizada)
13. diastolic Valor médio da pressão diastólica do paciente (variável contínua normalizada)
14. systolic Valor médio da pressão sistólica do paciente (variável contínua normalizada)
Classificação macro da patologia do paciente (variável categórica). Em
15. patology-group
situação de produção, este será o resultado da classificação fornecido pelo
módulo de categorização de patologia. Aqui, para o ciclo de treinamento, é

alimentado o valor efetivamente observado no caso.
Classificação mais detalhada da patologia do paciente (variável categórica).
Em situação de produção, este será o resultado da classificação fornecido pelo
16. pathology-subgroup módulo de categorização de patologia. Aqui, para o ciclo de treinamento, é
alimentado o valor efetivamente observado no caso.
A variável de output (dependente) “Gravidade”, é uma variável contínua que sintetiza a expectativa de
agravamento do estado de saúde do paciente. Em regime de produção, ela servirá de input para o módulo de
inferência de tempo de permanência e custo, bem como para a camada de decisão Bayesiana da aplicação,
abordada no próximo tópico.
Após alimentados os dados para treinamento, selecionamos quais serão usados para treinamento (“in-sample”
ou “optimization set”) e em quais (“out-of-sample”) será aplicado o modelo resultante, como teste de
capacidade preditiva do mesmo.
Figura 21
Em seguida, optamos pelo método de otimização. No caso do Chaos Hunter é oferecida, além da alternativa
de algoritmos genéticos (“evolution strategy”), a de Particle Swarm Optimization (PSO). A escolha de uma ou
outra depende de quanto o espaço de soluções contenha “ótimos localizados” que podem atrair o algoritmo
de PSO e desviá-lo (impedindo-o de atingir) de um “ótimo global”. Algoritmos genéticos são menos vulneráveis
(mas não imunes) ao efeito, embora a estratégia de PSO possa convergir (“swarm”) mais rápido a um “ótimo
global” se trabalharmos melhor as sementes iniciais do algoritmo (“seeds”). A IntelliSearch desenvolveu um
algoritmo próprio de geração de sementes (“seeding”) que maximiza a dispersão das mesmas sobre o espaço
de soluções, evitando assim a armadilha dos “ótimos locais”, tanto para PSO como para algoritmos genéticos.
O NeuroShell Classifier e o NeuroShell Predictor, por trabalharem apenas com otimização de redes neurais,
oferecem apenas a alternativa de otimização por algoritmos genéticos.
Figura 22
A etapa seguinte consiste em delimitar o escopo de funções matemáticas que o ciclo de treinamento do
modelo utilizará, os chamados blocos básicos (“building blocks”) que serão usados na fórmula final – o modelo
propriamente dito. Aqui é cabível uma consideração sobre diferenças entre o Chaos Hunter e o NeuroShell
Predictor, por exemplo. Ambos se propõem a derivar um modelo para uma variável dependente (“de output”
em tempo de produção) contínua, a partir de um conjunto de variáveis de input (independentes). Entretanto,
quando usamos o NeuroShell Predictor, o “engine” interno é uma General Regression Neural Network (GRNN).
Nele, o algoritmo genético busca as funções de peso corretas para cada input. Essas “mutações” da rede neural
vão se refinando até atingir, pela estratégia “evolutiva”, uma ANN com capacidade preditiva máxima, e de
acordo com o critério predeterminado pelo desenvolvedor (ex.: maior R2 ou menor MSE).
O Chaos Hunter, embora seja capaz de gerar modelos baseados em redes neurais, permite também
desenvolver modelos envolvendo funções matemáticas mais convencionais, tornando-se a ferramenta mais
apropriada quando o desenvolvedor espera poder modelar adequadamente a variável dependente desejada
usando métodos de regressão não-linear mais comuns (logística, polinomial, exponencial/hipergeométrica,
logarítmica ou trigonométrica, por exemplo).
Ilustrando, na tela da figura a seguir, escolhemos, na condição de desenvolvedor do modelo, como “building
blocks”, as funções logarítmicas, exponenciais, Booleanas e polinomiais. Não ativamos redes neurais, para
demonstrar melhor a diferenciação. Entretanto, ativamos, dentro do conjunto de redes neurais, a função
sigmóide, para flexibilizar, ao algoritmo genético, a possibilidade de desenvolver uma fórmula que utilize
alguma modalidade de regressão logística.
No Chaos Hunter, o algoritmo genético criará várias gerações de fórmulas, e a diferença de uma geração para
outra, as “mutações” das fórmulas, são obtidas por alteração de expoentes, de argumentos de funções, de
coeficientes, por adição e exclusão de termos, inclusão exclusão de funções (delimitadas pelos blocos básicos
pré-determinados), inclusão e exclusão de variáveis de input (entre as 16 supridas ao modelo) e constantes.
Quanto maior o número de variáveis, de linhas de dados e de “building bocks” selecionados, maior a precisão,
embora maior o tempo de processamento e maior a demanda por capacidade computacional exigidos pelo
ciclo de treinamento. Por isso o Chaos Hunter é apresentado muitas vezes como uma ferramenta de AI para
“Formula optimization”.
Figura 23
A figura a seguir ilustra a tela de treinamento do modelo em seu estágio final. A janela maior, superior
esquerda, mostra a evolução da fórmula, cada vez que uma nova mutação apresenta um valor de R2 maior do
que do que até então era a “melhor fórmula”. Os números da geração na qual a fórmula foi criada estão na
primeira coluna da janela, em ordem decrescente. A coluna seguinte exibe o valor de R2, também em ordem
decrescente, obviamente (o Apêndice deste documento mostra o mesmo conteúdo numa tabela em formato
maior, de visualização mais fácil).
Figura 24
A terceira coluna da mesma janela apresenta a melhor fórmula obtida pelo modelo para a derivação da
gravidade da condição do paciente, a partir de apenas seis das variáveis de input (o modelo desconsiderou as
demais, por não adicionarem capacidade preditiva). A fórmula que traduz a gravidade do paciente é, portanto:
Gravidade=sqrt(abs((cube(log(((-2,677042)^2 + abs(histopath-status)^2)))*nephr-status+abs(bilirubin)*log(diastolic)+abs((1/((-
2,677042) + active)))*exp(average fever))))
As variáveis utilizadas são: active, bilirubin, nephr-status, histopath-status, average fever, diastolic
A janela da direita, na figura 24, apresenta a mesma fórmula no formato “arborizado”.
O gráfico imediatamente abaixo das duas janelas mostra a evolução do valor do parâmetro R2 ao longo das
várias gerações criadas durante o ciclo de treinamento, tornando-se assintótico e levando à interrupção após
1500 gerações sem melhoria do parâmetro (critério definido pelo desenvolvedor – vide fig. 22)
Tendo a fórmula do modelo, podemos aplicá-la à amostra “out-of-sample” para testar a capacidade preditiva
e de generalização do mesmo.
O gráfico a seguir, equivalente ao ilustrado nas figuras 16 e 18 (gerado pelo NeuroShell Predictor), compara o
valor previsto contra o observado, da variável de output “Gravidade”, para cada linha da amostra “out-of-
sample”. O gráfico logo abaixo, em verde, exibe as diferenças.
Figura 25
O gráfico da figura a seguir (26), equivalente ao ilustrado nas figuras 16 e 18 (gerados pelo NeuroShell
Predictor), compara o valor previsto contra o observado, da variável de output “Gravidade”, para cada linha
da amostra “out-of-sample”. O gráfico mais abaixo, em verde, exibe as diferenças, para cada linha de dados.
Também como o NS Predictor, o Chaos Hunter oferece a demonstração dos resultados do teste do modelo na
forma mais sintética e expressiva do gráfico de dispersão, exibido a seguir para a amostra “out-of-sample” e
“in-sample” (respectivamente figuras 26 e 27). O primeiro gráfico demonstra que o modelo é levemente
“otimista” (o que pode ser desejado) com relação aos níveis de gravidade maiores. Isso decorre do fato de
termos selecionado pesadamente funções polinomiais, mas pode ser corrigido (se desejado pelo
desenvolvedor) acrescendo funções trigonométricas aos “building blocks”.
Figura 26
Figura 27
Assim que o desenvolvedor estiver satisfeito com o desempenho do modelo, basta salvá-lo, usando a opção
exibida na lista suspensa do menu “file”, na fig. 26 acima. O executável criado pode ser chamado como rotina
de qualquer programa de aplicação, que passará os valores das seis variáveis de input, recebendo em resposta
a previsão da evolução da gravidade do paciente. Alternativamente, como o modelo é uma fórmula, esta pode
ser simplesmente implantada diretamente como código na aplicação. Finalmente, o relatório final de
treinamento do modelo pode ser visualizado, impresso ou exportado (para Excel, por exemplo).
Figura 28
IV.4 – Mecanismo de inferência Bayesiana

Os outputs dos módulos da camada adaptativa, ou seja, a categoria (e também a subcategoria) da patologia, a
previsão da evolução da gravidade do estado do paciente, e a estimativa preditiva do tempo de permanência
(decorrente dos dois primeiros), estão entre os principais inputs da camada de decisão, que também usa dados
acumulados em bases externas, do sistema de saúde para o qual a aplicação está sendo desenvolvida.
Para o desenvolvimento de aplicativos baseados em metodologias de análise de decisão fundamentadas em
mecanismos Bayesianos, utilizamos frequentemente softwares abertos como o BAT, o BEAST e o WinBUGS
(este último desenvolvido pelo MRC de Cambridge em parceria com o Imperial College School of Medicine de
Londres). Para algumas aplicações bem específicas podemos usar também o JAGS e/ou o Stan.
Talvez a forma mais didática de ilustrar um mecanismo de decisão Bayesiano, sem recorrer a telas de software
ou a opções de topologia para a rede de decisão a ser construída, seja o recurso a exemplos simples, como
faremos a seguir.
Vamos supor que a camada adaptativa (Redes Neurais supervisionadas por algoritmos genéticos), entregou à
camada de decisão Bayesiana (vide fig.1), os seguintes dados sobre os pacientes Juliana e Oswaldo:
Juliana Oswaldo
Idade 38,7 anos Idade 56,3 anos
Cat.: Sistêmica Cat.: Gastroenterológica
Patologia Probabilidade: 83% (*) Patologia Probabilidade: 79% (*)
Subcat.: Dengue Subcat.: Hepatite B
Previsão de Previsão de
12,7 dias Probabilidade: 77% (**) 16,2 dias Probabilidade: 81% (**)
permanência permanência
Gravidade 7,25 (alta) Probabilidade: 85% (**) Gravidade 8,72 (alta) Probabilidade: 77% (**)
(*) Calculada como p=1-Fp onde Fp é o percentual de falsos positivos para essa categorização, fornecido pelo NS Classifier.
(**) Calculada como 1-DL onde DL (dispersão local) é calculada como a raiz do erro médio quadrado (fornecido pelo NS Predictor e/ou Chaos Hunter)
dividida pelo valor fornecido (gravidade ou previsão de permanência).
Em resumo, são dois casos relativamente graves, de patologias diferentes, e ambos com previsão de
permanência longa, portanto cada um deles deve ser redirecionado a um hospital o mais rapidamente possível.
Ambos podem, por exemplo, requerer o suporte de diálise, demandando, portanto, equipamentos
indisponíveis em unidades de pronto-atendimento e disputadíssimos mesmo na rede hospitalar convencional.
Digamos que a aplicação obtenha da base de dados externa (vide figura 1), os seguintes dados de
disponibilidade dos hospitais X e Y, ambos pertencentes à rede hospitalar do sistema de saúde em questão.
Hospital X Hospital Y
Nº de unidades com diálise 8 Nº de unidades com diálise 5
N de unidades atualmente ocupadas 8 N de unidades atualmente ocupadas 5
Nº de pacientes em espera 5 Nº de pacientes em espera 4
Prazo estimado para absorção da fila atual (dias) 4 Prazo estimado para absorção da fila atual (dias) 2
Turnover médio, em dias, do conjunto 3,5 Turnover médio, em dias, do conjunto 2,1
Ainda da mesma base de dados externa, a aplicação captura as seguintes estatísticas do sistema de saúde como
um todo (probabilidades obtidas com base em frequência de registros):
✓ Probabilidade de que um internado usuário de diálise (H) seja paciente de caso grave de dengue (d): P(d│H) = 25%
✓ Probabilidade de que um internado usuário de diálise (H) seja paciente de caso grave de hepatite B (b): P(b│H) = 36%
✓ Probabilidade de que um paciente (grave) internado qualquer (desconsiderando a patologia) faça uso de diálise: P(H)= 15%
Vamos supor agora, como uma simplificação didática, que a gravidade do estado de saúde do paciente seja
independente (coeficiente de correlação = 0) da categoria e da subcategoria da patologia (a fórmula
encontrada pelo Chaos Hunter – topo da página 19 - dá suporte a tal hipótese). Podemos então assumir que
a probabilidade de Juliana ser portadora de um caso grave de dengue é:
P(d)= 83% * 85% ≈ 70,6%
Já no caso do Oswaldo, a probabilidade de que seja um paciente de um caso grave de hepatite B é:
P(b)= 79% * 77% ≈ 61%
Temos portanto, pela lei de Bayes, para o caso da Juliana, a probabilidade de que ela necessite de suporte de
diálise P(H│d), dado que muito provavelmente é portadora de um caso grave de dengue:
P(H│d) = P(d│H) * P(H)/P(d) => P(H│d) = 25% * 15%/70,6% => P(H│d) ≈ 5,31%
No caso do Oswaldo, a probabilidade de que ele necessite de suporte de diálise P(H│b), dado que
provavelmente é portador de um caso grave de hepatite B:
P(H│b) = P(b│H) * P(H)/P(b) => P(H│b) = 36% * 15%/61% => P(H│b) ≈ 8,85%
Com base nos dados de disponibilidade dos Hospitais X e Y, as decisões sugeridas pela aplicação seriam:
➢ Ambos os pacientes devem ser redirecionados à rede hospitalar convencional do sistema de saúde em
questão, visto que demandarão cuidados, recursos técnicos e tempo de permanência incompatíveis
com unidades de pronto atendimento.
➢ O paciente Oswaldo será redirecionado ao Hospital Y, e adicionado à fila de espera do recurso de diálise
do estabelecimento, dado que tem maior probabilidade de necessitar de tal suporte.
➢ A paciente Juliana deverá ser redirecionada ao hospital X, adicionada à fila de espera do recurso de
diálise do mesmo hospital, porém com revisão da posição nas próximas 48h (tanto da evolução do
estado do paciente quanto da disponibilidade de recursos hospitalares).
Obviamente, este é um exemplo muito simplificado, apenas para ilustrar o funcionamento e interação dos
vários componentes da nossa solução. Análises estatísticas mais complexas devem ser consideradas numa
situação real. Ex.: Deve-se levar em conta, antes da decisão sobre qual paciente será encaminhado a qual
hospital, o desvio padrão do turnover dos equipamentos de diálise (não apenas a média) bem como
considerações sobre a disponibilidade de leitos para internação, comparada à expectativa de permanência de
cada paciente.
Para incorporar tais análises, torna-se inevitável a definição e construção de ume rede de decisão Bayesiana,
cuja topologia pode variar, embora normalmente siga a diretriz metodológica de diagramas de influência e/ou
diagramas causais. Mesmo que a camada adaptativa absorva a maior parte da dinâmica de evolução de
doenças e quadros clínicos, árvores de decisão e fluxogramas com regras rígidas ainda devem ser evitados
também na camada de decisão. Árvores probabilísticas (e fluxogramas equivalentes) podem ser usadas como
“ramificação” parcial, nos estágios finais do processo de decisão, mas isso somente nesses casos, que são raros.
V – Sobre a Ward Systems e a IntelliSearch

A Ward Systems é referência mundial em aplicações de AI destinadas ao apoio a decisões técnicas (em
medicina, biologia, engenharia, etc.), financeiras, comerciais e administrativas. Os softwares aqui
mencionados passaram por muitos anos de desenvolvimento, testes nas mais variadas aplicações, além de
serem constantemente aperfeiçoados para integrar novas tendências em AI (ex.: a inclusão de Particle Swarm
Optimization como método de otimização no Chaos Hunter, em alternativa a algoritmos genéticos).
Sobre aplicações em Health Care, há muitas referências no próprio website da Ward Systems
( http://www.wardsystems.com/apptalk.asp )
Entre as mais ilustrativas (há outras no link acima), relacionamos:
➢ Forecasting Treatment Costs - Cleveland Clinic;
➢ Forecasting Length of Patient Stay - Johns Hopkins University School of Medicine;
➢ A Neural Network/Genetic Algorithm Model to Predict Caesarean Section in a Busy Labor Ward -
University Medical Center of UMDNJ
➢ Diagnosing Prostate Cancer - Kaman Sciences Corporation (Colorado Springs, CO)
A IntelliSearch, por sua vez, tem mais de 12 anos de experiência contínua na utilização de ferramentas da Ward
Systems, e nesse tempo desenvolveu metodologias e camadas de software adicionais (interfaces,
normalizadores de dados de input e output para redes neurais, algoritmos de “seeding”).
Nossa longa cooperação com a Ward Systems também nos dá o privilégio de determos conhecimentos sobre
a melhor forma de configurar os parâmetros de otimização (treinamento de redes neurais), além de técnicas
para seleção de dados de treinamento e tratamento dos mesmos (redução de dimensionalidade, normalização,
desdobramento de variáveis, extensão de domínios).
Finalmente, como únicos parceiros ativos no Brasil temos a total credibilidade e autorização da Ward Systems
para prestarmos suporte local e consultoria relativa a seus softwares. Pela mesma condição de parceria,
conseguimos obter descontos para os clientes, em relação ao preço de lista.
Apêndice
Evolução da otimização da fórmula, pelo Chaos Hunter, para a variável “gravidade” do estado do paciente. A
última geração que apresentou melhoria na fórmula (a de nº 1.693) está no topo da lista. Melhorias anteriores
em ordem decrescente do número da respectiva geração de fórmulas.
Gen. R-Squared Fórmula deduzida pelo Chaos Hunter para a Gravidade do paciente Inputs utilizados
active, bilirubin,
sqrt(abs((cube(log(((-2,677042)^2 + abs(histopath-status)^2)))*nephr- nephr-status,
1.693 0,89973 status+abs(bilirubin)*log(diastolic)+abs((1/((-2,677042) + histopath-status,
active)))*exp(average fever)))) average fever,
diastolic
active, bilirubin,
sqrt(abs((cube(abs(log(((-2,677042)^2 + histopath-status^2))))*nephr- nephr-status,
1.544 0,899029 status+bilirubin*log(diastolic)+abs(((1/(-2,677042)) + histopath-status,
active))*abs(exp(average fever))))) average fever,
diastolic
active, bilirubin,
sqrt(abs((cube(log(abs(((-2,322496)^2 + histopath-status^2))))*nephr- nephr-status,
1.297 0,892387 status+bilirubin*log(diastolic)+abs(((1/(-2,322496)) + histopath-status,
active))*exp(average fever)))) average fever,
diastolic
active, bilirubin,
sqrt(abs((nephr-status*cube(log(((-2,322496)^2 + abs(histopath- nephr-status,
765 0,889701 status)^2)))+log(diastolic)*bilirubin+abs((1/((-2,322496) + histopath-status,
active)))*exp(average fever)))) average fever,
diastolic
active, bilirubin,
762 0,887835 status)^2)))+(diastolic + active)*log(bilirubin)+abs((1/(- histopath-status,
2,322496)))*exp(average fever)))) average fever,
diastolic
active, bilirubin,
755 0,886372 status)^2)))+diastolic*active+(1/abs((log(bilirubin) + (- histopath-status,
2,322496))))*exp(average fever)))) average fever,
diastolic
stable, active,
sqrt(abs(((nephr-status*cube(log(((-2,322496)^2 + abs(histopath- bilirubin, nephr-
715 0,879897 status)^2)))+active*bilirubin+abs((1/(diastolic + (- status, histopath-
2,322496))))*exp(average fever)) + log(stable)))) status, average
fever, diastolic
stable, active,
sqrt(abs(((nephr-status*cube(log(((-2,322496)^2 + abs(histopath- bilirubin, nephr-
552 0,87943 status)^2)))+diastolic*bilirubin+abs((1/((-2,322496) + status, histopath-
active)))*exp(average fever)) + log(stable)))) status, average
fever, diastolic
active, bilirubin,
sqrt(abs((nephr-status*cube(log((histopath-status^2 + (- nephr-status,
505 0,868679 2,322496)^2)))+diastolic*abs(((-2,322496) + histopath-status,
abs((1/active))))+exp(bilirubin)*average fever))) average fever,
diastolic
stable, active,
abs(sqrt(abs((nephr-status*cube(log((histopath-status^2 + (- bilirubin, nephr-
415 0,868251 2,322496)^2)))+(diastolic + (1/(-2,322496)))*stable+(active + status, histopath-
exp(bilirubin))*average fever)))) status, average
fever, diastolic
stable, active,
abs(sqrt(abs((nephr-status*cube(log((histopath-status^2 + (- bilirubin, nephr-
415 0,865713 2,322496)^2)))+diastolic*(stable + (-2,322496))+(active + status, histopath-
exp(bilirubin))*average fever)))) status, average
fever, diastolic
stable, active,
sqrt(abs((nephr-status*(cube(log((histopath-status^2 + 0,5174103^2))) + bilirubin, nephr-
376 0,861564 (diastolic + abs(0,5174103)))+abs(active)*stable+exp(bilirubin)*average status, histopath-
fever))) status, average
fever, diastolic
stable, active,
sqrt(abs(((nephr-status*cube(log(((-2,322496)^2 + histopath- bilirubin, nephr-
358 0,861379 status^2)))+diastolic*abs((abs((-2,322496)) + status, histopath-
active))+exp(bilirubin)*average fever) + stable))) status, average
fever, diastolic
stable, active,
sqrt(abs(((nephr-status*cube(log((histopath-status^2 + (- bilirubin, nephr-
301 0,846962 2,322496)^2)))+diastolic*abs(((-2,322496) + status, histopath-
abs(active)))+bilirubin*exp(stable)) + average fever))) status, average
fever, diastolic
active, bilirubin,
sqrt(abs((((nephr-status*cube(abs(log((histopath-status^2 + (- nephr-status,
242 0,815608 2,322496)^2))))+diastolic*abs((-2,322496))+active*bilirubin) + histopath-status,
(1/patology-group)) + avrg-score))) avrg-score, diastolic,
patology-group
active, bilirubin,
sqrt(abs((abs((nephr-status*cube(log((histopath-status^2 + (- nephr-status,
226 0,814172 2,322496)^2)))+diastolic*abs((-2,322496))+active*bilirubin)) + histopath-status,
(1/patology-group)))) diastolic, patology-
group
stable, active,
sqrt(abs(((nephr-status*cube(abs(log((histopath-status^2 + (- bilirubin, nephr-
181 0,81123 2,322496)^2))))+diastolic*(abs((-2,322496)) + active)+bilirubin*stable) + status, histopath-
(1/patology-group)))) status, diastolic,
patology-group
stable, active,
sqrt(abs((nephr-status*abs(abs((cube(log((histopath-status^2 + (- bilirubin, nephr-
170 0,805314 2,322496)^2))) + diastolic)))+active*bilirubin+(1/stable)*(patology-group status, histopath-
+ (-2,322496))))) status, diastolic,
patology-group
stable, active,
sqrt(abs((nephr-status*cube(abs(log((histopath-status^2 + (- bilirubin, nephr-
160 0,78736 2,322496)^2))))+abs(diastolic)*(active + (- status, histopath-
2,322496))+bilirubin*exp((stable + (1/patology-group)))))) status, diastolic,
patology-group
stable, active,
sqrt(abs((nephr-status*cube(log(((-2,322496)^2 + histopath- bilirubin, nephr-
145 0,650744 status^2)))+(abs(diastolic) + abs(active))*bilirubin+stable*exp((patology- status, histopath-
group + (-2,322496)))))) status, diastolic,
patology-group
stable, active,
abs(exp(ln((stable*active+histopath-status*log(nephr-status)+avrg- bilirubin, nephr-
117 0,607214
score*abs((1/bilirubin)))))) status, histopath-
status, avrg-score
nephr-status,
101 0,537564 cube(abs(log((nephr-status^2 + (histopath-status + (-1,154784))^2))))
histopath-status
nephr-status,
71 0,537546 cube(log((nephr-status^2 + (histopath-status + (-1,154784))^2)))
histopath-status
nephr-status,
64 0,449154 log((3,054628^2 + (cube(histopath-status) + nephr-status)^2))
histopath-status
nephr-status,
56 0,448525 log(((-1,988753)^2 + (cube(histopath-status) + nephr-status)^2))
histopath-status
nephr-status,
41 0,447577 log((4,5419^2 + (cube(histopath-status) + nephr-status)^2))
histopath-status
nephr-status,
28 0,423851 log((nephr-status^2 + cube(histopath-status)^2))
histopath-status
nephr-status,
22 0,340846 log((histopath-status^2 + cube(nephr-status)^2))
histopath-status
20 0,323247 log(((-14,07932)^2 + cube(nephr-status)^2)) nephr-status
gastric-status,
18 0,282241 log((gastric-status^2 + cube(abs(nephr-status))^2))
nephr-status
bilirubin, glicemic-
log(((bilirubin + pow(glicemic-status, diastolic))^2 + cube(nephr-
17 0,250548 status, nephr-
status)^2))
status, diastolic
bilirubin, nephr-
15 0,245556 log(cube((pow(bilirubin, diastolic)^2 + nephr-status^2)))
status, diastolic
bilirubin, cardiac-
10 0,23731 log(((cardiac-status + pow(bilirubin, diastolic))^2 + cube(nephr-status)^2)) status, nephr-
status, diastolic
bilirubin, cardiac-
log(((bilirubin + pow(sqrt(abs(cardiac-status)), diastolic))^2 +
5 0,197058 status, nephr-
abs(cube(nephr-status))^2))
status, diastolic
Direitos de uso e propriedade intelectual deste material

As marcas NeuroShell Classifier (também apresentado como NS Classifier), NeuroShell Predictor (ou NS
Predictor), NeuroShell Fire e Chaos Hunter são registradas como propriedade intelectual (copyright) da Ward
Systems. O mesmo ocorre para todas as figuras exibidas neste material, com exceção das de números 1 e 2
(páginas 2 e 3, respectivamente).
Todo o restante do material (com exceção da figura de capa, de domínio público) é de propriedade intelectual
da IntelliSearch (razão social Experteam Consultoria Ltda.).
Este material tem autorização e uso, apenas como consulta, para a vossa organização, não devendo ser
distribuído a qualquer outra pessoa física ou jurídica, mesmo que a esta relacionada.

Otimização de Atendimento Hospitalar Baseada em AI v2P

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Otimização de Atendimento Hospitalar Baseada em AI v2P

Diunggah oleh

Hak Cipta:

Format Tersedia

OTIMIZAÇÃO DA ASSISTÊNCIA MÉDICA

Otimização da assistência médica em

II – Objetivos da presente proposta de solução

➢ Agilização e aumento de precisão no processo de triagem e diagnóstico do paciente;

➢ Sugestão imediata de tratamento local ou de redirecionamento (para hospitais ou postos de saúde);

➢ Previsão da evolução do caso e do tempo e custo de permanência do paciente.

III – Estrutura macro da aplicação

IV.1 – Modelo categorizador de patologia

independentes de input do modelo e a dependente (de output quando em produção). No jargão de

• Variáveis discretas categóricas, como o histórico cardiovascular (hist-card) e o tipo de vermelhidão

IV.2 – Modelo de inferência de permanência e custo

IV.3 – Modelo preditivo de evolução do caso

1. age Idade do paciente (variável contínua – valor nominal)

2. stable Se o paciente está estável (variável binária S/N)

3. active Se o paciente está consciente e ativo (variável binária S/N)

4. bilirubin Nível de bilirrubina (variável contínua normalizada)

6. cardiac-status Status cardiovascular do paciente (variável discreta/categórica)

7. resp-status Status respiratório do paciente (variável discreta/categórica)

8. gastric-status Status gastrointestinal do paciente (variável discreta/categórica)

9. nephr-status Status renal do paciente (variável discreta/categórica)

10. histopath-status Status histopatológico do paciente (variável discreta/categórica)

11. average fever Valor médio da febre (variável contínua normalizada)

módulo de categorização de patologia. Aqui, para o ciclo de treinamento, é

IV.4 – Mecanismo de inferência Bayesiana

V – Sobre a Ward Systems e a IntelliSearch

Direitos de uso e propriedade intelectual deste material

Anda mungkin juga menyukai