Stakeholder Requirements for this Profile - i-focus

texturegainfulΚινητά – Ασύρματες Τεχνολογίες

10 Δεκ 2013 (πριν από 3 χρόνια και 10 μήνες)

151 εμφανίσεις









dallas

Interoperability Profile

An Information Architecture

for Multi
-
platform Services

Stakeholder Requirements

v 1.1 14

Dec 2012

Project Name:

i
-
focus / WS1

Project
Number:

a195

/
971241

Document:


Stakeholder Requirements

for
dallas

Interoperability Profile


䅮⁉ 景rma瑩Wn
䅲捨c瑥捴畲c⁦ r⁍u汴l
-
p污瑦o牭⁓敲v楣敳


Publication Date:


14
th

Dec
ember 2012

Revision:
1.1

Customer:

Technology Strategy Board / dallas


Revision History

v1.0

11 December 2012

Initial release, as presented to TSB monitoring officer

v1.1

14 December 2012

Addition of MR76 (metrics for efficacy)





Stakeholder Requirements for
dallas

Interoperability Profile:

An Information A
rchitecture for Multi
-
platform
Services



2
/
28



Stakeholder Requirements

The stakeholder requirements captured here are relevant to the
dallas

Interoperability P
rofile for
an
Information Architecture for Multi
-
platform Service
s.

They have been derived through engagement
with the four
dallas

communities by interviews and direct
project meetings, by scenario
-
building in
an experience
-
led design process, and during a review process in conference workshops.

Table of
Requirements for this profile

page

Stakeholder Requirements fo
r this Profile

................................
................................
.............................

4

Overview

................................
................................
................................
................................
.............

4

R1:

Users’ preferences for devices must be taken into account

................................
.......................

4

R2:

The statutory sector should be

able to minimise capital costs by utilising consumers’
own devices

................................
................................
................................
................................
.

5

R3:

The statutory sector should be able to purchase and util
ise consumer technology

..................

5

R4:

It must be possible to use the same system for communication both with friends &
family and with hea
lth professionals

................................
................................
..........................

6

R5:

Where practical, it should be possible to access services using a smartphone

..........................

7

R6:

Where practical, it should be possible to access services using a tablet

................................
....

7

R7:

Where practical, it should be possible to access services using a digital TV

..............................

8

R8:

Where practical, it should be possible to access services using a desktop PC

...........................

8

R9:

Where practical, it should be possible

to access services using a laptop PC

..............................

9

R10:

Where practical, it should be possible to access services using a landline
(voice
-
only)

.............

9

R11:

Where practical, it should be possible to access services using a basic mobile phone
(e.g. via SMS)

................................
................................
................................
.............................

10

R12:

The service must work despite poor network connectivity

................................
......................

10

R13:

It must be possible to add third
-
party apps, to create a marketplace for business

.................

11

R14:

It should be possible to access (some?) services without the mandated use of a
Personal Health Record

................................
................................
................................
.............

12

R15:

Individuals must be in control and able to choose the services and devices to use

................

12

R16:

After installation, sys
tems must be able to be extended by the addition of new
components, to add features as required

................................
................................
.................

13

R17:

Systems must be able to e
volve as devices change

................................
................................
..

13

R18:

Systems must be able to evolve as users’ preferences and/or needs change

.........................

14

R19:

Systems must facilitate greater self
-
care and/or informal (non
-
statutory) care

......................

14

Stakeholder Requirements for
dallas

Interoperability Profile:

An Information A
rchitecture for Multi
-
platform
Services



3
/
28



R20:

Where practical, it should be possible to access services using Games Consoles

....................

15

R21:

Systems must make it easy for users to access and use services

................................
.............

16

R22:

It must

be possible to access services using public internet access kiosks, hotspots,
access
-
points, etc.

................................
................................
................................
.....................

16

R23:

Systems should use
open
-
standard, non
-
proprietary interfaces, APIs, etc.

.............................

17

R24:

Systems should be simple enough for anyone to use, but secure enoug
h for everyone
to trust

................................
................................
................................
................................
.......

18

R25:

It must be possible to input telehealth information either directly from devices or
manually (or
both)
................................
................................
................................
.....................

19

R26:

The content/data must be stored in a device
-
agnostic form

................................
...................

19

R27:

Content must be delivered in an accessible manner

................................
................................

20

R28:

Data
-
sharing rules should include consideration of the application being used

......................

20

R29:

Data
-
sharing rules should include consideration of the device being used

.............................

21

R30:

Systems must support provision of forums and/or chat
-
rooms

................................
...............

21

R31:

System must support shared calendars and reminders

................................
...........................

22

R32:

Systems should support video calls and conferencing

................................
.............................

22

R33:

Systems should support video
-
based delivery of training and information

.............................

23

R34:

Systems should support interfaces with voluntary
-

and private
-
sector service
providers

................................
................................
................................
................................
...

23

R35:

Systems should allo
w booking of appointments

................................
................................
......

24

R36:

Systems should provide access to services whenever and wherever access is needed,
online and
offline

................................
................................
................................
......................

24

R37:

Information from PHRs must be available from within existing statutory sector
systems

................................
................................
................................
................................
......

25

