Cloud infrastructure sample case: Haelvoet – Olympia Hospital II
The example below shows how an already existing product, being a hospital bed, can evolve to an IoT product. It helps illustrating how to use the general flow described here, but does not discuss available technologies. See the section on AWS IoT for that.
Please keep in mind that this is a rather simple example (read: not a proposal), which only has an illustrative purpose.
Who can help?
Training people in the organization for the above steps is an option. Required knowledge is available within the consortium. Or, since investing in activities that is not one’s core business is not very time- and cost effective, other parties that make one or more of the above steps their business can help.
Completing the knowledge base and listing the available parties is a market research that will be carried out during the course of the ProMoW project.
What is the product?
In this case, the product is a hospital bed with a lot of options. More details can be found here. The goal is to make this bed somewhat “smarter”. The idea is to simplify the work of the nursing staff. We want to make the bed able to report that an infusion needs to be replaced or if its patient is no longer present (psychiatric department).
What sensors are needed?
Implementing the described uses cases (detecting infusions levels / patient’s presence) only requires two types of sensor:
- The infusion level could be monitored by using some kind of load sensor.
- To determine the presence of a patient one could integrate push sensors in the bed.
Possibly there are some better solutions, but let me reminder you that this is only an example case.
What kind of data?
In this case, we could consider the data as time series. One could send a message every single second holding the infusion level in milliliters (translated weight from the load sensor) and a bit (button pushed? 1 or 0) for the patients’ presence.
Processing and storing the data
Processing the data can happen at different levels. In this specific case, for example, we could “interpret” the level of the infusion locally, at the bed: Whenever the weight is below a specific threshold, it sends a message to our cloud. Or, no filtering happens locally and the infusion level is send every second to the cloud regardless of the threshold. The latter might be more interesting, as it gives us an insight how fast the level is decreasing. For example, we could integrate a new feature that adjust the decreasing speed automatically.
The same approaches can be used to detect the presence of a patient. Locally we could check if one or more buttons are pressed, sending “presence” to the cloud immediately. Again, we could also send all the values to the cloud and do there analysis there. As made clear by these thought patterns, it is important to always determine pros and cons of different approaches. In this case, the cloud can offer multiple advantages, such as scalability (thousands of beds), outsourcing infrastructure (servers, load balancer, firewalls, etc.) and (a part of) software knowledge (streaming data, event handlers, databases, etc.), easily securing data, availability (datacenters are spread geographically) and reliability.
The biggest concern doing this might be to entrust data to a cloud provider. You have very limited control over your data, once it is in the cloud. Besides the choice between a cloud provider and an on-premises solution, it is important to think in detail about how the data will be processed. In this case, at first glance, the analysis will be rather simple, as the case is simple. If we would use a service such as Amazon Web Services IoT (AWS IoT), implementing this set-up is not that difficult. The same is true for storing the data. One has to decide which way and in what kind of database everything should be stored.
How to make available
In addition to the IoT section, it must also be considered how the final application will be made available. There are many options. For example, one could use different (scalable) web servers to host the application. To ensure that the application is available at all times, you can request the servers at different geographic locations.
Presenting the data
The final product is a dashboard operated by the nursing personnel: Some kind of web application where an authorized staff-member can consult data of the patients and receive the “smart bed” data. The system has an option to specify whether a patient needs an infusion or not. If so, the system can send out an alert as soon the infusion level is low. There is also a possibility to trigger and alarm if a (psychiatric) patient leaves his / her bed. One can conclude that already existing data is linked to new data coming from the bed. To be future proof, the system is extensible with new features.