Tópico 5.4 — Economia da Engenharia de Software em Saúde

Por que isso importa na economia da saúde

Toda organização de saúde moderna é, admita ou não, um operador de software. Registros de paciente, prescrição, agendamento, resultados de laboratório, reclamações de pagamento, e vigilância populacional todos funcionam sobre código — comprado de fornecedores, construído internamente, herdado de predecessores, ou costurado através de todos os três. O dinheiro envolvido é grande e recorrente: programas nacionais de registro eletrônico de saúde consumiram bilhões de dólares de fundos públicos, e os custos operacionais de software de saúde — manutenção, integração, atualizações, segurança — tipicamente ofuscam o preço que apareceu no caso de negócio original. Ainda assim a maioria do treinamento de economia da saúde não diz nada sobre como software se comporta como um ativo econômico, e a maioria do treinamento de engenharia de software não diz nada sobre custo de oportunidade em um sistema que também compra enfermeiros e medicamentos.

A lacuna importa porque software falha economicamente de formas características que reflexos de aquisição ordinários não captam. Um sistema é comprado por seu preço de compra e características de demonstração; o fardo de integração, migração de dados, e manutenção chega depois, contra orçamentos que nunca foram consultados. Um relacionamento de fornecedor endurece em dependência, então cada renovação é negociada de fraqueza. Atalhos tomados sob pressão de prazo se acumulam invisivelmente até que o sistema que opera o hospital não possa mais ser mudado com segurança — ponto em que a organização enfrenta uma conta de modernização que nunca planejou e não pode adiar, porque o software agora carrega risco clínico. A história de grandes programas de TI de saúde, incluindo o Programa Nacional para TI do Reino Unido (desmontado em 2011 depois de um custo estimado de cerca de £10 bilhões), é uma história dessas dinâmicas em escala nacional.

Para um diretor, os riscos são triplos. Primeiro, dinheiro: software é um compromisso de vida inteira, e a opção barata na compra é rotineiramente a opção cara ao longo de uma década. Segundo, segurança: em um ambiente clínico uma interrupção, um erro de dados, ou um sistema não mantível não é um inconveniente mas um perigo, com custos que pousam no Tópico 3.11 — Economia da Qualidade e Segurança. Terceiro, soberania: as escolhas entre construir e comprar, entre sistemas proprietários e abertos, e entre interfaces padrão e sob medida determinam quanta liberdade a organização terá para agir em cinco anos — e liberdade de ação, como este livro argumenta ao longo, é um ativo econômico.

Conceitos centrais

Engenharia de software é o design, construção, e manutenção disciplinados de software — e a palavra manutenção carrega a maior parte da economia. Diferente de um edifício, software nunca está terminado: requisitos mudam, regulações mudam, dependências envelhecem, e ameaças de segurança evoluem. A manutenção de software — trabalho corretivo, adaptativo, e preventivo em um sistema em serviço — comumente absorve a maioria do custo vitalício de um sistema. A unidade econômica de análise portanto nunca é a compra; é o custo total de propriedade: aquisição mais integração, migração de dados, treinamento, hospedagem, suporte, atualizações, segurança, e eventual desativação, sobre a vida realista do sistema.

O segundo conceito é dívida técnica: o custo futuro implícito de escolher um design conveniente agora em vez de um sólido. A metáfora é exata o suficiente para usar em uma reunião de finanças. Dívida não é inerentemente ruim — um atalho deliberado que entrega uma capacidade necessária mais cedo pode ser um empréstimo racional — mas acumula juros: toda mudança futura ao sistema custa mais por causa dela, e dívida não gerenciada se compõe até que mudança se torna proibitivamente cara ou perigosa. Uma organização de saúde que não pode ver sua dívida técnica está carregando um passivo não registrado, exatamente como se tivesse empréstimo não registrado.

Terceiro, o sistema legado: software que permanece em serviço além do ponto onde pode ser economicamente mantido — frequentemente porque funciona, todos dependem dele, e substituí-lo é assustador. Legado é dívida técnica em escala organizacional, e apresenta um problema de avaliação genuíno: os custos de mantê-lo (manutenção crescente, exposição de segurança, pessoal que não pode mais ser contratado, melhorias bloqueadas em outros lugares) são difusos e graduais, enquanto o custo de substituição é concentrado, visível, e politicamente arriscado. Sistemas de saúde em todo o mundo operam serviços críticos sobre software de décadas de idade precisamente por essa razão.

