HL7v2 XDS.b Patient Feed HL7v2

  1. 參與角色： Document Registry Document Repository Patient Identity Source

  2. 流程圖：

    pic

  3. 指示：
    Patient Identity Sources and Document Registries which support the Patient Identity Feed option (HL7v2) run this test.
    This test shall be run using TLS.
    The connectathon monitor will also look for evidence of logging. You should use the NIST ARR.

  4. 描述：
    The XDS_Patient_Feed test is used to load patient identifiers in the XDS Registry and to test the Registry response to a merge.
    Each Patient Identity Source should create new patients of the form:

    North America Europe Japan
    IDENTITY^REGISTRY^S IDENTITY^REGISTRY^S
    IDENTITY^REGISTRY^N IDENTITY^REGISTRY^N

    IDENTITY is the name of the Patient Identity Source in the Kudu system, or a 3-4 letter abbreviation.
    REGISTRY is the name of the Document Registry in the Kudu system, or a 3-4 letter abbreviation.
    S stands for Surviving patient and N stands for Non-Surviving Patient (used to test marge).
    For example: Sms^Agfa^S

    The Patient Identity Source should send one ADT A01 or ADT A04 message (ITI-8) to inform the Registry of patient 'S' and patient 'N'.
    Patient Identity Source should populate the PID fields listed in the table below. Other fields may be populated if desired, but the Connectathon monitor will look for data in these fields:

    PID Seq Element Name Notes
    3 Patient Identifier List User proper assigning authority
    5 Patient Name See above
    7 Date/Time of Birth
    11 Patient Address (this is R2, and a value may not be available) Use Connectathon address if possible

  5. 驗證：

    1. TLS verification:
      The Connectathon monitor will examine logs that show a successful TLS handshake.
    2. Patient Identity Feed:
      Connectathon monitor should examine log files or database entries at the Document Registry indicating the patients have been registered.
      The Document Registry is not expected to have a formal GUI to demonstrate this data, but it will need to maintain the data in some persistent manner.
      For patient IDENTITY^REGISTRY^S, the Connectathon monitor is looking for data in PID-3, PID-5, and PID-7. PID-11 is R2 in the Technical Framework, so it may be empty.
      Other fields can be populated and ignored.
      Also verify that patient IDENTITY^REGISTRY^N and IDENTITY^REGISTRY^S were registered (before the merge).
    3. Merge functionality:
      Connectathon monitor needs to know what records were available for both patients before the merge occurs. The monitor should then examine the database of the Document Registry or dragoon a Document Consumer into service to perform queries of the Document Registry.
      The Connectathon monitor will verify that the Registry rejected a document submission for the Non-Surviving patient.
    4. Audit Logging:
      See specifics of audit requirements in ITI TF-2:3.8.5
      An audit message is sent by the Patient Identity Source when it sends A01, A04, A05, A08 and/or A40 messages to the Registry.
      The audit message is a 'Patient Record' event containing the Patient ID.
      An audit message is sent by the Document Registry when it receives A01, A05, A05, A08 and/or A40 messages from the Patient Identity Source.
      The audit message is a 'Patient Record' event containing the Patient ID.