SAREF4EHAW ontology and semantics

Introduction and overview

The objective of SAREF4EHAW is to extend SAREF ontology (see ETSI TS 103 264 [1]) for the eHealth/Ageing-well (EHAW) vertical. Clause 4.1 of the present document shortly introduces a high level view of the envisioned SAREF4EHAW semantic model and modular ontology, with the retained concepts (i.e. classes) and their relations.

SAREF4EHAW extension has been specified and formalized by investigating EHAW domain related resources, as reported in ETSI TR 103 509 [i.7], such as: potential stakeholders, standardization initiatives, alliances/associations, European projects, EC directives, existing ontologies and data repositories. Therefore, SAREF4EHAW modular ontology shall both:

• Allow the implementation of a limited set of typical EHAW related use cases already identified in ETSI TR 103 509 [i.7], i.e.:
  • use case 1 "monitoring and support of healthy lifestyles for citizens";
  • use case 2 "Early Warning System (EWS) and Cardiovascular Accidents detection".
• Fulfill the EHAW related requirements provided in ETSI TR 103 509 [i.7], mainly the ontological ones that were mostly taken as input for the ontology specification.

SAREF4EHAW mainly reuses the following existing ontologies: SAREF (see ETSI TS 103 264 [1]), SmartBAN (see ETSI TS 103 378 [2]), SAREF4ENVI (see ETSI TS 103 410-2 [3]) and SSN (see [i.1]). SAREF4EHAW modular ontology will be fully specified and formalized in clause 4.2 of the present document. Figure 1 presents the high level view of the envisioned model of SAREF4EHAW ontology. In Figure 1, classes directly imported from SAREF ontology are in yellow, classes directly imported from SAREF4ENVI ontology are in pink and finally classes specifically developed for SAREF4EHAW are in blue.

SAREF4EHAW is extending SAREF ontology for the EHAW vertical and thus shall logically mainly model the following concepts (i.e. classes within Figure 1):

• EHAW system actors (HealthActor class depicted in Figure 1) that are mainly responsibility parties (plays the role of the legal entity responsible for a Body Area Network - BAN -), patients/users, caregivers, helpers. A caregiver (Caregiver class depicted in Figure 1) may have one or multiple patients. A helper (Helper class depicted in Figure 1) may follow one or multiple users and or patients. As also shown in Figure 1, users and patients may have habits (e.g. smoking or overeating), impairments (e.g. visual or mobility), and postures (e.g. sitting or running) modelled a possible States of each actor.
• Health devices (HealthDevice class depicted in Figure 1) that are main components of an eHealth system and are mainly BAN hubs (i.e. Body Area Networks dedicated hubs, BanHub class depicted in Figure 1), Health-dedicated sensors (HealthSensor class depicted in Figure 1), Health-dedicated actuators (HealthActuator class depicted in Figure 1) and Health-dedicated wearables (HealthWearable class depicted in Figure 1). Those health devices have a given function (Function class depicted in Figure 1) aiming to support to accomplish their tasks. Function can act upon features, properties, or states. An instance of saref:Function can apply to different devices.
• A health device could be attached to one or multiples health actors, for example a caregiver that is using this device for a measurement collection session, a patient whose some vital data are measured by this device. This is modelled through the HealthActor class as depicted in Figure 1.
• An actuator is used for an actuation process and does action materialized via the Command class as depicted in Figure 1.
• Wearables, that are smart electronic devices, are also used for monitoring simple/complex vital parameters of patients/users. Wearables are not developed in the present document since they are already fully specified and formalized in ETSI TS 103 410-9 [4]. However, they shall also be listed as possible health-dedicated devices (i.e. through HealthWearable as sub-class of HealthDevice, as depicted in Figure 1).
• BAN (Ban class depicted in Figure 1) that is mainly used for collecting, aggregating and relaying patient or user vital parameters. It shall therefore logically contain BAN-dedicated hubs, health-dedicated sensors, health-dedicated actuators and health-dedicated wearables, as depicted in Figure 1.
• Observation collection session (ObservationCollectionSession class depicted in Figure 1) that logically has health actors (at least a caregiver and/or a patient/user) as participants (see Figure 1).

