Desenvolvimento vs. Aquisição de Sistema de Gestão Hospitalar e Prontuário Eletrônico (HIS/PEP)

Desenvolvimento vs. Aquisição de Sistema de Gestão Hospitalar e Prontuário Eletrônico (HIS/PEP)

Análise Exaustiva de Viabilidade Econômica, Requisitos Específicos por Especialidade Assistencial, Compliance Regulatório com CFM e SBIS (NGS1/NGS2), LGPD e o Caso NPfIT/NHS

Área: Governança em TI, Direito Médico & Saúde Digital Escopo: Estudo Estratégico Multidisciplinar Exaustivo

1. Introdução e Contexto do Mercado Hospitalar

A transformação digital na saúde transitou definitivamente de um status de diferencial competitivo para uma premissa de sobrevivência institucional e compliance jurídico-operacional. No epicentro da arquitetura tecnológica de qualquer organização de saúde — seja ela um hospital geral de alta complexidade, uma rede ambularorial ou uma operadora verticalizada — encontra-se a integração entre o Hospital Information System (HIS) e o Prontuário Eletrônico do Paciente (PEP).

O HIS/PEP atua como o sistema nervoso central da instituição: orquestra a jornada do paciente desde a recepção e classificação de risco até a alta, gerencia os fluxos de suprimentos de alto custo, realiza a checagem à beira do leito, possibilita o faturamento junto a operadoras e ao Sistema Único de Saúde (SUS) e, fundamentalmente, documenta os atos médicos e de enfermagem com valor probatório judicial.

Diante do valor expressivo das licenças, taxas de implantação e mensalidades cobradas pelas grandes software houses do setor (como MV, TOTVS, Pixeon, Philips e Benner), conselhos de administração, diretores de TI e lideranças médicas continuam a ponderar a questão estratégica decisiva: "Vale a pena investir no desenvolvimento de um sistema de gestão hospitalar e prontuário eletrônico próprio, construído do zero e sob medida para os nossos processos?"

Com base na literatura de governança de TI, na jurisprudência do Direito Médico brasileiro e no histórico acumulado de grandes projetos de software em saúde ao longo das últimas três décadas, a resposta categórica é não. Salvo em contextos extraordinários de escala global ou fomento de ecossistema, construir um HIS/PEP do zero é uma das decisões corporativas de maior risco financeiro, operacional e jurídico que uma instituição pode adotar.

2. A Complexidade Sistêmica do Prontuário Eletrônico do Paciente (PEP)

A percepção equivocada de que um PEP é apenas uma "interface de texto parametrizada para registro de consultas" é a causa raiz das tentativas frustradas de desenvolvimento interno. Um PEP moderno e seguro é uma infraestrutura de dados altamente dinâmica, que precisa integrar diretrizes de engenharia de software com rigor normativo sanitário e médico.

2.1 O Conceito do PEP como Documento Legal e Assistencial

Nos termos do Código de Ética Médica e da Resolução CFM nº 1.638/2002, o prontuário é um documento único, constituído de um conjunto de informações, sinais e imagens registrados, gerados a partir de fatos, acontecimentos e situações sobre a saúde do paciente e a assistência a ele prestada. O prontuário pertence ao paciente e permanece sob a guarda fiduciária e responsabilidade ética e legal do hospital e do médico assistente.

Por possuir tripla natureza — assistencial, jurídica e administrativa —, o software que o suporta deve garantir integralmente os princípios morais e legais da documentação médica: inalterabilidade dos registros, rastreabilidade irrestrita, confidencialidade, disponibilidade contínua e autenticidade das assinaturas.

2.2 Arquitetura de Software e Desafios de Engenharia de Dados

Desenvolver um PEP exige resolver problemas estruturais complexos de modelagem de banco de dados e arquitetura de sistemas:

● Sistemas Transacionais de Altíssima Disponibilidade (Mission-Critical): Um hospital opera 24 horas por dia, 365 dias por ano. Um downtime programado ou não programado no PEP paralisa administrações de medicamentos na UTI, impede procedimentos cirúrgicos e bloqueia a triagem no pronto-socorro. A arquitetura exige tolerância a falhas (HA/Fault Tolerance) e replicação em tempo real.

● Modelagem Longitudinal do Histórico Clínico: Diferente de ERPs bancários ou comerciais onde transações são encerradas, o registro de saúde de um paciente é longitudinal e cumulativo. O banco de dados precisa estruturar conceitos mutáveis ao longo de décadas sem perda de contexto histórico.

