Establishing Regulatory Compliance for InformationSystem Requirements:

An Experience Report from the Health Care Domain

Alberto Siena1, Giampaolo Armellin2, Gianluca Mameli1, John Mylopoulos3, AnnaPerini1, and Angelo Susi1

1 Fondazione Bruno Kessler, via Sommarive, 18 - Trento, Italy{siena,mameli,perini,susi}@fbk.eu

2 GPI, via Ragazzi del ’99, 13 - Trento, Italygarmellin@gpi.it

3 University of Trento, via Sommarive, 14 - Trento, Italyjm@disi.unitn.it

Abstract. Adherence to laws and regulations imposes important constraints onorganizations, for legacy and new systems, both for their design and operation.Nomos is a framework that supports the development of compliant software sys-tems. In this paper, we report on the application of Nomos in an industrial project,to provide model-based evidence that a set of requirements for a healthcare in-formation system are compliant with a specific law. Compliance is treated as acollection of assigned responsibilities to social and system actors. The design ofcompliance pays special attention to auditability, i.e., making sure that design-time compliance is actually being adhered to.

1 Introduction

Over the past decades, information and communication technologies have steadily evol-ved, so that the concept of calculus or data processing machine has been replaced by thatof a socio-technical system, consisting of software, human and organisational actors andbusiness processes, running on an open network of hardware nodes and fulfilling vitalfunctions for large organizations. Such systems gained the attention of governmentalbodies, which are responsible for regulating them through laws, regulations and poli-cies to ensure that they comply with security, privacy, governance and other concernsof importance to citizens and governments alike. The impact of this situation has beenimmense on Software Engineering as much as on business practices. It has been es-timated that in the Healthcare domain, organizations have spent $17.6 billion over anumber of years to align their systems and procedures with a single law, the HealthInsurance Portability and Accountability Act (HIPAA), introduced in 1996 [1]. In theBusiness domain, it was estimated that organizations spent $5.8 billion in one year alone(2005) to ensure compliance of their reporting and risk management procedures withthe Sarbanes-Oxley Act 4.

4 Online news published in dmreview.com, november 15, 2004.

In this setting, requirements engineers are faced with new challenges in elicitingrequirements that at the same time fulfill the needs of stakeholders and are compliantwith relevant legal prescriptions. However, unlike stakeholder requirements, which canbe validated thanks to the intervention of the stakeholders themselves, requirements in-troduced for compliance purposes suffer from lack of evaluation methods. Assumingthat with appropriate engineering tools we can identify the measures to be implementedin order to comply with law prescriptions, it’s unclear how to support such evidence ina real environment. After the requirements for the system-to-be have been elicited, thesystem has to be designed, developed and deployed. In each of these phases, wrong de-cisions may alter the compliance solutions set up in the requirements phase. Additionalefforts are necessary to maintain the system aligned with law prescriptions, thus causingcosts to grow. Unsurprisingly, legal compliance is gaining the attention of the softwareengineering community, which increasingly faces that problem, and approaches are be-ing developed, to deal with it in a systematic way.

In this paper, we report the application of a framework, namely Nomos, for sys-tematically generating law-compliant requirements. The framework was used in an in-dustrial health care project, which had the purpose of developing a distributed systemfor the realisation of an Electronic Patient Record (EPR) for storing social and healthinformation to be used in health care. Within the project, Nomos was used by analystsand law experts to reason about laws and strategies and to offer model-based evidencethat a set of given requirements indeed is compliant with a particular law. Specifically, itwas used for systematically ensuring that (i) none of the elements of the law is violatedby these requirements; and that (ii) requirements compliance is auditable — i.e., com-pliance can be confirmed during the operation of the system on the basis of gathereddata.

The paper is structured as follows: Section 2 recalls the theoretical baseline thiswork is based on. Section 3 presents the information system this work has been appliedto. Section 4 explains how the conceptual tools have been applied. Section 5 reports theachieved results. Section 6 summarises the lessons learned with this approach. Section 7overviews related works, while Section 8 concludes the paper.

2 Background

Nomos [11] is a goal-oriented, law-driven framework intended to generate requirementsthrough which a given information system can comply to a given law. Such require-ments are referred to in the sequel as compliance requirements. Nomos is based on thei* framework [13], which offers primitives to model a domain along two perspectives:the strategic rationale of the actors - i.e., a description of the intentional behavior ofdomain stakeholders in terms of their goals, tasks, and quality aspects (represented assoft-goals); and the strategic dependencies among actors - i.e., the system-wide strategicmodel based on the relationship between the depender, which is the actor, in a given or-ganizational setting, who “wants” something and the dependee, that is the actor who hasthe ability to do something that contributes to the achievement of the depender’s origi-nal goals. The system-to-be is modeled as a new actor of the organizational setting thatenables the achievement of domain stakeholders goals, so expressing the requirements

