Developing a Security Protocol for a Distributed Decision

Developing a Security Protocol for a Distributed Decision Support System in a Healthcare Environment Dr. Liang Xiao University of Southampton United Kingdom 1 30 th International Conference on Software Engineering

Background and motivation • Security in Software Engineering – Non-functional requirements – Software quality (IEEE standard, etc. ) – Relationship with functional requirements • Healthcare and security – Data sharing – Patient privacy and confidentiality • Laws and regulations – UK Data Protection Act 1998 • Existing Software Engineering approaches to security in healthcare – Heuristic agents intercept calls to resources – Security agents authenticate user access to electronic healthcare records – Multi-Agent System encrypts private patient records and authorises access before information sharing – Security not considered as an integral part of software design 2 30 th International Conference on Software Engineering

The Health. Agents project Micro. Art ITACA Universitat de València Universitat Autònoma de Barcelona Pharma Quality Europe Katholieke Universiteit Leuven University of Birmingham University of Edinburgh University of Southampton • Partners: seven educational and research institutions and 2 SMEs from Belgium, Italy, Spain, and the United Kingdom • Hospitals distributed in Birmingham, Barcelona, and Valencia 3 30 th International Conference on Software Engineering

The Health. Agents: to create a multi-agent distributed Decision Support System, and help in the early diagnosis and prognosis of brain tumours • Medical imaging techniques such as magnetic resonance spectroscopy (MRS) and laboratory techniques such as gene expression arrays promise to deliver these advances but suffer from a complexity of interpretation which has hindered their incorporation into routine clinical practice • The classification of brain tumours, especially rare types, will enhance with information sought from many hospitals • The application of Pattern Recognition techniques can improve the discrimination between tumour classes and facilitate decision making • This is supported by a distributed system for data collection and management prior to the required classifier training process 4 30 th International Conference on Software Engineering

Key components and architecture Retrieve a local case for classification Create a new classifier Local access control policies apply External access control policies apply to access of cases & classifiers from other clinical centres 5 Inter-centre resource access is via Yellow Pages Agent 30 th International Conference on Software Engineering

The Health. Agents network 6 30 th International Conference on Software Engineering

The use of a link-anonymised data scheme in Health. Agents • Data has personal information (e. g. name, address, date of birth) removed • A unique patient identifier is added • Allow data from the same patient to be added at a later date • Allow a specific patient’s data to be located and removed at any time when requested • Full patient records are kept for clinical purposes within the treating hospital 7 30 th International Conference on Software Engineering

Data transmission among distributed sites 8 30 th International Conference on Software Engineering

Resource access: case vs classifier • Cases are processed and tumour classifiers produced • Cases normally only known to the classifier producer software (agents) • The produced classifier software (agents) as opposed to specific cases are used for decision making in the tumour diagnosis processes • No private patient data that is involved in the production of classifiers will be revealed to the clinical users 9 30 th International Conference on Software Engineering

Types of case and classifier & their access principle • Anonymised patient cases – Validated: diagnosis confirmed – Public: accessible to all Health. Agents nodes – Private: accessible only to the local node or for producing classifiers • Classifiers – Global: trained upon public cases – Local: trained uniquely upon local public and private cases – Specific: trained upon all public cases and local private cases (being given a special weight) 10 30 th International Conference on Software Engineering

The UK Data Protection Act 1998 • Personal data shall be obtained for lawful purposes and processed in accordance with the rights of data subjects – • Personal data shall be processed fairly – • All cases used for the purpose of training classifiers will be discarded when classifiers are produced and will not be kept for longer than it is necessary Appropriate technical and organisational measures shall be taken against unauthorised processing of personal data – – 11 Patient case records are only processed for • the diagnosis of that particular patient • the training of classifiers Personal data processed for any purpose shall not be kept for longer than is necessary for that purpose or those purposes – • Patient consents will be obtained before cases enter into Health. Agents database. Furthermore, patients retain the rights of withdrawing their cases and if requested they will be removed from the databases immediately (via the unique patient identifier) – The publicity of a case and its direct access is strictly controlled by the case home node The routine use of cases, for facilitating decision making, is largely replaced by classifier training software Each clinical centre enforces an appropriate data access control mechanism 30 th International Conference on Software Engineering

The potential dangers on confidentiality, integrity, availability 12 • Theft and disclosure of patient privacy information by a hacker due to insecure transportation network – a confidentiality issue. • Malicious users may create low quality classifiers – an integrity issue. • Accidentally, inexperienced users may assign unreasonable reputation values to classifiers, such incorrect alteration of classifier reputation values will mislead diagnosis results – an integrity issue. • Abuse of system services (Yellow Pages, Classifier Training, etc. ) and so make them unavailable or even replace them with malicious alternatives and direct to wrong diagnosis – availability and integrity issues. • Users from one hospital access data or execute classifiers from another hospital without the proper permission – confidentiality and integrity issues. 30 th International Conference on Software Engineering

