SIST ES 202 642 V1.1.1:2011
(Main)Human Factors (HF) - Personalization of eHealth systems by using eHealth user profiles (eHealth)
Human Factors (HF) - Personalization of eHealth systems by using eHealth user profiles (eHealth)
To provide means to achieve the goal of the new ICT era where eHealth systems can be personalized by the users in order to meet the individual users' requirements and needs, in various situations.
Človeški dejavniki (HF) - Personalizacija sistemov e-zdravje z uporabo uporabniških profilov e-zdravje
Zagotavlja sredstvo za doseganje cilja v novem obdobju IKT, v katerem uporabniki lahko personalizirajo sisteme e-zdravja, da ustrezajo zahtevam in potrebam posameznega uporabnika v različnih situacijah.
General Information
Standards Content (Sample)
Final draft ETSI ES 202 642 V1.1.1 (2010-07)
ETSI Standard
Human Factors (HF);
Personalization of eHealth systems
by using eHealth user profiles (eHealth)
2 Final draft ETSI ES 202 642 V1.1.1 (2010-07)
Reference
DES/HF-00108
Keywords
health, HF, interface, MMI, user
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE
Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16
Siret N° 348 623 562 00017 - NAF 742 C
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° 7803/88
Important notice
Individual copies of the present document can be downloaded from:
http://www.etsi.org
The present document may be made available in more than one electronic version or in print. In any case of existing or
perceived difference in contents between such versions, the reference version is the Portable Document Format (PDF).
In case of dispute, the reference shall be the printing on ETSI printers of the PDF version kept on a specific network drive
within ETSI Secretariat.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at
http://portal.etsi.org/tb/status/status.asp
If you find errors in the present document, please send your comment to one of the following services:
http://portal.etsi.org/chaircor/ETSI_support.asp
Copyright Notification
No part may be reproduced except as authorized by written permission.
The copyright and the foregoing restriction extend to reproduction in all media.
© European Telecommunications Standards Institute 2010.
All rights reserved.
TM TM TM TM
DECT , PLUGTESTS , UMTS , TIPHON , the TIPHON logo and the ETSI logo are Trade Marks of ETSI registered
for the benefit of its Members.
TM
3GPP is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners.
LTE™ is a Trade Mark of ETSI currently being registered
for the benefit of its Members and of the 3GPP Organizational Partners.
GSM® and the GSM logo are Trade Marks registered and owned by the GSM Association.
ETSI
3 Final draft ETSI ES 202 642 V1.1.1 (2010-07)
Contents
Intellectual Property Rights . 5
Foreword . 5
Introduction . 5
1 Scope . 7
2 References . 7
2.1 Normative references . 7
2.2 Informative references . 8
3 Definitions and abbreviations . 8
3.1 Definitions . 8
3.2 Abbreviations . 9
4 Overview of the personalization and profile concept . 10
4.1 Introduction . 10
4.2 What is a profile? . 10
4.3 Organization of the profile content . 11
4.4 Profile extensions . 12
4.4.1 Proprietary profile extensions . 12
4.4.2 Additional standardized information and preferences . 12
4.5 Templates . 12
4.6 Profiles and user views . 12
4.6.1 Situations, context and the scope object . 12
4.6.2 Avoiding conflicts by using templates . 13
4.7 Context information . 14
4.8 Generic profile architecture . 15
5 Model . 16
5.1 General user profile model . 16
5.2 Extensions to the model . 18
5.2.1 Introduction. 18
5.2.2 Services and device . 18
5.2.3 Reference to alternative definitions and classifications . 19
5.2.4 Further extensions to Profile-Item-Attributes class . 20
6 Stakeholders and their healthcare roles . 20
6.1 Stakeholders . 20
7 Profile management information and preferences . 22
7.1 Addressable entities and group . 22
7.2 Profile related information and preferences . 23
7.2.1 Priority levels . 23
7.3 Requirements for information sharing and privacy . 24
7.3.1 Privacy of information held in electronic health records . 24
7.3.2 Privacy of information stored in a user profile . 24
7.3.3 Information acquisition and sharing . 24
7.3.4 Validation of profile data items . 25
7.3.5 Accreditation of profile read/write access . 25
7.4 Sources . 25
7.5 Roles . 26
7.5.1 Profile system roles . 26
7.5.2 eHealth related roles and sharing of profile data . 27
8 Client related information . 29
8.1 Introduction . 29
8.2 Personal information . 29
8.3 Health information . 32
ETSI
4 Final draft ETSI ES 202 642 V1.1.1 (2010-07)
9 Situation and context related information . 34
9.1 Introduction . 34
9.2 Highlevel health condition . 34
9.3 Place types and locations . 35
9.4 Mood and activity . 35
10 Service and device category related information and preferences . 36
10.1 Introduction . 36
10.2 Video preferences . 37
10.3 Numeric output . 37
10.3.1 Notifications and alerts . 38
10.4 Usability and accessibility . 38
Annex A (informative): Profile content specification . 39
A.1 Structure of profile items . 39
A.2 Description . 39
A.3 UID . 39
A.4 Reference to standards. 39
A.5 Instances . 39
A.6 Type . 40
A.7 Value range . 40
A.8 Default value . 40
A.9 Technical specification . 40
A.10 Related field . 40
Annex B (informative): Background . 41
B.1 eHealth and telecare . 41
B.2 eHealth standardization . 42
Annex C (informative): Scenarios . 45
C.1 Bert going to the bookies. 45
C.2 Sally has early onset of dementia . 47
History . 49
ETSI
5 Final draft ETSI ES 202 642 V1.1.1 (2010-07)
Intellectual Property Rights
IPRs essential or potentially essential to the present document may have been declared to ETSI. The information
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web
server (http://webapp.etsi.org/IPR/home.asp).
Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web
server) which are, or may be, or may become, essential to the present document.
Foreword
This ETSI Standard (ES) has been produced by ETSI Technical Committee Human Factors (HF), and is now submitted
for the ETSI standards Membership Approval Procedure.
Intended readers of the present document are:
• eHealth service providers;
• device manufacturers;
• software developers;
• researchers.
Introduction
Adapting an eHealth system to the individual user is essential for making it safe and easy to deploy and to use as an
effective support to independent living. Personalization can thus enhance the user's trust in the eHealth systems, and
make them more readily accepted. Personalization can range from simply setting an alarm volume according to the
user's hearing abilities and the ambient noise level, to the complex tailoring of the user's entire environment, including
the eHealth services and devices.
The present document specifies a standard for personalization of eHealth systems. The personalization is achieved by
maintaining and updating the user profile, consisting of a set of user related information, preferences and rules. The user
profile depends on and is dynamically adapted to the user's context, preferences, physical and mental abilities, and other
relevant parameters. The profile can then be used by eHealth systems to ensure an uniform user experience. The
standard builds on the personalization and user profile concept described in EG 202 325 [i.1]. The generic
personalization architectural framework is described in TS 102 747 [2] and the preferences for a wide range of services
and devices (not particularly related to eHealth) are described in ES 202 746 [1].
The Design for All approach has been adopted in the present document. It means that accessibility is considered as
something that can benefit people whether or not they have disabilities.
The URI root is upm-ns, identified by xmlns:upm-ns=http://uri.etsi.org/upm. The additional namespace which is health
specific (xmlns:health-ns in the list below) has been specified in the present document. The other additional namespaces
listed below are common with those listed in ES 202 746 [1].
ETSI
6 Final draft ETSI ES 202 642 V1.1.1 (2010-07)
Additional namespaces are:
• xmlns:profile-management-ns=http://uri.etsi.org/upm/profile-management;
• xmlns:personal-information-ns=http://uri.etsi.org/upm/personal-information;
• xmlns:connectivity-preferences-ns=http://uri.etsi.org/upm/connectivity-preferences;
• xmlns:interaction-preferences-ns=http://uri.etsi.org/upm/interaction- preferences;
• xmlns:notifications-ns=http://uri.etsi.org/upm/interaction-preferences/notifications;
• xmlns:communication-handling-ns=http://uri.etsi.org/upm/communication-handling;
• xmlns:consume-content-ns=http://uri.etsi.org/upm/consume-content;
• xmlns:way-finding-ns=http://uri.etsi.org/upm/way-finding;
• xmlns:health-ns=http://uri.etsi.org/upm/health.
ETSI
7 Final draft ETSI ES 202 642 V1.1.1 (2010-07)
1 Scope
The present document provides a standard relevant to management of user profiles for personalisation of eHealth
systems and services according to users' preferences and needs. Personalization of eHealth systems includes
personalization of the eHealth information and interaction. It specifies standardized elements of profiles including
information and preferences.
Profile aspects within the scope of the present document are:
• those provided for the primary benefit of the end-user;
• those where the end-user has rights to manage the profile contents;
• those where the end-user has the right to have a dialogue with the information owning stakeholder.
2 References
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
reference document (including any amendments) applies.
Referenced documents which are not found to be publicly available in the expected location might be found at
http://docbox.etsi.org/Reference.
NOTE: While any hyperlinks included in this clause were valid at the time of publication ETSI cannot guarantee
their long term validity.
2.1 Normative references
The following referenced documents are necessary for the application of the present document.
[1] ETSI ES 202 746: "Human Factors (HF); Personalization and User Profile Management; User
Profile Preferences and Information".
[2] ETSI TS 102 747: "Human Factors (HF); Personalization and User Profile Management;
Architectural Framework".
[3] IETF RFC 4480: "RPID: Rich Presence Extensions to the Presence Information Data Format
(PIDF)".
[4] CLDR: "Unicode Common Locale Data Repository", "measurement-unit" supplemental data.
NOTE: See http://cldr.unicode.org/.
[5] ISO 80000-1:2009: "Quantities and units - Part 1: General".
[6] vCard: The Electronic Business Card, Version 2.1.
NOTE: See: http://www.imc.org/pdi/vcard-21.txt.
[7] ETSI TS 102 334 (all parts): "Network Address Book on fixed network".
[8] XML Schema Part 2: Datatypes Second Edition (October 2004).
NOTE: See http://www.w3.org/TR/xmlschema-2/.
ETSI
8 Final draft ETSI ES 202 642 V1.1.1 (2010-07)
2.2 Informative references
The following referenced documents are not necessary for the application of the present document but they assist the
user with regard to a particular subject area.
[i.1] ETSI EG 202 325: "Human Factors (HF); User Profile Management".
[i.2] ETSI EG 202 421: "Human Factors (HF); Multicultural and language aspects of multimedia
communications".
[i.3] ETSI SR 002 564 (V2.0.0): "Applicability of existing ETSI and ETSI/3GPP deliverables to
eHealth".
[i.4] eHealth Ministerial Declaration: "The Contribution of ICT to Health. Ministerial Conference and
Exhibition"; Brussels, 22-23 May 2003.
NOTE: Available at:
http://ec.europa.eu/information_society/eeurope/ehealth/conference/2003/doc/min_dec_22_may_03.pdf.
[i.5] WHO: "International Classification of Diseases (ICD)".
NOTE: Available at: www.who.int.
[i.6] WHO: "International Classification of Functioning, Disability and Health (ICF)".
[i.7] WHO: "International Classification of Health Interventions (ICHI)".
[i.8] WHO: "Guidelines on the use of International Nonproprietary Names (INNs) for Pharmaceutical
Substances".
[i.9] Oh H, Rizo C, Enkin M, Jadad A: What Is eHealth (3): "A Systematic Review of Published
Definitions", J Med Internet Res 2005;7(1):e1.
NOTE: See http://www.jmir.org/2005/1/e1/.
[i.10] Eysenbach G. "What is e-health?" J Med Internet Res 2001 Jun 18;3(2):e20.
NOTE: See http://www.jmir.org/2001/2/e20/.
[i.11] Mitchell J. "From telehealth to e-health: The unstoppable rise of e-health", Canberra, Australia:
Commonwealth Department of Communications, Information Technology and the Arts
(DOCITA); 1999.
[i.12] "Integrating Community Equipment Services (ICES)" (January 2005): "Telecare".
[i.13] Doughty, K., Cameron, K. and Garner, P. (1996): "Three generations of telecare of the elderly"
Journal of Telemedicine and Telecare 2(2): 71-80.
[i.14] ISO 215: "Documentation - Presentation of contributions to periodicals and other serials".
3 Definitions and abbreviations
3.1 Definitions
For the purposes of the present document, the following terms and definitions apply:
accessibility: ensuring that all sectors of the community have equal access to communications and online information
administrator: person who defines profiles with profile data
NOTE: Also known as profile administrator.
ETSI
9 Final draft ETSI ES 202 642 V1.1.1 (2010-07)
carer: individual who provides health or social care to the client
NOTE: Both professional and informal carers are included in this category.
client: individual receiving the eHealth service, to support independent living and/or using eHealth services for the care
of his or her own health and wellbeing
eHealth service provider: provider of eHealth services to a group of people
formal carers: professional providing care for the client
health/care professionals: professionals (e.g. clinicians, doctors, occupational therapists, social workers) involved in
the assessment of clients and delivery of more specialist care than that provided by carers
informal carers: relatives, neighbours, friends or volunteers providing care for the client
profile: set of user related information, preferences, rules and settings which affects the way in which a user
experiences terminals, devices and services
NOTE: The use of the word profile in the present document implies user profile unless otherwise stated.
profile provider: entity (e.g. company such as a service provider, organisation such as a special interest or affinity
organization) that provide profiles and associated services
rule: statement that can be interpreted by the profile system to produce or limit an action
state: aspect of users and their devices and services
template: set of rules and settings provided by an entity as a starting point for the user for the creation of their profiles
usability: extent to which a product can be used by specific users to achieve specific goals with effectiveness,
efficiency and satisfaction in a specified context of use
user: person using ICT services
user profile: See profile.
3.2 Abbreviations
For the purposes of the present document, the following abbreviations apply:
ACR-NEMA American College of Radiology - National Electrical Manufacturers Association
ADL Activities of Daily Living
CEN Comité Européen de Normalization
COPD Chronic Obstructive Pulmonary Disease
DICOM Digital Imaging and Communications in Medicine
EAACI European Academy of Allergy and Clinical Immunology
EHR Electronic Health Record
FIC Family of International Classifications
HL7 Health Level 7
ICHI International Classification of Health Interventions
ICT Information and Communications Technology
IDR Informatics for the Disabled and Rehabilitation
IFIP International Federation for Information Processing
IHE Integrating the Healthcare Enterprise
NLU Natural Language Understanding
NPS Nomenclature for allergy Position Statement
PCI Primary Care Informatics
PHR Personal Health Record
PPD Personal Portable Devices
SDO Standards Developing Organization
SFC Scottish Funding Council
UPM User Profile Management
WAO World Allergy Organization
ETSI
10 Final draft ETSI ES 202 642 V1.1.1 (2010-07)
WG Working Group
WHO World Health Organization
4 Overview of the personalization and profile concept
4.1 Introduction
For the convenience of the reader, this clause provides an brief overview of the personalization and user profile concept
as described in more detail in EG 202 325 [i.1]. Further information can also be found in ES 202 746 [1] which
provides standardized user profile preferences and information. The personalization and user profile Architectural
Framework is described in [2] (not restricted to eHealth personalization). The present document concentrates on the
eHealth aspects of the user profile. From now on in the present document, the term "profile" will be used with the
meaning "user profile".
4.2 What is a profile?
A profile contains details of the user and their personal requirements in a form that can be used by a system to deliver
the required behaviours. When users wish to have the behaviour of devices or services personalized to their
requirements, a profile will be required for:
• storing information, preferences and rules;
• making the information and preferences available to services/devices and when relevant also to other people.
Users require the data to be stored in a secure manner with user agreed levels of privacy applied to the availability and
distribution of that data.
In the present document, the profile is often referred as if it is a single functional entity. However, parts of this profile
may be distributed amongst a number of storage locations that include the user's services and devices. There may also
be copies of profile data stored in devices or services and in a centralized location. Wherever the data is stored, the
profile system will ensure that the data is synchronized when relevant. When new devices are acquired, factory set
information and preferences may be updated by information and preferences copied from equivalent data that is already
in the user's profile.
Major factors of the profile concept described in the present document, that distinguish them from profiles described in
many other sources, are:
• the primary purpose of the profiles are to offer benefits to users;
• profiles contain information that allows users to configure services and devices to meet their individual needs;
• most of the data in the profile is considered to be owned by the user;
• the user can view all of the information in their profile in a form that is designed to be easy to understand;
• much of the information in the profile is intended to be applicable to a wide range of services and devices that
are associated with the user;
• the user is usually able to modify most of the information in the profile (examples of exceptions when
someone cannot modify information in the profile is when a child who might not be allowed to change most of
the data, as their parents might have decided to configure the profile for them or clients who ask a carer to
update the profile on their behalf).
ETSI
11 Final draft ETSI ES 202 642 V1.1.1 (2010-07)
4.3 Organization of the profile content
In general, a profile contains [1]:
• Information: data about or related to the user (e.g. name, address).
• Preferences: choices made by the user about a given parameter that will define or modify the system
behaviour. More complex preferences can be expressed in the form of rules (see below).
NOTE: When something is considered essential to the user, it would be more appropriate if a preference is
instead called a "need" (e.g. a blind user sets the modality to "sound"). However, for simplification, in the
present document the word "preference" is used.
• Rules: statements that can be automatically interpreted in order to define or modify the system behaviour.
These rules may:
- express complex preferences;
- activate or de-activate situation profiles.
More specifically, the profile is organized into several blocks. The major organisational units of the profile are:
• Personal information: data about or related to the user (e.g. name, address, location).
• Human centred preferences: These are the overall preferences that might apply across the user's usage of a
wide variety of different devices and services.
As these preferences are not mapped precisely to specific features of services and devices, they may be
presented in ways that must be interpreted before they can be used as the definition for a precise setting for a
service or device feature.
• Service/device category related information and preferences: The information and preferences in this clause
are related to service categories (e.g. Communications services), further sub-categories of the service category
(e.g. Realtime communication), and specific services/devices.
Information and preferences need to be associated with a scope, which includes:
• (groups of) services;
• (groups of) devices;
• (groups of) people (e.g. entries in an address book).
• A scope may be very narrow (e.g. one specific service) or very broad (e.g. preferred language for all my
services).
The values of the profile information and preferences in the profile will be either:
• directly set by the user (or by someone else on behalf of the user);
• read from other profile information (e.g. from devices or services);
• set as the result of a rule that is contained in the user's profile.
Further details on the profile content for services and devices in general (not restricted to eHealth services) is described
in ES 202 746 [1] on "User Profile Preferences and Information".
ETSI
12 Final draft ETSI ES 202 642 V1.1.1 (2010-07)
4.4 Profile extensions
4.4.1 Proprietary profile extensions
Because of the limited of standardization of the features of eHealth related services and devices, it is not possible to
define a full set of standardized profile data related to these. However, the profile may still contain information and
preferences related to these as proprietary profile extensions. As stated in ES 202 746 [1], in addition to profile data
items as defined and listed in the present document, it is possible for eHealth service developers and device
manufactures to include proprietary profile data items in the profile which shall be identifiable as proprietary
(e.g. specify the company and/or product identifier for which the proprietary information and preferences are intended
for). Proprietary profile extensions are outside the scope of the present document.
4.4.2 Additional standardized information and preferences
In addition to profile data items as defined and listed in the present document, it is expected that there will be a need for
future additional standardized information and preferences, for which new versions of the present standard may be
developed.
4.5 Templates
Profiles can contain a very large number of settings and preferences which would be difficult to set up unaided. When
users first create profile specifications, the creation task can be greatly simplified if the profile specifications are created
from templates. The template provides a set of rules and settings that act as a starting point for users when creating their
profiles, and these can be further amended by the user to suit their individual needs. Templates can be provided to the
user from a number of different sources. Typically, templates would be used to create a personal default profile
specification. Some templates for creating typical situation profiles would then also be provided. The use of templates
will typically be in combination with a wizard guiding the user while defining their profile.
There may be parameters for which defaults are not appropriate and where the profile system will force the user to set
their own value e.g. where it might result in a potentially dangerous health condition or if it is legally required for the
user to make an explicit decision for themselves. When prompting the user for a value, the profile agent may:
• request explicit user input;
• propose a range of options from which the user will have to chose one;
• propose a value to accept or reject and give the user a mechanism to specify an alternative value if they reject
the proposed value.
Further information and guidelines on templates can be found in clause 9 of EG 202 325 [i.1].
4.6 Profiles and user views
4.6.1 Situations, context and the scope object
Users move between situations throughout the day (e.g. at home, driving, working), and also users may change
depending on their specific health condition. In each of these situations, users may have different needs for how they
would like their ICT resources arranged. Wherever a user wishes to have different behaviour from their ICT it will first
be necessary to identify criteria that uniquely define the situation. These criteria are captured as rules that defines when
a Scope object is active (i.e. when it is isActive method evaluates to TRUE). Hence the user concept of a "situation" is
represented in the profile system by a Scope object.
ETSI
13 Final draft ETSI ES 202 642 V1.1.1 (2010-07)
Clause 5.4.4 in TS 102 747 on "Personalization and User Profile Management: Architectural Framework" [2] shows
very flexible ways in which the profile data is modified according to the context. However, users will be unable to
understand all of the possible implications of the dependency of individual data items on context. For this reason, it is
necessary to introduce the concept of User Views of the profile. Although it is possible to create any number of
specialized views of the profile, two views that have been defined in EG 202 325 [i.1], and which are described to users
as profiles, are the "Normal Profile" and the "Situation Profile". The view that is described as the "Normal Profile"
shows all of the profile data that will be applied when no specific user-defined situation applies. This view can be
achieved by creating a view of the profile that shows the values of profile data when no Scope object other than the
"Normal" Scope object have been activated.
Whereas the "Normal Profile" view shows the values of the items in the profile, it is useful to show the values of profile
data that may need to be set to values relevant to a user-determined situation. There is therefore a need for another view
which corresponds to the user concept "situation". Such a view is described in user terms in EG 202 325 [i.1] as the
"Situation Profile". In this view the user can see the values assigned to profile data items that may need to have a special
value set in that situation. The situation profile view will contain fewer profile data items than the "Normal Profile"
view, as it will contain only those data items which are different in that specific situation (i.e. only profile data items
associated with the Scope object that represents the user's "situation").
Profile providers may also offer other views of the profile to users. For example, users may wish to see all of their
profile as it will be in a particular "situation", not just the standard view that shows those profile data items that are
uniquely configured for the current situation.
Profile users should be allowed to view their profiles making use of these user views and, if they have administrator
rights, should be allowed to modify the profile data that they see in these views. Modifications to profile data in a user
view that shows a "Situation Profile" is a means to allow the modification of the Profile-Item-Attributes associated with
that "situation" (i.e. associated with the Scope object that represents that "situation").
Situation profiles can be activated:
• manually, e.g. the user choosing the relevant situation (Scope object) from a menu;
• automatically, e.g. the system detects that a Scope object has been activated and activates the appropriate
"situation profile";
• combination of automatically and manually, e.g. the system detects that a Scope object has been activated and
asks the user if they want the corresponding situation profile to be activated, and the user accepts.
NOTE: Clause 4.7 describes how many specialised health states, that in many ways are similar to situation
profiles, will not be user selectable in menus and will not be presented to users to accept or reject.
Conflicts may appear when two (or more) Scope objects are simultaneously activated, which would result in an attempt
to set the same profile data to different values. To avoid this, the profile system needs to determine which of these
alternative values shall be applied. Therefore, priorities are assigned to "Situation Profiles" and/or profile data items. In
the profile system, the priorities are attributes of the Scope objects that are associated with "Situation Profiles" and
individual profile data items. If there is an attempt to set two (or more) different values for an item of profile data, then
the value of the profile data that is associated with the Scope object with highest priority is set. The mechanisms for
handling conflicts and dealing with the situation when priorities still do not resolve a conflict are described in more
detail in TS 102 747 [2]. Table 5.3.3 (Scope class) in [1]. gives the specification of the priority attribute of the Scope
object, and defines ranges of priorities to be assigned to different categories of Scope objects (determined by the
scope-category attribute of the Scope object).
Profile provider support should assist users in defining priorities to avoid potential conflicts.
4.6.2 Avoiding conflicts by using templates
Potential conflicts (when two or more Scope objects, are trying to set the same data to different values), may be
resolved by the use of a well designed set of pre-defined templates that assign priorities to preferences in a way that
eliminates conflicts for most probable combinations of situations (Scope objects).
It would be expected that if profile providers assist users to create their profiles by means of a "creation wizard", the
wizard would make use of such a coherent set of templates and would thus create an initial profile setup where conflicts
are eliminated or confined to extremely unlikely combinations of situations.
ETSI
14 Final draft ETSI ES 202 642 V1.1.1 (2010-07)
4.7 Context information
The profile system should be provided with any relevant information that can affect the behaviour of the system. This is
called context information.
Examples of the context information include:
• the status of the services to which the user is subscribed;
• the status of the user's devices;
• the location of the user;
• other presence information;
• network conditions.
Context information will often be addressed in rules. The profile system can request context information or receive
notification of changes, based upon a subscription. The activation of Scope object will be determined by rules involving
context information. TS 102 747 [2] describes a "Context Watcher" application that is responsible for managing the
acquisition of context information from the various sources (e.g. sensors, devices, services). There are two fundamental
options for how this context information may be obtained:
• Polling: where the Context Watcher periodically requests updated context information from the source;
• On update: where the context source sends updated context information to the Context Watcher when a change
has occurred to that context information. The information would normally be sent immediately the change has
occurred at the source, but a degree of latency in sending this information may occur.
The choice about the frequency at which context information is requested from a source is the responsibility of the
profile management system. The choice about when a change of context information is notified to the profile
management system is the responsibility of the device, service or sensor system that is the source of the context
information. In both cases, the ideal aim is to adjust the frequency of context information updating to match the
perceived significance of the context information in terms of its importance and its urgency. Where context information
is used to control profile behaviour in ways that are not very important or very urgent, the profile management system
can be set to poll for this information quite infrequently.
Although frequent polling may place an unnecessary load on the communication channel used to acquire the updates
(which may also have an associated cost), for context information that may be needed to determine states that have a
very important or urgent significance in terms of the control of the profile, frequent polling will be what is required.
Some eHealth situations may be associated with outcomes that will cause discomfort or danger for the user. The health
status of a user may change very frequently and sometimes rapidly, and as a consequence, the associated context
information will therefore need to be polled very frequently to track those changes. Sources that provide context
information to a user profile management system will need to provide context updates more frequently and with less
latency under similar circumstances.
The "situations" that users define, or generic situation profiles that profile providers make available to profile user, will
relate to a situation that has some meaningful significance to the user. Users would normally be aware that they are in a
situation as the core features that define the situation would be very obvious to the user (e.g. the location that they are
in, the services that they are using or the time of day). So most user defined situations will be visible, predictable and
generally slow to change.
In contrast, there may be many instances in the eHealth domain where there is a need for a sudden change to the settings
of profile data to immediately reflect th
...
ETSI Standard
Human Factors (HF);
Personalization of eHealth systems
by using eHealth user profiles (eHealth)
2 ETSI ES 202 642 V1.1.1 (2010-09)
Reference
DES/HF-00108
Keywords
health, HF, interface, MMI, user
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE
Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16
Siret N° 348 623 562 00017 - NAF 742 C
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° 7803/88
Important notice
Individual copies of the present document can be downloaded from:
http://www.etsi.org
The present document may be made available in more than one electronic version or in print. In any case of existing or
perceived difference in contents between such versions, the reference version is the Portable Document Format (PDF).
In case of dispute, the reference shall be the printing on ETSI printers of the PDF version kept on a specific network drive
within ETSI Secretariat.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at
http://portal.etsi.org/tb/status/status.asp
If you find errors in the present document, please send your comment to one of the following services:
http://portal.etsi.org/chaircor/ETSI_support.asp
Copyright Notification
No part may be reproduced except as authorized by written permission.
The copyright and the foregoing restriction extend to reproduction in all media.
© European Telecommunications Standards Institute 2010.
All rights reserved.
TM TM TM TM
DECT , PLUGTESTS , UMTS , TIPHON , the TIPHON logo and the ETSI logo are Trade Marks of ETSI registered
for the benefit of its Members.
TM
3GPP is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners.
LTE™ is a Trade Mark of ETSI currently being registered
for the benefit of its Members and of the 3GPP Organizational Partners.
GSM® and the GSM logo are Trade Marks registered and owned by the GSM Association.
ETSI
3 ETSI ES 202 642 V1.1.1 (2010-09)
Contents
Intellectual Property Rights . 5
Foreword . 5
Introduction . 5
1 Scope . 7
2 References . 7
2.1 Normative references . 7
2.2 Informative references . 8
3 Definitions and abbreviations . 8
3.1 Definitions . 8
3.2 Abbreviations . 9
4 Overview of the personalization and profile concept . 10
4.1 Introduction . 10
4.2 What is a profile? . 10
4.3 Organization of the profile content . 11
4.4 Profile extensions . 12
4.4.1 Proprietary profile extensions . 12
4.4.2 Additional standardized information and preferences . 12
4.5 Templates . 12
4.6 Profiles and user views . 12
4.6.1 Situations, context and the scope object . 12
4.6.2 Avoiding conflicts by using templates . 13
4.7 Context information . 14
4.8 Generic profile architecture . 15
5 Model . 16
5.1 General user profile model . 16
5.2 Extensions to the model . 18
5.2.1 Introduction. 18
5.2.2 Services and device . 18
5.2.3 Reference to alternative definitions and classifications . 19
5.2.4 Further extensions to Profile-Item-Attributes class . 20
6 Stakeholders and their healthcare roles . 20
6.1 Stakeholders . 20
7 Profile management information and preferences . 22
7.1 Addressable entities and group . 22
7.2 Profile related information and preferences . 23
7.2.1 Priority levels . 23
7.3 Requirements for information sharing and privacy . 24
7.3.1 Privacy of information held in electronic health records . 24
7.3.2 Privacy of information stored in a user profile . 24
7.3.3 Information acquisition and sharing . 24
7.3.4 Validation of profile data items . 25
7.3.5 Accreditation of profile read/write access . 25
7.4 Sources . 25
7.5 Roles . 26
7.5.1 Profile system roles . 26
7.5.2 eHealth related roles and sharing of profile data . 27
8 Client related information . 29
8.1 Introduction . 29
8.2 Personal information . 29
8.3 Health information . 32
ETSI
4 ETSI ES 202 642 V1.1.1 (2010-09)
9 Situation and context related information . 34
9.1 Introduction . 34
9.2 Highlevel health condition . 34
9.3 Place types and locations . 35
9.4 Mood and activity . 35
10 Service and device category related information and preferences . 36
10.1 Introduction . 36
10.2 Video preferences . 37
10.3 Numeric output . 37
10.3.1 Notifications and alerts . 38
10.4 Usability and accessibility . 38
Annex A (informative): Profile content specification . 39
A.1 Structure of profile items . 39
A.2 Description . 39
A.3 UID . 39
A.4 Reference to standards. 39
A.5 Instances . 39
A.6 Type . 40
A.7 Value range . 40
A.8 Default value . 40
A.9 Technical specification . 40
A.10 Related field . 40
Annex B (informative): Background . 41
B.1 eHealth and telecare . 41
B.2 eHealth standardization . 42
Annex C (informative): Scenarios . 45
C.1 Bert going to the bookies. 45
C.2 Sally has early onset of dementia . 47
History . 49
ETSI
5 ETSI ES 202 642 V1.1.1 (2010-09)
Intellectual Property Rights
IPRs essential or potentially essential to the present document may have been declared to ETSI. The information
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web
server (http://webapp.etsi.org/IPR/home.asp).
Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web
server) which are, or may be, or may become, essential to the present document.
Foreword
This ETSI Standard (ES) has been produced by ETSI Technical Committee Human Factors (HF).
Intended readers of the present document are:
• eHealth service providers;
• device manufacturers;
• software developers;
• researchers.
Introduction
Adapting an eHealth system to the individual user is essential for making it safe and easy to deploy and to use as an
effective support to independent living. Personalization can thus enhance the user's trust in the eHealth systems, and
make them more readily accepted. Personalization can range from simply setting an alarm volume according to the
user's hearing abilities and the ambient noise level, to the complex tailoring of the user's entire environment, including
the eHealth services and devices.
The present document specifies a standard for personalization of eHealth systems. The personalization is achieved by
maintaining and updating the user profile, consisting of a set of user related information, preferences and rules. The user
profile depends on and is dynamically adapted to the user's context, preferences, physical and mental abilities, and other
relevant parameters. The profile can then be used by eHealth systems to ensure an uniform user experience. The
standard builds on the personalization and user profile concept described in EG 202 325 [i.1]. The generic
personalization architectural framework is described in TS 102 747 [2] and the preferences for a wide range of services
and devices (not particularly related to eHealth) are described in ES 202 746 [1].
The Design for All approach has been adopted in the present document. It means that accessibility is considered as
something that can benefit people whether or not they have disabilities.
The URI root is upm-ns, identified by xmlns:upm-ns=http://uri.etsi.org/upm. The additional namespace which is health
specific (xmlns:health-ns in the list below) has been specified in the present document. The other additional namespaces
listed below are common with those listed in ES 202 746 [1].
ETSI
6 ETSI ES 202 642 V1.1.1 (2010-09)
Additional namespaces are:
• xmlns:profile-management-ns=http://uri.etsi.org/upm/profile-management;
• xmlns:personal-information-ns=http://uri.etsi.org/upm/personal-information;
• xmlns:connectivity-preferences-ns=http://uri.etsi.org/upm/connectivity-preferences;
• xmlns:interaction-preferences-ns=http://uri.etsi.org/upm/interaction- preferences;
• xmlns:notifications-ns=http://uri.etsi.org/upm/interaction-preferences/notifications;
• xmlns:communication-handling-ns=http://uri.etsi.org/upm/communication-handling;
• xmlns:consume-content-ns=http://uri.etsi.org/upm/consume-content;
• xmlns:way-finding-ns=http://uri.etsi.org/upm/way-finding;
• xmlns:health-ns=http://uri.etsi.org/upm/health.
ETSI
7 ETSI ES 202 642 V1.1.1 (2010-09)
1 Scope
The present document provides a standard relevant to management of user profiles for personalisation of eHealth
systems and services according to users' preferences and needs. Personalization of eHealth systems includes
personalization of the eHealth information and interaction. It specifies standardized elements of profiles including
information and preferences.
Profile aspects within the scope of the present document are:
• those provided for the primary benefit of the end-user;
• those where the end-user has rights to manage the profile contents;
• those where the end-user has the right to have a dialogue with the information owning stakeholder.
2 References
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
reference document (including any amendments) applies.
Referenced documents which are not found to be publicly available in the expected location might be found at
http://docbox.etsi.org/Reference.
NOTE: While any hyperlinks included in this clause were valid at the time of publication ETSI cannot guarantee
their long term validity.
2.1 Normative references
The following referenced documents are necessary for the application of the present document.
[1] ETSI ES 202 746: "Human Factors (HF); Personalization and User Profile Management; User
Profile Preferences and Information".
[2] ETSI TS 102 747: "Human Factors (HF); Personalization and User Profile Management;
Architectural Framework".
[3] IETF RFC 4480: "RPID: Rich Presence Extensions to the Presence Information Data Format
(PIDF)".
[4] CLDR: "Unicode Common Locale Data Repository", "measurement-unit" supplemental data.
NOTE: See http://cldr.unicode.org/.
[5] ISO 80000-1:2009: "Quantities and units - Part 1: General".
[6] vCard: The Electronic Business Card, Version 2.1.
NOTE: See: http://www.imc.org/pdi/vcard-21.txt.
[7] ETSI TS 102 334 (all parts): "Network Address Book on fixed network".
[8] XML Schema Part 2: Datatypes Second Edition (October 2004).
NOTE: See http://www.w3.org/TR/xmlschema-2/.
ETSI
8 ETSI ES 202 642 V1.1.1 (2010-09)
2.2 Informative references
The following referenced documents are not necessary for the application of the present document but they assist the
user with regard to a particular subject area.
[i.1] ETSI EG 202 325: "Human Factors (HF); User Profile Management".
[i.2] ETSI EG 202 421: "Human Factors (HF); Multicultural and language aspects of multimedia
communications".
[i.3] ETSI SR 002 564 (V2.0.0): "Applicability of existing ETSI and ETSI/3GPP deliverables to
eHealth".
[i.4] eHealth Ministerial Declaration: "The Contribution of ICT to Health. Ministerial Conference and
Exhibition"; Brussels, 22-23 May 2003.
NOTE: Available at:
http://ec.europa.eu/information_society/eeurope/ehealth/conference/2003/doc/min_dec_22_may_03.pdf.
[i.5] WHO: "International Classification of Diseases (ICD)".
NOTE: Available at: www.who.int.
[i.6] WHO: "International Classification of Functioning, Disability and Health (ICF)".
[i.7] WHO: "International Classification of Health Interventions (ICHI)".
[i.8] WHO: "Guidelines on the use of International Nonproprietary Names (INNs) for Pharmaceutical
Substances".
[i.9] Oh H, Rizo C, Enkin M, Jadad A: What Is eHealth (3): "A Systematic Review of Published
Definitions", J Med Internet Res 2005;7(1):e1.
NOTE: See http://www.jmir.org/2005/1/e1/.
[i.10] Eysenbach G. "What is e-health?" J Med Internet Res 2001 Jun 18;3(2):e20.
NOTE: See http://www.jmir.org/2001/2/e20/.
[i.11] Mitchell J. "From telehealth to e-health: The unstoppable rise of e-health", Canberra, Australia:
Commonwealth Department of Communications, Information Technology and the Arts
(DOCITA); 1999.
[i.12] "Integrating Community Equipment Services (ICES)" (January 2005): "Telecare".
[i.13] Doughty, K., Cameron, K. and Garner, P. (1996): "Three generations of telecare of the elderly"
Journal of Telemedicine and Telecare 2(2): 71-80.
[i.14] ISO 215: "Documentation - Presentation of contributions to periodicals and other serials".
3 Definitions and abbreviations
3.1 Definitions
For the purposes of the present document, the following terms and definitions apply:
accessibility: ensuring that all sectors of the community have equal access to communications and online information
administrator: person who defines profiles with profile data
NOTE: Also known as profile administrator.
ETSI
9 ETSI ES 202 642 V1.1.1 (2010-09)
carer: individual who provides health or social care to the client
NOTE: Both professional and informal carers are included in this category.
client: individual receiving the eHealth service, to support independent living and/or using eHealth services for the care
of his or her own health and wellbeing
eHealth service provider: provider of eHealth services to a group of people
formal carers: professional providing care for the client
health/care professionals: professionals (e.g. clinicians, doctors, occupational therapists, social workers) involved in
the assessment of clients and delivery of more specialist care than that provided by carers
informal carers: relatives, neighbours, friends or volunteers providing care for the client
profile: set of user related information, preferences, rules and settings which affects the way in which a user
experiences terminals, devices and services
NOTE: The use of the word profile in the present document implies user profile unless otherwise stated.
profile provider: entity (e.g. company such as a service provider, organisation such as a special interest or affinity
organization) that provide profiles and associated services
rule: statement that can be interpreted by the profile system to produce or limit an action
state: aspect of users and their devices and services
template: set of rules and settings provided by an entity as a starting point for the user for the creation of their profiles
usability: extent to which a product can be used by specific users to achieve specific goals with effectiveness,
efficiency and satisfaction in a specified context of use
user: person using ICT services
user profile: See profile.
3.2 Abbreviations
For the purposes of the present document, the following abbreviations apply:
ACR-NEMA American College of Radiology - National Electrical Manufacturers Association
ADL Activities of Daily Living
CEN Comité Européen de Normalization
COPD Chronic Obstructive Pulmonary Disease
DICOM Digital Imaging and Communications in Medicine
EAACI European Academy of Allergy and Clinical Immunology
EHR Electronic Health Record
FIC Family of International Classifications
HL7 Health Level 7
ICHI International Classification of Health Interventions
ICT Information and Communications Technology
IDR Informatics for the Disabled and Rehabilitation
IFIP International Federation for Information Processing
IHE Integrating the Healthcare Enterprise
NLU Natural Language Understanding
NPS Nomenclature for allergy Position Statement
PCI Primary Care Informatics
PHR Personal Health Record
PPD Personal Portable Devices
SDO Standards Developing Organization
SFC Scottish Funding Council
UPM User Profile Management
WAO World Allergy Organization
ETSI
10 ETSI ES 202 642 V1.1.1 (2010-09)
WG Working Group
WHO World Health Organization
4 Overview of the personalization and profile concept
4.1 Introduction
For the convenience of the reader, this clause provides an brief overview of the personalization and user profile concept
as described in more detail in EG 202 325 [i.1]. Further information can also be found in ES 202 746 [1] which
provides standardized user profile preferences and information. The personalization and user profile Architectural
Framework is described in [2] (not restricted to eHealth personalization). The present document concentrates on the
eHealth aspects of the user profile. From now on in the present document, the term "profile" will be used with the
meaning "user profile".
4.2 What is a profile?
A profile contains details of the user and their personal requirements in a form that can be used by a system to deliver
the required behaviours. When users wish to have the behaviour of devices or services personalized to their
requirements, a profile will be required for:
• storing information, preferences and rules;
• making the information and preferences available to services/devices and when relevant also to other people.
Users require the data to be stored in a secure manner with user agreed levels of privacy applied to the availability and
distribution of that data.
In the present document, the profile is often referred as if it is a single functional entity. However, parts of this profile
may be distributed amongst a number of storage locations that include the user's services and devices. There may also
be copies of profile data stored in devices or services and in a centralized location. Wherever the data is stored, the
profile system will ensure that the data is synchronized when relevant. When new devices are acquired, factory set
information and preferences may be updated by information and preferences copied from equivalent data that is already
in the user's profile.
Major factors of the profile concept described in the present document, that distinguish them from profiles described in
many other sources, are:
• the primary purpose of the profiles are to offer benefits to users;
• profiles contain information that allows users to configure services and devices to meet their individual needs;
• most of the data in the profile is considered to be owned by the user;
• the user can view all of the information in their profile in a form that is designed to be easy to understand;
• much of the information in the profile is intended to be applicable to a wide range of services and devices that
are associated with the user;
• the user is usually able to modify most of the information in the profile (examples of exceptions when
someone cannot modify information in the profile is when a child who might not be allowed to change most of
the data, as their parents might have decided to configure the profile for them or clients who ask a carer to
update the profile on their behalf).
ETSI
11 ETSI ES 202 642 V1.1.1 (2010-09)
4.3 Organization of the profile content
In general, a profile contains [1]:
• Information: data about or related to the user (e.g. name, address).
• Preferences: choices made by the user about a given parameter that will define or modify the system
behaviour. More complex preferences can be expressed in the form of rules (see below).
NOTE: When something is considered essential to the user, it would be more appropriate if a preference is
instead called a "need" (e.g. a blind user sets the modality to "sound"). However, for simplification, in the
present document the word "preference" is used.
• Rules: statements that can be automatically interpreted in order to define or modify the system behaviour.
These rules may:
- express complex preferences;
- activate or de-activate situation profiles.
More specifically, the profile is organized into several blocks. The major organisational units of the profile are:
• Personal information: data about or related to the user (e.g. name, address, location).
• Human centred preferences: These are the overall preferences that might apply across the user's usage of a
wide variety of different devices and services.
As these preferences are not mapped precisely to specific features of services and devices, they may be
presented in ways that must be interpreted before they can be used as the definition for a precise setting for a
service or device feature.
• Service/device category related information and preferences: The information and preferences in this clause
are related to service categories (e.g. Communications services), further sub-categories of the service category
(e.g. Realtime communication), and specific services/devices.
Information and preferences need to be associated with a scope, which includes:
• (groups of) services;
• (groups of) devices;
• (groups of) people (e.g. entries in an address book).
• A scope may be very narrow (e.g. one specific service) or very broad (e.g. preferred language for all my
services).
The values of the profile information and preferences in the profile will be either:
• directly set by the user (or by someone else on behalf of the user);
• read from other profile information (e.g. from devices or services);
• set as the result of a rule that is contained in the user's profile.
Further details on the profile content for services and devices in general (not restricted to eHealth services) is described
in ES 202 746 [1] on "User Profile Preferences and Information".
ETSI
12 ETSI ES 202 642 V1.1.1 (2010-09)
4.4 Profile extensions
4.4.1 Proprietary profile extensions
Because of the limited of standardization of the features of eHealth related services and devices, it is not possible to
define a full set of standardized profile data related to these. However, the profile may still contain information and
preferences related to these as proprietary profile extensions. As stated in ES 202 746 [1], in addition to profile data
items as defined and listed in the present document, it is possible for eHealth service developers and device
manufactures to include proprietary profile data items in the profile which shall be identifiable as proprietary
(e.g. specify the company and/or product identifier for which the proprietary information and preferences are intended
for). Proprietary profile extensions are outside the scope of the present document.
4.4.2 Additional standardized information and preferences
In addition to profile data items as defined and listed in the present document, it is expected that there will be a need for
future additional standardized information and preferences, for which new versions of the present standard may be
developed.
4.5 Templates
Profiles can contain a very large number of settings and preferences which would be difficult to set up unaided. When
users first create profile specifications, the creation task can be greatly simplified if the profile specifications are created
from templates. The template provides a set of rules and settings that act as a starting point for users when creating their
profiles, and these can be further amended by the user to suit their individual needs. Templates can be provided to the
user from a number of different sources. Typically, templates would be used to create a personal default profile
specification. Some templates for creating typical situation profiles would then also be provided. The use of templates
will typically be in combination with a wizard guiding the user while defining their profile.
There may be parameters for which defaults are not appropriate and where the profile system will force the user to set
their own value e.g. where it might result in a potentially dangerous health condition or if it is legally required for the
user to make an explicit decision for themselves. When prompting the user for a value, the profile agent may:
• request explicit user input;
• propose a range of options from which the user will have to chose one;
• propose a value to accept or reject and give the user a mechanism to specify an alternative value if they reject
the proposed value.
Further information and guidelines on templates can be found in clause 9 of EG 202 325 [i.1].
4.6 Profiles and user views
4.6.1 Situations, context and the scope object
Users move between situations throughout the day (e.g. at home, driving, working), and also users may change
depending on their specific health condition. In each of these situations, users may have different needs for how they
would like their ICT resources arranged. Wherever a user wishes to have different behaviour from their ICT it will first
be necessary to identify criteria that uniquely define the situation. These criteria are captured as rules that defines when
a Scope object is active (i.e. when it is isActive method evaluates to TRUE). Hence the user concept of a "situation" is
represented in the profile system by a Scope object.
ETSI
13 ETSI ES 202 642 V1.1.1 (2010-09)
Clause 5.4.4 in TS 102 747 on "Personalization and User Profile Management: Architectural Framework" [2] shows
very flexible ways in which the profile data is modified according to the context. However, users will be unable to
understand all of the possible implications of the dependency of individual data items on context. For this reason, it is
necessary to introduce the concept of User Views of the profile. Although it is possible to create any number of
specialized views of the profile, two views that have been defined in EG 202 325 [i.1], and which are described to users
as profiles, are the "Normal Profile" and the "Situation Profile". The view that is described as the "Normal Profile"
shows all of the profile data that will be applied when no specific user-defined situation applies. This view can be
achieved by creating a view of the profile that shows the values of profile data when no Scope object other than the
"Normal" Scope object have been activated.
Whereas the "Normal Profile" view shows the values of the items in the profile, it is useful to show the values of profile
data that may need to be set to values relevant to a user-determined situation. There is therefore a need for another view
which corresponds to the user concept "situation". Such a view is described in user terms in EG 202 325 [i.1] as the
"Situation Profile". In this view the user can see the values assigned to profile data items that may need to have a special
value set in that situation. The situation profile view will contain fewer profile data items than the "Normal Profile"
view, as it will contain only those data items which are different in that specific situation (i.e. only profile data items
associated with the Scope object that represents the user's "situation").
Profile providers may also offer other views of the profile to users. For example, users may wish to see all of their
profile as it will be in a particular "situation", not just the standard view that shows those profile data items that are
uniquely configured for the current situation.
Profile users should be allowed to view their profiles making use of these user views and, if they have administrator
rights, should be allowed to modify the profile data that they see in these views. Modifications to profile data in a user
view that shows a "Situation Profile" is a means to allow the modification of the Profile-Item-Attributes associated with
that "situation" (i.e. associated with the Scope object that represents that "situation").
Situation profiles can be activated:
• manually, e.g. the user choosing the relevant situation (Scope object) from a menu;
• automatically, e.g. the system detects that a Scope object has been activated and activates the appropriate
"situation profile";
• combination of automatically and manually, e.g. the system detects that a Scope object has been activated and
asks the user if they want the corresponding situation profile to be activated, and the user accepts.
NOTE: Clause 4.7 describes how many specialised health states, that in many ways are similar to situation
profiles, will not be user selectable in menus and will not be presented to users to accept or reject.
Conflicts may appear when two (or more) Scope objects are simultaneously activated, which would result in an attempt
to set the same profile data to different values. To avoid this, the profile system needs to determine which of these
alternative values shall be applied. Therefore, priorities are assigned to "Situation Profiles" and/or profile data items. In
the profile system, the priorities are attributes of the Scope objects that are associated with "Situation Profiles" and
individual profile data items. If there is an attempt to set two (or more) different values for an item of profile data, then
the value of the profile data that is associated with the Scope object with highest priority is set. The mechanisms for
handling conflicts and dealing with the situation when priorities still do not resolve a conflict are described in more
detail in TS 102 747 [2]. Table 5.3.3 (Scope class) in [1]. gives the specification of the priority attribute of the Scope
object, and defines ranges of priorities to be assigned to different categories of Scope objects (determined by the
scope-category attribute of the Scope object).
Profile provider support should assist users in defining priorities to avoid potential conflicts.
4.6.2 Avoiding conflicts by using templates
Potential conflicts (when two or more Scope objects, are trying to set the same data to different values), may be
resolved by the use of a well designed set of pre-defined templates that assign priorities to preferences in a way that
eliminates conflicts for most probable combinations of situations (Scope objects).
It would be expected that if profile providers assist users to create their profiles by means of a "creation wizard", the
wizard would make use of such a coherent set of templates and would thus create an initial profile setup where conflicts
are eliminated or confined to extremely unlikely combinations of situations.
ETSI
14 ETSI ES 202 642 V1.1.1 (2010-09)
4.7 Context information
The profile system should be provided with any relevant information that can affect the behaviour of the system. This is
called context information.
Examples of the context information include:
• the status of the services to which the user is subscribed;
• the status of the user's devices;
• the location of the user;
• other presence information;
• network conditions.
Context information will often be addressed in rules. The profile system can request context information or receive
notification of changes, based upon a subscription. The activation of Scope object will be determined by rules involving
context information. TS 102 747 [2] describes a "Context Watcher" application that is responsible for managing the
acquisition of context information from the various sources (e.g. sensors, devices, services). There are two fundamental
options for how this context information may be obtained:
• Polling: where the Context Watcher periodically requests updated context information from the source;
• On update: where the context source sends updated context information to the Context Watcher when a change
has occurred to that context information. The information would normally be sent immediately the change has
occurred at the source, but a degree of latency in sending this information may occur.
The choice about the frequency at which context information is requested from a source is the responsibility of the
profile management system. The choice about when a change of context information is notified to the profile
management system is the responsibility of the device, service or sensor system that is the source of the context
information. In both cases, the ideal aim is to adjust the frequency of context information updating to match the
perceived significance of the context information in terms of its importance and its urgency. Where context information
is used to control profile behaviour in ways that are not very important or very urgent, the profile management system
can be set to poll for this information quite infrequently.
Although frequent polling may place an unnecessary load on the communication channel used to acquire the updates
(which may also have an associated cost), for context information that may be needed to determine states that have a
very important or urgent significance in terms of the control of the profile, frequent polling will be what is required.
Some eHealth situations may be associated with outcomes that will cause discomfort or danger for the user. The health
status of a user may change very frequently and sometimes rapidly, and as a consequence, the associated context
information will therefore need to be polled very frequently to track those changes. Sources that provide context
information to a user profile management system will need to provide context updates more frequently and with less
latency under similar circumstances.
The "situations" that users define, or generic situation profiles that profile providers make available to profile user, will
relate to a situation that has some meaningful significance to the user. Users would normally be aware that they are in a
situation as the core features that define the situation would be very obvious to the user (e.g. the location that they are
in, the services that they are using or the time of day). So most user defined situations will be visible, predictable and
generally slow to change.
In contrast, there may be many instances in the eHealth domain where there is a need for a sudden change to the settings
of profile data to immediately reflect the entry into a health state which the user was not able to predict and of which the
user may be totally unaware. For example, in cases where body-worn sensors detect that one of the user's physiological
measures has exceeded a th
...
SLOVENSKI STANDARD
01-junij-2011
ýORYHãNLGHMDYQLNL +) 3HUVRQDOL]DFLMDVLVWHPRYH]GUDYMH]XSRUDER
XSRUDEQLãNLKSURILORYH]GUDYMH
Human Factors (HF) - Personalization of eHealth systems by using eHealth user profiles
(eHealth)
Ta slovenski standard je istoveten z: ES 202 642 Version 1.1.1
ICS:
35.240.80 Uporabniške rešitve IT v IT applications in health care
zdravstveni tehniki technology
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.
ETSI Standard
Human Factors (HF);
Personalization of eHealth systems
by using eHealth user profiles (eHealth)
2 ETSI ES 202 642 V1.1.1 (2010-09)
Reference
DES/HF-00108
Keywords
health, HF, interface, MMI, user
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE
Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16
Siret N° 348 623 562 00017 - NAF 742 C
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° 7803/88
Important notice
Individual copies of the present document can be downloaded from:
http://www.etsi.org
The present document may be made available in more than one electronic version or in print. In any case of existing or
perceived difference in contents between such versions, the reference version is the Portable Document Format (PDF).
In case of dispute, the reference shall be the printing on ETSI printers of the PDF version kept on a specific network drive
within ETSI Secretariat.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at
http://portal.etsi.org/tb/status/status.asp
If you find errors in the present document, please send your comment to one of the following services:
http://portal.etsi.org/chaircor/ETSI_support.asp
Copyright Notification
No part may be reproduced except as authorized by written permission.
The copyright and the foregoing restriction extend to reproduction in all media.
© European Telecommunications Standards Institute 2010.
All rights reserved.
TM TM TM TM
DECT , PLUGTESTS , UMTS , TIPHON , the TIPHON logo and the ETSI logo are Trade Marks of ETSI registered
for the benefit of its Members.
TM
3GPP is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners.
LTE™ is a Trade Mark of ETSI currently being registered
for the benefit of its Members and of the 3GPP Organizational Partners.
GSM® and the GSM logo are Trade Marks registered and owned by the GSM Association.
ETSI
3 ETSI ES 202 642 V1.1.1 (2010-09)
Contents
Intellectual Property Rights . 5
Foreword . 5
Introduction . 5
1 Scope . 7
2 References . 7
2.1 Normative references . 7
2.2 Informative references . 8
3 Definitions and abbreviations . 8
3.1 Definitions . 8
3.2 Abbreviations . 9
4 Overview of the personalization and profile concept . 10
4.1 Introduction . 10
4.2 What is a profile? . 10
4.3 Organization of the profile content . 11
4.4 Profile extensions . 12
4.4.1 Proprietary profile extensions . 12
4.4.2 Additional standardized information and preferences . 12
4.5 Templates . 12
4.6 Profiles and user views . 12
4.6.1 Situations, context and the scope object . 12
4.6.2 Avoiding conflicts by using templates . 13
4.7 Context information . 14
4.8 Generic profile architecture . 15
5 Model . 16
5.1 General user profile model . 16
5.2 Extensions to the model . 18
5.2.1 Introduction. 18
5.2.2 Services and device . 18
5.2.3 Reference to alternative definitions and classifications . 19
5.2.4 Further extensions to Profile-Item-Attributes class . 20
6 Stakeholders and their healthcare roles . 20
6.1 Stakeholders . 20
7 Profile management information and preferences . 22
7.1 Addressable entities and group . 22
7.2 Profile related information and preferences . 23
7.2.1 Priority levels . 23
7.3 Requirements for information sharing and privacy . 24
7.3.1 Privacy of information held in electronic health records . 24
7.3.2 Privacy of information stored in a user profile . 24
7.3.3 Information acquisition and sharing . 24
7.3.4 Validation of profile data items . 25
7.3.5 Accreditation of profile read/write access . 25
7.4 Sources . 25
7.5 Roles . 26
7.5.1 Profile system roles . 26
7.5.2 eHealth related roles and sharing of profile data . 27
8 Client related information . 29
8.1 Introduction . 29
8.2 Personal information . 29
8.3 Health information . 32
ETSI
4 ETSI ES 202 642 V1.1.1 (2010-09)
9 Situation and context related information . 34
9.1 Introduction . 34
9.2 Highlevel health condition . 34
9.3 Place types and locations . 35
9.4 Mood and activity . 35
10 Service and device category related information and preferences . 36
10.1 Introduction . 36
10.2 Video preferences . 37
10.3 Numeric output . 37
10.3.1 Notifications and alerts . 38
10.4 Usability and accessibility . 38
Annex A (informative): Profile content specification . 39
A.1 Structure of profile items . 39
A.2 Description . 39
A.3 UID . 39
A.4 Reference to standards. 39
A.5 Instances . 39
A.6 Type . 40
A.7 Value range . 40
A.8 Default value . 40
A.9 Technical specification . 40
A.10 Related field . 40
Annex B (informative): Background . 41
B.1 eHealth and telecare . 41
B.2 eHealth standardization . 42
Annex C (informative): Scenarios . 45
C.1 Bert going to the bookies. 45
C.2 Sally has early onset of dementia . 47
History . 49
ETSI
5 ETSI ES 202 642 V1.1.1 (2010-09)
Intellectual Property Rights
IPRs essential or potentially essential to the present document may have been declared to ETSI. The information
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web
server (http://webapp.etsi.org/IPR/home.asp).
Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web
server) which are, or may be, or may become, essential to the present document.
Foreword
This ETSI Standard (ES) has been produced by ETSI Technical Committee Human Factors (HF).
Intended readers of the present document are:
• eHealth service providers;
• device manufacturers;
• software developers;
• researchers.
Introduction
Adapting an eHealth system to the individual user is essential for making it safe and easy to deploy and to use as an
effective support to independent living. Personalization can thus enhance the user's trust in the eHealth systems, and
make them more readily accepted. Personalization can range from simply setting an alarm volume according to the
user's hearing abilities and the ambient noise level, to the complex tailoring of the user's entire environment, including
the eHealth services and devices.
The present document specifies a standard for personalization of eHealth systems. The personalization is achieved by
maintaining and updating the user profile, consisting of a set of user related information, preferences and rules. The user
profile depends on and is dynamically adapted to the user's context, preferences, physical and mental abilities, and other
relevant parameters. The profile can then be used by eHealth systems to ensure an uniform user experience. The
standard builds on the personalization and user profile concept described in EG 202 325 [i.1]. The generic
personalization architectural framework is described in TS 102 747 [2] and the preferences for a wide range of services
and devices (not particularly related to eHealth) are described in ES 202 746 [1].
The Design for All approach has been adopted in the present document. It means that accessibility is considered as
something that can benefit people whether or not they have disabilities.
The URI root is upm-ns, identified by xmlns:upm-ns=http://uri.etsi.org/upm. The additional namespace which is health
specific (xmlns:health-ns in the list below) has been specified in the present document. The other additional namespaces
listed below are common with those listed in ES 202 746 [1].
ETSI
6 ETSI ES 202 642 V1.1.1 (2010-09)
Additional namespaces are:
• xmlns:profile-management-ns=http://uri.etsi.org/upm/profile-management;
• xmlns:personal-information-ns=http://uri.etsi.org/upm/personal-information;
• xmlns:connectivity-preferences-ns=http://uri.etsi.org/upm/connectivity-preferences;
• xmlns:interaction-preferences-ns=http://uri.etsi.org/upm/interaction- preferences;
• xmlns:notifications-ns=http://uri.etsi.org/upm/interaction-preferences/notifications;
• xmlns:communication-handling-ns=http://uri.etsi.org/upm/communication-handling;
• xmlns:consume-content-ns=http://uri.etsi.org/upm/consume-content;
• xmlns:way-finding-ns=http://uri.etsi.org/upm/way-finding;
• xmlns:health-ns=http://uri.etsi.org/upm/health.
ETSI
7 ETSI ES 202 642 V1.1.1 (2010-09)
1 Scope
The present document provides a standard relevant to management of user profiles for personalisation of eHealth
systems and services according to users' preferences and needs. Personalization of eHealth systems includes
personalization of the eHealth information and interaction. It specifies standardized elements of profiles including
information and preferences.
Profile aspects within the scope of the present document are:
• those provided for the primary benefit of the end-user;
• those where the end-user has rights to manage the profile contents;
• those where the end-user has the right to have a dialogue with the information owning stakeholder.
2 References
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
reference document (including any amendments) applies.
Referenced documents which are not found to be publicly available in the expected location might be found at
http://docbox.etsi.org/Reference.
NOTE: While any hyperlinks included in this clause were valid at the time of publication ETSI cannot guarantee
their long term validity.
2.1 Normative references
The following referenced documents are necessary for the application of the present document.
[1] ETSI ES 202 746: "Human Factors (HF); Personalization and User Profile Management; User
Profile Preferences and Information".
[2] ETSI TS 102 747: "Human Factors (HF); Personalization and User Profile Management;
Architectural Framework".
[3] IETF RFC 4480: "RPID: Rich Presence Extensions to the Presence Information Data Format
(PIDF)".
[4] CLDR: "Unicode Common Locale Data Repository", "measurement-unit" supplemental data.
NOTE: See http://cldr.unicode.org/.
[5] ISO 80000-1:2009: "Quantities and units - Part 1: General".
[6] vCard: The Electronic Business Card, Version 2.1.
NOTE: See: http://www.imc.org/pdi/vcard-21.txt.
[7] ETSI TS 102 334 (all parts): "Network Address Book on fixed network".
[8] XML Schema Part 2: Datatypes Second Edition (October 2004).
NOTE: See http://www.w3.org/TR/xmlschema-2/.
ETSI
8 ETSI ES 202 642 V1.1.1 (2010-09)
2.2 Informative references
The following referenced documents are not necessary for the application of the present document but they assist the
user with regard to a particular subject area.
[i.1] ETSI EG 202 325: "Human Factors (HF); User Profile Management".
[i.2] ETSI EG 202 421: "Human Factors (HF); Multicultural and language aspects of multimedia
communications".
[i.3] ETSI SR 002 564 (V2.0.0): "Applicability of existing ETSI and ETSI/3GPP deliverables to
eHealth".
[i.4] eHealth Ministerial Declaration: "The Contribution of ICT to Health. Ministerial Conference and
Exhibition"; Brussels, 22-23 May 2003.
NOTE: Available at:
http://ec.europa.eu/information_society/eeurope/ehealth/conference/2003/doc/min_dec_22_may_03.pdf.
[i.5] WHO: "International Classification of Diseases (ICD)".
NOTE: Available at: www.who.int.
[i.6] WHO: "International Classification of Functioning, Disability and Health (ICF)".
[i.7] WHO: "International Classification of Health Interventions (ICHI)".
[i.8] WHO: "Guidelines on the use of International Nonproprietary Names (INNs) for Pharmaceutical
Substances".
[i.9] Oh H, Rizo C, Enkin M, Jadad A: What Is eHealth (3): "A Systematic Review of Published
Definitions", J Med Internet Res 2005;7(1):e1.
NOTE: See http://www.jmir.org/2005/1/e1/.
[i.10] Eysenbach G. "What is e-health?" J Med Internet Res 2001 Jun 18;3(2):e20.
NOTE: See http://www.jmir.org/2001/2/e20/.
[i.11] Mitchell J. "From telehealth to e-health: The unstoppable rise of e-health", Canberra, Australia:
Commonwealth Department of Communications, Information Technology and the Arts
(DOCITA); 1999.
[i.12] "Integrating Community Equipment Services (ICES)" (January 2005): "Telecare".
[i.13] Doughty, K., Cameron, K. and Garner, P. (1996): "Three generations of telecare of the elderly"
Journal of Telemedicine and Telecare 2(2): 71-80.
[i.14] ISO 215: "Documentation - Presentation of contributions to periodicals and other serials".
3 Definitions and abbreviations
3.1 Definitions
For the purposes of the present document, the following terms and definitions apply:
accessibility: ensuring that all sectors of the community have equal access to communications and online information
administrator: person who defines profiles with profile data
NOTE: Also known as profile administrator.
ETSI
9 ETSI ES 202 642 V1.1.1 (2010-09)
carer: individual who provides health or social care to the client
NOTE: Both professional and informal carers are included in this category.
client: individual receiving the eHealth service, to support independent living and/or using eHealth services for the care
of his or her own health and wellbeing
eHealth service provider: provider of eHealth services to a group of people
formal carers: professional providing care for the client
health/care professionals: professionals (e.g. clinicians, doctors, occupational therapists, social workers) involved in
the assessment of clients and delivery of more specialist care than that provided by carers
informal carers: relatives, neighbours, friends or volunteers providing care for the client
profile: set of user related information, preferences, rules and settings which affects the way in which a user
experiences terminals, devices and services
NOTE: The use of the word profile in the present document implies user profile unless otherwise stated.
profile provider: entity (e.g. company such as a service provider, organisation such as a special interest or affinity
organization) that provide profiles and associated services
rule: statement that can be interpreted by the profile system to produce or limit an action
state: aspect of users and their devices and services
template: set of rules and settings provided by an entity as a starting point for the user for the creation of their profiles
usability: extent to which a product can be used by specific users to achieve specific goals with effectiveness,
efficiency and satisfaction in a specified context of use
user: person using ICT services
user profile: See profile.
3.2 Abbreviations
For the purposes of the present document, the following abbreviations apply:
ACR-NEMA American College of Radiology - National Electrical Manufacturers Association
ADL Activities of Daily Living
CEN Comité Européen de Normalization
COPD Chronic Obstructive Pulmonary Disease
DICOM Digital Imaging and Communications in Medicine
EAACI European Academy of Allergy and Clinical Immunology
EHR Electronic Health Record
FIC Family of International Classifications
HL7 Health Level 7
ICHI International Classification of Health Interventions
ICT Information and Communications Technology
IDR Informatics for the Disabled and Rehabilitation
IFIP International Federation for Information Processing
IHE Integrating the Healthcare Enterprise
NLU Natural Language Understanding
NPS Nomenclature for allergy Position Statement
PCI Primary Care Informatics
PHR Personal Health Record
PPD Personal Portable Devices
SDO Standards Developing Organization
SFC Scottish Funding Council
UPM User Profile Management
WAO World Allergy Organization
ETSI
10 ETSI ES 202 642 V1.1.1 (2010-09)
WG Working Group
WHO World Health Organization
4 Overview of the personalization and profile concept
4.1 Introduction
For the convenience of the reader, this clause provides an brief overview of the personalization and user profile concept
as described in more detail in EG 202 325 [i.1]. Further information can also be found in ES 202 746 [1] which
provides standardized user profile preferences and information. The personalization and user profile Architectural
Framework is described in [2] (not restricted to eHealth personalization). The present document concentrates on the
eHealth aspects of the user profile. From now on in the present document, the term "profile" will be used with the
meaning "user profile".
4.2 What is a profile?
A profile contains details of the user and their personal requirements in a form that can be used by a system to deliver
the required behaviours. When users wish to have the behaviour of devices or services personalized to their
requirements, a profile will be required for:
• storing information, preferences and rules;
• making the information and preferences available to services/devices and when relevant also to other people.
Users require the data to be stored in a secure manner with user agreed levels of privacy applied to the availability and
distribution of that data.
In the present document, the profile is often referred as if it is a single functional entity. However, parts of this profile
may be distributed amongst a number of storage locations that include the user's services and devices. There may also
be copies of profile data stored in devices or services and in a centralized location. Wherever the data is stored, the
profile system will ensure that the data is synchronized when relevant. When new devices are acquired, factory set
information and preferences may be updated by information and preferences copied from equivalent data that is already
in the user's profile.
Major factors of the profile concept described in the present document, that distinguish them from profiles described in
many other sources, are:
• the primary purpose of the profiles are to offer benefits to users;
• profiles contain information that allows users to configure services and devices to meet their individual needs;
• most of the data in the profile is considered to be owned by the user;
• the user can view all of the information in their profile in a form that is designed to be easy to understand;
• much of the information in the profile is intended to be applicable to a wide range of services and devices that
are associated with the user;
• the user is usually able to modify most of the information in the profile (examples of exceptions when
someone cannot modify information in the profile is when a child who might not be allowed to change most of
the data, as their parents might have decided to configure the profile for them or clients who ask a carer to
update the profile on their behalf).
ETSI
11 ETSI ES 202 642 V1.1.1 (2010-09)
4.3 Organization of the profile content
In general, a profile contains [1]:
• Information: data about or related to the user (e.g. name, address).
• Preferences: choices made by the user about a given parameter that will define or modify the system
behaviour. More complex preferences can be expressed in the form of rules (see below).
NOTE: When something is considered essential to the user, it would be more appropriate if a preference is
instead called a "need" (e.g. a blind user sets the modality to "sound"). However, for simplification, in the
present document the word "preference" is used.
• Rules: statements that can be automatically interpreted in order to define or modify the system behaviour.
These rules may:
- express complex preferences;
- activate or de-activate situation profiles.
More specifically, the profile is organized into several blocks. The major organisational units of the profile are:
• Personal information: data about or related to the user (e.g. name, address, location).
• Human centred preferences: These are the overall preferences that might apply across the user's usage of a
wide variety of different devices and services.
As these preferences are not mapped precisely to specific features of services and devices, they may be
presented in ways that must be interpreted before they can be used as the definition for a precise setting for a
service or device feature.
• Service/device category related information and preferences: The information and preferences in this clause
are related to service categories (e.g. Communications services), further sub-categories of the service category
(e.g. Realtime communication), and specific services/devices.
Information and preferences need to be associated with a scope, which includes:
• (groups of) services;
• (groups of) devices;
• (groups of) people (e.g. entries in an address book).
• A scope may be very narrow (e.g. one specific service) or very broad (e.g. preferred language for all my
services).
The values of the profile information and preferences in the profile will be either:
• directly set by the user (or by someone else on behalf of the user);
• read from other profile information (e.g. from devices or services);
• set as the result of a rule that is contained in the user's profile.
Further details on the profile content for services and devices in general (not restricted to eHealth services) is described
in ES 202 746 [1] on "User Profile Preferences and Information".
ETSI
12 ETSI ES 202 642 V1.1.1 (2010-09)
4.4 Profile extensions
4.4.1 Proprietary profile extensions
Because of the limited of standardization of the features of eHealth related services and devices, it is not possible to
define a full set of standardized profile data related to these. However, the profile may still contain information and
preferences related to these as proprietary profile extensions. As stated in ES 202 746 [1], in addition to profile data
items as defined and listed in the present document, it is possible for eHealth service developers and device
manufactures to include proprietary profile data items in the profile which shall be identifiable as proprietary
(e.g. specify the company and/or product identifier for which the proprietary information and preferences are intended
for). Proprietary profile extensions are outside the scope of the present document.
4.4.2 Additional standardized information and preferences
In addition to profile data items as defined and listed in the present document, it is expected that there will be a need for
future additional standardized information and preferences, for which new versions of the present standard may be
developed.
4.5 Templates
Profiles can contain a very large number of settings and preferences which would be difficult to set up unaided. When
users first create profile specifications, the creation task can be greatly simplified if the profile specifications are created
from templates. The template provides a set of rules and settings that act as a starting point for users when creating their
profiles, and these can be further amended by the user to suit their individual needs. Templates can be provided to the
user from a number of different sources. Typically, templates would be used to create a personal default profile
specification. Some templates for creating typical situation profiles would then also be provided. The use of templates
will typically be in combination with a wizard guiding the user while defining their profile.
There may be parameters for which defaults are not appropriate and where the profile system will force the user to set
their own value e.g. where it might result in a potentially dangerous health condition or if it is legally required for the
user to make an explicit decision for themselves. When prompting the user for a value, the profile agent may:
• request explicit user input;
• propose a range of options from which the user will have to chose one;
• propose a value to accept or reject and give the user a mechanism to specify an alternative value if they reject
the proposed value.
Further information and guidelines on templates can be found in clause 9 of EG 202 325 [i.1].
4.6 Profiles and user views
4.6.1 Situations, context and the scope object
Users move between situations throughout the day (e.g. at home, driving, working), and also users may change
depending on their specific health condition. In each of these situations, users may have different needs for how they
would like their ICT resources arranged. Wherever a user wishes to have different behaviour from their ICT it will first
be necessary to identify criteria that uniquely define the situation. These criteria are captured as rules that defines when
a Scope object is active (i.e. when it is isActive method evaluates to TRUE). Hence the user concept of a "situation" is
represented in the profile system by a Scope object.
ETSI
13 ETSI ES 202 642 V1.1.1 (2010-09)
Clause 5.4.4 in TS 102 747 on "Personalization and User Profile Management: Architectural Framework" [2] shows
very flexible ways in which the profile data is modified according to the context. However, users will be unable to
understand all of the possible implications of the dependency of individual data items on context. For this reason, it is
necessary to introduce the concept of User Views of the profile. Although it is possible to create any number of
specialized views of the profile, two views that have been defined in EG 202 325 [i.1], and which are described to users
as profiles, are the "Normal Profile" and the "Situation Profile". The view that is described as the "Normal Profile"
shows all of the profile data that will be applied when no specific user-defined situation applies. This view can be
achieved by creating a view of the profile that shows the values of profile data when no Scope object other than the
"Normal" Scope object have been activated.
Whereas the "Normal Profile" view shows the values of the items in the profile, it is useful to show the values of profile
data that may need to be set to values relevant to a user-determined situation. There is therefore a need for another view
which corresponds to the user concept "situation". Such a view is described in user terms in EG 202 325 [i.1] as the
"Situation Profile". In this view the user can see the values assigned to profile data items that may need to have a special
value set in that situation. The situation profile view will contain fewer profile data items than the "Normal Profile"
view, as it will contain only those data items which are different in that specific situation (i.e. only profile data items
associated with the Scope object that represents the user's "situation").
Profile providers may also offer other views of the profile to users. For example, users may wish to see all of their
profile as it will be in a particular "situation", not just the standard view that shows those profile data items that are
uniquely configured for the current situation.
Profile users should be allowed to view their profiles making use of these user views and, if they have administrator
rights, should be allowed to modify the profile data that they see in these views. Modifications to profile data in a user
view that shows a "Situation Profile" is a means to allow the modification of the Profile-Item-Attributes associated with
that "situation" (i.e. associated with the Scope object that represents that "situation").
Situation profiles can be activated:
• manually, e.g. the user choosing the relevant situation (Scope object) from a menu;
• automatically, e.g. the system detects that a Scope object has been activated and activates the appropriate
"situation profile";
• combination of automatically and manually, e.g. the system detects that a Scope object has been activated and
asks the user if they want the corresponding situation profile to be activated, and the user accepts.
NOTE: Clause 4.7 describes how many specialised health states, that in many ways are similar to situation
profiles, will not be user selectable in menus and will not be presented to users to accept or reject.
Conflicts may appear when two (or more) Scope objects are simultaneously activated, which would result in an attempt
to set the same profile data to different values. To avoid this, the profile system needs to determine which of these
alternative values shall be applied. Therefore, priorities are assigned to "Situation Profiles" and/or profile data items. In
the profile system, the priorities are attributes of the Scope objects that are associated with "Situation Profiles" and
individual profile data items. If there is an attempt to set two (or more) different values for an item of profile data, then
the value of the profile data that is associated with the Scope object with highest priority is set. The mechanisms for
handling conflicts and dealing with the situation when priorities still do not resolve a conflict are described in more
detail in TS 102 747 [2]. Table 5.3.3 (Scope class) in [1]. gives the specification of the priority attribute of the Scope
object, and defines ranges of priorities to be assigned to different categories of Scope objects (determined by the
scope-category attribute of the Scope object).
Profile provider support should assist users in defining priorities to avoid potential conflicts.
4.6.2 Avoiding conflicts by using templates
Potential conflicts (when two or more Scope objects, are trying to set the same data to different values), may be
resolved by the use of a well designed set of pre-defined templates that assign priorities to preferences in a way that
eliminates conflicts for most probable combinations of situations (Scope objects).
It would be expected that if profile providers assist users to create their profiles by means of a "creation wizard", the
wizard would make use of such a coherent set of templates and would thus create an initial profile setup where conflicts
are eliminated or confined to extremely unlikely combinations of situations.
ETSI
14 ETSI ES 202 642 V1.1.1 (2010-09)
4.7 Context information
The profile system should be provided with any relevant information that can affect the behaviour of the system. This is
called context information.
Examples of the context information include:
• the status of the services to which the user is subscribed;
• the status of the user's devices;
• the location of the user;
• other presence information;
• network conditions.
Context information will often be addressed in rules. The profile system can request context information or receive
notification of changes, based upon a subscription. The activation of Scope object will be determined by rules involving
context information. TS 102 747 [2] describes a "Context Watcher" application that is responsible for managing the
acquisition of context information from the various sources (e.g. sensors, devices, services). There are two fundamental
options for how this context information may be obtained:
• Polling: where the Context Watcher periodically requests updated context information from the source;
• On update: where the context source sends updated context information to the Context Watcher when a change
has occurred to that context information. The information would normally be sent immediately the change has
occurred at the source, but a degree of latency in sending this information may occur.
The choice about the frequency at which context information is requested from a source is the responsibility of the
profile management system. The choice about when a change of context information is notified to the profile
management system is the responsibility of the device, service or sensor system that is the source of the context
information. In both cases, the ideal aim is to adjust the frequency of context information updating to match the
perceived significance of the context information in terms of its importance and its urgency. Where context information
is used to control profile behaviour in ways that are not very important or very urgent, the profile management system
can be set to poll for this information quite infrequently.
Although frequent polling may place an unnecessary load on the communication channel used to acquire the updates
(which may also have an associated cost), for context information that may be needed to determine states that have a
very important or urgent significance in terms of the control of the profile, frequent polling will be what is required.
Some eHealth situations may be associated with outcomes that will cause discomfort or danger for the user. The health
status of a user may change very frequently and sometimes rapidly, and as a consequence, the associated context
information will therefore
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.
Loading comments...