【文章內(nèi)容簡(jiǎn)介】 n is created, stored, communicated, and modified。 this control protects the information from being exposed. For example: encryption or access controls. 5) Data Integrity Controls – The controls that prove that the data has not changed in an unauthorized way. For example: digital signatures, secure hash algorithms, CRC, and checksum. 6) NonRepudiation Controls – The controls that ensure that an entity can not later refute that they participated in an act. For example author of a document, order of a test, prescribe of a prescription. 7) Patient Privacy Controls – The controls that enforce patient specific handling instructions. 8) Availability Controls – The controls that ensure that information is available when needed. For example: backup, replication, fault tolerance, RAID, trusted recovery, uninterruptible power supplies, etc.,Technical Security and Privacy controls (3/4),For example: Two of the OECD data protection principals are Security Safeguards and Accountability. This can be viewed as: Security Safeguards: I want to be sure the data are not disclosed to someone who shouldn39。t see them Identification and Authentication Controls. Access Controls. Confidentiality Controls. Patient Privacy Controls. I want to be sure the data are not modify by some one who doesn39。t have the right for that Identification and Authentication Controls. Access Controls. Data Integrity Controls. I want to be sure the data can be retrieve when needed Availability Controls (CAI? Availability, Confidentiality, and Integrity) (3A ? Authentication, Authorization, and Accountability) Accountability: (more),Technical Security and Privacy controls (4/4),For example: Two of the OECD data protection principals are Security Safeguards and Accountability. This can be viewed as: Security Safeguards: (more) Accountability: I want to be sure who is doing action Identification and Authentication Controls. I want to know what is done by who Accountability Controls. I want to be sure what has been done cannot be denied NonRepudiation Controls These security and privacy controls are not useful without input from the various types of policies that reflect any individual environment and expectation. We will assume a conservative set of policies and show how these controls can be applied given the IHE profiles.,HIE Security and Privacy through IHE,Introduction Scoping Security and Privacy International Data Protection Principles Policies and Risk Management Technical Security and Privacy controls Applying Security and Privacy to an HIE Building Upon Existing Security Environment IHE Security and Privacy Toolkit IHE Security and Privacy Controls Conclusion,Applying Security and Privacy to an HIE,IHE does not set policies but is policy sensitive. Therefore we now discuss the policy enabling technologies and not the policies themselves. This section will show how the existing security controls in standalone system are leveraged and extended when connecting them into an HIE Building Upon Existing Security Environment IHE Security and Privacy Toolkit IHE Security and Privacy Controls,Building Upon Existing Security Environment (1/5),The IHE model for participants presumes that clinical applications in place today include the necessary basic security principles to protect patient data within the entity (e.g. hospital, clinic). These applications currently include controls to authenticate users, to check that the users have rights to perform functionality (e.g. RoleBasedAccess Control), and to account for the actions of users within the application. These applications are installed within a facility and that facility has taken care to physically and electronically protect these applications with physical barriers, backup electricity, airconditioning, backup of data, etc. For example, these are the types of controls currently required by the CCHIT certification criteria for Ambulatory EMR systems and InPatient EHR systems in the USA (See http://www.cchit.org).,Building Upon Existing Security Environment (2/5),The emergence of Personal Health Records may introduce new policy requirements and controls both at the HIE level and at the local operational policy level and individual participants should take this into account when evaluating their current risk profile. The Personal Health Record is an area that does not have regulatory controls in many countries (e.g. HIPAA has few regulatory controls on the Personal Health Record controlled by the patient). The entities that are joining the HIE have experience in implementing the appropriate policies for their entities and these have driven their choice of security mechanisms and influenced the appropriate implementation.,Building Upon Existing Security Environment (3/5),These entities have some measure of control (there will be variations in the entities) over their users (employees, contractors, patients). These entities understand their environment and have responsibility for implementing the controls for the locally appropriate authentication methods (passwords, smartcards, 2factor token, etc). They can react quickly to provision, suspend, authorize, and deprovision users in a way that is sensitive to the employees’ rights. As these entities join an HIE the clinical applications that touch the HIE can be seen as being applications at the edge of the entity that are participating in an exchange. As such the edge applications and their architecture need a common set of policies and controls to apply to the edge application, or edge system.,Building Upon Existing Security Environment (4/5),In healthcare, beyond the basic security principles, we must additionally be sensitive to patient care and safety. The applications closest to the patient are best informed for determining the context of the current situation. It is only at this level that emergency mode can be handled in an expedient way (often called breakglass). The IHE model leverages the general security controls availab