医疗系统安全课程规划.ppt

醫療系統安全課程規劃,醫療系統安全課程第16週規劃,6/18總結專題報告?XX醫院/醫學中心醫療資訊安全系統設計資訊安全通訊期刊邀稿整合醫療資訊安全系統報告?HIE Security and Privacy through IHESecurity and Authorization Issues in HL7 Electronic Health Records:A Semantic Web Services Based Approach,第一組 萬芳醫院,第二組 振興醫院,第三組 馬階醫院,第四組 義守醫院,第五組 三軍總醫院,第六組 台大醫院,第七組 長庚醫院,第八組 台北榮總醫院,醫療系統安全課程第16週規劃,6/18總結專題報告?XX醫院/醫學中心醫療資訊安全系統設計資訊安全通訊期刊邀稿整合醫療資訊安全系統報告?HIE Security and Privacy through IHESecurity and Authorization Issues in HL7 Electronic Health Records:A Semantic Web Services Based Approach,XX醫院/醫學中心醫療資訊安全系統設計,醫療資訊安全概論醫療資訊與隱私權重要何謂醫療資訊安全?醫療資訊安全與資訊安全差異?(從資安揭露角度)XX醫院/醫學中心醫療資訊安全系統目前醫療資訊系統架構及資安缺口醫療資訊安全需求(機密 真確 權限 不可否認 等)未來具有資安功能的醫療資訊系統架構 UCA XKMS SAML XACML為確保隱私權應有的醫療資訊安全政策 HIPPA結論,醫療系統安全課程第16週規劃,6/18總結專題報告?XX醫院/醫學中心醫療資訊安全系統設計資訊安全通訊期刊邀稿整合醫療資訊安全系統報告?HIE Security and Privacy through IHESecurity and Authorization Issues in HL7 Electronic Health Records:A Semantic Web Services Based Approach,資訊安全通訊期刊邀稿,資訊安全通訊雜誌係由中華民國資訊安全學會發行之刊物，並定期於每年一月、四月、七月及十月出版資訊安全相關領域之研究論著，每一期將邀請一位Guest Editor針對當期主題進行規劃與邀稿。此期刊並非TSSCI或EI，但為國內資訊安全重要期刊。後進(許建隆教授)目前受邀擔任資訊安全通訊期刊(Communications of CCISA)2008年10月10日出刊的特約主編，本次期刊主題為醫療資訊安全，涵蓋理論、實務、經驗、政策等相關議題，希冀藉由此期刊之內容，能讓讀者更多涉獵並重視醫療資訊安全。,醫療系統安全課程第16週規劃,6/18總結專題報告?XX醫院/醫學中心醫療資訊安全系統設計資訊安全通訊期刊邀稿整合醫療資訊安全系統報告?HIE Security and Privacy through IHESecurity and Authorization Issues in HL7 Electronic Health Records:A Semantic Web Services Based Approach,HIE Security and Privacy through IHE,A Healthcare Information Exchange(HIE)is a set of healthcare entities that are cooperating to share healthcare information about common patients.The IHE has proposed that a basic method of providing a HIE is through an infrastructure that allows for the sharing of clinical documents about a patient in a way that allows for long term use.This infrastructure is made up of a family of Profiles centered on the Cross-Enterprise Document Sharing(XDS)Profile.This white paper will discuss how an HIE that leverages IHE profiles can protect patient privacy and information security.The organizers of the HIE need to implement basic security principals in order to offer a security model to protect the HIE information exchanges.The architecture put forth by IHE is to share discrete information in the form of documents.These documents may be simple text documents,formatted documents using standards such as PDF,or fully structured and coded using standards such as HL7 CDA.These documents are shared with reference to the individual patient with the expectation that in the future they can be used to provide better healthcare treatment to that same individual patient.,HIE Security and Privacy through IHE,IntroductionScoping Security and PrivacyInternational Data Protection PrinciplesPolicies and Risk Management Technical Security and Privacy controls Applying Security and Privacy to an HIEBuilding Upon Existing Security EnvironmentIHE Security and Privacy ToolkitIHE Security and Privacy Controls Conclusion,Elements of the health information exchange challenge,Open“governance”Trust relationships among participantsInvolve consumersProvide securityDevelop sustainable fundingProvide capable business services and operationsDevelop technical capabilities and operations,Scoping Security and Privacy,The Policy Environment is made up of many layers of policies.These policies work together in a hierarchic way to interlock.We will introduce some of these different layers in this white paper and show how they influence the technology.International Data Protection PrinciplesPolicies and Risk ManagementTechnical Security and Privacy controls,HIE Security and Privacy through IHE,IntroductionScoping Security and PrivacyInternational Data Protection PrinciplesPolicies and Risk Management Technical Security and Privacy controls Applying Security and Privacy to an HIEBuilding Upon Existing Security EnvironmentIHE Security and Privacy ToolkitIHE Security and Privacy Controls Conclusion,International Data Protection Principles,In 1980,the Organization for Economic Cooperation and Development(“OECD”經濟合作暨發展組織)developed Guidelines on the Protection of Privacy and Transborder Flows of Personal Data.These guidelines were intended to harmonize national privacy laws,uphold human rights,and promote the free flow of information among its 30 member countries.The OECD guidelines have served as a basis for data protection laws in the United States,Europe,Canada,Japan,Australia,and elsewhere.Together,these principles and laws provide a useful framework for developing general data protection requirements for health information systems.In the context of this paper,these data protection principles will be scoped to the IHE relevant policies and understood in the context of the IHE risk environment.The technical controls that are relevant to IHE are distilled below.,http:/www.oecd.org/document/20/0,3343,en_2649_201185_15589524_1_1_1_1,00.html,HIE Security and Privacy through IHE,IntroductionScoping Security and PrivacyInternational Data Protection PrinciplesPolicies and Risk Management Technical Security and Privacy controls Applying Security and Privacy to an HIEBuilding Upon Existing Security EnvironmentIHE Security and Privacy ToolkitIHE Security and Privacy Controls Conclusion,Policies and Risk Management(1/5),IHE solves Interoperability problems via the implementation of technology standards.It does not define Privacy or Security Policies,Risk Management,Healthcare Application Functionality,Operating System Functionality,Physical Controls,or even general Network Controls.While HIE Policies and Risk Management are outside its scope,IHE does recognize that these elements are a necessary piece of a system implementation.IHE IT Infrastructure Technical Framework,Volume 1:Appendix“L”outlines some of the issues that should be evaluated to be included in the local Policy creation and Risk Management decisions.Also,the IHE IT Infrastructure Planning 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 HIEPolicies that indicate acceptable levels of risk within HIEPolicies that indicate what sanctions will be imposed on individuals that violate the HIE policiesPolicies on training and awarenessPolicies on user provisioning and de-provisioning within affinities(and local operations policy)Policies on emergency mode operationsPolicies on acceptable network use and protectionsPolicies on authentication methods that are acceptablePolicies on backup and recovery planningPolicies on acceptable third party accessPolicies on secondary use of the information in the HIEPolicies on the availability of the HIE(is the HIE considered life critical,115 normal,or low priority)Policies for maintenancePolicies for length of time that information will be maintained in the HIEEtc,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 patients data.At the Community level could be a Policy with general goals indicating that data is not to be disclosed to a persons 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 them-selves 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 up-front 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 generationIT infrastructure failure(e.g.hard drive crash)this situation is also common and handled through common infrastructural redundancyNeed to elevate privileges due to a patient emergency,often called break-glass(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,IntroductionScoping Security and PrivacyInternational Data Protection PrinciplesPolicies and Risk Management Technical Security and Privacy controls Applying Security and Privacy to an HIEBuilding Upon Existing Security EnvironmentIHE Security and Privacy ToolkitIHE 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 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)Non-Repudiation 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 shouldnt see themIdentification and Authentication Controls.Access Controls.Confidentiality Controls.Patient Privacy Controls.I want to be sure the data are not modify by some one who doesnt have the right for thatIdentification and Authentication Controls.Access Controls.Data Integrity Controls.I want to be sure the data can be retrieve when neededAvailability 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 actionIdentification and Authentication Controls.I want to know what is done by whoAccountability Controls.I want to be sure what has been done cannot be deniedNon-Repudiation ControlsThese 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,IntroductionScoping Security and PrivacyInternational Data Protection PrinciplesPolicies and Risk Management Technical Security and Privacy controls Applying Security and Privacy to an HIEBuilding Upon Existing Security EnvironmentIHE Security and Privacy ToolkitIHE 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 HIEBuilding Upon Existing Security EnvironmentIHE Security and Privacy ToolkitIHE 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 inclu