Post on 23-Jan-2015
description
transcript
Implementing Advanced Security and Privacy in the Nationwide
Health Information Network (NHIN)
Presentation to Health Information Technology Policy and Standards
Committees
June 17, 2010
John (Mike) Davis David Staggs (SAIC)Department of Veterans Affairs
Agenda
Introduction
Foundations
Summary
2
Implementation
Demonstration
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
Virtual Lifetime Electronic Record
3
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
Business Case for Health Information Sharing
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
Nationwide Health Information Network: San Diego Project
ADI=Access Control Decision InformationCDS=Clinical Data ServicesHDR=Health Data RepositoryMPI=Master Patient IndexNHIN=Nationwide Health Information NetworkPDP=Policy Decision PointPEP=Policy Enforcement PointROI=Release of InformationRPC=Remote Procedure CallWS=Web ServicesXACML=eXtensible Access Control Markup Language
NHIN San Diego Physical Deployment (To-Be)
6
View of Summary of Care Record (C32)
7
8
Foundations
Bottom Up Innovation Within aCoordination Framework
* Interoperability Framework Overview, Douglas Fridsma, MD, PhD, March 24, 2010
*
9
Today’s story is built on the backbone of a coordination framework applied to
security and privacy
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
Patient Privacy Requirements
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
Key Concept: Enforce both Consumer and Enterprise Privacy policy with Common Security Services
11
CPP Access Control System
Mike DavisOffice of Health Information, Security Architect
April 20, 2010
Web of Standards and Related Organizations
HL7
ASTM
•Privilege Management•Structural Roles
ISOvia US TAG
•Privilege Management•Structural and Functional
Roles, +++ANSI-
INCITS
•RBAC Standard•RBAC Implementation
HITSP •Authorization/Privacy Preference standards and Interface Specifications
OASIS
•Standards
CCHIT
•Models/Draft standards
DemosNIST
•FIPS/Special Publications
NHIN •NHIN Updates
IHE •Health care Profiles
•Certification Profiles
CDA=Clinical Document ArchitectureFIPS=Federal Information Processing StandardHL7=Health Level 7HITSP=Healthcare Information Technology Standards PanelNHIN=Nationwide Health Information Network
ISO=International Standards OrganizationNIST=National Institute of Standards & TechnologyOASIS=Organization for the Advancement of Structured Information StandardsRBAC=Role Based Access ControlStructured Information Standards
SAML=Security Assertion Markup LanguageSOA=Service Oriented ArchitectureXACML=eXtensible Access Control Markup Language
12
•SAML, XACML, WS-Trust Profiles
•CDA Consent Directive•Healthcare Functional Role Standard
•SOA Security and Privacy •Security/Privacy Info Models•Privacy Confidentiality Codes
•HL7 Service Aware Architecture
Text Color Key
Key Concept: Meet interoperability requirements with standards, their profiles, and shared information models
13
Leveraging Standards Organizations
1/08 1/101/09
Building Consensus Balloting Standards
ASTM=American Society for Testing and MaterialsDHHS=Department of Health and Human ServicesHL7=Health Level 7HITSP=Healthcare Information Technology NHIN=Nationwide Health Information Network
OASIS=Organization for the Advancement of Structured Information StandardsRBAC=Role Based Access Control
• 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
HIS=Health Information SystemNHIN=Nationwide Health Information NetworkSAML=Security Assertion Markup Language
XACML= eXtensible Access Control Markup Language
Key Concept: Validate approach through interoperability demonstrations (reference implementations and testing)
14
Conduct Interoperability Demonstrations
Health care security policy: Health care specific business rules for application behavior and patient safety
Emergency access: Granting extraordinary access during events involving risk of potential death or injuryClinical roles and permissions: Clinician least privilege
Patient consent directives: Patient driven authorizations to personal health information use and disclosure
15
XSPA Enabled Service Provider
Genome Wide Association Studies ServicePatient’sGenotype
Patient Policy Constrains access to specific AT-RISK SNPs based on characteristics and/or disease grouping
Multiple OrganizationsContribute Findings
New diseases and characteristicsare mapped
PHR ServicePatient has ability to view their Genotype and determine whether to deny access to all or portions of it.
Access Control System
OriginalMapping
Constraints
Visi
bilit
y To
Pat
ient
PEPPDP
PIP
Request for Patients genotype
Response
Assertion Consumption
ClinicalAdaptiveServices
Obligation
ContinuousRe-validation ofPatient Policy Intent
Policy
Trusted/Clinically relevant providers
GWAS
Patient
Provider
Advanced Concept DemonstrationsProtecting the Human Genome - RSA 2010
GWAS=Genome-wide Association StudyPDP=Policy Decision PointPEP=Policy Enforcement PointPHR=Patient Health RecordPIP=Policy Information PointSNIP=Single Nucleotide PolymorphismXSPA=Cross-enterprise Security and Privacy Authorization
16
System and Participant LocationsRSA 2008 – San Francisco, CAOasis XACML InterOp Demonstration – Ditton Manor, London, UKHIMSS 2009 – Chicago, ILRSA 2010 – San Francisco, CA
Global Participants
17
Implementation
18
Reference Model Overview
GW=GatewayPEP=Policy Enforcement PointROI=Release of Information Office
19
Consumer Privacy&
eConsent
20
Sarah Wade Video: http://www.youtube.com/watch?v=wrgHtc5DKIM
Testimony: http://veterans.house.gov/hearings/Testimony.aspx?TID=59828&Newsid=567&Name=%20Sarah%20%20Wade
Wife of a Wounded Warrior
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
21
NHIN=Nationwide Health Information NetworkONC=Office of the National Coordinator
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 availableAuthorize 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 ofencounter, embargoed records (VIP, legal restrictions)
By time (start, end, duration)
By level of participation (opt-in, opt-out, with or withoutadditional classifications, with or without additionalgranularity)
By purpose of use
22
NHIN=Nationwide Health Information NetworkONC=Office of the National CoordinatorVIP=Very Important Person
Fully meets
Partially meets
Does not meet
Patient Viewpoint (to-be)
23
Consent Directive
VA Forms Supporting eConsent Policies
24
25
eConsent Signature Service Framework
SignatureService
Approval
Electronic Forms Repository
1 2
3
Veteran Patient
25
Demographic
Service
User Input
AuthenticationService
Signature is bound to document
Leverages HL7 Consent Directive Analysis Model
Privacy Policy Reference
- allow/disallowaction
- purpose of consent
- effective period- additionalconditions
Information Sender- OrganizationInformation Receiver- Role- Identity
Health Information Affected- Related to a diagnosis- Data Sensitivity- Coverage Type- Type of information (e.g.,results)
Medical Record Reference- Patient Identification- Medical Record Identification
Action Specification- hierarchy of operations applied to information
26
27
Privacy Management
28
Release Of Information (ROI) Consent Reconciliation
29
30
Consumer Preferences Selection (To-Be)–Initiate/Revoke
MHV=MyHealtheVetROI=Release of InformationVAMC=VA Medical Center
31
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
Security Management
Assigning and Provisioning Roles
33
AUDIOLOGIST 001 Audiologist 309418004 DENTAL 002 Dental Hygienist/Registered Dental Hygienist (RDH)
26042002
003 Dentist 106289002 004 Oral Surgeon 49993003 DIETITIAN (RD) 005 Dietitian (RD) 159033005 NON-WESTERN MEDICINE PROVIDERS
006 Certified Acupuncturist (CA)
007 Licensed Massage Therapist (LMT)/ Registered Massage Therapist (RMT)
NURSE 008 Nurse 224569005 009 Clinical Nurse Specialist (CNS) 106292003
010 Clinical Registered Nurse
405278004
Anesthetist (CRNA) 011 Licensed Vocational Nurse (LVN)/ Licensed Practical Nurse (LPN)
012 Nurse Midwife (NM)
013 Nurse Practitioner (NP)
224571005
014 Registered Nurse (RN)
224535009
OPTOMETRIST (OD)
015 Optometrist (OD)
28229004
PHARMACIST 016 Pharmacist 46255001
017 Pharmacist, Apothecary
159011008
018 Pharmacist, Clinical
159010009
PHYSICIAN 019 Chiropractor (DC)
3842006
020 Osteopath (DO) 76231001 021 Homeopath
022 MD/Allopath 023 Naturopath (NP) 024 Pathologist 61207006 025 Podiatrist (DPM)
159034004
026 Psychiatrist 80584001 027 Radiologist 66862007 028 Physician Assistant (PA)
029 Psychologist 59944000 030 Social Worker (LCSW) 106328005
031 Speech Pathologist
ASTM E1986-2009 (Includes 166 Codes)
Corresponding SNOMED CT Code
VA Identity and Access Management
Identity Proofing Process
Identity Proofing – Standardized Proofing Process
Veterans
Beneficiaries
Employees
Contractors
Affiliates
VA Trusted Agent
Administer Identity
CheckIdentity
Verify & Capture Identity
Provide Identity
Information
Other Sources (SSA, OPM, etc.)
Correlate & Store
Proofing Service Provider
Proofing Repository
VIC Card Issuance Process
E-Auth Credentialing
Process
PIV Card Process
BIRLS
E -Benefits
MPI
Healthe-Vet
Vista
PIV
VADIR
PAID
ETA/IFCAP
LMS
Smith,Patricia
PIVEmployees,Contractors,& Affiliates
Veterans &Beneficiaries
34
BIRLS=Beneficiary Identification and Records Locator SystemeBenefits=Electronic BenefitsETA/IFCAP=Integrated Funds Control, Accounting, and Procurement
LMS=Learning Management SystemMPI=Master Patient IndexPAID=Personal and Accounting Integrated Data SystemPIV=Personal Identity Verification
VADIR=VA/DoD Identity RepositoryVIC=Veteran Identity CareVISTA=Veterans Health Information Systems and Technology Architecture
35
Access Control Service
Consumer Preferences and Policy (CPP) SOAHigh-Level Framework
HITSP TP20 Access Control, TP30 Manage Consent Directives, OASIS XSPA SAML, WS-TRUST
36
HITSP=Healthcare Information Technology Standards PanelOASIS=Organization for the Advancement of Structured Information StandardsSAML=Security Assertion Markup Language
TP=Transaction PackageXACML=eXtensible Access Control Markup Language
OASIS XSPA SAML Attribute Assertion
Attributes use to enforce security and privacy in an XSPA cross-enterprise exchange of patient data
37
SubjectID(User)
Purpose of Use(POU) Role (F) Permission 1 {Action, Object}
POU
POU
Unique identifier specific to a given entity.
Described in XSPA profiles and mutually agreed upon by participating entities.
Structural Role Refer to[ASTM E1986-98 (2005)]
Functional RoleRefer toANSI-INCITS 359-2004 Compliant[HL7-PERM]
Role (S)
Permission 3 {Action, Object}
Permission 2 {Action, Object}
Permission …N {Action, Object}
Location
Organization
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
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
Demonstration
41
Advanced Technology Demonstration
Cross-domain patientDiscovery menu
Can constrain access to many types of health care objects
Clinical Summary (below) reflects provider domain’s security and privacy policies
Clinicians request patient information with access control enforced by security and privacy policies
42
Advanced Technology Demonstration (Provider)
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
Recent standards allow patients and organizations improved security and privacy control over medical records
43
Advanced Technology Demonstration (Requester)
Cross-domain patientDiscovery menu
User may assert Purpose of Use as Emergency Treatment.
Clinicians now have access to patients’ records with appropriate access control enforced by both domains.
44
XACML Policy Examples - Patient
Patient Policy
Opt-IN
Blacklisted Organizations
Selected Provider – Role Based Denial
Selected Provider – Unique ID Based Denial
Confidentiality/Sensitive Data
Data Redaction – Provider Role
Data Redaction – Provider Unique Identifier
GenomicsDemonstrated Advanced Concepts of Obligations
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"><Description>Denies the request from the subject if their role is not permitted by the
patient.</Description> - <Target>- <Resources>- <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:resource: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></Resource></Resources></Target>
- <Rule Effect="Deny" RuleId="urn:oasis:names:tc:xspa:1.0:patient:dissenting:roles:deny"><Description>Evaluates the dissenting-role (if available) against the subject's
role.</Description> <Target />
- <Condition>- <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" /> <ResourceAttributeDesignator
AttributeId="urn:oasis:names:tc:xspa:1.0:resource:patient:dissenting-role" DataType="http://www.w3.org/2001/XMLSchema#string" /> </Apply></Apply></Condition></Rule></Policy>
45
Demonstration Videos
Patient Privacy – Clinical Data MaskingHealth Care Organization Policy – Emergency TreatmentProtecting the Human Genome
XSPA Technology Overview – Part 1XSPA Technology Overview – Part 2aXSPA Technology Overview – Part 2b
Use Case Examples
Overviewshttp://www.youtube.com/watch?v=fQQRwnbg-IEhttp://www.youtube.com/watch?v=TvHt9Yz2ekkhttp://www.youtube.com/watch?v=3IZvVDNvmiU
http://www.youtube.com/watch?v=RKbAtmgWGz4http://www.youtube.com/watch?v=8aA2Uy6IsQshttp://www.youtube.com/watch?v=A3HtXCu2sa8
*Larger videos are available for viewing at: http://www.ascendahealthcare.com/himss2009.html
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
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
Summary
HL7 Access Control Service Framework
49
QUESTIONS?
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• “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
50
NHIN=Nationwide Health Information Network