handbook on securing cyber-physical critical ... · of ehr systems, privacy and security concerns...

Das Ch27-9780124158153 2011129 2145 Page 677 1

C H A P T E R

27Security and Privacy for

Mobile Health-Care(m-Health) Systems

Jinyuan Sun Xiaoyan Zhu Chi Zhang Yuguang Fang

271 INTRODUCTION

Fast and secure access to patientsrsquo records helpsto save lives with timely treatment in emer-gency situations Therefore anywhere-anytime-accessible online health-care or medical systemsplay a vital role in daily life Advances in(wireless) communications and computing tech-nologies have lent great forces to migratinghealth-care systems from the paper based tothe EHR (electronic health record) based giv-ing rise to increased efficiency in human opera-tions reduced storage costs and medical errorsimproved data availability and sharing etcUnfortunately such convenience also comes withconcerns which should be carefully addressedFor example medical or health record privacyis a major concern to the patients and becomesthe major barrier in the deployment of theEHR-based health-care systems It is observedthat privacy and security breaches have alreadypenetrated every aspect of our activities and liv-ing environment including health care financialvoting e-commerce military etc Thus there isan urgent need for the development of archi-tectures assuring privacy and security that areimperative to safeguarding confidential informa-tion wherever it digitally resides Despite theparamount importance little progress has been

introduced by researchers in the design of secu-rity and privacy architectures for the EHR-basedhealth-care system In particular two extremelycritical issues are rarely touched in the researchrealm health information privacy and sharing

Health information privacy (or medical recordprivacy) refers to the confidentiality and accessrestrictions of patientsrsquo protected health infor-mation (PHI) which contains sensitive and per-sonal information such as disease history andundergoing treatment There are good reasonsfor keeping the records private and limiting theaccess to only minimum-necessary informationan employer may decide not to hire someone withpsychological issues an insurance company mayrefuse to provide life insurance when aware ofthe disease history of a patient a person with cer-tain types of disease may be discriminated by thehealth-care provider and so on However fun-damental developments of health-care systemshave threatened the confidentiality of medicalrecords and patient privacy [1] one of which isthe exponential increase in the use of computersand automated information systems for healthrecords Computers (connected to a network) arenow commonly used by the health-care providersto store and retrieve patientsrsquo electronic healthrecords (EHRs)

Handbook on Securing Cyber-Physical Critical Infrastructure DOI 101016B978-0-12-415815-300027-3 677ccopy 2012 Elsevier Inc All rights reserved

Das Ch27-9780124158153 2011129 2145 Page 678 2

678 CHAPTER 27 Security and Privacy for Mobile Health-Care (m-Health) Systems

EHR systems are used in lieu of paper sys-tems to increase physician efficiency to reducecosts (eg storage) and medical errors to improvedata availability and sharing etc An exemplarysuccessful implementation of the EHR system inthe United States is the Veterans Administrationhealth-care system with over 155 hospitals and800 clinics It is one of the largest integratedhealth-care information systems worldwide andhas been using a single EHR system for yearsDespite all the promising factors EHR systemsare not adopted by the majority of health-caresystems Statistical results of the actual adop-tion rate of EHR in US medical systems canbe found in Ref [2] and the references thereinAmong all the barriers to the implementationof EHR systems privacy and security concernson patientsrsquo medical records are arguably mostdominating This was reflected in a nationwidesurvey conducted in February 2005 by HarrisInteractive of Rochester NY in which 70 of thepopulation were concerned that personal medicalinformation would be leaked because of weakdata security [3] This sentiment has undoubtedlybeen exacerbated by illegal disclosures includ-ing Christus St Joseph Hospital Houston Texas(16000 records were compromised by theft)University of Chicago Hospital (employees werefound selling patient data) and Wilcox MemorialHospital Kauai Hawaii (130000 records werecompromised by theft) [4] Records stored in acentral server and exchanged over the Internetare subject to theft and security breaches TheHealth Insurance Portability and AccountabilityAct (HIPAA) in the United States was estab-lished to regulate EHR-related operations Privacyissues are particularly not addressed adequately atthe technical level [4] Therefore in addition togovernmental regulations standardization and anoverall strategy are needed to ensure that privacyprotection would be built into computer networkslinking insurers doctors hospitals and otherhealth-care providers [5] The implementation ofthe standardization or strategy will undoubtedlybe relying on technical details which are rarelystudied in the research community leaving usnumerous research opportunities

Health information sharing takes place asdaily routine where the primary caregiver (egfamily doctor) frequently refers patients to spe-cialists who are unavailable at the primary care-giverrsquos organization The sharing also occurs asa result of cross-organizational (or simply cross-domain) collaborative research for studying dis-eases and improving clinical care or collaborativeremote surgical operations Central issues aroundthe sharing of health information include authen-tication of an entity delegation of accessrights and permissions access control to patientrecords and revocation of access rights and per-missions with respect to an outside collaboratorIn its original form delegation of rights is usedto appoint a proxy signer who signs on behalfof the delegator in case heshe is absent In ourEHR system delegation of rights can be usedto allow the delegateersquos access to shared healthrecords More challenging yet such access shouldalso be restricted to only the portion(s) of dataintended for sharing since illegal disclosure ofhighly confidential data such as a patientrsquos healthrecords can be devastating and is against theHIPAA regulations Moreover revocation mustbe dynamic in that the delegator should be ableto revoke delegated rights at any time due tounforeseeable situations Data sharing in a dis-tributed fashion eg shifting the delegatorrsquos taskto each delegatee and thereby making the delega-tion process transparent to the delegator allow-ing each cooperating health-care provider to pro-cess data locally for either treatment or researchdelivers tremendous benefits including higher effi-ciency better scalability and lower complexityat the user end due to reduced human interven-tion etc Designing a secure EHR system thatoffers information sharing capability and guar-antees health record privacy is equivalent to glu-ing all the aforementioned challenges togetherand providing a feasible solution which is by nomeans a trivial task and will be the focus of thischapter

The majority of works on privacy protec-tion in health-care systems still concentrate onthe framework design or solution proposals withlittle or no technical realization [4 6ndash12] These

Das Ch27-9780124158153 2011129 2145 Page 679 3

CHAPTER 27 Security and Privacy for Mobile Health-Care (m-Health) Systems 679

works include the demonstration of the signifi-cance of privacy for EHR systems the authenti-cation based on existing wireless infrastructurethe role-based approach for access restrictionsetc As the need for technical details specificallythe cryptographic realization of privacy and secu-rity in health-care systems becomes clearer andmore stringent a few recent works followed thisline of research Lee and Lee [13] proposed acryptographic key management solution for pri-vacy and security regulations regarding patientsrsquoPHI Although technically correct the proposedscheme is unreasonable because the trusted serveris able to access the patientsrsquo PHI at any timeAs a result PHI privacy is not fully guaran-teed which is unacceptable for extremely sen-sitive information like PHI Furthermore theauthors did not address the issues related tostoring and retrieving PHI which can be intri-cate given the privacy requirements The workof Tan et al [14] is a technical realization ofthe role-based approach proposed in Ref [7]In spite of specifying the algorithms for storingand retrieving health-care records the scheme infact failed to achieve privacy protection in thatthe storage site will learn the ownership of theencrypted records (ie which records are fromwhich patient) in order to return the desiredrecords to a querying doctor Such leakage willcompromise patientsrsquo privacy by violating theunlinkability requirement

A survey on delegation for information shar-ing in distributed health-care context is givenin Ref [15] with no specific technical designto cope with the major issues identified inthis context namely least-privilege delegationrevocation onward delegation and dynami-cally changing credentials Current approachesto delegation in distributed health-care contextare identified and categorized as proxy certifi-cates [16ndash19] call-backs [20] XML [21ndash24]and role-based delegation [10ndash12] Among theseapproaches proxy certificates and role-based del-egation coincide in ideas with some part(s) ofour proposed solution However proxy certifi-cates bear some key drawbacks ie static accesscontrol and revocation that render this approach

