Jericho ut austin pilot
This presentation is the property of its rightful owner.
Sponsored Links
1 / 34

“ Jericho / UT Austin Pilot” PowerPoint PPT Presentation


  • 53 Views
  • Uploaded on
  • Presentation posted in: General

“ Jericho / UT Austin Pilot”. Privacy with Dynamic Patient Review. Presented by: David Staggs, JD, CISSP Jericho Systems Corporation. Agenda. Administrative issues Updated data flow diagram Functional requirements summary Issues from previous call Running observations

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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Jericho ut austin pilot

“Jericho / UT Austin Pilot”

Privacy with Dynamic Patient Review

Presented by:

David Staggs, JD, CISSP

Jericho Systems Corporation


Agenda

Agenda

  • Administrative issues

  • Updated data flow diagram

  • Functional requirements summary

  • Issues from previous call

  • Running observations

  • Review of XCA vs. XDS

  • Mapping ATNA to our use case

  • Gap analysis summary

  • Review of relevant standards

  • Questions

  • POA&M


Pilot administrivia

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


Expected data flow updated

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


Functional requirements summary

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-normative


Issues from previous call

Issues from Previous Call

  • Issues inherent in embedding PCD repository information

    • Embedding PCD Repository information in clinical documents

    • Providing a pointer to location is static (even if PCD dynamic)

    • Can we meet goal by embedding query information?

  • Subsequent Custodian of Data should multicast query for PCD

    • Provide broad information, specific to organization

    • Provide unique PCD identifier in clinical document

  • Cover new use cases

    • If PCD not found, multiple PCD found, or new repository

  • Build on previous pilots

    • Most recent PCD, no de-confliction step considered


  • Running observations

    Running Observations

    • XCA simplifies back-end implementation

      • Although XDS.b is described in IHE documents, not required

      • Many current examples of eHealth Exchange use XCA

  • On-Demand Documents Supplement

    • NHIN has adopted the use of On-Demand Documents

    • Updates XCA to use dynamically created documents

    • Allows registration of content dynamically assembled

  • Audit record from custodian of release decision

    • Previous pilots used unique message ID, not externalized

  • Creation of PCD on demand

    • If PCD has sensitive data, should not give all information


  • Nhin ihe xca

    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


    Pcd reference information

    PCD Reference Information

    • How a PCD is referenced depends on your environmental assumptions

      • XCA takes care of patient id mappings and lookups of remote service endpoint URLs

      • Using XCA, reference of PCD is by home community ID

      • Using plain XDS.b, reference of PCD is by patient ID and service endpoint URL

    • What is the impact of clinical document exchange architectures?


    Architecture differences

    Architecture Differences

    • eHealth Exchange using CONNECT

      • Uses XCA for document queries

      • Communities are connected with a service registry

        • If you are not in the service registry, you don’t exist

      • Works well when you don’t know who has the information

      • Typically requires MPI, XCA implementation, and a service registry.

        • Complex and expensive to manage the supporting systems


    Architecture differences cont

    Architecture Differences (cont)

    • DIRECT

      • Uses XDR and XDM instead of XCA.

        • i.e. either a direct SOAP web service call over HTTPS (XDR) or over S/MIME (XDM)

      • Works great when you are pushing a record to someone you know

      • Requires minimal supporting software and systems

      • Summary

      • What is the appropriate standard for exchanges with the PCD repository: XCA – or – XDR & XDM?


    Pcd reference table

    PCD Reference Table


    Using atna

    Using ATNA

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


    Gap analysis

    Gap Analysis

    • Initial gap analysis for discussion:

      • Single PCD can apply to multiple requests (filter PCD?)

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

      • Interoperability of current PCD (HL7 PCD structure)

      • Interoperability of current PCD (XACML payload)

      • Gaps in PCD vocabulary (supporting granularity)

      • Returning repository location in the clinical data (extension)

      • Mapping ATNA protocol to use case (sufficient for user story?)

    • Newly added issues:

      • More attributes are required in request to PCD repository

      • XCPD caching issue can result in wrong attributes ‡

      • Some attributes are missing or conflated


    Relevant standards

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

      • ODD (IHE) - On-Demand Documents (Trial) Supplement

        Note: PCD (HL7) – just updated last WGM, will re-ballot


    Ds4p standards material

    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


    Questions

    Questions?

    • For example:

      • Must we multicast to everyone on eHealth Exchange for a PCD?

      • Can we retrieve PCD from a patient’s PCD repository if we have that information?


    Plan of action

    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


    Ds4p references

    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


    Backup slides

    Backup Slides


    Query and response for location

    Query and Response for Location


    Query and response pcd

    Query and Response PCD


    Expected data flow updated1

    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


    Expected data flow updated2

    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


    Expected data flow 1

    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


    Expected data flow 2

    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


    Expected data flow 3

    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


    Expected data flow 4

    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


    Expected data flow 5

    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


    Expected data flow updated3

    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


    Informative note pcds

    Informative Note: PCDs

    • Structure of the PCD

    PCD Header

    PCD Format

    PCD Body


    Scope of the pilot

    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.


    Secondary goals of the pilot

    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


    Call for pilot team members

    Call for Pilot Team Members


  • Login