Description Therapylink V1.9a
Content
- Introduction.
- Description process en XML-layout opmaak bestelling.
2.1 Process description.
2.2 Description layout in accordance with TherapieExport.v1.9.XSD..
1. Introduction
The purpose of the Therapy’Link process is to send therapy 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 therapy schedule in his software for a.o. tarification per unit, preparing medication doses or creating files for automated dispensing systems. The difference with the Dose’Link file is that the former only contains the multidose medication (= medication dispensed by the pharmacy, either by a robot or manually), whereas Therapy’Link contains all medication, including medication managed by the care institution.
Therapy’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 therapy 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 (TH for therapy schedules) referring to the file type, as well as the identification of the elderly care home and the identification of the pharmacy.
The care institution sends the therapy schedules on a daily basis (preferably automated) at an agreed time. The time period covered in the schedule should be at least 10 days, because the tarification per unit is valid for a days, and it is best to have a couple of extra days as a buffer. It is recommended to use send therapy schedules for two weeks as a default.
2. Description process en XML-layout opmaak bestelling
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 [1])
zzzzzzzzzzzzzzzz (11 or 16) = sender (16 for care homes, 11 for pharmacies[2])
yyyymmdd = transaction date
hhmmss = transaction time
tt = transaction type: for a therapy schedule this is always ‘TH’
When the file is sent via eHealtbox, a functional type will be provided. For therapy schedules, this is HL-TH (which refers to HomeLink Therapy).
2.2 Description layout in accordance with TherapieExport.v1.9.XSD
2.2.1. Therapie
Section necessary: Yes
Restriction: 1 per file; this is the root element.
Fieldname | Type | Description | Mandatory | 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 | 11 | A | Identification number of the receiver. These are the same characters as used for the receiver 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 |
| xs:dateTime | YYYY-MM-DDTHH:MM:SS e.g. 2014-10-09T12:35:55 |
StartDate | Simple | Start date | Yes |
| xs:date | YYYY-MM-DD |
EndDate | Simple | End date | Yes |
| xs:date | YYYY-MM-DD |
SortOrder | Simple, see 2.2.2 | Order | No | 70 | A | Determines the order according to which the therapy schedule should be processed. See below. This is not important for the therapy, but it has been adopted from Dose’Link |
Patients | Complex see 2.2.3 |
| Yes |
|
|
|
2.2.2. Sort order
This tag is used when the pharmacy software creates a production file for an automated dispensing system based on a Therapy’Link file. It is used by the care home for determining the production and delivery order of the medication bags.
<SortOrder>Location2, Date, Hour, Location4, Location5</SortOrder>
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 <AdmDate> and <AdmHour> from the section <Adm>
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 following order: Floor, Room, Bed, Date, Hour
The field <SortOrder> will need to be filled as follows: “Location2, Location4, Location5, Date, Hour”
Rermarks:
- 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.3. Patients
Section necessary: Yes
Restriction: 1 per file
Explanation: This section contains all patients (residents) for whom a therapy schedule is being provided.
Fieldname | Type | Description | Mandatory? | Max length | Type | Specification |
Patient | Complex, see 2.2.4 |
| Yes |
|
|
|
2.2.4 Patient (Resident)
Sectie necessary: Yes
Restriction: 1 per resident
Fieldname | Type | Description | Mandatory? | Max Length | Type | Specification |
Id | Simple | Id | Yes | 20 | N | 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 |
| xs:date | YYYY-MM-DD |
DoctorName | Simple | Name doctor | No | 40 | A | Name of doctor treating the patient |
DoctorMedRegNr | Simple | INAMI/RIZIV number doctor | No | 11 | N | INAMI/RIZIV number of the doctor treating the patient (mandatory if DoctorName is provided) |
ShortStay | Simple | Short stay | No | 1 | N | 0 = not a 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 |
2.2.5. Products
Section necessary: Yes
Explanation: 1 per resident
Fieldname | Type | Description | Manadtory? | Max Length | Type | Specification |
Product | Complex See 2.2.6 |
| Yes |
|
|
|
2.2.6. Product (medication)
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 | IdMedication | Yes | 20 | A | Unique number for the medication used in the care home software |
PreparationId | Simple | IdPreparation | No | 20 | A | Internal number used by the institution for the preparation |
Speciality | Simple | Speciality | Yes | 1 | N | 0= magisterial preparation 1= proprietary drug with CNK |
Dsc | Simple | Description | Yes | 120 | N | Description of the medication |
Formula | Simple | Formula | No |
| A | 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 |
AdmUnit | Complex |
| No |
|
|
|
PrescriptionId | Simple | PrescriptionID | No | 30 | N | ID of the prescription |
StartTreatment | Simple | Start posology | No | 8 | xs:date | YYYY-MM-DD |
StopTreatment | Simple | Stop posology | No | 8 | xs:date | YYYY-MM-DD |
Adms | Complex See 2.2.8 |
| Ja |
|
|
|
ProductRemark | Simple | Product remark | No |
| A | Remarks on the product level |
2.2.7. AdmUnit
Section necessary: No
Restrictions: None; this section can be repeated
This section will be repeated for each language
Fieldname | Type | Description | Manadtory? | Max length | Type | Specification |
DscLg | Simple | Language | Yes | 2 | A | Must be NL for Dutch and FR for French. At least one language should be present. |
Dsc | Simple | Description | Ja |
| A | The description of the administration unit. |
2.2.8. Adms (administrations)
Sectie necessary: Yes
Restriction: 1 per product
Explanation: List of administration moments for medication to be dispensed, or indication ‘adhoc’ for medication that needs to be administered if needed.
Fieldname | Type | Description | Mandatory | Max length | Type | Specification |
Adm | Complex See 2.2.8 |
| Yes |
|
|
|
or
Fieldname | Type | Description | verplicht | max. Lengte | Type | Specification |
AdHoc | Simple | If needed | Yes | 1 | N | No fixed administration moment, only administer if needed? 0 = no 1 = yes |
The section will contain either
<Adms>
<Adm>…</Adm>
<Adm>…</Adm>
<Adm>…</Adm>
</Adms>
or
<Adms>
<Adhoc>1</Adhoc>
</Adms>
A combination of both is NOT allowed.
2.2.9. Adm
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 be 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 | YYYY-MM-DD |
AdmHour | Simple | Administration hour | Yes |
| xs:time | HH:MM:SS |
AdmCode | Simple | Code administration method | No |
| A | See table below. Column Code is enumeration from XSD. |
[1] The RIZIV-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-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.