Tópico 1.1 — O modelo operacional

Em uma frase: Um modelo operacional-alvo (TOM) é o desenho deliberado de como a estratégia da sua organização flui por fluxos de valor, capacidades, equipes, governança, tecnologia, dados e fornecedores para produzir resultados de saúde e cuidados digitais — e acertar a sua forma determina se tudo o que vem depois será rápido e seguro ou lento e frágil.

Por que isso importa na saúde e nos cuidados#

A maioria das organizações de saúde digital não fracassa por falta de talento ou de tecnologia; fracassa porque o seu modelo operacional trabalha contra elas. O financiamento está preso a projetos com prazo limitado, os direitos de decisão são ambíguos e cada equipe reconstrói a mesma infraestrutura de login, integração e auditoria. O resultado é custo duplicado com dinheiro público, segurança clínica inconsistente e serviços que não conseguem compartilhar dados num sistema de cuidados integrados (ICS).

Um modelo operacional é peculiar nesse domínio porque precisa conciliar bens concorrentes. Precisa ser federado o bastante para respeitar a autonomia de organizações soberanas — hospitais, autoridades locais, consultórios de clínica geral — e, ao mesmo tempo, coerente o bastante para dar ao paciente uma experiência segura entre elas. Precisa equilibrar a operação (manter os sistemas clínicos seguramente disponíveis) com a mudança (melhorá-los), quando uma indisponibilidade pode afetar o cuidado. E precisa gastar de forma proporcional: garantia pesada o bastante para a prestação de contas pública e a segurança clínica, leve o bastante para não sufocar a iteração. O TOM é o lugar onde essas concessões se tornam explícitas, em vez de ficarem ao acaso.

Conceitos centrais#

As camadas de um modelo operacional. Um TOM útil é uma pilha, em que cada camada serve à de cima:

• Estratégia e resultados — os resultados mensuráveis para a população e para o serviço que você existe para melhorar (muitas vezes expressos como OKRs; ver Tópico 1.3 — Decisões baseadas em evidências).
• Fluxos de valor — os fluxos de ponta a ponta que entregam valor a um usuário, por exemplo "encaminhar, triar e tratar um paciente" — organizados em torno da jornada do cidadão, e não do organograma.
• Capacidades — as coisas que você precisa ser capaz de fazer (identidade, agendamento de consultas, documentação clínica, análises). As capacidades são estáveis mesmo quando as soluções mudam.
• Equipes — as pessoas organizadas para entregar capacidades e fluxos de valor (ver Team Topologies, abaixo).
• Governança e direitos de decisão — quem decide o quê e como a garantia é aplicada.
• Tecnologia e dados — as plataformas, os padrões e a arquitetura de dados sobre os quais as equipes constroem.
• Fornecedores — o mercado de onde você compra e como o gere.

Desenhar de cima para baixo (estratégia → fluxos de valor → capacidades) mantém equipes e tecnologia alinhadas aos resultados, e não a estruturas legadas.

Modelos centralizado, federado e de plataforma. Um modelo centralizado concentra a entrega numa equipe ou num órgão independente: consistente e barato de padronizar, mas gargalo e, muitas vezes, distante da necessidade local. Um modelo federado devolve a entrega aos hospitais e aos territórios: ágil e com apropriação local, mas propenso à duplicação e à divergência. Um modelo de plataforma é o padrão conciliador: uma equipe central oferece capacidades compartilhadas e reutilizáveis (identidade, interoperabilidade, hospedagem, sistema de design) como uma plataforma, e as equipes federadas constroem por cima, em velocidade. A maioria dos sistemas de saúde maduros converge para "plataforma mais federação".

Team Topologies. Esse arcabouço nomeia quatro tipos de equipe — alinhada ao fluxo (responsável por um fluxo de valor), de plataforma (que oferece capacidades de autosserviço), habilitadora (que orienta outras a desenvolver uma capacidade) e de subsistema complicado (trabalho especializado profundo, como um algoritmo) — e enfatiza a interação de baixo atrito entre elas. Mapeia-se de forma limpa no modelo de plataforma: as equipes de plataforma reduzem a carga cognitiva das equipes alinhadas ao fluxo, para que elas se concentrem no valor para o usuário e no valor clínico.

