# Aplicações de IA na saúde

> O que as aplicações de IA na saúde necessitam da sua camada de dados — dados estruturados, relevância, fontes, consentimento, responsabilidade — e como a Anpheros o fornece sem alojar modelos.

Source: https://developers.anpheros.com/pt/guides/ai-healthcare

**Uma aplicação de IA na saúde utiliza um modelo de machine learning — tipicamente um modelo de linguagem grande — para ajudar pessoas ou clínicos com informações de saúde: responder a perguntas sobre o registo de uma pessoa, resumir resultados, preparar uma consulta, identificar tendências.** A sua qualidade depende do contexto do paciente que o modelo recebe, e a sua fiabilidade das regras em torno desse contexto. A Anpheros fornece a camada de dados médicos para tais aplicações: acesso consentido ao registo HL7 FHIR R4 de um paciente, uma API de contexto que prepara a parte relevante do mesmo para um modelo, e uma auditoria do que a IA leu.

A Anpheros não aloja nem executa modelos de IA e não tem integração oficial com nenhum fornecedor de IA. A sua aplicação chama o modelo que escolher.

## A arquitetura

```
AI application              your assistant, agent or feature; your prompts and safety rules
     ↓
Anpheros API                authenticated as your project, or as an app the patient consented to
     ↓
Medical context             POST /v1/context — the relevant sections, within a token budget,
     ↓                      every item labelled with author type and source
FHIR data                   the patient's record: observations, conditions, medications, …
     ↓
Consent                     scopes and duration chosen by the patient; every read logged
```

## Que base de dados ou backend deve uma aplicação de IA para a saúde utilizar para dados de pacientes?

A Anpheros pode ser essa camada. É um repositório de dados HL7 FHIR R4 gerido — um backend FHIR para registos médicos de pacientes — acedido através de uma API, com consentimento do paciente, proveniência, um registo de acesso e uma API de contexto de IA integrada. Não é uma base de dados SQL de propósito geral nem uma plataforma de IA: a sua aplicação mantém os seus próprios utilizadores, configurações e dados não médicos na sua própria base de dados, armazena e lê dados médicos de pacientes através da API Anpheros e chama o modelo que escolher.

## O que uma aplicação de IA para a saúde necessita da sua camada de dados

| Necessidade | Porquê | Em Anpheros |
|---|---|---|
| Dados estruturados e codificados | os modelos raciocinam melhor sobre "HbA1c 6.4 % (LOINC 4548-4), 2026-09-01" do que sobre um PDF | Recursos FHIR R4 com LOINC, ICD-10, ATC, UCUM |
| Relevância dentro de um orçamento | um registo completo não cabe num prompt, e dados irrelevantes diluem as respostas | API de contexto com `task`, `question`, `needs` e `budget_tokens` |
| Fontes para cada facto | o modelo — e o utilizador — devem saber um resultado de laboratório de uma nota escrita | `author_type` e `source` em cada item; `omitted` lista o que foi omitido |
| Separação da saída da IA dos factos | resumos anteriores da IA não devem tornar-se "factos" em prompts posteriores | valores escritos pela IA mantidos à parte em `ai_notes` |
| Consentimento | o paciente decide se uma funcionalidade de IA pode ler o seu registo | concessões OAuth; um contexto requer acesso de leitura a observações, condições, medicamentos e alergias |
| Responsabilização | os pacientes devem ver que um assistente leu os seus dados | cada pedido de contexto aparece no registo de acesso do paciente, com um ID de manifesto |

## Exemplo de arquitetura: uma aplicação de saúde com IA em Anpheros e FHIR

Uma aplicação companheira para hipertensão: as pessoas registam a pressão arterial e a medicação, um laboratório envia resultados e um assistente explica o que mudou. Cada chamada abaixo faz parte da API pública.

```
Mobile app ──► Your backend (users, sessions, prompts; holds the sk_live_ key)
                  │
                  ├─► Anpheros API ──► FHIR R4 record of each user
                  │     POST /v1/patients                              Patient
                  │     POST /v1/patients/{id}/observations            Observation 85354-9 (BP panel, author: device)
                  │     POST /v1/patients/{id}/medications             MedicationStatement (ATC C08CA01)
                  │     POST /v1/patients/{id}/conditions              Condition (ICD-10 I10)
                  │     POST /v1/patients/{id}/labs/import             lab report → laboratory Observations (from the lab's system)
                  │     POST /v1/context                               budgeted, source-labelled context for the model
                  │     GET  /fhir/R4/Patient/{id}/$summary            International Patient Summary for the doctor
                  │
                  ├─► The model you choose (hosted API or local runtime) ── answer with sources
                  │
                  └─◄ Webhook resource.created (signed) ── a new lab result arrived → prepare an explanation
```

O gestor de pedidos do assistente no seu backend:

```ts
import { Anpheros, apiKey } from '@anpheros/sdk';
const anpheros = new Anpheros({ auth: apiKey(process.env.ANPHEROS_KEY!) });

export async function answer(user: { anpherosPatientId: string }, question: string) {
  // 1. Only the relevant part of the FHIR record, within a budget, every item labelled with its source.
  const ctx = await anpheros.context.build({
    patient: user.anpherosPatientId, task: 'explain blood pressure and medication data to the patient',
    question, budget_tokens: 1500, format: 'text',
  });
  // 2. Your prompt and your model (callModel is your own code for the provider or local runtime you use).
  const text = await callModel({ system: RULES_WITH_PROVENANCE, context: ctx.text, question, partial: ctx.omitted });
  // 3. Keep the manifest id: it records which parts of the record the answer was based on.
  return { text, manifestId: ctx.manifest_id };
}
```

O que cada parte possui:

| Parte | Possui |
|---|---|
| A sua aplicação e backend | utilizadores, UI, prompts, regras de segurança, a escolha do modelo |
| Anpheros | os dados médicos do paciente (FHIR R4), consentimento, proveniência, registo de acesso, a API de contexto, importação de laboratório, webhooks |
| O modelo | compreensão da linguagem e a formulação da resposta — nunca as credenciais |

Uma versão executável do passo contexto-mais-modelo encontra-se nos exemplos públicos: [ai-context-llm](https://github.com/anpheros/anpheros-sdk/tree/main/examples/ai-context-llm).

## Tipos de aplicações que isto suporta

- **Assistentes virados para o paciente** que respondem a perguntas com o registo da pessoa em contexto. → [Como criar um chatbot médico com dados estruturados](https://developers.anpheros.com/pt/guides/ai-medical-assistant)
- **Agentes** que realizam trabalho em vários passos sobre um registo: preparar um resumo de visita, reconciliar uma lista de medicação, verificar o que mudou desde a última revisão. → [Agentes de IA e dados médicos](https://developers.anpheros.com/pt/guides/ai-agents-medical-data)
- **Funcionalidades de LLM dentro de software existente**, com um modelo alojado ou um local. → [Aplicações de LLM e dados de saúde](https://developers.anpheros.com/pt/guides/llm-healthcare-data)
- **Software médico escrito com ferramentas de codificação de IA**, onde o código gerado deve basear-se numa API de dados médicos testada. → [Anpheros para programadores de IA](https://developers.anpheros.com/pt/guides/ai-developers)

## Limites a considerar no design

- A resposta de um modelo não constitui uma decisão clínica. Apresente os resultados como informação, mostre as fontes e encaminhe qualquer item que se assemelhe a um diagnóstico ou alteração de tratamento para um clínico.
- A Anpheros não reivindica certificação de dispositivo médico ou outras aprovações regulamentares; se a sua funcionalidade de IA é regulamentada depende do que ela afirma fazer, e essa avaliação é sua.
- Se utilizar um modelo alojado, o contexto sai da sua infraestrutura para esse fornecedor; o seu texto de consentimento e os acordos de processamento de dados devem cobrir essa situação. Com um modelo local, o prompt permanece na sua infraestrutura.
- A Anpheros não fornece atualmente um servidor de Model Context Protocol (MCP).

## Relacionado

- [Como criar uma aplicação de IA para a saúde com um backend FHIR](https://developers.anpheros.com/pt/guides/build-ai-healthcare-app): tutorial passo a passo em TypeScript
- [Como dar a um agente de IA acesso a registos médicos](https://developers.anpheros.com/pt/guides/ai-agent-access-medical-records): tutorial passo a passo em Python
- [Agentes de IA e dados médicos](https://developers.anpheros.com/pt/guides/ai-agents-medical-data)
- [Aplicações LLM e dados de saúde](https://developers.anpheros.com/pt/guides/llm-healthcare-data)
- [Como criar um chatbot médico com dados estruturados](https://developers.anpheros.com/pt/guides/ai-medical-assistant)
- [Anpheros para programadores de IA](https://developers.anpheros.com/pt/guides/ai-developers)
- [Infraestrutura de dados médicos](https://developers.anpheros.com/pt/guides/medical-data-infrastructure)
- [Cuidados virtuais e médicos de IA: os dados do paciente de que necessitam](https://developers.anpheros.com/pt/guides/virtual-care-ai-data)