Tópico 3.5 — Ciclos de vida de entrega

Em uma frase: Um ciclo de vida de entrega é a sequência de fases e barreiras decisórias — Descoberta, Alfa, Beta, Produção (Live) e a eventual desativação — pelas quais um serviço digital passa, com a segurança clínica, a governança da informação e a garantia entrelaçadas a cada fase, e não acrescentadas no final.

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

Um ciclo de vida é como uma organização converte uma ideia num serviço seguro em produção e, por fim, o desativa com responsabilidade. Na saúde e nos cuidados, cada transição carrega peso estatutário e clínico: não se pode implantar um sistema que toca o cuidado do paciente sem um caso de segurança clínica, nem tratar dados confidenciais de pacientes sem uma base legal e uma avaliação de impacto sobre a proteção de dados (DPIA) concluída. Um ciclo de vida que trata isso como papelada de fim de projeto produz serviços atrasados, inseguros ou ambos.

O que está em jogo é assimétrico. Um aplicativo de consumo que entrega um erro irrita os usuários; um prontuário de cuidados compartilhado que entrega um erro pode mostrar a um clínico as alergias do paciente errado. É por isso que o NHS incorpora o modelo de fases do GOV.UK e as normas de gestão de riscos clínicos DCB0129 e DCB0160 ao mesmo ciclo de vida. Acertar o ciclo de vida não é uma sutileza de governança — é o mecanismo pelo qual a segurança, a equidade e a relação custo-benefício do dinheiro público são de fato entregues, e não meramente prometidas.

Os líderes também precisam do ciclo de vida porque ele torna o progresso legível. Fases e barreiras nomeadas permitem a um conselho ver onde está um serviço, que evidência existe e que decisão está por vir — substituindo a névoa do "está quase pronto" por um compromisso defensável e escalonado de dinheiro público.

Conceitos centrais#

O modelo de fases: Descoberta → Alfa → Beta → Produção. Os padrões de serviço do NHS e do GOV.UK definem quatro fases. A Descoberta (ver Tópico 3.4 — Fases de descoberta) entende o problema. A Alfa constrói protótipos descartáveis para testar se uma solução poderia funcionar e reduzir as suposições mais arriscadas. A Beta constrói o serviço real, privado e depois público, em infraestrutura de produção, iterando com usuários reais em escala crescente. A Produção (Live) opera o serviço em funcionamento contínuo, ainda iterando, até que ele seja desativado. As fases são uma rampa de redução de risco: cada uma compromete mais dinheiro e expõe mais usuários, justificada pela evidência da anterior.

Iteração contínua, e não esteira. As fases não são uma cascata de mão única. Um serviço em beta pode voltar à alfa para uma funcionalidade difícil; um serviço em produção itera continuamente. O valor do modelo está nas suas barreiras, e não numa promessa de que o trabalho flui numa só direção.

Ágil, cascata e híbrido. A cascata fixa o escopo de antemão e avança em sequência — adequada apenas onde os requisitos são genuinamente estáveis e cognoscíveis (uma migração de data center, uma mudança regulatória obrigatória). O ágil entrega em pequenos incrementos, inspecionando e adaptando — adequado à incerteza dos serviços voltados ao usuário. O híbrido é a realidade honesta da maioria dos grandes programas de saúde: equipes de produto ágeis operando dentro de um envoltório de marcos e financiamento que a organização e seus reguladores exigem. Ajuste o método à incerteza, e não à moda.

Avaliações de serviço e barreiras de padrões. Nas transições entre fases — especialmente de alfa para beta e antes do lançamento público —, os serviços do NHS e do GOV.UK enfrentam uma avaliação de serviço: um painel independente que testa o trabalho frente aos pontos do Service Standard (necessidade do usuário, acessibilidade, segurança, confiabilidade, equipe, escolhas de tecnologia). Passar é a barreira para gastar mais e expor mais usuários. A avaliação é uma revisão por pares baseada em evidências, e não um carimbo.

