Establishing Regulatory Compliance for Information System Requirements: An Experience Report from the Health Care Domain Alberto Siena1 , Giampaolo Armellin2 , Gianluca Mameli1 , John Mylopoulos3 , Anna Perini1 , 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, Italy [email protected] 3 University of Trento, via Sommarive, 14 - Trento, Italy [email protected]

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

1

Introduction

Over the past decades, information and communication technologies have steadily evolved, so that the concept of calculus or data processing machine has been replaced by that of a socio-technical system, consisting of software, human and organisational actors and business processes, running on an open network of hardware nodes and fulfilling vital functions for large organizations. Such systems gained the attention of governmental bodies, which are responsible for regulating them through laws, regulations and policies to ensure that they comply with security, privacy, governance and other concerns of importance to citizens and governments alike. The impact of this situation has been immense on Software Engineering as much as on business practices. It has been estimated that in the Healthcare domain, organizations have spent $17.6 billion over a number of years to align their systems and procedures with a single law, the Health Insurance Portability and Accountability Act (HIPAA), introduced in 1996 [1]. In the Business 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 with the 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 eliciting requirements that at the same time fulfill the needs of stakeholders and are compliant with relevant legal prescriptions. However, unlike stakeholder requirements, which can be validated thanks to the intervention of the stakeholders themselves, requirements introduced for compliance purposes suffer from lack of evaluation methods. Assuming that with appropriate engineering tools we can identify the measures to be implemented in order to comply with law prescriptions, it’s unclear how to support such evidence in a real environment. After the requirements for the system-to-be have been elicited, the system has to be designed, developed and deployed. In each of these phases, wrong decisions may alter the compliance solutions set up in the requirements phase. Additional efforts are necessary to maintain the system aligned with law prescriptions, thus causing costs to grow. Unsurprisingly, legal compliance is gaining the attention of the software engineering community, which increasingly faces that problem, and approaches are being developed, to deal with it in a systematic way. In this paper, we report the application of a framework, namely N`omos, for systematically generating law-compliant requirements. The framework was used in an industrial health care project, which had the purpose of developing a distributed system for the realisation of an Electronic Patient Record (EPR) for storing social and health information to be used in health care. Within the project, N`omos was used by analysts and law experts to reason about laws and strategies and to offer model-based evidence that a set of given requirements indeed is compliant with a particular law. Specifically, it was used for systematically ensuring that (i) none of the elements of the law is violated by these requirements; and that (ii) requirements compliance is auditable — i.e., compliance can be confirmed during the operation of the system on the basis of gathered data. The paper is structured as follows: Section 2 recalls the theoretical baseline this work is based on. Section 3 presents the information system this work has been applied to. Section 4 explains how the conceptual tools have been applied. Section 5 reports the achieved results. Section 6 summarises the lessons learned with this approach. Section 7 overviews related works, while Section 8 concludes the paper.

2

Background

N`omos [11] is a goal-oriented, law-driven framework intended to generate requirements through which a given information system can comply to a given law. Such requirements are referred to in the sequel as compliance requirements. N`omos is based on the i* 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 of domain stakeholders in terms of their goals, tasks, and quality aspects (represented as soft-goals); and the strategic dependencies among actors - i.e., the system-wide strategic model based on the relationship between the depender, which is the actor, in a given organizational setting, who “wants” something and the dependee, that is the actor who has the ability to do something that contributes to the achievement of the depender’s original goals. The system-to-be is modeled as a new actor of the organizational setting that enables the achievement of domain stakeholders goals, so expressing the requirements

0..*

use 0..*

meansEnd 1..* 0..*

Resource owns

PrivilegeNoclaim

Goal

0..* realizedBy 1

0..*

1

ClaimDuty

i* meta-model

Realization

1

1

source target 1

0..* realize

1 counterparty holder

Dominance

0..* wants

Actor 0..*

0..*

Task

performs

0..* Right sourceArt

concerns 0..*

PowerLiability

NP

ActionCharacterization

1

ImmunityDisability

Nomos

