| ITI-001 | Restricted Update Document Set [ITI-92] is used by the Update Initiator and Update Responder (See Section 3.92 Restricted Update Document Set) |
| ITI-002 | The Restricted Update Document Set Request message shall use SOAP 1.2 and Simple SOAP (See Section 3.92.4.1.2 Message Semantics) |
| ITI-003 | Implementers of this transaction shall comply with all requirements described in ITI TF-2x: Appendix V.3: Synchronous and Asynchronous Web Services (see Section 3.92.4.1.2 Message Semantics) |
| ITI-004 | The Update Initiator shall ensure that all metadata attributes are consistent with the requirements specified in ITI TF-3 (see Section 3.92.4.1.2.1 Content) |
| ITI-005 | The Update Responder shall use Metadata Annotations when processing the request for storage (see Section 3.92.4.1.2.2 Metadata Annotations) |
| ITI-006 | The default value for Association Propagation is "yes" (See Section 3.92.4.1.2.2.2 Association Propagation) |
| ITI-007 | The Update Responder shall return the status and any error codes incurred during the processing of the request in its response message (See Section 3.92.4.1.3 Expected Actions) |
| ITI-008 | If the value is not known, the Update Responder shall return the error code, XDSUnknownCommunity (See Section 3.92.4.1.3.1 Forward Update Option) |
| ITI-009 | If the value is omitted, the Update Responder shall return the error code, XDSMissingHomeCommunityId (See Section 3.92.4.1.3.1 Forward Update Option) |
| ITI-010 | The current version of the stored logical metadata object shall always have an availabilityStatus equal to urn:oasis:names:tc:ebxml-regrep:StatusType:Approved and prior versions shall have their availabilityStatus attribute set tourn:oasis:names:tc:ebxml-regrep:StatusType:Deprecated (see Section 3.92.4.1.3.4.1 Storage Requirements) |
| ITI-011 | Unless a more specific code is provided within the validation, the Update Responder shall return the error code, XDSMetadataUpdateError, for any error returned during processing (See Section 3.92.4.1.3.4 Request Validation) |
| ITI-012 | The system shall contain an existing DocumentEntry (Stable or On-Demand) metadata object instance with status of urn:oasis:names:tc:ebxml-regrep:StatusType:Approved (See Section 3.92.4.1.3.4 Request Validation) |
| ITI-013 | The SS-DE HasMember Association shall be present and have a Slot with name PreviousVersion (See Section 3.92.4.1.3.4 Request Validation) |
| ITI-014 | The submitted and existing DocumentEntry objects shall have the same values for both the logicalID ans uniqueID attribute (See Section 3.92.4.1.3.4 Request Validation) |
| ITI-015 | The submitted and existing DocumentEntry objects shall have the same values for the patientID attributes (see Section 3.92.4.1.3.4 Request Validation) |
| ITI-016 | All metadata objects must conform to the rules for content and format defined in ITI TF-3: 4.2 and 4.3. Stable Document Entry object metadata must confirm to the requirements defined in ITI TF-2b: 3.42 for the Register Document Set-b [ITI-42] transaction (see Section 3.92.4.1.3.4 Request Validation) |
| ITI-017 | On-Demand Document Entry objects must conform to the requirements defined in ITI TF-2b: 3.61 for the Register On-Demand Document Entry [ITI-61] transaction (see Section 3.92.4.1.3.4 Request Validation) |
| ITI-018 | The Restricted Update Document Set Response message shall use SOAP 1.2 and Simple SOAP (see Section 3.92.4.2.2 Message Semantics) |
| ITI-019 | Implementers of this transaction shall comply with all requirements described in ITI TF-2x: Appendix V.3: Synchronous and Asynchronous Web Services (see Section 3.92.4.2.2 Message Semantics) |
| RMU-001 | Actors must implement ITI-92 transaction. |