A FHIR szerver FHIR erőforrásokat tárol és szolgáltat. Egy FHIR platform az, amire valójában szüksége van egy egészségügyi termék kiadásához: a szerver, plusz az azonosítás, hozzájárulás, eredet, elkülönítés az ügyfelek között, webhookok, dokumentumok, terminológia és valaki, aki üzemelteti a GDPR alatt. Ez az útmutató ismerteti a különbséget, és leírja, hogyan tölti be az Anpheros Platform az egyes hiányosságokat, így eldöntheti, hogy erre épít-e, vagy futtatja a sajátját.
Műszaki verzió fejlesztőknek: Egészségügyi API platform · FHIR szerver összehasonlítás a developers.anpheros.com oldalon, kérésekkel, válaszokkal és korlátokkal. Ez az oldal a közérthető verzió.
Szerver versus platform
A nyílt forráskódú FHIR szerverek (például a HAPI) kiválóak a FHIR részében: erőforrások, keresés, érvényesítés, történet. Amit Önre hagynak, az minden, ami körülötte van:
| Szükséglet | FHIR szerver | FHIR platform |
|---|---|---|
| Erőforrás tárolás, keresés, történet | igen | igen |
| Ki olvashatja melyik beteget | az Ön kódja | beépített hozzájárulás |
| Ki írta minden értéket | az Ön kódja | Eredet minden írásnál |
| Több ügyfél egy rendszeren | az Ön kódja | projekt elkülönítés, párosított azonosítók |
| Beteg-orientált hozzájárulási képernyő | az Ön kódja | OAuth 2.1 + SMART on FHIR |
| Értesítések az Ön alkalmazásához | lekérdezés | aláírt webhookok |
| Reális tesztadatok | az Ön tesztadatai | 30 szintetikus beteg sandboxonként |
| Tárhely, biztonsági mentések, GDPR, DPA | az Ön üzemeltetési csapata | mellékelve |
Ha van üzemeltetési csapata, megfelelőségi tisztviselője és hat hónapja, a saját szerver futtatása jó választás. Ha van egy terméke, amit ki kell adnia, egy platform gyorsabb.
Hogyan épül fel az Anpheros Platform
Egy FHIR R4 rekord betegként. 26 erőforrás típus, LOINC, ICD-10 és ATC kódokkal, íráskor validálva. A szigorú FHIR API a /fhir/R4 címen érhető el, a CapabilityStatement a /fhir/R4/metadata címen, és egy egyszerű REST API a /v1 címen ugyanazokat az adatokat szolgálja ki ugyanazokkal az azonosítókkal.
Projekt elkülönítés és párosított azonosítók. Egy projekt (API kulcs) csak az általa létrehozott betegeket látja. Minden projekt saját azonosítót kap ugyanahhoz a személyhez; a belső azonosítók soha nem hagyják el a platformot. Az Ön hatókörén kívüli betegekre való hivatkozásokat egy átlátszatlan, projektenkénti token takarja el.
A hozzájárulás dönti el az olvasást, a tulajdonjog dönti el az írást. A beteg hozzájárulásával egy szervezet látja a teljes rekordot, beleértve azt is, amit más klinikák írtak, de csak azt változtathatja meg vagy törölheti, amit maga írt. Minden erőforrás minden verziója rögzíti a projektet, amely írta; egy másik projekt írása magyarázattal elutasításra kerül.
Eredet és audit minden írásnál. A Provenance.agent.onBehalfOf megnevezi a klinikát vagy szervezetet az írás időpontjában; egy audit sor rögzíti, hogy ki, mit, mikor, milyen engedéllyel, melyik alkalmazásból. A beteg elolvashatja a hozzáférési naplóját, szintén FHIR AuditEvent erőforrásokként.
Vékony, aláírt webhookok. Az események azonosítókat és verziókat tartalmaznak, soha nem klinikai tartalmat; az erőforrást az API-n keresztül olvassa. A kézbesítések HMAC-SHA256-tal vannak aláírva, és 24 órán keresztül visszavonással próbálkoznak.
A sandbox és a production külön adatbázisok. Egy sk_test_ kulcs nem érhet el valódi beteget. A sandbox ingyenes és önkiszolgáló.
EU tartózkodási hely. Cloud Run a europe-west4 régióban, adatfeldolgozási megállapodással a production szervezetek számára.
Mi az, ami szándékosan nincs benne
- Nincs klinikai döntéstámogatás. A platform tárol, kódol és megoszt; nem diagnosztizál vagy javasol kezelést.
- Nincs teljes gyógyszeradatbázis interakciókkal. A gyógyszereket ATC kódokkal kódolják, és egy csomagolt ATC és LOINC alcsoport elérhető kereséshez, de az interakció ellenőrzése az Ön komponense vagy egy licencelt szolgáltatás.
- Nincs kórházi szintű HL7 v2 üzenetküldő busz. Van egy HL7 v2 ORU^R01 import a laborjelentésekhez; nincs ADT vagy rendeléskezelés.
Ezen korlátok előzetes ismerete egy hét felfedezést takarít meg.
Mikor futtassa inkább a saját szerverét
- Saját kórházi hálózatán belül kell tárolnia, külső feldolgozó nélkül.
- FHIR R5-re vagy olyan profilokra van szüksége, amelyeket a platform nem implementál.
- Az Ön terméke maga a FHIR szerver.
Minden más esetben kezdje a sandboxban, mérjen, és döntsön adatok alapján. Az első órát a developers.anpheros.com/guides/first-hour címen írják le; a teljes API referenciát a platform.anpheros.com/docs címen találja.
Gyakori kérdések
Az Anpheros egy FHIR szerver?
Tartalmaz egyet: egy FHIR R4 API-t 26 erőforrás típussal, kereséssel, történettel, $everything, $summary, $validate és terminológiai műveletekkel. Körülötte van a hozzájárulás, eredet, elkülönítés, webhookok és tárhely, ami platformmá teszi.
Melyik FHIR verzió?
FHIR R4 (4.0.1), az EU és az USA szabályozása által megkövetelt verzió, és a legtöbb rendszer által implementált. A megfelelőséget az Inferno ellenőrizte; lásd az IPS megfelelőségi jegyzeteket.
Több klinika osztozhat egy beteg rekordján?
Igen, ez a lényege. A beteg hozzájárulásával minden klinika elolvassa a teljes rekordot, és saját erőforrásokat ír, mindegyik az eredetével megjelölve. Egy klinika sem tudja megváltoztatni, amit egy másik írt.
Van ingyenes FHIR backend fejlesztéshez?
Igen. A sandbox ingyenes, önkiszolgáló, és projektenként 30 szintetikus beteggel érkezik. Lásd: Ingyenes FHIR szerver: a sandbox.
Hogyan tudok elvándorolni, ha szükséges?
Minden FHIR R4 és exportálható: a Patient/{id}/$everything egy beteg teljes rekordját Bundle-ként adja vissza. Nincs saját formátum, amit fel kellene bontani.
Tartsd magadnál az egészségügyi dokumentációdat
Az Anpheros Daily egy helyen tárolja a tüneteket, leleteket, gyógyszereket és dokumentumokat, szabványos formátumban, az irányításod alatt. Az Alap csomag ingyenes.