Difference between revisions of "Mobile App Installation"

From TMS Support Wiki
Jump to navigation Jump to search
Line 72: Line 72:


==Devices unable to resolve server hostname==
==Devices unable to resolve server hostname==
iOS and Android are not easily able to resolve hostnames on an internal network. They are hard-coded at the OS level to use specific, remote DNS servers, even if you manually specify your own in network settings. "Fixing" this requires jailbreaking/rooting the device which is not something IT departments will consider. Using the IP address or the FQDN in the path instead of the hostname is usually the simple way of side-stepping this issue, however that causes problems when the server requires an SSL connection, as the certificate will likely be based on the simple hostname and not the IP address or FQDN.
iOS and Android are not easily able to resolve hostnames on an internal network. They are hard-coded at the OS level to use specific, remote DNS servers, even if you manually specify your own in network settings. "Fixing" this requires jailbreaking/rooting the device which is not something IT departments will consider.
 
Using the IP address or the FQDN in the path instead of the hostname is usually the simple way of side-stepping this issue, however that causes problems when the server requires an SSL connection, as the certificate will likely be based on the simple hostname, and not the IP address or FQDN.


=== iOS only workaround ===
=== iOS only workaround ===
Line 81: Line 83:


=== All device types ===
=== All device types ===
The better solution is to generate a new SSL certificate that implements the IP address of the server as a Subject Alternative Name (SAN).
The better solution is to generate a new SSL certificate that implements the IP address and the FQDN as Subject Alternative Names (SAN).


SANs are normally used when multiple hostnames are routed to the same server and the SSL certificate needs to be configured to accept them all. A little known feature is that it's possible to add an IP address as a SAN too. The process for adding SANs to a certificate is beyond the scope of this guide, but suffice to say that the IP address of the PTS server should be added to the SAN list.
SANs are normally used when multiple hostnames are routed to the same server and the SSL certificate needs to be configured to accept them all. A little known feature is that it's possible to add an IP address as a SAN too. The process for adding SANs to a certificate is beyond the scope of this guide, but suffice to say that the IP address and the FQDN of the PTS server should be added to the SAN list.


For example:<blockquote>SAN 1: DNS Name=pts
For example:<blockquote>SAN 1: DNS Name=pts

Revision as of 11:05, 1 February 2023

The PTS 5 mobile app's primary purpose is to facilitate the recording of collection and delivery of prescriptions, either from the dispensary to the ward, or from the hospital to a patient's home address. This is known as delivery tracking and was formerly the sole purpose of the app, however new features are being added all the time.

Hardware Requirements

  • The current minimum supported Android OS version is Android 6.0 "Marshmallow".
  • The current minimum supported iOS version is iOS 12.0.
  • The device must have a camera and the app must have permission to use it.
  • The device must be connected to the internal wireless network and/or be able to access your PTS application server over HTTP or HTTPS (as appropriate).

Installation

The PTS 5 App is available for both Android and iOS devices. If you have yet to purchase a device it is important to consult with IT as more often than not the choice between iOS or Android will be dictated by them, and in most cases devices not purchased through IT will not be able to connect to the internal network correctly.

Android

  1. The latest version of the app is always made available on Google Play (search “PTS 5”). It is preferable to install the app via Google Play as this will ensure that you get any software updates automatically and free of charge. Internet connection is required for this.
  2. Your IT department should have an MDM (mobile device management) solution in place for deploying and managing apps on your Trust’s devices. If this is the case it would be a good idea to consult with your IT department about the best way to proceed. A centralised solution like this is usually preferable to ad-hoc, unmanaged installations.
  3. Alternatively, we can provide the latest apk file for manual installation. If you have no other option you may download the apk file to your computer and then transfer the file to your device for installation.
  4. The app will attempt to verify your software license with each login attempt. Licenses are based on concurrent users. The correct licence key will be provided to you upon purchase and should be entered by a PTS system administrator into Setup > Application Settings > Devices Licence Key.

iOS

Firstly, it is even more important that you involve Trust IT in the purchasing, setup and deployment of iOS devices and apps. Unless you follow Trust IT procedures, you will be unable to connect a device to your internal wireless network and you will not be able to download the app to your device. It’s not possible to circumvent Trust IT iOS policies.

  1. The iOS version of the app is what’s known as a Custom app for Private Distribution (previously known as a B2B app). The difference between this and a normal app is the way it is listed; the app does not appear on the normal app store and instead only appears in Apple Business Manager once we have approved your Organisation ID.
  2. In Apple Business Manager, sign in with an account that has privileges to manage system-wide settings.
  3. Click Settings at the bottom of the sidebar, click Enrolment Information below Organisation Settings, then enable Custom Apps.
  4. Let us know your Organisation ID so we can add your organisation to the list for the PTS 5 app. To locate your Organisation ID, go to Settings, then select Device Management Settings below Organisation Settings.
  5. You can now "purchase" the PTS 5 app from the Custom Apps section.
  6. Once licenses have been purchased, you must then turn to your MDM (mobile device management) solution to roll the app out to user’s devices. You should refer to the instructions supplied by the MDM vendor for the correct procedure.
  7. The app will attempt to verify your software license with each login attempt. Licenses are based on concurrent users. The correct licence key will be provided to you upon purchase and should be entered by a PTS system administrator into Setup > Application Settings > Devices Licence Key.