Data sensibility levels and access control policies 13 0. Update a private patient record: often only available to the patient’s principle physician. 1. Read a private patient record: also available to the producers of specific classifiers. 2. Read a public anonymised patient record: available to classifier producers and under agreements to other hospitals in the Health. Agents network. 3. Create a classifier: available to specific experienced clinicians with sufficient power who may allow the classifier producers to access required anonymised data and later set the publicity of the classifier. 4. Update a classifier reputation: available to experienced clinicians who have executed that classifier upon a case and the accurate diagnosis result is known to them at that moment. 5. Execute a local classifier: often available to local hospitals. 6. Execute a global classifier: available to all hospitals in the Health. Agents network. 7. Invoke a system service (Yellow Pages, etc. ): may open even to hospitals outside of the Health. Agents network, this allows them to gain better knowledge of the available resources inside the network so they may want to join in later. 30 th International Conference on Software Engineering

Three security levels 14 30 th International Conference on Software Engineering

The security architecture (a crosshospital resource access scenario) 15 30 th International Conference on Software Engineering

Secure Message Transportation 1. An instance of Health. Agent register itself and upon recognition its principal (public key) is added to the trust list In both above situations, Jade. Security. Service. Agent 2. the Health. Agent communicates with other trusted uses validate. Principal to check if the communicating 4. Jade. Security. Service uses secure. Receiving. Message 3. Jade. Security. Service uses secure. Sending. Message agents by using handle. Message, which in turn uses agent’s principal is among the trusted. Principals, being to check if the message sender is trusted and if so, to check if the message receiver is trusted and if so, it Jade. Messaging. Service maintained by Yellow. Pages. Agent at runtime it will decrypt the message and reply in signed and will sign and encrypt the message and send it on encrypted messages 16 30 th International Conference on Software Engineering

Authentication • • • 17 Java Authentication and Authorisation Service (JAAS) provides a framework for user-based authentication A user’s identity is confirmed in authentication and represented by a subject A principal is granted to the user after identity is verified during the authentication A Login. Module performs authentication (verifying a subject’s username and password) The implementation of a Simple. Login. Module is provided in JAAS Alternative Login. Modules can be loaded as configured in a Configuration file, being consulted by a Login. Context invokes a login method of the loaded Login. Module for authentication of subjects and upon success will associate principals with them Principals of a subject can be later retrieved by invoking its get. Principals method JAAS policies can be configured for subjects and grant them authorised permissions following authentication These can be later enforced by invoking do. As(subject, action) method, achieving the effect of having an action run as the subject 30 th International Conference on Software Engineering

Authorisation • • 18 User identification User role and group recognition Security policy rule application Rule scheme: {Subject (Id, Role, Organisation), Resource (Id, Type), Access Operation (Op), Access Context (Co)} – A resource access request message can be identified to its origin and mapped to the roles that subject plays – To ease management, policies are defined on the basis of roles but those on the basis of individuals and organisations are also allowed – In Health. Agents, case records, classifiers, services (Yellow Pages, etc. ) are the resources to which access must be protected – Various access operations may be performed upon resources and they have different sensibility levels. One clinician may be able to execute a classifier but not update its reputation value – A context offers flexibility in access control: 1) allowing in particular situations certain specially delegated access in the name of a particular role; 2) constraining the valid time period associated with the access; 3) providing justification of the special access 30 th International Conference on Software Engineering

A role interaction model for a comprehensive Health. Agents case • 19 A new hospital joins the Health. Agents network with a new MAS setup in that site, new clinician users wish to perform classification upon cases from there, and they do so by creating new classifiers for the purpose 30 th International Conference on Software Engineering

The GUI Agent searches the Yellow. Pages. Agent for available classifiers by The GUI Agent at that node can start to communicate in the Health. Agents The Yellow. Pages. Agent has its principal registered in the trusted list so this The new clinician is authenticated by JAAS via the local GUI Agent and The Yellow. Pages. Agent adds this new node to the trusted node list The GUI Agent requires the building of a new specific classifier using The GUI Agent registers this new node via the Yellow. Pages. Agent The Training. Petitioner. Agent applies a local policy repository and A new classifier is produced and registered to the Yellow. Pages. Agent, The clinician now wants to execute the new classifier upon the case Decision making support is received from the results of the The Yellow. Pages. Agent checks this GUI Agent against the permission Relevant public cases as well as local private cases from the request The local policy rules on the use of the classifier and the particular When an actual diagnosis result is known, the clinician wants to sending questions to solve as the first message it initialises for a new network and now it wants to perform a classification upon a local case conversation is permitted and all ongoing messages signed and encrypted his/her principal is bound with the interface for the entire interactive session distributed data sets which recognises its identity allows the request operation of building a new classifier a copy becoming available to the original request site when being informed of the availability of the classifier classification and a diagnosis will be made later on of using its query service and will perform the query to its registered site will be sent to the building site for the production of the new case will be applied against this specific clinician and he/she will be update the classifier reputation and the case he/she just diagnosed conversation classifiers but unfortunately no such classifier is available classifier and data access policy rules will be applied allowed to do the operation and the local policy rules on both operations will be applied 20 30 th International Conference on Software Engineering