not readily applicable Role-based delegation isfree of these drawbacks but has problem in ensur-ing least-privilege assignment due to the lackof fine-grained access control Implementing theproposed information sharing procedure usingstandard XML language and framework is paral-lel to our work and can be considered for futurework (eg XML framework can be used as astandard means to specify the instantiation of thesignatures used in the technical descriptions ofour system Finally there are a few projects onsystem or architectural design in the health-carefield including cryptographic and system aspectsof medical information privacy assurance [25]self-scaling and distributed health informationarchitecture [26] and secure grid-enabled healthcare [27] which focus on vastly different aspectsof health-care system and are largely parallel toour work

In this chapter we present our design of asecurity architecture HIPS for EHR systemsbased on cryptographic tools First the pro-posed system should offer both full privacy forpatients without escrow (eg the trusted serverin Ref [13]) and the capability of handling emer-gency situations which are intrinsically relatedand somehow contradictory Full privacy meanseven when the patient is incapable of authorizingaccess to hisher PHI during emergency no oneshould be able to obtain the secrets for retriev-ing and decrypting the PHI On the other handthere must be a way to retrieve and decrypt thePHI (as if the patient is conscious to do so) forlife-saving purposes in emergencies In additionthe storage and retrieval of PHI in a secure andprivate manner underlie the health-care systemand must be carefully coped with Second infor-mation sharing capabilities should be providedby leveraging authentication delegation accesscontrol and revocation Authentication is a fun-damental requirement prior to privacy guaran-tee and health information sharing to assure theauthenticity of a communicating identity Dele-gation leverages proxy signature and role-basedapproach to distribute the task among delegatees(more specifically delegation servers of delega-teesrsquo organizations) and ensure transparency for

Das Ch27-9780124158153 2011129 2145 Page 680 4


the delegator Access control is an enhancementto delegation for further and accurately restrict-ing the data portions accessible to the delegateeThe revocation mechanism describes a dynamicapproach to tackle unexpected or urgent revoca-tion issues The ultimate goal of the architecturedescribed in this chapter is to simulate imple-ment and test HIPS to obtain the first functionalsecure and private EHR-based health-care sys-tem with the following design objectives

1 Establishing trust leveraging hierarchicalidentity (ID)-based cryptography (HIBC) forauthentication and key management

2 Protecting patient privacy featuring patient-controlled health information for bet-terprivacy and compliance with HIPAAregulations

3 Controlling access to patientsrsquo health recordsbearing different design requirements for theaccess to different portions of patientsrsquo healthdata with those containing identificationinformation subject to finer control

4 Sharing information for health care andresearch exploiting proxy signature and role-based delegation for secure cross-domaincollaborations

5 Revoking delegated rights providing viablemeans for terminating ongoing collaborationsonce violation of rules is detected

6 Resolving conflicts of security and functionalrequirements enabling life-saving treatmentduring emergency while not compromisingthe privacy of patientsrsquo health data

In a nutshell the proposed security archi-tecture for m-health has significance in manyaspects Securing cyberspace is one of the top pri-orities in protecting our national infrastructureincluding the health-care systems Protecting citi-zensrsquo privacy is critical to the deployment of suchapplication systems where highly sensitive andconfidential information is involved EHR sys-tems have been envisioned to be the most viablesolutions to deliver efficient health care simpli-fied management and seamless information shar-ing and will be the next big business push Thecurrent EHR systems have not addressed well on

privacy and information sharing and the pro-posed solution may lay the foundation for onlinefast access to patientsrsquo record in emergency situa-tions or collaborative diagnosis hence can poten-tially save peoplersquos lives with proper and timelytreatment

272 ELECTRONIC HEALTHRECORD (EHR)

Electronic health record refers to a patientrsquosmedical record created stored transferred andaccessed digitally as opposed to the traditionalpaper-based health record EHR is the centralpiece of information in realizing electronic healthcare and may record medical data such as radi-ology images (CAT MRI and X-ray) laboratorytest results medication allergy disease historybilling information as well as some processed oraggregated medical data (ECG emergencies crit-ical health conditions etc) monitored by wirelessbody sensor networks

EHR systems are used in lieu of paper sys-tems to increase physician efficiency reduce costs(eg storage) and medical errors to improvedata availability and sharing etc An exem-plary successful implementation of EHR systemin the United States is the Veterans Administra-tion health-care system with over 155 hospitalsand 800 clinics It is one of the largest inte-grated health-care information systems world-wide and has been using a single EHR systemfor years [28] Despite all the promising factorsEHR systems are not adopted by the majorityof health-care systems Statistical results [29 30]show very low actual adoption rate of EHR inthe US medical systems

Among all the barriers to the implementa-tion of EHR systems privacy and security con-cerns on patientsrsquo medical records are arguablymost dominating [28 31] EHR will inevitably bestored in remote servers (eg monitoring centerand primary health-care provider) and exchangedover the Internet for cooperative treatment emer-gency response clinical research etc and thusare subject to theft and security breaches TheHealth Insurance Portability and Accountability

Das Ch27-9780124158153 2011129 2145 Page 681 5


Act (HIPAA) in the United States was establishedto regulate EHR-related operations Privacyissues are particularly not addressed adequatelyat the technical level Therefore in addition togovernmental regulations standardization andan overall strategy are needed to ensure thatprivacy protections would be built into com-puter networks linking insurers doctors hos-pitals and other health-care providers [5] Theimplementation of the standardization or strat-egy will undoubtedly be relying on technicaldetails which are rarely studied in the researchrealm leaving numerous research opportunities

As the need for technical details ie thecryptographic realization of secure EHR systemsbecomes more clear and urgent a few recentworks followed this line of research includ-ing cryptographic key management schemesrole-based access control schemes anonymousauthentication schemes etc These works mostlyfocus on a single problem or aspect of the systemand thus would fail when taking other aspectsand objectives into consideration Technical solu-tions for the assurance of privacy and system-wise security in e-health care are yet to come

273 PRIVACY AND SECURITY INE-HEALTH CARE

We provide a non-exhaustive list of privacyand security issues that concern patients andwill serve as requirementsobjectives in futuree-health-care system design We also discussthe suitable cryptographic techniques for solvingthese issues

2731 Privacy

Privacy is of paramount importance in e-healthcare because the illegal disclosure and improperuse of EHR can cause legal disputes and damag-ing consequences to peoplersquos lives For examplean employer may decide not to hire people withpsychological issues an insurance company mayrefuse to provide life insurance knowing the dis-ease history of a patient people with certain types

of disease may be discriminated by the health-care provider health conditions of the elderlycould be revealed to their families disobeyingtheir willingness and so forth [28 31]

Privacy in e-health-care environment com-prises anonymity and unlinkability requirements[28] Anonymity is required when the identifyinginformation in the EHR need be hidden from cer-tain parties ie the EHR cannot be associatedwith a particular patient These parties includeinsurance providers researchers some manage-ment staff and any related personnel who has noappropriate access privileges On the other handprimary health-care providers including physi-cians and nurses delegated health-care providersand emergency medical technicians (EMTs) [32]should be able to view such information in orderto carry out proper treatment In addition theidentity of a patient can be deduced from thereceived medical data if the patientrsquos device (eghome PC PDA) transmitting the data can beidentified

Unlinkability indicates that multiple EHRscannot be linked to a same owner This require-ment is necessary because it prevents the pro-filing of a patient by insurance companies orcentral servers that store patient data [28] Theinsurance companies may benefit from learningmore information than that is allowed by thepatient through exploiting the linkage amongEHRs The monitor centers either independentor within a hospital offer services and storage topatients under home or critical care The mon-itored data can then be retrieved by the pri-mary physician for health evaluation or by theemergency medical technicians for ambulatorytreatment The unlinkability requirement appliesto the storage servers (ie the administrators)of the monitor center under the curious-but-honest assumption meaning that the servers willattempt to learn the privacy of the patient butwill not launch attacks on the stored EHRs (egdeletion modification bogus injection and irre-sponsive to retrieval requests) It is apparentthat anonymity is a prerequisite for unlinkabilitybecause identifying information renders EHRslinkable

Das Ch27-9780124158153 2011129 2145 Page 682 6


One can use data anonymization techniquesto remove identifying information and achievethe anonymity of EHRs [28] The anonymiza-tion can be performed by the patient or the pri-mary physician to allow sharing of EHRs withinsurance companies researchers cooperativehealth-care providers etc without compromis-ing privacy Since data anonymization techniquesfail to ensure anonymity when the device trans-mitting data is identified the aforementionedanonymous communication substrate for loca-tion privacy will also be needed here Further-more most commonly the device will be requiredto authenticate with the storage servers of themonitor center before transmitting health dataand to prevent users who are not subscribed tothe monitor services from abusing the serversSince authentication relies on public key infras-tructure (PKI) the public key of the device mustbe anonymous which can be realized by adopt-ing anonymous credential systems At this pointit is clear that the anonymity requirement is mul-tifaceted the negligence of which will cause fail-ures in the anonymity guarantee Anonymizationtechniques can be leveraged to achieve unlinka-bility because the removal of common identi-fiers in the EHRs results in ambiguity Encryptioncan also be used which encrypts EHRs and pro-duces ciphertexts that appear random and thusunlinkable More discussions on suitable encryp-tion schemes for e-health-care can be found in theconfidentiality requirement below

2732 Access Control

Access control is in charge of who can access thepatientrsquos EHRs and which part(s) of the data canbe accessed to ensure that only authorized par-ties can gain access to authorized data [28] Thisrequirement is in accordance with the HIPAAregulation that patient authorizations will berequired to use and disclose information for pur-poses other than treatment and payment [1]Basically the identifying information (or pro-tected health information PHI) is necessary fortreatment and payment where authorization canbe exempted In all other cases patients have

the right to permit the use and disclosure oftheir EHRs and hence the access control shouldbe patient-centric Access control is an intrinsicissue due to the various types of personnel med-ical or non-medical involved in the interactionsbetween patients and the health-care systems

Role-based access control is the de facto mech-anism to deal with authorizations in health-care systems where the roles (eg physiciannurse emergency medical technician insuranceprovider pharmacist and cashier) and their asso-ciated access rights can be defined and speci-fied It greatly simplifies the control task in thataccess is determined and granted for each groupof people but not individually [28] Translatingto cryptographic details the public key used forauthentication and secure communications willbe constructed from the descriptive string of arole as opposed to that of an identity Fairlyoften patients need to be referred to specialistsfor the examination and treatment of certainhealth conditions upon the primary physicianrsquosdiscretion The specialists will therefore havetemporary access to the entire or partial EHRduring the course of treatment Temporary accessimplies the need for potentially frequent assign-mentrevocation of the roles which can be ful-filled by means of delegation Delegation refers tothe primary physician delegating access right toanother physician and specifying the associatedvalidity period Delegation can also be role basedwhere the primary physician delegates hisherrole to another physician and revokes the roleupon the termination of treatment Dependingon the policies and applications onward dele-gation may be allowed in which the delegatedphysician can further delegate another physicianThe depth of the delegation chain will normallybe defined by the primary physician In addi-tion delegation can be realized through proxysignaturecertificate and XML-based approaches

The role-based approach solves the problemof who has access to the EHR However it alonecannot provide granularity in EHR access (iewhat portion(s) of the EHR a particular rolehas access to) which requires additional mech-anisms such as anonymization and encryption

Das Ch27-9780124158153 2011129 2145 Page 683 7


Anonymization is indispensable for data min-ing performed by parties such as researchers andinsurance providers who possess access rightsonly to the de-identifying or sensitive informa-tion of EHRs The anonymization may be car-ried out by the patient as the EHR owner orby the primary physician who can act on thepatientrsquos behalf Encryption is another optionand is more precise in restricting the access Thepatient and primary physician can simply encryptthe EHR portion(s) to be accessed by a role lever-aging role-based encryption (ie the public keyused for encryption indicates a role) This mani-fests another merit of role-based technique beingthat the encryption can be performed in advancewithout knowing the identity of the potentialrecipient

2733 Authentication

Authentication is a prerequisite for secure oper-ations or tasks since the communicating partiesneed to ascertain the legitimacy and authenticityof each other [28] Hence authentication proce-dure should be executed as the first step of almostall communications in e-health-care systems Forinstance authentication takes place as patientstransfer data to the monitor center or requesttest results from the primary physician primaryphysician retrieves the data for health evaluationor delegates other physicians researchers requestEHRs for statistical studies and so on

Authentication in the e-health-care contextrelies on public key infrastructure (PKI) wherea cryptographic publicprivate key pair is imper-ative Assigning key pairs for authentication ine-health-care systems is challenging in that mostof the aforementioned communications occur inan inter-domain fashion The domain is definedsuch that a trusted authority can be easily estab-lished to assign key pairs for every entity in thedomain facilitating intra-domain authenticationIn general a hospital clinic insurance companyresearch organization monitor center or ambu-latory treatment center can be considered as adomain where a server may be designated toassign key pairs for the employees with common

affiliation Moreover patients having business orresearch relationships with a domain will possessa key pair for that domain In the inter-domainauthentication scenario communications involvetwo independent domains the key pairs of whichcannot mutually authenticate As a result a com-mon certificate authority (CA) need be found incertificate-based PKI or the hierarchical identity-based cryptosystem (HIDC) need be adopted inidentity-based PKI Nevertheless the certificate-based PKI is inappropriate in the e-health-carecontext because it renders the role-based tech-niques introduced in the previous section infea-sible We will later demonstrate the possibility offinding common trust for inter-domain authenti-cation in e-healthcare leveraging HIDC

2734 Confidentiality and Integrity

Confidentiality and integrity are with respect toEHRs In particular confidentiality requires thatthe entire or partial EHR depending on theapplication and patientrsquos requirement is viewableonly to parties with proper authorizations (iedecryption keys) and is achieved by encryptionprimitives [28] Encryption was mentioned as oneof the techniques (another being anonymization)to be used with role-based approaches for fine-grained access control It is clear that the majordifference between encryption and anonymiza-tion lies in the assurance of confidentiality asthe remaining information in the EHRs afteranonymization is still viewable Confidentialityis indispensable when it is undesirable to revealsensitive information in the EHRs even whenthis information is not identifying For examplepatients with certain types of disease may feelembarrassing to disclose related information forany use other than necessary treatment

Symmetric or public key encryption can beused where the former requires a shared secretkey between the encrypting and decrypting partyand the latter can use the publicprivate key pairsassigned for authentication Apparently publickey encryption is the suitable solution in e-health-care context to provide basis for role-based tech-niques The basic encryption schemes are most

Das Ch27-9780124158153 2011129 2145 Page 684 8


useful for real-time communications Frequentlyin e-health-care applications the encryption ofmedical data will take place before the actualdecryption and review eg the EHRs are storedby the primary health-care provider for futurereference the monitored health data (raw orprocessed) are outsourced to central servers forlater evaluation by the primary physician Fur-thermore the retrieval of medical data shouldbe highly specific and efficient in that only theset of EHRs relevant to the retrieval (out of apotentially large pool of EHRs) need be returnedConsidering this feature of medical data retrievalspecial public key encryption schemes designedfor efficient retrieval purposes should be adoptedinstead of the basic schemes Public key encryp-tion with keyword search (PEKS) or simplysearchable public-key encryption is a desirablecandidate which supports the functionality ofrole-based (basic) public key encryption whilefacilitating efficient search for data of interest

Integrity of EHRs needs to be ensured sothat illegal alteration of the original EHRs canbe detected by future reviewers It is critical tosatisfy the integrity requirement in e-health-caresystems since illegal modification of the EHRs(either maliciously or erroneously) may result inlife-threatening consequences [28] Traditionallyintegrity is guaranteed by public keyndashbased dig-ital signature or symmetric keyndashbased messageauthentication code The former is expected to bethe dominant technique for e-health-care appli-cations and the latter is useful when the patientshares a secret with hisher family for EHRaccess Another popular approach for integrityguarantee is the watermarking technique appliedin medical information security to assure theintegrity and authenticity of the medical data(eg images texts videos audio etc) in whichthe watermark is embedded The challenge in thewatermarking technique is to achieve the secu-rity objectives and meanwhile to yield minimalimpact on the quality of the original data fordiagnosis Watermarking can be used to integrityassurance so long as the distortion is acceptablefor the purpose of the application Otherwisethe cryptographic approaches mentioned above

should be leveraged to avoid medical incidentscaused by inaccurate diagnosis or misdiagnosis

2735 Others

Other security requirements including availabil-ity and accountability need also be satisfied [28]The most common attack on availability isDenial of Service (DoS) or Distributed Denialof Service (DDoS) in distributed systems Theattacker may flood the servers storing EHRs withcontinuous bogus authentication requests (recallthat authentication is need for all secure commu-nications in e-health care) to cause irresponsive-ness at the server hindering critical data retrievalIn the wireless transmissions of medical datafrom the PDA to the monitor center the attackercan launch jamming attack rendering the wire-less channel saturated and unavailable and thuscause delay in the delivery of critical data DoSand jamming attacks are very difficult to thwartThe best solution so far is to alleviate the impactof such attacks and is application specific takinginto account the features of the application andits objectives

Accountability also referred to as non-repudiation or traceability provides the pos-sibility to trace and identify the party thatmisbehaves The definition of misbehavior isapplication specific and consists of a wide rangeof actions violating the regulation policy orsecurity requirements Misbehavior can includeillegal disclosure of EHRs abuse of access rightsfor illegitimate purposes unauthorized modifica-tion to EHRs collusion of insiders (eg physi-cians and insurance companies) for monetarygains etc To enable accountability and discour-age misbehavior audit trail and cryptography(ie digital signature) should be used in combi-nation Audit trail is available in many systems asthe data logger to record transactions and eventsoccurred for statistics quality of service or secu-rity purposes In e-health-care systems audit trailfunctionality should be provided whenever digi-tal signature is not required to trace the sourcethat breaks the rules and possibly also causesdamages

Das Ch27-9780124158153 2011129 2145 Page 685 9


274 STATE OF THE ART DESIGNFOR HEALTH INFORMATIONPRIVACY AND SHARING(HIPS)

2741 Entities and Definitions

The following entities are involved in the HIPSsystem Patient is the user of HIPS and is referredto as the combination of a person and hishercomputing facilities (personal desktop or anywireless-enabled portable devices [6 33ndash35])Physician including Delegator and Delegateedenotes health-care professionals such as doctorsnurses pharmacists and any other individualslicensed to provide health-care services Similarto patient physician refers to a person and hishercomputing facilities In the information sharingprocedure we will refer to the physician whoshares hisher patientsrsquo information as the dele-gator and the physician with whom the infor-mation is shared as the delegatee Other thanthe information sharing procedure we simplyuse physician to denote the primary caregiver(corresponding to the delegator in informationsharing) Family represents any person(s) of thepatientrsquos trust including parents children spouserelatives or close friends who will possess thesecrets for retrieving the patientrsquos PHI in emer-gencies and are assumed unlikely to compromisethe patientrsquos privacy in any case P-device (privatedevice) refers to electronic devices the patientowns such as smartphone PDA and some wear-able devices like the cloaker [8] P-device issubject to loss and theft and the subsequent com-promises It must be pervasive for patients withhigh risks to encounter emergencies

S-server (storage server) is provided by eachhospitalclinic to store the patientrsquos PHI whichis subject to compromise and is generally nottrusted by patients The S-server can be assumedhonest-but-curious meaning that it will not mali-ciously delete patientsrsquo PHI for gaining noth-ing D-server (delegation server) equipped withdecision making functionalities and possessingaccess to the privacy and security policies ofthe delegateersquos organization plays the role ofproxy signer (or mediator) in information sharing

and is in charge of properly assigning delegateeson the delegatorrsquos behalf A-server (authentica-tion server) is a trusted server run by the gov-ernment (eg NHIN and HHS) and placed inlocal offices responsible for authenticating physi-cians to determine their eligibility for accessing aparticular patientrsquos PHI in emergencies P-devicewill then be informed by the A-server regard-ing whether the authenticating physician has theaccess right to operate P-device

In addition to the entities two importanttypes of information need to be defined PHIthe protected health information denotes indi-vidually identifiable health information in anyform (ie electronic paper or oral) contain-ing both sensitive and non-sensitive informa-tion It also refers to information with respectto which there is a reasonable basis to believethe information can be used to identify the indi-vidual [36] We are interested in the electronicPHI in our EHR system HIPS We use PHIto represent patient-controlled health informa-tion that is mainly for common or emergencytreatment SHI the shared health informationrefers to the patientsrsquo health information sharedbetween organizations in collaboration wherepatients themselves are not involved SHI in thecase of refereed treatment is identical in contentto PHI However in the case of collaborativeclinical research sensitive information is usuallyremoved through de-anonymization and SHI isdifferent from PHI

2742 Security Requirements

It is crucial to design HIPS against a set of prede-fined security requirements indicating the mainfunctional objectives HIPS should satisfy as asecure system Provided the application scenariowith stringent privacy demands in our securesystem HIPS we will define and address the fol-lowing security requirements [31 37]

1 Privacy HIPS achieves privacy if patientsrsquo PHIcan only be accessed by authorized physiciansfor legitimate reasons (ie treatment pay-ment health-care operations [1]) and no one

Das Ch27-9780124158153 2011129 2145 Page 686 10


except the family and P-device can link thestored PHI files to a particular patient

2 Fail-Open We say that HIPS system is fail-open if the system provides backup mecha-nisms to successfully retrieve patientsrsquo PHI incase of emergency while preserving the aboveprivacy requirement

3 Access Control (Authorization) HIPS realizesaccess control if no physicians other than theauthorized can gain access to the patientrsquosPHI or the SHI

4 Accountability HIPS meets the accountabil-ity goal if the physician who discloses thepatientrsquos PHI and the SHI other than legiti-mate reasons is traceable and held responsiblein case of emergency and information sharingrespectively We implicitly assume that whenthe patient is physically competent to retrievethe PHI (ie not in emergency) heshe willknow the source of the PHI leakage by recall-ing which physician(s) recently treated him

5 Minimum-Privilege Delegation Our systemachieves minimum-privilege delegation if thedelegator is able to specify which data por-tions of SHI can be accessed by the delegateeeven if these data portions belong to a samedocument as those that cannot be accessed bythe delegatee

6 Adaptability Our system meets the adapt-ability goal if the change of status or avail-ability of a delegatee does not require theintervention of the delegator to restartthe information sharing procedure nor causethe interruption of the procedure in any wayIn other words the changes should be trans-parent to the delegator

7 Dynamic Revocation We say that our sys-tem guarantees dynamic revocation if the sys-tem provides mechanism for the delegator torevoke delegated rights at any time

8 Availability The availability requirementstates that the authorized physician must beable to obtain PHI and SHI stored anywherein the health-care architecture

9 Authenticity Authenticity indicates that anyentities involved in HIPS communicationsmust be able to successfully authenticate or

verify the identity of each other even if suchauthentication is cross-domain

10 Confidentiality Confidentiality requires thatthe contents of PHI and SHI are not learnedby any passive eavesdroppers or active attack-ers which fundamentally guarantees patientprivacy specified in the privacy requirementFurthermore message exchanges involvingsecret information are subject to confidential-ity requirement as well

11 Data Integrity HIPS guarantees that thestored PHI or SHI is not modified except byauthorized physicians upon patientsrsquo consentor requests Additionally protocol messagesexchanged between communicating partiesare not to be modified by any maliciousparties

2743 System Architecture

Consider the application scenario in our HIPSsystem shown in Figure 27-1 where all links arebidirectional and the bracketed numbers indicatemajor events or exchanged messages In generalthe physician has only physical contacts with allentities in a patient local area network (LAN)denoted by a double solid line from the physi-cian Dr White in Figure 27-1 to a patient LANSpecifically the physician orally communicateswith the patient and family in common-casetreatment and emergencies respectively Contactswith P-device on the other hand is through thephysician physically operating P-device in emer-gencies only

Similarly S-server interacts with all entities inthe patient LAN mainly via wireless links for PHIstorage and retrieval Note that PHI storage iscarried out only between S-server and the patientusing the patientrsquos home PC PHI retrieval can beperformed by the family and P-device in emergen-cies and by the patient in common-case treatmentusing cell phone

The internal links of the hospitalclinic net-work and the patient LAN are often high-speedwired links The patient interacts with the familyand P-device to assign privilege (ie secret keys)

Das Ch27-9780124158153 2011129 2145 Page 687 11


(1)

(1) Authentication based on HIBC

(7) Cross domain authentication and proxy appointmente(8) Delegationdelegatee assignment(9) PEKS encryption and storage

(10) Cross-domain authentication and PEKS-encrypted data retrieval

(11) amp (12) Potential PEKS data outsourcing

Policy server

Dr White

Storage server

Dr Black

Local area network of Hospital B

Storage server

(1)

(8)

(10)

(9)

(7)

(11)

Policy server

Cloud

Public storage server

VHA

Internet

A-server at local office

Patient localarea network

wireless link

wired link

physical contact

(2)

(3)

(4)

(5) (6)

(2) Emergency authentication(3) Access control information(4) Privilege assignment(5) PHI requestresponse

P-device

Patient

(12)

(6) PHI storageretrieval

Local area network ofClinic A

FIGURE 27-1 System architecture of HIPS

that will be used for retrieving the patientrsquos PHIin emergencies

The Veterans Health Administration (VHA)serves as the parent of Clinic A and Hospital B inthe hierarchy shown in Figure 27-2 for authen-tication and key management The delegator DrWhite and S-server will be engaged in SHI stor-age A public S-server is also depicted in Fig-ure 27-1 to show the potential outsourcing ofthe encrypted SHI enabling distributed healthinformation storageretrieval The PEKS (search-able public key encryption) primitive [38ndash40]

used for encrypting SHI ensures that the contentof the stored data will not be recovered by theS-server (or any other third-party entities exceptthe intended delegatee Dr Black) regardless ofthe location of the server in the health-care hier-archy Note that although we use the S-serverlocated within Clinic A for demonstration anyother S-server drawn in Figure 27-1 can be usedinstead Revocation takes place in Event (10) inbetween cross-domain authentication and PEKS-encrypted SHI retrieval which is not shown inthe figure Also not included in the figure is the

Das Ch27-9780124158153 2011129 2145 Page 688 12


NHIN

VHA RHIO1RHION

VA hospitalsVA clinics Region-1 non-VAhospitalsclinics

Region-N non-VAhospitalsclinics

Level 0

Level 2

Level 1

DrWhite

Clinic

A

PS (proxysigner

delegationserver)

Dr Black

HospitalB

SS(storageserver)

Level 3

FIGURE 27-2 Logic diagram of HIPS system hierarchy

consultation to the D-server in Event (10) Intu-itively the S-server should mainly be responsiblefor storage with authentication and revocationcapabilities left up to the D-server These designdetails can be easily handled and will be the pol-icy specification issue in the implementation ofHIPS as a part of our proposed research

All entities in Figure 27-1 need to individu-ally maintain audit trails for recording interac-tion histories (eg authentication proxy signingPHISHI storage retrieval revocation etc) withother entities Audit trails serving as proofs willbe critical for audit once disputes arise regard-ing serious issues such as abuse of permissionsillegal attempts of access improper disclosureof patientsrsquo health information etc and will bethe key technique in satisfying the accountabilityrequirement

2744 Establishing TrustAuthentication and KeyManagement

Establishing trust is fundamental to properlyensuring other security procedures and mecha-nisms since it essentially sets up a secure back-bone for all future authentication confidentialand integrity-protected message exchange andkey management This procedure thereby ensures

the security requirements of authenticity confi-dentiality data integrity and availability

United States has one of the largest integratedhealth-care delivery systems based on an EHRinformation system VistA which is administeredby Veterans Health Administration (VHA) thehealth-caremedical organization of US Depart-ment of Veterans Affairs (VA) Consequentlyfederal department VA can act as the commonancestor of all VA health-care providers (eg VAhospitals VA clinics etc) forming a hierarchyfor enabling cross-domain authentication amongthese providers

Outside the VA system however there waslack of adoption of EHR systems or incompati-bility of EHR software between vendors [2] Asa result the Office of the National Coordina-tor was established within the US Departmentof Health and Human Services (HHS) strivingto build Nationwide Health Information Net-work (NHIN) Within NHIN Regional HealthInformation Organizations (RHIOs) have beenestablished in many States in order to promotethe sharing of health information [2] It pro-vides a platform for cross-domain authentica-tion among the non-VA health-care providersas well as between VA and non-VA providersby incorporating VA providers as participants ofNHIN [41]

Das Ch27-9780124158153 2011129 2145 Page 689 13


The above example indicates the possibili-ties of finding common trust for informationsharing in the health-care system supportingthe proposed solution that leverages HIBC forcross-domain authentication In addition Limand Paterson [42] showed the feasibility of imple-menting HIBC in practice and the performancesuperiority of HIBC over certificate-based cryp-tosystem (ie RSA) in terms of communicationcosts Another advantage of HIBC is the capa-bility of directly authenticating a public key Ifthe certificate-based hierarchical cryptosystem isdeployed the verification of a certificate usuallyinvolves verifying all certificates along the certifi-cation path until a trusted certification authorityis reached [31]

We apply the domain initialization of HIBC[43] According to the above discussion we letNHIN locate at level 0 of the hierarchy VHA andRHIOs and their affiliated health-care providersare located at level 1 and level 2 respectivelyas shown in Figure 27-2 NHIN being the rootPKG (public key generator) performs the follow-ing domain initialization algorithm when HIPS isbootstrapped where P0 is a generator of G1 [37]

1 Input security parameter ξ isin Z+ into domainparameter generator PG and output theparameter tuple (qG1G2eP0H1)

2 Randomly select a domain master secret S0 isin

Z lowastq and calculate the domain public key Ppub =

S0P0

NHIN publishes the domain parameters (pG1

G2eP0H1Ppub ) and maintains S0 confidentialThe setup for an entity CHj at level j j isin 12in our scenario is performed by CHj rsquos immediateancestor (or parent) at level j minus 1 as

1 Compute PKTj = H1(ID1 IDj )2 Compute CHj rsquos private keys ψ j = ψ jminus1+

Sjminus1PKTj =sumj

i=1 Siminus1PKTi 3 Distribute QT = Ql 1le l lt j to CHj where

Ql = Sl P0

In the above private key assignment IDTi =

(ID1 IDi ) for 1le i le j is the ID tuple of CHj rsquosancestor at level i and PKTi is the corresponding

public key tuple The private key ψ j is generatedfor cross-domain authentication where Sjminus1 isthe parentrsquos secret information Due to the hard-ness of discrete logarithm problem (DLP) itis intractable to solve for Sjminus1 given any pri-vate key calculated from it with non-negligibleprobability

2745 Protecting Patient Privacy

This procedure guarantees the privacy require-ment by providing privacy protection for patientduring the PHI storage and future retrieval It isexecuted by the patient whenever the PHI is cre-ated updated or modified (eg after diagnosisor tests) The patient breaks the PHI into files fordifferent categories of health information (egallergy lists drug history X-ray data surgeriesetc)

The files are encrypted using any semanticallysecure symmetric key encryption and stored witha secure index (SI) in the S-server The construc-tion of SI can be based on searchable symmetricencryption [44]

From the visited hospital the patient canobtain the URL link to the S-server and a tem-porary HIBC publicprivate key pair based onwhich the patient can generate a valid pseudo-nymous key pair PKT pψp (cf pseudonym self-generation in Ref [45]) so that S-server andany other malicious parties are unable to linkan activity to a patient by the original keypair assigned by the hospital The patient thenuploads the PHI (ie the encrypted files and SI)to S-server [31] Furthermore the patient canself-generate multiple key pairs PKT pψp for dif-ferent searches so that hisher successive activi-ties will not be linked under the same PKT p

2746 Controlling Access toPatientsrsquo Health Records

This procedure is applied to the physicianrsquosaccess to PHI or to the delegateersquos access toSHI fulfilling the access control (authorization)requirement

Das Ch27-9780124158153 2011129 2145 Page 690 14


Controlling the Access to Personal HealthInformation On subsequent visits to the hospi-tal the patient will be asked for the PHI relevantto the treatment being sought The PHI retrievalcan be efficiently performed as a result of thesearchable symmetric encryption technique

The access control is executed between thepatient and S-server The patient transmits (PKT p SI TD (kw)) to S-server where TD (kw) is the trap-door for keyword kw and all other parametershave been defined before S-server executes analgorithm SEARCH locally and outputs 3(kw)the set of encrypted files containing kw Thepatient decrypts the received 3(kw) on hishercell phone and sends the plaintext PHI to thephysician [31] The cell phone would sufficedue to the low complexity of the retrieval pro-tocol The key point of adopting the keywordsearch is the small number of files (instead ofthe entire file collection) returned to the patientNote that we assume the patient also incorpo-rates into the keyword index the network addressinformation of S-servers for each stored PHI filecollectionControlling Access to Shared Health Infor-mation This procedure assures the securityrequirement of minimum-privilege delegationin addition to access control Uncertain inadvance of which doctor will be selected byD-server as the delegatee the delegator encryptsthe intended data using the role-based descrip-tive identity string IDTR (or more accuratelythe corresponding public key PKTR ) represent-ing the delegateersquos role in the hierarchy forwhich only an authentic entity in that role atthe desired organization has the correspondingprivate key ψR and secret key SR The delega-tor Dr White stores the PEKS-encrypted SHIby uploading (HIBEPKTR (PatientData) PEKS (KW )t1 HMACν(HIBE PEKS t1)) on S-server forfuture searches where PatientData denotes thePEKS-encrypted SHI and HIBE represents hier-archical ID-based encryption The pre-sharedsecret key ν is assumed to exist between DrWhite and S-server in the same domain or canbe easily established otherwise The keywordKW different from kw in the PHI case can

be the delegatorrsquos identity datetime the encryp-tion is created etc or any combination ofthem [40]

When Dr Black needs to access the intendedpatient data heshe first authenticates with S-server to prove appropriate access permissions bytransmitting (IDTR TD (KW ) t2HIDSψDminusserver SDminusserver HIDSψWhite SWhite HIDSψR SR (PKTR TD (KW ) HIDSψWhite SWhite HIDSψDminusserver SDminusserver t2)) lever-aging the proxy signatures obtained from theproxy signer D-server where TD (KW ) is the trap-door computed by Dr Black for searching KW The S-server essentially performs the same proxysignature verifications as the delegatee to assurethe authenticity and permissions of both theproxy signer and the delegatee The signatureHIDSψR SR is present for S-server to verify theproper role R Dr Black is claiming (recall thatPKTBlack is included in the proxy signature toenable such verification mainly for later auditonce disputes arise) The proxy signature verifi-cation also entails S-server checking Dr Blackrsquosrevocation status If not revoked Dr Black canobtain the PEKS-encrypted SHI by receivingHIBEPKTR (PatientData) from S-server

2747 Emergency HealthInformation Retrieval

This procedure is designed to handle the emer-gency case in which the patient is physicallyincompetent to perform PHI retrieval for treat-ment We propose two approaches the first ofwhich leverages familyFamily-Based Approach It is intuitive andcommon practice to seek help from a familymember that serves as the emergency contact andwill most likely be available when the patientencounters emergency Family is equipped withall necessary information to retrieval PHI inemergencies (the same procedure used patient inthe normal case)

The essence of family-based approach cap-tures the security factor of ldquosomeone youtrustrdquo [46] the key advantage of which is thatldquosomeonerdquo has subjective judgments to avoid

Das Ch27-9780124158153 2011129 2145 Page 691 15


possible security breaches In our context thefamily is able to judge if the physician request-ing the patientrsquos PHI has appropriate accessrights and if a particular physician has leakedthe PHI illegally without exercising any securitymechanisms It greatly reduces the complex-ity of our system design However the draw-back of this approach is also significant thatis the availability and timeliness of the familyrsquospresence at any emergencies cannot be guaran-teed which could be fatal in our scenario Asa result we propose a second line of defenseleveraging P-device if the family based approachfails [31]P-Device-Based Approach As health-care tech-nology evolves patients with high-risk diseasesare obtaining medical aids from more advancedequipments such as sensors and PDAs in bodysensor networks for monitoring critical healthissues the IMD (implantable medical device)implanted in bodies to assist in proper func-tioning of organs etc It is therefore reason-able to assume the presence of such equipmentsthe so-called P-device in HIPS carried or wornby patients who are to encounter sudden emer-gencies Note however that we can extend thenotion of P-device in our system to incorpo-rate smartphones or any portable devices withrequired capabilities so that patients withoutmonitoring equipments can also be covered bythe P-device-based approach We do not pursuefurther on this issue but argue that a vast major-ity of emergencies can be properly handled by ourtwo approaches

P-device should be programmed with an emer-gency functionality or simply has an emergencybutton The physician pushes the button andP-device enters the emergency mode in whichP-device automatically connects to A-serverthrough wireless network access Meanwhile thephysician contacts A-server to authenticate asthe emergency caregiver on duty This can beachieved for example by having the physiciansign in at hisher hospital for work and sign outwhen heshe leaves so that the list of ldquotodayrsquoson-duty physiciansrdquo of each hospital can be pub-lished online for A-server to check against [31]

The detailed PHI retrieval using P-device can befound in Ref [31]

2748 Sharing Information forHealth Care and Research

Delegation Our design features role-centereddelegation which essentially fulfills the adapt-ability requirement of HIPS by delegatingageneral role instead of a specific entity Aftercross-domain authentication is successfully exe-cuted using the keys assigned Dr White candelegate access rights to hisher patient data toDr Black with whom trust could be establishedindirectly via the D-server (see later this sec-tion) However directly delegating a specific per-son does not scale with dynamic changes Asin the example above when Dr Black becomesunavailable during delegation or the cooperationafterwards Dr Brown has to be delegated againto continue Dr Blackrsquos duty A feasible solutionyielding dynamics would be to delegate the accessrights to a role instead of a person in that roleeg delegating a rheumatologist (both Dr Blackand Dr Brown are rheumatologists) at Hospi-tal B

We recognize that there are two cases in prac-tice concerning role-based delegation [37] (a) thesame role exists in the organization of both thedelegator and the delegatee and (b) the role to bedelegated is delegatee-specific and has no map-ping in the delegatorrsquos organization Case (a) ispossible when the two health-care provider orga-nizations are conducting cooperative researchinvolving shared data and the two groups ofresearchers hold similar positions in their respec-tive groups Case (b) occurs as daily routinewhere the delegator frequently refers patients tospecialists that are unavailable at the delegatorrsquosorganization Case (a) is easily coped with sinceDr White the delegator can specify rules andpermissions for Dr Black the delegatee accord-ing to the policies of Dr Whitersquos organization(Clinic A) on Dr Blackrsquos role (ie rheumatolo-gist) Dr White then digitally signs the rules andpermissions which will be issued to Dr Blackas evidence of delegation The solution to Case

Das Ch27-9780124158153 2011129 2145 Page 692 16


(b) is not straightforward and deserves elabora-tion A naive approach would be to let the del-egator learn relevant policies in the delegateersquosorganization For one thing such an approachdoes not scale since the delegator may eventuallyhave to learn all policies associated with all pos-sible roles Furthermore policy learning is by nomeans an easy task [15] which will incur com-plexity in the delegation process especially at thedelegatorrsquos side For another policies specifyingpermissions to a role are usually for internaluses only and are hence confidential informationnot to be disclosed to any other organizationsA feasible solution would be for the delegatorDr White to appoint the policy server (or role-permission server) PS of the delegateersquos organi-zation which acts on the delegatorrsquos behalf toselect a qualified delegatee Dr Black Note thatthe design of policy server avoids the complexityinvolved in delegation-chaining where Dr Blackcan further delegate someone in hisher role dueto various reasons (eg availability) As a resultthe delegator from Clinic A will only need tocarry out cross-domain authentication and proxyappointment with the policy server as illustratedin Figure 27-1

The delegation procedure is described as fol-lows immediately after the cross-domain authen-tication between Dr White and PS with HP1 HP2

replaced by Dr White PS respectively) [37]