Quarto, dependência. O aprisionamento de fornecedor é a condição na qual trocar de um fornecedor custa tanto — em migração de dados, retreinamento, re-integração, e perturbação clínica — que o comprador perdeu poder de barganha efetivo. Em saúde é agravado por dados: uma década de registros de paciente mantidos em um formato proprietário é um refém. Aprisionamento não é um acidente; é uma estratégia de precificação, e o momento de precificá-lo é antes de assinar, não na renovação. Os contrapesos são contratuais (direitos de exportação de dados, custódia, assistência de saída) e arquitetônicos — acima de tudo, padrões.

Quinto, interoperabilidade: a capacidade de sistemas de trocar informação e usar o que é trocado. Sua economia é a economia do efeito de rede — cada sistema que fala um padrão comum eleva o valor de todo outro sistema que fala — que é por que interoperabilidade é cronicamente subfornecida por mercados: os benefícios acumulam para o sistema como um todo enquanto os custos recaem sobre cada fornecedor e comprador, e um incumbente pode lucrar de não interoperar. Padrões como Recursos de Interoperabilidade em Saúde Rápida (FHIR), a família HL7 à qual pertence, e openEHR existem para reduzir esses custos de troca, e reguladores — por exemplo os Estados Unidos através das regras de bloqueio de informação da Lei de Curas do Século 21, e a União Europeia através do Espaço Europeu de Dados de Saúde — começaram a mandatar o que o mercado não entregou.

Sexto, o espectro fazer-ou-comprar, incluindo software de código aberto — software cujo código fonte é livremente utilizável e modificável. Código aberto não é gratuito: o custo de licença desaparece, mas implementação, hospedagem, e administração permanecem, e alguém deve manter o código. Sua distinção econômica é diferente — remove o prêmio de aprisionamento e converte o software em um bem comum que muitos compradores podem cofinanciar, que é por que plataformas como DHIS2 e OpenMRS carregam grande parte do fardo de informação de saúde em países de renda baixa e média. A decisão construir-versus-comprar, igualmente, não é uma preferência tecnológica mas uma questão de portfólio: construa onde a capacidade é diferenciadora e a organização pode sustentar uma equipe de engenharia; compre onde a necessidade é commodity; e nunca construa o que você não pode manter.

Finalmente, confiabilidade como uma quantidade econômica. Software clínico opera serviços onde tempo de inatividade tem um custo de saúde, então as disciplinas de engenharia que mantêm sistemas confiáveis — incluindo engenharia de confiabilidade de site, que gerencia confiabilidade contra metas explícitas e orçamentos para falha aceitável — são melhor entendidas como comprar seguro cujo prêmio é esforço de engenharia. Confiabilidade acima do que o ambiente clínico precisa é desperdício; abaixo dela, o déficit é pago em incidentes. A maquinaria de avaliação para tudo isso permanece o Tópico 2.1 — Avaliação Econômica e a disciplina de acessibilidade do Tópico 2.5 — Impacto Orçamentário e Acessibilidade; este tópico fornece a estrutura de custo específica de software com a qual esses métodos devem ser alimentados. Avaliar uma ferramenta digital como uma intervenção de saúde — o aplicativo ou serviço de telessaúde melhora resultados a custo aceitável — pertence ao Tópico 5.2 — Economia da Saúde Digital; a economia de modelos de IA especificamente ao Tópico 5.3 — Economia da IA em Saúde.

Melhores práticas