Introducing Lightweight Coordination Calculus (LCC) • Developed in the Open. Knowledge project • Used for the specification of interaction behaviour • Regulate the message exchange protocols among participant peers, each of which plays a particular role that dictates its particular message passing pattern in protocols • a(role, id) : : def denotes that an agent of identity id plays a role of role as defined in def • def describes the message passing behaviour constructed using the following forms: def 1 then def 2 (def 1 satisfied before def 2), def 1 or def 2 (either def 1 or def 2 satisfied), or def 1 par def 2 (both def 1 and def 2 satisfied) • In the def, m a denotes that a message m is sent to agent a while m a denotes that a message m is received from agent a • Also in the def, ← constraint denotes that a constraint must be satisfied before the clause prior to it 21 30 th International Conference on Software Engineering

Resource access interaction formalism agents RRID and RMID play the roles of resource_request and resource_manager Def RMID plays the role of resource_manager and will receive a request message from RRID plays the role of resource_request and will send a request message to RMID RRID has a single and Def. RMID has a composite message passing behaviour which plays the role of resource_manager RRID. It will solve a constraint before a subsequent behaviour carried out a(resource_request, RRID) : : request(Resource, Operation, Context) a(resource_manager, RMID) : : request(Resource, Operation, Context) a(resource_request, RRID) ← grant. Permission(RRID, Resource, Operation, Context, Policies) then ( response(Grant_yes) a(resource_request, RRID) or response(Resource_result) a(resource_request, RRID) ← get. Operation. Result(Resource, Operation, Access_result) ) 22 Constraint being satisfied (or not), RMID responds by sending back a message the constraint is expressed as the resource manager agent applying appropriate Additional computation (for offering the required resource sets) may follow prior to security policies upon the request and as a result a permission is granted either saying the request has been granted (or rejected) or by providing the actual a response message is sent out back to RRID resources (or the results of their usage) being requested 30 th International Conference on Software Engineering

The LCC specification for Health. Agents (clinician roles ) /* R 10: classify a local case using the new classifier just produced */ a(clinician_classify, CID) : : classifier. Available(C) a(yellowpages_register, YPID) then request. Case. Record. By. ID(I) a(database, DBID) then case. Record (R) a(database, DBID) then request. Classification(R, C) a(classifier_petitioner, CPID) then classification. Results(S) a(classifier_petitioner, CPID) then a(clinician_followingdiagnosis, CID) /* R 14: update case record and classifier reputation following diagnosis */ a(clinician_followingdiagnosis, CID) : : ( update. Case. Record. By. ID(I) a(database_update, DBID) then case. Record. Updated(Y) a (database_update, DBID) ) par ( update. Classifier(I) a(classifier_petitioner, CPID) then classifier. Updated(Y) a (classifier_petitioner, CPID) ) 23 30 th International Conference on Software Engineering

The LCC specification for Health. Agents (manager roles ) /* R 11: send a case record for classification */ a(database_download, DBID) : : request. Case. Record. By. ID(I) a(clinician_classify, CID) ← grant. Permission(CID, I, Read, Normal_classify_from_local_site, Local_database_read_policy_set) then case. Record(R) a(clinician_classify, CID) ← get. Case. Record. By. ID(I, R) then a(database_update, DBID) /* R 15: update a case record after classification */ a(database_update, DBID) : : update. Case. Record. By. ID(I) a(clinician_followingdiagnosis, CID) ← grant. Permission(CID, I, Update, Normal_update_from_local_site, Local_database_update_policy_set) then case. Record. Updated (Y) a(clinician_followingdiagnosis, CID) 24 30 th International Conference on Software Engineering

Security policy rule checking • a(role, id) represents a clinician with a unique identity who wants to play a certain function role This identify can be extracted from the message being sent from the sender Associated with that identity, the access rights to resources involved in the function role playing behaviour will be checked by resource manager agents before permissions are granted and functions carried out This means security constraints embedded in the agent interaction protocols must be evaluated satisfactorily with a Boolean value of true returned A grant. Permission method will be provided in the system that will be invoked for security policy application. • • grant. Permission(ID RRID, Resource r, Operation o, Context c, Policy. Set p) { logger. set. Access. Audit(RRID, r, o, c, get. Timestamp()); return apply. Policies(RRID, get. Role. By. ID(RRID), r, o, c, p); …… } • • 25 This offers audit points where each access can be later traced back, hence the auditability of sensitive resource access being enabled The running and execution of LCC specification for agent interaction is supported by the Open. Knowledge kernel 30 th International Conference on Software Engineering

Conclusions 26 • A sustainable security solution has been presented, being developed in accordance with Software Engineering principles and ethical regulations • Provide in a distributed Decision Support System (d-DSS) for healthcare: secure communication, authentication, and authorisation • The functional (interaction model specification and runtime support) and non-functional requirements (security constraint specification and policy rule application) are separated but integrated into a unified framework from the start of software development • Maintenance of either functionalities or security constraints in systems is eased, each clinical centre can separately manage their local policy rules • Implementation work is going on in the Health. Agents (www. healthagents. net) and Open. Knowledge (www. openk. org) projects 30 th International Conference on Software Engineering

Questions? 27 30 th International Conference on Software Engineering