Jump to section

Microsserviços e integração de TI no setor de saúde

Copiar URL

Os microsserviços permitem que desenvolvedores da área de saúde e outros setores criem aplicações a partir de serviços com baixo acoplamento, facilitando o desenvolvimento, teste, implantação e upgrade. Por causa desses benefícios, os desenvolvedores do setor de saúde estão substituindo a tecnologia de integração de TI de geração anterior, o enterprise service bus (ESB), pelos microsserviços.

Como em toda grande empresa, o ambiente de TI das organizações de saúde é um conjunto de vários sistemas dispersos que precisam compartilhar dados críticos. Sistemas como os de transferência de internações/altas (ADT), de agendamento, de laboratórios, de radiologia e de cobranças, precisam se comunicar. E esses dados podem ser literalmente vitais em uma emergência médica.

Na era digital, os prestadores de serviços de saúde adotaram registros eletrônico de saúde (EHR), mas seus benefícios ficam muito limitados se os dados não forem compartilhados entre as várias aplicações. O desafio da integração dos sistemas de saúde vem de 1987 com o estabelecimento do Health Level Seven (HL7), um padrão global para transferência de dados clínicos e administrativos entre aplicações do setor de saúde. Depois do estabelecimento dessa linguagem comum, o setor de saúde precisava de uma maneira de conectar suas aplicações para que elas pudessem se comunicar via HL7.

Anos atrás, os profissionais de TI descobriram que fazer conexões diretas point-to-point entre cada aplicação não é prático e fica mais complicado à medida que a empresa cresce. Além disso, apesar de a HL7 oferecer um formato universal, não havia uma maneira comum de interpretar os campos. Assim, era preciso transformar alguns dados e a conectividade para viabilizar a comunicação entre sistemas de saúde.

A primeira tecnologia de integração adotada pelos prestadores de serviços de saúde foi o Interface Engine (IE), um servidor que funcionava como hub entre todos os sistemas de um hospital. Cada sistema se conectava ao IE, que transformava os dados e os roteava para os outros sistemas, conforme necessário. Há 20 anos surgiu o enterprise service bus (ESB). Parecido com o IE, um ESB funciona como hub para troca de dados entre aplicações de saúde, usando principalmente a HL7. Um ESB oferece transformação de dados, conversão de protocolo, roteamento e suporte para serviços web, JMS, HTTP e SOAP com gerenciamento e monitoramento simplificados. Há duas décadas o ESB é a solução mais usada para integração, tanto na área de saúde como em outros setores.

Desde a introdução do ESB, o desenvolvimento de aplicações evoluiu muito. Uma das mudanças mais importantes foi o avanço do desenvolvimento ágil e do DevOps, que deixou os ESBs para trás.

O pipeline de DevOps é um ciclo de vida de desenvolvimento baseado em mudanças incrementais e testes automatizados contínuos. Na era do DevOps, as características que popularizaram o ESB se tornaram um obstáculo. Em um ESB, todas as integrações são implantadas em uma aplicação monolítica. O que era uma vantagem, agora é um problema que torna o ESB incompatível com DevOps.

Num ambiente de desenvolvimento moderno, os ESBs apresentam as seguintes limitações:

  • Incompatibilidade com o desenvolvimento ágil e ferramentas de DevOps: muitos dos desenvolvedores recém-formados de hoje são treinados em ambientes de DevOps. Esses desenvolvedores ágeis produzem mais quando usam suas ferramentas preferidas, as soluções de DevOps mais recentes no mercado. No entanto, os ESBs não foram projetados para serem compatíveis com elas.
  • As mudanças afetam todo o sistema: para fazer qualquer alteração nas regras de um ESB, mesmo que sejam pequenas, você precisa pausar todo o sistema. Ou seja, aplicações que interajam com o ESB sofrerão disrupções, com downtimes improdutivos. Da mesma forma, se um erro for introduzido pela alteração, pode afetar todas as integrações. Tudo isso resulta em uma equipe com mentalidade contraproducente, resistente a upgrades e correções.
  • Ponto crítico de falha: como todas as integrações são roteadas pelo mesmo hub, um ESB representa um ponto crítico de falha para toda a empresa. Se o ESB falhar, todas as integrações falharão.
  • Incapacidade de automatizar testes: testes automatizados são um componente essencial do DevOps. Nos pipeline de DevOps, toda atualização é testada de maneira independente, de modo que não interrompe o processo de desenvolvimento. É a automação que possibilita isso. No entanto, o controle de versão e a GUI proprietária do ESB impossibilitam a automação.