Avalie custo total de propriedade sobre a vida realista do sistema, nunca o preço de compra. Exija que todo caso de negócio de software custeie aquisição, integração, migração de dados, treinamento, hospedagem, suporte, segurança, atualizações, e desativação sobre um horizonte declarado — geralmente uma década ou mais — e nomeie qual orçamento carrega cada linha recorrente. Uma taxa de licença comparada a nada não é um caso de negócio; é a ponta visível de um compromisso.
Coloque dívida técnica nos livros. Faça líderes de engenharia manterem um registro dos atalhos significativos e componentes envelhecendo na propriedade, com uma estimativa honesta do juro que cada um está cobrando — mudanças mais lentas, maior risco de incidente, melhorias bloqueadas. Revise-a com a mesma seriedade que um passivo financeiro, e orce uma parcela permanente de capacidade de engenharia (comumente um quinto a um terço) para pagá-la, porque serviço de dívida adiado é dívida composta.
Financie manutenção como um custo operacional desde o primeiro dia. Software que está "terminado" é software que está decaindo: dependências envelhecem, ameaças evoluem, regulações mudam. Construa o fluxo de manutenção na avaliação original e no orçamento recorrente, e trate uma proposta sem uma linha de manutenção como incompleta — o dinheiro será gasto de qualquer forma, e a única pergunta é se foi planejado ou extraído por uma crise.
Precifique aprisionamento antes de assinar, não na renovação. Para toda compra importante, custeie a saída enquanto você ainda tem alternativas: quem possui os dados, em que formato podem ser exportados, que assistência de saída o fornecedor deve fornecer, e o que uma migração plausivelmente custaria. Negocie direitos de exportação de dados e interfaces abertas no contrato, e trate resistência de fornecedor a eles como informação sobre a negociação de renovação por vir.
Compre interoperabilidade deliberadamente, porque o mercado a subfornece. Exija suporte a padrões abertos — FHIR e seus semelhantes — como uma condição de compra, verifique conformidade reivindicada contra seus fluxos de dados reais em vez de um folheto, e recuse interfaces sob medida onde uma padrão existe. Toda interface proprietária que você aceita é um custo de troca que você doou ao fornecedor e um imposto sobre toda integração futura.
Decida construir-versus-comprar como um portfólio, combinado com sua capacidade de engenharia. Construa apenas onde a capacidade diferencia seu serviço e você pode realisticamente recrutar, reter, e financiar uma equipe para manter o que constrói — um sistema interno sem uma equipe sustentada é um sistema legado com passos extras. Compre necessidades de commodity; considere plataformas de código aberto onde uma comunidade ou consórcio público as sustenta; e escreva o plano de sustentação na decisão, qualquer que seja o caminho.
Trate código aberto como uma opção de aquisição com sua própria estrutura de custo, não como gratuito. Compare-o em custo total de propriedade: sem taxa de licença, mas custos reais de implementação, hospedagem, suporte, e administração, seja carregados internamente ou através de um fornecedor de suporte. Pese seus benefícios distintivos — nenhum prêmio de aprisionamento, código inspecionável, a capacidade de cofinanciar um bem comum com outros órgãos de saúde — e sua obrigação distintiva: se você depende dele, contribua para sustentá-lo.
Defina metas de confiabilidade a partir de consequência clínica, e gaste até a meta. Decida, serviço por serviço, o que uma hora de tempo de inatividade realmente custa — em cuidado atrasado, soluções alternativas inseguras, e confiança perdida — e defina objetivos de disponibilidade e recuperação de acordo. Então mantenha o gasto de engenharia na meta de ambos os lados: pagar por menos confiabilidade do que a clínica precisa compra incidentes, e pagar por mais do que precisa compra excesso de acabamento.
Planeje substituição de legado antes que se torne forçada. Revise a idade e mantibilidade de sistemas críticos em um ciclo, e comece substituição enquanto o incumbente ainda funciona — uma migração executada sob falha é o tipo mais caro. Prefira migração incremental (estrangulando o sistema antigo interface por interface) a transições big-bang, cujo modo de falha em saúde é medido em clínicas canceladas e registros perdidos.
Torne migração de dados uma linha de primeira classe em toda avaliação. Dados de paciente sobrevivem a todo sistema que os detém, e movê-los — limpamente, completamente, com segurança clínica assegurada — é rotineiramente entre os custos maiores e mais subestimados de qualquer transição. Custeie-a explicitamente, teste-a cedo com registros reais, e mantenha custódia de seus dados em forma exportável durante toda a vida de um sistema para que a migração nunca seja refém do fornecedor que sai.
Mantenha engenharia de segurança clínica dentro da economia. Software de saúde é software relevante para segurança: mudanças precisam de teste, lançamentos precisam de caminhos de reversão, incidentes precisam de investigação, e jurisdições cada vez mais impõem padrões formais de risco clínico em TI de saúde. Essas disciplinas custam tempo de engenharia e pertencem ao caso de negócio — uma entrega "mais barata" que os pula está transferindo custo aos pacientes como risco (o custo de dano é o Tópico 3.11 — Economia da Qualidade e Segurança).
Direcione decisões de software através do mesmo escrutínio de valor que qualquer outro investimento de saúde. Um programa de software compete pelo mesmo orçamento restrito que medicamentos e pessoal, então deve a mesma disciplina: um benefício declarado, um comparador real (incluindo "melhorar o que temos"), um perfil de acessibilidade ao longo do tempo, e revisão pós-implementação contra as promessas feitas (a maquinaria é o Tópico 2.1 — Avaliação Econômica e Tópico 2.5 — Impacto Orçamentário e Acessibilidade, e a arte de compra é o Tópico 3.10 — Compras Estratégicas e Contratação).

