Most PAC systems have the ability to record event information such as image acquisition, logins and logouts, and exam views. However, few of these systems come with a good means of searching and utilizing this information in an effective manner. All too often, it is considered something to be logged in a log file, at best archived somewhere off the system if not actually purged on a periodic basis. However, while the PACS database might not be well suited to retain this information depending on its design, the audit information is very valuable and can be very useful if stored in an accessible database, albeit a different one. Therefore, we set out to capture the audit information of our PACS directly into a Microsoft SQL server database and make it accessible through carefully designed web-based query tools.

The first challenge in this task was obtaining the information in real time. Our vendor originally began outputting the information into a daily log file, which contained information that was at least 24 hours old at the time of creation. We complained that for some applications this is far too late. Rather we wanted a direct information feed that would send the events to our “event listener” immediately as they occurred. It involved some older computer-to-computer communication methods, such as sockets and data packing, but with the vendors help we were able to develop our own computer code in PHP to receive the events.

We then designed a SQL server database with fields named exactly as the vendor termed the event components and had the “event listener” enter the event information directly into the database. Frequently searched fields such as patient name, patient ID, accession number, and username are periodically indexed to allow for faster searching. A web page, also written in PHP, was then created to allow general queries of the database.

The general query web page has proven invaluable in troubleshooting problem cases, because it can instantly show the sequence of events of an individual exam, sparing the user from trying to plod through several days’ worth of log files. Likewise, it can show the activity of an individual user – when he or she started working, what he or she looked at, and when he or she stopped working. This information is used not only to monitor the productivity of technologists and radiologists, but also to investigate medical errors. It is often essential to know what an individual user did or did not see. Likewise, it is often necessary to research when an exam with significant findings was first acquired, when it was first viewed, and by whom. It allows us to not only prepare activity reports in advance of an investigative meeting, but also to answer new questions that come up during the meeting immediately. Rather than having to say “I’ll run a report and get back to you later this week,” we can say “Let’s look right now” because all of the data are up to date and immediately queryable.

Once we began utilizing this data, we quickly found more uses for it. While our dictation system and PACS workstation software are usually synchronized with regard to patient and exam, the systems can function independently, and the potential exists for a report to be dictated under another exam for the wrong patient. We began comparing the accession numbers of what the radiologists looked at versus what reports they signed on a given day. We know that the two will not always correspond for many legitimate reasons, such as nuclear medicine and mammography exams which get read outside the PACS on dedicated workstations. However, we are in the process of sifting out such “noise” and are trying to see if we can catch any true errors before they cause the wrong report to go out to the referring physician.

Another application of the real time data feed we found was simply locating our radiologists. The audit events include the name of the user and the network ID of the computer from which an exam was opened. We built a small dictionary into a web page called “Radiologist Last Know Location” which translates the username into the full name of the radiology attending or resident. For each computer network ID, the physical location (such as “Resident On-call Room) and the phone number are given. This makes the task of locating the radiologists much easier, particularly for file room staff who are constantly trying to locate particular radiologists to get them to read exams for which a stat read has been requested. It also makes it much easier for the radiologists to find each other, rather than looking up a pager number, paging someone, and then waiting for a call back. A PAC system with instant messaging built in would be great, but until that happens this is a great alternative.

Our vendor felt that simply writing audit event information to a log file was sufficient to meet the needs of HIPAA. While this is true, we realized that there is a lot more that we could do with the data if it were stored in a database. So we created our own system to do this and created a set of queries to make the information immediately accessible and useful. Administrative inquiries into the activities of individual users and the manipulation of specific patient data are now greatly simplified. We now can begin to proactively check for discrepancies between images viewed and reports dictated. Locating a radiologist has never been easier. All of these achievements were made possible by taking a stream of individual audit events and assembling them into an easily accessible database, something the “Google” generation has come to expect.

In sum, it is not enough just to have PACS audit event information lying around somewhere in case someone asks for it. If properly utilized, this information can be leveraged to improve patient care and the functioning of a radiology department.