Overview
Following the paradigm of informational separation of powers, identifying data and (medical or technical) analysis data must be managed by independent organizational entities. The A&EI Center is the trustworthy third-party responsible for ISAN management. An additional data trustee forwards the data to be productively used in the data consumer systems. The data trustees bridge between data sources and consumers. The resulting system architecture is composed of a data source layer (EDR, EMS, and EHR) and a data processing and usage layer. To request ISAN generation or lookup, the sources communicate with the ISAN Web Service. All IDs are secured by a trustee who manages the secured data exchange. The data consumer is provided with a virtual registry. Three types of data sources that typically use proprietary local IDs in order to reference their captured events or (treatment) cases are considered:
- Event Data Recorder (EDR): These systems (e.g. smart home, smart car, smart wearable) are capturing data on A&E events at the time of occurrence or emergence. They create an event ID.
- Emergency Medical Services (EMS): In the prehospital domain, a deployment ID is usually linked to rescue data, initial findings, diagnoses, etc.
- Electronic Health Records (EHR): There is a wide variety of medical data that is stored in a hospital information system (HIS), e.g. in the emergency department information system (EDIS) or the laboratory and radiology information system (LIS, RIS).
These are usually assigned to a patient encounter that is referenced through a case ID in the patient data management system (PDMS).
However, this architecture is flexible and can be changed, modified, improved and further extended according to the aim and requirements of the project.
Currently, the team is developing the approach for an efficient solution of data linkage among different resources and working toward ISAN generation.
ISAN structure
The ISAN acts as a master case index for accidents, emergencies, and other time-critical medical events. To that extend, it provides a unique alphanumeric identifier which allows to link data from hospital’s electronic health record (EHR), emergency medical services (EMS), and the growing field of event data recorders (EDR) in the Internet of Things (IoT), e.g. smart homes or smart vehicles.
The ISAN is mainly intended for machine to machine interaction and processing. Therefore, it is devised to be highly interoperable rather than readable by humans. For human evaluation of an ISAN, the information should be transformed into a suitable display format depending on the use-case at hand.
The team of developers address the technical specifications that must be followed to generate a valid ISAN.
The ISAN specification provides a useful methodology for transmitting data of high importance in a reliable way. An ISAN allow for uniquely identifying an event/accident/incident and thereby plays a central role to facilitate data linkage among various medical and non-medical resources. However, in the larger perspective, an ISAN is also considered as a token generated on the occurrence of an emergency and aims for accelerating the rescue operation by providing necessary information using a fast, efficient, and reliable methodology.
To this extend, the content of an ISAN is expected to only include important and informative data that can be generated and transmitted in real-time. Time and location of an event are the components that directly address the concerns of saving a life, by providing the right information in the right time to reduce the delay between event occurrence and dispatching of necessary aid. Furthermore, this data allows to identify relationships between different ISANs, e.g. in larger accidents with multiple parties involved. Moreover, each ISAN needs to includes information which allows to identify its source. Under such structure, linking different ISANs for data analysis at later stages, is feasible. For example, it facilitates the post-processing step by fusing the data from several ISANs generated by the same device.
In order to fulfill these requirements, an ISAN is represented by a unique sequence of characters which is divided in four components: time, horizontal location, vertical location and a unique identifier. Time and location ensure, to some extent, the uniqueness of the ISAN but to guarantee the uniqueness the identifier is used.
The time and location stored in an ISAN describe the circumstances of an event and indicate the importance of the transmitted data. Due to the possible inaccuracy of the measurement of time and location, the potential inaccuracy can be stored in the ISAN as well. The unique identifier is the last component of the ISAN ensuring the uniqueness and consequently the security and reliability of the transmitted data. It is used for identifying the ISAN generator and therefore it is likely fixed and unique in each individual device.
ISAN components
Time
The time stored in an ISAN should represent the time of occurrence of the event and not the time of the ISAN generation. However, there may be an inevitable delay between the occurrence of the event, its detection, and generation of the corresponding ISAN. Moreover, an inaccurate measurement method of the time might be available only. Hence, the potential uncertainty can be defined as well. ISAN support variety of Time formats (extended format of ISO 8601, short and long format of RFC 5322, Unix Time) generated from the EDRs which are part of the system, but we would prefer to directly use the ISO 8601 format. Further information on this format is found at here.
Location
The location stored in an ISAN reflects the horizontal and vertical location of occurrence of the event and not the location of the ISAN generation. As the instantaneous measurement of the location may be inaccurate, it is considered the potential inaccuracy by defining an area rather than an exact point.
The ISAN supports wide range of formats for the location (Subset of S42 standard, Open Location Code (OLC)). However, the ISAN developers would prefer using ISO 6709. Further information on this format is found at here.
Unique identifier
The unique identifier stored in an ISAN is used for identifying the source of the ISAN, i.e. the device that generated it (e.g. smart car, smart home, smart wearable) which can be utilized to link multiple ISANs. Thereby, in contrast to time and location, this value is likely fixed for a single device. The format of the unique identifier depends on the type of devices that generates the ISAN. If a device has no unique identifier, a random number with 10 digits is generated and used instead.
A valid ISAN
The order of the components follows the fixed pattern of time – horizontal location – vertical location – unique identifier. Therefore, an ISAN is generated by concatenating the individual sequences defined for each component. The symbol | is used as a separator between sub-sequences. An example of valid ISAN is given below:
