Integração de SIG com assistentes médicos de IA: um registo FHIR, uma API de contexto e um servidor MCP

Ligar um modelo de linguagem a um registo médico levanta três questões antes do primeiro pedido: o que é que o modelo vê, quem o permitiu e o que acontece quando ele quer escrever algo de volta. A Plataforma Anpheros responde a todas as três na API, para que o assistente que constrói (ou o que os seus utilizadores já têm) possa trabalhar num registo sem inventar as suas próprias regras. Este guia abrange a API de contexto, o servidor MCP e o fluxo de propostas.

Versão técnica para programadores: Assistente médico de IA · Servidor MCP em developers.anpheros.com, com pedidos, respostas e limites. Esta página é a versão em linguagem simples.

O que o modelo vê: a API de contexto

POST /v1/context constrói um resumo pronto para IA de um paciente dentro de um orçamento de tokens que define. Cada item carrega author_type (paciente, profissional de saúde, dispositivo, importação, derivado) e a sua origem, para que o modelo possa distinguir um valor laboratorial de um sintoma auto-relatado e um diagnóstico médico de um palpite. O orçamento decide o que é incluído primeiro: problemas ativos, medicação atual, alergias, resultados recentes, depois o resto. Recebe secções rotuladas ou, com format: "text", um bloco renderizado pronto para um pedido, mais uma lista omitted a nomear o que não coube.

curl -X POST "$BASE/v1/context" \
     -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" \
     -d '{"patient": "'$PID'", "budget_tokens": 2000, "task": "pre-visit summary", "format": "text"}'

Os mesmos rótulos de proveniência são o que tornam a saída defensável mais tarde: um resumo de um assistente pode dizer de onde veio cada declaração.

Quem o permitiu: consentimento, não configuração

O token na chamada acima vem da pessoa, através do OAuth 2.1 com PKCE, com os âmbitos e a duração que ela escolheu. Uma aplicação de IA é registada como qualquer outra, pede como qualquer outra e é listada em "Ligações" da pessoa como qualquer outra. A revogação para a próxima solicitação. Uma chave de projeto sozinha vê apenas os pacientes que o projeto criou; nunca substitui o consentimento.

Escrever de volta: propostas, não escritas

Uma escrita feita sob o consentimento de uma pessoa por uma aplicação registada como agente de IA é retida. A plataforma valida-a, responde 202 Accepted com um ID de proposta e não altera nada. A pessoa vê a proposta, o que é e qual o assistente que a enviou, e aceita-a ou rejeita-a. Uma proposta aceite é escrita exatamente como enviada, marcada como escrita por IA seguindo as orientações de transparência de IA da HL7. Projetos que podem ver o registo recebem um webhook fino proposal.created.

Esta é a regra que permite que um assistente seja útil ("Notei que mencionou uma nova medicação, devo adicioná-la?") sem nunca ser o autor do registo.

O servidor MCP

Assistentes que falam o Protocolo de Contexto de Modelo ligam-se diretamente a https://platform.anpheros.com/mcp (HTTP transmitido em fluxo). As pessoas ligam-se com OAuth, no seu próprio registo; os programadores podem ligar-se com uma chave de sandbox nos 30 pacientes sintéticos. As ferramentas são as que esperaria da API:

• list_patients, get_patient_context, get_patient_summary (o Resumo Internacional do Paciente), get_timeline
• get_health_patterns, get_pattern_evidence, get_series, compare_periods (o que mudou e o que recorre, com evidências; não diagnósticos)
• search_fhir, read_fhir_resource, get_provenance, lookup_code
• validate_fhir_resource, create_fhir_resource, create_patient, import_lab_report
• sandbox_status, reset_sandbox

O servidor está listado no registo MCP como com.anpheros/fhir. A configuração para Claude, ChatGPT e outros clientes está em developers.anpheros.com/guides/mcp.

Modelos privados e residência na UE

A plataforma não chama um modelo em seu nome; serve contexto e aceita propostas. Qual modelo lê o contexto é sua decisão: uma API alojada, uma implementação privada, um modelo no próprio hardware de um hospital. O registo em si permanece na UE, no Cloud Run em europe-west4, com proveniência e auditoria em cada acesso.

O que não é

A plataforma não diagnostica nem recomenda tratamento, e a API de contexto não é suporte à decisão clínica. Dá a um modelo os factos, rotulados, sob consentimento. O que o modelo diz é da responsabilidade de quem o implementa.

Perguntas frequentes

Posso ligar o ChatGPT ou o Claude a um registo de paciente?

Sim, através do servidor MCP, com o consentimento OAuth da pessoa no seu próprio registo. Para desenvolvimento, uma chave de sandbox dá ao assistente os 30 pacientes sintéticos.

A IA escreve no registo?

Apenas como uma proposta que a pessoa aprova. Nada que um agente de IA envia é aplicado sem essa aprovação, e as entradas aceites são marcadas como escritas por IA.

Como evito que o modelo veja demasiado?

Três formas: os âmbitos que a pessoa concede, os filtros de categoria nesses âmbitos e o orçamento de tokens na chamada de contexto, que ordena os itens por relevância clínica e para no orçamento.

Existe uma API para um chatbot de saúde na minha própria aplicação?

Sim. A sua aplicação obtém o consentimento da pessoa através do OAuth, chama a API de contexto, envia o resultado para o modelo que escolher e, se o modelo sugerir uma entrada, submete-a como uma escrita; a plataforma transforma-a numa proposta. Os SDKs TypeScript e Dart cobrem as chamadas.

Onde são processados os dados?

O registo é armazenado e servido a partir da UE. Onde o modelo é executado depende de si; a plataforma nunca envia dados do registo para um modelo em si.