Perguntas para discutir com sua equipe

Quanto nossa propriedade de software realmente custa por ano, e que parcela disso planejamos? A maioria das organizações pode nomear suas taxas de licença mas não seus custos de integração, manutenção, segurança, e solução alternativa, que se escondem em orçamentos operacionais e tempo de pessoal através da organização. Peça à equipe que reúna a figura anual verdadeira para o punhado principal de sistemas e a compare com o que os casos de negócio originais prometeram. A tensão é que os custos difusos não têm um único proprietário, então ninguém é responsável por seu crescimento, e as pessoas que aprovaram a compra raramente são as pessoas pagando a manutenção. Uma resposta honesta produz um número de vida inteira, nomeia quais orçamentos o carregam, e admite onde gasto é não planejado — porque um custo que você descobre anualmente em atraso é um custo que não pode gerenciar.
Onde está nossa dívida técnica, e que juro estamos pagando por ela? Equipes de engenharia geralmente sabem exatamente onde a dívida está — o módulo que ninguém ousa tocar, a interface mantida junta por passos manuais, a plataforma duas versões atrás em suporte de segurança — mas o conhecimento raramente alcança o conselho em linguagem econômica. Peça o registro: as dívidas significativas, o que cada uma desacelera ou ameaça, e o que pagá-la custaria. A tensão é que pagamento de dívida compete com novas características visíveis e sempre perde em aparência, que é precisamente como dívida se compõe. Uma resposta honesta quantifica o juro (entrega mais lenta, exposição a incidente, projetos bloqueados), compromete uma parcela permanente de capacidade a redução, e aceita que alguma dívida é racional de carregar — desde que seja carregada conscientemente.
Se tivéssemos que deixar nosso principal fornecedor de sistema em três anos, poderíamos — e o que custaria? Esta pergunta revela aprisionamento enquanto ainda há tempo de reduzi-lo. Investigue quem possui os dados e em que formato podem sair, o que o contrato diz sobre assistência de saída, quantas interfaces sob medida precisariam ser reconstruídas, e que retreinamento e perturbação clínica uma migração imporia. A tensão é que todos esperam nunca exercer a saída, então ninguém quer pagar para mantê-la aberta — ainda assim uma saída que é impossível é uma negociação de renovação já perdida. Uma resposta honesta precifica a saída, identifica as duas ou três ações que a barateariam (direitos de exportação de dados, interfaces padrão, documentação), e trata esse preço como uma posição de barganha que a organização ativamente mantém.
Quais sistemas deveríamos construir, quais deveríamos comprar, e nossa capacidade de engenharia corresponde a essa resposta? A divisão construir-versus-comprar é uma decisão de portfólio que muitas organizações fazem por acúmulo em vez de escolha, acabando construindo commodities e comprando o que as diferencia. Pergunte quais de seus sistemas genuinamente incorporam algo distintivo sobre seu serviço e quais são necessidades de commodity que um mercado ou uma comunidade de código aberto já atende. Depois teste a reivindicação de capacidade: para tudo construído internamente, há uma equipe financiada e recrutável comprometida a mantê-lo por sua vida — não apenas o projeto que o criou? A tensão é que construir lisonjeia ambição e comprar lisonjeia prudência, e nenhum instinto é uma análise. Uma resposta honesta nomeia os diferenciadores, admite onde construções passadas deveriam ser aposentadas ou substituídas por produtos padrão, e se recusa a começar qualquer construção cuja manutenção é não financiada.
O que uma hora de tempo de inatividade em nosso sistema mais crítico realmente custa, e nosso gasto de confiabilidade é combinado com isso? Decisões de confiabilidade são frequentemente tomadas por engenheiros sem informação de custo clínico, ou por conselhos sem informação de custo de engenharia, então o gasto é combinado com hábito em vez de consequência. Trabalhe através de um cenário concreto: o registro eletrônico está inativo através de um dia movimentado — o que é atrasado, que soluções alternativas inseguras aparecem, que dano plausivelmente se segue, quanto custa recuperação? Depois compare isso contra o que você gasta em resiliência, backups, failover, e resposta a incidente. A tensão corre em ambas as direções: subgastar compra incidentes, mas excesso de acabamento em um sistema de baixo risco desperdiça dinheiro que outro serviço precisa. Uma resposta honesta define uma meta explícita de disponibilidade e recuperação por serviço crítico, derivada de consequência clínica, e pode mostrar o gasto de engenharia que a atende — nem mais, nem menos.
Qual é nosso plano para os sistemas legados que todos têm medo de tocar? Toda organização de saúde madura os tem: sistemas além de mantibilidade econômica, mantidos vivos porque funcionam e substituição é assustadora. Nomeie os seus. Pergunte o que cada um bloqueia — integrações não construídas, melhorias não feitas, exposição de segurança carregada — e qual é o caminho de substituição: migração incremental, substituição total, ou retenção deliberada e planejada com risco contido. A tensão é temporal: os custos de manter legado são difusos e anuais enquanto o custo de substituí-lo é concentrado e visível na carreira, então adiamento aparentemente racional é o padrão até que falha force a questão ao pior preço possível. Uma resposta honesta agenda substituição enquanto o incumbente ainda funciona, prefere migração incremental de estilo estrangulador a transição big-bang, e trata "decidiremos ano que vem" como a decisão que realmente é.