Operação versus mudança. Operar é manter os serviços em produção seguros e disponíveis; mudar é melhorá-los ou construí-los. Equipes de produto que constroem e operam um serviço ("você constrói, você opera") fecham o ciclo de retroalimentação e melhoram a segurança, mas o equilíbrio precisa ser financiado com honestidade — esvaziar a operação para financiar a mudança é como os sistemas clínicos se degradam.

A plataforma mínima viável (TVP). Do Team Topologies: uma plataforma deve ser o menor conjunto de serviços compartilhados que realmente reduza o atrito para as equipes de fluxo — nem mais. Uma plataforma superconstruída se torna o seu próprio gargalo e o seu próprio legado. Comece com as poucas capacidades de que toda equipe realmente precisa (autenticação, uma camada de interoperabilidade, hospedagem, um sistema de design) e cresça apenas com demanda comprovada.

Boas práticas#

1. Desenhe o modelo dos resultados para baixo, e não do organograma para cima. Comece pelos resultados de população e de serviço que você precisa mover, derive os fluxos de valor que os entregam e só então desenhe equipes e tecnologia. Um TOM ancorado na hierarquia existente apenas automatiza os silos atuais.

2. Adote o formato de plataforma mais federação. Ofereça as capacidades compartilhadas de forma centralizada, como uma plataforma de autosserviço, e deixe as equipes alinhadas ao fluxo, nos hospitais e nos territórios, construírem por cima. Isso dá consistência nacional em segurança e interoperabilidade com velocidade e apropriação locais — a conciliação que o domínio exige.

3. Financie produtos, e não projetos. Transfira o dinheiro de projetos com prazo fechado para equipes de produto financiadas de forma permanente e alinhadas aos fluxos de valor. O financiamento por projeto força as equipes a se dissolverem exatamente quando aprenderam o domínio; o financiamento por produto sustenta o conhecimento de segurança e a iteração de que os serviços de saúde precisam (ver Tópico 5.0 — Trabalho conduzido por produto).

4. Torne o controle de gastos proporcional e escalonado. Use financiamento escalonado, atrelado a evidências — libere o dinheiro nas etapas de descoberta, alfa, beta e produção, em vez de aprovar um programa inteiro de antemão. Os controles de gastos ao estilo do GDS e a via de garantia do NHS existem para evitar grandes custos irrecuperáveis em ideias não comprovadas; aplique-os como limiares proporcionais ao risco e ao valor, e não como burocracia indiscriminada.

5. Torne explícitos os direitos de decisão com um mapa RACI ou RAPID. A autoridade ambígua é a causa mais comum de entrega paralisada. Nomeie, para cada tipo de decisão relevante, quem é Responsável/Aprovador/Consultado/Informado (RACI) ou quem Recomenda, Concorda, Executa, dá Contribuição e Decide (RAPID). Publique-o para que as equipes parem de escalar decisões que têm autonomia para tomar.

6. Mantenha a plataforma mínima e movida pela demanda. Construa capacidades compartilhadas apenas quando duas ou mais equipes comprovadamente precisarem da mesma coisa e trate a plataforma como um produto com seus próprios usuários (as equipes internas). Resista ao impulso de pré-construir uma grande plataforma; a plataforma mínima viável conquista seu escopo pela adoção.

7. Gerencie os fornecedores como parte do modelo, e não fora dele. Decida deliberadamente quais capacidades são estratégicas (construir/possuir) e quais são commodity (comprar), evite a dependência de um único fornecedor (lock-in) sobre dados clínicos centrais e exija padrões abertos e direitos de saída nos contratos. Seus fornecedores são uma camada do seu modelo operacional, e os modos de trabalho deles precisam ser compatíveis com os seus.

8. Torne explícitos os direitos de decisão. Um modelo operacional só funciona se as pessoas sabem quem decide o quê — quais escolhas cabem a uma equipe de produto, quais a uma autoridade de segurança clínica e quais precisam chegar a um conselho. Mapeie os direitos de decisão e empurre cada decisão para o nível mais baixo que consiga sustentá-la com segurança, de modo que a entrega não seja estrangulada por escalonamentos desnecessários. A autoridade ambígua é uma das causas mais comuns de entregas lentas e defensivas.