1 Whiterarr PS IDTWhite W HIDSψWhite SWhite (00 W PKTPS PKTR ) t4 HMACζ (PKTWhite W HIDSψWhite SWhite t4)

2 PS rarr Black IDTPS W m HIDSψWhite SWhite HIDSψPS SPS (01 PKTWhite m) t5 HMACς(PKTPS W HIDSψWhite SWhite HIDSψPS SPS

t5)3 Black rarr PS IDBlack PUBR t6 HMACς (PKBlack

PUBR t6)4 PS rarrWhite IDTPS PUBR t7 HMACζ (PKTPS

PUBR t7)

where PKBlackλBlack ς HMAC denote the stan-dard ID-based publicprivate key pair the sharedsecret key between PS and Dr Black andthe keyed-hash message authentication code fordata integrity check respectively with PKBlack=

λBlack H1(IDBlack ) The role-based public keyID

string PKTRIDTR describes the role of the dele-gatee Dr Black and is assigned together withPKTBlackIDTBlack at domain initialization Therole-based credentials can be deduced by anyonein the hierarchy since they are formed the sameway as PKTBlackIDTBlack except with a general roleldquoRheumatologistrdquo replacing a specific name DrBlack The warrant W containing the expiry dateof the appointed proxy PS is used for restrictingPS rsquos signing rights as the proxy signer In gen-eral the proxy signing rights expire as the role-based delegation terminates The numeric stringsprepended in the above signed messages arenecessary for provably secure proxy-signature-based delegation [17] Since PS and Dr Blackare in the same organization or managementdomain we assume the pre-shared secret keysbetween these two entities However the hier-archical ID-based signature HIDSψPS SPS is usedinstead of the standard ID-based signature dueto the future cross-domain proxy signature ver-ification which will be explained in a later sec-tion Refer to Refs [45] and [47] for standardID-based domain initialization and the instanti-ation of IBS respectively Upon receiving thedelegation message m m =(PKTBlackPKTR ) thedelegatee Dr Black can verify the proxy signa-tures including the delegator Dr Whitersquos signa-tureHIDSψWhite SWhite on the warrant and the proxysigner PS rsquos signatureHIDSψPS SPS on the delega-tion message by performing HIDVPKTWhite (00WPKTPSPKTR HIDSψWhite SWhite ) and HIDVPKTPS (01PKTWhitemHIDSψPS SPS ) respectively The sig-nature verification algorithms HIDVPKTWhite andHIDVPKTPS correspond to HIDSψWhite SWhite andHIDSψPS SPS respectively Upon successful veri-fication the delegatee Dr Black returns to thepolicy server PS an additional public key PUBR which is necessary for fine-grained access con-trol and is eventually returned to the delegatorDr White Note that Steps 3 and 4 can be elim-inated if the fine-grained access control is optedout due to the unnecessary employment of thisadvanced control mechanism in some applicationscenariosFine-Grained Access Control The delegationprocedure discussed in the previous section canbe regarded as general access control in that

