Example instance of the patient from master patient index.

UC-AHD-056: cancels a confirmed patient's end-of-life directive (PET). A new version with status entered-in-error is created. The operation accepts no input parameters and answers HTTP 200 with an empty body.

UC-AHD-055: confirms a patient's end-of-life directive (PET). Input is exactly one of: a digitally signed PET as a Binary (signedBinary) or a QuestionnaireResponse and Provenance collection Bundle for paper signing (bundle). Under the stage-1 mock configuration, the digital path parses the ASiC-E container without DigiDoc signature verification and stores it locally instead of DRIT. Where digital signing is not enabled, the digital path responds with HTTP 501.

UC-AHD-058: a healthcare worker adds and confirms a trusted person who signed on paper during the appointment. Input is a collection Bundle with the RelatedPerson and the paper-signing Provenance.

UC-AHD-060: the invitation recipient accepts the trusted person invitation with a digitally signed RelatedPerson (ASiC-E container). Under the stage-1 mock configuration, the operation parses the container without DigiDoc signature verification and stores it locally instead of DRIT. Where digital signing is not enabled, the operation responds with HTTP 501.

UC-AHD-060 alternative flow 2.2.1: the invitation recipient rejects the trusted person invitation. The operation accepts no input parameters.

Custom parameter (UC-AHD-054): last=true returns only the chronologically latest valid counselling decision for the patient and linked persons.

Search for trusted-person invitations (Task) and trusted persons (RelatedPerson) by PET (QuestionnaireResponse) id. The relation runs through the trusted person and is resolved by the PET search service, so expression is deliberately unset.

AHD consultation data stating whether the patient is allowed to sign their decision. If the consultant decides the patient should not be able to sign their document, the consultant must provide a reason.

The actual content of the AHD and the patient's wishes

Bundle of data consisting of questionnaire response and the signature

Binary resource of the AHD questionnaire response in asice container

Data about the signing process of the AHD questionnaire response. Provides info about when the signing occurred, whether the signer was the patient or a capable witness and the signature itself.

Patient can request a trustee who will represent thir wishes when the patient is incapable of doing so. Difference with witness: witness represents the patient in the AHD signing process when the trustee represents the patient's wishes when the AHD has activated.

The patient can request a person to be their representative in the AHD employing process. The request can be made by the patient or a healthcare practitioner and the performer will be the requested trustee.

Bundle of data consisting of information who the trustee is and their signature agreeing to be the patient's representative.

Binary resource of the AHD RelatedPerson in asice container

Data about the signing process when a person agrees to be a patient's trustee represeting their wishes.

If the patient is physically incapable of filling out their AHD document and signing it (while being capable of decision-making), a witness must be provided who will fill out the content in paper form sign the document on their behalf. Difference with trustee: witness represents the patient in the AHD signing process when the trustee represents the patient's wishes when the AHD has activated.

Reference to the content that the trustee is connected with.

Status that shows whether the trustee has accepted the request. The statuses are ootel (Requested), kehtiv (Completed), tagasilükatud (Rejected), tühistatud (Cancelled).

Reference to the witness as a patient from MPI (will be made to Person eventually). This extension points to the witness, so that the witness's name and identity can be resolved from MPI

Reference to the witness if a witness was used in the AHD signing process

Shows whether the AHD content was filled and signed digitally by the patient (via National Health Portal Terviseportaal) or as a paper format by the patient or a witness (digitalized by the practitioner via TJT).

Acceptable statuses for filled out AHD content. In-progress defines AHD that has been started but not finished. Completed states a finished AHD. Entered in error defines AHD that has been cancelled

Status values for consultation to see whether the consultation was completed (final) or cancelled (entered-in-error).

Acceptable languages for AHD. Currently accepting three languages: Estonian, English, Russian

Signer role values are used for Provenance resources in the AHD service. AHD trustee uses Provenance for the signature and the signer role will be the data subject. AHD content may be signed be either the patient (role data subject) or a witness if the patient is incapable (role legal).

The status values for defining the completeness of the request (adding an AHD trustee). Subsection of the FHIR statuses showing if the request is pending (request was sent but has yet to be answered - Requested), if the request is finalized and agreed (Completed), or the request was rejected by the trustee (Rejected).

Status values defining the trustee (partly depends on the request). A subsection of FHIR statuses with Estonian designation. Requested = ootel, Completed = kehtiv, Rejected = tagasilükatud, Cancelled = tühistatud.

Example instance of the counselling observation, where the HCP has deemed patient unfit to sign their AHD. Must provide the reason.

Example instance of the counselling observation, where the HCP has deemed patient fit to sign their AHD. Does not need to describe the observation further.

Example instance of the AHD content and its structure. The questionnaire itself is defined in QRE service.

Example instance of the trustee (related person) who represents patient's wishes according to their AHD.

Example instance of the witness (related person) who represents the patient in the AHD signing.

Example organization where the consultation takes place. Data will come from SPD service

Example healthcare practitioner (doctor) who will conduct the consultation process. Data will come from SPD service