R38:

Information shared by the statutory sector into a PHR needs to be linked to current
professional practice

................................
................................
................................
.................

25

R39:

Information released by the statutory sector must be easy to understand by
individuals and their informal care network

................................
................................
.............

26

R40:

Consideration should be given to the implications of the potential use of the smart
meter communications infrastructure

................................
................................
......................

26

R41:

Systems must allow the collection of appropriate metrics to allow the long
-
term
evaluation of the efficacy of the services offered

................................
................................
.....

27


Stakeholder Requirements for
dallas

Interoperability Profile:

An Information A
rchitecture for Multi
-
platform
Services



4
/
28



Stakeholder Requirements for this Profile

Overview

In order to achieve the
dallas

goal of scale, there must be as few barriers to access to services as
possible
. One key barrier is the availability of the services via an individual’s device of choice,
whether that is a PC, portable device, TV or landline telephone. Within each of these device classes,
again to ensure as few barriers as possible, all the major ope
rating systems/ecosystems must be
supported


e.g. Windows and Mac on PCs, and iOS, Android, Windows Phone and Blackberry on
mobile devices. Equally important, given the focus on the interface between statutory
-
sector
providers and the consumer world, is a
vailability
of access through the popular records systems used
by the NHS, social services, and private/voluntary
-
sector service providers.

This Profile seeks to
specify an information architecture that facilitates delivery of
dallas

services
over a diverse variety of devices
.

R1:

Users


preferences for devices must be taken into account

Description

In order to roll out services as widely as possible and achieve the
dallas

goal of Scale, services
should not be limited to platforms chosen

by suppliers or commissioners, but should include the
devices that consumers are already using in their daily life, or might choose to purchase and/or use
for reasons outside their health & wellbeing.

On each of the technical platforms, the services shoul
d appear as a “native” application, with the
content displayed and interacted
-
with in ways that are usual for that platform, and thus expected by
the users.

Explanation

If architected well, then the services themselves could very nearly be device
-
agnostic,

with only the
delivery mechanism rendering content to different devices at the point where they really differ from
each other (e.g. screen resolution, UI capability etc.).

Source of Requirement

Communities:
LiU,

FGF,

YZ,

WN

Workshop

i
-
focus Master Requi
rement Reference

R1

Stakeholder Requirements for
dallas

Interoperability Profile:

An Information A
rchitecture for Multi
-
platform
Services



5
/
28



Other Relevant Profiles:

Implications of MDD for Consumer Devices

R2:

The
statutory sector should be able to minimise capital costs by utilising
consumers
’ own

devices

Description

The rollout of services by the statutory sector will be
impeded by cost if the devices that must be
supplied are to be paid for by the statutory sector; meanwhile, if the cost is to be borne directly by
the consumer then there will be again a cost
-
resistance, especially if the need for the service is
directed b
y the statutory sector. The solution is to launch services that can be used on devices that
consumers already own, or on devices the consumer perceives to have wider lifestyle benefits.

Explanation

The information architecture must allow easy delivery of c
ontent to the widest possible range of
consumer devices.

Source of Requirement

Communities: LiU, YZ


i
-
focus Master Requirement Reference

R2

Other Relevant Profiles

Implicatio
ns of MDD for Consumer Devices

Information Governance: PHRs & statutory systems

R3:

The s
tatutory sector should be able to purchase and utilise consumer
technology

Description

The statutory sector has traditionally purchased only from approved supplier lists. For specialised
medical products this had justification. However, with the wide
availability of very capable portable
consumer devices, better purchasing decisions may now involve using standardised consumer
devices, with the appropriate software, as economies of scale can significantly reduce cost.

Other advantages include the tried
-
and
-
tested nature of mass
-
market technology, the familiarity of
use (reducing training needs), and the availability of lower
-
priced consumables.

Explanation

The information architecture must allow easy delivery of content to the widest possible range of
consumer devices.

Stakeholder Requirements for
dallas

Interoperability Profile:

An Information A
rchitecture for Multi
-
platform
Services



6
/
28



Source of Requirement

Communities:
LiU,

YZ


i
-
focus Master Requirement Reference

R3

Other Relevant Profiles

Implications of MDD for Consumer Devices



Information Governance: PHRs & statutory systems

R4:

It must be possible to use
the same

system for communication
both with
friends & family and

with health professionals

Description

One of the barriers to mass adoption of
dallas

services will be if individuals are required to use one
means of communication with their friends and family (e.g.

Skype,
instant messaging,
e
-
mail
) and a
different means of communication with health and care professionals (e.g. secure messaging app,
unfamiliar video calling technology). It is important, therefore, that, as far as possible, existing well
-
used means of

communication are adopted by the statutory sector. This is even more important
where a care network includes both formal and informal carers.

Explanation

Communicating with statutory sector carers should be made as easy and natural as communicating
with f
riends and family. Because of the nature of the services provided and the information being
conveyed, there are obvious concerns about security, quality of service, etc. As far as possible, these
concerns should be addressed by technology hidden from the u
ser.

Source of Requirement

Communities:
LiU,FGF,WN


i
-
focus Master Requirement Reference

R4

Other Relevant Profiles

Framework for Identity and consent
,


