Search Criteria : 25 assertions found for this search Review filtered assertions

Assertion

Applies to

Applied to
Not applied to

Coverage

Covered by
Not covered by
Id scheme
Assertion id
Status
Testable?
#Coverage
#Applies to
Comment
Predicate
Page
Tags
Last changed
Actions
ITI8ITI8-002to be reviewedTestable 0 1 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 38Section 3.8.4.1.14/4/16 4:38:44 PM by aberge
ITI8ITI8-003validatedTestable 0 1 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 sender39Section 3.8.4.1.24/4/16 4:53:07 PM by aberge
ITI8ITI8-009to be reviewedTestable 0 0 Pre-admission of inpatients shall use the A05 trigger event.42Section 3.8.4.1.24/4/16 4:37:51 PM by aberge
ITI8ITI8-018validatedTestable 0 1 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.44Section 3.8.4.1.34/4/16 4:50:37 PM by aberge
ITI8ITI8-019validatedTestable 0 1 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. 45Section 3.8.4.1.34/4/16 4:50:40 PM by aberge
ITI8ITI8-020validatedTestable 0 1 The Patient Identifier Cross-reference Manager Actor shall only recognize (by configuration) a single Patient Identity Source Actor per domain.45Section 3.8.4.1.34/4/16 5:01:40 PM by aberge
ITI8ITI8-021validatedTestable 0 1 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).45Section 3.8.4.1.34/4/16 4:42:44 PM by aberge
ITI8ITI8-022validatedTestable 0 1 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.45Section 3.8.4.1.3.14/4/16 4:51:01 PM by aberge
ITI8ITI8-023to deleteTestable 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.)45Section 3.8.4.1.3.14/4/16 4:33:46 PM by aberge
ITI8ITI8-024to be reviewedTestable 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.46Section 3.8.4.1.4.14/4/16 4:33:58 PM by aberge
ITI8ITI8-025to be reviewedTestable 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).46Section 3.8.4.2.14/4/16 4:34:10 PM by aberge
ITI8ITI8-026to be reviewedTestable 0 0 we are not testing the PIX Source actor in this year cycleThe 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.47Section 3.8.4.2.24/4/16 4:34:24 PM by aberge
ITI8ITI8-029to be reviewedTestable 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.47Section 3.8.4.2.24/4/16 4:35:13 PM by aberge
ITI8ITI8-030to be reviewedTestable 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.47Section 3.8.4.2.24/4/16 4:35:25 PM by aberge
ITI8ITI8-034to be reviewedTestable 0 0 we are not testing the PIX source actor in this cycleThe 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.48Section 3.8.4.2.2.44/4/16 4:35:58 PM by aberge
ITI8ITI8-037validatedTestable 0 1 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. 48Section 3.8.4.2.34/4/16 4:44:19 PM by aberge
ITI8ITI8-038to be reviewedTestable 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.49Table 3.8-44/4/16 4:36:31 PM by aberge
ITI8ITI8-039to be reviewedTestable 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.49Section 3.8.4.2.44/4/16 4:36:42 PM by aberge
ITI8ITI8-040to be reviewedTestable 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.50Section 3.8.4.2.44/4/16 4:37:09 PM by aberge
ITI8ITI8-1to deleteTestable 0 1 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) 38Section 3.8.4.1.12/17/16 12:24:11 PM by aberge