Resposta curta: A IA em dados médicos é um pipeline com sete questões, e a maioria das falhas advém de saltar uma delas. De onde vêm os dados (um registo FHIR, documentos, dispositivos, as palavras do próprio paciente)? Como é que o modelo os acede (uma API de contexto que compila o que é relevante, um servidor Model Context Protocol, recuperação sobre o registo)? Quem decidiu que pode (o consentimento do paciente, delimitado por propósito e tempo, registado)? O que protege as pessoas nele contidas (desidentificação para tudo o que sai do contexto de cuidados, dados sintéticos para desenvolvimento, pseudonimização para investigação)? Pode cada resultado ser rastreado (proveniência nas entradas e saídas)? Como sabemos que funciona (avaliação contra a verdade clínica, não "vibrações")? Que regras se aplicam (Artigos 9 e 22 do GDPR, o MDR se o resultado informar decisões clínicas, o EU AI Act, HIPAA)? Esta página é o mapa; cada questão tem a sua própria página.
O pipeline
O pipeline para IA em dados médicos tem sete fases, cada uma com uma pergunta: fonte (de onde vêm os dados), acesso (como o modelo os alcança), controlo (quem decidiu que pode), privacidade (o que protege as pessoas nele), rastreabilidade (se os resultados podem ser rastreados), avaliação (como o sucesso é medido) e regras (quais leis se aplicam).
| Etapa | Questão | O que é bom | Página |
|---|---|---|---|
| Fonte | De onde vêm os dados? | Um registo FHIR com códigos (LOINC, SNOMED CT, ATC), documentos com estrutura extraída, dados de dispositivos com proveniência; não apenas capturas de ecrã e PDFs | FHIR Observation, FHIR DiagnosticReport |
| Acesso | Como é que o modelo os acede? | Uma API de contexto ou servidor MCP que retorna uma fatia delimitada e com proveniência do registo; recuperação com filtros estruturados, não um dump | RAG em registos médicos, API de Saúde para IA, Servidor MCP |
| Controlo | Quem decidiu que pode? | Consentimento do paciente por propósito e duração; âmbitos aplicados no lado do servidor; um registo de acesso que o paciente lê; revogação que funciona | Plataforma de consentimento do paciente, Quem viu o meu registo? |
| Privacidade | O que protege as pessoas? | Dados identificados permanecem no contexto de cuidados; dados desidentificados ou sintéticos para desenvolvimento, análise e treino de modelos; dados pseudonimizados para investigação sob licenças | Desidentificação, Dados sintéticos de pacientes |
| Rastreabilidade | Os resultados podem ser rastreados? | Proeniência em cada entrada (quem a registou, quando, de onde) e em cada resultado de IA (modelo, versão, entradas usadas), armazenada com o registo | Proveniência de dados médicos |
| Avaliação | Como sabemos que funciona? | Conjuntos de teste com verdade clínica, fidelidade às fontes, análise de erros por subgrupo, monitorização em produção, caminhos de revisão humana | Avaliação de LLMs clínicos |
| Regras | Que leis se aplicam? | Artigos 9 e 22 do GDPR, DPIA; MDR se o resultado informar diagnóstico ou tratamento; o regime de alto risco do AI Act para dispositivos e para usos listados; HIPAA nos EUA | O EU AI Act e a IA na saúde, Classes de SaMD, Artigo 9 do GDPR |
Três tipos de IA, três perfis de risco
A IA em dados médicos vem em três tipos com três perfis de risco: IA assistiva e administrativa, como resumos em linguagem clara e notas redigidas, onde o risco é a privacidade e erros não detetados; suporte à decisão, como sinalização de interações ou triagem, onde o risco é clínico e aplica-se o MDR; e IA de população e pesquisa, onde os riscos são reidentificação e viés.
Assistiva e administrativa: resumir um registo para o paciente em linguagem clara, redigir uma nota de visita a partir de uma transcrição para o clínico editar, responder a "onde está o meu último exame de sangue" sobre um registo consentido. O risco reside na privacidade e em erros que um humano pode não detetar; o MDR não se aplica desde que nenhuma decisão clínica seja informada, mas os deveres de transparência do AI Act e o GDPR sim.
Apoio à decisão: sinalizar uma interação, sugerir um diagnóstico diferencial, triagem. O risco é clínico; o MDR aplica-se (geralmente classe IIa ou superior), o regime de alto risco do AI Act segue, e são necessários IEC 62304 e avaliação clínica. Veja CDS Hooks explicado para saber como tais sistemas se ligam a um EHR.
População e investigação: encontrar padrões em muitos registos, sinais de farmacovigilância, descoberta de coortes. O risco é a reidentificação e o viés; os dados devem ser anonimizados ou pseudonimizados sob licenças, agregados com tamanhos mínimos de célula, e os métodos avaliados quanto a fatores de confusão. Veja Uso secundário de dados de saúde.
Modos de falha
Os modos de falha comuns da IA em dados médicos são inserir um registo inteiro num prompt, injeção de prompt através de documentos, inferência silenciosa que escreve a suposição de um modelo no registo como se um clínico tivesse feito, treino em dados identificados sem base legal, avaliação apenas no conjunto de demonstração do fornecedor e registos de depuração cheios de dados de pacientes.
- Contexto sobrecarregado: colar um registo inteiro numa prompt. Caro, vaza dados, e o modelo atende às partes erradas. Um contexto delimitado e classificado com proveniência funciona melhor e é auditável.
- Injeção de prompt através de documentos: uma carta digitalizada que diz "ignorar instruções anteriores". Trate todo o conteúdo do registo como dados; nunca o deixe definir políticas. Veja RAG em registos médicos.
- Inferência silenciosa: um modelo que infere um diagnóstico a partir do comportamento e o escreve no registo como se um clínico o tivesse feito. Os resultados são rotulados como gerados por IA com proveniência e nunca se tornam uma Condição sem uma afirmação humana. Veja FHIR Condition explicado.
- Treino em dados identificados sem base: o fine-tuning em registos de pacientes necessita de uma base legal para além de "tínhamos os dados"; dados desidentificados ou sintéticos servem geralmente.
- Avaliação no conjunto de demonstração do fornecedor: avalie na sua população, nas suas línguas, nos seus tipos de documentos, e continue a avaliar após a implementação.
- Registos cheios de PHI: prompts e conclusões registadas para depuração tornam-se um segundo registo, desprotegido. Pseudonimize ou não registe o conteúdo.
Normas e blocos de construção
As normas e blocos de construção para IA em dados médicos são FHIR para o registo e para resultados de IA estruturados, o Protocolo de Contexto de Modelo para acesso governado a ferramentas e dados, SMART on FHIR para autorização, o trabalho do ciclo de vida de dados de IA/ML da HL7 para rastreabilidade, ISO/IEC 42001 para gestão de IA e as normas harmonizadas do AI Act.
FHIR para o registo e para os resultados estruturados da IA (Observation com um derivedFrom, DocumentReference para resumos gerados, Provenance com o modelo como agente); o Model Context Protocol para dar aos assistentes acesso governado a ferramentas e dados; SMART on FHIR para autorização; o trabalho do HL7 AI/ML Data Lifecycle e proveniência para rastreabilidade; ISO/IEC 42001 para um sistema de gestão de IA; as normas harmonizadas do AI Act à medida que são publicadas.
Na Anpheros
Para IA em dados médicos, a Anpheros fornece o registo FHIR R4 com códigos e proveniência, uma API de contexto que retorna uma fatia do registo com rótulo de proveniência dentro de um orçamento de tokens, um servidor MCP através do qual os assistentes leem o registo próprio de uma pessoa com o consentimento dessa pessoa, e registos de consentimento e acesso que a pessoa controla. A Anpheros não executa IA de diagnóstico.
A Anpheros fornece o registo (FHIR R4, codificado, com proveniência), uma API de contexto que retorna uma fatia rotulada com proveniência dentro de um orçamento de tokens, um servidor MCP para que assistentes como o Claude leiam o registo de uma pessoa com o consentimento dessa pessoa, e registos de consentimento e acesso que a pessoa controla. Não executa IA de diagnóstico e não escreve inferências de IA no registo como factos clínicos. O site do programador tem os detalhes: API de saúde para IA, servidor MCP, LLMs em dados de saúde.
Páginas relacionadas
- RAG em registos médicos: como funciona a recuperação sobre um registo FHIR
- O EU AI Act e a IA na saúde
- API de Saúde para IA: contexto do paciente rotulado com proveniência
- Desidentificação de dados de saúde
- IA e o seu registo médico (para pacientes)
- Uso secundário de dados de saúde
- Servidor MCP Anpheros (site do programador)
- LLMs em dados de saúde (site do programador)
Fontes
- Especificação do Model Context Protocol
- HL7 FHIR R4: Provenance
- Regulamento (UE) 2024/1689 (AI Act), EUR-Lex
- ISO/IEC 42001:2023, Sistema de gestão de IA
- OMS: Ética e governação da inteligência artificial para a saúde, orientações sobre modelos multimodais grandes (2024)
- HL7 SMART App Launch
Perguntas frequentes
Posso fazer fine-tuning de um modelo em registos de pacientes?
Apenas com uma base legal para esse propósito (consentimento, ou base de investigação ao abrigo do Artigo 9(2)(j) com salvaguardas), uma DPIA e geralmente desidentificação; os registos identificados não podem ser usados para treino porque estavam disponíveis por acaso. Dados sintéticos e desidentificados servem a maioria das necessidades de desenvolvimento.
Um resumo de IA de um registo é um dispositivo médico?
Não, se apenas repetir o que o registo contém para o paciente ou clínico sem o interpretar para diagnóstico ou tratamento. No momento em que sugere o que os achados significam clinicamente, é apoio à decisão ao abrigo do MDR.
O que é MCP e porque é importante aqui?
O Model Context Protocol é uma norma aberta para ligar assistentes de IA a ferramentas e fontes de dados através de servidores com capacidades definidas. Para dados de saúde, permite que um assistente leia o registo de uma pessoa através de um servidor governado, com o consentimento e registo da pessoa, em vez de colar dados num chat.
Como avalio uma funcionalidade de LLM clínico?
Com um conjunto separado de casos reais da sua população rotulados por clínicos, métricas de correção e fidelidade às fontes, análise por subgrupo e língua, revisão de casos de falha, e monitorização após o lançamento. Os benchmarks do fornecedor são um ponto de partida, não uma prova.
Experimente grátis no sandbox
Sua primeira chamada FHIR em 5 minutos. Uma API HL7 FHIR R4 com o consentimento do paciente integrado: experimente na sandbox e depois conecte a sua própria app ou sistema clínico.
Grátis · 30 pacientes sintéticos · sem cartão
A Anpheros desenvolve um registo médico que o doente controla e pode partilhar com qualquer clínica, numa plataforma HL7 FHIR R4, sediada na UE. Estes guias ajudam-no a compreender e organizar a sua saúde; não substituem o seu médico.
Sobre a Anpheros →