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
Keyword
Name
Description
Action
29 XCA Cross-Community Access The Cross-Community Access profile supports the means to query and retrieve patient relevant medical data held by other communities. A community is defined as a coupling of facilities/enterprises that have agreed to work together using a common set of policies for the purpose of sharing clinical information via an established mechanism. Facilities/enterprises may host any type of healthcare application such as EHR, PHR, etc. A community is identifiable by a globally unique id called the homeCommunityId. Membership of a facility/enterprise in one community does not preclude it from being a member in another community. Such communities may be XDS Affinity Domains which define document sharing using the XDS profile or any other communities, no matter what their internal sharing structure.
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.
90 CH:XDS-I.b Cross-Enterprise Document Sharing for Imaging
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.
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.
354 CH:ATNA Deprecated Audit Trail and Node Authentication Swiss Extension Deprecated
386 CH:XDS.b Cross-Enterprise Document Sharing Swiss Extension
Id
Keyword
Name
Description
Action
1ARRAudit Record RepositoryA system unit that receives and collects audit records from multiple systems.
42DOC_CONSUMERDocument ConsumerThe Document Consumer Actor queries a Document Registry Actor for documents meeting certain criteria, and retrieves selected documents from one or more Document Repository actors.
43DOC_REGISTRYDocument RegistryThe Document Registry Actor maintains metadata about each registered document in a document entry. This includes a link to the Document in the Repository where it is stored. The Document Registry responds to queries from Document Consumer actors about documents meeting specific criteria. It also enforces some healthcare specific technical policies at the time of document registration.
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.
54EMBED_REPOSIntegrated Document Source/RepositoryThe Integrated Document Source/Repository is an XDS combination of Document Source and Document Repository that does not expose the interface between the Source and Repository. That is, this Source only publishes documents to its own Repository. It does register documents with a Document Registry
89INIT_GATEWAYInitiating Gateway
187ON_DEMAND_DOC_SOURCEOn-Demand Document SourceThe On-Demand Document Source is the producer and publisher of On-Demand Documents. This actor registers On-Demand Document Entries with the Document Registry and responds to Retrieve Document Set transactions with a document reflecting current information for the entry requested.
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.
1321DOC_AUDIT_CONSUMERDocument Audit Consumer
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
ITI43-1 The Retrieve Document Set Request shall carry a required repositoryUniqueId that identifies the repository from which the document is to be retrieved. This value corresponds to XDSDocumentEntry.repositoryUniqueId
ITI43-10 A Document Repository or On-Demand Document Source shall return the document(s) indicated in the request
ITI43-11 Implementors of this transaction (ITI-43) shall comply with all requirements described in ITI TF-2x:Appendix V: Web Services for IHE Transactions
ITI43-12 The Retrieve Document Set transaction shall use SOAP12 and MTOM with XOP encoding (labeled MTOM/XOP in this specification).
ITI43-13 The Document Repository shall accept the Retrieve Document Set Request message in MTOM/XOP format
ITI43-14 The Document Repository shall: generate the Retrieve Document Set Response message in MTOM/XOP format
ITI43-15 The Document Consumer shall generate the Retrieve Document Set Request message in MTOM/XOP format
ITI43-16 The Document Consumer shall accept the Retrieve Document Set Response message in MTOM/XOP format
ITI43-17 The Retrieve Document Set Transaction is either a PHI-Import event or a PHI-Export event, depending on the actor, as defined in ITI TF-2a: Table 3.20.6-1, with the following exceptions
ITI43-18 The DocumentRepository Actor, On-Demand Document Source, and Initiating Gateway shall generate an Export event
ITI43-19 The Document Consumer Actor shall generate an Import event
ITI43-2 The Retrieve Document Set Request shall carry a required documentUniqueId that identifies the document within the repository. This value corresponds to the XDSDocumentEntry.uniqueId.
ITI43-20 If some documents were retrieved successfully and others were not, the Actors involved shall record a success audit event for those documents retrieved successfully and a failure audit event for those documents not retrieved successfully
ITI43-3 When receiving a Retrieve Document Set Request, a Document Repository or an Initiating Gateway shall generate a Retrieve Document Set Response containing the requested documents or error codes if the documents could not be retrieved
ITI43-4 The Retrieve Document Set Response Message shall carry for each of the returned documents a homeCommunityId if it is provided in the request. This value shall be the same as the homeCommunityId value in the Retrieve Document Set Request Message
ITI43-5 If the homeCommunityId value is not present in the Retrieve Document Set Request Message, it shall not be present in the response
ITI43-6 The Retrieve Document Set Response Message shall carry for each of the returned documents: a required repositoryUniqueId that identifies the repository from which the document is to be retrieved. This value shall be the same as the value of the repositoryUniqueId in the original Retrieve Document Set Request Message
ITI43-7 The Retrieve Document Set Response Message shall carry for each of the returned documents : a required documentUniqueId that identifies the document within the repository
ITI43-8 The Retrieve Document Set Response Message shall carry t for each of the returned documents: the retrieved document as a XOP Infoset
ITI43-9 The Retrieve Document Set Response Message shall carry for each of the returned documents: the MIME type of the retrieved document

Tool index

  • Simulators

    Copyright IHE 2024
  • Gazelle 7.1.7
Back to top