Actor

PrivilegeNoclaim ClaimDuty PowerLiability ImmunityDisability

sourceArtRight

10..*

1

0..*ActionCharacterization

0..* 1

holder

counterparty

concernssource

1

0..*

Goal

0..*1..*

realizeRealization

Dominance

1

0..*

0..*

1realizedBy

10..* target

i* meta-model NP Nomos

Resource

Task

0..*

use

meansEndperforms

ownswants

0..*

0..*

Figure 1. The meta-model of the Nomos language.

of the system. Nomos extends i* by adding the capability to model law prescriptionsand the link between intentional elements and legal elements.

The core elements of legal prescriptions are normative propositions (NPs) [9], whichare the most atomic propositions able to carry a normative meaning. NPs contain infor-mation concerning: the subject, who is addressed by the NP itself; the legal modality(i.e., whether it is a duty, a privilege and so on); and the description of the object ofsuch modality (i.e., what is actually the duty or privilege). The legal modality is oneof the 8 elementary rights, classified by Hohfeld [6] as privilege, claim, power, immu-nity, no-claim, duty, liability, and disability. Claim is the entitlement for a person tohave something done from another person, who has therefore a Duty of doing it. Priv-ilege is the entitlement for a person to discretionally perform an action, regardless ofthe will of others who may not claim him to perform that action, and have thereforea No-claim. Power is the (legal) capability to produce changes in the legal system to-wards another subject, who has the corresponding Liability. Immunity is the right ofbeing kept untouched from other performing an action, who has therefore a Disability.Complex legal prescriptions are created in law documents by structuring NPs throughconditions, exceptions, and other conditional elements. Such elements are captured inNomos by introducing priorities between NPs. For example, a data processor may beallowed (i.e., it has a privilege) to process the data of a subject; but the right of the sub-ject to keep his/her data closed w.r.t. third parties has a higher priority on the privilege,thus constraining the way data is used by the processor.

Figure 1 depicts the Nomos meta-model, and shows how it integrates the repre-sentation of NPs with the representation of goals. The dashed line contains a partof the i* meta-model, including to the Actor class and its wants association withGoal. The dotted line contains the elements that form a NP. The join point betweenthe goal-oriented and the legal part of the meta-model is the class Actor, which isat the same time stakeholder in the domain and subject of NPs. Actors are associ-

ated to the class Right by means of the holder relation. So on the one hand ac-tors want goals, perform tasks, own resources; on the other hand, they are addressedby rights carried by NPs. Rights also impact on the social interaction of actors - inthe Hohfeldian legal taxonomy, rights are related by correlativity relations: for exam-ple, if someone has the claim to access some data, then somebody else will have theduty of providing that data. This means that duty and claim are correlatives. Similarly,privilege-noclaim, power-liability, immunity-disability are correlatives: they describethe same reality from two different points of view. So instead of defining two sepa-rate classes for “duty” or “claim”, we have a single class, ClaimDuty, which is ableto model both. Similarly the classes PrivilegeNoclaim, PowerLiability andImmunityDisability, each of them sub-class of the abstract class Right. Prior-ities between rights are captured in the meta-model by means of the Dominance class,which connects two rights. The PrescribedAction class contains the actual ob-ject of the NP. Such prescribed action is bound to the behaviour of actors by meansof the Realization class. It specifies that a certain goal is wanted by the actor inorder to accomplish the action prescribed by law. For more information on the Nomosmeta-model, see [12].

Figure 2 exemplifies the Nomos language used to create models of laws. The lan-guage is an extension of the i* modelling language, and inherits its notation. For ex-ample, actors of the domain are represented as circles, and they have an associatedrationale, which contains the goals, tasks and resources of the actors. In the Nomoslanguage, the actor’s rationale also contains the NPs addressing that actor, partially or-dered through dominance relations. Finally, the holder and counter-party actors of aright are linked by a legal relation. The diagram in the figure shows an excerpt of theNomos models that represent some fragments of the Italian Personal Data ProtectionCode5. The figure shows the subject of right - the [User] - and its claim, toward the dataprocessor, to have [Protection of the personal data] (as of Art. 7.1). However, the dataprocessor is free to [Process performance data] (Art. 7.1). The general duty to protectthe personal data is then overcame by a number of more specific duties, such as [Be in-formed of the source of the personal data], [Obtain updating, rectification or integrationof the data], [Confirmation as to whether or not personal data concerning him exist],[Be informed of the source of the purposes] (all from Art. 7.2), and so on. However, thedata processor has the claim, towards the data subject, to refuse requests of informationin (unlikely) case, for example, of the data that are processed for reasons of justice byjudicial authorities.

