1 / 48

“ Jericho / UT Austin Pilot”

“ Jericho / UT Austin Pilot”. Privacy with Dynamic Patient Review. Presented by: David Staggs, JD, CISSP Jericho Systems Corporation. Agenda. Administrative issues Pilot scope Data flow diagram ATNA ITI Guidance NHIN IHE XCA ITI Transactions NHIN IHE XCPD ITI Transactions

keitha
Download Presentation

“ Jericho / UT Austin Pilot”

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. “Jericho / UT Austin Pilot” Privacy with Dynamic Patient Review Presented by: David Staggs, JD, CISSP Jericho Systems Corporation

  2. Agenda • Administrative issues • Pilot scope • Data flow diagram • ATNA • ITI Guidance • NHIN IHE XCA ITI Transactions • NHIN IHE XCPD ITI Transactions • Proposed approach • UT student involvement • Questions • POA&M

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

  4. Scope of the Pilot • 1.      Define the exchange of HL7 CDA-compliant PCD between a data custodian and a PCD repository 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.

  5. Expected Data Flow (updated) , = Clinical data A,B = PCD data = audit record  1st Requestor And Subsequent Custodian of Data being Provided at  B Custodian of Data being Provided at   PCD Repository 2nd Requestor Patient

  6. Recording Release Decisions • Where should our audit record by generated? • Concept of the Audit Trail • “audit records must capture event descriptions for the entire process, not just for individual components” • How do we specify what is sent where? • Identify the RFC-3881 expressible concepts • Identify the appropriate PCD repository • Repository can be different between patients • Have ability to send to the repository • How much information should be sent?

  7. ATNA Basics • Audit Trail and Node Authentication (ATNA): • patient information confidentiality • data integrity • user accountability • Network communications only between secure nodes • local user authentication • bi-directional certificate-based node authentication • audit trail provides accountability • Example transactions: • ITI-19: Node Authentication, • ITI-20: Record Audit Event

  8. ATNA Details • ITI Example Transactions: • Node Authentication (ITI-19) • Record Audit Event (ITI-20) • Secure Communications: • Transport Layer Security (RFC 2246) • Audit Log Transport: • Syslog Protocol (RFC 5424) • Transmission of Syslog Messages over TLS (RFC 5425) • Audit Log Messages: • Security Audit and Access Accountability Message XML Data Definitions for Healthcare Applications (RFC 3881)

  9. ITI Guidance • IHE IT Infrastructure Technical Framework (ITI TF) • IT infrastructure domain (ITI) guidance: • Volume 1 - Section 9 • principles • integration profile • trigger events • Volume 2 - Sections 3.19, 3.20, … • describes details of transactions • For example, 3.20 equals Record Audit Event (ITI-20)

  10. ITI Guidance, Volume 1 • Volume 1 - Section 9: • principal objective of the Audit Trail mechanism is to track data access to PHI • recommends using RFC-3881 format, and reporting only events that it can describe • IHE profile does not specify any audit reporting functions or formats • specifies Syslog Protocols as the mechanism for logging audit record messages to the audit record repository • new applications domains may have their own extended vocabularies • Audit Trail and Node Authentication Integration Profile - actors and transactions (next slide)

  11. ATNA Actors and Transactions Audit Trail and Node Authentication Integration Profile - Actors and Transactions; IHE IT Infrastructure Technical Framework, Vol. 1, Table 9.4-1

  12. ITI Guidance, Volume 2 • Volume 2 (ITI-1 through ITI-28) - Sections 3.19, 3.20: • Section 3.19 • trust relationship between two nodes in a network • Section 3.20 • communicate with the audit record repository • uses the syslog protocol (RFC 5424) over TLS (RFC 5425) or UDP (RFC 5426) • record of actions performed on data by users • description of RFC-3881 format • defines terminology for use in IHE extensions

  13. NHIN IHE XCA NHIN Query for Documents Web Service Interface Specification XCA Cross Gateway Query transaction [ITI-38] as the protocol for query for documents NHIN Retrieve Documents Web Service Interface Specification XCA Cross Gateway Retrieve transaction [ITI-39] as the protocol for retrieving documents

  14. What’s Relevant to J-UT? • Transactions from the diagram: • XCA Query for Documents (ITI-38) • XDS.bDocument Query (ITI-18) • XCA DocumentRetrieve (ITI-39) • XDS.b Document Retrieve (ITI-43) • and • XCPD (ITI-55)

  15. Document Query (ITI-38), part 1 • XCA Query for Documents (ITI-38) Section 3.38.4.1.4 • The Initiating Gateway: • If receiving a Registry Stored Query transaction from a Document Consumer, see ITI TF-2a: 3.18.5.1.2. • In addition, shall audit the Cross Gateway Query as if it were a Document Consumer, see ITI TF-2a: 3.18.5.1.1. • In addition, if interacting with a local Document Registry, shall audit as if it were a Document Consumer, see ITI TF-2a: 3.18.5.1.1.

  16. Document Query (ITI-38), part 2 • XCA Query for Documents: Responding Gateway: • Shall audit the Cross Gateway Query as if it were a Document Registry, see ITI TF-2a: 3.18.5.1.2. • Where in the CONNECT stack is this done? • In addition, if interacting with a local Document Registry, shall audit as if it were a Document Consumer. See ITI TF-2a: 3.18.5.1.1.

  17. Document Query (ITI-39), part 1 • Document Query (ITI-39) Section 3.39.4.1.4 • The Initiating Gateway: • If receiving a Retrieve Document Set transaction from a Document Consumer, shall audit as if it were a Document Repository, see ITI TF-2b: 3.43.6. • In addition, shall audit the Cross Gateway Retrieve as if it were a Document Consumer, see ITI TF-2b: 3.43.6. • In addition, if interacting with a local Document Repository, shall audit as if it were a Document Consumer, see ITI TF-2b: 3.43.6. • One audit record per Document Repository contacted.

  18. Document Query (ITI-39), part 2 • The Responding Gateway: • Shall audit the Cross Gateway Retrieve as if it were a Document Repository, see ITI TF-2b: 3.43.6. • Where in the CONNECT stack is this done? • In addition, if interacting with a local Document Registry, shall audit as if it were a Document Consumer, see ITI TF-2a: 3.18.5.1.1.

  19. Document Query (ITI-18), part 1 • Document Query (ITI-18) • The Initiating Gateway: • If receiving a Registry Stored Query transaction from a Document Consumer, see ITI TF-2a: 3.18.5.1.2. • In addition, shall audit the Cross Gateway Query as if it were a Document Consumer, see ITI TF-2a: 3.18.5.1.1. • In addition, if interacting with a local Document Registry, shall audit as if it were a Document Consumer, see ITI TF-2a: 3.18.5.1.1.

  20. Document Query (ITI-18), part 2 • The Responding Gateway: • Shall audit the Cross Gateway Query as if it were a Document Registry, see ITI TF-2a: 3.18.5.1.2. • In addition, if interacting with a local Document Registry, shall audit as if it were a Document Consumer. See ITI TF-2a: 3.18.5.1.1.

  21. Document Query (ITI-43), part 1 • Document Query (ITI-43) • The Initiating Gateway: • If receiving a Retrieve Document Set transaction from a Document Consumer, shall audit as if it were a Document Repository, see ITI TF-2b: 3.43.6. • In addition, shall audit the Cross Gateway Retrieve as if it were a Document Consumer, see ITI TF-2b: 3.43.6. • In addition, if interacting with a local Document Repository, shall audit as if it were a Document Consumer, see ITI TF-2b: 3.43.6. • One audit record per Document Repository contacted.

  22. Document Query (ITI-39), part 2 • The Responding Gateway: • Shall audit the Cross Gateway Retrieve as if it were a Document Repository, see ITI TF-2b: 3.43.6. • In addition, if interacting with a local Document Registry, shall audit as if it were a Document Consumer, see ITI TF-2a: 3.18.5.1.1.

  23. NHIN IHE XCPD from “IHE ITI Technical Framework Supplement – Cross-Community Patient Discovery (XCPD)”

  24. XCPD Integration Profile eHealth Exchange uses Cross Gateway Patient Discovery [ITI-55] from “IHE ITI Technical Framework Supplement – Cross-Community Patient Discovery (XCPD)”

  25. XCPD (ITI-55, 56) • Cross Gateway Patient Discovery [ITI-55] • 3.55.5.1 Security Audit Considerations • 3.55.5.1.1 Initiating Gateway audit message • 3.55.5.1.2 Responding Gateway audit message • Patient Location Query [ITI-56] (not supported by eHealth Exchange) • 3.56.5.1 Security Audit Considerations • 3.56.5.1.1 Initiating Gateway audit message • 3.56.5.1.2 Responding Gateway audit message

  26. ATNA: XCPD

  27. ATNA: Document Query

  28. ATNA: Document Retrieve

  29. Implementation Approach • EXTEND existing ATNA messages to include consent metadata • XCPD Supplement 3.55.5.1.2 Responding Gateway audit message • TF_VOL2a 3.18.5.1.2: Document Registry audit Message • TF_VOL2b 3.43.6.1.2 Document Repository audit message

  30. Privacy Extension Define additional ParticipantObjectDetail for consent metadata

  31. Document Retrieve Extension

  32. Document Retrieve Extension (2)

  33. UT Student Contribution • "Definition of Data Sets Exchanged During Request for Patient Consent Directive (PCD) on e-Health Exchange" • UT Students: Johnny Bender and Adrian Tan • Initial enquiry: • HCS rules for assigning and rendering security labels within the CDA document entry. • Findings: • HCS rules for assigning/rendering security labels in CDA document entry/header/sections: • Encode and store clinical elements/metadata • Rule for a tagged entry: • A tagged entry must have a content element identifier (otherwise optional in CDA).

  34. UT Student Contribution (2) • Non-sensitive coded attributes: • Not required to reference associated content element identifiers. • Narrative consent not required to have content element identifiers. • Tagged entry reference to narrative content: • CDA derived (coded) content element identifier: Must reference narrative content source. • Original (non-coded) narrative content element identifier: Must be encoded to assign security labels. • Tagged entry attribute reference to narrative content: • The attribute of the originalText must reference narrative content element.

  35. Pilot Timeline • General Timeline, conditioned on agreement of stakeholders

  36. Questions? • For example: • How many audit records should be sent per document request? • What information should be in the audit record sent from the custodian? • Should we audit events within the PCD repository, too?

  37. 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 • Stand up information holders and requestors • Create XDS.b repository holding PCD • Identify remaining pieces • Document and update IG with results of our experience

  38. 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 Guidance http://wiki.siframework.org/file/view/Data%20Segmentation%20Implementation%20Guidance_consensus_v1_0_4.pdf/416474106/Data%20Segmentation%20Implementation%20Guidance_consensus_v1_0_4.pdf

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

  40. Backup Slides

  41. Expected Data Flow (updated) , = Clinical data A,B = PCD data = audit record  1st Requestor And Subsequent Custodian of Data being Provided at  B Custodian of Data being Provided at   PCD Repository 2nd Requestor Patient

  42. Expected Data Flow (updated) Clinical exchange # , = Clinical data A,B = PCD data = audit record 1st Requestor And Subsequent Custodian of Data being Provided at  B Fetch PCD Fetch PCD Custodian of Data being Provided at  Clinical exchange #  Send audit Send audit PCD Repository 2nd Requestor Patient

  43. Expected Data Flow (1) , = Clinical data A,B = PCD data = audit record  1st Requestor Custodian of Data being Provided at  PCD Repository 2nd Requestor Patient

  44. Expected Data Flow (2) , = Clinical data A,B = PCD data = audit record  1st Requestor Custodian of Data being Provided at  PCD Repository 2nd Requestor Patient

  45. Expected Data Flow (3) , = Clinical data A,B = PCD data = audit record 1st Requestor And Subsequent Custodian of Data being Provided at  B Custodian of Data being Provided at   PCD Repository 2nd Requestor Patient

  46. Expected Data Flow (4) , = Clinical data A,B = PCD data = audit record 1st Requestor And Subsequent Custodian of Data being Provided at  Custodian of Data being Provided at   PCD Repository 2nd Requestor Patient

  47. Expected Data Flow (5) , = Clinical data A,B = PCD data = audit record 1st Requestor And Subsequent Custodian of Data being Provided at  Custodian of Data being Provided at  PCD Repository 2nd Requestor Patient

  48. Expected Data Flow (updated) , = Clinical data A,B = PCD data = audit record  1st Requestor And Subsequent Custodian of Data being Provided at  B Custodian of Data being Provided at   PCD Repository 2nd Requestor Patient

More Related