Dr' Liang Xiao

1
Developing a Security Protocol for a Distributed
DecisionSupport System in a Healthcare
Environment

• Dr. Liang Xiao
• University of Southampton
• United Kingdom

2
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
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
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
Key components and architecture
6
The HealthAgents network
7
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 patients data to be located and
  removed at any time when requested
• Full patient records are kept for clinical
  purposes within the treating hospital

8
Data transmission among distributed sites
9
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
Types of case and classifier their access
principle

• 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)

11
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
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
Data sensibility levels and access control
policies

• 0. Update a private patient record often only
  available to the patients 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.

14
Three security levels
15
The security architecture (a cross-hospital
resource access scenario)
16
Secure Message Transportation
17
Authentication

• Java Authentication and Authorisation Service
  (JAAS) provides a framework for user-based
  authentication
• A users 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 subjects 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
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
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
(No Transcript)
21
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
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_petitio
ner, CPID) then classificationResults(S) ?
a(classifier_petitioner, CPID) then
a(clinician_followingdiagnosis, CID) / R14
update case record and classifier reputation
following diagnosis / a(clinician_followingdiagno
sis, 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_upda
te_policy_set) then caseRecordUpdated (Y) ?
a(clinician_followingdiagnosis, CID)
25
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.setAccessAudi
t(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
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) projects

27
Questions?