Segurança clínica e governança da informação como fios do ciclo de vida. A DCB0129 (para o fabricante/fornecedor) e a DCB0160 (para a organização de saúde ou de cuidados que implanta) exigem um sistema de gestão de riscos clínicos, um registro de perigos e um relatório de caso de segurança clínica aprovado por um Responsável pela Segurança Clínica (CSO) nomeado e treinado. A governança da informação exige uma base legal, uma DPIA e a observância dos Princípios de Caldicott. Ambos são fios que atravessam a descoberta, a alfa, a beta e a produção — e não barreiras no final.

Desativação. Um ciclo de vida tem um fim. Desativar um serviço com segurança — migrar ou arquivar dados sob a lei de retenção, redirecionar usuários, notificar clínicos e preservar registros — é uma fase por si só e uma das mais negligenciadas.

Boas práticas#

1. Use as fases como barreiras de redução de risco, e não como marcos de calendário. Faça com que a decisão de cada fase seja "há evidência suficiente para justificar o compromisso da próxima parcela de dinheiro e de usuários?". Uma fase que termina porque a data chegou, e não porque a evidência chegou, pulou o sentido da barreira.

2. Entrelace a segurança clínica a partir da alfa, e não antes da produção. Nomeie um Responsável pela Segurança Clínica e abra o registro de perigos assim que existir uma forma de solução. Os perigos identificados na alfa são baratos de eliminar no projeto; os perigos encontrados na entrada em produção são uma crise que bloqueia o lançamento. O caso de segurança amadurece junto com o serviço, de modo que a aprovação DCB0129/0160 é um resumo do trabalho já feito, e não uma correria.

3. Inicie a DPIA e o trabalho de governança da informação na descoberta e mantenha-os vivos. Fluxos de dados, base legal e considerações de Caldicott moldam a arquitetura; portanto, traga-os à tona enquanto a arquitetura ainda é maleável. Uma DPIA escrita depois da construção é um exercício de documentação; uma escrita junto com o projeto de fato reduz o risco e evita retrabalho.

4. Automatize o caminho até a produção com CI/CD e DevOps. A integração contínua e a entrega contínua — esteiras automatizadas de construção, teste e implantação — permitem a uma equipe entregar mudanças pequenas e reversíveis com segurança e com frequência. Num domínio crítico para a segurança, a capacidade de implantar uma correção em minutos e reverter limpamente é, em si, um controle de segurança. Combine-a com monitoramento, alertas e infraestrutura como código, para que o serviço em produção seja observável e reprodutível.

5. Ajuste o método à incerteza. Use o ágil onde as necessidades dos usuários são incertas e a descoberta ainda está ensinando coisas; aceite sequenciamento ao estilo cascata apenas onde os requisitos são genuinamente fixos e o risco de mudança é baixo. Seja explícito ao conduzir um híbrido — equipes ágeis dentro de um envoltório de programa — em vez de fingir que um método governa tudo, o que não engana ninguém e frustra todos.

6. Trate a avaliação de serviço como uma ferramenta de design, e não como uma prova. Traga revisores de garantia, segurança clínica, segurança e acessibilidade cedo e com frequência, para que a avaliação formal confirme um serviço já construído conforme o padrão. As equipes que encontram o padrão pela primeira vez na semana anterior à avaliação fracassam de forma lenta e cara; as que o internalizam passam como subproduto.

7. Continue iterando na produção — e dê-lhe recursos. Um serviço não deixa de precisar de uma equipe ao entrar em produção. A produção é onde o uso real expõe as últimas iniquidades, os casos clínicos extremos raros, porém graves, e as lacunas de acessibilidade. Financie uma equipe de produto permanente durante a vida operacional do serviço (ver Tópico 5.0 — Trabalho conduzido por produto); um serviço em produção sem equipe é dívida técnica acumulando risco clínico.

8. Planeje a desativação antes de precisar dela. Decida, durante a construção, como o serviço será eventualmente desativado: retenção e migração de dados sob a lei de gestão de registros, redirecionamento de usuários, notificação de clínicos e arquivamento do caso de segurança clínica e da trilha de auditoria. Uma desativação não planejada deixa dados e usuários encalhados; uma planejada é uma fase controlada e auditável.

