Federation

1. Federation Karen Witting

2. Goals of “Federation” • Show a vision for support of cross XDS Affinity Domain communication • Show cooperation between IHE and Connecting for Health

3. Community • a coupling of facilities/enterprises for the purpose of sharing patient-relevant medical information • Examples: XDS Affinity Domain, RHIO, Sub-network Organization (SNO) • Communities can be hierarchically part of a larger community

4. Communicating across Communities • Finding the community • Focus of prior discussion • Communicating with the community • Minimal focus so far SNO XDS AD SNO RLS Other XDS AD XDS AD

5. Patient-Data Existence Locator • Privacy/security of entity outside a community of significant concern • Multiple such entities being consistent • Support for such a locator within a community for patients of interest referencing external communities

6. Distributed, patient indexed

7. Locator of selected patients controlled by community

8. Data Repository (e.g. XDS Repository) Data Repository (e.g. XDS Repository) Selected patient-data locations saved within community Patient-Data Existence Locator Mechanism to support creation of this line Patient-Data Locator (e.g. XDS Registry) Patient-Data Locator (e.g. XDS Registry) Federation Service Federation Service Profile Data Source (e.g. XDS Doc Source) Data Requester (e.g. XDS Doc Consumer) Data Source (e.g. XDS Doc Source)

9. Finding Likely Relevant Communities • Search by attributes • Most people have data in one or few communities • Proper selection of attributes will facilitating successful search in most cases • Precision is not as critical as ease of creation & use • All data is public, no security needed • Searches will be infrequent, setup activities rather than frequent or ongoing • Define schema for defining attributes: participating organizations, cities serviced, medical specialty, etc. • Communities required to provided attributes as described in schema • Supports creation of search engines both within and outside of communities. Special purpose search engines. • Result of search is a list of hostnames, community is defined by a registered hostname.

10. Data Repository (e.g. XDS Repository) Data Repository (e.g. XDS Repository) Get Attributes Transaction Search Non-XDS Community Federation Service Search Engine Search Engine Patient-Data Existence Locator Patient-Data Locator (e.g. XDS Registry) Patient-Data Locator (e.g. XDS Registry) Federation Service Federation Service Data Source (e.g. XDS Doc Source) Data Requester (e.g. XDS Doc Consumer) Data Source (e.g. XDS Doc Source)

11. Communicating with Communities • URL is not enough • Protocol: XDS, CfH, other? • Coding systems • Document format • Authorization/Authentication mechanisms • Get Capabilities transaction • Define structure for defining capabilities • Require all communities to supply the information • Get Capabilities query may mean communication between that pair of communities is not possible: query return should include alternate mechanism like phone # or records dept, FAX, other

12. Data Repository (e.g. XDS Repository) Data Repository (e.g. XDS Repository) Get Capabilities Transaction Non-XDS Community Federation Service Search Engine Patient-Data Existence Locator Search Patient-Data Locator (e.g. XDS Registry) Patient-Data Locator (e.g. XDS Registry) Federation Service Federation Service Data Source (e.g. XDS Doc Source) Data Requester (e.g. XDS Doc Consumer) Data Source (e.g. XDS Doc Source)

13. Data Repository (e.g. XDS Repository) Get Capabilities Transaction Search Engine CfH Adapter Patient-Data Existence Locator Connecting for Health Community Inter-SNO Bridge Patient-Data Locator (e.g. XDS Registry) RLS Federation Service Other Maybe XDS Data Source (e.g. XDS Doc Source) Data Requester (e.g. XDS Doc Consumer)

14. Conclusion • Patient data held only within communities which have a relationship with the patient. • Patient data indexing done within communities for selected patients • Transactions needed to allow indexing of external communities containing patient data for patients of interest • Suggest: • Defining and sharing attributes for communities • Defining and sharing capabilities for communities • Supporting storing references to external communities within XDS registry • Consider “Federation service” actor and transactions it supports.

15. Focus Bottom Up • Agree on vision • Build profile to connect “Federation Service” to internal actors – rename to Cross Community Bridge • Build collecting references of patients of interest • 2009 timeframe – build capabilities & attributes support

16. Two approaches to linking multiple communities • Hierarchical grouping of communities • Peer-to-peer community communication SNO • Transactions to RLS/PIX+: • Update provide demographics and reference for a “domain” • Querygiven demographics return a list of references • These transactions also used in peer-to-peer RLS/PIX+ Other XDS AD XDS AD

17. Query Demo • Precondition: The IHE-RLS is primed with data • Query (existing transaction) • Query RLS/PIX+ (new transaction – alternate could configure static list to query) • Query each registry in list (existing transaction) • Return consolidated results • Document Retrieve (existing) • Document Retrieve (existing) XDS Registry (3) (4) RLS/PIX+ XDS Repository Cross Community Bridge (7) XDS Registry (4) (6) Data Repository (7) XDS Registry (5) (2) Document Consumer XDS Repository

18. Find New • Find New (attributes + demographics) • Search by attributes • Get Capabilities • Query PDQ/Registry • Update RLS/PIX+ • Notify caller: found new Search Engine PDQ (2) (5) RLS/PIX+ Cross Community Bridge (4) XDS Registry Cross Community Bridge (3) XDS Registry Data Repository (6) (1) Cross Community Searcher

19. Query External • Query External (query info, identical except for expected return timeframe?) • Query RLS/PIX+ • Query registries • Return consolidated results • Retrieve External (url/webservice retrieve) • Retrieve • Return transformed data XDS Registry Cross Community Bridge (2) (3) RLS/PIX+ XDS Repository Cross Community Bridge (6) XDS Registry (3) Cross Community Bridge (5) Data Repository (6) XDS Registry (4) (1) (7) Cross Community Requestor XDS Repository

20. Cross Community Transactions Update RLS RLS/PIX+ ?? Query RLS Query External Cross Community Consumer Cross Community Bridge Find New Cross Community Searcher Cross Community Bridge Cross Community Bridge Search by Attributes Search Engine Get Capabilities Cross Community Bridge Cross Community Bridge Etc….

21. Cross Community Transactions Cross Community Consumer Query External Query RLS Cross Community Searcher Find New Cross Community Bridge RLS/PIX+ Update RLS Get Capabilities Search by Attributes Search Engine Etc….

22. Find New Transaction • Search for patient data in a community which has not previously been located. • Request includes attributes and patient demographics • Bridge executes search transaction • Bridge checks capabilities • Bridge executes PDQ query for patient • Bridge queries non-local registry • Bridge updates local RLS/PIX+ with a new reference

23. Query External Communities • Pull information from references external communities • Query specifying patient demographics and query parameters • Bridge pulls external reference list from RLS/PIX+ • Bridge queries referenced XDS Registries • Bridge consolidates/translates results • Bridge returns results to caller

24. Other Thoughts • Async vs. Sync vs mixed • Give me whatever you get in 30 seconds and hold the rest until I ask for more • Agreed that async is needed • Technology, Technology, where is the standards to build on?