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: 138

Mot-clé: ITI-43

Nom: Retrieve Document Set

Description: Retrieve Document Set

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

Statut: Final Text

Section du document :

Aucun

Id
Mot-clé
Nom
Description
Action
29 XCA Cross-Community Access https://profiles.ihe.net/ITI/TF/Volume1/ch-18.html 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 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.
90 XDS-I.b Cross-Enterprise Document Sharing for Imaging The Cross-Enterprise Document Sharing (XDS.b) Profile in the IHE IT Infrastructure Domain provides a solution for sharing (publishing, finding and retrieving) documents across a group of affiliated enterprises. The XDS for Imaging (XDS-I.b) Profile, defined here, extends and specializes the mechanisms defined by XDS.b to support imaging “documents”
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.
408 mXDE Mobile Cross-Enterprise Document Data Element Extraction https://profiles.ihe.net/ITI/TF/Volume1/ch-45.html The Mobile Cross-Enterprise Document Data Element Extraction (mXDE) Profile provides the means to access data elements extracted from shared structured documents. The profile enables the deployment of health data exchange infrastructures where fine-grained access to health data coexists and complements the sharing of coarse-grained documents and the fine-grained data elements they contain.
Id
Mot-clé
Nom
Description
Action
42DOC_CONSUMERDocument ConsumerThe Document Consumer queries for document metadata meeting certain criteria and may retrieve selected documents.
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.
1353DATA_ELEMENT_EXTRACTORData Element ExtractorAccesses documents to extract data elements and create the links to the data elements’ source documents.
1371MED_ADMIN_PERFORMERMedication Administration PerformerReceives instructions for administration of medications to patients, to perform the necessary checks and display it to the user (patient or healthcare professional)
1402PHARM_REPORepository actorFormally the Community Pharmacy process defines different “repositories” for Medication Treatment Plans, Prescriptions, Pharmaceutical Advices, Dispenses and Medication Administrations, but they shall be seen as abstract repository-roles for persisting the appropriate document types the documents, not as XDS repositories defined in the “Cross Document Sharing” (XDS) Integration Profile of the ITI Technical Framework.
Id de l'assertion
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
    Copyright IHE 2024
  • Gazelle Master Model 8.0.0
Haut de page