Tópico 4.6 — Prontuários eletrônicos do paciente e sistemas clínicos

O prontuário eletrônico do paciente é a espinha dorsal operacional de um hospital moderno; por isso a forma como você o seleciona, configura, implanta e continua otimizando é uma decisão de segurança clínica, de produtividade da força de trabalho e de dinheiro público que moldará o cuidado por uma década — e não uma aquisição pontual de TI.

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

O prontuário eletrônico do paciente (EPR) é o sistema único pelo qual passa hoje a maior parte do trabalho clínico. Médicos e enfermeiros o leem para saber o que há de errado com um paciente, pedem os exames e medicamentos que mudam o curso do paciente e documentam as decisões em que outros se apoiarão horas ou anos depois. Quando o EPR é bom, torna fácil a coisa segura: a dose certa, o alerta de alergia certo, os resultados diante de quem precisa deles. Quando é ruim, enterra os clínicos em cliques, esconde o sinal no ruído e remodela em silêncio o comportamento clínico de maneiras que ninguém pretendia.

É por isso que um programa de EPR é diferente de quase qualquer outro projeto de tecnologia que você conduzirá. Toca todo clínico, todo plantão, todo paciente, e o faz no exato momento em que o cuidado é prestado. Um conjunto de pedidos mal configurado pode propagar um erro de dosagem por todo um hospital; uma entrada em produção malfeita pode alongar cada consulta por meses; uma migração de dados que perde alergias ou o estado de ressuscitação pode matar alguém. O prontuário é também um artefato legal e regulatório — o relato médico-legal do que foi feito e por quê —, de modo que sua integridade, disponibilidade e auditabilidade carregam peso estatutário (ver Tópico 1.6 — Segurança clínica e gestão de riscos e Tópico 1.7 — Governança da informação, proteção de dados e cibersegurança).

O que está em jogo também é financeiro e estratégico. Um EPR está entre os maiores investimentos isolados que um hospital faz, muitas vezes dezenas de milhões de libras ao longo da sua vida, e prende a organização a um fornecedor e a um modo de trabalhar por muitos anos. Nacionalmente, o programa de digitalização da linha de frente do NHS England fez de um EPR central a expectativa de base para todo prestador de agudos, comunitário, de saúde mental e de ambulância, atrelando o financiamento de capital à maturidade digital. Acertar o EPR é hoje indissociável de acertar o modelo operacional (ver Tópico 1.1 — O modelo operacional). Errar desperdiça dinheiro público, esgota clínicos e pode atrasar uma organização por anos.

Conceitos centrais#

Um prontuário eletrônico de saúde (EHR) é a coleção digital e sistematizada das informações de saúde de um paciente. Na prática do Reino Unido, o quase sinônimo prontuário eletrônico do paciente (EPR) costuma designar o sistema clínico central de uma organização prestadora — o prontuário e as ferramentas que os clínicos usam no ponto de cuidado. Em torno dele existe uma família de sistemas clínicos, historicamente descrita como sistema de informação hospitalar (HIS): o sistema de administração de pacientes (PAS), que acompanha internações, altas, transferências e consultas ambulatoriais; a documentação clínica; o relato de resultados; e sistemas especializados para centros cirúrgicos, maternidade, emergência e cuidados intensivos.

A entrada computadorizada de pedidos médicos (CPOE, também chamada de comunicação de pedidos, ou "order comms") é a entrada eletrônica de pedidos clínicos — exames, medicamentos, encaminhamentos — diretamente pelo clínico que pede, substituindo papel e telefonemas. É onde grande parte do valor de segurança de um EPR se realiza, porque os pedidos podem ser verificados, padronizados em conjuntos de pedidos e encaminhados automaticamente. A CPOE está estreitamente acoplada à prescrição eletrônica e ao apoio à decisão clínica, que traz alertas e orientações para o fluxo de trabalho (tratados no Tópico 4.7 — Apoio à decisão clínica e informática clínica e no Tópico 4.8 — Prescrição eletrônica e medicamentos).

