Proposing an International Standard Accident Number for Interconnecting Information and Communication Technology Systems of the Rescue Chain.

BACKGROUND: The rapid dissemination of smart devices within the internet of things (IoT) is developing toward automatic emergency alerts which are transmitted from machine to machine without human interaction. However, apart from individual projects concentrating on single types of accidents, there is no general methodology of connecting the standalone information and communication technology (ICT) systems involved in an accident: systems for alerting (e.g., smart home/car/wearable), systems in the responding stage (e.g., ambulance), and in the curing stage (e.g., hospital).
OBJECTIVES: We define the International Standard Accident Number (ISAN) as a unique token for interconnecting these ICT systems and to provide embedded data describing the circumstances of an accident (time, position, and identifier of the alerting system).
MATERIALS AND METHODS: Based on the characteristics of processes and ICT systems in emergency care, we derive technological, syntactic, and semantic requirements for the ISAN, and we analyze existing standards to be incorporated in the ISAN specification.
RESULTS: We choose a set of formats for describing the embedded data and give rules for their combination to generate an ISAN. It is a compact alphanumeric representation that is generated easily by the alerting system. We demonstrate generation, conversion, analysis, and visualization via representational state transfer (REST) services. Although ISAN targets machine-to-machine communication, we give examples of graphical user interfaces.
CONCLUSION: Created either locally by the alerting IoT system or remotely using our RESTful service, the ISAN is a simple and flexible token that enables technological, syntactic, and semantic interoperability between all ICT systems in emergency care. The Author(s). This is an open access article published by Thieme under the terms of the Creative Commons Attribution-NonDerivative-NonCommercial License, permitting copying and reproduction so long as the original work is given appropriate credit. Contents may not be used for commercial purposes, or adapted, remixed, transformed or built upon. (https://creativecommons.org/licenses/by-nc-nd/4.0/).

Introduction

According to the World Health Organization (WHO), more than 1.3 million people die on road traffic injuries annually; the major cause of death globally. 1 The second leading cause are falls, yielding 650,000 deaths per year. 2 For both events, victims often are unable to activate the rescue chain and bystanders are required to recognize and report the event.

Nowadays, accidents are reported by using emergency telephone numbers. Such calls are answered by a dispatcher, who is trained in requesting relevant information from the caller and providing him assistance in first aid. However, multiple studies reported delays in the alerting process. 3 4 5 Eventually, these limitations of manual emergency alerts could be overcome by automatic alerting, but to date this concept is not yet implemented. The WHO provides a summary of global emergency care system frameworks, which are based only on direct communication between humans using speech or paper documents. 6

However, some initiatives toward the aim of automatic alerting have been proposed already. For example, eCall is a European Union-wide project for vehicles. 7 In case of an accident, the vehicle automatically dials the emergency number, establishes a hands-free voice connection to the emergency dispatcher, and transmits a minimum set of data that includes time and global positioning system (GPS) data. Weinlich et al 8 proposed an “emergency call support system” based on a smartphone application with a single button that, once pressed, sends the GPS coordinates to an emergency center. However, such approaches require actions of the victims and are answered manually.

Fully automatic approaches have been proposed already. The accident detection and reporting system by Bhatty et al is a smartphone app for detecting and reporting accidents to nearby hospitals. 9 Dar et al developed an emergency response and disaster management system on android platform that notifies a nearby hospital, directs the ambulance to the accident location, and notifies the family of the victim. 10 Fogue et al proposed to automatically detect accidents through a vehicular network. 11 A few approaches are commercially available devices, for example, fall detection with Apple Watch. 12 However, these approaches are intended for specific types of accidents, specific hardware, or specific use-cases.

In the near future, we expect the response to smart devices performing emergency calls automatically being also automatically, without a human in the loop. This is due to the internet of things (IoT) disseminating rapidly, allowing to collect data in multiple aspects of daily life, in particular in environments such as smart homes, cars, and wearables. Within a smart home, IoT devices usually perform home automation tasks, such as climate control. Recently, there is a trend toward smart health care applications, 13 driven by the need for remote health monitoring in an aging society. 14 Applications include floor tiles for fall detection, 15 mirrors reflecting the health status, 16 or unobtrusive vital sign measurement. 17 18

Today, vehicles already host more than 100 sensors for external and internal climate (e.g., humidity, light, and temperature), vehicle- (e.g., wheel pressure and window opening), engine- (e.g., water and oil temperatures), trip- (e.g., speed, acceleration, and front radar), and occupants-related (e.g., seat occupation and camera) information as well as for feeding active driving assistance. 19 Current research yields further sensor types, for instance, adaptive airbags 20 and sensors monitoring the health status of passengers. 21

Smart wearables range from rather small devices, such as watches, toward textiles with embedded sensors that cover large parts of the body. 22 Typically, sensors measure environmental data (e.g., outside temperature) behavioral data (e.g., movement), and vital signs (e.g., heart/respiration rate, blood pressure, body temperature). 23 Wearable devices have a multitude of potential applications, ranging from well-being (e.g., monitoring the number of steps per day) to safety-critical applications (e.g., monitoring fatigue of workers in hazardous environments).

Evidently, the given examples are not exhaustive and other smart environments could issue automatic alarms as well.

Disregarding research projects, 9 10 11 today alarming still means phoning and dispatchers request relevant information from the caller, which they manually enter into isolated information and communication technology (ICT) systems. 24 Then, an ambulance is sent to the position of the event. Medical professionals store initial findings on mobile computers 25 but use different ICT systems for measuring vital signs. 26 Arriving at the emergency room, physicians record triage and related data. 27 When the patient is transferred to the appropriate treatment unit (e.g., prompt care and intensive care), further components of a hospital information system are involved, for example, patient data are stored in an electronic health record images within a picture archiving and communication system, and laboratory values within a laboratory information management system.

Objectives

In this work, we propose the International Standard Accident Number (ISAN). Our principal motivation is twofold (1) to establish fully automatic emergency alerts and (2) to interconnect the isolated ICT systems of the rescue chain for automatic, secure, and interoperable data exchange. We aim at establishing a “multipurpose” identifier that is able to cope with a variety of events and is not bound to a specific type of emergency or hardware. Regarding interoperability, it has three aspects: (1) technology, that is, defining the connectivity between the systems; (2) syntax, that is, defining the format of data exchange; and (3) semantics, that is, defining the meaning of data. 28 Information exchange across ICT systems requires a common token, which is nonexistent in the rescue chain to date. We intend to fill this gap with the ISAN. In this work, we describe the ISAN syntax and semantics, and we give examples of technology interoperability.

Materials and Methods

In operator-based calls, the dispatcher acquires event details using standardized questions (Who? What? When? Where? Why?). If an alarm is issued automatically, relevant information must be exchanged between ICT systems of the alerting (e.g., smart home/car/wearable), responding (e.g., ambulance), and curing (e.g., emergency room) instances of the rescue chain.

International Standard Accident Number Requirements

Based on the characteristics of the rescue chain 6 and the levels of interoperability, 28 we derive key requirements for the ISAN.

Automatic Alerting

On the time of event occurrence, the ISAN is generated automatically without human interaction. To ensure a unique ISAN, we do not use initial dummy values to be replaced later but derive a minimal dataset that can be obtained automatically in all cases: point in time (When?) and position in terms of location and altitude (Where?). The remaining questions (Who? What? Why?) cannot be answered automatically in all events.

Technological Interoperability

We consider the ISAN as a token simplifying and accelerating the rescue procedures and we want to include scenarios, where IoT hardware acts as an alerting system activated by their integrated sensors. Hence, for the IoT hardware, we require minimal processing power, memory consumption, and data rate. In particular, IoT devices shall be able to generate an ISAN using their existing hardware. Ensuring backward compatibility, technological disruptions (e.g., smart implants, drones), and new standards (e.g., 5G cellular networks) shall be incorporated in the future. In addition, we construct the ISAN based on regular expressions. 29

Syntactic Interoperability

We intend the ISAN to interconnect diverse ICT systems. This requires a high degree of syntactic interoperability that we build upon existing technology. The success of incorporating existing standards is demonstrated, for example, by health level 7 (HL7) fast health care interoperability resources (FHIR), 30 which uses representational state transfer (REST) and extensible markup language, or the digital imaging and communications in medicine (DICOM) standard, which incorporates several International Organization For Standardization (ISO) norms. 31

Semantic Interoperability

The machine-to-machine communication of an ISAN without any human interaction contains static data (e.g., identifier of the alerting system) and dynamic data (e.g., point in time of event). To ensure semantic interoperability, we require the ISAN to represent this information using existing standards. Only if internationally accepted standards are unavailable, we specify a custom format such that can be implemented easily.

Existing Standards

Regarding the embedded content of an ISAN, we focus on time, position (location and altitude), and require the ISAN to be unique by using a system-specific, unique identifier. In the following, we review existing standards and analyze their pros and cons.

Technological Requirements

The ISAN generation aims at being independent of aspects such as hardware, operating system, or programming language. Most importantly, the alerting system must be able to detect an emergency. Additionally, the minimal requirements are a real-time clock and for movable systems a sensor to measure its location (e.g., GPS module). If the system is stationary, the location is hardcoded (e.g., street address). For ISAN generation, basic string processing capabilities (e.g., concatenation) are required and for its transmission a TCP/IP stack with internet connection is needed. We believe that these requirements should be fulfilled by the majority of alerting systems (e.g., embedded system, smartphone, and IoT).

Syntactic Standards

Fixed-Order Paradigm

The fixed-order paradigm is a key concept in computer science. For example, the HL7 standards V2.x, 32(p7) as widely used in health care, 33 follow the fixed-order paradigm. They compose a message of multiple lines (“segments”) containing “fields” of text. A one-character delimiter (“|”) separates these fields, and the standard specifies their number and content. Each segment starts with a three-character string defining its content (e.g., “PID” indicates the patient identity). If information is missing, the field stays empty but the delimiters are present.

Tag-Value Paradigm

The tag-value paradigm is used, for instance, by the hypertext markup language (HTML) or the tagged image file format. Here, the number and order of fields are variable. The tag defines the format of the corresponding value. In medicine, DICOM follows that paradigm. 34 Data are stored in so-called “data elements,” and each element has a unique tag, a name, and a value representation.

Semantic Standards

We reference to ISO standards or, with regard to the internet, requests for comments (RFC). However, frequently used formats also rely on informal agreements or best practices.

Time

Since the first computer systems, representation of date and time is challenging, and many formats have been used ( Table 1 ). An even higher number of implementations is available, for example, specific operators in programming languages or databases. The most widely used formats are Unix time and ISO 8601 with the latter being refined slightly in RFC 3399. RFC 5322 obsoletes foregoing RFC 2822 and RFC 822 defines the timestamps within electronic mail. The major differences between the formats are (1) their ability to express more complex information than points in time (e.g., time zones, durations, and repeating intervals), (2) the number of characters required for defining specific information, and (3) whether they are human readable.

Table 1

Formats for time

Standard	Format name	Est.	Format description	Example	Pros	Cons	Ref.
	Unix time	1971	Whole number within (0,2147483647)	1586436471	Widely used in operating systems	Can only specify fixed points in time	35
RFC 822	Standard for the format of ARPA internet text messages	1982	(day-of-week) DD-month-YYYYhh:mm:ss zone	Thursday, 9-April-202015:25:42 GMT		Replaced by RFC822	36
ISO 8601	Date and time format	1988	Basic format: YYYY-MM-DDThh:mm:ss“ ± ”hh:mm	2020-April-9T15:25:42 ± 2:00	Basis of nearly all time formats in programming languages and databases		37
			Extended format: YYYY-MM-DDThh:mm:ss+ hh:mm	2020-04-09T15:25:42 + 02:00
RFC 2822	Internet message format	2001	(day-of-week) DD-month YYYY hh “”: mm ( “”: ss ) “ ± ” hhmm	Thursday, 9 April 2020 15:25:42 +0200		Replaced by RFC 5322	38
RFC 3399	Date and time on the internet: time stamps	2002	Similar to ISO 8601 with minor differences, e.g., T can be omitted, Z can be used for (00:00)-time zone	2020-April-915:25:42-time zone	Specifies ISO 8601 and defines a formal grammar		39
RFC 5322	Internet message format	2008	Short format: DD-month-YYYYhh: mm:ss ± hh:mm	9-April-202015:25:42 +02:00	Widely known; used for timestamping e-mails	Many characters compared with other standards; can only specify fixed points in time	40

Abbreviations: ISO, International Organization for Standardization; RFC, requests for comment.

Position

We define the position of an accident being composed of a point on the Earth's surface (location, Table 2 ) and the height at this location (altitude, Table 3 ).

Table 2

Formats for location

Standard	Format name	Est.	Format description	Example	Pros	Cons	Ref.
	Universal transverse mercator	1940	Earth divided in 60 zones which are refined by a hemisphere (N/S) and by easting/northing values	Zone 32N, 604074 5792499			44
ISO 6709	Standard representation of geographic point location by coordinates	1983	Latitude and longitude are given in degrees, minutes and seconds (right; top) or in decimal degrees (bottom)	52°16′22.8‘‘N10°31′31.2‘‘E			45
				52.273000 10.525340
Defense Mapping Agency Technical Manual 8358.1	Military Grid Reference System	1996	Characters1–2: UTM zone3–4: 100,000-m grid squares5–9: Easting values10–15: Northing values	32U PC 04073 92498			46
Defense Mapping Agency Technical Manual 8358.1	World Geographic Reference System	1996	Characters:1–2: 24/12 long./lat. zones3–4: 15/15 long./lat. zones5–7: long. minutes8–10: lat. minutes	NK LH 315 163	Uses only increasingly shrinking quadrangles		46
Mapcode:A Public Location Reference Standard	Mapcode	2001	Territory identifier followed by a code encoding a rectangle where increasing the length of the code, decreases the sides length	DEU 9L.NDJ	Can be used with and without a country identifier	Cannot be truncated; Multiple codes may decode the same location	47
	Geohash	2008	Longitude and latitude are converted into a discrete grid using base 32	u1r3rs00q	Truncation allows to reduce accuracy	Multiple codes may decode the same location	48
RFC 5870	A uniform resource identifier for geographic locations	2010	An URI for encoding physical locations	<geo:13.4125,103.8667,10.000; u = 5.000>	Next to longitude and latitude, altitude and uncertainty can be defined		49
	Open Location Code	2014	Code encoding a rectangle where increasing the length of the code, decreases the sides of the rectangle	7GFG + 54 Braunschweig	Truncation allows to reduce accuracy; locality is optional		41
				9F4G 7GFG + 84
ISO 19160	International postal address components and template language	2017	Standard defining components of postal addresses	Mühlenpfordtstraße 2338106 BraunschweigGermany	Rules for country-specific rendering	Does not specify syntax, length or value range of components	43

Abbreviations: ISO, International Organization for Standardization; RFC, requests for comment.

Table 3

Formats for altitude

Standard	Format name	Est.	Format description	Example	Pros	Cons	Ref.
ISO 6709	Standard representation of geographic point location by coordinates	1983	±MMMM_CRSID where MMMM is the value and CRSID encodes the used coordinate reference system (e.g., WGS84)	±8850CRSWGS_84		Requires reference system	45
ISO 4157	Floor numbering	1998	Numerical digits	0 (ground floor)	Simple number	Does not consider text descriptions of floor	50
RFC 5870	A uniform resource identifier for geographic locations	2010	An URI for encoding physical locations	<geo:13.4125,103.8667,10.000; u = 5.000>	Allows to define altitude and uncertainty		49

Abbreviations: ISO, International Organization for Standardization; RFC, requests for comment.

Location

ISO 6709 represents the location by latitude and longitude either in degrees, minutes, and seconds, or in decimals. For its interpretation by a web browser, RFC 5870 describes an uniform resource identifier (URI). Next to latitude and longitude, it enables defining altitude and an uncertainty. However, these values are difficult to interpret manually and more intuitive codes, such as Mapcode, Geohash, and the Open Location Code have been proposed. 41 They support accuracy within a few meters. The universal transverse mercator (UTM) divides the earth into nonhierarchical zones, which are then further detailed using easting and northing values. 42 UTM is refined in hierarchical approaches such as the Military Grid Reference System (MGRS) and the World Geographic Reference System (GEOREF) ( Table 2 ).

Another concept to represent a location is based on postal addresses. ISO 19160 provides a hierarchical structure of postal address components for worldwide addressing but does not define their syntax. 43

Altitude

Regarding the altitude at a certain location, only few formats exist ( Table 3 ). ISO 6709 and RFC 5870 can be used to encode it optionally. Then, however, a coordinate reference system has to be defined as well. Within a building, ISO 4157 guides the assignment of the number of floors. Ambiguities arise from intermediate levels and large building complexes.

Uncertainty

As we have learned from metrology, any measure (in ISAN: time, location, and altitude) has an uncertainty that defines the accuracy of the measurement. The uncertainty depends on the physical method of measurement. Hence, uncertainty must be stored in the ISAN, too. We suggest coding it similar to RFC 5870 49 which results in measurement ± uncertainty yielding a time interval or an area in space. If possible, we reuse previous formats ( Tables 1 2 3 ).

Unique Identifier

Even if several alerting systems (e.g., cars) are involved in the same event (e.g., vehicle pileup), we want to deliver different ISANs to guarantee ISAN's uniqueness. Hence, we need a unique identifier as an ISAN component. Table 4 contains relevant formats for smart cars, homes, and wearables. Connected IoT devices are identified by media access control, internet protocol, or bluetooth device addresses. In cellular networks, the static international mobile equipment identity and international mobile subscriber identity identifies mobile phones and SIM cards, respectively. Nearly, all devices contain a manufacturer serial number, which is given by the manufacturer, but there is no established standard for its generation. The vehicle identification number uniquely identifies a (smart) car. If a device does not contain any unique identifier, a universally unique identifier (UUID) could be generated.

Table 4

Formats for identifiers

Standard	Format name	Est.	Format description	Example	Pros	Cons	Ref.
ISO 3779:2009	VIN	1954	Sequence with a length of 17 digits	1M8GDM9AKP042788	A large number of vehicles, including cars, motorcycle, and mopeds can be identified	Competing standards for VIN generation	51
RFC 791	IP version 4 (IPv4) address	1981	Sequence with four parts with 8 bits, resulting in a total length of 32 bits	192.168.0.1	Obtained easily	The IP address is not unique as the same may be used in different networks	52
ITU-TE.212	IMSI	1988	Sequence with a length up to 15 digits	310120265624299	Unique number for identifying clients in cellular networks (e.g., SIM Cards)	Access requires permission	53
ISO/IEC 10039	MAC address	1991	Sequence of 48 bits usually expressed as 12 alphanumeric characters	01–23–45–67–89-AB	Every device with a network interface has a MAC	Many network interfaces allow to manipulate the MAC address	54
RFC 4291	IP version 6 (IPv6) address	1995	Sequence with eight parts with 16 bits, resulting in a total length of 128 bits	2001:0db8:85a3:0000:0000:8a2e:0370:7334	Obtained easily	The IP address is not unique as the same may be used in different networks	55
3GPP TS 23.003	IMEI	1999	Sequence with a length of 15 digits	990000862471854	Unique number for identifying mobile phones	Accessing requires permission	56
Bluetooth Core Specification	Bluetooth Device Address	2001	Sequence of 48 bits usually expressed as 12 alphanumeric characters	01–23–45–67–89-AB	Obtained easily.	The address of the Bluetooth device can be changed	57
ISO/IEC 9834–8:2014	UUID	2005	Number with a length of 128 bits, usually represented as 32 hexadecimal characters	40151662-d18a-4b2f-97b3–0411098b04ef	Random number which is considered as unique	No central authority supervising UUID generation; may not be unique	58
	MSN		E.g. sequence with a length of 25 digits (Apple Unique Device Identifier)	12345678–90123456789012345	Given to a device by the manufacturer	No standard MSN generation; may not be unique.

Abbreviations: IMEI, International Mobile Equipment Identity; IMSI, International Mobile Subscriber Identity; IP, internet protocol; MAC, media access control; MSN, Manufacturer Serial Number; UUID, universally unique identifier; VIN, vehicle identification number.

International Standard Accident Number Services

To support stakeholders implementing the ISAN, we provide assisting services. Our description follows the user's perspective and does not assume specific hardware, software, architecture, or implementation.

Generation: An ISAN token is generated automatically in two steps: (1) acquisition of relevant data describing the accident or emergency (time, location, altitude, and unique identifier) and (2) generation of the ISAN token. We provide a service for step (2) that supports local as well as remote use, for example, if the alerting system is incapable to create an ISAN.

Conversion: To cope with diverse IoT devices, the ISAN specification supports several standards to semantically encode information. We provide a conversion service that checks for ISAN compliance and converts between compliant ISAN formats.

Analysis: Based on the uncertainty values of time, location, and altitude, we provide a service that evaluates whether different ISAN may indicate the same event.

Visualization: The ISAN is mainly intended for machine-to-machine communication. For humans, we provide an additional graphical visualization service, for example, a map showing the location.

Results

With respect to the defined requirements, we specify the ISAN, give examples, and demonstrate services.

International Standard Accident Number Specification

An ISAN consists of four embedded components, namely time, location, altitude, and unique identifier. They follow the fixed-order paradigm ( Fig. 1 , 2nd row) and are represented by data fields (3rd row). As measurements of time, location, and altitude are imprecise, the uncertainty is specified in additional data fields. This results in a total of seven fields, each of which following the tag-value paradigm (4th row).

Fig. 1

Structure of the International Standard Accident Number.

As established by HL7, 32 (p7), we suggest the “|” character as a separator between tags and values (i.e., the data fields). The altitude is optional and might be empty, yielding a sequence of separators (“||||”). The tag is formed as a single-character literal, where “0” indicates our preferred choice ( Fig. 2 ). We selected all existing formats which satisfy the introduced requirements.

Fig. 2

Semantic formats supported by International Standard Accident Number.

For the unique identifier, we only selected formats providing a high chance of being unique. There is no preferred format as it depends on the alerting device and the use-case. If an alerting device does not have a unique identifier (tags 1–6), a 10-digit number shall be generated using a pseudorandom number generated based on the Mersenne twister. 59 We did not use UUID (, 58 32 digits) as we believe that 10 digits are a suitable tradeoff between technical efficiency and the risk to obtain identical ISANs from different devices.

If ISO 19160 is used, we propose a representation based on the fixed-order paradigm and a new separator symbol (“^”). We selected a subset of elements from the standard for defining an address ( Table 5 ). With a total of 12 selected fields, 11 separator signs must be present, but 7 of those fields may be empty.

Table 5

International Standard Accident Number extract of ISO 19160

ISO 19160 standard (48)			ISAN location specification
Segment	Element	Name	Order Number	Required?
U40	13	Post Code	1	Yes
U40	14	Country Name	2	No
U40	15	Region	3	No
U40	16	Town	4	Yes
U40	17	District	5	No
U40	21	Thoroughfare	6	Yes
U40	24	Premises	7	No
U40	26	Building	8	Yes
U40	29	Wing	9	No
U40	30	Stairwell	10	No
U40	32	Door	11	No
U40	41	Country Code	12	Yes

Abbreviations: ISAN, International Standard Accident Number; ISO, International Organization for Standardization.

Regarding time uncertainty, we use the time representation of the ISO 8601 standard as it is the only format that can specify a duration. For the location, we refer to RFC 5870, specifying the radius (in meters) of a circle around the given measurement. Both, time and location uncertainty must not be empty. If the alerting system cannot compute an uncertainty value instantaneously, a fixed value must be used. For the altitude, if ISO 4157 is used for representing the measurement, the dimensionless number refers to floors. If the altitude measurement is empty, the corresponding uncertainty must be empty as well.

Example

Table 6 shows compliant ISANs created at the same point in time at the same location from different devices using different semantic formats. For example, the first ISAN was generated by an IMEI device (e.g., a smart phone). According to the specified uncertainty, the event might have occurred 10 seconds before or after the specified time (measurement ± uncertainty). The location is given in ISO 19160 format and the altitude is defined as a floor number. The location uncertainty is 10 m and the altitude uncertainty is 0 floors; therefore, the accident occurred within a 10 m radius at specified coordinates on the 4th floor.

Table 6

Example of compliant International Standard Accident Numbers that all were generated on August 8, 2020 from within the Peter L. Reichertz Institute of Medical Informatics in Braunschweig, Germany (time, location, altitude, unique identifier)

International Standard Accident Numbers examples
0|20200808T121010 + 0200|0|000010|2|38106^Germany^^Braunschweig^^Mühlenpfordtstraße^^23^^^442^DE|0|10|1| + 4|0|0|3|990000862471854|
1|2020–08–08T12:10:10 + 02:00|1|00:00:10|0|+ 52.2729771 + 10.5251894|0|10|0|10|0|0|5|01–23–45–67–89-AB|
2|1596888610|1|00:01:00|1|9F4G7GFG + 73G|0|20|||||7|9563718520|
4|Sat, 08 Aug 2020 12:10:10 +0200|0|001000 |0| + 52.2729771 + 10.5251894|0|5|1| + 4|1|00|2|1c:52:16:52:8c:3a|

Based on the defined requirements, we developed a RESTful API which can either deployed locally on an alerting system or can be accessed remotely: https://isan-service.plri.de/ ( Fig. 3 ). Next to generation of an ISAN (top left), the simple syntax and well-defined semantics allow conversion between compliant formats (top right), comparison of event location and time to check whether they are associated to the same event (bottom left), and a map-based visualization (bottom right). Additionally, a website is provided to enter the data manually for testing purposes. Services return the results in machine-readable JavaScript Object Notation except for the visualization service which returns an image in JPEG format.

Fig. 3

Screenshots of International Standard Accident Number services for generation (top left), conversion (top right), analysis (bottom left), and visualization (bottom right). Screenshots on the left show access via the RESTful API and screenshots on the right access via the website.

Discussion

We proposed the ISAN to enable automatic emergency alerts by linking ICT systems of the rescue chain. Building upon the results from literature, 9 10 11 which were focused on single type of accident, we indent the ISAN to be a “multipurpose” identifier not limited to a certain type of accident. Thereby, it directly contains information on time, position, and a unique system identifier, which, if not available, is filled randomly, but it does not contain information on the type of event. Certainly, this specification is limited by several aspects. Compared with the level of detail that is provided via an emergency phone call (Who? What? When? Where? Why?), the content of the ISAN is reduced. However, ISAN is supposed to link ICT systems as a token, and the who, what, and why can be coded by the records that are linked via the ISAN.

The International Classification of Diseases (ICD) is the global standard for encoding diseases and causes of death. Its 11th revision (ICD-11) allows to classify the reasons for a disease or death if it results from an external cause such as transport accidents, falls, threats to breathing, or exposure to chemicals. 60 Furthermore, extension codes describe the circumstances of an event, such as the role of the victim (e.g., XE42A vehicle driver), or the location of the event (e.g., XE8RZ bathroom). However, ICD-11 cannot be used as a unique token.

The ISAN is composed similarly to HL7 V2.x. 32 This might be regarded out of date, as HL7 delivered the clinical document architecture (CDA) and the FHIR standards already in 2000 and 2011, respectively. 33 However, CDA and FHIR is focused on human readability 61 and exchanging clinical data, 62 respectively. We assumed these standards too complex for IoT support.

As the ISAN is indented to be generated and transmitted without any human interaction, we believe that the chosen embedded information is an adequate tradeoff between content, data availability, and the high heterogeneity of alerting systems. The uncertainty stored within the ISAN can be used to (1) instantaneously determine whether two ISANs might refer to the same event and, additionally, (2) to support the emergency personnel in detecting the site of the accident. 63 It delays rescue from building complexes (e.g., hotels, hospitals) or complex sites (e.g., pileups) due to complicated wayfinding. 64 Furthermore, appropriate terminologies in emergency care need to be established. 65

Our work has several limitations:

We are suggesting the syntax and semantics of the ISAN, but not on the underlying network architecture or communication protocols. This needs further specification and consensus between all stakeholders, in particular for handling administrative metadata.

Our RESTful API just gives an idea of some ISAN functionality based on widely used communication protocols. However, it is only a demonstrator and not designed for routine use or handling of real emergencies.

An “ISAN platform” might be useful to register and manage involved ICT systems and to establish secure communication between the ICT systems that are involved in an accident. This platform can prevent critical security issues such as denial-of-service attacks by ISAN flooding, man-in-the-middle attacks by altering the communication between the ICT systems, or wiretapping of ISAN messages.

The proposed concept depends on timely ISAN generation and transmission. We do not consider situations with GPS being unavailable or devices detecting the critical issue delayed. Then, the “where” or “when” information is missing, respectively. As emergency calls without such information cannot be answered appropriately, the device might be switched to energy-saving mode and alert later.

Our ISAN idea is driven by fully automatic system communication without humans in the loop. Therefore, is it not designed to substitute manual emergency calls, where the staff of a control room will first ask a caller for his or her personal details. Furthermore, we did not add control numbers, as a manual input for ISAN generation is not planned, and the underlying communication protocols have own mechanisms to avoid transmission errors.

We claimed to define syntax and semantics of the ISAN by using established standards. Some standards, however, have limitations. For instance, the VIN needs vendor-specific background information to determine the vehicle type, and the floor numbering according to ISO 4157 might be ambiguous internationally because of different numbers of the ground level (0 or 1). This limitation can be addressed by further ISAN platform-integrated services.

In conclusion, we specified the ISAN to provide interoperability of ICT systems involved in the rescue chain. Focusing on syntactical and semantical interoperability, the ISAN is generated easily and supports diverse IoT hardware and software as alerting system (e.g., smart home, smart car, smart wearable). Thereby, ISAN will enable automatic alerts of and responses to a manifold of accidents and emergencies–purely by machine-to-machine communication and without any human in the loop.