9. Trate o modelo operacional como um produto que evolui. Um modelo operacional-alvo não é definido uma vez e emoldurado numa parede; inspecione-o à medida que a demanda, a tecnologia e as parcerias mudam e adapte-o com base em evidências. Observe alguns sinais — fluxo de trabalho, tempo até a decisão, retrabalho e saúde da equipe — e mude as estruturas quando elas comprovadamente atrapalharem, e não em resposta a modismos de reorganização.

Perguntas para discutir com a sua equipe#

1. O nosso modelo operacional foi desenhado dos resultados e fluxos de valor para baixo, ou apenas automatizou o nosso organograma atual e seus silos? Esta pergunta vai ao cerne do alerta central do tópico: um TOM ancorado na hierarquia atual apenas consolida os silos que você já tem; por isso vale colocá-la na mesa antes de qualquer reorganização. Importa no contexto de saúde e cuidados porque os fluxos de valor seguem a jornada do cidadão — encaminhar, triar, tratar — entre organizações soberanas, enquanto os organogramas seguem as fronteiras institucionais, e um modelo construído sobre estas últimas continuará produzindo serviços fragmentados e não interoperáveis com dinheiro público. A tensão a debater com honestidade é que desenhar de cima para baixo, a partir dos resultados, é genuinamente disruptivo: atravessa a propriedade departamental, os orçamentos e as linhas hierárquicas em torno dos quais pessoas seniores construíram carreiras, de modo que fazê-lo direito tem custo político real. Teste-se de forma concreta nomeando os seus três principais resultados e verificando se as fronteiras reais das equipes e as linhas de financiamento seguem esses fluxos de valor ou os departamentos; se as equipes se mapeiam de forma limpa nos departamentos, está aí a resposta. Uma boa resposta, honesta, admite onde o modelo tem formato de organograma, identifica ao menos um fluxo de valor hoje dividido entre silos em seu prejuízo e é realista sobre quais fronteiras estruturais a organização está disposta a redesenhar.

2. O que pertence à nossa plataforma mínima viável, e como evitaremos que ela seja superconstruída até virar um gargalo ou subconstruída a ponto de cada equipe reconstruir a mesma infraestrutura? O formato de plataforma mais federação só funciona se a plataforma permanecer mínima e movida pela demanda, e esta pergunta faz a equipe enfrentar os dois modos de falha que o tópico nomeia — a grande plataforma que se torna o seu próprio gargalo legado e a ausência que obriga cada equipe a reconstruir login, integração e auditoria. Importa porque, num ICS, a plataforma é na prática infraestrutura compartilhada (identidade, uma camada de interoperabilidade FHIR, hospedagem com bases de segurança, um sistema de design), e errar o seu escopo multiplica custo ou atrito em todas as equipes de fluxo. A concessão a debater é o momento e a evidência: construir cedo demais significa errar o palpite e criar um gargalo; construir tarde demais significa que a duplicação já calcificou — de modo que o teste "duas ou mais equipes comprovadamente precisam da mesma coisa" é o ponto central, e a equipe deve testar sob estresse se de fato o aplica ou apenas constrói o que parece obviamente central. Observe o que hoje você trata como plataforma em comparação com o que as equipes reconstroem e pergunte se a plataforma é operada como um produto com seus próprios usuários internos e SLAs ou como uma fila atrás da qual todos esperam. Uma resposta honesta nomeia as capacidades específicas que hoje passam no teste das duas equipes, resiste à tentação de pré-construir o resto e se compromete a tratar os usuários internos da equipe de plataforma como clientes reais, com níveis de serviço reais.

