1. 1 1 30th International Conference on Software Engineering Leipzig, Germany, 10 - 18 May 2008 Dr. Liang Xiao University of Southampton United Kingdom Developing a Security Protocol for a Distributed Decision Support System in a Healthcare Environment

2. 2 2 30th International Conference on Software Engineering Leipzig, Germany, 10 - 18 May 2008 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

3. 3 3 30th International Conference on Software Engineering Leipzig, Germany, 10 - 18 May 2008 The HealthAgents project MicroArtUniversitat de ValènciaUniversitat Autònoma de Barcelona ITACAPharma Quality EuropeKatholieke Universiteit Leuven University of BirminghamUniversity of EdinburghUniversity 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

4. 4 4 30th International Conference on Software Engineering Leipzig, Germany, 10 - 18 May 2008 The HealthAgents: 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

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

6. 6 6 30th International Conference on Software Engineering Leipzig, Germany, 10 - 18 May 2008 The HealthAgents network

7. 7 7 30th International Conference on Software Engineering Leipzig, Germany, 10 - 18 May 2008 The use of a link-anonymised data scheme in HealthAgents 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

8. 8 8 30th International Conference on Software Engineering Leipzig, Germany, 10 - 18 May 2008 Data transmission among distributed sites

9. 9 9 30th International Conference on Software Engineering Leipzig, Germany, 10 - 18 May 2008 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

10. 10 30th International Conference on Software Engineering Leipzig, Germany, 10 - 18 May 2008 Anonymised patient cases –Validated: diagnosis confirmed –Public: accessible to all HealthAgents 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) Types of case and classifier & their access principle

11. 11 30th International Conference on Software Engineering Leipzig, Germany, 10 - 18 May 2008 The UK Data Protection Act 1998 Personal data shall be obtained for lawful purposes and processed in accordance with the rights of data subjects –Patient consents will be obtained before cases enter into HealthAgents 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) Personal data shall be processed fairly –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 –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 –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

12. 12 30th International Conference on Software Engineering Leipzig, Germany, 10 - 18 May 2008 The potential dangers on confidentiality, integrity, availability 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.

13. 13 30th International Conference on Software Engineering Leipzig, Germany, 10 - 18 May 2008 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 HealthAgents 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 HealthAgents network. 7. Invoke a system service (Yellow Pages, etc.): may open even to hospitals outside of the HealthAgents network, this allows them to gain better knowledge of the available resources inside the network so they may want to join in later. Data sensibility levels and access control policies

14. 14 30th International Conference on Software Engineering Leipzig, Germany, 10 - 18 May 2008 Three security levels

15. 15 30th International Conference on Software Engineering Leipzig, Germany, 10 - 18 May 2008 The security architecture (a cross- hospital resource access scenario)

16. 16 30th International Conference on Software Engineering Leipzig, Germany, 10 - 18 May 2008 Secure Message Transportation 1. An instance of HealthAgent register itself and upon recognition its principal (public key) is added to the trust list 2. the HealthAgent communicates with other trusted agents by using handleMessage, which in turn uses JadeMessagingService 3. JadeSecurityService uses secureSendingMessage to check if the message receiver is trusted and if so, it will sign and encrypt the message and send it on 4. JadeSecurityService uses secureReceivingMessage to check if the the message sender is trusted and if so, it will decrypt the message and reply in signed and encrypted messages In both above situations, JadeSecurityServiceAgent uses validatePrincipal to check if the communicating agent’s principal is among the trustedPrincipals, being maintained by YellowPagesAgent at runtime

17. 17 30th International Conference on Software Engineering Leipzig, Germany, 10 - 18 May 2008 Authentication 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 LoginModule performs authentication (verifying a subject’s username and password) The implementation of a SimpleLoginModule is provided in JAAS Alternative LoginModules can be loaded as configured in a Configuration file, being consulted by a LoginContext LoginContext invokes a login method of the loaded LoginModule for authentication of subjects and upon success will associate principals with them Principals of a subject can be later retrieved by invoking its getPrincipals method JAAS policies can be configured for subjects and grant them authorised permissions following authentication These can be later enforced by invoking doAs(subject,action) method, achieving the effect of having an action run as the subject

18. 18 30th International Conference on Software Engineering Leipzig, Germany, 10 - 18 May 2008 Authorisation 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 HealthAgents, 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

19. 19 30th International Conference on Software Engineering Leipzig, Germany, 10 - 18 May 2008 A role interaction model for a comprehensive HealthAgents case A new hospital joins the HealthAgents 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

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

21. 21 30th International Conference on Software Engineering Leipzig, Germany, 10 - 18 May 2008 Introducing Lightweight Coordination Calculus (LCC) Developed in the OpenKnowledge 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: def1 then def2 (def1 satisfied before def2), def1 or def2 (either def1 or def2 satisfied), or def1 par def2 (both def1 and def2 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

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

23. 23 30th International Conference on Software Engineering Leipzig, Germany, 10 - 18 May 2008 The LCC specification for HealthAgents (clinician roles ) /* R10: classify a local case using the new classifier just produced */ a(clinician_classify, CID) :: classifierAvailable(C)  a(yellowpages_register, YPID) then requestCaseRecordByID(I)  a(database, DBID) then caseRecord (R)  a(database, DBID) then requestClassification(R, C)  a(classifier_petitioner, CPID) then classificationResults(S)  a(classifier_petitioner, CPID) then a(clinician_followingdiagnosis, CID) /* R14: update case record and classifier reputation following diagnosis */ a(clinician_followingdiagnosis, CID) :: ( updateCaseRecordByID(I)  a(database_update, DBID) then caseRecordUpdated(Y)  a (database_update, DBID) ) par ( updateClassifier(I)  a(classifier_petitioner, CPID) then classifierUpdated(Y)  a (classifier_petitioner, CPID) )

24. 24 30th International Conference on Software Engineering Leipzig, Germany, 10 - 18 May 2008 /* R11: send a case record for classification */ a(database_download, DBID) :: requestCaseRecordByID(I)  a(clinician_classify, CID) ← grantPermission(CID, I, Read, Normal_classify_from_local_site, Local_database_read_policy_set) then caseRecord(R)  a(clinician_classify, CID) ← getCaseRecordByID(I, R) then a(database_update, DBID) /* R15: update a case record after classification */ a(database_update, DBID) :: updateCaseRecordByID(I)  a(clinician_followingdiagnosis, CID) ← grantPermission(CID, I, Update, Normal_update_from_local_site, Local_database_update_policy_set) then caseRecordUpdated (Y)  a(clinician_followingdiagnosis, CID) The LCC specification for HealthAgents (manager roles )

25. 25 30th International Conference on Software Engineering Leipzig, Germany, 10 - 18 May 2008 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 grantPermission method will be provided in the system that will be invoked for security policy application. grantPermission(ID RRID, Resource r, Operation o, Context c, PolicySet p) { logger.setAccessAudit(RRID, r, o, c, getTimestamp()); return applyPolicies(RRID, getRoleByID(RRID), r, o, c, p); …… } This offers audit points where each access can be later traced back, hence the audit- ability of sensitive resource access being enabled The running and execution of LCC specification for agent interaction is supported by the OpenKnowledge kernel

26. 26 30th International Conference on Software Engineering Leipzig, Germany, 10 - 18 May 2008 Conclusions 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 HealthAgents (www.healthagents.net) and OpenKnowledge (www.openk.org) projectswww.healthagents.netwww.openk.org

27. 27 30th International Conference on Software Engineering Leipzig, Germany, 10 - 18 May 2008 Questions?