Presentation is loading. Please wait.

Presentation is loading. Please wait.

Cross Community Access Profile Karen Witting IBM Co-chair ITI technical committee.

Similar presentations


Presentation on theme: "Cross Community Access Profile Karen Witting IBM Co-chair ITI technical committee."— Presentation transcript:

1 Cross Community Access Profile Karen Witting IBM Co-chair ITI technical committee

2 Outline Vision – 2006 IHE White Paper on Cross Community Information Exchange Scope of Cross Community Access profile Transaction Diagram Actors and Transactions Process Flow Implications to Document Consumers Open issues Future work

3 Cross Community Information Exchange White Paper Developed concept of “community” and exchange of health information across communities Released in August 2006 Available on www.ihe.net under “Resources – Technical Frameworks” then select IT Infrastructurewww.ihe.net Defines two types of cross community information exchange: Hierarchical Lateral Defines a set of profiles which are useful in both types of community information exchanges. The first step in realizing the vision of this whitepaper is the Cross Community Access profile

4 Community Network B Document Registry Practice Clinic Hospitals Hospital Diag Test Other Practice Hospital Community Network C Document Registry Practice Clinic Hospitals Hierarchical Exchange From Cross Community Information Exchange White Paper IHE transactions (XCA and future)  Gateways query and retrieve records  National or Regional Networks not required to be IHE-based – could do the mapping to & from IHE Transactions in the Gateway Gateway National Network A Non-IHE National EHR Which community holds records for a patient ?

5 Community Network B Document Registry Practice Clinic Hospitals Hospital Diag Test Other Practice Hospital Community Network C Document Registry Practice Clinic Hospitals Lateral Exchange From Cross Community Information Exchange White Paper IHE transactions (XCA and future)  No shared resource to map patients to communities  Identification of communities done through attributes, or other configuration.  Identification of patient id through lateral transactions rather than hierarchical management Gateway National Network A Non-IHE National EHR Which communities have specific attributes CommunitySearchService

6 Community Network B Document Registry Practice Clinic Hospitals Hospital Diag Test Other Practice Hospital Community Network C Document Registry Practice Clinic Hospitals The largest multi-vendor prototype ever built ! HIMSS Interoperability Showcase The largest multi-vendor prototype ever built ! 18 edge systems 4 infrastructure systems 5 edge systems 4 infrastructure systems 13 edge systems 3 infrastructure systems 3 infrastructure Systems Community Network A Document Registry Practice Clinic Hospitals Diag Test Hierarchical Patient Indexing

7 Cross Community Access Scope Sharing of documents across communities Re-use of XDS.b transactions. Document Consumer consistency –Requirements of Document Consumer are the same as for local document query and retrieval Out of scope: –How to identify which communities to interact with –How to identify the patient id to use when interacting

8 XCA Transaction Diagram

9 Cross Community Access Actors and Transactions Document Consumer –Supports Registry Stored query and Retrieve Document Set –New requirement: propagation of the homeCommunityId requirement Applies to XDS.a, XDS.b and XCA profiles Initiating Gateway –On behalf of internal actors, initiates all transactions leaving the community –Receives Registry Stored Query and Retrieve Document Set from Document Consumer –Propagates transaction to local Document Registry and Repository, if appropriate –Propagates transaction to other communities by contacting their Receiving Gateway and sending: Cross Gateway Query and Cross Gateway Retrieve Receiving Gateway –Single contact point for all transactions coming in to the community. –Propagates incoming transactions to local actors New Transactions: –Cross Gateway Query: from Initiating Gateway to Receiving Gateway, mimics Registry Stored Query –Cross Gateway Retrieve: from Initiating Gateway to Receiving Gateway, mimics Retrieve Document Set

10 XDS Registry Initiating Gateway Document Consumer XCA Process Flow XDS Registry XDS Repository RSQ XDS Registry RSQ XGQ XDS Repository Community A Community B Community C Receiving Gateway Receiving Gateway XGQ RSQ RDS RSQ – Registry Stored Query XGQ – Cross Gateway Query RDS – Retrieve Document Set XGR – Cross Gateway Query RDS XGR RDS

11 homeCommunityId NEW: requirement for all Document Consumer implementers (XDS.a, XDS.b, XCA) SHALL propagate homeCommunityId value to subsequent Registry Stored Query (XDS.a & XDS.b) or Retrieve Document Set (XDS.b only) transactions. homeCommunityId corresponds to the ‘home’ attribute defined on the relevant ebRIM 3.0 elements. Example: homeCommunityId value is unique and opaque Used by Initiating Gateway to map to the originator of the data New optional parameter to stored queries which do not include a patient id. Optional parameter on the new Retrieve Document Set transaction

12 Processing of “home” (homeCommunityId) Initiating GW Receiving GW Home ‘a’ Home ‘b’ Doc Consumer Home ‘a’ GW Address Home ‘a’ GW Address Home ‘b’ GW Address Home ‘a’ Home ‘b’ Query by patient id Query by uuid Home ‘a’ Home ‘b’ Retrieve GW Address Home ‘b’ @ GW Address

13 Considerations for Asynchronous Communications Asynchronous Transactions –Extensively discussed –Left as an open issue –Complicates the transactions to a significant extent –Unclear how compelling the need is Support large volumes of data Support significant delay in response Support messaging systems preferences for asynch mode

14 Future Work Support Patient Identification Management –Appendix in supplement presents some possible solutions Support Locator Service (PIX+, RLS, RLUS type service)

15


Download ppt "Cross Community Access Profile Karen Witting IBM Co-chair ITI technical committee."

Similar presentations


Ads by Google