| ITI8 | ITI8-002 | reviewed | Testable |
0
|
0
| | Changes to patient demographics (e.g., change in patient name, patient address, etc.) shall trigger the following Admit/Register or Update message:
A08 Update Patient Information | 39 | Section 3.8.4.1.1 | 5/22/19 4:22:41 PM by NicolasBailliet |
|
| ITI8 | ITI8-003 | reviewed | Testable |
0
|
0
| | Each message shall be acknowledged by the HL7 ACK message (see ITI TF-2x C.2.3) sent by the receiver of ADT message to its sender | 39 | Section 3.8.4.1.2 | 5/22/19 4:22:41 PM by NicolasBailliet |
|
| ITI8 | ITI8-009 | reviewed | Testable |
0
|
0
| | Pre-admission of inpatients shall use the A05 trigger event. | 39 | Section 3.8.4.1.2 | 5/22/19 4:22:41 PM by NicolasBailliet |
|
| ITI8 | ITI8-018 | reviewed | Testable |
0
|
0
| | The Patient Identifier Cross-reference Manager shall be capable of accepting attributes in the PID segment as specified in HL7 standard as well as their extended field length as defined in Table 3.8-2. This is to ensure that the Patient Identifier Cross-reference Manager can handle a sufficient set of corroborating information in order to perform its cross-referencing function. | 42 | Section 3.8.4.1.3 | 5/22/19 4:22:41 PM by NicolasBailliet |
|
| ITI8 | ITI8-019 | reviewed | Testable |
0
|
0
| | If the PID-3.4 (assigning authority) component is not included in the message (as described in Section 3.8.4.1.2.3) the Patient Identifier Cross-reference Manager shall fill PID-3.4 prior to storing the ID information and performing its cross-referencing activities. | 42 | Section 3.8.4.1.3 | 5/22/19 4:22:41 PM by NicolasBailliet |
|
| ITI8 | ITI8-020 | reviewed | Testable |
0
|
0
| | The Patient Identifier Cross-reference Manager Actor shall only recognize (by configuration) a single Patient Identity Source Actor per domain. | 42 | Section 3.8.4.1.3 | 5/22/19 4:22:41 PM by NicolasBailliet |
|
| ITI8 | ITI8-021 | reviewed | Testable |
0
|
0
| | Once the Patient Identifier Cross-reference Manager has completed its cross-referencing function, it shall send out notification to any Patient Identifier Cross-reference Consumers that have been configured using the PIX Update Notification transaction (see Section 3.10 for the details of that transaction). | 42 | Section 3.8.4.1.3 | 5/22/19 4:22:41 PM by NicolasBailliet |
|
| ITI8 | ITI8-022 | reviewed | Testable |
0
|
0
| | The identifier of the domain shall specify all 3 components of the HL7 assigning authority (including the namespace ID and/or both the universal ID and universal ID type subcomponents) of the PID-3 field for the identification of the domain. | 42 | Section 3.8.4.1.3.1 | 5/22/19 4:22:41 PM by NicolasBailliet |
|
| ITI8 | ITI8-023 | reviewed | Testable |
0
|
0
| | The Patient Identity Source Actor is expected to be the MSH-3 Sending Application and the corresponding MSH-4 Sending Facility fields in the HL7 ADT message. (Alternative identification schemes might include IP address of the Patient Identity Source Actor or Node Authentication if the Audit Trail and Node Authentication Integration Profile is used.) | 42 | Section 3.8.4.1.3.1 | 5/22/19 4:22:41 PM by NicolasBailliet |
|
| ITI8 | ITI8-024 | reviewed | Testable |
0
|
0
| | The identifier of the Patient Identification Domain of the XDS Affinity Domain shall be specified with 3 components of the HL7 assigning authority (data type 1185 HD): namespaceID, universal ID and universal ID type. The universal ID shall be an ISO OID (Object Identifier), and therefore the universal ID Type must be ISO. | 43 | Section 3.8.4.1.4.1 | 5/22/19 4:22:41 PM by NicolasBailliet |
|
| ITI8 | ITI8-025 | reviewed | Testable |
0
|
0
| | When two patients records are found to identify the same patient by a Patient Identity Source Actor in a Patient Identifier Domain and are merged, the Patient Identity Source shall trigger the following message:
A40 Merge Patient Internal ID
An A40 message indicates that the Patient Identity Source Actor has done a merge within a specific Patient Identification Domain. That is, MRG-1 (patient ID) has been merged into PID-3 (Patient ID). | 44 | Section 3.8.4.2.1 | 5/22/19 4:22:41 PM by NicolasBailliet |
|
| ITI8 | ITI8-026 | reviewed | Testable |
0
|
0
| we are not testing the PIX Source actor in this year cycle | The Patient Identity Feed transaction is an HL7 ADT message. The message shall be generated by the system (Patient Identity Source Actor) that performs the update whenever two patient records are found to reference the same person. | 44 | Section 3.8.4.2.2 | 5/22/19 4:22:41 PM by NicolasBailliet |
|
| ITI8 | ITI8-029 | reviewed | Testable |
0
|
0
| | A separate merge message shall be sent for each pair of patient records to be merged. For example, if Patients A, B, and C are all to be merged into Patient B, two ADT^A40 messages would be sent. In the first ADT^A40 message, patient B would be identified in the PID segment and Patient A would be identified in the MRG segment. In the second ADT^A40 message, patient B would be identified in the PID segment, and Patient C would be identified in the MRG segment. | 44 | Section 3.8.4.2.2 | 5/22/19 4:22:41 PM by NicolasBailliet |
|
| ITI8 | ITI8-030 | reviewed | Testable |
0
|
0
| | Modification of any patient demographic information shall be done by sending a separate Update Patient Information (A08) message for the current Patient ID. | 44 | Section 3.8.4.2.2 | 5/22/19 4:22:41 PM by NicolasBailliet |
|
| ITI8 | ITI8-034 | reviewed | Testable |
0
|
0
| we are not testing the PIX source actor in this cycle | The Patient Identity Source Actor shall send the old patient identifier (to be merged) in MRG-1, with the identifier value in the component MRG-1.1 and the assigning authority in the component MRG-1.4. The Patient Identity Source Actor shall populate the same value of the assigning authority in PID-3.4, in the component MRG-1.4. | 45 | Section 3.8.4.2.2.4 | 5/22/19 4:22:41 PM by NicolasBailliet |
|
| ITI8 | ITI8-037 | reviewed | Testable |
0
|
0
| | When the Patient Identifier Cross-reference Manager receives the ADT^A40 message type of the Patient Identity Feed transaction, it shall cross-reference the patient identifiers provided in the PID-3 and MRG-1 fields of the message by replacing any references it is maintaining internally to the patient ID provided in the MRG-1 field by the patient ID included in the PID-3 field. | 46 | Section 3.8.4.2.3 | 5/22/19 4:22:41 PM by NicolasBailliet |
|
| ITI8 | ITI8-038 | reviewed | Testable |
0
|
0
| | The Document Registry shall be capable of accepting attributes in the MRG segment as specified in Table 3.8-4. Other attributes may exist, but the Document Registry shall ignore them. | 45 | Table 3.8-4 | 5/22/19 4:22:41 PM by NicolasBailliet |
|
| ITI8 | ITI8-039 | reviewed | Testable |
0
|
0
| | When the Document Registry receives the ADT^A40 message type of the Patient Identity Feed transaction, it shall merge the patient identity specified in MRG-1 (secondary patient identity) into the patient identity specified in PID-3 (primary patient identity) in its registry. After the merge, all Document Submission Sets (including all Documents and Folders beneath them) under the secondary patient identity before the merge shall point to the primary patient identity. The secondary patient identity shall no longer be referenced in the future services provided by the Document Registry. | 46 | Section 3.8.4.2.4 | 5/22/19 4:22:41 PM by NicolasBailliet |
|
| ITI8 | ITI8-040 | reviewed | Testable |
0
|
0
| | After a merge, the patient identifier PID-3 represents all records formerly represented by either MRG-1 or PID-3. All other fields may be ignored.
The following conditions shall be detected by the Document Registry. Messages containing these conditions shall not update the state of the Document Registry.
The subsumed patient identifier is not issued by the correct Assigning Authority according to the Affinity Domain configuration.
The surviving patient identifier is not issued by the correct Assigning Authority according to the Affinity Domain configuration.
The subsumed and surviving patient identifiers are the same.
The subsumed patient identifier has already been subsumed by an earlier message.
The surviving patient identifier has already been subsumed by and earlier message.
Both the subsumed and surviving patient identifier must convey a currently active patient identifier known to the Registry Actor.
If none of the above conditions occur then the Document Registry Actor shall perform the following duties:
Records the merge. Only the subsumed and surviving patient identifiers need be remembered. A patient identifier merge affects the processing of future Register Document Set-b [ITI-42] transactions. See ITI TF-3: 4.3.1.2.4 XDS Registry Enforcement of Attributes and ITI TF-3: 4.3.1.2.5 XDS Registry Responsibilities for more details.
Multiple merge transactions can form a recorded merge chain, where the Subsumed identifier of the current merge is the Surviving identifier of a previous merge.
Register Document Set-b transactions referencing a subsumed identifier are rejected with an XdsUnknownPatientId error.
Registry Stored Query transactions referencing a subsumed identifier return no content.
Registry Stored Query transactions referencing a surviving identifier successfully match the entire recorded merge chain and return appropriate metadata. | 46 | Section 3.8.4.2.4 | 5/22/19 4:22:41 PM by NicolasBailliet |
|
| ITI8 | ITI8-1 | reviewed | Testable |
0
|
0
| | The following events from a Patient Identity Source Actor will trigger one of the Admit/Register or Update messages:
A01 Admission of an in-patient into a facility
A04 Registration of an outpatient for a visit of the facility
A05 Pre-admission of an in-patient (i.e., registration of patient information ahead of actual admission)
| 39 | Section 3.8.4.1.1 | 5/22/19 4:22:41 PM by NicolasBailliet |
|