Jak implementovat FHIR v české nemocnici

Jak implementovat FHIR v české nemocnici — praktický průvodce z první ruky

Je to přítomnost. Jen o tom většina českých nemocnic zatím neví.

---

Autor: Petr Sovadina Datum: Březen 2026 Kategorie: Healthcare IT Tagy: FHIR, HL7, interoperabilita, zdravotnictví, API, české nemocnice Čas čtení: 18 minut

---

Proč vůbec FHIR?

Představte si tohle: Pacient přijde na urgentní příjem v Brně. Lékař potřebuje jeho alergické reakce, chronickou medikaci a poslední laboratorní výsledky. Všechno existuje — v systému praktického lékaře v Olomouci, v ambulanci kardiologa v Praze a v databázi lékárny na rohu.

Tři systémy. Tři formáty. Nulová komunikace.

Zní vám to povědomě? Mně ano. Vyrostl jsem v rodině dvou lékařů a tyhle příběhy jsem slýchával celý život. Ne ty dramatické ze seriálů — ty reálné. O papírech, které se ztrácejí. O systémech, které spolu nekomunikují. O tom, jak lékař tráví víc času hledáním informací než léčením.

FHIR (Fast Healthcare Interoperability Resources) je standard, který tohle mění. A v tomhle článku vám ukážu, jak ho implementovat v praxi — konkrétně v kontextu českého zdravotnictví.

---

Co je FHIR a proč by vás měl zajímat

FHIR je moderní standard pro výměnu zdravotnických dat vyvinutý organizací HL7 International. Na rozdíl od svých předchůdců (HL7 v2, HL7 v3, CDA) je FHIR:

• Postavený na webových technologiích — REST API, JSON, HTTP
• Modulární — pracuje s “Resources” (zdroji), které lze skládat
• Human-readable — data jsou čitelná i bez specializovaného softwaru
• Široce adoptovaný — používá ho Google Health, Apple Health, Microsoft Azure, Epic, Cerner

FHIR vs. starší standardy

Z mé zkušenosti: Ve STAPROu jsme pracovali s HL7 v2 a přechod na FHIR nám zkrátil čas integrace nového datového zdroje z měsíců na týdny. To není marketing — to jsou reálná čísla z projektů, které dnes používá přes 4 000 lékařů.

---

Anatomie FHIR — základní koncepty

Než se pustíme do implementace, potřebujete rozumět třem základním konceptům.

1. Resources (Zdroje)

Všechno ve FHIR je “Resource”. Pacient, lékař, diagnóza, recept, laboratorní výsledek — každý má svůj definovaný Resource typ.

Nejpoužívanější Resources v českém kontextu:

2. REST API

FHIR používá standardní HTTP metody:

GET    /Patient/123              → Získat pacienta
POST   /Patient                  → Vytvořit pacienta
PUT    /Patient/123              → Aktualizovat pacienta
DELETE /Patient/123              → Smazat pacienta
GET    /Patient?name=Novak       → Vyhledat pacienty

Tohle je krása FHIR. Pokud umíte volat REST API (a v roce 2026 to umí každý developer), umíte pracovat s FHIR.

3. Bundles

Když potřebujete poslat více Resources najednou (typicky: pacient + diagnózy + léky + lab výsledky), použijete Bundle:

{
  "resourceType": "Bundle",
  "type": "transaction",
  "entry": [
    {
      "resource": {
        "resourceType": "Patient",
        "name": [{ "family": "Novák", "given": ["Jan"] }],
        "birthDate": "1985-03-15",
        "identifier": [{
          "system": "https://www.uzis.cz/rid",
          "value": "8503150001"
        }]
      }
    },
    {
      "resource": {
        "resourceType": "Condition",
        "code": {
          "coding": [{
            "system": "https://icd.who.int/browse/2024-01/mms/cs",
            "code": "BA00",
            "display": "Esenciální hypertenze"
          }]
        },
        "subject": { "reference": "Patient/123" }
      }
    }
  ]
}

Všimněte si: diagnóza používá kód MKN-11 (BA00 = Esenciální hypertenze). FHIR je mezinárodní standard, ale kódové systémy jsou lokální. V Česku pracujeme s MKN-11 (resp. stále ještě MKN-10 v přechodném období), SÚKL kódy pro léky a identifikátory ÚZIS.

---

Architektura FHIR integrace pro českou nemocnici

Teď se dostáváme k tomu zajímavému. Jak FHIR reálně nasadit?

Z mé praxe v Medevio a STAPROu vím, že většina českých nemocnic má tuto výchozí situaci:

• NIS (Nemocniční informační systém) — centrální systém (STAPRO, ICZ, CompuGroup)
• LIS (Laboratorní informační systém) — oddělený, vlastní formáty
• PACS (obrazová data) — DICOM standard
• Ambulantní systémy — každé oddělení jiný
• Lékárenský systém — propojený na SÚKL

Cílová architektura

┌─────────────────────────────────────────────────┐
│              FHIR Integration Layer              │
│         (FHIR Server / Facade)                   │
├─────────────────────────────────────────────────┤
│                                                   │
│   ┌─────┐  ┌─────┐  ┌──────┐  ┌──────────────┐ │
│   │ NIS │  │ LIS │  │ PACS │  │ Ambulantní   │ │
│   │     │  │     │  │      │  │ systémy      │ │
│   └──┬──┘  └──┬──┘  └──┬───┘  └──────┬───────┘ │
│      │        │        │              │          │
│      ▼        ▼        ▼              ▼          │
│   ┌──────────────────────────────────────────┐   │
│   │        FHIR Adapter / Mapper Layer       │   │
│   │  (Transformace lokálních formátů → FHIR) │   │
│   └──────────────────┬───────────────────────┘   │
│                      │                            │
│                      ▼                            │
│   ┌──────────────────────────────────────────┐   │
│   │           FHIR R4 Server                 │   │
│   │  (HAPI FHIR / Microsoft FHIR Server)    │   │
│   └──────────────────┬───────────────────────┘   │
│                      │                            │
│         ┌────────────┼────────────┐               │
│         ▼            ▼            ▼               │
│   ┌──────────┐ ┌──────────┐ ┌──────────┐        │
│   │ AI moduly│ │ Pacient. │ │ Ext.     │        │
│   │ (LLM,   │ │ portál   │ │ systémy  │        │
│   │  RAG)   │ │          │ │ (EHDS)   │        │
│   └──────────┘ └──────────┘ └──────────┘        │
│                                                   │
└─────────────────────────────────────────────────┘

Klíčový princip: FHIR server funguje jako prostředník. Existující systémy se nemění — místo toho vytvoříte adapter vrstvu, která překládá jejich nativní formáty do FHIR Resources.

---

Krok za krokem: Implementace FHIR v praxi

Krok 1: Audit stávajících systémů

Než napíšete řádek kódu, potřebujete vědět, s čím pracujete.

Checklist pro audit:

• Jaký NIS nemocnice používá? (STAPRO UNIS, ICZ AMIS, CompuGroup CGM)
• Jaké API/exporty NIS nabízí? (HL7 v2, XML, CSV, proprietární?)
• Jak jsou strukturovaná data pacientů? (rodné číslo, pojišťovna, kontakt)
• Jaké kódové systémy se používají? (MKN-10, MKN-11, SÚKL kódy)
• Kde jsou laboratorní výsledky? (LIS typ, formát)
• Jaký je objem dat? (počet pacientů, návštěv/den)
• Jaké jsou bezpečnostní požadavky? (GDPR, síťová izolace)

Z mé zkušenosti: Tohle zabere 1–2 týdny. Nezkracujte to. Špatný audit = špatná architektura = drahý refactoring.

Krok 2: Výběr FHIR serveru

Pro české prostředí doporučuji dva přístupy:

Varianta A: HAPI FHIR (Open-source, Java)

# Docker deployment — nejrychlejší start
docker run -p 8080:8080 hapiproject/hapi:latest

Výhody:

• Zdarma, open-source
• Největší komunita
• Plná podpora FHIR R4
• Java ekosystém (běží na čemkoli)

Nevýhody:

• Java (pokud váš tým preferuje jiný stack)
• Self-hosted = vaše zodpovědnost za provoz

Varianta B: Azure FHIR Service (Managed, cloud)

# Azure CLI
az healthcareapis service create \
  --resource-group nemocnice-rg \
  --resource-name fhir-brno \
  --kind fhir-R4 \
  --location westeurope

Výhody:

• Managed — Azure se stará o provoz
• Compliance certifikace (HIPAA, GDPR)
• Škálovatelnost
• Integrace s Azure AI

Nevýhody:

• Cena (od ~200 EUR/měsíc)
• Data v cloudu (některé nemocnice vyžadují on-premise)

Moje doporučení: Pro pilotní projekt začněte s HAPI FHIR na Dockeru. Pokud nemocnice preferuje cloud a má Azure, přejděte na Azure FHIR Service. V Medevio používáme hybridní přístup.

Krok 3: Mapování dat — nejnáročnější část