Figure 1. The meta-model of the N`omos language.

of the system. N`omos extends i* by adding the capability to model law prescriptions and the link between intentional elements and legal elements. The core elements of legal prescriptions are normative propositions (NPs) [9], which are the most atomic propositions able to carry a normative meaning. NPs contain information 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 of such modality (i.e., what is actually the duty or privilege). The legal modality is one of the 8 elementary rights, classified by Hohfeld [6] as privilege, claim, power, immunity, no-claim, duty, liability, and disability. Claim is the entitlement for a person to have something done from another person, who has therefore a Duty of doing it. Privilege is the entitlement for a person to discretionally perform an action, regardless of the will of others who may not claim him to perform that action, and have therefore a No-claim. Power is the (legal) capability to produce changes in the legal system towards another subject, who has the corresponding Liability. Immunity is the right of being kept untouched from other performing an action, who has therefore a Disability. Complex legal prescriptions are created in law documents by structuring NPs through conditions, exceptions, and other conditional elements. Such elements are captured in N`omos by introducing priorities between NPs. For example, a data processor may be allowed (i.e., it has a privilege) to process the data of a subject; but the right of the subject 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 N`omos meta-model, and shows how it integrates the representation of NPs with the representation of goals. The dashed line contains a part of the i* meta-model, including to the Actor class and its wants association with Goal. The dotted line contains the elements that form a NP. The join point between the goal-oriented and the legal part of the meta-model is the class Actor, which is at 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 actors want goals, perform tasks, own resources; on the other hand, they are addressed by rights carried by NPs. Rights also impact on the social interaction of actors - in the Hohfeldian legal taxonomy, rights are related by correlativity relations: for example, if someone has the claim to access some data, then somebody else will have the duty of providing that data. This means that duty and claim are correlatives. Similarly, privilege-noclaim, power-liability, immunity-disability are correlatives: they describe the same reality from two different points of view. So instead of defining two separate classes for “duty” or “claim”, we have a single class, ClaimDuty, which is able to model both. Similarly the classes PrivilegeNoclaim, PowerLiability and ImmunityDisability, each of them sub-class of the abstract class Right. Priorities between rights are captured in the meta-model by means of the Dominance class, which connects two rights. The PrescribedAction class contains the actual object of the NP. Such prescribed action is bound to the behaviour of actors by means of the Realization class. It specifies that a certain goal is wanted by the actor in order to accomplish the action prescribed by law. For more information on the N`omos meta-model, see [12]. Figure 2 exemplifies the N`omos language used to create models of laws. The language is an extension of the i* modelling language, and inherits its notation. For example, actors of the domain are represented as circles, and they have an associated rationale, which contains the goals, tasks and resources of the actors. In the N`omos language, the actor’s rationale also contains the NPs addressing that actor, partially ordered through dominance relations. Finally, the holder and counter-party actors of a right are linked by a legal relation. The diagram in the figure shows an excerpt of the N`omos models that represent some fragments of the Italian Personal Data Protection Code5 . The figure shows the subject of right - the [User] - and its claim, toward the data processor, to have [Protection of the personal data] (as of Art. 7.1). However, the data processor is free to [Process performance data] (Art. 7.1). The general duty to protect the personal data is then overcame by a number of more specific duties, such as [Be informed of the source of the personal data], [Obtain updating, rectification or integration of 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, the data processor has the claim, towards the data subject, to refuse requests of information in (unlikely) case, for example, of the data that are processed for reasons of justice by judicial authorities.

3

A Healthcare Information System

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

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

Cl Confirmation as to whether or not personal data concerning him exist P1T2S1.1

<

<

Protection of the personal data P1T1S1.1

>

Refuse requests in cases a) to h) P1T2S8.2

Legenda k

k has, towards j, the claim of having A

k

A

j

Be informed > of the source of the personal data P1T2S7.2 j has, towards j, the freedom to make A

Protection of the personal data P1T2S7.1

Be informed of the source of the purposes P1T2S7.2 the {duty/claim/power|...} A1 has the priority over A2 A1

Optional annotation of actions

