# Egészségügyi API: mi ez és hogyan működik

> Mi az egészségügyi API, hogyan működik egy hívás, mire figyeljünk, és egy ingyenes FHIR R4 egészségügyi API beteg beleegyezéssel, eredetiséggel és EU-s tárhelyszolgáltatással – példákkal és GYIK-kel.

Source: https://developers.anpheros.com/hu/guides/healthcare-api

**Az egészségügyi API egy programozási felület, amelyen keresztül a szoftverek egészségügyi adatokat – betegrekordokat, megfigyeléseket, diagnózisokat, gyógyszereket, dokumentumokat – olvasnak és írnak, és amelyen keresztül az adatokhoz való hozzáférést engedélyezik.** Az Anpheros Platform API egy egészségügyi API egy beteg által vezérelt HL7 FHIR R4 rekord felett: az alkalmazások ezt használják orvosi adatok tárolására és lekérésére, a beteg beleegyezésének megszerzésére és a változásokról való értesítésre.

<!-- visual: hapi-hero -->

## Hogyan működik egy egészségügyi API hívás

Bármelyik gyártóról is legyen szó, egy egészségügyi API hívás ugyanazokat az ellenőrzőpontokat futtatja végig: ki hív, melyik beteg és milyen adatokhoz férhet hozzá, hol tárolják az adatokat, ki írta azokat, és kinek kell tudnia a változásukról.

<!-- visual: hapi-request -->

## Egészségügyi API-k típusai

| Típus | Mit cserél | Tipikus felhasználás |
|---|---|---|
| FHIR REST API-k | FHIR erőforrások HTTP-n keresztül (`GET /Observation?patient=…`) | a klinikai adatcsere modern szabványa |
| SMART on FHIR / OAuth | engedélyezés FHIR API-khoz | harmadik féltől származó alkalmazások számára, hogy a felhasználó engedélyével hozzáférjenek egy rekordhoz |
| HL7 v2 üzenetek | pipe-delimitált üzenetek (`ORU^R01` eredményekhez, `ADT` beutaztatásokhoz) | laboratóriumi és kórházi rendszerek, gyakran interfészeken keresztül, nem pedig HTTP-n |
| Dokumentumcsere | klinikai dokumentumok (PDF, CDA, FHIR dokumentumcsomagok) | összefoglalók, elbocsátó levelek, beutalók |
| Szabadalmaztatott REST API-k | gyártóspecifikus JSON | egyetlen termék saját mobilalkalmazása vagy integrációi |

Az Anpheros az első kettőt kombinálja magjaként, HL7 v2 laboratóriumi eredményeket fogad bemenetként, dokumentumokat az eredetiekkel együtt tárol, és FHIR dokumentumcsomagokat (International Patient Summary) állít elő. Egyszerűbb REST API-t is kínál ugyanazon adatok felett azoknak a fejlesztőknek, akik nem akarnak közvetlenül FHIR-rel dolgozni.

## Mire figyeljünk egy egészségügyi API kiválasztásakor

<!-- visual:hapi-checklist:replace -->

- **Szabványosított adatmodell**: hogy az adatok egyedi leképzés nélkül mozoghassanak a rendszerek között.
- **Beteg által vezérelt engedélyezés**: ne csak az alkalmazás által vezérelt hitelesítő adatok legyenek.
- **Származás (Provenance)**: ki írt minden értéket, kinek a nevében, melyik rendszerből.
- **Előzmények (History)**: verziók a csendes felülírások helyett.
- **Auditálhatóság**: az olvasásoké, nem csak az írásoké.
- **Biztonságos újrapróbálkozások (idempotencia)** és **előrejelezhető hibák**, mert az egészségügyi adatok nem duplikálódhatnak vagy veszhetnek el.
- **Elszigetelés** a közös infrastruktúrát használó alkalmazások között.
- **Adat-tartózkodási hely (Data residency)**, amely megegyezik a betegek tartózkodási helyével.

Az oldal további része bemutatja, hogyan jelenik meg mindez az Anpheros API-ban.

