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

FHIR kontra własna baza danych medycznych

Własne tabele czy HL7 FHIR R4 dla danych medycznych: to samo czytanie zapisane na oba sposoby, kompromisy zestawione obok siebie, kiedy co jest właściwe i typowy podział między Twoją bazą danych a repozytorium FHIR.

Zespół rozpoczynający produkt medyczny zazwyczaj na wczesnym etapie staje przed tym samym wyborem: zaprojektować własne tabele dla pacjentów, pomiarów i diagnoz w PostgreSQL lub innej bazie danych, czy od początku przechowywać dane medyczne jako zasoby HL7 FHIR R4. Niestandardowe schematy są szybsze pierwszego dnia i idealnie pasują do Twojego produktu. FHIR wymaga więcej przemyśleń na początku i zwraca się za każdym razem, gdy dane muszą opuścić Twój system, zostać poddane audytowi, udostępnione za zgodą lub odczytane przez kogoś innego niż Ty. Ta strona uczciwie przedstawia kompromisy, z tym samym odczytem przechowywanym na oba sposoby, i mówi, kiedy każdy wybór jest właściwy.

Jest to inne pytanie niż który serwer FHIR wybrać. W tej sprawie zobacz Jak Anpheros wypada na tle innych serwerów FHIR.

To samo odczytanie, na dwa sposoby

Odczyt ciśnienia krwi w niestandardowym schemacie:

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

Proste, szybkie do zapytania, dokładnie to, czego potrzebuje aplikacja. Następnie pojawiają się pytania, na które tabela nie odpowiada:

• Które urządzenie lub osoba wygenerowała wartość? Czy została wpisana przez pacjenta, zmierzona przez mankiet, czy wprowadzona przez pielęgniarkę?
• Jaka była wartość przed jej poprawieniem i kto ją poprawił?
• Jak odczytuje ją system kliniczny, laboratorium lub ubezpieczyciel? Co oznacza systolic w ich systemie?
• Jak pacjent udostępnia ją aplikacji swojego lekarza i przestaje udostępniać w przyszłym miesiącu?
• Kiedy dodajesz tętno, wagę, HbA1c i 200 innych pomiarów, czy są to 200 tabel, czy jedna ogólna tabela, którą projektujesz samodzielnie?

To samo odczytanie w formacie 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"}}

Bardziej rozwlekłe, ale każda część ma znaczenie, które jest wspólne dla każdego systemu FHIR: LOINC mówi, co zostało zmierzone, UCUM mówi o jednostce, meta.versionId rozpoczyna historię, a ta sama struktura Observation zawiera pozostałe 200 pomiarów. Z Anpheros, zasób Provenance również rejestruje, kto go zapisał. Jak przechowywać dokumentację medyczną przy użyciu FHIR R4 omawia to szczegółowo.

Obok siebie

Kiedy niestandardowy schemat jest właściwym wyborem

• Dane nie są faktycznie medyczne lub nie dotyczą jednej osoby. Plany treningowe, treści, katalog produktów: użyj własnych tabel.
• Krótkotrwały prototyp do testowania zainteresowania produktem, z danymi syntetycznymi i planem migracji.
• Dane, których żaden standardowy model dobrze nie opisuje, na przykład nowy pomiar badawczy. FHIR nadal może je przechowywać (Observation z własnym systemem kodowania lub Basic), ale niestandardowa tabela może być jaśniejsza.
• Ciężka analityka. Nawet jeśli FHIR jest systemem źródłowym, większość zespołów kopiuje dane do hurtowni danych w swojej własnej strukturze do celów raportowania.

Kiedy FHIR jest właściwym wyborem

• Dane to historia medyczna osoby: pomiary, diagnozy, leki, alergie, wyniki badań laboratoryjnych, dokumenty.
• Dane opuszczą Twój system: do pacjenta, lekarza, kliniki, laboratorium, ubezpieczyciela, modelu AI lub konkurenta, gdy pacjent się przeniesie.
• Musisz pokazać, kto co napisał i co się zmieniło: audyty, bezpieczeństwo kliniczne, spory.
• Pacjenci będą udzielać i cofać dostęp na aplikację.
• Sprzedajesz w Unii Europejskiej, gdzie European Health Data Space oczekuje wymiany rekordów w standardowych formatach.

Zwykła, środkowa ścieżka

Większość produktów kończy z oboma rozwiązaniami, podzielonymi według rodzaju danych:

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

Twoja baza danych pozostaje niewielka i dopasowana do produktu. Dokumentacja medyczna jest standardowa, wersjonowana i możliwa do udostępnienia, a Ty nie musiałeś jej budować. Backend i baza danych aplikacji medycznej szczegółowo opisuje ten podział, a Jak zbudować API dla opieki zdrowotnej w TypeScript je implementuje.

Co jest potrzebne do samodzielnego zbudowania FHIR

Wybór FHIR nie oznacza pisania serwera FHIR od zera. Twoje opcje to: serwer open-source, który uruchamiasz samodzielnie, FHIR store dostawcy chmury, platforma opieki zdrowotnej open-source lub zarządzana baza danych opieki zdrowotnej, taka jak Anpheros. Różnią się one tym, kto zarządza zgodami, audytem, pochodzeniem danych, rezydencją i integracjami, co zostało przedstawione w Jak Anpheros wypada na tle innych serwerów FHIR.

Często zadawane pytania

Czy FHIR to baza danych?

Nie. FHIR to standard dotyczący struktury i wymiany danych medycznych: zasobów, kodów i REST API. Serwer FHIR lub zarządzana baza danych FHIR przechowuje zasoby i implementuje API na bazie rzeczywistej bazy danych.

Czy mogę samodzielnie przechowywać zasoby FHIR w PostgreSQL?

Tak, jako kolumny JSON z własnymi indeksami, a niektóre serwery open-source robią właśnie to. Praca polega na wszystkim, co dotyczy przechowywania: parametrach wyszukiwania, wersjonowaniu, referencjach, walidacji, kontroli dostępu na pacjenta i pochodzeniu danych.

Czy mogę zacząć od niestandardowego schematu i później przejść na FHIR?

Możesz, i wiele zespołów tak robi, ale migracja to projekt mapowania: każda tabela potrzebuje kodów, jednostek i autorów, których nigdy nie rejestrowała. Przechowywanie danych medycznych w formacie FHIR od pierwszej funkcji kosztuje mniej niż późniejsza konwersja.

Czy potrzebuję FHIR, aby przestrzegać RODO?

Nie. RODO nie wymaga konkretnego formatu. FHIR ułatwia spełnienie kilku obowiązków: przenośności (rekord jest eksportowany w standardowym formacie), kontroli dostępu na cel oraz pokazywania, kto przetwarzał jakie dane.

Powiązane

• Schemat bazy danych FHIR: jak zasoby FHIR są przechowywane i indeksowane
• Jak przechowywać dokumentację medyczną przy użyciu FHIR R4
• Platforma FHIR
• Jak Anpheros wypada w porównaniu z innymi serwerami FHIR
• Backend i baza danych aplikacji medycznych
• API dla służby zdrowia

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