Tópico 1.0 — Modos de trabalho em saúde e cuidados digitais

Em uma frase: Modos de trabalho são os hábitos deliberados e compartilhados — como você organiza equipes, toma decisões, gere riscos e entrega valor — que permitem a uma organização de saúde e cuidados transformar intenção em resultados seguros, equitativos e baseados em evidências para pacientes e cidadãos.

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

Toda organização tem modos de trabalho, escolhidos ou herdados. Na saúde e nos cuidados digitais, os que você herda costumam ser inadequados para a tarefa: foram construídos para projetos de estilo construção civil, com escopo fixo, e não para serviços adaptativos que tocam a segurança clínica, o dever legal e o dinheiro público. Acertá-los não é um luxo de retaguarda; é a diferença entre um prontuário compartilhado em que os clínicos confiam e outro que fica sem uso.

A saúde e os cuidados têm particularidades que moldam todas as práticas deste livro. A segurança é inegociável — um defeito num serviço digital pode causar danos a um paciente, de modo que a gestão do risco clínico (ver Tópico 1.6 — Segurança clínica e gestão de riscos) está entrelaçada com a entrega, e não acrescentada depois. A equidade importa porque um serviço que só funciona para quem tem confiança digital amplia as desigualdades em saúde; as populações Core20PLUS5 e as pessoas com acesso digital limitado devem ser contempladas no desenho, e não excluídas dele. Os deveres legais — o compromisso do NHS com o cuidado abrangente, a lei de proteção de dados, o dever de confidencialidade — restringem o que você pode fazer com os dados e como deve realizar consultas. O dinheiro público exige controle de gastos proporcional e valor demonstrável. E quase nada é entregue por um único órgão: a parceria entre sistemas de cuidados integrados (ICS), autoridades locais, prestadores de cuidados sociais e fornecedores é a condição normal de operação.

Essas quatro pressões — segurança, equidade, dever, dinheiro — são o motivo pelo qual não se pode simplesmente copiar um manual de tecnologia de consumo. É preciso ter modos de trabalho que sejam ágeis e responsáveis, rápidos e seguros, centrados no usuário e justos para a população.

Conceitos centrais#

Os modos de trabalho operam em três níveis. No nível da equipe, são as práticas diárias: reuniões diárias, pesquisa com usuários, entrega iterativa, trabalho em dupla. No nível organizacional, são o modelo operacional — como a estratégia se transforma em fluxos de valor, capacidades, financiamento e direitos de decisão (ver Tópico 1.1 — O modelo operacional). No nível do sistema, são a forma como organizações independentes se alinham: padrões compartilhados, interoperabilidade e governança comum em todo um ICS. Este livro percorre deliberadamente os três.

O design centrado no usuário significa partir das necessidades das pessoas que usam um serviço — pacientes, cuidadores, clínicos, administradores — em vez de partir de uma solução presumida. O Government Digital Service (GDS) do Reino Unido e o NHS codificaram isso em padrões de serviço: entenda os usuários e suas necessidades antes de construir e continue testando com usuários reais ao longo de todo o processo.

A entrega ágil e iterativa significa colocar um serviço funcional diante de usuários reais cedo, aprender e adaptar-se — em vez de especificar tudo de antemão. O manual de serviço digital do NHS é explícito: modos de trabalho ágeis e centrados no usuário reduzem o risco de construir a coisa errada. O ágil, aqui, é tanto uma estratégia de gestão de riscos quanto um método de entrega.

As equipes multidisciplinares (MDTs) reúnem, numa única equipe com autonomia, a combinação de competências de que um serviço precisa: gestão de produto e de entrega, pesquisa e design com usuários, engenharia, conhecimento clínico e de governança da informação, e conhecimento operacional. O padrão de serviço do NHS exige equipes que incluam competências e perspectivas multidisciplinares — inclusive acesso a contribuições clínicas, jurídicas ou de políticas especializadas. A MDT é o átomo da entrega digital; a maioria dos fracassos remonta a uma disciplina ausente da mesa.

