ABSTRACT

There is no doubt that the privacy of people, the confidentiality of their information, the integrity of transaction holding, and the availability of service systems are all essential and any threats in any one of these aspects will be costly and could lead to disaster. Thereby securing computer services has been considered as a core part of any new development one of which is the clinical information systems. In this report we will discus a security policy model for a clinical information system [1,2] and investigate whether logical languages can represent the principles of this model. We have used three security logical languages: the Authorization Specification Language (ASL) [3], a Language for Security Constrains on Objects (LaSCO) [4] and Ponder: a Language for Specifying Security and Management Policies for Distributed Systems [5]. We will also study whether these principles are sufficient to deal with the case of multi-agency services and sharing information with the different agencies such as social services, police and education authority.

Keywords

Security policies, security models, multi-agency services, clinical information systems.

INTRODUCTION

For economy of expression and to make it easy for readers to link with Anderson’s model, we will assume that the clinician is female and the patient male.

A security model for clinical information systems has been proposed by Ross Anderson to allow the British Medical Association (BMA) to meet security requirements of the electronic patient record (EPR) and to be the base of any proposed system claims to operate the EPR. Anderson's model is composed of a set of principles based on a statement found in the (Good Medical Practice) booklet issued by the General Medical Council (GMC), says:

Patients have a right to expect that you will not pass on any personal information, which you learn in the course of your professional duties, unless they agree.

This raises the following questions. Is a patient/patient's guardian qualified enough to give consent and be aware about all consequences that could accrue in future including security threats? For instance some patients consider their clinicians commands as a part of their treatments and must be obeyed. Are ordinary patients usually familiar with how their information could be used in future? Despite his guardian's help, which may derive the patient to permit an action that may consequently lead to security threats. For example patients with a little knowledge about the abuse of clinical information will assume that to reject giving consent is safer. Who is responsible in case a patient died as a result of rejected consent? Nevertheless a patient may find himself forced to give a consent that authorizes other agencies to gain access to his medical record in order to obtain a particular service, for instance [8] to claim for a reimbursement for the cost of doctor visit (in US but still there might be many examples in UK as well) from your insurance company you need to fill a form that include the following part:

I authorized any physician, hospital, or other medical related facility, insurance company, or other organization, institution or person, that has any record or knowledge of me or my dependents, or our health to disclose, when ever requested to do so by CAN or its representatives, any and all such information. A photocopy of this authorization shall be considered as effective and valid as the original.

Principle 1: Each identifiable clinical record shall be marked with an access control list naming the people or groups of people who may read it and append data to it. The system shall prevent anyone not on the access control list from accessing the record in any way.

Principle 2: A clinician may open a record with herself and the patient on the access control list. Where a patient has been referred, she may open a record with herself, the patient and the referring clinician(s) on the access control list.

The clinician-may-open-record clause in principle 2 makes this principle difficult to be logically represented. It can be only understood as following: a clinician must open a new clinical record associated with a new access control list for a patient if the new information appear to be hidden from users who already have access to this patient's clinical record unless this principle is not needed to be formally implemented. There should be, at least a measurement/mechanism to find out whether a clinician was right by opening/not opening a new medical record for a patient according to her judgment about the security level of the new information.

Principle 3: One of the clinicians on the access control list must be marked as being responsible. Only she may alter the access control list, and only she may add other health care professionals to it.

Let's consider the case where the responsible clinician is the only authorized user to alter the access control list for a certain clinical record. For instance she forgets her password or deletes her record from the access control list, which means losing access to the access control list of that clinical record. Who is going to make the access control list available again? We may assume that a new access control list has to be created to that clinical record to replace the inaccessible one and/or there will be another higher level of security such as system administrator. However this assumption is against the goal of principle 3, which is based on the responsible clinician being the highest security level for a certain clinical record unless the super authorization (e.g. system administrator) might be made as an exception comparable to the accident and emergency staff authorization. The second part of the confusion is that in which technical level is the position of the responsible clinician at network level? Is it operating system level, meddleware level, application level)? Definitely it's going to be impracticable for a clinician to manage control on all these levels, so her control will be in one level, which very likely will be at the application level. Logically the levels beneath compromise security mechanisms of any higher level. For instance the security mechanism from application level can be bypassed using power control of the operating system.