3 A Healthcare Information System

Amico6 is an industrial research and development (R&D) project in the health care do-main, which involved around 25 people working on it — including project manager,analysts, software architect, programmers and researchers — and lasted 18 months ofwork. The Amico project is intended to define the architecture for an integrated service-based system, aiming at increasing the possibilities of self-supporting life for elder or

5 An English translation of the law can be found at http://www.privacy.it/6 Assistenza Multilivello Integrata e Cura Ovunque

P1T2S7.2

Be informed of the source of

the personal data P1T2S7.2

Be informed of the source ofthe purposes

>

>

>

Hospital

DataSubject

<

Protectionof the personal data

P1T1S1.1

Processperformance data

P1T1S1.1

P1T2S1.1

Confirmation as to whether or not personal data

concerning him exist

P1T2S7.1

Confirmation as to whether or not personal data

concerning him exist

P1T2S7.2

Be informed of the source of

the personal data P1T2S7.3

Obtain updating, rectification or

integration of the data

>>

<

>

>

<

P1T2S8.2

Refuse requestsin cases a) to h)

Cl

P1T2S8.2

Refuse requestsin cases a) to h)

Protectionof the personal data

P1T2S7.1

Processperformance data

P1T2S7.1

P1T2S7.2

Be informed of the source of

the personal data

k has, towards j, the freedom to make A

k has, towards j,the claim of having A

A

A

>

the {duty/claim/power|...} A1has the priority over A2

A1 A2

j

j

k

k

PrivilegeNoclaim

ClaimDuty

ImmunityDisability

PowerLiability

G A

G is a possiblecompliance goal for A

Optional annotationof actions

j has, towards j, the freedom to make A

j has, towards k,the duty of doing A

Legenda

Figure 2. The Nomos modelling languages: visual representation of the Italian Personal DataProtection Code.

the health care system: social workers, doctors, social cooperatives, relatives. The EPR,accessed via web, allows for a collaboration among the subjects, for improving healthcare and having social and health information, as well as economic and managerialdata. Technological devices are applied in patients’ home and according to the patient’sneeds, to both support them and to monitor their health conditions. Data produced bythe devices is integrated with patients’ health history, and with the human activity ofhealth and social workers to create a health centre, able to provide fast assistance ac-tions, if needed, improve life quality of patients, reduce unneeded hospitalisations, andrationalise costs.

The EPR. Amico has been conceived as a network of interconnected systems, asdepicted in Figure 3. Nodes of the network are mainly the health care facilities withtheir information systems, called Local Authorities (LA). Local Authorities run theirown databases, and provide services such as data search and retrieval to other mem-bers of the network. Local authorities directly collect data from patients mainly in twoways: through direct input of operators, such as doctors and nurses; or, through auto-matic sensing, by means of input peripherals such as cameras, heart rate monitor, andso on. Alternatively, they receive data that had previously collected by other Local Au-thorities. The collected data can in turn be further propagated to other members of thenetwork, if needed. Certificate Authorities (CA) are the reference actors for Local Au-thorities: they keep a copy of those data that have been verified and can be trusted. So,the data that the Local Authorities retrieves form the Certificate Authorities are con-sidered “clean”. On the contrary, data retrieved from other Local Authorities, are notverified and are considered “dirty”. An Index node manages the list of members of thenetwork. Through the Index, a Local or Certificate Authority can know of others Au-

Figure 2. The Nomos modelling languages: visual representation of the Italian Personal DataProtection Code.

disabled people in their own home. The project is focused on the realisation of an Elec-tronic Patient Record (EPR) for storing social and health information to be used inhealth care. Information is stored and accessed independently by the subjects that oper-ate in the health care system: social workers, doctors, social cooperatives, relatives. TheEPR, accessed via web, allows for a collaboration among the subjects, for improvinghealth care and having social and health information, as well as economic and manage-rial data.

The EPR. The Amico system has been conceived as a network of interconnectedcomponents, as depicted in Figure 3. Nodes of the network are mainly the health care fa-cilities with their information systems, called Local Authorities (LA). Local Authoritiesrun their own databases, and provide services such as data search and retrieval to othermembers of the network. Local authorities directly collect data from patients mainlyin two ways: through direct input of operators, such as doctors and nurses; or, throughautomatic sensing, by means of input peripherals such as cameras, heart rate monitor,and so on. Alternatively, they receive data that had previously collected by other LocalAuthorities. The collected data can in turn be further propagated to other members ofthe network, if needed. Certificate Authorities (CA) are the reference actors for LocalAuthorities: they keep a copy of those data that have been verified and can be trusted.So, the data that the Local Authorities retrieves form the Certificate Authorities are con-sidered “clean”, as opposed to data retrieved from other Local Authorities, which arenot verified and are considered “dirty”. An Index node manages the list of members ofthe network. Through the Index, a Local or Certificate Authority can know of othersAuthorities registered system-wide. The network-wide collection of patient data formsthe EPR for the patient.