Duas escolhas de projeto definem um programa de EPR. A primeira é configuração versus personalização: a configuração adapta o produto com as alavancas que o fornecedor apoia (construir telas, conjuntos de pedidos, papéis, regras) e permanece dentro do caminho de atualização apoiado, ao passo que a personalização escreve código sob medida ou estruturas que o fornecedor não pretendia, o que é poderoso, mas vira um passivo de manutenção e de segurança a cada atualização. A segunda é a forma de implantação: a adoção big bang (troca direta, em que toda a organização muda numa só data) versus uma implantação faseada ou modular que põe locais ou funções em produção em sequência. Cada forma troca concentração de risco por complexidade de integração e "fadiga do big bang".

O programa é conduzido tanto por clínicos quanto por tecnólogos. O diretor médico de informática (CMIO, no Reino Unido em geral o diretor clínico de informação, CCIO) e o diretor de enfermagem de informação (CNIO) são clínicos seniores que respondem pelo projeto clínico, pela segurança e pela adoção do sistema — a ponte entre a linha de frente e a construção. Sua disciplina é a informática em saúde: aplicar a ciência da informação e da computação para melhorar a gestão e o uso da informação clínica.

Vários conceitos de nível de sistema se repetem. A migração de dados é a transferência única de prontuários históricos de sistemas legados para o novo EPR — tecnicamente rotineira, clinicamente espinhosa. Um motor de integração (interface engine) encaminha mensagens entre sistemas usando padrões como o Health Level Seven (HL7) e o FHIR (ver Tópico 4.3 — Interoperabilidade e padrões de dados). Uma troca de informações de saúde ou prontuário de cuidados compartilhado permite que organizações de uma área leiam os prontuários umas das outras. E, como o prontuário é crítico para a segurança, os procedimentos de contingência — os planos de continuidade de negócios para quando o EPR está indisponível — são parte central do sistema, e não uma reflexão tardia (ver Tópico 3.9 — Continuidade de negócios e recuperação de desastres). A maturidade digital é comumente avaliada com o Electronic Medical Record Adoption Model (EMRAM) da Healthcare Information and Management Systems Society (HIMSS), uma escala de 0 a 7 da capacidade dos sistemas clínicos.

Boas práticas#

1. Faça da liderança clínica a espinha do programa, e não uma consultada. Um EPR tem sucesso ou fracassa conforme os clínicos se apropriem dele. Nomeiem e dotem de recursos adequados um CCIO e um CNIO com autoridade real e tempo protegido, construam uma rede de "campeões digitais" clínicos em cada especialidade e enfermaria e deem à liderança do projeto clínico direitos genuínos de decisão sobre a construção e a configuração. O padrão que falha é um programa conduzido tecnicamente que "engaja" os clínicos por oficinas ocasionais; o que funciona trata clínicos em exercício como coautores do sistema que usarão a cada plantão.

2. Configure o produto apoiado; personalize apenas de olhos abertos. Toda personalização sob medida é uma dívida paga a cada atualização e uma superfície oculta de segurança clínica que ninguém retesta. Adotem por padrão a configuração dentro do modelo apoiado pelo fornecedor, adotem o conteúdo testado e os conjuntos de pedidos do produto quando forem seguros e reservem a verdadeira personalização para os poucos lugares em que uma necessidade clínica ou estatutária genuína não pode ser atendida de outro modo — cada uma documentada, avaliada quanto ao risco e com responsável. Resistam ao impulso de reconstruir o sistema antigo dentro do novo; "faça funcionar como o formulário em papel" é como as organizações pagam por um EPR moderno e herdam seus problemas legados.

3. Escolha deliberadamente a forma de implantação e reduza o risco de qualquer uma que escolher. O big bang concentra o risco numa única data, mas evita a dor e o custo de operar dois sistemas em paralelo e integrá-los; uma implantação faseada ou modular distribui o risco e permite aprender, mas multiplica interfaces, a operação em paralelo e a fadiga de mudança. Decidam com base no apetite por risco, na complexidade de integração e em quanta ruptura clínica a organização consegue absorver de uma vez (ver Tópico 8.0 — Implantação faseada da inovação). Qualquer que seja a escolha, invistam desproporcionalmente na virada: ensaios gerais, um centro de comando, apoio maciço de acompanhamento nas enfermarias nas primeiras semanas e uma posição de recuo clara e praticada.