Das Ch27-9780124158153 2011129 2145 Page 693 17


only those who are delegated proper rights canaccess private patient data However the delega-tion of rights is role-based which indicates thatthe delegatee is granted all permissions associ-ated with a particular role possibly includingpermissions beyond the access of intended patientdata Such coarse-grained access control is insuf-ficient especially in the case where there is norole mapping between organizations (ie Case(b) above) since the delegatorrsquos organization hasto rely entirely on the policies of the delegateersquosorganization Although the policy server (ie theproxy signer) of the delegateersquos organization canbe held guilty if its behavior is not compliant withthe policies by inspecting the audit trails such anapproach is reactive rather than preventive Toproactively gather more control over the portionof patient data to be accessed by the delegateethe delegator can place an extra layer of fine-grained control to limit the access to only min-imum necessary amount of data Note that thefine-grained access control is optional providedthat delegation is in place as the general accesscontrol mechanism However the fine-grainedcontrol is highly recommended for handling sen-sitive data such as those in EHR context

The fine-grained access control is based onPEKS the searchable public-key encryption Inour EHR environment the delegator selectivelyencrypts those data intended for access under thedelegateersquos public key and stores the encrypteddata on a storage server at the delegatorrsquos orga-nization Note that the storage server is subjectto corruption and other attacks Using PEKS theencrypted patient data can only be accessed bythe delegatee as the intended receiver

Uncertain in advance of which doctor willbe selected by the policy server as the dele-gatee the delegator encrypts the intended datausing the role-based descriptive identity stringIDTR (with the corresponding public key PKTR )representing the delegateersquos role in the hierar-chy for which only an authentic entity in thatrole at the desired organization has the corre-sponding private key ψR and secret key SR Thedelegator Dr White stores the encrypted patientdata in the storage server SS for future searchesas [31]

Whiterarr SS IDWhite HIBEPKTR (PatientData) PEKSσ (KW ) t8 HMACν(PKWhite IBE PEKSσ t8)

where PEKSσ (KW )= (σP0H3(e(H2(KW )PUBR )σ ))

is the searchable public key encryption withτ σ isinR Z lowastq chosen by Dr White and PUBR = τP0The PEKS can be instantiated by Ref [38] or theimproved scheme [39] As in the delegation pro-cedure IDWhite and IBE denote standard ID-basedpublic key and encryption respectively The pre-shared secret key ν is assumed to exist betweenthe delegator Dr White and storage server SSin the same organizationmanagement domainor can be easily established otherwise The key-word KW can be the delegatorrsquos identity datetimethe encryption is created etc for retrieving theintended patient data The choice of keywordsmust obey an agreed-upon syntax so that the del-egatee will be able to specify proper keywordsfor searching The single keyword PEKS shownabove can be extended to facilitate multiple-keyword search [40]

When the delegatee Dr Black needs to accessthe intended patient data after being delegatedDr Black first authenticates with the storageserver SS to prove appropriate access permis-sions leveraging the proxy signatures obtainedfrom the proxy signer The storage serverSS essentially performs the same proxy signa-ture verifications as the delegatee to assurethe authenticity and permissions of both theproxy signer and the delegatee We have omit-ted these straightforward authentication stepsin the following illustration to avoid repeat-ing and assume the establishment of a sharedsecret key π = ab P0 during the above authen-tication analogous to the establishment of ζ After successful authentication for access (withbasic revocation implicitly executed) SS needsto check if Dr Black is revoked on demandby Dr White If not revoked Dr Black canobtain the encrypted patient data from SS asfollows [37]

1 BlackrarrSS IDTR TDR (KW ) t9 HMACπ (PKTR

TDR t9)2 SSrarrBlack HIBEPKTR (PatientData) t10HMACπ

(HIBE t10)

Das Ch27-9780124158153 2011129 2145 Page 694 18


where TDR (kw)= τH2(KW ) is the trapdoor com-puted by the delegatee Dr Black for search-ing KW The storage server SS searches over theencrypted patient data designated for Dr Blackand returns the results HIBEPKTR (PatientData) toDr Black

2749 Revoking Access Rights

Intuitively after the delegator Dr White delegatesaccess rights to the delegatee Dr Black Dr Whitewill need to revoke such rights at a later time forvarious reasons including completion of a taskavailability issues or role change of Dr Blackabortion of collaboration with Dr Black due toDr Whitersquos dissatisfaction etc In this section wediscuss issues around revocation in health infor-mation sharingConstruction of Warrant In most cases itwould suffice that the delegator only specifies theexpiry date of the delegated rights indicating theexpected termination time of a cooperative taskThe expiry date can be easily incorporated intothe warrant W We thus do not further pursuesolutions to common-case revocation which willin fact be part of the solutions to on-demandrevocation In our EHR system two exceptionsmay occur which cannot be dealt with by simplyusing the expiry date First of all the role-baseddelegation procedure delegates access rights to arole instead of a delegatee Whenever the dele-gatee becomes unavailable (eg due to a busyschedule) the policy server PS needs to reselecta delegatee in the same role from possible candi-dates The main advantage of this mechanism liesin the transparency at the delegatorrsquos side in thatthe delegator need not be involved in a new del-egation procedure caused by the internal changesof the cooperating organization This mechanismalso greatly reduces communication overhead inthe system incurred by cross-domain authenti-cation particularly when the internal changestake place frequently However it renders revo-cation more difficult in that the delegator can-not directly revoke a role (and hence any entityin that role) The delegator can only revoke the

appointed proxy signer according to the origi-nal design of the warrant [17] which includesonly the proxy signerrsquos public key and relatedinformation In the presentation of the delega-tion procedure we have implied our solution byincorporating the role PKTR in the warrant In thedesign of warrant shown below we will elabo-rate on this issue The second exception would bethe aforementioned abortion of cooperation dueto the delegatorrsquos dissatisfaction or situationsalike that require immediate revocation of dele-gated rights regardlessly Expiry dates alone can-not cope with such unpredictable or on-demandrevocation requests

The warrant W plays a central role in our revo-cation procedure which is constructed as [37]

PS EXP0 PKTPS HIBEPKTPS (10) MISC0R1 Rheumatologist EXP1N1 PKTR1

HIBEPKTR1(11) MISC1

R2 Cardiologist EXP2N2 PKTR2 HIBEPKTR2

(12) MISC2R3 Eye Specialist EXP3N3 PKTR3

HIBEPKTR3(13) MISC3

R6 Pediatrician EXP6N6 PKTR6 HIBEPKTR6

(16) MISC6

where EXPlowast Nlowast PKTRlowast and MISClowast denote theexpiry datetime of the proxy signing rights or thedelegated access rights the number of times a del-egatee can access the encrypted patient data thepublic key associated with the descriptive stringof a role Rlowast and some miscellaneous restrictionsrespectively The encryption of a public key 1lowastHIBEPKTPS (10) issued by the delegator will beused for the second exception mentioned aboveThese encryptions intended for roles in the war-rant will be delivered by the proxy signer PS tocorresponding delegatees in those roles duringthe Step 2 of the delegation procedure (not actu-ally shown)On-Demand Revocation The warrant W spec-ifies the proxy signer PS and all possible roles Rlowastthe delegator is likely to cooperate with Note

Das Ch27-9780124158153 2011129 2145 Page 695 19


that it is possible to add in additional roles whichrequires reissuance of warrant by the delegator(ie generating a new signature HIDSψWhite SWhite

on the warrant) [37] One key point of usingrole-based delegation here is that though it wouldbe cumbersome to list all possible names ofdelegatees it is possible to exhaust all possibleroles in an organization or at least those thedelegator will most frequently encounter so thatthe reissuance of warrant occurs infrequently Inaddition the types of roles in an organization areexpected to remain unchanged while the employ-ees in those roles may undergo frequent and dras-tic changes This design rationale also lends itselfto the solution of the first exception in revo-cation Since each role and associated restric-tions are specified in the warrant which areabsent in the original warrant design according toRef [17] the delegator now has fine-grained con-trol over the revocation of a role besides merelyrelying on the proxy signer Without the specifica-tion of role restrictions revocation of a role willhave to leverage the proxy signer as the ldquomessen-gerrdquo Even if a delegated role say R3 expires (orviolates other restrictions) the warrant need notbe modified or reissued and can be continuouslyused until all entries have expired Note that Nlowastwhich restricts the number of times the delega-tee (in a role) can access the encrypted patientdata is included for fine-grained revocation com-pared with the general expiry datetime It mani-fests another merit of role-based delegationrevocation When the delegatee Dr Black as therheumatologist first access the intended patientdata the storage server SS initiates a countern = Nlowast and decreases it each time the correspond-ing role PKTRlowast accesses the patient data SupposeDr Black is later replaced by Dr Brown to takeover the role as a rheumatologist n will continueto count down instead of being refreshed to a newvalue since Dr Black and Dr Brown are under thesame role-based public key PKTRlowast

To deal with the second exception case a morepowerful revocation mechanism will be neededsince this exception case has the most stringentrequirement that the delegator must be capableof revoking any delegated role at any time [37]

An intuitive approach would be based on theidea of certificate revocation list (CRL) wherethe delegator updates the list of revoked publickeys PKTRlowast and distributes it to the storage serverThis approach is appropriate if we assume thestorage server cannot be compromised In real-ity the storage server can be impersonated bymalicious attackers or be corrupted by the del-egatee (ie collusion attack) so that the stor-age server will allow the revoked delegatee withPKTRlowast to continue accessing the patient data Thissecurity breach exists due to the lack of con-trol over the revocation at the storage server Asuitable solution would use more advanced tech-nique the dynamic accumulator [48] The ideabehind is to consider the delegator to be run-ning a dynamic group of delegated roles eachof which has a public key 1lowast assigned by thedelegator The delegator publishes and updatesan archive ARC on the storage server recordingpast and current accumulated values The delega-tor also publishes public parameters 2 isinR G1 and2pub = s2 on the storage server with s isinR Z lowastq thesecret information of the delegator The accumu-lated value is updated whenever the delegator has(a) a new role to delegate which is not in the con-structed warrant (ie the delegator needs to reis-sue a warrant incorporating this new role) (b) anexisting role in the warrant to delegate (ie thewarrant can contain schedules of future delega-tions if the restrictions to be applied can be pre-determined) or (c) a delegated role to revoke ondemand Cases (a) and (b) represent the joining tothe delegatorrsquos dynamic group which is essentialfor the later on-demand revocation as in Case (c)Before the delegatee authenticates with the stor-age server to access the patient data the delega-tee needs to update a witness $ lowast associated withthe assigned public key 1lowast such that the witnesscannot be successfully updated if this delegateeis revoked Note that the delegatee can skip thewitness update if the accumulated value remainsunchanged (ie none of Cases (a) (b) (c)happens)

For example the delegator Dr White has dis-tributed the public key 16 to the delegatee DrBlack as Pediatrician R6 and published necessary

Das Ch27-9780124158153 2011129 2145 Page 696 20


information on the storage server SS as describedabove Assume that ARC currently comprises kaccumulated values up to Vk The on-demandrevocation procedure based on dynamic accumu-lators we just presented is illustrated as followswhich occurs in between the proxy signature ver-ification (including inspection on the warrant forEXPlowastNlowast based common-case revocation) and thePEKS-encrypted data retrieval mentioned previ-ously [37]

1 Black rarr SS 8= rminus1$ k 9 = r(162+2pub )t11 HMACπ (8 9 t11)

2 SS rarr Black m t12 HMACπ (m t12)

where r isinR Z lowastq is the random secret selected byDr Black π is the shared secret key establishedduring the proxy signature verification and$ k =

Update(ι$ ι) with Update the witness updatealgorithm in Ref [49] and ι lt k the last updateinstance In Step 2 the storage server SS checksthe revocation status of the delegatee Dr Blackby verifying the equality e(89)= e(Vk 2) If itholds the delegatee Dr Black is not revoked oth-erwise Dr Black is revoked The most updatedaccumulated value Vk is calculated by the delega-tor Dr White and published on the storage serverSS as follows (1) Vk = (1s +16)Vkminus1 if Dr Blackwas revoked in the k minus 1st instance or (2) Vk =

(s +1lowast)Vkminus1 if there is joining to the dynamicgroup (ie either Case (a) or (b) happens) andno one was revoked in the k minus 1st instance or (3)Vk remains unchanged if there is no revocation orjoining The storage server then sends a messagem to Dr Black indicating the revocation status ofDr Black Refer to Ref [49] for the Update algo-rithm the initialization of the accumulated valueV0 and more details on the dynamic accumulatoroperationDiscussion One may argue that a sophisti-cated attacker can still subvert the executionof the storage server and deviate the dynamic-accumulator-based revocation Note that in gen-eral such tampering attacks cannot be resolvedby any cryptographic scheme which only func-tions in the face of unsophisticated attackers whoare assumed unable to tamper withmodify thesoftware or hardware of a compromised entity

The same assumption exists in many applica-tion scenarios with applied cryptography [50]In the aforementioned intuitive approach thelist of revoked public keys PKTRlowast must be signedby the delegator to guarantee integrity sinceotherwise even an unsophisticated attacker caneasily alter a public key resulting in a sup-posed revocation unattainable Whereas in ourdynamic-accumulator-based approach alteringthe information stored at the storage serveronly renders a supposed successful verificationto fail causing the entity under verification tobe revoked Apparently if the attackerrsquos goalis to bypass the revocation mechanism andenable a revoked delegatee to continue access-ing patient data our approach will thwartsuch attacks More importantly the dynamic-accumulator-based approach allows our systemto extend to incorporate anonymous settingsAlthough not within the scope of this chap-ter it is sometimes desirable to hide the realidentity of the delegator and delegatee andtheir cooperative relationship during communi-cations These pieces of information can be sensi-tive data in some applications especially whenthe cooperative relationship must be kept con-fidential in the health-care industry A commontechnique to achieve such privacy is throughthe use of pseudonyms in place of the pub-lic key PKTRlowast which reveals identity informationThen revocation based on updating and distribut-ing the list of pseudonyms (in the anonymoussettings instead of PKTRlowast ) will be highly diffi-cult since pseudonyms are changed frequentlyto preserve privacy On the other hand ourdynamic-accumulator-based approach can com-bine with the pseudonym technique to achieveboth revocation and privacy protection for thecommunicating parties Furthermore adoptingour approach provides a countermeasure to thecollusion attack where the delegator colludeswith the storage server to revoke any delegateeof choice This collusion attack cannot be resistedby the intuitive approach while can be resisted bythe dynamic-accumulator-based approach [49]Last but not least the dynamic-accumulator-based revocation mechanism also outperforms

Das Ch27-9780124158153 2011129 2145 Page 697 21


the group-signature-based counterpart in termsof both security and efficiency The detailed com-parisons can be found in Ref [48]

We have mentioned that if revocation is usedthe outsourcing of PEKS-encrypted data enablingdistributed storage would be intractable in thatthe outside storage servers cannot be trusted toexecute the revocation mechanism If the storageserver is totally public which is outside the EHRsystem it is impossible to apply any techniquefor such server (due to the difficulty in authen-tication) to exercise revocation Therefore theoption of outsourcing to a totally public serveris feasible only when revocation is not needed Insystems where distributed data storageretrievalis attractive we can leverage the storage server ateach delegateersquos organization or a public serverdesignated for patient data storage within theEHR system (ie the public storage server shownin Figure 27-1) to host the PEKS storage andretrieval Since the trust relationship with suchcross-domain storage servers can be establishedvia HIB-PKI we can use delegation once again toallow such servers to act on behalf of the dele-gator the design details of which are beyond thescope of this chapter Please refer to Refs [31 37]for more details on protecting patient privacycontrolling access to patientsrsquo health recordsdelegation fine-grained access control and on-demand revocation

275 SECURITY ANALYSIS

In this section we show that the proposed HIPSsystem satisfies the predefined security require-ments [31 37]

Privacy and Confidentiality First of all allPHI (and MHI) files are encrypted which pre-vents the storage server and other malicious par-ties to learn the content of the PHI achievingboth patient privacy and PHI data confidential-ity Second the unlinkability property of the pri-vacy requirement is guaranteed by having thepatient family or P-device actively control theretrieval of the encrypted PHI from S-server andreturn plaintext PHI to the physician based onthe SSE and PEKS primitives breaking the link