Tady se odehrává 60 % celé práce. Musíte definovat, jak vaše stávající data odpovídají FHIR Resources.

Příklad: Mapování pacienta z NIS do FHIR

// src/mappers/patient-mapper.ts

interface NISPatient {
  rodne_cislo: string;
  jmeno: string;
  prijmeni: string;
  datum_narozeni: string;     // DD.MM.YYYY
  kod_pojistovny: string;     // 111, 201, 207...
  ulice: string;
  mesto: string;
  psc: string;
  telefon?: string;
  email?: string;
}

function mapToFHIRPatient(nis: NISPatient): fhir4.Patient {
  return {
    resourceType: "Patient",
    identifier: [
      {
        system: "https://www.uzis.cz/rid",
        value: nis.rodne_cislo,
        type: {
          coding: [{
            system: "http://terminology.hl7.org/CodeSystem/v2-0203",
            code: "NI",
            display: "National unique individual identifier"
          }]
        }
      }
    ],
    name: [{
      family: nis.prijmeni,
      given: [nis.jmeno],
      use: "official"
    }],
    birthDate: convertCzechDate(nis.datum_narozeni),
    gender: deriveGenderFromRC(nis.rodne_cislo),
    address: [{
      line: [nis.ulice],
      city: nis.mesto,
      postalCode: nis.psc,
      country: "CZ"
    }],
    telecom: [
      ...(nis.telefon ? [{
        system: "phone" as const,
        value: nis.telefon
      }] : []),
      ...(nis.email ? [{
        system: "email" as const,
        value: nis.email
      }] : [])
    ],
    // Česká pojišťovna jako "managing organization"
    managingOrganization: {
      reference: `Organization/pojistovna-${nis.kod_pojistovny}`,
      display: getInsuranceName(nis.kod_pojistovny)
    }
  };
}

// Helper: České datum DD.MM.YYYY → FHIR YYYY-MM-DD
function convertCzechDate(date: string): string {
  const [day, month, year] = date.split(".");
  return `${year}-${month.padStart(2, "0")}-${day.padStart(2, "0")}`;
}

// Helper: Pohlaví z rodného čísla (měsíc > 50 = žena)
function deriveGenderFromRC(rc: string): "male" | "female" {
  const month = parseInt(rc.substring(2, 4));
  return month > 50 ? "female" : "male";
}

Poznámka k rodným číslům: Rodné číslo je v FHIR mapováno jako identifier se systémem ÚZIS. Buďte opatrní — rodné číslo je citlivý osobní údaj a musíte s ním zacházet v souladu s GDPR. V produkci doporučuji pseudonymizaci tam, kde plný identifikátor není nutný.

Příklad: Mapování diagnózy (MKN-11)

// src/mappers/condition-mapper.ts

interface NISDiagnosis {
  kod_mkn: string;        // "I10" (MKN-10) nebo "BA00" (MKN-11)
  nazev: string;
  datum_stanoveni: string;
  typ: "hlavni" | "vedlejsi";
  lekar_icz: string;
}

function mapToFHIRCondition(
  diag: NISDiagnosis,
  patientRef: string,
  version: "mkn10" | "mkn11" = "mkn10"
): fhir4.Condition {
  const codeSystem = version === "mkn11"
    ? "https://icd.who.int/browse/2024-01/mms/cs"
    : "http://hl7.org/fhir/sid/icd-10";

  return {
    resourceType: "Condition",
    clinicalStatus: {
      coding: [{
        system: "http://terminology.hl7.org/CodeSystem/condition-clinical",
        code: "active"
      }]
    },
    category: [{
      coding: [{
        system: "http://terminology.hl7.org/CodeSystem/condition-category",
        code: diag.typ === "hlavni"
          ? "encounter-diagnosis"
          : "problem-list-item"
      }]
    }],
    code: {
      coding: [{
        system: codeSystem,
        code: diag.kod_mkn,
        display: diag.nazev
      }]
    },
    subject: { reference: patientRef },
    onsetDateTime: convertCzechDate(diag.datum_stanoveni),
    asserter: {
      reference: `Practitioner/icz-${diag.lekar_icz}`
    }
  };
}

Proč je mapování tak důležité: Špatně namapovaná data jsou horší než žádná data. Když AI systém přečte špatně strukturovanou diagnózu, může navrhnout špatnou léčbu. Ve zdravotnictví nejde o UX — jde o bezpečnost pacientů.

Krok 4: Adapter vrstva pro NIS

Protože nemůžete (a nechcete) měnit NIS, vytvoříte adapter, který pravidelně synchronizuje data:

// src/adapters/nis-sync.ts

import { FHIRClient } from "./fhir-client";
import { mapToFHIRPatient } from "../mappers/patient-mapper";
import { mapToFHIRCondition } from "../mappers/condition-mapper";

class NISSyncAdapter {
  private fhir: FHIRClient;
  private nisDb: NISDatabase;

  async syncPatients(since: Date): Promise<SyncResult> {
    // 1. Získat změněné pacienty z NIS
    const updatedPatients = await this.nisDb.query(
      `SELECT * FROM pacienti WHERE modified > $1`,
      [since]
    );

    let synced = 0;
    let errors = 0;

    for (const nisPatient of updatedPatients) {
      try {
        // 2. Namapovat na FHIR
        const fhirPatient = mapToFHIRPatient(nisPatient);

        // 3. Upsert do FHIR serveru
        await this.fhir.update("Patient", fhirPatient);

        // 4. Synchronizovat diagnózy
        const diagnoses = await this.nisDb.query(
          `SELECT * FROM diagnozy WHERE pacient_rc = $1`,
          [nisPatient.rodne_cislo]
        );

        for (const diag of diagnoses) {
          const fhirCondition = mapToFHIRCondition(
            diag,
            `Patient/${nisPatient.rodne_cislo}`
          );
          await this.fhir.update("Condition", fhirCondition);
        }

        synced++;
      } catch (error) {
        errors++;
        // Logování je kritické — ve zdravotnictví
        // musíte vědět, která data se nesynchronizovala
        logger.error("Sync failed", {
          patient: nisPatient.rodne_cislo,
          error: error.message
        });
      }
    }

    return { synced, errors, total: updatedPatients.length };
  }
}

Krok 5: Bezpečnost a GDPR

Tohle nemůžete přeskočit. Zdravotnická data patří do nejvyšší kategorie citlivosti.

Minimální bezpečnostní požadavky:

1. Autentizace: OAuth 2.0 / SMART on FHIR
2. Autorizace: Role-based access (lékař vs. sestra vs. admin)
3. Šifrování: TLS 1.3 pro přenos, AES-256 pro data at rest
4. Audit log: Kdo, kdy, co četl/měnil — povinné
5. Anonymizace: Pro výzkum a AI trénování
6. Data residency: Data musí zůstat v EU (ideálně v ČR)

// src/middleware/audit-log.ts

async function auditMiddleware(req: Request, res: Response, next: Next) {
  const auditEntry = {
    timestamp: new Date().toISOString(),
    user: req.auth.practitionerId,
    action: req.method,
    resource: req.path,
    ip: req.ip,
    userAgent: req.headers["user-agent"],
    // Pozor: nelogujte celá data pacienta!
    resourceId: extractResourceId(req.path)
  };

  await auditLog.write(auditEntry);
  next();
}

---

Česká specifika: Na co si dát pozor

MKN-10 → MKN-11 přechod

Česko je v přechodném období. Některé systémy stále používají MKN-10, jiné přecházejí na MKN-11. Váš FHIR systém musí umět obojí.

Přesně na tohle jsem vytvořil MKN11-coder — AI systém, který automaticky kóduje diagnózy z českého textu a navrhuje odpovídající MKN-11 kódy s validací. Přesnost aktuálně dosahuje 94 %.

SÚKL kódy pro léky

Česká databáze léků (68 000+ registrovaných přípravků) používá vlastní kódový systém SÚKL. V FHIR mapujete léky přes MedicationRequest s odkazem na SÚKL systém:

{
  "resourceType": "MedicationRequest",
  "medicationCodeableConcept": {
    "coding": [{
      "system": "https://www.sukl.cz/modules/medication",
      "code": "0001234",
      "display": "WARFARIN ORION 5MG TBL NOB 100"
    }]
  }
}

Pro AI asistenty jsem vytvořil SÚKL MCP Server, který umožňuje Claude nebo GPT přistupovat k celé databázi léků v reálném čase — vyhledávání, interakce, příbalové informace.

Pojišťovny

V Česku máme 7 zdravotních pojišťoven a každá má trochu jiné požadavky na vykazování. Ve FHIR se pojišťovna mapuje jako Organization:

{
  "resourceType": "Organization",
  "identifier": [{
    "system": "https://www.uzis.cz/pojistovny",
    "value": "111"
  }],
  "name": "Všeobecná zdravotní pojišťovna ČR",
  "type": [{
    "coding": [{
      "system": "http://terminology.hl7.org/CodeSystem/organization-type",
      "code": "ins",
      "display": "Insurance Company"
    }]
  }]
}