● Consistência Eventual vs. Consistência Imediata: Prescrições médicas e checagens de medicação exigem consistência imediata (ACID), enquanto telemetria de exames pode tolerar micro-atrasos. Equilibrar essas demandas em um único banco de dados exige engenheiros de dados sêniores altamente especializados.

3. Aprofundamento das Necessidades de Compliance por Tipo de Prontuário

Um dos maiores equívocos no desenvolvimento próprio de software é assumir que existe um "formato genérico de prontuário". Cada ambiente assistencial e especialidade médica possui requisitos clínicos, fluxos de trabalho e exigências legais radicalmente distintos que precisam ser implementados em código fonte.

3.1 Prontuário Ambulatorial e de Consultório

Focado no atendimento eletivo e contínuo. Exige ferramentas para o acompanhamento histórico de patologias crônicas, linhas do tempo de indicadores laboratoriais e facilidade para prescrição repetitiva. Requisitos chave:

● Modelagem de Anamnese Estruturada: Capacidade de alternar entre texto livre e campos codificados para alimentar indicadores de qualidade (ex: controle de HbA1c em diabéticos).

● Módulo de Prescrição Eletrônica e Receituário Controlado: Integração nativa com plataformas de validação de assinaturas e dispensação de medicamentos controlados (Portaria SVS/MS nº 344/1998) e emissão de atestados e laudos com validação em tempo real no CFM (Serviço de Validação de Assinatura Eletrônica).

● Gestão de Absenteísmo e Acompanhamento Preventivo: Ferramentas para medicina preventiva e acompanhamento pós-consulta.

3.2 Prontuário de Pronto-Atendimento e Emergência

Ambiente caracterizado pelo alto estresse, alta rotatividade e necessidade de tomada de decisão em segundos. A interface de usuário (UI/UX) é crítica para evitar erros médicos.

● Protocolos Nacionais e Internacionais de Triagem: O PEP precisa integrar de forma nativa e rápida a triagem de risco, como o Protocolo de Manchester ou ESI (Emergency Severity Index), determinando o tempo limite de atendimento e disparando alertas visuais no painel de controle do setor.

● Protocolos Clínicos de Emergência Guiados por Alertas (Clinical Decision Support - CDSS): Disparo automático de bundles de atendimento crítico diante de alteração de sinais vitais. Exemplos: Protocolo de Sepsis (ILAS), Protocolo de AVC (AVC isquêmico / trombólise) e Protocolo de Dor Torácica (SCA). O software deve exigir justificativa médica para não adesão aos protocolos padrão.

● Interface Mínima de Cliques: A entrada de dados precisa ser otimizada via macros, ordens padronizadas e conjuntos de prescrição rápida (order sets), garantindo que o médico passe mais tempo atendendo do que digitando.

3.3 Prontuário de Unidade de Terapia Intensiva (UTI)

A UTI representa a área de maior complexidade assistencial e densidade de dados do hospital. O PEP de UTI é profundamente quantitativo e dinâmico:

● Balanço Hídrico Rigoroso: Cálculo automático e contínuo de entradas (infusões, dietas, medicações, soros) e saídas (diurese, drenos, diálise), com consolidação hora a hora e balanço acumulado de 24 horas. Erros de arredondamento em código podem causar sobrecarga volêmica fatal.

● Integração de Monitores Múltiplos e Ventiladores (Captura de Sinais Vitais): Comunicação direta via protocolos de comunicação de dispositivos médicos (IEEE 11073, RS232, TCP/IP) para importação automática de saturação de O2, pressão arterial invasiva, capnografia e parâmetros ventilatórios sem digitação manual.

● Escores de Gravidade e Prognóstico Integrados: Cálculo automático de SAPS III, APACHE II, SOFA e TISS-28 a partir dos dados do prontuário e exames de laboratório, mensurando o risco de mortalidade e a carga de trabalho da enfermagem.

3.4 Prontuário Cirúrgico e Bloco Cirúrgico

Envolve a coordenação multidisciplinar entre equipes cirúrgicas, anestesistas, enfermagem cirúrgica e central de material e esterilização (CME):

