Tópico 4.1 — Plataformas e serviços compartilhados

Na saúde e nos cuidados, uma plataforma compartilhada não é uma conveniência para economizar custos, mas uma forma de tornar a segurança, a equidade e a confiança repetíveis — para que cada equipe as herde em vez de reinventá-las, muitas vezes mal.

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

Quando você conduz a entrega digital em todo um sistema de saúde e cuidados, logo percebe as mesmas capacidades sendo reconstruídas de novo e de novo. Todo serviço quer autenticar um paciente, consultar um registro demográfico, enviar uma notificação, registrar uma trilha de auditoria ou verificar o papel de um clínico. Se deixadas sozinhas, cada equipe constrói a sua versão. Você acaba com uma dúzia de telas de login, uma dúzia de formas de tratar a identidade de um paciente, uma dúzia de registros de auditoria de qualidade variável — e uma dúzia de lugares onde um defeito de segurança pode se esconder.

Essa duplicação é cara, mas o problema mais profundo é que é perigosa e iníqua. Na saúde e nos cuidados, a infraestrutura carrega risco clínico. Se a lógica de correspondência de pacientes de uma equipe é mais fraca do que a de outra, um paciente pode receber o prontuário errado. Se a acessibilidade de um serviço é pior, algumas pessoas são excluídas em silêncio. Se as trilhas de auditoria diferem, uma investigação de governança da informação emperra. Uma plataforma compartilhada permite construir uma capacidade uma vez, num padrão elevado, com o trabalho de segurança clínica e de acessibilidade feito direito, e deixar muitas equipes herdarem esse padrão, em vez de cada uma apostar em acertar sozinha.

As plataformas também moldam o ritmo de todo o sistema. Uma boa plataforma significa que um novo serviço pode chegar aos pacientes em semanas e não em anos, porque as partes difíceis e genéricas já existem. Uma plataforma ruim ou ausente significa que cada equipe carrega todo o peso da infraestrutura, e a entrega desacelera até a velocidade da equipe com menos recursos. Num setor sob pressão financeira e de força de trabalho sustentada, em que as mesmas capacidades nacionais e locais são necessárias a centenas de organizações, acertar nas plataformas é uma das decisões de maior alavancagem que você tomará. Este tópico trata de como construí-las e operá-las bem — como produtos com usuários reais, e não como infraestrutura imposta que ninguém ama.

Conceitos centrais#

Uma plataforma, neste contexto, é um conjunto de capacidades sobre as quais outras equipes constroem em vez de construir por conta própria. O enquadramento moderno mais útil é que uma plataforma é um produto com usuários internos. Seus clientes são os seus próprios desenvolvedores, equipes de entrega e organizações parceiras, e seu sucesso se mede como o de qualquer produto: pela adoção, pela experiência das pessoas que a usam e pelos desfechos que viabiliza.

Várias ideias relacionadas ficam por baixo disso. Os serviços compartilhados são o padrão organizacional mais antigo de prover uma capacidade uma vez para muitas partes de uma organização, em vez de duplicá-la em cada uma. A infraestrutura pública digital estende isso ao nível de toda uma sociedade — os blocos de construção compartilhados, reutilizáveis e interoperáveis (identidade, pagamentos, troca de dados) sobre os quais serviços públicos e privados são construídos. O "governo como plataforma", expressão cunhada por Tim O'Reilly e adotada por equipes de governo digital do mundo todo, aplica a mesma lógica ao Estado: o governo fornece componentes comuns, e os departamentos compõem serviços a partir deles, em vez de cada um construir toda a pilha.

Tecnicamente, as plataformas muitas vezes expõem suas capacidades por meio de uma interface de programação de aplicações (API) — um contrato definido que permite a um sistema usar a capacidade de outro sem conhecer seus detalhes internos. Frequentemente se apoiam em modelos de plataforma como serviço (PaaS) na nuvem, e as plataformas nacionais compartilhadas normalmente dependem da multilocação (multitenancy), em que uma única instância serve a muitas organizações mantendo separados seus dados e sua configuração.

