Try it free in the sandbox · first FHIR call in 5 minutesFree · 30 synthetic patients · no card

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

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

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

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.

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.

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 · Limites e limites de taxa

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.

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.

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: quando projetar as suas próprias tabelas e quando usar FHIR
• Como criar uma API de saúde com TypeScript: tutorial passo a passo com Express
• Como criar uma aplicação de saúde com Flutter: tutorial passo a passo com o SDK Dart
• Desenvolvimento de software de saúde
• Criar uma aplicação de saúde
• Arquitetura
• API de dados médicos
• SDKs

Try it free in the sandbox · first FHIR call in 5 minutesFree · 30 synthetic patients · no card