O setor de saúde, assim como qualquer outro, adotou as novas práticas de desenvolvimento de microsserviços, DevOps e Ágil. Isso foi ampliado para a integração da saúde também. As novas aplicações e pontos de contato digitais precisam de integração em HL7, REST e outros protocolos. Os desenvolvedores de microsserviços do setor de saúde querem controlar as integrações e outros códigos que desenvolvem (por exemplo, dados, streaming, GUI, comando e controle etc.) e empacotar todas as mudanças em unidades implantáveis que trafeguem pelo CI/CD. As limitações acima atrapalham a meta de integração entre códigos do CI/CD.

Os microsserviços são o futuro do desenvolvimento, e o ESB não é compatível com eles. Enquanto os ESBs são monolíticos, os microsserviços são o oposto. Com eles, os desenvolvedores podem usar a estrutura dos serviços com baixo acoplamento para criar aplicações e integrações. Ao dividir as aplicações em módulos independentes, fica mais fácil desenvolver, testar, alterar, testar de novo, corrigir, implantar, testar em produção, fazer upgrade e assim por diante.

Os microsserviços possibilitam o DevOps porque viabilizam testes automatizados. Como os microsserviços representam pequenos componentes, eles se adequam facilmente aos containers, que podem automatizar os processos de teste e facilitar a integração e entrega contínuas (CI/CD). Por outro lado, um ESB monolítico é grande demais para caber em um container e não pode ser dividido em componentes. Portanto, não pode ser testado da mesma forma.

No entanto, o motivo mais importante para adoção de integrações baseadas em microsserviços talvez seja o suporte que eles oferecem para desenvolvedores ágeis. Assim, eles podem usar suas ferramentas preferidas de DevOps. Remover o ESB da equação libera os desenvolvedores para trabalharem em um ambiente de desenvolvimento ágil que eles conhecem e preferem. Sem os ESBs, os desenvolvedores não precisam de treinamentos nos sistemas proprietários e podem se concentrar em uma abordagem de desenvolvimento mais produtiva.

Além disso, os microsserviços democratizam a integração, uma vez que permitem ao desenvolvedores explorar suas próprias necessidades em vez de a restringi-la a uma equipe isolada de especialistas em ESB. Isso faz mais sentido porque ninguém compreende os requisitos de dados da aplicação melhor do que os próprios desenvolvedores.

Os microsserviços também são compatíveis com gerenciamento de API, viabilizando a integração baseada em API, quando necessário.

A integração baseada em microsserviços oferece as mesmas vantagens de um ESB, como transformação gráfica e lógica para criar regras de fluxo de dados sofisticadas na sua empresa. Por exemplo, talvez você goste dos cenários de desenvolvimento gráfico do ESB, mas é possível encontrar outros similares compatíveis com a integração baseada em microsserviços.

A integração baseada em microsserviços oferece vários benefícios como:

  • Monitoramento e gerenciamento abrangentes: os microsserviços podem ser monitorados por meio das ferramentas avançadas preferidas dos desenvolvedores ágeis, como Kibana, Elasticsearch, Grafana, Prometheus etc. Com elas, você consegue identificar os pontos de falha e solucionar os problemas antes que eles cresçam e afetem os negócios.
  • Testes automatizados: uma das maiores vantagens dos microsserviços e do DevOps é a capacidade de realizar testes automatizados. Cada integração é tratada como um componente independente durante o processo de testes, sem interromper outros componentes da aplicação ou outras aplicações.
  • Software com qualidade superior:,processos mais eficientes e testes melhorados resultam em softwares de maior qualidade.
  • Desenvolvimento acelerado: a otimização do processo de desenvolvimento da integração com DevOps e automação e a eliminação de antigos processos manuais aceleram o ciclo de vida do desenvolvimento.
  • Maior escalabilidade: como as aplicações são compostas por módulos separados, cada serviço é escalado de maneira vertical e independente, sem afetar o resto da aplicação.
  • Inovação avançada: a união entre microsserviços e DevOps capacita seus desenvolvedores para inovar nas soluções de integração, de modo que sua organização possa introduzir novos serviços e atender melhor aos clientes.
  • Agilidade empresarial: o desenvolvimento ágil leva naturalmente à agilidade empresarial, que é a capacidade de reagir com rapidez às mudanças do mercado. Por exemplo, novos parceiros ou fornecedores que exigem compartilhamento de dados podem ser rapidamente integrados. Para isso, a equipe de desenvolvimento ágil usa os microsserviços para acelerar a criação das integrações necessárias ao suporte das relações empresariais.
  • Experiência do cliente aprimorada: sua meta principal é atender aos clientes, ou seja, os pacientes que dependem dos serviços de saúde todo dia. Ao melhorar os processos e compartilhar os dados entre sistemas e departamentos de forma simplificada, você assegura uma experiência do paciente satisfatória.

A tarefa de migrar a integração para microsserviços pode parecer assustadora. Por que migrar? Afinal, sua equipe já conhece os aspectos proprietários do ESB que vocês usam há tantos anos. Mas é aí que está o problema. E se um ou dois especialistas de ESB deixarem a organização? Como recuperar esse nível de habilidade?

