FHIR prakticky: Jak s ním začít, když vyvíjíte software pro české zdravotnictví

FHIR už není jen „něco, co se možná jednou bude hodit“. Pro české dodavatele zdravotnického softwaru se z něj stává praktický integrační jazyk nové generace elektronického zdravotnictví. eŽádanky, sdílený zdravotní záznam, služby NPEZ, EZKarta, výměna zdravotnické dokumentace i budoucí evropský prostor zdravotních dat budou stále častěji stát na stejném principu: Strukturovaná zdravotnická data, jasné profily, interoperabilní API a validace podle implementačních příruček.

Pro vývojáře je FHIR lákavý. Otevřete dokumentaci, spustíte server v Dockeru, pošlete první Patient nebo Observationa za hodinu máte pocit, že „to není tak těžké“. To je dobrý začátek. Ale jen začátek. Prototyp může vzniknout za hodinu, zatímco vyvinout bezpečné produkční řešení s reálnými klinickými daty, provozní odpovědností, synchronizací, auditem, validací, správou identit a datovou governance může trvat měsíce až roky.

Tento článek je praktický návod pro menší dodavatele NIS, AIS, laboratorních, radiologických, objednávkových, dokumentačních nebo pacientských systémů. Cílem není stát se za týden FHIR architektem. Cílem je vědět, kde začít, co si osahat, jak číst české Implementation Guides a jak se vyhnout rozhodnutím, která budou za rok bolet.

Proč řešit FHIR právě teď

FHIR je standard HL7 pro výměnu zdravotnických dat. V R4 specifikaci ho HL7 popisuje jako standard pro výměnu zdravotnických dat a dokumentace obsahuje základní stavební bloky jako Patient, Practitioner, Organization, ServiceRequest, Observation, DiagnosticReport, DocumentReference, REST API, vyhledávání, profily, terminologie a implementační příručky.

V českém kontextu je důležitější něco jiného. FHIR se posouvá z oblasti „mezinárodní standard, který někdo možná použije“ do oblasti národních eHealth služeb. Nové služby elektronického zdravotnictví mají podporovat rozhraní HL7 FHIR, národní standard má být odvozen od evropského a Ministerstvo zdravotnictví ČR má podporovat postupný přechod datové komunikace na HL7 FHIR.

Od ledna 2026 Ministerstvo zdravotnictví spouští první verze klíčových projektů elektronizace zdravotnictví včetně Národního portálu elektronického zdravotnictví, elektronických žádanek, elektronických posudků a nových funkcí EZKarty. Poskytovatelé zdravotních služeb budou využívat své stávající ambulantní softwary, jejichž dodavatelé se budou postupně napojovat na rozhraní elektronických žádanek a elektronických posudků.

eŽádanka je přitom dobrý příklad toho, co se bude opakovat i u dalších služeb. Je to bezpečná, elektronická a standardizová správa žádostí o zdravotní služby, dostupná poskytovatelům prostřednictvím API integrovaného do NIS/AIS nebo přes Národní portál elektronického zdravotnictví. Technická část uvádí REST, TLS 1.2+, JSON, OpenID Connect a OAuth 2.0. Pro dodavatele zdravotnického softwaru už FHIR není „výzkumné téma“. Je to schopnost, kterou bude trh očekávat.

Co je FHIR v praxi

Nejjednodušší vysvětlení pro produktový tým zní. FHIR je společný jazyk pro zdravotnická data a API.

Neříká jen „pošlete JSON“. Říká, jak má vypadat pacient, organizace, zdravotnický pracovník, žádanka, výsledek, nález, dokument, diagnóza nebo pozorování. Zároveň definuje RESTful API. Jak zdroj vytvořit, přečíst, aktualizovat, vyhledat, validovat nebo poslat v transakčním balíčku. FHIR REST API pracuje se standardními interakcemi jako read, create, update, search, capabilities, batch a transaction. Server má zároveň poskytovat CapabilityStatement, který říká, jaké zdroje a operace podporuje.

Pro vývojáře je zásadní pochopit čtyři pojmy.

