Manažerský informační systém pro vedení nemocnice
Výsledek měsíce na telefonu, nad MIS a BI systémem, který klient už provozuje. Jen pro čtení, jen souhrny, nikdy data pacientů.
- Klient
- Český dodavatel zdravotnického softwaru, po dohodě nejmenován
- Obor
- Zdravotnictví
- Typ
- Klientský projekt
- Stav
- V realizaci
- Role
- Návrh, UX/UI, vývoj, dlouhodobá údržba
- Rok
- 2026
- 1
Kontext
Klient staví a provozuje manažerský informační systém, ve kterém pracuje ekonomický úsek nemocnice: zdrojové systémy plní datový sklad, nad ním běží ETL a desktopoví klienti MIS a BI. Čísla, která ředitel chce, už existují. Existují na desktopu uvnitř nemocniční sítě.
- 2
Problém
Mezi tím, kdy chcete výsledek měsíce, a tím, kdy ho máte, leží pracovní den a žádost na ekonomický úsek. Zkrátit tuhle vzdálenost je celý produkt: manažerský pohled na finance organizace, přečtený za pár vteřin na telefonu.
- 3
Omezení
BI engine nemá HTTP API, čte sklad přímo. Nešlo tedy o integraci. Aplikace potřebovala vlastní backend, který sedí vedle databáze a mluví SQL, a telefon, který se k té databázi za žádných okolností nedostane.
Finance nemocnice jsou obchodně i politicky citlivé, i když v nich není jediný záznam o pacientovi. Dodavatel pracuje podle ISO 9001 a ISO/IEC 27001 a má vlastního bezpečnostního manažera, který všechno projde, než se to nasadí. Jak se telefon dostane k datům uvnitř nemocniční sítě, bylo stále otevřené, takže architektura nesměla stát na odhadu.
- 4
Role
Tolaron navrhuje a staví mobilní aplikaci a její backend a po vydání je udržuje. Systém, datový sklad i značka patří klientovi.
- 5
Řešení
Aplikace v React Native pro iOS a Android s webovým buildem ze stejného zdroje a backend v TypeScriptu, v jednom monorepu rozděleném podle linie, která má obchodní význam: znovupoužitelná platforma se nikdy nedozví jméno zákazníka a vše, co platí jen pro tento produkt, leží na druhé straně. Tu hranici hlídá test.
Každý tvar dat, který jde po drátě, je schéma, ze kterého obě strany odvozují typy, a každé čtení prochází jedním rozhraním zdroje dat, takže rozhodnutí o transportu mohlo zůstat otevřené, zatímco produkt vznikal. Dashboard říká, k čemu se jeho čísla vztahují: kdy byla zdrojová data naposledy obnovena, odděleně od toho, kdy vznikla odpověď, a zda je měsíc na obrazovce uzavřený, nebo se ještě hýbe.
Do repozitáře nikdy nevstoupila zákaznická data, ani anonymizovaná, ani jako ukázka. Vývoj běží na syntetických datech a očekávaný tvar skladu je zapsaný jako navržené schéma, které klient opravuje přímo v něm.
- 6
Výsledek
Řetězec běží od začátku do konce nad skutečným finančním exportem klienta: kostka skladu, doménová matematika, kontrakt, API, zařízení. Účetní pasti v datech, dvakrát započtený kurzový přepočet, mezisoučet převlečený za nákladové středisko, neuzavřený měsíc, jsou zdokumentované a odfiltrované, ne tiše zprůměrované. Nad skutečnými čísly vznikly čtyři vizuální směry, aby se o designu rozhodovalo pohledem.
Zatím není v produkci. Čeká na odpověď klienta, jak se telefon dostane k datům uvnitř nemocniční sítě, a na autentizovaný tok, který z ní plyne. To, co existuje, jasně odděluje hotová bezpečnostní opatření od těch teprve plánovaných; to je část, kterou bezpečnostní manažer čte jako první.
- 7
Technologie
React Native a TypeScript na telefonu i ve webovém buildu. Backend v TypeScriptu nad skladem přes SQL. Sdílená schémata pro každý tvar dat. Syntetická data pro vývoj.
Klient není jmenován a obrazovky se neukazují, po dohodě obou stran. Vše výše je inženýrský problém a podíl Tolaronu na něm.
