Investor Relations

19 pages
4 views

A knowledgeable security model for distributed health information systems

of 19
All materials on our website are shared by users. If you have any questions about copyright issues, please report us to resolve them. We are always happy to assist you.
Share
Description
Realising the vision of pervasive healthcare will generate new challenges to system security. Such challenges are fundamentally different from issues and problems that we face in centralised approaches as well as non-clinical scenarios. In this
Transcript
  A knowledgeable security model for distributed healthinformation systems Liang Xiao*, Bo Hu, Madalina Croitoru, Paul Lewis, Srinandan Dasmahapatra University of Southampton, UK a r t i c l e i n f o Article history: Received 6 October 2008Received in revised form1 May 2009Accepted 1 August 2009 Keywords: Decision support system (DSS)Distributed clinical informationsystemInteraction modelLightweight Coordination Calculus(LCC)Multi-agent system (MAS)Security model a b s t r a c t Realising the vision of pervasive healthcare will generate new challenges to systemsecurity. Such challenges are fundamentally different from issues and problems that weface in centralised approaches as well as non-clinical scenarios. In this paper, we reflectupon our experiences in the HealthAgents project wherein a prototype system wasdeveloped and a novel approach employed that supports data transfer and decisionmaking in human brain tumour diagnosis and treatment. While the decision making needsto rely on different clinical expertise, the HealthAgents system leveraged a domainontology to align different sub-domain vocabularies and we have experimented witha process calculus to glue together distributed services. We examine the capability of theLightweight Coordination Calculus (LCC), a process calculus based language, in meeting security challenges in pervasive settings, especially in the healthcare domain. The keydifference in approach lies in making the representational abstraction reflect the relativeautonomy of the various clinical specialisms involved in contributing to patient manage-ment. The scope within LCC of accommodating Boolean-valued constraints allows forflexible integration of heterogeneous sources in multiple formats, which are characteristicfeatures of a pervasive healthcare environment. ª 2009 Elsevier Ltd. All rights reserved. 1. Introduction and motivation ‘‘The most profound technologies are those that disappear.They weave themselves into the fabric of everyday life untilthey are indistinguishable from it’’. This is Mark Weiser’svision (Weiser, 2001) of how technologies might eventuallyblend in with our surroundings. Projecting this vision on tohealthcare gives a picture wherein ‘‘smart’’ software agentswould act on behalf of human specialists in collecting/moni-toring critical life support data, extracting information fromthe data, jigsawing information/data together, and eventuallyenabling decisions and actions to be taken on the outcome of suchprocesses. Oneofthemostfar-reachingconsequencesof such a vision is the emergence of a different paradigm of patient care – pervasive healthcare. Currently, a personexperiencing a perceptible ailment invokes the ‘‘patient-seeing-doctor’’ pattern, where a doctor is often an array of specialists. Instead, the new healthcare paradigm emphasisesa degree of continuous medical surveillance, with key deci-sions for medical follow-ups requiring automated processing,and in a decentralised manner.One of the fundamental questions concerning pervasivehealthcare is how to ensure the data are delivered to the rightperson at the right moment. Thus far, knowledge in health-care, to some extent, remains a ‘‘cottage industry’’ withlargely tacit knowledge only explicit to isolated specialists, * Corresponding author . Royal College of Surgeons in Ireland (RCSI), Homepage:http://hrb.rcsi.ie/liang/index.html.E-mail addresses:liangxiao@rcsi.ie,lx@ecs.soton.ac.uk(L. Xiao),bh@ecs.soton.ac.uk(B. Hu),mc3@ecs.soton.ac.uk(M. Croitoru),phl@ ecs.soton.ac.uk(P. Lewis),sd@ecs.soton.ac.uk(S. Dasmahapatra). available at www.sciencedirect.comjournal homepage:www.elsevier.com/locate/cose 0167-4048/$ – see front matter ª 2009 Elsevier Ltd. All rights reserved.doi:10.1016/j.cose.2009.08.002 computers & security 29 (2010) 331–349  organisations and professional guilds. Although the necessityof collaboration has been recognised, there is little systematicknowledge sharing of clinical intervention outcomes. Withthe advance of modern transportation, communication, andtele-medicine, patients are no longer restricted by physicaland geographical constraints. In the situation of comorbidity(e.g.heartdisease,AIDS,cancer,diabetes,ormentalhealth),itis not a surprise to find that a patient is examined in onehospital; his/her case is reviewed by clinicians from anotherhospital; and he/she is treated in a third hospital by yetanother group of clinicians due to speciality and availability.Data about a particular patient might be held by differentdepartments within one hospital, from different hospitalsand/orevenfromhospitalslocatedindifferentcountries.Datarequests might come from members of a dedicated teamaccessing from their office or home, members of auditing committees, interns for educational purposes, and patientsthemselves all with different access privileges and accesscapabilities. Differences in work idioms in different situationsevidently have the potential to significantly impinge on thequality of services and data security. Apart from the widespreadin geographic regionsand adiverselandscapeof users,the heterogeneity of clinical data is also demonstrated in thedifferent levels of granularity of domain knowledge, differentnomenclatures used in sub clinical domains, different proto-cols followed, different levels of details passed on in the formof medical records, and different standards reinforced byindustrial manufacturers. In such an environment, knowl-edge which is a prime capital can only be based upondistributed and heterogeneous data/information sources andneeds to be processed automatically in streaming mode.Users, therefore, need to locate the correct data providers,retrieve the most appropriate parts of the exposed data andglue together all the bits and pieces of information to makesensible conclusions. In the meantime, one needs to observethe data integrity and obey the data privacy and ethicalregulations enforced by organisational and national clinicalguidelines and protocols.The HealthAgents 1 prototype provides us with an idealplatform to investigate the impacts and implications of experimenting with semantic-rich data and knowledgemanagement technologies in a decentralised/pervasivehealthcare system. In practice, a centralised repository gainscreditforitseffectiveness,security,andmanageability.Thisistrue as long as patients do not go beyond the catchment areaof a hospital. Centralised solutions become less attractivewhen one is injured while visiting another country; when oneneeds daily care while on holiday in a retreat cabin; and whenspecialists are summoned up from different areas in a tele-conference to discuss a rare case. Such a list of counterex-amples could continue whilst they all share the samecharacteristics: decentralisation. As illustrated inFig. 1, ina fully pervasive environment, we observe the relative inde-pendence of each participating agent or intelligent devicewhich fulfils its designated responsibilities, either automati-cally, semi-automatically or under the supervision of humanexperts.We shall lay out the various information fragments thatare produced by these participating agents and build upa clinically appropriate and coherent representation of a patient based on potentially very different views. Wetolerate the diversity and heterogeneity while systematicallychoreographing individual information resources so as tocombinetheirknowledgeofaparticularpatientoraparticulardisease. While interactions among individuals play animportant role in engineering together distributed servicesunderpinning the envisioned healthcare paradigm, securitybecomes a major concern when sharing, transferring, andmodifying patient data/profiles. Prior to the discussion of thedetails of these interaction models and their scientific back-ground,security requirementsofclinicalinformationsystemsare analysed forbuildingup thepropermodelstailoredfortheneed of secure interactions within Healthcare InformationSystem (HIS). 2. Security requirements of healthcareinformation systems We shall, in the beginning, draw distinctions between thetypes of threats imposed on healthcare systems and theirlikelihood. Though eavesdropping or hacking is a majorconcern to computer network security, it is so expensive thatdedicated and capable intruders may consider using a moreconvenientway.Actually,10%ofGPs(generalpractitioners)inthe UK have experienced their computers being physicallystolen (Pitchford and Kay, 1995). More likely, improper use of the system may lead to privacy leaks, by careless (or mali-cious) users and when inappropriate privileges being given tothem by the system. A well-designed system should not onlyprotect the communication sites and end users, but alsocarefullyauthoriseuserswithgenuineneedstohaveaccesstoselective sharing of information without exposing additional Fig. 1 – Pervasive healthcare architecture. 1 http://www.healthagents.cat. computers & security 29 (2010) 331–349 332  information under protection. This particular security needhas currently not been well addressed in healthcare infor-mation systems (Zhang et al., 2002). In this section, we outlinethe challenges and common security requirements of healthcare systems in a distributed environment, wherepreserving privacy and maintaining openness are crucial andinformation access decisions depend upon role and context. 2.1. The distributed environment of healthcareinformation systems Aggregating dispersed data into large databases is expensiveand practically unfeasible, since geographically differenthealthcare centres have to have control over their datasetsand at the same time maintain a globally consistent dataschema. A more important reason to oppose data consolida-tion is concerned with healthcare data confidentiality. In theUK, the National Health Service (NHS), driven by the motivesof easier central administration and better informationavailability, attempted to build a unified electronic patientrecord system and give access to extended NHS community.This has been opposed (Anderson, 1996a,2001) for the reason that such a system, collecting data from existing GP systemsbut out of their control, is in conflict with the ethical principlethat no patient should be identifiable other than to the GPwithout patient consent ( Joint Computer Group of the GMSCand RCGP, 1988) and the result from a survey that mostpatients are unwilling to share their information with NHS(Hawker, 1995). Another objection arises from the over-whelming workload such a centralised system could possiblyput upon a security officer responsible for managing the datasharing (Zhang et al., 2002).A distributed healthcare service infrastructure, however,implies the capability that is required to cope with theadministrative burden and the continuous maintenanceneeds arising from fully functional and networked clinicalcentres, each of whichhas its ownusers, data,access policies,and which assumes that cross-centre access is the norm. Adistributed environment and its associated dynamics bring other concerns, such as patient privacy preserving, to theinformation-sharing healthcare network. 2.2. Preserving privacy and confidentiality in sharedaccess The privacy of patient information is an important issue andfailure to recognise this will lead to risk of patient safety, lossof public confidence in clinical organisations, and so on(Denley and Smith, 1999). A fundamental ethical principlestated by both the EU and the General Medical Council in theUK is that, patients must consent to data sharing. TheBritishMedical Associationadvises that clinical professionals, whohave access to patient confidential information in order toperform their duties, are responsible for the information theyhold under ethical or professional obligations of confidenti-ality and shall not use or disclose such information for anypurpose other than the clinical care of the patient to whom itrelates. This means patients shall be assured that they cantrust the access of their information, by a care team withintheir treating hospitals or experts involved from collaborativecentres, if any, is safe and accords with their agreement. Themoving from a traditional patient–doctor relationshiptowards a modern patient-healthcare service relationshipimplies trust in clinical systems must be maintained ratherthan reliance on doctor responsibilities. The absence of a mechanism or policy framework in the interest of infor-mation governance and confidentiality protection, hence,may damage the healthcare services aimed to be delivered,since private information of any individual patient may bemade available by systems to people not directly related withthe care of that patient. This will give opportunities topotential threats, possibly coming from inside workers, aswell as outside hackers. Such threats include ungracefulprivate information disclosure and abuse or even more risky,incorrect clinical decisions made for vulnerable patients dueto clinical data being wrongly altered, accidentally or delib-erately. It is worth noting that threats from outside intruding into the network are much rarer than from inside. The secu-rity risks tend to increase dramatically, therefore, when aninter-connected clinical system network is in place whichmakes separately stored patient records and clinical infor-mation easily accessible and lets a wider range of people haveaccess to them. Appropriate access control to patient recordsis the fundamental need for patient privacy and informationsecurity (Denley and Smith, 1999). 2.3. Maintaining an open access Two aspects of openness must be maintained: 1) open for joining the system and not preventing any friendly butpreviously unknown clinical centre (bringing in its previouslyunrecognised users) from accessing information availableacross organisational boundaries; 2) open for informationsharing to the network. Conducting healthcare research withmore open use of information (identifiable data, etc.) underlegitimate constraints and user acceptance, though notrelated with the clinical care directly, advances medicalknowledge and promotes higher quality of healthcare servicein the long run and is welcomed by the society. A clinicalsystem can benefit most from clinical data as well as patient-specific data if such information can be machine-analysedand digested. The knowledge accumulated can be useful forlater decision makings, particularly for rare but similar casesencountered in the future,confidential information containedin cases not being revealed. 2.4. The different access needs to data subsets due todistinct job nature The need of distinguishing only the relevant data for sharing among clinical professionals rather than the whole recordsarises from preserving privacy while maintaining openaccess. Even if name, address and other privacy informationis removed to produce a seemingly anonymised record, anNHS clinician can easily identify a patient by the NHSnumber and they must be able to do so to perform their jobs. Therefore, it is sensible to grant access permission toparticular record parts on the basis of users’ expertise. Thisexpertise determines their actual needs of access, to thedata parts they routinely work with and by doing so, computers & security 29 (2010) 331–349 333  healthcare roles are fulfilled. For example, pathologymedical records or reports may be sent to a pathologistinvolved in a patient’s care; prescription sent to a pharma-cist; and sensitive parts not sent out at all. A specialist mayhave more control over their own partitions, e.g. write theirreports or order certain tests, but limited permissions toother specialists’ partitions or even not at all, e.g. to verysensitive medical test results. 2.5. The access policies and principles pertinent to patients as individuals It is not rational to allow a professional to have access to allpatient records, even if limited to the data subset fitting his/her expertise. Only relevant clinicians who have real liferelationships with patients in clinical centres should accesstheir records. This is documented in British Medical Associa-tion’s security policy principles for clinical informationsystems (Anderson, 1996a), and the feasibility of adopting ithas been evidenced inDenley and Smith (1999). Two majorprinciples areas follows. Principle of Access : ‘‘Each identifiable clinical record shall bemarked with an access control list naming the people orgroups of people who may read it and append data to it. Thesystem shall prevent anyone not on the access control listfrom accessing the record in any way.’’ Principle of Control: ‘‘One of the clinicians on the accesscontrol list must be marked as being responsible. Only shemay alter the access control list, and she may only add otherhealthcare professionals to it.’’A named responsible clinician, possibly a patient GP, as inthe UK or a primary care physician (PCP), as in the US, maysetup a workgroup including the specialists who togetherdeliver healthcare to the patient. According to the Principle of Access, it is the members of this group who will be in thepatient access control list, as used by RBAC for files (Sandhuet al., 1996), have access to a subset of data they are respon-sible for, reflecting their job nature. The one who sets up theworkgroup will let the system know the group members andtheirrolesinthegroup,inaccordwiththePrincipleofControl.This implies a data ownership. Such a scheme decentralisesmanagement burden and increases scalability. The distrib-uted environment and open access requirements suggest thata named doctor may involve specialists from other sites(remote consultants, temporary attending physicians, etc.)into healthcare procedures. For example, a medical opinionrequested on a surgical patient may require a medical regis-trar, from other directorates, to exercise override access tothat patient’s notes (Denley and Smith, 1999). This is relatedwith delegation (Zhang et al., 2002). Essentially, a responsibledoctorgrantsaccesstolocalorremoteusersfromtrustedsitesand occasionally, someone acts on their behalf, implying ownership transfer. A triangle relationship is described inCalam: a patient is associated with a workgroup, of whicha user is a member, so that a user is permitted access via theworkgroup to patient (‘‘self-claimed’’ or ‘‘colleague-granted’’/delegation). 3. Enhancing security in distributedhealthcare In fulfilling the requirements discussed in the previoussection, we investigated a process calculus based messaging service that allows us to fragment and distribute clinicalguidelines and protocols and a high-level knowledge repre-sentation paradigm to address knowledge/semantics inter-operability issues. In the following, we first review existing approaches aiming at secure pervasive healthcare environ-ments. We continue with a layered model and a brief discus-sion of its enabling technologies. 3.1. Security domains and existing security solutions Security can be assured in different levels, operating systems,database systems, and applications. Some operating systemswhich take serious concerns of security include: OpenBSD,TrustedBSD, Trusted Solaris, Active Directory (as part of Microsoft Windows), and SELinux. Security-Enhanced Linux,or SELinux, is a Linux feature that provides a variety of secu-rity policies in the Linux kernel. It provides utilities to incor-porate a strong, flexible mandatory access control (FMAC)architecture into the major subsystems of the kernel. In 2006,U.K. Cabinet Office backed SELinux and did experimental useofittoprovidesecuresystemaccessfortheNHS’snewfinancesystem. Database security is the system, processes, andprocedures that protect a database from unintended activity.Authentication, authorisation, auditing, and intrusion detec-tion mechanisms are considered common database securitymeasures. We will focus in this paper, however, the applica-tion level security where information sharing and resourceaccess through the HealthAgents system must be underproper control. Access control at the operating system levelprovides the protectionof ‘‘whose data is to be protected fromwhom’’ and a protection mechanism is the manner by whichthe operating system enforces the access control to its users.Access control at the HealthAgents system level requires theapplication to be designed in such a way that it recognisesvalid users, possibly from one site, and allow them to accessresources, possibly from another site, under system-levelconstraints and mutually agreed policies between both sites,within an inter-connected network. This design provides anadditional assurance on top of what will be secured in theoperatingsystemlevelanddatabasesystemlevel,whichmusthave been offered in the existing and standard environmentbut not under our control.Two earlier access control models are discretionary accesscontrol (DAC) and mandatory access control (MAC). DAC is anaccess policy determined by the owner of an object. MAC is anaccess policy determined by the system, not the owner. Anaccess control list (ACL), a list of permissions attached to anobject, can be used by both models and applied in operating systems such as Windows. A newer access control model thatsupports efficient management is the widely accepted USNational Institute of Standards and Technology model of  role-based access control (RBAC) (Sandhu et al., 1996). All thesemodels can be applied in the operating system level as well asthe application level. Since no operating system can computers & security 29 (2010) 331–349 334  accommodate application-tailored requirements, adaptationof a suitable model for the system under consideration isrequired. In RBAC, permissions that describe operations uponresourcesareassociatedwithroles.Usersareassignedtorolesto gain permissions that allow them to perform particular jobfunctions. Privileges may be calculated as follows (M-TechInformation Technology, Inc., 2006): Privileges ¼ User Role à Role Definition þ Rules Function ð User Attributes Þ In addition to the static collection of rights accumulated byroles, a user can dynamically achieve extra rights if theyexpose certain attributes as defined by rules. This model isefficient when many users require the same set of rights in anorganisation but otherwise unmanageable or even uselesswhenrolesvary in different conditions underwhichusers act.In a hospital, roles can be defined for a number of classifiedgroups to aggregate permissions, e.g. consultant, radiologist,nurse, who have static job functions. However, dynamiccontextsexistinroleplaying,e.g.patientsmaybeadditionallyassignedtoorremovedfromalistforwhichanameddoctorisresponsible and this influences this doctor’s role in caring these patients. RBAC has difficulties to capture such security-relevant contexts as patient, location, and time in healthcareenvironment (Zhang et al., 2002). Patient–doctor relationshipis identified as a critical clinical security constraint to recordaccess, described in Section2.The Community Authorisation Service (CAS) (Pereira et al.,2006) provides a solution to the management of user accesscontrol within Virtual Organisations (VOs) spanning overmultiple sites in the Grid environment. It breaks the traditionof requiring each resource provider to maintain the mapping of individual users (across VOs) to its local database roles inorder to authorise access to its resources. Using CAS, usermembershipsareinsteadbasedonVOrolesandlocalresourceproviders only need to map these to local database roles. Thisdramatically reduces the number of mapping entries acrossresource providers and the duplicated maintenance burdenput on them once a new user joins or a current user privilegechanges. Such an approach requires no global user repository.However, a presumption of using the approach, as it is inRBAC, is that a large number of users can be grouped intoseveral role groups requiring certain access levels in involvedorganisations. For the same reason that RBAC is infeasible toaddress the clinical requirement that information access ortravelling may alter from patient to patient and user led asstated in the Principle of Access, the CAS is encountered withsimilar difficulties. Suppose clinicians A and B with the samespecialityarefromhospitalsPand Qrespectively. Theywillbecategorised into the same VO role and the same access rightsto data in P and Q. But in reality A shall have more privilegesthan B to certain data, e.g. of patients in P under A 0 s care, andvice versa for B 0 s privileges in Q.Managing a resource access model is complex where thereis a large number and various types of users, resource items,and access policies, user responsibilities being dynamic andownership being distributed. The common practice of simplydefining roles that aggregate all permissions required for thecollection of resources to complete tasks is not realistic due tothe diversity of individual needs which literally entails eachindividual having a distinct role. Even the burden of defining and maintaining a proper set of access control policies basedonrolesforautomatingauthorisationcouldbeconsiderable.Asecurity solution must be able to cope with the complexity. 3.2. Overview of a layered security model It has been pointed out that healthcare systems should bedesigned with multilateral security rather than multilevelsecurity (Anderson, 1996b). Unlike some military systemswhich prevent information flow ‘‘down’’ from top secret tosecret then to confidential, healthcare systems usuallyprevent information flow ‘‘across’’ from one clinician toanother or from one hospital to another. This is evidenced bythe requirements outlined in Section2.4and Section2.5 where different access needs to cases and case partitions aredistinguished due to distinct job responsibilities.However, we argue a multilevel security model is moremanageable,taskavailabilitybeinginthetoplevelcontrolandresource availability to tasks in lower level control. A multi-lateral security model resides in the lower level and comple-ments the multilevel security model. The assignment of tasksto users is a business decision to be made by stakeholders,possibly explicitly in rules. It is sensible to regard the acces-sibility to tasks the organisational privileges with whichorganisation seniority is related and access to business func-tions restricted. Since tasks already exist in organisations andare routinely performed by specific user groups, they help tofunctionally decompose the system and ease securitymanagement. If a user can perform a specific type of task,then there must be certain resource items available to him/her to load into the task, if not all. Without the context of accomplishing one or more tasks in different privilege levels,information access makes no sense. The rationale of using a combined multilevel and multilateral model is further sup-portedbythefactthatajobresponsibilityisdeterminedbythelevel of authority and the division of work (Crook et al., 2002).The former prevents information flow downwards and thelatter prevents information flow across, being concernedabout workgroup membership and job speciality under ourfurther refinement. This forms a layered security architecturethat addresses the healthcare security requirements.1) Privilege of performing various types/levels of tasks andexecuting associated interaction models is determined by job title or grade/level. Users may upgrade their job titlesoccasionally and this is managed locally. Semantics of jobtitles and task collections must be globally defined andagreed among organisations.2) Privilege of loading case instances for performing tasks (orenactment of interaction models) is determined by real lifeworkgroup memberships or job boundary. This is managedby the locally named doctors, who shall be flagged asowners in case records’ access control lists.3) Privilege of accessing case record partitions (e.g. patientdata, biopsy data, Microarray data, MRI and MRS data,diagnosis data, therapy data, surgery data, etc.) is deter-mined by job nature or specialist one takes on in hospitals(e.g. oncologist, pathologist, radiologist, surgeon, etc.). This computers & security 29 (2010) 331–349 335
We Need Your Support
Thank you for visiting our website and your interest in our free products and services. We are nonprofit website to share and download documents. To the running of this website, we need your help to support us.

Thanks to everyone for your continued support.

No, Thanks
SAVE OUR EARTH

We need your sign to support Project to invent "SMART AND CONTROLLABLE REFLECTIVE BALLOONS" to cover the Sun and Save Our Earth.

More details...

Sign Now!

We are very appreciated for your Prompt Action!

x