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

* BLE: Bluetooth Low Energy

* DICOM: Digital Imaging and Communications in Medicine

* DL: Description Logics

* dob: date of birth

* EC: Eutopean 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

* JSON-LD: JavaScript Object Notation for Linked Data

* LA: Left Arm

* LL: Left Leg

* LSP: Large Scale Pilot

* MAC: Medium Access Control

* MIPS: Mega (Million) Instructions Per Second

* 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

* RAM: Random Access Memory

* RDF: Resource Description Framework

* RDF-S: Resource Description Framework Schema

* 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

* TC: Technical Committee

* TTL: Terse RDF Triple Language (Turtle)

* UFO: Unified Foundational Ontology

* uom: unit of measurement

* URI: Uniform Resource Identifier

* US: United States

* UUID: Universally Unique IDentifier 

* UWB: ultra-wideband

* WHO: World Health Organization

* XML:	eXtensible Markup Language

 No newline at end of file

<!--TS 103 673 v0.3.4 Clause 9.7.1-->

<!--The optional documentation source abstract.html or abstract.md shall contain a short description of the SAREF project version ontology. It shall not include diagrams.-->

<p>The objective of SAREF4EHAW is to extend <a href="https://saref.etsi.org/core/">SAREF ontology</a> for the eHealth/Ageing-well (EHAW) vertical. </p>

 No newline at end of file

# 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".

* Fulfil 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.

<figure id="Figure_1">

        <img data-docx-width="20.49cm" src="diagrams/SAREF4EHAW_Model.jpg" 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>

Within Figure 1, as well as within all the figures that are depicted in clause 4 of the present document, the following conventions are used: 

* arrows are used to represent properties between classes and to represent some RDF, RDF-S and OWL constructs, more precisely:

    * plain arrows with white triangles represent the _rdfs:subClassOf_ relation between two classes. The origin of the arrow is the class to be declared as subclass of the class at the destination of the arrow;

    * dashed arrows between two classes indicate a local restriction in the origin class, i.e. that the object property can be instantiated between the classes in the origin and the destination of the arrow. The identifier of the object property is indicated within the arrow;

    * dashed arrows with no identifier are used to represent the _rdf:type_ relation, indicating that the element in the origin of the arrow is an instance of the class in the destination of the arrow;

* datatype properties are denoted by rectangles attached to the classes, in an UML-oriented way. Dashed boxes represent local restrictions in the class, i.e. datatype properties that can be applied to the class they are attached to;

* individuals are denoted by rectangles in which the identifier is underlined.

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).

* 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, an equivalent class to SAREF Sensor one), Health-dedicated actuators (HealthActuator class depicted in Figure 1, an equivalent class to SAREF Actuator one) and Health-dedicated wearables (HealthWearable class depicted in Figure 1, an equivalent class to SAREF4WEAR Wearable one). Those health devices have a given function (Funtion class depicted in Figure 1) necessary to the accomplishment of the task for which those devices were designed.

* 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 Contact class as depicted in Figure 1.

* A sensor has a measurement function (MeasurementFunction class depicted in Figure 1) and has measurement data (Data class 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.

* Measurement collection session (MeasurementCollectionSession class depicted in Figure 1) that logically has health actors (at least a caregiver and/or a patient/user) as participants (see Figure 1).

* Measurement data (Data class depicted in Figure 1) that logically has measurement. This measurement is measured in a given unit of measure, and is manly of two types: single value (Measurement class depicted in Figure 1), and time series (TimeSeriesMeasurement class depicted in 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}}

<!--TS 103 673 v0.3.4 Clause 9.7.1-->

<!--The optional documentation source acknowledgement.html or acknowledgement.md shall contain a list of acknowledgements. It shall not include diagrams.-->

<!--TS 103 673 v0.3.4 Clause 9.7.1-->

<!--The optional documentation source description.html or description.md shall contain a description of the SAREF project version ontology and how it is intended to be used. It should include diagrams as defined in clause 9.6.2.-->

<p>SAREF4EHAW extension has been specified and formalised by investigating EHAW domain related resources, as reported in ETSI TR 103 509 <a href="#ref-2">[2]</a>, such as: potential stakeholders, standardization initiatives, alliances/associations, European projects, EC directives, existing ontologies, and data repositories. Therefore, SAREF4EHAW modular ontology shall both:</p>

<ul>

  <li>Allow the implementation of a limited set of typical EHAW related use cases already identified in <a href="#ref-2">[2]</a>, i.e.

    <ul>

      <li>Use case 1 “monitoring and support of healthy lifestyles for citizens”,</li>

      <li>Use case 2 “Early Warning System (EWS) and Cardiovascular Accidents detection”.</li>

    </ul>

  </li>

  <li>Fulfil the EHAW related requirements provided in <a href="#ref-2">[2]</a>, mainly the ontological ones that were mostly taken as input for the ontology specification.</li>

</ul>