4. Trate a migração de dados como um exercício de segurança clínica, e não uma tarefa de encanamento de dados. Decidir que histórico passa para o novo prontuário — e verificar se chegou corretamente — é onde as migrações prejudicam pacientes, por alergias perdidas, identificadores incompatíveis ou históricos de medicação truncados. Acordem explicitamente o que migra automaticamente, o que é resumido, o que é deixado num arquivo somente leitura do sistema legado e como os clínicos o alcançarão; depois reconciliem e validem os dados migrados com aprovação clínica antes da entrada em produção. Jamais suponham que um campo foi mapeado limpamente porque a carga rodou sem erros — uma migração tecnicamente bem-sucedida ainda pode estar clinicamente errada (ver Tópico 4.9 — Qualidade de dados e gestão de dados mestres).

5. Planeje a queda de produtividade e financie a otimização que a segue. Quase toda entrada em produção de um EPR é seguida por um período de menor vazão, enquanto a equipe aprende o sistema, e as organizações que fingem o contrário prejudicam tanto a segurança quanto o moral. Reduzam deliberadamente a atividade eletiva em torno da entrada em produção, protejam o tempo de treinamento e definam trajetórias de recuperação realistas com o conselho, para que a queda seja um evento planejado, e não uma crise (ver Tópico 8.1 — Gestão de mudanças). De modo crucial, orcem e dotem de pessoal a otimização contínua depois: o valor de um EPR se realiza nos anos seguintes à entrada em produção, por meio do ajuste iterativo de fluxos de trabalho, conjuntos de pedidos e alertas — uma disciplina de produto, e não um projeto que termina na virada (ver Tópico 5.0 — Trabalho conduzido por produto).

6. Projete conjuntos de pedidos, alertas e fluxos de trabalho para reduzir a carga e governe-os continuamente. A construção clínica é onde um EPR economiza carga cognitiva ou a aumenta. Padronizem os conjuntos de pedidos em torno de boa evidência, ajustem os alertas de apoio à decisão para que os clínicos vejam os poucos que importam em vez de se afogar em pop-ups de baixo valor e meçam a carga de documentação como resultado de primeira ordem. Estabeleçam um grupo permanente de governança de informática clínica que responda pela construção ao longo do tempo, revise as taxas de disparo e de anulação de alertas e aposente o conteúdo que já não merece o seu lugar (ver Tópico 4.7 — Apoio à decisão clínica e informática clínica).

7. Incorpore ao prontuário, desde o início, a contingência e a continuidade de negócios. O EPR um dia estará indisponível — por uma atualização fracassada, uma queda de rede ou um ataque de ransomware —, e um hospital que não consegue funcionar em papel por essas horas é um incidente de segurança do paciente à espera de acontecer. Forneçam acesso somente leitura a uma cópia recente do prontuário durante as indisponibilidades, mantenham fluxos clínicos ensaiados em papel e pratiquem indisponibilidades planejadas e não planejadas, para que a equipe não improvise sob pressão. Acordem explicitamente os objetivos de tempo e de ponto de recuperação do prontuário clínico e testem a reconciliação dos registros em papel de volta ao sistema após a recuperação (ver Tópico 3.9 — Continuidade de negócios e recuperação de desastres).

8. Realize os benefícios deliberadamente e meça os desfechos que prometeu. O caso de negócio de um EPR repousa em benefícios de segurança, qualidade e eficiência que não aparecem automaticamente; eles precisam ser projetados, ter dono e ser acompanhados. Estabeleçam a linha de base das métricas antes da entrada em produção, liguem cada benefício a um responsável nomeado e a uma mudança de fluxo de trabalho e revisem a realização frente ao caso em intervalos definidos, em vez de declarar vitória na virada (ver Tópico 6.2 — Realização de benefícios e gestão de valor). Usem uma referência reconhecida de maturidade, como o HIMSS EMRAM, para dar ao conselho uma medida externa e comparável de progresso, e não apenas anedotas internas.

9. Gerencie a convergência e a interoperabilidade como um sistema, e não apenas como um programa de hospital. Num sistema de cuidados integrados (ICS), a atração estratégica é rumo a menos instâncias de EPR e a um prontuário de cuidados compartilhado, para que a informação de um paciente o acompanhe entre organizações. Convergir para um EPR comum pode cortar custos e suavizar o fluxo de pacientes, mas concentra risco e dilui o controle local; pesem-no, portanto, frente a uma forte interoperabilidade entre sistemas distintos (ver Tópico 4.3 — Interoperabilidade e padrões de dados). Qualquer que seja a forma, insistam em padrões abertos e numa estratégia realista de saída para limitar a dependência de fornecedor, porque um EPR do qual você não consegue tirar seus dados é um EPR que é dono de você (ver Tópico 6.3 — Aquisições e contratações).