Produto em vez de projeto. Um projeto tem início, fim e passagem de bastão; um produto é financiado e cuidado ao longo de toda a sua vida. A mudança do pensamento de projeto para o de produto (ver Tópico 1.1 e Tópico 5.0 — Trabalho conduzido por produto) altera o financiamento, as equipes e a responsabilização, e combina muito melhor com os serviços de saúde — que são duradouros e estão em evolução contínua — do que projetos isolados.

Boas práticas#

1. Parta das necessidades dos usuários, comprovadas por pesquisa. Antes de se comprometer com uma construção, entenda quem são os usuários, o que tentam fazer e onde o serviço atual falha com eles. Financie uma descoberta (ver Tópico 3.4 — Fases de descoberta) e trate "nós presumimos" como sinal de alerta. As necessidades dos usuários, e não as preferências internas, são a âncora de toda decisão posterior.

2. Construa equipes multidisciplinares, com autonomia e estáveis. Reúna toda a combinação de competências — incluindo segurança clínica e governança da informação — e dê à equipe autoridade para decidir dentro de limites claros. Mantenha as equipes juntas em torno de um serviço, em vez de dissolvê-las a cada fronteira de projeto; equipes estáveis acumulam o conhecimento de domínio e de segurança que os serviços de saúde exigem.

3. Trabalhe às claras e itere em pequenos passos. Entregue fatias finas, meça e ajuste. Lançamentos pequenos e frequentes são mais seguros do que lançamentos "big-bang", porque os problemas aparecem enquanto ainda são pequenos, e permitem que a revisão de segurança clínica e de governança da informação acompanhe a mudança, em vez de virar uma barreira no final.

4. Torne a segurança e a equidade prioridades desde o primeiro dia. Conduza a gestão de riscos clínicos (DCB0129/DCB0160) e a análise de igualdade e de desigualdades em saúde em paralelo à entrega, e não como aprovações de fim de etapa. Pergunte cedo quem poderia ser excluído ou prejudicado e projete para os casos mais difíceis — canais digitais assistidos, acessibilidade (WCAG) e alternativas offline.

5. Decida com base em evidências e registre a decisão. Distinga a evidência clínica (funciona e é seguro?) da evidência de entrega (estamos construindo bem e sendo usados?) e mantenha um registro leve de decisões para que o raciocínio sobreviva à rotatividade de pessoal (ver Tópico 1.3 — Decisões baseadas em evidências). A evidência vence a opinião da pessoa mais bem paga.

6. Projete para a interoperabilidade e a reutilização. Os dados de saúde e cuidados precisam circular com segurança entre organizações; construa sobre padrões abertos (HL7 FHIR, SNOMED CT) e reutilize plataformas em vez de reinventá-las (ver a "plataforma mínima viável" do Tópico 1.1 e o Tópico 4.3 — Interoperabilidade e padrões de dados). Um serviço que não consegue compartilhar dados é um silo à espera de virar um risco.

7. Governe de forma proporcional. Ajuste o peso da garantia ao nível de risco. Mudanças clínicas de alto risco merecem escrutínio profundo; mudanças de conteúdo de baixo risco não devem esperar semanas por um conselho. A governança proporcional mantém você seguro e rápido ao mesmo tempo.

8. Trabalhe às claras. Compartilhe planos, decisões, roteiros e — quando for seguro — código, para que parceiros, clínicos e o público vejam como e por que as escolhas são feitas. A abertura gera confiança, reduz a duplicação num sistema fragmentado e convida ao questionamento antes que os erros se cristalizem em serviços em produção. Na saúde e nos cuidados, ser transparente sobre o que um serviço faz com os dados, e por quê, é em si uma prática de confiança e de segurança.

