Veuillez utiliser un navigateur compatible :Google Chrome ou Mozilla Firefox
La page a expiré. Tout changement sera perdu. Essayez d'actualiser la page.
Mise à jour de Gazelle planifiée, sauvegardez votre travail :
Votre session Gazelle va expirer :
Redéployé...
Déconnexion ...
Le serveur redémarre. Tout changement sera perdu.
 

Voir la Transaction

Voir les informations sur la Transaction

Id: 136

Mot-clé: ITI-41

Nom: Provide and Register Document Set-b

Description: Provide and Register Document Set-b

Référence du TF: https://profiles.ihe.net/ITI/TF/Volume2/ITI-41.html

Statut: Final Text

Section du document :

Aucun

Id
Mot-clé
Nom
Description
Action
21 XDR Cross-Enterprise Document Reliable Interchange https://profiles.ihe.net/ITI/TF/Volume1/ch-15.html Cross-Enterprise Document Reliable Interchange (XDR) provides document interchange using a reliable messaging system. This permits direct document interchange between EHRs, PHRs, and other healthcare IT systems in the absence of a document sharing infrastructure such as XDS.
36 TP13 Manage Sharing of Documents Transaction Package with Doc Integrity Check US HITSP: TP13: Manage Sharing of Documents Transaction Package with Doc The Manage Sharing of Documents Transaction Package supports the sharing of patient records in the form of source attested objects called documents. A healthcare document is a composite of structured and coded health information, both narrative and tabular, that describes acts, observations and services for the purpose of exchange. No assumption is made by this construct in terms of the format and structure of the content of documents shared.
39 XDS.b Cross-Enterprise Document Sharing https://profiles.ihe.net/ITI/TF/Volume1/ch-10.html The Cross-Enterprise Document Sharing (XDS.b) IHE Integration Profile facilitates the registration, distribution and access across health enterprises of patient electronic health records. Cross-Enterprise Document Sharing is focused on providing a standards-based specification for managing the sharing of documents between any healthcare enterprise, ranging from a private physician office to a clinic to an acute care in-patient facility.
46 DEPRECATED:DSG-2014 DEPRECATED:Digital Signature-2014 DSG is document content profile that describes the digital signature content and how it is managed in XDS, as well as guidance on how other IHE domains (such as Patient Care Coordination) could create document content profiles for such purposes as e-referral and e-prescription.
85 DEPRECATED:CRD2011 DEPRECATED: Clinical Research Document CRD describes the content and format to be used within the Prepopulation Data transaction described within the RFD Integration Profile. The purpose of this profile is to support a standard set of data in CCD format which the Form Filler provides for use in Clinical Research. In addition this profile will reference the ability to convert this output into a standard case report form (Standard CRF) consisting of ODM and CDASH.
139 T31 HITSP Reliable Document Exchange US HITSP: T31: Reliable Document Exchange. The Document Reliable Interchange Transaction provides a standards-based mechanism for conveying a set of medical documents in a point-to-point network-based communication. This Transaction uses the IHE Cross-Enterprise Document Reliable Interchange (XDR) Integration Profile, a companion to the IHE Cross-Enterprise Document Sharing (XDS) Integration Profile. Cross-Enterprise Document Reliable Interchange (XDR) uses the XDS defined metadata formats in a simpler environment in which the communicating parties have agreed to a point-to-point interchange rather than communicating via document sharing.
151 TP49 HITSP Sharing Radiology Results Transaction Package US HITSP: TP49: Sharing Radiology Results Transaction Package. The Sharing Imaging Results Transaction Package supports the sharing of radiology result data in a document sharing functional flow scenario.
239 epSOS Dispensation Service epSOS Dispensation Service The epSOS Dispensation Service provides an operation for notifying the patient’s country of affili-ation on the dispensation of a previously retrieved ePrescription.
240 epSOS Consent Service epSOS Consent Service The epSOS consent service provides operations for the remote management of consents (e. g. giving and revoking consent from abroad).
Id
Mot-clé
Nom
Description
Action
41DOC_SOURCEDocument SourceThe Document Source is the producer and publisher of documents and metadata.
44DOC_REPOSITORYDocument RepositoryThe Document Repository is responsible for both the persistent storage of these documents as well as for their registration with the appropriate Document Registry. It assigns a URI to documents for subsequent retrieval by a Document Consumer.
76DOC_RECIPIENTDocument Recipient The Document Recipient receives documents and metadata sent by another actor.
82FORM_FILLERForm FillerThe actor responsible for retrieving a form from a Form Manager, and for submitting form instance data to a Form Receiver.
83FORM_ARCHIVERForm ArchiverThe actor responsible for receiving form instance data for archival purposes.
1181NCP-ANational Contact Point Country A This is the country of affiliation of the patient
1182NCP-BNational Contact Point Country BThis is the country of care
1194METADATA_LTD_DOC_SOURCEMetadata-Limited Document SourceThe Metadata-Limited Document Source sends documents and metadata similar to a Document Source but is limited in the quantity of metadata it is able to provide.
Id de l'assertion
Description
ITI41-1 A Provide and Register Document Set-b transaction shall carry within metadata, one XDSDocumentEntry object per document
ITI41-10 In the case where the Document Source submits a replacement of documents, if the Document Recipient is not able to process the replacement semantics in the submission it shall return a PartialReplaceContentNotProcessed warning which includes a textual description identifying that the replacement semantics were not processed. In this case the Document Recipient is expected to have processed the rest of the submission successfully
ITI41-11 A Document Repository shall forward the metadata to the Document Registry using the Register Document Set-b transaction [ITI-42]
ITI41-12 Each document within the message shall be stored into the Document Repository as an octet stream with an associated MIME type.
ITI41-13 The Document Repository shall modify the received document metadata before initiating the Register Document Set-b transaction to the Document Registry by adding/replacing: The repositoryUniqueId for this Document Repository to allow for the Document Consumer to correctly identify the proper Document Repository for each document (XDSDocumentEntry.repositoryUniqueId). A hash value (XDSDocumentEntry.hash) A size (XDSDocumentEntry.size).
ITI41-15 The Document Repository shall ensure that when any Retrieve Document Set transaction is received requesting a specific document(s), it shall be provided to the Document Consumer unchanged from the octet stream that was submitted (full fidelity repository) and shall match the size and hash attributes of the XDSDocumentEntry object
ITI41-16 If the Document Repository or Document Recipient detects a failure it shall return an error message to the Document Source or Metadata-Limited Document Source thus terminating this transaction.
ITI41-17 The Document Repository or Document Recipient shall send a Provide and Register Document Set-b Response when the processing of a Provide and Register Document Set-b Request is complete
ITI41-18 The document(s) received by the Document Recipient shall be available for further processing according to the capabilities of the system
ITI41-19 The metadata added to the registry shall be available for discovery via Registry Stored Query transactions
ITI41-2 A Provide and Register Document Set-b transaction shall carry XDS Submission Set definition along with the linkage to new documents and references to existing documents
ITI41-20 An implementation of the Document Source or Metadata-Limited Document Source Actor shall be capable of Submit one or more documents
ITI41-22 A Document Repository or Document Recipient shall be capable of accepting submissions containing multiple documents
ITI41-23 A Document Repository shall validate the following metadata element received as part of a Provide and Register transaction: XDSDocumentEntry.uniqueId, XDSSubmissionSet.sourceId, XDSDocumentEntry.hash, XDSDocumentEntry.size
ITI41-24 A submission shall be rejected if not unique within the repository and the hashes of the two documents do not match. If the hashes of the documents match, the Document Repository shall accept the duplicate document
ITI41-25 a submission shall be rejected if the hash is included in the submission and its value does not match the hash for the received document (ignoring case), as calculated by the Document Repository or Document Recipient; an XDSRepositoryMetadataError shall be returned on mismatch
ITI41-26 a submission shall be rejected if the size is included in the submission and its value does not match the size of the received document, as computed by the Document Repository or Document Recipient; an XDSRepositoryMetadataError shall be returned on mismatch
ITI41-27 The Provide and Register Document Set-b Transaction is either a PHI-Import event or a PHI-Export event, depending on actor, as defined in ITI TF-2a: Table 3.20.6-1, with the following exceptions
ITI41-3 The Document Repository shall, upon receipt of a Provide and Register Document Set-b [ITI-41] transaction send a corresponding Register Document Set-b [ITI-42] transaction to the Document Registry Actor
ITI41-4 The Document Repository Actor shall create and insert the XDSDocumentEntry.repositoryUniqueId, XDSDocumentEntry.size, and XDSDocumentEntry.hash attributes for each document received from the Provide and Register Document Set-b [ITI-41] transaction into the resulting Register Document Set-b [ITI-42] transaction metadata
    Copyright IHE 2024
  • Gazelle Master Model 8.0.0
Haut de page