3. Onde os nossos direitos de decisão são genuinamente ambíguos, e o que as equipes estão escalando hoje que deveriam ter autonomia para decidir sozinhas? A autoridade ambígua é apontada como a causa mais comum de entrega paralisada; por isso esta pergunta traz à tona o atrito cotidiano que um mapa RACI ou RAPID publicado se destina a remover. Importa de forma aguda num sistema de saúde federado, em que as equipes dos territórios, um conselho digital do ICS, a segurança clínica e a governança da informação têm todos reivindicações legítimas sobre uma decisão, e fronteiras pouco claras significam que tudo escala ou, pior, ninguém assume uma decisão até que ela dê errado. A tensão que vale explorar é que devolver decisões exige confiar nas equipes dentro de limites, algo que líderes seniores e conselhos costumam resistir justamente onde há segurança clínica ou dinheiro público — e, no entanto, negar essa confiança é o que cria o congestionamento de escalonamentos. Torne-a concreta listando as últimas cinco decisões que escalaram e perguntando, para cada uma, quem deveria ter decidido e que limite o teria permitido; o padrão costuma revelar um pequeno número de tipos de decisão ambíguos recorrentes. Uma boa resposta produz uma declaração específica e publicável de quem decide o quê — distinguindo padrões de plataforma, desenho de serviço e aprovação de segurança clínica — e é honesta sobre quais decisões a organização está realmente disposta a devolver e quais manterá centralizadas, e por quê.

4. Estamos financiando a operação e a mudança com honestidade, ou estamos silenciosamente esvaziando a operação dos serviços em produção para pagar por novas funcionalidades? O tópico é direto: esvaziar a operação para financiar a mudança é como os sistemas clínicos se degradam, e esta pergunta coloca o equilíbrio às claras antes que uma indisponibilidade ou um incidente de segurança o faça por você. Importa na saúde e nos cuidados porque "operar" não é custo indireto de retaguarda — é a disponibilidade dos sistemas de que os clínicos dependem no ponto de cuidado; assim, um orçamento de operação degradado aparece como indisponibilidade que pode afetar pacientes, e não apenas usuários incomodados. A concessão é desconfortável porque a mudança é visível e celebrada, enquanto a operação é invisível até falhar, de modo que conselhos e roteiros naturalmente pendem para o novo; um modelo "você constrói, você opera" ajuda ao manter o ciclo de retroalimentação fechado, mas só se o tempo de operação da equipe for de fato protegido, e não alocado nominalmente e depois saqueado. Torne-a concreta observando que proporção da capacidade de cada equipe de produto realmente foi para manter os serviços seguros e disponíveis no trimestre passado em comparação com o planejado e se o trabalho de operação é acompanhado e valorizado ou tratado como interrupção. Uma resposta honesta nomeia onde a operação está hoje subfinanciada, protege uma alocação realista de operação como primeira despesa, e não como resíduo, e é franca sobre quais serviços em produção carregam risco operacional acumulado.

5. Quais capacidades escolhemos deliberadamente construir e possuir em comparação com comprar, e estamos aceitando dependência de fornecedor sobre os nossos dados clínicos centrais sem querer? A boa prática aqui é decidir deliberadamente entre construir e comprar, evitar a dependência de um único fornecedor sobre dados clínicos centrais e tratar os fornecedores como uma camada do modelo operacional, e não como algo externo a ele — esta pergunta testa se essas escolhas estão de fato sendo feitas ou ocorrendo por omissão. Importa porque, na saúde digital, a dependência mais consequente está em torno do prontuário clínico e de seus dados, onde um repositório proprietário sem saída realista pode prender um sistema inteiro por uma década e ditar o que cada serviço a jusante pode fazer. A tensão é velocidade versus opcionalidade: comprar é mais rápido e muitas vezes mais barato hoje, sobretudo para uma equipe sobrecarregada, mas cada compra conveniente sem padrões abertos ou direitos de saída estreita silenciosamente as escolhas de amanhã, e o custo só se torna visível quando você tenta sair. Torne-a concreta listando as suas capacidades centrais, marcando cada uma como estratégica (construir/possuir) ou commodity (comprar) e verificando se os contratos por trás das commodities realmente exigem padrões abertos (HL7 FHIR, SNOMED CT) e direitos de saída exequíveis. Uma boa resposta distingue as poucas capacidades genuinamente estratégicas das muitas que podem ser compradas com segurança, é honesta sobre onde a organização já está presa em dados clínicos e se compromete com padrões abertos e direitos de saída nos contratos que mais importam.