Três conceitos governam se uma plataforma ajuda ou prejudica. O primeiro é a carga cognitiva: uma boa plataforma reduz o quanto uma equipe de entrega precisa guardar na cabeça, para que ela se concentre no problema clínico ou de cuidado para o qual existe. O segundo é a "estrada pavimentada" ou "caminho dourado" — uma forma padrão, bem apoiada e opinativa de fazer uma tarefa comum, mais fácil de seguir do que de evitar, oferecida por autosserviço e não por controle de acesso. O terceiro é a prevenção da dependência de fornecedor (vendor lock-in), razão pela qual as plataformas devem ser construídas sobre padrões abertos, para que as organizações possam passar de um fornecedor a outro sem custos proibitivos de mudança.

Na saúde, especificamente, os serviços nacionais compartilhados já fazem parte do cenário. Programas históricos como o NHS Connecting for Health estabeleceram a NHS Spine, um conjunto de serviços nacionais que carregam dados centrais, como o Personal Demographics Service. Os equivalentes modernos incluem APIs nacionais, o NHS login para a autenticação de cidadãos e o NHS Notify para mensagens — capacidades oferecidas para que serviços individuais não precisem reconstruí-las. Onde uma plataforma oferece uma forma comum de comprovar quem alguém é, ela muitas vezes expõe o login único (single sign-on), para que um clínico se autentique uma vez e não repetidamente. Este tópico trata de como construir e operar essas plataformas; os detalhes de quem você é e do que pode fazer pertencem ao Tópico 4.2 — Gestão de identidade e acesso, e os padrões que permitem aos sistemas trocar dados pertencem ao Tópico 4.3 — Interoperabilidade e padrões de dados.

Boas práticas#

1. Trate a plataforma como um produto, e não como um projeto. Uma plataforma tem roteiro, gerente de produto, financiamento contínuo e usuários cuja satisfação você mede — e não uma data final e uma passagem de bastão. Os projetos terminam e decaem; as plataformas precisam ser operadas indefinidamente, porque as equipes passam a depender delas. Financie e dote de pessoal em conformidade e veja o Tópico 5.0 — Trabalho conduzido por produto para a disciplina operacional que isso implica.

2. Comece pela plataforma mínima viável. Construa o menor conjunto de capacidades compartilhadas que genuinamente alivie as equipes e acrescente mais apenas quando a demanda e a dor reais justificarem. Essa ideia de "plataforma mínima viável", introduzida no Tópico 1.1 — O modelo operacional, protege contra a falha mais comum: uma ambiciosa plataforma central que tenta fazer tudo, chega tarde e não serve a ninguém. Deixe a plataforma crescer a partir de evidências de uso, e não de aspiração arquitetural.

3. Faça da estrada pavimentada a estrada fácil. Uma plataforma conquista adoção ao tornar o caminho apoiado mais rápido e simples do que construir o seu próprio — por meio de integração por autosserviço, documentação clara, ambientes de teste e padrões sensatos, com segurança clínica e acessibilidade embutidas. Se usar a plataforma é mais lento ou mais penoso do que contorná-la, as equipes a contornarão, e você terá gasto dinheiro para criar um gargalo. Projete para a primeira hora do desenvolvedor e para o seu pior dia.

4. Meça o sucesso pela adoção e pela experiência do usuário, e não pela existência. As métricas certas são quantas equipes usam a plataforma de bom grado, quanto tempo leva a integração, com que frequência a plataforma está disponível e como seus usuários avaliam a experiência. Métricas de vaidade, como o número de serviços implantados, nada dizem sobre se as equipes estão sendo ajudadas. Instrumentem a plataforma, conduzam pesquisa regular com as equipes que constroem sobre ela e tratem uma curva de adoção em queda ou estagnada como um problema de produto a corrigir, e não um problema de conformidade a impor.

