História Clínica Eletrônica – Desenvolver ou Comprar – Há espaço para uma terceira opção?

0

 "Desenvolver ou Comprar – essa é a questão"… Por décadas este questionamento no mais puro estilo "shakespeariano" parece ser outra vez o dilema dos CIOs quando decide abordar um novo projeto tecnológico. Tão velho como a própria profissão de informática, o debate se repete tanto para aplicações multissetoriais (ERPs, CRMs, etc.), como para aplicações especificas de um negócio ou setor. Assim, não é de se estranhar que quando o diretor de TI de um hospital recebe o encargo da direção geral e/ou da direção médica de avaliar a incorporação de um sistema de História Clínica Electrônica (Eletronic Health Record – EHR) encontre-se nesta disjuntiva.

Indo direto ao ponto, não creio que exista uma solução perfeita. Cada hospital ou instituição de saúde tem suas características e singularidades, e cada uma deve avaliar o que é melhor em cada caso. Múltiplas variáveis condicionam a decisão, entre elas, as próprias características da instituição (quão especializadas e particulares são suas necessidades e qual oferta de mercado existe para satisfazê-las); a existência ou não de talento interno para construir e manter por anos seu próprio sistema clínico de acordo com constantes mudanças circunstanciais do mercado da saúde; a necessidade de contar com o sistema em tempo e forma (restrições temporais e orçamentárias), entre outras.

Apesar de que cada caso é único, existe um crescente consenso no setor de que quase sempre a melhor opção é ir escolher um produto de mercado. Por quê? Existem argumentos fundamentais. Primero, desenvolver um sistema de EHR desde zero requer grande quantidade de tempo, esforço e investimento, especialmente quando se pretende cobrir todas as capacidades funcionais dos líderes do mercado, e o que é pior, não há nenhuma garantia de êxito a priori. É importante destacar que existe um grande déficit global em especialistas em eHealth e em EHR, com os quais a tarefa de construir algo novo torna-se ainda mais complicada. Por outro lado, enquanto as empresas que se dedicam a construir soluções comerciais investem importantes quantidades de dinheiro em P&D para manter atualizadas e evoluir suas soluções para incorporar as melhores práticas de mercado, os hospitais usualmente não contam com partidas orçamentárias para estes fins. O segundo grande argumento é o foco no negócio: um hospital ou instituição de saúde tem como objetivo cuidar e atender seus pacientes, e não ser uma fábrica de soluções de tecnologia, não é seu "core-business" e, portanto, manter esta aposta em longo prazo resulta pouco justificável.

Decidir por uma solução de mercado, porém, não é a "panaceia" tecnológica que nos livra de todos os riscos. Para começar, muitos produtos comerciais requerem um esforço importante de personalização, adaptação e ajustes para que cumpra os requerimentos e as expectativas de um cliente. Isto é normal, uma vez que um produto de mercado está baseado na incorporação das melhores práticas, generalizando-as em uma solução tecnológica concreta. O que da questão está então na capacidade do produto em ser tão flexível como um desenvolvimento sob medida e poder assim se adaptar às necessidades especificas de um mercado e de um cliente concreto, seja via parametrização, configuração ou biblioteca de funções ou APIs de desenvolvimento.

A pergunta deveria ser então: há espaço para uma "terceira via" na implementação da EHR? Alguma solução comercial que ofereça um produto base com as melhores práticas internacionais, mas que nos permita adapta-lo às necessidades da organização sem morrer tentando?

Conceitualmente falando, este tipo de solução flexível, com módulos funcionais construídos como "building blocks" que podem ser montados e adaptados para construir uma solução final é conhecida como "EHR Modular" e em certa medida, constitui o sonho de muitos clientes que desejam dar um salto de qualidade em suas soluções de EHR, mas sem renunciar nem descontinuar certos componentes ou módulos desenvolvidos internamente com muito esforço e que estão desenhados para responder a certas necessidades particulares de sua organização.

Por outro lado, estes sistemas modulares e flexíveis devem conter APIs, orientadas ao setor de saúde, que lhes permita não somente adaptar sua EHR, mas também abordar outros desenvolvimentos específicos internamente sem depender de um fornecedor externo. Assim, se chega ao conceito de framework de eHealth, o que é o mesmo, uma arquitetura de desenvolvimento de software, que permita adaptar a EHR ou gerar novas aplicações de negócio reduzindo sensivelmente o risco de um desenvolvimento sob medida, e aproveitando as melhores práticas do mercado já incorporadas no framework e no produto base, de com padrões internacionais de interoperabilidade como HL7, Dicom, Loinc, IHE, etc.

Em um mercado imaturo como o setor de tecnologia da informação aplicada à saúde, e em concreto o subsegmento de EHR, a chegada desta "terceira via" é uma alternativa bastante viável e especialmente atrativa para clientes que investiram muito dinheiro na construção de soluções ad-hoc mas que necessitam atualiza-las ou melhora-las, ou inclusive para clientes que querem comprar uma solução de mercado contrastada mas baseada em frameworks ou arquiteturas especialmente pensadas para a personalização e/ou adaptação da solução,  que a tornem flexível, ágil e acessível econômica e tecnicamente. Este enfoque esta ganhando cada vez mais adeptos, inclusive em mercados muito competitivos como o dos Estados Unidos, no qual iniciativas governamentais estão incluindo os sistemas modulares dentro do programa de estimulo à aquisição de sistemas de EHR.

Mario Chao, diretor global de Saúde da everis

DEIXE UMA RESPOSTA

Por favor digite seu comentário!
Por favor, digite seu nome aqui

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.