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

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. Agenda
Introduction
Foundations
Implementation
Demonstration
Summary
2

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. 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. 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. 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. View of Summary of Care Record (C32)
7

8. Foundations
8

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. 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. 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. 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. 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. 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. 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. 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. Implementation
17

18. Reference Model Overview
GW=Gateway
PEP=Policy Enforcement Point
ROI=Release of Information Office
18

19. Consumer Privacy
&
eConsent
19

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. 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. 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. Patient Viewpoint (to-be)
Consent Directive
23

24. VA Forms Supporting eConsent Policies
24

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. 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. Privacy Management
27

28. Release Of Information (ROI) Consent Reconciliation
28

29. 29

30. Consumer Preferences Selection (To-Be)–Initiate/Revoke
MHV=MyHealtheVet
ROI=Release of Information
VAMC=VA Medical Center
30

31. Security Management
31

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. 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. 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. Access Control Service
35

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. 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. 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. 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
40

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. 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. 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. 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. 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. 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. 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
48

49. HL7 Access Control Service Framework
49

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