5. Construa sobre padrões abertos e mantenha barata a saída. Prefira padrões e interfaces abertos e amplamente adotados, para que nem você nem as equipes da sua plataforma fiquem presos. Documente como uma equipe sairia e garanta que ela poderia. Paradoxalmente, tornar fácil sair é o que deixa as equipes à vontade para chegar, e mantém a plataforma honesta, porque ela precisa merecer o seu lugar em vez de contar com o cativeiro. Isso reduz diretamente a dependência de fornecedor em todo o parque mais amplo discutido no Tópico 4.0 — Arquitetura técnica, nuvem e sistemas legados.

6. Seja explícito sobre quem paga e quem decide. Uma plataforma compartilhada precisa de um modelo de financiamento e de um modelo de governança acordados de antemão: se é financiada centralmente, cobrada dos usuários ou híbrida, e como o seu roteiro é priorizado entre inquilinos concorrentes. A ambiguidade aqui é o que transforma plataformas em campos de batalha políticos. Publiquem o modelo, deem aos usuários voz real no roteiro e revisitem-no à medida que a plataforma cresce.

7. Conduza a equipe da plataforma com responsabilidades e fronteiras claras. Organize-se em torno de uma equipe de plataforma dedicada, cujo trabalho é viabilizar as equipes de entrega alinhadas ao fluxo por autosserviço, conforme os padrões do Team Topologies descritos no Tópico 7.0 — Estruturas de equipe, papéis e responsabilidades. Mantenha explícita a interface entre a plataforma e os consumidores — o que a plataforma promete, o que não promete e como obter suporte —, para que a plataforma viabilize em vez de controlar o acesso.

8. Projete para multilocação, isolamento e segurança desde o início. Se muitas organizações compartilharão uma plataforma, a separação de seus dados, configuração e domínios de falha é um requisito fundamental, e não uma funcionalidade posterior. Na saúde e nos cuidados, isso é também um requisito de governança da informação e de segurança clínica: o incidente de um inquilino não deve expor nem pôr em perigo os pacientes de outro. Incorporem isolamento, observabilidade por inquilino e um caso de segurança clínica para a própria plataforma sob a DCB0129.

Perguntas para discutir com a sua equipe#

1. Qual é a plataforma mais mínima que genuinamente aliviaria nossas equipes, e o que somos tentados a construir que não deveríamos? É fácil desenhar uma plataforma expansiva num quadro e difícil entregar uma que as equipes amem. Partam da dor real e repetida que suas equipes de entrega sentem hoje — a capacidade que três ou mais equipes estão reconstruindo — e resistam a acrescentar qualquer coisa que só uma equipe precise ou que ninguém ainda tenha pedido. Perguntem quais capacidades são genuinamente comuns e quais apenas parecem semelhantes de longe, mas diferem nos detalhes que importam clinicamente. Considerem o custo de errar: uma capacidade compartilhada prematura que as equipes precisam contornar é pior do que nenhuma plataforma. Acordem uma linha explícita entre o que a plataforma possuirá agora e o que adiará deliberadamente. Revisitem essa linha em cronograma, movendo itens apenas quando a demanda e a dor forem demonstradas. A disciplina é dizer não a boas ideias que ainda não merecem o seu lugar.

2. Como financiaremos a plataforma e decidiremos seu roteiro quando os inquilinos discordarem? Uma plataforma serve a muitas equipes com prioridades concorrentes, e, no momento em que dois inquilinos importantes querem coisas incompatíveis, a sua governança é testada. Decidam agora se a plataforma é financiada centralmente, cobrada dos usuários ou híbrida e sejam honestos sobre os incentivos que cada modelo cria: a cobrança pode suprimir a adoção, enquanto o financiamento central pode desligar a plataforma da necessidade do usuário. Decidam quem detém o roteiro, como os inquilinos o influenciam e como vocês arbitram entre a necessidade urgente de uma grande organização e a necessidade básica de uma pequena. Considerem a equidade explicitamente, porque um modelo de cobrança pode tirar organizações menores ou mais pobres das capacidades compartilhadas de segurança. Acordem como lidarão com um inquilino que quer financiar uma funcionalidade que os demais não querem. Escrevam o modelo e publiquem-no, para que as decisões pareçam governança e não favoritismo. Depois comprometam-se a revisitá-lo à medida que a plataforma e sua base de usuários crescem.

