Architecture

The BioT PaaS is a cloud-native system with a microservice design. It is built by default on AWS Virtual Private Cloud, but can also be ported to other managed clouds (e.g. Microsoft Azure, Google GCP). The following illustration shows the high-level deployment architecture of the BioT platform:

The system is deployed over 2 high-availability zones, ensuring that service is available at all times even if a complete AWS availability zone is out of commission.

All services utilize a microservices architecture and can be scaled up or down automatically per need, and without interruption of ongoing service. Each microservice is a walled garden owning its data. This means that if a single microservice gets compromised, only a small portion of the data gets exposed, and never a combination of patient data and identifying data (PHI). The microservice architecture also allows BioT to quickly and agilely introduce new platform updates, while keeping the same quality standard.

Communication Channels and Methodologies

The system allows for several types of communication over multiple channels:

Device communication - communication between the medical device and the BioT services is done via 2 separate channels:

1. IoT Channel

   a. This channel is MQTT-based and is used to create bi-directional communication with the device. It enables BioT services to receive small (payload size) observations (medical data) and status messages from the device, and to send configuration and commands to the device.

   b. This channel is opened by the device with the IoT broker and is kept alive, ready to receive configuration and commands from BioT. In parallel to listening to BioT, it is up to the device designer to decide on a policy for the device to report status (periodically or just upon changes).

   c. BioT does not initiate communication with the device if the device does not have an existing connection with BioT (that is, the device must open the communication channel). This allows deployment of devices in any network architecture scenario - behind NAT, FW, VPN, or any other security mechanism - in a completely transparent way that always allows communication.

   d. Once a communication channel is opened by the device with the IoT broker, BioT sends information to the device based on need, in real time. The device does not need to poll the server for updates, but needs to listen for MQTT notifications.

   e. The communication channel is encrypted using TLS.

   f. BioT provides a Software Development Kit (SDK) for the device that can be used by the manufacturer to implement this communication support on the device.

   g. The same channel is used when the device does not support direct Internet connection protocols and needs to be connected indirectly via a mobile phone or other gateways (GW). For example, a Bluetooth device may use BLE to connect to a mobile phone app, and from there to the Internet. The communication protocol between the GW or mobile phone app and the BioT cloud is the same as described above. BioT provides SDKs for this case as well.

2. Web Services Channel
   This channel is a standard web-based channel (using HTTPS) connecting to BioT web services and is used for several purposes:

   a. Portal connectivity - All user's portals are accessed via this channel.

   b. File transfer from the medical devices - MQTT protocol is optimized for relatively small data transfers. If there is a need for a collection of larger files, usually with raw data, they are sent to the BioT platform over a secure HTTPS channel.

   c. Video and images transfer - Similar to the file transfer mechanism, HTTPS is used to send imaging (video or pictures) from the device to the BioT platform.

   d. Web connectivity is established by the client. When the user accesses a portal or a device opens a connection for file transfer, it is initiated by the client side, similar to MQTT communication. This achieves the same transparency to the device or user connectivity scenario (NAT, FW, GW, etc.).

Device Data Persistency

The BioT architecture is built around the concept of configuration, as well as medical data stored in the cloud, providing manufacturers the following benefits:

• Reduces the device cost by limiting the need for non-volatile storage – data can be saved in the cloud.
• Improves PHI security by not storing any PHI data on the device and removing the capability of a compromised device to send PHI data.
• Simplifies configuration of devices in the field using the cloud to push configuration to devices, and allowing every device to operate in any mode of operation, per need and without on-site configurations. For example, when the device is used during hospitalization it may work in one mode, while at home, it may work in another mode.
• Allows manufacturers to grant doctors the ability to remotely configure patient devices without the need for a patient to visit a clinic – for example, changing the treatment protocol to take longer measurements because exacerbation was detected.
• Reduces complexity of the device software by removing the need for devices to manage state and / or persistency, by saving all data in the cloud and synchronizing it to the device, as needed.

High Availability (HA)

The system is built using a HA design that utilizes Amazon AWS high availability zones. This ensures that a local Amazon malfunction, impacting in an entire zone of servers or services, does not result in loss of service, as another HA zone immediately takes over.

The system works in an always-active-standby mode and continuously synchronizes information between the databases (DBs) of the availability zones, allowing smooth and transparent transition to another high availability zone in case of catastrophic failure.

The system natively provides local HA schemes, so any local failure in a component or service is managed locally without the need to move to another HA zone. This is done in a completely transparent manner.

Under any HA scenario, the system continues to operate in a way that is completely transparent to both users and devices. There is no need to change configurations, re-establish communications or re-configure any service or device.

Scalability

The BioT PaaS is designed for infinite scalability. It can manage any number of devices, with any type and scale of observation data and device configurations, as well as any number of manufacturer users and organizational users.

This is achieved using a load balancing scheme and a stateless microservice design that allow infinite growth in any parameter. Any states are managed in scalable DBs which are also not limited in scale, and can add computational power and storage on demand.

Detailed Architecture

A detailed deployment architecture showing the end-to-end deployment scheme including the complete AWS environment is shown in the following diagram.