BUS

S4

Database

CA 1

S1 S2 S3

Database

LA 2

S1 S2 S3

Database

LA 1

S5

Database

Index

Services

Figure 3. The demo scenario for the Amico’s system architecture.

Usage scenario. For checking the requirements of the system, a usage scenariohas been proposed by the industrial partners. The scenario focuses on the case of apatient that needs to access the (physical) services of a health care facility. The patientmay turn to various facilities, according to their specialisation and w.r.t. his/her needs.On reception, the facility needs to know the clinical history of the patient, in order toselect the most appropriate cure. The clinical data can be in the local database of theaccessed facility; or, it can be distributed somewhere across the Amico network; or, itcan be completely absent. Through the Amico system, it should be possible to accessan integrated EPR, which collects every useful information available for the patientwherever in the network; alternatively, it should be possible to create the EPR fromscratch, and broadcast it through the network.

Involved services. With regard to the described scenario, five services are providedby the nodes of the network, they are labelled S1 to S5, in Figure 3. Services S1, S2 andS3 are provided by the node Local Authority. In particular, the service S1 is responsiblefor accessing the underlying system and provides service such as local data search andupdating; the service S2, is responsible for accessing the Certificate Authority node andprovides service of data search remotely. It is not possible to update information in thiscase as it provides a read only service. Once information is available from the CertificateAuthority it is possible to update or create new information locally by invoking S1; andthe service S3, broadcast “dirty” information (information still not verified) to all localauthorities. This service enables each local authority to keep integrity of data betweenlocal systems. Service S4 and S5 are exposed by the Certificate Authority and the Indexnodes respectively. They behave as in the following: S4, each Certificate Authority isresponsible for providing certified data search — i.e., it provides a read-only access tosome verified data; and S5, this is a service accessible from anywhere and it returnsinformation of corresponding Certificate Authority. The Local authority accesses S1to S5, regardless whether the services are provided by itself, or by another node. TheCertificate Authority accesses S4 and S5.

Compliance issues. Our role in the Amico project consisted in refining the analysisof gathered requirements from the point of view of legal compliance. Specifically, thelaw under analysis was the Italian Personal Data Protection Code D.Lgs. n. 196/2003

(depicted in Figure 2), limited to Part I, Title II (Data Subject’s Rights) of the law. Eightpeople were involved in this task: 3 analysts, 1 industry partner, 1 software architect,2 designers, 1 programmer. We modelled the requirements of the demo scenario bymeans of goals. In goal models, goals express the why of requirements choices. Goalsare decomposed into sub-goals and operationalised by means of plans. Plans, in turn,may need resources to be executed. In the Amico project, we used i* (which Nomos isbased on) to create goal models representing the rationale behind the demo scenario.Figure 4 represents such rationale, limited to the [Local Authority] actor. When a patient([User]) accesses a health care centre, at the check-in the EPR of the patient has to beretrieved from the system. In the health care centre accessed by the patient, the system (a[Local Authority]) executes a query on the local database, and the [S1] service furnishessuch data. If the data is not found in the local database, the [Local Authority] forwardsthe request to the [S2] service, which returns the name of the reference [CertificateAuthority]. The Authority is queried to have certified data. But [Certificate Authority] canalso be unable to provide the requested data. In this case, the local authority contactsanother Local Authority (the actor [Peer Local Authority] in the diagram), which in turnexecutes a local search or queries its own reference Certificate Authority. If the searcheddata don’t exist in the system, the Local Authority proceeds inserting it, and markingit as “dirty”. In this case, after the data insertion, the Local Authority invokes the [S3]service, which broadcasts the data to the whole system. When the broadcast notificationis received, each Local Authority updates its local database. However, the privacy lawlays down many prescriptions concerning the processing of personal data (in particular,sensitive data) of patients. For example, it requires the owner’s confirmation for thedata being processed. Before building the system, it is necessary to provide some kindof evidence that the described scenario do not violate the law.

4 Compliant and Auditable Requirements

The purpose of our work in Amico is to provide evidence of compliance of require-ments. In a general sense, being compliant with law means behaving according to lawprescriptions. However, this meaning has the drawback that behaviours can only beverified at run-time. For this reason, Nomos splits the notion of compliance into inten-tional compliance and auditability. Intentional compliance is defined as the design-timedistribution of responsibilities such that, if every actor fulfils its goals, then actual com-pliance is ensured. It represents the intention to comply. Intentional compliance allowsfor moving at design time the notion of compliance, but has the drawback that havingthe intention to comply is not equivalent to actually behaving in compliance. Therefore,intentional compliance is associated to the concept of auditability, which is the design-time distribution of auditing resources, such that the run-time execution of processescan be monitored and eventually contrasted to their purpose.