Na prática: um exemplo de economia da saúde

O Ministério da Saúde de um país fictício da África Oriental enfrenta uma decisão de renovação. Por nove anos seus hospitais regionais operaram um sistema de informação hospitalar proprietário fornecido por um fornecedor estrangeiro. O sistema funciona, mas a cotação de renovação subiu acentuadamente, toda nova interface — ao esquema de seguro nacional, à rede de laboratório — é um projeto sob medida e precificado pelo fornecedor, e o contrato é silencioso sobre exportação de dados. Enquanto isso os escritórios de saúde distritais do ministério já operam DHIS2, a plataforma de código aberto usada para estatísticas de saúde nacionais, e um país vizinho implementou uma plataforma de registro médico de código aberto com um consórcio de suporte regional.

A unidade de economia da saúde do ministério reenquadra a decisão de "renovar ou não" para uma comparação de vida inteira de três opções sobre dez anos: renovar o incumbente, renovar a curto prazo enquanto constrói direitos de saída, ou migrar incrementalmente para a plataforma de código aberto. Custear as opções expõe a economia real. A licença do incumbente é apenas um terço de seu custo anual verdadeiro uma vez que interfaces sob medida, projetos de atualização obrigatórios, e viagem de suporte estrangeiro são contados. A opção de código aberto não carrega licença mas exige que o ministério financie uma equipe de suporte nacional, hospedagem regional, e uma contribuição à comunidade da plataforma — dinheiro real e recorrente que a retórica de "software gratuito" havia escondido. A linha decisiva, porém, não é nenhuma dessas: é migração de dados. Nove anos de registros de paciente situam-se em um esquema proprietário, e o preço do fornecedor por assistência de extração é, em efeito, o preço de sair.

A unidade precifica a saída de qualquer forma, e o número muda a negociação. Armado com uma alternativa custeada, o ministério negocia uma renovação de dois anos a um preço mais baixo que inclui exportação de dados contratual em um formato documentado e interfaces FHIR padrão ao esquema de seguro e rede de laboratório — comprado, em termos econômicos, como uma opção sobre uma saída futura mais barata, valorada da forma que o Tópico 3.12 — Economia da Preparação para Pandemias e Emergências valora qualquer opção sobre liberdade de ação futura. Durante esses dois anos, um piloto migra três hospitais distritais para a plataforma de código aberto, testando o consórcio de suporte, as ferramentas de migração de dados, e — criticamente — se o ministério pode recrutar e reter os engenheiros que a plataforma precisa, baseando-se na economia de força de trabalho do Tópico 3.6 — Força de Trabalho em Saúde e Mercados de Trabalho.

