A Comprehensive Approach to Compliance Management in
Inter-organizational Service Integration Platforms
Laura Gonz
´
alez and Ra
´
ul Ruggia
Instituto de Computaci
´
on, Facultad de Ingenier
´
ıa, Universidad de la Rep
´
ublica,
J. Herrera y Reissig 565, Montevideo, Uruguay
Keywords:
Compliance Management, Integration Platforms.
Abstract:
Organizations increasingly collaborate with each other using the service-oriented approach. Such collabora-
tion is usually supported by integration platforms which process all inter-organizational service interactions.
In turn, these collaborative environments have to satisfy compliance requirements originating from different
sources (e.g. laws, standards). This paper proposes a comprehensive approach to compliance management in
inter-organizational service integration platforms. The approach defines a compliance management life cycle
for this context and a common framework to homogeneously manage compliance issues in different areas.
1 INTRODUCTION
Organizations increasingly collaborate with each
other following the service-oriented approach. This
has led to large-scale systems which interconnect the
software applications of different, autonomous and
geographically distributed organizations (Gonz
´
alez
and Ruggia, 2015). Such systems are usually sup-
ported by integration platforms which are specialized
infrastructures providing connectivity and mediation
capabilities to facilitate the integration of applica-
tions (Golluscio et al., 2016). By these means, rather
than interacting directly, organizations communicate
by exchanging messages through the platform. These
messages may be processed by mediation flows which
have the goal of solving integration issues by applying
operations such message transformation and routing.
These collaborative environments have to sat-
isfy compliance requirements established by various
sources (e.g. laws), concerning different areas (e.g.
quality of service) and which may apply to each orga-
nization or to the whole inter-organizational system
(Elgammal et al., 2016). Some aspects of these re-
quirements may impact on the interactions between
organizations. In these cases, integration platforms
mechanisms (e.g. transformations) can be used to
deal with such requirements.
Taking this approach, solutions for controlling
compliance requirements have been proposed in ar-
eas such as quality of service (QoS) (Gonz
´
alez and
Ruggia, 2011), data quality (DQ) (Pidre et al., 2017)
and data protection (DP) (Gonz
´
alez et al., 2016).
The common approach in these proposals is: i) pro-
cessing messages exchanged through the platform, ii)
checking if they comply with the established require-
ments, and iii) in case requirements are not met, tak-
ing actions leveraging integration platforms mecha-
nisms (e.g. transformations).
This work goes a step forward by proposing a
comprehensive approach to compliance management
in inter-organizational service integration platforms.
The approach defines a compliance management life
cycle for this specific context and a common frame-
work to homogeneously manage compliance issues.
The rest of the paper is organized as follows. Sec-
tion 2 shows a motivational scenario. Section 3 char-
acterizes the working context. Section 4 describes the
proposed approach. Section 5 analyses related work.
Section 6 presents conclusions and future work.
2 MOTIVATIONAL SCENARIO
The scenario is inspired in the Uruguayan e-
Government Interoperability Platform (eIP)
(Gonz
´
alez et al., 2012) which was developed by
the Uruguayan e-Government Agency (AGESIC).
The eIP allows and facilitates government organiza-
tions to offer business services leveraging the web
services technology. These web services, which
are usually hosted on organizations’ infrastructure,
are exposed and invoked through proxy services
688
González, L. and Ruggia, R.
A Comprehensive Approach to Compliance Management in Inter-organizational Service Integration Platforms.
DOI: 10.5220/0006915406880696
In Proceedings of the 13th International Conference on Software Technologies (ICSOFT 2018), pages 688-696
ISBN: 978-989-758-320-9
Copyright © 2018 by SCITEPRESS Science and Technology Publications, Lda. All rights reserved
deployed on the eIP. This way, the eIP is able to
process all service invocations and apply them
security controls as well as mediation operations.
For example, Figure 1 presents how web services
messages are processed by the eIP when the Ministry
of Public Health (MSP) invokes, via a proxy service,
the Basic Information Service provided by the Civil
Identification National Directorate (DNIC). This
service receives a citizen identifier and returns basic
information about citizens (e.g. their names).
Figure 1: e-Government Interoperability Platform (eIP).
The eIP is not only intended to aid general purpose
e-government operations but also to contribute to the
development of supporting platforms in strategic sec-
tors, such as health. Indeed, the Uruguayan e-Health
Platform (Abin et al., 2015), which supports the Na-
tional Electronic Health Record (EHR) in Uruguay,
leverages and exposes services in the eIP.
2.1 Business Services
For the context of the motivational scenario, six busi-
ness services are considered.
The Basic Information Service, provided by
DNIC, makes available basic information about citi-
zens. It has one synchronous request-response opera-
tion, named GetPersonById which, given a national
identification number (NIN), returns data including
names, last names, sex, birthdate and nationality.
The Passport Service, also provided by DNIC, al-
lows citizens scheduling an appointment to get or re-
new their passport. It has two synchronous request-
response operations. The GetAvailableDates opera-
tion receives a NIN and returns a list of available dates
and times for the appointment. The ConfirmAppoint-
ment operation allows confirming the appointment by
receiving a NIN, a date and a time, and returning
whether or not the appointment was confirmed.
The Judicial Records Certificate Service, provided
by the Technical Police National Directorate (DNPT)
allows checking if a citizen has judicial records. It has
one asynchronous request-response operation, named
HasJudicialRecords, which receives a NIN and re-
turns if the citizen with this NIN has judicial records.
The Local EHR Service, provided by Health Ser-
vice Providers, allows providers to obtain clinical
documents stored within other providers. It has one
synchronous request-response operation, named Ob-
tainDocument, which receives a document identifier
and returns the clinical document associated with it.
The Procedures Status Service, provided by
AGESIC, allows organizations to notify AGESIC the
status of e-government procedures so it can be com-
municated to citizens (e.g. through a portal). It has
one one-way operation, named NotifyProcedureSta-
tus, which receives a NIN, a procedure identifier, an
status and complementary information.
The Disability Records Service, provided by the
Ministry of Social Development (MIDES), allows
checking if citizens have disabilities. It has one syn-
chronous request-response operation, named HasDis-
ability, which receives an NIN and returns if the citi-
zen is registered as having a disability.
2.2 Compliance Requirements
Compliance requirements arising in the motivational
scenario are organized in four areas: QoS, Data Qual-
ity (DQ), Data Protection (DP) and Collaborations.
QoS requirements concerns aspects such as inter-
operability, performance and dependability. Interop-
erability requirements are mainly defined by AGESIC
and Salud.uy (i.e. the e-health initiative in Uruguay).
AGESIC requires web services to comply with SOAP
1.1 and with the WS-I Basic Profile 1.1. Salud.uy re-
quires EHR services to use HL7 Messaging Standard
Version 2.5 for exchanging clinical information and
HL7V3 Clinical Document Architecture (CDA) R2
for structuring clinical documents. Performance re-
quirements are mainly defined by organizations when
they publish services in the eIP. Regarding through-
put, the Basic Information Service is expected to han-
dle seven transactions per second and the Disability
Records Service ten transactions per second. In addi-
tion, this last service is expected to have a response
time of five seconds. Dependability requirements are
also defined by organizations when they publish ser-
vices. The Basic Information Service and the Disabil-
ity Records Service are expected to have an availabil-
ity of 99% and 90%, respectively. Within the motiva-
tional scenario the succesability (i.e. the percentage
of responses returned without unhandled errors) of all
services is expected to be greater than 80%.
DQ requirements concerns aspects such as in-
teroperability, completeness, accuracy and consis-
tency (Pidre et al., 2017). Regarding interoperabil-
ity, AGESIC requires the use of reference data mod-
els for exchanging data of people and addresses.
Salud.uy requires the use of SNOMED-CT and ICD-
10 for specifying clinical information such as causes
of death. With respect to completeness, Salud.uy es-
tablished minimal data sets to register specific clini-
A Comprehensive Approach to Compliance Management in Inter-organizational Service Integration Platforms
689
cal events such as centralized urgent emergency med-
ical consultations. AGESIC also established syntac-
tic accuracy requirements (e.g. countries should be
specified using the Alpha-3 codes of the ISO 3166-1
standard). It also established allowed values for civil
status, sex, gender and citizenship, among others. Re-
garding consistency, there are relational integrity re-
quirements (e.g. the locality and department of an ad-
dress should be consistent with each other as well as
the disease and sex specified in a clinical document).
There are also temporal integrity requirements (i.e.
data should be consistent over time).
DP requirements concerns aspects such as privacy,
integrity and confidentiality. Regarding privacy, orga-
nizations are not allowed to share sensitive personal
data of citizens unless they provide explicit consent
for that. With respect to integrity, Salud.uy requires
Health Service Providers to sign the clinical docu-
ments they provide with advanced digital signature.
Finally, in order to ensure confidentiality, data regard-
ing the racial origin and sex of citizens are required to
be encrypted when they are exchanged.
Collaboration requirements originate when two or
more organizations agree to carry out collaborative
processes. For example, the Passport Application col-
laboration allows citizens to get or renew their pass-
port and it involves three organizations: AGESIC,
DNIC and DNPT. The collaboration starts when a
citizen requests an appointment through the portal.
AGESIC interacts with DNIC, through the Passport
Service, to get the appointment and DNIC returns a
list of available dates and times. After the citizen se-
lects a date and a time, AGESIC confirms these data
to DNIC via the Passport Service. DNIC checks if the
citizen has judicial records by interacting with DNPT
through the Judicial Records Certificate Service. If
the citizen has judicial records or if DNIC does not re-
ceive a response from DNPT in twenty four hours, the
appointment is canceled and DNIC informs AGESIC
of this decision via the Procedure Status Service. Oth-
erwise, DNIC informs AGESIC if the citizen could
get or renew the passport. For this collaboration two
requirements are considered: i) messages should flow
as specified in the collaboration, and ii) the collabora-
tion has to be completed in less than one month.
3 WORKING CONTEXT
This section characterizes the working context taken
as starting point for the proposed approach. This
working context constitutes a generalization of the
motivational scenario presented in Section 2.
The working context comprises organizations
collaborating through an integration platform via
service-based interactions (Gonz
´
alez and Ruggia,
2015). To this end, as shown in Figure 2, business
services running in organizations (e.g. BS1) are ex-
posed through proxy services (e.g. S1) deployed on
the integration platform. For the context of this work,
business and proxy services are assumed to be imple-
mented as web services.
Figure 2: General Description of the Working Context.
When an organization (e.g. Organization A) in-
vokes a business service provided by another organi-
zation (e.g. BS1 provided by Organization B), ser-
vice messages (e.g. SOAP messages) are exchanged
through the platform between these organizations.
Service messages are first processed by a connector
which creates platform-specific messages containing
a service message and message properties (e.g. a mes-
sage id). Service messages can include business data
elements. Messages properties specify the origin (e.g.
an organization), destination (e.g. a service) and iden-
tification related data (e.g. a message id). These prop-
erties may be obtained from the service message or
may be automatically generated by the platform (e.g.
message ids). Message properties allow specifying,
for example, that a message is sent by a user (e.g.
smith) belonging to an organization (e.g. Organiza-
tion A) in order to invoke a service (e.g. S1) provided
by other organization (e.g. Organization B). The plat-
form processes these messages and may apply them
different mediation operations.
The integration platform is hosted on a trusted
party and managed by platform administrators. Ad-
ministrators maintain data required by the platform in
order to operate (e.g. integrated organizations, ser-
vices provided by organizations, the operations each
service has, collaborations, data models).
3.1 Working Context Concepts
The main concepts of the working context are: or-
ganizations, services, operations, message types, col-
laborations, data models and data elements. Figure 3
shows these concepts as well as their relationships.
ICSOFT 2018 - 13th International Conference on Software Technologies
690
Figure 3: Working Context Concepts.
Organizations provide services and consume oper-
ations of services exposed through the platform. For
example, DNPT provides the Judicial Records Cer-
tificate service which has the operation HasJudicial-
Records that is consumed by DNIC. Services have
one or more operations which can be either request-
response operations (e.g. HasJudicialRecords) or
one-way operations (e.g. NotifyProcedureStatus).
Data models specify the structure of data (e.g. per-
son) exchanged in invocations. A data model (e.g.
person model) may use others (e.g. address model)
and comprises at least one data element (e.g. name).
Message types specify the structure of messages that
organizations exchange when invoking service opera-
tions. Message types may include data elements de-
fined within data models.
Organizations participate in collaborations which
comprise one or more service operations (e.g. the
Passport Application collaboration comprises the op-
erations: GetAvailableDates, ConfirmAppointment,
NotifyProcedureStatus and HasJudicialRecords).
3.2 Business Transactions Concepts
At runtime, organizations carry out business trans-
actions by collaborating with each other through the
platform. Figure 4 presents the main concepts related
to business transactions. The concepts in gray were
already introduced in Figure 3 and their relations are
not included in order to simplify the diagram.
Business transactions can be either operation
transactions or collaboration transactions. An oper-
ation transaction corresponds to the invocation of an
operation by a client and can be either a request-
response transaction or a one-way transaction. Op-
eration transactions comprise one or more platform
Figure 4: Business Transactions Concepts.
messages which may include a service message of a
specific type. A collaboration transaction corresponds
to the execution of a collaboration and it includes one
or more operation transactions.
4 COMPLIANCE APPROACH
This section presents the compliance management
approach for inter-organizational service integration
platforms which: i) defines a life cycle for compliance
management within the working context presented in
Section 3 and, ii) defines a common framework, com-
prising conceptual models and components, in order
to homogeneously manage compliance issues.
4.1 General Description
Figure 5 presents a high-level description of the pro-
posed approach showing the new compliance related
actors and how the compliance management system
extends integration platforms to support the proposed
compliance management life cycle.
Compliance actors are either Compliance Busi-
ness Experts or Compliance Technical Experts. Com-
pliance business experts are responsible for the busi-
ness related aspects of compliance management. In
particular, they are aware of the applicable reg-
ulations, how these regulations impact on inter-
organizational interactions carry out through the plat-
form and what actions (e.g. sanctions) should be
taken in case these regulations are not met. Compli-
ance technical experts are responsible for the techni-
cal related aspects of compliance management. For
instance, they know how to setup technical compli-
ance mechanisms within the platform (e.g. the avail-
able system level compliance actions) and how to im-
A Comprehensive Approach to Compliance Management in Inter-organizational Service Integration Platforms
691
Figure 5: Compliance Management Approach.
plement solutions which control (e.g. monitor, en-
force) compliance within the platform.
The compliance management life cycle proposed
in this work comprises four phases: Compliance
Setup, Compliance Engineering, Compliance Control
and Compliance Analysis. The Compliance Manage-
ment System extends inter-organizational integration
platforms in order to deal with compliance manage-
ment within them. As shown in Figure 5, it comprises
four subsystems geared towards supporting the four
phases of the compliance life cycle.
4.2 Compliance Setup
Compliance Setup involves managing elements that
allow building compliance solutions and is supported
by the Compliance Setup Subsystem. In particular,
this subsystem allows managing system level compli-
ance actions, business level compliance actions and
external compliance services.
System Level Compliance Actions are actions
taken within the platform (e.g. transforming a mes-
sage) in order to enforce compliance or to repair a
situation where compliance is not met. For example,
a ”Remove Data Values” action may remove values
of data elements from a message.
Business Level Compliance Actions (e.g. sanc-
tions) are triggered by the platform when compliance
with regulations is controlled. They have a business
connotation as opposed to system level actions. An
example of a business level action is a monetary sanc-
tion to an organization.
External Compliance Services provide access to
data attributes (e.g. additional information of a user)
or functionality (e.g. validation functions) required
for compliance control. Some examples of external
services are: ”User Roles” (it returns the roles of a
user) and ”Alpha 3 - Correct” (it returns true if the
country is specified using Alpha 3).
4.3 Compliance Engineering
Compliance Engineering focuses on the development
of compliance solutions for controlling compliance
within the platform and it is supported by the Compli-
ance Engineering Subsystem. Compliance engineer-
ing comprises Compliance Modeling, Compliance
Specification, Compliance Development and Com-
pliance Deployment which are supported by specific
subsystems of the compliance engineering subsystem.
4.3.1 Compliance Modeling
Compliance Modeling involves managing compli-
ance aspects relevant for the integration platform.
In particular, compliance models define the relevant
compliance areas (e.g. QoS, DQ) and relevant char-
acteristics within these areas (e.g. availability, com-
pleteness). Compliance requirements specify general
requirements (e.g. response time greater than 1ms)
applying to specific objects types (e.g. operation, ser-
vice). Compliance profiles define a set of require-
ments for the same object type, in order to make more
agile the specification of a set of requirements for dif-
ferent objects of the same type. Regulations are also
managed, which allows relating requirements with the
regulations from which they come from. Compliance
modeling is mainly performed by compliance busi-
ness experts. The main concepts related to compli-
ance modeling are presented in Figure 6.
Compliance Object Types represent the types of
objects that are target of compliance control. The ob-
jects types identified in this work as well as exam-
ples of requirements for these types, within the moti-
vational scenario, are:
Platform: SOAP web services must comply with
the WS-I Basic Profile 1.1.
Organization: The average availability of services
provided by AGESIC must be greater than 95%.
ICSOFT 2018 - 13th International Conference on Software Technologies
692
Figure 6: Compliance Modeling Concepts.
Collaboration: Messages exchanged within the
Passport Application collaboration should follow
the specified message flow.
Service: Racial origin data must be returned en-
crypted by the Basic Information Service.
Operation: The response time of the HasDisabil-
ity operation must be less than 5 seconds.
Message Type: The civil status data included in
the message type associated with the getPerson-
ById operation should be syntactically correct.
Compliance Areas represent broad areas of com-
pliance (e.g. QoS, DQ). Compliance areas comprise
Compliance Dimensions which capture a high level
compliance facet (e.g. performance) within an area.
Compliance Factors represent a particular aspect of a
dimension (e.g. response time). Examples of compli-
ance areas and dimensions originating from the mo-
tivational scenario are: i) Quality of Service (dimen-
sions: Performance, Dependability, Interoperability),
ii) Data Quality (dimensions: Accuracy, Complete-
ness, Consistency, Interoperability), iii) Data Protec-
tion (dimensions: Privacy, Integrity, Confidentiality),
and iv) Collaborations (dimensions: Collaboration
Messages, Collaboration Execution).
Examples of compliance factors in the QoS area
are: i) for performance: Response Time, Through-
put; ii) for dependability: Availability, Succesability;
iii) for interoperability: Standards Adoption / Confor-
mance. Examples of compliance factors in the DQ
area are: i) for accuracy: Syntactic Correctness, Pre-
cision; ii) for completeness: Density, Coverage; iii)
for consistency: Relational / Time Integrity; iv) for in-
teroperability: Standards / Recommendations Adop-
tion. Examples of compliance factors in the DP area
are: i) for privacy: Message / Data Element Privacy;
ii) for integrity: Message / Data Element Integrity; iii)
for confidentiality: Message / Data Element Confi-
dentiality. Examples of compliance factors in the Col-
laborations area are: i) for messages: Messages Flow;
ii) for collaboration execution: Processing Time.
Compliance Controls (e.g. max response time) are
used to control compliance factors for a specific com-
pliance object type (e.g. service). They have configu-
ration properties (e.g. response time in seconds) that
allow reusing the control. Within the motivational
scenario, a max response time control may be used
for all the response time requirements by specifying
the specific value for each service.
Compliance Requirements represent requirements
that can be applied to different objects of the same
type (e.g. availability of a service greater than 90%).
A compliance requirement is based on a compliance
control (e.g. availability of a service greater than a
percentage value) and defines a value for all its con-
figuration properties (e.g. percentage value = 90%).
Compliance Profiles group compliance require-
ments for the same object type (e.g. service) with the
goal of facilitating the specification of a group of re-
quirements for different objects of the same type.
Finally, compliance requirements originate from
regulations (e.g laws, agreements).
4.3.2 Compliance Specification
Compliance Specification involves the specification
of compliance requirements (e.g. response time
greater than 1ms) for concrete compliance objects
(e.g. Basic Information Service). Requirements are
specified in agreements which may define actions
(e.g. notify an administrator) for different situations
(e.g. if requirements are not met). Figure 7 presents
the main concepts related to compliance specification.
Object Compliance Requirements (i.e. compli-
ance requirements applied to concrete objects) are
specified in Compliance Agreements in which at least
one organization participates. For instance, when an
organization publish a service in the platform, it can
establish an agreement where it commits to provide
an availability of 99% by leveraging the requirement
”Availability greater than 99%”.
Compliance Agreements also comprise Agree-
ment Actions which specify the actions to be taken
in case the specified Compliance Conditions for these
actions hold. Agreement actions are based on Busi-
ness Level Compliance Actions (e.g. sanctions, in-
centives) provided by the platform. An agreement
action should specify a value for each configuration
property of the associated compliance action.
A Comprehensive Approach to Compliance Management in Inter-organizational Service Integration Platforms
693
Figure 7: Compliance Specification Concepts.
In the context of the motivational scenario, a com-
pliance agreement may be set up between DNIC,
DNPT and AGESIC in order to control the compli-
ance requirements of the Passport Application Col-
laboration. Compliance conditions may establish that
if the specified message flow for the collaboration is
not followed more than three times at day, a monetary
sanction has to be issued for the three organizations.
4.3.3 Compliance Development
Compliance Development involves defining how
compliance requirements have to be controlled within
the integration platform. In particular, this comprises
managing compliance strategies (e.g. reactive, pre-
ventive) and compliance methods (e.g. enforce pri-
vacy). This work takes a policy-based approach to
control compliance (Gonz
´
alez and Ruggia, 2017),
that is, compliance methods are specified in terms of
compliance policies. Figure 8 presents the main con-
cepts related to compliance development.
Compliance Method Templates are blueprints for
implementing compliance controls (e.g. regarding
service availability) within the platform. They are
specified in terms of Compliance Policy Templates.
Neither the methods templates nor the policy tem-
plates are completely specified given that they depend
on the specific requirement (e.g. availability greater
than 90%) and the specific object (e.g. Disability
Records Service) to which the requirement applies.
Compliance Methods control compliance require-
ments for specific compliance objects in the platform.
They may be generated from compliance method tem-
plates according to the values of configuration prop-
erties for the associated compliance control. These
Figure 8: Compliance Development Concepts.
methods comprise a set of Compliance Policies which
may also be generated from policy templates associ-
ated with the method template. Also, a compliance
developer may implement compliance methods from
scratch or may modify the generated methods and
policies in order to suit the required needs.
Compliance methods and method templates may
follow Compliance Strategies (e.g. reactive) which
provide additional information about them.
4.3.4 Compliance Deployment
Compliance Deployment involves installing and let-
ting operational, in the platform, the compliance el-
ements defined in the setup phase (e.g. system-level
actions) and in the previous sub-phases of the engi-
neering phase (e.g. agreements, policies). In particu-
lar, compliance policies may lead to the deployment
of monitored events, if they specify certain types of
conditions (e.g. temporal conditions). These events
are then monitored by components of the platform.
4.4 Compliance Control
Compliance Control involves controlling compliance
within the platform, based on the compliance so-
lutions developed in the engineering phase, and it
is supported by the Compliance Control Subsystem.
Compliance control comprises System-level Compli-
ance Control, Runtime Business-level Compliance
Control and A Posteriori Business-level Compliance
Control which, as shown in Figure 9, are supported
by subsystems of the compliance control subsystem.
System-level Compliance Control involves pro-
cessing platform messages in order to control com-
pliance within messages exchanges, based on the de-
ployed compliance elements (e.g. policies). This con-
trol, at the message level, may involve processing: i)
ICSOFT 2018 - 13th International Conference on Software Technologies
694
Figure 9: Compliance Control Subsystem.
only one message (e.g. to check if a data element
is compliant with ICD-10), ii) two messages (e.g. to
check if the temporal distance between a service re-
quest and a response is as specified by a response time
requirement), iii) various messages of a collaboration
(e.g. to check if they are interchanged as specified in
the corresponding messages flow), or iv) various in-
dependent messages (e.g. to check if a data element,
as birthdate, is consistent over time). In case a not-
compliance is detected, system-level compliance ac-
tions specified in policies may be taken (e.g. taking
out data from a message). System-level compliance
control is automatically performed by the platform
and it is supported by the System-level Compliance
Control (SCC) Subsystem.
Runtime Business-level Compliance Control in-
volves processing system-level compliance control
results obtained from the SCC subsystem and control-
ling compliance with requirements and agreements.
Business-level compliance actions can be taken (e.g.
sanctions, incentives) after business-level compliance
control is completed. Runtime Business-level compli-
ance control is automatically performed by the plat-
form and it is supported by the Runtime Business-
level Compliance Control (RBCC) Subsystem.
A Posteriori Business-level Compliance Control
involves processing system-level and business-level
compliance control results in order to control com-
pliance. This may be needed when such controls can
not be performed by the RBCC. A posterior business-
level compliance control can be either automatically
performed by the platform or can be performed by
compliance business experts. This a posteriori con-
trol can also lead to business-level compliance actions
and it is supported by the A Posteriori Business-level
Compliance Control (PBCC) Subsystem.
4.5 Compliance Analysis
Compliance Analysis involves analyzing compliance
control results as well as defining compliance analysis
artifacts (e.g. reports) in order to facilitate such analy-
sis. The activities of this phase are mainly performed
by compliance business experts and are supported by
the Compliance Analysis Subsystem which includes
three subsystems to support Compliance Traceability,
Compliance Reporting and Compliance Dashboards.
Compliance Traceability comprises tracing com-
pliance violations starting from high level elements
(e.g. compliance agreements) until reaching the mes-
sage level. This allows explaining how a compliance
violation took place in terms of platform messages.
For example, a traceability view may be set up so that
a compliance expert can obtain the violations of an
agreement as well as the associated compliance re-
quirements violations and the platform messages that
caused that those requirements were not met.
Compliance Reporting involves defining compli-
ance reports, based on the defined traceability views,
as well as using them to analyze compliance evalua-
tion results. A compliance report provides a view of
compliance violations for specific elements.
Compliance Dashboards group compliance re-
ports of interest for a given user so that compliance
control results are displayed in an integrated way for
that user. In addition, compliance dashboards allows
specifying the format in which these results are pre-
sented (e.g. summaries, graphs).
5 RELATED WORK
There are various proposals which identify differ-
ent phases in a compliance management process
(Sackmann and K
¨
ahmer, 2008)(Koliadis and Ghose,
2008)(El Kharbili, 2012)(Tran et al., 2012). Our work
is aligned with these proposals; indeed it takes some
of the phases identified by them. However, compared
to our work, none of these proposals specializes the
phases for inter-organizational integration platforms.
There are also proposals that address compliance is-
sues in cross-organizational business process (Knu-
plesch et al., 2013). Our proposal also deals with this
kind of requirements, but it is not restricted to only
that. Regarding comprehensive approaches to com-
pliance management, one of the most relevant initia-
tives is the European project COMPAS that proposed
an integrated solution for runtime compliance gov-
ernance in SOA (Tran et al., 2012). However, the
project focuses on compliance management within an
organization while our work deals with compliance
management within integration platforms that process
inter-organizational service interactions.
In summary, the distinguished characteristics of
our proposal are: i) the focus on compliance manage-
ment in inter-organizational interactions, ii) policy-
based solutions that process all interactions within an
integration platform, iii) a common framework (e.g.
models) that allows dealing with different compliance
A Comprehensive Approach to Compliance Management in Inter-organizational Service Integration Platforms
695
areas in an homogeneous way, iv) non-invasive so-
lutions (i.e. not requiring deployments in organiza-
tions), and v) a compliance management life cycle in-
cluding adapted activities for the specific context.
6 CONCLUSIONS
This work proposes a comprehensive approach to
compliance management in inter-organizational ser-
vice integration platforms. The approach defines a
compliance management life cycle for this specific
context and a common framework to homogeneously
manage compliance issues.
The life cycle includes four main phases: setup,
engineering, control and analysis. The engineer-
ing phase comprises compliance modeling, specifi-
cation, development and deployment. The control
phase comprises system-level compliance control and
business-level compliance control.
The common framework includes conceptual
models and components that allow managing aspects
of compliance through the whole life cycle and within
different compliance areas in an homogeneous way.
Future work consists in completing the specifica-
tion of the compliance policy language to be used in
the approach. This language is inspired in XACML,
extending it to not only deal with access control is-
sues. The example in (Gonz
´
alez and Ruggia, 2017)
shows how compliance policies would look like. In
addition, we plan to continue advancing in the eval-
uation of the technical feasibility of the approach
through the development of prototypes. Finally, we
aim to address other compliance areas such as privacy
in the e-health domain.
REFERENCES
Abin, J., Nemeth, H., and Friedmann, I. (2015). Sys-
tems architecture for a nationwide healthcare system.
In MEDINFO 2015: Proceedings of the 15th World
Congress on Health and Biomedical Informatics.
El Kharbili, M. (2012). Business process regulatory com-
pliance management solution frameworks: A compar-
ative evaluation. In Proceedings of the Eighth Asia-
Pacific Conference on Conceptual Modelling - Volume
130, APCCM ’12. Australian Computer Society, Inc.
Elgammal, A., Turetken, O., van den Heuvel, W.-J., and
Papazoglou, M. (2016). Formalizing and appling
compliance patterns for business process compliance.
Software & Systems Modeling, 15(1):119–146.
Golluscio, E., Thompson, J., and Guttridge, K. (2016). Mar-
ket Guide for Hybrid Integration Platform-Enabling
Technologies. Technical Report G00290089, Gartner.
Gonz
´
alez, L., Echevarr
´
ıa, A., Morales, D., and Ruggia, R.
(2016). An e-government interoperability platform
supporting personal data protection regulations. CLEI
Electronic Journal, 19:8 – 8.
Gonz
´
alez, L. and Ruggia, R. (2011). Addressing QoS issues
in service based systems through an adaptive ESB in-
frastructure. In 6th Workshop on Middleware for Ser-
vice Oriented Computing - MW4SOC’11. ACM Press.
Gonz
´
alez, L. and Ruggia, R. (2015). A reference ar-
chitecture for integration platforms supporting cross-
organizational collaboration. In Proceedings of 17th
International Conference on Information Integration
and Web-based Applications &Services. ACM Press.
Gonz
´
alez, L. and Ruggia, R. (2017). Towards a middle-
ware and policy-based approach to compliance man-
agement for collaborative organizations interactions.
In Proceedings of the 12th International Conference
on Software Technologies. SCITEPRESS.
Gonz
´
alez, L., Ruggia, R., Abin, J., Llamb
´
ıas, G., Sosa,
R., Rienzi, B., Bello, D., and
´
Alvarez, F. (2012).
A service-oriented integration platform to support a
joined-up e-government approach: The uruguayan ex-
perience. In Advancing Democracy, Government and
Governance, volume 7452 of Lecture Notes in Com-
puter Science. Springer Berlin Heidelberg.
Knuplesch, D., Reichert, M., Fdhila, W., and Rinderle-
Ma, S. (2013). On enabling compliance of cross-
organizational business processes. In Daniel, F.,
Wang, J., and Weber, B., editors, Business Pro-
cess Management, pages 146–154, Berlin, Heidel-
berg. Springer Berlin Heidelberg.
Koliadis and Ghose (2008). Service compliance: towards
electronic compliance programs. Technical report.
Pidre, S., Gonz
´
alez, Mendoza, R., Pinatares, M., Granja,
N., Serra, F., and Ruggia, R. (2017). A data quality
aware enterprise service bus for e-health integration
platforms. In 2017 XLIII Latin American Computer
Conference (CLEI). IEEE.
Sackmann, S. and K
¨
ahmer, M. (2008). Expdt: A
policy-based approach for automating compliance.
WIRTSCHAFTSINFORMATIK, 50(5):366–374.
Tran, Zdun, Holmes, Oberortner, Mulo, and Dustdar
(2012). Compliance in service-oriented architectures:
A model-driven and view-based approach. Informa-
tion and Software Technology, 54(6).
ICSOFT 2018 - 13th International Conference on Software Technologies
696