● Checklist de Cirurgia Segura da OMS (Safe Surgery Saves Lives): O sistema deve obrigatoriamente bloquear a evolução para a fase seguinte da cirurgia caso as etapas (Sign In, Time Out, Sign Out) não sejam registradas em tempo real com a validação da equipe.

● Ficha Anestésica Digital: Registro em tempo real de drogas anestésicas, bloqueios neuromuscular, escala de Aldrete e Kroulik para alta da RPA (Recuperação Pós-Anestésica) e curvas de monitorização contínua.

● Rastreabilidade de Consumo de Opióides, OPME e Fios Cirúrgicos: Vinculação direta entre a ficha cirúrgica, o lote da Prótese/Órtese/Material Especial (OPME) utilizado no paciente e o débito automático no estoque/faturamento.

3.5 Prontuário Oncológico e Terapia Infusional

Uma das áreas de maior risco legal e clínico devido ao potencial de toxicidade dos fármacos empregados:

● Cálculo Automático por Área de Superfície Corporal (ASC): A dose de quimioterápicos é calculada com base na fórmula de DuBois, Mosteller ou Gehan baseada no peso e altura atuais do paciente. O PEP precisa recalcular a dose a cada ciclo e emitir bloqueio rígido caso haja divergência superior à margem de segurança.

● Controle de Ciclos e Intervalos de Tratamento: Registro de esquemas terapêuticos (ex: AC-T, FOLFOX) com bloqueio preventivo de aprazamento antecipado ou aplicação em prazos fora da janela de segurança biológica.

3.6 Prontuário Pediátrico e Neonatal

● Prescrição Dinâmica por Miligrama/Quilo (mg/kg/dia): Ajuste automático de dosagens com base no peso exato aferido na admissão, com alerta para doses adultas aplicadas por engano a pediatria e alertas para apresentação comercial líquida (gotas/mL).

● Curvas de Crescimento da OMS Incorporadas: Plotagem automática em gráficos percentílicos de peso/idade, estatura/idade e perímetro cefálico no prontuário.

4. Normas Regulatórias CFM e a Certificação SBIS / CFM (NGS1 e NGS2)

No Brasil, a legalidade do uso de sistemas informatizados para a guarda e manuseio de prontuários de pacientes está estritamente regulada pelo Conselho Federal de Medicina (CFM) e pela Sociedade Brasileira de Informática em Saúde (SBIS). O descumprimento destas diretrizes invalida o status legal do prontuário, expondo diretores de TI, diretores clínicos e a própria instituição a severas sanções administrativas, civis e criminais.

4.1 Histórico Normativo: Das Resoluções CFM nº 1.638/2002, 1.821/2007 e 2.299/2021

A Resolução CFM nº 1.638/2002 definiu a obrigatoriedade da Comissão de Prontuário Médico nos hospitais e os itens mínimos constitutivos. Em seguida, a marco regulatório divisor de águas foi a Resolução CFM nº 1.821/2007, que aprovou as normas técnicas para a digitação, uso de sistemas informatizados para a guarda e manuseio dos documentos do prontuário, autorizando a eliminação do suporte em papel, desde que o software atenda integralmente ao Manual de Requisitos de Segurança, Funcionalidade e Subjetividade estabelecido pelo convênio CFM/SBIS.

Recentemente, a Resolução CFM nº 2.299/2021 regulamentou a emissão de documentos médicos eletrônicos (atestados, prescrições, laudos), exigindo o uso de assinatura digital qualificada (ICP-Brasil) ou avançada regulamentada, e integração com os meios oficiais de validação pública.

4.2 Os Níveis de Garantia de Segurança: NGS1 vs. NGS2

O Manual de Requisitos CFM/SBIS divide a conformidade do software em dois Níveis de Garantia de Segurança (NGS), com impactos operacionais e jurídicos completamente distintos:

Dimensão de Conformidade Nível de Garantia de Segurança 1 (NGS1) Nível de Garantia de Segurança 2 (NGS2)

Escopo de Autenticação Autenticação baseada em usuário e senha forte. Não exige Certificado Digital ICP-Brasil por evolução. Exige obrigatoriamente Assinatura Digital com Certificado Digital ICP-Brasil (Padrão PKI-Brasil, A3 ou SASS/Cloud).

Validade Jurídica do Registro Garante segurança lógica interna, mas não possui presunção legal absoluta de veracidade frente a terceiros sem perícia. Equiparação plena a documento público assinado de próprio punho (Art. 10, § 1º da MP 2.200-2/2001). Presunção legal de autoria.