Further iOS purchasing notes

  1. Instructions for how to use Apple Business Manager are subject to change without notice.
  2. Even though Apple’s directions don’t mention it, we also sometimes seem to need your Organisation Name that corresponds with the Organisation ID. The organisation name field is case-sensitive and requires matching punctuation.
  3. For the time being we can still support organisations that are enrolled with the older VPP program. The process is much the same, we simply need the VPP Apple ID (which takes the form of an email address) as opposed to the newer Organisation ID. We do not know for how much longer the VPP program will be supported.

As much as we'd like to also list the app on the normal app store for simplicities sake, Apple will not allow a business to business app to be listed on the public app store.

App settings

Once the app is installed there are a few settings that need to be set before you can use it.

  • PTS Server Details
    Enter the path to your PTS application using the IP address, e.g. https://192.168.0.1/PTSWeb, or the fully qualified domain name, e.g. https://server.domain.nhs.uk/PTSWeb. Unfortunately the hostname alone is very unlikely to work on Android or iOS. Pharmacy IT will be able to find out the IP address or FQDN for you if you send them the URL you normally use to access PTS on your PCs.
  • Auto-Upload
    If enabled the app will attempt to automatically upload data after every collection or delivery. This is usually desirable but can get annoying if network conditions mean that each upload takes a long time.
  • Auto-Refresh
    If enabled the app will attempt to re-download prescription data from PTS after every successful upload (automatic and manual uploads alike). This is usually for the best, but again, poor network conditions can sometimes mean this causes too many interruptions.
  • Domain Username
    Sometimes, a network will insist that you provide domain credentials (AKA Windows credentials or Active Desktop credentials) before it will allow the app to access an internal server such as your PTS server. If this is the case, enter a valid username here. This account is ONLY used to let the app connect to your network; nothing you do within the app is assigned to this user based on this setting.
  • Domain Password
    If you are providing domain credentials enter the corresponding password here. If you have a generic login for pharmacy that you use to log in to your PCs we recommend that you use those credentials.
  • Require bag scan on delivery
    If enabled, attempting to deliver a bag will prompt the user to confirm the correct bag is being delivered by scanning it again.
  • Skip user scan on collection
    The app needs to know who is performing collection and whether they have permission to do it. The app can either prompt for a user's barcode to be scanned and attribute the collection to them, or skip the user scan prompt and attribute collection to the currently logged in user. Typically the user scan on collection is skipped, assuming delivery personnel can authorise their own collections.
  • Skip user scan on delivery
    The app needs to know who is performing delivery and whether they have permission to do it. The app can either prompt for a user's barcode to be scanned and attribute the delivery to them, or skip the user scan prompt and attribute delivery to the currently logged in user. Typically the user scan on delivery is not skipped, and delivery personnel should be made to authorise deliveries by scanning a valid recipients barcode.
  • Minimum Delivery Proximity
    If a delivery address is specified on the item then the app assumes that the delivery is off-site, such as to a patient's home address. For convenience - and as a safeguard - the app will not allow delivery if it deems the destination to be too far away, and will instead suggest GPS navigation beyond a certain distance from the destination address. The minimum distance is defined here, in metres. This feature can be effectively disabled by entering a very high value.

SSL issues

Attempting to use an SSL (HTTPS) connection to the PTS server is likely to fail without some changes.

Devices unable to resolve server hostname

iOS and Android are not easily able to resolve hostnames on an internal network. They are hard-coded at the OS level to use specific, remote DNS servers, even if you manually specify your own in network settings. "Fixing" this requires jailbreaking/rooting the device which is not something IT departments will consider.

Using the IP address or the FQDN in the path instead of the hostname is usually the simple way of side-stepping this issue, however that causes problems when the server requires an SSL connection, as the certificate will likely be based on the simple hostname, and not the IP address or FQDN.

iOS only workaround

It may be possible to override the remote DNS server lookup by adding .local to the hostname in the PTS Server IP Address field. For example:

https://PTSServer.local/PTSWeb/api/

However, this may require that Apple's Bonjour service is installed on the server, and it's possible that the .local version of the hostname may need to be added to the certificate (see below).

Android only workaround

On request we can provide an amended version of the .apk file that is configured to accept all SSL certificates without exception. This version of the application is not approved by Google, and is arguably completely meaningless, as you may as well just not use SSL. However some Trusts have found this helpful.

All device types

The better solution is to generate a new SSL certificate that implements the IP address and the FQDN as Subject Alternative Names (SAN).

SANs are normally used when multiple hostnames are routed to the same server and the SSL certificate needs to be configured to accept them all. A little known feature is that it's possible to add an IP address as a SAN too. The process for adding SANs to a certificate is beyond the scope of this guide, but suffice to say that the IP address and the FQDN of the PTS server should be added to the SAN list.

For example:

SAN 1: DNS Name=pts

SAN 2: DNS Name=ptsserver

SAN 3: DNS Name=pts.local

SAN 4: IP Address=93.184.216.34

SAN 5: IP Address=2606:2800:220:1:248:1893:25c8:1946

Note the difference between the "DNS Name" and "IP Address" headers.

While it's not strictly a valid configuration it's conceivable that adding the IP address as a DNS Name may help too in certain edge cases.

The certificate is self-signed and the mobile device does not trust it

Self signed certificates are common within the NHS. Devices and apps that have to support an SSL certificate from an unknown certificate authority typically white list the certificate authority in the device or app configuration itself. As a nationwide mobile app that is installed in hundreds of different network configurations, the PTS mobile app is in the somewhat unique position of having to support multiple unknown certificate authorities, and maintaining a list of all of our customers CAs within the app is not plausible.