<p>SAREF4EHAW mainly reuses the following existing ontologies: SAREF (see <a href="#ref-1">[1]</a>), SmartBAN (see <a href="#ref-3">[3]</a>), SAREF4ENVI (see <a href="#ref-4">[4]</a>), SAREF4WEAR (see <a href="#ref-5">[5]</a>) and SAREF4health ontology <a href="#ref-6">[6]</a> which is a very first try to somehow extend SAREF ontology for the health vertical (it has nothing to do with ETSI SAREF4ABCD naming convention). <a href="#Figure1">Figure 1</a> presents the high level view of the envisioned model of SAREF4EHAW ontology. In <a href="#Figure1">Figure 1</a>, classes directly imported from SAREF ontology are in blue and classes specifically developed for SAREF4EHAW are in grey.</p>

<figure id="Figure1">

  <img alt="The SAREF4EHAW Model" src="diagrams/SAREF4EHAW_Model.jpg" style="max-width:100%">

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

</figure>

<p>Within <a href="#Figure1">Figure 1</a>, as well as within all the figures that are depicted in clause 4 of the present document, the following conventions are used: </p>

<ul>

  <li>Arrows are used to represent properties between classes and to represent some RDF, RDF-S and OWL constructs, more precisely:

    <ul>

      <li>Plain arrows with white triangles represent the rdfs:subClassOf relation between two classes. The origin of the arrow is the class to be declared as subclass of the class at the destination of the arrow.</li>

      <li>Dashed arrows between two classes indicate a local restriction in the origin class, i.e. that the object property can be instantiated between the classes in the origin and the destination of the arrow. The identifier of the object property is indicated within the arrow.</li>

      <li>Dashed arrows with no identifier are used to represent the rdf:type relation, indicating that the element in the origin of the arrow is an instance of the class in the destination of the arrow.</li>

    </ul>

  </li>

  <li>Datatype properties are denoted by rectangles attached to the classes, in an UML-oriented way. Dashed boxes represent local restrictions in the class, i.e. datatype properties that can be applied to the class they are attached to,</li>

  <li>Individuals are denoted by rectangles in which the identifier is underlined.</li>

</ul>

<p>SAREF4EHAW is extending SAREF ontology for the EHAW vertical and thus shall logically mainly model the following concepts (i.e. classes within <a href="#Figure1">Figure 1</a>):</p>

<ul>

  <li>EHAW system actors (HealthActor class depicted in <a href="#Figure1">Figure 1</a>) 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 <a href="#Figure1">Figure 1</a>) may have one or multiple patients. A helper (Helper class depicted in <a href="#Figure1">Figure 1</a>) may follow one or multiple users and or patients. As also shown in <a href="#Figure1">Figure 1</a>, users and patients may have habits (e.g. smoking or overeating), impairments (e.g. visual or mobility), and postures (e.g. sitting or running).</li>

  <li>Health devices (HealthDevice class depicted in <a href="#Figure1">Figure 1</a>) that are main components of an eHealth system and are mainly BAN hubs (i.e. Body Area Networks dedicated hubs, BanHub class depicted in <a href="#Figure1">Figure 1</a>), Health-dedicated sensors (HealthSensor class depicted in <a href="#Figure1">Figure 1</a>, an equivalent class to SAREF Sensor one), Health-dedicated  actuators (HealthActuator class depicted in <a href="#Figure1">Figure 1</a>, an equivalent class to SAREF Actuator one) and Health-dedicated wearables (HealthWearable class depicted in <a href="#Figure1">Figure 1</a>, an equivalent class to SAREF4WEAR Wearable one). Those health devices have a given function (Funtion class depicted in <a href="#Figure1">Figure 1</a>) necessary to the accomplishment of the task for which those devices were designed,</li>

  <li>An 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 Contact class as depicted in <a href="#Figure1">Figure 1</a>,</li>

  <li>a sensor has a measurement function (MeasurementFunction class depicted in <a href="#Figure1">Figure 1</a>) and has measurement data (Data class depicted in <a href="#Figure1">Figure 1</a>),</li>

  <li>an actuator is used for an actuation process and does action materialised via the Command class as depicted in <a href="#Figure1">Figure 1</a>,</li>

  <li>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 formalised in ETSI TS 103 410-9. However, they shall also be modelled as possible health-dedicated devices (i.e. sub-class of HealthDevice, as depicted in <a href="#Figure1">Figure 1</a>),</li>

  <li>BAN (Ban class depicted in <a href="#Figure1">Figure 1</a>) 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 <a href="#Figure1">Figure 1</a>,</li>

  <li>Measurement collection session (MeasurementCollectionSession class depicted in <a href="#Figure1">Figure 1</a>) that logically involve some health devices and health actors (at least a caregiver and/or a patient/user) as depicted in <a href="#Figure1">Figure 1</a>,</li>

  <li>Measurement data (Data class depicted in <a href="#Figure1">Figure 1</a>) that logically has measurement. This measurement is measured in a given unit of measure, and is manly of two types: single value (Measurement class depicted in <a href="#Figure1">Figure 1</a>), and time series (TimeSeriesMeasurement class depicted in <a href="#Figure1">Figure 1</a>).</li>

</ul>

<p>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 <a href="#Figure1">Figure 1</a>).</p>

<p>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 <a href="#ref-2">[2]</a>) and can thus be mainly described by the following self-contained knowledge sub-ontologies (or modules): HealthActor, Ban, HealthDevice, Function (measured data related concepts included) and Service. </p>

<!-- + add description of each of the four sub ontologies ?-->

 No newline at end of file