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

FHIR kontra egyedi egészségügyi adatbázis

Saját táblázatok vagy HL7 FHIR R4 az egészségügyi adatokhoz: ugyanaz az olvasás mindkét módon tárolva, a kompromisszumok egymás mellett, mikor melyik a megfelelő, és a szokásos felosztás az Ön adatbázisa és a FHIR rekord között.

Egy egészségügyi terméket indító csapat általában korán ugyanazzal a választással néz szembe: saját táblákat tervez a betegek, mérések és diagnózisok számára PostgreSQL-ben vagy más adatbázisban, vagy kezdetektől fogva HL7 FHIR R4 erőforrásként tárolja az orvosi adatokat. Egyedi séma gyorsabb az első napon, és pontosan illeszkedik a termékedhez. A FHIR több gondolkodást igényel előre, és minden alkalommal megtérül, amikor az adatoknak el kell hagyniuk a rendszeredet, auditálni kell őket, beleegyezéssel meg kell osztani, vagy el kell olvasnia valakinek, aki nem te vagy. Ez az oldal becsületesen bemutatja az előnyöket és hátrányokat, ugyanazt az olvasmányt mindkét módon tárolva, és megmondja, mikor melyik választás a helyes.

Ez egy más kérdés, mint hogy melyik FHIR szervert használjuk. Ehhez lásd: Hogyan hasonlítja össze az Anpheros a többi FHIR szervert.

Ugyanaz az adat, kétféleképpen

Vérnyomásérték egyedi séma szerint:

CREATE TABLE bp_readings (
  id          uuid PRIMARY KEY,
  user_id     uuid REFERENCES users(id),
  systolic    int,
  diastolic   int,
  measured_at timestamptz,
  created_at  timestamptz DEFAULT now()
);

Egyszerű, gyorsan lekérdezhető, pontosan az, amire az alkalmazásnak szüksége van. Aztán jönnek a kérdések, amelyekre a tábla nem ad választ:

• Melyik eszköz vagy személy állította elő az értéket? A beteg írta be, mandzsettával mérték, vagy egy nővér rögzítette?
• Mi volt az érték, mielőtt valaki javította, és ki javította?
• Hogyan olvassa el egy klinikai rendszer, egy laboratórium vagy egy biztosító? Mit jelent a systolic az ő rendszerükben?
• Hogyan osztja meg a beteg az adatot az orvosa alkalmazásával, és hogyan szünteti meg a megosztást a következő hónapban?
• Ha hozzáadunk pulzusszámot, testsúlyt, HbA1c-t és további 200 mérést, az 200 táblát jelent, vagy egy általános táblát, amelyet magad tervezel meg?

Ugyanaz az adat FHIR R4 formátumban:

{"resourceType": "Observation", "status": "final",
 "category": [{"coding": [{"system": "http://terminology.hl7.org/CodeSystem/observation-category", "code": "vital-signs"}]}],
 "code": {"coding": [{"system": "http://loinc.org", "code": "85354-9", "display": "Blood pressure panel"}]},
 "subject": {"reference": "Patient/d09e3942-…"}, "effectiveDateTime": "2026-10-10T08:30:00Z",
 "component": [
   {"code": {"coding": [{"system": "http://loinc.org", "code": "8480-6"}]}, "valueQuantity": {"value": 138, "unit": "mmHg", "system": "http://unitsofmeasure.org", "code": "mm[Hg]"}},
   {"code": {"coding": [{"system": "http://loinc.org", "code": "8462-4"}]}, "valueQuantity": {"value": 88, "unit": "mmHg", "system": "http://unitsofmeasure.org", "code": "mm[Hg]"}}],
 "meta": {"versionId": "1"}}

Bővebb, de minden része hordoz olyan jelentést, amelyet bármely FHIR rendszer megoszt: a LOINC megmondja, mit mértek, az UCUM a mértékegységet, a meta.versionId elindít egy előzményt, és ugyanez a Observation alakzat tartalmazza a többi 200 mérést. Az Anpheros segítségével egy Provenance erőforrás rögzíti azt is, hogy ki írta azt. Hogyan tároljunk orvosi dokumentációt FHIR R4 használatával részletesen bemutatja.

Egymás mellett

Mikor érdemes egyedi sémát használni