Eliminação do Prontuário em Papel PROIBIDA. O hospital é obrigado a imprimir, colher assinatura manual e arquivar fisicamente por 20 anos. AUTORIZADA. Permite a digitalização com eliminação do papel físico original e operação 100% paperless.

Integridade e Não-Repúdio Protegida por hashes internos no banco de dados. Suscetível a questionamentos em perícia judicial de TI. Garantida por algoritmo criptográfico e Carimbo do Tempo (Timestamp) de Autoridade Certificadora credenciada. Não-repúdio absoluto.

Custo e Complexidade Tecnológica Médio. Exige controle rigoroso de acessos e trilha de auditoria no software. Extremamente Alto. Requer motor de assinatura em lote, integração com HSM (Hardware Security Module) e custódia de chaves.

4.3 O Processo e Custos da Certificação SBIS/CFM para Desenvolvedores Internos

Se uma instituição de saúde decide criar seu próprio PEP e deseja operar sem papel (NGS2), ela é legalmente obrigada a submeter seu software ao processo formal de Certificação CFM/SBIS. Este processo inclui:

1. Auditoria Extensa do Código-Fonte e Arquitetura: Verificação de mais de 150 requisitos obrigatórios de funcionalidade, estrutura de dados e segurança da informação.

2. Testes de Penetração e Vulnerabilidade (Pentests): Provas de conceito para tentar adulterar registros retroativos no banco de dados, contornar logs de auditoria e falsificar identidades de profissionais.

3. Custo Financeiro Direto e Recorrência: A auditoria cobrada pela SBIS custa dezenas de milhares de reais por versão do sistema. Cada alteração estrutural no código exige um processo de re-certificação ou auditoria de versão.

4. Manutenção de Processo Contínuo: O certificado possui validade limitada. Alterações regulatórias na legislação brasileira exigem que a equipe do hospital atualize o software e passe por novas etapas de homologação.

5. LGPD, Segurança Cibernética e Responsabilidade Civil Hospitalar

A promulgação da Lei Geral de Proteção de Dados Pessoais (Lei nº 13.709/2018 - LGPD) elevou os dados de saúde ao status de dados pessoais sensíveis (Art. 5º, II), impondo rigor extremo ao tratamento e armazenamento dessas informações.

5.1 Hipóteses Legais para Tratamento de Dados de Saúde

O tratamento de dados de saúde no PEP não depende unicamente do consentimento do paciente, enquadrando-se comumente em obrigações legais, tutela da saúde e proteção da vida (Art. 11, II da LGPD). No entanto, o dever de segurança e confidencialidade permanece irrestrito. Vazamentos de dados clínicos geram responsabilidade objetiva e multas administrativas pela ANPD que podem atingir R$ 50 milhões por infração, além do dever de indenização por danos morais individuais.

5.2 Requisitos Técnicos de Segurança Obrigatórios no Software

Para estar em conformidade com a LGPD e as diretrizes da ANPD e SBIS, o código fonte do PEP precisa ter nativamente:

● Privacidade desde a Concepção e por Padrão (Privacy by Design & Default): Restrição de acesso aos dados com base no princípio do menor privilégio (Role-Based Access Control - RBAC). Um médico da ortopedia não deve ter acesso ao prontuário psiquiátrico de um paciente, a menos que haja justificativa assistencial explícita ("quebra de vidro" / break the glass).

● Trilha de Auditoria Inalterável (Audit Trail / Immutable Logs): O sistema deve registrar de forma indelével cada leitura, consulta, alteração, exportação ou exclusão de qualquer registro do PEP. O log deve conter: ID do usuário, IP de origem, data/hora exata sincronizada por NTP oficial, dado acessado e justificativa. Alterar ou apagar uma tabela de log em banco de dados deve ser tecnicamente impossível.

● Anonimização e Pseudonimização para Ambientes de Testes: Ambientes de desenvolvimento e homologação do software interno nunca podem utilizar dados reais de pacientes sem passar por algoritmos irreversíveis de anonimização.

● Criptografia em Repouso e em Trânsito: Todos os bancos de dados do PEP devem utilizar criptografia em repouso (ex: AES-256) e comunicações via TLS 1.3. O gerenciamento das chaves de criptografia não pode ficar no mesmo ambiente que armazena os dados.

5.3 O Impacto no Direito Probatório e na Defesa de Erro Médico