Perguntas para discutir com a sua equipe#

1. Nossas barreiras de fase são genuinamente governadas por evidências, ou silenciosamente viraram datas num plano? Todo o valor do modelo Descoberta–Alfa–Beta–Produção é que cada transição compromete mais dinheiro e expõe mais usuários apenas quando a evidência da fase anterior o justifica; no momento em que uma barreira dispara porque o trimestre acabou e não porque a evidência chegou, a rampa deixa de reduzir risco e vira "cascata fantasiada de ágil". Esta pergunta pede à equipe que olhe com honestidade para suas últimas transições e pergunte o que teria acontecido se a evidência tivesse dito "ainda não" — havia espaço para segurar, devolver uma beta à alfa para uma funcionalidade difícil, ou a data de entrada em produção era politicamente inamovível? A tensão a debater é entre a necessidade da organização de marcos legíveis e agendados pelo conselho e a realidade de que os serviços seguros se movem no ritmo da evidência; a entrega híbrida vive precisamente nesse atrito. Ângulos concretos incluem nomear a decisão e a evidência específicas devidas na próxima barreira, verificar se os "sprints" de fato mudam o escopo ou apenas acompanham um plano fixo e perguntar quem tem poder para atrasar uma barreira sem risco de carreira. Uma boa resposta consegue apontar um caso real em que a evidência mudou o plano e articular que evidência justificaria — ou bloquearia — o próximo compromisso de dinheiro público e de usuários.

2. A segurança clínica e a governança da informação são fios vivos em todas as fases, ou papelada que pretendemos terminar antes da produção? Na saúde e nos cuidados, a DPIA e o trabalho de riscos clínicos DCB0129/0160 não são aprovações de fim de projeto, mas fios que devem moldar a arquitetura e o projeto a partir da alfa, porque um perigo eliminado no projeto cedo é barato, ao passo que um descoberto na entrada em produção é uma crise que bloqueia o lançamento — ou, pior, uma pressão para deixar passar o caso de segurança. Esta pergunta traz à tona se existem um Responsável pela Segurança Clínica nomeado e treinado e um registro de perigos aberto assim que surge uma forma de solução, e se a DPIA e a análise da base legal começaram na descoberta, enquanto os fluxos de dados ainda eram maleáveis o bastante para mudar. A concessão que vale debater é o arrasto sentido de fazer isso continuamente versus o custo e o risco clínico muito maiores de um retrofit, especialmente para equipes menores ou startups, onde nenhum regulador ainda observa, mas a obrigação da DCB0129 recai sobre o fabricante independentemente. Considerem evidências concretas: o registro de perigos mostra perigos encontrados e mitigados na alfa, o caso de segurança se lê como um resumo do trabalho já feito e a DPIA se rastreia a decisões de projeto reais? Uma resposta honesta distingue uma equipe que amadurece o seu caso de segurança junto com o serviço de outra que caminha para uma correria de documentação no mês anterior ao lançamento.

3. Como este serviço será operado em produção e, por fim, desativado — e quem é financiado para fazê-lo? Os ciclos de vida têm uma longa cauda que as organizações rotineiramente subfinanciam: a produção é onde o uso real expõe as últimas iniquidades, os casos clínicos extremos raros, porém graves, e as lacunas de acessibilidade, e precisa de uma equipe de produto permanente, monitoramento e implantação rápida e reversível, e não de uma equipe que se dissolve na entrada em produção, deixando o serviço apodrecer e acumular risco clínico em silêncio. Igualmente negligenciada é a desativação — desativar um serviço sob a lei de retenção de registros, migrar ou arquivar dados, redirecionar usuários, notificar clínicos e preservar o registro de perigos e a trilha de auditoria — que, para um sistema nacional, é um grande programa por si só, e não uma reflexão tardia quando o substituto chega. A tensão a debater são os ciclos anuais de financiamento e a pressão para declarar um projeto "concluído" no lançamento versus a propriedade ao longo de toda a vida que um serviço seguro realmente exige. Ângulos úteis incluem se uma esteira de CI/CD com monitoramento e reversão rápida é tratada como um controle de segurança em produção, se um orçamento de plantão e de iteração sobrevive à celebração da entrada em produção e se um plano de saída foi escrito durante a construção, em vez de improvisado em pânico. Uma boa resposta nomeia quem responde pelo serviço durante a sua vida operacional e descreve uma desativação controlada e auditável, e não a esperança de que alguém cuide disso depois.

