“Jericho / UT Austin Pilot”

Privacy with Dynamic Patient Review

May 14, 2013

Presented by:David Staggs, JD, CISSP

Jericho Systems Corporation

205/14/2013

Agenda

• Administrative issues • Review and discuss user stories• Review and discuss functional requirements• Review and discuss non-normative system requirements• Initial Gap Analysis (7 issues for discussion)• Review and discuss relevant standards• Questions• POA&M first draft of functional requirements• Call for new members

305/14/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/14/2013

Review of User Stories1. Requestor makes request to a provider for patient data on

eHealth Exchange

2. Provider receives request from eHealth Exchange for patient information, retrieves PCD from PCD repository and applies, returns status to PCD repository

3. PCD repository receives request for PCD from eHealth Exchange partner, returns PCD, accepts status from AC decision

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

5. PCD repository allows management of PCD from healthcare consumer

6. Healthcare consumer manages PCD from PCD repository account, views AC status reports

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/14/2013 5

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 6

Initial 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?)

05/14/2013 7

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/14/2013 8

Standards Guidance (part 1)• Data Segmentation Implementation Guidance (Version 1.0.4)

– Patient Consent Directive §2.8• Uses HL7 DSTU “Recommended”• “DS4P” requirement table and proposed PCD changes

– Querying and Retrieving Consent Location §4.3• Only those data elements consistent with patient privacy

preferences for that type of clinical encounter are shared • Uses IHE XUA and SAML for consent directive location

query• Future pilot: Granular consent preferences (in support of

future Stage 3 Meaningful Use goals)• “XUA is an additional component on the SOAP request that

will carry the query for consent directive location” • SHOULD reference location using the IHE XDS.b Registry

Stored Query transaction (figure, next slide)05/14/2013 9

Query and Response for Location

10/11/2011 10

Standards Guidance (part 2)• Data Segmentation Implementation Guidance (Version 1.0.4)

– Consent Location Response §4.3• Uses OASIS ebxml message

– Does V 4.0 ratified on January 26, 2012 change this?• Provides example RegistryObjectList metadata • Uses IHE XDS Metadata

– Querying and Retrieving Consent Directive §4.4• Uses IHE XUA for the query for consent directive with

identified consent directive location• Audit event will also be recorded by the Document

Repository (no standard specified in §)• Uses an implementation of the XDS.b Retrieve Document

Set transaction (figure, next slide)

05/14/2013 11

Query and Response PCD

1210/11/2011

Standards Guidance (part 3)• Data Segmentation Implementation Guidance (Version 1.0.4)

– Consent Directive Response §4.4• Uses IHE XDS Metadata• Uses HL7 CDA Consent Directive DSTU Metadata

– PCD Vocabulary• §3.8.2 XSPA Purpose of Use (POU) Value Set• Use HL7 Security and Privacy Domain Analysis Model

(DAM)• Gap: no consenter vis. patient support in CDA (Appendix A)• Gap: no CDA R3 support for POU (Appendix B)• Gap: no support for POU in XDS metadata (Appendix C)

• Conformance Statement (Appendix G)– Provides conformance statement tied to section numbers

• Relevant §§ need review and any recommendations reported05/14/2013 13

14

Relevant Standards

• Standards explicitly mentioned in PCD discussion:• ATNA (IHE) – for returned decision, or is it appropriate• CDA r2 (HL7) for returning PCD location• ebxml (OASIS) – in IHE profile but new version ratified• NwHIN specification• SAML (OASIS) – or is IHE profile enough• SOAP (W3C) – or is IHE profile enough• XACML (OASIS) – which version, XACML v3 now standard• PCD (HL7) – just updated last week• XDS.b (IHE)• XSPA (OASIS)• XUA (IHE)• Other: PDU, PIX for patient identity?

05/14/2013

1505/14/2013

Questions?

• For example:• Do we have to use XDS.b, since it is only recommended?• Can we use the repository to field requests for PCD instead of

using ATNA directly or is it even appropriate for returning the release decision information?

• Can we use a lower level standard, such as ad hoc ebxml exchange?

16

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 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/14/2013

17

Call for Pilot Team Members

05/14/2013

Name Role Organization

David Staggs Participant Jericho Systems Corporation

Michael Field Participant UT Austin HIT Lab

1805/14/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

1905/14/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 20

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 21

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 22

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 23

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 24

Potential Gap 2• Discovered XDS.b issues: Participant

05/14/2013 25

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 26

• 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 27

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 28

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 29

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 30

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 31

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 32

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 33

3405/14/2013

Expected Data Flow

Patient’s Provider

Patient

PCD Repository

2nd Requestor

Requestor

B

, = Clinical data

A,B =PCD data

= reporting

3505/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.

3605/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

3705/14/2013

Available Roles

• Holder of PHI that is participating on the eHealth Exchange– Accepts eHealth Exchange compliant request– Retrieves PCD and reports result of request– Synthetic Patient Data is Available

• Requester of PHI that is participating on the eHealth Exchange– Makes eHealth Exchange compliant request

• Repository holding subject’s Patient Consent Directive (PCD)– Transmits PCD to trusted eHealth Exchange requesters– Accepts policy created by subject of shared PHI – Passes HL7-compliant PCD– Displays result of the request transmitted from holder of PHI