# Backend și baza de date a aplicației medicale

> Ce trebuie să gestioneze un backend de aplicație medicală și baza sa de date, ce părți sunt furnizate de Anpheros ca bază de date medicală gestionată, ce rămâne în backend-ul dvs., trei moduri de conectare și cum să rămâneți sincronizat cu webhooks.

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

**Un backend de aplicație medicală este partea de server a unei aplicații de sănătate: stochează datele pacienților, impune cine le poate vedea, păstrează un istoric al modificărilor și comunică cu laboratoarele, clinicile și alte servicii.** Cu Anpheros, partea medicală a acelui backend — baza de date medicală care deține dosarul fiecărui pacient, cu istoricul său, consimțământul, proveniența, auditul, importul de laborator și evenimentele — este furnizată de platformă printr-un API, iar propriul backend păstrează doar ceea ce este specific produsului dvs.

## Ce trebuie să gestioneze un backend medical

| Responsabilitate | De ce este dificil în domeniul sănătății | Cu Anpheros |
|---|---|---|
| Un model de date medical | zeci de tipuri de date, fiecare cu coduri standard | HL7 FHIR R4, 26 tipuri de resurse, LOINC / ICD-10 / ATC / UCUM |
| Versionare | datele medicale sunt corectate, niciodată suprascrise silențios | fiecare actualizare este o versiune nouă; `If-Match` pentru actualizări condiționale |
| Documente | originalele trebuie să rămână neschimbate și trasabile | originale imuabile cu SHA-256, stocare UE criptată cu o cheie gestionată de client |
| Controlul accesului | per pacient, per aplicație, per tip de date | izolare proiect, ID-uri pereche, scopuri OAuth cu filtre de categorie |
| Consimțământ | pacientul decide și se poate răzgândi | granturi pentru 30–365 zile, revocabile, oglindite ca FHIR `Consent` |
| Audit | pacienții și autoritățile de reglementare întreabă cine a văzut ce | fiecare citire și scriere înregistrată și vizibilă pentru pacient |
| Proveniență | o valoare de la un laborator nu este o valoare introdusă de un pacient | tip autor, organizație, practician și sistem sursă la fiecare scriere |
| Integrări | laboratoarele trimit CSV, HL7 v2, JSON; aplicațiile necesită evenimente | import laborator, tranzacții FHIR, webhooks semnate |
| Reîncercări sigure | o medicație sau un rezultat duplicat este o eroare clinică | `Idempotency-Key` la fiecare creare |
| Date de test | pacienții reali nu trebuie să fie niciodată în dezvoltare | o bază de date sandbox cu pacienți sintetici |

## Ce rămâne în backend-ul dvs.

- **utilizatorii și conturile** dvs., precum și maparea fiecărui utilizator la ID-ul pacientului Anpheros (ID-ul pereche pe care îl vede proiectul dvs.);
- **datele produsului** care nu sunt medicale: setări, abonamente, conținut, programări pentru memento-uri;
- **reguli de afaceri** — personalul dvs. care poate vedea ce pacient în produsul dvs.;
- **cheia API**, care nu trebuie trimisă niciodată într-o aplicație mobilă sau web.

## Trei modalități de conectare

**1. Backend-ul dvs. deține cheia API (cel mai comun).** Aplicația dvs. apelează backend-ul dvs.; backend-ul dvs. apelează Anpheros cu o cheie `sk_live_` și vede pacienții creați de proiectul dvs.