Perguntas para discutir com a sua equipe#

1. Quem de fato é dono do projeto clínico do nosso EPR — e essa pessoa tem a autoridade, o tempo e a credibilidade para tomar as decisões difíceis que a linha de frente aceitará? Isto importa porque o mais forte preditor isolado do sucesso de um EPR é a genuína propriedade clínica, e a falha mais comum é um programa tecnicamente competente, mas clinicamente vazio. Debatam se o seu CCIO e o seu CNIO têm sessões protegidas, orçamento real e direitos de decisão ou se são figuras respeitadas, mas vencidas por prazos de entrega e padrões do fornecedor. Tragam à tona a tensão entre a variação clínica e a padronização: toda especialidade quer a sua própria construção, mas mil variantes locais se tornam insustentáveis e inseguras. Considerem como as disputas são de fato resolvidas hoje — por consenso clínico, pela voz mais alta ou por quem controla o cronograma. Vejam se existem campeões na linha de frente em cada área ou apenas no papel. Uma boa resposta, honesta, nomeia os responsáveis clínicos, admite onde a autoridade hoje é fina demais e descreve uma via de governança em que as decisões de projeto clínico são tomadas por clínicos e se sustentam.

2. Quanto a queda de produtividade de fato nos custará, e o conselho aceitou isso de olhos abertos? Quase toda entrada em produção desacelera a organização antes de acelerá-la, e, no entanto, os casos de negócio e os conselhos rotineiramente supõem uma curva suave, preparando o programa para ser julgado um fracasso justamente quando se comporta normalmente. Discutam até que ponto vocês reduzirão deliberadamente a atividade eletiva em torno da entrada em produção, quanto tempo a recuperação realisticamente leva para a sua combinação de especialidades e o que dirão aos reguladores e pacientes sobre os tempos de espera nessa janela. Pesem a concessão entre uma queda mais curta e mais aguda, com forte apoio inicial, e uma mais suave e mais longa — e quem arca com o risco operacional e financeiro de cada uma. Sondem se as horas de treinamento são de fato protegidas ou a primeira coisa sacrificada quando a escala aperta. Considerem que indicadores antecedentes diriam que a queda é mais profunda ou mais longa do que o planejado e qual seria a sua resposta. Uma boa resposta enuncia uma queda planejada, financiada e endossada pelo conselho, com trajetórias de recuperação, e não a esperança de que os clínicos simplesmente a absorvam.

3. Quando o EPR cai, ainda conseguimos manter um hospital seguro — e quando foi a última vez que provamos isso? O prontuário é hoje tão central que a sua indisponibilidade é uma emergência clínica, e, no entanto, os procedimentos de contingência costumam ser a parte menos ensaiada de todo o programa. Discutam quais funções clínicas seriam mais perigosas de perder, se a equipe consegue de fato alcançar uma cópia recente somente leitura do prontuário durante uma indisponibilidade e se os fluxos de recurso em papel existem e são praticados ou são fichários empoeirados que ninguém abriu. Tragam à tona o cenário mais difícil — uma indisponibilidade prolongada e não planejada, como um ciberataque que dura dias, e não a arrumada janela de atualização planejada — e se os seus objetivos de tempo e de ponto de recuperação do prontuário clínico estão acordados e testados. Considerem o problema da reconciliação: como os registros em papel criados durante a indisponibilidade voltam ao sistema com segurança depois, sem perder nem duplicar informação. Uma boa resposta aponta exercícios recentes e realistas de indisponibilidade, objetivos nomeados para o prontuário e uma equipe que sabe o que fazer, e não um plano que só existiu no papel.