3. Como saberemos que a plataforma é amada e não meramente imposta, e o que faremos se não for? Uma plataforma pode ser tecnicamente sólida, oficialmente exigida e silenciosamente odiada — e uma plataforma imposta, mas malquista, acumula gambiarras, sistemas paralelos e ressentimento. Decidam de antemão quais sinais dizem a verdade: adoção voluntária onde as equipes têm escolha, tempo até o primeiro sucesso de uma nova equipe, disponibilidade e histórico de incidentes e retorno direto dos desenvolvedores que a usam. Falem sobre como coletarão retorno honesto quando também detêm poder sobre seus usuários, já que as pessoas relutam em criticar uma plataforma que são obrigadas a usar. Acordem como é uma curva de adoção saudável e que limiar acionaria um repensar sério. Decidam se estariam dispostos a aposentar ou substituir a plataforma se a evidência exigisse. Estar disposto a ouvir que sua plataforma não está funcionando é o que a mantém funcionando. A alternativa é descobrir a verdade apenas quando um serviço importante a contorna.

4. Como manteremos barata a saída, e uma equipe da nossa plataforma realmente poderia sair se precisasse? É fácil alegar que se está construído sobre padrões abertos e outra coisa bem diferente é provar que uma equipe poderia ir embora sem uma reescrita proibitiva. Conversem com honestidade sobre onde a dependência está se infiltrando — uma interface proprietária, um formato de dados não documentado, uma dependência nacional sem alternativa — e se o custo de sair está subindo em silêncio com o tempo. Decidam quem é responsável por documentar e testar periodicamente um caminho de saída, em vez de supor que ele existe. Considerem que, na saúde e nos cuidados, o risco de dependência se agrava: uma plataforma nacional construída sobre o cativeiro pode prender todo um sistema por uma geração, e as equipes menos capazes de absorver os custos de mudança costumam ser os menores prestadores. Uma resposta honesta nomeia as dependências específicas que vocês teriam dificuldade em desfazer, descreve uma saída concreta para ao menos um inquilino real e trata a portabilidade como uma funcionalidade que se mantém e não um slogan que se repete. Lembrem-se de que tornar fácil sair é, muitas vezes, o que deixa as equipes à vontade para chegar.

5. A plataforma carrega o seu próprio caso de segurança clínica, e como impedimos que a falha de um inquilino prejudique os pacientes de outro? Quando muitas organizações compartilham uma plataforma, sua infraestrutura carrega risco clínico em nome de todo serviço construído sobre ela; assim, um defeito na correspondência de pacientes ou um vazamento entre inquilinos não é problema de uma equipe, mas de todas. Decidam se a plataforma tem seu próprio caso de segurança DCB0129 em que as equipes consumidoras possam genuinamente confiar ou se cada serviço está reavaliando em silêncio o mesmo risco compartilhado. Discutam como vocês isolam os dados, a configuração e os domínios de falha dos inquilinos e como saberiam se esse isolamento fosse violado — a observabilidade por inquilino é a diferença entre conter um incidente e descobri-lo tarde. Considerem também as consequências de governança da informação: uma investigação sobre um inquilino não deve exigir expor os registros de outro. Uma resposta honesta consegue apontar um caso de segurança mantido, uma fronteira de isolamento testada e um relato claro do que a plataforma promete sobre segurança versus o que continua sendo responsabilidade de cada serviço. Tratar a segurança e o isolamento como fundamentais, e não como funcionalidades posteriores, é o que permite às equipes herdar a garantia em vez de apostar nela.

6. Onde está a linha entre a equipe da plataforma e as equipes que ela serve, e como impedimos que a plataforma vire um gargalo? Uma plataforma compartilhada pode acelerar todas as equipes ou reduzi-las todas à velocidade de uma única fila central, e a diferença está em quão nitidamente vocês traçaram a interface entre a plataforma e os consumidores. Decidam o que a plataforma possui e promete, o que explicitamente não promete e como uma equipe obtém suporte sem esperar por um chamado para o trabalho de rotina. Falem do autosserviço como padrão: se a integração, o provisionamento ou uma mudança comum exigem que a equipe da plataforma aja à mão, vocês construíram uma barreira e não uma estrada pavimentada. Considerem a barganha de carga cognitiva no coração de uma boa plataforma — ela deve reduzir o que uma equipe de entrega precisa guardar na cabeça para que se concentre no problema clínico, e não acrescentar uma nova camada a negociar. Uma resposta honesta nomeia as tarefas que ainda funilam pela equipe da plataforma como gargalo, define uma direção para torná-las autosserviço e é franca sobre onde a plataforma viabiliza e onde controla o acesso.

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

