1 Introduction

During a situation of emergency, it is important for hospitals to be able to communicate with each other and with emergency care providers about their shortage or availability of resources in terms of bed and staff capacity. With this information, first responders are able to manage at their best the flow of patients and this improves the response time and the health service resilience during emergencies.

For example, the emergency related to the spread of the COVID-19 virus in Italy required the activation of the Remote Control Center for Health Rescue (CROSS - Centrale Remota Operazioni Soccorso Sanitario) by the Italian Department of Civil Protection. This remote control centre acts in cooperation with the regional contact points to monitor and manage the available resources for hospitals and healthcare facilities on the whole national territory. Its goal is to give support to the areas where the emergency occurred and, if needed, to get access to resources of nearby areas. The mechanism is based on requests of resources (beds, personnel, etc.) that the CROSS platform aims to satisfy, identifying which other areas can provide the needed resources.

As a consequence, effective management of emergencies and crisis depends on the knowledge of each healthcare facility of the status of its own resources and on timely information availability, reliability and intelligibility. Therefore, having a fast communication of incidents and a subsequent processing of availability is a key point in order to provide relevant information as soon as possible, giving to emergency managers the possibility to take more accurate decisions. Furthermore, it’s mandatory to identify a common protocol/language to exchange data about availability among the different Stakeholders to facilitate the overall management.

The Hospital Availability Management System (HAMS), developed in the framework of the EU-funded SAFECARE projectFootnote 1, has been designed and developed to support hospitals in both aspects. Thus, the role of the HAMS is to manage the availability of hospital assets and provide hospital status and asset availability information in case of emergency. From one side, HAMS is able to provide operators with the current availability of hospital resources through a graphic interface. Thanks to the integration with incident detection systems and impact propagation models, HAMS considers not only health emergency but also incidents (physical or cyber) that can hinder the normal operations of the structure. On the other side, HAMS is able to export data in a format compliant with the EDXL-HAVE standard [1].

This paper provides a description of the HAMS system, its context and the innovation it brings, also compared to similar existing systems. Section 2 describes which are the current approaches in the definition of system for emergency management in hospitals. Section 3 provides an overall description of a more complex system in which the HAMS is one of the building blocks. Finally, Sect. 4 describes the HAMS system, its architecture and its integration with the other modules developed within the SAFECARE project.

2 Related Works

One of the essential parts of a hospital management system is the management of information about resources availability. A system that handles the hospital status and its resources availability is in charge of tracking the occupancy rates, calculating the number of required employees and estimating the number of available employees and other resources such as departments, bed availability, services, medical equipment, drugs, etc. Such information is of primary importance in emergency situation and different software that handles it should exchange this information through a common language. For this purpose several standards have been developed and this section provide a description of software that implemented the EDXL-HAVE standard.

Analyzing this standard, one of the first software based on it was the SAHANA Disaster Management System (DMS) [2, 3]. Sahana DMS system was used in 2010 during the earthquake emergency in Haiti and in particular in the city of Port-au-Prince. This system helped to handle the flow of victims in Haiti, sharing data about hospital availability with emergency managers.

Liapis et al. [4] described how, within the IMPRESS project, they implemented management system of Hospital Availability, through which hospitals or other health care institutions can exchange information about facilities and resources. The data about the hospital availability are entered by the hospital operators that report the bed, staff and service availability to the crisis center and first responders. In this case, operators usually receive a request from another hospital or emergency call center and answer the request reporting the availability of the hospital.

Health Resources Availability Mapping System (HeRAMS) [5, 6] developed by the WHO and Global Health Cluster, is another relevant example. Its purpose is to evaluate the availability of services and resources in the hospitals located in territories in crisis or health emergency. The system is based on surveys carried out in hospitals to collect information about the availability of health resources and services such as staff, beds, medical equipment, drugs. The results of the surveys are reported in an interactive dashboard to visualize the status of hospital resources. Based on the results, the WHO in collaboration with the local health ministries, develops analytical reports to plan future measures to improve the situation. This solution is therefore useful to help governments managing health services during emergency.

The analysis of the main projects in the management of hospital availability shows that the use of a standard in crisis or emergency is essential to exchange information quickly and reliably between different hospital systems.

3 SAFECARE Cyber-Physical Integrated Security System

SAFECARE project is developing an integrated solution for the cyber and physical security of the healthcare sector in general [9]. As so, the HAMS service is a component plugged in more complex infrastructure, consisting of cyber and physical incident detection systems and a centralised system capable to combine and store incoming data and evaluate potential impacts when security incidents occur (Fig. 1).

Fig. 1.
figure 1

SAFECARE global architecture

Full size image