6. Como saberemos quando o nosso modelo operacional precisa mudar e que sinais nos diriam isso — em vez de reorganizar por moda ou pela chegada de um novo líder? O tópico enquadra o modelo operacional como um produto que evolui com base em evidências, e não como um diagrama emoldurado numa parede; por isso esta pergunta pede à equipe que defina de antemão que evidência justificaria remodelá-lo. Importa na saúde e nos cuidados porque a reorganização é disruptiva e cara — dissolve conhecimento de domínio e de segurança clínica arduamente conquistado — e, no entanto, o setor é propenso à rotatividade estrutural movida por ciclos de políticas e por novas nomeações, e não pelo fato de o modelo atual estar de fato atrapalhando. A tensão está entre estabilidade e adaptação: mude o modelo com facilidade demais e nunca deixará as equipes se assentarem ou acumularem expertise de segurança; mude-o raramente demais e estruturas calcificadas estrangularão o fluxo muito depois de deixarem de se encaixar no trabalho. Torne-a concreta escolhendo um pequeno conjunto de sinais a observar — fluxo de trabalho, tempo até a decisão, retrabalho e saúde da equipe — e acordando que movimento neles acionaria um redesenho deliberado e não um ajuste menor. Uma resposta honesta se compromete com alguns indicadores antecedentes, distingue mudança guiada por evidências de teatro de reorganização e é clara sobre quem é responsável por inspecionar o modelo e agir quando os sinais indicarem que ele está atrapalhando a entrega.

Na prática: um exemplo de saúde e cuidados#

Um ICS que abrange cinco territórios tem cada hospital construindo as suas próprias ferramentas de agendamento voltadas aos pacientes. Os custos se duplicam, as experiências divergem e nenhuma compartilha dados de forma limpa. O ICS redesenha o seu modelo operacional.

Define três resultados (reduzir as faltas às consultas, diminuir as internações evitáveis, melhorar a equidade de acesso) e os fluxos de valor por trás deles. Monta uma pequena equipe de plataforma responsável por quatro capacidades mínimas viáveis: uma identidade/login compartilhada, uma camada de interoperabilidade baseada em FHIR, uma hospedagem comum com bases de segurança e de segurança clínica e um sistema de design. Cada território mantém uma equipe alinhada ao fluxo, mas agora constrói sobre a plataforma, e não do zero.

O financiamento passa das propostas anuais de projeto para orçamentos permanentes de produto para cada fluxo, liberados por etapas de descoberta/alfa/beta. Um mapa RAPID publicado deixa claro que as equipes dos territórios decidem o próprio desenho de serviço dentro dos limites da plataforma e da segurança clínica, enquanto o conselho digital do ICS decide os padrões da plataforma. Em um ano, três territórios compartilham uma única capacidade de agendamento, a base de design e de segurança é consistente e novas funcionalidades que antes levavam um ciclo de projeto passam a ser entregues em semanas — porque a plataforma absorveu o trabalho pesado indiferenciado.

Perspectivas setoriais#

Um modelo operacional é dimensionado conforme a organização que serve; as mesmas camadas — fluxos de valor, capacidades, equipes, governança, plataforma, fornecedores — são desenhadas de formas muito diferentes por uma startup, uma grande organização e um órgão de governo.

Startup#

Numa pequena empresa de saúde digital, o modelo operacional é em grande parte implícito, e isso é aceitável: uma ou duas equipes alinhadas ao fluxo, um fundador que detém a maior parte dos direitos de decisão e nenhuma equipe de plataforma, porque ainda não há nada para plataformizar. A disciplina é tornar explícitas cedo as poucas decisões reais — construir ou comprar o repositório de dados clínicos, a quais padrões abertos se comprometer — para que o atalho de hoje não vire a dependência de amanhã. Operação e mudança estão nas mesmas mãos, de modo que o risco é que manter as luzes acesas para os primeiros clientes esvazie o roteiro; uma divisão simples e honesta do tempo de engenharia é o equivalente leve de um orçamento de operação protegido. Os fornecedores são escolhidos pela velocidade, mas uma startup ainda deve recusar a dependência sobre dados clínicos centrais, porque seus futuros compradores do NHS exigirão direitos de saída.