• Az adatok nem igazán orvosi jellegűek, vagy nem egy személyre vonatkoznak. Edzési tervek, tartalom, termékkatalógus: használjon saját táblákat.
• Rövid életű prototípus annak tesztelésére, hogy van-e rá igény a termékre, szintetikus adatokkal és áttelepülési tervvel.
• Az adatok nem modellezhetők jól szabványokkal, például egy új kutatási mérés. A FHIR továbbra is képes kezelni (Observation saját kódtáblával, vagy Basic), de egy egyedi tábla lehet világosabb.
• Intenzív analitika. Még akkor is, ha a FHIR a rendszer nyilvántartása, a legtöbb csapat másolja az adatokat egy adattárházba a saját formátumában a jelentéskészítéshez.

Mikor jó választás a FHIR

• Az adatok egy személy egészségügyi nyilvántartását képezik: mérések, diagnózisok, gyógyszerek, allergiák, laboreredmények, dokumentumok.
• Valaha is elhagyja a rendszert: a pácienshez, orvoshoz, klinikához, laborhoz, biztosítóhoz, AI modellhez vagy egy versenytárshoz, amikor a páciens költözik.
• Meg kell mutatnia, hogy ki mit írt, és mi változott: auditok, klinikai biztonság, viták.
• A páciensek alkalmazásonként engedélyezik és visszavonják a hozzáférést.
• Az Európai Unióban értékesít, ahol az Európai Egészségügyi Adattér szabványos formátumokban cserélhető nyilvántartásokat vár el.

A szokásos középső út

A legtöbb termék végül mindkettőt tartalmazza, az adatok típusa szerint felosztva:

your database                         FHIR record (Anpheros)
─────────────                         ──────────────────────
users, sessions, settings             Patient
subscriptions, billing                Observation, Condition, MedicationStatement
product content, feature flags        AllergyIntolerance, Immunization, DocumentReference
user id → patient id (one column)     Provenance, Consent, history
caches and analytics copies  ◄─────── webhooks

Az Ön adatbázisa kicsi és termékformájú marad. Az orvosi nyilvántartás szabványosított, verziószámozott és megosztható, és Önnek nem kellett felépítenie. A Medical app backend and database részletesen leírja ezt a felosztást, a How to build a healthcare API with TypeScript pedig meg is valósítja.

Mit kell tudni a FHIR saját kezű felépítéséhez

A FHIR választása nem jelenti azt, hogy FHIR szervert kell írnia. Lehetőségei közé tartozik egy Ön által futtatott nyílt forráskódú szerver, egy felhőszolgáltató FHIR tárolója, egy nyílt forráskódú egészségügyi platform, vagy egy felügyelt egészségügyi adatbázis, mint például az Anpheros. Ezek abban különböznek, hogy ki kezeli a hozzájárulást, az auditálást, a származást, a lakóhelyet és az integrációkat, amit a Hogyan hasonlítja össze az Anpheros a többi FHIR szervert részletez.

Gyakran ismételt kérdések

A FHIR egy adatbázis?

Nem. A FHIR egy szabvány az egészségügyi adatok szerkezetére és cseréjére: erőforrások, kódok és egy REST API. Egy FHIR szerver vagy felügyelt FHIR adatbázis tárolja az erőforrásokat, és az API-t egy valós adatbázis tetején implementálja.

Tárolhatok FHIR erőforrásokat PostgreSQL-ben magam?

Igen, JSON oszlopokban saját indexekkel, és néhány nyílt forráskódú szerver pontosan ezt teszi. A munka a tárolással kapcsolatos minden mással jár: keresési paraméterek, verziókezelés, hivatkozások, érvényesítés, betegszintű hozzáférés-vezérlés és eredet.

Kezdhetek egyedi sémával, és később áttérhetek FHIR-re?

Megteheti, és sok csapat így is tesz, de a migráció egy megfeleltetési projekt: minden táblához olyan kódok, egységek és szerzők tartoznak, amelyeket soha nem rögzített. Az orvosi adatok FHIR-ként való tárolása az első funkciótól kezdve kevesebbe kerül, mint később konvertálni.

Szükségem van FHIR-re a GDPR betartásához?

Nem. A GDPR nem ír elő konkrét formátumot. A FHIR megkönnyíti több kötelezettség teljesítését: hordozhatóság (a rekord szabványos formátumban exportálható), célonkénti hozzáférés-vezérlés, és annak bemutatása, hogy ki melyik adatot dolgozta fel.

Kapcsolódó

• FHIR adatbázisséma: hogyan tárolódnak és indexelődnek a FHIR erőforrások
• Orvosi rekordok tárolása FHIR R4 használatával
• FHIR platform
• Az Anpheros összehasonlítása más FHIR szerverekkel
• Egészségügyi alkalmazás backend és adatbázis
• Egészségügyi API

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