Eye care facilities are increasingly dependent on imaging devices to conduct their business. There are many devices including visual field machines, OCT scanners and fundus cameras.
An all too common problem is purchasing these devices without adequately planning how they should be connected to the existing hospital network. This can create serious problems in terms of accessing and using the data and safe data storage. Optimal installations tend to require additional hardware and licencing. If these requirements are not addressed at the initial business case stage, it can be financially difficult to justify them later. This document is designed to help staff understand the requirements for good device management, address shortfalls in existing device deployments and optimise future purchases.
We introduce a scoring tool called the ODM Level (Ophthalmic Device Maturity) to allow units to capture and articulate the current state of device maturity. Before describing the tool further, the next section clarifies some useful concepts and terminology central to this topic.
Backing up data:
No backup vs. local backup vs. network backup
Ideally, once the patient examination has been completed, the examination data stored on a device should be copied, or better moved, off the device, into a data store. The data store should also be regularly backed up automatically. If the device is not on the network, it should still backed up to an external hard drive or similar. Many eye units still use non-connected devices, without any backups being performed. When the hard drives inevitably fail, clinical data will be lost.
Storing the data
Siloed data store vs. centralised DICOM data store
Many device manufacturers provide proprietary server software, to create a data store for their devices. A common consequence can be multiple, siloed, data stores which do not communicate to each other. For example, a trust may have two OCT scanners (from different manufacturers), a field machine and a fundus camera. If the organisation connects all the devices to the network and uses the recommended server software for each device, four different data stores will exist. A single patient may then have four different records, in four different electronic systems. Worse still, if the patient details (name, DOB, ID number) are entered manually on each device, it is likely that inconsistencies in name format and errors will result. Future attempts to transfer data from those systems to merge them with a centralised system is then very difficult.
The recommended way is to use a centralised DICOM data store. DICOM (Digital Imaging and Communications in Medicine) is a series of data standards, adhered to by most modern device manufacturers. If a device is DICOM compliant, it allows the data to be exported to any DICOM data store. This allows devices from different manufacturers to store their data on a central server.
Of note, the DICOM standard only guarantees compatible transfer and storage of the data. It does not mean the data can be viewed in one system. This causes most problems for OCT scanners and field analysers. Detailed analysis and progression features are usually only available using the software provided by the manufacturers. Some companies sell software that claim to view data from all devices (assuming DICOM compatibility). This is unfortunately only true up to a point. Such software can often allow viewing of the individual OCT slices, but fail to provide the progression analysis features of the original software. The only way to rationalise this conflict is to accept that it may be necessary to support greater than one DICOM data store.
Achieving a single imaging record for each patient – Modality Worklists (MWL)
The use of a DICOM data store does not automatically result in a single imaging record per patient. If staff need to manually enter patient details to create a record, duplicates will result. The optimal way is to use another DICOM feature called MWL (Modality Worklists). This is described best by an example:
– A patient arrives for an appointment, and checks in at the front desk, or an electronic kiosk.
– The check-in process triggers the PAS (Patient Administration System) to send the patient details to the master DICOM data store. The data store then checks if it knows that patient already. If it does not, it creates a new entry, and populates all the demographic data from the PAS.
– The data store uses the MWL feature to send the patient details to all the imaging devices that are configured to use MWL. This adds the patient to the worklist on all devices.
– The patient is then taken to a device for a scan or test. Staff find the patient’s name already on the worklist and perform the test.
– After the test, the device then sends the data to its configured DICOM data store.
The use of Modality Worklists ensures only one imaging record, per patient, ever exists in the data store, regardless of the number of devices connected.
Choice of DICOM data store
Multiple choices exist in this area. Often the best choice for a unit depends on the principle type of OCT scanners in use and the type of visual field analyser in use. If a unit uses Zeiss OCT scanners and Zeiss field scanners, it makes most sense to use the Zeiss Forum DICOM data store. If a unit primarily uses Heidelberg OCT scanners and does not use Zeiss HFA field machines, it would make more sense to use the HEYEX2 platform. As mentioned above, multiple DICOM data stores may be needed, if different OCT devices are in use. If that is the case, there is merit in choosing one to be the primary store.
Here is a realistic example: A trust that has Zeiss Cirrus OCT scanners and Heidelberg scanners also has Zeiss HFA field machines. The trust uses Zeiss Forum as the primary DICOM data store and also uses HEYEX to service the Heidelberg OCT data. The other DICOM compatible devices in the unit send their data to the primary Forum data store (e.g. Optos Optomap, IOL Master and Acutome A-Scan).
Requirements when choosing and purchasing new devices
For peripheral devices, like A-scan or B-scan units or all range of fundus cameras, there is a simple question to ask when purchasing. Simply ask if the unit supports DICOM Modality Worklists. Importantly, this is not the same as asking if the device supports DICOM. Some devices are DICOM compliant, but do not support the Modality Worklist feature.
There are one-off licencing costs in connecting equipment via DICOM. Much of the licencing fee is paid to the DICOM corporation in the USA, who set the data standards. It is also worth knowing that a DICOM licence is needed at both ends of the connection. For example, if a fundus camera is to be connected to a DICOM data store, two DICOM licences will be required: one for the camera and one for the data store. Licences often cost between £1000 and £2000 each.
Ophthalmic Device Maturity Level
As described above, the ODM Level tool allows units to capture and share their current state of device maturity. Our hope this that this national scoring scheme will allow units use their device maturity scores to evidence the need for investment and it can be used to benchmark and compare against other units.
An ODM Level should be determined for each ophthalmic imaging device. Level 1A is the worst and level 4C is the best. The value from 1 to 4 denotes the connectivity of the device. The letter from A to C reflects the level of data backup or safety. Aiming for a level of 4C should be possible for most devices. Some older devices (without DICOM support) will be limited to level 3C. All imaging devices, whether slit-lamp cameras or mobile B-scanners should be graded. The ODM level scoring scheme can be seen below.
The image below illustrates an example network of six connected devices, each with an ODM level of 4C. Despite the presence of OCT devices from multiple manufacturers, all devices still achieve the maximum level possible. To maintain high quality analytic data, two ophthalmic PACS stores are required (FORUM and HEYEX). In this example, FORUM is the primary data store, and acts as the source for DICOM Modality Worklists. Even though the worklist on the Spectralis is populated from ZEISS FORUM, the data is still transferred to the Heidelberg data store (HEYEX). All six devices transfer their data to a server, and worklists replace the need for manual data entry. This earns each device a connectivity score of 4. Both the FORUM and HEYEX servers are backed up, earning the devices connected to them a safety rating of C.
Some aspects of device connectivity are intentionally not captured by the ODM level. Integration with an ophthalmic EPR (such as OpenEyes or Medisoft) is one example. This feature is excluded as it is only available for a few device types (like biometry machines and OCT scanners).
In addition to the scoring tool, a data collection spreadsheet (in Excel format) is provided. Use this to record the scores off all devices in your unit. The spreadsheet returns summary data in numeric and graphical forms to provide an overview of the device maturity for your unit.
Links to download the scoring tool and a data collection spreadsheet are provided here:
Scoring tool: bit.ly/ODMtool
Data collection sheet: bit.ly/ODMsheet
Once the results are understood, an eye unit can develop a prioritised plan to improve less than ideal scores, with an approach tailored to the scores and existing device and IT architecture.
Author: Mr David Haider / Consultant Ophthalmologist and Chief Clinical Information Officer, Bolton Foundation Trust