Information Governance: PHRs & statutory systems

Stakeholder Requirements for
dallas

Interoperability Profile:

An Information A
rchitecture for Multi
-
platform
Services



7
/
28



R5:

Where practical, i
t
should

be
possible
to access serv
ice
s

using
a
smartphone

Description

Smartphones are becoming ubiquitous and are used increasingly by individuals, and their doctors
and carers alike. Those people that wish to access
dallas

services via their smartphone should be
able to do so. Where it ma
kes sense to do so, therefore, services should be designed for and made
available on smartphones.

Explanation

For maximum take
-
up, services should, where possible, be designed to be accessible through all
major smartphone ecosystems


iOS, Android, Windows

Phone, Blackberry and, possibly Symbian.

Source of Requirement

Communities:
LiU,

FGF,

YZ,

WN


i
-
focus Master Requirement Reference

R5

Other Relevant Profiles

Implications of MDD for Consumer Devices



R6:

Where practical, it should

be
possi
ble to access
service
s

using
a
tablet

Description

Tablets are becoming ubiquitous and are used increasingly by individuals, and their doctors and
carers alike. Those people that wish to access
dallas

services via their tablet should be able to do so.
Where it makes sens
e to do so, therefore, services should be designed for and made available on
tablets.

Explanation

For maximum take
-
up, services should, where possible, be designed to be accessible through all
major tablet ecosystems


iOS, Android, and possibly in the fut
ure, WindowsRT.

Source of Requirement

Communities:
LiU,

FGF,

YZ,

WN


i
-
focus Master Requirement Reference

MR6

Other Relevant Profiles

Information architecture for Multi
-
platform service delivery


Implications of MDD for Consumer Devices



Stakeholder Requirements for
dallas

Interoperability Profile:

An Information A
rchitecture for Multi
-
platform
Services



8
/
28



R7:

Where practical,
it should

be
possi
ble to access service
s

using
a
digital T
V

Description

Many of the target users of
dallas

services
will

have no access to smartphones and tablets, nor any
likelihood of purchasing them in the near future. A more convenient medium for many
people will
be their existing TV set, supported if necessary by a set
-
top box, with applications downloaded and
installed to that TV or STB. Where it makes sense to do so, therefore, services should be designed for
and made available on digital TV platform
s.

Explanation

There is no common standard for Connected TV apps


most vendors have their own specification,
although these all tend to be based on a variety of either HTML or Adobe Flash, so it may be possible
to reduce the development time by appropriat
e common development. Virgin Media cable STBs also
use either a version of HTML (the older boxes) or Adobe Air (the newer “Tivo” boxes). Sky TV boxes
use a proprietary system. Freeview and Freesat boxes use the MHEG
-
5 international standard,
although the n
ew
-
generation Freesat “Freetime” boxes also support HbbTV, which is based on
HTML.

Source of Requirement

Communities:
LiU,

FGF,

YZ,

WN


i
-
focus Master Requirement Reference

MR7

Other Relevant Profiles

Implications of MDD for Consumer Devices



R8:

Where
practical, it should

be
possi
ble to access service
s

using
a
desktop PC

Description

Desktop PCs are used by the vast majority of health and care professionals in their work
environment, and by a large proportion of individuals, either at home or at work. Th
ose people that
wish to access
dallas

services via their desktop PC should be able to do so. Where it makes sense to
do so, therefore, services should be designed for and made available on desktop PCs (Windows,
Mac, or Linux), ideally using the user’s web
browser of choice, rather than after installing some
additional software.

Explanation

Modern web
-
browsers are much more standards
-
compliant than a few years ago, so it should be
possible to design an application that will work across all major browsers on
all major operating
systems.

Source of Requirement

Communities:
LiU,

YZ

Stakeholder Requirements for
dallas

Interoperability Profile:

An Information A
rchitecture for Multi
-
platform
Services



9
/
28



i
-
focus Master Requirement Reference

R8

Other Relevant Profiles

Implications of MDD for Consumer Devices



R9:

Where practical, it should

be
possi
ble to access service
s

using
a
laptop PC

D
escription

Laptop PCs are used by the increasing numbers of health and care professionals in their work
environment, and by a large proportion of individuals, either at home or at work. Those people that
wish to access
dallas

services via their laptop PC
should be able to do so. Where it makes sense to do
so, therefore, services should be designed for and made available on laptop PCs (Windows, Mac, or
Linux), ideally using the user’s web browser of choice, rather than after installing some additional
softw
are.

Explanation

Modern web
-
browsers are much more standards
-
compliant than a few years ago, so it should be
possible to design an application that will work across all major browsers on all major operating
systems.

Source of Requirement

Communities:
LiU,Y
Z

i
-
focus Master Requirement Reference

R9

Other Relevant Profiles

Implications of MDD for Consumer Devices



R10:

Where practical, it should

be
possi
ble to access service
s

using
a
landline
(voice
-
only
)

Description

Many of the target audience for
dallas

services will not have smartphones, tablets, or PCs, either
through choice or financial necessity. A large percentage of these people, will, however, have a
landline. It is important, therefore, that wherever practical,
dallas
services are able to be acce
ssed,
perhaps in a cut
-
down manner, by voice telephone calls to ensure universal access.