Resource je základní datový objekt. Například Patient, Practitioner, Organization, ServiceRequest, Observation, DiagnosticReport.

Profile je zpřesnění resource pro konkrétní použití. Říká například: „v české obrazové žádance použij tento resource takto, tento údaj je povinný, tento číselník je závazný“.

Implementation Guide, zkráceně IG, je sada pravidel, profilů, číselníků, příkladů, mapování a textových instrukcí pro konkrétní doménu nebo zemi.

Terminologie říká, jaké kódy a číselníky se mají používat. Bez terminologií se ze strukturovaného standardu rychle stane jen jiný JSON.

Člověk, který s FHIR opravdu začíná se musí naučit číst IG, vybrat správný resource a profil pro use-case, rozumět REST API, CapabilityStatement, Bundle, vyhledávacím parametrům, terminologiím, validaci a OperationOutcome.

FHIR server není celá platforma

Tady přichází první důležitá brzda nadšení. FHIR server není nemocniční systém, není integrační platforma, není datový sklad a není náhrada za governance zdravotnických dat.

FHIR server přijme požadavek, validuje ho, provede ho a vrátí odpověď. Neřeší za vás business validaci, MPI/EMPI, zlatý záznam pacienta, master data management, datovou governance, komplexní audit, jemnozrnná oprávnění ani analytické dotazy.

To je pro produktové řízení zásadní. Když si tým řekne „koupíme FHIR server a tím máme hotovo“, pravděpodobně podcení většinu práce. V produkci budete stále potřebovat identitu, autorizaci, správu souhlasů, audit, monitoring, retry mechanismy, mapování dat, řešení chyb, validaci nad českými IG, práci s číselníky, provozní SLA a jasnou odpovědnost za zdroj pravdy.

Pro menšího dodavatele z toho plyne jednoduché pravidlo. FHIR server berte jako nástroj, ne jako strategii.

Jak začít: praktický plán pro první 2–4 týdny

Nezačínejte výběrem vendorů. Nezačínejte velkou architekturou. Nezačínejte tím, že si do backlogu dáte „implementovat FHIR“. Začněte malým, konkrétním use-casem.

1. Vyberte jeden reálný scénář

Dobrý první scénář není „podporovat FHIR“. Dobrý první scénář zní například:

„Chceme z našeho AIS vytvořit elektronickou žádanku na obrazové vyšetření.“

Nebo:

„Chceme umět vystavit a přečíst základní pacientská data podle českého core profilu.“

Nebo:

„Chceme připravit export laboratorního výsledku jako FHIR DiagnosticReport a související Observation.“

Nebo:

„Chceme z našeho systému poskytovat vybraná data pro sdílený zdravotní záznam“

Produktový tým musí u každého scénáře odpovědět. Kdo data vytváří, kdo je čte, kdo je zdroj pravdy, jde o read-only nebo read/write scénář, jaké národní nebo evropské IG se použije, jaké identifikátory a číselníky jsou potřeba a jaký je očekávaný provoz.

2. Spusťte lokální FHIR server

Pro učení a první prototyp stačí HAPI FHIR. HAPI FHIR JPA Server Starter je kompletní startovací projekt pro nasazení FHIR serveru nad HAPI FHIR JPA. Jednoduché spuštění přes Docker:

docker pull hapiproject/hapi:latestdocker run -p 8080:8080 hapiproject/hapi:latest

Po spuštění je FHIR base URL typicky:

http://localhost:8080/fhir/

A CapabilityStatement najdete na:

http://localhost:8080/fhir/metadata

Starter nemá out-of-the-box produkční bezpečnost, enterprise logging a některé distribuované provozní komponenty. Pro lokální učení je skvělý, pro produkci ne hotové řešení.

3. Vezměte Postman, Insomnia nebo obyčejný curl

První den není potřeba SDK. Potřebujete pochopit API. Začněte třeba takto:

curl http://localhost:8080/fhir/metadata

Pak vytvořte jednoduchý Patient:

curl -X POST http://localhost:8080/fhir/Patient \  -H "Content-Type: application/fhir+json" \  -d '{    "resourceType": "Patient",    "identifier": [      {        "system": "https://example.cz/ids/patient",        "value": "12345"      }    ],    "name": [      {        "family": "Novák",        "given": ["Jan"]      }    ],    "gender": "male",    "birthDate": "1980-01-01"  }'

Pak zkuste vyhledávání:

curl "http://localhost:8080/fhir/Patient?identifier=https://example.cz/ids/patient|12345"

A potom přidejte Organization, Practitioner, Encounter, ServiceRequest, Observation a DiagnosticReport. Nesnažte se hned pokrýt všechno. Smyslem je pochopit vztahy mezi resources.

4. Naučte se číst odpověď typu Bundle

FHIR search typicky nevrací jeden objekt, ale Bundle. To je pro nové týmy častý zdroj zmatku. Vyhledávání pacienta, žádanek nebo výsledků vrací seznam záznamů, metadata, odkazy na další stránky a informace o výsledku. Produktový tým musí vědět, že „najít pacienta“ není totéž jako „načíst konkrétního pacienta podle ID“.

5. Nainstalujte SDK až po pochopení REST API

Jakmile víte, co dělají GET, POST, PUT, search parametry, Bundle a OperationOutcome, přidejte SDK. Pro .NET je přirozenou volbou Firely .NET SDK, které poskytuje modelové třídy pro FHIR data, REST klienta, XML/JSON parsery, práci se StructureDefinition, terminologickou podporu a validaci instancí proti profilům. Je nutné vybrat SDK podle verze FHIR, což často určuje lokální regulace nebo národní IG.

Pro Java svět je přirozená volba HAPI FHIR knihovna. Je to vlastně implementace HL7 FHIR specifikace pro Java prostředí a pokrývá práci s resources, serializaci, reference, profily, extensions, validaci a klientský přístup.

6. Přidejte syntetická data

Prázdný FHIR server je špatný učitel. Potřebujete data. Synthea je open-source simulátor syntetických pacientů, který generuje realistická, ale ne reálná data a umí exportovat mimo jiné do HL7 FHIR R4.

Pro první týmový workshop stačí vygenerovat desítky nebo stovky pacientů, nahrát je do serveru a zkoušet dotazy:

GET /Patient?family=NovakGET /Observation?subject=Patient/123GET /DiagnosticReport?subject=Patient/123GET /ServiceRequest?subject=Patient/123&status=active

U českých implementací ale pozor. Synthea typicky negeneruje české identifikátory (například RID/DRID ap), české adresní vazby, české role, lokální číselníky ani profily podle CZ Core. Je výborná pro učení FHIR API, ne jako náhrada českého testovacího datasetu.

Jak pracovat s českými Implementation Guides

Tady se odděluje „umíme poslat FHIR JSON“ od „umíme implementovat českou interoperabilitu“.

Na https://www.hl7.cz najdete české IG. Základ tvoří Czech National FHIR R4 Core and Base Implementation Guide STU 1, tedy národní core a base profily nad FHIR R4. Současně existují průběžné buildy, například HL7 Czech Base and Core FHIR IG v0.4.0. U těch je výslovně uvedeno, že nejde o autorizovanou publikaci, ale o continuous build, který se pravidelně mění.

Pro dodavatele to znamená pět praktických pravidel.

Vždy rozlišujte release a CI build. CI build je skvělý pro sledování vývoje, ale do produkčního kontraktu, testovací dokumentace nebo release notes patří konkrétní publikovaná verze.

Začněte od českého core. Core profily řeší společné věci jako pacient, adresa, organizace, zdravotnický pracovník, pokrytí, identifikátory a česká lokalizace. Doménové IG typicky staví nad core.

Čtěte IG jako produktovou specifikaci, ne jen jako technickou dokumentaci. V dobrém IG jsou use-cases, workflow, logický model, mapování na profily, příklady, terminologie, povinnosti a poznámky k implementaci.

Validujte už v CI pipeline. Každý FHIR JSON, který váš systém generuje, by měl projít validací proti správnému profilu. Minimálně u klíčových scénářů by měla validace běžet jako automatický test.

