100 likes | 325 Views
Agenda. Overview of use cases collected so far Goal: Add missing use cases if any Comparison of use cases Goal: Understand the distinction between the use cases Detail review of each use case Goal: Scope the work to most important and common set of functions needed to satisfy the use cases.
E N D
Agenda • Overview of use cases collected so far • Goal: Add missing use cases if any • Comparison of use cases • Goal: Understand the distinction between the use cases • Detail review of each use case • Goal: Scope the work to most important and common set of functions needed to satisfy the use cases.
Use Cases • Hierarchical top-most PIX – group Initiating Gateway with PIX Consumer. • One time pt-to-pt transfer of specific patient information – use PDQ like transaction prior to every Cross Gateway Query. • Tightly connected – once a patient identifier/location is shared any changes to that patient demographics (updates, merge, link, remove) are communicated to all sites known to know that patient. • Loosely connected – once a patient identifier/location is shared changes to that patient might be shared with other sites. • Shared patient identifier (national patient ID) – still requires identification of patient locations • Pseudonym use – community acquires a pseudonym specific to the community and patient requested for restricted use.
Meta-Community using existing IHE Profiles Meta-Community Topmost PIX Server Community B (1) (1) Patient Identity Source (1) (3) XDS Registry Responding Gateway Community A Initiating Gateway Patient Identity Source (4) XDS Repository (4) (4) XDS Registry Community C (6) Patient Identity Source (2) (6) (6) (5) Responding Gateway XDS Registry XDS Repository Document Consumer XDS Repository
On-time point-to-point - Easy to implement - Simple - Query and forget - Point-to-Point Discovery only - Not Scalable - Not High-performance - No Update Management Community A PDQ Query Community B Initiating Gateway Responding Gateway
Tightly-coupled Use Case Community B - Scalable - High-performance - Update Management A-3 Responding Gateway Community A Initiating Gateway A-2 Community C Responding Gateway A-1 Community D Responding Gateway Community E Responding Gateway
Loosely-coupled Use Case Community B - Lower Scalability Requirements - Lower Performance Requirements - Optional Update Management A-3 Responding Gateway Community A Initiating Gateway A-2 Community C Responding Gateway A-1 Community D Responding Gateway Community E Responding Gateway
National/Shared Patient Identifier Community B - Scalable - High-performance - Update Management N-3 Responding Gateway Community A Initiating Gateway N-2 Community C Responding Gateway N-1 Community D Responding Gateway Community E Responding Gateway
Pseudonym Use A-13, A-23, A-33 … Community B - Scalable - High-performance - Update Management Responding Gateway Community A A-12, … Initiating Gateway Community C Responding Gateway A-11, … Community D Responding Gateway Community E Responding Gateway
When to ask? i.e. What can the receiver assume about how long between when there is information about Karen to share and you ask if receiver knows Karen. What side-effects from asking? XCA Gateway for community A XCA Gateway for community B Do you know Karen Witting? What if A doesn’t agree with match? What if demographics change after match? Yes, she is ID 44398402 in domain 88.693.222.4 What if later Karen shows up in B? No How and when is this resolved? Maybe