Study of Middleware for IoHT and Their Applications
229
reaction, such the case of an application that monitors the vital signs of a patient
in a reanimation unit. Any modification in these signs (heart beats rate decrease,
respiration problem, etc.) should trigger an event that must be handled rapidly.
In these situations, an event-based middleware is a suitable candidate.
In SOA, there are service providers, service consumers and service registry.
The service consumers search their required service from a service registry. They
inform the corresponding service provider if the service is found. This architecture is well-suited for heterogeneous devices. And it ensures efficient service
composition. However it does not fit real time applications. Many health scenario
rely on one to many communication like the dissemination of a relevant healthcare information to a group of patients. In these situations, Publish/Subscribe is
more suitable than the request/response strategy because it offers lower delays.
But, if many situations are present simultaneously, how to choose the best middleware?
The answer is: Why to choose if we can combine? Effectively, most of these
middleware classes are not mutually exclusive! We can conceive a middleware
that is at the same time an event-based and a Web of Things-based for example.
A middleware can even contain multiple components and each component can
be based on different middleware class.
Based on the studied middleware, we can confirm that there are up to now lot
of challenges that are not overcame. Indeed, the majority of the proposed middleware are conceived to a specific application and are not able to be adaptable
to other applications without applying core modifications. Also, interoperability
is still a crucial issue due to the continuous emergence of new medical devices
with new technologies and new standards. Furthermore, the progress of the security middleware is countered by the progress of the security attacks, which lets
security one of the most leading open issues that need more investigation.
4 Conclusion
We studied in this paper existing middleware for the Internet of Healthcare
Things and specified their various applications. This study conducted us to conclude that in spite of the diversity of the proposed middleware, none of them has
the ability to fulfill all the healthcare requirements. This urges to the openess and
the collaboration between these middleware to have a more robust middleware
verifying the trade off between the IoHT needs and devices technical limits.
References
1. Menvielle, L., Audrain-Pontevia, A.F., Menvielle, W.: The Digitization of Healthcare: New Challenges and Opportunities. Palgrave Macmillan, London (2017)
2. Wilk, S., et al.: An ontology-driven framework to support the dynamic formation
of an interdisciplinary healthcare team. Int. J. Med. Inf. 136, 1–12 (2020)
3. Shukla, S., Hassan, M.F., Khan, M.K., Jung, L.T., Awang, A.: Ananalytical model
to minimize the latency in healthcare internet-of-things in fog computing environment. PLoS One 14(11), 1–31 (2019)
229
reaction, such the case of an application that monitors the vital signs of a patient
in a reanimation unit. Any modification in these signs (heart beats rate decrease,
respiration problem, etc.) should trigger an event that must be handled rapidly.
In these situations, an event-based middleware is a suitable candidate.
In SOA, there are service providers, service consumers and service registry.
The service consumers search their required service from a service registry. They
inform the corresponding service provider if the service is found. This architecture is well-suited for heterogeneous devices. And it ensures efficient service
composition. However it does not fit real time applications. Many health scenario
rely on one to many communication like the dissemination of a relevant healthcare information to a group of patients. In these situations, Publish/Subscribe is
more suitable than the request/response strategy because it offers lower delays.
But, if many situations are present simultaneously, how to choose the best middleware?
The answer is: Why to choose if we can combine? Effectively, most of these
middleware classes are not mutually exclusive! We can conceive a middleware
that is at the same time an event-based and a Web of Things-based for example.
A middleware can even contain multiple components and each component can
be based on different middleware class.
Based on the studied middleware, we can confirm that there are up to now lot
of challenges that are not overcame. Indeed, the majority of the proposed middleware are conceived to a specific application and are not able to be adaptable
to other applications without applying core modifications. Also, interoperability
is still a crucial issue due to the continuous emergence of new medical devices
with new technologies and new standards. Furthermore, the progress of the security middleware is countered by the progress of the security attacks, which lets
security one of the most leading open issues that need more investigation.
4 Conclusion
We studied in this paper existing middleware for the Internet of Healthcare
Things and specified their various applications. This study conducted us to conclude that in spite of the diversity of the proposed middleware, none of them has
the ability to fulfill all the healthcare requirements. This urges to the openess and
the collaboration between these middleware to have a more robust middleware
verifying the trade off between the IoHT needs and devices technical limits.
References
1. Menvielle, L., Audrain-Pontevia, A.F., Menvielle, W.: The Digitization of Healthcare: New Challenges and Opportunities. Palgrave Macmillan, London (2017)
2. Wilk, S., et al.: An ontology-driven framework to support the dynamic formation
of an interdisciplinary healthcare team. Int. J. Med. Inf. 136, 1–12 (2020)
3. Shukla, S., Hassan, M.F., Khan, M.K., Jung, L.T., Awang, A.: Ananalytical model
to minimize the latency in healthcare internet-of-things in fog computing environment. PLoS One 14(11), 1–31 (2019)