Pequena empresa#

Um pequeno prestador estabelecido — um consultório de clínica geral, uma farmácia comunitária, uma casa de repouso ou prestador de cuidados domiciliares, uma clínica de unidade única ou um pequeno fornecedor de tecnologia em saúde que já passou da fase pré-receita — tem pacientes reais e operações em curso, mas nenhuma equipe de plataforma, nenhuma capacidade digital ou de TI dedicada e pouca folga de caixa ou de pessoal. Aqui o modelo operacional é em grande parte um conjunto de capacidades compradas, costuradas entre si; por isso as escolhas decisivas são as de fornecedores: insistir em padrões abertos e direitos de saída nos sistemas clínicos que se adquirem, porque você carrega os mesmos deveres de interoperabilidade e de segurança clínica que um grande hospital, sem o seu poder de compra ou a sua expertise interna. Operação e mudança recaem sobre o mesmo punhado de pessoas que também presta cuidados, de modo que a disciplina honesta é proteger um pouco de tempo para manter os sistemas seguros e atualizados, em vez de apenas apagar incêndios. Os direitos de decisão são simples — em geral, decide um sócio ou o proprietário-gestor — mas isso facilita adiar indefinidamente as decisões digitais, de modo que o valor está em nomear as poucas que importam (qual prontuário clínico, a qual plataforma regional compartilhada aderir) e tomá-las deliberadamente. Quando um ICS ou um órgão nacional oferece uma plataforma compartilhada de identidade, interoperabilidade ou design, a melhor jogada da pequena empresa costuma ser construir sobre ela em vez de reinventar, tomando emprestada a capacidade que não consegue prover sozinha.

Grande organização#

Um hospital do NHS ou um ICS é onde o formato de plataforma mais federação justifica seu custo: organizações soberanas que precisam parecer um único serviço para o paciente. Os problemas difíceis são tanto políticos quanto técnicos — transferir dinheiro de propostas de projeto com prazo limitado para orçamentos permanentes de produto e publicar um mapa RACI/RAPID para que as equipes dos territórios deixem de escalar decisões que lhes pertencem. Uma grande empresa de tecnologia em saúde ou farmacêutica tem músculo de engenharia de plataforma, mas corre o risco de superconstruir uma grande plataforma interna que vira o seu próprio gargalo; o teste da plataforma mínima viável — duas ou mais equipes comprovadamente precisam da mesma coisa — é o freio. Nessa escala, os direitos de decisão e o fluxo de financiamento são o modelo operacional; a tecnologia geralmente não é a restrição.

Governo#

Um órgão público nacional ou local desenha modelos operacionais que outras organizações precisam habitar, de modo que suas escolhas sobre padrões e plataformas são, na prática, infraestrutura nacional. O NHS England ou o DHSC oferecendo uma camada de identidade compartilhada, uma espinha dorsal de interoperabilidade ou um sistema de design é o padrão de plataforma aplicado em escala populacional, e seus controles de gastos e etapas de garantia escalonadas são a forma de submeter o dinheiro público à prestação de contas. O modo de falha é um modelo centralizado que se torna um gargalo distante, impondo uma única solução a todo contexto local; o corretivo é plataformizar as capacidades realmente comuns e federar o resto para hospitais e autoridades locais. A prestação de contas ao Parlamento também significa que construir ou comprar e a gestão de fornecedores são matérias de registro público, de modo que padrões abertos e direitos de saída não são apenas prudentes, mas esperados.

Modos de falha comuns#

