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

Abstract

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.

Keywords

accidents (D000059) - emergency medical services (D004632) - emergency medical service communication systems (D004631) - health information interoperability (D000073892) - internet of things (D00008s0487)

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-YYYY hh:mm:ss zone	Thursday, 9-April-2020 15:25:42 GMT		Replaced by RFC822	[36]
ISO 8601	Date and time format	1988	Basic format: YYYY-MM-DD Thh:mm:ss“ ± ”hh:mm	2020-April-9 T15:25:42 ± 2:00	Basis of nearly all time formats in programming languages and databases		[37]
			Extended format: YYYY-MM-DD Thh:mm:ss+ hh:mm	2020-04-09 T15: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-9 15:25:42-time zone	Specifies ISO 8601 and defines a formal grammar		[39]
RFC 5322	Internet message format	2008	Short format: DD-month-YYYY hh: mm:ss ± hh:mm	9-April-2020 15: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‘‘N 10°31′31.2‘‘E			[45]
				52.273000 10.525340
Defense Mapping Agency Technical Manual 8358.1	Military Grid Reference System	1996	Characters 1–2: UTM zone 3–4: 100,000-m grid squares 5–9: Easting values 10–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. zones 3–4: 15/15 long./lat. zones 5–7: long. minutes 8–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 23 38106 Braunschweig Germany	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|

International Standard Accident Number Services

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.

Conflict of Interest

None declared.

Acknowledgment

We acknowledge support by the German Research Foundation and the Open Access Publication Funds of Technische Universität Braunschweig.

• References