Principle 4: The responsible clinician must notify the patient of the names on his record's access control list when it is opened, of all subsequent additions, and whenever responsibility is transferred. His consent must also be obtained, except in emergency or in the case of statutory exemptions.

Principle 5: No-one shall have the ability to delete clinical information until the appropriate time period has expired.

Principle 6: All accesses to clinical records shall be marked on the record with the subject's name, as well as the date and time. An audit trail must also be kept of all deletions.

Principle 7: Information derived from record A may be appended to record B if and only if B's access control list is contained in A's.

Principle 8: There shall be effective measures to prevent the aggregation of personal health information. In particular, patients must receive special notification if any person whom it is proposed to add to their access control list already has access to personal health information on a large number of people.

Principle 9: Computer systems that handle personal health information shall have a subsystem that enforces the above principles in an effective way. Its effectiveness shall be subject to evaluation by independent experts.

The manual nature of principle 9 makes it unsuitable to be represented by the logical languages. For this reason we will assume that it has no part to play in the following sections.

Using security logical languages to represent Anderson's Principles:

General Definitions:

Some important definitions need to be stated before we start using a logical language to represent a security policy:

Closed Policies (positive Authorizations):

An access is granted if there is an authorization stating that the user can access the object.

Open policies (negative Authorizations):

A user can access any object unless it has been explicitly denied.

An access Control policy: is a set of rules defining what is authorized.

An access control mechanism: is a policy implementation to ensure that all accesses are in accordance with the underlying policy.

The Authorization Specification Language (ASL):

Definitions and an overview:

ASL [3] is a language for expressing the authorization according to access control policies. ASL supports a model based on two elements, an object (o) which could be a file or directory in a operating system or table in relational database, and an authorised entity who could be a user (U), group (G), or roles (R). An authorization policy in ASL is a mapping that maps 4-tuples (o, u, R, a) to the set {+, -}, where o is an object, u is a user, R is a role, and a is an action, while + means authorised and - means denied.

ASL is designed principally to express the following rules:

Authorization Rules: used by the System Security Officer (SSO) to allow or deny accesses to objects explicitly in the following form:

cando(o, s, <sign>a) ¬ L1& …. &Ln

This predicate symbol states that a subject s can (Positive authorization sign = "+") or can not (negative authorization sign = " -") perform the action a on the object o under the conditions that specified by L1& .. &Ln

Where L 1 ,…, Ln could be one of the following literals: in, dirin, or typeof. principle 1 in the following section is an example of this rule.

Derivation Rules: used to derive implicit authorizations from explicit authorizations and determine the authorization policy. Indeed it is for expressing propagation of authorization along subject's hierarchies. In addition derivation rules can express some kinds of implication relationships such as the derivation of an authorization in the base of the presence or the absence of other authorizations. The derivation rule has the following form:

dercando(o, s, <sign>a) ¬ L1& …. &Ln

The right hand side of this rule derives a positive or negative authorization

(Determined by <sign>) for a subject s to perform the action a on the object o according on another authorization in the right hand side (L1& …&Ln ) Where L 1 ,…, Ln could be one of the following literals: cando, dercando, done, do, in, dirin or typeof.

Resolution Rules: used to regulate how to resolve any conflict could accrue between authorizations specified by the authorization rules cando and dercando as in the following form:

do(o, s, <sign>a) ¬ L1& …. &Ln

This form states the enforcement of exercising (if sign = +) or forbidding (if sign = -) an access on an object by a subject s in case of a conflict in the Authorization rules (cando or dercando) in the right hand side.

Access Control Rules: to be used to regulate access control decisions on the basis of authorization specified by the authorization rules.

Access control rules have the following form:

grant(o, u, rs, <sign>a) ???L1& …. &Ln

This form states that a request submitted by a user u with active roles R to perform the action a will be allowed (sign = +) or forbidden (sign = -) based on an authorization condition on the right hand side L1& …. &Ln

where L1& …. &Ln are either cando, dercando, done, do, in, dirin, or typeof

Integrity Rules: used to express different kind of constrains on the specifications and the use of authorizations. Integrity rule is a rule of the form:

error()¬ L1& …. &Ln

where L1& …. &Ln are either cando, dercando, done, do, in, dirin, or typeof

This rule derives an error every time the conditions in the right hand side of the rules are satisfied.