4.1 Intentional Compliance

In a Nomos model, we distinguish goals with respect to their role in achieving compli-ance. We define strategic goals those goals that come from stakeholders and represent

User

LocalAuthority Certificate

Authority

S3S1

S2

S4

Broadcastdirty data

Searchlocal data Get name

of Certificateauthority

Getcertificated

data

updateAllLocal

searchLocal

getCertificateAuthoritysearchCertificate

Updatelocally

updateLocal

Broadcastdirty data

Retrievelocal data

Requestdata to peer

AuthorityGet

CertificateAuthority

Retrievedata

RetrieveEPR data

OR

Retrieveexisting data

ORRetrieve

remote dataAND

Ask userauthorization

Insertdata

Returninserted

data

Health careAccesshealth care

centrePeerLocal

Authority

is-a

Get data

Provideremote data

Getcertificated

data

Searchlocal data

Get name ofCertificateauthority

Updatelocally

Verify user'sauthorization

Updatelocal data

Update datalocally

ORProvide

remote data

P1T2S7.1

Confirmation as to whether or not personal data

concerning him exist

P1T2S7.1

Confirmation as to whether or not personal data

concerning him exist

Retrievedirty data

AND

Patient'sdata

ForwardEPR datato doctors

Accesshealth care

centreAND

Figure 4. A goal model for the demo scenario of the Amico project.

needs of the stakeholders. We define compliance goals those goals that have been de-veloped to cope with legal prescriptions. For example, in Figure 4, the goal [Updatedata locally] is a strategic goal, because it is only due to the reason-to-be of the owningactor; viceversa, [Ask user authorization] is a compliance goal, because it is due to theneed of complying with the [Confirmation as to whether or not personal data concern-ing him exist] claim of the user. The identification of compliance goals, and specificallythe identification of missing compliance goals, was actually the objective of our anal-ysis. We moved from the analysis of the Italian Privacy Code, which lays down manyprescriptions concerning the processing of personal data (in particular, sensitive data)of patients. We modelled the relevant fragments of the law through the Nomos lan-guage, as in Figure 2. Afterwards, those goals have been identified, which could servefor achieving compliance with that particular law fragment, and were associated withthe corresponding normative proposition. If no appropriate goals were identified, newones were conceived and added to the model. For example, the law requires the owner’sconfirmation for the data being processed. In Figure 4, this is depicted by means of thenormative proposition [Confirmation as to whether or not personal data concerning himexist]), extracted from article 7.1. The normative proposition is modelled as a claim ofthe patient, held towards the Local Authority, which has therefore a corresponding duty.This results in two additions to the diagram. The first one concerns the insertion of the

LocalAuthority

S3

Broadcastdirty data

updateAllLocal

Broadcastdirty data

Ask userauthorization

Insertdata

Returninserted

data

Retrievedirty data

ANDData

processingauthorized

Authorizationsrecord: [Patient,Authorization]

Broadcastlog

Patient,Record

Verify user'sauthorization

Patient'sauthorization

User

Health care

Dataprocessingauthorized

Accesshealth care

centre

Figure 5. The rationale for an auditable process.

data into the local database, and subsequent broadcast to the system. In this case, beforethe broadcast is executed, it is necessary to obtain the patient’s authorisation (goal [Askuser authorization]), and to add such information in the broadcast message. The sec-ond case concerns the reception of the broadcast system by a Local Authority. In thiscase, before updating the local data with the received one, the Local Authority mustverify that in the broadcast message the authorisation to data processing is declared(task [Verify user authorization]). This has been done for every normative propositionconsidered relevant for the demo scenario. The resulting models (partially depicted inFigure 2) contained 10 normative propositions relevant for the described demo scenario.This approach allowed for assigning to domain’s actors a set of goals, which representtheir responsibility in order to achieve compliance.

4.2 Compliance Auditability

The second kind of compliance evidence we produced concerns the capability of theadopted solution to be monitored at run-time in order to confirm compliance. Nomossupports this evidence through the concept of auditability. The idea is that, if an activityor a whole process is not executed or is executed incorrectly, this is reflected in the logdata. Auditing the log data makes possible to monitor the execution of processes anddetect problems. Designing for auditability means deciding which log data have to beproduced, by which process, when, and so on. For the information systems supportingthe processes, it’s important to specify requirements of compliance auditability togetherwith other requirements. Consequently, compliance auditability has to be conceivedduring the requirements analysis.