present in Ref [14] where the physician candirectly query the server Moreover the distribu-tions of the secret keys in privilege assignmentand the nounce in emergency health informationretrieval are through secure encryption schemesto provide confidentiality for sensitive messagesThe confidentiality of the patient data sharedbetween the delegator and delegatee to facilitatecooperation is assured by the PEKS primitivewhich essentially protects patientsrsquo health dataprivacy Furthermore secret information con-tained in message exchanges remains confidentialby using encryption schemes (ie HIBE IBE)

Fail-Open We developed family-based and P-device-based approaches as the backup mecha-nisms for emergency situations Both approachesare effective in successfully retrieving the neededPHI in the absence of the patient and preserve theprivacy properties as described above

Access Control The fact that in our HIPSsystem the physician must always request thepatient family or P-device for accessing the PHIfacilitates access control The patient and fam-ily can reject inappropriate access requests bysubjective judging P-device relies on A-serveras a trusted authority to verify the eligibilityof the physician for accessing both PHI andMHI As a result only physicians with certainaccess rights can learn the content of PHI orMHI through legitimate requests In additionfine-grained access control has been ensured bythe minimum-privilege delegation requirementThe goal of the delegatee is to ultimately accessthe PEKS-encrypted patient data with properassigned role However in order to prevent otherentities in a same role who are not delegated toaccess the data the proxy signature-based basicaccess control has to be in place By performingproxy signature verification the verifier can beascertain of an entityrsquos delegation status

Accountability This requirement can be easilysatisfied when either patient or family is execut-ing the protocols due to the assumption we madeearlier that possible sources of PHI leakage canbe recalled When the P-device-based approachis leveraged the patient can check back his P-device after the emergency is resolved to obtain

Das Ch27-9780124158153 2011129 2145 Page 698 22


the records (RDs) created in emergency healthinformation retrieval RDs contain informationon which physicians interacted with P-device atwhat times necessary for the patient to con-tact A-server (with A-serverrsquos signature as proof)to obtain the traces (TRs with physicianrsquos sig-nature) from A-server as evidence to hold thephysician(s) accountable Even if the PHI is notleaked the patient can check the keywords in theRDs to determine if the physician should be heldaccountable for searching any PHI other thanappropriate

Minimum-Privilege Delegation This require-ment is specially treated with the fine-grainedaccess control The role-based delegation is toogeneral to restrict the delegated privilege to beprecisely minimum necessary which is the reasonto use the PEKS-based access control Throughencrypting the exact patient data to be accessedby the delegatee the delegator actively and effec-tively restricts the privilege of the delegatee toonly those data intended or PEKS-encrypted forlater retrieval

Adaptability By using the role-centeredapproach for both delegation and revocationinstead of more specific entity-based approachthe changing credentials or availability of a del-egatee is fully dealt with by the policy server ofthe delegateersquos organization without interventionof the delegator or interruption of any delegationand revocation procedures which are thus trans-parent to the delegator

On-Demand Revocation The advanced revo-cation mechanism based on dynamic accu-mulators is dedicated to handling on-demandrevocation Through the update of the accu-mulated values performed by the delegator andmaintained at the storage server the delegateewith a revoked public key will be automaticallyrestrained from further access This technique isalso very efficient in that the storage cost incurredby the accumulated values is independent of thenumber of revoked entities or the total number ofentities in the delegatorrsquos dynamic group

Availability When the patient or family isavailable the S-server that stores the desired PHIcan be looked up using the keyword index In the

protocol description we implicitly assumed thatthe S-server is inside its parent A-serverrsquos domainso that the standard IBC suffices As mentioned insystem setup the hierarchical IBC (HIBC) will beused if the S-server is outside its parent A-serverrsquosdomain The patient can be provided a temporarykey pair (similar to TPp0p ) at level 3 of the hier-archical tree enabling the patient to interact withany S-server throughout the country In emergen-cies the interactions between the physician orP-device and any A-server can be carried out sim-ilarly The HIBC infrastructure ensures the avail-ability of desired PHI wherever the PHI is stored

Data Integrity Since the PHI and MHI areencrypted no one except the patient himherself can perform any meaningful modificationsAlthough the actual modifications to the PHIare performed by an authorized physician thepatient must agree and retrieve the plaintext PHIfor the physician Note that it is technically pos-sible for the family and P-device to retrieve theplaintext PHI for a physician to modify How-ever the family or P-device would not be ableto store the modified PHI back which involves afile collection update and can only be performedwith the patientrsquos secret key not distributed toany other entity The protocol message integrity isensured by including HMAC or digital signaturesin the message exchanges Moreover the integrityof both the stored patient data and the exchangedmessages during interactions is guaranteed byeither signature schemes (ie HIDS IBS) ormessage authentication code (ie HMAC)

Authenticity This objective is achieved lever-aging cross-domain and in-domain authentica-tion based on hierarchical ID-based signatureHIDS and standard ID-based signature IBSrespectively

Another requirement on the delegation indistributed EHR system is the onward delega-tion [15] where the appointed proxy signer isable to further appoint other proxy signers inorder to complete a task thereby forming a dele-gation chain Since our EHR system is concernedwith the sharing of sensitive patient data it isinappropriate to enable delegation chain whichwould be in violation of our fine-grained access

Das Ch27-9780124158153 2011129 2145 Page 699 23


control rationale Intuitively fine-grained accesscontrol is developed due to the delegatorrsquos insuffi-cient control over the delegateersquos access to patientdata If the delegation chain is allowed by the del-egator the proxy signer can further delegate anentity without the delegatorrsquos awareness In otherwords the delegator voluntarily surrenders someof hisher control power In some other appli-cation scenarios eg cooperative research forstatistical studies where patient data have beenpreprocessed to remove sensitive informationthe delegation chain can be adopted to supportonward delegation and alleviate the burden onthe delegator In this case our proxy signature-based delegation can be easily adapted to provideonward delegation mechanism [15]

276 CONCLUSION AND FUTUREWORK

In this chapter we present a secure EHR sys-tem to protect patient privacy and at thesame time to enable emergency health care andsupport patient data sharing across coopera-tive organizations The system is demonstratedto be resilient to various attacks fulfill thedesired functionalities and satisfy the securityrequirements

There are many open issues that constitute ourfuture work The first two issues are related to thesecurity aspects of HIPS The remaining issues arepertinent to the implementation evaluation anddeployability of HIPS

1 Attacks and Threats Besides social engineer-ing there are potential attacks to HIPS thatwill cause devastating consequences Suchattacks comprise collusion traffic analysistiming analysis and denial-of-service (DoS)which we have identified in the designof HIPS Consequently additional mecha-nisms such as alerting functions of the P-device anonymous communication substraterandomized scheduling for PHI uploadsdecentralized storage (to S-servers) andauthentication (to A-servers) have been incor-porated into HIPS rendering the attacks

extremely difficult Nonetheless there willbe unknown adversarial behavior that canlead to effective attacks to HIPS especiallywhen computing and communication tech-nologies are evolving fast As a result newthreats must be identified and defined in theevaluation phase and only when HIPS isroad-tested on trial deployment or even realsystems

2 Social Engineering This is a special and pow-erful type of threats to any security sys-tems with human intervention Human isarguably the weakest link in secure com-munication systems This weakness is oftenexploited by attackers to break into the sys-tem where the security architecture is well-designed and hard to attack by other meansPossible forms of social engineering includetailgating spidering etc [46] The effectivesocial engineering threats to HIPS an exam-ple being the (attackersrsquo) exploitation in PHIaccess control and dissemination in the con-text of social networks are also possible tobe quantitatively measured For instance therisk of victims being identified or linked tocertain activities can be measured in termsof anonymity the probability that an adver-saryrsquos hypothesis is true given the variousinformation gained by the adversary oversocial networks [51] This probability is cal-culated by Bayesian inference as Pr(hj |E )=(Pr(hj )Pr(E |hj )

sumNk=1 Pr(hk )Pr(E |hk )) where

Pr(hlowast) is the a priori probability of hypoth-esis hlowast being true and Pr(E |hlowast) is the condi-tional probability of the event E being truegiven that hlowast is true The number of hypothe-ses N indicates possible sources of informa-tion from the social network for concludingthe hypotheses The Bayesian inference tech-nique can be applied to HIPS to quantify theimpact of social engineering threats given theentity interaction patterns in our applicationscenario The corresponding countermeasureswill be developed subsequently

3 Development of Metrics The evaluation ofsystem performance currently takes placein the form of analytical reasoning More

Das Ch27-9780124158153 2011129 2145 Page 700 24


quantitative and practical evaluations needto be carried out including simulation andtrial deployment of HIPS on real systemswhich cannot be easily accomplished lackingthe right tool the metrics for quantitativemeasurement Our first task will be to exploremeaningful and measurable quantities thatcan serve as metrics for evaluating the sys-tem performance For example the amount ofanonymity guaranteed by HIPS can be mea-sured leveraging Bayesian inference as men-tioned above Another example would be theanonymization of SHI to remove identifica-tion data of the patient for the collaborativeclinical research in HIPS Meaningful metricscan be re-identification risk and informationloss [52] measured by re-identification prob-ability and discernability respectively The re-identification probability is defined by ϑmax =

(1minj (Fj )) where Fj =sum

iisinU I (XZ i = j ) (j =1 J ) is the size of an equivalence class inthe identification database Z the records inwhich take on J different values and havea one-to-one mapping to the individuals inU and XZ i denotes the value of record i inZ The discernability metric [53] is definedas C (gk )=

sumforallE |E |gek |E |

2+

sumforallE |E |ltk |D ||E |

where E refers to the equivalence classes oftuples (of size k ) in the data set D inducedby the anonymization g and || denotes thesize or cardinality We will investigate theapplicability of these metrics to HIPS andmore importantly develop other key met-rics capturing measurable performance perti-nent to security privacy and trustworthinessof HIPS

4 System Deployment and Evaluation At thecurrent stage system evaluation is per-formed by means of analytical reasoningwhich demonstrates that the state-of-the-artdesign of HIPS fulfills the predefined secu-rity requirements Our future work con-sists of simulation using developed metricstrial deployment possibly cooperating withThe University of Florida Healthcare Cen-ter (also known as Shands Hospital) tostudy the tradeoffs among communication

computation and storage ensure no vul-nerability or inefficiency is introduced as abyproduct during HIPS design and test theinteroperability and performance of the sys-tem

5 Human Operations and Autonomic SystemHuman and technology are interwoven Asindicated in the social engineering threatseven the most secure system could be eas-ily hacked by exploiting human factors Itis thus attractive to reduce human interven-tion a possible solution of which is to useautonomic communications system [54 55]as a substitute for human decisions and oper-ations Our health information sharing func-tionality can be implemented autonomicallyresulting in greatly simplified operations fromend usersrsquo perspective A proof-of-conceptimplementation of autonomic informationsharing between two health-care providers iscurrently being developed as shown in Fig-ure 27-3 The autonomic elements designatedfor information sharing in Figure 27-3 areat a higher level of the autonomic commu-nications system above individual computingelements level In general an autonomic ele-ment is constituted by a functional unit whichperforms basic operational functions and amanagement unit which monitors and con-trols the operationconfiguration of the func-tional unit These autonomic elements areexpected to operate in a very dynamic envi-ronment with only fixed policies (ie privacyand security policies in Figure 27-3) and func-tions consisting of authentication delegationaccess control and revocation These func-tions which will be realized through decom-posing the information sharing element tofour lower-level elements performing the cor-responding four functions

For our ongoing research smart context-aware autonomic system with intrusiondetection functionalities would be an idealcandidate for reacting to unforeseeableattacks and informing users in a timely fash-ion On the other hand human operationsare indispensable in critical-decision making

Das Ch27-9780124158153 2011129 2145 Page 701 25


Managementunit for

informationsharing

Functionalunit for

informationsharing

Functionalunit for

informationsharing

Privacy andsecurity policies


User orAdministrator

Autonomic elementof Clinic A

Autonomic elementof Hospital B

(4) Interaction request

(6) Analysis and decision making


(7) Reportrequest for intervention

(8) Message exchange

(8) Acquiring resources


Managementunit for

informationsharing

(1) Collecting application information from higher level

(7) Control information instruction

(5) Monitoring collecting communication information from the network (7) Control information

instruction

FIGURE 27-3 Logic diagram of our autonomic health information sharing framework

and stringent control of sensitive PHI andSHI Therefore the design of HIPS shouldnot introduce inconvenience or complexity tohuman users in performing these operationsWhether autonomic communications systemis appropriate for HIPS and how to guaran-tee security and privacy of HIPS while stillrendering it usable for human users remainopen questions for us to seek answers

As a final remark many of the open issues wehave brought forward are present in almost allsecurity systems Success in tackling these issueswill enlighten research on similar issues in otherapplication systems and contribute to deeperunderstanding in security and trustworthiness

ACKNOWLEDGMENTS

This work was partially supported by the USNational Science Foundation under grants CNS-0916391 and CNS-0716450 the National Nat-ural Science Foundation of China under Grant

61003300 and the China 111 Project underGrant B08038 The work of X Zhu was alsopartially supported by the Fundamental ResearchFunds for the Central Universities under grantJY10000901021

EXERCISE PROBLEMS

1 What is EHR Give some examples of EHRsWhat are the advantages of EHRs overpaper-based medical records

2 What are the three requirements of privacy3 In the hierarchical ID-based cryptosystem

used by the authentication of our e-health-care system can a parent learn the privatekey of a child

4 Name two conflicting requirements for asecure and functional e-health-care systemand how to solve the conflict

5 What technique is used to protect patient pri-vacy against the storage server How doesthis technique achieve this goal

Das Ch27-9780124158153 2011129 2145 Page 702 26


6 In protecting patient privacy and provid-ing access control we used searchable sym-metric encryption and public-key encryp-tion with keyword search (PEKS) bothfor securely searching over encrypted dataDescribe the key differences between thesetwo schemes in terms of their different con-structions and uses

7 How to guarantee location privacy whenpatients use their mobile devices to accessthe e-health-care system (suppose the loca-tions of the device can be tracked all the timesuch as cell phones)

8 When is dynamic revocation desirable andhow to achieve it

9 Can you think of a meaningful attack to theproposed e-health-care system that was notmentioned in the chapter and the counter-measure

10 What are the challenges of implementinghealth information sharing in an autonomiccommunications environment

REFERENCES[1] GM Stevens A brief summary of the medical

privacy rule CRS Report for Congress 2003[2] Electronic health record httpenwikipediaorg

wikiElectronic health record (accessed 081808)[3] MC Rash Privacy concerns hinder electronic

medical records Bus J Greater Triad AreaApril 2005

[4] P Ray J Wimalasiri The need for technicalsolutions for maintaining the privacy of EHRin Proc 28th IEEE EMBS Annual InternationalConference September 2006 pp 4686ndash4689

[5] R Pear Warnings Over Privacy of US HealthNetwork New York Times Feb 2007

[6] U Sax I Kohane KD Mandl Wireless technologyinfrastructures for authentication of patients PKIthat rings J Am Med Inf Assoc 12 (3) (2005)263ndash268

[7] MC Mont P Bramhall K Harrison A flexiblerole-based secure messaging service Exploiting IBEtechnology for privacy in health care in Proc 14thInternational Workshop on Database and ExpertSystems Applications (DEXArsquo03) Prague CzechRepublic 2003

[8] T Denning K Fu T Kohno Absence makes theheart grow fonder New directions for implantablemedical device security in 3rd USENIX Workshop

on Hot Topics in Security (HotSecrsquo08) San JoseCalifornia July 2008

[9] D Halperin T S Heydt-Benjamin B RansfordS S Clark B Defend W Morgan et alPacemakers and implantable cardiac defibrillatorsSoftware radio attacks and zero-power defensesin Proc IEEE Symposium on Security and PrivacyOakland California May 2008

[10] RS Sandhu E J Coyne H L Feinstein C EYouman Role-based access control modelsComputer 29 (2) (1996) 38ndash47

[11] L Zhang G J Ahn B T Chu A role-baseddelegation framework for healthcare informationsystems in SACMAT Monterey California 2002pp 125ndash134

[12] L Zhang G J Ahn B T Chu A rule-basedframework for role-based delegation andrevocation ACM Trans Inf Syst Secur6 (3) (2003) 404ndash441

[13] W-B Lee C-D Lee A cryptographic keymanagement solution for HIPAA privacysecurityregulations IEEE Trans Inf Technol Biomed 12(1) (Jan 2008) 34ndash41

[14] CC Tan H Wang S Zhong Q Li Body sensornetwork security an identity-based cryptographyapproach The ACM Conference on WirelessNetwork Security (WiSecrsquo08) April 2008

[15] M Katzarova A Simpson Delegation in aDistributed Healthcare Context A Survey ofCurrent Approaches in S K Katsikas et al (Eds)ISC 2006 LNCS vol 4176 Springer-VerlagPalermo Italy 2006

[16] V Welch I Foster C Kesselman O MulmoL Pearlman S Tuecke et al X509 ProxyCertificates for Dynamic Delegation in thirdAnnual PKI RampD Workshop GaithersburgMaryland 2004

