1. Defina a tese de investimento em torno de um trabalho delimitado a ser realizado
Empresas de voz e fluxo de trabalho em saúde AI devem ser avaliadas com base em um trabalho delimitado a ser realizado. O investidor deve declarar qual usuário executa qual tarefa, em qual ambiente de cuidado, usando qual insumo, produzindo qual resultado, com qual obrigação de revisão e resultado econômico mensurável. “ AI para saúde” é amplo demais para sustentar a diligência devida. Documentação ambiente para clínicos ambulatoriais, chamadas autônomas de pacientes, resumos de passagem de plantão hospitalar, sugestões de codificação e preparação de autorização prévia ocupam posições clínicas, regulatórias e econômicas diferentes.
O perímetro do produto deve distinguir captura, transcrição, extração, sumarização, recomendação, preparação de ações e execução de ações. A captura registra ou transmite fala. A transcrição converte áudio em texto. A extração identifica fatos especificados. A sumarização comprime informações. A recomendação propõe um julgamento ou próximo passo. A preparação de ações cria um pedido, mensagem, cobrança ou tarefa para revisão. A execução de ações altera um registro, inicia comunicação ou afeta o cuidado. O risco aumenta à medida que o produto avança da representação para o julgamento e a execução.
A tese deve identificar o comprador, o orçamento, o beneficiário e o detentor do veto. Um diretor de informações médicas pode patrocinar o caso clínico. Operações pode ser responsável pela implantação. Equipes de segurança e privacidade podem aprovar fluxos de dados. Finanças pode exigir um caso de produtividade ou retenção. Clínicos e pacientes determinam a adoção prática. Compras pode impor condições de integração, seguro e contratuais. Uma empresa pode ter usuários entusiasmados e uma venda corporativa bloqueada quando esses papéis não estão alinhados.
A questão da diligência devida é, portanto, causal: o produto cria uma melhoria repetível em um fluxo de trabalho de alto valor, sob os controles exigidos pelos clientes, a um custo de implantação e suporte que permita economia unitária durável? A resposta deve ser testada por meio de evidências de fluxo de trabalho, desempenho em produção, direitos, dados de coorte e referências de clientes. Entusiasmo de mercado, qualidade da demonstração e sofisticação do modelo permanecem como contexto de apoio.
Tabela 1. Mapa do perímetro do produto e do uso pretendido
| Função do produto | Saída principal | Revisor responsável | Questão principal de diligência |
|---|---|---|---|
| documentação ambiente | rascunho de nota de atendimento | clínico assistente | o rascunho reduz o trabalho total preservando a precisão? |
| suporte à codificação | código sugerido ou evidência | responsável qualificado em codificação ou clínico | a sugestão melhora o rendimento em conformidade sem codificação inflada? |
| fluxo de trabalho da caixa de entrada | mensagem priorizada e rascunho de resposta | membro autorizado da equipe assistencial | a urgência, o roteamento e o escalonamento são confiáveis? |
| preparação do pedido | rascunho de pedido ou encaminhamento | clínico autorizado | o usuário pode revisar a base antes da ação? |
| agente de voz para pacientes | conversa e tarefa | responsável clínico ou de serviço designado | identidade, consentimento, limites e escalonamento estão controlados? |
| fluxo de trabalho de autorização prévia | pacote de evidências e status | responsável pelo ciclo de receita | Reduz o tempo de ciclo e o retrabalho entre as diferentes regras dos pagadores? |
A classificação e as obrigações exigem assessoria jurídica e regulatória específica da jurisdição.
2. Mapeie o fluxo de trabalho completo antes de avaliar o modelo
A acurácia do modelo só tem significado dentro de um fluxo de trabalho. A diligência devida deve começar com observação direta, evidências de tela, logs de sistemas e entrevistas com usuários que reconstruam o processo atual e o proposto. O mapa começa antes de o modelo receber dados e termina após a ação final do usuário, a reconciliação a jusante e o tratamento de exceções. Ele deve mostrar identidades, sistemas, filas, transferências de responsabilidade, pontos de revisão, estados de espera e recuperação de falhas.
Para a documentação ambiente, o fluxo de trabalho pode incluir notificação ou consentimento do paciente, seleção de microfone, início da sessão, separação de falantes, transmissão de áudio, transcrição, extração estruturada, geração de notas, revisão por clínico, edição, atestação, codificação, gravação de volta no prontuário e exclusão ou retenção. Cada etapa pode falhar de forma independente. Uma transcrição forte ainda pode produzir uma nota ruim. Uma boa nota ainda pode aumentar o trabalho quando a navegação no EHR, a seleção de modelo, a atribuição ou a assinatura são difíceis.
O mapa deve registrar tempo e qualidade tanto para o processo antigo quanto para o novo. O tempo economizado durante o ditado pode ser compensado por edição, busca, interrupções do fluxo de trabalho ou correções fora do horário. Um produto pode transferir trabalho de clínicos para assistentes médicos, codificadores, equipes de suporte ou equipes de implementação. O investidor deve quantificar o trabalho total do sistema e identificar quem o absorve.
A adequação ao fluxo de trabalho também varia por especialidade e tipo de atendimento. Uma consulta curta de atenção primária, uma consulta pediátrica com vários falantes, um atendimento de saúde mental, uma visita ao pronto-socorro e uma discussão de consentimento cirúrgico têm vocabulário, alternância de fala, privacidade e estruturas de documentação diferentes. A amostra de diligência devida deve representar o plano de expansão comercial, e não o caso de uso atual mais fácil.
O mapa identifica a cadeia completa de controle; os fluxos de trabalho reais variam conforme o produto, o ambiente de cuidado e a jurisdição.
3. Monte a sala de evidências em torno da realidade de produção
A sala de diligência devida deve ser organizada em torno das afirmações que importam para clientes e investidores. Para cada afirmação, a empresa deve fornecer a definição, a população de medição, o período, o comparador, o sistema de origem, as exclusões, o método estatístico, o responsável e o resultado reproduzível. As evidências devem distinguir testes internos, pilotos com clientes, implantações em produção, estudos revisados por pares e estimativas de marketing.
Os materiais principais incluem especificações do produto, declarações de uso pretendido, fichas de modelo, planos de validação, conjuntos de dados de teste, históricos de versões, registros de incidentes, arquivos de segurança clínica, avaliações de privacidade, relatórios de segurança, diagramas de arquitetura, mapas de fluxo de dados, contratos de clientes, acordos de associado comercial, listas de subprocessadores, planos de implementação, tickets de suporte, registros de disponibilidade, evidências de integração com EHR, receita por coorte, faturas, contas de nuvem e permissões de referência de clientes. A lista de solicitações deve conectar cada documento a uma questão de investimento.
Os registros de produção merecem atenção especial. Eles podem mostrar tentativas de atendimento, capturas bem-sucedidas, abandono, latência, geração de saídas, tempo de revisão, distância de edição, aceitação, gravação de retorno, erro, sobrescrita e eventos de suporte. O investigador deve conciliar as definições de eventos entre versões. Uma métrica pode melhorar porque um atendimento falho ou difícil desapareceu do denominador. Uma versão do produto pode alterar o registro em log antes de alterar o desempenho.
A sala de evidências deve preservar evidências negativas. Pilotos fracassados, coortes com baixa adoção, preocupações com segurança, restrições de direitos sobre dados, integrações não lucrativas e churn de clientes podem revelar os limites da repetibilidade. A gestão deve explicar se o problema surgiu da capacidade do produto, do desenho do fluxo de trabalho, da prontidão do cliente, da precificação, da implementação, da governança ou da concorrência. O investidor pode então testar se o plano atual aborda a causa.
Tabela 2. Inventário de evidências para diligência de investidor de crescimento
| Domínio de evidências | Evidência mínima | Teste de conciliação | Uso na decisão |
|---|---|---|---|
| produto | especificações, versões, notas de versão | as alegações correspondem às funções entregues | risco de escopo e de roadmap |
| modelo | conjuntos de dados, avaliações, falhas, monitoramento | a população de teste corresponde ao uso | confiança no desempenho |
| fluxo de trabalho | registros, observações, referências de usuários | o trabalho total e as exceções se conciliam | adoção e valor |
| direitos | contratos, avisos, consentimentos, licenças | todo uso tem uma base identificada | risco de dados e de propriedade intelectual |
| implantação | declarações de trabalho, tickets, integrações | esforço corresponde ao custo reportado | margem e escalabilidade |
| comercial | contratos, faturas, coortes, churn | bookings como ponte para caixa e retenção | qualidade da receita |
A profundidade exigida deve refletir o uso pretendido do produto, a abrangência de clientes e a materialidade da transação.
4. Crie um registro de direitos sobre dados para cada finalidade de processamento
Uma empresa de saúde AI pode possuir dados sem deter todos os direitos exigidos por seu produto e plano de crescimento. A diligência devida deve separar o direito de receber dados do direito de processá-los para uma finalidade específica. Gravação, transcrição, geração de notas, armazenamento, garantia de qualidade, suporte, avaliação de modelos, aprimoramento do produto, treinamento de modelos, benchmarking e exportação de dados de clientes podem exigir diferentes análises contratuais, de privacidade, de consentimento e regulatórias.
O registro deve identificar categoria de dados, titular, origem, controlador ou entidade coberta, operador ou business associate, subprocessador, localização, finalidade, base legal ou contratual, retenção, exclusão, exportação, uso para treinamento, direito de auditoria e responsabilidade por incidentes. O áudio merece tratamento separado da transcrição e do texto gerado. O áudio pode conter vozes de pacientes, familiares, profissionais de saúde e pessoas presentes. Características derivadas, embeddings, rótulos e feedback de modelos podem manter sensibilidade ou restrições contratuais.
O HHS declara que entidades cobertas que usam business associates exigem acordos escritos que especifiquem funções permitidas e salvaguardas para informações de saúde protegidas.[7] As orientações do HHS sobre nuvem também tornam relevante um contrato de business associate quando um serviço de nuvem cria, recebe, mantém ou transmite informações de saúde protegidas eletrônicas em nome de uma entidade coberta ou business associate.[8] Produtos fora do perímetro de entidade coberta e business associate da HIPAA ainda podem enfrentar outras obrigações de privacidade e de violação de dados. A Regra de Notificação de Violação de Saúde da FTC é um exemplo nos EUA para fornecedores cobertos de registros pessoais de saúde e entidades relacionadas.[19]
Os direitos devem ser testados em casos de rescisão e mudança de controle. O investidor deve determinar se um cliente pode revogar direitos de aprimoramento, exigir exclusão, proibir treinamento de modelos, restringir processamento transfronteiriço ou exigir assistência para migração. A empresa deve demonstrar como a linhagem de dados sustenta essas obrigações. A linguagem contratual e a capacidade do sistema devem estar alinhadas.
Cada finalidade de tratamento exige sua própria evidência; o número não determina uma base legal.
5. Entenda o modelo e a cadeia de suprimentos de software
O produto pode combinar reconhecimento de fala, diarização de locutor, detecção de idioma, vocabulários especializados, recuperação, modelos de linguagem de grande porte, regras, templates, mecanismos de codificação e orquestração de fluxos de trabalho. A diligência devida deve identificar quais componentes são proprietários, licenciados, de código aberto, específicos do cliente ou fornecidos por terceiros. A arquitetura deve mostrar onde cada componente é executado, quais dados ele recebe e qual saída ele controla.
A análise de dependências deve abranger termos de modelos de fundação, termos de modelos de fala, concentração de hospedagem, limites de taxa, disponibilidade regional, mudanças de preço, descontinuação, filtros de segurança e direitos sobre a saída gerada. Uma empresa pode possuir a interface e a lógica do fluxo de trabalho enquanto depende de um pequeno número de provedores upstream para a inferência principal. Isso ainda pode ser um modelo de negócio atraente, mas o investidor deve precificar o custo de substituição e o poder de negociação.
O registro de modelos deve registrar finalidade, versão, entrada, saída, método de treinamento ou adaptação, população de avaliação, limitações conhecidas, uso aprovado, monitoramento e autoridade de liberação. Regras determinísticas, modelos estatísticos e sistemas generativos devem permanecer distintos porque seus erros e métodos de teste diferem. Uma única versão de produto pode conter várias versões de modelo e configurações de prompt ou de recuperação.
O controle de alterações é central. A orientação da FDA sobre planos de controle de alterações predeterminadas e gestão do ciclo de vida mostra por que modificações planejadas, validação e monitoramento importam para funções de dispositivo habilitadas por AI.[4][5] A aplicação regulatória exata depende do uso pretendido e da jurisdição. Mesmo quando o software está fora da regulamentação de dispositivos, os clientes ainda precisam de evidências de que alterações materiais são avaliadas antes da liberação e de que regressões podem ser detectadas, contidas e revertidas.
O investidor deve testar o caminho de substituição de emergência. A empresa consegue trocar um modelo upstream sem perder funcionalidade, direitos, latência, geografia ou economia unitária? Ela tem testes de regressão e regras de notificação ao cliente? A opcionalidade da arquitetura só é valiosa quando foi exercitada ou evidenciada.
6. Avalie o desempenho na unidade de decisão do fluxo de trabalho
A precisão agregada da transcrição é uma medida incompleta. O investidor deve testar a unidade que afeta o fluxo de trabalho e o cuidado: um medicamento, alergia, sintoma, diagnóstico, duração, negação, atribuição de locutor, tarefa, código, elemento de pedido, classificação de urgência ou instrução ao paciente. Uma nota pode ser lida fluentemente enquanto omite um fato clinicamente material ou o atribui ao locutor errado.
O plano de avaliação deve definir uso pretendido, população, cenário, padrão de referência, adjudicação, métricas, limiares e resposta a falhas. Ele deve incluir positivos conhecidos, negativos conhecidos, casos limite difíceis e condições fora da distribuição. As amostras devem abranger especialidades, tipos de atendimento, sotaques, idiomas, ruído, telessaúde, interrupções, vários locutores e grupos de pacientes relevantes. O roteiro comercial deve determinar a matriz de testes.
As dimensões de desempenho incluem completude factual, correção factual, conteúdo sem suporte, negação, temporalidade, atribuição de locutor, estrutura, extração de ações, latência e abstenção. As dimensões do fluxo de trabalho incluem tempo de revisão, distância de edição, aceitação, sobrescrita, abandono, uso de suporte e correção a jusante. As dimensões de segurança concentram-se em erros clinicamente materiais e em se os controles os detectam antes da ação.
A empresa deve preservar resultados versionados. Uma pontuação global pode melhorar enquanto um subgrupo material regride. Portanto, os limiares devem ser definidos por caso de uso e dano, não por conveniência de marketing. Os dados de avaliação devem ser suficientemente independentes dos dados de desenvolvimento, e o ajuste específico do cliente deve ser separado do desempenho do produto principal.
Tabela 3. Desenho de avaliação de modelos por unidade de decisão
| Unidade de decisão | Exemplo de falha | Medida de avaliação | Revisão necessária |
|---|---|---|---|
| medicamento | erro de nome, dose ou negação | erro exato e clinicamente ponderado | clínico ou revisor qualificado |
| falante | sintoma atribuído à pessoa errada | precisão e recall de atribuição | adjudicação no nível do atendimento |
| fato do resumo | declaração omitida ou não sustentada | completude factual e suporte | revisão de referência cega |
| tarefa | urgência não detectada ou encaminhamento incorreto | sensibilidade, especificidade e escalonamento | responsável operacional e clínico |
| ação no fluxo de trabalho | gravação de retorno não autorizada ou incorreta | sucesso e recuperação de ações controladas | responsável pela segurança e pelo sistema |
As métricas e os limiares exigem um desenho clínico e estatístico específico do produto.
As pontuações são dimensões ilustrativas; os investidores devem usar métricas e limiares específicos do produto.
7. Testar a segurança clínica e a supervisão humana como sistemas operacionais
A supervisão humana deve ser especificada como um controle operacional. “Humano no circuito” não explica quem revisa, o que vê, quanto tempo tem, quais erros consegue detectar, o que acontece sob pressão de carga de trabalho ou como o sistema responde quando a revisão falha. A diligência devida deve mapear o papel responsável, a interface de revisão, a rota de escalonamento e as evidências retidas para cada resultado material.
O desenho da revisão deve expor o contexto da fonte e a incerteza quando útil. Um usuário pode precisar do trecho relevante da transcrição, do falante, do carimbo de data/hora, da confiança, do registro de apoio e do motivo de uma ação sugerida. Um rascunho longo e fluente pode tornar os erros mais difíceis de encontrar. O desenho da interface, a carga de alertas e a pressão de tempo afetam, portanto, a confiabilidade prática da supervisão humana.
As orientações da OMS sobre grandes modelos multimodais destacam riscos, incluindo resultados imprecisos, viés, viés de automação, privacidade e cibersegurança.[2] A DCB0129 do NHS exige gestão de risco clínico para fabricantes de TI em saúde, enquanto a DCB0160 aborda a implantação e o uso por organizações de cuidados.[12] Essas normas ilustram a responsabilidade compartilhada entre produto e adotante. A empresa deve apresentar um registro de perigos, um dossiê de segurança clínica ou um arquivo de risco equivalente adequado aos seus mercados e uso.
A gestão de incidentes deve conectar a telemetria do produto, os relatos de clientes, a revisão clínica, a investigação de engenharia e os direitos de decisão executiva. As definições de gravidade devem captar danos potenciais e quase-acidentes, não apenas danos confirmados. Incidentes materiais devem desencadear contenção, comunicação ao cliente, análise de causa raiz, ação corretiva, testes de regressão e monitoramento.
O investidor deve testar o modo degradado. Se a transcrição, a inferência, a conectividade com o EHR ou a resolução de identidade falhar, o usuário consegue continuar a prestar cuidados com segurança? O fluxo de trabalho precisa de status claro, nenhuma gravação de retorno silenciosa, regras de nova tentativa e uma rota manual. Um caminho de falha seguro pode ser mais importante do que o desempenho médio do modelo.
8. Examinar o desempenho por subgrupo, o idioma e a acessibilidade
Produtos de voz operam em diferentes sotaques, idiomas, alternância de código, deficiências de fala, faixas etárias, qualidade de microfone e ambientes clínicos. Um resultado agregado pode ocultar desempenho fraco em populações comercialmente importantes ou vulneráveis. A diligência devida deve alinhar os testes por subgrupo à pegada de implantação e ao plano de expansão da empresa.
A empresa deve explicar como define grupos, obtém dados de avaliação lícitos, estabelece a verdade de referência e evita conclusões instáveis a partir de amostras pequenas. As diferenças de desempenho devem ser avaliadas em unidades clinicamente e operacionalmente significativas. Uma diferença modesta na taxa de erro de palavra pode se tornar relevante quando afeta nomes de medicamentos, negação, números ou sintomas urgentes.
O suporte a idiomas deve distinguir a tradução da interface do usuário, o reconhecimento de fala, o vocabulário clínico, a geração de notas e a execução do fluxo de trabalho. Um produto pode reconhecer fala conversacional em um idioma, mas não ter termos especializados validados, modelos ou campos de EHR a jusante. Atendimentos em idiomas mistos exigem evidências separadas. Rótulos de marketing como multilíngue devem ser decompostos em funções e configurações testadas.
A acessibilidade inclui necessidades auditivas, de fala, cognitivas, visuais e motoras, bem como letramento digital. Agentes de voz voltados ao paciente devem lidar com repetição, interrupção, incerteza, participação de intérprete e transferência para um humano. Devem evitar criar uma barreira para pessoas que não podem ou não desejam usar automação de voz.
Os princípios mais amplos de governança de AI da OMS colocam a inclusão e a equidade ao lado da autonomia, segurança, transparência, responsabilidade e sustentabilidade.[1] O investidor deve traduzir esses princípios em avaliação de subgrupos versionada, critérios de implantação para clientes, monitoramento e remediação. O modelo comercial deve incluir o custo de apoiar as populações que promete atender.
9. Auditar privacidade, consentimento, segurança e resiliência
O mapa de fluxo de dados deve acompanhar áudio, transcrição, conteúdo gerado, identificadores, metadados, logs, acesso de suporte, backups e feedback do modelo em dispositivos, redes, nuvens, subprocessadores e sistemas de clientes. Cada transferência precisa de um responsável, finalidade, proteção, regra de retenção e rota de incidentes. Certificados de segurança e testes de penetração são evidências úteis, mas não substituem um modelo de ameaças específico da arquitetura.
A voz cria riscos específicos. A captura sempre ativa ou ambiente pode incluir interlocutores não intencionais e discussões sensíveis. Controles de início e fim de sessão, status visível, consentimento ou aviso, permissões de microfone, armazenamento temporário local e comportamento de exclusão exigem testes. O produto deve impedir que o conteúdo de um paciente entre no registro de outro e deve expor a incerteza de identidade antes da gravação de volta.
A diligência devida de segurança deve abranger autenticação, acesso por função, privilégio mínimo, criptografia, gestão de chaves, segredos, isolamento entre locatários, cadeia de suprimentos de software, gestão de vulnerabilidades, desenvolvimento seguro, registro de logs, detecção de anomalias, backup, recuperação e notificação ao cliente. Sistemas generativos acrescentam injeção de prompt, vazamento de dados, conteúdo malicioso, envenenamento de recuperação e dependência de serviços de modelo. O RMF de AI do NIST e o Perfil de AI Generativa fornecem uma referência estruturada de gestão de riscos.[13]
Para funções reguladas de dispositivo, a orientação de cibersegurança da FDA de 2026 aborda considerações de design, sistema de qualidade e submissão.[5] A aplicação, novamente, depende do produto e do uso pretendido. Todas as empresas devem demonstrar resiliência por meio de objetivos de recuperação testados, falhas de dependência e exercícios de incidentes.
As promessas contratuais devem ser conciliadas com as operações. Se o contrato promete processamento regional, exclusão rápida, aviso sobre subprocessadores ou um objetivo de recuperação, a empresa deve apresentar evidências do sistema. Uma lacuna entre a linguagem de vendas e a capacidade de produção pode se tornar um risco de renovação, responsabilidade e avaliação.
10. Classificar a exposição regulatória por função e jurisdição
A classificação regulatória segue o uso pretendido e a função, não a categoria preferida da empresa. Uma ferramenta de documentação que registra e redige uma nota pode ocupar uma posição diferente do software que recomenda diagnóstico, prioriza sintomas urgentes ou executa uma ordem médica. Portanto, módulos de produto e alegações devem ser classificados separadamente.
Nos Estados Unidos, a orientação sobre suporte à decisão clínica da FDA de janeiro de 2026 explica critérios para certas funções de CDS que não constituem dispositivo e fornece exemplos que distinguem software que não é dispositivo de software de dispositivo.[3] As demais orientações de saúde digital da FDA abordam software de dispositivo habilitado por AI, controle de alterações e cibersegurança.[4][5] A regra HTI-1 da ONC acrescenta requisitos de transparência de algoritmos para suporte à decisão preditivo fornecido por meio de TI de saúde certificada.[6] A equipe de diligência devida deve mapear se a empresa é uma desenvolvedora de TI de saúde certificada, integra-se a uma ou fornece funcionalidade que aciona repasse contratual.
Na União Europeia, a Lei AI cria obrigações com base na função do sistema e na classificação de risco, incluindo categorias de alto risco relacionadas a produtos regulamentados e usos especificados.[9] O Espaço Europeu de Dados de Saúde acrescenta requisitos faseados para dados de saúde eletrônicos e sistemas de registro eletrônico de saúde (EHR), preservando a aplicação das regras GDPR, de dispositivos médicos e AI.[10] As datas de vigência e o impacto no produto exigem análise atual específica da jurisdição.
No Reino Unido, as orientações da MHRA e o seu programa de software e AI como dispositivo médico enquadram a classificação do produto e as expectativas de ciclo de vida.[11] Implantações no NHS também podem exigir evidências de risco clínico, proteção de dados, segurança técnica, interoperabilidade e usabilidade por meio de normas e critérios de avaliação DCB.[12]
A matriz regulatória deve registrar módulo, alegação, usuário, ação, jurisdição, visão de classificação, evidência, registro ou certificação, deveres pós-comercialização e consequência da alteração. A conclusão da administração deve ser sustentada por assessoria qualificada quando material. Um rótulo como software administrativo não resolve a análise.
11. Avaliar criticamente a arquitetura de integração e a interoperabilidade
A integração faz parte do produto. O valor empresarial pode depender de identidade confiável, lançamento em contexto, correspondência de encontros, acesso à agenda, gravação de documentação de retorno, roteamento de tarefas, codificação, consentimento, auditoria e análise em todos os sistemas do cliente. Um fornecedor com modelos fortes e integração frágil pode enfrentar ciclos de vendas longos, alto custo de serviços e resultados variáveis.
A revisão da arquitetura deve identificar cada interface, protocolo, método de autenticação, objeto de dados, permissão de gravação, mecanismo de consulta periódica ou de eventos, latência, nova tentativa, fila de erros, observabilidade e responsável pelo suporte. Padrões como HL7 FHIR podem melhorar a portabilidade, mas a implementação do cliente, as versões, os perfis e as restrições proprietárias ainda importam.[20] Uma integração declarada deve ser comprovada em produção, e não inferida de uma especificação API.
O investidor deve distinguir conectores reutilizáveis de trabalho específico do cliente. A configuração reutilizável pode sustentar escala. Transformações sob medida, mapeamento de templates, redesenho de fluxos de trabalho, revisão de segurança e testes podem criar trabalho recorrente mesmo quando a interface técnica é padrão. Os dados de implementação devem mostrar horas por função, tempo decorrido, esperas por dependências, defeitos e suporte pós-implantação.
A gravação de retorno merece um caminho de controle separado. O sistema deve confirmar paciente, encontro, tipo de documento, autor, versão e aprovação final. Deve impedir gravações duplicadas ou desatualizadas e preservar uma trilha de auditoria. Gravações com falha precisam de uma fila visível e recuperação com responsável definido. O conteúdo clínico não deve desaparecer em um log de integração genérico.
O modelo de diligência devida deve valorizar a interoperabilidade por meio de evidências: menor tempo até a entrada em produção, menor custo de implementação, menos defeitos, maior adoção, menor carga de suporte e expansão mais fácil. A contagem de conectores por si só pode superestimar a prontidão quando as integrações são antigas, pouco usadas ou mantidas manualmente.
12. Converter a carga de implementação em custo total até a entrada em produção
Os clientes compram uma mudança funcional, e não um modelo isolado. O custo total até a entrada em produção inclui revisão de segurança e jurídica, governança clínica, compras, integração, configuração, desenho de fluxos de trabalho, treinamento, comunicações, suporte, medição e operação em paralelo. Esses custos podem recair sobre o fornecedor, o cliente, o parceiro de implementação ou o provedor de EHR. O investidor deve capturar o custo completo do sistema e identificar quem paga.
A implementação deve ser decomposta em etapas repetíveis: qualificação, contratação, aprovação de dados e segurança, construção técnica, configuração, revisão de segurança clínica, piloto, treinamento, entrada em produção, monitoramento e escala. Para cada etapa, a empresa deve fornecer mediana e distribuição de tempo decorrido, horas internas, horas do cliente, bloqueios, retrabalho e abandono. As médias podem ocultar uma cauda longa que consome caixa e atenção da liderança.
A curva de custo deve separar investimento fixo na plataforma, trabalho reutilizável de produto e trabalho específico do cliente. Coortes iniciais podem ser caras enquanto a empresa aprende. Coortes posteriores devem mostrar evidências de esforço decrescente para complexidade comparável. O crescimento criado ao adicionar pessoal de implementação na mesma proporção da receita tem economia diferente da repetibilidade liderada pelo produto.
A carga do lado do cliente afeta a adoção e a renovação mesmo quando não aparece no custo da receita do fornecedor. Os clínicos podem gastar tempo revisando, corrigindo e aprendendo. As equipes de informática podem manter templates e governança. As equipes de TI podem operar interfaces. A referência do cliente deve testar se o benefício realizado excede essa carga.
Os valores são hipotéticos; a diligência devida em curso exige horas por cliente, custos em caixa e evidências de tempo decorrido.
Tabela 4. Matriz de responsabilidades e custos de integração
| Frente de trabalho | Responsabilidade do fornecedor | Responsabilidade do cliente | Evidência de repetibilidade |
|---|---|---|---|
| segurança e privacidade | arquitetura, controles e respostas | revisão e aprovação de riscos | pacote padrão e tempo de ciclo |
| interface | conector e monitoramento | acesso, testes e controle de alterações | código reutilizável e histórico de defeitos |
| fluxo de trabalho | configuração do produto | desenho operacional e titularidade | escopo de configuração e adoção |
| segurança clínica | riscos do produto e controles | riscos de implantação e governança | arquivos aprovados e incidentes |
| treinamento e lançamento | materiais, capacitação e suporte | presença, campeões locais e políticas | tempo até o uso competente |
| mensuração de valor | telemetria e definições | linha de base, comparador e revisão de resultados | evidências de benefícios reconciliadas |
A matriz deve ser preenchida para cada segmento de cliente relevante e ambiente de EHR.
13. Reconstruir a economia do cliente a partir de coortes e uso
O valor anual contratado não comprova fundamentos econômicos duradouros. O investidor deve construir coortes por período de início, segmento, produto, geografia, EHR, complexidade de implantação e tipo de contrato. Cada coorte deve mostrar valor contratado, valor ativo, uso, expansão, contração, churn, custo de implementação, custo de suporte, custo de nuvem e de modelo, margem bruta, recebimento em caixa e concentração de clientes.
A ponte começa com usuários ou atendimentos elegíveis, usuários ativados, uso ativo, conclusão bem-sucedida do fluxo de trabalho, saída revisada e uso sustentado. As licenças por assento podem superestimar o valor quando o uso é baixo. A precificação por atendimento pode superestimar a previsibilidade quando o volume ou o mix de especialidades muda. A precificação empresarial pode ocultar usuários intensivos não lucrativos. O modelo comercial deve conciliar a unidade de precificação com os direcionadores de valor e de custo.
A retenção deve ser medida em várias bases. A retenção de logos captura a continuidade do relacionamento. A retenção de receita bruta exclui a expansão. A retenção de receita líquida inclui expansão e contração. A retenção de uso mostra se o produto permanece incorporado. A retenção de margem testa se a receita renovada continua econômica após inferência, suporte e integração. As definições e o tratamento cambial devem ser consistentes.
A expansão exige evidência causal. Um cliente pode adicionar clínicos porque o piloto funcionou, porque um orçamento separado foi aberto ou porque o fornecedor concedeu desconto para uma conversão empresarial. A expansão para codificação, caixa de entrada ou voz do paciente pode ter um comprador, uma revisão de risco e um modelo de suporte diferentes. O investidor deve separar a escala do mesmo produto das vendas cruzadas entre produtos.
As referências de clientes devem testar o comportamento contrafactual. O cliente renovaria pelo preço atual? Qual fluxo de trabalho mensurável mudou? Quais usuários se beneficiam e quais não? Que ônus permanece? Qual falha do produto levaria à remoção? O entusiasmo das referências deve ser reconciliado com faturas, uso e decisões de renovação.
14. Testar a qualidade da receita, o poder de precificação e a margem bruta
A qualidade da receita depende de contratos exequíveis, status de implantação, aceite, uso, renovação, cobrança e custo de entrega. Os bookings podem incluir pilotos, direitos de cancelamento, módulos futuros ou volumes contingentes. A diligência devida deve fazer a ponte entre contratos assinados e receita reconhecida, faturas, caixa e utilização ativa por cliente.
A precificação deve refletir a unidade de valor do cliente, permanecendo observável e governável. A precificação por clínico é simples, mas pode se descolar do volume de atendimentos. A precificação por atendimento alinha o uso, mas cria variabilidade de volume. A precificação empresarial apoia a previsibilidade orçamentária, embora exija controles para uso intensivo. A precificação vinculada a resultados pode ser atraente quando a medida, a linha de base e a atribuição são críveis. Estruturas híbridas podem se adequar a diferentes fluxos de trabalho.
O poder de precificação deve ser testado por meio do histórico de renovações, descontos, substituições competitivas, concessões de compras e disposição para expandir. Um preço de tabela alto com créditos extensivos de implementação, pilotos gratuitos ou módulos agrupados pode resultar em um preço líquido mais fraco. O investidor deve calcular o preço efetivo após incentivos e compromissos de serviço.
A margem bruta deve incluir fala, modelo de base, armazenamento, observabilidade, taxas de EHR, suporte, operações clínicas, implementação, sucesso do cliente e royalties de terceiros quando atribuíveis à entrega. O desenvolvimento capitalizado e a política de alocação devem ser compreendidos separadamente. Quedas de preço da inferência upstream podem melhorar a margem, enquanto crescimento do uso, contexto maior, saídas mais ricas ou redundância podem compensar o benefício.
A empresa deve demonstrar margem por coorte e produto. Clientes maduros devem revelar o perfil de suporte e computação em estado estacionário. Novos produtos podem ter margem menor enquanto evidências e fluxo de trabalho amadurecem. O modelo de avaliação deve refletir o tempo e o investimento necessários para atingir a margem-alvo, em vez de aplicar um benchmark de software por rótulo.
Os valores são unidades de índice hipotéticas e não representam uma referência de mercado nem uma previsão.
15. Separar as evidências clínicas das alegações de marketing
A força da evidência depende do desenho. Um estudo de caso de fornecedor pode estabelecer viabilidade e experiência do cliente. Um estudo pré-pós pode descrever mudança, mas permanece exposto a seleção, timing e iniciativas concorrentes. Um estudo observacional emparelhado pode melhorar a comparação, mas mantém confundimento. Um ensaio randomizado pode reforçar a inferência causal para o produto, os usuários, o período e os desfechos testados. Nenhum estudo isolado comprova todas as especialidades, clientes ou versões de produto.
O investidor deve construir uma matriz de alegações e evidências. Cada alegação clínica, de fluxo de trabalho e econômica recebe uma população pretendida, um desfecho, um desenho de estudo, uma versão, um comparador, um resultado, uma limitação e uma formulação comercial permitida. Evidência sobre tempo de documentação não comprova automaticamente redução de esgotamento, maior capacidade de atendimento de pacientes, melhor qualidade das notas ou aumento de receita.
A revisão rápida de 2025 sobre escribas ambientais AI encontrou apenas seis estudos do mundo real elegíveis de um conjunto de busca muito maior e relatou evidência escassa, padronização mista e efeitos limitados sobre produtividade.[15] Uma revisão sistemática posterior também identificou benefícios de implementação ao lado de variação de precisão, edições manuais e lacunas de avaliação.[18] Essas revisões apoiam uma coleta disciplinada de evidências, e não uma conclusão para toda a categoria.
Um ensaio randomizado pragmático com 238 médicos ambulatoriais testou duas aplicações de escriba ambiental em comparação com o cuidado usual e relatou desfechos específicos por aplicação.[16] Outra comparação em departamento de emergência encontrou qualidade das notas semelhante ou inferior e maior contribuição do clínico para notas geradas por AI versus escribas humanos naquele contexto.[17] Esses estudos mostram por que comparador, contexto, usuário e métrica importam.
A empresa deve manter evidências pós-implantação. Mudanças de versão, novas especialidades, idiomas, prontuários eletrônicos e ações de fluxo de trabalho podem alterar o desempenho. O monitoramento deve incluir adoção, edições, erros, incidentes, subgrupos, suporte e desfechos de clientes. As alegações comerciais devem seguir o conjunto de evidências aprovado.
16. Examinar propriedade intelectual, vantagem de dados e defensabilidade
A defensabilidade pode surgir do desenho do fluxo de trabalho, da distribuição, das integrações, dos sistemas de avaliação, dos direitos sobre dados proprietários, da confiança clínica, da capacidade regulatória e da evidência operacional. Um modelo isolado pode ser replicável ou obtido de um fornecedor upstream. O investidor deve identificar quais ativos permanecem valiosos se um modelo de base melhorar, os preços caírem ou os clientes obtiverem recursos semelhantes de uma plataforma incumbente.
A revisão de PI deve abranger cessão por funcionários e prestadores de serviço, PI preexistente, software de código aberto, licenças de modelos e conjuntos de dados, feedback de clientes, patentes, marcas registradas, nomes de domínio, proveniência de código e restrições em parcerias comerciais. Código e conteúdo gerados devem ser avaliados conforme a lei e o contrato aplicáveis. Componentes materiais devem ter um proprietário claro e uso comercial permitido.
Uma vantagem de dados exige dados lícitos, contratualmente permitidos e tecnicamente utilizáveis. Grande volume é insuficiente quando os direitos proíbem o treinamento, os rótulos são fracos, as populações são restritas ou as versões não podem ser vinculadas a desfechos. A empresa deve explicar como os dados melhoram uma capacidade definida e como a melhoria é medida. Dados específicos de clientes podem criar custo de troca sem sustentar um modelo transferível.
A infraestrutura de avaliação pode ser um ativo durável. Conjuntos de testes curados, taxonomias de erros, adjudicação clínica, análise de subgrupos, monitoramento em produção e gates de liberação podem acelerar a melhoria segura. Seu valor depende de representatividade, direitos, atualidade e reprodutibilidade.
O investidor deve aplicar um teste de substituição. Se o modelo upstream de fala ou de linguagem mudasse, o que permaneceria? Se um fornecedor de prontuário eletrônico lançasse um recurso concorrente, qual vantagem de fluxo de trabalho, evidência, integração ou distribuição protegeria a renovação? A defensabilidade deve ser descrita como um mecanismo econômico testado.
17. Avaliar organização, governança e capacidade de implantação
A organização deve corresponder ao risco e ao modelo operacional do produto. Capacidades relevantes podem incluir aprendizado de máquina, engenharia de fala, informática clínica, gestão de produtos, segurança, privacidade, assuntos regulatórios, segurança clínica, integrações, implementação, sucesso do cliente e especialização em ciclo de receita. A combinação necessária depende do uso pretendido e do segmento de clientes.
A análise de pessoas-chave deve identificar quem é responsável pela arquitetura do modelo, pelo julgamento clínico, pelos sistemas de qualidade regulamentados, pelas principais integrações, pelos relacionamentos com clientes e pela resposta a incidentes. O conhecimento deve ser evidenciado em documentação, processos de revisão e sucessão, em vez de concentrado em um fundador ou em poucos engenheiros. Planos de remuneração, retenção e contratação devem estar alinhados ao caso de expansão.
A governança deve conectar liberação de produto, segurança clínica, privacidade, segurança e alegações comerciais. Um comitê de liberação pode exigir avaliação concluída, revisão de perigos, testes de segurança, documentação, prontidão de suporte e comunicação ao cliente. Exceções devem ter um aprovador nomeado, justificativa, prazo de validade e plano de monitoramento.
Incentivos de vendas exigem revisão. As equipes podem ser recompensadas pelo valor contratado antes da aprovação de segurança, da entrada em operação ou do uso sustentado. As alegações sobre o produto podem superar as evidências quando a pressão competitiva é alta. A remuneração e as etapas de aprovação devem apoiar receita qualificada e implantação segura.
O relatório ao conselho deve combinar desempenho do produto, incidentes, direitos, situação regulatória, implantação em clientes, retenção, margem e risco de roadmap. Um conselho de crescimento precisa de indicadores de alerta precoce: implementações paradas, baixo uso ativo, aumento de edições, regressões em subgrupos, concentração de suporte, mudanças no custo de inferência e exposição à renovação. A governança se torna um ativo quando produz decisões tempestivas e evidências confiáveis para os clientes.
18. Converter constatações em avaliação e financiamento
Cada constatação confirmada deve alterar o fluxo de caixa, o prazo, o risco, a opcionalidade ou a estrutura da transação. Uma curva de implementação mais lenta atrasa a receita e consome capacidade de serviços. Um ônus maior de revisão pode enfraquecer a adoção. Direitos restritos sobre dados podem limitar o aprimoramento do modelo ou a abrangência geográfica. A concentração a montante pode afetar a margem bruta e a resiliência. A reclassificação regulatória pode exigir evidências, sistemas de qualidade e ciclos de vendas mais longos.
O modelo de avaliação deve fazer a ponte entre pipeline, valor contratado, entrada em operação, uso ativo, retenção, expansão e margem de contribuição. As variáveis de cenário devem incluir ciclo de segurança e compras, capacidade de implementação, custo de inferência, concentração de clientes, renovação, preço, mix de produtos e investimento em evidências. O cenário-base da administração deve ser reconciliado com o comportamento histórico das coortes.
A dupla contagem deve ser evitada. Uma entrada em operação mais lenta já pode reduzir a receita e o caixa. A mesma questão não deve receber um desconto adicional de múltiplo, a menos que reste incerteza residual. Um custo de suporte mais alto já pode reduzir a margem. Os revisores de finanças e de produto devem aprovar juntos a ponte causal.
As necessidades de financiamento podem aumentar devido a atrasos nas cobranças, mão de obra de implementação, estudos clínicos, remediação de segurança, sistemas de qualidade regulamentados, parcerias com EHR e expansão geográfica. O modelo de fontes e usos deve incluir esses investimentos. Uma rodada de growth equity dimensionada apenas para contratação de vendas pode financiar insuficientemente a capacidade de evidências e implantação.
Os comparáveis de avaliação exigem normalização cuidadosa. Empresas de software para saúde diferem por situação regulatória, conteúdo de serviços, concentração de clientes, crescimento, margem bruta, retenção e consumo de caixa. Um múltiplo de receita de destaque pode obscurecer a qualidade do produto e das coortes. O comitê de investimentos deve receber uma ponte transparente das evidências para as premissas e o valor.
19. Converter a diligência devida em proteções da transação e no plano de participação societária
A proteção da transação deve seguir o risco causal. Uma condição de fechamento pode exigir a entrega de um consentimento de cliente, remediação de segurança, contrato principal, protocolo regulatório ou liberação validada. O preço e os proventos podem refletir uma lacuna mensurável de receita, caixa ou passivo. O depósito em garantia, a retenção, a garantia, a indenização ou o covenant podem alocar uma exposição residual definida, sujeitos à lei aplicável e a assessoria qualificada.
As declarações devem abordar titularidade, licenças, direitos sobre dados, privacidade, segurança, situação regulatória, código aberto, contratos com clientes, dependências de modelos, incidentes e reclamações. Seu escopo deve corresponder às evidências e ao modelo de negócios. Uma garantia genérica de conformidade pode ser mais fraca do que um anexo de finalidades de tratamento conhecidas, subprocessadores, incidentes e limitações.
O plano de participação societária deve existir antes da assinatura. As prioridades iniciais podem incluir congelar versões de produto e modelo, preservar dados e logs, confirmar obrigações com clientes, garantir a permanência de profissionais-chave, validar monitoramento, revisar fluxos de trabalho de alto risco, reconciliar a economia das coortes e fechar lacunas de evidências. A integração com uma plataforma da controladora deve avançar por etapas de aprovação clínica, de segurança e de clientes.
O conselho deve distinguir o risco aceito da diligência devida não concluída. Cada item aceito recebe um responsável, orçamento, marco, evidência e direito de decisão. Itens materiais não resolvidos podem exigir diligência devida adicional, uma condição, uma alteração de avaliação ou rejeição.
Tabela 5. Etapas de aprovação do comitê de investimentos e respostas a falhas
| Ponto de verificação | Evidências exigidas | Responsável pela decisão | Resposta a falhas |
|---|---|---|---|
| fluxo de trabalho | processo observado, ônus para o usuário e mapa de exceções | líder de diligência de produto | estreitar a tese ou ampliar as evidências |
| dados | direitos e linhagem específicos por finalidade | líderes de privacidade e jurídico | restringir o uso, corrigir ou interromper |
| modelo | avaliação representativa versionada | líderes clínicos e técnicos | limitar o uso ou exigir validação |
| implantação | evidências repetíveis de integração e custo | líder operacional | reprecificar o cenário de crescimento e margem |
| aspectos econômicos | coortes, uso, retenção, margem e caixa | comitê de investimentos | reavaliar, reestruturar ou interromper |
O desenho dos pontos de decisão deve refletir a materialidade da transação, o uso pretendido e a autoridade delegada.
20. Estabeleça pontos de decisão de rejeição e um sistema de diligência devida repetível
Algumas constatações devem interromper ou restringir o investimento. Exemplos incluem incapacidade de estabelecer direitos para uma finalidade central de processamento, erros clinicamente materiais sem um caminho eficaz de detecção, alegações regulatórias sem suporte, isolamento entre tenants não resolvido, correspondência de identidade não confiável, avaliação não reproduzível, concentração de clientes sem evidência crível de retenção ou economia unitária que permanece negativa em implantações comparáveis maduras.
Os critérios de rejeição devem ser explícitos antes da apresentação da administração. Isso reduz o viés de confirmação e impede que a pressão de cronograma transforme evidências ausentes em conforto presumido. Um critério não atendido pode levar à rejeição, a um perímetro de produto mais restrito, a uma avaliação mais baixa, a um investimento por etapas, a uma condição ou a um plano de remediação financiado. A resposta deve refletir controle e materialidade.
O sistema de diligência devida deve preservar um registro de perguntas, índice de evidências, registro de direitos sobre dados, registro de modelos, resultados de avaliação, mapas de fluxo de trabalho, modelo de coorte, registro de constatações e registro de decisões. Cada constatação deve incluir fonte, versão, causalidade, materialidade, responsável, revisor, efeito econômico e resposta transacional. As saídas devem permanecer rastreáveis até as evidências.
Após o investimento, o prazo real de entrada em operação, a adoção, as edições, os incidentes, a retenção, a expansão, a margem bruta e o caixa podem ser comparados com as premissas de diligência devida. Esse feedback revela quais indicadores previram o desempenho e quais controles eram frágeis. O aprendizado do portfólio deve reter tipo de produto, contexto assistencial, comprador, EHR, risco de fluxo de trabalho, geografia e versão, para que as evidências não sejam generalizadas além de seu contexto.
As lacunas de pesquisa continuam substanciais. Trabalhos futuros devem examinar desfechos de longo prazo para pacientes e clínicos, desempenho por subgrupo, efeitos posteriores na codificação e nas cobranças, autonomia segura, implantação multilíngue, deriva de modelo, migração de clientes e a economia da concorrência nativa de EHR. Investidores de crescimento podem contribuir exigindo avaliação transparente e apoiando a infraestrutura de evidências como parte do plano de criação de valor.
O teste de decisão é direto: o investidor consegue reproduzir como o produto transforma dados autorizados em uma melhoria controlada de fluxo de trabalho, como essa melhoria se torna valor de cliente retido e como a empresa obtém margem duradoura enquanto cumpre suas responsabilidades clínicas e regulatórias? Evidências que sobrevivem a essa cadeia sustentam uma tese investível. Rompimentos na cadeia identificam a próxima pergunta de diligência ou o motivo para parar.
Referências
- Organização Mundial da Saúde, Ética e governança da inteligência artificial para a saúde, 28 de junho de 2021, https://www.who.int/publications/i/item/9789240029200
- Organização Mundial da Saúde, Ética e governança da inteligência artificial para a saúde: orientação sobre grandes modelos multimodais, 25 de março de 2025, https://www.who.int/publications/i/item/9789240084759
- Administração de Alimentos e Medicamentos dos EUA, Software de apoio à decisão clínica, Orientação final, janeiro de 2026, https://www.fda.gov/regulatory-information/search-fda-guidance-documents/clinical-decision-support-software
- Administração de Alimentos e Medicamentos dos EUA, Orientações com conteúdo de saúde digital, https://www.fda.gov/medical-devices/digital-health-center-excellence/guidances-digital-health-content
- Administração de Alimentos e Medicamentos dos EUA, Cibersegurança em dispositivos médicos: considerações do sistema de gestão da qualidade e conteúdo de submissões pré-comercialização, fevereiro de 2026, https://www.fda.gov/regulatory-information/search-fda-guidance-documents/cybersecurity-medical-devices-quality-management-system-considerations-and-content-premarket
- Escritório do Coordenador Nacional de Tecnologia da Informação em Saúde, Regra Final HTI-1, https://healthit.gov/regulations/hti-rules/hti-1-final-rule/
- Departamento de Saúde e Serviços Humanos dos EUA, Entidades Cobertas e Parceiros de Negócios, https://www.hhs.gov/hipaa/for-professionals/covered-entities/index.html
- Departamento de Saúde e Serviços Humanos dos EUA, Computação em nuvem e informações de saúde protegidas eletrônicas, https://www.hhs.gov/hipaa/for-professionals/faq/2075/may-a-hipaa-covered-entity-or-business-associate-use-cloud-service-to-store-or-process-ephi/index.html
- União Europeia, Regulamento (UE) 2024/1689 que estabelece regras harmonizadas sobre inteligência artificial, https://eur-lex.europa.eu/eli/reg/2024/1689/oj
- União Europeia, Regulamento (UE) 2025/327 sobre o Espaço Europeu de Dados de Saúde, https://eur-lex.europa.eu/eli/reg/2025/327/oj/
- Agência Reguladora de Medicamentos e Produtos de Saúde do Reino Unido, Software e inteligência artificial como dispositivo médico, https://www.gov.uk/government/publications/software-and-artificial-intelligence-ai-as-a-medical-device
- NHS England, padrões de gestão de risco clínico DCB0129 e DCB0160, https://digital.nhs.uk/data-and-information/information-standards/governance/latest-activity/standards-and-collections/dcb0129-clinical-risk-management-its-application-in-the-manufacture-of-health-it-systems
- Instituto Nacional de Padrões e Tecnologia, Estrutura de Gestão de Riscos de Inteligência Artificial e Perfil de AI Generativa, https://www.nist.gov/itl/ai-risk-management-framework
- Fórum Internacional de Reguladores de Dispositivos Médicos, Software como Dispositivo Médico: Avaliação Clínica, 21 de setembro de 2017, https://www.imdrf.org/documents/software-medical-device-samd-clinical-evaluation
- Kanaparthy NS et al., Síntese de evidências do mundo real de escribas digitais usando escuta ambiente e inteligência artificial generativa para fluxos de trabalho de documentação clínica: revisão rápida, JMIR AI, 2025, https://pubmed.ncbi.nlm.nih.gov/41071988/
- Shah SJ et al., Escribas de AI ambiente na prática clínica: um ensaio randomizado, 2025, https://pubmed.ncbi.nlm.nih.gov/41497288/
- Morey J et al., Inteligência artificial ambiente versus escribas humanos no departamento de emergência, Annals of Emergency Medicine, 2025, https://pubmed.ncbi.nlm.nih.gov/41251650/
- Implementação clínica de escribas de inteligência artificial na saúde: uma revisão sistemática, 2025, https://pubmed.ncbi.nlm.nih.gov/40306686/
- Comissão Federal de Comércio dos EUA, Regra de Notificação de Violação de Dados de Saúde, Regra Final, 30 de maio de 2024, https://www.ftc.gov/legal-library/browse/rules/health-breach-notification-rule
- HL7 International, Visão geral do FHIR, https://www.hl7.org/fhir/overview.html