Data about hospital assets are statically stored in a database, that in SAFECARE terminology is called Central Database (CDB). Such data includes departments, medical devices, facilities, personnel, etc. Moreover, dynamic information and messages such as fire alarms, physical access control alarms, malware detection and so on, are automatically generated by various sensors and systems and generally directed to human operators, that can validate or reject them. Once incidents are validated by human operators, potential impacts corresponding to that incident are evaluated and simulated. Impacts are a list of assets that may have been involved in the incident and for each asset a corresponding likelihood and severity is estimated. With the information contained in incidents and impacts, the HAMS can evaluate and update the availability and status of each resource. Indeed, the key is to optimize the way the availability of an asset in the system is updated when it changes.

4 Hospital Availability Management System

4.1 Relevant Data

When an incident occurs in a healthcare facility, such as hospital, the internal staff must have updated information on the availability status of several elements in order to adequately respond to the incident and safely continue the hospital activities for patients and staff. The required information can be grouped into three main categories: hospital assets (including services), bed capacity and staff availability.

Hospital assets include all the medical devices inside the hospital. Knowing which assets are available allows the hospital staff to understand which kind of patients can be accepted or if they have to be transported in another structure. Beyond medical devices, hospital assets include all the services required for the proper work and management of the hospital. These services are crucial to provide an effective assistance to patients and users and to guarantee their security and safety, even if at first sight, some of them may seem not essential. For example, the IT system is not specifically related to the treatment of a patient. However, it is crucial for the management and recording of its personal data and for protecting them from unauthorized access.

Finally, two essential elements that a hospital management system must handle are the number of available beds and available staff. The number of total and available beds should not be expressed by a total amount for the entire healthcare facility, but for each medical ward in order to provide a clear picture of how many patients, and which of them, can be admitted in the structure. Strictly related to the bed capacity is the assessment of available staff (doctors, nurses, paramedics, etc.) as they are a crucial elements to assist patients. Thus bed and staff availability are related and the availability of a ward or a hospital strictly depends on these two elements. According to this principle, in some open standards like the EDXL-HAVE, they are considered together, and the bed capacity parameter reflects fully staffed and equipped beds.

4.2 HAMS Data Model

As described above, the HAMS deeply relies on the EDXL-HAVE standard to represent data internally and to share them with other systems. This section provides a description of the main data types effectively used by the HAMS, through a detailed description of the standard. EDXL [7] is a set of standards approved by OASIS to manage the entire emergency life cycle. It was developed to exchange and share information easily between different emergency systems. EDXL-HAVE (HAVE) [8] is an XML messaging standard developed by OASIS in the context of emergency management. A HAVE schema consists of a root element that uniquely identifies the organization that is responsible for the reporting facilities. Figure 2 shows the HAMS data model based on EDXL-HAVE main data types. Each facility is described through several attributes and a list of sub-elements that allow a complete description of hospital departments, services, and resources.

Fig. 2.
figure 2

HAMS internal data model

Full size image

HAVE is the top-level container element for Hospital Availability Exchange (HAVE) message. It has the following attributes:

  • organizationInformation; it provides basic information about the name and location of the organization for which the status and availability is being reported;

  • reportingPeriod; it provides information about the period to which the report refers to. If this element is left blank, the assumption is that the file refers to the last 24 h.

HAVE element has also a list of facilities. Each Facility contains the following main attributes:

  • name of the facility;

  • kind of facility (e.g. hospital, long term care, senior residence, temporary Clinic);

  • geoLocation field that provides geo-spatial information about facility location;

  • status of the facility from the perspective of the person responsible for it;

Facilities can have several sub-elements, such as services, operations and resources. Each Service is represented by a set of attributes:

  • name of the service;

  • code that uniquely defines and represents the service;

  • status of the service;

  • bedCapacity, an element that reports bed capacity of a service, represented by two attributes:

    • baselineCount: contains the total amount of beds.

    • availableCount: contains the number of vacant/available beds;

Systems that are not considered medical assets but that are fundamental for the proper operation of the healthcare facility are represented as Operation elements. Operations are characterized by a name, a kind and a status.

Finally, medical devices and staff are represented by the resource element and staffing element. Through these elements it is possible to represent the status of the resources (medical devices and staff) in terms of offers or needs too.

4.3 HAMS Internal Architecture

The HAMS has been designed as a web application, following the client-server paradigm.

Fig. 3.
figure 3

HAMS internal architecture

Full size image

