pix/pdq – today and tomorrow vassil peytchev epic
DESCRIPTION
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]TRANSCRIPT
PIX/PDQ –Today and Tomorrow
Vassil PeytchevVassil PeytchevEpic
Introduction
• Patient Identity Cross-reference Profile– Actors and Transaction Flow– Transactions – Implementation considerations
• Patient Demographics Query Profile– Actors and Transaction Flow– Transactions – Implementation Considerations
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]
ITI-10
ITI-8 ITI-X1
PIX and PIXV3 Transaction Flows
Patient IdentitySource
Patient IdentifierCross-reference
Consumer
Patient IdentifierCross-reference
Manager
ITI-9 ITI-X2
ITI-X3
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
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
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
PIX Implementation Considerations
Transactions HL7 MessagesITI-8 ADT^A01, ADT^A04,
ADT^A05, ADT^A08, ADT^A40
ITI-9 QBP^Q23, RSP^K23
ITI-10 ADT^A31
• Use of assigning authority for patient identifier domainUse of assigning authority for patient identifier domain-Patient identifier domains specified by Assigning Authority Patient identifier domains specified by Assigning Authority component of HL7 CX data typecomponent of HL7 CX data type-Valid assigning authority value combinationsValid assigning authority value combinations
-Namespace onlyNamespace only-Universal Id, Universal Id Type OnlyUniversal Id, Universal Id Type Only-Name, Universal Id and Universal Id TypeName, Universal Id and Universal Id Type
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.
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
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
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
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)
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
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
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
HL7 V3 Message Models
HL7 V3 Message Models
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.
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
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
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
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]
ITI-22
PDQ and PDQV3 Transaction Flows
PatientDemographics
Consumer
PatientDemographics
Supplier
ITI-21 ITI-X4
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
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
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
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.
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
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)
HL7 V3 Profiles
