I have walked into plenty of clinics where check in feels like air traffic control. Phones light up, staff toggle across screens, and the line inches forward while someone tries to confirm a last name and a birth date. If that scene sounds familiar, PDQ is worth your attention, because it shortens the search and lowers the odds of picking the wrong chart.
PDQ focuses on one problem that quietly drags access, throughput, and staff morale. Finding the right patient record fast. When front desk staff can retrieve a clean candidate list in seconds, the desk clears sooner, clinicians start on time, and billing teams inherit fewer messes. That confidence at the first touch point stabilizes the rest of the day. If your broader operations strategy includes a unified inbox and AI intake automation that are integrated with EHR and PM systems, PDQ strengthens that foundation. For background on those building blocks, see Solum Health, the overview on centralized patient messaging hub, the primer on EHR PM system integration, the guidance on EHR inbox integration, and the explainer on omnichannel patient communications. You can also review how intake ties into operations in medical coding automation, patient message triage, and referral intake, along with metrics thinking in call queue analytics for medical practices.
Patient Demographics Query, or PDQ, is a standards based way for one system, the consumer, to ask another system, the supplier, for patient demographic records. The consumer submits a small set of demographic inputs, usually a name fragment, date of birth, and one or two contact details. The supplier searches its index and returns a list of candidate matches for review. PDQ is not a database and not a policy about identity resolution. It is the query and response mechanism that keeps structure and vocabulary consistent so different systems can exchange demographic lookups. For primary references, see the IHE profile description in Patient Demographics Query and the API oriented variant in Patient Demographics Query for Mobile.
Step 1, a search is triggered. A staff member, a scheduling workflow, or an intake assistant initiates a lookup using a few attributes. Most clinics start with last name, date of birth, and a phone or zip.
Step 2, the request is constructed. The consumer formats the query to the profile in use and applies basic normalization, for example casing and whitespace, to improve match quality.
Step 3, candidates are returned. The supplier, often a master patient index or a source of truth, evaluates the inputs and responds with a ranked set of records, each with identifiers and key demographics.
Step 4, review and selection. High confidence results can be auto accepted within policy. Ambiguous results go to a quick human check, the safest way to prevent mislinks.
Step 5, workflow completion. The chosen record is attached to the appointment, demographics pre fill forms, and downstream tasks are set up.
Step 6, monitor and tune. Thresholds and attributes rarely stay perfect. Teams review accepted versus rejected candidates and adjust rules to balance speed and safety.
What is PDQ in healthcare? PDQ is a standards based query that returns candidate patient records using basic demographics, not clinical data. It helps staff or approved rules select the right person quickly.
How does PDQ differ from an MPI? PDQ is how you ask, an MPI is where you look. The MPI stores and reconciles demographic identities. PDQ is the request that retrieves candidates from that service.
Is PDQ compatible with modern APIs? Yes. PDQ has variants that align with contemporary interfaces while preserving the semantics of demographic search. Confirm supported attributes and map them cleanly so results are predictable.
Which data elements are most useful? Start with last name, first name, date of birth, and one contact field such as phone or zip. Combine at least two attributes when feasible. Collect only what you need.
How can a clinic cut false matches? Normalize inputs, use clear acceptance thresholds, require human confirmation for ambiguous results, and review outliers monthly. Tune based on accepted versus rejected candidates and any subsequent corrections.
If you want a quick win, run a one week pilot at the front desk. Define inputs, configure the PDQ consumer and supplier, and set a strict auto accept rule for high confidence matches only. Log every manual confirmation and every new chart created. At the end of the week, review candidate yield and average time to selection, then tighten or loosen thresholds. Fold the protocol into your broader operations approach that uses a unified inbox and AI intake automation, integrated with EHR and PM systems, so PDQ results flow directly into the work your teams already manage.
