【正文】 g Committee has produced a white paper that guides IHE profile developers on detail risk identification so the profiles can properly advise implementers. It is therefore the duty of system implementers to take this guidance into account as part of their Risk Management practices,Policies and Risk Management (2/5),Figure 2 shows how the corporate Polices are developed, promulgated, 95 and eventually implemented with varying degrees of automation. Policy enforcement must be a part of this policy lifecycle.,Policies and Risk Management (3/5),For example implementers need to be aware of different kinds of policies that need to be harmonized with local enterprise policies: Policies for who has access to what type of documents in the HIE (Access) Policies for who is allowed to publish documents into the HIE (Write) Policies on the acceptable types of documents in the HIE Policies that indicate acceptable levels of risk within HIE Policies that indicate what sanctions will be imposed on individuals that violate the HIE policies Policies on training and awareness Policies on user provisioning and deprovisioning within affinities (and local operations policy) Policies on emergency mode operations Policies on acceptable network use and protections Policies on authentication methods that are acceptable Policies on backup and recovery planning Policies on acceptable third party access Policies on secondary use of the information in the HIE Policies on the availability of the HIE (is the HIE considered life critical, 115 normal, or low priority) Policies for maintenance Policies for length of time that information will be maintained in the HIE Etc,Policies and Risk Management (4/5),These policies are not a flat set, but often can be seen as a cascade. A good example of this is the cascade of policies related to access to a patient’s data. At the Community level could be a Policy with general goals indicating that data is not to be disclosed to a person’s neighbor. This is further refined at the Enterprise Policy where a ‘neighbor’ would be defined given the known population and social norms. This Policy can further be refined by the patient themselves in their own privacy consent where specifically a hostile neighbor might be named. An important set of policies are those around emergency modes. There are wide definitions of cases that are often referred to as emergency mode. These emergency modes need to be recognized for the risks they present. When these use cases are factored in upfront the mitigations are reasonable. Natural or man made catastrophic disaster (e.g. Hurricane, Earth Quake) – often times additional workforce migrates into the area from other places to help out. These individuals need to quickly be screened and provisioned with appropriate access. Utility failure (e.g. electric failure) – this situation is common and easily handled through uninterruptible power supplies and backup generation IT infrastructure failure (e.g. hard drive crash) – this situation is also common and handled through common infrastructural redundancy Need to elevate privileges due to a patient emergency, often called breakglass (e.g. nurse needs to prescribe) Need to override a patient specified block due to eminent danger to that patient – this override is not a breaking of the policy but is an explicit condition within the policy.,Policies and Risk Management (5/5),Often times the emergency room is considered as an emergency mode, but the emergency room is really a normal mode for those scheduled to work there. When looked at as normal mode, the proper privileges and workflow flexibility can be specified. Policy development is frustrated by apparent conflicts in policies. These conflicts are often superficial and can be addressed upfront once the details of the policy are understood. For example in Europe there are policies that forbid the recording of race, yet this is an important clinical attribute. This superficial conflict might be addressed by recording genetic markers instead of race. Another good example of a superficial policy conflict is in records retention requirements at the national level vs at the medical level. Retention of records is fixed at a short period after death, yet if the patient has black lung then the records must be preserved well beyond.,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,Technical Security and Privacy controls (1/4),Based on the experience of the IHE participants through experience in implementing HIE environments there is a common set of Security and Privacy controls that have been identified. These controls are informed by a combination of the OECD data protection principles, experience with explicit policies at HIE implementations, and expectation of general Policies and Security Risk Management. These security and privacy controls can be used to enforce the: 1) Accountability Controls – The controls that can prove the system is protecting the resources in accordance to the policies. This set of controls includes security audit logging, reporting, alerting and alarming. 2) Identification and Authentication Controls – The controls that prove that a system or person is who they say that they are. For example: personal interactions, Digital Certificates, security assertions, Kerberos, and LDAP. 3) Access Controls – The controls that limit access by an authenticated entity to the information and functions that they are authorized to have access to. These controls are often implemented using Role Based Access Controls.,Technical Security and Privacy controls (2/4),4) Confidentiality Controls– As sensitive information is created, stored, communicated, and modifi