In order to assess auditability we associate data log resources to goals. More prop-erly, the resources are associated to the plans intended to fulfil compliance goals. Or,as a shortcut, the plans are omitted and resources are associated directly to goals. Inany case when plans (either explicitly modelled or not) are executed to achieve a goal,they use the associated resource. The idea, conceived in the Nomos framework, is thatsuch resources can be the key to monitor, at run-time, the execution of the processes.When a resource - such as a database - is used, its state is affected and the state changecan be recorded. Or, even the simple access to a resource can be recorded. Upon this

idea, 2 analysts have undertaken a modelling session. An excerpt of the results is de-picted in Figure 5. The ultimate purpose was to revise existing models, searching forcompliance goals. Once found, compliance goals have been elaborated to be made au-ditable. For example, the [Local Authority] has the goal [Ask user authorisation], whichhas been developed to comply with the duty to have such authorisation from the userbefore processing his data, can’t be proved at run-time. Even if the authorisation isrequested, if a legal controversy arises, the developed models do not inform on howto prove that this request has been made. To deal with this situation, we added the[Authorisation record] to the model, and associated it to the [Ask user authorisation]goal. This way, we are saying that, whenever the goal is achieved, this is recorded in theauthorisation record, where we store the name of the patient, who gave the authorisa-tion, and the authorisation itself (if the authorisation has been provided electronically;otherwise, the ID of the archived copy of it). On the other hand, the [Local Authority]receives broadcasted messages when other local authorities commit dirty data in theirdatabases. In this case, the goal to [Verify user’s authorization] had been added, to avoidthat failures of other local authorities in getting the authorisation from the user maylead to compliance issues. Again, in this case, from the model it’s not possible to spec-ify how the achievement of this goal can be monitored. For this reason, after havingverified the presence of the authorisation information within the broadcasted message,the [Local Authority] stores such information in another log, which informs on whichauthorisations have been received and from which peer. Additionally, we enriched themodel with a resource dependency form the [Local Authority] to the service [S3] (ofthe peer authority), to indicate that the authorisation has to be provided by that service.In turn, this raises another problem, of where that information has came from. This isnot explicit in the model, so it’s not possible to associate the behaviour of [S3] with itsauditability resources. So finally, we associated the [Insert data] goal to its resources:the [Authorizations record], where it takes the authorisation information from; and the[Patients data], where the actual data is stored. This way, patients’ data is associated tothe authorisation to process them.

5 Results

The proposed approach has led to some important results. The Software RequirementsSpecification (SRS) document has been integrated to reflect the compliance solutionsfound, and to support the auditability of the compliance solutions.

Table 1 reports the most important additions introduced by the Nomos analysis. Inthe table, the first column reports the law or law fragment, which the requirement hasbeen developed for; the second column presents the description of the requirements,gathered or induced by the law fragment; the third column indicates whether the re-quirement is intended to be audited at run-time.

As the first column shows, not all of the articles in the selected law slice wereaddressed. This is due to the demo scenario, which concerned only on search, additionand update of data: so, law articles not impacting on these functionalities were notaddressed. On the contrary, one article - the 157.1 - has been considered, even if notcontained in Title II of the law. The reason has been a cross-referencing from article 8.3,

Table 1. An excerpt of the Software Requirements Specification document.

Law article Requirement AuditArt. 7.1 The Local Authority registers users’ authorisations

The Local Authority writes the User’s in the Authorisations base XThe Local Authority inserts the data into the local DB X

Art. 7.2e The Local Authority verifies the entrance of new peersThe Local Authority maintains the list of verified peers XS1 gets the list of verified peers from the Local Authority

Art. 7.3a, 7.3b The Local Authority writes data modifications to log XArt. 9.4 The Local Authority identifies the patient by means of identity card

The Local Authority records patients’ ID card number X... ...Art. 157.1 The Local Authority produces a report with the collected data to the Garante X

Table 2. An excerpt of the Auditability Requirements document.

Auditability document Reponsible When usedAuthorisations record Local Authority Request of user’s authorisation

Insertion of dirty data into the local DB...

Database log Local Authority Insertion of dirty data...

Broadcast log S3 Broadcast of dirty data entriesRequests log Local Authority Requests of data modifications are received from the patient

Changes are made in the local databasePeers list Local Authority Addition of a new peer to the list of known peers

