According to Morin, the concept of an emergency has spread to all areas, but can be defined as the sudden and intense appearance of a disruptive event, which usually requires a human response  . In recent years, the number of such operations has increased and it has become difficult to provide support for the response to an emergency through health system coordination and management. Difficulties in terms of dispatching emergency ambulances have also been exacerbated in the cases of mass casualties  . Indeed, in France in 2012 there were 4.25 million emergency operations1. Emergency operations are defined in France as the response to any situation or an impending situation that constitutes a danger of major proportions that could result in serious harm to persons or substantial damage to property, and which is caused by the forces of nature, a disease or any other health risk, an accident or an act whether intentional or otherwise. These emergency interventions involve the use of one or more ambulances, according to the number of victims. The ambulances enable first aid to be given to the victims, and to transport them to a health facility corresponding to their needs. To accomplish this task, a discussion takes place between the first-aid workers in the ambulance and the medical command physician (who is in a remote location) in order to transport the victims to the most appropriate health facility. This health facility must then be informed to be better prepared for this arrival and to take care of the patient.
In a changing societal context, in which we strive to optimize the latest technologies to offer an integrated and flexible system for the chain of decisions in emergency operations, the objective of the work presented here is to “rethink the ambulance” in order to meet the technological challenges and provide optimal assistance to victims. In particular:
・ A new generation of emergency vehicles features new technologies that are underutilized by the emergency services because they are inadequate or poorly adapted.
・ New medical devices, such as electrocardiograms, are only partially interconnected and pre-integrated into ambulances.
・ Most exchange of information between first-aid teams and emergency operation centers are only made orally.
Another major cause of complexity is the multiplicity and wide range of roads (e.g. highways, national, local), which makes it difficult to define specific emergency plans  . As a consequence, emergency services are increasingly interested in improving their coordination (coordination focuses on the organization of activities deployed by different people involved in an operation) and communication (communication is verbal or exchanged between one person and another who seeks an answer) during emergency operations  .
The ability of emergency services to coordinate and communicate easier is one of the key factors to characterize and assess, in order to improve emergency operations. This factor is related to the concept of interoperability, which can be defined as the “the ability of two or more systems or components to exchange information and to use the information that has been exchanged”  . Therefore, emergency services involved in an emergency operation have to improve their interoperability. With this objective in mind, we propose to redesign the French ambulance with a focus on interoperability to facilitate the communication between all the services involved in an operation.
This paper focuses on how interoperability can be integrated to improve care for victims, from the arrival of rescue teams to the transport of victims to a hospital. After presenting the background issues of this research related to exchanges during emergency operations, this paper proposes a review of several research projects focusing on systems engineering and especially requirements engineering. The following section presents the considerations of interoperability for next generation ambulances, while the final section gives our conclusions and future prospects for this research.
2. Issues with Communication during Emergency Operations
Emergency operations can be treated in different ways in different countries. Our research focuses on the French model for addressing emergency responses, but we hope that our model can be applied internationally. One of the unique aspects of the French model for emergency medical aid, besides the fact that is based on the management of the patient by doctors specifically trained in emergency medicine, is that it relies on an order called in my a medical command physician and, when necessary, on medication for operations in the field. In addition, the French model  has some specific features, such as:
・ All interactions between the medical command physician and the first-aid workers are made via verbal exchange;
・ Only the medical command physician is allowed to contact the hospital where the victim is taken;
・ Only the medical command physician has authority over decisions regarding the victim even if (s)he is not on the site of the operations;
・ The use of a transport form on paper filled in by the first-aid workers.
As a recent report suggests  , these specific features can create some problems, which can complicate the emergency operations:
・ The loss of information during verbal exchanges that can be important to the decisions made by the medical command physician;
・ The hospital is often not informed of the arrival of an ambulance with victims or of the assessment made by first-aid workers;
・ The transport form is only seen by the first-aid workers and sometimes by the doctors when arriving at the hospital. It is not seen by the medical command physician.
As a consequence, we propose to redesign the ambulance service by taking account of the real needs of all the people involved in an emergency operation such as first-aid workers and doctors. To achieve this objective, improvement is needed in two main areas:
・ Data exchange must be improved between field teams and the medical command physician to improve early care for victims;
・ The physical and mechanical characteristics of the vehicle must be improved to reduce the negative effects on the victims during transport.
In this paper, we focus on data exchange. To address this issue, we propose to design a system in the ambulance that can integrate the results of medical and paramedical devices and information from the transport form as presented in Figure 1. Subsequently, the information integrated into the system can be translated by the first-aid workers to the medical command physician who can analyze it and decide on what should be done with the victim and then contact the hospital with all the information gathered. Finally, the medical command physician can give his decision to first-aid workers via the system to transport the victim to the appropriate hospital. The twofold objective of this innovative system is to provide the optimal response for the victim and streamline access to health facilities. The spirit of this ambitious and strategic plan is all about giving the medical command physician a better view of the situation and the condition of the victim to facilitate decision making and provide health-care tailored to the victim.
This system will be developed in close cooperation with users and the entire value chain in order to allow maximum integration as early as possible to ensure the interoperability and compatibility of equipment and operational management systems.
Specifically, vehicles will be designed that feature communication tools that are easy to use for field teams and perform well to be able to inform the operational management center, and facilitate decision making. These tools will also help in the development of protocols and operational procedures in what can be a complex environment. The features to be developed must enable to:
・ Facilitate communication with the medical command physician to improve care for the victim;
・ Improve methods for data exchange between the different emergency services;
・ Access library databases and assistance in the implementation of protocols;
・ Facilitate the choice of destinations for victims;
・ Select the proper channel for transmitting data according to its specificity (available bandwidth), its availability, and the type of data to be transmitted (criticality and volume). It is important to convey “necessary and sufficient” information to provide support to the victim regardless of their location.
Figure 1. Overview of solution proposed.
Today, no project has helped to transform the ambulance into an ambulance for future generations with a communication tool integrated into a real system, linking field teams and medical command physicians at the emergency operation center.
However, there are several projects or tools that partially resolve our issues:
・ Videoconferencing, used in 2008 by France Telecom Orange and the Paris hospital to experiment with a conferencing service between the control center of a hospital and an ambulance. This method permits direct communication between the field and the control center but does not enable the transfer and reception of data2
・ PILOT V3 and V4 of TPL System are fixed equipment that enable data transmission, but do not transmit multimedia data (image and video)3
・ In addition, medical tablets can be found in hospitals and provide access to patient data anywhere and anytime. However, these tablets are restricted to hospital use and do not allow the sharing of data processing  .
The following Table 1 compares how existing solutions respond to the issues concerned in terms of communication, transmission/reception of data, geopositioning, recovery constants, patient’s condition management, and data security.
The approach we propose posits that with the development of communication networks and the standardization of data transmission protocols, these markets will gradually converge towards a system based on linkages between a permanent intervening model of heterogeneous medical education across regions, and hospitals or nursing homes remotely.
To create this system, we propose the use of systems engineering. However, to respond to the issue of data exchange, it is important to consider interoperability within systems engineering. The next section presents the state of the art of systems engineering.
3. Requirements Engineering within Systems Engineering: The State of the Art
Systems engineering is an interdisciplinary discipline and the related means to enable the realization of successful systems. It aims to control the design of systems whose
Table 1. Existing solutions.
complexity does not allow for easy oversight. To achieve that goal, it focuses on defining customer needs and required functionalities early in the development cycle, documenting requirements, and then proceeding with design synthesis and system validation while considering the complete problem    , as presented in the following Figure 2.
Systems engineering defines several principles that support the design of systems and document their functionalities and interfaces in a way that ensures that independently designed systems can interoperate with each other. However, it is necessary to integrate this notion of interoperability into requirements engineering, which represents the most important step in systems engineering and is presented in Figure 3. Indeed, requirements engineering is the main cause of the failure or difficulties of a system, but it is also the main cause of the success of a project4. Requirements engineering is a methodical and multidisciplinary collaborative activity-based on science and
Figure 2. Vee Model of systems engineering  .
Figure 3. Requirements engineering in systems engineering processes  .
experience―to collect, specify, refine, and describe the requirements for a system to be positioned in its environment, and control the changes in these requirements early enough to make a globally optimal solution for the identified stakeholder needs.
The design of a system therefore entails the specification of requirements from the stakeholder needs that the system must meet. It must also ensure at each phase in project design that each requirement has been taken into account and that the result of each step meets the requirements.
A need is a desire expressed by a user or by any stakeholder interested in the use or operation of the system. A requirement is defined as “a statement which requires a function, ability or characteristic which a product or a system must fulfill in a given context”  . This is a fundamental concept that must guide any activity, i.e., the design and development of systems engineering. There are two categories of requirements in this area  , namely functional requirements and non-functional requirements. Functional requirements specify what the system should do. Non-functional requirements specify how the system ultimately “does it” in terms of performance, security, reliability, ergonomics, and constraints.
Furthermore, during the engineering requirements phase, requirements must be clearly expressed, identifiable, traceable, verifiable, unambiguous, and not contradict any other requirements from the same repository. Various problems may be encountered during these activities, such as volatility, modification, and expression of requirements.
For this purpose, requirements engineering manages system requirements throughout the life cycle of a system. The objectives of the engineering requirements are as follows:
1) The identification of stakeholders. Who does what? Identify stakeholders, that is to say, all people or groups who are related with the product or system to handle during its life cycle.
2) Requirements elicitation. What should the system do? Identify and articulate the needs expressed by the stakeholders. Methods such as brainstorming and interviews are often used.
3) Description of requirements. Translate each need into a set of requirements and then consider all the requirements to analyze, complete, arrange the trace and eliminate possible ambiguities, redundancies, unspoken, omissions between traditional requirements. The result is a document that clearly specifies all the requirements, which are often described in natural language.
4) Verification and validation of requirements   . We must then verify that requirements are well written and have the necessary qualities of a requirement, such as lack of ambiguity, readability, and feasibility. The next step is to validate the list of requirements with regard to stakeholder needs. This will provide a set of consistent and comprehensive requirements called “specifications” especially when they are validated and approved by stakeholders  .
5) Changing requirements. Modifications of requests and requirements can finally be managed and tracked.
Two engineering requirements methods exist to accomplish these objectives: the KAOS method and the REGAL method. The KAOS method (Keep All Objectives Satisfied)  assumes that requirements can be expressed as objectives. These objectives can then be refined into sub goals until provable and testable model requirements can be established. In addition, the REGAL approach (Requirement Engineering Guide for All) lists and structures a number of good practices in requirements engineering  . These methods enable engineering requirements to be made easily; however, interoperability is not taken into account for the conception of a system.
Thus, interoperability has to be considered in the first phase of the conception of a system, i.e., during the requirements engineering. The next section presents the approach we propose for taking into consideration interoperability during requirements engineering.
4. Approach Proposed
Interoperability is defined as a non-functional requirement that must be taken into consideration all along a system’s life cycle   . Non-functional requirements represent attributes that characterize a system. In this case, interoperability is one of the characteristics that the system must have; however, it often falls in the category of the so called “forgotten”-“illities”  .
Indeed, interoperability is often overlooked or not planned for during requirements engineering in the same way as accessibility, suitability, serviceability, and portability. As a consequence, interoperability should be one of the main requirements to think about during the requirements elicitation phase.
In this case, we used requirements engineering as illustrated in Figure 4 below. First, a survey is made using a questionnaire destined for the final users and builders of the system to collect their needs. Next, SysML is used  to complete use cases to give a global vision of the behavior of the system in terms of its functionalities. This step is completed in accordance with the survey to refine the stakeholder needs. Finally, the requirements obtained from stakeholder needs are presented in a requirements diagram.
Figure 4. Approach proposed.
During the elicitation of requirements with SysML  , which uses for example diagram requirements, our approach represents interoperability requirements in the diagram in Figure 5. Interoperability is part of the requirements with which the system may be subsequently built.
In order to demonstrate the importance of taking account of interoperability in the first phase of requirements elicitation, our approach focuses on interoperability requirements for the conception of next generation ambulances.
4.1. Interoperability Requirements for next Generation Ambulances
To design a new system that facilitates data exchange between first-aid workers and the medical command physician, our model starts with requirements engineering in order to take account of interoperability issues. In fact, interoperability can be an important aspect to think about during the conception of any system. Particularly today, interoperability is an important factor for systems to avoid any incompatibility or mismatch which can obstruct the sharing and exchange of data flows or the use of the
Figure 5. Requirements diagram of a system with interoperability requirements.
system with other systems. Two research projects have defined three categories of interoperability problems to be taken into consideration   :
・ Conceptual problems are concerned with the syntax and semantic incompatibilities of the flows to be exchanged;
・ Technological barriers are concerned with the use of computer or ICT (Information and Communication Technology) to communicate and exchange flow;
・ Organizational barriers are concerned with the incompatibilities of organizational structure and the management techniques implemented.
As a consequence, after the stakeholders, i.e. representing especially the users of the system (nurses, doctors, medical command physician and first-aid workers) and desig- ners have been identified, a survey was conducted among these stakeholders to clearly identify their real needs in terms of system design. This survey is based on interviews and the distribution of a questionnaire constructed initially to collect the needs from three points of view: operational, medical and technical as illustrated in Figure 6.
・ The operational point of view focuses primarily on actions taken by the field teams (rescuers, nurses and doctors) and their needs in terms of elements to communicate and operational constraints;
・ The medical point of view focuses on the needs expressed by essentially the medical command physician in terms of data to analyze (e.g., electrocardiogram) to make a diagnosis and a decision;
・ The technical point of view focuses on the techniques of communication used by the field teams and their needs in terms of data transmission and reception.
From the responses collected using the questionnaire, a large number of needs were identified and the early phases of requirements engineering in terms of the purpose, missions and objectives of the system design could be defined.
The actual purpose of the system is to improve the management of the victim by facilitating interactions with the field teams and the care facility of the medical command physician. Meanwhile, the overall mission of the system is to manage all information related to patients. This mission is broken down into the following tasks:
・ Collect information about the victim at the time of the first emergency call;
・ Receive all information collected by field teams;
・ Provide the medical command physician’s decision to field teams;
・ Provide information to the care facility that receives the victim;
・ Store the information in accordance with regulatory considerations (set location).
Figure 6. Questionnaire for survey.
As a consequence, the general goal of the system is to improve the recognition of each victim in any situation as well as in an isolated situation. This goal is based on the following objectives:
・ Have as much information as possible upon receipt of the order of departure of the ambulance from the station, if necessary during transit, the circumstances of the incident, and the victim’s condition;
・ Improve the exchanges between the medical command physician and para-medics or medical teams in the field;
・ Facilitate the diagnosis of pathologies requiring the rapid implementation of protocol and/or a specific destination;
・ Reduce the time of taking care of a victim by transmitting information from the victim during transport and arrival at the health facility via the medical command physician;
・ Reduce the loss of information stemming from oral transmission between multiple stakeholders.
In addition, in terms of performance, the objectives of the system are:
・ Reduce the waiting time during communications between field teams and the medical command physician;
・ Reduce time to support victims care facilities.
From these initial considerations and identified needs, it is possible to express the requirements of the system, which can be functional or non-functional. These require- ments concern several aspects such as expected services, performance, ergonomics, dependability, information security and storage. Several of these requirements are related to interoperability to avoid problems regarding the three objectives defined above.
Figure 7 presents the links between the system and other systems to improve interoperability during an emergency operation. In terms of conceptual considerations, several needs were formulated by stakeholders regarding the use of a common data base listing the procedures used to avoid any incomprehension between the field teams and the medical command physician. Then, in terms of technological questions, the need of
Figure 7. Interoperability issues to be resolves for next generation ambulances.
originality concerns the compatibility of the expected system with other systems such as medical and paramedical devices to retrieve the data to be sent to the medical command physician. Finally, in terms of organizational issues, many needs were expressed to avoid organizational problems when arriving at the hospital such as the sending of all information concerning the victim before the arrival of the ambulance to minimize the waiting time.
Several interoperability requirements were defined in relation to the three categories. An interoperability requirement is defined as: “a statement that specifies a function, ability or characteristic, related to the ability of a partner to ensure its partnership in terms of compatibility, interoperation, autonomy, and reversibility that it must satisfy”  .
Four categories of interoperability requirements are thus defined: compatibility, interoperation, autonomy, and reversibility, which respect the three categories of issues  . From this definition, we posit the hypothesis that in requirements engineering, an interoperability requirement can be applied to any system. As a consequence, an intero- perability requirement can be defined in general as “a statement that specifies a function, ability or characteristic, related to the ability of a system to ensure its interactions in terms of conceptual, organizational and technological aspects, which it must satisfy”.
Therefore, from the needs collected, several interoperability needs can be expressed regarding the three categories.
Figure 8 presents some examples of interoperability requirements related to the detected interoperability problems expressed previously to be avoided for the next generation ambulance we imagine.
In the next section, to express other interoperability requirements, we describe several scenarios from technical, operational, and medical points of view.
4.2. Emergency Operation Scenarios
The basic scenarios in which our system could be deployed concern several types of emergencies including the most frequent operations presented in Figure 9. The first
Figure 8. Example of interoperability requirements  .
Figure 9. Emergency operation scenarios.
type of emergency concerns non-emergency medical illnesses where the field team’s role is to transport victims and reassure them about their health.
The second type concerns an urgent medical illness where the field team’s role is to transport the victim quickly and apply first-aid intervention. The final type of emergency is related to a specific health incident that can be dangerous such as a cerebrovascular accident (CVA), cardiopulmonary arrest or intoxication. The effectiveness of the field team for the last two types of emergencies is closely related to the rapidity of care. Furthermore, in these types of emergencies, when necessary we must also take account of pediatric and obstetric concerns. In addition, these scenarios will be developed to take into consideration a factor of gravity. In this way, they can be developed in the case of an operation with one victim, several victims, the numerous victims plan (i.e., this specific plan is deployed when there are more than a specific number of victims for an operation), and a disaster.
The above scenarios will be completed in detail through input from users such as first-aid workers, doctors and medical command physicians, to be used as a reference for technical, operational and medical developments. The different operational modes to be taken account of during the conception of the system are represented in Figure 10:
・ Normal operation mode
・ Degraded mode:
o Total stop due to failure of data gathering.
o Total stop due to system failure:
§ Partial shutdown due to the failure of transmission system
§ Partial shutdown due to the failure of medical devices tool
Thanks to the aforementioned scenarios and operational modes, it is possible to represent the most important functionalities of the target system with a use case dia- gram. Figure 11 represents the functionalities that a user (e.g. first responder) has to handle in the system to engage in exchanges during an emergency operation for any scenario in normal operational mode. In fact, when the field team arrives at the operation site, it is first necessary to recover data on the victim such as name and age in
Figure 10. Operational modes for next generation ambulance.
Figure 11. Use case diagram for a next generation ambulance  .
order to enter them into the system. Subsequently, after giving the victim first aid and using medical and paramedical equipment such as an ECG (electrocardiogram), it is essential to recover the data. The data entered and retrieved are then sent to the doctor who will analyze them to make a decision. Finally, after the decision made by the medical command physician (request for additional information or transport to the hospital), the field team receives and acts accordingly for better care of the patient until the patient arrives at the health facility.
A system must be designed that enables all the established functionalities that ensure interoperability via the respect of interoperability requirements to ensure better care of victims in a next generation ambulance.
In an emergency operation, especially in the field, data exchange is becoming increa- singly important for field teams and medical command physicians to facilitate diagnosis and provide support to victims. Consequently, in this paper we propose a next generation ambulance that features a system such as a tablet for exchanging data efficiently. It is also important to consider interoperability when designing such a system for a next generation ambulance in the specific context of the French model for emergency operations. To achieve this goal, a survey was conducted by means of a questionnaire addressed to the main users of the future system (first-aid workers, doctors, medical command physicians) in a process of requirements engineering. Furthermore, the concept of interoperability was included that could take account of conceptual, organizational and technological issues through the integration of interoperability requirements into the requirements engineering process. Finally, several scenarios were developed in accordance with the future users of the system to consolidate the requirements ex- pressed during the survey. In summary, thanks to our approach, sixty stakeholder needs were identified, which have enabled us to formulate the requirements and constraints to take account of in the design of the next generation ambulance.
As we have insisted, our approach implies changes in the process of care delivery in order to optimize the dispatching of ambulances, enhance pre-hospital care by paramedics or first aid staff, and to better anticipate hospital care. Field test procedures will be launched in order to identify limits, prospects and further improvements.
Future research must first of all analyze the scenarios developed for emergency operations to consolidate and enrich interoperability requirements. It must also use the system developed in the established scenarios to verify that all requirements are satisfied so that the system can facilitate exchanges during an emergency operation. Finally, the research we propose aims to develop the prototype of a next generation ambulance using the specifications presented to improve the care given to victims before they are transported to a hospital.
This research was completed in the framework of the collaborative research project “AMBUCOM”, funded by the Single Interministerial Fund.
1Source: Ministère Intérieur-DGSCGC, Les statistiques des Services d’Incendie et de Secours, 2013.
 Tena-Chollet, F., Tixier, J., Dandrieux, A. and Slangen, P. (2016), Training Decision- Makers: Existing Strategies for Natural and Technological Crisis Management and Specifications of an Improved Simulation-Based Tool. Safety Science.
 Tena-Chollet, F., Tixier, J., Mangin, J.-F. and Dusserre, G. (2013) Development of a Spatial Risk Assessment Tool for the Transportation of Hydrocarbons: Methodology and Implementation in a Geographical Information System. Environmental Modelling & Software, 46, 61-74.
 Platts, D., Brown, M., Javorsky, G., Scalia, G. and MacKenzie, S. (2012) Smart Phone and Tablet PC Use by the Medical Profession—A Vital Clinical Tool or a Dangerous Distraction? “SMart Phone Utilisation for Rational Fact Finding”. Heart, Lung and Circulation, 21, S239-S240.
 Scucanec, S.J. and Van Gaasbeek, J.R. (2008) A Day in the Life of a Verification Requirement. US Air Force T&E Days Conference, Los Angeles, 5-7 February 2008, 104-116.
 Balci, O. and Ornwsby, W. (2002) Expanding Our Horizons in Verification, Validation and Accreditation Research and Practice. 2002 Winter Simulation Conference, San Diego, 8-11 December 2002, 653-663.
 Berard, B., Bidoit, M., Finkel, A., Laroussinie, F., Petit, A., Petrucci, L., Schnoebelen, P. and McKenzie, P. (2001) Systems and Software Verification: Model-Checking Techniques and Tools. Springer, Berlin.
 Van Lamsweerd, A., Dardenne, A., Delcourt, B. and Dubisy, F. (1991) The KAOS Project: Knowledge Acquisition in Automated Specification of Software. Proceedings AAAI Spring Symposium Series, Stanford University, American Association for Artificial Intelligence, 59-62.
 Charrel, B., Sauvagnargues, S., Mallek, S. and Tena-Chollet, F. (2013) Projet AMBUCOM, Conception et développement d’une ambulance communicante. Rapport intermédiaire, Expression du besoin et spécifications fonctionnelles, 40 p.