4. Quando foi a última vez que deixamos o fracasso de um protótipo nos fazer parar — e ainda construímos coisas para jogar fora? A alfa existe para reduzir as suposições mais arriscadas de forma barata, o que significa que um protótipo descartável que fracassa cumpriu o seu papel: comprou uma lição custosa antes de comprometer dinheiro de produção e pacientes reais. Esta pergunta sonda se uma equipe de fato trata a alfa como aprendizado descartável ou silenciosamente escorregou para polir o primeiro protótipo até virar o produto final porque descartar código parece desperdício — a armadilha do custo irrecuperável que transforma uma fase de redução de risco num compromisso caro assumido às cegas. A tensão que vale trazer à tona é a pressão de "ter algo a mostrar" e reaproveitar cada linha escrita contra a disciplina de provar que uma solução poderia funcionar antes de construir a real em infraestrutura de produção. Ângulos concretos incluem perguntar que suposições a última alfa de fato testou, se algum protótipo já foi abandonado com base na evidência e se a construção da beta privada reaproveitou código descartável que deveria ter sido reescrito em padrão de produção. Uma resposta honesta consegue apontar uma suposição específica que um protótipo matou ou confirmou e distinguir os artefatos de aprendizado que a equipe aceitou descartar do código assegurado que hoje roda em produção.

5. Conduzimos um único híbrido honesto, ou vários métodos disfarçados que silenciosamente se contradizem? A maioria dos grandes programas de saúde é genuinamente híbrida — equipes de produto ágeis operando dentro de um envoltório de marcos e financiamento que a organização e seus reguladores exigem —, e a falha não é o híbrido em si, mas fingir que é ágil puro ou cascata pura, de modo que as duas lógicas colidem sem gestão a cada barreira. Esta pergunta pede à equipe que nomeie onde ficam de fato os compromissos fixos e sequenciados (parcelas de financiamento, marcos regulatórios, congelamentos de integração) e onde acontece a iteração genuína, em vez de deixar que o "ágil" e o "plano" reivindiquem, cada um, o programa inteiro e frustrem a todos. A concessão a debater é a necessidade legítima da organização de marcos previsíveis e gastos auditáveis versus a necessidade da equipe de entrega de mudar o escopo com base em evidências, e a atitude honesta é tornar as costuras explícitas para que ambos possam ser planejados em torno delas. Ângulos úteis incluem se a repriorização do backlog alguma vez sobrevive ao contato com o plano do programa, se os fornecedores são contratados por escopo fixo enquanto se pede que trabalhem de forma iterativa e se os relatórios que o conselho vê correspondem ao modo como o trabalho é realmente feito. Uma boa resposta descreve um híbrido deliberadamente projetado, com pontos fixos nomeados e espaços flexíveis nomeados, e não uma confusão em que um método é reivindicado para as aparências.

6. Quão bem sabemos o que um serviço em produção está de fato fazendo com seus usuários neste momento — e perceberíamos o dano antes que eles o relatassem? Um serviço de saúde em produção é tão seguro quanto sua observabilidade: monitoramento, alertas e os instintos de segurança clínica que transformam uma métrica em perigo marcam a diferença entre pegar um defeito de dados obsoletos em minutos e saber dele por um relatório de incidente semanas depois. Esta pergunta examina se a equipe consegue ver o serviço em produção — taxas de erro, falhas de integração, abandono por acessibilidade, as lacunas de equidade que só o uso real revela — e se alguém observa os painéis com o risco clínico em mente, e não apenas o tempo de atividade da infraestrutura. A tensão é o custo e a disciplina de uma observabilidade e de um plantão adequados versus a suposição silenciosa de que "sem notícias, boas notícias" depois que um serviço entra em produção, o que, num domínio crítico para a segurança, é como o dano silencioso se acumula. Ângulos concretos incluem se o registro de perigos é atualizado com incidentes em produção, se os alertas correspondem ao impacto clínico e não apenas à saúde do servidor e se uma versão ruim pode ser detectada e revertida antes de chegar a muitos pacientes. Uma resposta honesta descreve sinais específicos que a equipe observa, um incidente real que o monitoramento pegou (ou deixou passar) e como a evidência em produção retroalimenta a próxima iteração.

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

