ITI-41

The ITI-41 (Provide and Register Document Set-b) transaction allows a content sender to send documents to the eMedication service (content receiver).

Generic DocumentEntry metadata are described in the documents section. This page references additional constraints specific to ITI-41.

See also IHE’s documentation for metadata in Document Sharing profiles as well as EPD by example’s Provide and Register Document Set page.

Publishing documents

Document types

Two types of documents might be published to the service:

• CH-EMED-EPR documents (MTP, PRE, DIS and PADV only, PML and PMLC can only be retrieved from the service and not published to it). These documents contain the eMedication data. See also the corresponding page in this guide.
• APPC (Advanced Patient Privacy Consent) documents. These documents are used to let patients define access rights to their data (who can publish and retrieve their data). See also the corresponding page in this guide.

SubmissionSet and relations

The eMedication service does not support folders and can only receive ONE document at a time. Hence, the metadata must always contain a SubmissionSet with a single DocumentEntry.

Only the following associations are supported:

Uniqueness

Documents can be sent to the eMedication service only once. Uniqueness is checked against DocumentEntry’s unique Id, that must be an UUID and DocumentEntry’s entryUUID.

Metadata

This section describes the rules applicable for any document’s type metadata.

SubmissionSet metadata

See also the IHE SubmissionSet Metadata Attributes diagram or the IHE SubmissionSet Attributes section.

DocumentEntry metadata

See also the DocumentEntry Metadata Attributes diagram.

Publishing a CH-EMED-EPR document

This section details the specific rules to follow when publishing CH-EMED-EPR documents.

Only MTP, PRE, DIS and PADV docs can be published. PML and PMLC can only be retrieved from the service.

Referencing external documents

When publishing CH-EMED-EPR documents, all references (from the key elements) shall be known to the eMedication service. All non-key elements are ignored by the eMedication service.

This implies that the metadata cannot contain Reference ids. This option is not supported, and submission of a reference to an existing document is forbidden.

Creation times

Creation time of a document must be equal or greater than the creation time of the last document of the treatment chain, ie. the last published document targeting the treatment (either the original MTP if no other document, or the last document published referencing this treatment).

• Creation time of the document has to be in the past.
• All references to other documents or items have to refer to existing approved non deleted documents.

Rules for each type of document

MTP

• The medication referenced in the MTP (CHEMEDEPRMedicationStatement) should follow some rules. These are detailed in the implementation guide’s treatment guidance page.

PRE

• Each PRE item should refer to an MTP item (CHEMEDEPRMedicationRequest.treatmentplan) that must:
  • Exist (has already been published, and never deleted)
  • Be approved, ie. DocumentEntry.availabilityStatus = approved,
  • Preferably be valid, i.e. the submission date should be within the MTP dosage’s boundsPeriod (CHEMEDEPRDosage.repeat.bounds).
    • If the boundsPeriod is not defined, the entry is considered to be always active.
    • If only a startDate is specified, the MTP is considered to be active if the current date is after that date.
  • Active, ie. CHEMEDEPRDocumentMedicationTreatmentPlan.CHEMEDEPRMedicationStatement.status = active
  • For the same patient.
• Code of medication should match the code of medication of the MTP referenced by the PRE (CHEMEDEPRMedicationRequest.treatmentplan). This rule is not enforced and might be extended in the future.
• If lot number (CHEMEDEPRMedication.batch) is specified in referenced MTP, the one in the PRE (CHEMEDEPRMedicationRequest.medication[x]:medicationReference.batch) should match it. This rule is not enforced and might be extended in the future.

PADV

PADV against a provisional PRE

A “provisional PRE” is a prescription for which the CHEMEDEPRMedicationRequest.status is SUBMITTED or PROVISIONAL and for which a PADV OK has not been completed yet.

• Medication cannot be changed. This rule is not enforced and might be extended in the future.
• Dosage instructions cannot be changed. This rule is not enforced and might be extended in the future.
• Substitution cannot be disallowed if the existing dispense includes one. This rule is not enforced and might be extended in the future.
• Observation code REFUSE cannot be issued.

PADV CANCEL

• Sets status to CANCELED.
• Not allowed against DIS or other PADV documents.

Against MTP

• Also set related prescriptions’ status to CANCELED if their status was not already REFUSED or CANCELED.
• Treatment plan status must be ACTIVE or SUSPENDED.

Against PRE

• Not allowed for prescriptions whose status is already CANCELED or REFUSED.
• Not allowed to target anything else than MTP or PRE

PADV OK

• Sets targeted MTP or PRE status to ACTIVE.
• Against MTP: only allowed for treatment plans with status ACTIVE or SUSPENDED.
• Against PRE: only allowed for prescriptions with status SUBMITTED or PROVISIONAL.
• PADV OK cannot target anything else than MTP or PRE.

PADV CHANGE

• Changes the treatment plan or prescription.
• Can only target MTP or PRE.

Against MTP

• The treatment status must be ACTIVE or SUSPENDED.
• The treatment must not have been prescribed.
• Additionally, the treatment’s status is set to ACTIVE as a result of the aggregation.

Against PRE

