Please use a compatible browser :Google Chrome or Mozilla Firefox
Page expired. Any change will be lost. Try to refresh the page.
Gazelle update scheduled, unsaved changes will be lost :
Your session will timeout :
Redeployed...
Logged out...
The server is restarting. Any change will be lost.
 

View Transaction

View Transaction Information

Id: 136

Keyword: ITI-41

Name: Provide and Register Document Set-b

Description: Provide and Register Document Set-b

TF Reference:

Status: Final Text

Document Section :

None

Id
Keyword
Name
Description
Action
21 XDR Cross-Enterprise Document Reliable Interchange 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 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 DSG Digital Signature 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).
244 CMPD Community Medication Prescription and Dispense The Community Medication Prescription and Dispense Integration Profile (CMPD) describes the process of prescription, validation and dispense of medication in the community domain.
386 CH:XDS.b Cross-Enterprise Document Sharing Swiss Extension
Id
Keyword
Name
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
1183PRES_PLACERPrescription PlacerThe main role of this actor consists in placing the prescription (initial or modified in case of a substitution of invalidation, for example). It sends the cancellation of the prescription or its discontinuation, as well. In order to fulfill this task, the prescription placer retrieves the current treatment of the patient and medication already dispensed recently. The prescription placer receives the pharmaceutical validation and status tracking information such as substitution, availability, administration plan and reports and cancellation. The corresponding human actor is a prescriber.
1184PHA_ADVPharmaceutical AdviserThis actor is responsible for the validation of prescriptions from a pharmacist’s perspective. Therefore, it receives the initial prescription, validates it and sends it back (accepted, cancelled, modified, substitution of pharmaceutical product); therefore it provides the pharmaceutical advice. To perform this task it checks the current treatment. The pharmaceutical advice can be due to clinical, legal, or supply aspects. This actor may be implemented in the hospital pharmacy module of a hospital information system or the point of sale software of the pharmacy. The corresponding human actor is typically a pharmacist (or pharmacist assistant).
1185MED_DISMedication DispenserThis actor is responsible for the process of dispensing medication to the patient, fulfilling the prescription. Therefore it produces the information on the medication dispensed to the patient. In order to achieve this, it receives prescriptions already validated. It also confirms drug availability for administration and it receives the administration plan and administration reports. This actor may be implemented as the point of sale software of a community pharmacy or the hospital pharmacy module of a hospital information system. The human actor behind this system actor is usually a pharmacist or a pharmacist assistant. In addition to the dispense, in this version this actor is considered to take care of all the dependencies to ensure a proper dispensing.
1190CPMCommunity Pharmacy ManagerThe main role of this actor consists in providing the business logic for status management and other purposes. As a second role it acts as a “relaying role” where certain standard XDS communication is routed through for providing the possibility of applying project-specific business logic on it. It provides special query-transactions which consuming actors (prescription placer, pharmaceutical adviser or medication dispenser) used for reducing the amount of data flowing to them. They return just “relevant” information for specific purposes (e.g., returning just all “active” prescriptions ready for being validated or dispensed together with all related documents). This actor is usually a system actor without human participation.
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.
1345MED_TREAT_PLANNERMedication Treatment PlannerThe main role of this actor consists in adding a new Medication Treatment Plan Item. It sends the cancelation of the planned item or its discontinuation, as well. In order to fulfill this task, the Medication Treatment Planner retrieves the current set of planned medications of the patient.
Assertion Id
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

Tool index

  • Simulators

    Copyright IHE 2024
  • Gazelle 7.1.7
Back to top