---

Proč FHIR + AI je game changer

Tady se to celé propojuje. FHIR není jen o výměně dat mezi systémy — je to základ pro AI ve zdravotnictví.

Bez strukturovaných dat je AI slepá. Můžete mít nejlepší LLM na světě, ale pokud nedokáže přečíst zdravotní záznamy pacienta, je k ničemu.

FHIR umožňuje AI systémům:

1. Číst strukturovaná data — diagnózy, léky, výsledky v jednotném formátu
2. Provádět dotazy — “Všichni pacienti s diabetem a Warfarinem” = jeden API call
3. Zapisovat výsledky — AI predikce zpět do FHIR jako Observation
4. Auditovat — každý přístup AI k datům je logovaný

V Medevio právě tohle děláme: AI moduly čtou zdravotnickou dokumentaci přes FHIR, automaticky extrahují diagnózy (MKN-11) a strukturují nestrukturovaná data. Výsledek: lékař ušetří desítky minut denně.

---

Časový plán a rozpočet

Realisticky — kolik to stojí a jak dlouho to trvá?

Fáze 1: Audit a návrh (2–3 týdny)

• Analýza stávajících systémů
• Výběr FHIR serveru
• Návrh architektury a mapování
• Rozpočet: 80 000 – 150 000 CZK

Fáze 2: MVP integrace (4–6 týdnů)

• Implementace adaptérů pro hlavní NIS
• Základní mapování (Patient, Condition, Medication)
• Bezpečnostní vrstva + audit log
• Rozpočet: 200 000 – 400 000 CZK

Fáze 3: Rozšíření a AI (4–8 týdnů)

• Integrace dalších systémů (LIS, PACS)
• AI moduly (automatické kódování, predikce)
• Pacientský portál
• Rozpočet: 300 000 – 600 000 CZK

Celkem: 2–4 měsíce, 580 000 – 1 150 000 CZK

Zní to jako hodně? Zvažte alternativu: jeden lékař, který denně stráví 30 minut hledáním informací v různých systémech. Za rok to je 125 hodin. Vynásobte počtem lékařů v nemocnici. Náklady na FHIR integraci se typicky vrátí do 12–18 měsíců.

---

EU kontext: EHDS a proč FHIR bude povinný

European Health Data Space (EHDS) je regulace EU, která bude vyžadovat, aby zdravotnická data byla sdílitelná napříč členskými státy. A hádejte, na jakém standardu EHDS staví?

Ano — FHIR.

Nemocnice, které FHIR adoptují teď, budou mít 2–3 roky náskok před těmi, které budou čekat. A z mé zkušenosti s Ask-EHDS chatbotem vím, že povědomí o EHDS v českém zdravotnictví je zatím minimální.

EU AI Act navíc klasifikuje zdravotnické AI systémy jako “high-risk” — což znamená povinnou dokumentaci, auditovatelnost a transparentnost. FHIR vám s tím pomůže, protože standardizovaná data = standardizované audity.

---

Shrnutí: 5 věcí, které si odneste

1. FHIR je standard, ne produkt. Je to společný jazyk pro zdravotnická data — a v Česku ho potřebujeme urgentně.
2. Začněte malým pilotem. Vyberte jednu integraci (např. NIS → AI modul), implementujte, změřte výsledky, škálujte.
3. Investujte do mapování. 60 % práce je v překladu lokálních dat (MKN-10/11, SÚKL kódy, rodná čísla) do FHIR. Neošiďte to.
4. Bezpečnost není volitelná. GDPR, audit logy, šifrování — ve zdravotnictví neexistuje “přidáme to potom.”
5. FHIR + AI = budoucnost. Bez strukturovaných dat nemůže AI ve zdravotnictví fungovat. FHIR je most mezi starými systémy a moderní AI.

---

Chcete se dozvědět víc?

Pokud zvažujete FHIR integraci ve vašem zdravotnickém zařízení, rád si o tom popovídám. Nabízím bezplatnou 30minutovou konzultaci, kde proberu vaše konkrétní potřeby a navrhnu postup.

Rezervovat konzultaci

Nebo se podívejte na moje open-source projekty, které s FHIR přímo souvisejí:

• SÚKL MCP Server — přístup AI k databázi 68 000+ léků
• MKN11-coder — automatické kódování diagnóz
• Ask-EHDS — chatbot pro EHDS regulace
• Czech MedAI — AI platforma pro české zdravotnictví

---

Máte otázky? Napište mi na LinkedIn nebo na petr.sovadina9@gmail.com — odpovím na každou zprávu.