6 de fevereiro de 2015

Caso de Uso: Amara Health Analytics

   Agora iremos expor uma entrevista do Planet Cassandra com Steve Nathan e Dwight Hare, respetivamente CEO e chefe de Arquitetura de Software da Amara Health Analytics.

Fonte: http://planetcassandra.org/blogs/Upload/Poste6cf1d48-1f06-4b32-9876-9e0009fd05df/amara.png


"Como o Amara Health Analytics ajuda seus clientes?

Steve Nathan: 'Nós fornecemos apoio à decisão em tempo real para os médicos, ajudando na identificação precoce de pacientes do hospital com graves riscos e doenças de rápida progressão, como sepse. São pacientes que potencialmente vão piorar nas próximas horas ou dias, portanto uma intervenção é extremamente urgente. Obviamente, isso significa que analisamos muitos fluxos de dados em tempo real na natureza.'

Como os clientes utilizam seu software?

Steve Nathan: 'Para os médicos, que são os usuários finais, é muito simples. Eles recebem um alerta de mensagem de texto, a partir de nosso sistema em seu smartphone ou tablet que chama sua atenção para um paciente em situação de risco. A mensagem inclui variáveis clínicas fundamentais para fornecer o contexto para o alerta.
                      Em termos de TI, nosso software conecta múltiplas fontes de dados do hospital. Em termos gerais, existem três formas de analise de dados: estruturado - tais como códigos de médicos e outros valores numéricos; desestruturado narrativo clínico - como anotações do médico, relatórios operacionais e resumos de descarga; e em tempo real com sinais fisiológicos de dispositivos  de monitoramento do paciente. Muitos desses dados nos vem em formato Health Level 7 (HL 7), mas podemos lidar com qualquer outro formato que o hospital possa ter.'

Qual técnica ou desafio de negócio que o levou a uma solução NoSQL contra um banco de dados relacional tradicional?

Dwight Hare: 'Um desafio significativo envolve o fato de termos uma grande quantidade de dados estruturados e não estruturados - mas isso é muito dinâmico, em que podemos passar a receber um feed de dados que nós não sabíamos quando construímos o sistema. O código que nós desenvolvemos é escrito em Java - a do lado do servidor normal, back-end das aplicações Java. Na verdade, é um interprete, porque queremos que o sistema seja muito dinâmico e seja capaz de ingerir novas fontes de dados que nós não sabíamos quando projetamos o sistema.
                     Precisávamos de algo que fosse muito dinâmico, no sentido de que o esquema pudesse mudar em tempo de execução, em tempo real. Nós também usamos grandes quantidades de textos narrativos longos, anotações de enfermagem, coisas desse tipo. Precisávamos fazer um monte de procura em texto, portanto, queria um tipo Solr de capacidade de consulta, em comparação com o que você recebe em SQL. SQL simplesmente não satisfaz todas as nossas necessidades, porque ele é muito hard-wired. Você tem que definir o esquema com antecedência, e isso não satisfaz muito bem aos dados não estruturados em termos de busca e manipulação. Decidimos, rapidamente, por um banco de dados NoSQL.
                    Olhamos em volta e o Cassandra e o DataStax Enterprise eram os líderes. Nós inserimos todos esses dados em uma variedade de Column Families, na nossa chamada principal, que é uma timeline do paciente,  uma série temporal da natureza. Nós colocamos todos os dados que estavam em streaming dos pacientes nas timelines em ordem cronológica para cada paciente. Temos uma imagem de tudo o que aconteceu a esse paciente a partir do momento em que ele entrou no hospital até o que ele saiu, e mesmo depois de sair, os laboratórios podem obter os resultados mais tarde. Então, nós geramos outras column families a partir daí.
                   Nós também geramos uma column family para relatório, e é a partir daí que nós realizamos as análises. Nós temos uma combinação de processamento de linguagem natural, aprendizado de máquina e análise baseada em regras de modo que construímos um grande conjunto de regras bastante complexas que deduzem o estado dos pacientes com base nos dados que estamos recebendo, e em seguida, identificamos os riscos para a sua saúde.
                  Estamos a procura de um acúmulo de evidências que indicam uma deterioração no estado do paciente, e por isso temos regras complexas. As saídas das regras são derivadas dos dados.
                 Os dados brutos do histórico do paciente e os fatos derivados estão no relatório.                 Construímos este conjunto muito grande de dados e, em seguida, podemos usar consultas para executar mais relatórios. Uma das coisas importantes sobre o nosso produto é que, a fim de realmente demonstrar o seu valor, temos de mostrar que os alertas enviados tem um impacto significativo sobre o atendimento dos pacientes. Por isso, queremos mostrar ao longo de um período de tempo que os pacientes que receberam alertas e, portanto, receberam tratamento mais cedo, têm melhores resultados.
                    A grande coisa sobre o Cassandra, DataStax e Solr é que podemos separar os dados e gerar relatórios variados. Podemos mostrar que os efeitos são devidos aos nossos alertas contra os outros fatores.'

Você disse que nunca olhou para bancos de dados relacionais para esta aplicação - mas você avaliou outros bancos de dados NoSQL?

Dwight Hare: 'Sim, nós olhamos muitos deles. Nós escolhemos o Cassandra e o DataStax porque gostamos de software open-source e se você tem a comunidade você não fica preso. Além disso, o hook-up para o Solr foi muito importante para nós. A capacidade de pesquisa e a correta estabilidade da empresa resultou no nosso desenvolvimento, de modo muito mais rápido.'"

Fonte: Planeta Cassandra, Disponível em <http://planetcassandra.org/blog/amara-health-analytics-uses-cassandra-to-proactively-protect-patients-health/>, acessado 04 de fevereiro de 2015.

Nenhum comentário:

Postar um comentário