Explanation

As far as possible, services should be accessible via IVR systems, or via a call centre.

Stakeholder Requirements for
dallas

Interoperability Profile:

An Information A
rchitecture for Multi
-
platform
Services



10
/
28



Source of Requirement

Communities:
LiU,

FGF,

WN

Workshop

i
-
focus M
aster Requirement Reference

R10

Other Relevant Profiles


R11:

Where practical, it should

be
possi
ble to access service
s

using
a basic

mobile
phone

(e.g.

via
SMS)

Description

Many of the target audience for
dallas

services will not have smartphones, tablets, or
PCs, either
through choice or financial necessity. A large percentage of these people, will, however, have a basic
mobile phone, capable of voice calls and text messages. It is important, therefore, that wherever
practical,
dallas
services are able to be a
ccessed, perhaps in a cut
-
down manner, by voice telephone
calls and/or text messages to ensure universal access.

Explanation

As far as possible, services should be accessible via voice calls to/from IVR systems or a call centre,
or via text message.

Sourc
e of Requirement

Communities:
LiU,

FGF,

YZ,

WN


i
-
focus Master Requirement Reference

R11

Other Relevant Profiles

Implications of MDD for Consumer Devices



R12:

The s
ervice must work despite poor network connectivity

Description

The quality of available network

connection will vary with location and also possibly with time
(especially in the case of mobile or wireless connectivity). Services should be designed with this in
mind, and should be as resilient as possible to low bandwidth, high error rates and interm
ittent
connectivity.

Stakeholder Requirements for
dallas

Interoperability Profile:

An Information A
rchitecture for Multi
-
platform
Services



11
/
28



Explanation

Clearly the network requirements will vary from service to service, with some (e.g. video calls)
requiring much higher bandwidth, better quality connections than others. Each (part of the) service
should be designed to be
as resilient as possible to network problems. For example, it might be
sensible to download a set of data to a local cache within the device, and to allow delayed updating
of the master data if connectivity with the server is lost.

Source of Requirement

Co
mmunities:
LiU


i
-
focus Master Requirement Reference

R12

Other Relevant Profiles

Information architecture for Multi
-
platform service delivery




R13:

It must be possible to add third
-
party apps, to create a marketplace for
business

Description

The
dallas

commun
ities cannot do all the application development themselves, nor will they have all
the best ideas. The information architecture should allow third party applications to join the
ecosystem to fill gaps that their creators perceive to exist. In addition, it
should be possible for
additional service providers to plug
-
in their systems and services to the ecosystem.

Explanation

There will need to be a balance struck between openness and security. Apps will need to be trusted
by the ecosystem before being allowed

in (to stop, for example, an insecure app gaining access to
medical records).

Source of Requirement

Communities:
LiU,FGF,WN


i
-
focus Master Requirement Reference

R12

Other Relevant Profiles

Framework for Identity and consent


Information Governance: PHRs

& statutory systems

Stakeholder Requirements for
dallas

Interoperability Profile:

An Information A
rchitecture for Multi
-
platform
Services



12
/
28



R14:

It s
hould be
possi
ble to access (some?) services without
the
mandated use
of
a
P
ersonal
H
ealth
R
ecord

Description

There is a question over what percentage of the population would wish to create a fully
-
featured
PHR, with concerns both
over the need for and security of such a record. To maximise take
-
up of
services, therefore, it should be possible to access as many services as possible without the need to
create and/or populate a PHR.

Explanation

Examples of services that should not nee
d the creation of a PHR include the use of health
information and education services, the booking of GP’s appointments and the viewing of statutory
records.

Source of Requirement

Communities:
LiU


i
-
focus Master Requirement Reference

R20

Other Relevant Pro
files


R15:

Individuals

must be
in control and
able to

choose
the
services and devices t
o

use

Description

In order to roll out services as widely as possible and achieve the
dallas

goal of Scale, individuals
must be able to choose services that meet their particular needs, and to access those services on the
device(s) that they are already using in their daily life, or choose to purchase based on factors other
than just their healt
h & wellbeing.

Explanation

The information architecture must allow easy delivery of content to the widest possible range of
consumer devices, and must allow users to pick, choose and personalise applications and services
that best meet their current requir
ements.

Source of Requirement

Communities:
LiU


i
-
focus Master Requirement Reference

R21

Stakeholder Requirements for
dallas

Interoperability Profile:

An Information A
rchitecture for Multi
-
platform
Services



13
/
28



Other Relevant Profiles

Implications of MDD for Consumer Devices



Information Governance: PHRs & statutory systems

R16:

After installation, systems
must be able to

be extended by the addition of
new components
,

to add features as required


Description

Today’s consumer is used to computer software and smartphone/tablet apps being upgraded to add
new features to entice new users and/or retain existing users.
dallas

se
rvices must embrace this
approach to remain relevant to today’s consumer.

Explanation

The information architecture must be designed to support backward and forward compatibility
between all subsystems and applications.

Source of Requirement

Communities:
Li
U


i
-
focus Master Requirement Reference

R22

Other Relevant Profiles

Information architecture for Multi
-
platform service delivery


