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

FHIR vs. vlastní databáze pro zdravotnictví

Vaše vlastní tabulky nebo HL7 FHIR R4 pro zdravotnická data: stejné čtení uložené oběma způsoby, kompromisy vedle sebe, kdy je co vhodné a obvyklé rozdělení mezi vaši databázi a FHIR záznam.

Tým, který začíná s produktem pro oblast zdravotnictví, obvykle brzy čelí stejné volbě: navrhnout si vlastní tabulky pro pacienty, měření a diagnózy v PostgreSQL nebo jiné databázi, nebo od začátku ukládat lékařská data jako zdroje HL7 FHIR R4. Vlastní schéma je první den rychlejší a přesně odpovídá vašemu produktu. FHIR stojí více přemýšlení na začátku a vrací se pokaždé, když data musí opustit váš systém, být auditována, sdílena se souhlasem nebo čtena někým jiným než vámi. Tato stránka upřímně uvádí kompromisy, se stejným záznamem uloženým oběma způsoby, a říká, kdy je každá volba správná.

Toto je jiná otázka než který FHIR server použít. Pro to viz Jak se Anpheros srovnává s jinými FHIR servery.

Stejné měření, dva způsoby

Měření krevního tlaku ve vlastním schématu:

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()
);

Jednoduché, rychlé na dotazování, přesně to, co aplikace potřebuje. Pak přicházejí otázky, na které tabulka neodpovídá:

Které zařízení nebo osoba vytvořila hodnotu? Zapsal ji pacient, změřil ji manžeta, nebo ji zadala sestra?
Jaká byla hodnota předtím, než ji někdo opravil, a kdo ji opravil?
Jak ji čte klinický systém, laboratoř nebo pojišťovna? Co znamená systolic v jejich systému?
Jak ji pacient sdílí s aplikací svého lékaře a příští měsíc přestane sdílet?
Když přidáte srdeční frekvenci, váhu, HbA1c a dalších 200 měření, jsou to 200 tabulek, nebo jedna obecná tabulka, kterou si navrhnete sami?

Stejné měření jako FHIR R4:

{"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"}}

Obsáhlejší, ale každá část má význam, který sdílí jakýkoli FHIR systém: LOINC říká, co bylo změřeno, UCUM říká jednotku, meta.versionId začíná historii a stejný tvar Observation obsahuje dalších 200 měření. S Anpheros také Provenance resource zaznamenává, kdo jej zapsal. Jak ukládat lékařské záznamy pomocí FHIR R4 vás tím provede.

Vedle sebe

	Vlastní schéma	FHIR R4
Čas do první funkce	hodiny	den nebo dva na naučení se zdrojů
Přizpůsobení vašemu produktu	přesné	obecné; pohled vašeho produktu sedí navrchu
Přidání nového druhu dat	migrace na druh	obvykle nový kód v existujícím zdroji
Význam mimo váš systém	žádný bez mapování	sdílené kódy (LOINC, ICD-10, ATC, UCUM)
Historie a opravy	navrhujete vy	verze a `_history` dle návrhu
Kdo co napsal	navrhujete vy	`Provenance` (automaticky v Anpheros)
Výměna s klinikami, laboratořemi, jinými aplikacemi	vlastní integrace pokaždé	FHIR R4 API, import HL7 v2, International Patient Summary
Souhlas pacienta na aplikaci	navrhujete vy	rozsahy SMART on FHIR a OAuth
Dotazování pro analytiku	prostý SQL	vyhledávání FHIR nebo export do vašeho skladu
Regulace (GDPR článek 9, EHDS)	dokumentujete každou část	standardní formáty, na které se regulace odkazuje

Kdy je vlastní schéma správnou volbou

Data nejsou skutečně lékařská nebo se netýkají jedné osoby. Tréninkové plány, obsah, produktový katalog: použijte vlastní tabulky.
Krátkodobý prototyp k otestování zájmu o produkt, se syntetickými daty a plánem na přesun.
Data, která standardní modely dobře nepokrývají, například nové výzkumné měření. FHIR je stále může nést (Observation s vaším vlastním kódem systému, nebo Basic), ale vlastní tabulka může být srozumitelnější.
Náročná analytika. I když je FHIR systémem záznamu, většina týmů kopíruje data do datového skladu ve své vlastní podobě pro reporting.

Kdy je FHIR správnou volbou

Data představují zdravotní záznam osoby: měření, diagnózy, léky, alergie, laboratorní výsledky, dokumenty.
Data opustí váš systém: k pacientovi, lékaři, klinice, laboratoři, pojišťovně, AI modelu nebo konkurenci, když se pacient stěhuje.
Potřebujete ukázat, kdo co napsal a co se změnilo: audity, klinická bezpečnost, spory.
Pacienti budou udělovat a odebírat přístup na základě aplikace.
Prodáváte v Evropské unii, kde Evropský prostor pro zdraví očekává, že záznamy budou směnitelnými ve standardních formátech.

Obvyklá střední cesta

Většina produktů skončí s oběma, rozdělenými podle druhu dat:

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

Vaše databáze zůstane malá a tvarovaná podle produktu. Lékařský záznam je standardní, verzovaný a sdílitelný, a vy jste ho nemuseli sestavovat. Backend a databáze lékařské aplikace popisuje toto rozdělení podrobně a Jak vytvořit zdravotnické API pomocí TypeScriptu ho sestavuje.

Co je potřeba k vlastnímu vybudování FHIR

Volba FHIR neznamená psaní FHIR serveru. Vaše možnosti jsou open-source server, který provozujete, FHIR úložiště cloudového poskytovatele, open-source zdravotnická platforma nebo spravovaná zdravotnická databáze jako Anpheros. Liší se v tom, kdo spravuje souhlas, audit, původ dat, rezidenci a integrace, což je popsáno v Jak si Anpheros stojí v porovnání s jinými FHIR servery.

Často kladené dotazy

Je FHIR databáze?

Ne. FHIR je standard pro strukturu a výměnu zdravotnických dat: zdroje, kódy a REST API. FHIR server nebo spravovaná FHIR databáze ukládá zdroje a implementuje API nad skutečnou databází.

Mohu si sám ukládat FHIR zdroje do PostgreSQL?

Ano, jako JSON sloupce s vlastními indexy, a některé open-source servery to přesně dělají. Práce spočívá ve všem kolem ukládání: vyhledávací parametry, verzování, reference, validace, řízení přístupu na pacienta a původ dat.

Mohu začít s vlastním schématem a později přejít na FHIR?

Můžete, a mnoho týmů to dělá, ale migrace je projekt mapování: každá tabulka potřebuje kódy, jednotky a autory, které nikdy nezaznamenala. Ukládání lékařských dat jako FHIR od první funkce stojí méně než jejich pozdější konverze.

Potřebuji FHIR pro dodržení GDPR?

Ne. GDPR nevyžaduje konkrétní formát. FHIR usnadňuje splnění několika povinností: přenositelnost (záznam se exportuje ve standardním formátu), řízení přístupu na základě účelu a zobrazení toho, kdo zpracoval jaká data.

Související

Schéma databáze FHIR: jak jsou zdroje FHIR ukládány a indexovány
Jak ukládat lékařské záznamy pomocí FHIR R4
Platforma FHIR
Jak si Anpheros stojí v porovnání s jinými FHIR servery
Backend a databáze lékařských aplikací
API pro zdravotnictví

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