Em ações judiciais de indenização por alegado erro médico ou negligência hospitalar, o prontuário eletrônico é a principal peça de defesa da instituição. Se o software utilizado pelo hospital for próprio e não possuir a certificação NGS2/SBIS ou apresentar falhas na trilha de auditoria, a justiça pode:

1. Inverter o Ônus da Prova com Suspeição do Registro: O juiz pode declarar o registro eletrônico como manipulação unilateral do hospital, anulando seu valor probatório.

2. Presumir Verdadeiras as Alegações do Autor: A ausência de provas documentais inquestionáveis da checagem de medicação ou do monitoramento do paciente leva à condenação do hospital por negligência ou imperícia.

6. Padrões Internacionais de Interoperabilidade na Saúde

Nenhum sistema hospitalar vive isolado. Um hospital moderno interage continuamente com laboratórios externos, operadoras de saúde, redes de exames de imagem, equipamentos à beira do leito e plataformas governamentais. Desenvolver um software do zero exige a implementação manual de protocolos complexos de integração:

6.1 HL7 (Health Level Seven) v2 / v3

O padrão legado, mas ainda dominante para troca de mensagens transacionais dentro do hospital. Exige a criação de parsers e encoders para mensagens delimitadas como ADT (Admissão, Alta e Transferência), ORM (Pedidos Médicos) e ORU (Resultados de Exames). Cada fabricante de equipamento ou sistema especialista implementa variações próprias do HL7, exigindo a manutenção constante de engines de integração (ex: Mirth Connect / NextGen Connect).

6.2 HL7 FHIR (Fast Healthcare Interoperability Resources)

O padrão moderno de interoperabilidade baseado em arquitetura RESTful, JSON/XML e especificações web. É o padrão adotado pela Rede Nacional de Dados em Saúde (RNDS) do Ministério da Saúde no Brasil. Construir um servidor FHIR nativo dentro de um PEP próprio exige dominar a modelagem de recursos clínicos (Patient, Encounter, Observation, Condition, MedicationRequest) e gerenciar perfis de extensão e validação de conformidade.

6.3 DICOM (Digital Imaging and Communications in Medicine) e Integração PACS

O PEP precisa se comunicar nativamente com sistemas PACS (Picture Archiving and Communication System) e modalidades médicas (Tomografia, Ressonância, Ultrassom) via protocolo DICOM. A integração envolve disparar a Worklist modalidade, receber a confirmação de armazenamento e incorporar o visualizador de imagens web (Zero-Footprint Viewer) diretamente dentro da aba de laudos do prontuário do paciente.

7. Exemplo Emblemático de Insucesso: O Caso NPfIT (NHS - Reino Unido)

Para compreender como a complexidade do software hospitalar pode suplantar até mesmo os maiores orçamentos estatais e equipes de engenharia do planeta, deve-se estudar o National Programme for IT (NPfIT) do Serviço Nacional de Saúde do Reino Unido (NHS).

ESTUDO DE CASO APROFUNDADO: O CATACLISMO TECNOLÓGICO DO NPFIT / NHS

Contexto e Ambição: Lançado em 2002 pelo governo britânico, o NPfIT foi projetado para ser o maior programa de TI civil do mundo. O objetivo era criar um Prontuário Eletrônico do Paciente centralizado e padronizado (o Care Records Service), conectando todos os hospitais gerais, clínicas comunitárias e médicos da família (GPs) da Inglaterra.

Orçamento Inicial e Prazo: Previsto em £ 6,2 bilhões de libras esterlinas, com conclusão programada para 10 anos.

Causas do Colapso Tecnológico e Operacional:

● Rejeição do Corpo Clínico (A Falha de Usabilidade): O software foi projetado por comitês de TI e grandes consultorias sem a participação ativa dos médicos de ponta. As interfaces resultantes eram extremamente burocráticas, exigindo dezenas de cliques para tarefas simples. Médicos e enfermeiros recusaram-se a utilizar o sistema, criando "gargalos" no atendimento e retornando ao uso do papel.

● Desconexão com a Heterogeneidade dos Processos Locais: Cada hospital possui peculiaridades em suas rotinas de pronto-socorro, oncologia e cirurgia. A tentativa de impor um código fonte único e engessado para centenas de hospitais paralisou fluxos assistenciais existentes.