Um Sistema de Cuidados Integrados (ICS) que abrange vários hospitais do NHS, prestadores comunitários e o serviço de cuidados sociais para adultos de um conselho de condado continua batendo na mesma parede. Cada novo serviço digital — uma enfermaria virtual, um formulário de autoencaminhamento para fisioterapia comunitária, uma ferramenta de supervisão de casas de repouso — gasta os três primeiros meses reconstruindo as mesmas fundações: comprovar quem é o paciente, verificar o papel do profissional, enviar lembretes por SMS e escrever uma trilha de auditoria. A correspondência de pacientes da equipe da enfermaria virtual se revela mais fraca do que a da equipe de fisioterapia, e ocorre um quase-acidente quando um lembrete é enviado à pessoa errada. A liderança digital do ICS reconhece o padrão: estão pagando muitas vezes por capacidades que deveriam existir uma só vez, e a variação é um risco para a segurança.

Em vez de encomendar uma grande plataforma do ICS, começam pelo mínimo. Montam um único serviço compartilhado que faz uma coisa bem: envolve o NHS login e o Personal Demographics Service nacional atrás de uma API limpa e documentada, com ambiente de teste, de modo que qualquer equipe possa verificar a identidade de um cidadão e recuperar um registro demográfico confirmado por um único caminho apoiado. Uma pequena equipe de plataforma de cinco pessoas o trata como um produto. Publica um guia da estrada pavimentada, oferece integração por autosserviço e define como meta que uma nova equipe faça sua primeira chamada bem-sucedida em um dia. De forma decisiva, não o impõe. Torna-o a opção mais fácil e deixa a equipe da enfermaria virtual ser a primeira adotante voluntária.

O modelo de financiamento é acordado às claras: o ICS financia centralmente o núcleo da plataforma por seus dois primeiros anos, para que a adoção não seja suprimida pela cobrança, com uma revisão aos dezoito meses. Um grupo entre prestadores, incluindo o conselho, detém o roteiro e se reúne mensalmente. Quando a equipe de fisioterapia pede em seguida uma capacidade de notificações, a equipe da plataforma acrescenta um envoltório fino em torno do NHS Notify em vez de construir mensagens do zero — construir uma vez, usar muitas. Em um ano, seis equipes adotaram o serviço de identidade de bom grado, a integração caiu de meses para dias e a equipe da plataforma publica abertamente seus números de disponibilidade e de adoção. Quando o sistema sob medida de um hospital contorna a plataforma, a equipe trata isso como pesquisa, e não como desafio, aprende o atrito que motivou a decisão e o corrige. A plataforma cresce porque as equipes a escolhem, e o ICS herda uma forma única, bem testada e acessível de fazer as coisas arriscadas e comuns.

Perspectivas setoriais#

Startup#

