“ jericho / ut austin pilot” privacy with dynamic patient review may 7, 2013 presented by: david...
TRANSCRIPT
“Jericho / UT Austin Pilot”
Privacy with Dynamic Patient Review
May 7, 2013
Presented by:David Staggs, JD, CISSP
Jericho Systems Corporation
205/07/2013
Agenda
• Administrative issues • Review and discussion of user stories• Review and discuss functional requirements
– Precondition functional requirements– Functional requirements– Post-condition functional requirements– System requirements (for demonstration capability)
• Initial Gap Analysis (7 issues for discussion)• Questions• POA&M first draft of functional requirements• Call for new members
305/07/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/07/2013
Review of User Stories
1. 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
• 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]05/07/2013 5
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/07/2013 6
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/07/2013 7
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/07/2013 8
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/07/2013 9
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/07/2013 10
Initial Gap Analysis• Initial gap analysis for discussion:
1. Single PCD can apply to multiple requests
2. Discovered XDS.b issues
3. Interoperability of current PCD (PCD structure)
4. Interoperability of current PCD (XACML)
5. Gaps in PCD vocabulary
6. Returning repository location in the clinical data
7. Mapping ATNA protocol to use case • Guidance available in§17 Dataset Considerations discussion of “Data
Segmentation for Privacy Initiative: Use Case Development and Functional Requirements for Interoperability Data Segmentation for Privacy Use Case” (3/12/2012) and “Data Segmentation Implementation Guidance” v. 1.0.4 (3/20/2012).
05/07/2013 11
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/07/2013 12
Potential Gap 2• Discovered XDS.b issues: Participant
05/07/2013 13
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/07/2013 14
• 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/07/2013 15
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/07/2013 16
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 synaptic interoperability and correct decisions made on passed attributes
• No known XACML profile for PCD repository exchange of a PCD with XACML in payload
05/07/2013 17
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/07/2013 18
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/07/2013 19
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/07/2013 20
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/07/2013 21
2205/07/2013
Questions?
• For example:• Do we have to use ATNA?• Can we use the repository to field requests for PCD instead of
using ATNA directly?
23
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/07/2013
24
Call for Pilot Team Members
05/07/2013
Name Role Organization
David Staggs Participant Jericho Systems Corporation
Michael Field Participant UT Austin HIT Lab
2505/07/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/07/2013
Backup Slides
2705/07/2013
Expected Data Flow
Patient’s Provider
Patient
PCD Repository
2nd Requestor
Requestor
B
, = Clinical data
A,B =PCD data
= reporting
2805/07/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.
2905/07/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
3005/07/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