CITIZEN-SIDE HANDLING OF LIFE EVENT SERVICES
Hélder Gomes
1
, André Zúquete
2
and Gonçalo Paiva Dias
3
1
ESTGA, IEETA, Universidade de Aveiro, Aveiro, Portugal
2
DETI, IEETA, Universidade de Aveiro, Aveiro, Portugal
3
ESTGA, GOVCOPP, Universidade de Aveiro, Aveiro, Portugal
Keywords: E-government, Life Events, Privacy, Public Administration, Electronic Service Delivery.
Abstract: CHAPAS is a model for the provision of life event e-government services where no direct communication
between service providers exists. The citizen, assisted by a personal tool (Chappie), is responsible to gather
all the information required by the service he wants to apply to, possibly from services of other providers. In
this paper we discuss how life event e-government services are provided in CHAPAS, from the point of
view of the interactions of Chappie with services. The immediate advantage of this approach is that services
do not need to directly interact with each other to provide complex life event services, thereby citizens
having full control of the flow of their personal information.
1 INTRODUCTION
Life event e-government services are e-government
services organized according to episodes in
everyone’s life (Vintar et al., 2002). Examples are
the birth of a child, the purchase of a car, etc.
Typically, life event situations require the citizen to
interact with several public services, possibly from
several Public Administration (PA) departments.
Life events should not require the citizen to
understand the PA complexity in order to determine
the partial services required to satisfy their life event
situation (application sequence, the information each
requires and produces, etc.) (Dias and Rafael, 2007).
A common approach to life event service
provision is the integration of several partial services
into a single service to be offered to the citizen.
Implementations of this integration, illustrated in
Figure 1, basis on direct communication between PA
departments and on the coordination of the life-event
service by some department (Pappa and
Makropoulos, 2004; Vintar et al., 2002; Dias, 2011).
While this approach brings real benefits for the
citizen by reducing service complexity, e.g. by
requiring less citizen information, it also implies the
citizen loss of control over the flow of information
between PA departments, which may raise privacy
concerns.
Our approach to e-government life event service
provision (Gomes et al., 2011) has the potential to
improve citizen privacy by making the citizen aware
of whom and when, accesses his information. This is
achieved by allowing the citizen to control the
execution of life event services and the flow of
information between participating services, as
illustrated in Figure 2. This way, we avoid the need
of direct communication between PA departments,
for the purpose of service provision, at the cost of
bringing service complexity back to the citizen side.
Figure 1: Common model of life-event service provision
to citizens.
Our model, CHAPAS, can only be effective if
complexity is handled transparently by the citizen,
while under his control. This calls for a new way of
making e-government services publicly available
and a tool, running on the citizen computer, to assist
the citizen in his interactions with services and
providing some level of automation while preserving
citizen control of information flow. This tool is
Chappie (formerly egWallet (Gomes et al., 2011)).
The goal of this paper is to discuss the provision
565
Gomes H., Zúquete A. and Paiva Dias G..
CITIZEN-SIDE HANDLING OF LIFE EVENT SERVICES.
DOI: 10.5220/0003936805650570
In Proceedings of the 8th International Conference on Web Information Systems and Technologies (WEBIST-2012), pages 565-570
ISBN: 978-989-8565-08-2
Copyright
c
2012 SCITEPRESS (Science and Technology Publications, Lda.)
of life event services in CHAPAS from the point of
view of the interactions with services. We present
the related work in section 2 and an overview of
CHAPAS in section 3. In section 4 we discuss how
life event services are implemented and in section 5
we present details of how a service express which
documents it requires from citizens. In section 6 we
discuss some advantages and disadvantages of
CHAPAS after which we present the conclusions.
Figure 2: CHAPAS model for life-event service provision.
2 RELATED WORK
The offer of life event services typically implies the
integration of services from multiple independent
PA departments. This integration involves direct
communication between PA departments
(Tambouris et al., 2008). An approach for this
integration is modelling life event services as
workflows of existing services (Momotko et al.,
2007; Momotko et al., 2006; Oteniya et al., 2006;
Todorovski et al., 2007). Life event services are then
offered in active life event portals (Vintar and
Leben, 2002; Vintar et al., 2002; Todorovski et al.,
2006; Momotko et al., 2007; Tambouris and
Tarabanis, 2008). OneStopGov
(http://islab.uom.gr/onestopgov) and eGov
(http://www.egov-project.org) are examples of such
portals. They simplify citizens’ interaction with
services, but the citizen is not in control of the life
event service (it is managed by some government
agency) and does not control the dissemination of
his information through the involved PAs.
In (Dais et al., 2008) an integration platform is
proposed that gives the citizen full control over the
data kept in the platform and allows him to
personalize his interactions with PA services. The
citizen is even able to orchestrate personalized life-
event services, being the platform the central point
of communication between all involved services.
However, the platform is controlled by a “commonly
accepted and independent authority, constitutionally
and legislatively responsible for the protection of
citizens’ personal data” and not by the citizen. A
further enhancement to include Web2.0 interactions
is presented in (Dais et al., 2011).
In (Todorovski et al., 2007) it is defined a
general life event reference model that abstracts the
generic characteristics of life event service
workflows and classifies partial services in three
types: (i) support services, (ii) crucial services and
(iii) after-care services. Support services provide the
information required by crucial services. Crucial
services are those services that are always executed,
independent of the citizen circumstances. After-care
services are complementary services to which the
citizen may apply after life event service completion
as, for example, applying to a change maiden name
service after a wedding service. This classification
of partial services that compose life event service
workflows will be useful in our approach to the
provision of life event services.
3 OVERVIEW OF CHAPAS
At the basis of CHAPAS model is the premise that
no direct communication between PA departments is
needed for the provision of services to citizens
(Gomes et al., 2011). As a result, it is a citizen
responsibility the gathering of all the information
required to apply for the service he is in need. We
consider that this information is in the form of
documents gathered from provider organizations.
Other ways of providing information, like citizen
form based input information, are not considered at
this stage. Nevertheless, they should be handled
similarly if documents can be used as a base to
implement them.
A document is an identifiable self-describing
item of information in a XML format according to a
XML schema. The schema is typically defined by
the respective document issuing organization, or by
some standard organization and adapted by the
document issuer organization.
Documents are composed of attributes. An
attribute is an identifiable item of information inside
the document and corresponds to an element of the
document schema. Attributes are used to identify
items of information inside documents that for some
reason have to be dealt in a special way as, for
example, an attribute value that mandatorily must be
present in the document (e.g. owner name).
Attributes may correspond both to simple and
complex schema elements.
To facilitate the citizen gathering of the
documents required by a service, Service Providers
must provide some guidance. Such guidance is the
Required Documents Policy (RDP), that specifies
the documents a service requires and from where
WEBIST2012-8thInternationalConferenceonWebInformationSystemsandTechnologies
566
they may be obtained. The RDP must be publicly
available and in a format that computers can process.
Notice that Chappie is agnostic regarding the
meaning of the information it handles. Chappie role
is to gather documents from issuer services,
following their RDP, and provide them to consumer
services, also following their RDP, all under citizen
agreement. To fulfil this role, it has no need to take
decisions based on the meaning of the information in
the documents; it just follows the guidance in
services’ RDPs, always under citizen supervision.
Discovery of life event services is not in the
scope of CHAPAS. We consider that the citizen
discovers the life event service he needs, for
example, by browsing in some life event portal.
When the citizen selects (clicks) the desired life
event service, the browser activates Chappie which
will handle the life event service.
Figure 3: Interactions with services in CHAPAS.
An important pattern in CHAPAS, illustrated by
Figure 3, is the recursive dependency satisfaction
pattern of Chappie interaction with services. It
comprises four steps:
i. Obtaining the RDP;
ii. Gathering all required documents, from the
respective providers;
iii. Applying for the service (includes providing all
the required documents); and
iv. Obtaining the resulting documents at service
completion.
It applies to every service and is a key to understand
how life event services are provided in CHAPAS.
4 LIFE EVENT SERVICES
IN CHAPAS
A life event service workflow describes the
progression of steps (actions to execute, partial
services), from the start to the conclusion, that
results in the satisfaction of the life event service.
The progression may have branches, created by
forks, when some steps may perform in parallel, and
by decisions, when the selection of the next steps
depends on some condition, as citizen circumstances
like age, civil status, etc. The workflow is managed
by an organization and some of the workflow steps
may involve the execution of services (partial
services) possibly provided by other organizations.
Modelling life event services as workflows of
partial services is not well suited for CHAPAS. One
reason for such is the CHAPAS base principle of
avoiding direct communication between service
providers. In the workflow model, at least the life-
event service provider has to communicate with
partial service providers. Other reason is that the
workflow paradigm (a known progression of steps
from start to end) does not fit with the Chappie
dependency satisfaction pattern, where a service
provider specify which other services must be
previously executed to obtain the documents
required by the service the citizen is in need.
The partial service classification from the general
life event reference model (Todorovski et al., 2007)
is useful to our modelling approach to life event
services. It identifies Crucial Services as a type of
partial services that always execute in life event
service workflows. If we do not consider after-care
services (a type of service not always considered in
the modelling of life event services (Todorovski et
al., 2007)), the last partial service executed in life
event services workflows is always a crucial service.
This makes crucial services good entry points for the
execution of life event services in CHAPAS, i.e., the
service to which the citizen first applies. The
execution of the life event service will then evolve
by recursively applying the dependency satisfaction
pattern to the entry-point service and to all partial
services that must be contacted to obtain the
documents required by the entry-point service.
The recursive dependency satisfaction pattern
implies that Chappie, based on the RDPs collected
from each partial service, builds a dependency graph
of partial services, illustrated in Figure 4, starting
from the entry-point service. Its execution satisfies
the life event service.
Typically, the set of documents required by a
service depends on a set of circumstances as, for
example, the citizen age (minor, senior, etc.), civil
status (single, married, etc.), etc. Therefore, a service
RDP must include circumstance-based decision rules
to evaluate which documents a specific citizen must
provide. Since documents are obtained from partial
services, circumstances implicitly also determine to
which other services the citizen must apply to obtain
CITIZEN-SIDEHANDLINGOFLIFEEVENTSERVICES
567
the required documents.
It is important to notice that an RDP refers to a
single service. No single service has a global view of
all partial services involved in a life event service, as
it occurs with workflows. Only Chappie, after
building the dependency graph, has this global view,
but tailored to a specific citizen. This dependency
graph is equivalent to the corresponding life event
service workflow pruned of all branches that do not
apply to the specific citizen circumstances.
Figure 4: Life event service dependency graph example
showing its building direction and its execution direction.
5 REQUIRED DOCUMENTS
POLICY
The RDP is a statement describing the requirements
of a service. Generically, it specifies (i) the
documents the citizen must present, including the
required attributes on each document and the
services from where each document may be
obtained, (ii) the circumstances affecting which
documents the service may require, and (iii) the
circumstance-based decision rules whose evaluation
determine, for a specific citizen, the documents to be
present. Each of these sections of the RDP is further
analysed in the next sections.
5.1 Documents
The Documents section specifies the documents
required by the service providing the RDP. For each
document it must identify the its type, the attributes
requiring special actions, and the issuing services.
The document type specifies a unique identifier
for the type of the document (e.g. a birth certificate)
and the schema to which the document must comply.
Document attributes that must be subject to some
special action by the document issuer (e.g. to omit or
encrypt their values), may be specified. The
specification must identify the respective item of
information in the document and the special action
to be applied. The specification of an attribute action
depends on the specific action. For example, if
ciphering is required then, along with the action
identifier, an encryption algorithm and a key must be
specified. If the special action is to omit the attribute
value, only the action identifier must be specified.
A document specification may contain the
specification of the services that are able to issue the
document. Two possibilities might occur: at least
one very well known issuer exists, in which case it
must be precisely identified with the contact point
from where to obtain the respective RDP, or only the
types of providers, e.g. municipalities, insurance
companies, etc., are known. In this latter case, a list
of types of providers is specified. Both types of
provider definitions may coexist and it’s a citizen
responsibility to indicate the specific provider from
where the document must be gathered. Directories of
services may be used, in the latter case, to assist the
citizen in the selection of the service to be contacted.
This directory search is not addressed in this paper.
5.2 Circumstances
In the Circumstances section the circumstances that
influence which required documents a citizen must
present when applying for the service are specified.
We consider two types of circumstances: those
whose values are given by the citizen and those that
correspond to attributes in documents. In the first
case, since Chappie is agnostic to the meaning of the
circumstances, the RDP must include a text question
and a value data type in order to handle the interface
with citizen to get the circumstance value.
The latter case requires accessing a document
and read the attribute with the circumstance value.
The document must be defined in the Documents
section of the RDP. This latter case may also require
the previous gathering of the document from its
respective service provider.
5.3 Decision Rules
Decision rules are Boolean expressions that specify
the dependency of the required input documents on a
set of circumstances. Each required document must
be clearly associated with a Boolean expression.
Chappie must evaluate them to determine which
documents a specific citizen is required to present,
i.e., which documents must be gathered.
To evaluate a Boolean expression, Chappie must
obtain the circumstances’ values. As values are
obtained directly from the citizen or from attributes
WEBIST2012-8thInternationalConferenceonWebInformationSystemsandTechnologies
568
in documents, which might have to be first gathered
from the respective service providers, evaluation
rules were defined to avoid the risk of both
bothering the citizen with questions not applying to
its specific situation or the request of unnecessary
documents. Also a XML language was defined to
express the decision rules.
6 DISCUSSION
In previous sections we briefly presented CHAPAS
and how it implements life event services. It is based
on a mechanism where service providers define the
documents each service requires and a citizen tool
(Chappie) that agnostically and recursively gathers
and provides those required documents from and to
services respectively, in order to fulfil the life event
service the citizen is in need. Since it runs on a
citizen computer, the citizen is in control of the
disclosure of his information. This is a clear benefit
for the citizen as it promotes his privacy.
CHAPAS also brings benefits for organizations
as the costs of e-government interoperability may be
reduced. Interoperability projects are very complex
and very risky. Three levels of interoperability have
been defined: technical, semantic and organizational
interoperability (IDABC, 2004). The organizational
level is the harder to achieve, as it involves political
and hierarchical issues. In CHAPAS organizational
interoperability is simplified as no dramatic changes
are required on organizations internal processes:
they keep interacting with Chappie as they used to
do with individual citizens and avoiding the need to
cooperate with other service providers in the
development of transversal workflows. Only
technical and semantic interoperability is required,
but they are required in any interoperability project.
There are some issues that complicate life event
service provision in CHAPAS, which we discuss
now. One is services’ asynchrony. While there are
services that immediately execute and complete,
producing their intended outputs, other exists that
may take long, and irregular, time intervals to
complete. One reason for this is the human decisions
in the service execution loop. Since services’ outputs
are not produced immediately at service request and
the requesters are not willing to wait large amounts
of time for the service completion, Chappie must
handle asynchronous services.
The failure of service interactions is also an
issue. Unhappily, not every interaction with services
always ends successfully. Many reasons exist for a
failure. As the failing interaction may occur in the
context of a set of interactions that constitute a life
event service, it is important to discuss the
consequences of such failure and the actions to take
to remedy the failure. This type of problems is
typically addressed using transactions, where a set of
operations is made permanent if all complete
successfully (commit), or undone if at least one fails
(rollback). Transactions are difficult to accept in
CHAPAS because it is the citizen who controls the
transaction, and that would imply its ability to, in
case of failure, undo services already obtained.
Another issue is identity management. It is a
normal practice to require citizen authentication to
obtain the desired service. Several authentication
mechanisms can be used, e.g. passwords and smart
cards. Authentication has the potential to become
problematic in CHAPAS if most services handle
citizen authentication independently. As many
partial services may participate in a single life event
service, possibly from different service providers,
multiple citizen authentications may be required (in
the worst case as many as the number of partial
services), and this will not be practical. To avoid
this, it is recommended that service providers adhere
to, or organize themselves as, identity federations.
An identity federation is an agreement made by a
group of organizations so identities from one
organization are accepted by the remaining
organizations (Jøsang et al., 2007). An interesting
feature they provide is single-sign-on, which allows
a user to seamlessly access multiple services without
having to continuously authenticate.
An important aspect to consider is the flow of
identity information from the identity provider to the
identity consumer that must follow the same pattern
of document flow in CHAPAS, i.e., it must go
through the citizen and under his control.
As demonstrated, the CHAPAS model is well
suited to support the provision of life event services
to citizens, preserving citizen’s control of the flow of
information and avoiding direct communication
between service providers. This does not completely
avoids the need for service providers to
communicate, since not all business transactions in
the public administration are performed in the scope
of the provision of services to citizens or, being so,
are meant to be controlled by the citizen (e.g. some
citizen criminal information might have to be shared
without the awareness of that citizen).
7 CONCLUSIONS
In this paper we presented how life event services
CITIZEN-SIDEHANDLINGOFLIFEEVENTSERVICES
569
are implemented in the CHAPAS model. The
fundamental characteristics of the model are
discussed, such as (i) the centralization of the
information flow between PA departments in the
citizen (more properly in a citizen tool, Chappie,
running in a citizen computer, that agnostically and
under citizen control gathers and provides citizen
information from/to services, respectively), and (ii)
the guidance that each service provides, in the form
of a Required Documents Policy, to assist Chappie
in the determination of the documents that a specific
citizen must provide (based on citizen
circumstances, either extracted from documents’
attributes or entered by the citizen upon request) and
its gathering from issuer services.
Advantages and disadvantages of life event
services in CHAPAS are discussed and we
concluded that despite some highlighted difficulties,
it still is advantageous for the citizen, as it brings
him more control over the flow of his information,
and for PA management, as it does not demand for
dramatic changes on their internal processes.
ACKNOWLEDGEMENTS
This work was partially funded by FEDER through
the Operational Program Competitiveness Factors -
COMPETE and by National Funds through FCT -
Foundation for Science and Technology in the
context of the project FCOMP-01-0124-FEDER-
022682 (FCT reference PEst-C/EEI/UI0127/2011)
and PROTEC scholarship SFRH/PROTEC/
49849/2009.
REFERENCES
Dais, A., Nikolaidou, M. & Anagnostopoulos, D., 2011.
OpenSocialGov: A Web 2.0 Environment for
Governmental E-Service Delivery. In LNCS 6866.
Springer.
Dais, A. et al., 2008. Introducing a Public Agency
Networking Platform towards supporting Connected
Governance. In EGOV 2008. Turin,Italy.
Dias, G. P., 2011. Q-Model: um modelo bidimensional de
maturidade para o e-government. RISTI, (7).
Dias, G.P. & Rafael, J., 2007. A simple model and a
distributed architecture for realizing one-stop e-
government. ECRA, 6(1).
Gomes, H., Zúquete, A. & Dias, G. P., 2011. Citizen
Controlled Exchange of Information in E-government.
In WEBIST 2011. Noordwijkerhout, The Netherlands.
IDABC, 2004. European Interoperability Framework for
Pan-European eGovernment Services (EIF), Version
1.0, European Commision.
Jøsang, A., Zomai, M. A. & Suriadi, S., 2007. Usability
and Privacy in Identity Management Architectures. In
ACSW ’07. Darlinghurst, Australia.
Momotko, M. et al., 2007. An Architecture of Active Life
Event Portals: Generic Workflow Approach. In LNCS
4656. Springer.
Momotko, M. et al., 2006. Towards Implementation of
Life Events Using Generic Workflows. In eGOV06.
Brunel University, London.
Oteniya, O., Janowski, T. & Ojo, A., 2006. Government-
Wide Workflow Infrastructure-Enabling Virtual
Government Organizations. In IFIP 224. Springer.
Pappa, D. & Makropoulos, C., 2004. Designing a
Brokerage Platform for the Delivery of E-government
Services to the Public. In LNCS 3035. Springer.
Tambouris, E. & Tarabanis, K., 2008. A dialogue-based ,
life-event oriented , active portal for online one-stop
government: The OneStopGov platform. In DG.O
2008. Montreal, Canada.
Tambouris, E. et al., 2008. The role of interoperability in
eGovernment applications: An investigation of
obstacles and implementation decisions. In ICDIM
2008. London: IEEE.
Todorovski, L., Kunstelj, M. & Vintar, M., 2007.
Reference Models for e-Services Integration based on
Life-Events. In LNCS 4656. Springer.
Todorovski, L. et al., 2006. Methodology for Building
Models of Life Events for Active Portals. In EGOV
2006. Cracow, Poland.
Vintar, M. & Leben, A., 2002. The Concepts of an Active
Life-Event Public Portal. In LNCS 2456. Springer.
Vintar, M., Kunstelj, M. & Leben, A., 2002. Delivering
Better Quality Public Services Through Life-Event
Portals. In 10th NISPAcce Annual Conference.
Cracow, Poland.
WEBIST2012-8thInternationalConferenceonWebInformationSystemsandTechnologies
570
