<H3>Special Instructions</H3> This test is run once by Observation Processor actors who DO NOT support the PIX-Based Reconciliation Option.   <p> If the PIX-based Reconciliation Option is supported, then the Observation Processor actor will instead run all required tests for the PIX Consumer actor in the PIX Profile and test IDCO_PIX-based_Reconciliation_Option. </p> <H3>Description</H3> Observation Processors are required to cross-reference patient identifiers across two Patient Identifier Domains:  the device vendor systms providing the observations and the clinics receiving the observations. <p> Observation Processors who do not support the PIX-based Reconciliation option must demonstrate their implementation-specific ID mapping mechanism in this test.  The Monitor uses best judgment when observing the system. </p> <H3>Evaluation</H3>  <p>The Connectathon Monitor will observe the Observation  Processor application.&nbsp; &nbsp;The operator of the Observation Processor  system will be asked to demonstrate its Patient Identifier mapping  mechanism.&nbsp; This may be an automated or  manual method.&nbsp; <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.&nbsp; </p> <ul> <ul>   <li><em>If the  method is automatic</em>:<br>     The Connectathon Monitor will ask you to <u>describe</u> the mapping mechanism,  including the method for obtaining the values of the Patient IDs in the  &lsquo;receiving&rsquo; 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>   <li>Receive  an obervation including a Patient ID in the format as specified in the  [CARD-12] transaction &ndash; concatenation of the device model number and device serial  numberl</li>   <li>Receive  (or enter) a Patient ID (different value) from a receiving Domain</li>   <li>&lt;an  automatic mapping method happens here&gt;</li>   <li>The  observations included in the received observation message are now associated  with the correct Patient ID from the receiving Domain.&nbsp; The best way to demonstrate this is in the  output &lsquo;processed&rsquo; observations.</li> </ul> <ul>   <li><em>If the  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 &lsquo;receiving&rsquo; 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 &ndash; concatenation of the device model number and device  serial numberl</li>   <li>Receive  (or enter) a Patient ID (different value) from a receiving Domain</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 one of the  (many) possible 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.&nbsp; The best way to demonstrate this is in the  output &lsquo;processed&rsquo; observations.</li> </ul>