Using 3 XDS Affinity Domains at the Connectathon At past connectathons, we chose to test with one Affinity Domain and one Patient ID assigning authority accepted by all XDS.b Registries. – One AD was easier to test (less switching) – But his was not as effective for also testing XCA This year we will have three Affinity Domains in Bordeaux.

Using 3 XDS Affinity Domains at the Connectathon (Part 2) Each Affinity Domain has its own (different) ‘master’ assigning authority for Patient IDs (eg … , … , ) For ease-of-reference, we call these the ‘blue’, ‘red’, and ‘green’ domains Each XDS.b Registry is assigned to one of these 3 domains for the week. – The Patient ID feed must have the Assigning Authority OID for its domain – All documents submitted must use the proper Assigning Authority OID Affinity domain codes (from codes.xml) are the same across all 3 affinity domains – A simplification to ease testing

Assigning Authority & XDS.b / XDS-I.b We define 3 “Master” Patient ID Assigning Authority values (eg … , … , ) XDS.b Registries: – A given Registry is assigned only one of these values. It only accepts Patient Feeds and Documents submitted for this Assigning Authority. This value remains the same for the whole week. – We have ~15 Registries in Bordeaux. That means that five of the Registries will be assigned to accept a Patient ID with the … value, five are assigned the … value, etc. This is no different than what we have done up until now with multiple Registries accepting the same assigning authority value. XDS.b Repositories: – A Repository shouldn’t care if it has stored documents for patients with different assigning authority values; the Repository can keep its database and be paired with different Registries during the week with no adverse effect. XDS.b Sources & Consumers: – The burden for multiple assigning authority domains lies here. – Sources will have to pay close attention to Assigning Authority of the Registry associated with the Doc Repository to which they are submitting a document. – Consumers will have to know the Assigning Authority value of the Registry it is querying.

XCA GW Registry Repos assigning authority Patient ID feed Patient ID feed Patient ID feed Sources PIX MGR

Patient ID Assigning Authority for XDS.b Registries to accept Company nameXDS.b Doc Registry System name Patient ID Assigning Authority to accept IBMXDSb_REG_IBM ISOFT_NLOTHER_ISOFT_NL SIBXDSb_REG_SIB topicusXDSb_REG_topicus_topicus ALERTEHR_ALERT_ ForcareXDSb_REG_Forcare MEDICASOFTPACS_MEDICASOFT SIEMENS / ITH-ICOSERVEEHR_ITH-ICOSERVE_SIEMENS_2 A-thonXDSab_REG_A-thon_COPY_ GE / ICWOTHER_GE_ICW ISCEHR_ISC_HEALTHSHARE SanteosXDSb_REG_Santeos_COPY_0 Tiani - CiscoEHR_Tiani - Cisco

Assigning Authority & HL7 actors PIX/PIXv3/XDS.b Patient Identity Sources: – For tests driven by XDS.b, we will use a tool to serve as the Patient Identity Source (able to send demographics with red, blue, green assigning authority) – As usual, for PIX peer-to-per tests, each PIX Patient ID Source actor will have its own assigning authority value given to them in the gazelle configuration section PIX/PIXv3 Managers: Should receive a feed for all patients created by the Patient Identity Source tool used for XDS.b testing (including red, blue, green assigning authority values) PIX/PIXv3 Consumers: – Are already required to specify the affinity domain in their PIX Query; they may optionally specify ‘what domain returned’, to query a PIX Manager for a Patient ID in the domain they want PDQ/PDQv3 Suppliers: – PDQ Suppliers will be given one of the red/blue/green assigning authority values It responds to PDQ queries using the value of the Assigning Authority OID it has been given See next slide

Assigning Authority for PDQ/PDS systems PDQ and PDQv3 Patient Demographics Suppliers Assigning Authority for Patient IDs on your PDS engEHR_eng_AREAS InitiatePIX_X_REF_MGR_Initiate_COPY_ MedasysOP_Medasys NOEMALIFEEHR_NOEMALIFE SIEMENS / ITH- ICOSERVEEHR_ITH-ICOSERVE_SIEMENS_ WEB100TADT_WEB100T_PCP GIP CPAGEADT_GIP CPAGE MCKADT_MCK NextgatePIX_X_REF_MGR_Nextgate SIEMENSEHR_SIEMENS_CLINICOM SystelabPOCT_DM_Systelab_Synapse GE / ICWOTHER_GE_ICW ISCEHR_ISC_HEALTHSHARE MIPIHADT_MIPIH SQLIEHR_SQLI_IDEOSANTE Tiani - CiscoEHR_Tiani - Cisco

Multiple domains & XCA & XCPD XCA Initiating and Responding Gateways: – Connectathon Monitors assigned to XCA will help Gateways “plug in” to this infrastructure – Those Gateways that support the ‘XDS affinity domain’ option can be associated with one of the affinity domains – They will either learn about patients by accepting a Patient ID feed, or will do it some other non-IHE way – A few Gateways will also support XCPD, and can test this as well

Connectathon demographics We distribute patient demographics prior to the connectathon to be pre-loaded on XDS.b Registry, PDQ Supplier and PIX Manager systems – We have 3 sets – demographics-red, demographics-blue, demographics- green – PIX Managers load all demographics – PDQ Suppliers load demographics marked for PDQ tests – XDS.b Registries load demographics marked for XDS tests. There are red/blue/green versions of demographics that contain the same patient name/DOB/addr for these patients, but different ID values for each of the 3 assigning authorities. The PIX Managers should recognize these as the same person. An electronic copy of the Bordeaux patient demographics is here: