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

Orvosi alkalmazás backend és adatbázis

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

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

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é.

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.

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 · Korlátok és sebességkorlátok

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.

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.

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: mikor tervezzen saját táblákat, és mikor használjon FHIR-t
• Egészségügyi API építése TypeScript-tel: lépésről lépésre útmutató Express-szel
• Egészségügyi alkalmazás építése Flutterrel: lépésről lépésre útmutató a Dart SDK-val
• Egészségügyi szoftverfejlesztés
• Egészségügyi alkalmazás építése
• Architektúra
• Orvosi adat API
• SDK-k

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