9. Projete para o longo prazo e para a passagem de bastão. Os serviços digitais de saúde sobrevivem às equipes e aos contratos que os constroem; por isso registre as decisões, evite o conhecimento "heroico" não documentado e projete para as pessoas que operarão e alterarão o serviço durante anos (ver Tópico 10.3 — Gestão do conhecimento e documentação). Trate a sustentabilidade — da equipe, da tecnologia e do modelo de financiamento — como uma restrição de primeira ordem, e não como uma reflexão tardia.

Perguntas para discutir com a sua equipe#

1. Onde os nossos modos de trabalho atuais são herdados e não escolhidos, e qual hábito herdado nos custa mais em segurança, equidade ou gasto desperdiçado? Esta pergunta obriga a uma auditoria honesta das práticas que ninguém decidiu, mas que todos seguem — financiamento de programas com escopo fixo, equipes de projeto que se dissolvem e se reconstroem, governança consultada apenas na entrada em produção. Importa porque os hábitos herdados costumam ser invisíveis até serem nomeados e, na saúde e nos cuidados, têm custo real: um prontuário compartilhado em que os clínicos não confiam, um serviço que exclui as populações Core20PLUS5 ou a reconstrução, com dinheiro público, da mesma infraestrutura de login. A tensão a debater é que os modos herdados muitas vezes parecem seguros justamente por serem familiares e auditáveis, de modo que abandoná-los parece assumir risco em vez de removê-lo. Baseie a discussão em artefatos concretos — examine os seus três últimos casos de negócio, a rotatividade das equipes entre projetos e o momento em que a segurança clínica foi envolvida pela primeira vez — em vez de trocar opiniões. Uma boa resposta nomeia um ou dois hábitos específicos com evidências do seu custo, distingue os que vale a pena manter dos que prejudicam ativamente os resultados e se compromete com uma mudança pela qual um líder sênior responderá.

2. As nossas equipes têm de fato a combinação completa de competências multidisciplinares — incluindo segurança clínica e governança da informação — dentro da equipe, ou essas disciplinas ainda são acrescentadas como barreiras de fim de etapa? O tópico defende que a MDT é o átomo da entrega digital e que a maioria dos fracassos remonta a uma disciplina ausente da mesa; esta pergunta testa se esse princípio é real na sua organização ou apenas aspiracional. Importa porque um responsável pela segurança clínica ou um Caldicott Guardian envolvido só na entrada em produção força retrabalho ou atalhos inseguros, ao passo que um incorporado desde a primeira semana mantém um registro de perigos vivo que dá o ritmo da entrega. A concessão que vale trazer à tona é o custo e a escassez: o tempo de especialistas clínicos, jurídicos e de governança da informação é realmente limitado, de modo que "incorporar todos em todas as equipes" colide com restrições reais de recursos, e a equipe precisa decidir onde papéis fracionados ou compartilhados são aceitáveis e onde não são. Examine um serviço atual e mapeie quem está de fato na equipe permanente e quem é consultado como aprovação externa, e verifique se a equipe tem autoridade para decidir dentro dos limites ou precisa escalar constantemente. Uma boa resposta, honesta, é específica sobre quais disciplinas faltam ou são emprestadas, reconhece com franqueza a tensão de recursos e propõe um modelo concreto — tempo integral, fracionado ou sob demanda — para fechar a lacuna sem fingir que a escassez não existe.