Uma startup de tecnologia em saúde raramente constrói plataformas para outros; constrói sobre elas. Sua alavancagem vem de consumir plataformas nacionais e de nuvem — NHS login, APIs nacionais, serviços gerenciados de um provedor de nuvem —, para que a sua pequena equipe gaste energia no problema clínico, e não em reinventar identidade ou mensagens. Fique atento à dependência de qualquer modo: escolha padrões abertos e mantenha seus dados portáteis, porque a capacidade que você aluga barato hoje pode virar a dependência que a restringe amanhã. Internamente, mantenha a sua própria "plataforma" tão mínima a ponto de ser quase invisível; uma equipe de duas pessoas não precisa de uma abstração de caminho dourado, precisa entregar. A disciplina é saber quando você cresceu o bastante para que valha extrair uma capacidade interna compartilhada.

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 — é quase sempre um consumidor de plataformas, com pouca ou nenhuma capacidade digital própria, de modo que as plataformas de que depende fixam, na prática, o seu piso de segurança e equidade. Sua tarefa prática é escolher serviços compartilhados apoiados em vez de construções sob medida que não consegue dotar de pessoal nem manter, favorecendo capacidades nacionais como o NHS login, a consulta demográfica e o NHS Notify, que já carregam trabalho de acessibilidade e de segurança clínica que você jamais poderia financiar sozinho. Insista em integração genuína por autosserviço e documentação clara, porque você não tem equipe de plataforma a quem escalar e não pode arcar com um longo projeto de integração. Observe de perto o modelo de financiamento: uma plataforma com cobrança pode tirar um pequeno prestador das próprias capacidades de segurança de que mais precisa; por isso pressione por acesso equitativo e levante a questão em qualquer governança de roteiro que consiga alcançar. Fique atento também à saída, já que a dependência de fornecedor proprietário é mais difícil de escapar quando não há equipe técnica interna para migrá-lo. O ganho é que uma boa plataforma compartilhada permite herdar padrões que você não conseguiria construir, cumprindo os mesmos deveres das grandes organizações sem os seus recursos.

Grande organização#

Um grande hospital ou órgão nacional tem a escala para justificar plataformas de verdade e a burocracia para arruiná-las. O risco é uma equipe central de plataforma que vira uma torre de marfim — arquiteturalmente elegante, lenta para responder e desligada das equipes de entrega a quem supostamente serve. Combata isso financiando as plataformas como produtos de longa duração, com roteiros próprios e pesquisa com usuários, e medindo-as pela adoção e pela experiência do desenvolvedor, e não pelo cumprimento da obrigatoriedade. A multilocação, o isolamento e um caso de segurança clínica para a própria plataforma se tornam essenciais nessa escala. O prêmio é enorme: uma capacidade construída uma vez num padrão elevado e herdada por dezenas de serviços, elevando o piso de toda a organização.

Governo#

Em nível nacional e de sistema, o enquadramento é o da infraestrutura pública digital e do governo como plataforma: construir componentes comuns — identidade, notificações, consulta demográfica, troca de dados — que centenas de organizações compõem em serviços. O que está em jogo quanto à abertura é maior aqui, porque uma plataforma nacional construída sobre dependência proprietária pode prender todo um sistema de saúde por uma geração. A governança e o financiamento devem ser resolvidos às claras, com influência real para as organizações menores e mais pobres que as plataformas compartilhadas existem, em parte, para proteger. A tentação de impor é mais forte e mais perigosa nesse nível; uma plataforma nacional exigida, mas malquista, gera sistemas paralelos pelo país. Conquistem a adoção pela qualidade e pelo suporte e tratem cada gambiarra como um sinal para melhorar.

Modos de falha comuns#

• O gargalo. Toda equipe precisa esperar a equipe central da plataforma para fazer qualquer coisa, de modo que a plataforma retarda a entrega em vez de acelerá-la. A cura é o autosserviço: as equipes devem poder se integrar e agir sem um chamado.
• A torre de marfim. A plataforma é projetada por pessoas distantes da entrega, é tecnicamente admirável e não serve a nenhuma equipe real. A cura é conduzir a plataforma como produto, com pesquisa contínua com usuários.
• Imposta, mas malquista. A plataforma é exigida por política, mas contornada na prática, acumulando sistemas paralelos e ressentimento. A cura é conquistar a adoção pela qualidade e ouvir quando as equipes a contornam.
• A plataforma de tudo. Um escopo superambicioso faz a plataforma chegar tarde, fazer demais e nada bem. A cura é a plataforma mínima viável, crescida a partir de evidências de demanda.
• Dependência furtiva. A plataforma prende silenciosamente as equipes a um fornecedor ou interface proprietários, e o custo de sair se torna proibitivo. A cura são padrões abertos e um caminho de saída documentado e testado.
• Ambiguidade de financiamento. Ninguém acordou quem paga ou quem decide, de modo que a plataforma passa fome ou vira campo de batalha político. A cura é um modelo explícito e publicado de financiamento e governança.
• Segurança como reflexão tardia. A plataforma não tem caso de segurança clínica próprio, de modo que todo serviço consumidor herda risco não avaliado. A cura é tratar o caso de segurança DCB0129 da plataforma como fundamental.

