SAREF4EHAW
The objective of SAREF4EHAW is to extend SAREF ontology 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 formalised by investigating EHAW domain related resources, as reported in ETSI TR 103 509, 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.e. - Use case 1 “elderly at home monitoring and support”, - Use case 2 “monitoring and support of healthy lifestyles for citizens”, - Use case 3 “Early Warning System (EWS) and Cardiovascular Accidents detection”. - Fulfil the eHealth Ageing Well related requirements provided in ETSI TR 103 509, mainly the ontological ones that were mostly taken as input for the ontology specification. SAREF4EHAW mainly reuses the following existing ontologies: SAREF, ETSI SmartBAN reference model, SAREF 4 Environment extension, SAREF 4 Wearables extension, SAREF4health ontology which is a very first try to somehow extend SAREF ontology for the health vertical (it has nothing to do with ETSI SAREF4XYZ naming convention). The following figure presents the high level view of SAREF4EHAW ontology. ![SAREF4SYST overview](diagrams/SAREF4EHAW_Model.jpg) 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 behas been fully modelled (Service class and sub-classes depicted in the previous figure). For embedded semantic analytics purposes, SAREF4EHAW shall behas been designed using the modularity principle (see ETSI TR 103 509) 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.
Extension of SAREF for eHealth Ageing Well domain.
SAREF4EHAW: an extension of SAREF for eHealth Ageing Well domain
is described by
A service is described by a service process (how the service works).
presents
A service presents a service profile (what the service does).
supports
A service supports a service grounding (how to access the service).
contains
A Body Area Network or BAN contains one or multiple health devices
follows user
A helper may follow one or multiple users that can in particular be patients.
has activity
A health actor may have one or multiple activities.
has ban application domain
The BAN application domain - healthcare, telemedicine, assisted living, sport training, pervasive computing, safety and emergency... -.
has communication function
A BAN has a communication function that is the type of communication carried out between BAN devices and BAN Hub.
has computing power
A health device type has computing power describing the processing power or capabilities of the device (e.g. processor ID and manufacturer, duty cycle, available flash/RM memory, maximum flash/RAM memory...).
has constraint
Data has constraints (validity, operating, security...).
has contact
A BAN has one or multiple contacts (e.g. the patient or user that is monitored through this BAN, the caregiver that is using this BAN for monitoring purposes).
has data
A function has one or many data, for example a tracking function shall include latitude, longitude and speed data.
has device type
A health device has a device type describing the physical characteristics of the health device.
has hub
A Body Area Network or BAN elects one hub that mainly plays the role of both a data concentrator and a network GW.
has habit
The habits of a user and a patient (as sub-class of user it also inherits habit), e.g. smoking or overeating.
has impairment
The impairment type of a user and a patient (as sub-class of user it also inherits habit), e.g. deaf, hearing, handling, visual, mobility...
has interface
A health device has one or multiple interfaces (Bluetooth, UWB, IEEE 802.15.6, serial interface...).
has location
The location of an eHealth device, i.e. its position against the body (on ¡V body surface ¡V or in the body ¡V implant ¡V) and its physical location (i.e. its postal address and/or its current geolocation geolocation when available).
has measurement
Defines the relationship between data that has measurement.
has mode
Each device type has modes of operations that model its dynamic characteristic varying during its lifetime, e.g. active, parked, sleeping...
has operating constraint
The operating constraints of a health device.
has participant
A measurement session has health actors as participants (caregiver controling the session, patient monitored during the session).
A measurement session has one or multiple health devices as participants (sensor, actuator, wearable).
has patient
A caregiver may have one or multiple patients.
has physical location
Defines the physical location of the patient, i.e. its postal address and/or its geolocation (when available).
has posture
The posture of a user and a patient (as sub-class of user it also inherits habit), e.g. exercising, lying, running, sitting, walking...
has power source
A health device type has power sources, mainly describing energy source and battery related capabilities of the health device (number of power source, source type, rechargeable or not, available power level...).
has responsible party
A BAN that has a responsible party which plays the role of the legal entity responsible for this BAN (e.g. to contact in case of problem). It should be an organization or a person.
has time series measurements
Data has time series measurements, a sequence taken at successive equally spaced points in time.
A relationship defining the set of values (an array) of a certain property, e.g., energy or power
in current mode
Each eHealth device has modes of operations that model its dynamic characteristic varying during its lifetime, e.g. active, parked, sleeping...
is attached to
A health Device is attached to a health actor such as a patient, a user and or a caregiver.
unit of measurement
Defines the unit of measure of a measurement function.
uses ban
A health actor (e.g. a caregiver, a patient or a helper) uses a BAN for collecting, aggregating and relaying vital parameters.
has frequency measurement
A measurement fucntion, in case of complex measurement like time series, has frequency measurement, i.e. the frequency in which it makes measurements.
activity duration
The duration of an activity, in second.
activity kind
The kind of atcivities that a patient or a user can have, i.e. e.g. sleeping in bed, sitting on a chair, using the shower, etc.
age category
The age group of a health actor, i.e. old or young.
available flash
The available flash memory of a health device. It is a dynamic attribute.
available ram
Indicates the available volatile memory space of a health device. It is a dynamic attribute.
baud
The baud rate of the interface, the number of bits transmitted by second.
data size
The data size represents the size of the data e.g. 20 bits
density
The BAN density, i.e. its number of node.
device type name
The commercial name of a device.
dimension
The dimension of the device i.e. height*weight*length.
date of birth
The date of birth of a health actor.
duty cycle
The duty cycle for each health device embedded processor in order to determine the processing speed.
fault tolerence
Defines the error rate tolerated for a measurement function.
first name
The first name of a health actor.
format
The format is a UDDI for a standard format like integer, memo, etc.
frequency
The frequency is the number of instructions an embedded processor - within a health device - can perform per second.
geolocation
The geolocation, when available, shall be given relatively to the current location - geolocation as standardized ISO 6709 -.
grounding protocol
The grounding protocol is the protocol used to transmit the message of the service, e.g. BLE.
has calculation method
The service process has a calculation method to get the output or result, e.g. the calculation formula to determine the posture of a patient.
has effect
The effect of a service can be an alert, nothing, an activation of another process...
has gender
The gender of a health actor.
has geolocation
The geolocation of the BAN, when available and needed, shall be given relatively to the current location - geolocation as standardized ISO 6709 - of the patient wearing the BAN.
has input
The service process has data input like e.g. the patient ID, the timestamp, the read value from a sensor...
has mbox
An email address (or mail box) of an health actor: a URI with the 'mailto' scheme as defined by RFC 6068.
has output
The output is e.g. the calculated value returned by the process, e.g the posture of a patient.
has precondition
The conditions that are imposed over the inputs of the process and the process must hold to be successufully invoked.
has result
The process can have many results for the same output. Those results may include a message that should be displayed, an alert...
interface address
The interface address. The interface may have many addresses like MAC address, IP address or others.
interface description
The interface type description.
interface protocol
The interface communication protocol can be e.g. BLE, serial, Ethernet...
is derived data
Is derived data is a Boolean property to indicate if the data is a row data or a calculated/derived data from other one.
is gateway
This boolean variable indicates if the interface is a gateway or not.
last name
The familly name of a health actor.
latency
The latency is the time interval between the stimulation and response of a measurement function.
lifetime
The BAN lifetime, e.g. BAN for entertainment purposes should have a lifetime of weeks or few years whereas BAN dedicated for assisted living or anomaly monitoring should last for many years.
manufacturer
The manufacturer name of the embedded processor of a health device, e.g. Intel.
maximum flash
Indicates the maximum flash memory space of a health device.
maximum ram
Indicates the maximum volatile memory space of a health device.
maximum value
The maximum allowable value of a measurement.
minimum value
The minimum allowable value of a measurement.
mode name
The mode name of a device, e.g. sleeping.
phenomena
The BAN monitors a specific phenomenon (burned calories during exercises, glucose level...).
phone
The phone number of a health actor, in international format.
port number
The port number used to offer the service.
postal address
Defines the postal address.
power source type
The type of power source of a health device. It can be solar, battery, electricity...
precision
Precision of a measurement function is the uncertainty of the measured data.
rechargeable
This boolean variable indicates if the power source is rechargeable or not, e.g. a rechargeable battery.
remaining battery level
The level of remaining battery (if any) for a health device. It is a dynamic attribute.
sample time
The sample time of a measurement function.
sending frequency
Defines the sending frequency at an health device level.
serial number
The serial number of a health device.
service description
The service description should describe the offered service like e.g. heart rate measurement.
service name
The service name identify the offered service, e.g heart rate.
topology
The BAN physical topology type, i.e Adhoc or Star or Mesh or Others.
velocity
The velocity of a moving device.
Activity
The activity of a patient/user, i.e. daily and nocturnal activities.
Alarm comand
BAN
Smart Body Area Network (BAN), as defined within ETSI SmartBAN TC (see ETSI TR 103 394).
BAN application domain
The BAN application domain, e.g. healthcare, telemedicine, assisted living, sport training, safety and emergency...
Hub of the BAN, mainly playing the role of both a data concentrator and a network GW.
Body surface location
Defines a helth device location in terms of a body surface position (i.e. on body health device).
Caregiver
For caregivers modelling.
Communication function
The BAN communication function way of working, i.e. periodic, event driven or on request.
Computing power
The computing power capabilities of a Health device.
Constraint
The Data constraints, e.g. validity, operating, security...
Contact
A BAN has one or multiple contacts, i.e some health actors, e.g. the patient or user that is monitored through this BAN, the caregiver that is using this BAN for monitoring purposes...
Daily activity
The patient/user activities that occur during daytime.
Data
Device type
Event driven communication function
BAN communication function way of working of the type event driven.
Functional device
Functional 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.
Defined for users (that can in particular be patients) habits modelling, e.g. smoking, alcohol drinking, overeating, undereating...
Health actor
The eHealth system actors like e.g. caregivers, patients, users, helpers...
Health actuator
Health-related Actuator, equivalent to SAREF Actuator
Health Device
Health Devices, e.g. BAN hub, health sensor/actuator/Wereable.
Health sensor
Health-related Sensor, equivalent to SAREF Sensor
Health wereable
Health-related Wearable, equivalent to SAREF4WEAR Wearable
Helper
Helper of partients/users of a health system, e.g. a patient's relative.
Defined for users (that can in particular be patients) impairments modelling, e.g. deaf impairment, hearing impairement, handling impairment, visual impairement, blindI impairement, mobility impairement...
Implant location
Implant Device (i.e. in body health device) position.
Interface
Used for modelling the interfaces of a health device (e.g. Bluetooth, UWB, IEEE 802.15.6, serial interface...).
Legal constraint
An empty container for describing the legal constraints a data can be submitted to, like e.g. anonymization.
Location
The location, i.e. a position against the body (on - body surface – or in the body – implant –) and a physical location (i.e. a postal address and/or a current geolocation geolocation when available).
Measurement collection session
Task in which a health actor (mainly a patient or a user) is subject of measurement collection (recording) by both some measurement-related health Device (e.g. Sensor, Wereable, ECG Device...) and a health actor (mainly a caregiver).
Measurement function
The functionality necessary to accomplish the measurement task for which a measurement-related health Device (e.g. Sensor, Wereable, ECG Device...) is designed for, e.g. a heart rate measurement function.
Mode
The dynamic characteristics of a eHealth Device that vary during its lifetime or its BAN lifetime.
Nocturnal activity
The class of activities that occur during the night.
On request communication function
BAN communication function way of working of the type on request.
Operating constraint
An empty container for describing the operating constraints of a device, e.g. recommended humidity and temperature range...
Patient
A user of the type patient, i.e. a cared-for person by one or multiple caregivers.
Periodic communication function
BAN communication function way of working of the type periodic.
Physical location
The physical location, i.e. a postal address and a geolocation when available.
Posture
The posture of a health actor (mainly a patient or a user), e.g. exercising, lying, running, sitting, walking...
Power source
The power sources of a health device, mainly describing energy source and battery related capabilities of the health device (number of power source, source type, rechargeable or not...).
Reminder command
Command used for sending reminder notifications to health actors, e.g. pationts, users or Caregivers.
Responsible party
The legal entity responsible for a BAN, i.e. to contact in case of problem
Service grounding
How to access the service.
Service process
How the service works.
Service profile
What the service does.
A sequence of data in a successive equally spaced points in time. The O&M ontology (ISO 19156) defines Time Series Observation as an “observation whose result is a time-series”, while both Hl7 aECG and DICOM standards define the Series element as a sequence of data sharing a common frame of reference. In SAREF4health this concept is termed as Time Series Measurements since this sequence of data refers to time series measured by a health device.
User
A health actor (patient included) that can be equiped with BANs or health devices for monitoring, control, care (specific case of patients) or support purposes.
Validity constraint
Data may have validity constraint such as allowable value range.
Frequency measurement
Represents the measured value made over a frequency property. It is also linked to the frequency unit of measure in which the value is expressed and the timestamp of the measurement.