“Jericho / UT Austin Pilot”

Privacy with Dynamic Patient Review

May 21, 2013

Presented by:David Staggs, JD, CISSP

Jericho Systems Corporation

205/21/2013

Agenda

• Administrative issues • Updated data flow diagram• Review of user stories (and goals)• Review of functional requirements• Review of relevant standards• Clinical exchange attributes• PCD exchange attributes• Gap analysis update• Questions• POA&M first draft of functional requirements

305/21/2013

Pilot Administrivia

• This pilot is a community led pilot– Limited support provided by the ONC

• Apurva Dharia (ESAC)• Jeanne Burton (Security Risk Solutions)• Melissa Springer (HHS)

• In conjunction with DS4P bi-weekly return of an All Hands meeting• Access to DS4P Wiki, teleconference, and calendar • Meeting times: Tuesdays 11AM (ET)

– Dial In: +1-650-479-3208Access code: 662 197 169URL:https://siframework1.webex.com/siframework1/onstage/g.php?t=a&d=662197169

405/21/2013

Expected Data Flow (updated)

Custodian of Data being Provided at

Patient

PCD Repository2nd Requestor

1st Requestor

B

, = Clinical data

A,B =PCD data

= audit record

And Subsequent Custodian of Data being Provided at

505/21/2013

Expected Data Flow (1)

Custodian of Data being Provided at

Patient

PCD Repository2nd Requestor

1st Requestor

, = Clinical data

A,B =PCD data

= audit record

605/21/2013

Expected Data Flow (2)

Custodian of Data being Provided at

Patient

PCD Repository2nd Requestor

1st Requestor

, = Clinical data

A,B =PCD data

= audit record

705/21/2013

Expected Data Flow (3)

Custodian of Data being Provided at

Patient

PCD Repository2nd Requestor

1st Requestor

B

, = Clinical data

A,B =PCD data

= audit record

And Subsequent Custodian of Data being Provided at

805/21/2013

Expected Data Flow (4)

Custodian of Data being Provided at

Patient

PCD Repository2nd Requestor

1st Requestor

, = Clinical data

A,B =PCD data

= audit record

And Subsequent Custodian of Data being Provided at

905/21/2013

Expected Data Flow (5)

Custodian of Data being Provided at

Patient

PCD Repository2nd Requestor

1st Requestor

, = Clinical data

A,B =PCD data

= audit record

And Subsequent Custodian of Data being Provided at

1005/21/2013

Review of User Stories1. Requestor makes (two-step) request for patient information to a

“Custodian of Data” across the eHealth Exchange

2. “Custodian of Data” receives request from eHealth Exchange for patient information, retrieves PCD from PCD repository, applies the PCD when deciding if requested data should be released, and returns status to PCD repository • Do we have permission to respond to patient query?• Do we have permission to respond to document query?

3. PCD repository receives request for PCD from “Custodian of Data” across the eHealth Exchange, returns PCD, and accepts status from AC decision • Are we passing the minimum required information in PCD?

4. Stretch: transmitting location of PCD in the returned clinical data

Functional Requirements Summary• Precondition Functional Requirements

– Document format for establishing authentication exchange *– Document format for exchange of repository account holder and

HIO identifiers? (in proxy) *– Document format for clinical data request (NwHIN)

• Functional Requirements – Document format for requesting consent directive– Document format for returning consent directive – Document format for sending result of decision to consent

directive repository • Post-Condition Functional Requirements

– Document format for exchange of repository location and account holder identifier to 2nd requestors associated with data

[based on DS4P IG UC 3 as discussed 30APR2013]* = non-normative05/21/2013 11

DS4P Standards Material• Location of DS4P Standards Inventory:

http://wiki.siframework.org/Data+Segmentation+-+Standards+Inventory

• Location of DS4P Standards Mapping Issues:http://wiki.siframework.org/file/view/Copy%20of%20DataMappingsIssues%2005102012.xlsx/333681710/Copy%20of%20DataMappingsIssues%2005102012.xlsx

• General Standards Source List:http://wiki.siframework.org/file/view/General%20SI%20Framework%20Standards%20Analysis.xlsx/297940330/General%20SI%20Framework%20Standards%20Analysis.xlsx

• Standards Crosswalk Analysis http://wiki.siframework.org/Data+Segmentation+for+Privacy+Standards+and+Harmonization (at bottom of page, exportable)