```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. Aplicația acționează în numele pacientului cu OAuth.** Pentru persoanele care au deja un cont Anpheros, o aplicație mobilă sau web este un client OAuth *public* cu PKCE: persoana își dă consimțământul pe pagina găzduită, iar aplicația primește un token de acces de 30 de minute și un token de reîmprospătare rotativ pentru acel cont. SDK-urile implementează fluxul (`OAuthFlow`).

**3. Parteneri server-la-server.** Un client confidențial (cu un secret, păstrat pe un server) poate utiliza fluxul authorization-code sau `client_credentials`, care se comportă ca o cheie API pentru acel proiect.

## Păstrarea backend-ului sincronizat

Abonează-te la webhooks în loc să folosești polling. Livrările sunt semnate (`Anpheros-Signature`, HMAC-SHA256 peste timestamp și body), livrate cel puțin o dată și posibil în afara ordinii; deduplică după ID-ul evenimentului și ignoră versiunile învechite.

```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();
});
```

## Gestionarea erorilor și a limitelor

- Tratați `404` ca "nu este vizibil pentru dumneavoastră", niciodată ca o dovadă că un înregistrare nu există.
- `403` înseamnă că acreditarea există, dar s-ar putea să nu permită acest lucru — un scop lipsă sau o resursă scrisă de o altă organizație.
- `429` vine cu `Retry-After`; SDK-urile așteaptă și reîncearcă automat, așa cum fac și pentru `5xx`.
- Păstrați `Anpheros-Request-Id` apelurilor eșuate pentru suport.

[Erori](https://developers.anpheros.com/ro/guides/errors) · [Limite și limite de rată](https://developers.anpheros.com/ro/guides/limits)

## Întrebări frecvente

### Ce bază de date ar trebui să folosească o aplicație medicală?
Una care păstrează datele medicale într-o formă standardizată, versionată și controlează accesul per pacient. Anpheros este o bază de date gestionată pentru sănătate, construită pe HL7 FHIR R4: înregistrarea fiecărui pacient este versionată și căutabilă, fiecare scriere poartă proveniență, iar o aplicație vede un pacient doar dacă a creat înregistrarea sau pacientul și-a dat consimțământul. Baza dvs. de date proprie păstrează restul datelor produsului dvs. — conturi, facturare, conținut. Pentru compromisurile proiectării propriilor tabele în loc, consultați [FHIR vs. o bază de date medicală personalizată](https://developers.anpheros.com/ro/guides/fhir-vs-custom-database).

### Există o bază de date gratuită pentru aplicații medicale?
Da. Sandbox-ul Anpheros este gratuit: conectați-vă cu Google, obțineți o cheie cu un singur clic, iar proiectul dvs. primește proprii 30 de pacienți sintetici și până la 10.000 de scrieri pe zi. Producția începe de la 99 € pe lună pentru 2.500 de pacienți, cu prima lună gratuită; accesul la producție este pentru organizații verificate cu un acord de procesare a datelor semnat. Consultați [Prețuri](https://developers.anpheros.com/ro/guides/pricing).

### Pot păstra date reale ale pacienților în sandbox-ul gratuit?
Nu. Sandbox-ul este doar pentru date sintetice: fiecare proiect sandbox primește proprii pacienți sintetici, iar cheile sandbox nu pot accesa producția. Înregistrările reale ale pacienților aparțin unui proiect de producție.

## Conexe

- [FHIR vs. o bază de date medicală personalizată](https://developers.anpheros.com/ro/guides/fhir-vs-custom-database): când să proiectați propriile tabele și când să utilizați FHIR
- [Cum să construiți un API pentru domeniul sănătății cu TypeScript](https://developers.anpheros.com/ro/guides/healthcare-api-typescript): tutorial pas cu pas cu Express
- [Cum să construiți o aplicație pentru domeniul sănătății cu Flutter](https://developers.anpheros.com/ro/guides/healthcare-app-flutter): tutorial pas cu pas cu SDK-ul Dart
- [Dezvoltare software pentru domeniul sănătății](https://developers.anpheros.com/ro/guides/healthcare-software)
- [Construiți o aplicație pentru domeniul sănătății](https://developers.anpheros.com/ro/guides/build-a-healthcare-app)
- [Arhitectură](https://developers.anpheros.com/ro/guides/architecture)
- [API pentru date medicale](https://developers.anpheros.com/ro/guides/medical-data-api)
- [SDK-uri](https://developers.anpheros.com/ro/guides/sdks)