Study case
Virtualise an ultrasound trolley: move from an all-in-one / standalone healthcare solution (ultrasound trolley) to a delocalized solution with specific modules running in different places.
Demonstration
We have started some communication and performance tests and defined some test points for taking measures about throughput and, mainly, latency. In addition, we have to understand the best protocols to use, in particular for the real-time exam execution. We are testing sockets and gRPC (high performance Remote Procedure Call) protocols.
Demonstration
We have started some communication and performance tests and defined some test points for taking measures about throughput and, mainly, latency. In addition, we have to understand the best protocols to use, in particular for the real-time exam execution. We are testing sockets and gRPC (high performance Remote Procedure Call) protocols.
Scenarios
We are initially working in an infrastructure with four virtual machines - one for each actor - in the University of Genova and CNIT.
Goal
The objective is to move from an all-in-one / standalone healthcare solutions (ultrasound trolley) towards a delocalized solution with specific modules running in different places. It is expected that the Processing unit component will run on the NEPHELE platform.
Description
Nowadays we usually have all-in-one / standalone solutions for taking ultrasound images. Depending on the exam to be performed we could have different kinds of probe. All-in-one means that all features - both software and hardware - are plugged together in an ultrasound trolley where we have a Windows OS with all components running on it. The hardware components - diagnostic monitor, physical keyboard - are all mounted on the trolley. Standalone means that the device works with any connection towards Internet. The Processing Unit is one of the more important components. This component provides ultrasound frames, trasforming raw data coming from the probe into a video stream with different formats, with lossless compression.
What we are developing in NEPHELE is the virtualization of the process. The main elements inside the ultrasound trolley must become Virtual Objects. The elements to be defined are:
- The minimal hardware and software components, that is:
- a probe
- the ADC (Analog-to-Digital-Converter)
- the minimal software for packing the data and sending them to the network
- A dashboard for controlling the ultrasound parameters
- A display for remote consulting/training
The Settings Hub will be an additional element for exchanging settings amongst other elements.
It is possible to have additional actors, for example reporting service, an exam archive, a patient data system and others.
Technical constrains
- Definition of the Ultrasound Remote Platform
- Move and optimize main components from the ultrasound device to dedicated components or services outside a classic ultrasound equipment
- The migration of the Processing Service to Linux Container to simplify the deployment and running of the service on the NEPHELE platform
- Define hosting models (web application, native mobile, desktop, etc)
- Define best protocols (sockets, gRPC, MQTT, etc). MQTT (Message Queuing Telemetry Transport) is the de facto data exchange protocol for IoT messaging, tandardized by OASIS and ISO.
- Optimize communication from code side