1 / 14

Federation

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

roblesb
Télécharger la présentation

Federation

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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 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.

More Related