# FHIR vs. niestandardowa baza danych medycznych

> Własne tabele lub HL7 FHIR R4 dla danych medycznych: ten sam odczyt przechowywany na oba sposoby, porównanie kompromisów, kiedy każde rozwiązanie jest właściwe, oraz typowy podział między Twoją bazą danych a rekordem FHIR.

Source: https://developers.anpheros.com/pl/guides/fhir-vs-custom-database

**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](https://developers.anpheros.com/pl/guides/fhir-server-comparison).

## To samo odczytanie, na dwa sposoby

Odczyt ciśnienia krwi w niestandardowym schemacie:

```sql
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:

```json
{"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](https://developers.anpheros.com/pl/guides/store-medical-records-fhir) omawia to szczegółowo.

## Obok siebie

| | Niestandardowe schematy | FHIR R4 |
|---|---|---|
| Czas do pierwszej funkcji | godziny | dzień lub dwa na poznanie zasobów |
| Dopasowanie do Twojego produktu | dokładne | ogólne; widok Twojego produktu znajduje się na wierzchu |
| Dodawanie nowego rodzaju danych | migracja dla każdego rodzaju | zazwyczaj nowy kod w istniejącym zasobie |
| Znaczenie poza Twoim systemem | brak bez mapowania | współdzielone kody (LOINC, ICD-10, ATC, UCUM) |
| Historia i poprawki | projektujesz to | wersje i `_history` z założenia |
| Kto co napisał | projektujesz to | `Provenance` (automatyczne w Anpheros) |
| Wymiana z klinikami, laboratoriami, innymi aplikacjami | każdorazowo niestandardowa integracja | FHIR R4 API, import HL7 v2, International Patient Summary |
| Zgoda pacjenta na aplikację | projektujesz to | zakresy SMART on FHIR i OAuth |
| Zapytania do analiz | zwykły SQL | wyszukiwanie FHIR lub eksport do Twojego magazynu danych |
| Regulacje (RODO Artykuł 9, EHDS) | dokumentujesz każdą część | standardowe formaty, do których odnosi się regulacja |

## 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](https://developers.anpheros.com/pl/guides/medical-app-backend) szczegółowo opisuje ten podział, a [Jak zbudować API dla opieki zdrowotnej w TypeScript](https://developers.anpheros.com/pl/guides/healthcare-api-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](https://developers.anpheros.com/pl/guides/fhir-server-comparison).

## 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](https://developers.anpheros.com/pl/guides/fhir-database-schema): jak zasoby FHIR są przechowywane i indeksowane
- [Jak przechowywać dokumentację medyczną przy użyciu FHIR R4](https://developers.anpheros.com/pl/guides/store-medical-records-fhir)
- [Platforma FHIR](https://developers.anpheros.com/pl/guides/fhir)
- [Jak Anpheros wypada w porównaniu z innymi serwerami FHIR](https://developers.anpheros.com/pl/guides/fhir-server-comparison)
- [Backend i baza danych aplikacji medycznych](https://developers.anpheros.com/pl/guides/medical-app-backend)
- [API dla służby zdrowia](https://developers.anpheros.com/pl/guides/healthcare-api)