Federation Karen Witting. Goals of “Federation” Show a vision for support of cross XDS Affinity Domain communication Show cooperation between IHE and

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

RLSOther

XDS AD SNO

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

Patient-Data-Existence Locator

Patient-Data-Locator (e.g. XDS Registry)

Data Repository (e.g. XDS Doc Repository)



Data Repository (e.g. XDS Doc Repository) Data Repository

(e.g. XDS Doc Repository) Data Repository (e.g. XDS Doc Repository) Data Repository

(e.g. XDS Doc Repository)



Data Requesters (e.g. XDS Doc Consumer)

Data Source (e.g. XDS Doc Source)


Distributed, patient indexed

Patient-Data-Existence Locator Patient-Data-Locator (e.g. XDS Registry)





(e.g. XDS Doc Repository) Data Repository (e.g. XDS Doc Repository) Data Repository




Data Requesters (e.g. XDS Doc Consumer)



Locator of selected patients controlled by community

Patient-Data Locator(e.g. XDS Registry)

Data Repository(e.g. XDS Repository)



Federation

Service


Data Requester(e.g. XDS Doc Consumer)

Data Source(e.g. XDS Doc Source)


FederationService

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

Service





FederationService

Get Attributes Transaction

Search EngineNon-XDS CommunityFederation

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

Service





FederationService

Get Capabilities Transaction

Search EngineNon-XDS CommunityFederation

Service

Sear

ch



FederationServiceData Repository

(e.g. XDS Repository)



Get Capabilities Transaction

Search Engine

Connecting for Health Community

Inter-SNOBridge

RLS

CfHAdapter

OtherMaybe 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 communities2. Defining and sharing capabilities for communities3. Supporting storing references to external communities within

XDS registry4. Consider “Federation service” actor and transactions it supports.

Focus Bottom Up

1. Agree on vision2. Build profile to connect “Federation

Service” to internal actors – rename to Cross Community Bridge

3. Build collecting references of patients of interest

4. 2009 timeframe – build capabilities & attributes support

Two approaches to linking multiple communities

• Hierarchical grouping of communities

• Peer-to-peer community communication

SNO

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

CrossCommunity

Bridge

DataRepository

DocumentConsumer

Query Demo

(2)

1. Precondition: The IHE-RLS is primed with data2. 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 results6. Document Retrieve (existing)7. Document Retrieve (existing)

(4)

(3)

(5)

XDS Repository

(7)

(6)

XDS Registry

XDS Repository

(7)

(4)

XDS RegistryRLS/PIX+

XDS Registry

CrossCommunity

Bridge

DataRepository

CrossCommunity

Searcher

CrossCommunity

Bridge

Find New

Search Engine

(1)

(2)

1. Find New (attributes + demographics)2. Search by attributes3. Get Capabilities4. Query PDQ/Registry5. Update RLS/PIX+6. Notify caller: found new

(3)

(4)(5)

(6)

PDQ

CrossCommunity

Bridge

XDS Registry

RLS/PIX+

XDS Registry

CrossCommunity

Bridge

DataRepository

CrossCommunityRequestor

CrossCommunity

Bridge

Query External

(1)

1. Query External (query info, identical except for expected return timeframe?)2. Query RLS/PIX+3. Query registries4. Return consolidated results5. Retrieve External (url/webservice retrieve)6. Retrieve7. Return transformed data

(3)

(2)

(4)

XDS Repository

(7)

(6)

(5)

XDS Registry

XDS Repository

(6)

(3)

Cross Community Transactions

Cross CommunitySearcher

Cross CommunityBridge

Cross CommunityConsumer


Find New

Query External



Get Capabilities


Search EngineSearch by Attributes

Etc….

?? RLS/PIX+Query RLS

Update RLS

Cross Community Transactions

Cross CommunitySearcher

Cross CommunityConsumer

Find New

Query External

Get Capabilities

Search Engine

Search by Attributes

Etc….


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?

Documents

Federation Karen Witting. Goals of “Federation” Show a vision for support of cross XDS Affinity Domain communication Show cooperation between IHE and