# Az Anpheros összehasonlítása más FHIR szerverekkel

> Önhöz telepített FHIR szerverek, felhő alapú FHIR tárolók, nyílt forráskódú egészségügyi platformok és az Anpheros egymás mellett: ki jogosít fel hozzáférést, beleegyezést, eredetet, lakóhelyet, árazást, és mikor melyik a megfelelő választás.

Source: https://developers.anpheros.com/hu/guides/fhir-server-comparison

**A FHIR backendet választó csapatok általában négyféle opciót mérlegelnek: egy általuk maguk által üzemeltetett nyílt forráskódú szervert, egy felhőszolgáltató által kínált felügyelt FHIR tárolót, egy nyílt forráskódú egészségügyi platformot annak felhőben futó kiadásával, vagy egy felügyelt egészségügyi adatbázist, mint az Anpheros.** Ez az útmutató leírja, mire jó mindegyik típus, és hol helyezkedik el az Anpheros, a nyilvánosan elérhető dokumentáció alapján, 2026. októberi állapot szerint. Az itt említett termékek esetében ellenőrizze azok saját dokumentációját; a funkciók változhatnak.

## A négyféle

| | Önhostolt FHIR szerver (pl. HAPI FHIR) | Felhő alapú FHIR tároló (pl. Google Cloud Healthcare API, Azure Health Data Services, AWS HealthLake) | Egészségügyi platform (pl. Medplum) | Anpheros |
|---|---|---|---|---|
| Mi ez | egy általad futtatott FHIR szerver | egy FHIR adattár egy felhő fiókon belül | egy FHIR-natív alkalmazás platform hitelesítéssel, munkafolyamatokkal és hostolt kiadással | egy felügyelt egészségügyi adatbázis: FHIR R4 rekord betegként, hozzájárulás, API, audit |
| Ki engedélyezi a hozzáférést | bármi, amit köré építesz | a felhő IAM rendszere, projektenként vagy adatkészletenként | a platform hozzáférési szabályzatai, általad konfigurálva | a beteg (OAuth 2.1 hozzájárulás) vagy a szervezet (API kulcs) |
| Betegközpontú hozzájárulás és audit | nem | nem | felépíthető a szabályzati modelljével | beépített, a beteg számára látható |
| Származás minden írásnál | ha hozzáadod | ha hozzáadod | támogatott a FHIR által; te érvényesíted | szükséges és automatikus |
| Azonosító elkülönítés az alkalmazások között | nem | nem | nem | páronkénti azonosítók alkalmazásonként |
| Laboratóriumi import (HL7 v2) | külön eszközök | részleges (v2-ről FHIR-re való leképezés néhány tárolóban) | általad írt integrációk | beépített, egy kérés |
| Adatmegőrzés helye | ahol hostolod | a szolgáltató által kínált régiók | a hostolástól függ | csak Európai Unió |
| Árazás | az infrastruktúrád és az időd | használatalapú (kérések, tárhely) | tervenként vagy önhostolt | szervezetként, tárolt betegek száma alapján |
| Legjobb | tanuláshoz, teljes kontrollhoz, szokatlan adatformátumokhoz | olyan csapatoknak, akik már abban a felhőben vannak, és maguk építik az egészségügyi réteget | olyan csapatoknak, akik nyílt forráskódú kódbázison szeretnének építkezni és teljes stack-et birtokolni | olyan csapatoknak, akik szeretnék, hogy az egészségügyi réteg készen legyen, és a termék legyen a munkájuk |

## Google Cloud Healthcare API vagy felügyelt platform?

A Google terméke szó szerint a Cloud Healthcare API nevet viseli, így sok "healthcare API" keresésnél ez jelenik meg elsőként. Ez egy felhő alapú FHIR tároló (plusz HL7 v2 és DICOM tárolók) a Google Cloud projekteden belül: tárolás, FHIR keresés és IAM alapú hozzáférés, használat alapján számlázva. A többit neked kell felépítened – betegközpontú hozzájárulás és audit, alkalmazás izoláció, labor importálás, SDK-k és egy sandbox tesztadatokkal. Az Anpheros biztosítja ezeket a részeket és az EU-ban tárolja az adatokat; nem biztosít FHIR tárolót a saját felhő fiókodon belül. Válassz aszerint, hogy kinek kell birtokolnia az egészségügyi réteget: a csapatodnak (Cloud Healthcare API) vagy a platformnak (Anpheros).