● Atrasos e Incompatibilidade de Módulos Core: Os fornecedores e equipes de desenvolvimento interno foram incapazes de entregar os módulos de prontuário e agendamento dentro dos prazos, gerando versões instáveis e repletas de erros que travavam os servidores dos hospitais durante o atendimento.

● Escopo Mutável e Pressão Regulatória Contínua: Durante o desenvolvimento, novas legislações de saúde e requisitos administrativos foram constantemente adicionados, impedindo que o sistema atingisse uma versão estável (Baseline).

O Desfecho e o Prejuízo: Em setembro de 2011, após anos de escândalos políticos, relatórios devastadores do parlamento britânico e paralisações operacionais, o governo britânico cancelou oficialmente o programa. Estudos do National Audit Office (NAO) e do Comitê de Contas Públicas estimaram que o custo final do fracasso superou £ 12 bilhões de libras esterlinas (mais de R$ 80 bilhões de reais), com grande parte dos módulos descartada inteiramente.

Lições Críticas para Gestores e Diretores de TI Hospitalares:

1. Softwares Médicos Não Aceitam "Força Bruta" Financeira: Investir bilhões de reais ou colocar centenas de desenvolvedores não garante o sucesso de um PEP se a arquitetura de dados e a usabilidade clínica não forem perfeitas.

2. O Custo da Rejeição Médica é Fatal: Se o médico percebe que o PEP atrasa sua consulta ou aumenta o risco de erro, ele abandona o sistema. Em um hospital privado, isso gera perda de médicos renomados; em um hospital público, gera filas no pronto-socorro e escândalos de atendimento.

3. O Risco do Escopo Infinito (Scope Creep): Tentar atender a todas as solicitações customizadas de cada chefe de serviço de um hospital garante que o software nunca fique pronto e estável.

8. Análise Comparativa Exaustiva de Custos: Build vs. Buy

A decisão de investimento deve ser pautada pelo cálculo realista do Custo Total de Propriedade (TCO - Total Cost of Ownership) ao longo de um horizonte mínimo de 5 a 10 anos. A tabela a seguir compara os custos diretos e ocultos das abordagens:

Dimensão Estratégica Desenvolvimento Próprio do Zero (Build) Aquisição / Licenciamento SaaS de Mercado (Buy)

Investimento Inicial (CapEx) Extremamente Alto. Financiamento de 2 a 4 anos de salários de engenharia de software, arquitetos, designers UX, consultores médicos e infraestrutura sem nenhum retorno operacional. Médio a Baixo. Custo focado na taxa de implantação, parametrização de processos, treinamento e migração de dados legados.

Custo Operacional Recorrente (OpEx) Alto e Imprevisível. Manutenção contínua de uma software house interna inteira (DevOps, QA, Suporte 24x7, Devs Sêniores) para corrigir bugs e refatorar o código. Previsível. Mensalidade/Anuidade clara de licenciamento SaaS ou manutenção, escalável conforme o número de leitos ou vidas ativas.

Tempo de Ativação (Time-to-Value) Longo (24 a 48 meses). Alto risco de obsolescência tecnológica antes mesmo do primeiro Go-Live completo do sistema. Curto/Médio (3 a 12 meses). Software com processos de negócio e fluxos clínicos pré-testados em milhares de outros leitos do país.

Atualização Regulatória e Fiscal Responsabilidade 100% Interna. Cada mudança nas tabelas do SUS, TUSS/ANS, Guias TISS, portarias da Anvisa ou resoluções do CFM exige gasto interno imediato de horas de código. Inclusa no Contrato de Manutenção. O fornecedor de software absorve o custo de manter o sistema em compliance para toda a sua base de clientes.

Risco de Reter Talentos em TI Crítico. A rotatividade (turnover) de desenvolvedores no mercado de tecnologia pode paralisar o projeto ou deixar o código fonte sem profissionais que o compreendam. Irrelevante para o Hospital. A responsabilidade de manter a equipe de engenharia e a memória do código é transferida para a empresa de software.

Continuidade do Negócio e Suporte 24x7 Complexo e Oneroso. Exige manter equipes de plantão de TI interno em regime de sobreaviso constante para resolver travamentos de sistema na madrugada. Garantido por SLA Contratual. Acordo de Nível de Serviço rígido com penalidades financeiras pesadas ao fornecedor em caso de indisponibilidade.

