Federation Karen Witting

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

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

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

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

Distributed, patient indexed

Locator of selected patients controlled by community

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

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.

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

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

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

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

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: 1.Defining and sharing attributes for communities 2.Defining and sharing capabilities for communities 3.Supporting storing references to external communities within XDS registry 4.Consider “Federation service” actor and transactions it supports.

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

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

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

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

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

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

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

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

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

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?