Enhetshanteraren. Utöka MIS till enheter

En automatiserad vårdcentral använder många olika enheter, vars funktion måste styras av ett medicinskt informationssystem (MIS), samt enheter som inte accepterar kommandon, utan måste överföra resultatet av sitt arbete till MIS. Alla enheter har dock olika anslutningsalternativ (USB, RS-232, Ethernet, etc.) och sätt att interagera med dem. Det är nästan omöjligt att stödja dem alla i MIS, så mjukvaruskiktet DeviceManager (DM) utvecklades, som tillhandahåller ett enda gränssnitt för MIS för att tilldela uppgifter till enheter och få resultat.


För att öka systemets feltolerans delades DM upp i en uppsättning program placerade på datorer i vårdcentralen. DM är uppdelat i ett huvudprogram och en uppsättning plugins som interagerar med en specifik enhet och skickar data till MIS. Figuren nedan visar en generaliserad struktur för interaktion med DeviceManager, MIS och enheter.

Interaktionsstrukturen mellan MIS och DeviceManager visar tre alternativ för plugin-program:

1. Pluginet tar inte emot någon data från MIS och skickar data omvandlade till ett format som är förståeligt för det från enheten (motsvarar enhetstyp 3 i figuren ovan).
2. Pluginet får en kort (när det gäller körtid) uppgift från MIS, till exempel att skriva ut på en skrivare eller skanna en bild, köra den och skicka resultatet som svar på begäran (motsvarar enhetstyp 1 i figuren ovan) ).
3. Insticksprogrammet får en långsiktig uppgift från MIS, till exempel att genomföra en undersökning eller mäta indikatorer, och som svar skickar uppgiftens acceptansstatus (uppgiften kan nekas om det finns ett fel i begäran). Efter att ha slutfört uppgiften konverteras resultaten till ett format som är begripligt för MIS och laddas upp till gränssnitten som motsvarar deras typ (motsvarar enhetstyp 2 i figuren ovan).

DM-huvudprogrammet startar, initieras, startar om i händelse av ett oväntat stopp (krasch) och avslutar alla plugins när de stängs av. Sammansättningen av plugins på varje dator är olika, endast de nödvändiga startas, som anges i inställningarna.

Varje plugin är ett oberoende program som interagerar med huvudprogrammet. Den här definitionen av ett plugin möjliggör mer stabil drift på grund av oberoendet av alla plugin-instanser och huvudet när det gäller felhantering (om ett kritiskt fel inträffar som gör att plugin-programmet kraschar, kommer detta inte att påverka andra plugins och huvudet) . En plugin låter dig arbeta med enheter av en typ (ofta samma modell), medan vissa plugins bara kan interagera med en enhet, medan andra kan interagera med flera. För att ansluta flera enheter av samma typ till en DM, starta flera instanser av samma plugin.

Qt-verktygslådan användes för att utveckla DM:n eftersom den i de flesta fall möjliggör abstraktion från ett specifikt operativsystem. Detta möjliggjorde stöd för datorer baserade på Windows, Linux och MacOS, såväl som Raspberry Pi-enheter med ett enda kort. Den enda begränsningen för valet av operativsystem vid utveckling av plugin-program är tillgången till drivrutiner och/eller specialiserad programvara för en specifik enhet.

Interaktion mellan plugins och huvudet sker genom en konstant aktiv QLocalSocket med namnet på en specifik plugin-instans, enligt protokollet vi skapade. Implementeringen av kommunikationsprotokollet på båda sidor var designat som ett dynamiskt bibliotek, vilket gjorde det möjligt att utveckla vissa plugins av andra företag utan att helt avslöja interaktionen med huvudet. Den interna logiken i det lokala uttaget gör att huvudet omedelbart kan lära sig om fallet med hjälp av en anslutningsavbrottssignal. När en sådan signal utlöses startas det problematiska pluginet om, vilket gör att du kan hantera kritiska situationer mer smärtfritt.

Man beslutade att bygga interaktionen mellan MIS och DM baserat på HTTP-protokollet, eftersom MIS fungerar utifrån Webbservrar, vilket gör det enklare att skicka och ta emot förfrågningar med hjälp av detta protokoll. Det låter dig också identifiera problem som kan ha uppstått vid inställning eller körning av uppgifter på enheter baserat på svarskoder.

I de följande artiklarna, med exemplet med flera diagnostiska centerrum, kommer driften av DM och några plug-ins att undersökas.

Källa: will.com