For semantic interoperability handling purposes, an ontology based solution, combined with sensing-as-a-service and WoT strategies, is retained for SAREF4EHAW. Therefore, an upper level ontology, at service level, shall also be fully modelled (Service class and sub-classes depicted in Figure 1).

Finally, SAREF4EHAW is an OWL-DL ontology. For embedded semantic analytics purposes, SAREF4EHAW shall be designed using the modularity principle (see ETSI TR 103 509 [i.7]) and can thus be mainly described by the following self-contained knowledge modules: HealthActor, Ban, HealthDevice, Function (measured data related concepts included) and Service. All these SAREF4EHAW modules will be fully detailed in clause 4.2 of the present document. The prefixes and namespaces used in SAREF4EHAW and in the present document are listed in Table 1.

SAREF4EHAW

Introduction

As already introduced in clause 4.1 of the present document SAREF4EHAW is an OWL-DL ontology and shall be designed using the modularity principle (see ETSI TR 103 509 [i.7]) and can thus be mainly described by the following self-contained knowledge modules:

• HealthActor module that models eHealth system actors, i.e. caregivers, patients, users, helpers and responsibility parties (see Figure 1). It is fully specified and formalized in clause 4.2.1 of the present document.
• Ban module that models Body Area Networks or BANs (see Figure 1). It is fully specified and formalized in clause 4.2.2 of the present document.
• HealthDevice module that models health devices, e.g. sensors and actuators (see Figure 1). It is fully specified and formalized in clause 4.2.3 of the present document.
• FunctionalDevice module that models functional devices (see Figure 1). Those devices are non-purely eHealth/ageing-well devices that can be used for modelling/detecting activities or behaviours of patients/users, like for example beacons that can detect indoor positioning of a patient in a house. It is fully specified and formalized in clause 4.2.4 of the present document.
• Function module that models observation and actuation functions (via the Command class), as well as observations (see Figure 1). It is fully specified and formalized in clause 4.2.5 of the present document.

HealthActor module

A detailed view of SAREF4EHAW HealthActor module is depicted in Figure 2.

SAREF4EHAW HealthActor module models the eHealth system actors, i.e. responsible parties (the legal entity responsible for a Body Area Network - BAN -), caregivers, patients, users and helpers (see Figure 2). A health actor also uses a BAN for complex monitoring purposes.

Caregiver, Patient, User, Helper and ResponsibleParty are all sub-classes of HealthActor (rdfs:subClassOf relation). Patient and User may have in particular:

• One or multiple activities (Activity class depicted in Figure 2), characterized by a kind (e.g. sleeping in bed, sitting on a chair, using the shower, etc.) and a duration (in second).
• Habits (Habit class depicted in Figure 2), modeled as a State, that should mainly have for value one of the following SAREF4EHAW individuals (non-exhaustive): Smoking, AlcoholDrinking, Overeating, Undereating.
• Postures (Posture individual depicted in Figure 2), modeled as a State, that should mainly have for value one of the following SAREF4EHAW individuals (non-exhaustive): Lying, Sitting, Walking, Exercising, Running.
• Impairments (Impairment class depicted in Figure 2), modeled as a State, that should mainly have for value one of the following SAREF4EHAW individuals (non-exhaustive): AuralImpairement, SkeletalImpairment, OcularImpairement, MobilityImpairment, IntellectualImpairement. Those impairments (non exhaustive) are compatible with the World Health Organization (WHO) classification (see https://apps.who.int/iris/bitstream/handle/10665/41003/9241541261_eng.pdf;jsessionid=6AB8BF561C227503A5B55496EB606C36?sequence=1) [i.11].
• Chronic Disease (ChronicDisease individual depicted in Figure 2; instantiating the SAREF State class_)_ that should mainly be the broader of SAREF4EHAW individuals (non-exhaustive): Diabetes, Asthma.

The object properties defined for SAREF4EHAW HealthActor module are described in Table 2. The data properties defined for SAREF4EHAW HealthActor module are described in Table 3.

Ban module

A detailed view of SAREF4EHAW Ban module is depicted in Figure 3.

A BAN (Ban class depicted in Figure 3) is mainly used for collecting, aggregating and relaying patient or user vital parameters, thus for complex monitoring purposes. It therefore contains health devices, and has a hub (playing both the BAN network gateway and the data concentrator roles) as depicted in Figure 3. A BAN enables the execution of tasks (class Task depicted in Figure 3) modeled as the following SAREF4EHAW individuals: Healthcare, Telemedicine, AssistedLiving, SportTraining, PervasiveComputing, Safety, Emergency.

As shown in Figure 3, a BAN has:

• Responsible party that plays the role of the legal entity responsible for a BAN. ResponsibleParty class, already detailed in clause 4.2.1 of the present document, is thus not detailed again in clause 4.2.3 of the present document.
• BAN communication function (class BANCommunicationFunction depicted in Figure 3) that is either periodic, event driven or on demand, as depicted in Figure 3.

The object properties defined for SAREF4EHAW Ban module are described in Table 4. The data properties defined for SAREF4EHAW Ban module are described in Table 5.

HealthDevice module

A detailed view of SAREF4EHAW HealthDevice module is depicted in Figure 4.

As depicted in Figure 4, an HealthDevice is a sub-class of SAREF Device class (rdfs:subClassOf relation). A HealthDevice has a given function (e.g. a heart rate observation function) and offers services (e.g. a heart rate observation service), both inherited form SAREF Device, and is also attached to a health actor (e.g. a patient and/or a caregiver).

As shown in Figure 4, a health device also has an Interface that models the data transmission and network protocol related interface of the device (e.g. serial or wireless interface, address, transmission rate, etc.). A HealthDevice also has a set of properties, like ComputingPower, characterizing it.

HealthSensor, HealthActuator, HealthWearable and BanHub classes are all sub-classes of HealthDevice class (rdfs:subClassOf relation). HealthSensor and HealthActuator classes are sub-classes of the SAREF Sensor/Actuator ones. They will therefore not be described within clause 4.2.3 of the present document in order to reduce duplication with SAREF documentation (see ETSI TS 103 264 [1] for details). HealthWearable class is a sub-class of to SAREF4WEAR Wearable class. It will therefore not be described within clause 4.2.3 of the present document in order to reduce duplication with SAREF4WEAR documentation (see ETSI TS 103 410-9 [4] for details).

Finally and for reducing duplication with SAREF documentation, the reader is referred to the SAREF specification ETSI TS 103 264 [1] for details about all the classes that are reused from SAREF within Figure 4.

The object properties defined for SAREF4EHAW HealthDevice module are described in Table 6. The data properties defined for SAREF4EHAW HealthDevice module are described in Table 7.

FunctionalDevice module

FunctionalDevice are non-purely eHealth/ageing-well devices that can be used for modelling/detecting activities or behaviours of patients/users, like for example beacons that can detect indoor positioning of a patient in a house.

A functional device is a sub-class of SAREF Device class (rdfs:subClassOf relation) and shall thus have exactly the same object and data properties. Therefore and for reducing duplication with SAREF documentation, It will not be detailed in clause 4.2.5 of the present document and the reader is referred to the SAREF specification (ETSI TS 103 264 [1]).

Function module

A detailed view of SAREF4EHAW Function module is depicted in Figure 5.

SAREF4EHAW Function module models the observation and actuation functions (see Figure 5).

As shown in Figure 5, a function has:

• Command (e.g. an actuation command or a command for getting a body temperature measurement). Alarms (class AlarmCommand) are considered as SAREF commands (rdfs:subClassOf relation) as depicted in Figure 5.
• Data, that has both data constraints (such as validity or legal constraints) and measurement (single or time series measurements) that are measured in a given unit of measure, as depicted in Figure 5 (DataConstraint, Observation and TimeSeriesObservation classes).
• The TimeSeriesObservation is inspired on existing classes from other standards in the health domain (listed in Table 6). This class represents a sequence of data in a successive equally spaced points in time (i.e. with a fixed frequency) measured by a health device, e.g. ECG time series data measured by an ECG device during a recording session.

Figure 5 also shows that a observation function (a sub-class of SAREF Function class, rdfs:subClassOf relation), in case of complex observations such as time series provided by ECG devices (sequences of data in a successive equally spaced points in time), shall have a frequency property that is the frequency in which the measurements are made.

Finally and for reducing duplication with both SAREF and SAREF4ENVI documentation, the reader is referred to the SAREF and SAREF4ENVI specifications (ETSI TS 103 264 [1], ETSI TS 103 410-2 [3]) for details about all the classes that are reused from SAREF within Figure 5.

The object properties defined for SAREF4EHAW Function module are described in Table 7 The data properties defined for SAREF4EHAW Function module are described in Table 8.

Instantiating SAREF4EHAW

Monitoring and support of healthy lifestyles for citizens, in the context of Covid-19

This use case is about a patient of around 50 years old, Bob, with overeating habit. In the context of Covid-19, Bob as a risky patient is thus remotely followed/monitored/controlled by a caregiver, Dr. Knock, for Covid-19 signs detection purposes. Our patient is equipped with a BAN with an android smartphone as the BAN hub, as well as three COVID-19 related devices (wearables, sensors). Bob is equipped with SpireStone wearable device for breathing rate monitoring, a ScanWatch wearable for monitoring the SPO2 level and a TUCKY thermometer for the body temperature monitoring. Thus, using SAREF4EHAW ontology and has depicted in Figure 6:

• Bob is created as a s4ehaw:Patient that uses (s4ehaw:usesBan property) Bob monitoring BAN (a s4ehaw:Ban).
• Bob has a habit (a s4ehaw:Habit) of Overeating (s4ehaw:hasHabit property).
• Dr. Knock is created as a s4ehaw:Caregiver that has Bob as patient (s4ehaw:hasPatient property).
• SpireStone and ScanWatch wearables, as well as TUCKY thermometer, are health devices (s4ehaw:HealthDevice) that are attached to Bob (s4ehaw:isAttachedTo property).

Figure 7 depicts the SpireStone wearable device (a s4ehaw:HealthDevice) of Bob (a s4ehaw:Patient), as described using SAREF4EHAW extension.

As depicted in Figure 7, Bob SpireStone wearable, called BobSpireHealth, consists of three embedded sensors (saref:consistsOf property) that are health devices (s4ehaw:HealthDevice): an accelerometer (BobSpireAccelero), a vibration monitor (BobSpireVbro) and a breath rate sensor (BobSpireBreathSens). In the case presented in clause 4.3.1 of the present document, the Respiration function of this device will only be described as it measures the respiratory rate in bpm which is one of the key COVID-19 indicators to monitor. Figure 8 also shows that the SpireStone wearable (BobSpireHealth) is connected through the Bob monitoring BAN (s4syst:connectedThrough property) and is also attached to Bob (s4ehaw:isAttachedTo property).

Each of BobSpireHealth sensors has a certain function (saref:hasFunction property), as depicted in Figure 8. For example, the BobSpireBreathSens sensor has a respiration measurement function (a s4ehaw:MeasurementFunction), called Respiration and described in Figure 8.

Figure 8 shows that Respiration observation function has data (s4ehaw:hasData property), a respiratory rate (a s4ehaw:Data.

Figure 9 depicts the ScanWatch wearable device (a s4ehaw:HealthDevice) of Bob (a s4ehaw:Patient), as described using SAREF4EHAW extension.

As depicted in Figure 9, Bob is using the Withings_ScanWatch wearable (a s4ehaw:HealthDevice) that consists of many embedded sensors (saref:consistsOf property): an altimeter, a combined SPO2/heart rate sensor, and three electrodes for ECG. In the case of COVID-19 prevention, SPO2 level and heart rate can be described. This Scan watch has two functions (saref:hasFunction): an oxymeter measurement and a systolic pressure measurement.

Figure 10 describes the Oxymeter measurement function (a s4ehaw:ObservationFunction): it has data (s4ehaw:hasData property), a SPO2 level (a s4ehaw:Data).

Figure 11 shows the SystolicPressureSens measurement function which has data (s4ehaw:hasData property) the SystolicPressure (a s4ehaw:Data).

Figure 12 describes the third device which is the TUCKY Thermometer (a s4ehaw:HealthDevice) of Bob (a s4ehaw:Patient) called BobBodyThermo. It is a sensor patch which function is to measure accurately the body temperature in degree Celsius.

Figure 13 describes the BodyThermometer observation function (a s4ehaw:ObservationFunction).

As depicted in Figure 13, the BodyThermometer observation function has data (s4ehaw:hasData property).

Figure 14 describes BobMonitorBan, the BAN (a s4ehaw:Ban) that Bob (a s4ehaw:Patient) uses (s4ehaw:usesBan property) for vital parameters monitoring purposes.`

Since Bob is using three s4ehaw:HealthDevice, these health devices should be part of Bob's BAN. Therefore and as shown in Figure 14, BobMonitorBan connects (s4syst:connectsSystem property) the tree aforementioned health devices: BobSpireHealth, BobScanWatch, and BobBodyThermometer (all s4ehaw:HealthDevice). As also shown in Figure 14, BobMonitorBan has a hub (s4ehaw:hasHub property), which plays the role of the data aggregator/collector and gateway of the BAN. This hub (a s4ehaw:BanHub) is called BobAndroidPhone (see Figure 14).

This scenario supports a set of rules, as described below.

As general rule, the doctor who is monitoring a patient should be inferred as using the ban used by this patient.

As COVID-19 early detection rules, the first scenario consists of early detection of suspected COVID-19 symptoms. When the body temperature rises above 37,5 degrees Celsius and the breathing rate exceeds 22 breaths/min a warning is sent to the BAN hub, in our case s4ehawInst:BobAndroidPhone.

The second scenario consists of another, more severe symptom of COVID-19. When the breathing rate rises above 22 breaths/min, the ambient SPO2 level is below 90 %, and the systolic pressure < 90 % an immediate alert is sent for hospitalisation of the patient.

In these two cases, if the caregiver/doctor confirms that this user has COVID-19, the user is automatically inferred as patient that has (s4ehaw:hasChronicDisease property) COVID-19 disease (a s4ehaw:ChronicDisease).

The third scenario focuses on detecting the users that met a COVID-19 patient. It is done by monitoring the distance maintained between Bob (or any patient) and any nearby COVID-19 patient. Thus, the distance between two nearby patients (s4ehaw:Patient) is computed using the geolocation property (s4ehaw:hasPhysicalLocation property) of these patients. Whenever this computed distance is below 1 meter, and if one of nearby patients is infected with COVID-19, an alarm is sent to the Ban Hub indicating that there is a high risk of COVID-19. The distance is computed using the latitude and longitude of the geolocation properties (s4ehaw:hasPhysicalLocation property) of patients (s4ehaw:Patient) with Haversine formula as follows:

• R = radius of earth, 6 371 km
• A = Sin² (Δlat/2) + Cos (lat1).Cos (lat2).Sin² (Δlong/2), angle in rad
• C = 2.atan2(√A, √(1−A))
• D = R.C × 1 000 is the distance in meters between the two patients (s4ehaw:Patient)

Early Warning System (EWS) for Cardiovascular Accidents

This example describes how a cardiovascular Early Warning System (EWS) instantiates SAREF4EHAW. In this use case, the EWS collects data from an e-Health solution that allows monitoring the ECG data of a person (the patient) using the device. The chosen ECG solution for this example includes the Shimmer3 ECG, which is an ECG unit (device), a mobile application responsible for receiving high-frequency data (e.g. 256 Hz) via Bluetooth from the ECG device and sending the aggregated data to a service deployed in a cloud vendor. Therefore, the mobile app aggregates the ECG data and sends the aggregated data to an cloud IoT Hub (a publish/subscribe cloud gateway), allowing a service in the cloud to detect and warn possible emergency situations with the patient based on ECG time series and acceleration data.

An ECG Device registers the Heart Electrical Activity through electrodes attached to different places of the body, under the assumption that the heart is beating inside the body of a living person. Two electrodes enable an ECG lead to be measured, which is an electrical vector characterized by the depolarization of the heart resulted by the electrical signal between the atria and the ventricles. Manufacturers commonly characterize an ECG device by its number of ECG leads. An ECG device is composed by extremity electrodes, which are attached close to the Left Arm (LA), Right Arm (RA), Left Leg (LL) and the Right Leg (RL); and the chest (precordial), varying from one to six units (V1-6). By convention, lead I measures the electrical activity from the electrodes RA to LA, lead II measures of the electrical activity from RA to LL, lead III measures the electrical activity from LA to LL. The rule lead I + lead III = lead II makes it possible to derive a lead based on the other two. Lead I, Lead II and Lead III are known as Bipolar Limb. Unipolar leads measure the electrical activity from the Wilson's central terminal (negative pole) to each of the chest electrodes (positive poles). For example, the Shimmer3 ECG is a four-lead ECG device wired with four extremity electrodes and one chest electrode, enabling the measurement of three bipolar and one unipolar lead.

Figure 15 illustrates the composition of the ECG device (a s4ehaw:HealthDevice) of this example. The ECG device ECG_unit_T9JRN42 is an s4ehaw:HealthDevice that is composed of 4 leads (ECGLead_I_, ECGLead_II_, ECGLead_III_ and ECGLead_Vx_RL) and three accelerometer sensors (X, Y and Z). The acceleration data can be used by the EWS to detect collisions (e.g. car accidents) and correlate with the ECG data for detecting heart damages. The ECG device plays the role of a recorder in the complex event (action) of a s4ehaw:ObservationCollectionSession (the ECG recording session s4ehawInst:RecordingECGSession_01). In SAREF, this complex action can be classified as a saref:Task that an ECG device saref:accomplishes.

The frequency of an ECG device can be set through an API, which becomes the frequency of each ECG Sample Sequence measured during a recording session (a s4ehaw:ObservationCollectionSession).

The term s4ehaw:TimeSeriesObservation refers to a time series of a sequence of measurements made by a device, in line with the terminology often used in the measurement science (metrology). This term can be applied to several types of measurements, such as ECG time series. As illustrated in Figure 16, the ECGseries_Example002 is a s4ehaw:TimeSeriesObservation that is measured in ElectricPotential units (an array) and relates to the HeartElectricalActivity property. s4ehaw:TimeSeriesObservation is classified as saref:Observation in SAREF for two reasons:

The saref:hasValue property limits the value domain of a Observation to exactly one number. The s4ehaw:hasValues property was added to overcome this issue, in which a s4ehaw:TimeSeriesObservation can instantiate this property multiple times as an ordered (depending on the serialization format) array of numbers. The size of this array should reflect the frequency of the time series measurement and, if not, it shows a possible issue on missing measurements in the Bluetooth communication between the ECG device and the mobile application.

Discussion

In the following, several observations about the SAREF4EHAW ontology and its usage are mentioned.

The hierarchies and individuals defined for SAREF4EHAW extension in the present document should not be considered as exhaustive. It might be needed to extend the hierarchies and lists of individuals for particular use cases, as well as to specialize some of the defined classes. Furthermore, SAREF4EHAW is a dynamic semantic model that can thus evolve over the time. Therefore, eHealth/Ageing Well domain stakeholders are invited to use and validate SAREF4EHAW extension, as well as to give feedback on it and to collaborate with SAREF experts so that amendments and improvements can be incorporated in future releases of the present document.

Regarding s4ehaw:TimeSeriesObservation and its values property (s4ehaw:hasValues), it shall be highlighted that this approach has a formalization issue regarding the ordering of the values. Although the RDF language syntax provides the rdf:Seq element for ordered lists, ordering of triples may be an issue for OWL2 DL reasoners. Some serialization formats dealing with this issue, e.g. RDF/XML and JSON-LD (via @list), was taken into account. Particularly, JSON-LD is recommended for the serialization since it addresses some data exchange needs of modern e-Health solutions that rely on IoT technologies, such as dealing with the verbosity issue of messages. Verbosity relies on message size (payload), which is one of the most common non-functional requirement affecting performance and costs of IoT solutions. JSON-LD is one of the most recommended type of serialization for "semantic IoT" solutions and the other types of serializations (e.g. XML and TTL) are more verbose for ordered data.

Finally, a last attention point is related to the possibility that this extension will overlap with existing key initiatives and standards partially related to eHealth/Ageing Well, in particular:

• SAREF4WEAR, extension of SAREF for the Wearable domain. During STF 566 phase of specification and design of SAREF extensions, special attention was drawn to avoid overlapping in particular between SAREF4EHAW and SAREF4WEAR. However, further alignments may be required.
• HL7 Fast Healthcare Interoperability Resources (FHIR^®) [i.3]. FHIR^® is intended for providing reasoning and decision making supports about healthcare processes and clinical systems, which means that it is more at the organizational level while SAREF4EHAW ontology is more at the engineering level (i.e. one layer below FHIR^®). In that sense, SAREF4EHAW ontology is rather complementary with FHIR^®. However, further mapping and alignments may be required and could also be investigated.
• HL7 annotated ECG (aECG) [i.5] standard is a medical record data format for storing and retrieving electrocardiogram (ECG), chosen by the US Food and Drug Administration (FDA) for clinical trials, implemented as a lexicon approach, i.e. using XML schemas, running nowadays in several hospital information systems.
• Digital Imaging and Communications in Medicine (DICOM^®) [i.6] is the international standard to transmit, store, retrieve, print, process, and display medical imaging information. It is one of the most used standards in e-Health solutions, being a lexicon approach that makes medical imaging information interoperable.
• OGC Observations and Measurements (O&M) [i.4] is one of the core standards in the OGC Sensor Web Enablement (SWE) suite standard and defines a conceptual schema encoding for observations, and for features involved in sampling when making observations, adhering to ISO 19156 [i.4]. The model is derived from generic patterns and is not limited to spatial information.
• Unified Foundational Ontology ECG (UFO ECG) [i.2] is a well-founded ECG ontology designed through an ontological analysis of existing health standards based on the ontology-driven conceptual modelling approach with the Unified Foundational Ontology. The main goal of UFO ECG is to serve as a reference "unified Electronic Health Record (EHR) model", providing mappings to the most common standards that support the representation of ECG data.
• ACTIVAGE Data Model. ACTIVAGE LSP (see http://www.activageproject.eu) is a European Large Scale Pilot (9 deployment sites in seven European countries) on Smart Living Environments that in particular specified and designed a dedicated data model for such environments. Therefore, it might be required to investigate possible alignments and/or mappings between SAREF4EHAW ontology and ACTIVAGE Data Model. Contact has already been established between ACTIVAGE LSP representatives and SAREF4EHAW ontology designers for that purpose.

References

Normative references

• [0] ETSI TS 103 410-8 (V2.1.1): "SmartM2M;; Extension to SAREF; Part 8: eHealth/Ageing-well Domain".
• [1] ETSI TS 103 264: "SmartM2M; Smart Applications; Reference Ontology and oneM2M Mapping".
• [2] ETSI TS 103 378 (V1.1.1) (2015-12): "Smart Body Area Networks (SmartBAN) Unified data representation formats, semantic and open data model".
• [3] ETSI TS 103 410-2 (V1.1.2) (2020-05): "SmartM2M; Extension to SAREF; Part 2: Environment Domain".
• [4] ETSI TS 103 410-9 (V1.1.1) (2020-07): "SmartM2M; Extension to SAREF; Part 9: Wearables Domain".

Informative references

• [i.1] W3C^® Recommendation 19 October 2017:"Semantic sensor network ontology", OGC^® and W3C^® Spatial Data on the Web working Group.
• [i.2] B. Gonçalves, G. Guizzardi, J. G.Pereira Filho: "Using an ECG reference ontology for semantic interoperability of ECG data", Journal of Biomedical Informatics, vol. 44, issue 1, pp. 126-136, February 2011.
• [i.3] HL7 FHIR^®: "Fast Healthcare Interoperability Resources".

• [i.4] S. Cox: "Observations and measurements-xml implementation" OGC document, 2011 (also published as ISO/DIS 19156).
• [i.5] HL7 annotated ECG (aECG) R1 and R2 (US realm): "Implementation Guide: Annotated ECG (aECG) R1, Release 2 - US Realm".
• [i.6] Digital Imaging and Communications in Medicine (DICOM^®) international standard.

• [i.7] ETSI TR 103 509: "SmartM2M; SAREF extension investigation; Requirements for eHealth/Ageing-well".
• [i.8] Void.
• [i.9] Void.
• [i.10] IEEE 802.15.6™: "IEEE Standard for Local and metropolitan area networks - Part 15.6: Wireless Body Area Networks".
• [i.11] World Health Organization: "International Classification of Impairments, Disabilities, and Handicaps".

Acknowledgements

The editors would like to thank the ETSI SmartM2M technical committee for providing guidance and expertise.

Also, many thanks to the ETSI staff and all other current and former active Participants of the ETSI SmartM2M group for their support, technical input and suggestions that led to improvements to this ontology.

Also, special thanks goes to the ETSI SmartM2M Technical Officer Guillemin Patrick for his help.