• Implementation Guidancehttp://wiki.siframework.org/file/view/Data%20Segmentation%20Implementation%20Guidance_consensus_v1_0_4.pdf/416474106/Data%20Segmentation%20Implementation%20Guidance_consensus_v1_0_4.pdf

05/21/2013 12

13

Relevant Standards

• Standards from last week’s discussion:• XCA and/or XDS.b (IHE)• XUA (IHE) – IHE profile includes SAML (OASIS) • XCPD (IHE) – not fully integrated into DS4P IG• ATNA (IHE) – for returned audit record of the release decision• CDA r2 (HL7) – for PCD location in released clinical document

– for format of the directive (includes XACML)• XACML (OASIS) – specifically to PCD• NwHIN specification

Note: PCD (HL7) – just updated last WGM, ongoing reconciliation05/21/2013

14

Clinical Data Exchange• Requestor makes (two-step) request for patient information to a

“Custodian of Data” across the eHealth Exchange • Patient Discovery

• NHIN Patient Discovery Web Service Interface Specification • Document Query

• NHIN Query for Documents Web Service Interface Specification

• Review standards to identify attributes required to meet goals:• Do we have permission to respond to patient query?• Do we have permission to respond to document query?

05/21/2013

15

SAML Attributes• Attribute set presented in an eHealth Exchange document query:

• Contained in SAML envelope included in the XUA profile are:• 1. Subject ID• 2. Subject Organization• 3. Subject Role• 4. Purpose Of Use• 5. Home Community ID• 6. Organization ID• 7. Resource ID (Optional)• 8. National Provider Identifier (Optional)

NHIN Authorization Framework Specification v 3.0 p. 19

05/21/2013

Formal SAML Attributes

05/21/2013 16

Attribute Element Description

xacml:1.0:subject:subject-id person making the request

xspa:1.0:subject:organization name of organization

xacml:2.0:subject:role role of the requester

xspa:1.0:subject:purposeofuse reason for the request

nhin:names:saml:homeCommunityId assigned unique NHIO value

xspa:1.0:subject:organization-id unique ID of the organization

xacml:1.0:resource:resource-id unique patient identifier

xspa:2.0:subject:npi (optional) CMS 10-digit identification number

Cross-Enterprise Security and Privacy Authorization (XSPA) Profile of Security Assertion Markup Language (SAML) for Healthcare V. 1.0 p. 13

17

Map and Gap Policy Attributes

05/21/2013

Attribute Source Description

subject-id XUA (SAML) person making the request

organization XUA (SAML) name of organization

role XUA (SAML) role of the requester

purposeofuse XUA (SAML) reason for the request

patient-id XCPD de-conflicts use of resource-id (new)

action-id N/A policy targeting feature

locality Configured homeCommunityId NHIO value

type XCA (XDS.b) LOINC code for requested document

confidentiality-code XCA (XDS.b) confidentiality-code of document

18

Clinical Data Exchange Goal• Attributes required to meet goals:

• Do we have permission to respond to patient query?• Do we have permission to respond to document query?

• What are the attributes required to retrieve patient consent directive:• patient-id: If multiple resource profile is required need to replace

use of resource-id• action-id: if policy targeting required need new attribute• locality: specify locality in PCD• type: specify type of document in PCD• confidentiality-code: specify confidentiality tag in PCD

05/21/2013

19

PCD Exchange• Impacts due to use of XCPD query

• Specification allows cached XCPD queries for documents• Multiple requesters can use the same XCPD query• How does that effect the requester role and identifiers?

• Variety of XCPD Attributes • Do we have enough to allow properly formed PCD

• Do we meet our goal with attributes:• Are we passing the minimum required information in PCD?• Attributes are required to return the properly scoped PCD

– purposeofuse, organization, patient-id, action-id– Does this goal conflict with XCPD? (next slide)

05/21/2013

Query and Response for Location

05/21/2013 20

Query and Response PCD

2105/21/2013

Gap Analysis• Initial gap analysis for discussion:

1. Single PCD can apply to multiple requests (filter PCD?)

2. Discovered XDS.b issues (XUA “participant” issue)

3. Interoperability of current PCD (HL7 PCD structure)

4. Interoperability of current PCD (XACML payload)

5. Gaps in PCD vocabulary (supporting granularity)

6. Returning repository location in the clinical data (extension)

7. Mapping ATNA protocol to use case (sufficient for user story?)• Newly added issues:

8. More attributes are required in request to PCD repository