## Az Anpheros API áttekintése

| Felület | Alapútvonal | Cél |
|---|---|---|
| FHIR R4 | `/fhir/R4` | 26 erőforrástípus; olvasás, keresés, létrehozás, frissítés, törlés, előzmények, tranzakciók, `$everything`, `$summary`, `$validate` |
| REST v1 | `/v1` | betegek, megfigyelések, állapotok, gyógyszerek, dokumentumok, idővonal, származás, AI kontextus, laboratóriumi import, terminológia, webhookok |
| OAuth 2.1 | `/oauth` | hozzájárulási oldal, tokenek (PKCE), visszavonás, OpenID Connect kulcsok |
| Betegoldal | `/me` | egy személy saját rekordjai, ki rendelkezik hozzáféréssel, hozzáférési napló, visszavonás |
| Felfedezés | `/fhir/R4/metadata`, `/fhir/R4/.well-known/smart-configuration`, `/openapi.json` | az API géppel olvasható leírásai |

Alap URL: `https://platform.anpheros.com`. A sandbox és a production ezt használja; a kulcs határozza meg az adatréteget.

### Hitelesítés

- **API kulcsok** (`sk_test_…`, `sk_live_…`) a szervereihez; ezek látják azokat a betegeket, akiket a projektje létrehozott.
- **OAuth hozzáférési tokenek** (`at_…`) egy olyan alkalmazáshoz, amely egy beteg nevében jár el egy hozzájárulás alapján.

```bash
curl https://platform.anpheros.com/v1/patients -H "Authorization: Bearer $KEY"
```

### Biztonságos írás

A `POST` kérések elfogadnak egy `Idempotency-Key`-t: egy újraküldött kérés ugyanazzal a kulccsal visszaadja az eredeti választ, és nem hoz létre semmit. Minden írás kap egy `Provenance`-t; az író típusa a törzsben (`author_type`) vagy olyan fejlécben kerül elküldésre, mint a `X-Anpheros-Author-Type`, `X-Anpheros-Source-System`, `X-Anpheros-Origin-Id` és `X-Anpheros-On-Behalf-Of`.

```bash
curl -X POST https://platform.anpheros.com/v1/patients/$PID/observations \
     -H "Authorization: Bearer $KEY" -H 'content-type: application/json' -H "Idempotency-Key: $(uuidgen)" \
     -d '{"code": "29463-7", "display": "Body weight", "category": "vital-signs",
          "value": 71.4, "unit": "kg", "effective_at": "2026-09-28T07:30:00Z", "author_type": "patient"}'
```

### Hibák és korlátok