Modelo de maturidade#

Lista de verificação#

• A plataforma tem um gerente de produto nomeado, um roteiro e financiamento contínuo (e não de projeto).
• Vocês começaram pela plataforma mínima viável e conseguem nomear o que adiaram deliberadamente.
• O caminho apoiado é genuinamente mais rápido e mais fácil do que as equipes construírem o seu.
• As novas equipes podem se integrar por autosserviço, com um ambiente de teste e documentação clara.
• Vocês medem a adoção, o tempo até o primeiro sucesso, a disponibilidade e a experiência do desenvolvedor.
• O modelo de financiamento (central, cobrança ou híbrido) está acordado e publicado.
• A governança do roteiro dá aos inquilinos, inclusive às organizações menores, uma voz real.
• A plataforma é construída sobre padrões abertos e existe um caminho de saída documentado.
• O isolamento multilocatário de dados e de falhas é projetado desde o início, e não acrescentado depois.
• A plataforma tem o seu próprio caso de segurança clínica (DCB0129) em que as equipes consumidoras podem confiar.
• Vocês tratam as equipes que contornam a plataforma como pesquisa, e não como desafio.

Fontes-chave#

• GOV.UK Service Manual e os textos do Government Digital Service sobre governo como plataforma e componentes comuns.
• Matthew Skelton e Manuel Pais, Team Topologies — equipes de plataforma, plataforma mínima viável e carga cognitiva.
• Orientações do NHS England para desenvolvedores e APIs (NHS login, NHS Notify, APIs nacionais e os serviços da Spine).
• Normas de gestão de riscos clínicos DCB0129 e DCB0160 para sistemas de TI em saúde.
• Textos do Banco Mundial e das Nações Unidas sobre infraestrutura pública digital e blocos de construção públicos reutilizáveis.
• Tim O'Reilly, "Government as a Platform", em Open Government (O'Reilly Media).

Referências#

1. Digital public infrastructure — Wikipedia — https://en.wikipedia.org/wiki/Digital_public_infrastructure
2. Shared services — Wikipedia — https://en.wikipedia.org/wiki/Shared_services
3. API (application programming interface) — Wikipedia — https://en.wikipedia.org/wiki/API
4. Platform as a service — Wikipedia — https://en.wikipedia.org/wiki/Platform_as_a_service
5. Multitenancy — Wikipedia — https://en.wikipedia.org/wiki/Multitenancy
6. Cognitive load — Wikipedia — https://en.wikipedia.org/wiki/Cognitive_load
7. Vendor lock-in — Wikipedia — https://en.wikipedia.org/wiki/Vendor_lock-in
8. Open standard — Wikipedia — https://en.wikipedia.org/wiki/Open_standard
9. NHS Connecting for Health (including the NHS Spine and Personal Demographics Service) — Wikipedia — https://en.wikipedia.org/wiki/NHS_Connecting_for_Health
10. Single sign-on — Wikipedia — https://en.wikipedia.org/wiki/Single_sign-on
11. Team Topologies: Organizing Business and Technology Teams for Fast Flow — Matthew Skelton and Manuel Pais (IT Revolution Press) — https://teamtopologies.com/book
12. Government as a Platform — Tim O'Reilly, in Open Government (O'Reilly Media) — https://www.oreilly.com/library/view/open-government/9781449381936/ch02.html
13. GOV.UK Service Manual — Government Digital Service — https://www.gov.uk/service-manual
14. NHS login and NHS England developer/API guidance — NHS England — https://digital.nhs.uk/services/nhs-login
15. Clinical risk management: its application in the manufacture of health IT systems (DCB0129) — NHS England — https://digital.nhs.uk/services/clinical-safety/documentation