# Бекенд медичного застосунку та база даних

> Що повинен обробляти бекенд медичного застосунку та його база даних, які частини надає Anpheros як керована база даних охорони здоров'я, що залишається у вашому бекенді, три способи підключення та як залишатися синхронізованим за допомогою вебхуків.

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

**Бекенд медичного застосунку — це серверна частина медичного застосунку: він зберігає дані пацієнтів, контролює, хто може їх бачити, веде історію змін і взаємодіє з лабораторіями, клініками та іншими сервісами.** З Anpheros медична частина цього бекенду — база даних охорони здоров'я, яка містить записи кожного пацієнта, його історію, згоду, походження, аудит, імпорт лабораторних даних та події — надається платформою через API, а ваш власний бекенд зберігає лише те, що є специфічним для вашого продукту.

## Що повинен обробляти медичний бекенд

| Відповідальність | Чому це складно в охороні здоров'я | З Anpheros |
|---|---|---|
| Медична модель даних | десятки видів даних, кожен зі стандартними кодами | HL7 FHIR R4, 26 типів ресурсів, LOINC / ICD-10 / ATC / UCUM |
| Версіонування | медичні дані виправляються, ніколи не перезаписуються мовчки | кожне оновлення є новою версією; `If-Match` для умовних оновлень |
| Документи | оригінали повинні залишатися незмінними та відстежуваними | незмінні оригінали з SHA-256, зберігання в ЄС зашифроване ключем, керованим клієнтом |
| Контроль доступу | на пацієнта, на додаток, на тип даних | ізоляція проектів, парні ідентифікатори, OAuth scopes з фільтрами категорій |
| Згода | пацієнт вирішує і може передумати | дозволи на 30–365 днів, відкличні, дзеркально відображені як FHIR `Consent` |
| Аудит | пацієнти та регулятори запитують, хто що бачив | кожне читання та запис реєструється та видиме пацієнту |
| Походження | значення з лабораторії — це не значення, введене пацієнтом | тип автора, організація, практикуючий лікар та вихідна система при кожному записі |
| Інтеграції | лабораторії надсилають CSV, HL7 v2, JSON; додатки потребують подій | імпорт з лабораторії, транзакції FHIR, підписані вебхуки |
| Безпечні повторні спроби | дубльовані ліки або результат є клінічною помилкою | `Idempotency-Key` при кожному створенні |
| Тестові дані | реальні пацієнти ніколи не повинні бути в розробці | база даних пісочниці з синтетичними пацієнтами |

## Що залишається у вашому бекенді

- ваші **користувачі та облікові записи**, а також відображення кожного користувача на його ідентифікатор пацієнта Anpheros (парний ідентифікатор, який бачить ваш проєкт);
- **дані продукту**, які не є медичними: налаштування, підписки, контент, розклади нагадувань;
- **бізнес-правила** — хто з вашого персоналу може бачити якого пацієнта у вашому продукті;
- **API ключ**, який ніколи не повинен бути вбудований у мобільний або веб-додаток.

## Три способи підключення

**1. Ваш бекенд зберігає API-ключ (найпоширеніший).** Ваш додаток викликає ваш бекенд; ваш бекенд викликає Anpheros з ключем `sk_live_` і бачить пацієнтів, створених вашим проєктом.

```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. Додаток діє від імені пацієнта з OAuth.** Для людей, які вже мають запис в Anpheros, мобільний або веб-додаток є *публічним* OAuth-клієнтом з PKCE: людина надає згоду на розміщеній сторінці, і додаток отримує 30-хвилинний токен доступу та змінний токен оновлення для цього одного запису. SDK реалізують цей потік (`OAuthFlow`).

**3. Партнери "сервер-сервер".** Конфіденчий клієнт (з секретом, що зберігається на сервері) може використовувати потік авторизаційного коду, або `client_credentials`, який діє як API-ключ для цього проєкту.

## Синхронізація вашого бекенду

Підписуйтесь на вебхуки замість опитування. Доставлення підписані (`Anpheros-Signature`, HMAC-SHA256 за часовою міткою та тілом), щонайменше один раз і, можливо, не по порядку; дедуплікуйте за ідентифікатором події та ігноруйте застарілі версії.

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

## Обробка помилок та обмежень

- Розглядайте `404` як "невидимий для вас", а не як доказ того, що запис не існує.
- `403` означає, що облікові дані існують, але можуть не мати доступу до цього — відсутня область дії (scope) або ресурс, записаний іншою організацією.
- `429` супроводжується `Retry-After`; SDK автоматично чекають та повторюють спробу, як і для `5xx`.
- Зберігайте `Anpheros-Request-Id` невдалих викликів для підтримки.

[Помилки](https://developers.anpheros.com/uk/guides/errors) · [Обмеження та ліміти запитів](https://developers.anpheros.com/uk/guides/limits)

## Часті запитання

### Яку базу даних слід використовувати медичному додатку?
Таку, що зберігає медичні дані у стандартному, версіонованому форматі та контролює доступ для кожного пацієнта. Anpheros — це керована база даних для охорони здоров'я, побудована на HL7 FHIR R4: запис кожного пацієнта версіонується та є доступним для пошуку, кожен запис містить інформацію про походження, а додаток бачить пацієнта лише у випадку, якщо він створив запис або пацієнт надав згоду. Ваша власна база даних зберігає решту даних вашого продукту — облікові записи, білінг, контент. Щодо компромісів при розробці власних таблиць замість цього, див. [FHIR проти власної медичної бази даних](https://developers.anpheros.com/uk/guides/fhir-vs-custom-database).

### Чи існує безкоштовна база даних для медичних додатків?
Так. Пісочниця Anpheros є безкоштовною: увійдіть за допомогою Google, отримайте ключ одним кліком, і ваш проєкт отримає 30 синтетичних пацієнтів та до 10 000 записів на день. Виробництво починається від €99 на місяць за 2500 пацієнтів, з першим місяцем безкоштовно; доступ до виробництва надається перевіреним організаціям з підписаною угодою про обробку даних. Див. [Ціни](https://developers.anpheros.com/uk/guides/pricing).

### Чи можу я зберігати реальні дані пацієнтів у безкоштовній пісочниці?
Ні. Пісочниця призначена лише для синтетичних даних: кожен проєкт пісочниці отримує власних синтетичних пацієнтів, а ключі пісочниці не можуть отримати доступ до виробництва. Записи реальних пацієнтів належать до виробничого проєкту.

## Пов'язане

- [FHIR проти власної медичної бази даних](https://developers.anpheros.com/uk/guides/fhir-vs-custom-database): коли проєктувати власні таблиці, а коли використовувати FHIR
- [Як створити медичний API за допомогою TypeScript](https://developers.anpheros.com/uk/guides/healthcare-api-typescript): покроковий посібник з Express
- [Як створити медичний застосунок за допомогою Flutter](https://developers.anpheros.com/uk/guides/healthcare-app-flutter): покроковий посібник з Dart SDK
- [Розробка медичного програмного забезпечення](https://developers.anpheros.com/uk/guides/healthcare-software)
- [Створення медичного застосунку](https://developers.anpheros.com/uk/guides/build-a-healthcare-app)
- [Архітектура](https://developers.anpheros.com/uk/guides/architecture)
- [API медичних даних](https://developers.anpheros.com/uk/guides/medical-data-api)
- [SDK](https://developers.anpheros.com/uk/guides/sdks)