Neignorujte dependencies. České IG budou často záviset na HL7 Terminology, FHIR Extensions Pack, IPS, HL7 Europe Base/Core nebo dalších balíčcích. Například český IG pro sdílený zdravotní záznam uvádí závislosti na FHIR R4, IPS (mezinárodní "pacientský sohrn"), HL7 Czech Base/Core, HL7 Europe Base/Core a dalších balíčcích.

Evropská vrstva je důležitá i strategicky. HL7 Europe Base and Core IG je publikovaný pro evropský kontext, má sloužit jako základ pro národní projekty a EHDS-aligned projekty a pracuje s vrstvením Base a Core profilů. Pro české dodavatele to znamená, že FHIR se nebude vyvíjet jen národně izolovaně, ale bude se postupně zarovnávat s evropskou interoperabilitou.

Český příklad: Obrazová eŽádanka ("Zetko")

Český HL7 Czech Imaging Order FHIR IG je velmi dobrý materiál pro praktické studium. Je založen na FHIR R4 a specifikuje pravidla, jak reprezentovat obrazovou žádanku v českém národním kontextu. Jeho cílem je definovat obsahové komponenty a preferovanou strukturu pro konstrukci obrazové žádanky jako lékařského záznamu pacienta pro elektronickou výměnu zdravotních informací mezi pacientem, poskytovateli a infrastrukturou v ČR.

To je přesně typ IG, nad kterým by měl menší dodavatel postavit svůj první FHIR spike:

1. Najít hlavní resource pro scénář, typicky ServiceRequest.

2. Podívat se na profil, povinné položky, vazby na Patient, Practitioner, Organization, Coverage, Encounter.

3. Projít příklady v IG.

4. Vytvořit vlastní minimální validní instanci.

5. Přidat meta.profile.

6. Validovat proti IG.

7. Zmapovat interní datový model AIS/NIS na požadované FHIR elementy.

8. Udělat seznam chybějících údajů ve vašem produktu.
   

Ten poslední bod je často nejdůležitější. FHIR implementace často neztroskotá na JSONu. Ztroskotá na tom, že produkt dnes vůbec neukládá údaj, který národní služba očekává, ukládá ho volným textem, nemá správný číselník, neumí identifikovat pracoviště, neumí roli zdravotnického pracovníka nebo neumí dohledat vazbu mezi žádankou a epizodou péče.

Architektonická otázka: façade, hybrid, nebo FHIR-native?

Známe tři základní modely: façade, hybrid a FHIR-native. Žádný není univerzálně nejlepší. Liší se hlavně tím, kde leží zdroj pravdy a kdo vlastní data.

Façade znamená, že nad existujícím systémem postavíte FHIR API, které data za běhu čte z vaší databáze nebo služeb a převádí je do FHIR. Je to rychlé pro úzký read-only scénář, ale špatně se škáluje pro složité dotazy, více zdrojů dat a vysoký provoz. Façade je často dobrý mezikrok, ale zřídka dobrý dlouhodobý model, pokud se rozsah FHIRu rozšiřuje.

Hybrid znamená, že existující systém zůstává zdrojem pravdy a data se synchronizují do FHIR serveru, ze kterého je čtou klienti. To je velmi praktické pro dodavatele se zavedeným NIS/AIS, nemusíte totiž přepsat celý produkt, ale dokážete vystavit výkonné FHIR API. Rizikem je synchronizace, datový drift, zpoždění, chybové stavy a nutnost mít korekční rozhraní.

FHIR-native znamená, že FHIR server je zdrojem pravdy pro některá nebo všechna data. To dává smysl u nových modulů nebo doménových systémů, které samy vytvářejí transakční data. Například nový objednávkový, triážní, screeningový nebo dokumentační modul může některá data ukládat přímo jako FHIR resources. Ale pozor. Jakmile FHIR server začne být zdrojem pravdy, berete na sebe datovou governance, správu identit, korekce, audit, validace, životní cyklus záznamu a často i master data management.

Pro menšího dodavatele bychom doporučili tuto pracovní heuristiku.