A

Claim Duty

Privilege Noclaim

j

Immunity Disability

j has, towards k, the duty of doing A Power Liability

>

>

k has, towards j, the freedom to make A

Confirmation as to whether or not personal data concerning him exist P1T2S7.1 Obtain updating, Be informed rectification or of the source ofintegration of the data Process the personal data P1T2S7.3 performance data P1T2S7.2 > P1T2S7.1 <

>

Process performance data P1T1S1.1

Data Subject

Hospital

Refuse requests in cases a) to h) > P1T2S8.2

> Be informed A2

of the source of the personal data G is a possible P1T2S7.2 compliance goal for A G

A

Figure 2. The N`omos modelling languages: visual representation of the Italian Personal Data Figure Data Protection Code.

the healthpeople care system: workers, cooperatives, relatives.ofThe disabled in theirsocial own home. Thedoctors, project social is focused on the realisation an EPR, Elecaccessed via web, allows for afor collaboration among subjects, for improving health tronic Patient Record (EPR) storing social and the health information to be used in care and having social and health information, as well as economic and managerial health care. Information is stored and accessed independently by the subjects that operdata. applied in patients’ home and according torelatives. the patient’s ate in Technological the health caredevices system:are social workers, doctors, social cooperatives, The needs,accessed to both support andfor to amonitor their health conditions. Datafor produced by EPR, via web,them allows collaboration among the subjects, improving the devices is integrated withand patients’ history,asand the human activity of health care and having social health health information, wellwith as economic and managehealth and social workers to create a health centre, able to provide fast assistance acrial data. tions, if needed, improve life quality of patients, reduce unneeded hospitalisations, and The EPR. The Amico system has been conceived as a network of interconnected rationalise costs. components, as depicted in Figure 3. Nodes of the network are mainly the health care faThewith EPR. Amico has been conceived asLocal a network of interconnected as cilities their information systems, called Authorities (LA). Local systems, Authorities depicted in Figure 3. Nodes of the network mainly thesearch healthand care facilities with run their own databases, and provide servicesare such as data retrieval to other their information systems,Local calledauthorities Local Authorities Authorities their members of the network. directly (LA). collectLocal data from patientsrun mainly own and provide services such as data and retrieval to other memin twodatabases, ways: through direct input of operators, suchsearch as doctors and nurses; or, through bers of thesensing, network.byLocal authorities collect from patients in two automatic means of input directly peripherals suchdata as cameras, heartmainly rate monitor, ways: direct input of receive operators, doctors and nurses; or,by through autoand so through on. Alternatively, they datasuch thatas had previously collected other Local matic sensing, means ofdata input as cameras, heart rate monitor, Authorities. Thebycollected canperipherals in turn besuch further propagated to other membersand of so on. Alternatively, theyCertificate receive data that had previously collected by other Authe network, if needed. Authorities (CA) are the reference actorsLocal for Local thorities. Thethey collected turndata be further propagated to other of the Authorities: keep adata copycan of in those that have been verified andmembers can be trusted. network, if needed. Certificate Authorities (CA)form are the Certificate reference actors for Local AuSo, the data that the Local Authorities retrieves Authorities are conthorities:“clean”, they keep a copy oftothose that have verified can be trusted. sidered as opposed datadata retrieved frombeen other Local and Authorities, which So, are the verified data thatand theare Local Authorities retrieves formnode the Certificate Authorities are connot considered “dirty”. An Index manages the list of members of sidered “clean”. On thethecontrary, retrieved from other Local Authorities, not the network. Through Index, adata Local or Certificate Authority can know ofare others verified andregistered are considered “dirty”. An node manages the list members the Authorities system-wide. TheIndex network-wide collection of of patient data of forms network. Through the Index, a Local or Certificate Authority can know of others Authe EPR for the patient.

BUS

S1

Services

S2

S3

S1

S2

S3

S4

S5

Database

Database

Database

Database

LA 1

LA 2

CA 1

Index

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

Usage scenario. For checking the requirements of the system, a usage scenario has been proposed by the industrial partners. The scenario focuses on the case of a patient that needs to access the (physical) services of a health care facility. The patient may 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 to select the most appropriate cure. The clinical data can be in the local database of the accessed facility; or, it can be distributed somewhere across the Amico network; or, it can be completely absent. Through the Amico system, it should be possible to access an integrated EPR, which collects every useful information available for the patient wherever in the network; alternatively, it should be possible to create the EPR from scratch, and broadcast it through the network. Involved services. With regard to the described scenario, five services are provided by the nodes of the network, they are labelled S1 to S5, in Figure 3. Services S1, S2 and S3 are provided by the node Local Authority. In particular, the service S1 is responsible for accessing the underlying system and provides service such as local data search and updating; the service S2, is responsible for accessing the Certificate Authority node and provides service of data search remotely. It is not possible to update information in this case as it provides a read only service. Once information is available from the Certificate Authority it is possible to update or create new information locally by invoking S1; and the service S3, broadcast “dirty” information (information still not verified) to all local authorities. This service enables each local authority to keep integrity of data between local systems. Service S4 and S5 are exposed by the Certificate Authority and the Index nodes respectively. They behave as in the following: S4, each Certificate Authority is responsible for providing certified data search — i.e., it provides a read-only access to some verified data; and S5, this is a service accessible from anywhere and it returns information of corresponding Certificate Authority. The Local authority accesses S1 to S5, regardless whether the services are provided by itself, or by another node. The Certificate Authority accesses S4 and S5. Compliance issues. Our role in the Amico project consisted in refining the analysis of gathered requirements from the point of view of legal compliance. Specifically, the law 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. Eight people 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 by means of goals. In goal models, goals express the why of requirements choices. Goals are 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 N`omos is based 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 be retrieved 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 furnishes such data. If the data is not found in the local database, the [Local Authority] forwards the request to the [S2] service, which returns the name of the reference [Certificate Authority]. The Authority is queried to have certified data. But [Certificate Authority] can also be unable to provide the requested data. In this case, the local authority contacts another Local Authority (the actor [Peer Local Authority] in the diagram), which in turn executes a local search or queries its own reference Certificate Authority. If the searched data don’t exist in the system, the Local Authority proceeds inserting it, and marking it 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 notification is received, each Local Authority updates its local database. However, the privacy law lays down many prescriptions concerning the processing of personal data (in particular, sensitive data) of patients. For example, it requires the owner’s confirmation for the data being processed. Before building the system, it is necessary to provide some kind of 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 requirements. In a general sense, being compliant with law means behaving according to law prescriptions. However, this meaning has the drawback that behaviours can only be verified at run-time. For this reason, N`omos splits the notion of compliance into intentional compliance and auditability. Intentional compliance is defined as the design-time distribution of responsibilities such that, if every actor fulfils its goals, then actual compliance is ensured. It represents the intention to comply. Intentional compliance allows for moving at design time the notion of compliance, but has the drawback that having the intention to comply is not equivalent to actually behaving in compliance. Therefore, intentional compliance is associated to the concept of auditability, which is the designtime distribution of auditing resources, such that the run-time execution of processes can be monitored and eventually contrasted to their purpose. 4.1

Intentional Compliance

In a N`omos model, we distinguish goals with respect to their role in achieving compliance. We define strategic goals those goals that come from stakeholders and represent