in relation to the role plaid by the [Garante] actor, a public body in charge of controllinglaw application. The Garante has monitoring responsibilities, and may request from thedata processors to “provide information and produce documents”. Such informationand documents are those derived with the use of the Nomos framework, and are inthe following enumerated in Table 2. Table 2 shows the overall results of the analysisprocess. It reports the auditability documents for the identified compliance goals. Thetable has been created by collecting from the model all the data logs used as auditingsources. The first column contains the name of the audit document. The second columncontains the name of the actor, who is in charge of maintaining the document. The thirdcolumn contains the cases, in which the document is modified. Basically, the content ofthe table has to be attached to the SRS, and specifies what documents does the systemneed to produce once developed, to provide compliance evidence at run-time.

6 Lesson learned

Upon the experience with the Amico project, we performed a qualitative evaluation ofthe Nomos framework by answering a set of questions. We summarize it below in termsof lessons learned.

Which has been the main contribution given to the Amico project?An interview with the industrial partners allowed to capture their perception of using

Nomos models of law. Primarily, an overall decrease in ambiguity. The representationof law prescriptions as models made analysis choices more explicit. This, turns out

also into a better understanding of these choices by the customer, showing that modelscan be a powerful communication language. Worth saying that in order to be used forinteraction, the customer has to be shortly instructed on the notation.

Was the framework effective, with regard to a costs/benefits comparison?The effort spent for the compliance analysis amounted in 15 person-days, includ-

ing meetings with the industrial partner, and also modelling and analysis of compliancegoals. The analysis of the law sources was not included in this estimation: in fact, it wasnecessary in any case, regardless of the use of the Nomos framework. The modelling ac-tivity lasted around 7 person-days. Overall, 29 law articles (including sub-paragraphs)were analysed. Out of them, 10 were mapped into normative propositions (focusingon the demo scenario described in Section 3), from whose analysis 12 new goals wereadded to the goal diagram of the demo scenario, and 5 audit resources were identi-fied. Globally, 25 new requirements were derived, including those related to log datafor compliance auditing. We considered as requirements: the goals, added for compli-ance reasons; the resources, representing auditable data logs; and associations, betweengoals and resources, considered as the explanation of which processes are responsibleto maintain the auditing logs. A quantitative evaluation reveals a productivity measureof around 4 elements per day. This is not a high number, with respect to the limiteddemo scenario, but the identified requirements were previously not considered at all.So, the use of the Nomos framework has ultimately been effective in our experience.

Is the framework scalable for larger case studies?The activity of identifying compliance basically consists in an exhaustive search

throughout the models for portions of them addressed by normative propositions. Oncefound, and after the proper compliance goals have been identified, an additional effortconsists in keeping synchronised the use of auditability resources by different compli-ance goals across the models. In case of a large model, the effort to face these activitiesmay be considerable. To partially mitigate this fact, the framework does not seem tointroduce additional complexity, if compared to the effort of working directly on thetextual sources of the law; law is in fact the major source of complexity. As mentionedabove we exclude from this analysis the effort needed to analyze laws with the purposeof extracting normative propositions.

What advantages did the analysts see in using the framework?The Nomos framework allowed for a straightforward association of compliance

goals to legal prescriptions. In particular, when a normative had effects on multipleparts of the model, the visual notation of the framework effectively gave to the analyststhe capability to easily observe these effects.

The association of auditing resources to compliance goals was more complex. Iden-tifying resources required to deeper comprehension of previously created goals. Forexample, the goal [Ask user authorization] generated the problem that a hard copy ofthe authorisation cannot be broadcasted. This forced us to reconsider the semantics ofthe goal, and decompose it into lower level goals ([Archive hard copy of authorization],[Assign authorization number] and [Broadcast the authorization number]).

What issues did the analysts see in using the framework?A major issue concerned the values to be given to some elements of the model

(in particular, to resources) to be significant. The semantics of the model relies mainly

on the semantics of the labels on goals and tasks. When associating a resource to agoal or task, we noticed that the meaning of this association changed depending on thesemantics of the goal (or task). For example, when the goal [Ask user authorization] andthe goal [Insert data], both of them use the [Authorizations record] resources. However,while the first accesses the resource for producing data, the latter accesses it only forreading data. The difference between these two cases is important, because producingdata actually refers to the capability to provide auditability of compliance goals. Thishas been resolved by adding annotations to the goal models, in order to be able todifferentiate requirements for auditable compliance, from others.

7 Related Works

