50 likes | 75 Views
Requirements summary. Four response types: No match Single match Multiple matches Request more attributes Support of patient identifier identification and patient identifier correlation across communities Allow for asynchronous processing: requestor selected and responder selected.
E N D
Requirements summary • Four response types: • No match • Single match • Multiple matches • Request more attributes • Support of patient identifier identification and patient identifier correlation across communities • Allow for asynchronous processing: requestor selected and responder selected
General Issues with adopting PDQ V3 • Review of HL7 V3 Patient Demographics Query resulted in the following questions: • Use of continuation (CP 364 to make optional) • Use of application level ack – bypasses intermediate accept ack • Parameters (next slide) • Support for async operation (real time vs. batch)
PDQ V3 ALL optional Name * Gender * Birthtime * Address ID * Other IDs Scoping organization (see next slide) Consider adding Birth place Telecon Principle Care Provider Mothers maiden name Request Parameter Requirements
Response • PDQ supports 0 or more response entries • No way to request more attributes to help refine the search (??) • Scoping Organization rules requires requester to know the organization prior to the query. Not applicable in XCPI case. • Include birth place in response as optional? • PDQ requires all matches to be returned. XCPI must allow responder to choose a best fit match. • PDQ response required elements • Name • Provider org (PDQ requires HL7 does not) • Query match observation • ID • Birthtime (PDQ requires HL7 does not) • Add to required elements?
Responder Requirements • Response Modality (R=real time, B=Batch) • Query Priority (I=immediate, D=deferred)