Confirmation as to User whether or not personal data concerning him exist Access P1T2S7.1 Health care health care centre Patient's Peer data is-a Local Local Access Authority Certificate Authority health care Authority centre Update data AND Confirmation as to locally Provide whether or not personal data Get data remote data OR concerning him exist Forward Retrieve P1T2S7.1 EPR data EPR data Update to doctors OR local data Retrieve dirty data

Ask user authorization

AND Insert data Return inserted data Broadcast dirty data

Retrieve existing data OR

Retrieve Request Retrieve remote data data to peer local data AND Authority Get Certificate Authority

Retrieve data

Broadcast dirty data

updateAllLocal

Provide remote data Get certificated data

Update locally Get name of Certificate authority

Search local data

S4 Search local data

S1 S3

Verify user's authorization

searchLocal

Update locally

updateLocal

S2

Get name of Certificate authority

Get certificated data searchCertificate

getCertificateAuthority

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 developed to cope with legal prescriptions. For example, in Figure 4, the goal [Update data locally] is a strategic goal, because it is only due to the reason-to-be of the owning actor; viceversa, [Ask user authorization] is a compliance goal, because it is due to the need of complying with the [Confirmation as to whether or not personal data concerning him exist] claim of the user. The identification of compliance goals, and specifically the identification of missing compliance goals, was actually the objective of our analysis. We moved from the analysis of the Italian Privacy Code, which lays down many prescriptions concerning the processing of personal data (in particular, sensitive data) of patients. We modelled the relevant fragments of the law through the N`omos language, as in Figure 2. Afterwards, those goals have been identified, which could serve for achieving compliance with that particular law fragment, and were associated with the corresponding normative proposition. If no appropriate goals were identified, new ones were conceived and added to the model. For example, the law requires the owner’s confirmation for the data being processed. In Figure 4, this is depicted by means of the normative proposition [Confirmation as to whether or not personal data concerning him exist]), extracted from article 7.1. The normative proposition is modelled as a claim of the 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

Local Authority

Data processing authorized

Retrieve dirty data AND

Access health care centre User

Health care

Ask user authorization

Return inserted data

Authorizations record: [Patient, Authorization]

Data processing authorized

Patient's authorization

Verify user's authorization

S3

Broadcast dirty data updateAllLocal

Insert data Patient, Record

Broadcast log Broadcast dirty data

Figure 5. The rationale for an auditable process.

data into the local database, and subsequent broadcast to the system. In this case, before the broadcast is executed, it is necessary to obtain the patient’s authorisation (goal [Ask user authorization]), and to add such information in the broadcast message. The second case concerns the reception of the broadcast system by a Local Authority. In this case, before updating the local data with the received one, the Local Authority must verify that in the broadcast message the authorisation to data processing is declared (task [Verify user authorization]). This has been done for every normative proposition considered relevant for the demo scenario. The resulting models (partially depicted in Figure 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 represent their responsibility in order to achieve compliance. 4.2

Compliance Auditability

The second kind of compliance evidence we produced concerns the capability of the adopted solution to be monitored at run-time in order to confirm compliance. N`omos supports this evidence through the concept of auditability. The idea is that, if an activity or a whole process is not executed or is executed incorrectly, this is reflected in the log data. Auditing the log data makes possible to monitor the execution of processes and detect problems. Designing for auditability means deciding which log data have to be produced, by which process, when, and so on. For the information systems supporting the processes, it’s important to specify requirements of compliance auditability together with other requirements. Consequently, compliance auditability has to be conceived during the requirements analysis. In order to assess auditability we associate data log resources to goals. More properly, 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. In any case when plans (either explicitly modelled or not) are executed to achieve a goal, they use the associated resource. The idea, conceived in the N`omos framework, is that such 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 change can 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 depicted in Figure 5. The ultimate purpose was to revise existing models, searching for compliance goals. Once found, compliance goals have been elaborated to be made auditable. For example, the [Local Authority] has the goal [Ask user authorisation], which has been developed to comply with the duty to have such authorisation from the user before processing his data, can’t be proved at run-time. Even if the authorisation is requested, if a legal controversy arises, the developed models do not inform on how to 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 the authorisation record, where we store the name of the patient, who gave the authorisation, 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 their databases. In this case, the goal to [Verify user’s authorization] had been added, to avoid that failures of other local authorities in getting the authorisation from the user may lead to compliance issues. Again, in this case, from the model it’s not possible to specify how the achievement of this goal can be monitored. For this reason, after having verified the presence of the authorisation information within the broadcasted message, the [Local Authority] stores such information in another log, which informs on which authorisations have been received and from which peer. Additionally, we enriched the model with a resource dependency form the [Local Authority] to the service [S3] (of the 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 is not explicit in the model, so it’s not possible to associate the behaviour of [S3] with its auditability 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 to the authorisation to process them.

5

Results

The proposed approach has led to some important results. The Software Requirements Specification (SRS) document has been integrated to reflect the compliance solutions found, and to support the auditability of the compliance solutions. Table 1 reports the most important additions introduced by the N`omos analysis. In the table, the first column reports the law or law fragment, which the requirement has been developed for; the second column presents the description of the requirements, gathered or induced by the law fragment; the third column indicates whether the requirement is intended to be audited at run-time. As the first column shows, not all of the articles in the selected law slice were addressed. This is due to the demo scenario, which concerned only on search, addition and update of data: so, law articles not impacting on these functionalities were not addressed. On the contrary, one article - the 157.1 - has been considered, even if not contained 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 Art. 7.1 Art. 7.2e Art. 7.3a, 7.3b Art. 9.4 ... Art. 157.1