3. Quando tratamos um serviço digital como um projeto com passagem de bastão, e não como um produto cuidado ao longo de toda a sua vida, e o que isso nos custou em conhecimento de domínio e de segurança perdido? Produto em vez de projeto é uma das mudanças estruturantes do tópico, e esta pergunta faz a equipe confrontar onde ainda financia e dimensiona para o encerramento em vez da continuidade. Importa porque os serviços de saúde são duradouros e estão em evolução contínua; uma equipe dissolvida na fronteira do projeto leva consigo exatamente o conhecimento clínico e operacional acumulado que mantém um serviço seguro, e o "purgatório dos pilotos" é o sintoma recorrente. A tensão real é financeira e estrutural: o financiamento por produto exige orçamentos permanentes e desafia o modelo de propostas anuais e prazos fechados em torno do qual as finanças e a governança foram construídas; por isso a conversa é tanto sobre dinheiro e responsabilização quanto sobre entrega. Considere um serviço específico que passou por uma passagem de bastão — rastreie o que aconteceu com o seu registro de perigos, a sua pesquisa com usuários e a sua equipe — e compare com a disciplina que o financiamento por produto exige. Uma boa resposta identifica um caso concreto, quantifica ou ao menos caracteriza o conhecimento perdido e é franca sobre quais barreiras organizacionais (ciclos de financiamento, regras de alocação de recursos, estruturas de governança) teriam de mudar para que equipes de produto permanentes se tornassem a norma.

4. Quem tem mais probabilidade de ser excluído ou prejudicado pelos serviços que construímos, e conseguimos apontar onde projetamos para essas pessoas primeiro, e não por último? O tópico insiste que a equidade é inegociável e que um serviço que só funciona para quem tem confiança digital amplia as desigualdades em saúde; esta pergunta testa se "projetar para os casos mais difíceis" é uma prática viva ou um slogan. Importa porque a exclusão na saúde e nos cuidados não é um incômodo, mas um dano à segurança e ao acesso: as populações Core20PLUS5, as pessoas com acesso digital limitado, baixo letramento em saúde ou sem smartphone são justamente aquelas cujas necessidades são maiores, e um serviço que as exclui do desenho concentra o dano onde ele é menos suportável. A tensão a trazer à tona é que projetar para as margens custa tempo e dinheiro logo de início — canais digitais assistidos, acessibilidade conforme a WCAG, alternativas offline e não digitais, tradução — e esses custos são fáceis de adiar quando uma data de entrega se aproxima e a maioria confiante já consegue usar o produto. Observe um serviço real e pergunte quem está na amostra da pesquisa com usuários, se uma análise de igualdade e de desigualdades em saúde realmente moldou alguma decisão de design e o que acontece com alguém que não pode ou não quer ficar on-line. Uma resposta honesta nomeia os grupos específicos em risco para esse serviço, mostra ao menos uma escolha concreta de design feita para eles e é franca sobre onde a equipe abriu mão da inclusão sob pressão e como defenderia essa concessão da próxima vez.

5. Onde estamos reinventando infraestrutura que já existe, e onde construir sobre padrões abertos e reutilizar plataformas compartilhadas mudaria de fato o que entregamos? Projetar para a interoperabilidade e a reutilização é uma das boas práticas do tópico, e esta pergunta faz a equipe confrontar a atração de construir sob medida em vez de reutilizar — o login, as notificações, a integração com o prontuário que uma dúzia de outras equipes também construíram. Importa porque, num sistema fragmentado, cada componente reinventado é dinheiro público gasto duas vezes e um novo silo que não consegue trocar dados com segurança; por outro lado, construir sobre HL7 FHIR e SNOMED CT e reutilizar a plataforma mínima viável é o que permite a um serviço passar pelas aquisições e compartilhar dados num ICS. A concessão real é que a reutilização implica dependência: uma plataforma compartilhada pode ser mais lenta, menos adaptada ou regida pelo roteiro de outra pessoa, de modo que a equipe deve pesar o arrasto de um componente compartilhado contra o custo e o risco de longo prazo de um silo sob medida. Examine uma construção atual e liste o que é genuinamente novo e o que duplica uma plataforma, um padrão ou um componente aberto existente, e verifique se "não podemos reutilizar isso" é uma restrição comprovada ou uma suposição não testada. Uma boa resposta distingue as partes que valem ser construídas das que valem ser reutilizadas, é honesta sobre a maturidade e a governança das plataformas disponíveis e se compromete com padrões abertos para tudo o que precisa trocar dados.