[17] A Boldyreva A Palacio B Warinschi SecureProxy Signature Schemes for Delegation ofSigning Rights Cryptology ePrint ArchiveReport 2003096 available athttpeprintiacrorg2003096pdf 2003

[18] M Gasser E McDermott An architecture forpractical delegation in a distributed system in ProcIEEE Symposium on Research in Security andPrivacy Oakland California May 1990pp 20ndash30

[19] R Housley W Polk W Ford D Solo InternetX509 public key infrastructure certificate andcertificate revocation list (CRL) profile RFC 3280April 2002

[20] I Foster C Kesselman G Tsudik S TueckeA security architecture for computational gridsin ACM Conference on Computer andCommunications Security (CCS) San FranciscoCalifornia 1998 pp 83ndash92 1998

Das Ch27-9780124158153 2011129 2145 Page 703 27


[21] G Navarro B Sadhigi-Firozabadi E RissanenJ Borrell Constrained delegation in XML-basedaccess control and digital rights managementstandards December 2003

[22] L Seitz E Rissanen T Sandholm B S FirozibadiO Mulmo Policy administration control anddelegation using XACML and delegent in 6thIEEEACM International Workshop on GridComputing Seattle Washington November 2005

[23] J Wang D D Vecchio M Humphrey Extendingthe security assertion markup language to supportdelegation for web services and grid services inIEEE International Conference on Web Services(ICWSrsquo05) Orlando Florida July 2005

[24] Oasis eXtensible Access Control Markup LanguageCommittee XACML V20 httpwwwoasis-openorgcommittees

[25] G Ateniese R Curtmola B de Medeiros D DavisMedical information privacy assurancecryptographic and system aspects in 3rdConference on Security in CommunicationNetworks (SCNrsquo02) Amalfi Italy September 2002

[26] AJ McMurry CA Gilbert BY Reis HC ChuehIS Kohane KD Mandl A self-scaling distributedinformation architecture for public health researchand clinical care J Am Med Inform Assoc 14 (4)(2007) 527ndash533

[27] DJ Power EA Politou MA Slaymaker ACSimpson Towards secure grid-enabled healthcareSoftware Prac Exp 35(9) (2005) 857ndash871

[28] J Sun X Zhu Y Fang Privacy and emergencyresponse in e-healthcare leveraging wireless bodysensor networks IEEE Wireless Commun17 (1) (2010) 66ndash73

[29] CW Burt E Hing amd D Woodwell Electronicmedical record use by office-based physiciansUnited states 2005 National Center for HealthStatistics httpwwwcdcgovnchsproductspubspubdhestatselectronicelectronichtm 2005

[30] CDCrsquos National Center for Health Statistics Morephysicians using electrical medical recordshttpwwwcdcgovodocmediapressrela060721htm2006 (accessed 081808)

[31] J Sun X Zhu C Zhang Y Fang HCPPCryptography Based Secure EHR System for PatientPrivacy and Emergency Healthcare IEEEInternational Conference on Distributed ComputingSystems (ICDCSrsquo11) June 2011

[32] J Sun X Zhu Y Fang Preserving Privacy inEmergency Response Based on Wireless Body SensorNetworks in Proceedings of the IEEE GlobalCommunications Conference December 2010

[33] C-H Chen C-W Chen C Kuo Y-H LaiJM McCune A Studer et al GAnGS GatherSuthenticate rsquon Group Securely in Proceedings ofthe ACM Annual International Conference on

Mobile Computing and Networking (MobiCom)San Francisco California September 2008

[34] C-H Chen C-W Chen C Kuo Y-H Lai J MMcCune A Studer et al Seeing-is-Believing UsingCamera Phones for Human-VerifiableAuthentication in Proceedings of the IEEESymposium on Security and Privacy OaklandCalifornia May 2005

[35] L Zhong M Sinclair R Bittner A Phone-CenteredBody Sensor Network Platform Cost EnergyEfficiency amp User Interface in Proc InternationalWorkshop on Wearable and Implantable BodySensor Networks (BSN) CambridgeMassachusetts 2006

[36] 45 CFR part 160 mdash general administrativerequirements 160103 definitions Department ofHealth and Human Services vol 1 October2002

[37] J Sun Y Fang Cross-domain data sharing indistributed electronic-health-record system IEEETrans Parallel Distrib Syst 21 (6) (2010)754ndash764

[38] D Boneh G D Crescenzo R OstrovskyG Persiano Public Key Encryption with KeywordSearch in EUROCRYPT 2004 LNCS vol 3027Springer Interlaken Switzerland 2004

[39] M Abdalla M Bellare D Catalano E KiltzT Kohno et al Searchable Encryption RevisitedConsistency Properties Relation to AnonymousIBE and Extensions in V Shoup (Eds) Crypto2005 LNCS vol 3621 Springer Santa BarbaraCalifornia 2005

[40] J Baek R Safiavi-Naini W Susilo Public KeyEncryption with Keyword Search RevisitedCryptology ePrint Archive Report 2005191available at httpeprintiacrorg2005191pdf2005 (accessed 081808)

[41] US Department of Health amp Human ServicesWebsite Health information technologyhttpwwwhhsgovhealthit (accessed 081808)

[42] HW Lim K G Paterson Identity-basedcryptography for grid security in H StockingerR Buyya R Perrott (Eds) in Proceedings of the1st IEEE International Conference on e-Science andGrid Computing (e-Science 2005) IEEE ComputerSociety Press Melbourne Australia

[43] C Gentry A Silverberg Hierarchical id-basedcryptography in Proc ASIACRYPT QueenstownNew Zealand December 2002 pp 548ndash556

[44] R Curtmola J Garay S Kamara R OstrovskySearchable symmetric encryption improveddefinitions and efficient constructions in ACMConference on Computer and CommunicationsSecurity (CCS) Alexandria Virginia 2006

[45] J Sun C Zhang Y Fang A security architectureachieving anonymity and traceability in wireless

Das Ch27-9780124158153 2011129 2145 Page 704 28


mesh networks IEEE Conf on ComputerCommunications (INFOCOM) April 2008pp 1687ndash1695

[46] J Brainard A Juels R L Rivest M SzydloM Yung Fourth-factor authentication somebodyyou know in ACM Conference on Computer andCommunications Security (CCS) AlexandriaVirginia 2006

[47] F Hess Efficient Identity-Based Signature SchemesBased on Pairings SAC 2002 LNCS vol 2595Springer-Verlag Madrid Spain 2002 pp 310ndash324

[48] J Camenisch A Lysyanskaya DynamicAccumulators and Application to EfficientRevocation of Anonymous Credentials CRYPTO2002 vol 2442 Springer-Verlag Santa BarbaraCalifornia 2002 pp 61ndash76

[49] L Nguyen R Safavi-Naini Dynamic k-timesanonymous authentication in AppliedCryptography and Network Security Conferencevol 3531 New York City New York 2005pp 318ndash333

[50] T Ristenpart G Maganis A KrishnamurthyT Kohno Privacy-preserving location tracking of

lost or stolen devices cryptographic techniquesand replacing trusted third parties with DHTs in17th USENIX Security Symposium San JoseCalifornia July 2008 pp 275ndash290

[51] C Diaz C Troncoso A Serjantov On the impactof social network profiling on anonymity inN Borisov I Goldberg (Eds) PETS 2008 LNCSvol 5134 Springer-Verlag Berlin Heidelberg2008

[52] KE Emam F K Dankar Protecting privacy usingk-anonymity J Am Med Inf Assoc 15 (5) (2008)627ndash637

[53] R Bayardo R Agrawal Data privacy throughoptimal k-anonymization in Proceedings of the21st International Conference on Data EngineeringTokyo Japan 2005 pp 217ndash228

[54] S Dobson et al A survey of autonomiccommunications ACM Trans Auton Adapt Syst1 (2) (2006) 223ndash259

[55] DM Chess C C Palmer S R White Security inan autonomic computing environment IBM Syst J42 (1) (2003) 107ndash118

Das Ch27-9780124158153 2011129 2145 Page 678 2


EHR systems are used in lieu of paper sys-tems to increase physician efficiency to reducecosts (eg storage) and medical errors to improvedata availability and sharing etc An exemplarysuccessful implementation of the EHR system inthe United States is the Veterans Administrationhealth-care system with over 155 hospitals and800 clinics It is one of the largest integratedhealth-care information systems worldwide andhas been using a single EHR system for yearsDespite all the promising factors EHR systemsare not adopted by the majority of health-caresystems Statistical results of the actual adop-tion rate of EHR in US medical systems canbe found in Ref [2] and the references thereinAmong all the barriers to the implementationof EHR systems privacy and security concernson patientsrsquo medical records are arguably mostdominating This was reflected in a nationwidesurvey conducted in February 2005 by HarrisInteractive of Rochester NY in which 70 of thepopulation were concerned that personal medicalinformation would be leaked because of weakdata security [3] This sentiment has undoubtedlybeen exacerbated by illegal disclosures includ-ing Christus St Joseph Hospital Houston Texas(16000 records were compromised by theft)University of Chicago Hospital (employees werefound selling patient data) and Wilcox MemorialHospital Kauai Hawaii (130000 records werecompromised by theft) [4] Records stored in acentral server and exchanged over the Internetare subject to theft and security breaches TheHealth Insurance Portability and AccountabilityAct (HIPAA) in the United States was estab-lished to regulate EHR-related operations Privacyissues are particularly not addressed adequately atthe technical level [4] Therefore in addition togovernmental regulations standardization and anoverall strategy are needed to ensure that privacyprotection would be built into computer networkslinking insurers doctors hospitals and otherhealth-care providers [5] The implementation ofthe standardization or strategy will undoubtedlybe relying on technical details which are rarelystudied in the research community leaving usnumerous research opportunities

Health information sharing takes place asdaily routine where the primary caregiver (egfamily doctor) frequently refers patients to spe-cialists who are unavailable at the primary care-giverrsquos organization The sharing also occurs asa result of cross-organizational (or simply cross-domain) collaborative research for studying dis-eases and improving clinical care or collaborativeremote surgical operations Central issues aroundthe sharing of health information include authen-tication of an entity delegation of accessrights and permissions access control to patientrecords and revocation of access rights and per-missions with respect to an outside collaboratorIn its original form delegation of rights is usedto appoint a proxy signer who signs on behalfof the delegator in case heshe is absent In ourEHR system delegation of rights can be usedto allow the delegateersquos access to shared healthrecords More challenging yet such access shouldalso be restricted to only the portion(s) of dataintended for sharing since illegal disclosure ofhighly confidential data such as a patientrsquos healthrecords can be devastating and is against theHIPAA regulations Moreover revocation mustbe dynamic in that the delegator should be ableto revoke delegated rights at any time due tounforeseeable situations Data sharing in a dis-tributed fashion eg shifting the delegatorrsquos taskto each delegatee and thereby making the delega-tion process transparent to the delegator allow-ing each cooperating health-care provider to pro-cess data locally for either treatment or researchdelivers tremendous benefits including higher effi-ciency better scalability and lower complexityat the user end due to reduced human interven-tion etc Designing a secure EHR system thatoffers information sharing capability and guar-antees health record privacy is equivalent to glu-ing all the aforementioned challenges togetherand providing a feasible solution which is by nomeans a trivial task and will be the focus of thischapter

The majority of works on privacy protec-tion in health-care systems still concentrate onthe framework design or solution proposals withlittle or no technical realization [4 6ndash12] These

Das Ch27-9780124158153 2011129 2145 Page 679 3






Das Ch27-9780124158153 2011129 2145 Page 680 4















Das Ch27-9780124158153 2011129 2145 Page 681 5






2731 Privacy





Das Ch27-9780124158153 2011129 2145 Page 682 6



2732 Access Control





Das Ch27-9780124158153 2011129 2145 Page 683 7



2733 Authentication







Das Ch27-9780124158153 2011129 2145 Page 684 8





2735 Others



Das Ch27-9780124158153 2011129 2145 Page 685 9











Das Ch27-9780124158153 2011129 2145 Page 686 10


















Das Ch27-9780124158153 2011129 2145 Page 687 11


(1)





Policy server

Dr White

Storage server

Dr Black


Storage server

(1)

(8)

(10)

(9)

(7)

(11)

Policy server

Cloud


VHA

Internet



wireless link

wired link

physical contact

(2)

(3)

(4)

(5) (6)


P-device

Patient

(12)







Das Ch27-9780124158153 2011129 2145 Page 688 12


NHIN

VHA RHIO1RHION



Level 0

Level 2

Level 1

DrWhite

Clinic

A

PS (proxysigner

delegationserver)

Dr Black

HospitalB

SS(storageserver)

Level 3









Das Ch27-9780124158153 2011129 2145 Page 689 13







S0P0




Sjminus1PKTj =sumj


Ql = Sl P0










Das Ch27-9780124158153 2011129 2145 Page 690 14









Das Ch27-9780124158153 2011129 2145 Page 691 15








Das Ch27-9780124158153 2011129 2145 Page 692 16









PUBR t7)




Das Ch27-9780124158153 2011129 2145 Page 693 17











(HIBE t10)

Das Ch27-9780124158153 2011129 2145 Page 694 18








HIBEPKTR1(11) MISC1



HIBEPKTR3(13) MISC3


(16) MISC6


Das Ch27-9780124158153 2011129 2145 Page 695 19







Das Ch27-9780124158153 2011129 2145 Page 696 20









Das Ch27-9780124158153 2011129 2145 Page 697 21











Das Ch27-9780124158153 2011129 2145 Page 698 22











Das Ch27-9780124158153 2011129 2145 Page 699 23












Das Ch27-9780124158153 2011129 2145 Page 700 24






2+







Das Ch27-9780124158153 2011129 2145 Page 701 25


Managementunit for

informationsharing

Functionalunit for

informationsharing

Functionalunit for

informationsharing













Managementunit for

informationsharing




instruction




ACKNOWLEDGMENTS



EXERCISE PROBLEMS






Das Ch27-9780124158153 2011129 2145 Page 702 26





























Das Ch27-9780124158153 2011129 2145 Page 703 27




























Das Ch27-9780124158153 2011129 2145 Page 704 28














Das Ch27-9780124158153 2011129 2145 Page 679 3






Das Ch27-9780124158153 2011129 2145 Page 680 4















Das Ch27-9780124158153 2011129 2145 Page 681 5






2731 Privacy





Das Ch27-9780124158153 2011129 2145 Page 682 6



2732 Access Control





Das Ch27-9780124158153 2011129 2145 Page 683 7



2733 Authentication







Das Ch27-9780124158153 2011129 2145 Page 684 8





2735 Others



Das Ch27-9780124158153 2011129 2145 Page 685 9











Das Ch27-9780124158153 2011129 2145 Page 686 10


















Das Ch27-9780124158153 2011129 2145 Page 687 11


(1)





Policy server

Dr White

Storage server

Dr Black


Storage server

(1)

(8)

(10)

(9)

(7)

(11)

Policy server

Cloud


VHA

Internet



wireless link

wired link

physical contact

(2)

(3)

(4)

(5) (6)


P-device

Patient

(12)







Das Ch27-9780124158153 2011129 2145 Page 688 12


NHIN

VHA RHIO1RHION



Level 0

Level 2

Level 1

DrWhite

Clinic

A

PS (proxysigner

delegationserver)

Dr Black

HospitalB

SS(storageserver)

Level 3









Das Ch27-9780124158153 2011129 2145 Page 689 13







S0P0




Sjminus1PKTj =sumj


Ql = Sl P0










Das Ch27-9780124158153 2011129 2145 Page 690 14









Das Ch27-9780124158153 2011129 2145 Page 691 15








Das Ch27-9780124158153 2011129 2145 Page 692 16









PUBR t7)




Das Ch27-9780124158153 2011129 2145 Page 693 17











(HIBE t10)

Das Ch27-9780124158153 2011129 2145 Page 694 18








HIBEPKTR1(11) MISC1



HIBEPKTR3(13) MISC3


(16) MISC6


Das Ch27-9780124158153 2011129 2145 Page 695 19







Das Ch27-9780124158153 2011129 2145 Page 696 20









Das Ch27-9780124158153 2011129 2145 Page 697 21











Das Ch27-9780124158153 2011129 2145 Page 698 22











Das Ch27-9780124158153 2011129 2145 Page 699 23












Das Ch27-9780124158153 2011129 2145 Page 700 24






2+







Das Ch27-9780124158153 2011129 2145 Page 701 25


Managementunit for

informationsharing

Functionalunit for

informationsharing

Functionalunit for

informationsharing













Managementunit for

informationsharing




instruction




ACKNOWLEDGMENTS



EXERCISE PROBLEMS






Das Ch27-9780124158153 2011129 2145 Page 702 26





























Das Ch27-9780124158153 2011129 2145 Page 703 27




























Das Ch27-9780124158153 2011129 2145 Page 704 28














Das Ch27-9780124158153 2011129 2145 Page 680 4















