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