Extended PDQ
1. Proposed Workitem: Extended PDQ
- Proposal Editor: Alean Kirnak / Sandy Thames
- Editor: N/A
- Date: N/A (Wiki keeps history)
- Version: N/A (Wiki keeps history)
- Domain: IT Infrastructure
2. The Problem
The American Immunization Registry Association (AIRA) is developing an updated HL7 (version 2.5) implementation guide for immunization information systems (IISs), and the North American Association of Central Cancer Registries (NAACCR) is developing an HL7 CDA implementation guide for central cancer registry (CCR) systems. AIRA is making an effort in the new IIS implementation guide to harmonize with the IHE PIX and PDQ profiles. However, both in its existing HL7 version 2.3.1 implementation guide and in practice, the set of demographic traits used by Patient Demographics Query is too small for practical use. In practice, the following additional traits are required to be processed by at least the Patient Demographics Supplier:
- Patient Home Telephone (Cancer could use this element)
- Patient Birth State
- Patient Multiple Birth Indicator
- Patient Birth Order
- Last Update Date/Time
- Last Update Facility
- Mother’s Name
- Mother’s SSN
- Father’s Name
- Father’s SSN
In addition, the interpretation of the most recent version of PDQ requires matches on all traits, i.e. AND’s them rather than OR’s them. This also has been found impractical in the field by IISs, so we also request that this requirement, which was not present in earlier versions, be removed.
3. Key Use Case
IISs often have millions of records representing patients in a single geographic region. Due to similarities of names and other demographic traits, due to missing, incomplete or incorrect data, and other issues, in practice, the mentioned fields are required for accurate matching. For example, a multiple birth indicator and birth order often is the only piece of information that allows an automated matching algorithm to distinguish between twins, triplets, etc. as they often (particularly in pediatrics) have similar first names, identical last names, dates of birth, addresses and other demographic traits.
Cancer registries have the same difficulties as those described above for IISs. CCRs receive records for patients from multiple reporting facilities. Information from these different facilities must be consolidated by the CCRs to create a longitudinal report for each cancer case. A unique patient identifier, properly secured, offers the most accurate and efficient method for resolving this industry wide problem.
4. Standards & Systems
(1) See existing IHE PDQ profile and transactions.
(2) HL7 Version 2.3.1 and HL7 Version 2.5.
(2) Implementation Guide for Immunization Data Transactions Using V 2.3.1 of the Health Level Seven (HL7) Standard Protocol. See:
- http://www.immregistries.org/pubs/index.phtml
- http://www.cdc.gov/vaccines/programs/iis/stds/downloads/hl7guide.pdf
(3) HSSP Entity Identification Service: Service Functional Model (SFM), balloted HL7 Draft Standard for Trial Use (DSTU), references PIX and PDQ. See:
Initial submission to OMG includes a profile that demonstrates PIX/PDQ compatibility, with the above stated extensions. See:
5. Discussion
Interfacing to public health, IISs, and CCRs is an important interoperability requirement. If proper profiles are in place, providers and EMR systems can use IHE profiles to perform patient identity resolution, can update and retrieve data, and invoke publicly maintained decision support modules for immunization forecasting and cancer registration.
See white paper on public health, including immunizations and cancer registries, published by the Public Health Data Standards Consortium, pages 17, and 21-22 for description of immunization use case and pages ____ for description of cancer registry use case. Currently, the immunization use case can only partially be implemented with IHE profiles. This proposed new profile is required to make it possible for IISs and CCRs to be fully compatible with IHE profiles, and will apply to other domains as well.