# Orvosi alkalmazás backendje és adatbázisa

> Mit kell kezelnie egy orvosi alkalmazás backendjének és adatbázisának, mely részeket biztosít az Anpheros felügyelt egészségügyi adatbázisként, mi marad a backendedben, három csatlakozási mód, és hogyan maradj szinkronban webhookokkal.

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

**Az orvosi alkalmazás backendje egy egészségügyi alkalmazás szerveroldala: tárolja a páciens adatait, érvényesíti, ki láthatja azokat, naplót vezet a változásokról, és kommunikál laborokkal, klinikákkal és más szolgáltatásokkal.** Az Anpheros-szal a backend orvosi része – az egészségügyi adatbázis, amely minden páciens rekordját, annak előzményeit, hozzájárulásait, eredetét, auditját, laborimportját és eseményeit tartalmazza – a platformon keresztül érhető el API-n keresztül, és a saját backended csak a termék specifikus részeket tárolja.

## Mit kell kezelnie egy orvosi backendnek

| Felelősség | Miért nehéz az egészségügyben | Az Anpheros-szal |
|---|---|---|
| Orvosi adatmodell | több tucat adatfajta, mindegyik szabványos kódokkal | HL7 FHIR R4, 26 erőforrástípus, LOINC / ICD-10 / ATC / UCUM |
| Verziókezelés | az orvosi adatokat javítják, soha nem írják felül csendben | minden frissítés új verzió; `If-Match` feltételes frissítésekhez |
| Dokumentumok | az eredetiknek változatlanoknak és nyomon követhetőnek kell maradniuk | megváltoztathatatlan eredetik SHA-256-tal, EU tárolás ügyfél által felügyelt kulccsal titkosítva |
| Hozzáférés-vezérlés | páciensenként, alkalmazásonként, adattípusonként | projekt izoláció, páros azonosítók, OAuth hatókörök kategóriaszűrőkkel |
| Hozzájárulás | a páciens dönt, és meggondolhatja magát | 30–365 napos engedélyek, visszavonható, tükrözve FHIR `Consent`-ként |
| Audit | a páciensek és a szabályozók megkérdezik, ki mit látott | minden olvasás és írás naplózva és látható a páciens számára |
| Származás | egy labor értéke nem egy páciens által beírt érték | szerző típusa, szervezet, gyakorló és forrásrendszer minden írásnál |
| Integrációk | a laborok CSV-t, HL7 v2-t, JSON-t küldenek; az alkalmazások eseményeket igényelnek | labor import, FHIR tranzakciók, aláírt webhookok |
| Biztonságos újrakísérletek | egy duplikált gyógyszer vagy eredmény klinikai hiba | `Idempotency-Key` minden létrehozásnál |
| Tesztadatok | a valós páciensek soha nem lehetnek a fejlesztésben | egy homokozó adatbázis szintetikus páciensekkel |

## Mi marad a backendben

- a **felhasználók és fiókok**, valamint az egyes felhasználók és az ő Anpheros betegazonosítójuk közötti megfeleltetés (az Ön projektje által látott páronkénti azonosító);
- **termékadatok**, amelyek nem orvosi jellegűek: beállítások, előfizetések, tartalom, emlékeztetők ütemezése;
- **üzleti szabályok** – melyik munkatársuk láthatja melyik beteget a termékében;
- az **API kulcs**, amelyet soha nem szabad mobil- vagy webalkalmazásba csomagolni.

## Három csatlakozási mód

**1. A backend tárolja az API-kulcsot (leggyakoribb).** Az Ön alkalmazása meghívja a backendjét; a backend az Ön által létrehozott betegeket látja az `sk_live_` kulccsal az Anpheros felé.