Máte zavedený produkt, existující databázi a potřebujete „jen“ vystavit nebo přijmout data pro národní službu? Začněte façade nebo hybridem.

Máte existující systém jako zdroj pravdy a chcete výkonné čtení přes FHIR pro více scénářů? Směřujte k hybridu.

Stavíte nový modul, který vytváří vlastní klinická nebo procesní data, ale pacienty a poskytovatele přebírá odjinud? Zvažte omezený FHIR-native model pro transakční data, nikoli pro všechno.

Chcete přepsat celý produkt na FHIR-native, protože to vypadá čistě? Zastavte se a nejdřív napište rozhodnutí o zdroji pravdy pro každý resource: Patient, Practitioner, Organization, Encounter, ServiceRequest, Observation, DiagnosticReport, DocumentReference.

Produktový backlog: co musí být v prvních epicech

První FHIR backlog by neměl začínat položkou „Implementovat FHIR“. To je moc široké. Použijte konkrétnější epicy.

FHIR základy a vývojové prostředí: lokální HAPI server, Postman kolekce, první resources, první search dotazy, první validace.

Use-case a rozsah: konkrétní scénář, role systému, čtení/zápis, národní služba, verze IG, seznam profilů.

Mapování dat: interní datový model na FHIR resources, chybějící položky v produktu, identifikátory, reference mezi resources.

Terminologie: používané číselníky, povinné value sety, lokální kódy, mapování kódů, fallback pro neznámé hodnoty.

Validace: base FHIR validace, profilová validace, český IG, testovací příklady, OperationOutcome, chybové hlášky pro uživatele i support.

Bezpečnost: autentizace, autorizace, OAuth2/OpenID Connect, klientské certifikáty podle cílové služby, auditní log, provozní logy, správa oprávnění.

Provoz: retry, idempotence, monitoring, alerting, korekční obrazovky, dohledatelnost, export podkladů pro podporu.

Verzování IG: sledování release českých IG, rozdílová analýza verzí, kompatibilita, testy proti nové verzi.

Pilot: jeden zákazník, jeden scénář, realistická data, testovací prostředí národní služby, měřené SLA.

Praktický plán 30–60–90 dnů

Prvních 30 dnů: naučit se jazyk

Do konce prvního měsíce by tým měl umět spustit lokální FHIR server, vytvořit a vyhledat základní resources, přečíst CapabilityStatement, pochopit Bundle, pracovat s OperationOutcome, přidat meta.profile a ručně projít jedno české IG.

Vývojářský výstup: běžící lokální server, Postman kolekce, sada ukázkových resources, první validace.

Produktový výstup: jeden konkrétní use-case, popsaný tok, role systému, zdroj pravdy, seznam potřebných FHIR resources a profilů.

60 dnů: napojit to na vlastní produkt

Druhý měsíc už nejde o sandbox. Vyberte jeden interní datový tok a zmapujte ho. Například žádanka v AIS - FHIR ServiceRequest. Nebo výsledek v LIS - DiagnosticReport a Observation. Nebo pacientská dokumentace - Composition a DocumentReference.

Vývojářský výstup: transformační vrstva, automatická validace, testovací dataset, první chybové scénáře.

Produktový výstup: gap analýza produktu, dopad do formulářů, chybějící číselníky, změny v UI, změny v datech, dopad na zákazníka.

90 dnů: rozhodnout architekturu

Třetí měsíc už by měl tým vědět, jestli první produkční scénář bude façade, hybrid, nebo omezený FHIR-native modul. Tady má smysl začít řešit vendor/server rozhodnutí, ale až po praktickém testu. Špatné rozhodnutí o serveru se často dělá příliš brzy, kdy tým nejméně rozumí FHIRu i skutečným požadavkům.

Výstup: architektonické rozhodnutí, POC s reálnějšími daty, měření výkonu, návrh provozu, bezpečnosti a supportu.

Co když nechci FHIR vyvíjet celý sám: role middleware

