ProjektyPřípadová studie 01

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. 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. 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. 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. 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. 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. 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. 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.