Implications of MDD for Consumer Devices



R17:

System
s

must be able to evolve as devices change

Description

Consumer devices are e
volving all the time, with new versions of operating system, new form
-
factors, and new ways of user interaction. The information architecture should be designed to be as
device
-
agnostic as possible.

Explanation

If architected well, then the services themse
lves could very nearly be device
-
agnostic, with only the
delivery mechanism rendering content to different devices at the point where they really differ from
each other (e.g. screen resolution, UI capability etc.).

Source of Requirement

Communities:
LiU


Stakeholder Requirements for
dallas

Interoperability Profile:

An Information A
rchitecture for Multi
-
platform
Services



14
/
28



i
-
focus Master Requirement Reference

R23

Other Relevant Profiles

Information architecture for Multi
-
platform service delivery




R18:

System
s

must be able to evolve as users


preferences and/or needs change

Description

Over time, individuals may purchase new devices through which they wish to access
dallas

services,
they may wish to swap from viewing their information in one application to using another because
of the additional facilities it offers, their circumstances
may change such that they need to access
additional services in parallel or instead of those they were using when they signed
-
up, or they may
acquire a mental or physical disability which makes it difficult for them to access services in the way
that they
have done. Systems should be designed to smooth all of the above transitions, and more.

Explanation

This requirement perhaps suggests that as much data as possible needs to be stored in a central
database (the PHR?) that is accessible to all authorised app
lications, rather than being stored in a
data silo associated with a particular vendor or application. Different means of signing
-
in to the
systems need to be provided to allow for those with physical and/or mental disabilities.

It was also suggested in th
e workshop that systems should be smart enough to detect users having
difficulties accessing or using the system, and to prompt the user with alternatives.

Source of Requirement

Communities:
LiU,

WN


Workshop

i
-
focus Master Requirement Reference

R24

Other
Relevant Profiles

Information Governance: PHRs & statutory systems

R19:

Systems must facilitate greater self
-
care and/or informal (non
-
statutory)
care

Description

One of the
dallas

goals is to increase the number of people taking an active interest in their ow
n
health and wellbeing, and that of their family, friends and neighbours, long before they reach the
point where their medical condition has necessitates statutory sector intervention.

Stakeholder Requirements for
dallas

Interoperability Profile:

An Information A
rchitecture for Multi
-
platform
Services



15
/
28



Explanation

The information architecture must allow easy delivery of co
ntent to the widest possible range of
consumer devices, and must allow users to pick, choose and personalise applications and services
that best meet their current requirements.

Source of Requirement

Communities:
LiU,YZ,WN


i
-
focus Master Requirement Refer
ence

R25

Other Relevant Profiles

Implications of MDD for Consumer Devices


Framework for Identity and consent


Information Governance: PHRs & statutory systems

R20:

Where practical, it should

be
possi
ble to access service
s

using Games
Consoles

Description

Games consoles, either hand
-
held or connected to TVs, are becoming ubiquitous. Many people who
do not own a smartphone or tablet might have access to a games console. Those people that wish to
access
dallas

services via their games console should be able t
o do so. Where it makes sense to do
so, therefore, services should be designed for and made available on games consoles.

Explanation

For maximum take
-
up, services should, where possible, be designed to be accessible through all
major games consoles that ha
ve internet access.

Source of Requirement

Communities:
LiU


i
-
focus Master Requirement Reference

R26

Other Relevant Profiles

Implications of MDD for Consumer Devices



Stakeholder Requirements for
dallas

Interoperability Profile:

An Information A
rchitecture for Multi
-
platform
Services



16
/
28



R21:

System
s

must make it easy for users to access and use services

Description

The information architecture must allow easy delivery of content to the widest possible range of
consumer devices, and must allow users to pick, choose and personalise applications and services
that best meet their current requirements.

On each of the tec
hnical platforms, the services should appear as a “native” application, with the
content displayed and interacted
-
with in ways that are usual for that platform, and thus expected by
the users.

In addition, existing well
-
understood metaphors, such as “app s
tores” and
“friending/unfriending”, should be used wherever possible.

Explanation

The information architecture must allow easy delivery of content to the widest possible range of
consumer devices, and must allow users to pick, choose and personalise applic
ations and services
that best meet their current requirements.

Source of Requirement

Communities:
LiU,

FGF,

WN


i
-
focus Master Requirement Reference

R34

Other Relevant Profiles

Framework for Identity and consent


R22:

It m
ust be
possi
ble to
access services
using

public internet access kiosks,
hotspots, access
-
points
,

etc.

Description

Many of the target users of
dallas

services
will

not own smartphones, tablets or PCs, nor any
likelihood of purchasing them in the near future. If they cannot use alternative pl
atforms, such as
their TV for accessing the services that they are interested in, it should be possible for them to use
public internet access terminals at the local library, community centre or internet café.

Those with smartphones or tablets may also wis
h to use them to access
dallas

services whilst
connected to a public wi
-
fi access point.

Explanation

Modern web
-
browsers are much more standards
-
compliant than a few years ago, so it should be
possible to design an application that will work inside any web

browser likely to be installed on a
public access internet terminal.

Stakeholder Requirements for
dallas