O piloto tem sucesso em dois hospitais e luta no terceiro, onde lacunas de pessoal transformam todo incidente em uma crise — um aviso sobre capacidade, não software. O ministério prossegue com uma migração nacional faseada ao longo de cinco anos, hospital por hospital, mantendo o incumbente funcionando em paralelo até que os dados de cada site sejam verificados. A avaliação final torna a lição explícita: o movimento vencedor não foi escolher código aberto sobre proprietário, mas precificar toda a vida de cada opção, comprar direitos de saída antes que dependência endurecesse ainda mais, e combinar o compromisso de engenharia com o que o ministério poderia realmente sustentar.

Quatro lentes setoriais

Startup

Uma startup de software de saúde vive a economia deste tópico do lado vendedor: sua avaliação recompensa velocidade de entrega, que é precisamente como dívida técnica se acumula, e seu modelo de receita pode silenciosamente depender do aprisionamento que seus clientes deveriam resistir. A disciplina é assumir dívida deliberadamente — um atalho que ganha um cliente pivotal pode ser racional — enquanto mantém um registro e um plano de pagamento, porque uma base de código que não pode ser mudada é uma empresa que não pode pivotar. Interoperabilidade é estratégia, não conformidade: interfaces padrão (FHIR acima de tudo) são como um pequeno produto ganha um lugar dentro de propriedades dominadas por incumbentes. E engenharia de segurança clínica não é burocracia a adiar até escala; um incidente de integridade de dados em um ambiente clínico pode encerrar uma empresa jovem.

Pequena empresa

Um provedor pequeno mas estabelecido — um grupo de clínicas, uma rede de farmácia, um laboratório de diagnóstico — compra quase todo seu software e não tem pessoal de engenharia para compensar uma compra ruim, então sua economia é a economia de dependência. Custo total de propriedade e direitos de saída importam mais aqui do que em qualquer lugar, porque um sistema mal precificado é proporcionalmente uma parcela maior do orçamento e uma migração fracassada pode parar o negócio. A postura sensata é padronização: produtos mainstream, interfaces de padrão aberto, serviços hospedados em vez de servidores autogerenciados, e contratos lidos por cláusulas de exportação de dados antes do preço. Seu risco distintivo é legado silencioso — o sistema de gestão de prática que envelhece no lugar até que seu fornecedor feche — então mesmo um pequeno comprador deveria saber, a cada ano, o que custaria sair de cada sistema do qual depende.

Empresa

Um grande grupo hospitalar ou seguradora opera centenas de sistemas, então seu problema é o portfólio: produtos sobrepostos comprados por departamentos diferentes, uma teia de integração que ninguém mapeia totalmente, e dívida técnica distribuída através de uma propriedade grande demais para qualquer equipe única ver. A empresa madura gerencia a propriedade da forma que gerencia um portfólio de investimento — um inventário de sistemas com proprietários, custos de vida inteira, classificações de dívida e risco, e horizontes de substituição planejados — e financia uma capacidade de engenharia permanente para integração, confiabilidade, e pagamento em vez de tratar toda melhoria como um projeto a ser licitado. Escala também lhe dá poder de compra que o comprador menor não tem: pode exigir interfaces padrão, direitos de exportação de dados, e custódia como condições de entrada, e suas escolhas arquitetônicas disciplinam seus fornecedores em vez do inverso.

Governo

Um ministério ou pagador nacional molda essa economia para todos os outros. Define as regras de interoperabilidade que determinam se o mercado recompensa ou pune abertura — como os Estados Unidos fizeram com as disposições de bloqueio de informação da Lei de Curas do Século 21 e a União Europeia com o Espaço Europeu de Dados de Saúde — e sua própria aquisição ensina fornecedores o que compradores tolerarão. Seu modo de falha distintivo é o mega-programa nacional: entrega de software centralizada, big-bang, agendada politicamente cujo colapso é medido em bilhões, como o Programa Nacional para TI do Reino Unido demonstrou. A disciplina é a postura inversa — padrões e plataformas centralmente, entrega incrementalmente, com opções de código aberto e localmente-mantíveis pesadas seriamente onde mercados comerciais são finos (a maquinaria de política é o Tópico 3.2 — Política de Saúde, e a arte de compra o Tópico 3.10 — Compras Estratégicas e Contratação).

