ALL MODIFICATIONS COMPARED TO VERSION 1.5 ARE MARKED IN RED (SEE SECTION 2.2.6 & SECTION 3).
Content
1. Introduction.
2. Process description and XML layout order
2.1 Process description.
2.2 Description layout in accordance with HomesExport.v.1.6.XSD.
3. Import order confirmation.
1. Introduction
The purpose of the Order’Link process is to send medication orders from care institutions (e.g. rest and care homes) via eHealthBox and thereafter to process prescriptions and import them in the default pharmacy software. This allows for simple and transparent pricing and invoicing. The follow up of these prescriptions is done by the pharmacist in his default software (patient credit file management, attestation management, invoicing etc.).
Order’Link is part of the Home’Link Pharmacy v2 protocol. Home’Link consists of all interface protocols between care homes and pharmacies. It’s the second version of the protocol which was initially launched in 2007. In the second version, both functional enhancements and secure communication of patient data were important. In the roadbook for the digitization of elderly care homes, the Flemish government and all Flemish professional federations addressed the importance of secure electronic communication between care providers and linked the financing of the eWZC project Pad-02 with the use of eHealthbox.
Care homes register per pharmacy whether they use electronic orders and to which ehealthID the orders should be sent. The name of the files and the functional type is used to determine which files can be imported.
The pharmacist imports the order in his software. The file name contains elements that allow the software to determine what to do with the available files. It contains two characters (OR for order) referring to the file type, the identification of the elderly care home and the identification of the pharmacy.
2. Process description and XML layout order
2.1 Process description
The file format chosen is XML with UTF-8 encoding, according to HomesExport.XSD
File name:
The name of the interface files always needs to be built according to the following structure:
bbbbbbbbbbbbbbbb_zzzzzzzzzzzzzzzz_yyyymmddhhmmss_tt.xml
where
bbbbbbbbbbbbbbbb (11 or 16) = receiver (16 for care homes, 11 for pharmacies [1])
zzzzzzzzzzzzzzzz (11 or 16) = sender (16 for care homes, 11 for pharmacies[2])
yyyymmdd = transaction date
hhmmss = transaction time
tt = transaction type: for an order this is always ‘OR
2.2 Description layout in accordance with HomesExport.v.1.6.XSD
2.2.1 Order
Section necessary: Yes
Restriction: 1 per file; this is the root element.
Fieldname | Type | Description | Mandatory | Max. length | Type | Specification |
SenderNr | Simple | Number of the sender | Yes | 16 | A | Identification numbers of the sender. These are the same characters as used for the sender in the file name. At the left side, the number needs to be completed with leading zeroes. Spaces and special characters need to be removed. This is the INAMI number of the care home. |
Ordernr | Simple | Order number | Yes | 20 | A | This is the number of the order in the format YYYYMMNNNNNN (YYYY=year / MM=month / NNNNN=serial number per month).This is necessary to book the confirmation. |
SenderName | Simple | Name of the sender | Yes | 35 | A | This field is used in order to quickly recognize who the sender is in overview lists. |
DeliveryGroup | Complex, see 2.2.2 |
| Yes |
|
|
|
2.2.2 DeliveryGroup
Section necessary: Yes
Restriction: none
Explanation: This section correlates with an order. Preferably, this section will only occur once per order file.
Fieldname | Type | Description | Mandatory | Max length | Type | Specification |
Date | Simple | Date | Yes | 8 | A | Order date, format YYYYMMDD |
Id1 | Simple | Id number 1 | No | 3 | A | Used for additional refinement of the destination of the products. Leave this empty. |
Id2 | Simple | Id number 2 | No | 2 | A | Used for additional refinement of the destination of the products. Leave this empty. |
Id3 | Simple | Id number 3 | No | 10 | A | Used for additional refinement of the destination of the products. Leave this empty. |
Customer | Complex, see 2.2.3 |
| Yes |
|
|
|
Based on the 3 ID numbers; lists can be displayed and printed in the care home module. This section can be used to sort different institutions (customers) in order to ensure an efficient rounds management.
E.g.: Id1=Region, Id2=unused, Id3=unused.
2.2.3 Customer
Section necessary: Yes
Restriction: 1 per Delivery Group
Explanation: This is the care home. Since orders are being created per care home, this section will only occur once per file.
Fieldname | Type | Description | Mandatory | Max Length | Type | Specification |
Id | Simple | Id | Ja | 16 | A | Customer serial number: This is the code that will be used in the feedback from the pharmacy to the care home. This is the INAMI number of the care home. |
Name | Simple | Customer name | Ja | 35 | A | Customer identification |
Address | Simple | Address | No | 35 | A | Customer address |
Postalcode | Simple | Postal code | No | 8 | A | Postal code of the customer |
City | Simple | Place | No | 35 | A | Place name customer |
CompNr | Simple | Company number | No | 16 | A | This is the company number of the care home |
DeilveryCustomer | Complex see 2.2.4 |
| Ja |
|
|
|
In most cases, the customer name and the sender name will be the same. As a consequence, there will be only one customer record per file.
2.2.4 DeliveryCustomer
Section necessary: Yes
Explanation: This section should be repeated per department. Consequently, residents should be grouped per department.
Fieldname | Type | Description | Mandatory | Max length | Type | Specification |
Id1 | Simple | Department | No | Variable | A | Department code |
Id2 | Simple | Id number 2 | No | Variable | A | Used for additional refinement of the product destination. |
Id3 | Simple | Id number 3 | No | Variable | A | Used for additional refinement of the product destination. |
Customer | Complex, see 2.2.5 |
| Yes |
|
|
|
Based on the 3 ID numbers; lists can be displayed and printed in the care home software.
2.2.5 Patient
Section necessary: Yes
If an institution needs to place an order for their internal pharmacy, i.e. not related to a resident, a patient record should be created, based on information about the institution. If this order is for the care home, we will use its INAMI number as patient number.
Fieldname | Type | Description | Mandatory | Max Length | Type | Specification |
Id | Simple | Id | Yes | 20 | A | Patient serial number (Internal number from sender). Possible values : NISS of the patient or INAMI of the home |
Name | Simple | Last name | Yes | 48 | A | Last name of the patient |
Firstname | Simple | First name | Yes | 24 | A | First name of the patient |
PatMut | Simple | Health insurance fund | No | 3 | N | Health insurance fund : value between 100 and 999. |
Code1 | Simple | CG1/CT1 | No | 3 | N | Insurability code 1 |
Code2 | Simple | CG2/CT2 | No | 3 | N | Insurability code 2. Base on the Health insurance fund, insurability code 1 and insurability code 2, the refund category can be determined. E.g. Active persons, NMBS-employees, WIGW (widows, people with disabilities, orphans..) |
InsCompNr | Simple | Registration number | No | 13 | A | Registration number health insurance fund (Stamnummer/Numéro de matriculation) |
INSZNr | Simple | Social security number. | No | 11 | N | Social security number (rijksregisternummer/numéro de register national) |
NrSisCard | Simple | NrSisKaart | No | 11 | A | SIS card number: obsolete |
EndInsur | Simple | End date insurability | No | 8 | A | End date insurability, YYYYMMDD |
DateRead | Simple | Date read | No | 8 | A | Date the SIS card has been read, YYYYMMDD obsolete |
Certificate | Simple | Certificate | No | 32 | A | Certificate SIS-card: obsolete |
VerInsur | Simple | Version insurability | No | 2 | A | Version insurability |
Birthdate | Simple | Date of birth | No | 8 | A | Date of birth, format YYYYMMDD |
Sex | Simple | Sex | No | 1 | N | 0 = unknown, 1 = male, 2 = female |
Code | Simple | Code | No | 1 | A | Out of use |
Location | Simple | Location | No | 8 | A | Room/bed |
ShortStay | Simple | Short stay resident | No | 1 | N | 0 = not a short stay resident 1 = short stay resident |
Prescription | Complex See 2.2.6 |
| No |
|
| Orders with prescription |
Productlist | Complex See 2.2.12 |
| No |
|
| Orders without prescription |
2.2.6 Prescription
Sectie necessary: No
Explanation: List of ordered prescription medication
The section prescription is mandatory if the file contains product lines and a doctor element. If there is no doctor element, the products for one and the same patient will be added to a ‘product list’. In the file, this list will be added to the next element.
This section will be repeated per prescription.
Fieldname | Type | Description | Mandatory | max. Lengte | Type | Explanation |
PrescType | Simple | Type of prescription | Yes | 1 | N | 1 = prescription immediately available. This type should be used if the RID is known, or if paper prescriptions are used. 2 = prescription to be added later (invoicing will be suspended). This type should be used if the RID is not known. 3 = Post-prescription: This type should be used if the previous prescription did not contain a RID. In this case, the fields PrescNr, RecipeID and PreviousOrder are mandatory. |
Property | Simple | Property | No | 2 | A | Out of use |
PrescNr | Simple | Prescription number | No | 36 | AN | This is the internal prescription number and is preferably a guid. If PreviousOrder contains a value, this should be the same number as the original prescription number. |
RecipeID | Simple | Recip-e ID | No | 12 | AN | This is the Recip-e ID (RID) as supplied by the EMD. This field contains no value if the prescription has not been validated by a doctor, or if this concerns a paper prescription. |
PreviousOrder | Simple | Previous order number | Nee | 20 | N | This is mandatory if PrescType = 3. In that case this is the original ordernumber. This product does not have to be delivered anymore, but is only to inform the pharmacy., so he can add the RID for that order. |
TicketNr | Simple | TicketNr | No | 10 | N | Ticket Number: this will not be supplied. |
Doctor | Complex. Zie 2.2.8 |
| Yes |
|
| Prescribing doctor |
Products | Complex Zie 2.2.7 |
| No |
|
| List of medication that belong to the official medication (with CNK) |
Preparations | Complex Zie 2.2.10 |
| No |
|
| List of preparations |
This record is used to indicate the description of a prescription.
When a specific proprietary medicinal product can only be used once per prescription, we assume that the doctor is informed about this, and that the prescriptions have been composed according to the legal requirements concerning refundability. In other words, the physical prescriptions should match the electronic prescriptions.
For example: A patient needs 2 x CLAMOXYL and 1 x PERDOLAN. This results in 1 prescription for CLAMOXYL and PERDOLAN and a second prescription for 1 x CLAMOXYL.
The institution also has the option to make a separate prescription for each medicine. In this example, we will get 3 prescriptions.
2.2.7 Products
Fieldname | Type | Description | Mandatory | Max length | Type | Specification |
Product | Complex Zie 2.2.9 |
| Ja |
|
|
|
2.2.8 Doctor
Section necessary: Yes
Restriction: 1 per Prescription
If this section is not available, we will use a Productlist.
Fieldname | Type | Description | Mandatory | Max length | Type | Specification |
Name | Simple | Name | Yes | 20 | A | Name of the doctor |
MedRegNr | Simple | INAMI Nr | Yes | 11 | A | INAMI Nr of the doctor |
2.2.9 Product (proprietary medicinal products)
Section necessary: No
Remark: All product tags in a prescription are grouped under a ‘Products’ main tag.
Fieldname | Type | Description | Mandatory | Max length | Type | Specification |
Id | Simple | Id | Yes | 20 | A | Unique number for the product used in the institution. |
ProdId | Simple | CNK | No | 7 | N | CNK-code of the package |
Description | Simple | Description | No | 32 | A | Product description èThis may not match the description used by the pharmacy. Do not use this as search key. |
Quantity | Simple | Quantity | Yes | 3 | N | Value between 1 and 999 |
CatDeliv | Simple | Delivery category | No | 1 | A | A,B,C,X,S,D; category of refundable proprietary medicinal products. This is a.o. necessary to determine the attestation type. Do not use this. |
PP | Simple | Public price | No | 8 | N | Value in eurocents. This price will not be used to determine the price in the pharmacy software. For informative purposes. |
RP | Simple | Price to be paid by patient | No | 8 | N | Idem; (RP= RemgeldPrijs, Remboursement prix.) Do not use this |
Attest | Simple | Attestation available | No | 1 | N | 1 = available, 0 = not available |
AttestNr | Simple | Attestation number | No | 16 | A | The full attestation number, if known. |
ExpDate | Simple | Expiration date | No | 8 | A | The attestation expiration date, format YYYYMMDD |
CatException | Simple | Exception category | No | 1 | A | A = accident at work, '*' = sticker missing, '', In case of A or *, the full price must be paid. Do not use this. |
Poso | Simple | Posology | No | 64 | A | Text concerning the posology which needs to be printed on the labels. è This will not be exported for the time being because of the complexity. |
DCI | Simple | Prescription by substance name | No | 1 | A | 1 = prescription by substance name, 0 = not a prescription by substance name This wil be always be ‘0’. This determines that if a doctor prescribes medication by substance name, the pharmacy may choose an alternative.[3] |
Unidose | Simple | Unidose | No | 1 | N | 0 = not unidose, 1 = unidose |
OrderLineUId | Simple | Order line | No | 5 | N | This is the order line on the order. Starts with 1 and continues throughout the entire order. |
If the value in the field ‘Attest’ = ‘1’ and there is no value in the field ‘AttestNr’, this means that the attestation is missing, and that the prescription will be suspended for invoicing.
2.2.10 Preparations
Fieldname | Type | Description | Mandatory | Max length | Type | Specification |
Product | Complex See 2.2.11 |
| Ja |
|
|
|
2.2.11 Preparation
Remark: All preparation tags in a prescription are grouped under a ‘Preparations’ main tag.
Fieldname | Type | Description | Mandatory | Max length | Type | Specification |
Id | Simple | Id | Yes | 20 | A | Internal number used by the pharmacy for the preparation. Possibly, this is unknown for the first order, so this will be empty for the first order for this magisterial preparation. The pharmacy will supply the care home with the number, so it can be used on following orders. |
Description | Simple | Description | Yes | 32 | A | Description of the preparation |
Quantity | Simple | Quantity | Yes | 4 | N | Quantity to deliver: If this is 1, the total quantity in the default formula will be used. In other cases, the required quantity will be deduced from the default formula. |
Unit | Simple | Unit | No | 1 | N | 0 = pieces, 1 = gram, 2 = ml/cc |
PP | Simple | Public Price | No | 8 | N | Value in eurocents. This price will not be used to determine the price in the pharmacy software. For informative purposes.. |
RP | Simple | Price to be paid by patient | No | 8 | N | Idem; (RP= Remgeldprijs, Remboursement prix.) Do not use this |
Attest | Simple | Attestation | No | 1 | N | 1 = available, 0 = not available |
Memo | Simple | Memo | No | Variable | A | Free comment field. Can e.g. be used for the description of the preparation (ingredients + amount & unit) + attestation number,+ attestation validity date. |
Poso | Simple | Posology | No | 64 | A | Text concerning the posology which needs to be printed on the labels. Do not use this |
CatException | Simple | Exception category | No | 1 | A | Exception category. Do not use this |
NrInstitute | Simple | Institue number | No | 5 | A | Internal number used by institution |
Unidose | Simple | Unidose | No | 1 | N | 0 = not unidose, 1 = unidose |
OrderLineUId | Simple | Order line | No | 5 | N | This is the order line on the order. Starts with 1 and continues throughout the entire order. |
The import module used by the pharmacy contains a table where the description of the link between the preparation numbers of the pharmacy and the institution is stored. The customer ID will also be used here. One single pharmacy can be the supplier for multiple institutions, which all have their own internal numbering. Internal numbers will be unique in the institution, but this is not necessarily the case across multiple institutions. When a preparation has been ordered, it will first be looked up in this table.
If the ID number does not exist yet, the preparation will appear in a list of unknown preparations. When the pharmacist creates this formula in his default software package, he can link this via the care home module to the internal number used by the institution.
2.2.12 Productlist
Section necessary: No
Explanation: This is the list of non-prescription medication.
Fieldname | Type | Description | Mandatory | Max Length | Type | Specification |
TicketNr | Simple | TicketNr | No | 10 | N | Ticket number |
Product | Complex See 2.2.9 |
| No |
|
| List of proprietary medicinal products (with CNK) |
Preparations | Complex See 2.2.11 |
| No |
|
| List of preparations |
Ticket numbers are being assigned at the moment when the import occurs. Therefore, they will never exist as tags.
2.2.13 Proprietary medicinal products
Remark: All product tags in the product list are grouped under a ‘Products’ main tag.
Fieldname | Type | Description | Mandatory | Max length | Type | Specification |
Id | Simple | Id | Yes | 20 | A | Unique number for the product used in the institution. |
ProdId | Simple | CNK | No | 7 | N | CNK-code of the package |
Description | Simple | Description | No | 32 | A | Product description èThis may not match the description used by the pharmacy. Do not use this as search key. |
Quantity | Simple | Quantity | Yes | 3 | N | Value between 1 and 999 |
CatDeliv | Simple | Delivery category | No | 1 | A | A,B,C,X,S,D; category of refundable proprietary medicinal products. This is among others. necessary to determine the attestation type. Do not use this. |
Attest | Simple | Attestation available | No | 1 | N | 1 = available, 0 = not available |
AttestNr | Simple | Attestation number | No | 16 | A | The full attestation number, if known. |
ExpDate | Simple | Expiration date | No | 8 | A | The attestation expiration date, format YYYYMMDD |
Poso | Simple | Posology | No | 64 | A | Text concerning the posology which needs to be e printed on the labels. è This will not be exported for the time being because of the complexity. |
DCI | Simple | Prescription by substance name | No | 1 | A | 1 = prescription by substance name, 0 = not a prescription by substance name This will be always be ‘0’. This determines that if a doctor prescribes medication by substance name, the pharmacy may choose an alternative.[4] |
Unidose | Simple | Unidose | No | 1 | N | 0 = not unidose, 1 = unidose |
OrderLineUId | Simple | Order line | No | 5 | N | This is the order line on the order. Starts with 1 and continues throughout the entire order. |
If the value in the field ‘Attest’ = ‘1’ and there is no value in the field ‘AttestNr’, this means that the attestation is missing, and that the prescription will be suspended for invoicing.
2.2.14 Preparation
Remark: Remark: All preparation tags in a product list are grouped under a ‘Preparations’ main tag.
Fieldname | Type | Description | Mandatory | Max length | Type | Specification |
Id | Simple | Id | Yes | 20 | A | Internal number used by the pharmacy for the preparation. Possibly, this is unknown for the first order, so this will be empty for the first order for this magisterial preparation. The pharmacy will supply the care home with the number, so it can be used for following orders. |
Description | Simple | Description | Yes | 32 | A | Description of the preparation |
Quantity | Simple | Quantity | Yes | 4 | N | Quantity to deliver: If this is 1, the total quantity in the default formula will be used. In other cases, the required quantity will be deduced from the default formula. |
Unit | Simple | Unit | No | 1 | N | 0 = pieces, 1 = gram, 2 = ml/cc |
Attest | Simple | Attestation | No | 1 | N | 1 = available, 0 = not available |
Memo | Simple | Memo | No | Variable | A | Free comment field. Can e.g. be used for the description of the preparation (ingredients + amount & unit) + attestation number,+ attestation validity date. |
Poso | Simple | Posology | No | 64 | A | Text concerning the posology which needs to be printed on the labels. Do not use this |
CatException | Simple | Exception category | No | 1 | A | Exception category. Do not use this |
NrInstitute | Simple | Institue number | No | 5 | A | Internal number used by institution |
Unidose | Simple | Unidose | No | 1 | N | 0 = not unidose, 1 = unidose |
OrderLineUId | Simple | Order line | No | 5 | N | This is the order line on the order. Starts with 1 and continues throughout the entire order. |
3. Import order confirmation
When using eHealthbox, the order confirmation becomes obsolete. You can use the message status instead.
[1] The RIZIV-INAMI-number is used for care homes. The length of this number is variable, depending on the type of home, and needs to be completed with leading zeroes up to 16 positions.
The APB-number is used for pharmacies. The length of this number is 6 characters. It needs to be completed with leading zeroes up to 11 positions.
[2] The RIZIV-INAMI-number is used for care homes. The length of this number is variable, depending on the type of home, and needs to be completed with leading zeroes up to 16 positions.
The APB-number is used for pharmacies. The length of this number is 6 characters. It needs to be completed with leading zeroes up to 11 positions.
[3] For a prescription by substance name, a CNK will still be supplied. This happens because the care home needs to know how many doses will be delivered so that they can calculate how many prescriptions need to be created until the next doctor visit. In practice, the pharmacy needs to use the CNK linked in the prescription by substance name.
[4] For a prescription by substance name, a CNK will still be supplied. This happens because the care home needs to know how many doses will be delivered so that can calculate how many prescriptions need to be created until the next doctor visit. In practice, the pharmacy needs to use the CNK linked in the prescription by substance name.
0 Comments