Um hospital comunitário do NHS está substituindo um sistema legado de papel e planilha para agendar as visitas de enfermeiras distritais. Saindo da descoberta (Tópico 3.4), a equipe entra na alfa e constrói dois protótipos descartáveis para testar as suposições mais arriscadas: que as enfermeiras usarão um telefone nas casas dos pacientes e que o agendamento pode se integrar ao prontuário eletrônico do paciente. Um Responsável pela Segurança Clínica é nomeado no primeiro dia da alfa e abre um registro de perigos; um perigo inicial — uma agenda obsoleta mostrando uma visita já concluída por uma colega — conduz a uma decisão de projeto de mostrar o estado de sincronização em tempo real. A DPIA, iniciada na descoberta, sinaliza que os dados de localização dos trabalhadores isolados precisam de uma base legal definida e de um limite de retenção.

Na avaliação de serviço de alfa para beta, um painel independente sonda a acessibilidade (enfermeiras com deficiência visual), a segurança e o raciocínio da equipe. O serviço passa com ações. Na beta privada, dez enfermeiras usam o sistema real em infraestrutura de produção; uma esteira de CI/CD permite à equipe entregar diariamente e reverter uma versão ruim em menos de dez minutos. O uso revela uma questão de equidade — equipe temporária sem dispositivos do hospital —, o que leva a uma alternativa baseada em navegador. A beta pública escala para três localidades; o relatório do caso de segurança clínica é concluído e aprovado sob a DCB0160 antes da implantação mais ampla.

O serviço entra em Produção com uma equipe de produto permanente, painéis de monitoramento e uma escala de plantão. Dezoito meses depois, quando o hospital adota uma plataforma regional, o agendamento é desativado conforme o plano: dados migrados sob o cronograma de retenção, enfermeiras retreinadas e redirecionadas, e o registro de perigos e o caso de segurança arquivados para auditoria. Cada transição foi uma decisão amparada por evidências, e não uma data num gráfico de Gantt.

Perspectivas setoriais#

Startup#

O ciclo de vida de uma startup é comprimido e em grande parte autogovernado: não há painel independente de avaliação de serviço; assim, a disciplina das barreiras Alfa–Beta–Produção precisa ser autoimposta ou colapsa em "entregar continuamente e esperar". A vantagem é que uma pequena equipe pode rodar CI/CD de verdade desde o primeiro dia e iterar mais depressa do que qualquer grande organização. O perigo é abandonar silenciosamente os fios de segurança clínica e de DPIA porque nenhum regulador ainda observa — um erro fatal na saúde, em que as obrigações da DCB0129 recaem sobre o fabricante independentemente do porte da empresa, e um único perigo não gerido pode acabar com o produto e com a empresa. As startups devem adotar a intenção do modelo de fases — evidência antes da exposição — mesmo sem a cerimônia, nomeando um Responsável pela Segurança Clínica (muitas vezes fracionado) assim que existir uma forma de solução.

Pequena empresa#

Um pequeno prestador estabelecido — um consultório de clínica geral, uma farmácia comunitária, uma casa de repouso ou uma clínica de unidade única — geralmente encontra o ciclo de vida como implantador, e não como construtor: está adquirindo ou configurando o sistema de um fornecedor; assim, a aprovação de implantação DCB0160 e uma DPIA local recaem sobre ele, mesmo sem equipe digital interna. As fases ainda se aplicam, mas comprimidas e terceirizadas: a "alfa" é um piloto supervisionado com alguns pacientes reais, a "beta" é uma implantação escalonada por todo o consultório e a produção é a rotina, com as atualizações do fornecedor chegando continuamente e em grande parte fora do controle do consultório. A organização deve nomear um Responsável pela Segurança Clínica (muitas vezes um sócio clínico que assume o papel além do trabalho diário) e manter um registro de perigos para o modo como o sistema é usado localmente, porque o trabalho DCB0129 do fabricante não cobre os riscos específicos da implantação. Com caixa apertado e sem TI dedicada, a disciplina realista é apoiar-se na garantia do fornecedor enquanto assume as poucas decisões que só o conhecimento local pode tomar — quem é treinado, qual é o recurso quando o sistema está fora do ar e como os dados dos pacientes fluem neste ambiente específico.