4. Onde traçamos a linha entre configurar o produto apoiado e construir o nosso, e quem responde por cada exceção? Toda personalização sob medida parece justificada no momento — a forte preferência de um clínico, um fluxo de trabalho que o sistema antigo apoiava, um relatório que alguém exige —, mas cada uma é uma dívida paga a cada atualização e uma superfície de segurança clínica que ninguém retesta. Discutam se vocês têm um princípio declarado de configurar o apoiado ou se as decisões de personalização são tomadas ad hoc, módulo a módulo, sob pressão de entrega. Tragam à tona a tensão real: adotar o conteúdo testado do fornecedor é mais seguro e mais barato de manter, mas obriga os clínicos a mudar como trabalham, e "o produto não faz do nosso jeito" é um lobby poderoso. Examinem quem aprova uma exceção, se cada uma é documentada e avaliada quanto ao risco e se alguém alguma vez revisita e aposenta as personalizações que vocês já carregam. Considerem como isso se agrava ao longo de uma década e como molda a sua capacidade de absorver atualizações futuras com limpeza. Uma boa resposta, honesta, descreve um padrão explícito, uma via nomeada para aprovar e assumir exceções e um relato realista de quanta construção sob medida vocês já estão comprometidos a manter.

5. Depois da entrada em produção, quem continua melhorando o EPR — e isso é financiado como função permanente ou esperado como favor? Grande parte do valor prometido de um EPR se realiza nos anos seguintes à virada, por meio do ajuste iterativo de fluxos de trabalho, conjuntos de pedidos e alertas, e, no entanto, as organizações rotineiramente dissolvem o programa na entrada em produção e esperam que a otimização aconteça de graça. Discutam se vocês têm uma equipe permanente de informática clínica e otimização, com pessoal e orçamento protegidos, ou se a melhoria depende de boa vontade quando o dinheiro do projeto acaba. Pesem a concessão entre gastar para sustentar essa capacidade e a pressão para contabilizar economias imediatamente no caso de negócio. Sondem como os benefícios são de fato acompanhados: são baseados em linha de base antes da entrada em produção, ligados a responsáveis nomeados e a mudanças específicas de fluxo de trabalho e revistos frente ao caso em intervalos definidos, ou silenciosamente supostos como alcançados? Considerem como vocês decidem quais alertas aposentar, quais conjuntos de pedidos revisar e como a linha de frente solicita e vê as mudanças. Uma boa resposta nomeia uma função permanente e dotada de recursos, com um ritmo claro de realização de benefícios, e não um projeto que termina na virada.

6. Estamos otimizando para o nosso hospital ou para o sistema mais amplo por onde um paciente de fato circula? A atração estratégica num sistema de cuidados integrados é rumo a menos instâncias de EPR e a um prontuário de cuidados compartilhado, para que a informação acompanhe o paciente entre hospital, comunidade, saúde mental e atenção primária, em vez de parar a cada porta de entrada. Discutam se as suas escolhas de EPR reforçam ou minam isso: vocês insistem em padrões abertos e interoperabilidade limpa, ou estão construindo uma ilha bem administrada? Tragam à tona a tensão genuína entre a convergência — que pode cortar custos e suavizar o fluxo, mas concentra risco e atropela a preferência clínica local — e a forte interoperabilidade entre sistemas distintos, que preserva a autonomia ao preço de mais interfaces. Examinem o quanto vocês estão expostos à dependência de fornecedor e se têm uma estratégia realista de saída e a capacidade de tirar os próprios dados. Considerem quem, no nível do ICS, está tomando essas decisões e se as suas decisões locais se alinham com elas. Uma boa resposta mostra uma posição explícita sobre convergência versus interoperabilidade, um compromisso com padrões abertos e saída segura e uma visão honesta de onde os interesses locais e do sistema hoje se afastam.

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

O Brackenmoor NHS Foundation Trust, um prestador de agudos e comunitário de porte médio, está substituindo três sistemas envelhecidos — um sistema de administração de pacientes, um sistema separado de comunicação de pedidos e uma colcha de retalhos de bancos de dados departamentais — por um único EPR de um fornecedor, financiado em parte pelo programa nacional de digitalização da linha de frente. Seu estágio atual no HIMSS EMRAM é baixo, e seu caso de negócio promete benefícios de segurança e eficiência com que o conselho está contando. A tentação, verbalizada cedo, é "levar e colocar" os velhos modos de trabalhar no novo sistema para minimizar a ruptura.