Using the authorization language (ASL) for specifying the clinical security principles:

Principle 1:

A subject s can read from and write on a clinical record clincal_record if and only if she is in the access control list Clinical_Record_ACL (here specified as a role) of that record.

The following is just an authorization rule. The left hand side part (cando(clincal_record, s, +read/write)) is the authorization that is to be given and the right hand side part (in(s, Clinical_Record_ACL)) is specifying conditions that must be verified for the authorization to be hold.

¬ cando(clincal_record, s, +read/write)

¬ in(s, Clinical_Record_ACL)

Principle 3 and 4:

The following code states that a subject patient must read his access control list Clinical_Record_ACL if it has been appended by a subject clinician who is authorized to do so

¬ cando(Clinical_Record_ACL, clinician, +append)).

do(Clinical_Record_ACL , patient, +read)

¬ cando (Clinical_Record_ACL , patient, +read)

¬ done (Clinical_Record_ACL, clinician, append) ¬ cando (Clinical_Record_ACL, clinician, +append)

Observations:

ASL is a language for expressing the authorization in matter of allowing or denying an access to an object. There is no way to express consequence actions that should be carried out after some authorised access such as auditing operations (e.g. principle 6). In addition it is not clear in this language how to express authorization restricted by number of accesses for instance controlling aggregation problem (e.g. principle 8).

A Language for Security Constrains on Objects (LaSCO):

An overview:

LsSCO [4] is based on a model where a system consists of objects and events. The attributes on an event denote the specifics of the event’s execution. Policies in LaSCO are stated as policy graphs which describe a specific state of the system (domain) and specific access constraints (requirements). Predicates are annotations near the nodes (objects) and the edges (events) to describe the domains (in the graph written as bold text, e.g. type="user" and Method="access" -- as in figure 1 --) and requirements (in the graph written as normal text) . LaSCO uses variables called policy variables. A policy variable represents a value of an attribute and relates attribute values associated with different objects and events. Variables may appear as operands in domain (e.g. in figure 1 ID=$UID) and requirement predicates (e.g. in figure 1 $UID Î ACL). They are denoted by a “$” prefix.

Using LaSCO to describe the clinical security principles:

Principle 1:

The policy graph in figure 1 indicates that a user/subject needs to have his/her/it ID that represented by the policy variable $UID included in ($UID Î ACL) the access control list of the clinical record in order to have an access to it.

Figure 1: a security policy graph represents principle 1 of the clinical security policy.

Principle 2:

If the user's security level/clearance (represented by the policy variable $UL) is not the same as (stated by the event requirement $UL # $FL) the clinical record's security level (represented by another policy variable $FL) a clinician may create a new clinical record with new access control list as shown in figure 2.

Figure 2: a security policy graph represents principle 2 of the clinical security policy.

Principle 3:

The policy graph in figure 3 states that a user (represented as an object, which is stated by a set of attributes type and position in addition to policy variable $ID) can only append (represented in the policy graph as an event called method with value "append") the access control list for a clinical record (represented as an object, which is stated by a set of attributes type and name) if she is marked as responsible clinician (This condition represented as a requirement says that the ID of that user has to be the value of attribute called responsible_clinician).

Figure 3: a security policy graph represents principle 3 of the clinical security policy.

Principle 4:

Since principle 4 includes two events under different restrictions, we will divide it into two principles: principle 4a considers the part that says the responsible clinician must notify the patient of the names on his record's access control list when it is opened, of all subsequent additions, and principle 4b considers the part that says whenever responsibility is transferred the Patient's consent must also be obtained, except in emergency or in the case of statutory exemptions.

Principle 4a:

The policy graph in figure 4 specifies the first part of principle 4 by restricting the method add to be executed after the method message (where add and message are events and the restriction ensured by a security requirement that enforces the order of these two events Time > $ST). So adding a new user to the access control list will not be allowed before sending message to the patient containing the name of the user who it is proposed to be added to the access control list of his clinical record.

Figure 4: a security policy graph represents the first part of principle 4 of the clinical security policy.

Principle 4b:

The policy graph in figure 5 specifies the second part of principle 4 as following: the event change responsibility is restricted by either the case is an emergency or the other event Name="Consent" && Permit=$PM has been performed and the consent has been given $PM=true || Case="emergency".