Das Ch27-9780124158153 2011129 2145 Page 681 5






2731 Privacy





Das Ch27-9780124158153 2011129 2145 Page 682 6



2732 Access Control





Das Ch27-9780124158153 2011129 2145 Page 683 7



2733 Authentication







Das Ch27-9780124158153 2011129 2145 Page 684 8





2735 Others



Das Ch27-9780124158153 2011129 2145 Page 685 9











Das Ch27-9780124158153 2011129 2145 Page 686 10


















Das Ch27-9780124158153 2011129 2145 Page 687 11


(1)





Policy server

Dr White

Storage server

Dr Black


Storage server

(1)

(8)

(10)

(9)

(7)

(11)

Policy server

Cloud


VHA

Internet



wireless link

wired link

physical contact

(2)

(3)

(4)

(5) (6)


P-device

Patient

(12)







Das Ch27-9780124158153 2011129 2145 Page 688 12


NHIN

VHA RHIO1RHION



Level 0

Level 2

Level 1

DrWhite

Clinic

A

PS (proxysigner

delegationserver)

Dr Black

HospitalB

SS(storageserver)

Level 3









Das Ch27-9780124158153 2011129 2145 Page 689 13







S0P0




Sjminus1PKTj =sumj


Ql = Sl P0










Das Ch27-9780124158153 2011129 2145 Page 690 14









Das Ch27-9780124158153 2011129 2145 Page 691 15








Das Ch27-9780124158153 2011129 2145 Page 692 16









PUBR t7)




Das Ch27-9780124158153 2011129 2145 Page 693 17











(HIBE t10)

Das Ch27-9780124158153 2011129 2145 Page 694 18








HIBEPKTR1(11) MISC1



HIBEPKTR3(13) MISC3


(16) MISC6


Das Ch27-9780124158153 2011129 2145 Page 695 19







Das Ch27-9780124158153 2011129 2145 Page 696 20









Das Ch27-9780124158153 2011129 2145 Page 697 21











Das Ch27-9780124158153 2011129 2145 Page 698 22











Das Ch27-9780124158153 2011129 2145 Page 699 23












Das Ch27-9780124158153 2011129 2145 Page 700 24






2+







Das Ch27-9780124158153 2011129 2145 Page 701 25


Managementunit for

informationsharing

Functionalunit for

informationsharing

Functionalunit for

informationsharing













Managementunit for

informationsharing




instruction




ACKNOWLEDGMENTS



EXERCISE PROBLEMS






Das Ch27-9780124158153 2011129 2145 Page 702 26





























Das Ch27-9780124158153 2011129 2145 Page 703 27




























Das Ch27-9780124158153 2011129 2145 Page 704 28














Das Ch27-9780124158153 2011129 2145 Page 681 5






2731 Privacy





Das Ch27-9780124158153 2011129 2145 Page 682 6



2732 Access Control





Das Ch27-9780124158153 2011129 2145 Page 683 7



2733 Authentication







Das Ch27-9780124158153 2011129 2145 Page 684 8





2735 Others



Das Ch27-9780124158153 2011129 2145 Page 685 9











Das Ch27-9780124158153 2011129 2145 Page 686 10


















Das Ch27-9780124158153 2011129 2145 Page 687 11


(1)





Policy server

Dr White

Storage server

Dr Black


Storage server

(1)

(8)

(10)

(9)

(7)

(11)

Policy server

Cloud


VHA

Internet



wireless link

wired link

physical contact

(2)

(3)

(4)

(5) (6)


P-device

Patient

(12)







Das Ch27-9780124158153 2011129 2145 Page 688 12


NHIN

VHA RHIO1RHION



Level 0

Level 2

Level 1

DrWhite

Clinic

A

PS (proxysigner

delegationserver)

Dr Black

HospitalB

SS(storageserver)

Level 3









Das Ch27-9780124158153 2011129 2145 Page 689 13







S0P0




Sjminus1PKTj =sumj


Ql = Sl P0










Das Ch27-9780124158153 2011129 2145 Page 690 14









Das Ch27-9780124158153 2011129 2145 Page 691 15








Das Ch27-9780124158153 2011129 2145 Page 692 16









PUBR t7)




Das Ch27-9780124158153 2011129 2145 Page 693 17











(HIBE t10)

Das Ch27-9780124158153 2011129 2145 Page 694 18








HIBEPKTR1(11) MISC1



HIBEPKTR3(13) MISC3


(16) MISC6


Das Ch27-9780124158153 2011129 2145 Page 695 19







Das Ch27-9780124158153 2011129 2145 Page 696 20









Das Ch27-9780124158153 2011129 2145 Page 697 21











Das Ch27-9780124158153 2011129 2145 Page 698 22











Das Ch27-9780124158153 2011129 2145 Page 699 23












Das Ch27-9780124158153 2011129 2145 Page 700 24






2+







Das Ch27-9780124158153 2011129 2145 Page 701 25


Managementunit for

informationsharing

Functionalunit for

informationsharing

Functionalunit for

informationsharing













Managementunit for

informationsharing




instruction




ACKNOWLEDGMENTS



EXERCISE PROBLEMS






Das Ch27-9780124158153 2011129 2145 Page 702 26





























Das Ch27-9780124158153 2011129 2145 Page 703 27




























Das Ch27-9780124158153 2011129 2145 Page 704 28














Das Ch27-9780124158153 2011129 2145 82 6



2732 Access Control





Das Ch27-9780124158153 2011129 2145 Page 683 7



2733 Authentication







Das Ch27-9780124158153 2011129 2145 Page 684 8





2735 Others



Das Ch27-9780124158153 2011129 2145 Page 685 9











Das Ch27-9780124158153 2011129 2145 Page 686 10


















Das Ch27-9780124158153 2011129 2145 Page 687 11


(1)





Policy server

Dr White

Storage server

Dr Black


Storage server

(1)

(8)

(10)

(9)

(7)

(11)

Policy server

Cloud


VHA

Internet



wireless link

wired link

physical contact

(2)

(3)

(4)

(5) (6)


P-device

Patient

(12)







Das Ch27-9780124158153 2011129 2145 Page 688 12


NHIN

VHA RHIO1RHION



Level 0

Level 2

Level 1

DrWhite

Clinic

A

PS (proxysigner

delegationserver)

Dr Black

HospitalB

SS(storageserver)

Level 3









Das Ch27-9780124158153 2011129 2145 Page 689 13







S0P0




Sjminus1PKTj =sumj


Ql = Sl P0










Das Ch27-9780124158153 2011129 2145 Page 690 14









Das Ch27-9780124158153 2011129 2145 Page 691 15








Das Ch27-9780124158153 2011129 2145 Page 692 16









PUBR t7)




Das Ch27-9780124158153 2011129 2145 Page 693 17











(HIBE t10)

Das Ch27-9780124158153 2011129 2145 Page 694 18








HIBEPKTR1(11) MISC1



HIBEPKTR3(13) MISC3


(16) MISC6


Das Ch27-9780124158153 2011129 2145 Page 695 19







Das Ch27-9780124158153 2011129 2145 Page 696 20









Das Ch27-9780124158153 2011129 2145 Page 697 21











Das Ch27-9780124158153 2011129 2145 Page 698 22











Das Ch27-9780124158153 2011129 2145 Page 699 23












Das Ch27-9780124158153 2011129 2145 Page 700 24






2+







Das Ch27-9780124158153 2011129 2145 Page 701 25


Managementunit for

informationsharing

Functionalunit for

informationsharing

Functionalunit for

informationsharing













Managementunit for

informationsharing




instruction




ACKNOWLEDGMENTS



EXERCISE PROBLEMS






Das Ch27-9780124158153 2011129 2145 Page 702 26





























Das Ch27-9780124158153 2011129 2145 Page 703 27




























Das Ch27-9780124158153 2011129 2145 Page 704 28














Das Ch27-9780124158153 2011129 2145 Page 683 7



2733 Authentication







Das Ch27-9780124158153 2011129 2145 Page 684 8





2735 Others



Das Ch27-9780124158153 2011129 2145 Page 685 9











Das Ch27-9780124158153 2011129 2145 Page 686 10


















Das Ch27-9780124158153 2011129 2145 Page 687 11


(1)





Policy server

Dr White

Storage server

Dr Black


Storage server

(1)

(8)

(10)

(9)

(7)

(11)

Policy server

Cloud


VHA

Internet



wireless link

wired link

physical contact

(2)

(3)

(4)

(5) (6)


P-device

Patient

(12)







Das Ch27-9780124158153 2011129 2145 Page 688 12


NHIN

VHA RHIO1RHION



Level 0

Level 2

Level 1

DrWhite

Clinic

A

PS (proxysigner

delegationserver)

Dr Black

HospitalB

SS(storageserver)

Level 3









Das Ch27-9780124158153 2011129 2145 Page 689 13







S0P0




Sjminus1PKTj =sumj


Ql = Sl P0










Das Ch27-9780124158153 2011129 2145 Page 690 14









Das Ch27-9780124158153 2011129 2145 Page 691 15








Das Ch27-9780124158153 2011129 2145 Page 692 16









PUBR t7)




Das Ch27-9780124158153 2011129 2145 Page 693 17











(HIBE t10)

Das Ch27-9780124158153 2011129 2145 Page 694 18








HIBEPKTR1(11) MISC1



HIBEPKTR3(13) MISC3


(16) MISC6


Das Ch27-9780124158153 2011129 2145 Page 695 19







Das Ch27-9780124158153 2011129 2145 Page 696 20









Das Ch27-9780124158153 2011129 2145 Page 697 21











Das Ch27-9780124158153 2011129 2145 Page 698 22











Das Ch27-9780124158153 2011129 2145 Page 699 23












Das Ch27-9780124158153 2011129 2145 00 24






2+







Das Ch27-9780124158153 2011129 2145 Page 701 25


Managementunit for

informationsharing

Functionalunit for

informationsharing

Functionalunit for

informationsharing













Managementunit for

informationsharing




instruction




ACKNOWLEDGMENTS



EXERCISE PROBLEMS






Das Ch27-9780124158153 2011129 2145 Page 702 26





























Das Ch27-9780124158153 2011129 2145 Page 703 27




























Das Ch27-9780124158153 2011129 2145 Page 704 28














Das Ch27-9780124158153 2011129 2145 Page 684 8





2735 Others



Das Ch27-9780124158153 2011129 2145 Page 685 9











Das Ch27-9780124158153 2011129 2145 Page 686 10


















Das Ch27-9780124158153 2011129 2145 Page 687 11


(1)





Policy server

Dr White

Storage server

Dr Black


Storage server

(1)

(8)

(10)

(9)

(7)

(11)

Policy server

Cloud


VHA

Internet



wireless link

wired link

physical contact

(2)

(3)

(4)

(5) (6)


P-device

Patient

(12)







Das Ch27-9780124158153 2011129 2145 Page 688 12


NHIN

VHA RHIO1RHION



Level 0

Level 2

Level 1

DrWhite

Clinic

A

PS (proxysigner

delegationserver)

Dr Black

HospitalB

SS(storageserver)

Level 3









Das Ch27-9780124158153 2011129 2145 Page 689 13







S0P0




Sjminus1PKTj =sumj


Ql = Sl P0










Das Ch27-9780124158153 2011129 2145 Page 690 14









Das Ch27-9780124158153 2011129 2145 Page 691 15








Das Ch27-9780124158153 2011129 2145 Page 692 16









PUBR t7)




Das Ch27-9780124158153 2011129 2145 Page 693 17











(HIBE t10)

Das Ch27-9780124158153 2011129 2145 Page 694 18








HIBEPKTR1(11) MISC1



HIBEPKTR3(13) MISC3


(16) MISC6


Das Ch27-9780124158153 2011129 2145 Page 695 19







Das Ch27-9780124158153 2011129 2145 Page 696 20









Das Ch27-9780124158153 2011129 2145 Page 697 21











Das Ch27-9780124158153 2011129 2145 Page 698 22











Das Ch27-9780124158153 2011129 2145 Page 699 23












Das Ch27-9780124158153 2011129 2145 Page 700 24






2+







Das Ch27-9780124158153 2011129 2145 Page 701 25


Managementunit for

informationsharing

Functionalunit for

informationsharing

Functionalunit for

informationsharing













Managementunit for

informationsharing




instruction




ACKNOWLEDGMENTS



EXERCISE PROBLEMS






Das Ch27-9780124158153 2011129 2145 Page 702 26





























Das Ch27-9780124158153 2011129 2145 Page 703 27




























Das Ch27-9780124158153 2011129 2145 Page 704 28














Das Ch27-9780124158153 2011129 2145 Page 685 9











Das Ch27-9780124158153 2011129 2145 Page 686 10


















Das Ch27-9780124158153 2011129 2145 Page 687 11


(1)





Policy server

Dr White

Storage server

Dr Black


Storage server

(1)

(8)

(10)

(9)

(7)

(11)

Policy server

Cloud


VHA

Internet



wireless link

wired link

physical contact

(2)

(3)

(4)

(5) (6)


P-device

Patient

(12)







Das Ch27-9780124158153 2011129 2145 Page 688 12


NHIN

VHA RHIO1RHION



Level 0

Level 2

Level 1

DrWhite

Clinic

A

PS (proxysigner

delegationserver)

Dr Black

HospitalB

SS(storageserver)

Level 3









Das Ch27-9780124158153 2011129 2145 Page 689 13







S0P0




Sjminus1PKTj =sumj


Ql = Sl P0










Das Ch27-9780124158153 2011129 2145 Page 690 14









Das Ch27-9780124158153 2011129 2145 Page 691 15








Das Ch27-9780124158153 2011129 2145 Page 692 16









PUBR t7)




Das Ch27-9780124158153 2011129 2145 Page 693 17











(HIBE t10)

Das Ch27-9780124158153 2011129 2145 Page 694 18








HIBEPKTR1(11) MISC1



HIBEPKTR3(13) MISC3


(16) MISC6


Das Ch27-9780124158153 2011129 2145 Page 695 19







Das Ch27-9780124158153 2011129 2145 Page 696 20









Das Ch27-9780124158153 2011129 2145 Page 697 21











Das Ch27-9780124158153 2011129 2145 Page 698 22











Das Ch27-9780124158153 2011129 2145 Page 699 23












Das Ch27-9780124158153 2011129 2145 Page 700 24






2+







Das Ch27-9780124158153 2011129 2145 Page 701 25


Managementunit for

informationsharing

Functionalunit for

informationsharing

Functionalunit for

informationsharing













Managementunit for

informationsharing




instruction




ACKNOWLEDGMENTS



EXERCISE PROBLEMS






Das Ch27-9780124158153 2011129 2145 Page 702 26





























Das Ch27-9780124158153 2011129 2145 Page 703 27




























Das Ch27-9780124158153 2011129 2145 Page 704 28














Das Ch27-9780124158153 2011129 2145 Page 686 10


















Das Ch27-9780124158153 2011129 2145 Page 687 11


(1)





Policy server

Dr White

Storage server

Dr Black


Storage server

(1)

(8)

(10)

(9)

(7)

(11)

Policy server

Cloud


VHA

Internet



wireless link

wired link

physical contact

(2)

(3)

(4)

(5) (6)


P-device

Patient

(12)







Das Ch27-9780124158153 2011129 2145 Page 688 12


NHIN

VHA RHIO1RHION



Level 0

Level 2

Level 1

DrWhite

Clinic

A

PS (proxysigner

delegationserver)

Dr Black

HospitalB

SS(storageserver)

Level 3









Das Ch27-9780124158153 2011129 2145 Page 689 13







S0P0




Sjminus1PKTj =sumj


Ql = Sl P0










Das Ch27-9780124158153 2011129 2145 Page 690 14









Das Ch27-9780124158153 2011129 2145 Page 691 15








Das Ch27-9780124158153 2011129 2145 Page 692 16









PUBR t7)




Das Ch27-9780124158153 2011129 2145 Page 693 17











(HIBE t10)

Das Ch27-9780124158153 2011129 2145 Page 694 18








HIBEPKTR1(11) MISC1



HIBEPKTR3(13) MISC3


(16) MISC6


Das Ch27-9780124158153 2011129 2145 Page 695 19







Das Ch27-9780124158153 2011129 2145 Page 696 20









Das Ch27-9780124158153 2011129 2145 Page 697 21











Das Ch27-9780124158153 2011129 2145 Page 698 22











Das Ch27-9780124158153 2011129 2145 Page 699 23












Das Ch27-9780124158153 2011129 2145 Page 700 24






2+







Das Ch27-9780124158153 2011129 2145 Page 701 25


Managementunit for

informationsharing

Functionalunit for

informationsharing

Functionalunit for

informationsharing













Managementunit for

informationsharing




instruction




ACKNOWLEDGMENTS



EXERCISE PROBLEMS






Das Ch27-9780124158153 2011129 2145 Page 702 26





























Das Ch27-9780124158153 2011129 2145 Page 703 27




