O programa resiste. Um CCIO (um consultor em exercício) e um CNIO (uma enfermeira sênior) são nomeados com tempo protegido e recebem aprovação conjunta sobre a construção clínica, apoiados por uma rede de campeões digitais que alcança cada enfermaria e clínica. Fixam um princípio firme: configurar conforme o modelo apoiado do fornecedor e adotar seus conjuntos de pedidos testados sempre que clinicamente seguro, personalizando apenas onde uma necessidade genuína não pode ser atendida de outro modo, com cada exceção documentada e avaliada quanto ao risco pelo processo de segurança clínica sob a DCB0160. Os conjuntos de pedidos e os alertas de apoio à decisão são projetados com as especialidades que os usarão, com uma inclinação deliberada para menos alertas e de maior valor, a fim de evitar soterrar a equipe em pop-ups.

A migração de dados é conduzida como um exercício clínico, e não apenas técnico. As equipes clínicas decidem que problemas ativos, alergias, medicamentos atuais e resultados-chave migram para o prontuário estruturado; o histórico mais antigo é resumido ou deixado num arquivo somente leitura dos sistemas legados, alcançável com um clique. Os clínicos reconciliam e aprovam amostras dos dados migrados antes da entrada em produção, e a equipe pega um erro de mapeamento que havia truncado em silêncio algumas entradas de alergia — uma correção feita antes, e não depois, de poder prejudicar alguém. O conselho acorda uma queda de produtividade planejada: a atividade eletiva é reduzida em uma quantidade acordada por seis semanas em torno da entrada em produção, o tempo de treinamento é reservado e as trajetórias de recuperação são definidas para que a queda seja um evento gerido, e não uma surpresa.

O Brackenmoor escolhe uma implantação faseada por local, em vez de um único big bang em todo o hospital, aceitando integração extra e operação em paralelo em troca da chance de aprender entre as fases. Cada virada passa por um centro de comando ensaiado, com apoio intenso de acompanhamento nas enfermarias nas duas primeiras semanas. Antes da primeira entrada em produção, o hospital conduz um exercício completo de indisponibilidade — acesso somente leitura ao prontuário, fluxos em papel e reconciliação de volta ao sistema — porque o ciberincidente de um hospital vizinho tornou o risco vívido. Depois da entrada em produção, o programa não se dissolve: vira uma função permanente de otimização e de informática clínica que ajusta fluxos de trabalho e alertas, acompanha os benefícios prometidos frente ao caso de negócio e leva o hospital deliberadamente a subir na escala EMRAM nos dois anos seguintes.

Perspectivas setoriais#

Startup#

Uma startup de saúde digital raramente vende um EPR completo, mas vive ou morre pelo quanto se encaixa em um. Projete para a realidade de que os hospitais rodam num sistema clínico central que você não controla: apoie padrões abertos como HL7 e FHIR, integre-se pelo motor de integração do hospital em vez de exigir uma ligação sob medida e escreva de volta no prontuário de forma limpa e segura. Sua via mais rápida para a adoção é reduzir, e não aumentar, a carga de cliques do clínico dentro do EPR que ele já usa. Trate o ecossistema do fornecedor do EPR e a governança da informação do hospital como restrições em torno das quais projetar, e não obstáculos de que reclamar.

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 — normalmente compra um sistema clínico em vez de construí-lo e carrega os mesmos deveres de registro, segurança e governança da informação de um grande hospital, sem nenhum dos seus recursos de TI. Escolha um produto apoiado e bem integrado e resista à personalização local que você não consegue manter, porque não há equipe interna para pagar essa dívida a cada atualização. Trate a migração de dados do seu sistema antigo como tarefa de segurança clínica mesmo em pequena escala: alergias, medicamentos atuais e problemas ativos precisam chegar intactos e ser conferidos por um clínico, e não presumidos corretos porque a carga rodou. Planeje também a queda de produtividade — um punhado de clínicos aprendendo um novo sistema pode paralisar um pequeno consultório; portanto, proteja o tempo de treinamento e escalone a mudança em vez de ligar tudo de uma vez. Acima de tudo, insista em interoperabilidade e em um prontuário de cuidados compartilhado, para que a informação dos seus pacientes os acompanhe até o sistema mais amplo, e numa saída realista, para que um único fornecedor não seja dono dos seus dados.

Grande organização#

