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