9. XCPD caching issue can result in wrong attributes

10. Some attributes are missing or conflated

05/21/2013 22

2305/21/2013

Questions?

• For example:• Must we solve the Multiple Resource Policy issue with resource-

id, since the problem is greatest in data segmentation?• What will be the impact on existing systems if we change the

meaning of resource-id?• Does the need for policy targeting justify creating a new

attribute, and can we create a new attribute with help from OASIS?

24

Plan of Action

• Upon agreement of the participants the POA is: • Identify the elements available from previous DS4P pilots• Scope level of effort, decide on extended scenario• Determine first draft of functional requirements• Review standards available for returning information on requests• Determine any gaps or extensions required in standards• Create XDS.b repository holding PCD• Stand up information holders and requestors• Identify remaining pieces • Document and update IG with results of our experience

05/21/2013

2505/21/2013

DS4P References

• Use Case: http://wiki.siframework.org/Data+Segmentation+for+Privacy+Use+Cases

• Implementation Guide: http://wiki.siframework.org/Data+Segmentation+for+Privacy+IG+Consensus

• Pilots Wiki Page: http://wiki.siframework.org/Data+Segmentation+for+Privacy+RI+and+Pilots+Sub-Workgroup

2605/21/2013

Backup Slides

Precondition Functional Reqs.

• Document format for establishing authentication exchange?– No related requirements

• Document format for exchange of Consent Repository Account Holder and HIO identifiers? (in proxy)– The PCD Repository must create a unique identifier for the

patient that may be used by providers to request the consent directive.

– The PCD Repository must maintain a mapping of patient identifiers when a patient strongly authenticates with a provider.

• Document format for clinical data request– Use NwHIN Exchange format

05/14/2013 27

Functional Requirements• Document format for request to consent directive, including

specifying patient /account number and consent directive repository – Request must include POU, Repository ID, Requestor

• Document format for returning consent directive, including specifying patient HIO identifier– PCD encoded in HL7 Consent Directive format– If no match to parameter (e.g. requestor, POU) no PCD returned– If no PCD returned may use default based on local policy– If PCD returned must be used in deciding release decision– PCD computable in a portable and standards-compliant manner – PCD returned must have only information intended for requestor– PCD returned must support of organization and/or provider ids– PCD returned must support purpose of use and sensitivity codes

05/14/2013 28

Functional Requirements (cont.)• Document format for sending result of release decision to consent

directive repository, including detail appropriate for patient– Patient identifier for the provider– Patient identifier for the requestor– Patient identifier for the repository– Purpose of use for the request– Resource requested– Provider community id– Requestor community id– Requestor identifier (email, NPI, name)– Release decision (permit / deny)– Basis for the decision (jurisdictional policy, patient consent, etc.)

• Review ATNA for usability

05/14/2013 29

Post Condition Functional Reqs.

• Document format for exchange PCD information to 2nd requestors associated with data exchanged with 1st requester (provenance) – Use HL7 format consistent with clinical data returned– PCD repository location and account holder identifier

05/14/2013 30

System Functional Reqs.• Functional requirements recorded for use in demonstration (non-normative)

– PCD repository must index the audit logs received so that patients may view, filter, and search on the access attempts

– PCD repository receives request for new account from healthcare consumer, possibly involving providers

– PCD repository must maintain account credentials for the patient– PCD repository must maintain a mapping of patient identifiers when a

patient strongly authenticates with a provider– PCD repository allows management of PCD from healthcare consumer– Healthcare consumer manages PCD from PCD repository account,

views response decision status reports – PCD repository must support creating, updating, and deleting consents – PCD repository must support Opt-In/Opt-Out/Opt-In With

Restrictions/Opt-Out with Exceptions

05/14/2013 31

Potential Gap 1

• Single PCD can apply to multiple requests– Consider opt-in, opt-opt, opt-in with restrictions, opt-opt with

exceptions• What should happen if requester can not support level of granularity

– Consider opt-opt with exceptions• If consumer lists, e.g., mental health clinic and general practitioner,

passing the exception list conveys too much information

– Multiple PCDs infeasible; create on the fly based on request?

05/14/2013 32

Potential Gap 2• Discovered XDS.b issues: Participant

05/14/2013 33

CDA Component within Consent Directive

CDA Consent Directive Implementation Guidelines and Conformance Criteria

Cardinality Optionality

structuredBody Every CDA Consent Directive MUST define a structured body that represents the patient consent in a machine-readable format.

