Difference between revisions of "Patient Record (PAS) Lookup"
| Line 2: | Line 2: | ||
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. | 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 | 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 | 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 automatically. | It's worth pointing out that PTS remains usable even if the patient lookup goes down - users can just enter patient details automatically. | ||
==Amending the patient record connection information== | ==Amending the patient record connection information== | ||
Starting in 2022 new patient record implementations are implemented with an ODBC data source called <strong>"PTSPAS"</strong> on the PTS application server. It is best to simply amend this data source to point it to the new location. If the data source drivers are outdated (e.g. requires the new IRIS drivers) or are otherwise invalid (e.g. moving from one patient record ecosystem to another) it's easiest to completely remove the PTSPAS datasource and create a new one with the same name. | Starting in 2022 new patient record implementations are implemented with an ODBC system data source called <strong>"PTSPAS"</strong> on the PTS application server. It is best to simply amend this data source to point it to the new location. If the data source drivers are outdated (e.g. requires the new IRIS drivers) or are otherwise invalid (e.g. moving from one patient record ecosystem to another) it's easiest to completely remove the PTSPAS datasource and create a new one with the same name. | ||
Assuming the data structure of the patient record database remains the same, the patient lookup should now be working again in your PTS application ( | Assuming the data structure of the patient record database remains the same, the patient lookup should now be working again in your PTS application (there hasn't been a "breaking change" to the CMM patient record data structure since 2014). | ||
==When PTSPAS data source is not yet in use, or there is another complication== | ==When PTSPAS data source is not yet in use, or there is another complication== | ||
You should contact TMSi to arrange a date and time for one of our support technicians to remote access your PTS server and create and configure the PTSPAS ODBC data source for you and | You should contact TMSi to arrange a date and time for one of our support technicians to remote access your PTS server and create and configure the PTSPAS ODBC data source for you and make sure PTS is pointed to it. | ||
Have the following information handy: | Have the following information handy: | ||
| Line 22: | Line 22: | ||
</ol> | </ol> | ||
Note: CMM seems to use the same database name, uid and password across the board, so we can usually infer these. | 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 that non-critical nature of this facility. It's just an auto-complete of the patient's name on the booking in screen. | |||
Revision as of 17:03, 21 March 2022
Overview
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 automatically.
Amending the patient record connection information
Starting in 2022 new patient record implementations are implemented with an ODBC system data source called "PTSPAS" on the PTS application server. It is best to simply amend this data source to point it to the new location. If the data source drivers are outdated (e.g. requires the new IRIS drivers) or are otherwise invalid (e.g. moving from one patient record ecosystem to another) it's easiest to completely remove the PTSPAS datasource and create a new one with the same name.
Assuming the data structure of the patient record database remains the same, the patient lookup should now be working again in your PTS application (there hasn't been a "breaking change" to the CMM patient record data structure since 2014).
When PTSPAS data source is not yet in use, or there is another complication
You should contact TMSi to arrange a date and time for one of our support technicians to remote access your PTS server and create and configure the PTSPAS ODBC data source for you and make sure PTS is pointed to it.
Have the following information handy:
- The connection details of your old patient record database (server name, database/namespace name, uid, password, port etc.).
- The same connection details for your new patient record database.
- The date and time the patient record migration/update/etc is taking place.
- 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 that non-critical nature of this facility. It's just an auto-complete of the patient's name on the booking in screen.