• Automatizar o organograma. Desenhar equipes em torno de departamentos existentes e não de fluxos de valor, de modo que o TOM consolida os silos. Antídoto: desenhar dos resultados e fluxos de valor para baixo.
• A plataforma que vira gargalo. Uma equipe de plataforma central de escopo excessivo atrás da qual toda solicitação precisa fazer fila. Antídoto: plataforma mínima viável, tratada como um produto com SLAs.
• Financiamento por projeto para trabalho de produto. Dinheiro que expira força a rotatividade de dissolver e reconstruir. Antídoto: financiamento permanente de produto com etapas escalonadas.
• Operação esvaziada para alimentar a mudança. Subfinanciar a operação dos serviços em produção até os sistemas clínicos se degradarem. Antídoto: financiar operação e mudança explicitamente e proteger o orçamento de operação.
• Decisões sem dono. Ninguém sabe quem decide, então tudo escala. Antídoto: um RACI/RAPID publicado.
• Dependência por omissão. Dados clínicos centrais presos num sistema proprietário de fornecedor, sem saída. Antídoto: padrões abertos e direitos de saída em todo contrato estratégico.

Modelo de maturidade#

Lista de verificação#

• O modelo operacional é desenhado a partir dos resultados e dos fluxos de valor, e não da hierarquia existente.
• As capacidades compartilhadas são oferecidas como uma plataforma mínima viável, com as equipes de fluxo construindo por cima.
• As equipes de produto são financiadas de forma permanente e alinhadas aos fluxos de valor.
• O controle de gastos é escalonado (etapas de descoberta/alfa/beta/produção) e proporcional ao risco e ao valor.
• Os direitos de decisão estão documentados (RACI ou RAPID) e publicados.
• Operação e mudança são financiadas explicitamente, com o orçamento de operação protegido.
• Os tipos de equipe (alinhada ao fluxo, de plataforma, habilitadora, de subsistema complicado) são compreendidos e usados.
• Construir ou comprar é uma escolha deliberada por capacidade; os dados clínicos centrais evitam dependência de fornecedor.
• Os contratos exigem padrões abertos (p. ex., HL7 FHIR, SNOMED CT) e direitos de saída.

Fontes-chave#

• Matthew Skelton & Manuel Pais — Team Topologies (equipes alinhadas ao fluxo, de plataforma, habilitadoras e de subsistema complicado; plataforma mínima viável).
• GOV.UK Service Manual — controles de gastos e garantia escalonada (descoberta/alfa/beta/produção); Government Digital Service.
• Manual de serviço digital do NHS — Padrão de serviço do NHS (service-manual.nhs.uk).
• AXELOS — Management of Portfolios (MoP) e Managing Successful Programmes (MSP), para a governança de portfólios e programas.
• Bain & Company — arcabouço de direitos de decisão RAPID; e o modelo de atribuição de responsabilidades RACI.
• John Doerr — Measure What Matters (OKRs), para a definição de resultados.

Referências#

1. Operating model — Wikipedia — https://en.wikipedia.org/wiki/Operating_model
2. Value stream — Wikipedia — https://en.wikipedia.org/wiki/Value_stream
3. Objectives and key results (OKRs) — Wikipedia — https://en.wikipedia.org/wiki/Objectives_and_key_results
4. Responsibility assignment matrix (RACI) — Wikipedia — https://en.wikipedia.org/wiki/Responsibility_assignment_matrix
5. Vendor lock-in — Wikipedia — https://en.wikipedia.org/wiki/Vendor_lock-in
6. Government Digital Service — Wikipedia — https://en.wikipedia.org/wiki/Government_Digital_Service
7. Fast Healthcare Interoperability Resources (HL7 FHIR) — Wikipedia — https://en.wikipedia.org/wiki/Fast_Healthcare_Interoperability_Resources
8. SNOMED CT — Wikipedia — https://en.wikipedia.org/wiki/SNOMED_CT
9. Team Topologies: Organizing Business and Technology Teams for Fast Flow — Matthew Skelton & Manuel Pais, IT Revolution — https://teamtopologies.com/book
10. Spend controls and staged assurance (discovery/alpha/beta/live) — GOV.UK Service Manual, Government Digital Service — https://www.gov.uk/service-manual/agile-delivery
11. NHS service standard — NHS digital service manual, NHS England — https://service-manual.nhs.uk/standards-and-technology/service-standard
12. Managing Successful Programmes (MSP) and Management of Portfolios (MoP) — AXELOS/PeopleCert — https://www.axelos.com/
13. Measure What Matters (OKRs) — John Doerr — https://www.whatmatters.com/the-book