1 Required

Consent Directive Details

Informant Refer to section 3.2.1.1 – Consent Directive Entry in the HL7 CDA Consent Directive DSTU.This implementation guide adopts CONF-CD-19 as conformance criteria for this section of the consent directive.

1 Required

Participant Refer to section 3.2.1.1 – Consent Directive Entry in the HL7 CDA Consent Directive DSTU.This implementation guide adopts CONF-CD-20, CONF-CD-21, CONF-CD-22, and CONF-CD-23 as conformance criteria for this section of the consent directive.The role code that is used in this section MUST be the same as the role code used in the IHE XUA++.

1..N Required

From: “Data Segmentation Implementation Guidance” v. 1.0.4 (3/20/2012), p. 48

Potential Gap 2 (cont.)

• 3.42.2 Use Case Roles

05/14/2013 34

• Actor: Document Repository or Integrated Document Source/Repository

• Role: A document storage system that submits document metadata to a Document Registry.

• Actor: Document Registry• Role: A document indexing system that receives and stores

document metadata.

From: Rev. 9.0 Final Text – 2012-08-31 146 Copyright © 2012 IHE International, Inc.

Informative Note: PCDs

05/14/2013 35

PCD Format PCD Header

PCD Body

• Structure of the PCD

Potential Gap 3

• Interoperability of current PCD (PCD structure)– Large amount of metadata included in the HL7 PCD

• Specification includes many optional elements that might affect the ability to accept different PCD implementations

• No known Schematron available– Possibly too ambiguous to be interoperable– Currently in ballot at HL7 Working Group Meeting (WGM)

• We have provided comments

05/14/2013 36

Potential Gap 4

• Interoperability of current PCD (XACML)– XACML can be included in the HL7 PCD

• eXtensible Access Control Markup Language is well-defined and interoperable

• Vocabulary must be agreed upon for semantic interoperability and correct decisions made on passed attributes

• No known XACML profile for PCD repository exchange of a PCD with XACML in payload

05/14/2013 37

Potential Gap 5

• Gaps in PCD vocabulary– PCD must support the four possible consent models

• DS4P profile must define semantics of: – opt-in, – opt-opt, – opt-in with restrictions, – opt-opt with exceptions

05/14/2013 38

Potential Gap 6

• Returning repository location in the clinical data– Patient discovery queries are in addition to registration with

specific providers through, e.g. a repository serving as a proxy– Special considerations for use of ATNA

05/14/2013 39

Potential Gap 6 (cont.)

• Should the provider query the PCD repository to decide if they can respond to the patient discovery queries

• Subsequently the provider must query the PCD repository to decide if the request for release of patient’s EHR will be allowed– When data is exchanged with the requester, either the ATNA

endpoint or the PCD repository location and account identifier be included in the clinical document

– CDA header example (ATNA endpoint):• <element name="consent"

type="{urn:hl7‑org:v3}POCD_MT000040.Consent"/>

• Explore encoding ATNA audit endpoint information in the CDA information

05/14/2013 40

Potential Gap 7

• Mapping ATNA protocol to use case – ATNA protocol is based on syslog and consists of an XML

payload• Does the ATNA schema has the required data for our use

case for directly interfacing with requesters:

05/14/2013 41

4205/14/2013

Scope of the Pilot

• 1.      Define the exchange of HL7 CDA-compliant PCD between a PCD repository and a provider evaluating that includes a report on the outcome of the request back to the healthcare consumer. 

• 2.      Additional goal: use of identifiers that can uniquely identify the healthcare consumer and PCD repository used to report the outcome of the request back to the healthcare consumer by healthcare consumer’s provider and subsequent EHR custodians.

• 3.      Stretch goal: use of the PCD repository as a proxy allowing direct authentication by the healthcare consumer to the provider, subsequently reducing correlation errors.

4305/14/2013

Secondary Goals of the Pilot

• Exchange and enforce privacy metadata to ensure proper policy-based disclosure and redisclosure of PHI

• Accept and display reports from information owners on access control decisions for requests for the patient’s PHI

• Create a token passing scheme that facilitates secondary use reporting

• Demonstrate dynamic reporting of access to a patient’s PHI and their ability to change their PCD using their PCD central repository

44

Call for Pilot Team Members

05/14/2013

Name Role Organization

David Staggs Participant Jericho Systems Corporation

Michael Field Participant UT Austin HIT Lab