Interoperability Profile:

An Information A
rchitecture for Multi
-
platform
Services



17
/
28



Applications should be designed, as far as possible, not to require the installation of additional
software, or the plugging
-
in of additional hardware, as this is likely to be problemati
c on public
access internet terminals.

Applications need to be written to ensure that sensitive information is used in a secure way, and is
not available to other applications, or after the user has logged
-
out of the terminal.

More generally, internet conn
ections should make appropriate use of encrypted connections (e.g.
HTTPS) to ensure that communications cannot be monitored.

Source of Requirement

Communities:
FGF,

YZ


i
-
focus Master Requirement Reference

R40

Other Relevant Profiles

Implications of MDD fo
r Consumer Devices


Framework for Identity and consent


Information Governance: PHRs & statutory systems

R23:

Systems should use open
-
standard
,

non
-
proprietary interfaces
,

APIs
,

etc.

Description

The

interests
of the widest number of stakeholders
are
usually
best served by
using

open standard
interfaces that allow competition on feature and price to system components and elements,
enabling greater consumer and com
missioner choice, greater extensi
bility and greater innovation
potential.

However, use of such ope
n standards should not prohibit the creation of custom services
providing added value.

Explanation

Some of the open standards and standards development organisations that have been mentioned
during the development of this requirement are: W3C, HTML5, DVB
,
IHE, HL7, IEEE

11073, BSI
8571,
Continua,
XSLT
, ITK,

HTTP, XML, REST, oData, X509, and Cabinet office IDA.

Source of Requirement

Communities: LiU,

FGF,

YZ,

WN

i
-
focus scenario: 7

Roleplay

Workshop

Stakeholder Requirements for
dallas

Interoperability Profile:

An Information A
rchitecture for Multi
-
platform
Services



18
/
28



i
-
focus Master Requirement Reference

R41

Other Relevant Pro
files


R24:

Systems should be simple enough for an
yone

to use
,

but secure enough for
everyone to trus
t

Description

In order to maximise adoption and achieve the
dallas

goal of Scale, services should be simple to use
for anyone with basic familiarity with the d
evice they are using to access the services. The services
should appear as “native” applications, with the content displayed and interacted
-
with in ways that
are usual for that platform, and thus as expected by the users.

At the same time, the systems should be secure, and be perceived as being secure, enough for
everyone to trust with their personal information.

Explanation

If architected well, then the services themselves could very nearly be device
-
agnostic, with only th
e
delivery mechanism rendering content to different devices at the point where they really differ from
each other.

There is a need to balance ease of access with data security. For instance, a single sign
-
on system
will greatly
-
enhance usability, but mayb
e an additional authentication process is needed prior to
access to particularly sensitive data or important commitments.

Privacy control must be controlled in a consistent
,

intuitively simple manner
, so that

individuals
are

able to understand at a glance
who has what access to
what parts of
their data.

Source of Requirement

Communities: FGF

i
-
focus scenarios:
7,8,9,10,11,12,13,16

Roleplay

Workshop

i
-
focus Master Requirement Reference

R42

Other Relevant Profiles

Framework for Identity and consent


Information Governance: PHRs & statutory systems

Stakeholder Requirements for
dallas

Interoperability Profile:

An Information A
rchitecture for Multi
-
platform
Services



19
/
28



R25:

It must be possible to input telehealth information either directly from
devices or manually (or both)

Description

Telehealth measurements may be automatically uploaded by the measurement device, via a
smar
tphone, tablet or PC, to the PHR, or the user may have to take the readings and then manually
input them to the PHR via an app running on his/her device of choice.

Explanation

Systems should allow telehealth devices to automatically upload data via an app
on a portable
device or PC, and ensure that the provenance of the data is recorded. Where measurements are to
be manually input to the app, the user interface should follow the norms for the particular platform.

Source of Requirement

Communities:
FGF,

YZ


i
-
focus Master Requirement Reference

R44

Other Relevant Profiles

Implications of MDD for Consumer Devices



Information Governance: PHRs & statutory systems

R26:

The content/data must be stored in a device
-
agnostic form

Description

To enable information to be
displayed on as many devices, and via as many systems as possible, it
should be stored in a device
-
agnostic form, and then rendered or transformed as necessary for
display on each device.

Explanation

This may require that data is rendered or transformed du
ring its delivery to/from the display device.
Consideration will need to be given as to whether this is best done in the device or in the server
infrastructure.

Source of Requirement

i
-
focus internal

i
-
focus Master Requirement Reference

R49

Other Relevant
Profiles

Implications of MDD for Consumer Devices



Stakeholder Requirements for
dallas

Interoperability Profile:

An Information A
rchitecture for Multi
-
platform
Services



20
/
28



R27:

Content must be delivered in an accessible manner

Description

To enable information to be delivered in an accessible manner (e.g. in braille for those with sight
difficulties), it should be stored in a de
vice
-
agnostic form, and then rendered or transformed as
necessary as part of the delivery process.

Explanation

Accessibility is a legal requirement under Equality Act 2010.

Source of Requirement

i
-
focus internal

i
-
focus Master Requirement Reference

R50

Oth
er Relevant Profiles