Um grande hospital do NHS ou um ICS que conduz um programa de EPR está assumindo um compromisso de uma década e de muitos milhões de libras que remodela todo fluxo de trabalho clínico. Seus desafios centrais são a propriedade clínica em escala, a configuração disciplinada em vez da personalização desenfreada, uma forma de implantação exequível e o fôlego para financiar a otimização e a realização de benefícios muito depois da entrada em produção. A convergência entre o ICS rumo a menos instâncias de EPR oferece prêmios reais — prontuários compartilhados, fluxo de pacientes mais suave, menor custo unitário —, mas concentra risco e pode atropelar a preferência clínica local; deve, portanto, ser conduzida com engajamento genuíno e uma visão lúcida da dependência de fornecedor. Nessa escala, os maiores retornos vêm de algumas disciplinas mantidas de modo consistente — liderança clínica, configuração apoiada, virada ensaiada, otimização contínua —, e não de heroísmo em qualquer módulo isolado.

Governo#

Os órgãos nacionais moldam o ambiente em que todo programa de EPR opera. Por meio do programa de digitalização da linha de frente do NHS England, o governo fixa a expectativa de que todo prestador tenha um EPR central, atrela o financiamento de capital à maturidade digital e conduz o mercado por meio de convergência e de marcos de aquisição. Sua alavancagem é tornar os padrões abertos, a interoperabilidade e a saída segura os termos padrão do mercado, para que os hospitais individuais não negociem cada um a partir da fraqueza frente a um pequeno número de grandes fornecedores (ver Tópico 9.1 — Trabalho com governos locais e nacionais). O governo também carrega o dever de aprendizado de todo o sistema: difundir o que funciona entre hospitais, avaliar a maturidade nacionalmente e garantir que um prontuário de cuidados compartilhado melhore o cuidado através das fronteiras organizacionais, em vez de parar na porta de entrada de cada hospital.

Modos de falha comuns#

• O programa clinicamente vazio. Um projeto tecnicamente bem conduzido que trata os clínicos como consultados produz um sistema que ninguém quer usar. Deem ao CCIO e ao CNIO autoridade real, tempo protegido e direitos de decisão sobre a construção.
• Pavimentar os caminhos de vaca. Reconstruir velhos formulários em papel e fluxos legados dentro de um EPR moderno paga por software novo e herda os problemas antigos. Adotem o conteúdo testado do produto apoiado e redesenhem os fluxos em vez de replicá-los.
• Personalização desenfreada. Toda mudança sob medida é paga de novo a cada atualização e reabre uma superfície de segurança que ninguém retesta. Configurem conforme o modelo apoiado; documentem, avaliem o risco e assumam cada exceção verdadeira.
• A migração que "rodou limpa". Uma carga sem erros técnicos ainda pode perder alergias ou confundir pacientes. Reconciliem e aprovem clinicamente os dados migrados antes da entrada em produção e mantenham um arquivo legado alcançável.
• Fingir que não há queda. Supor uma curva suave de produtividade transforma uma desaceleração normal pós-entrada em produção num desastre percebido. Planejem, financiem e façam o conselho endossar uma janela de atividade reduzida, com recuperação realista.
• Parar na entrada em produção. Tratar o EPR como um projeto que termina na virada deixa seus benefícios sem realização. Montem uma função permanente de otimização e de realização de benefícios.
• Sobrecarga de alertas. Disparar alertas de apoio à decisão de baixo valor demais ensina os clínicos a clicar sobre todos eles, inclusive os que importam. Ajustem, meçam as taxas de anulação e aposentem o ruído.
• Planos de contingência não testados. Um fichário de contingência que ninguém abriu não é um plano. Ensaiem indisponibilidades planejadas e não planejadas, inclusive a reconciliação de volta ao prontuário.

Modelo de maturidade#

Lista de verificação#

