PIX/PDQ – Today and Tomorrow

1. PIX/PDQ –Today and Tomorrow Vassil Peytchev Epic

2. Introduction • Patient Identity Cross-reference Profile • Actors and Transaction Flow • Transactions • Implementation considerations • Patient Demographics Query Profile • Actors and Transaction Flow • Transactions • Implementation Considerations

3. PIX and PIXV3 Summary • Patient Identity Cross Reference (PIX) profile defines 3 transactions: • Patient Identity Feed [ITI-8] • PIX Update Notification [ITI-10] • PIX Query [ITI-9] • Patient Identity Cross Reference HL7 V3 (PIXV3) profile also defines 3 transactions: • Patient Identity Feed HL7 V3 [ITI-X1] • PIXV3 Update Notification [ITI-X3] • PIXV3 Query [ITI-X2]

4. PIX and PIXV3 Transaction Flows Patient Identity Source Patient Identifier Cross-reference Consumer ITI-9 ITI-X2 ITI-8 ITI-X1 ITI-10 ITI-X3 Patient Identifier Cross-reference Manager

5. PIX and PIXV3 Transactions • Patient Identity Feed and Patient Identity Feed HL7 V3 [ITI-8 and ITI-X1] • Part of several profiles • ITI-8 is part of PIX, XDS.a and (optionally) XDS.b • ITI-X1 is part of PIXV3 and (optionally) XDS.b • Patient Identity Source conveys patient demographic data and patient identifiers to PIX Cross Reference Manager and XDS Document Registry • XDS Document Registry uses information in the feed to identify patients that are members of the affinity domain • PIX Cross Reference Manager uses information in the feed to cross reference corresponding patient ids from multiple domains • Including linkage between hospital/clinic ids and affinity domain ids

6. PIX and PIXV3 Transactions • PIX Update Notification and PIXV3 Update Notification (ITI-10 and ITI-X3) • PIX Cross Reference Manager notifies PIX Cross Reference Consumer of changes in cross referenced identifiers for a given patient • PIX Cross Reference Manager actor must implement this transaction • Transaction is optional for PIX Cross Reference Consumer actors

7. PIX and PIXV3 Transactions • PIX Query and PIXV3 Query [ITI-9 and ITI-X2] • PIX Cross Reference Consumer presents a patient ID to PIX Cross Reference Manager • PIX Cross Reference Manager returns corresponding ids for same patient within other domains

8. PIX Implementation Considerations • Use of assigning authority for patient identifier domain • Patient identifier domains specified by Assigning Authority component of HL7 CX data type • Valid assigning authority value combinations • Namespace only • Universal Id, Universal Id Type Only • Name, Universal Id and Universal Id Type

9. PIX and PIXV3 Implementation Considerations • If Patient ID Source supports multiple patient identifier domains, then patient IDs within PIX feed must be qualified by domain • Otherwise, PIX Cross Reference Manager and XDS Document Registry can default to single domain associated with the Patient Id Source • When using Patient Identity Feed [ITI-8] within an XDS.a or XDS.b profile context… • Assigning authority shall be specified as Universal ID and Universal ID Type • Universal ID shall be an OID (which implies Universal ID Type == ISO) • When using Patient Identity Feed HL7 V3 [ITI-X1] within an XDS.b profile context, document registry must translate between the II data type and the CX format used in XDS.

10. PIX Implementation Considerations • Specifying what domains to return on PIX Query • Use QPD-4 to specify explicit list of domains for which cross-referenced patient ids are requested • If no domains specified in QPD-4… • Will receive cross-referenced patient identifiers for all domains known to the PIX Cross Reference Manager • More than 1 patient id can be returned for a given domain • Consumer needs to handle all of the ids returned or must ignore all of the ids returned • To avoid situations where consumer presents incomplete set of information based on use of partial set of patient identifiers

11. PIX and PIXV3 Implementation Considerations • Use of PIX or PIXV3 Update Notification • Useful in situations where actor wants to keep a local cache of cross-referenced identifiers • Example: • XDS Document Source within a hospital maintains a list of local hospital patient ids and corresponding affinity domain ids • Typically used in lieu of PIX or PIXV3 Query • Mechanics of PIX or PIXV3 Update Notification • PIX Consumer indicates which domains they are interested in receiving cross reference event notifications • PIX Cross Reference Manager notifies PIX Consumer of changes to the set of cross-referenced patient ids spanning the domains of interest to a given PIX Consumer • This will typically result as a side effect of a Patient Identity Feed transaction

12. PIX and PIXV3 Implementation Considerations • Out-of-band issues PIX Consumer and PIX Cross Reference Manager need to agree on • PIX Cross Reference Manager responsible for maintaining list of PIX Consumers subscribing to PIX or PIXV3 Update Notifications • And for each subscriber, list of domains to subscribe to • How this information is conveyed to and managed by the PIX Cross Reference Manager is not addressed by the PIX or PIXV3 profiles