Implications of MDD for Consumer Devices



R28:

Data
-
sharing rules
should include consideration of the

application being
used


Description

Access to information should be dependent on the application being used having been authorised to
acc
ess that information.

Explanation

This is to ensure that rogue or simply insecure applications do not have access to sensitive
information. It is anticipated that each application will need to be digitally
-
signed

and then go
through some approval and authorisation process before being given access to certain classes of
information. A balance will need to be struck between security and the stifling of creativity and the
marketplace for apps and services.

Source of
Requirement

Communities:
YZ

i
-
focus Master Requirement Reference

R52

Other Relevant Profiles

Information Governance: PHRs & statutory systems

Stakeholder Requirements for
dallas

Interoperability Profile:

An Information A
rchitecture for Multi
-
platform
Services



21
/
28



R29:

Data
-
sharing rules
should include consideration of the

device being used

Description

Access to information should

be dependent on the device being used having been authorised to
access that information.

Explanation

This is to ensure that known security weaknesses in devices do not compromise the overall security
of the system. For example, a particular mobile device
operating system may be deemed insecure
enough to allow access to sensitive medical information, and thus it must be possible to block access
to that information from any application on any device using that operating system.

Source of Requirement

i
-
focus
internal

i
-
focus Master Requirement Reference

R53

Other Relevant Profiles

Information Governance: PHRs & statutory systems

R30:

System
s

must supp
or
t provision of forums and/or chat
-
rooms


Description

A number of the
dallas

communities wish to facilitate peer
-
to
-
peer support via online forums of one
form or another, so the information architecture needs to support such services.

Explanation

There will likely be a range of services, from those trying to i
ncrease virtual
(and
thus perhaps
physical)
social interaction to enhance mental wellbeing and reduce isolation
, to those providing
more targeted
support, coaching, educat
ional and informative content.

Source of Requirement

Communities:
LiU,FGF


i
-
focus

Master Requirement Reference

R54

Other Relevant Profiles

Framework for Identity and consent


Information Governance: PHRs & statutory systems

Stakeholder Requirements for
dallas

Interoperability Profile:

An Information A
rchitecture for Multi
-
platform
Services



22
/
28



R31:

System must support
shared
calendars and reminders

Description

A number of the
dallas

communities wish to develo
p informal care networ
ks, which will likely
benefit from shared calendars and reminders
, so the information architecture needs to support such
services.

The same features might also be useful for individuals to set reminders to take telehealth
readings, ta
ke medication and attend appointments.

Explanation

A shared calendar, with the ability to be reminded of commitments, is a fundamental building block
for informal care networks. The carers need to be able to co
-
ordinate their activities between
themselves
and the cared person.

Where an individual already has a personal calendar from another
provider (e.g. Google), it should be possible to integrate the
dallas

calendar so that the user is able
to see a unified view from that third
-
party calendar.

Source of R
equirement

Communities:
LiU,

YZ


i
-
focus Master Requirement Reference

R55

Other Relevant Profiles

Framework for Identity and consent


Information Governance: PHRs & statutory systems

R32:

System
s

should support video calls and conferencing



Description

A num
ber of the
dallas

communities wish to provide the facility for individuals to have video
consultations with professionals and with others in their informal care network. Mutual support
groups, etc., could be supported by use of video conferencing.

Explanation

The information architecture needs to support the delivery of video calls and conferences over as
diverse a range of devices as possible.

Source of Requirement

Communities:
LiU


i
-
focus Master Requirement Reference

R56

Other Relevant Profiles

Framework for Identity and consent


Stakeholder Requirements for
dallas

Interoperability Profile:

An Information A
rchitecture for Multi
-
platform
Services



23
/
28



Information Governance: PHRs & statutory systems

R33:

System
s

should support
video
-
based delivery of
training and information

Description

A number of the
dallas

communities wish to provide the facility for individuals to be
able to access
information, educational and coaching through the medium of on
-
demand video content.

Explanation

The information architecture needs to support the delivery of video material over as diverse a range
of devices as possible.

Source of Requireme
nt

Communities:
LiU,

FGF


i
-
focus Master Requirement Reference

R57

Other Relevant Profiles

Information architecture for Multi
-
platform service delivery




R34:

System
s

should support interfaces with voluntary
-

and private
-
sector service
providers

Description

To
day, health and care services, even if funded by the statutory sector, are often delivered by
private
-

or voluntary
-
sector service providers. It is important, therefore, that as well as connections
into statutory
-
sector IT systems, there are connections in
to the appropriate systems used by these
providers.

Explanation

It is likely that a wide variety of systems are used by these private
-

and voluntary
-
sector providers.
The information architecture should facilitate easy connections to the widest range.

Source of Requirement

Communities:
LiU,

FGF,

WN


i
-
focus Master Requirement Reference

R58

Other Relevant Profiles

Information Governance: PHRs & statutory systems

Stakeholder Requirements for
dallas

Interoperability Profile:

An Information A
rchitecture for Multi
-
platform
Services



24
/
28



R35:

Systems should allow booking of appointments


Description

Individuals should be able to book appointments to visit any of their formal carers via the
dallas

applications.

Explanation