Grande organização#

Um hospital do NHS ou um grande fornecedor conduz o ciclo de vida em sua forma mais plena e assegurada: avaliações formais de serviço, um Responsável pela Segurança Clínica nomeado, aprovação de implantação DCB0160, conselhos consultivos de mudança e um ciclo anual de financiamento dentro do qual o trabalho ágil precisa caber. O desafio característico é o híbrido — equipes de entrega ágeis operando dentro de um envoltório de programa e marcos que a organização e seus auditores exigem — e a falha clássica é a "cascata fantasiada de ágil", em que as barreiras silenciosamente viram datas de calendário. As grandes organizações têm os recursos para fazer bem CI/CD, observabilidade e equipes de produto permanentes, mas a inércia organizacional e a integração com sistemas legados muitas vezes reduzem a implantação a um arrastar. A responsabilização é ampla e o raio de impacto é grande; assim, a rampa escalonada da beta privada à produção não é prudência opcional, mas controle de risco essencial.

Governo#

Um órgão nacional entrega sob todo o Service Standard, avaliações de serviço publicadas, controles de gastos e escrutínio parlamentar; assim, cada barreira de fase é também um ponto de responsabilização pública. Os ciclos de vida aqui são longos e a exposição é vasta — um serviço em produção em todo o NHS pode tocar milhões —, o que eleva o que está em jogo na rampa escalonada, na garantia de segurança clínica e na desativação dos sistemas legados que estão sendo substituídos. As regras de aquisição e os acordos de financiamento plurianuais moldam o que "ágil" pode significar na prática, e desativar um sistema nacional (com décadas de registros e deveres estatutários de retenção) é um grande programa por si só. A concessão é garantia versus velocidade: a entrega governamental é fortemente controlada por barreiras, o que protege a segurança e o dinheiro público, mas exige esforço deliberado para manter as equipes iterando em vez de reverter ao grande projeto antecipado.

Modos de falha comuns#

• Cascata fantasiada de ágil. A equipe roda "sprints", mas escopo, datas e projeto foram todos fixados de antemão; a iteração é teatro. Antídoto: deixar que a evidência em cada barreira genuinamente mude o plano.
• Segurança e governança da informação acrescentadas no fim. O caso de segurança clínica e a DPIA são escritos no mês anterior à entrada em produção, bloqueando o lançamento ou, pior, sendo deixados passar sob pressão. Antídoto: abrir o registro de perigos e a DPIA na alfa e amadurecê-los continuamente.
• O lançamento em big-bang. O serviço pula a beta privada/pública e vai direto à implantação completa, expondo todos os usuários a software não comprovado. Antídoto: usar a rampa escalonada; aumentar a exposição com evidência.
• O serviço em produção abandonado. A equipe de entrega se dissolve na entrada em produção; o serviço apodrece e o risco clínico se acumula em silêncio. Antídoto: financiar uma equipe de produto permanente durante a vida operacional.
• Avaliação decorada. Os padrões são ignorados até a avaliação se aproximar e depois atendidos superficialmente. Antídoto: envolver continuamente a garantia e os revisores clínicos.
• Sem plano de saída. O serviço é desativado em pânico quando o substituto chega, deixando dados e usuários encalhados. Antídoto: planejar a desativação como fase de primeira ordem.

Modelo de maturidade#

Lista de verificação#

