Patient Record (PAS) Lookup

Your PTS application is likely to be connecting to a patient record database of some sort. This is the facility that looks up the patient details on the booking in screen.

By far the most popular choice is to connect PTS to the JAC/WellSky/CMM (hereafter "CMM") dispensing database, and our technician will have created this link for you during installation if the option was available to them.

When the CMM database (or other patient record database) is moved or modified (e.g. as part of an upgrade or server decommission) the link between PTS and the patient record database will be broken.

It's worth pointing out that PTS remains usable even if the patient lookup goes down - users can just enter patient details manually.

Amending the patient record connection information

Starting in PTS 5.0.3.1, the PAS link information is stored in Application Settings and is modifiable by a system administrator. The relevant settings are as follows:

• LOCALIDF
  Format of Local ID. This allows prefix or suffix characters to be added to Local IDs. Alternatively you could handle this in the query itself.
• LOCALIDQRY
  Query used by booking-in screen when searching for a patient using localID. PTS will look for the following field names returned by the query: NationalID, LocalID, Title, Forename, Familyname, Gender, Mobile, EMail, DOB, Address.
• NATIDF
  Format of National ID. This allows prefix or suffix characters to be added to National IDs. Alternatively you could handle this in the query itself.
• NATIDQRY
  Query used by booking-in screen when searching for a patient using nationalID. PTS will look for the following field names returned by the query: NationalID, LocalID, Title, Forename, Familyname, Gender, Mobile, EMail, DOB, Address.
• PASDSNS
  Patient Lookup DSNs.

Assuming the data structure of the new patient record database remains the same as before, more than likely you'll only need to amend the PASDSNS setting and/or the server data source itself to repoint it to the new database location. There hasn't been a "breaking change" to the CMM patient record data structure since 2014.

If you are on an older version of PTS the data source name will be hardcoded - PTSPAS - so you should locate this data source on the PTS server and either modify it, or replace it with a new data source while retaining the PTSPAS name.

When data source is not yet in use

You should install and configure the data source and connect PTS up to it.

Install the 64-bit ODBC data source on the PTS application server using the CACHE or IRIS drivers, configured in the same way that the data source is installed on pharmacy PCs, and name it "PTSPAS" ("CACHE" seems to be the name used on a typical pharmacy PC).

Once the data source passes a connection test, PTS needs to be modified to use it. The following DLL file on your PTS server contains the PAS connection information:

[PTS Installation Path]\bin\PTSPatientLookup.dll
e.g. c:\inetpub\wwwroot\PTSWeb\bin\PTSPatientLookup.dll

1. Make a backup of your existing PTSPatientLookup.dll file.
2. Do not keep the backup anywhere inside the PTSWeb directory or its subdirectories, even if you rename it. It will cause a conflict.
3. Download the updated PTSPatientLookup.dll file. This version references the PTSPAS data source.
4. Extract the DLL from the zip file and move it to the bin folder, confirming the overwrite.
5. Test the patient lookup on the booking in screen. It's normal for PTS to take a while to load immediately after changing a DLL. Testing using Internet Explorer on the web server itself may not work as it often has Javascript disabled.

If the test fails, restore the backup and contact TMSi to arrange a date and time for one of our support technicians to remote access your PTS server and set this up for you.

Have the following information handy:

1. The connection details of your new patient record database (server name, database/namespace name, uid, password, port etc.).
2. The date and time the patient record migration/update/etc is taking place.
3. A date and time after this you would like the remote update to take place.

Note: CMM seems to use the same database name, uid and password across the board, so we can usually infer these.

Timing of the update

We're commonly asked if we can implement the update beforehand on a test basis and have it ready for the CMM server switchover. Unfortunately this isn't logistically possible. Firstly, until the new server is live, we cannot test a connection to it. Secondly implementing the change prematurely would break the existing patient lookup for no good reason; there is no mechanism to connect to two databases from one data source.

Essentially when the connection would pass any meaningful test, the change would be ready to implement anyway.

It's important to reiterate the non-critical nature of this facility. It is just an auto-complete of the patient's name on the booking in screen which can be typed in by hand at any time.