documentation generated from TS

For the purposes of the present document, the following abbreviations apply:

- aECG: annotated ECG

- API: Application Programming Interface

- BAN : Body Area Network

- DICOM: Digital Imaging and Communications in Medicine

- EC: European Commission : 

- ECG: ElectroCardioGram

- EHAW: eHealth and Ageing Well

- EHR: Electronic Health Record

- ETSI: European Telecommunications Standards Institute

- EWS: Early Warning System

- FDA: Food and Drug Administration

- FHIR: Fast Healthcare Interoperability Resources

- HL7: Health Level Seven International

- IoT: Internet of Things

- JSON-LD: JavaScript Object Notation for Linked Data

- LA: Left Arm

- LL: Left Leg

- LSP: Large Scale Pilot

- MAC: Medium Access Control

- O&M: Observations and Measurements

- OGC: Open Geospatial Consortium

- OWL2 DL: Web Ontology Language (second edition) Description Logics 

- OWL-DL: Web Ontology Language Description Logics

- RA: Right Arm

- RDF: Resource Description Framework

- RL: Right Leg

- SAREF: Smart Applications REFerence ontology

- SAREF4EHAW: SAREF extension for eHealth/Ageing-Well

- SAREF4ENVI: SAREF extension for the environment domain

- SAREF4WEAR: SAREF extension for Wearables domain

- SSN: Semantic Sensor Network 

- STF: Special Task Force

- SWE: Sensor Web Enablement

- TTL: Terse RDF Triple Language (Turtle)

- UFO: Unified Foundational Ontology

- US: United States

- UWB: Ultra-WideBand

- WHO: World Health Organization

- XML: eXtensible Markup Language

* aECG: annotated ECG

* API: Application Programming Interface

* BAN : Body Area Network

* DICOM: Digital Imaging and Communications in Medicine

* EC: European Commission 	

* ECG: ElectroCardioGram

* EHAW: eHealth and Ageing Well

* EHR: Electronic Health Record

* ETSI: European Telecommunications Standards Institute

* EWS: Early Warning System

* FDA: Food and Drug Administration

* FHIR: Fast Healthcare Interoperability Resources

* HL7: Health Level Seven International

* IoT: Internet of Things

* JSON-LD: JavaScript Object Notation for Linked Data

* LA: Left Arm

* LL: Left Leg

* LSP: Large Scale Pilot

* MAC: Medium Access Control

* O&M: Observations and Measurements

* OGC: Open Geospatial Consortium

* OWL2 DL: Web Ontology Language (second edition) Description Logics 

* OWL-DL: Web Ontology Language Description Logics

* RA: Right Arm

* RDF: Resource Description Framework

* RL: Right Leg

* SAREF: Smart Applications REFerence ontology

* SAREF4EHAW: SAREF extension for eHealth/Ageing-Well

* SAREF4ENVI: SAREF extension for the environment domain

* SAREF4WEAR: SAREF extension for Wearables domain

* SSN: Semantic Sensor Network 

* STF: Special Task Force

* SWE: Sensor Web Enablement

* TTL: Terse RDF Triple Language (Turtle)

* UFO: Unified Foundational Ontology

* US: United States

* UWB: Ultra-WideBand

* WHO: World Health Organization

* XML:	eXtensible Markup Language

 No newline at end of file

<div class="alert-warning">NOTE: The text in this section is extracted from ETSI TS 103 410-8 (V2.1.1) <a href="#[0]">[0]</a>, and therefore falls inside the <a href="https://www.etsi.org/intellectual-property-rights">ETSI IPR Policy</a></div>

