# Backend e base de dados de aplicações médicas

> O que um backend e a sua base de dados de aplicações médicas devem gerir, que partes o Anpheros fornece como base de dados de saúde gerida, o que fica no seu backend, três formas de se conectar e como manter a sincronização com webhooks.

Source: https://developers.anpheros.com/pt/guides/medical-app-backend

**Um backend de aplicação médica é o lado do servidor de uma aplicação de saúde: armazena dados do paciente, impõe quem pode vê-los, mantém um histórico de alterações e comunica com laboratórios, clínicas e outros serviços.** Com o Anpheros, a parte médica desse backend — a base de dados de saúde que detém o registo de cada paciente, com o seu histórico, consentimento, proveniência, auditoria, importação de laboratório e eventos — é fornecida pela plataforma através de uma API, e o seu próprio backend guarda apenas o que é específico do seu produto.

## O que um backend médico tem de gerir

| Responsabilidade | Porquê é difícil na área da saúde | Com Anpheros |
|---|---|---|
| Um modelo de dados médicos | dezenas de tipos de dados, cada um com códigos standard | HL7 FHIR R4, 26 tipos de recursos, LOINC / ICD-10 / ATC / UCUM |
| Versionamento | dados médicos são corrigidos, nunca substituídos silenciosamente | cada atualização é uma nova versão; `If-Match` para atualizações condicionais |
| Documentos | originais devem permanecer inalterados e rastreáveis | originais imutáveis com SHA-256, armazenamento na UE encriptado com uma chave gerida pelo cliente |
| Controlo de acesso | por paciente, por aplicação, por tipo de dados | isolamento de projetos, IDs par a par, escopos OAuth com filtros de categoria |
| Consentimento | o paciente decide e pode mudar de ideias | concessões por 30–365 dias, revogáveis, espelhadas como FHIR `Consent` |
| Auditoria | pacientes e reguladores perguntam quem viu o quê | cada leitura e escrita registada e visível para o paciente |
| Proveniência | um valor de um laboratório não é um valor introduzido por um paciente | tipo de autor, organização, praticante e sistema de origem em cada escrita |
| Integrações | laboratórios enviam CSV, HL7 v2, JSON; aplicações necessitam de eventos | importação de laboratório, transações FHIR, webhooks assinados |
| Retentativas seguras | uma medicação ou resultado duplicado é um erro clínico | `Idempotency-Key` em cada criação |
| Dados de teste | pacientes reais nunca devem estar em desenvolvimento | uma base de dados sandbox com pacientes sintéticos |

## O que fica no seu backend

- os seus **utilizadores e contas**, e o mapeamento de cada utilizador para o seu ID de paciente Anpheros (o ID pairwise que o seu projeto vê);
- **dados do produto** que não são médicos: configurações, subscrições, conteúdo, agendamentos de lembretes;
- **regras de negócio** — qual dos seus funcionários pode ver qual paciente no seu produto;
- a **API key**, que nunca deve ser incluída numa aplicação móvel ou web.

## Três formas de conectar

**1. O seu backend detém a chave da API (mais comum).** A sua aplicação chama o seu backend; o seu backend chama o Anpheros com uma chave `sk_live_` e vê os pacientes que o seu projeto criou.

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

// GET /api/me/vitals in your backend, after your own authentication
export async function myVitals(user: { anpherosPatientId: string }) {
  const page = await anpheros.observations.list(user.anpherosPatientId, { category: 'vital-signs', limit: 50 });
  return page.data;
}
```

**2. A aplicação atua em nome do paciente com OAuth.** Para pessoas que já têm um registo Anpheros, uma aplicação móvel ou web é um cliente OAuth *público* com PKCE: a pessoa consente na página alojada e a aplicação recebe um token de acesso de 30 minutos e um token de atualização rotativo para esse único registo. Os SDKs implementam o fluxo (`OAuthFlow`).

**3. Parceiros servidor-a-servidor.** Um cliente confidencial (com um segredo, mantido num servidor) pode usar o fluxo de código de autorização, ou `client_credentials`, que se comporta como uma chave de API para esse projeto.

## Manter o seu backend sincronizado

Subscreva webhooks em vez de fazer polling. As entregas são assinadas (`Anpheros-Signature`, HMAC-SHA256 sobre timestamp e corpo), pelo menos uma vez e possivelmente fora de ordem; deduplique por ID de evento e ignore versões desatualizadas.

```ts
import { verifyWebhookSignature } from '@anpheros/sdk';

