# Egészségügyi alkalmazás architektúra

> Diagramok és adatfolyamok: páciens az alkalmazáshoz az Anpheros API-n keresztül a FHIR rekordhoz és külső szolgáltatásokhoz, valamint AI ügynök a kontextus API-hoz engedélyezett adatokhoz.

Source: https://developers.anpheros.com/hu/guides/architecture

Az Anpheros az orvosi adatréteg az Ön alkalmazása (vagy AI ügynöke) és a páciens rekordja között. Az Ön alkalmazása megtartja saját felhasználói felületét és üzleti logikáját; az orvosi rekord, a hozzájárulás, az eredet és az audit az Anpherosban él, és egy API-n keresztül érhető el.

```
  Your application, backend or AI agent
  (mobile app, web app, clinic system, lab system, LLM-based assistant)
                        │  HTTPS · API key (sk_test_ / sk_live_) or OAuth token (at_…)
                        ▼
  Anpheros Platform API
  ├─ /v1        simplified REST: patients, observations, conditions, medications,
  │             documents, timeline, provenance, context, labs, webhooks
  ├─ /fhir/R4   strict FHIR R4: 26 resource types, search, history, transactions,
  │             $everything, $summary (IPS), $validate
  └─ /oauth     OAuth 2.1 + PKCE, SMART on FHIR, OpenID Connect
                        │  every request: project isolation · scopes · rate limits
                        ▼
  One FHIR R4 record per patient
  ├─ versions of every resource (history)   ├─ Provenance for every write
  ├─ Consent resources for every grant      └─ access log visible to the patient
                        │
                        ▼
  Events out: signed webhooks to your server (ids only, never clinical content)
```

## A páciens nézőpontja: az embertől a külső szolgáltatásokig

```
Patient
   ↓   uses an app, chooses what to share, sees every access
Healthcare application          Anpheros Daily, or your own app
   ↓   REST v1 / FHIR R4 over HTTPS, API key or OAuth token
Anpheros API
   ↓   isolation, scopes, idempotency, provenance
FHIR medical data               the patient's record: 26 resource types, every version kept
   ↓   only what the patient allowed, only for as long as allowed
External healthcare services    laboratories (lab import), clinics (directory, acting-as),
                                other apps (OAuth / SMART), your backend (webhooks)
```

## Az AI nézet: az agenttől az engedélyezett adatokig

```
AI agent or LLM application     runs the model you choose — hosted or local
   ↓   POST /v1/context  {patient, task, question, budget_tokens}
Medical context API             plans which parts of the record matter, fits them into the budget,
   ↓                            labels every item with author type and source, records a manifest
Authorised medical data         only records the project created or the patient granted;
                                the read appears in the patient's access log
```