The objective of SAREF4EHAW is to extend SAREF ontology (see ETSI TS 103 264 [[1]](#[1])) for the eHealth/Ageing-well (EHAW) vertical. Clause 4.1 of [the technical specification ETSI TS 103 410-8](#[0]) 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 ontology and semantics

SAREF4EHAW extension has been specified and formalized by investigating EHAW domain related resources, as reported in ETSI TR 103 509 [[i.7]](#[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.7]), i.e.:

## 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]](#[i.7]), mainly the ontological ones that were mostly taken as input for the ontology specification.

* 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]](#[1])), SmartBAN (see ETSI TS 103 378 [[2]](#[2])), SAREF4ENVI (see ETSI TS 103 410-2 [[3]](#[3])) and SSN (see [[i.1]](#[i.1])). SAREF4EHAW modular ontology will be fully specified and formalized in clause 4.2 of [the technical specification ETSI TS 103 410-8](#[0]). [Figure 1](#Figure_1) presents the high level view of the envisioned model of SAREF4EHAW ontology. In [Figure 1](#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 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.

<figure data-docx-layout="landscape">

    <img data-docx-width="25.2cm" src="diagrams/SAREF4EHAW.Overall.png" alt="High level view of the envisioned semantic model for SAREF4EHAW ontology "/>

    <figcaption id="Figure_1">Figure 1: High level view of the envisioned semantic model for SAREF4EHAW ontology </figcaption>

<figure id="Figure_1">

        <img data-docx-width="25.20cm" src="diagrams/SAREF4EHAW.Overall.png" alt="High level view of the envisioned semantic model for SAREF4EHAW ontology "/>

        <figcaption>Figure 1: High level view of the envisioned semantic model for SAREF4EHAW ontology </figcaption>

    </figure>

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

* EHAW system actors (HealthActor class depicted in [Figure 1](#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](#Figure_1)) may have one or multiple patients. A helper (Helper class depicted in [Figure 1](#Figure_1)) may follow one or multiple users and or patients. As also shown in [Figure 1](#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 as possible States of each actor.

* Health devices (HealthDevice class depicted in [Figure 1](#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](#Figure_1)), Healthdedicated sensors (HealthSensor class depicted in [Figure 1](#Figure_1)), Health-dedicated actuators (HealthActuator class depicted in [Figure 1](#Figure_1)) and Health-dedicated wearables (HealthWearable class depicted in [Figure 1](#Figure_1)). Those health devices have a given function (Function class depicted in [Figure 1](#Figure_1)) aiming to support to accomplish their tasks. Function can act upon features, properties, or states. An instance of [saref:Function](https://saref.etsi.org/core/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](#Figure_1).

* An actuator is used for an actuation process and does action materialized via the Command class as depicted in [Figure 1](#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 technical specification ETSI TS 103 410-8](#[0]) since they are already fully specified and formalized in ETSI TS 103 410-9 [[4]](#[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](#Figure_1)).

* BAN (Ban class depicted in [Figure 1](#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](#Figure_1).

* Observation collection session (ObservationCollectionSession class depicted in [Figure 1](#Figure_1)) that logically has health actors (at least a caregiver and/or a patient/user) as participants (see [Figure 1](#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](#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]](#[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 technical specification ETSI TS 103 410-8](#[0]). The prefixes and namespaces used in SAREF4EHAW and in [the technical specification ETSI TS 103 410-8](#[0]) are listed in [the Namespace Declarations section](#namespacedeclarations).

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.

{{table_1}}

# History of changes

Milestone [https://saref.etsi.org/sources/saref4ehaw/-/milestones/1](https://saref.etsi.org/sources/saref4ehaw/-/milestones/1) lists the 29 issues that have been addressed in version V2.1.1.

The important changes are listed below:

* Updated the modelling of _Measurement_ by using the new _Observation_ pattern of SAREF Core.

* Simplified the modelling of _State_, _Command_, and _Function_ branches by moving concepts to individuals in order to be compliant with the new SAREF patterns.

* Delete the _BanCommunicationType_ concepts and used the SAREF pattern for _Function_.

* Fixed all domain and ranges of ObjectProperties and DataTypeProperties.