Ne každý dodavatel zdravotnického softwaru musí hned budovat vlastní plnohodnotnou FHIR platformu. V řadě případů dává smysl použít integrační middleware, který převezme část technické složitosti: transformaci dat z interního modelu do FHIR, správu rozhraní, validaci, logování, retry mechanismy, směrování zpráv, práci s profily, případně i napojení na národní nebo regionální služby. Middleware může být velmi praktický zejména tehdy, když má dodavatel stabilní existující produkt, nechce zásadně měnit jeho interní datový model a potřebuje relativně rychle splnit nové integrační požadavky. Typicky může jít o ambulantní systém, laboratorní systém, radiologický systém nebo menší nemocniční modul, který má dobrá data, ale není připraven stát se plně FHIR-native řešením. Je však důležité nemít iluzi, že middleware odstraní potřebu analytiky. I při použití hotové integrační vrstvy musíte vědět, jaká data máte, kdo je jejich zdrojem pravdy, jaké profily a číselníky se použijí, jak se budou řešit chyby a jaké dopady bude mít integrace do workflow uživatele. Middleware může výrazně zrychlit technickou implementaci, ale nenahradí produktové, datové a procesní rozhodnutí. Dobře zvolený middleware tedy není zkratka kolem interoperability. Je to způsob, jak ji zavést rychleji, bezpečněji a s menším zásahem do existujícího systému. Špatně zvolený middleware se naopak může stát jen další černou skříňkou mezi produktem a národní službou. Proto je vhodné ho hodnotit podle podpory českých IG, možností validace, auditovatelnosti, provozní robustnosti, schopnosti pracovat s verzemi profilů a otevřenosti vůči budoucím změnám.

Co má umět produkťák

Produkťák nemusí psát FHIR JSON. Ale musí se ptát správně.

Když přijde požadavek „podporujte eŽádanky“, dobré produktové otázky jsou:

Jakou roli má náš systém? Žadatel, příjemce, pacientský pohled, nebo integrační mezivrstva?

Jde o vytvoření, změnu, storno, přijetí, vyřízení, vyhledání nebo jen zobrazení žádanky?

Jaké typy žádanek podporujeme v první verzi?

Které údaje dnes v produktu máme strukturovaně a které jen textově?

Jaké identifikátory používáme pro pacienta, poskytovatele, pracoviště a zdravotnického pracovníka?

Jaký český IG a jaká verze platí pro tento scénář?

Jak budeme validovat data před odesláním?

Jak zobrazíme uživateli chybu z API?

Jak budeme řešit opakované odeslání po výpadku?

Co se stane, když národní služba žádanku přijme, ale náš systém spadne před uložením odpovědi?

Kdo u zákazníka řeší supportní incident, když se žádanka ztratila, zdvojila nebo zůstala v nesprávném stavu?

Tohle jsou produktové otázky, ne jen technické. A čím dřív zazní, tím levnější bude implementace.

Co má umět vývojář

Přečíst FHIR resource v JSONu a poznat základní elementy: resourceType, id, meta, identifier, status, code, subject, performer, requester, authoredOn, contained, extension.

Rozumět rozdílu mezi id a business identifikátorem v identifier.

Rozumět referencím, například subject: { "reference": "Patient/123" }.

Umět napsat jednoduchý search dotaz.

Umět přečíst OperationOutcome.

Umět přidat meta.profile.

Umět validovat resource proti profilu.

Umět pracovat s terminologií v CodeableConcept: system, code, display, text.

Umět rozlišit, kdy použít ServiceRequest, Task, DiagnosticReport, Observation, DocumentReference nebo Composition.

Umět najít v IG konkrétní profil, příklad a value set.

Jde tedy o práci s IG, API behavior, resource modelem, implementací, troubleshootingem a validací.

Nejčastější chyby malých týmů

První chyba je, že tým implementuje jen JSON, ne interoperabilitu. Výsledkem je FHIR-looking payload, který neprojde profilem, používá špatné kódy a neodpovídá workflow.

Druhá chyba je, že tým neřeší zdroj pravdy. U pacienta, žádanky, dokumentu i výsledku musí být jasné, který systém je autoritativní. Bez toho vzniká datový drift a konflikty.

