Connectathon Patient Identifiers Steve Moore Lynn Felhofer

Connectathon Patient IDs – 2 areas of concern This presentation explains the use of Patient IDs at the Connectathon: In departmental workflow tests: SWF, CATH, ECHO, STRESS – Slides 3-5 In XDS tests – Slides 6-18

Patient IDs in Departmental Workflow tests 3 3

Patient Identifiers: IHE, Department IHE manages identifiers in the departmental workflows through SWF, Cath and other workflow profiles An ADT system is the source of patient identifiers Emergency, unidentified patients have special cases This is not the ID that is used in XDS.b 4 4

Identifiers: Connectathon, Department For Departmental workflow tests We do not always have enough ADT systems to make things work smoothly Connectathon management supplements the participant ADT systems with a separate application (RIS Mall) that generates ADT messages with identifiers used for departmental workflow These are Connectathon tests, not Demonstration choices

Patient IDs in XDS.b tests 6 6

Identifiers: XDS Affinity Domain An XDS Affinity Domain requires a unique patient identifier IHE gives these choices (but does not mandate) PIX PDQ Other Affinity Domains are free to choose, and they can choose “other”

Meta Data vs Document XDS requires that the Patient ID in a document’s XDS meta-data be the value known by the Affinity Domain Documents themselves are not required to use that ID within their content In fact, documents may have internal, department identifiers inside the document and never reference the Affinity Domain Patient ID

Identifiers: Connectathon, Affinity Domain In theory, each XDS Registry would warrant a separate Affinity Domain, and a separate domain of patient identifiers In practice, at the Connectathon, we bundle all XDS Registry actors into a single Affinity Domain with one domain of patient identifiers This is a huge simplification that makes switching from one Registry to another possible Otherwise, there would be unmanageable confusion

Connectathon Affinity Domain ID Source We use the Geneva tool (previously known as the HIMSS Registration Tool) as the source of Patient Identifiers in the ‘Affinity Domain’ at the Connectathon If a vendor participant wants to step up and take that responsibility, we would be glad to share or turn that over That source of Affinity Domain Patient Identifiers (Geneva tool or vendor participant) is responsible for sending ADT messages to the Registry actors, PIX Managers and PDQ Servers

Connectathon: Doc Source, Doc Consumer To obtain an Affinity Domain Patient ID, what are my Connectathon choices as a Doc Source or Doc Consumer? Get an ADT feed from the Patient ID source There is no IHE transaction defined to the Doc Source or Doc Consumer, but we can use ITI-8 (or ITI-44) Use PDQ query Use PIX query Configure the ID by hand The operative term is “Connectathon choice”. IHE/XDS does not require a specific solution. These are your choices.

Two Models For PIX If you choose PIX… Model 1: My Local Identifier Affinity Domain Patient ID Source sends master Patient ID to PIX Manager I send my local ID to the PIX Manager I ask the PIX Manager: “For my local ID, what is the Affinity Domain ID?” Model 2: Delegated Identifier Slide 14-15

More on PIX Model 1 In Model 1, you have to send the proper demographics to help the PIX managers (Name, DOB, Address) You can have the Geneva tool send you a Patient Registration message (HL7 v2 or v3) so you can copy the demographics out of that message before you send your Pat Registration msg, or You use the Web GUI on the Geneva tool to send ADT messages to PIX Managers. Geneva then displays the demographics so you can register the patient in your system.

PIX Delegated Identifier Affinity Domain Patient ID Source sends master Patient ID to PIX Manager Some other patient ID source (my delegate) sends a local identifier to the PIX Manager and to me I send a query to the PIX Manager: “Given the local identifier sent by my delegate, what is the Affinity Domain identifier?”

Geneva Tool as Delegate The Geneva tool can serve as the delegate It can send a Patient Registration message (HL7 v2 or v3) with your local identifier to Your system All PIX Managers

PIX Models You can choose either model for Connectathon testing Demonstration rules are not the same as Connectathon testing rules Demonstration committee makes decisions/documents requirements Your use of PIX, PDQ, ADT feeds is governed by the demonstration committee. You need to have a clear understanding of their requirements.

XDS-I XDS-I.b presents a challenge because departmental Image Managers are accustomed to receiving local identifiers Now, as an Imaging Document Source, they have to manage the local identifier and get an identifier for the Affinity Domain This is no different than requirements on other Document Source actors