Requirement The Local Authority registers users’ authorisations The Local Authority writes the User’s in the Authorisations base The Local Authority inserts the data into the local DB The Local Authority verifies the entrance of new peers The Local Authority maintains the list of verified peers S1 gets the list of verified peers from the Local Authority The Local Authority writes data modifications to log The Local Authority identifies the patient by means of identity card The Local Authority records patients’ ID card number ... The Local Authority produces a report with the collected data to the Garante

Audit X X X X X X

Table 2. An excerpt of the Auditability Requirements document. Auditability document Authorisations record

Reponsible Local Authority

Database log

Local Authority

Broadcast log Requests log

S3 Local Authority

Peers list

Local Authority

When used Request of user’s authorisation Insertion of dirty data into the local DB ... Insertion of dirty data ... Broadcast of dirty data entries Requests of data modifications are received from the patient Changes are made in the local database 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 controlling law application. The Garante has monitoring responsibilities, and may request from the data processors to “provide information and produce documents”. Such information and documents are those derived with the use of the N`omos framework, and are in the following enumerated in Table 2. Table 2 shows the overall results of the analysis process. It reports the auditability documents for the identified compliance goals. The table has been created by collecting from the model all the data logs used as auditing sources. The first column contains the name of the audit document. The second column contains the name of the actor, who is in charge of maintaining the document. The third column contains the cases, in which the document is modified. Basically, the content of the table has to be attached to the SRS, and specifies what documents does the system need 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 of the N`omos framework by answering a set of questions. We summarize it below in terms of 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 N`omos models of law. Primarily, an overall decrease in ambiguity. The representation of 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 models can be a powerful communication language. Worth saying that in order to be used for interaction, 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, including meetings with the industrial partner, and also modelling and analysis of compliance goals. The analysis of the law sources was not included in this estimation: in fact, it was necessary in any case, regardless of the use of the N`omos framework. The modelling activity lasted around 7 person-days. Overall, 29 law articles (including sub-paragraphs) were analysed. Out of them, 10 were mapped into normative propositions (focusing on the demo scenario described in Section 3), from whose analysis 12 new goals were added to the goal diagram of the demo scenario, and 5 audit resources were identified. Globally, 25 new requirements were derived, including those related to log data for compliance auditing. We considered as requirements: the goals, added for compliance reasons; the resources, representing auditable data logs; and associations, between goals and resources, considered as the explanation of which processes are responsible to maintain the auditing logs. A quantitative evaluation reveals a productivity measure of around 4 elements per day. This is not a high number, with respect to the limited demo scenario, but the identified requirements were previously not considered at all. So, the use of the N`omos 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. Once found, and after the proper compliance goals have been identified, an additional effort consists in keeping synchronised the use of auditability resources by different compliance goals across the models. In case of a large model, the effort to face these activities may be considerable. To partially mitigate this fact, the framework does not seem to introduce additional complexity, if compared to the effort of working directly on the textual sources of the law; law is in fact the major source of complexity. As mentioned above we exclude from this analysis the effort needed to analyze laws with the purpose of extracting normative propositions. What advantages did the analysts see in using the framework? The N`omos framework allowed for a straightforward association of compliance goals to legal prescriptions. In particular, when a normative had effects on multiple parts of the model, the visual notation of the framework effectively gave to the analysts the capability to easily observe these effects. The association of auditing resources to compliance goals was more complex. Identifying resources required to deeper comprehension of previously created goals. For example, the goal [Ask user authorization] generated the problem that a hard copy of the authorisation cannot be broadcasted. This forced us to reconsider the semantics of the 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 a goal or task, we noticed that the meaning of this association changed depending on the semantics of the goal (or task). For example, when the goal [Ask user authorization] and the 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 for reading data. The difference between these two cases is important, because producing data actually refers to the capability to provide auditability of compliance goals. This has been resolved by adding annotations to the goal models, in order to be able to differentiate requirements for auditable compliance, from others.

