Connectathon Testing PIX PDQ XDS

From IHEWiki

Jump to: navigation, search

Patient Identifiers and Assigning Authority

This page needs to be updated to address PIX/PDQv3 and XDS.b.


These notes are specific to PIX (HL7 V2), PDQ (HL7 V2) and XDS. The next version should be extended to include PIX V & PDQ V3

This page requires more research on the usage of PID 3.5, Identifier Type Code. We will use the value PI, but need to document which messages will use Identifier Type Code.

  1. Different IHE profiles treat the HL7 assigning authority (PID 3.4) differently. The Assigning Authority has 3 subcomponents
    1. Namespace ID (text string)
    2. Universal ID (OID)
    3. Universal ID type (the string ISO when you use an OID)
  2. PIX requirements for Connectathon
    1. Patient Identifier Source (ITI 8):
      1. You can send either Namespace ID, or
      2. Universal ID + Universal ID type, or
      3. All three subcomponents
    2. PIX Manager for PIX Profile (inbound feed)
      1. You will receive ADT feeds as described above
      2. You need to map these to the full assigning authority (3 components)
    3. PIX Consumer (ITI 9)
      1. You can provide either Namespace ID, Universal ID + Universal ID type, or all three components (ITI vol 2, 3.9.4.1.2.2)
      2. We recommend you provide all three components (will make it easier on configuration)
    4. PIX Manager for PIX Profile (ITI 9)
      1. You shall return all three components (ITI 2, 3.9.4.2.2.5)
      2. Be aware that the client may provide Namespace ID, Universal ID + Universal ID type, or all three components
  3. PDQ Requirements for Connectathon
    1. Patient Demographics Consumer
      1. If you specify a value in QPD-8, only component 4 (Assigning Authority) shall be valued (ITI 2, 3.21.4.1.2.2.2).
      2. If you specify a value in QPD-8, we recommend you provide all three components of the Assigning Authority: Namespace ID, Universal ID, Universal ID Type.
    2. Patient Demographics Supplier
      1. The TF is silent on how to format PID 3.4.
      2. For the Connectathon, we will require all three components: Namespace ID, Universal ID, Universal ID type
  4. XDS Requirements
    1. Patient ID Source (ITI 8)
      1. When you send a message to a Document Registry, you need to send Universal ID + Universal ID type (ITI 1, 10.1, Table 10.1-1, Note 3).
      2. The TF is silent on including the Namespace ID. For the connectathon, do not send the Namespace ID to the Document Registry. This may be difficult if you are configured to send all three components to the PIX Manager for the PIX profile. Do the best you can.
    2. Document Source
      1. When you submit documents, you use only the Universal ID + Universal ID type and do not use the Namespace ID. This is true universally for IHE XDS.
      2. For the Connectathon, all documents sent to a Repository (and registered with a Registry) shall be registered using a Patient ID with the "master" Assigning Authority. The Assigning Authority values for Universal ID + Universal ID type given to you in separate documentation by the Connectathon Manager.
    3. Do not register documents using Assigning Authorities other than those for the "master" Affinity Domain. Do not use the patient IDs you receive from the vendor Patient Identifier sources (which are each using their own Assigning Authority). Use PIX or PDQ to get the "master" Patient ID.
    4. Properly format the assigning authority when submitting for XDS. Do not include the Namespace ID when you submit documents.
    5. Document Registry
      1. For inbound ADT feed, you should expect the Universal ID + Universal ID Type.
      2. For inbound ADT feed, you might receive the Namespace ID. You should discard that.
    6. Document Consumer
      1. When you send an XDS query, you shall only include the Universal ID + Universal ID type for the assigning authority and omit the Namespace ID (ITI 2, 3.16.4.1.4)
  5. Notes for Document Source, PIX Manager and Document Consumer
    1. The PIX, PDQ and XDS requirements are slightly different
    2. You need to live in both worlds and perform the proper formatting
    3. You cannot expect to treat the assigning authority as an opaque string in a hospital and just pass it through.

In the table below

  • Yes means send a value in this component (does not make sense if you do not send a value)
  • No means do not send a value
  • Required by the IHE TF or by Connectathon Manager implementation; send a value
Transaction PID 3.1 PID 3.2 PID 3.3 PID 3.4.1 PID 3.4.2 & 3.4.3 PID 3.5
PIX ADT (ITI-8) Yes No No Can send by itself Can send if you include both
XDS ADT (ITI-8) Yes No No Can send by itself Can send if you include both
PIX Query (Query) Yes No No Can send by itself Can send if you include both
PIX Query (Response) Yes No No Required Required
PDQ Query (Query)
PDQ Query (Response) Yes No No Required Required
XDS.a Submit Document Yes No No No Required
XDS.a Query Document Yes No No No Required
Personal tools