• The prescription’s status must not be CANCELED or REFUSED.
• If the prescription’s status is SUBMITTED, the aggregation sets it to ACTIVE as a result.

PADV REFUSE

• Sets status to REFUSED.

Against MTP

• Sets also related prescriptions’ status to REFUSED if the status was not already REFUSED or CANCELED.
• Treatment’s status must be ACTIVE or SUSPENDED.

Against PRE

• The prescription’s status must not be REFUSED, CANCELED or PROVISIONAL.
• Cannot target anything else than MTP or PRE.

PADV SUSPEND

• Sets status to SUSPENDED
• Only allowed to target MTP entries
• The treatment status must be ACTIVE

PADV COMMENT:

• Can target MTP, PRE and DIS entries only.

DIS

• If lot number (batch) is specified in referenced MTP(treatmentPlan) or PRE (prescription), then it should match the one in the DIS if substitution is not allowed. This rule is not enforced and might be extended in the future.

DIS against MTP or PRE + MTP:

• Medication should not be different if substitution is not allowed by PRE. This rule might be extended in the future.
• Dispense should not occur after the end of validity of the PRE document. This rule might be extended in the future.
• Dispense should not occur after the end of the treatment if specified in the prescription item. This rule might be extended in the future.
• If referenced PRE is not provisional, it should be dispensable (that is have status either PROVISIONAL or ACTIVE). This rule is not enforced and might be extended in the future.
• List of active ingredients should be the same than the one in the referenced PRE (prescription). This rule is not enforced and might be extended in the future.
• If the treatment has been prescribed (at least one PRE document has been successfully submitted for it), then any DIS document targeting this treatment must reference one of its prescriptions as well.

Roles

• Patients and their representatives are allowed to publish only the following type of docs:
  • MTP
  • PADV with a COMMENT observation code with no restriction.
  • PADV with any other observation code only when referencing a document published by the same patient or a representative of the same patient.
• Healthcare professionals are allowed to publish only the following types of docs:
  • MTP
  • PRE
  • DIS
  • PADV

Metadata values check

Some values from the DocumentEntry are checked against the document (values in metadata and document must be equal):

Metadata codes per document type

The class and type codes are from the SNOMED CT system: 2.16.840.1.113883.6.96. The system for the formatCode is 2.16.756.5.30.1.127.3.10.10

Replacing a CH-EMED-EPR document

The following rules must be observed when replacing a document:

• Patients and their representatives can only replace a document published by the same patient.
  • representatives are not supported by the service yet.
• Healthcare professionals (HCP) can only replace a document published by himself or by another HCP of same community of affiliation.
  • Current implementation: an HCP can replace a document published by any other HCP. Further rules and possible implementations are under discussion.
• Document administrator may only replace a document published by an HCP of the same community of affiliation.
  • Not implemented in PMP, to be discussed, for now a document admin can replace any document.
• Replacing and replaced documents have to be of the same type (e.g. both MTP documents).
• Replacing and replaced documents have to refer to the same patient.
• Only documents at the end of a treatment chain can be replaced.
• Replaced document must exist in the repository.
• A replacement document must can be linked only to elements of the same medication chain. In case a PRE document is replaced, it may be linked only to elements of the medication chain of the referenced MTP.
• Document administrator can replace any document regardless of who published it.
• Replaced document must be approved (although this is always the case after an initial ITI-41 transaction, documents might become deprecated after another ITI-41 transaction with a replacement association).
• Replaced document must not have deletionStatus = deletionRequested (this is relevant since although it is not the case at the moment with the current implementation, there might be files in the repository flagged for deletion but not deleted yet).

Publishing a PMP-APPC document

This section details the rules applicable to metadata when publishing APPC documents.

Rules for APPC

• Only Patients and their representatives or policy administrators can publish a new APPC document.
  • representatives are not supported by the service yet.
• Only Patients and their representatives can replace their own APPC documents (if it exists).
  • representatives are not supported by the service yet.
• Policy administrators of the reference community of the patient can replace any existing APPC document.
• No APPC for the specified patient exists in the system (unless the published document is a replacement), otherwise the document is refused.
• As for CH-EMED-EPR, APPC documents to be replaced must:
  • Be approved (as before, this is always the case for documents in the PMP repository when they are published, but their status might change to deprecated after a replacement).
  • Not have deletionStatus = deletionRequested.
• APPC document structure is described in Implementation Guide for eMedication architecture in the context of the EPR, section §7.5
  • 1 Description section for free text description of the policy set
  • 1 Target section containing:
    • 1 Resources section containing 1 Resource object pointing to the patient by indicating the EPR-SPID.
    • * Subjects sections each one containing themselves Subject entries each defining 1 “who”. Subject cannot be the patient.
    • * Environments sections each one containing one Environment object limiting the validity period of the policy.
      • Required if at least one Subject refers to an organization or group.
        • Specs state “This section will not be used within this context.”
    • A list of PolicyIdReference or PolicySetIdReference defining the level of access granted to the users identified by the Subjects section.
      • See 7.5 for the list of policies that can be used.
    • * embedded PolicySet sections containing:
      • 1..* Subjects sections containing themselves Subject entries and each defines one “who”.
      • * Environments (same as above)

APPC metadata