A modell soha nem kap hitelesítő adatokat, és soha nem hívja meg közvetlenül az Anpheros-t; az Ön alkalmazása kéri le a kontextust, és eldönti, mit küldjön a modellnek. Két teljes példa az API hívásokkal: egy AI egészségügyi alkalmazás a [AI egészségügyi alkalmazások](https://developers.anpheros.com/hu/guides/ai-healthcare) részben, és egy hozzájárulással rendelkező agent az [AI agentek és orvosi adatok](https://developers.anpheros.com/hu/guides/ai-agents-medical-data) részben. Részletek: [AI agentek és orvosi adatok](https://developers.anpheros.com/hu/guides/ai-agents-medical-data), [LLM alkalmazások és egészségügyi adatok](https://developers.anpheros.com/hu/guides/llm-healthcare-data).

## A rekord

Minden betegnek van egy rekordja, amely FHIR R4 erőforrásokból áll: `Observation` az életjelekhez, laboreredményekhez, tünetekhez és napi aktivitási összefoglalókhoz, `Condition` és `EpisodeOfCare`, `MedicationStatement` és `MedicationAdministration`, `DocumentReference`, `Immunization`, `AllergyIntolerance` és mások – összesen 26 típus, amelyek élőben szerepelnek a CapabilityStatement-ben (`GET /fhir/R4/metadata`). Nincs szükség saját séma elsajátítására: a REST API az erőforrások egyszerűbb nézete, ugyanazokkal az azonosítókkal.

Semmi sem íródik felül észrevétlenül. Minden frissítés új verziót hoz létre (`/fhir/R4/{type}/{id}/_history`), és minden verziő rögzíti a létrehozó projektet és azt a szervezetet, amelynek nevében íródott.

## Kétféle bejutás

| | API kulcs | OAuth hozzáférési token |
|---|---|---|
| Kinézet | `sk_test_…` / `sk_live_…` | `at_…` |
| Használja | a szervered | egy alkalmazás, amely egy páciens nevében jár el |
| Látja | a projekt által létrehozott pácienseket | pontosan egy pácienst, a páciens által megadott hatókörökön belül |
| Tipikus használat | saját alkalmazás backendje, laboratóriumi rendszer, klinikai integráció | egy harmadik féltől származó alkalmazás vagy AI asszisztens, amely a páciens már meglévő rekordjához fér hozzá |

Egy projekt soha nem látja egy másik projekt pácienseit, hacsak a páciens nem ad hozzáférést. Minden projekt saját azonosítót kap ugyanazon személyhez (páros azonosítók), így az azonosítók nem korrelálhatók az alkalmazások között, és az Ön hatókörén kívüli rekord `404`-ként, soha sem `403`-ként válaszol.

## Két környezet

A sandbox és a production külön adatbázisok. Egy sandbox kulcs (`sk_test_`) fizikailag nem érheti el a valós betegeket; minden sandbox projekt kap egy saját, 30 szintetikus beteget tartalmazó másolatot, amelyet szabadon módosíthat és visszaállíthat. A production kulcsokat (`sk_live_`) igazolt szervezeteknek adják ki.

## Adatfolyamok

**Az Ön alkalmazása ír.** `POST /v1/patients/{id}/observations` egy `Idempotency-Key` segítségével. A platform tárol egy FHIR `Observation`-t, ír egy `Provenance`-t (szerző típusa: beteg, gyakorló, eszköz, importálás vagy AI), naplózza a hozzáférést, és küld egy `resource.created` webhookot az előfizetett végpontokra.

**Egy másik alkalmazás olvas beleegyezéssel.** A beteg jóváhagyja a fogadott beleegyezési oldalon (`/oauth/authorize`), kiválasztva a rekordot és az időtartamot (30–365 nap). Az alkalmazás kicseréli a kódot tokenekre, és csak azt olvassa, amit a hatókörök megengednek. A beteg látja az alkalmazást, annak hatóköreit és minden olvasást a hozzáférési naplójában, és bármikor visszavonhatja azt.

**Egy laboratórium eredményeket szállít.** `POST /v1/patients/{id}/labs/import` CSV, HL7 v2 ORU^R01 vagy JSON jelentéssel; minden eredmény egy laboratóriumi `Observation`-vé válik, ahol ismert, LOINC kódokkal, és ugyanazon jelentés újraküldése biztonságos.

**Egy AI modellnek kontextusra van szüksége.** `POST /v1/context` visszaadja a rekord azon részeit, amelyek egy feladathoz relevánsak, egy token költségvetésen belül, minden elem forrásával címkézve; a hívás egy manifest id-vel van rögzítve. Maga a modell ott fut, ahol Ön választ.

## Hol helyezkedik el az Anpheros a saját építéshez képest

| Szempont | Saját építés | Anpheros-szal |
|---|---|---|
| Orvosi adatmodell | táblák tervezése minden rekordtípushoz | FHIR R4 erőforrások, 26 típus |
| Interoperabilitás | egyéni export formátumok | FHIR R4, International Patient Summary, SMART on FHIR |
| Hozzájárulás | engedélyezési, hatókör-, lejárati és visszavonási logika építése | OAuth 2.1 engedélyek tükrözve FHIR `Consent`-ként |
| Audit | naplózás építése és mód a betegeknek való megjelenítésére | minden olvasás és írás naplózva és látható a beteg számára |
| Laboratóriumi integráció | minden labor formátumának elemzése | CSV, HL7 v2 ORU és JSON import |
| AI kontextus | lekérdezési és összefoglaló kód írása | kontext API token költségkerettel és származási címkékkel |

## Kapcsolódó

- [Mi az az Anpheros?](https://developers.anpheros.com/hu/guides/what-is-anpheros)
- [Egészségügyi szoftverfejlesztés](https://developers.anpheros.com/hu/guides/healthcare-software)
- [Orvosi alkalmazás backend és adatbázis](https://developers.anpheros.com/hu/guides/medical-app-backend)
- [Egészségügyi alkalmazás készítése](https://developers.anpheros.com/hu/guides/build-a-healthcare-app)
- [Hozzájárulási és hozzáférési modell](https://developers.anpheros.com/hu/guides/consent)
- [Biztonság, adatvédelem és adattartózkodási hely](https://developers.anpheros.com/hu/guides/security)