Starting with version 2.8.0, which will be released within the next couple of weeks, e-Quip will include a Pocket PC interface. This will run on any PDA running Windows Mobile 6 or 6.5 Classic.
You might ask why we chose this particular device. We had taken the decision to support mobile devices and we decided to start with PDA’s because a) the development is within a Microsoft environment and is straightforward and well understood, and b) users with the Harland Simon Discovery RFID asset tracking system are already using PDA’s. If our first device was an Android tablet then these guys would have to carry both a PDA and an Android. Even if you don’t plan to use PDA’s you might still be interested in this article, as we will be using the PDA interface as the specification for the Android tablet version.
OCA’s – Occasionally Connected Applications
The first decision to take with a mobile application is whether or not the mobile device will always have a data connection available to it, or if it will only be connected to a data source infrequently. We have actually decided to adopt both, but in slightly different ways.
1. The Pocket PC interface is only connected during two phases of use: to synchronise data FROM e-Quip TO the PDA and to synchronise data FROM the PDA back TO e-Quip. When the application is in-use there is no need for a connection to be available.
2. Our Mobile Web interface will initially rely on a permanent WiFi connection. It will work on any mobile device, such as a smart phone (including i-Phone, Android & Windows Phone), or a tablet (i-Pad, Android, Windows 8 etc).
Note that the Pocket PC version will be available in a couple of weeks while development of the Mobile Web version has only just started. Eventually there will be an OCA version which will cover unconnected Androids, i-Pads etc, so by then we should have all bases covered.
Using the Pocket PC interface is a three-stage process:
1. Connect the PDA to your PC with Active Sync (or WMDC, the Windows 7 equivalent) and choose which data you want to copy to the PDA.
2. Disconnect the PDA and use it to check & edit equipment and to add and edit jobs.
3.Connect the PDA to your PC with Active Sync and synchronise your changes.
The screen captures below show the synchronisation process. Note that when you copy data from e-Quip to the PDA:
1. You can either copy all assets or just those assets in up to 5 selected locations.
2. You can optionally copy jobs
3. Only active assets are copied
4. Only uncompleted jobs are copied
Synchronising to the PDA (sometimes called “check-out”) copies data from your main SQL-Server database into a small SQL-Server CE (Compact Edition) database. This is a single file called “e-Quip.sdf”. This file is then copied to the PDA. If you don’t have your PDA with you you can do a check-out and manually copy the SDF file to the PDA later (using Active Sync).
Synchronising from the PDA involves copying the eQuip.sdf database file from the PDA to your Windows temorary directory. The process then analyses all records from the PDA which have been modified more recently than the data in e-Quip. If the PDA version is more recent then e-Quip is updated.
The Pocket PC application is very simple. There are two screens: equipment & jobs. Both of these are based on the desktop version summary screens and include the familiar “Look For” search mechanism.
The Equipment Screen
As you would expect, double-tapping on an equipment or job will open the appropriate equipment or job record. The equipment record has four tabs:
4. Job List
Note that from the General Tab you can put the record into edit mode. This allows you to edit the:
You can also create new jobs from the Jobs tab. Note that whenever you add a new job the system will generate a temporary job number, e.g. “New Job 1”. The permanent Job No will be assigned when the data is synchronised.
The Job Screen
The job detail screen has four tabs:
Unlike the equipment detail screen, every field on the job screen can be edited.
The operation of Pocket PC interface is extremely simple and very easy to use. It can be useful when doing audits, especially when fitted with a barcode reader. It allows jobs to be create jobs whilst out and about around the hospital and it also allows jobs to be picked up by engineers on the move.
I should point out that this is the initial design (even though the software is ready to release and will be available from 2.8.0), but if you have any suggestions as to how this can be improved then please let us know. We will be using this interface as the specification for the Android tablet interface, so you can suggest changes even if you don’t plan to use PDA’s.
The technical aspects of mobile development are well-established and are not complex. However, as the BYOD (Bring Your Own Device) metaphor becomes more widespread there are some concerns which need to be addressed.
1. Phones or Tablets with Cameras: Unlike Pocket PC’s Android Devices are not well-served by external hardware add-ons. Devices like barcode readers and RFID scanners for this type of device are not common. They may exist but would most likely connect via USB and are unlikely to be as well-integrated as similar devices for PDA’s. The most common way to capture barcodes with Android devices is to use the built-in camera. What are the legal implications of hospital staff photographing equipment in close proximity to children in a children’s ward? This becomes even more important if the tablet or phone belongs to the engineer and not to the hospital.
2. Personal or Trust Smartphones: I would guess that most engineers or technicians these days would carry a smartphone with them pretty much all the time. Assuming that a WiFi connection is not available in every location within the hospital it is likely that an OCA approach will be necessary (as in our Pocket PC interface). This means that data will be copied to the phone, which raises some additional concerns. If you give all engineering staff a hospital smartphone then your policies could prevent these phones from being taken off-site, although it’s difficult to see how this could be enforced. If you do adopt this approach this also means that staff have to carry an additional phone. If you allow staff to use their own phones, then what steps can you take to ensure that no NHS data is taken off-site on an engineer’s personal phone. It would extremely difficult to enforce a policy which required all engineers to remove all NHS data from their phones before they leave each evening. It is also by no means certain whether a way of securely deleting data from smartphones is actually supported by mobile phone operating systems.
There clearly are some interesting issues which need to be thought out, but mobile computing is certainly here to stay. What we need to do is to understand exactly what services are required when working away from the workshop, and then find the best ways of making those services available on a wide range of devices in a broad spectrum of environments.