 |
|
| |
|
| |
 |
| |
 |
| |
It's not too late! Your support of the SIIM Research & Education Fund through the 4th Annual "Ride to SIIM" will help fund the SIIM Grant Program and the Samuel J. Dwyer, III, PhD, FSIIM, Memorial Lecture.
Make a per-mile contribution to the SIIM Research & Education Fund today!
|
|
| |
|
| |
|
|
 |
 |
'Separation Anxiety' - Migrating from an Integrated RIS/PACS Platform to Two Separate Systems |
| |
| Authors: |
Lisa M. Romanoski, Geisinger Health System; Peter R. Cassidy; David L. Weiss, MD
|
| |
| Background: |
In May of 2002, Geisinger Health System implemented a PACS solution for archiving images. Based on our organizational needs, the system chosen allowed for a completely integrated RIS/PACS platform with a single, shared database. Support for both systems was provided through the RIS vendor who, in turn, would contact the PACS vendor for issues they could not resolve. Over time, due to changes in vendor relationships and the increasing need to directly interact with the PACS vendor, an administrative decision was made that resulted in the splitting of the database structure, while still maintaining the existing functionality of the two systems. The challenge was to perform this separation as seamlessly as possible with minimal disruption to current workflow.
|
| |
| Evaluation: |
| We considered moving to a different vendor entirely, but ultimately decided that was not the direction we wanted to take. Our goal was to have more direct contact with our PACS vendor, instead of being required to go through our RIS vendor for issues related to PACS. Since we could not participate in user groups on the PACS end, we felt we did not have proper representation for future updates. Another item that was missing in the original arrangement was the use of an API package. By working directly with the PACS vendor, we could begin to make use of this functionality, which would provide us more flexibility. |
| |
| Discussion: |
| The first step in this “separation” process was to test communication between the systems. This was accomplished via an HL7 interface from RIS to PACS. Defining the necessary fields and changes that were needed to accurately reflect the same information in both systems was a tedious process. In some instances, RIS fields could not be mapped to their corresponding fields within the PACS system, so workarounds were needed. Another serious issue was the fact that not all the status codes were available on the PACS side, as they had been when the databases were integrated. The most notable was that the “dictated” status in RIS was no longer valid in PACS. Because of the complexity of our dictation workflow, we could not rely on the reporting system to initiate a “dictated” and “marked read” status within PACS. Therefore this issue was considered a “showstopper” and had to be addressed by both vendors. Another issue was with linked exams. In our integrated system, different accession numbers that shared the same image set would be linked together in both RIS and PACS, so viewing any of the studies would show the same images. It was necessary to maintain the PACS linkage for both legacy and new exams since our image enabled EMR would only access the PACS database and not the RIS. Since there is no HL7 transaction to “link” exams, the vendors again had to make a coordinated effort to come up with a means of accomplishing this task. Both of these issues delayed our implementation significantly, as we could not go forward without them, and there were no viable workarounds. Several other issues came up as well, but we were able to find suitable workflow modification solutions to handle them. One example was in the case of our organizational structure within the RIS system. Modality locations were broken down by a code which was used in the PACS system to assist in building filters. The organization code could be used within the RIS system since the medical record number, our primary patient identifier, could be set up to be shared across all of those organizations. This was not the case on the PACS system, however. So the organization structure would not work properly in the de-coupled database. In the integrated system, we had used this code to assist in building filters. Now we needed to come up with another method. Our workaround was to “prepend” the modality resource with the organization code, which then allowed us to build our filters by resource. While this is not an easy way to create filters, it still allowed us the opportunity to separate facilities when needed. |
| |
| Conclusion: |
| On the surface, splitting databases, yet keeping the same vendors had seemed an easier process than a complete PACS migration. However, this process was shown to be much more difficult than originally anticipated. While many things looked the same in the foreground, there were a number of slight database differences that required workflow changes and code modifications. Our users’ expectations were such that user interface and workflow should appear virtually the same after the split as they did after before. This was difficult to accomplish in all cases. In addition, these stumbling blocks made the process take much longer than originally anticipated. We have completed go-live, but are still wrestling with several database and image access issues. |
| |
|
|
| |
| |
|
|