V automatizovaném zdravotnickém centru se využívá řada různých přístrojů, jejichž činnost by měla být řízena zdravotnickým informačním systémem (MIS), a také zařízení, která neprovádějí příkazy, ale měla by posílat výsledky své činnosti do MIS. Všechna zařízení však mají různé možnosti připojení (USB, RS-232, Ethernet atd.) a způsoby interakce. Podporovat je všechny v MIS je prakticky nemožné, proto byla vyvinuta softwarová vrstva DeviceManager (DM), která poskytuje pro MIS jednotné rozhraní pro zadávání úkolů přístrojům a získávání výsledků.
Pro zvýšení odolnosti systému DM byl rozdělen na sadu programů umístěných na počítačích v zdravotnickém centru. DM se dělí na hlavní program a sadu pluginů, které zajišťují interakci s konkrétním zařízením a posílají data do MIS. Na obrázku níže je zobrazena obecná struktura interakce s DeviceManagerem, MIS a přístroji.
Ve struktuře interakce mezi MIS a DeviceManagerem jsou znázorněny 3 varianty práce pluginů:
- Plugin neobdrží žádná data od MIS a posílá převedená na pro něj srozumitelný formát data od přístroje (odpovídá zařízení typu 3 na obrázku výše).
- Plugin obdrží od MIS krátký (časově výkonný) úkol, například tisk na tiskárně nebo skenování obrázku, splní ho a pošle výsledek jako odpověď na dotaz (odpovídá zařízení typu 1 na obrázku výše).
- Plugin obdrží od MIS dlouhodobý úkol, například provést vyšetření nebo změřit hodnoty, v odpovědi posílá stav příjmu úkolu (při chybě v požadavku může být zamítnuto zadání úkolu). Po splnění úkolu jsou výsledky převedeny do pro MIS srozumitelného formátu a nahrány do odpovídajících rozhraní podle jejich typu (odpovídá zařízení typu 2 na obrázku výše).
Hlavní program DM spouští, inicializuje, znovu spouští v případě neočekávaného zastavení (selhání) a ukončuje při skončení činnosti všechny pluginy. Soubor pluginů na každém počítači je individuální, spouští se pouze ty nezbytné, které jsou uvedeny v nastavení.
Každý plugin je samostatný program, který interaguje s hlavním programem. Taková definice pluginu umožňuje zajistit stabilnější provoz díky nezávislosti všech instancí pluginů a hlavního programu na odpracování chyb (pokud dojde k kritické chybě, která způsobí pád pluginu, ostatní pluginy a hlavní program tím nebudou ovlivněny). Jeden plugin umožňuje práci s zařízeními jednoho typu (často jedné modelové řady), přičemž některé pluginy mohou interagovat pouze s jedním zařízením, zatímco jiné s několika. Pro připojení několika zařízení jednoho typu k jednomu DM se používá spuštění několika instancí jednoho pluginu.
Pro vývoj DM byl použit nástroj Qt, protože umožňuje v mnoha případech abstrahovat od konkrétní operační soustavy. To umožnilo podporovat práci s počítači na bázi Windows, Linux a MacOS, stejně jako jednodeskovými počítači Raspberry. Jediným omezením při výběru operační soustavy pro vývoj pluginů je dostupnost ovladačů a/nebo speciálního softwaru pro konkrétní zařízení.
Interakce mezi pluginy a hlavním programem probíhá prostřednictvím neustále aktivního QLocalSocket s názvem konkrétní instance pluginu, podle vytvoreného protokolu. Realizace protokolu spojení z obou stran byla vytvořena jako dynamická knihovna, což umožnilo vést vývoj některých pluginů jinými společnostmi, aniž by se plně odhalilo, jak interakce s hlavním programem probíhá. Vnitřní logika práce s lokálním socketem umožňuje hlavnímu programu okamžitě zjistit o pádu pomocí signálu o přerušení spojení. Při aktivaci takového signálu dojde k restartu problematického pluginu, což umožňuje lépe zvládat kritické situace.
Interakce mezi MIS a DM byla postavena na základě HTTP protokolu, protože MIS funguje na bázi webového serveru, na kterém je snazší odesílat a přijímat požadavky podle tohoto protokolu. Také je možné rozlišit problémy, které mohly nastat při zadávání nebo vykonávání úloh zařízeními, na základě kódů odpovědí.
V následujících článcích na příkladu několika kanceláří diagnostického centra bude popsána práce DM a některých pluginů.
Zdroj: habr.com