The Fig. 3 describes the internal architecture of the HAMS and the interconnections with other systems. Describing the HAMS architecture, two different parts can be identified:

  • The back-end part of the HAMS is a python web server that hosts all the logic to manage hospital status and resources availability, and also to elaborate incidents and impacts (defined in the SAFECARE terminology), and interacts with the rest of the SAFECARE systems, through the MQTT client and leveraging on REST APIs. Indeed, HAMS exchanges data communicating through the MQTT protocol, implemented in the Data Exchange Layer in the SAFECARE architecture. The MQTT protocol is based on a star logical topology: a broker is the center and manages all the connections with the clients. The transmitted messages are associated with a topic, and a client is able to receive messages associated with the topics it previously subscribed to. The messages are structured using the JSON format, and specific JSON schema has been defined for each message type. Data Exchange Layer also exposes several REST APIs to allow different modules to retrieve or store data from the Central database. Besides the communication with the Central database, the HAMS itself provides REST APIs to the front-end part and to other applications compliant with the EDXL-HAVE standard. In particular, one REST API is devoted to provide hospital data in EDXL-HAVE format. In this case, the individual facility can provide up-to-date reports via a web service, and an aggregator could poll the data regarding that facility to collect information and provide new insights based on the analysis of aggregated data.

  • The HAMS front-end is a web interface developed with the JavaScript framework Vue.js. The front-end represents the graphical user interface of the HAMS and it is in charge of providing an easy-to-use interface for hospital administrators and staff that manage the asset availability. Through this interface, it is possible to control the general availability of departments in each hospital as well as the availability of medical devices belonging to each department. Indeed, this interface is composed of three different views: i) a home page, that provide some general information, the overall status and the position in a map of the selected facility. It is useful to have information about position visualised in a map because hospitals may be composed of different buildings, distributed over a region; ii) a dashboard that provides a list of departments, showing for each of them the current status, the availability of beds and staff compared to the total amount (baseline), and the current status of the medical devices that belongs to that department; iii) a reporting page through which users can set manually the actual status of departments or medical devices and store updated values into the central database.

4.4 Integration with SAFECARE System

Taking into account the provisioning of availability data and the possibility of manually reporting information into the platform, the HAMS can be considered as stand-alone software to manage the availability of an hospital, but its operation is fully merged with the SAFECARE system and in particular, is an important phase of the incident lifecycle.

At boot time, HAMS populates its internal data structure with all the relevant information regarding the hospital obtaining the static data from the central database. In SAFECARE project, the Central Database, through the Data Exchange Layer, exports some REST APIs, that can be used by the HAMS module to get information about the various assets of the hospital and the corresponding baseline availability data. Following a similar approach of the HAVE standard, asset availability status is mapped using a two level approach: a Boolean value (yes or no), indicating if the asset is available or not, and a colour code (green, yellow, red) to better detail the availability. If an asset is marked with a “green” status, it is working in normal condition, thus it is fully available; if it is marked with a “yellow” status, the asset is still available, but it has been involved in an incident thus a specific attention must be put in order to avoid that the status will deteriorate; finally, if it is marked with a “red” status, there is a severe/extreme deviation from normal operation, making the asset not available. Furthermore, if an asset is a department or a facility, the static data provided by the central database module include the total number of beds as well as the number of staff people.

When fully operational, the HAMS receives messages from the incident detection modules, through the data exchange layer. This information provides data on the assets involved in an incident, associated with a severity level. Incidents are evaluated and validated by specialized human operators, so they are considered reliable. Based on the asset involved and on the severity of the incident, the internal logic of the HAMS applies several policies in order to automatically decide whether there is the need to update the status of involved assets. For example, if a physical incident reports a loitering and suspicious behaviour of two people in a hall, the incident will be managed but the HAMS will not update any availability. Instead, if a cyber incident reports an attack with high severity to a medical device or an IT system, the HAMS will update the status of these assets.

The updated status and availability are shown to the final user through the graphic interface. At the same time, the HAMS module updates a specific table of the Central Database in order to keep track of the history of availability changes.

After an incident is validated by a human operator, it is forwarded to the HAMS, and the other decision modules present into SAFECARE system. One of these module is the Impact propagation module [10]. This software, triggered by incident messages, evaluates the incident taking into account the directly involved assets and the severity, and it provides a list of assets that could potentially be impacted, simulating potential cascading effects of that incident. Thus, the output of the impact propagation module is a list of assets with a corresponding likelihood that indicates how likely it is for an asset to be affected or impacted by the incident. Once this process ends, the list of potentially involved assets is also forwarded to the HAMS. Upon these values, the HAMS will compute the final hospital availability after the incident, updating medical devices status as well as bed and staff availability if necessary. Updates of status and resource availability are stored into the Central Database and showed by the HAMS web interface, so that users can visualise updated information. These features, combined with the standardized data model and the possibility to get the hospital status through a specific REST API too, make the HAMS an innovative tool in its application field.

5 Conclusions

This paper describes the Hospital Availability Management Systems, developed as a sub-module of a more complex system that manages cyber and physical security in hospitals, considered critical infrastructures. The need to have updated information about the status and the availability of medical devices, available beds, and medical staff is crucial during emergencies. HAMS can manage this information, allowing authorized users to get data through a web interface or through a REST API that exports data according to the EDXL-HAVE format. It provides such information to other software and management systems, which are able to gather data from different infrastructures and to provide indications to first responders. This can improve the health service resilience and it is useful to reroute the flow of patients in case of incident. Through the integration with the SAFECARE system, HAMS aims to automatically update data about the availability of hospital assets, speeding up this process. Thus, HAMS can be considered as a step forward towards a fully automatic system able to update single asset availability based on incidents.