Referral Prescription, published by . This guide is not an authorized publication; it is the continuous build for version 1.0.0 built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/hl7-be/referral/ and changes regularly. See the Directory of published versions
Contents:
This page provides a list of the FHIR artifacts defined as part of this implementation guide.
These are custom operations that can be supported by and/or invoked by systems conforming to this implementation guide.
BeOpApproveAnnex81 |
Creates an approval from an Annex81 proposal |
BeOpRejectAnnex81 |
Rejects an Annex81 proposal |
These define the properties by which a RESTful server can be searched. They can also be used for sorting and including related resources.
BeSPServiceRequestStatusReason |
This SearchParameter enables query of ServiceRequests by the statusReason extension. |
BeSPTaskStatusProfile |
This SearchParameter enables query of Tasks on the combination of status and profile |
These define collections of interrelated resources that are useful to pass around as a group.
BeGDFullReferralPrescription |
Specify to include all useful resources around a ServiceRequest that can be retrieved with the $graph operation. |
These define data models that represent the domain covered by this implementation guide in more business-friendly terms than the underlying FHIR resources.
BeModelAnnex81 |
Logical model describing the model for the Annex81 proposal and approval |
BeModelAssignment |
Logical model with the information for the assignment to a referral prescription of a care provider. |
BeModelNursingPrescription | |
BeModelOrganisationClaim |
Logical model with the information of a claim of an organisation to have the prescription fulfilled by one of its members. |
BeModelReferralPrescription |
Logical model describing the model for the prescription referral. This draft is used in the HL7 Belgian workgroup for referral. |
BeModelTreatmentStatus |
Logical model with the information for the status of the treatment. |
These define constraints on FHIR resources for systems conforming to this implementation guide.
BeAnnex81 | |
BeOrganizationTask |
Subtask to assign the referral task and prescription to one or more members of this organisation |
BePerformerTask |
Subtask performed by one performer |
BeReferralServiceRequest |
The common structure for referral prescription. |
BeReferralServiceRequestNursing |
The nursing profile, generic version. Please note the nursing referral for medication does NOT depend on this generic version but is a FHIR prodfile on a different FHIR resource (MedicationRequest) |
BeReferralTask |
The task that is referred to in the referral prescription (this is the common task for the execution of the prescription). The subtasks per performer can be found in BePerformerTask |
These define constraints on FHIR data types for systems conforming to this implementation guide.
BeNoContainedReference |
A reference disallowing the use of contained references |
BeYearMonthDay |
a datetime of length 10 or empty |
These define constraints on FHIR data types for systems conforming to this implementation guide.
BeFeedbackToPrescriber |
Does the prescriber request feedback? |
BeLatestEndDate |
Request must be performed before |
BePerformerType |
Types of performers that can execute this request |
BeValidityPeriod |
Begin and enddate of the validity of the request |
These define sets of codes used by systems conforming to this implementation guide.
BeReferralCategory |
Codes to define the high level category for a referral prescription. SNOMED-CT codes in this valueset are just a draft proposal to give a general idea - pending an official valueset. |
BeVSAnnex81ReasonCode |
Nurse diagnostics and observations giving cause to the Annex 81 |
BeVSAnnex81StatusReason |
This is the status reason of the Annex 81 |
BeVSPerformerTaskStatusReason |
Codes to explain the current status of a referral prescription. |
BeVSPrescriptionStatusReason |
This is the status reason of the prescription |
BeVSRequestIntent |
The allowed intent codes in the context of referral prescription |
BeVSRequestNoteType |
Types of notes used in a referral prescription |
BeVSRequestedServicesNurse |
Codes indicating the requests that can be asked from a nurse. |
BeVSRequestedServicesNurseDetail |
Codes indicating the request details that can be asked from a nurse. |
BeVSTaskIntent |
The allowed intent codes in the context of tasks in the field of referral prescriptions |
BeVSTreatmentStatusReason |
Codes to explain the current status of a treatment in a referral prescription. |
Body Site |
Body Site |
These define new code systems used by systems conforming to this implementation guide.
BeCSAnnex81StatusReason |
Status reason for the Annex 81 |
BePrescriptionStatusReason |
Status reason for the prescription. Initially defined as supporting CodeSystem for the referral prescription. |
BeTempRequestedService |
Temporary codes for indicating services that can be requested from a Nurse |
BeTempRequestedServiceDetail |
Temporary codes for indicating service details that can be requested from a Nurse |
BeTreatmentStatusReason |
Status reason for the treatment. Initially defined as supporting CodeSystem for the referral prescription. |
These define identifier and/or code system identities used by systems conforming to this implementation guide.
BeNsUhmepShort |
UHMEP userfriendly namingsystem |
BeUnadressedHealthMessageExchangePlatform |
UHMEP naming system |
These are example instances that show what data produced and consumed by systems conforming with this implementation guide might look like.
Example 12: Annex 81 |
Annex 81 proposal |
Example 16: Bladder care |
One Care Prescription |
Example 1b: Colon Cleansing |
One Care Referral Prescription |
Example 24: Non reimbursable prescription |
One Care Referral Prescription |
Example 26: Generic prescription |
One Care Referral Prescription |
Example 2: Digestive System Care |
One Care Referral Prescription |
Example 2b: Digestive System Care |
One Care Referral Prescription |
Example 32: Chronical Psychiatric |
One Care Referral Prescription |
Example 3: Compression therapy |
One Care Referral Prescription |
Example 3b: Compression therapy |
One Care Referral Prescription |
Example 4: Bladder care |
One Care Prescription |
Example 5: Digestive System Care |
One Care Referral Prescription |
Example 5: Digestive System care |
One Care Prescription |
Example 6: Compression therapy |
One Care Prescription |
Example 6: Compression therapy |
One Care Referral Prescription |
Example 9: Wound care |
One Care Referral Prescription |
Nurse | |
Nurse Requester |
Nurse acting as a Requester |
Physician | |
Physician Requester |
Physician acting as a Requester |
Use Case 1.10: see GitHub issue 241 |
On 03/10/2022, the patient who suffers from Parkingson’s disease goes to the doctor (prescriber) who detects that his patient needs assistance with his personal hygiene. The patient is disoriented in time and space and also has nocturnal urinary incontinence and occasional urinary incontinence. The prescriber completes the digital prescription “Assisting with personal hygiene” via the digital prescription. The prescriber makes one attest for disorientation in time and space and another one for nocturnal urinary incontinence and occasional urinary incontinence. The prescriber gives both attests to the patient. The digital prescription cannot be completed without the signature of the prescriber. As all “required signatures conditions” are fulfilled, the PrescriptionStatus is automatically set from Draft to Pending/Active. (In our Case “Active”). The patient assigns his nurse to this prescription via the digital application. The nurse consults the digital prescription he/she is assigned to. On 06/10/2022, the nurse goes to the patient’s home. The patient gives her his two attests. The nurse starts the care following the instructions on the digital prescription. She determines the patient score on a Katz scale (or index) and sends this to the consulting physician for refund determination. |
Use Case 1.11: see GitHub issue 241 |
On 03/10/2022, a patient goes to the doctor (prescriber) who diagnoses kidney failure and a loss of blood pressure. The patient is treated for his disease in a convention center. In order to prevent the loss of residual renal functions, the prescriber (working in the convention center) completes a digital prescription for “chronic peritoneal dialysis” via the digital application. The digital prescription cannot be completed without the signature of the prescriber. As all “required signatures conditions” are fulfilled, the PrescriptionStatus is automatically set from Draft to Pending/Active. (In our Case “Active”). The patient assigns his nurse to this prescription via the digital application. This nurse has made an agreement with the convention center about remuneration and receives orders by the prescriber of the convention center. The nurse consults the digital prescription he/she is assigned to. On 06/10/2022, the patient meets the nurse which follows instructions on prescription and starts the care. |
Use Case 1.2: see GitHub issue 222 |
On 03/10/2022, Patient who has recently had chemotherapy via “implantable venous access port catheter” goes to doctor who prescribes a catheter dressing change and rinse of his/her “implantable venous access port catheter” (via CareSet ServiceRequest- group- and Device) with NaCl 0.9% given by a nurse. Furthermore, the needle needs to be changed by a Huber needle 20G x 25mm. |
Use Case 1.2: see GitHub issue 222 | |
Use Case 1.2: see GitHub issue 222 | |
Use Case 1.5: see GitHub issue 241 |
On 03/10/2022, the patient consults his doctor (prescriber) and admits he has difficulty following his medication-treatment. The prescriber detects no valid reason (“medical reason” via CareSet ProbCode) for refundable medication preparation (appendix 81) so he tells his patient that the asked help for his medication preparation will not be refundable. The patient still wants help even if it is not refundable. The prescriber completes the digital prescription for “medication prefill preparation – not refundable”. The digital prescription cannot be completed without the signature of the prescriber. As all “required signatures conditions” are fulfilled, the PrescriptionStatus is automatically set from Draft to Pending/Active. (In our Case “Active”). The prescriber also prepares the medication scheme so the nurse that will be assigned to this prescription has all the necessary information to prepare the medication and fill the pillbox of the patient. He gives the medication scheme to the patient so that he can give it to his nurse. The patient assigns a nurse to his prescription via the digital application. The assigned nurse consults the digital prescription via the digital application. On 06/10/2022, the nurse goes to the patient who gives her his medication scheme. On a weekly basis, the nurse goes to the patient to prepare his medication and fill his pillbox according to the medication scheme received. This service is not refundable, and the nurse charges the patient himself. |
Use Case 1.6: see GitHub issue 241 |
On 03/10/2022, a patient goes to a doctor (prescriber) and is diagnosed as a diabetic type 1. The patient is treated for his diabetes type 1 in a specialised convention center. This center has a convention about reimbursement with NIHDI. The patient needs some support at home and the convention center delegates care to a home nurse. The convention center has an agreement with this home nurse about remuneration. The convention center physician (prescriber) makes a digital prescription “Diabetes education via convention center” via the digital application and specifies the type of education needed by the patient: “diabetic self-management”. The digital prescription cannot be completed without the signature of the prescriber. As all “required signatures conditions” are fulfilled, the PrescriptionStatus is automatically set from Draft to Pending/Active. (In our Case “Active”). The convention centre enters the prescription ID in the digital application and, with consent of the patient, assigns their diabetes educator as caregiver of the prescription. On 06/10/2022, the patient goes to the convention centre and follows his class on “diabetic self-management”. |
Use Case 1.7: see GitHub issue 241 |
On 03/10/2022, a 55-year-old patient who has diabetes type 2, a BMI < 30, arterial hypertension and a care model (zorgmodel) goes to a doctor (prescriber) who detects the need for diabetes education for the patient. The prescriber prescribes 4 individual education sessions given by a nurse or a diabetes educator. The prescriber completes the digital prescription “Diabetes education with care model (preliminary path) – follow up of patients with diabetes type 2”. The digital prescription cannot be completed without the signature of the prescriber. As all “required signatures conditions” are fulfilled, the PrescriptionStatus is automatically set from Draft to Pending/Active. (In our Case “Active”). The patient assigns his nurse to this prescription via the digital application. The nurse consults the digital prescription he/she has been assigned to. On 06/10/2022, the nurse meets the patient for a first diabetes education individual session. The three other individual sessions are planned (within the current year). |
Use Case 1.8: see GitHub issue 241 |
On 03/10/2022, a type 2 diabetic patient who has insulin treatment, a care path contract, and a complete global medical file (GMF) goes to a doctor (prescriber) who recommends to his patient 5 individual ½ hour education sessions about the “use of a blood glucose meter”. This session needs to be given by a diabetes educator (with recognition by NIHDI) at the residence of the patient to be refundable. The prescriber completes the digital prescription “Diabetes education with care path” via the digital application. The digital prescription cannot be completed without the signature of the prescriber. As all “required signatures conditions” are fulfilled, the PrescriptionStatus is automatically set from Draft to Pending/Active. (In our Case “Active”). The patient assigns his nurse (who is a certified diabetes educator) to this prescription via the digital application. The diabetes educator consults the digital prescription he/she is assigned to. On 06/10/2022, the diabetes educator goes to the patient’s home (with the blood glucose meter) for a first ½ hour individual diabetes education session about “use of a blood glucose meter”. The four other individual sessions are planned (within the current year). |
Use Case 1.9: see GitHub issue 241 |
On 03/10/2022, a diabetic patient goes to his doctor (prescriber) because he has some troubles about the self-management of his treatment. The prescriber prescribes to his patient 10 sessions of ½ hour each of “education for self-care”. The prescriber fills in the digital prescription “Education and self-care for diabetes patients without a care path” via the digital application. The digital prescription cannot be completed without the signature of the prescriber. As all “required signatures conditions” are fulfilled, the PrescriptionStatus is automatically set from Draft to Pending/Active. (In our Case “Active”). The patient assigns his nurse to this prescription via the digital application. The nurse consults the digital prescription he/she is assigned to. On 06/10/2022, the nurse meets the patient for a first diabetes education session. The nine other sessions are planned (within the current year). |
Use Case 5a |
On 02/07/2023, Dr. Hendrickx wants the nurse to take a blood test from Mrs. Dupont in order to analyze her glucose and cholesterol following general fatigue. He writes a prescription for the nurse with the blood test to be done on Mrs. Dupont. The nurse takes Mrs. Dupont’s blood test the next day. Important note: The part specifying that the analysis request concerns Mrs. Dupont’s glucose and cholesterol should not be on this prescription. This is linked to the prescription for the Lab. |
These are resources that are used within this implementation guide that do not fit into one of the other categories.