Modos de falha comuns

Comprar a licença, não a vida. Aprovar software com base em preço de compra enquanto integração, migração, manutenção, e saída ficam não custeados. Correção: exija custo total de propriedade de vida inteira, com orçamentos nomeados para cada linha recorrente, em todo caso de negócio.
Dívida invisível até compor. Deixar dívida técnica se acumular não registrada até que a propriedade não possa ser mudada com segurança. Correção: mantenha um registro de dívida, relate-o em termos econômicos, e comprometa capacidade permanente a pagamento.
Caminhar sonâmbulo para aprisionamento. Aceitar formatos proprietários e interfaces sob medida até que saída seja inacessível e renovações sejam ditadas. Correção: negocie direitos de exportação de dados e interfaces padrão na compra, e precifique a saída anualmente.
Construir o que você não pode manter. Comissionar sistemas internos sem uma equipe financiada para sua vida inteira. Correção: nenhuma construção sem um plano de sustentação; compre ou adote plataformas de código aberto onde capacidade é fina.
Tratar código aberto como gratuito. Adotar plataformas comunitárias sem financiar hospedagem, suporte, e administração. Correção: avalie código aberto em custo total de propriedade e orce a sustentação que precisa.
Confiabilidade por esperança. Deixar metas de disponibilidade não definidas até que uma interrupção revele o custo clínico de tempo de inatividade. Correção: defina objetivos de disponibilidade e recuperação por serviço crítico a partir de consequência clínica, e gaste até a meta.
Substituição de legado big-bang sob pressão. Adiar modernização até que falha force uma transição apressada e total. Correção: planeje substituição enquanto o incumbente funciona, e migre incrementalmente com execução paralela e dados verificados.
Software fora da disciplina de valor. Deixar programas de TI pularem o escrutínio aplicado a medicamentos e serviços. Correção: mesmas regras — benefício declarado, comparador real, perfil de acessibilidade, revisão pós-implementação.

Modelo de maturidade

Dimensão	Iniciar	Desenvolver	Padronizar	Gerenciar	Orquestrar
Custeio de vida inteira	Software comprado com base em preço de licença; custos operacionais descobertos em atraso	Compras importantes custeadas sobre vários anos; linhas recorrentes parcialmente identificadas	Custo total de propriedade sobre vida de sistema exigido em todo caso de negócio, com orçamentos nomeados	Custos de propriedade inteira rastreados contra previsão, variações investigadas, previsões recalibradas	Economia de vida inteira dirige o portfólio: investimentos, renovações, e aposentadorias rebalanceados continuamente
Dívida técnica	Invisível; descoberta através de incidentes	Conhecida informalmente por engenheiros; nenhum registro compartilhado	Registro de dívida mantido e relatado em termos econômicos; capacidade de pagamento permanente	Tendências de dívida gerenciadas com limites e prioridades; juro medido em velocidade de entrega e exposição a incidente	Dívida assumida e aposentada deliberadamente como estratégia, precificada em toda decisão de entrega
Fornecedor e saída	Termos aceitos como oferecidos; saída não precificada	Aprisionamento reconhecido; algumas cláusulas de exportação buscadas	Direitos de exportação de dados e interfaces padrão contratuais como regra; saídas custeadas na compra	Posições de saída mantidas e ensaiadas; renovações negociadas contra uma alternativa viva	Portfólio de fornecedor moldado ao longo do tempo; dependência uma posição escolhida e precificada, nunca um acidente
Interoperabilidade	Interfaces sob medida se acumulam caso a caso	Padrões abertos preferidos onde conveniente	Conformidade de padrão (ex. FHIR) uma condição verificada de compra	Propriedade de integração mapeada e gerenciada; interfaces proprietárias aposentadas conforme plano	Organização molda adoção de padrão através de parceiros e seu mercado
Confiabilidade e segurança	Custo de tempo de inatividade desconhecido; recuperação improvisada	Backups e resposta a incidente existem; metas implícitas	Objetivos de disponibilidade e recuperação definidos por serviço crítico a partir de consequência clínica	Confiabilidade projetada e medida contra metas; incidentes investigados economicamente	Resiliência orquestrada através da propriedade e fornecedores, ensaiada e continuamente melhorada