app.post('/anpheros/hook', express.raw({ type: 'application/json' }), async (req, res) => {
  const ok = await verifyWebhookSignature({ secret: process.env.ANPHEROS_WEBHOOK_SECRET!, header: req.header('anpheros-signature'), body: req.body });
  if (!ok) return res.status(400).end();
  const event = JSON.parse(req.body.toString());   // ids and versions only — read the resource if you need it
  res.status(204).end();
});
```

## Tratamento de erros e limites

- Trate `404` como "não visível para si", nunca como prova de que um registo não existe.
- `403` significa que a credencial existe, mas pode não ter permissão para esta ação — um âmbito em falta, ou um recurso escrito por outra organização.
- `429` vem acompanhado de `Retry-After`; os SDKs esperam e tentam novamente automaticamente, tal como fazem para `5xx`.
- Guarde os `Anpheros-Request-Id` das chamadas falhadas para suporte.

[Erros](https://developers.anpheros.com/pt/guides/errors) · [Limites e limites de taxa](https://developers.anpheros.com/pt/guides/limits)

## Perguntas Frequentes

### Que base de dados deve uma aplicação médica utilizar?
Uma que mantenha dados médicos numa forma padronizada e versionada e que controle o acesso por paciente. Anpheros é uma base de dados gerida para cuidados de saúde construída sobre HL7 FHIR R4: o registo de cada paciente é versionado e pesquisável, cada escrita carrega proveniência, e uma aplicação vê um paciente apenas se criou o registo ou se o paciente consentiu. A sua própria base de dados mantém o resto dos dados do seu produto — contas, faturação, conteúdo. Para as contrapartidas de desenhar as suas próprias tabelas em vez disso, consulte [FHIR vs. uma base de dados médica personalizada](https://developers.anpheros.com/pt/guides/fhir-vs-custom-database).

### Existe uma base de dados gratuita para aplicações médicas?
Sim. A sandbox Anpheros é gratuita: inicie sessão com o Google, obtenha uma chave com um clique, e o seu projeto obtém os seus próprios 30 pacientes sintéticos e até 10 000 escritas por dia. A produção começa em €99 por mês para 2.500 pacientes, com o primeiro mês gratuito; o acesso à produção é para organizações verificadas com um acordo de processamento de dados assinado. Consulte [Preços](https://developers.anpheros.com/pt/guides/pricing).

### Posso manter dados reais de pacientes na sandbox gratuita?
Não. A sandbox é apenas para dados sintéticos: cada projeto de sandbox obtém os seus próprios pacientes sintéticos, e as chaves da sandbox não podem aceder à produção. Registos reais de pacientes pertencem a um projeto de produção.

## Relacionado

- [FHIR vs. uma base de dados médica personalizada](https://developers.anpheros.com/pt/guides/fhir-vs-custom-database): quando projetar as suas próprias tabelas e quando usar FHIR
- [Como criar uma API de saúde com TypeScript](https://developers.anpheros.com/pt/guides/healthcare-api-typescript): tutorial passo a passo com Express
- [Como criar uma aplicação de saúde com Flutter](https://developers.anpheros.com/guides/healthcare-app-flutter): tutorial passo a passo com o SDK Dart
- [Desenvolvimento de software de saúde](https://developers.anpheros.com/pt/guides/healthcare-software)
- [Criar uma aplicação de saúde](https://developers.anpheros.com/pt/guides/build-a-healthcare-app)
- [Arquitetura](https://developers.anpheros.com/pt/guides/architecture)
- [API de dados médicos](https://developers.anpheros.com/pt/guides/medical-data-api)
- [SDKs](https://developers.anpheros.com/pt/guides/sdks)