6. Como ajustamos o peso da nossa governança ao nível de risco, e onde a garantia está hoje pesada demais para mudanças de baixo risco ou leve demais para mudanças de alto risco? A governança proporcional é uma ideia estruturante neste tópico — mudanças clínicas de alto risco merecem escrutínio profundo, enquanto mudanças de conteúdo de baixo risco não devem esperar semanas por um conselho — e esta pergunta testa se a organização calibra a garantia ao risco ou aplica um único processo grosseiro a tudo. Importa porque uma governança mal calibrada prejudica nos dois sentidos: uma barreira pesada, igual para todos, leva as equipes a agrupar mudanças e retarda a própria iteração que mantém os serviços seguros, enquanto um toque uniformemente leve deixa passar uma mudança clínica de fato de alto risco sem o escrutínio de segurança clínica e de governança da informação de que precisa. A tensão é que a proporcionalidade exige julgamento, e o julgamento incomoda conselhos e auditores, que consideram uma lista de verificação obrigatória única mais fácil de defender do que uma via escalonada por risco. Observe como as suas últimas doze mudanças foram asseguradas, classifique-as pelo risco clínico e de dados real e veja se o esforço despendido acompanhou o risco ou o calendário. Uma resposta honesta identifica exemplos concretos de excesso e de falta de governança, propõe critérios claros para escalonar as mudanças por risco e nomeia quem detém a autoridade para decidir o nível e responder por ele.

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

Um sistema de cuidados integrados quer dar a clínicos de três hospitais de agudos, dos serviços comunitários e dos cuidados sociais da autoridade local um prontuário de cuidados compartilhado. O modo antigo contrataria um programa de escopo fixo, especificaria cada tela de antemão e integraria tarde.

Em vez disso, o ICS forma uma equipe multidisciplinar: um gerente de produto, um gerente de entrega, um pesquisador de usuários, um designer de interação, dois engenheiros, um responsável pela segurança clínica e um líder de governança da informação, com acesso a um Caldicott Guardian e a um profissional de cuidados sociais. Realizam uma descoberta de oito semanas, observando como uma enfermeira distrital, um consultor de pronto-socorro e um assistente social tentam, hoje, encontrar informações. Descobrem que a dor real não é "falta de dados", mas "dados cuja atualidade não se pode confiar".

A equipe entrega uma alfa restrita: acesso somente leitura a alergias, medicamentos e ao estado atual do plano de cuidados para uma via clínica, com um carimbo visível de "última atualização". A segurança clínica corre em paralelo; um registro de perigos é mantido desde a primeira semana. Eles medem se os clínicos deixam de telefonar para outras equipes para confirmar informações. Só depois que essa fatia fina se mostra valiosa e segura é que ampliam o prontuário — financiado como um produto contínuo, e não como um projeto encerrado.

Perspectivas setoriais#

As mesmas quatro pressões — segurança, equidade, dever, dinheiro — pesam sobre todas as organizações, mas os modos de trabalho que respondem a elas mudam com a escala, o financiamento e a responsabilização.

Startup#

Uma pequena empresa de saúde digital vive ou morre pelo foco, de modo que seus modos de trabalho são enxutos por necessidade: uma equipe multidisciplinar, decisão horizontal e contato diário com os usuários. A restrição é o fôlego financeiro, e não regras de quadro de pessoal; por isso a descoberta se mede em semanas e a evidência é reunida a baixo custo — um punhado de entrevistas clínicas, um protótipo clicável, um registro de perigos honesto mantido por um responsável fracionado pela segurança clínica. O perigo é abrir mão do rigor de segurança e de governança da informação para cumprir um marco de investidor; a disciplina que resiste ao escrutínio é tratar a DCB0129 e uma avaliação de impacto sobre a proteção de dados como critérios de entrada para um piloto, e não como papelada adiada até que um hospital a peça. A interoperabilidade desde o primeiro dia (FHIR, SNOMED CT) é também um ativo comercial, porque uma startup que não consegue trocar dados nunca passará pelas aquisições do NHS.

