Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.

NHIN Privacy & Security

3 141 vues

Publié le

Implementing Advanced Security and Privacy in the Nationwide Health Information Network (NHIN)

Publié dans : Technologie, Santé & Médecine
  • Soyez le premier à commenter

NHIN Privacy & Security

  1. 1. Implementing Advanced Security and Privacy in the Nationwide Health Information Network (NHIN) Presentation to Health Information Technology Policy and Standards Committees John (Mike) Davis David Staggs (SAIC) June 17, 2010 Department of Veterans Affairs
  2. 2. Agenda Introduction Foundations Implementation Demonstration Summary 2
  3. 3. Virtual Lifetime Electronic Record On April 9, 2009, President Obama directed the Department of Defense and the Department of Veterans Affairs to create the Virtual Lifetime Electronic Record: “… will ultimately contain administrative and medical information from the day an individual enters military service throughout their military career and after they leave the military.” -President Barack Obama 3
  4. 4. Virtual Lifetime Electronic Record Strategy  Allow health care providers access to Servicemembers’ and Veterans’ health records, in a secure and authorized way, regardless of whether care is delivered in the private sector, by Department of Defense (DoD), or VA  More efficient, effective, and timely than creating a single DoD/VA system – Builds on existing DoD and VA Electronic Health Record capabilities – Solves the need to share information with the private sector – Not a large acquisition program – Avoids obsolescence as Electronic Health Record systems modernize 4
  5. 5. Business Case for Health Information Sharing Nationwide Health Information Network: San Diego Project News Report  Electronic processes replace paper-based health information requests saving weeks or months  Advanced security and privacy mechanisms ensure appropriate access to patient records  Patients have the option to allow or prevent sharing of some of their information 5
  6. 6. NHIN San Diego Physical Deployment (To-Be) ADI=Access Control Decision Information CDS=Clinical Data Services HDR=Health Data Repository MPI=Master Patient Index NHIN=Nationwide Health Information Network PDP=Policy Decision Point PEP=Policy Enforcement Point ROI=Release of Information RPC=Remote Procedure Call WS=Web Services XACML=eXtensible Access Control Markup Language 6
  7. 7. View of Summary of Care Record (C32) 7
  8. 8. Foundations 8
  9. 9. Bottom Up Innovation Within a Coordination Framework * Today’s story is built on the backbone of a coordination framework applied to security and privacy * Interoperability Framework Overview, Douglas Fridsma, MD, PhD, March 24, 2010 9
  10. 10. Top Health Care System Security Requirements  Security and privacy infrastructure for end-to-end data sharing  High-assurance person identifiers across federated domains  Organizational and personal policy enforcement  User accountability for potential security events (audit)  Security assurance, interoperability through standards, common processes, and system certification 10
  11. 11. Patient Privacy Requirements Key Concept: Enforce both Consumer and Enterprise Privacy policy with Common Security Services  Enforcing consumer privacy policy is a security concern  Agreement to enforce privacy is a business decision/contract with consumer  Basic consumer privacy policies both control access and constrain security 11
  12. 12. Web of Standards and Related Organizations •Certification Profiles NHIN •NHIN Updates HL7 CCHIT •Health care IHE Profiles OASIS •CDA Consent Directive ASTM •Healthcare Functional Role Standard CPP Access Control •SAML, XACML, WS- •SOA Security and Privacy •Security/Privacy Info ModelsSystem Trust Profiles •Privacy Confidentiality Codes •Privilege Management •HL7 Service Aware Architecture •Structural Roles ISO HITSP •Authorization/Privacy via US TAG Preference standards and Mike Davis Interface Specifications •Privilege Management Office of Health Information, Security Architect •Structural and Functional ANSI- Roles, +++ April 20, 2010 INCITS Text Color Key NIST Demos •Standards •RBAC Standard •RBAC Implementation •FIPS/Special •Models/Draft standards Publications CDA=Clinical Document Architecture ISO=International Standards Organization SAML=Security Assertion Markup Language FIPS=Federal Information Processing Standard NIST=National Institute of Standards & Technology SOA=Service Oriented Architecture HL7=Health Level 7 OASIS=Organization for the Advancement of Structured XACML=eXtensible Access Control Markup Language HITSP=Healthcare Information Technology Information Standards Standards Panel RBAC=Role Based Access Control NHIN=Nationwide Health Information Network Structured Information Standards 12
  13. 13. Leveraging Standards Organizations Key Concept: Meet interoperability requirements with standards, their profiles, and shared information models 1/08 1/09 1/10 Building Consensus Balloting Standards ASTM=American Society for Testing and Materials OASIS=Organization for the Advancement of Structured Information Standards DHHS=Department of Health and Human Services RBAC=Role Based Access Control HL7=Health Level 7 HITSP=Healthcare Information Technology NHIN=Nationwide Health Information Network 13
  14. 14. Conduct Interoperability Demonstrations Key Concept: Validate approach through interoperability demonstrations (reference implementations and testing) • RSA Conference March 2010 – Multi-vendor demonstration of NHIN Connect Security & Privacy • HIMSS Apr 2009 – First end-to- end demonstration of privacy consents and access control • London Conference Oct 2008 – Extensions to the RSA demonstration adding SAML • RSA Conference April 2008 – Multi-vendor demonstration of OASIS XACML profile Clinical roles and permissions: Clinician least privilege Emergency access: Granting extraordinary access during events involving risk of potential death or injury Patient consent directives: Patient driven authorizations to personal health information use and disclosure Health care security policy: Health care specific business rules for application behavior and patient safety HIS=Health Information System XACML= eXtensible Access Control Markup NHIN=Nationwide Health Information Network Language SAML=Security Assertion Markup Language 14
  15. 15. Advanced Concept Demonstrations Protecting the Human Genome - RSA 2010 Patient Access Control System PHR Service Patient Policy Patient has ability to view their Genotype Constrains access and determine whether to deny access to to specific AT-RISK PIP all or portions of it. SNPs based on Policy characteristics and/or disease PDP PEP grouping Provider Request for Constraints Patients genotype Assertion Consumption Visibility To Patient Clinical Obligation Adaptive Services Response XSPA Enabled Service Provider Continuous Re-validation of Patient Policy Intent Original Mapping Genome Wide Association Studies Service Patient’s GWAS Genotype New diseases and GWAS=Genome-wide Association Study characteristics PDP=Policy Decision Point are mapped PEP=Policy Enforcement Point PHR=Patient Health Record Multiple Organizations PIP=Policy Information Point Contribute Findings SNIP=Single Nucleotide Polymorphism XSPA=Cross-enterprise Security and Privacy Authorization Trusted/Clinically relevant providers 15
  16. 16. Global Participants System and Participant Locations RSA 2008 – San Francisco, CA Oasis XACML InterOp Demonstration – Ditton Manor, London, UK HIMSS 2009 – Chicago, IL RSA 2010 – San Francisco, CA 16
  17. 17. Implementation 17
  18. 18. Reference Model Overview GW=Gateway PEP=Policy Enforcement Point ROI=Release of Information Office 18
  19. 19. Consumer Privacy & eConsent 19
  20. 20. Wife of a Wounded Warrior Sarah Wade Video: http://www.youtube.com/watch?v=wrgHtc5DKIM Testimony: http://veterans.house.gov/hearings/Testimony.aspx?TID=598 28&Newsid=567&Name=%20Sarah%20%20Wade 20
  21. 21. Veteran eConsent Task Goal • Provide Veterans with a simple way to create, electronically sign, and communicate their personal privacy preferences: • From their home, at a VA Hospital Kiosk, or anywhere else • To encourage and support participation in NHIN • Replace cumbersome paper-based systems • Meet ONC Consumer Preference Requirements • Veterans are VA’s consumers, but goals apply equally to all NHIN providers NHIN=Nationwide Health Information Network ONC=Office of the National Coordinator 21
  22. 22. Meet ONC Consumer Preferences Requirements Consumers should be able to: Define permissions for who is permitted to access information Express how their health information would be made available Authorize release of their health information Establish various types of consumer preferences (consents, advance directives, etc.) Define privacy preference conditions including:  By type of information (all data, segmentation of data)  By role and criteria based access, including type of encounter, embargoed records (VIP, legal restrictions)  By time (start, end, duration)  By level of participation (opt-in, opt-out, with or without additional classifications, with or without additional Fully meets granularity) NHIN=Nationwide Health Information Network Partially meets  By purpose of use ONC=Office of the National Coordinator VIP=Very Important Person Does not meet 22
  23. 23. Patient Viewpoint (to-be) Consent Directive 23
  24. 24. VA Forms Supporting eConsent Policies 24
  25. 25. eConsent Signature Service Framework Electronic Forms Signature Repository Service  Approval Authentication Demographic Service 1 2 Service User Input 3 Signature is Veteran bound to Patient document 25
  26. 26. Leverages HL7 Consent Directive Analysis Model - allow/disallow action Medical Record - purpose of Privacy Policy Reference consent Reference - effective period - Patient Identification - additional - Medical Record conditions Identification Action Specification - hierarchy of operations applied to information Information Sender Health Information Affected - Organization - Related to a diagnosis Information - Data Sensitivity Receiver - Coverage Type - Role - Type of information (e.g., - Identity results) 26
  27. 27. Privacy Management 27
  28. 28. Release Of Information (ROI) Consent Reconciliation 28
  29. 29. 29
  30. 30. Consumer Preferences Selection (To-Be)–Initiate/Revoke MHV=MyHealtheVet ROI=Release of Information VAMC=VA Medical Center 30
  31. 31. Security Management 31
  32. 32. Security Management  Provide control and management of security mechanisms providing security services  Control and provision of enterprise security policy identity and authorizations (IAM) and other security information  Generate configuration data, cryptographic keys  Provide security management for logging of security relevant events, recovery and support for breach reporting 32
  33. 33. Assigning and Provisioning Roles AUDIOLOGIST Anesthetist (CRNA) 022 MD/Allopath 001 Audiologist 309418004 011 Licensed 023 Naturopath (NP) DENTAL Vocational Nurse 024 Pathologist 61207006 002 Dental 26042002 (LVN)/ Licensed 025 Podiatrist 159034004 Hygienist/Registered Practical Nurse (DPM) Dental Hygienist (LPN) 026 Psychiatrist 80584001 (RDH) 012 Nurse Midwife 027 Radiologist 66862007 003 Dentist 106289002 (NM) 028 Physician 004 Oral Surgeon 49993003 013 Nurse 224571005 Assistant (PA) DIETITIAN (RD) Practitioner (NP) 029 Psychologist 59944000 005 Dietitian (RD) 159033005 014 Registered 224535009 030 Social Worker NON-WESTERN Nurse (RN) (LCSW) 106328005 MEDICINE OPTOMETRIST 031 Speech PROVIDERS (OD) Pathologist 006 Certified 015 Optometrist 28229004 Acupuncturist (CA) (OD) 007 Licensed PHARMACIST ASTM E1986-2009 Massage Therapist 016 Pharmacist (LMT)/ Registered 46255001 (Includes 166 Codes) Massage Therapist 017 Pharmacist, 159011008 (RMT) Apothecary NURSE 018 Pharmacist, 159010009 008 Nurse 224569005 Clinical Corresponding 009 Clinical Nurse PHYSICIAN SNOMED CT Code Specialist (CNS) 019 Chiropractor 3842006 106292003 (DC) 010 Clinical 405278004 020 Osteopath (DO) 76231001 Registered Nurse 021 Homeopath 33
  34. 34. VA Identity and Access Management Identity Proofing – Standardized Proofing Process Correlate & Proofing Service BIRLS Store Provider Proofing LMS Repository Veterans Other Sources PIV (SSA, OPM, etc.) VADIR Identity Proofing Process Beneficiaries Verify & Provide PAID Administer Check Capture Identity Identity Identity Identity Information Healthe -Vet Employees VA Trusted Agent Vista MPI Contractors VIC Card E- Issuance Benefits Process ETA/ PIV Card IFCAP Affiliates Veterans & Process Smith, Patricia Beneficiaries PIV E-Auth Employees, Credentialing Contractors, Process & Affiliates BIRLS=Beneficiary Identification and Records LMS=Learning Management System VADIR=VA/DoD Identity Repository Locator System MPI=Master Patient Index VIC=Veteran Identity Care eBenefits=Electronic Benefits PAID=Personal and Accounting Integrated Data VISTA=Veterans Health Information Systems and ETA/IFCAP=Integrated Funds Control, Accounting, System Technology Architecture and Procurement PIV=Personal Identity Verification 34
  35. 35. Access Control Service 35
  36. 36. Consumer Preferences and Policy (CPP) SOA High-Level Framework HITSP TP20 Access Control, TP30 Manage Consent Directives, OASIS XSPA SAML, WS-TRUST HITSP=Healthcare Information Technology TP=Transaction Package Standards Panel XACML=eXtensible Access Control Markup Language OASIS=Organization for the Advancement of Structured Information Standards SAML=Security Assertion Markup Language 36
  37. 37. OASIS XSPA SAML Attribute Assertion Attributes use to enforce security and privacy in an XSPA cross-enterprise exchange of patient data Organization Location SubjectID Purpose of Use Role (S) Role (F) Permission 1 {Action, Object} (User) (POU) Permission 2 {Action, Object} POU Permission 3 {Action, Object} POU Permission …N {Action, Object} Functional Role Described in XSPA Refer to Unique identifier profiles and mutually Structural Role ANSI-INCITS 359-2004 Compliant specific to a given agreed upon by Refer to [HL7-PERM] entity. participating entities. [ASTM E1986-98 (2005)] 37
  38. 38. Implemented Security and Privacy Policies • Demonstrate the Enforcement of Patient Consent Directives • Opt-In / Opt-Out • Deny Access based on Organizations • Deny Access based on Role • Deny Access based on Purpose of Use* • Deny Access to Specific Providers • Mask C32 Results based on Role (future release)** • Mask C32 Results for Specific Providers (future release)** • Mask C32 Results based on data sensitivity (not supported) • Demonstrate the Enforcement of Organizational Policies • Limit access to specific organizations • Limit access during specific hours of the day • Require certain roles based on purpose of use and service requested • Require certain permissions based on purpose of use and service requested * Demonstration only. Current model is single purpose of use **Future capability. Requires ability of Adaptor to accept obligation 37
  39. 39. Current State  Nationwide Health Information Network Connect provides a basic Policy Decision Point (PDP) • Jericho Systems PDP with 12 pre-filled policies • Used in interoperability demonstrations  Can be used to deploy, test, and benchmark any provider’s solution 39
  40. 40. Demonstration 40
  41. 41. Advanced Technology Demonstration Clinicians request patient information with access control enforced by security and privacy policies Can constrain access to many Cross-domain patient types of health care objects Discovery menu Clinical Summary (below) reflects provider domain’s security and privacy policies 41
  42. 42. Advanced Technology Demonstration (Provider) Recent standards allow patients and organizations improved security and privacy control over medical records Patient must opt-In before their record is exchanged Patient can constrain the domains that have access to their records Patient can set general restrictions through use of HL7 Confidentiality Codes Patient can set specific restrictions to specific roles based on Purpose of Use, or Constrain Access of Specific Providers Patient can mask specific portions of the medical record on Role or a Specific Provider 42
  43. 43. Advanced Technology Demonstration (Requester) Clinicians now have access to patients’ records with appropriate access control enforced by both domains. User may assert Purpose of Use as Emergency Treatment. Cross-domain patient Discovery menu 43
  44. 44. XACML Policy Examples - Patient Denial based on subjects ASTM structured role: <Policy PolicyId="urn:oasis:names:tc:xspa:1.0:resource:patient:dissenting:role" RuleCombiningAlgId="urn:oasis:names:tc:xacml:1.0:rule-combining-algorithm:deny- overrides"> Opt-IN <Description>Denies the request from the subject if their role is not permitted by the patient.</Description> - <Target> - <Resources> Blacklisted Organizations - <Resource> - <ResourceMatch MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal"> <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">urn:oasis:names:tc:xspa:1.0:reso Confidentiality/Sensitive Data urce:hl7:type:medical-record</AttributeValue> <ResourceAttributeDesignator AttributeId="urn:oasis:names:tc:xspa:1.0:resource:hl7:type" DataType="http://www.w3.org/2001/XMLSchema#string" /> </ResourceMatch> Selected Provider – Role Based Denial </Resource> Patient Policy </Resources> </Target> - <Rule Effect="Deny" RuleId="urn:oasis:names:tc:xspa:1.0:patient:dissenting:roles:deny"> Selected Provider – Unique ID Based Denial <Description>Evaluates the dissenting-role (if available) against the subject's role.</Description> <Target /> - <Condition> Data Redaction – Provider Role - <Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:and"> - <Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-subset"> <SubjectAttributeDesignator AttributeId="urn:oasis:names:tc:xacml:2.0:subject:role" DataType="http://www.w3.org/2001/XMLSchema#string" /> Data Redaction – Provider Unique Identifier <ResourceAttributeDesignator AttributeId="urn:oasis:names:tc:xspa:1.0:resource:patient:dissenting-role" DataType="http://www.w3.org/2001/XMLSchema#string" /> Demonstrated </Apply> </Apply> Advanced Concepts Genomics </Condition> of Obligations </Rule> </Policy> 44
  45. 45. Demonstration Videos Use Case Examples Patient Privacy – Clinical Data Masking http://www.youtube.com/watch?v=RKbAtmgWGz4 Health Care Organization Policy – Emergency Treatment http://www.youtube.com/watch?v=8aA2Uy6IsQs Protecting the Human Genome http://www.youtube.com/watch?v=A3HtXCu2sa8 Overviews XSPA Technology Overview – Part 1 http://www.youtube.com/watch?v=fQQRwnbg-IE XSPA Technology Overview – Part 2a http://www.youtube.com/watch?v=TvHt9Yz2ekk XSPA Technology Overview – Part 2b http://www.youtube.com/watch?v=3IZvVDNvmiU *Larger videos are available for viewing at: http://www.ascendahealthcare.com/himss2009.html 45
  46. 46. Next Steps  OASIS Reference Model  OASIS Certification  XSPA Profile of WS-Trust  OASIS XACML Ontology  OASIS Privacy Management Reference Model (PMRM)  INCITS (Next Gen RBAC)  ISO Purpose of Use  OASIS XSPA Submission to ITU  SOA PASS Audit  IHE XUA++ 46
  47. 47. Lessons Learned  Need for strong level of assurance between the consumer's identity and health record identity (potentially at multiple locations)  Need national guidance for the use of electronic signature in consent directives  Need for more effort in back office: security and privacy management: role assignment, policy writing, provisioning, etc. 47
  48. 48. Summary 48
  49. 49. HL7 Access Control Service Framework 49
  50. 50. Summary  Core standards are in place and new standards are under development to meet gaps  Vendors have demonstrated the ability to implement: • Multiple vendors demonstrated at several InterOps QUESTIONS? • “no cost” solutions available today from NHIN CONNECT: http://www.connectopensource.org/partners/Jericho% 20Systems%20Corporation  VA is implementing advanced security and privacy capabilities in NHIN projects: • Kaiser Permanente and DoD • Plans to participate in Beacon Communities NHIN=Nationwide Health Information Network 50