Dr. Liang Xiao University of Southampton United Kingdom

1. Dr. Liang Xiao University of Southampton United Kingdom Developing a Security Protocol for a Distributed DecisionSupport System in a Healthcare Environment

2. 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 Background and motivation

3. The HealthAgents project MicroArt Universitat de València Universitat Autònoma de Barcelona ITACA 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

4. 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 The HealthAgents: to create a multi-agent distributed Decision Support System, and help in the early diagnosis and prognosis of brain tumours

5. 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 Inter-centre resource access is via Yellow Pages Agent Key components and architecture

6. The HealthAgents network

7. 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 The use of a link-anonymised data scheme in HealthAgents

8. Data transmission among distributed sites

9. 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 Resource access: case vs classifier

10. 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. 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 The UK Data Protection Act 1998

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. The potential dangers on confidentiality, integrity, availability

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 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. Three security levels

15. The security architecture (a cross-hospital resource access scenario)

16. 1. An instance of HealthAgent register itself and upon recognition its principal (public key) is added to the trust list 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 2. the HealthAgent communicates with other trusted agents by using handleMessage, which in turn uses JadeMessagingService 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 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 Secure Message Transportation

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 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 Authentication

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 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 Authorisation

19. 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 A role interaction model for a comprehensive HealthAgents case

20. 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 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 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. 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 ordef2 (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 Introducing Lightweight Coordination Calculus (LCC)

22. agents RRID and RMID play the roles of resource_request and resource_manager DefRRID has a single and DefRMID has a composite message passing behaviour RRID 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 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) )

23. 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. The LCC specification for HealthAgents (manager roles ) /* 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)

25. 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. Security policy rule checking 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. 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) projects Conclusions

27. Questions?