Pequena empresa#

Um pequeno prestador estabelecido — um consultório de clínica geral, uma farmácia comunitária, uma casa de repouso ou agência de cuidados domiciliares, uma clínica de unidade única ou um modesto fornecedor de tecnologia em saúde que já passou da fase pré-receita — carrega as mesmas pressões de segurança, equidade, dever e dinheiro que um grande hospital, mas com uma fração da capacidade para enfrentá-las. Os modos de trabalho aqui precisam ser radicalmente proporcionais: raramente há uma equipe digital ou de governança da informação dedicada, de modo que a "equipe multidisciplinar" costuma ser um punhado de pessoas que acumulam vários papéis, mais um recurso compartilhado ou terceirizado de segurança clínica e proteção de dados. A armadilha é supor que os deveres legais diminuem com a organização — não diminuem; assim, a segurança clínica DCB0129/DCB0160, uma avaliação de impacto sobre a proteção de dados e a acessibilidade continuam valendo por inteiro, ainda que um único gerente de consultório responda por todas elas. A disciplina prática é apoiar-se fortemente na reutilização em vez de construir: adotar sistemas prontos e credenciados, exigir que os fornecedores cumpram o DTAC e os padrões abertos (FHIR, SNOMED CT) e usar plataformas nacionais e do ICS, de modo que segurança, interoperabilidade e governança da informação sejam herdadas, e não reinventadas com poucos recursos.

Grande organização#

Um hospital do NHS ou um ICS tem o problema oposto: processo em abundância e propriedade fragmentada. Os modos de trabalho aqui tratam tanto de desaprender — aposentar hábitos de programas de escopo fixo, desfazer equipes de projeto que se dissolvem e se reconstroem — quanto de adotar novas práticas. A responsabilização é formal e pessoal (um responsável sênior, um Caldicott Guardian, uma aprovação de segurança clínica em nível de conselho), de modo que a vitória está em incorporar esses papéis dentro da equipe de entrega, e não em acrescentá-los como barreiras. Um grande fornecedor de tecnologia em saúde ou farmacêutico enfrenta a imagem espelhada: forte maturidade de engenharia, mas distância da realidade clínica da linha de frente, que as equipes multidisciplinares com tempo real de clínicos existem para encurtar.

Governo#

Um órgão público nacional ou local — NHS England, DHSC, UKHSA, uma autoridade local — define os padrões aos quais todos os demais trabalham, de modo que seus modos de trabalho se propagam para fora. Sua responsabilização é perante o Parlamento e o público, o que eleva o nível de exigência em transparência, controle de gastos e equidade: um padrão de serviço, uma via de garantia publicada e os deveres Core20PLUS5 são instrumentos dessa responsabilização, e não extras opcionais. O risco nessa escala é projetar centralmente para um cidadão médio que não existe e impor uma solução antes de entender a necessidade local. O corretivo é a mesma disciplina iterativa e centrada no usuário de todos os outros lugares, aplicada com uma inclinação para definir padrões abertos e plataformas reutilizáveis sobre as quais organizações federadas possam construir — governar o sistema, e não apenas prestar um serviço.

Modos de falha comuns#

• Entrega começando pela solução. Comprometer-se com um produto nomeado antes de entender a necessidade. Antídoto: financiar a descoberta e fazer das necessidades dos usuários o critério de entrada para a construção.
• Governança como barreira tardia. Segurança clínica e governança da informação consultadas apenas na entrada em produção, forçando retrabalho ou atalhos inseguros. Antídoto: incorporar ambas na equipe desde o primeiro dia.
• Rotatividade de projetos. Montar e desmontar equipes, perdendo o conhecimento de domínio e de segurança arduamente conquistado. Antídoto: financiamento por produto e equipes permanentes.
• Purgatório dos pilotos. Pilotos intermináveis que nunca escalam porque a adoção, o treinamento e a mudança de negócio nunca foram providos de recursos (ver Tópico 8.1 — Gestão de mudanças). Antídoto: planejar o caminho até a escala antes do piloto.
• Equidade como reflexão tardia. Projetar para a maioria confiante e excluir as pessoas que mais precisam de cuidados. Antídoto: projetar primeiro para os casos mais difíceis.