The applications should allow the booking of appointments with GPs, consultants, social workers,
and any other appropriate professi
onal. Where the user has a calendar or diary (whether as part of
the
dallas

application suite or not), it should be possible for the appointments to be added to that
calendar.

Source of Requirement

Communities:
FGF


i
-
focus Master Requirement Reference

R59

Other Relevant Profiles

Framework for Identity and consent


Information Governance: PHRs & statutory systems

R36:

Systems should p
rovide access
to services
whenever and wherever
access is

needed, online and offline



Description

Users and their devices cannot

always guarantee to be online at all times
, and if they are online, they
may be sat behind a firewall
.

Explanation

Wherever possible, systems should be designed to use standard protocols over standard ports to
minimise problems with firewalls, and to all
ow working offline, with later synchronisation.

Source of Requirement

Communities:
YZ


i
-
focus Master Requirement Reference

MR6
0

Other Relevant Profiles


Stakeholder Requirements for
dallas

Interoperability Profile:

An Information A
rchitecture for Multi
-
platform
Services



25
/
28



R37:

Information from PHR
s

must

be available from within existing statutory
sector systems

Description

The information architecture should be designed to facilitate easy access to information from the IT
suystems used by statutory
-
sector providers.

Explanation

Professionals working in the statutory sector should not have to switch away from their usual
reco
rds system to access information from
dallas

systems; the information should be visible from
within their existing IT system.

Source of Requirement

i
-
focus scenario
s
: 8,10

Roleplay

i
-
focus Master Requirement Reference

MR6
4

Other Relevant Profiles

Information Governance: PHRs & statutory systems


R38:

Information
shared by the statutory sector into a PHR needs to be linked to
current professional practice

Description

To encourage sharing of information with
dallas

systems by professionals, the informati
on
architecture should make it as
simple and easy as possible for information to be shared; this is likely
to mean that existing information will need to be exported “as is”, rather than additional
information being required to be provided.

Explanation

For

example, test results, discharge forms, and other clinical correspondence needs to be able to be
imported in and/or interpreted from the standardises form in which it is held by the statutory sector
(e.g. HL7 CDA).

Source of Requirement

i
-
focus scenario
s
:

8,9,10,11

Roleplay

Stakeholder Requirements for
dallas

Interoperability Profile:

An Information A
rchitecture for Multi
-
platform
Services



26
/
28



i
-
focus Master Requirement Reference

MR6
5

Other Relevant Profiles

Information Governance: PHRs & statutory systems

R39:

Information released by the
statutory

sector must be

easy to understand by
individuals

and their

informal care network

Description

Information released by the statutory sector must be presented by the dallas application in a way
that is understandable to the layman.

Explanation

Clinical coding, for example, will need to be interpreted and mapped into language that is
unde
rstandable by the average person.

Source of Requirement

i
-
focus scenario
s
:

10,11
,12

Roleplay

Workshop

i
-
focus Master Requirement Reference

MR6
8

Other Relevant Profiles

Information Governance: PHRs & statutory systems

R40:

C
onsider
ation should be given to the
implications of
the
potential use of
the
smart meter comm
unications

infrastructure

Description

There is a possibility that the infrastructure being rolled
-
out by the energy industry as part of the
smart metering programme could be used to provide a
communications channel for telehealth
information. The implications of this need to be taken into account during the design of the
information architecture.

Explanation

As part of the smart metering roll
-
out, a very low bandwidth communications channel wil
l be
provided to every household’s electricity meter. Within each home, this communications channel
will be bridged onto a Zigbee “home area network”. It may be possible for telehealth or telecare
Stakeholder Requirements for
dallas

Interoperability Profile:

An Information A
rchitecture for Multi
-
platform
Services



27
/
28



devices, which also comply with the appropriate specificati
ons to have access to this communication
channel.

Source of Requirement

Workshop

i
-
focus Master Requirement Reference

MR7
5

Other Relevant Profiles


R41:

Systems must allow the collection of appropriate metrics to allow the long
-
term evaluation of the efficacy o
f the services offered

Description

Systems must be built in such a way as to allow not only the measurement of how many users are
using individual services, or parts of services, but also the long
-
term efficacy of these services. These
measurements will bo
th assist developers and service providers to develop appropriate applications
and services, but will also help inform the wider public health debate about how to best improve the
nation’s health. The systems must ensure that all data is effectively anonym
ised and /or the
appropriate informed consent is obtained from the individuals involved.

Explanation

The efficacy of the services provided by all

dallas

communities will be formally evaluated as part of
the

dallas

programme governance. The use and collecti
on of common measurement criteria across
all the communities will greatly ease the burden of making comparisons between the different
services offered across the different communities. In the longer term, the widespread adoption
of

dallas

services offers t
he potential for a very large dataset allowing the long
-
term efficacy of
various forms of early intervention and informal care.

Source of Requirement

Glasgow University

i
-
focus Master Requirement Reference

MR76

Other Relevant Profiles

Information architect
ure for Multi
-
platform service delivery

Information Governance:


PHRs & statutory systems

Framework for Identity and consent


Stakeholder Requirements for
dallas

Interoperability Profile:

An Information A
rchitecture for Multi
-
platform
Services



28
/
28