Electronic Prescribing Integration

Introduction

This document outlines the requirements for an interface between TMS Insights Prescription Tracking System (PTS) and an Electronic Prescribing (ePrescribing) module.

The reason for the interface between the two systems is to save pharmacy staff time re-entering information into PTS that has already been entered into the other system.

Whereas ePrescribing systems tend to focus on the ordering and dispensing of individual drugs and the management of stock, the focus for PTS is in managing the workflow of ‘prescriptions’ for individual patients through the whole dispensing process – from when an order is placed through to completion, collection and delivery back to the Ward.

A ‘prescription’ in PTS is defined as a group of medicines that will be processed as one unit of work for an individual patient.

There are several circumstances where PTS & ePrescribing systems need to interface:

1) When a prescription is manually entered in PTS and the user enters a patient identifier (Hospital number or NHS number). An interface is required here to return demographic information to save the user having to type these details into PTS. This interface is provided as part of the system, while it’s not required many Trusts implement this to assist booking in prescriptions.

2) When an ‘order’ is created in the ePrescribing system this information is sent to PTS so that it can be tracked. In addition to the patient demographics more information is required about the order so that PTS can group medicines into ‘prescriptions’ for each patient, assign prescription types and allocate each prescription to a Ward and Dispensary.

3) When Prescription tracking information needs to be sent back to the ePrescribing system &/or to an additional system (such as a whiteboard or bed management system) when the status of a Prescription changes &/or an activity is recorded against a Prescription.

Automatic ePrescribing links (option 2) are chargeable and you should obtain a quotation if required.

Demographics for Manual Data Entry

PTS has a ‘booking-in’ screen for entering prescription information in manually. Options can be defined (by Prescription Type) to allow the following demographics to be captured:

• Local ID (e.g. Hospital Number)
• National ID (e.g. NHS Number)
• Forename*
• Surname*
• Prescription Type
• Ward*
• No. of Items
• Drugs
  • Drug name
  • Dose units
  • Dose frequency
• Title*
• Gender*
• DOB*
• Mobile Phone no.*
• E-Mail Address*
• Address*
• Date/Time prescription requested
• Visit number / Episode ID*

A * next to an entry in the above lists indicates a field that we can potentially get from the patient demographics held in the ePrescribing system.

ODBC link

PTS can be configured (by amending a DLL file on the PTS application server) to retrieve demographic fields via an ODBC connection when a patients hospital or NHS number is entered. Typically a 64 bit system DSN would be configured to connect to the source system and PTS would use this to retrieve the demographic information for the prescription type being entered from the hospital / NHS number that was entered.

We have connected to numerous PAS systems using an ODBC connection, examples being: Careflow MMS (CACHE or IRIS), MS SQL, MySQL. Essentially - if there is a 64 bit ODBC driver available, we should be able to connect.

The queries being performed to retrieve the demographic data vary with the underlying PAS system. Many trusts set up a view or stored procedure on the PAS database that we can use to pull the required demographic data. With more common connections (Careflow for example) we have 'standard' queries that we are able to utilise, for example:

SELECT patient_hospital_no.lnkphn, patient_basic.forenames, patient_basic.surname, patient_basic.nhs_no, patient_demographics.sex, patient_demographics.telephone_no, TRIM(LEADING ', ' FROM ifnull(patient_demographics.address1,,UPPER(patient_demographics.address1))||ifnull(patient_demographics.address2,,','||UPPER(patient_demographics.address2))||ifnull(patient_demographics.address3,,', '||UPPER(patient_demographics.address3))||ifnull(patient_demographics.address4,,', '||UPPER(patient_demographics.address4))||ifnull(patient_demographics.postcode,,','||UPPER(patient_demographics.postcode))) address, patient_demographics.birth_date FROM JAC.patient_basic patient_basic, JAC.patient_demographics patient_demographics, JAC.patient_hospital_no patient_hospital_no WHERE patient_demographics.lnkpid = patient_basic.lnkpid AND patient_hospital_no.lnkpid = patient_basic.lnkpid AND patient_hospital_no.lnkphn = ' " & PatientID.ToUpper & "'"

HL7 Query link

We can send an HL7 as an alternative to an ODBC query. We would need details of the IP address of the system capable of responding to HL7 query and details of the format of the message that is expected and that will be returned.

An example HL7 request from PTS would look something like this:

MSH|^~\&|TMSInsight|TMSInsight|TIE|RHM|20220320090000||QRY^A19^QRY_A19|GUID|P|2.4
QRD|20220320090000|R|I|GUID|20220320090000|1^RD|^NHS|DEM

Webservice link

As an alternative to an ODBC query we are able to call SOAP or REST Web-services to obtain demographic data. We would need to know the destination URL, the type of request (GET or POST) and the parameters that need to be sent. If the web service requires additional security (e.g. a JWT token) then we would need the details to obtain this token (e.g. any client secrets required). These details will be hard-coded into PTS so will not be visible in any text files etc.

Automatic order tracking

