AnpherosAnpheros PlatformDevelopers

Try it free in the sandbox · first FHIR call in 5 minutesFree · 30 synthetic patients · no card

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

Diagramok és adatfolyamok: betegtől az alkalmazáson át az Anpheros API-ig a FHIR rekordig és külső szolgáltatásokig, valamint AI ügynök a kontextus API-hoz engedélyezett adatokhoz.

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 részben, és egy hozzájárulással rendelkező agent az AI agentek és orvosi adatok részben. Részletek: AI agentek és orvosi adatok, LLM alkalmazások és egészségügyi adatok.

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ó

Try it free in the sandbox · first FHIR call in 5 minutesFree · 30 synthetic patients · no card

Product updates by email

New features, guides and the end of the beta. One email a month at most.

Send me occasional Anpheros Platform updates by email (new features, API changes, guides). I'll confirm by email and can unsubscribe in one click from any email. Privacy