<H3>Special Instructions</H3> This test is run once by Observation Processor actors who support the PIX-Based Reconciliation Option.   <p> Prior to running this test, the PIX Manager actor must already have the Patient Identifier of the device registered and have done its internal mapping to the patient's record in the receiving domain. </p> <H3>Description</H3> Observation Processors are required to cross-reference patient identifiers across two Patient Identifier Domains:  the device vendor systems providing the observations and the clinics receiving the observations. <p> Observation Processors who support the PIX-based Reconciliation option must demonstrate that observations are associated with the proper Patient Identifier in the receiving Domain.  The Monitor uses best judgment when observing the system. </p> <H3>Evaluation</H3> <p>The Connectathon Monitor will observe the Observation  Processor application.   The operator of the Observation Processor  system will be asked to demonstrate it Patient Identifier mapping  mechanism.  This may be an automated or  manual method.  <br>   In general, the Connectathon Monitor is looking for a  method (not necessarily polished) that a vendor would be willing to  demonstrateto a customer as a part of a product.  </p> <ul> <ul>   <li>The Connectathon Monitor may ask to see a copy  of the QBP^Q23 message from the [ITI-9] message.  </li> </ul> <ul>   <li>QBP-3.1  contains the Patient Identifier from the observation message (a concatentation  of the device model number and the device serial number</li>   <li>QBP-3.4  contains the value for Assigning Authority.   This is the Device Manufacturer.</li> </ul> <ul>   <li><em>If the mapping  method is automatic</em>:<br>     The Connectathon Monitor will ask you to <u>demonstrate</u> this mapping  mechanism in action, eg </li> </ul> <ul>   <li>Receive  an obervation including a Patient ID in the format as specified in the  [CARD-12] transaction – concatenation of the device model number and device  serial numberl</li>   <li>Query  for the Patient ID from the receiving domain (and optionally receive Patient  Updates via ADT^A31, ie. [ITI-10])</li>   <li><an  automatic mapping method happens here></li>   <li>The  observations included in the received observation message are now associated  with the correct Patient ID from the receiving Domain.  The best way to demonstrate this is in the  output ‘processed’ observations.</li> </ul> <ul>   <li><em>If the mapping  method is manual</em>:<br>     The Connectathon Monitor will ask you to <u>describe</u> the manual mapping  procedure, including the method for obtaining the values of the Patient IDs in  the ‘receiving’ Patient ID Domain (eg in the clinic receiving the  observations).<br>     <br>     The Connectathon Monitor may ask you to <u>demonstrate</u> this mapping  mechanism in action, eg </li> </ul> <ul> <ul>   <li>Receive  an obervation including a Patient ID in the format as specified in the  [CARD-12] transaction – concatenation of the device model number and device  serial numberl</li>   <li>Query  for the Patient ID from the receiving domain (and optionally receive a Patient  Updates via ADT^A31, ie. [ITI-10])</li>   <li>Demonstrate  the mechanism, eg a User Interface, where the operator will perform the mapping  between the Patient ID received in the observation message and the Patient ID (or  multiple matching Patient IDs) in the receiving Domain.</li>   <li>The  observations included in the received observation message are now associated  with the correct Patient ID from the receiving Domain.  The best way to demonstrate this is in the  output ‘processed’ observations.</li> </ul>  