PTS 5 has a comprehensive API that allows ePrescribing systems to send order information to PTS. This API can be called directly, or a service can be installed on the PTS application server to forward HL7 / FHIR / ODBC Queries to the API.

API documentation is available at https://prescriptiontracking.co.uk/swagger

Call PTS API directly

In order to create a Prescription via the API, PTS will require the following information as a minimum:

• The Destination Ward
• The Type of Prescription
• Patient Details

So, for example a POST could be made to http://prescriptiontracking.co.uk/api/Prescriptions/PostPrescriptionWithCreationOptions with the following BODY:

{"prescription":{"OriginatingWardId":1,"PrescriptionTypeID":1,"Requested":"2021-09-08 11:37:00","RequestedBy":"ADMIN", "Patients": [{"LocalID": "123ABC", "Forename":"Anne", "FamilyName":"Othertest"}]}, "start":true, "notes":[]}

In order for this to successfully create a Prescription valid OriginatingWardId, PrescriptionTypeId and RequestedBy codes would need to be passed in. These are codes stored in PTS and won't match the Id's used by the external system. For this reason we enable an 'ePrescribingId' to be stored against each user and ward in the system & also enable order types and sub types to be matched to prescription types within PTS. It is common for external systems calling the API to get the PTS ID's of the Ward/Type and User from helper API methods before calling PostPrescriptionWithCreationOptions:

GET http://prescriptiontracking.co.uk/api/Prescriptions/GetWardDetailsFromEPrescribingID?id=TEST (Use the value from the 'WardID' field returned in the response)
GET http://prescriptiontracking.co.uk/api/prescriptions/GetPrescriptionTypeDetailsFromOrderType?orderType=T&subType=T (Use the value from the 'PrescriptionTypeId' field returned in the response)
GET http://prescriptiontracking.co.uk/api/Users/GetUserDetailsFromEPrescribingID?id=ADMIN (Use the value in the 'Barcode' field returned in the response)

When utilising the API it can be advantageous to enter the details of the drugs being requested. In order to facilitate this PTS has a list of Drugs (at a VMP level) in it's database. We have utilities to import Drug data from Careflow MMS and from the DM+D TRUD Drug files. Once PTS has the necessary Drug information the details can be passed in the POST to PostPrescriptionWithCreationOptions, e.g:

{"prescription":{"OriginatingWardId":1,"PrescriptionTypeID":51,"Requested":"2021-07-27 09:50:00","RequestedBy":"ADMIN", "Patients": [{"LocalID": "123456", "Forename":"Jim", "FamilyName":"McTesterson","DOB":"1971-03-20","Mobile":"0759123456" , "Drugs": [{"DrugID":"10447211000001101", "DoseFrequency":"Two tablets at tea time","NoOfDosesDispensed":25}]}]}, "start":true, "notes":[]}

Options

• If a Ward is served by multiple dispensaries (for example a main dispensary and a satellite dispensary) the dispensary can be specified in the message OR PTS can use logic (based on opening times, bank holidays and drug lists) to determine which dispensary the prescription should be booked to.
• Prescriptions booked-in electronically can be configured so that they are not immediately started if the dispensary that they are being booked-in to is closed.
• Barcode labels for the tracking of the Prescription through the dispensing process can be configured to be printed at different stages (e.g. you might want to have the labels print as soon as the order comes in OR wait until you manually start them).
• 'User views' can be created within PTS to show only Electronic Prescriptions if required.

HL7 listener

ePrescribing systems are routinely able to send HL7 messages when an order for medication is created. This message may look something like this:

MSH|^~\&|PCS|SCM|HL7PRX||20161123113853||ORM^O01|2002417409110001|D|2.3
PID||50000214^^^TrustNo|50000214^^^TrustNo||Still^Stan^^^MR||19530428|Male||British|3 Warren Close^Bexleyheath^^^DA6 7LX^UK^Home||0117 496 0227||NSP|Unknown|Church of England|W00000073^^^VisitID
PV1||W|B4DAY^^^STH||||NHNA^Arsanious^N H N|||URO|""|||||||Waiting List|W00000073^^^VisitID|||||||||||||||||||||||||20190911090000
ORC|NW|001HKTFWN^PCS|||IP||^every 24 hours^^20161123113700^^Routine||20161123113853|interfaces^DataGate^Interfaces||INTERFACES2^DataGate^Interfaces
RXO|Pharm412^CITALOPRAM TABLET^Local_Pharm|5||mg|||||||||0

An HL7 listening service can be installed on the PTS application server to listen for these messages and forward them to our API:

• Patient details for the Prescription can be obtained from the PID segment.
• Ward details can be obtained from the PV1 segment.
• Drug details can be obtained from the RXO (or RXD) segment. If Dose information is required then this can be obtained from the ORC segment.
• It can sometimes be difficult to determine the Prescription Type from the messages. If only one type of Prescription is being entered electronically then this isn't a problem. Otherwise we have to infer from other fields or have an additional OBX segment sent which has further order details.