Lista de verificação

Avalie toda decisão de software em custo total de propriedade sobre sua vida realista, com orçamentos nomeados para cada linha recorrente.
Mantenha um registro de dívida técnica, relate-o em termos econômicos, e comprometa capacidade de engenharia permanente a pagamento.
Financie manutenção como um custo operacional planejado desde o caso de negócio original em diante.
Negocie direitos de exportação de dados, interfaces padrão, e assistência de saída em contratos na compra.
Precifique a saída de cada sistema principal anualmente, e mantenha uma alternativa custeada viva antes de renovações.
Exija conformidade de padrões abertos verificada (ex. FHIR) como uma condição de compra.
Decida construir-versus-comprar como um portfólio, e não comece nenhuma construção sem um plano de sustentação de vida inteira financiado.
Avalie opções de código aberto em custo total de propriedade, orçando hospedagem, suporte, e administração.
Defina metas de disponibilidade e recuperação por serviço crítico a partir de consequência clínica, e combine gasto com elas.
Agende substituição de legado enquanto incumbentes ainda funcionam, preferindo migração incremental a transição big-bang.
Custeie e teste migração de dados cedo, e mantenha dados de paciente exportáveis durante toda a vida de cada sistema.
Direcione programas de software através do mesmo escrutínio de valor que qualquer outro investimento de saúde, com revisão pós-implementação.

Key sources

WHO, Global Strategy on Digital Health 2020–2025 — the World Health Organization's frame for digital health investment, including sustainability and interoperability principles.
HL7 International — the FHIR (Fast Healthcare Interoperability Resources) standard, the dominant open standard for health-data exchange.
openEHR, DHIS2, and OpenMRS — open-source health-information platforms and specifications widely deployed worldwide, exemplars of community-sustained health software.
U.S. Office of the National Coordinator for Health IT (now ASTP) — 21st Century Cures Act information-blocking and interoperability rules, a regulatory response to under-supplied interoperability.
DORA, Accelerate State of DevOps reports — long-running research linking software delivery and reliability practices to organizational performance.
UK National Audit Office — reports on the National Programme for IT in the NHS, the canonical case study of large-scale health-IT programme failure.

References

Software engineering — Wikipedia — https://en.wikipedia.org/wiki/Software_engineering
Software maintenance — Wikipedia — https://en.wikipedia.org/wiki/Software_maintenance
Total cost of ownership — Wikipedia — https://en.wikipedia.org/wiki/Total_cost_of_ownership
Technical debt — Wikipedia — https://en.wikipedia.org/wiki/Technical_debt
Legacy system — Wikipedia — https://en.wikipedia.org/wiki/Legacy_system
Vendor lock-in — Wikipedia — https://en.wikipedia.org/wiki/Vendor_lock-in
Interoperability — Wikipedia — https://en.wikipedia.org/wiki/Interoperability
Network effect — Wikipedia — https://en.wikipedia.org/wiki/Network_effect
Fast Healthcare Interoperability Resources — Wikipedia — https://en.wikipedia.org/wiki/Fast_Healthcare_Interoperability_Resources
Health Level 7 — Wikipedia — https://en.wikipedia.org/wiki/Health_Level_7
Open-source software — Wikipedia — https://en.wikipedia.org/wiki/Open-source_software
Site reliability engineering — Wikipedia — https://en.wikipedia.org/wiki/Site_reliability_engineering
World Health Organization — Global Strategy on Digital Health 2020–2025 — https://www.who.int/publications/i/item/9789240020924
HL7 International — FHIR specification — https://hl7.org/fhir/
National Audit Office — The National Programme for IT in the NHS: an update on the delivery of detailed care records systems — https://www.nao.org.uk/reports/the-national-programme-for-it-in-the-nhs-an-update-on-the-delivery-of-detailed-care-records-systems/
National Programme for IT — Wikipedia — https://en.wikipedia.org/wiki/National_Programme_for_IT