Essa migração para além do ESB monolítico parece muito trabalhosa, e é justamente por isso que você deve seguir adiante. Quando você se libertar das limitações do ESB, você poderá aproveitar os benefícios de todo um novo mundo de integração.

Microsserviços: de monolitos a serviços independentes, meshes, serverless e além.

Casos de uso de event mesh

Uma arquitetura orientada a eventos em conjunto com uma event mesh oferece suporte à uma grande variedade de casos de uso, implantados em topologias multicloud complexas e largamente distribuídas com o uso de vários stacks de aplicações. Veja a seguir alguns exemplos de casos de uso de event mesh.

Integração de microsserviços

A event mesh conecta facilmente aplicações baseadas em microsserviços entre si e com tecnologias legadas.

E-commerce

A event mesh viabiliza o processamento acelerado de transações para assegurar interações rápidas e altamente confiáveis por meio de sites e apps.

Suporte ao cliente

A event mesh é compatível com a disponibilização rápida dos dados de interação com o cliente para que as equipes de suporte possam responder em tempo real e criar uma experiência personalizada.

Serviços financeiros

A event mesh pode oferecer sincronização de baixa latência dos dados de transações comerciais em tempo real para provedores de serviços financeiros. Além disso, ela também pode transmitir informações em tempo real sobre transações suspeitas para auxiliar na identificação de fraudes.

Conectividade de IoT

A event mesh disponibiliza conectividade com a internet das coisas (IoT) confiável e escalável para sistemas de back-end, possibilitando o processamento de métricas a partir de uma variedade quase ilimitada de sensores.

A event mesh oferece:

Capacidade de resposta em tempo real

O sucesso nos negócios é determinado pela capacidade de reagir às mudanças. Uma das maiores vantagens de uma event mesh é a disponibilização de dados em tempo real para viabilizar respostas rápidas. Esses dados são entregues em fluxos de eventos por meio de uma arquitetura orientada a eventos. A event mesh é altamente eficiente e determina o caminho mais rápido entre produtores e consumidores de eventos, o que praticamente elimina a latência no sistema de mensageria. Isso dá aos stakeholders empresariais a agilidade para reagir rapidamente a problemas críticos que demandam decisões urgentes.

Melhoria da experiência do cliente

Ao permitir que as equipes de relação com clientes e de tecnologias de e-commerce disponibilizem dados em tempo real, a event mesh contribui para um melhor atendimento aos usuários e uma experiência do cliente aprimorada.

Redução dos custos operacionais

Ao oferecer visibilidade em tempo real aos departamentos de produção, vendas, inventário e envio, a event mesh permite que as organizações otimizem operações, aumentem a eficiência e reduzam os custos.

Produtividade do desenvolvedor

Com o suporte de uma event mesh que não depende de diferentes tipos de ambientes, sistemas de mensageria e protocolos, os desenvolvedores de aplicações podem se concentrar nas melhores tecnologias disponíveis para implementar a lógica de negócios. Assim, os desenvolvedores ficam livres para inovar sem precisarem criar uma complexa rede de distribuição de dados e sem ficarem presos a ambientes de desenvolvimento,  plataformas de mensageria ou tipos de nuvem.

Leitura recomendada

ARTIGO

Microsserviços e o suporte à integração de TI no setor de saúde

Microsserviços permitem que desenvolvedores da área de saúde e outros setores criem aplicações a partir de serviços com baixo acoplamento, facilitando as etapas de desenvolvimento, teste, implantação e upgrade.

ARTIGO

O que são microsserviços?

Microsserviços são uma abordagem de arquitetura para a criação de aplicações formadas por partes menores que funcionam juntas, mas de maneira independente.

ARTIGO

O que é service mesh?

Uma service mesh é uma camada de infraestrutura incorporada a uma aplicação que documenta como os serviços interagem, facilitando a comunicação e eliminando o downtime.

Leia mais sobre microsserviços

Soluções Red Hat

Red Hat OpenShift

Uma plataforma empresarial de aplicações em container Kubernetes com stack completo de operações automatizadas para gerenciar implantações de nuvem híbrida, multicloud e edge computing.

Conteúdo adicional

Estudo de caso

Banco Original usa o Red Hat OpenShift e garante aumento de 700% em pagamentos em tempo real

VÍDEO - THE SOURCE TV

A cultura dos microsserviços

Mais do que apenas uma nova abordagem técnica, os microsserviços apoiam a construção de uma nova cultura nas organizações, ancorada no conceito de DevOps

Estudo de caso

ANBIMA moderniza sua infraestrutura com orientações de especialistas em TI da Red Hat

Treinamentos Red Hat

Treinamento gratuito

Developing Cloud-Native Applications with Microservices Architectures

Illustration - mail

Quer receber mais conteúdo deste tipo?

Cadastre-se para receber a nossa newsletter Red Hat Shares.