## Open-source FHIR szerver vagy felügyelt?

Az olyan nyílt forráskódú szerverek, mint a HAPI FHIR, bárhol futtathatók (Docker image-ek elérhetők), és támogatják a teljes FHIR specifikációt, saját profilokkal és kiterjesztésekkel. Ha egyet futtat production környezetben, akkor Ön felel az adatbázis, a frissítések, a biztonság, a biztonsági mentések és a hozzáférési réteg működtetéséért. A felügyelt platformok bizonyos szabadságot (az Anpheros 26 erőforrástípust tárol) cserébe kínálnak a működtetés elkerüléséért. Lásd a [FHIR adatbázis séma](https://developers.anpheros.com/hu/guides/fhir-database-schema) részt, hogy megtudja, mit tárol egy ilyen szerver a háttérben.

## Mikor jó választás az Anpheros

- Olyan terméket épít, amely betegeknek, klinikáknak, laboratóriumoknak vagy mesterséges intelligenciának szól, és a termékre, nem pedig a rekordokra szeretne koncentrálni.
- A beteg beleegyezése és az auditnapló, amelyet a beteg el tud olvasni, követelmény, nem pedig "nice-to-have" (GDPR 9. cikk, EHDS).
- Az Ön adatai az Európai Unióban kell, hogy maradjanak.
- FHIR R4-et szeretne, de egy egyszerűbb REST nézetet, SDK-kat és webhookokat is, mindezt egyetlen szállítótól.
- Ingyenesen szeretne kezdeni, egy sandboxban, valósághű szintetikus betegekkel, és átállni a termelésbe átírás nélkül.

## Mikor egy másik opció jobb

- Olyan FHIR erőforrás típusokra, profilokra vagy kiegészítőkre van szüksége, amelyek kívül esnek az Anpheros által támogatott 26-on, vagy egy teljesen egyedi adatmodellre: egy önállóan üzemeltetett szerver megadja ezt a szabadságot.
- Szervezete megfelelési okokból mindent egyetlen felhőszámlán belül szeretne tartani: egy felhő alapú FHIR tároló illeszkedik ehhez a szabályzathoz.
- Ön szeretné birtokolni és módosítani a teljes stack-et, beleértve az engedélyezési szervert és a felhasználói felület komponenseit: egy nyílt forráskódú platform erre lett tervezve.
- Önnek ma van szüksége EHR launch, Bulk Data export vagy `system/` scope-okra: az Anpheros ezeket még nem kínálja (lásd: [Beteg beleegyezés implementálása SMART on FHIR használatával](https://developers.anpheros.com/hu/guides/smart-on-fhir-backend)).

## A méltányos döntés módja

Számolja össze az egészségügyi réteg azon részeit, amelyekre a termékének szüksége van: hozzájárulás, eredet, audit, azonosítók, laboratóriumi import, dokumentumtárolás, tartózkodási hely, és becsülje meg a hónapokat, amelyek szükségesek ezek megépítéséhez és karbantartásához az Ön által preferált opción. Ezután hasonlítsa össze ezt azzal a termékmunkával, amelyre ezek a hónapok fordíthatóak lettek volna. Az Anpheros a helyes válasz, ha a második szám nagyobb.

## Kapcsolódó

- [Egészségügyi API platform: mit tartalmaz és hogyan válasszunk](https://developers.anpheros.com/hu/guides/healthcare-api-platform): a kérdések, amelyeket fel kell tenni minden beszállítónak
- [FHIR vs. egyedi orvosi adatbázis](https://developers.anpheros.com/hu/guides/fhir-vs-custom-database): mikor tervezzünk saját táblákat és mikor használjunk FHIR-t
- [Ingyenes FHIR adatbázis és sandbox](https://developers.anpheros.com/hu/guides/free-fhir-database)
- [FHIR platform](https://developers.anpheros.com/hu/guides/fhir)
- [Orvosi alkalmazás backend és adatbázis](https://developers.anpheros.com/hu/guides/medical-app-backend)
- [Egészségügyi startupok](https://developers.anpheros.com/hu/guides/healthcare-startups)
- [Biztonság, adatvédelem és adattartózkodási hely](https://developers.anpheros.com/hu/guides/security)