Conclusão da Análise Financeira: Na ponta do lápis, o Custo Total de Propriedade (TCO) de um software próprio nos primeiros 5 anos costuma ser de 3 a 5 vezes maior do que o custo acumulado de licenciamento de uma solução líder de mercado, com um nível de risco institucional desproporcionalmente superior.

9. Exceções Estratégicas: Quando o Código Próprio se Justifica?

Apesar de a recomendação padrão ser o licenciamento de soluções comerciais, a teoria da estratégia empresarial reconhece cenários específicos onde o desenvolvimento de código próprio se justifica integralmente. É crucial, contudo, diferenciar o desenvolvimento do núcleo do sistema (Core HIS/PEP) da criação de camadas de inovação periféricas.

9.1 Grandes Conglomerados de Saúde e Redes Bilionárias

Grandes grupos operadores de saúde que administram dezenas de hospitais, centenas de unidades de diagnóstico e milhões de vidas possuem volume financeiro e ganho de escala que justificam a criação de uma subsidiária de tecnologia dedicada. Nesses casos, a TI deixa de ser um centro de custo e passa a ser geradora de Propriedade Intelectual (IP) e ativo de valoração corporativa (valuation).

9.2 O Modelo da Arquitetura Componível (Composable Healthcare)

O paradigma moderno e mais eficiente adotado por hospitais inovadores não é "desenvolver tudo do zero", nem "ficar refém absoluto do fornecedor". Trata-se do modelo da Arquitetura de Saúde Componível:

● Core do Sistema (Buy): O hospital adquire um HIS/PEP de prateleira sólido e consolidado para gerenciar as rotinas pesadas de faturamento, estoque, prescrição básica, agendamento e conformidade de registros legados.

● Camadas de Inovação Próprias (Build via APIs): A equipe interna de TI desenvolve aplicações proprietárias leves que se conectam ao core via APIs abertas (FHIR/REST). Exemplos:

○ Modelos próprios de Inteligência Artificial para predição de sepse e readmissão.

○ Aplicativos customizados para a jornada digital e engajamento do paciente (Check-in, resultados, orientação pós-alta).

○ Painéis de Business Intelligence (BI) para a diretoria executiva e gestão de leitos em tempo real.

10. Conclusão, Recomendações e Matriz de Decisão para Executivos

A tentativa de desenvolver um Sistema de Gestão Hospitalar e Prontuário Eletrônico do Paciente do zero é uma armadilha clássica da gestão de TI em saúde. A aparente simplicidade de telas de cadastro oculta a enorme densidade de regras de negócio, tabelas de faturamento, algoritmos assistenciais de alta complexidade, requisitos cibernéticos de segurança e um arcabouço regulatório inflexível imposto pelo CFM, SBIS, Anvisa e ANPD.

O caso do NPfIT no Reino Unido serve como um alerta histórico indelével: a falta de usabilidade, a desconexão com os fluxos médicos reais e o descontrole de escopo têm o poder de destruir projetos orçados em bilhões de reais e colocar em risco a segurança e a vida dos pacientes.

Diretrizes Estratégicas para o Conselho de Administração e Diretoria de TI:

1. Adotar a Regra de Ouro "Buy Core, Build Innovation": Nunca reescreva o "motor" financeiro, regulatório e assistencial básico. Compre soluções comerciais que já possuem escala, certificação SBIS NGS2 e homologação de faturamento no mercado.

2. Exigir Padrões Abertos no Processo de RFP (Request for Proposal): Ao contratar um fornecedor de software, estabeleça como cláusula contratual obrigatória a disponibilização de APIs documentadas no padrão HL7 FHIR e acesso transparente ao banco de dados para evitar o aprisionamento (vendor lock-in).

3. Priorizar a Experiência do Profissional de Saúde (Clinical UX): Na escolha do software comercial, coloque os médicos, enfermeiros e farmacêuticos como avaliadores centrais das provas de conceito (Proof of Concept - PoC). Um software tecnicamente perfeito que é rejeitado pela equipe médica é um fracasso garantido.

4. Direcionar o Talento Interno para a Inteligência de Dados: Em vez de gastar a energia dos desenvolvedores da instituição corrigindo bugs de tela de faturamento, foque o time interno em análise de dados, automação de processos via APIs, inteligência artificial aplicada à clínica e melhoria da experiência do paciente.

João Rufino de Sales – M.Sc.

Consultor Estratégico de Sistemas de Informação em Saúde.