Das Ch27-9780124158153 2011129 2145 Page 704 28














Das Ch27-9780124158153 2011129 2145 Page 687 11


(1)





Policy server

Dr White

Storage server

Dr Black


Storage server

(1)

(8)

(10)

(9)

(7)

(11)

Policy server

Cloud


VHA

Internet



wireless link

wired link

physical contact

(2)

(3)

(4)

(5) (6)


P-device

Patient

(12)







Das Ch27-9780124158153 2011129 2145 Page 688 12


NHIN

VHA RHIO1RHION



Level 0

Level 2

Level 1

DrWhite

Clinic

A

PS (proxysigner

delegationserver)

Dr Black

HospitalB

SS(storageserver)

Level 3









Das Ch27-9780124158153 2011129 2145 Page 689 13







S0P0




Sjminus1PKTj =sumj


Ql = Sl P0










Das Ch27-9780124158153 2011129 2145 Page 690 14









Das Ch27-9780124158153 2011129 2145 Page 691 15








Das Ch27-9780124158153 2011129 2145 Page 692 16









PUBR t7)




Das Ch27-9780124158153 2011129 2145 Page 693 17











(HIBE t10)

Das Ch27-9780124158153 2011129 2145 Page 694 18








HIBEPKTR1(11) MISC1



HIBEPKTR3(13) MISC3


(16) MISC6


Das Ch27-9780124158153 2011129 2145 Page 695 19







Das Ch27-9780124158153 2011129 2145 Page 696 20









Das Ch27-9780124158153 2011129 2145 Page 697 21











Das Ch27-9780124158153 2011129 2145 Page 698 22











Das Ch27-9780124158153 2011129 2145 Page 699 23












Das Ch27-9780124158153 2011129 2145 Page 700 24






2+







Das Ch27-9780124158153 2011129 2145 Page 701 25


Managementunit for

informationsharing

Functionalunit for

informationsharing

Functionalunit for

informationsharing













Managementunit for

informationsharing




instruction




ACKNOWLEDGMENTS



EXERCISE PROBLEMS






Das Ch27-9780124158153 2011129 2145 Page 702 26





























Das Ch27-9780124158153 2011129 2145 Page 703 27




























Das Ch27-9780124158153 2011129 2145 Page 704 28














Das Ch27-9780124158153 2011129 2145 Page 688 12


NHIN

VHA RHIO1RHION



Level 0

Level 2

Level 1

DrWhite

Clinic

A

PS (proxysigner

delegationserver)

Dr Black

HospitalB

SS(storageserver)

Level 3









Das Ch27-9780124158153 2011129 2145 Page 689 13







S0P0




Sjminus1PKTj =sumj


Ql = Sl P0










Das Ch27-9780124158153 2011129 2145 Page 690 14









Das Ch27-9780124158153 2011129 2145 Page 691 15








Das Ch27-9780124158153 2011129 2145 Page 692 16









PUBR t7)




Das Ch27-9780124158153 2011129 2145 Page 693 17











(HIBE t10)

Das Ch27-9780124158153 2011129 2145 Page 694 18








HIBEPKTR1(11) MISC1



HIBEPKTR3(13) MISC3


(16) MISC6


Das Ch27-9780124158153 2011129 2145 Page 695 19







Das Ch27-9780124158153 2011129 2145 Page 696 20









Das Ch27-9780124158153 2011129 2145 Page 697 21











Das Ch27-9780124158153 2011129 2145 Page 698 22











Das Ch27-9780124158153 2011129 2145 Page 699 23












Das Ch27-9780124158153 2011129 2145 Page 700 24






2+







Das Ch27-9780124158153 2011129 2145 Page 701 25


Managementunit for

informationsharing

Functionalunit for

informationsharing

Functionalunit for

informationsharing













Managementunit for

informationsharing




instruction




ACKNOWLEDGMENTS



EXERCISE PROBLEMS






Das Ch27-9780124158153 2011129 2145 Page 702 26





























Das Ch27-9780124158153 2011129 2145 Page 703 27




























Das Ch27-9780124158153 2011129 2145 Page 704 28














Das Ch27-9780124158153 2011129 2145 Page 689 13







S0P0




Sjminus1PKTj =sumj


Ql = Sl P0










Das Ch27-9780124158153 2011129 2145 Page 690 14









Das Ch27-9780124158153 2011129 2145 Page 691 15








Das Ch27-9780124158153 2011129 2145 Page 692 16









PUBR t7)




Das Ch27-9780124158153 2011129 2145 Page 693 17











(HIBE t10)

Das Ch27-9780124158153 2011129 2145 Page 694 18








HIBEPKTR1(11) MISC1



HIBEPKTR3(13) MISC3


(16) MISC6


Das Ch27-9780124158153 2011129 2145 Page 695 19







Das Ch27-9780124158153 2011129 2145 Page 696 20









Das Ch27-9780124158153 2011129 2145 Page 697 21











Das Ch27-9780124158153 2011129 2145 Page 698 22











Das Ch27-9780124158153 2011129 2145 Page 699 23












Das Ch27-9780124158153 2011129 2145 Page 700 24






2+







Das Ch27-9780124158153 2011129 2145 Page 701 25


Managementunit for

informationsharing

Functionalunit for

informationsharing

Functionalunit for

informationsharing













Managementunit for

informationsharing




instruction




ACKNOWLEDGMENTS



EXERCISE PROBLEMS






Das Ch27-9780124158153 2011129 2145 Page 702 26





























Das Ch27-9780124158153 2011129 2145 Page 703 27




























Das Ch27-9780124158153 2011129 2145 Page 704 28














Das Ch27-9780124158153 2011129 2145 Page 690 14









Das Ch27-9780124158153 2011129 2145 Page 691 15








Das Ch27-9780124158153 2011129 2145 Page 692 16









PUBR t7)




Das Ch27-9780124158153 2011129 2145 Page 693 17











(HIBE t10)

Das Ch27-9780124158153 2011129 2145 Page 694 18








HIBEPKTR1(11) MISC1



HIBEPKTR3(13) MISC3


(16) MISC6


Das Ch27-9780124158153 2011129 2145 Page 695 19







Das Ch27-9780124158153 2011129 2145 Page 696 20









Das Ch27-9780124158153 2011129 2145 Page 697 21











Das Ch27-9780124158153 2011129 2145 Page 698 22











Das Ch27-9780124158153 2011129 2145 Page 699 23












Das Ch27-9780124158153 2011129 2145 Page 700 24






2+







Das Ch27-9780124158153 2011129 2145 Page 701 25


Managementunit for

informationsharing

Functionalunit for

informationsharing

Functionalunit for

informationsharing













Managementunit for

informationsharing




instruction




ACKNOWLEDGMENTS



EXERCISE PROBLEMS






Das Ch27-9780124158153 2011129 2145 Page 702 26





























Das Ch27-9780124158153 2011129 2145 Page 703 27




























Das Ch27-9780124158153 2011129 2145 Page 704 28














Das Ch27-9780124158153 2011129 2145 Page 691 15








Das Ch27-9780124158153 2011129 2145 Page 692 16









PUBR t7)




Das Ch27-9780124158153 2011129 2145 Page 693 17











(HIBE t10)

Das Ch27-9780124158153 2011129 2145 Page 694 18








HIBEPKTR1(11) MISC1



HIBEPKTR3(13) MISC3


(16) MISC6


Das Ch27-9780124158153 2011129 2145 Page 695 19







Das Ch27-9780124158153 2011129 2145 Page 696 20









Das Ch27-9780124158153 2011129 2145 Page 697 21











Das Ch27-9780124158153 2011129 2145 Page 698 22











Das Ch27-9780124158153 2011129 2145 Page 699 23












Das Ch27-9780124158153 2011129 2145 Page 700 24






2+







Das Ch27-9780124158153 2011129 2145 Page 701 25


Managementunit for

informationsharing

Functionalunit for

informationsharing

Functionalunit for

informationsharing













Managementunit for

informationsharing




instruction




ACKNOWLEDGMENTS



EXERCISE PROBLEMS






Das Ch27-9780124158153 2011129 2145 Page 702 26





























Das Ch27-9780124158153 2011129 2145 Page 703 27




























Das Ch27-9780124158153 2011129 2145 Page 704 28














Das Ch27-9780124158153 2011129 2145 Page 692 16









PUBR t7)




Das Ch27-9780124158153 2011129 2145 Page 693 17











(HIBE t10)

Das Ch27-9780124158153 2011129 2145 Page 694 18








HIBEPKTR1(11) MISC1



HIBEPKTR3(13) MISC3


(16) MISC6


Das Ch27-9780124158153 2011129 2145 Page 695 19







Das Ch27-9780124158153 2011129 2145 Page 696 20









Das Ch27-9780124158153 2011129 2145 Page 697 21











Das Ch27-9780124158153 2011129 2145 Page 698 22











Das Ch27-9780124158153 2011129 2145 Page 699 23












Das Ch27-9780124158153 2011129 2145 Page 700 24






2+







Das Ch27-9780124158153 2011129 2145 Page 701 25


Managementunit for

informationsharing

Functionalunit for

informationsharing

Functionalunit for

informationsharing













Managementunit for

informationsharing




instruction




ACKNOWLEDGMENTS



EXERCISE PROBLEMS






Das Ch27-9780124158153 2011129 2145 Page 702 26





























Das Ch27-9780124158153 2011129 2145 Page 703 27




























Das Ch27-9780124158153 2011129 2145 Page 704 28














Das Ch27-9780124158153 2011129 2145 Page 693 17











(HIBE t10)

Das Ch27-9780124158153 2011129 2145 Page 694 18








HIBEPKTR1(11) MISC1



HIBEPKTR3(13) MISC3


(16) MISC6


Das Ch27-9780124158153 2011129 2145 Page 695 19







Das Ch27-9780124158153 2011129 2145 Page 696 20









Das Ch27-9780124158153 2011129 2145 Page 697 21











Das Ch27-9780124158153 2011129 2145 Page 698 22











Das Ch27-9780124158153 2011129 2145 Page 699 23












Das Ch27-9780124158153 2011129 2145 Page 700 24






2+







Das Ch27-9780124158153 2011129 2145 Page 701 25


Managementunit for

informationsharing

Functionalunit for

informationsharing

Functionalunit for

informationsharing













Managementunit for

informationsharing




instruction




ACKNOWLEDGMENTS



EXERCISE PROBLEMS






Das Ch27-9780124158153 2011129 2145 Page 702 26





























Das Ch27-9780124158153 2011129 2145 Page 703 27




























Das Ch27-9780124158153 2011129 2145 Page 704 28














Das Ch27-9780124158153 2011129 2145 Page 694 18








HIBEPKTR1(11) MISC1



HIBEPKTR3(13) MISC3


(16) MISC6


Das Ch27-9780124158153 2011129 2145 Page 695 19







Das Ch27-9780124158153 2011129 2145 Page 696 20









Das Ch27-9780124158153 2011129 2145 Page 697 21











Das Ch27-9780124158153 2011129 2145 Page 698 22











Das Ch27-9780124158153 2011129 2145 Page 699 23












Das Ch27-9780124158153 2011129 2145 Page 700 24






2+







Das Ch27-9780124158153 2011129 2145 Page 701 25


Managementunit for

informationsharing

Functionalunit for

informationsharing

Functionalunit for

informationsharing













Managementunit for

informationsharing




instruction




ACKNOWLEDGMENTS



EXERCISE PROBLEMS






Das Ch27-9780124158153 2011129 2145 Page 702 26





























Das Ch27-9780124158153 2011129 2145 Page 703 27




























Das Ch27-9780124158153 2011129 2145 Page 704 28














Das Ch27-9780124158153 2011129 2145 Page 695 19







Das Ch27-9780124158153 2011129 2145 Page 696 20









Das Ch27-9780124158153 2011129 2145 Page 697 21











Das Ch27-9780124158153 2011129 2145 Page 698 22











Das Ch27-9780124158153 2011129 2145 Page 699 23












Das Ch27-9780124158153 2011129 2145 Page 700 24






2+







Das Ch27-9780124158153 2011129 2145 Page 701 25


Managementunit for

informationsharing

Functionalunit for

informationsharing

Functionalunit for

informationsharing













Managementunit for

informationsharing




instruction




ACKNOWLEDGMENTS



EXERCISE PROBLEMS






Das Ch27-9780124158153 2011129 2145 Page 702 26





























Das Ch27-9780124158153 2011129 2145 Page 703 27




























Das Ch27-9780124158153 2011129 2145 Page 704 28














Das Ch27-9780124158153 2011129 2145 Page 696 20









Das Ch27-9780124158153 2011129 2145 Page 697 21











Das Ch27-9780124158153 2011129 2145 Page 698 22











Das Ch27-9780124158153 2011129 2145 Page 699 23












Das Ch27-9780124158153 2011129 2145 Page 700 24






2+







Das Ch27-9780124158153 2011129 2145 Page 701 25


Managementunit for

informationsharing

Functionalunit for

informationsharing

Functionalunit for

informationsharing













Managementunit for

informationsharing




instruction




ACKNOWLEDGMENTS



EXERCISE PROBLEMS






Das Ch27-9780124158153 2011129 2145 Page 702 26





























Das Ch27-9780124158153 2011129 2145 Page 703 27




























Das Ch27-9780124158153 2011129 2145 Page 704 28














Das Ch27-9780124158153 2011129 2145 Page 697 21











Das Ch27-9780124158153 2011129 2145 Page 698 22











Das Ch27-9780124158153 2011129 2145 Page 699 23












Das Ch27-9780124158153 2011129 2145 Page 700 24






2+







Das Ch27-9780124158153 2011129 2145 Page 701 25


Managementunit for

informationsharing

Functionalunit for

informationsharing

Functionalunit for

informationsharing













Managementunit for

informationsharing




instruction




ACKNOWLEDGMENTS



EXERCISE PROBLEMS






Das Ch27-9780124158153 2011129 2145 Page 702 26





























Das Ch27-9780124158153 2011129 2145 Page 703 27




























Das Ch27-9780124158153 2011129 2145 Page 704 28














Das Ch27-9780124158153 2011129 2145 Page 698 22











Das Ch27-9780124158153 2011129 2145 Page 699 23












Das Ch27-9780124158153 2011129 2145 Page 700 24






2+







Das Ch27-9780124158153 2011129 2145 Page 701 25


Managementunit for

informationsharing

Functionalunit for

informationsharing

Functionalunit for

informationsharing













Managementunit for

informationsharing




instruction




ACKNOWLEDGMENTS



EXERCISE PROBLEMS






Das Ch27-9780124158153 2011129 2145 Page 702 26





























Das Ch27-9780124158153 2011129 2145 Page 703 27




























Das Ch27-9780124158153 2011129 2145 Page 704 28














Das Ch27-9780124158153 2011129 2145 Page 699 23












Das Ch27-9780124158153 2011129 2145 Page 700 24






2+







Das Ch27-9780124158153 2011129 2145 Page 701 25


Managementunit for

informationsharing

Functionalunit for

informationsharing

Functionalunit for

informationsharing













Managementunit for

informationsharing




instruction




ACKNOWLEDGMENTS



EXERCISE PROBLEMS






Das Ch27-9780124158153 2011129 2145 Page 702 26





























Das Ch27-9780124158153 2011129 2145 Page 703 27




























Das Ch27-9780124158153 2011129 2145 Page 704 28














Das Ch27-9780124158153 2011129 2145 Page 700 24






2+







Das Ch27-9780124158153 2011129 2145 Page 701 25


Managementunit for

informationsharing

Functionalunit for

informationsharing

Functionalunit for

informationsharing













Managementunit for

informationsharing




instruction




ACKNOWLEDGMENTS



EXERCISE PROBLEMS






Das Ch27-9780124158153 2011129 2145 Page 702 26





























Das Ch27-9780124158153 2011129 2145 Page 703 27




























Das Ch27-9780124158153 2011129 2145 Page 704 28














Das Ch27-9780124158153 2011129 2145 Page 701 25


Managementunit for

informationsharing

Functionalunit for

informationsharing

Functionalunit for

informationsharing













Managementunit for

informationsharing




instruction




ACKNOWLEDGMENTS



EXERCISE PROBLEMS






Das Ch27-9780124158153 2011129 2145 Page 702 26





























Das Ch27-9780124158153 2011129 2145 Page 703 27




























Das Ch27-9780124158153 2011129 2145 Page 704 28














Das Ch27-9780124158153 2011129 2145 Page 702 26





























Das Ch27-9780124158153 2011129 2145 Page 703 27




























Das Ch27-9780124158153 2011129 2145 Page 704 28














Das Ch27-9780124158153 2011129 2145 Page 703 27




























Das Ch27-9780124158153 2011129 2145 Page 704 28














Das Ch27-9780124158153 2011129 2145 Page 704 28














handbook on securing cyber-physical critical ... · of ehr systems, privacy and security concerns...

Documents