Modelo de maturidade#

Lista de verificação#

• Cada serviço tem uma equipe multidisciplinar nomeada e estável, com competências de segurança clínica e de governança da informação.
• Nenhuma construção começa sem necessidades dos usuários comprovadas pela descoberta.
• A gestão de riscos clínicos (DCB0129/DCB0160) funciona desde o primeiro dia, com um registro de perigos vivo.
• Foi feita uma análise de equidade e de desigualdades em saúde, e existem canais digitais assistidos.
• A entrega avança em fatias pequenas, frequentes e mensuráveis.
• As decisões são registradas, distinguindo a evidência clínica da evidência de entrega.
• Os serviços são construídos sobre padrões abertos de interoperabilidade e reutilizam plataformas compartilhadas.
• O peso da governança é ajustado ao risco e conhecido pela equipe.
• Existe um caminho financiado do piloto à escala, incluindo treinamento e mudança.

Fontes-chave#

• Manual de serviço digital do NHS — Padrão de serviço do NHS e seus pontos, incluindo "Use modos de trabalho ágeis" e "Crie uma equipe que inclua competências e perspectivas multidisciplinares" (service-manual.nhs.uk).
• GOV.UK Service Manual e o Government Service Standard — Government Digital Service (gov.uk/service-manual).
• NHS England / NHSX — Digital Technology Assessment Criteria (DTAC).
• Normas de segurança clínica DCB0129 e DCB0160 (NHS England / antigo NHS Digital).
• NICE — Evidence Standards Framework for digital health technologies (nice.org.uk).
• NHS England — abordagem Core20PLUS5 para reduzir as desigualdades em saúde.

Referências#

1. User-centered design — Wikipedia — https://en.wikipedia.org/wiki/User-centered_design
2. Government Digital Service — Wikipedia — https://en.wikipedia.org/wiki/Government_Digital_Service
3. Agile software development — Wikipedia — https://en.wikipedia.org/wiki/Agile_software_development
4. Iterative and incremental development — Wikipedia — https://en.wikipedia.org/wiki/Iterative_and_incremental_development
5. Interdisciplinarity — Wikipedia — https://en.wikipedia.org/wiki/Interdisciplinarity
6. Product management — Wikipedia — https://en.wikipedia.org/wiki/Product_management
7. Health equity — Wikipedia — https://en.wikipedia.org/wiki/Health_equity
8. Web Content Accessibility Guidelines — Wikipedia — https://en.wikipedia.org/wiki/Web_Content_Accessibility_Guidelines
9. Fast Healthcare Interoperability Resources (HL7 FHIR) — Wikipedia — https://en.wikipedia.org/wiki/Fast_Healthcare_Interoperability_Resources
10. SNOMED CT — Wikipedia — https://en.wikipedia.org/wiki/SNOMED_CT
11. NHS service standard — NHS digital service manual, NHS England — https://service-manual.nhs.uk/standards-and-technology/service-standard
12. Government Service Standard — Government Digital Service, GOV.UK — https://www.gov.uk/service-manual/service-standard
13. Digital Technology Assessment Criteria (DTAC) — NHS England — https://www.nhs.uk/digital-technology-assessment-criteria-dtac/
14. Clinical Risk Management: DCB0129 and DCB0160 — NHS England — https://digital.nhs.uk/services/clinical-safety
15. Evidence Standards Framework for digital health technologies — NICE — https://www.nice.org.uk/about/what-we-do/digital-health
16. Core20PLUS5 — NHS England — https://www.england.nhs.uk/about/equality/equality-hub/national-healthcare-inequalities-improvement-programme/core20plus5/