Třetí chyba je, že tým validuje až na konci. Validace musí běžet od prvního prototypu, jinak se chyby v modelu stanou součástí architektury.

Čtvrtá chyba je, že produkt nepočítá se změnou workflow. FHIR integrace často znamená nové stavy, nové chybové situace, nové notifikace a nové odpovědnosti uživatele.

Pátá chyba je, že tým očekává, že FHIR server vyřeší governance. Nevyřeší. FHIR server je důležitá komponenta, ale odpovědnost za data zůstává na architektuře a procesech.

A nakonec šestá chyba je, že tým si vybere server podle značky nebo cloudové politiky, ne podle požadavků. Lepší je dělat POC s realistickými daty a ignorovat marketingové performance claims bez vlastního ověření.

Doporučený minimální FHIR stack pro menšího dodavatele

Pro první fázi nepotřebujete enterprise platformu za miliony. Potřebujete dobře uchopený vývojový a validační stack.

Lokální HAPI FHIR server pro vývoj a experimenty.

Postman nebo Insomnia kolekce pro ruční testování.

SDK podle vašeho jazyka: HAPI FHIR pro Java, Firely .NET SDK pro .NET.

Synthea pro rychlá syntetická data, doplněná vlastními českými testovacími příklady.

FHIR validator nebo validační schopnosti serveru/SDK.

Interní repozitář FHIR příkladů: validní, nevalidní, hraniční, chybové.

CI job, který validuje FHIR resources proti vybraným profilům.

Malý interní katalog mapování: interní pole - FHIR resource/element - profil - číselník - poznámka.

Sledování verzí českých IG a release notes.

Jeden člověk v týmu, který má vlastnictví nad FHIR profily a terminologiemi. Ne jako bokovku, ale jako reálnou odpovědnost.

Nezačínejte velkým přepisem, začněte schopností

FHIR nebude pro české dodavatele jeden projekt. Bude to schopnost, která se bude opakovat napříč moduly: eŽádanky, sdílený zdravotní záznam, klinické EHR, výsledky, žádosti, notifikace, pacientské aplikace, napojení na NPEZ, EZKartu i evropské scénáře.

Nejlepší první krok není koupit server. Nejlepší první krok je vzít jeden konkrétní scénář, spustit lokální FHIR server, poslat několik resources, najít správný český IG, validovat proti němu, zmapovat vlastní data a popsat, kde je zdroj pravdy.

Za měsíc budete vědět víc než po týdnu prezentací. Za tři měsíce budete vědět, jaká architektura dává smysl. A až přijde požadavek od zákazníka nebo národní služby, nebudete začínat od nuly. Budete mít jazyk, nástroje, testy a tým, který ví, že FHIR není jen formát. Je to způsob, jak se bude zdravotnický software v Česku postupně propojovat.

Kde s tím může pomoci Umbrellateam

Implementace FHIR není jen vývoj API. Je to kombinace produktové analytiky, znalosti zdravotnických procesů, datového modelování, architektury, legislativního kontextu, implementačních příruček a praktického vývoje. Právě v této kombinaci může být užitečná externí expertní podpora.

V Umbrellateam pomáháme dodavatelům zdravotnického softwaru i poskytovatelům zdravotních služeb uchopit FHIR prakticky. Od prvotní analýzy use-casů a dopadů do produktu, přes návrh architektury a mapování dat na české a evropské IG, až po podporu vývoje, validace, testování a přípravy na napojení do služeb elektronického zdravotnictví.

Typicky umíme pomoci s tím, kde začít, jaký scénář zvolit jako první, zda dává smysl façade, hybridní model, FHIR-native přístup nebo middleware, jak číst české implementační příručky, jak připravit backlog pro vývojový tým a jak přeložit požadavky národního eHealth do konkrétních úprav produktu.

Naším cílem není dodat další obecnou prezentaci o interoperabilitě. Smyslem je pomoci týmům udělat první správná rozhodnutí, vytvořit realistický plán a postupně vybudovat schopnost, která bude pro český zdravotnický software v dalších letech zásadní.