• 1 World Health Organization. Global status report on road safety 2018. Accessed June 30, 2020 at: https://www.who.int/violence_injury_prevention/road_safety_status/2018
• 2 World Health Organization. Fact Sheet: Falls. Published January 16, 2018. Accessed July 1, 2020 at: https://www.who.int/news-room/fact-sheets/detail/falls
• 3 Takei Y, Inaba H, Yachida T, Enami M, Goto Y, Ohta K. Analysis of reasons for emergency call delays in Japan in relation to location: high incidence of correctable causes and the impact of delays on patient outcomes. Resuscitation 2010; 81 (11) 1492-1498
• 4 Swor RA, Compton S, Domeier R, Harmon N, Chu K. Delay prior to calling 9-1-1 is associated with increased mortality after out-of-hospital cardiac arrest. Prehosp Emerg Care 2008; 12 (03) 333-338
• 5 Nehme Z, Andrew E, Cameron P. et al. Direction of first bystander call for help is associated with outcome from out-of-hospital cardiac arrest. Resuscitation 2014; 85 (01) 42-48
• 6 World Health Organization. Emergency Care System Framework Infographic. Published May 2, 2018. Accessed July 1, 2020 at: https://www.who.int/publications/i/item/who-emergency-care-system-framework
• 7 European Commission. The interoperable EU-wide eCall. Published June 30, 2020. Accessed June 30, 2020 at: https://ec.europa.eu/transport/themes/its/road/action_plan/ecall_en
• 8 Weinlich M, Kurz P, Blau MB, Walcher F, Piatek S. Significant acceleration of emergency response using smartphone geolocation data and a worldwide emergency call support system. Kou YR, ed. PLOS ONE 2018; 13 (05) e0196336
• 9 Bhatti F, Shah MA, Maple C, Islam SU. A novel internet of things-enabled accident detection and reporting system for smart city environments. Sensors (Basel) 2019; 19 (09) 2071
• 10 Dar BK, Shah MA, Islam SU, Maple C, Mussadiq S, Khan S. Delay-aware accident detection and response system using fog computing. IEEE Access 2019; 7: 70975-70985
• 11 Fogue M, Garrido P, Martinez FJ, Cano J-C, Calafate CT, Manzoni P. A system for automatic notification and severity estimation of automotive accidents. IEEE Trans Mobile Comput 2014; 13 (05) 948-963
• 12 Apple Inc. Use fall detection with apple watch. Use fall detection with Apple Watch. Published 2020. Accessed July 2, 2020 at: https://support.apple.com/en-us/HT208944
• 13 Sadoughi F, Behmanesh A, Sayfouri N. Internet of things in medicine: a systematic mapping study. J Biomed Inform 2020; 103: 103383
• 14 Majumder S, Aghayi E, Noferesti M. et al. Smart homes for elderly healthcare—recent advances and research challenges. Sensors (Basel) 2017; 17 (11) 2496
• 15 Daher M, Diab A, El Badaoui El Najjar M, Ali Khalil M, Charpillet F. Elder tracking and fall detection system using smart tiles. IEEE Sens J 2017; 17 (02) 469-479
• 16 Miotto R, Danieletto M, Scelza JR, Kidd BA, Dudley JT. Reflecting health: smart mirrors for personalized medicine. NPJ Digit Med 2018; 1 (01) 62
• 17 Bruser C, Antink CH, Wartzek T, Walter M, Leonhardt S. Ambient and unobtrusive cardiorespiratory monitoring techniques. IEEE Rev Biomed Eng 2015; 8: 30-43
• 18 Deserno TM. Transforming smart vehicles and smart homes into private diagnostic spaces. In: Proceedings of the 2020 2nd Asia Pacific Information Technology Conference. ACM; 2020:165–171. Accessed January 2020 at: https://dl.acm.org/doi/10.1145/3379310.3379325
• 19 Robert Bosch GmbH. Bosch Automotive Electrics and Automotive Electronics: Systems and Components, Networking and Hybrid Drive. 5th ed.. Springer Vieweg; 2014
• 20 Shirur N, Birker C, Henze R, Deserno TM, Dudhat D. Effect of airbag deployment phases on tactile occupant detection sensor. In: Proc. Automotive Safety. Accessed 2020 at: https://www.researchgate.net/publication/324310143_Design_and_Occupant-Protection_Performance_Analysis_of_a_New_Tubular_Driver_Airbag
• 21 Wang J, Warnecke JM, Haghi M, Deserno TM. Unobtrusive health monitoring in private spaces: the smart vehicle. Sensors (Basel) 2020; 20 (09) 2442
• 22 Haghi M, Thurow K, Stoll R. Wearable devices in medical internet of things: scientific research and commercially available devices. Healthc Inform Res 2017; 23 (01) 4-15
• 23 Haghi M, Stoll R, Thurow K. Pervasive and personalized ambient parameters monitoring: a wearable, modular, and configurable watch. IEEE Access 2019; 7: 20126-20143
• 24 Ebben RH, Vloet LC, Verhofstad MH, Meijer S, Mintjes-de Groot JA, van Achterberg T. Adherence to guidelines and protocols in the prehospital and emergency care setting: a systematic review. Scand J Trauma Resusc Emerg Med 2013; 21 (01) 9
• 25 Porter A, Badshah A, Black S. et al. Electronic health records in ambulances: the ERA multiple-methods study. Health Serv Deliv Res 2020; 8 (10) 1-140
• 26 Roberts K, Allison KP, Porter KM. A review of emergency equipment carried and procedures performed by UK front line paramedics. Resuscitation 2003; 58 (02) 153-158
• 27 Christ M, Grossmann F, Winter D, Bingisser R, Platz E. Modern triage in the emergency department. Dtsch Aerztebl Int Published online December 17, 2010 DOI: 10.3238/arztebl.2010.0892.
• 28 Healthcare Information and Management Systems Society. HIMSS Dictionary of Health Information Technology Terms, Acronyms, and Organizations. 4th ed;. 2017
• 29 Knuth DE, Morris Jr JH, Pratt VR. Fast pattern matching in strings. SIAM J Comput 1977; 6 (02) 323-350
• 30 Health Level 7. FHIR Specification v.4.0.1. Published October 31, 2019. Accessed June 24, 2020 at: http://hl7.org/fhir/
• 31 Mildenberger P, Eichelberg M, Martin E. Introduction to the DICOM standard. Eur Radiol 2002; 12 (04) 920-927
• 32 Health Level 7. Messaging Standard Version 2.8.2. Published September 4, 2015. Accessed June 23, 2020 at: https://www.hl7.org/implement/standards/product_brief.cfm?product_id=403
• 33 Benson T, Grieve G. Principles of Health Interoperability: SNOMED CT, HL7 and FHIR. 3rd ed.. Springer; 2016
• 34 DICOM Standards Committee. DICOM PS3.1 2020b - Introduction and Overview. Published 2020. Accessed June 23, 2020 https://www.dicomstandard.org/
• 35 Thompson K, Ritchie DM. Unix Programmer's Manual. Published November 3, 1971. Accessed June 19, 2020 at: https://www.bell-labs.com/usr/dmr/www/1stEdman.html
• 36 RFC 822: Standard for the Format of ARPA Internet Text Messages. Published August 1982. Accessed 2020 at: https://tools.ietf.org/html/rfc822
• 37 ISO/TC 154. ISO 8601–1:2019 Date and time — Representations for information interchange — Part 1: basic rules. Accessed February 2019 at: https://www.iso.org/standard/70907.html
• 38 Resnick P. RFC 2822: internet message format. Published April 2001. Accessed June 19, 2020 at: https://tools.ietf.org/html/rfc2822
• 39 Klyne G, Newman C. RFC 3339: date and time on the internet: timestamps. Published July 2002. Accessed June 19, 2020 at: https://tools.ietf.org/html/rfc3339
• 40 Resnick P. RFC 5322: Internet Message Format. Published October 2008. Accessed June 19, 2020 at: https://tools.ietf.org/html/rfc5322
• 41 Open Location Code. An open source standard for addresses, independent of building numbers and street names. Published April 21, 2019. Accessed June 22, 2020 at: https://github.com/google/open-location-code/blob/master/docs/olc_definition.adoc
• 42 John P. Snyder. Map projections: a working manual. 1987 . Accessed 2020 at: https://pubs.er.usgs.gov/publication/pp1395
• 43 ISO/TC 211. ISO 19160–4:2017: Addressing –Part 4: International postal address components and template language. Published November 2017. Accessed July 30, 2020 at: https://www.iso.org/standard/64242.html
• 44 Office of Geomatics. Website. Published June 22, 2020. Accessed June 22, 2020 at: https://earth-info.nga.mil/GandG/coordsys/grids/utm.html
• 45 ISO/IEC JTC 1/SC 6. ISO 6709:2008: Standard representation of geographic point location by coordinates. Published July 2008. Accessed June 22, 2020 at: https://www.iso.org/standard/39242.html
• 46 Defense Mapping Agency. Technical Manual 8358.1. Published September 1990. Accessed June 22, 2020 at: https://earth-info.nga.mil/GandG/publications/tm8358.1/tr83581a.html
• 47 Greelen P. Mapcode: A Public Location Reference Standard. Published 2015. Accessed June 22, 2020 at: https://www.mapcode.com/documentation
• 48 Veness C. Geohash Website. Published June 22, 2020. Accessed June 22, 2020 at: https://www.movable-type.co.uk/scripts/geohash.html
• 49 Mayrhofer A, Spanring C. RFC 5870: A Uniform Resource Identifier for Geographic Locations (“geo” URI). Published June 2010. Accessed July 25, 2020 at: https://tools.ietf.org/html/rfc5870
• 50 ISO/TC 10/SC 8. ISO 4157–1:1998: Construction drawings — Designation systems — Part 1: Buildings and parts of buildings. Published December 1998. Accessed June 22, 2020 at: https://www.iso.org/standard/26189.html
• 51 ISO/TC 22. ISO 3779:2009: Road vehicles — Vehicle identification number (VIN) — Content and structure. Published October 2009. Accessed June 20, 2020 at: https://www.iso.org/standard/70907.html
• 52 Postel J. RFC 791: DARPA internet program protocol specification. Published October 1981. Accessed June 20, 2020 at: https://tools.ietf.org/html/rfc791
• 53 International Telecomunication Union. E.212: The international identification plan for public networks and subscriptions. Published September 2016. Accessed June 22, 2020 at: https://www.itu.int/rec/T-REC-E.212
• 54 ISO/IEC JTC 1/SC 6. ISO/IEC 10039:1991: Information technology — Open Systems Interconnection — Local area networks — Medium Access Control (MAC) service definition. Published May 1991. Accessed June 19, 2020 at: https://www.iso.org/standard/18004.html
• 55 Hinden R, Deering S. RFC 4291: Internet Protocol, Version 6 (IPv6) Specification. Published February 2006. Accessed June 22, 2020 at: https://tools.ietf.org/html/rfc4291
• 56 3rd Generation Partnership Project. Technical Specification Group Core Network and Terminals; Numbering, addressing and identification; (Release 16). Published March 2020. Accessed June 22, 2020 at: https://www.3gpp.org/ftp/Specs/archive/23_series/23.003/
• 57 Bluetooth Special Interest Group. Bluetooth Core Specification v.5.2. Published December 31, 2019. Accessed June 22, 2020 at: https://www.bluetooth.com/specifications/bluetooth-core-specification/
• 58 ISO/IEC JTC 1/SC 6. ISO/IEC 9834–8:2014: Information technology — Procedures for the operation of object identifier registration authorities — Part 8: Generation of universally unique identifiers (UUIDs) and their use in object identifiers. Published August 2014. Accessed June 22, 2020 at: https://www.iso.org/standard/62795.html
• 59 Matsumoto M, Nishimura T. Mersenne twister: a 623-dimensionally equidistributed uniform pseudo-random number generator. ACM Trans Model Comput Simul 1998; 8 (01) 3-30 DOI: 10.1145/272991.272995.
• 60 World Health Organization. Classifications ICD-11. Accessed 2020 at: https://www.who.int/classifications/icd/en/
• 61 Andersen B, Kasparick M, Ulrich H. et al. Connecting the clinical IT infrastructure to a service-oriented architecture of medical devices. Biomed Tech (Berl) 2018; 63 (01) 57-68
• 62 Saripalle R, Runyan C, Russell M. Using HL7 FHIR to achieve interoperability in patient health record. J Biomed Inform 2019; 94: 103188
• 63 Le HP, Hackel S, Guenther A, Goldschmidt R, Daoud M, Deserno TM. International Standard Accident Number: a master case index linking accident & emergency with medical data. Stud Health Technol Inform 2019; 258: 120-124
• 64 Bélanger P. Underground landscape: The urbanism and infrastructure of Toronto's downtown pedestrian network. Tunn Undergr Space Technol 2007; 22 (03) 272-292
• 65 Deserno TM, Jakob R. Accident & emergency informatics: terminologies and standards are needed for digital health in the early rescue chain. In: Proceedings of the 14 ^th IEEE International Conference on Application of Information and Communication Technologies. 2020; Accessed 2020 at: http://www.aict.info/2020/info/AICT2020-Conference-Program.pdf

Publication History

Received: 16 October 2020

Accepted: 27 January 2021

Article published online:
12 May 2021