13. PIX and PIXV3 Implementation Considerations • ATNA audit requirements (CP for 2006) • Patient Identity Feed is defined as a Patient Record event per ATNA Record Audit Event transaction • Patient Id Source responsible for generating Patient Record audit message per DICOM (Supp 95) • PIX Query is defined as a Query event per ATNA Record Audit Event transaction • PIX Consumer and PIX Cross Reference Manager responsible for generating Query audit messages per DICOM (Supp 95) • PIX Update Notification is defined as a Patient Record event per ATNA Record Audit Event transaction • PIX Cross Reference Manager responsible for generating Patient Record audit message per DICOM (Supp 95)

14. MLLP and the PIX profile • Socket connection management • Current PDQ and PIX profiles use HL7 MLLP (a TCP sockets based protocol) for message transport • Key design question: when to establish new socket connection • This is not covered explicitly within the IHE profiles • Options include: • New connection for each message exchange between client and server (no ambiguity in socket connection lifetime) • Reuse single connection across all interactions between given client and server (better for performance) • Something in between these two extremes • Recommendation • Client establishes connection for first message exchange and attempts to reuse connection for subsequent transactions • If socket connection closed; client handles by initiating new connection • Server responsible for determining how long to keep an inactive connection open

15. PIXV3 Implementation Considerations • HL7 Version 3 Implementation • Already familiar to those who use CDA-based content • Data Types implementation • Message Models • XML serialization • Web Services

16. HL7 V3 Data Types • Formally Defined • Abstract Data Types • XML ITS for Data Types • Implement all base types • II • CD • AD • PN • TS • Consider Time-related Data Types • Consider Null Flavors

17. HL7 V3 Message Models

18. HL7 V3 Message Models

19. HL7 V3 From Model To XML • The model describes the data, which can be transferred • The HL7 V3 XML ITS describes how to serialize the model • Since the IHE restrictions retain any required and mandatory classes and attributes, the HL7 generated XML schemas can be used to understand the XML format of the messages.

20. HL7 V3 XML handling • Generating XML • Use the data types implementation • Refer to the IHE specification for required elements • Consuming XML • Use XML namespaces • Use XPath or Schematron to validate input • DOM vs. SAX processing

21. PIX V3 Implementation Considerations • II Data Type For Patient Identifiers • Compatibility with the HL7 V2 CX data type • Assigning Authority vs. Scoping Organization • PN Data Type • AD Data Type

22. HL7 V3 and Web Services • HL7 Version 3 Messages are Transmitted Using Web Services • WSDL Definitions • Sample WSDL Provided • Consider Separate Implementation • Message Schema • Development WSDL

23. PDQ and PDQV3 Summary • Patient Demographics Query (PDQ) profile defines two transactions: • Patient Demographics Query [ITI-21] • Patient Demographics and Visit Query [ITI-22] • Patient Demographics Query HL7 V3 (PDQV3) profile defines one transactions: • Patient Demographics Query HL7 V3 [ITI-X4]

24. PDQ and PDQV3 Transaction Flows Patient Demographics Consumer ITI-21 ITI-X4 ITI-22 Patient Demographics Supplier

25. PDQ and PDQV3 Transactions • Patient Demographics Query and Patient Demographics Query HL7 V3 Transactions • Given a partial set of patient demographics… • Return set of matching patients, their demographics and corresponding patient identifiers • Patient Demographics and Visit Query • If supplier supports visit data, search criteria may include combination of demographic and visit data • Patient Demographics and Visit Query is an optional transaction for both Patient Demographics Consumer and Supplier

26. PDQ and PDQV3 Implementation Considerations • Patient Information Source identification • A patient demographics supplier may contain patient information from multiple sources • The query is evaluated within the context of a given patient information source • The Patient Demographics Consumer uses MSH-5/6 Receiving Application/Facility (PDQ) or the transmission wrapper’s Receiver.id/Organization.id (PDQV3) to identify patient information source context for PDQ query

27. PDQ and PDQV3 Considerations • Identifying domains for requested patient identifiers • For PDQ QPD-8 used to identify list of domains for returned patient identifiers • For PDQV3 the OtherIDsScopingOrganization Parameter is used for the same purpose. • If no domains are specified, you get all domains associated with patient information source • If using the within XDS, will typically want to specify affinity domain explicitly

28. PDQ and PDQV3 Continuations • Specified in the corresponding versions of the standards • Query cancellation is optional • Query Tag (PDQ) or queryId (PDQV3) used to link the query session messages together.

29. PDQ and PDQV3 Implementation Considerations • Out-of-band issues PD Consumer and Supplier need to agree on • Set of demographic items that can be queried • Profile defines minimal set; but supplier can support additional demographic fields as search criteria • Supplier may return any of the demographic attributes defined in the PID segment or the Patient Registry Query by Demographics Response • Support for wildcard queries and syntax used for wildcard queries • E.g. Find all patients whose last name starts with “M” • Use of Message Query Name (QPD-1) • Some PDQ Suppliers may require specific query name • List of patient information sources supported by the supplier • Consumer needs to identify one of the supported patient information source when issuing PD Query

30. PDQ and PDQV3 Implementation Considerations • ATNA audit requirements (CP for 2006) • PD Query is defined as a Query Information event per ATNA Record Audit Event transaction • PD Consumer and PD Supplier responsible for generating Query audit messages per DICOM (Supp 95)

31. HL7 V3 Profiles

32. Questions? Vassil Peytchev vassil@epicsystems.com