Mobilní MIS pro zdravotnictví

01Kontext

Klient staví a provozuje manažerský informační systém, ve kterém žije ekonomické oddělení nemocnice: zdrojové systémy plnící datový sklad, ETL řetězec a nad tím desktopoví MIS a BI klienti. Čísla, která ředitel chce, už existují. Existují na desktopu uvnitř nemocniční sítě.

Vzdálenost mezi tím chtít výsledek za tenhle měsíc a mít ho je proto pracovní den a žádost na ekonomiku. Zkrátit ji je celý produkt. Systém, sklad i značka patří klientovi, takže případová studie zůstává u inženýrského problému a mého podílu na něm.

02Výzva

BI engine nemá žádné HTTP API, čte sklad přímo, takže tohle nikdy nebyla integrace. Potřebovalo to vlastní backend, který sedí vedle databáze a mluví SQL, a telefon, který se k databázi za žádných okolností nedostane.

Zbytek určuje prostředí. Nemocniční finance jsou obchodně i politicky citlivé i bez jediného záznamu o pacientovi: dodavatel pracující podle ISO 9001 a ISO/IEC 27001, vlastní bezpečnostní manažer, který si věc projde dřív, než cokoli vyjde, certifikovaný ISMS, do jehož rozsahu může aplikace spadnout, a stále žádná odpověď na to, jak se telefon dostane k datům v nemocniční síti. Ať dorazí jakákoli, architektura nesmí stát na odhadu.

A data se brání. První skutečný export ztrojnásobí součty, když se sečte přesně tak, jak radí průvodní poznámka: odvozené měnové čtení započítané dvakrát, součtový řádek převlečený za středisko a neuzavřený prosinec, který z chybějících nákladů udělá 26milionový zisk. Chytat přesně tuhle třídu chyb je smyslem celého dashboardu, takže udělat ji by bylo fatální.

03Co jsem postavil

Aplikaci v React Native (iOS, Android a webový build ze stejného zdroje) a TypeScriptový backend, v jednom monorepu rozděleném čarou, která má obchodní význam: znovupoužitelná platforma se nikdy nedozví jméno zákazníka a všechno, co platí jen pro tenhle produkt (mapování skladu, definice KPI, design systém), leží na druhé straně. Tu čáru hlídá test.

Každý tvar, který jde po drátě, je schéma, ze kterého si obě strany odvozují typy, a každé čtení jde přes jedno rozhraní datového zdroje, takže rozhodnutí o transportu mohlo zůstat otevřené, zatímco produkt vznikal. Dashboard říká, proti čemu se jeho čísla měří: kdy se naposledy obnovila zdrojová data, odděleně od toho, kdy se sestavila odpověď, a jestli 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 demo. Vývoj běží na syntetických datech a očekávaný tvar skladu je sepsaný jako návrh schématu, který klient opraví na místě; z žádosti, která zůstala dvakrát bez odpovědi, se tím stala otázka, která si odpovídá sama.

04Výsledek

Řetězec běží od začátku do konce nad skutečným ekonomickým exportem klienta (kostka skladu, doménová matematika, kontrakt, API, zařízení) s účetními pastmi popsanými a odfiltrovanými, ne tiše zprůměrovanými. Čtyři kompletní vizuální směry vznikly nad reálnými čísly, takže se volba designu dělá díváním, ne dohadováním.

V produkci to není a případová studie to říká: čeká to na odpověď klienta, jak se telefon dostane k datům uvnitř nemocnice, a na autentizované flow, které z ní vyplyne. Co existuje, jasně rozlišuje, které bezpečnostní kontroly jsou hotové a které zatím jen plánované, a to je část, kterou si bezpečnostní manažer nemocnice přečte první.