In recent years, there has been various efforts to deal with law-related issues from therequirements elicitation phase. Anton and Breaux have developed a systematic pro-cess, called semantic parameterisation [2], which consists of identifying in legal textrestricted natural language statements (RNLSs) and then expressing them as seman-tic models of rights and obligations (along with auxiliary concepts such as actors andconstraints). Secure Tropos [5] is a framework for security-related goal-oriented re-quirements modelling that, in order to ensure access control, uses strategic dependen-cies refined with concepts such as: trust, delegation of a permission to fulfill a goal,execute a task or access a resource, as well as ownership of goals or other intentionalelements. Along similar lines, Darimont and Lemoine have used KAOS as a modellinglanguage for representing objectives extracted from regulation texts [3]. Such an ap-proach is based on the analogy between regulation documents and requirements doc-uments. Ghanavati et al. [4] use GRL to model goals and actions prescribed by laws.This work is founded on the premise that the same modelling framework can be usedfor both regulations and requirements. Likewise, Rifaut and Dubois use i* to produce agoal model of the Basel II regulation [8]. Worth mentioning that the authors have alsoexperimented this goal-only approach in the Normative i* framework [10], in whichthe notion of compliance was not considered. Finally, much work has been done inAI on formalizing law, e.g. [7, 9]. We use some of this work as a foundation for ourframework. However, our software engineering task of having a person check for com-pliance between a model of law and another of requirements is different from that offormalizing law for purposes of automatic question-answering and reasoning.

8 Conclusions and Future Work

The paper reports on the application of the Nomos framework to ensure complianceand auditability for a given set of requirements for a healthcare information system.The case study was conducted over a period of 18 months and involved 25 people,including project manager, analysts, software architect, programmers and researchers.On the basis of the results reported in this paper, the Nomos framework has been refinedintroducing the distinction between strategic goals, the goals related to the strategicdimension of the domain, and compliancy goals, devoted to the fullfilments of norms inthe domain. Moreover, we introduced the concept of auditability for the requirements

and means to dscribe it in the Nomos requirements models. More case studies need tobe conducted, that do not involve principal authors of the Nomos framework, to validatethe approach and to evaluate the effort needed to introduce it in a typical requirementanalysis process.

Acknowledgement. The activities described here have been funded by the AutonomousProvince of Trento, Italy, L6 funding, project “Amico”.

References

1. Medical privacy - national standards to protect the privacy of personal health information.Office for Civil Rights, US Department of Health and Human Services, 2000.

2. T. D. Breaux, A. I. Anton, and J. Doyle. Semantic parameterization: A process for modelingdomain descriptions. ACM Trans. Softw. Eng. Methodol., 18(2):1–27, 2008.

3. R. Darimont and M. Lemoine. Goal-oriented analysis of regulations. In R. Laleau andM. Lemoine, editors, ReMo2V, held at CAiSE’06, volume 241 of CEUR Workshop Proceed-ings. CEUR-WS.org, 2006.

4. S. Ghanavati, D. Amyot, and L. Peyton. Towards a framework for tracking legal compliancein healthcare. In J. Krogstie, A. L. Opdahl, and G. Sindre, editors, CAiSE, volume 4495 ofLecture Notes in Computer Science, pages 218–232. Springer, 2007.

5. P. Giorgini, F. Massacci, J. Mylopoulos, and N. Zannone. Requirements engineering meetstrust management: Model, methodology, and reasoning. In ITRUST-04, volume 2995 ofLNCS, pages 176–190. SVG, 2004.

6. W. N. Hohfeld. Fundamental Legal Conceptions as Applied in Judicial Reasoning. YaleLaw Journal 23(1), 1913.

7. V. Padmanabhan, G. Governatori, S. W. Sadiq, R. Colomb, and A. Rotolo. Process mod-elling: the deontic way. In M. Stumptner, S. Hartmann, and Y. Kiyoki, editors, APCCM,volume 53 of CRPIT, pages 75–84. Australian Computer Society, 2006.

8. A. Rifaut and E. Dubois. Using goal-oriented requirements engineering for improving thequality of iso/iec 15504 based compliance assessment frameworks. In Proceedings of RE2008, pages 33–42, Washington, DC, USA, 2008. IEEE Computer Society.

9. G. Sartor. Fundamental legal concepts: A formal and teleological characterisation. ArtificialIntelligence and Law, 14(1-2):101–142, April 2006.

10. A. Siena, N. A. M. Maiden, J. Lockerbie, K. Karlsen, A. Perini, and A. Susi. Exploring theeffectiveness of normative i* modelling: Results from a case study on food chain traceability.In Proceedings of CAiSE 2008, pages 182–196, 2008.

11. A. Siena, J. Mylopoulos, A. Perini, and A. Susi. Designing law-compliant software require-ments. In Conceptual Modeling - ER 2009, pages 472–486, 2009.

12. A. Siena, J. Mylopoulos, A. Perini, and A. Susi. A meta-model for modeling law-compliantrequirements. In 2nd International Workshop on Requirements Engineering and Law(Relaw’09), Atlanta, USA, September 2009.

13. E. S.-K. Yu. Modelling strategic relationships for process reengineering. PhD thesis,Toronto, Ont., Canada, Canada, 1996.