eWZC PAD-02: Home’Link Apotheek v. 2
Beschrijving interface Doseerlink
versie 1.1a
Inhoudstafel
1. Inleiding. 3
2. Description process en XML-layout opmaak bestelling. 4
2.1 Beschrijving proces. 4
...
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.
...
Het doel van dit proces is om doseerschema’s van instellingen (bv. WZC’s) te versturen via eHealthBox en vervolgens te importeren in het standaard apotheekpakket. Hierdoor kan de apotheek het doseerschema gebruiken om vanuit de apotheeksoftware klaar te zetten of het bestand aanmaken voor de verdeelkast.
We noemen dit “Doseerlink”. De Doseerlink maakt deel uit van het Home’Link Apotheek v2 protocol. De Home’Link omvat alle interface protocollen tussen instelling en apotheek. Het is de tweede versie van het protocol dat initieel in 2007 gelanceerd werd, waarbij naast functionele uitbreidingen ook de beveiligde communicatie van deze medische patiënten gegevens belangrijk is. De Vlaamse overheid en alle Vlaamse beroepsfederaties hebben in het roadbook voor de informatisering van WZC het belang van beveiligde elektronische communicatie tussen zorgactoren toegelicht en de financiering van het eWZC project Pad-02 gekoppeld aan het gebruik van de eHealthbox.
De instellingen houden per apotheker bij of de schema’s elektronisch worden verstuurd en naar welke eHealthID ze verstuurd moeten worden. De naamgeving van de bestanden en het type wordt gebruikt om te herkennen welke bestanden opgehaald mogen worden.
De apotheker neemt initiatief vanuit zijn pakket om de schema’s op te halen. Dit gebeurt op basis van de herkenning op naam van de beschikbare bestanden. In de naam zit het type verwerkt via 2 karakters (MD (=multidose) voor doseerschema’s), identificatie rustoord en identificatie apotheker.
2. Description process en XML-layout opmaak bestelling
2.1 Beschrijving proces
Als bestandformaat werd gekozen voor XML met UTF-8 encoding, volgens MultidoseExport.XSD.
Bestandsnaam:
...
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 = datum van de transactie
hhmmss = tijdstip van de transactie
tt = type transactie, dus voor de doseerschema’s steeds MD.
...
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 |
...
verplicht
...
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 |
...
CreatieDatumUur
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 |
|
|
|
SortOrder: In deze tag bepaalt men de sortering waarop het bestand dient verwerkt te worden. Dit is vooral van belang als men met een verdeelkast werkt en men vanuit de apotheeksoftware een nieuw bestand aanmaakt die de verdeelkast zal aansturen. De meegegeven sortering zal de volgorde van de aanmaak van de zakjes bepalen. In principe is de instelling master van de sortering als deze wordt meegeven. De inhoud van dit veld bestaat uit max 7 komma-gescheiden delen, gaande van Location1 tot Location5, plus Date en Hour. In de velden Location1 tot 5 in de sectie <Patient> kunnen 5 mogelijke niveaus van locatie bepaald worden. Date en Hour verwijzen naar <AdministrationDate> en <AdministrationHour> uit de sectie <Administration>.
...
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”
...
Als <SortOrder> niet is ingevuld of meegegeven zal de apotheeksoftware de sortering moeten bepalen.
2.2.2 Patients
Sectie noodzakelijk: Ja
...
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 |
...
verplicht
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 |
...
verplicht
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 | 5 |
...
th level to determine the location (e.g. Bed A) | |
Birthdate | Simple |
...
Geboortedatum
Date of birth. | No | 8 | N | YYYYMMDD |
DoctorName | Simple |
...
Name doctor |
...
No | 40 | A |
...
Name of doctor treating the patient | |
DoctorMedRegNr | Simple |
...
RizivNrDokter
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 |
...
verplicht
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 |
...
verplicht
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 |
...
Start date of the current posology/treatment for this medication | ||
StopTreatment | Simple | StopPosologie |
...
No | 8 | N | YYYYMMDD |
...
Stop date of the current posology/treatment for this medication. If this date is not provided, it is undefined | |
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 |
...
verplicht
Mandatory | Max length | Type |
...
Specification | |
Administration | Complex, |
...
see 2.2.7 |
|
...
Yes |
|
|
|
2.2.
...
7.
...
Administration
Sectie
...
necessary:
...
Yes
Beperking: geen, kan dus meerdere keren voorkomen.
...
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 |
...
verplicht
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 |
...
AdministrationDate
...
Simple
...
ToedieningsDatum
...
It needs to be defined in the care home software whether decimal places may be used. | ||||||
AdmDate | Simple | Administration date | Yes | 8 | N | YYYYMMDD |
...
AdmHour | Simple |
...
Administration hour |
...
Yes |
...
|
...
N
...
HHMM
Is het beginuur van het toedieningsmoment.
...
xs:time | HH:MM:SS |