• O serviço tem uma fase atual explícita (Descoberta / Alfa / Beta / Produção) e uma próxima decisão nomeada.
• As transições de fase são condicionadas por evidência, e não por datas.
• Um Responsável pela Segurança Clínica está nomeado e um registro de perigos está aberto (DCB0129/0160) desde a alfa.
• Uma DPIA e uma avaliação da base legal (Caldicott, UK GDPR) começaram na descoberta e são mantidas atuais.
• O método de entrega é ajustado ao nível de incerteza, e qualquer arranjo híbrido é explícito.
• As avaliações de serviço estão planejadas, e os revisores de garantia/segurança/acessibilidade são envolvidos cedo.
• Uma esteira de CI/CD com monitoramento e reversão rápida está em vigor antes da beta pública.
• O serviço é exposto aos usuários numa rampa escalonada (beta privada → beta pública → produção), e não em big-bang.
• Uma equipe de produto permanente é financiada durante a vida operacional do serviço (ver Tópico 5.0).
• Um plano de desativação cobre retenção/migração de dados, redirecionamento de usuários e arquivamento dos registros de segurança e de auditoria.

Fontes-chave#

• GOV.UK Service Manual — as fases de um projeto ágil (Descoberta, Alfa, Beta, Produção) e o Government Service Standard.
• NHS England — NHS Service Standard e NHS Digital Service Manual; avaliações de serviço do NHS.
• NHS England Digital — DCB0129 (Clinical Risk Management: its Application in the Manufacture of Health IT Systems) e DCB0160 (its Application in the Deployment and Use of Health IT Systems).
• NHS England — garantia digital de segurança clínica; o papel de Responsável pela Segurança Clínica, o registro de perigos e o relatório do caso de segurança clínica.
• NHS England — Digital Technology Assessment Criteria (DTAC).
• Princípios de Caldicott do Reino Unido; Data Protection Act 2018 / UK GDPR e avaliações de impacto sobre a proteção de dados.
• NICE — Evidence Standards Framework for Digital Health Technologies.
• Prática de DevOps e entrega contínua (p. ex., as capacidades DORA: integração contínua, automação de implantação, monitoramento); orientações do GOV.UK Service Manual sobre entrega contínua e operação de um serviço.

Referências#

1. Systems development life cycle — Wikipedia — https://en.wikipedia.org/wiki/Systems_development_life_cycle
2. Waterfall model — Wikipedia — https://en.wikipedia.org/wiki/Waterfall_model
3. Agile software development — Wikipedia — https://en.wikipedia.org/wiki/Agile_software_development
4. Software prototyping — Wikipedia — https://en.wikipedia.org/wiki/Software_prototyping
5. CI/CD — Wikipedia — https://en.wikipedia.org/wiki/CI/CD
6. Continuous integration — Wikipedia — https://en.wikipedia.org/wiki/Continuous_integration
7. Continuous delivery — Wikipedia — https://en.wikipedia.org/wiki/Continuous_delivery
8. DevOps — Wikipedia — https://en.wikipedia.org/wiki/DevOps
9. Infrastructure as Code — Wikipedia — https://en.wikipedia.org/wiki/Infrastructure_as_code
10. Observability (software) — Wikipedia — https://en.wikipedia.org/wiki/Observability_(software)
11. Privacy impact assessment (data protection impact assessment) — Wikipedia — https://en.wikipedia.org/wiki/Privacy_impact_assessment
12. Agile delivery: the phases of an agile project — Government Digital Service, GOV.UK Service Manual — https://www.gov.uk/service-manual/agile-delivery
13. NHS service standard and NHS digital service manual — NHS England — https://service-manual.nhs.uk/
14. Clinical risk management standards DCB0129 and DCB0160 — NHS England (Clinical Safety) — https://digital.nhs.uk/services/clinical-safety
15. DevOps Research and Assessment (DORA) capabilities — Google Cloud / DORA — https://dora.dev/
16. Continuous delivery — Jez Humble and David Farley — https://continuousdelivery.com/
17. Data protection impact assessments (DPIAs) — Information Commissioner's Office (ICO) — https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/accountability-and-governance/data-protection-impact-assessments-dpias/
18. Evidence standards framework for digital health technologies — NICE — https://www.nice.org.uk/about/what-we-do/digital-health