Een geautomatiseerd medisch centrum maakt gebruik van veel verschillende apparaten, waarvan de werking moet worden aangestuurd door een medisch informatiesysteem (MIS), maar ook van apparaten die geen commando's accepteren, maar de resultaten van hun werk moeten doorgeven aan de MIS. Alle apparaten hebben echter verschillende verbindingsopties (USB, RS-232, Ethernet, enz.) en manieren om ermee te communiceren. Het is bijna onmogelijk om ze allemaal in het MIS te ondersteunen, daarom is de DeviceManager (DM) softwarelaag ontwikkeld, die één enkele interface voor het MIS biedt voor het toewijzen van taken aan apparaten en het verkrijgen van resultaten.
Om de fouttolerantie van het systeem te vergroten, werd DM opgedeeld in een reeks programma's die zich op computers in het medisch centrum bevonden. DM is onderverdeeld in een hoofdprogramma en een reeks plug-ins die communiceren met een specifiek apparaat en gegevens naar het MIS sturen. De onderstaande figuur toont een algemene structuur van interactie met DeviceManager, MIS en apparaten.
De structuur van de interactie tussen MIS en DeviceManager toont 3 opties voor plug-ins:
- De plug-in ontvangt geen gegevens van het MIS en verzendt gegevens die zijn geconverteerd naar een voor hem begrijpelijk formaat vanaf het apparaat (komt overeen met apparaattype 3 in de afbeelding hierboven).
- De plug-in krijgt een korte (qua uitvoeringstijd) taak van het MIS, bijvoorbeeld het afdrukken op een printer of het scannen van een afbeelding, voert deze uit en verzendt het resultaat naar aanleiding van het verzoek (komt overeen met apparaattype 1 in de afbeelding hierboven ).
- De plug-in ontvangt een langetermijntaak van het MIS, bijvoorbeeld om een onderzoek uit te voeren of indicatoren te meten, en verzendt in reactie daarop de taakacceptatiestatus (de taak kan worden geweigerd als er een fout in het verzoek zit). Na voltooiing van de taak worden de resultaten omgezet in een formaat dat begrijpelijk is voor het MIS en geüpload naar de interfaces die overeenkomen met hun type (komt overeen met apparaattype 2 in de afbeelding hierboven).
Het hoofdprogramma van DM start, initialiseert, start opnieuw op in geval van een onverwachte stop (crash) en beëindigt alle plug-ins bij het afsluiten. De samenstelling van plug-ins op elke computer is anders: alleen de noodzakelijke worden gelanceerd, die zijn gespecificeerd in de instellingen.
Elke plug-in is een onafhankelijk programma dat samenwerkt met het hoofdprogramma. Deze definitie van een plug-in zorgt voor een stabielere werking vanwege de onafhankelijkheid van alle plug-ins en de kop in termen van foutafhandeling (als er een kritieke fout optreedt waardoor de plug-in crasht, heeft dit geen invloed op andere plug-ins en de kop) . Met één plug-in kunt u werken met apparaten van één type (vaak hetzelfde model), terwijl sommige plug-ins slechts met één apparaat kunnen communiceren, terwijl andere met meerdere apparaten kunnen communiceren. Om meerdere apparaten van hetzelfde type op één DM aan te sluiten, start u meerdere exemplaren van dezelfde plug-in.
De Qt-toolkit werd gebruikt om DM te ontwikkelen, omdat het ons in de meeste gevallen in staat stelt om afstand te nemen van een specifiek besturingssysteem. Dit maakte het mogelijk om het werken met computers op basis van Windows, Linux en MacOS te ondersteunen, evenals Raspberry single-board-apparaten. De enige beperking bij het kiezen van een besturingssysteem bij het ontwikkelen van plug-ins is de beschikbaarheid van stuurprogramma's en/of speciale software voor een specifiek apparaat.
Interactie tussen plug-ins en de kop vindt plaats via een constant actieve QLocalSocket met de naam van een specifieke plug-ininstantie, volgens het protocol dat we hebben gemaakt. De implementatie van het communicatieprotocol aan beide kanten was ontworpen als een dynamische bibliotheek, die het mogelijk maakte om enkele plug-ins van andere bedrijven te ontwikkelen zonder de interactie met het hoofd volledig bloot te leggen. Dankzij de interne logica van de lokale socket kan het hoofd onmiddellijk leren over de val met behulp van een verbindingsverbreeksignaal. Wanneer een dergelijk signaal wordt geactiveerd, wordt de problematische plug-in opnieuw opgestart, waardoor u kritieke situaties pijnlozer kunt afhandelen.
Er is voor gekozen om de interactie tussen MIS en DM op te bouwen op basis van het HTTP-protocol, omdat MIS op een webserver werkt, waardoor het eenvoudiger wordt om via dit protocol verzoeken te verzenden en te ontvangen. Ook is het mogelijk om op basis van responscodes onderscheid te maken tussen problemen die kunnen optreden bij het instellen of uitvoeren van taken met apparaten.
In de volgende artikelen wordt aan de hand van het voorbeeld van enkele diagnosecentrumkamers de werking van DM en enkele plug-ins onderzocht.
Bron: www.habr.com