7

Related Works

In recent years, there has been various efforts to deal with law-related issues from the requirements elicitation phase. Ant`on and Breaux have developed a systematic process, called semantic parameterisation [2], which consists of identifying in legal text restricted natural language statements (RNLSs) and then expressing them as semantic models of rights and obligations (along with auxiliary concepts such as actors and constraints). Secure Tropos [5] is a framework for security-related goal-oriented requirements modelling that, in order to ensure access control, uses strategic dependencies 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 intentional elements. Along similar lines, Darimont and Lemoine have used KAOS as a modelling language for representing objectives extracted from regulation texts [3]. Such an approach is based on the analogy between regulation documents and requirements documents. 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 used for both regulations and requirements. Likewise, Rifaut and Dubois use i* to produce a goal model of the Basel II regulation [8]. Worth mentioning that the authors have also experimented this goal-only approach in the Normative i* framework [10], in which the notion of compliance was not considered. Finally, much work has been done in AI on formalizing law, e.g. [7, 9]. We use some of this work as a foundation for our framework. However, our software engineering task of having a person check for compliance between a model of law and another of requirements is different from that of formalizing law for purposes of automatic question-answering and reasoning.

8

Conclusions and Future Work

The paper reports on the application of the N`omos framework to ensure compliance and 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 N`omos framework has been refined introducing the distinction between strategic goals, the goals related to the strategic dimension of the domain, and compliancy goals, devoted to the fullfilments of norms in the domain. Moreover, we introduced the concept of auditability for the requirements

and means to dscribe it in the N`omos requirements models. More case studies need to be conducted, that do not involve principal authors of the N`omos framework, to validate the approach and to evaluate the effort needed to introduce it in a typical requirement analysis process. Acknowledgement. The activities described here have been funded by the Autonomous Province 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. Ant´on, and J. Doyle. Semantic parameterization: A process for modeling domain 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 and M. Lemoine, editors, ReMo2V, held at CAiSE’06, volume 241 of CEUR Workshop Proceedings. CEUR-WS.org, 2006. 4. S. Ghanavati, D. Amyot, and L. Peyton. Towards a framework for tracking legal compliance in healthcare. In J. Krogstie, A. L. Opdahl, and G. Sindre, editors, CAiSE, volume 4495 of Lecture Notes in Computer Science, pages 218–232. Springer, 2007. 5. P. Giorgini, F. Massacci, J. Mylopoulos, and N. Zannone. Requirements engineering meets trust management: Model, methodology, and reasoning. In ITRUST-04, volume 2995 of LNCS, pages 176–190. SVG, 2004. 6. W. N. Hohfeld. Fundamental Legal Conceptions as Applied in Judicial Reasoning. Yale Law Journal 23(1), 1913. 7. V. Padmanabhan, G. Governatori, S. W. Sadiq, R. Colomb, and A. Rotolo. Process modelling: 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 the quality of iso/iec 15504 based compliance assessment frameworks. In Proceedings of RE 2008, pages 33–42, Washington, DC, USA, 2008. IEEE Computer Society. 9. G. Sartor. Fundamental legal concepts: A formal and teleological characterisation. Artificial Intelligence 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 the effectiveness 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 requirements. 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-compliant requirements. 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.