Requirements for the "EHAW" category
| Id |
Requirement |
| 0 |
eHealth/Ageing-well system is composed of one or several devices, including actuators, sensors, and wearables |
| 1 |
eHealth/Ageing-well system is used by actors, that are the patient(s), the caregiver(s), the helpers(s). |
| 2 |
Patients and assisted persons have profiles, including their age category (young, old), and/or pathology, and/or impairment (hearing, visual, handling, deaf), the caregiver(s) and the helper(s) that is (are) following him |
| 3 |
Patients and assisted persons have to be uniquely identifiable. |
| 4 |
eHealth-dedicated sensors and wearables devices are used for monitoring vital parameters, or measurements, of a patient |
| 5 |
Measurements of vital data of patient are recorded according to a measurement process.
By taking the example of an elderly, the measurements that are often recorded and have thus to be modelled are: heartbeat, oxygen saturation, body temperature, urinal leakage, posture and fall.
Other vital data often recorded and that have to be somehow modelled are for example: blood pressure, ECG, arrhythmias, etc. |
| 6 |
eHealth/Ageing-well actuators can be used to act upon a patient’s properties or environment variables |
| 7 |
Functional devices (non-purely eHealth/ageing-well devices) can be used for modelling/detecting daily/nightly activities or behaviours of patients, like for example gyroscopes/accelerometers can detect posture/fall, or beacons can detect indoor positioning, as well as environment interaction tracking (e.g. door opening ; home, city). |
| 8 |
A BAN (Body Area Network) has to be used for collecting/aggregating patient or person parameters. |
| 9 |
A given eHealth device (sensor, wearable, actuator) and a BAN, are usually used for monitoring and control of a given patient or person. |
| 10 |
Patient (or assisted person) has behaviours that should be modelled. Reasoning and/or semantic queries and analytics have to be handled on this data/information for in particular critical situation detection and alert/alarm triggering. |
| 11 |
Patients or assisted persons have postures that have to be in particular modelled in terms of kind (e.g. falling, lying on a bed, sitting on a chair, standing under the shower…) and duration. |
| 12 |
Patient (or assisted person) has daily and nightly activities that should be modelled (e.g. doing the same way or path, leaving a room, getting up or not getting back after a certain amount of time, time and patterns of sleep…). Reasoning and/or semantic queries and analytics have to be handled on this data/information for in particular critical situation detection and alert/alarm triggering. |
| 13 |
Patient (or assisted person) environment, as well as patient environment interactions, should modelled. The following environment information can in particular be modelled: presence and/or motion, door opening, temperature, humidity, luminosity and pressure, smoke presence, temperature, gas, wind, CO2, windows open, Smart Appliances interactions (e.g. fridge), air quality. This also means that cross domain related interaction and semantic interoperability have to be handled. |
| 14 |
For outdoor and mobility scenarios, patients and assisted persons location (i.e. geolocation) have to be modelled. |
| 15 |
A given eHealth device (sensor, wearable, actuator) has to be uniquely identifiable. |
| 16 |
eHealth devices (sensors, wearables and actuators) can be located in the patient body, on the patient body, or around the patient body (i.e. surrounding/near environment) |
| 17 |
If the sensor/wearables is located on the body and for some eHealth/Ageing-well use cases, its body position should be monitored and modelled. |
| 18 |
eHealth devices (sensors, wearables and actuators) have properties, such as operating modes (e.g. for data sending), latency, sensitivity, velocity… Those properties have to be taken into consideration |
| 19 |
eHealth devices (sensors, wearables and actuators) are mainly constraint/embedded devices, with in particular low power and low energy constraints. They therefore have processing and battery resources and capabilities, like e.g. processor load or battery levels |
| 20 |
An eHealth device (sensor, wearable and actuator) has an interface. This interface is mainly used for communication purposes and data/command transfer. |
| 21 |
An eHealth device (sensor, wearable and actuator) may be provided with a geolocation component and therefore may provide its geolocation that should be modelled. |
| 22 |
Sensors or wearables may have control capabilities |
| 23 |
An eHealth device (sensor, wearable and actuator) has constraints, like for examples: validity (e.g. min or max value…), operating conditions (e.g. temperatures, humidity levels…), legal, security… |
| 24 |
The choice of wearables has to be determined based on the patient preferences in terms of comfort and suitability |
| 25 |
Measurements can be handled and analysed as single instant measure. They are in particular characterized by: a unit of measure and a value |
| 26 |
In some eHealth/Ageing Well use cases, measurements sessions are conducted (e.g. ECG measurement session) and samples, or measurement occurrences (consecutive or not), or aggregated values like e.g. time series or vectors have also to be recorded and modelled |
| 27 |
Factors/data related to falls, gait, speed, etc. should be modelled for fall detection purposes. |
| 28 |
Patient, or assisted person, has have daily and nocturnal activities, some of these activities are critical (risky situations) and can trigger alarms.
This also means that reasoning and/or semantic queries and analytics have to be handled on this activities data/information. |
| 29 |
Co-conception with patients/caregivers design also holds for data modelling. |
| 30 |
Privacy, data anonymization and protection issues have to be taken into account during the ontology design. |
| 31 |
Ontology has to be designed using the modularity principle (i.e. decomposable in less-complex sub-ontologies that can be processed separately) for handling both embedded devices and embedded semantic analytic, which also means that the trade-off between data model richness and complexity has to be taken into account during ontology design phase. |
| 32 |
The ontology has to be rich enough to enable semantics analytics, in particular for - local alarms/alerts triggering and management, patient/person guidance and daily life support, caregiver alerting and decision making support – and at any level (device, edge, fog). |
| 33 |
Cross domain and full semantic interoperability have to be handled. This in particular means that a WoT strategy and service level extensions and modelling could be envisioned. |
| 34 |
A database of pathological diseases (e.g. SNOMED International) has to be linked in order to allow better semantic analytics such as detecting early symptoms of cognitive impairment and pathologies (e.g. physical inactivity, lack of personal hygiene, erratic paths, loss of memory) |
| 35 |
A link has to be made between patient’ (or assisted person’) instant and/or continuous monitoring data/information and its Electronic Health Record (HER), at least for those suffering for chronical pathologies. |
| 36 |
What is an ECG device and how it is composed (mereology)? |
| 37 |
What are the elements participating in an ECG recording session? |
| 38 |
What is an ECG lead, what are the types of ECG leads, what type of property an ECG lead measures and what type of measurement an ECG lead can measure? |
| 39 |
What is an ECG sample sequence? |
| 40 |
What is a time series of measurements? |
| 41 |
What is the frequency (rate) measurement of an ECG sample sequence? |
| 42 |
How to represent tri-axial acceleration data from accelerometers of an ECG device? |
| 43 |
How to integrate measurements from multiple sensors (e.g., ECG leads, accelerometer and battery monitor) of an ECG device for near real-time (frequency-based) monitoring? |