A FHIR végpontok `OperationOutcome`-val válaszolnak; a többi `{"error": {"type", "message", "field"}}`-vel. Minden válasz tartalmaz `Anpheros-Request-Id`-t. Az alapértelmezett korlát percenként 600 kérés kulcsonként és IP címenként. [Hibák](https://developers.anpheros.com/hu/guides/errors) · [Korlátok](https://developers.anpheros.com/hu/guides/limits)

### Események

Aláírt webhookok a `resource.created`, `resource.updated`, `resource.deleted`, `consent.granted`, `consent.revoked`, `document.finalized` és `ping` eseményekhez. [Webhookok](https://developers.anpheros.com/hu/guides/webhooks)

## FHIR és REST v1 közötti választás

Használja a **FHIR**-t, ha már dolgozik FHIR-rel, olyan erőforrástípusokra van szüksége, amelyeket a `/v1` nem fed le (például `Immunization`, `Procedure` vagy `CarePlan`), vagy más FHIR rendszerekkel cserél adatot. Használja a **REST v1**-et olyan alkalmazáskódokhoz, amelyek a gyakori esetekben lapos JSON-t szeretnének. Mindkettő ugyanazokat az erőforrásokat olvassa és írja ugyanazokkal az azonosítókkal, így egy projekt keverheti őket. A [Medical data API](https://developers.anpheros.com/hu/guides/medical-data-api) részletesen ismerteti az adatműveleteket.

## Gyakran ismételt kérdések

### Mi az egészségügyi API?
Programozható interfész, amelyen keresztül a szoftver egészségügyi adatokat – betegrekordokat, megfigyeléseket, diagnózisokat, gyógyszereket és dokumentumokat – olvas és ír, és amelyen keresztül az adatokhoz való hozzáférés engedélyezett. A modern egészségügyi API-k HL7 FHIR R4-et használnak az adatokhoz, és OAuth 2.0 vagy 2.1 SMART on FHIR-rel a hozzáférés engedélyezéséhez.

### Mi a különbség az egészségügyi API és a FHIR API között?
A FHIR egy olyan szabvány, amelyet egy egészségügyi API követhet. A FHIR API FHIR erőforrásokat cserél REST-en keresztül; egy egészségügyi API elfogadhat HL7 v2 üzeneteket, dokumentumokat vagy saját JSON formátumot is. Az Anpheros kínál egy FHIR R4 API-t és egy egyszerűbb REST API-t ugyanazon adatok felett.

### Van ingyenes egészségügyi API fejlesztőknek?
Igen. Az Anpheros sandbox ingyenes és önkiszolgáló: jelentkezzen be Google-lel, szerezzen API kulcsot, és dolgozzon 30 szintetikus beteggel FHIR R4 vagy REST protokollon keresztül. A termelés havi 49 eurótól indul, az első hónap ingyenes.

### Hogyan adnak a betegek hozzájárulást egy egészségügyi API-hoz?
OAuth 2.1 PKCE-vel: az alkalmazás elküldi a személyt egy hozzájárulási oldalra SMART on FHIR hatókörökkel; a személy kiválasztja, mit oszt meg és mennyi ideig, megtekintheti a hozzáférési naplót, és bármikor visszavonhatja a hozzáférést.

### Hol tárolják az adatokat?
Az Európai Unióban: a szolgáltatás és annak adatbázisai a Google Cloud `europe-west4` (Hollandia) rendszerében futnak.

### Melyik egészségügyi API-t válasszam?
Hasonlítsa össze az adat szabványt, ki engedélyezi a hozzáférést, a származást és az auditálást, az adatok tartózkodási helyét, hogyan viselkednek az ismétlési kísérletek és a hibák, valamint hogy ingyenesen tesztelhet-e valósághű adatokkal. A [Egészségügyi API platform: mit tartalmaz és hogyan válasszunk](https://developers.anpheros.com/hu/guides/healthcare-api-platform) ezeket kérdésekké alakítja, amelyeket bármely eladónak feltehet.

<!-- visual:cta-hapi -->

## Kapcsolódó

- [EHR API és orvosi nyilvántartások API-ja](https://developers.anpheros.com/hu/guides/ehr-api)
- [Egészségügyi API platform: mit tartalmaz és hogyan válasszunk](https://developers.anpheros.com/hu/guides/healthcare-api-platform)
- [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
- [Orvosi nyilvántartások tárolása FHIR R4 segítségével](https://developers.anpheros.com/hu/guides/store-medical-records-fhir): lépésről lépésre útmutató curl-lel
- [Egészségügyi API beteg beleegyezéssel](https://developers.anpheros.com/hu/guides/healthcare-api-patient-consent)
- [SMART on FHIR backend](https://developers.anpheros.com/hu/guides/smart-on-fhir-backend)
- [Orvosi adat API](https://developers.anpheros.com/hu/guides/medical-data-api)
- [FHIR platform](https://developers.anpheros.com/hu/guides/fhir)
- [Egészségügyi adatok interoperabilitása](https://developers.anpheros.com/hu/guides/interoperability)
- [Egészségügyi integrációk](https://developers.anpheros.com/hu/guides/healthcare-integrations)
- [API referencia (OpenAPI)](https://developers.anpheros.com/docs) · [Hitelesítés és OAuth](https://developers.anpheros.com/hu/guides/authentication)