Description Doselink V1.1a
Content
- Introduction.
- Description process and XML-layout dosage schedule.
2.1 Process description.
2.2 Description layout according to MultidoseExport.v1.1.XSD.. 5
1. Introduction
The purpose of the Dose’Link process is to send dosage schedules from care institutions (e.g. rest and care homes) via eHealtbox and thereafter to import them in the default pharmacy software. This enables the pharmacy to use the dosage schedule in its software for preparing medication doses or creating production files for automated dispensing systems.
Dose’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 dosage schedules and to which ehealthID the schedules should be sent. The name of the files and the functional type is used to determine which files can be imported.
The pharmacy imports the files in its software. The file name contains elements that allow the software to determine what to do with the available files. It contains two characters (MD (= multidose) for dosage schedules) referring to the file type, the identification of the elderly care home and the identification of the pharmacy.
2. Description process and XML-layout dosage schedule
2.1 Process description
The file format chosen is XML with UTF-8 encoding, according to TherapieExport.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 )
zzzzzzzzzzzzzzzz (11 or 16) = sender (16 for care homes, 11 for pharmacies )
yyyymmdd = transaction date
hhmmss = transaction time
tt = transaction type: for a dosage schedule this is always ‘MD’
When the file is sent via eHealthbox, a functional type will be provided. For dosage schedules, this is HL-MD-X (which refers to HomeLink MultiDise XML). (If you import TXT files directly into the HDmedi robotic dispensing system, HL-MD-T is used)
2.2 Description layout according to MultidoseExport.v1.1.XSD
2.2.1 Multidose
Section necessary: Yes
Restriction: 1 per file; this is the root element.
Fieldname | Type | Description | Manadtory? | Max Length | Type | Specification |
SenderNr | Simple | Sender number | Yes | 16 | A | Identification number 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. |
SenderName | Simple | Sender name | Yes | 35 | A | Name of the care home |
ReceiverNr | Simple | Receiver number | Yes | 16 | A | Identification number of the receiver. 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 APB number of the pharmacy |
ReceiverName | Simple | Receiver name | Yes | 35 | A | Name of the pharmacy |
CreationDateTime | Simple | Creation date and time | Yes | 14 | N | YYYY-MM-DDTHH:MM:SS e.g. 2014-10-09T12:35:55 |
StartDate | Simple | Start date | Yes | 8 | N | YYYY-MM-DD |
EndDate | Simple | End date | Yes | 8 | N | YYYY-MM-DD |
SortOrder | Simple | Order | No | 70 | A | Determines the order according to which the therapy schedule should be processed. |
Patients | Complex, see 2.2.2 |
| Yes |
|
|
|
This tag is used to determine the order in which the file should be processed. It is mostly important when working with an automated dispensing system for which the pharmacy software creates a production file. The sorting order will determine the production order of the medication bags.
If a sorting order is given, normally the order given by the care home will be used as master.
The contents of this field consist of maximum 7 parts separated by commas, starting from Location1 to Location5, plus Date and Hour:
- Location 1 to 5 from the section <Patient>
- Date and hour refer to <AdministrationDate> and <AdministrationHour> from the section <Administration>
Example 1:
Location1 = Building A,
Location2 = 1st floor,
Location3 = Section 1,
Location4 = 101 (room number),
Location5 = A (Bed A)
Example 2:
Suppose the institution wants the medication dispensed in the following order: Floor, Room, Bed, Date, Hour
The field <SortOrder> will need to be filled as follows: “Location2, Location4, Location5, Date, Hour”
Remarks:
- It is not mandatory to use all 5 location for the sorting
- Date and hour don’t necessary need to follow each other
- If <SortOrder> is left empty or hasn’t been provided, the pharmacy software will need to determine the sorting.
2.2.2 Patients
Section necessary: Yes
Restrictions: 1 per file
Explanation: This section contains all patients (residents) for whom a dosage schedule is being provided.
Fieldname | Type | Description | Mandatory? | Max length | Type | Specification |
Patient | Complex, see 2.2.3 |
| Yes |
|
|
|
2.2.3 Patient (Resident)
Sectie necessary: Yes
Restriction: 1 per resident
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 |
HomeId | Simple | HomeId | No | 20 | A | Patient ID used in the care home software |
Location1 | Simple | Location1 | No | 40 | A | Highest level used to determine the location (e.g. Building A) |
Location2 | Simple | Location2 | No | 40 | A | 2nd level to determine the location (e.g. 1st floor) |
Location3 | Simple | Location3 | No | 40 | A | 3d level to determine the location (e.g. Section 1) |
Location4 | Simple | Location4 | No | 40 | A | 4th level to determine the location (e.g. room number) |
Location5 | Simple | Location5 | No | 40 | A | 5th level to determine the location (e.g. Bed A) |
Birthdate | Simple | Date of birth. | No | 8 | N | YYYYMMDD |
DoctorName | Simple | Name doctor | No | 40 | A | Name of doctor treating the patient |
DoctorMedRegNr | Simple | INAMI/RIZIV number doctor | No | 16 | A | Patient serial number (Internal number from sender). Possible values : NISS of the patient or INAMI of the home |
ShortStay | Simple | Short stay | No | 1 | N | 0 = not a short stay resident 1 = short stay resident |
PatientUnidose | Simple | PatientUnidose | No | 1 | N | 0 or 1 (1= multi dose management allowed fort his resident, 0 = no multi dose management allowed) |
PatientUnidosePacket | Simple | PatientUnidosePacket | No | 1 | N | 0= before food 1= with food 2= after food Used for all medication for this patient |
Products | Complex see 2.2.4 |
| Yes |
|
|
|
2.2.4 Products
Sectie noodzakelijk: Ja
Uitleg: komt 1x per patient voor
Fieldname | Type | Description | Mandatory | Max length | Type | Specification |
Product | Complex, see 2.2.5 |
| Yes |
|
|
|
2.2.5 Product (medicament)
Sectie necessary: Yes
Explanation: This section will be repeated for each medication in the dosage schedule
Fieldname | Type | Description | Mandatory | Max length | Type | Specification |
ProductId | Simple | CNK | Yes | 20 | N | CNK code of the package or CNK code given by the pharmacy to a magisterial preparation |
ProductIdHome | Simple | IdMedicament | Yes | 20 | A | Unique number for the medication used in the institution |
Speciality | Simple | Speciality | Yes | 1 | N | 0= magisterial preparation 1= proprietary drug with CNK |
Description | Simple | Description | Yes | 120 | N | Description of the medication |
Formula | Simple | Formule | No | Memo | N | Formula of the magisterial preparation |
TabletUnidose | Simple | TabletUnidose | No | 1 | N | 0 or 1 (1= multi dose product, 0 = not a multi dose product |
TabletUnidosePacket | Simple | TabletUnidosePacket | No | 1 | N | 0= before food 1= with food 2= after food Used for this medication |
PrescriptionId | Simple | VoorschriftId | No | 30 | N | ID of the prescription |
StartTreament | Simple | StartPosologie | No | 8 | N | YYYYMMDD |
StopTreatment | Simple | StopPosologie | No | 8 | N | YYYYMMDD |
Administrations | Complex See 2.2.6. |
| Yes |
|
|
|
2.2.6 Administrations (Toedieningen)
Sectie necessary: Yes
Restriction: 1 per product
Explanation: List of medication to be packaged
Fieldname | Type | Description | Mandatory | Max length | Type | Specification |
Administration | Complex, see 2.2.7 |
| Yes |
|
|
|
2.2.7. Administration
Sectie necessary: Yes
Restriction: none; this section can be repeated.
This section will be repeated for each administration moment, and this for the entire period for which the file has been created.
E.g. If the file has been created for 7 days, and the medication needs to be taken 3 times per day, this will result in 21 lines.
Fieldname | Type | Description | Mandatory | Max length | Type | Specification |
Qty | Simple | Quantity | Yes | 8 | N | Number of units to bef administered. 2 decimal places allowed. A quarter tablet will be 0.25 One and a half tablet will be 1.50 |
AdmDate | Simple | Administration date | Yes | 8 | N | YYYYMMDD |
AdmHour | Simple | Administration hour | Yes |
| xs:time | HH:MM:SS |