Figure 5: a security policy graph represents the second part of principle 4 of the clinical security policy.

Principle 5:

The policy graph that is shown in figure 6 states that event delete can he called by a subject to delete a clinical record (an object) if and only if the system date $sysdate (Policy variable) is grater than or equal to the expire date of that clinical record $Edate (Policy variable).

Figure 6: a security policy graph represents principle 5 of the clinical security policy.

Principle 6:

The policy graph that is shown in figure 7 specifies principle 6 by enforcing that a log record to be created contains a subject id ($SID), the access date and time ($DT), the access id ($ADID), and the accessed clinical record ($RID) for any access to the clinical record instance.

Figure7: a security policy graph represents principle 6 of the clinical security policy.

Principle 7:

The policy graph that is shown in figure 8 represents the information flow control by ensuring that the access control list for the source record is a subset of the access control list of the destination record ($ACL_B Î $ACL_A)

Note that: this principle is also implicitly shown in principle 1 representation

Figure 8: a security policy graph represents principle 7 of the clinical security policy.

Principle 8:

The policy graph that is shown in figure 9 states that adding a new user to the access control list of a patient's medical record is not allowed before sending a message to patients informing them that the user who is proposed to be added to their access control list already has access to personal health information on a large number of people NoA > n (where NoA is the number of accesses for the proposed user, and n is a constant) .

Note that the order of the two events is enforced by ensure that the time of the add method is grater than the time of message method Time > $ST.

Figure 9: a security policy graph represents principle 8 of the clinical security policy.

A Language for Specifying Security and Management Policies for distributed Systems (Ponder):

Definitions and an overview:

Ponder [5] is a declarative and object-oriented language that includes constructs for specifying the following basic policy types:

Authorization policies specify what activities a subject is permitted or forbidden to do. In other word specifying positive (auth+) and negative (auth+) authorization policies (Principle 1 in the following section is represented as a positive authorization while principle 5 is an example of the negative authorization)
Obligation policies specify what activities a subject must do. These policies are triggered by events and are usually interpreted by a manager agent. An example of this type is found in principle 2.
Refrain policies define actions that subjects must refrain from performing.
Delegation policies define what authorizations can be delegated and to whom.
Composed policies are used to define a syntactic scope for specifying a set of related policies. There are four types of composed policies: groups, roles, relationships and structure management.
Meta policies specify a permitted value for a valid policy.

The reader of this report will note in the following section that all Anderson's principles fall into two types of security policies, authorization policies and obligation policies because these principles attempt to restrict the access control and/or enforce consequence actions such as auditing process.

Using Ponder language to describe the clinical security principles:

Principle 1:

A subject s of type user is authorized (can perform the action) to read and/or append the clinical record r if and only if s is in the access control list of the clinical record r.ACL where r.ACL is the access control of the clinical record r.

Note that type is a type definition introducing a new user-defined policy type, from which one or more policy instances of that type can be created, auth+ is a reserved word indicating that the following is a positive authorization policy, principle1 the name of the policy type, subject<user> s means that s is a subject of type user, target <clinicalRecord> r means that r is the target object of type clinical Record to be accessed by the subject s, action is a reserved word followed by the action (read and append) that is needed to be authorized, and belongs is a user define function to check whether the subject s is a member of the access control list of the record r if so the positive authorisation will be allowed result = enable;

type

auth+ principle1 (subject <user> s,

target <clinicalRecord> r)

{

action read, append if belongs(s, r.ACL)

{

result = enable;

}

Principle 2:

In case of new clinical information for a patient NewInformation appears to be in a different security level isDifferentSecLevel. With the exist access control list currClinicalRecordAcl a new access control list newClinicalRecordAcl has to be created

Note that on is a reserved word followed by the obligation condition, and isDifferentSecLevel is a user defied function to compare the new information against the current security level and check whether it is a different security level in this case the mandatory action has to be performed do createNewACL(newClinicalRecordAcl)).

type

oblig principle2 (subject <responsible_clinician> s,

target <ACL> currClinicalRecordAcl,

newClinicalRecordAcl,

<ClincalData> newInformation)

{

on isDifferentSecLevel (currClinicalRecordAcl,

NewInformation);

do createNewACL(newClinicalRecordAcl));

}

Principle 3:

A subject s of type clinician is authorized (can perform the action alter/append) to alter and/or append the access control list of a clinical record clinicalRecordAcl if and only if s is marked as a responsible user in the access control list.

type

auth+ principle3 (subject <clinician> s,

target<ACL> clinicalRecordAc

{

action alter, append

if position(s, clinicalRecordAcl) = "responsible"

{

result = enable;

}

Principle 4:

This principle is divided into two parts the first principle4a concerns informing the patient about any new addition to his clinical record access control list via the responsible clinician. This part is represented as follows: in case of adding new record addNew to a patient's access control list of his clinical record clinicalRecordAcl, consequently that patient has to be informed informPatient.

type

oblig principle4a (subject <responsible_clinician> s,

target <ACL> clinicalRecordAcl,

clinician newName)

{

on addNew (newName, clinicalRecordAcl);

do informPatient (newName);

}

The second part of this principle (principle4b) deals with the case of changing the responsibilities in the access control list of the clinical records. This part is represented as follows: a subject s of type responsible clinician will be authorized to change the responsibilities in the access control list of a patient clinical record if and only if he has obtained that patient's consent.

type

auth+ principle4b (subject <responsible_clinician> s,

target <ACL> clinicalRecordAcl)

{

action changeResponsibility

if PatientConsent (clinician,

newResponsibility)=true

{

result = enable;

}

Principle 5:

A subject s cannot delete clinical record r until this record expired todayDate() > expireDate(r).

Note that when is called the authorization filter and is used to restrict an action by a given condition.

type

auth- principle5 (subject s, target<clinicalRecord> r)

{

action delete;

when todayDate() > expireDate(r);

}

Principle 6:

An audit record contains the subject identifier s, date aDate and time aTime of action, type of action aType, and the record that has been accessed r for all accesses on the clinical record r by a subject s must be created.

type

oblig principle4 (subject s, target <clinicalRecord> r)

{

on allAccess (s, aDate, aTime, aType, r);

do createAuditRecord (s, aDate, aTime, aType);

}

Principle 7:

Transferring data from clinical record A to clinical record B is not allowed unless all records in the access control list of b clinicalRecordAcl_B are included in the access control list of a clinicalRecordAcl_A.

type

auth- principle7 (clinicalRecord A,

ACL clinicalRecordAcl_A,

ACL clinicalRecordAcl_B,

target<clinicalRecord> B)

{

action transfer(a.data, b.data);

when List(clinicalRecordAcl_B) in

List(clinicalRecordAcl_A)

}

Principle 8:

In the case of adding a new record (grant new user to have access to a clinical record) to a patient access control list, consequently the patient has to be informed at how many records the new user has access to.

type

oblig principle8 (subject <responsible_clinician> s,

target <ACL> clinicalRecordAcl,

clinician newName)

{

on addNew (newName, clinicalRecordAcl);

do informPatient (newName,

getNoAccess(newName));

}

Comparisons:

Although all the above languages are basically targeting specifying security polices, they focus on different aspects, for instance ASL focuses more on the access control policies and LaSCO attempts to express constraints on objects, while Ponder aims to specify security and management policies for distributed systems. Additionally they are different from the language's character point of view. Whereas ASL is based on logic and LaSCO policies are specified as logical expressions and as directed graphs, Ponder is a declarative language inheriting its syntax from the OCL "Object Constrain Language". According to the nature of each one of these languages we have found that some of Anderson's principles are not representable. For example principles such as those concerning auditing operations (e.g. principle 6) and control aggregation problems (e.g. principle 8) were not representable by ASL and indirectly expressed by LaSCO. On the other hand Ponder was more suitable for those kinds of principles since Ponder has got forms to deal with the management polices. Table 1 illustrates the comparison between these three languages according to their ability to express Anderson's clinical security principles.

Table 1: Comparison table shows how far ASL, LaSCO and Ponder language can represent Anderson's principles.

Need-to-know problem:

Need-to-know was not included in the Anderson's model, as the BMA does not accept that 'need-to-know' is an acceptable basis for access control decisions further details found in [1,2]. however there might be a case where the need-to-know can not be avoided. For instance a service provider such as social services offers its services conditioned by some information about the patient who applies for such services. There are two major problems in this case. Firstly who is authorised to decide about who needs to now in multi-agency services environment where responsibilities are distributed, and how to resolve the conflict between the patient consent and need-to-know? Further investigation will take place to find out whether the mandatory need-to-know exists. Since there is no need-to-know without a task, we propose an approach based on associating the data with tasks and grant these tasks to performers rather than giving direct authorization to the secret data. The task could be in a form of an agreement between the information’s owner and who needs to know (task’s performer) and consisting of full awareness about the task that requires the information, information size, release time, time of expire, and guaranty to restrict the use of this information by the specified task. We shall explain this approach and need-to-know problem in detail in another report.

It is important to note that there is a previous work considering a task based access control model [9]

Multi-agency services environment and collaboration issue

Despite some forms of cross-organization access control such as principle 4 that requires informing the patient about any addition to his record access control list or those concerning the auditing aspect (e.g. principle 6). In general the issue of sharing clinical information including collaboration activities with other agencies such as police, social services or the education authority were not clearly considered [7]. One possible reason could be that these principles derived from centralized system idea at least from responsibilities and ownerships point of view.

Conclusion

Anderson in his papers [1,2] argues that a security solution is an issue requiring great care to make the security mechanisms work together rather than a mechanisms selection and that a user whose computer and administrative skills are less than average can easily manage the system. Giving at the end a short evaluations of the available security mechanisms, and architectures and predicates, the selection of any solution that should support the above requirements to the systems suppliers/vendors with suggesting that the selected system need to be tested and evaluated by independent party without specifying or recommending a specific security mechanism/architecture.

Although professionals in health care information technology believe that any implementation of Anderson's principles would be expensive to implement and unmanageable to maintain, others such as Denley and Smith [6] according to their experience in the implementation of these principles in three British hospitals: ConquestHospital, Aintree Hospital, and Royal Devonand Exeter Hospital state that Anderson's principles can be applied to the electronic patient record to maximise privacy.

Our work at the end may possibly contribute to the solution of the clinical information systems security problem by discussing Anderson’s security model for the clinical information systems and proves logically the principles of this model by implementing them using some selective languages for specifying security policies. finally Anderson's principles are only being applicable to a centralized systems. In addition there were no precise principles in this model considering neither the multi-agency services environment nor the need-to-know problem, which was rejected by the BMA.

ACKNOWLEDGMENTS

……………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………....

REFERENCES

Ross Anderson. Security in clinical information systems. BMA Report, British Medical Association, Jan 1996, ISBN 0-7279-1048-5.

Ross Anderson. A security Policy Model for clinical information systems. In Proceedings of the IEEE Symposium on Research in Security and Privacy, Research in Security and Privacy, pp. 30–43. IEEE Computer Society, Technical Committee on Security and Privacy, IEEE Computer Society Press, Oakland, CA, May 1996.

Jajodia, Sushil, Pierangela Samarati, and V.S. Subrahmanian. A Logical Language for Expressing Authorizations. in Proceedings of the 1997 IEEE Symposium on Security and Privacy. Oakland, CA, USA: IEEE Press, 1997. p. 31-42.

Hoagland, James, Raju Pandey, and Karl Levitt. Security Policy Specification Using a Graphical Approach. Technical report CSE-98-3, The University of California, Davis Department of Computer Science. July 1998.

Nicodemos Damianou, Naranker Dulay, Emil Lupu, Morris Sloman. Ponder: A Language for Specifying Security and Management Policies for Distributed Systems The Language Specification Version 2.2. 15 July, 2000

available at http://www-dse.doc.ic.ac.uk/policies

Ian Denley, Simon Weston Smith. Privacy in clinical information systems in secondary care, 15 May 1999, Available at http://www.bmj.com/cgi/content/short/318/7194/1328

Rory O'Conor. Commentary: Organisational and cultural aspects are also important. 15 May 1999

available at http://www.bmj.com/cgi/content/short/318/7194/1328#resp2

Simson Garfinkel. Database Nation - The death of privacy in 21^st century. Sebastopol, CA: O'Reilly & Associates, 2000. ISBN 1-5659-2653-6

R. K. Thomas and R. S. Sandhu. Task-based Authorization Controls (TBAC): A Family of Models for Active and Enterprise-oriented Authorization Management. Proceedings of the IFIP WG11.3 Workshop on Database Security, Lake Tahoe, California, August 11-13, 1997