```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. Az alkalmazás a beteg nevében jár el OAuth segítségével.** Azok számára, akiknek már van Anpheros rekordjuk, egy mobil vagy webes alkalmazás egy *nyilvános* OAuth kliens PKCE-vel: a személy hozzájárul a hosztolt oldalon, és az alkalmazás egy 30 perces hozzáférési tokent és egy forgó frissítési tokent kap az adott rekordhoz. Az SDK-k implementálják a folyamatot (`OAuthFlow`).

**3. Szerver-szerver közötti partnerek.** Egy bizalmas kliens (titkos kulccsal, szerveren tárolva) használhatja az authorization-code folyamatot, vagy a `client_credentials`-at, amely az adott projektre vonatkozó API-kulcsként működik.

## Backend szinkronizálása

A lekérdezés (polling) helyett iratkozzon fel webhookokra. A kézbesítések aláírtak (`Anpheros-Signature`, HMAC-SHA256 a timestamp és a body felett), legalább egyszeriek és esetleg nem sorrendben érkeznek; az eseményazonosító alapján duplikátumokat távolítson el és hagyja figyelmen kívül az elavult verziókat.

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

## Hibák és korlátok kezelése

- A `404`-t úgy kezelje, mint "nem látható az Ön számára", soha ne tekintse bizonyítéknak arra, hogy egy rekord nem létezik.
- A `403` azt jelenti, hogy az engedély hitelesítőadatok léteznek, de nem tudják ezt megtenni – hiányzó hatókör, vagy egy másik szervezet által írt erőforrás.
- A `429`-t a `Retry-After` kíséri; az SDK-k automatikusan várnak és újra próbálkoznak, ahogy teszik a `5xx` esetében is.
- A sikertelen hívások `Anpheros-Request-Id`-ét őrizze meg támogatási célokra.

[Hibák](https://developers.anpheros.com/hu/guides/errors) · [Korlátok és sebességkorlátok](https://developers.anpheros.com/hu/guides/limits)

## Gyakran ismételt kérdések

### Milyen adatbázist használjon egy orvosi alkalmazás?
Olyat, amely szabványos, verziószámozott formában tárolja az orvosi adatokat, és betegszintenként szabályozza a hozzáférést. Az Anpheros egy felügyelt egészségügyi adatbázis, amely az HL7 FHIR R4-en alapul: minden beteg rekordja verziószámozott és kereshető, minden írás magával hozza a származási információt, és egy alkalmazás csak akkor lát egy beteget, ha létrehozta a rekordot, vagy a beteg hozzájárult ehhez. A saját adatbázisa tárolja a termék többi adatát – fiókokat, számlázást, tartalmat. Az egyedi táblák tervezésének előnyeiről és hátrányairól lásd: [FHIR vs. egyedi orvosi adatbázis](https://developers.anpheros.com/hu/guides/fhir-vs-custom-database).

### Van ingyenes adatbázis orvosi alkalmazásokhoz?
Igen. Az Anpheros sandbox ingyenes: jelentkezzen be Google-lel, szerezzen egy kulcsot egy kattintással, és a projektje megkapja a saját 30 szintetikus betegét és napi 10 000 írásig terjedő lehetőséget. A termelés havi 49 eurótól indul 2500 betegre, az első hónap ingyenes; a termelési hozzáférés igazolt szervezetek számára érhető el, aláírt adatfeldolgozási megállapodással. Lásd: [Árazás](https://developers.anpheros.com/hu/guides/pricing).

### Tárolhatok valós betegadatokat az ingyenes sandboxban?
Nem. A sandbox csak szintetikus adatokra használható: minden sandbox projekt a saját szintetikus betegeit kapja, és a sandbox kulcsok nem érhetik el a termelést. A valós betegrekordok termelési projektbe tartoznak.

## Kapcsolódó

- [FHIR vs. egyedi orvosi adatbázis](https://developers.anpheros.com/hu/guides/fhir-vs-custom-database): mikor tervezzen saját táblákat, és mikor használjon FHIR-t
- [Egészségügyi API építése TypeScript-tel](https://developers.anpheros.com/hu/guides/healthcare-api-typescript): lépésről lépésre útmutató Express-szel
- [Egészségügyi alkalmazás építése Flutterrel](https://developers.anpheros.com/guides/healthcare-app-flutter): lépésről lépésre útmutató a Dart SDK-val
- [Egészségügyi szoftverfejlesztés](https://developers.anpheros.com/hu/guides/healthcare-software)
- [Egészségügyi alkalmazás építése](https://developers.anpheros.com/hu/guides/build-a-healthcare-app)
- [Architektúra](https://developers.anpheros.com/hu/guides/architecture)
- [Orvosi adat API](https://developers.anpheros.com/hu/guides/medical-data-api)
- [SDK-k](https://developers.anpheros.com/hu/guides/sdks)