• Um CCIO e um CNIO estão nomeados, com tempo protegido, orçamento e direitos reais de decisão sobre a construção clínica, apoiados por uma rede de campeões digitais.
• O programa configura por padrão conforme o modelo apoiado do fornecedor; toda personalização é documentada, avaliada quanto ao risco e tem responsável.
• A forma de implantação (big bang versus faseada/modular) é escolhida deliberadamente frente ao apetite por risco e à complexidade de integração, com virada ensaiada e plano de recuo.
• A migração de dados é conduzida como exercício clínico: escopo da migração acordado, dados reconciliados e aprovados clinicamente e um arquivo legado alcançável fornecido.
• Uma queda de produtividade está planejada, financiada e endossada pelo conselho, com atividade reduzida, treinamento protegido e trajetórias de recuperação realistas.
• Os conjuntos de pedidos e os alertas de apoio à decisão são codesenhados com clínicos e governados continuamente, com taxas de disparo e de anulação de alertas monitoradas.
• Procedimentos de contingência e de continuidade de negócios — acesso somente leitura, fluxos em papel, RTO/RPO acordados, reconciliação — existem e são ensaiados para indisponibilidades planejadas e não planejadas.
• Os benefícios têm linha de base antes da entrada em produção, são ligados a responsáveis nomeados e a mudanças de fluxo de trabalho e revistos frente ao caso de negócio depois.
• A maturidade digital é avaliada (p. ex., HIMSS EMRAM) e usada para acompanhar o progresso com o conselho.
• Uma função permanente de otimização e de informática clínica continua após a virada.
• Padrões abertos, interoperabilidade e uma estratégia realista de saída são garantidos para limitar a dependência de fornecedor, alinhados aos planos de convergência do ICS.

Fontes-chave#

• NHS England — programa Frontline Digitisation e arcabouços de maturidade digital What Good Looks Like / Who Pays for What para sistemas clínicos de prestadores.
• HIMSS — Electronic Medical Record Adoption Model (EMRAM), uma referência internacional de 0 a 7 da maturidade digital dos sistemas clínicos.
• NHS England / NHS Digital — normas de segurança clínica DCB0129 (fabricação) e DCB0160 (implantação) que regem sistemas de TI em saúde, incluindo os EPRs.
• Faculty of Clinical Informatics e CCIO/CNIO Network — orientações profissionais para os papéis de liderança em informação clínica.
• HL7 International — padrões HL7 v2 e FHIR para mensagens e integração entre sistemas clínicos.
• HM Treasury — The Green Book e Five Case Model para o caso de negócio de um EPR e a realização de benefícios.
• Wachter Review (Making IT Work, 2016) e Topol Review — revisões nacionais sobre a digitalização dos prestadores do NHS e a força de trabalho clínica.

Referências#

1. Electronic health record — Wikipedia — https://en.wikipedia.org/wiki/Electronic_health_record
2. Hospital information system — Wikipedia — https://en.wikipedia.org/wiki/Hospital_information_system
3. Computerized physician order entry — Wikipedia — https://en.wikipedia.org/wiki/Computerized_physician_order_entry
4. Clinical decision support system — Wikipedia — https://en.wikipedia.org/wiki/Clinical_decision_support_system
5. Big bang adoption — Wikipedia — https://en.wikipedia.org/wiki/Big_bang_adoption
6. Chief medical informatics officer — Wikipedia — https://en.wikipedia.org/wiki/Chief_medical_informatics_officer
7. Health informatics — Wikipedia — https://en.wikipedia.org/wiki/Health_informatics
8. Data migration — Wikipedia — https://en.wikipedia.org/wiki/Data_migration
9. Health Level 7 — Wikipedia — https://en.wikipedia.org/wiki/Health_Level_7
10. Health information exchange — Wikipedia — https://en.wikipedia.org/wiki/Health_information_exchange
11. Healthcare Information and Management Systems Society — Wikipedia — https://en.wikipedia.org/wiki/Healthcare_Information_and_Management_Systems_Society
12. NHS England — Frontline Digitisation — NHS England — https://www.england.nhs.uk/digitalhealth/connecting-frontline-digitisation/
13. NHS England — What Good Looks Like framework — NHS England — https://www.england.nhs.uk/digitalhealth/what-good-looks-like/
14. HIMSS — Electronic Medical Record Adoption Model (EMRAM) — HIMSS — https://www.himss.org/what-we-do-solutions/digital-health-transformation/maturity-models/electronic-medical-record-adoption-model-emram
15. NHS Digital — Clinical Safety standards DCB0129 and DCB0160 — NHS England — https://digital.nhs.uk/services/clinical-safety
16. Robert Wachter — Making IT Work: Harnessing the Power of Health Information Technology to Improve Care in England — GOV.UK — https://www.gov.uk/government/publications/using-information-technology-to-improve-the-nhs
17. Faculty of Clinical Informatics — professional body for clinical informaticians — FCI — https://facultyofclinicalinformatics.org.uk/