|The ultimate radiology workstation|
The annual PACS meeting organized by SIIM and held in Portland, Oregon from June 28-July 1 wasa major turn-around from past years as attendance was up, the quality of the presentations significantly improved with regard to being current and interesting, and vendors getting quite a bit of traffic in their booths.
The messages were predominantly positive, unlike the doom and gloom from last year’s “PACS is dead” messages, and many of the sessions were standing room only, especially those dealing with enterprise imaging and anything to do with deconstruction of the PACS. SIIM seems to have started to reinvent itself, albeit slowly. The collaboration with HIMSS, a great initiative, resulted in publication of several high-quality white papers about enterprise imaging, which are freely available.
Below are my top ten observations based on attending the presentations and talking with peers in the industry during the meeting:
1. Archive-less PACS – Every year there is yet another acronym introduced that does not really improve functionality but seems to confuse rather than adds value. Case in point is the archive-less PACS, which was introduced as a variant between a traditional Vendor Neutral Archive (VNA) solution and a deconstructed PACS, however under close inspection, it is nothing more than building a traditional PACS system using best-of-breed components. It is identical to reconstructing a PACS from the deconstructed components. SO, nothing new, but what I liked from the presentation was that it gave a good breakdown of the several PACS components, being:
· Order Processing
· Prior identification/prefetching
· Modality worklist
· Image QC
· Reading worklist
· Diagnostic display
· Dictation/VR integration
· 3-D integration
· Annotations and Key images
· Inter- and intra-enterprise communications
· Non-diagnostic display
I would have added lifecycle and/or content management, image management, other communication such as critical result reporting and discrepancy reporting, and peer reviews but this list was useful to show that a PACS system is not just about image communication and archiving.
2. VNA – Vendor Neutral Archives (VNA’s) are increasingly being installed and are getting more mature. Most of them are now implementing IOCM (Imaging Object Change Management), which is the IHE profile that synchronizes a PACS with the VNA with regard to changes and updates as well as deletions of the images and related information. Challenges with deploying a VNA are mainly with the integration of specialties, especially those who create non-DICOM objects such as PDF’s, JPEG’s, MPEG’s or other file formats. The traditional radiology and to a lesser degree the cardiology workflow, where everything is scheduled and ordered and managed on a procedure level, does not quite fit the other specialties hence these issues arise. Images are typically managed on an encounter or visit level, identified with a visit number instead of an Accession Number. Prior to image acquisition, a modality might need to query an EMR to obtain patient demographics using HL7 messaging instead of having a DICOM modality worklist available. There is definitely a learning curve involved with implementing this in these other departments especially with the modified workflow. In addition, there are issues with regard to the integration of the results, especially for the EMR. For example, ultrasound images created by an anesthesiologist might not belong in the same place where the diagnostic ultrasounds are managed and displayed, but, rather as part of the surgery notes. When deploying these devices for enterprise imaging to include many different specialties, these kinds of issues will surface, which is to be expected and part of the learning process.
3. DIY migration – Image migration is a fact-of-life as many institutions are at their second or third generation PACS, which in many cases means changing vendors. The reasons for changing vendors are typically driven by the need for increasing or adding different functionality, reliability, service and support issues, financial considerations, or in many cases the perception that another PACS vendor will magically solve existing issues that in many cases have nothing to do with the vendor but everything with how the system is used and managed.
Regardless, migration is a fact of life. When migrating a PACS archive, which can take months and in many cases more than a year, it becomes obvious how good your previous PACS was managed. Orphan images, un-identified studies, and other issues with the DICOM objects will surface when trying to add these to a new archive. Support for non-image objects such as Key Images, annotations and presentation states might be lacking or have limitations. Migrations used to be performed by the new PACS vendor or specialty companies, however, to save cost, more users are doing it themselves. One can purchase a software migration controller that queries the old archive and manages the image transfer potentially fixing DICOM tags or purchase a VNA that has this capability built in. DIY or Do It Yourself migration is definitely an option, instead of paying a lot of money to your PACS vendor or a migration vendor.
4. Evolution of middleware – Many PACS systems, including VNA’s, have limited routing capabilities, lack the capability to change tags to identify the origin (i.e. institution and/or modality), manage duplicate Accession Numbers or coerce parameters in the header that impact the workstation hanging protocols such as the study or series descriptions. Hence the advent of middleware vendors who can provide these capabilities. Note that most VNA vendors do provide quite a bit of this functionality as they are used to performing tag morphing to preserve their image integrity, which can be jeopardized by having multiple PACS as a source, but most PACS systems do have limited functionality with regard to changing the image data and/or doing sophisticated routing. The good news is that there are several vendors that fill this void and provide the middleware to integrate a PACS with other PACS systems or VNA’s, and provide intelligent routing and tag morphing.
5. The ultimate radiology workstation – The first PACS workstations were designed to mimic a film alternator, resulting in a row of four to six monitors or even two rows of four on top of each other. In the early years, these were CRT monsters, very heavy, and from a PACS administrator’s perspective, a “pain in the back.” Eventually, these configurations dwindled down to a two-monitor medical display configuration combined with a color text monitor for worklist display, looking at ultrasounds, and report creation. The reason for the second monitor is that radiologists were starting to look at CT and MR in a stack mode, virtually integrating the 3-D space in their minds by replaying the 2-D axial slices in a CINE mode. However, there is a need to also look at prior studies, and, in the case of CT ad MR, different reconstructed views (MPR, 3-D etc.), which again, asks for additional real estate. The circle has come around again by adding more and more monitors. This combined with an adjustable table that allows for a combined sitting/standing workplace and an acoustic work environment that provides a noise-free background, the work environment of a radiologist has become much more ergonomically sound. Also note in the illustration the use of a chair that can rotate and always provide a perpendicular view to the monitor. More research is needed in this area, but given the increase of occupational injuries caused by having a fixed, non-ergonomically designed work environment with multiple monitors might become a necessity.
6. FHIR update – The FHIR standard, which is the protocol that provides a web-services based interface to healthcare systems such as an EMR, PACS archive, and other information resources, is coming along well. The problem with this standard is that it is still very much in a developmental phase, as a matter of fact, its official term for the latest version is DSTU 3.0, which means Draft Standard for Trial Use version 3, meaning that it is not finalized yet. The standard relies also on a set of so-called resources that are accessible in a standard format which are also not quite finished yet. Lastly, there are many options in the standard, which makes conformance a challenge, in addition to the fact that there is the version issue, i.e. is the interface based on version 3.0 or a predecessor? In the meantime, recommendations and/or standards including federal guidelines are being defined based on FHIR requirements. It seems as if FHIR is definitely moving up on the hype curve, but there is serious concern about the potential “bleeding edge” effect when there are going to be real-life implementations. So far, there is good feedback from hackathons and trials, but real-life implementations are still scarce and support from major vendors still in the works or in beta. It might make sense as a user to have a wait-and-see attitude about early implementations.
7. DICOMWeb – The DICOM protocol has not changed since its initial definition in the early 1990’s. It does not have to, as it is robust and has a large installed base, as pretty much every medical imaging device supports it. There are many toolkits that allow for an effective and easy implementation supported by various operating systems and computers. However, the protocol is not that efficient for exchanging information over the web, i.e. to be displayed in browsers and mobile devices, which is getting increasingly important with the requirement to display images in an EMR. Therefore, similar to the HL7 standard, which added a web-based version called FHIR, the DICOM standard has added several options to allow use of web services, generally called DICOMWeb. The first generation called WADO (Web Access to DICOM Objects) has been around for quite some time, which basically is a http call for a DICOM image, the second generation added queries (QIDO-Query based on ID for DICOM Objects) and store (STOW-Store Over the Web). One should realize that these additions only impact the protocol, i.e. how the data is exchanged, and not the data formats, including the header definition. Also, one should realize that these additions are for an initial relatively small set of applications related to mobile access and most likely EMR functionality. It is generally understood that the vast majority of DICOM applications, especially the connection of the digital modalities such as the CT, MR. etc. will still be using the conventional, robust and proven protocol. DICOMWeb implementations are also in the prototype phase.
8. XDS – Cross-Enterprise Document (and image) Sharing is a set of profiles defined by IHE to exchange documents and images. There has been widespread implementation in the UK, however, in the US it has been piecemeal, even though most PACS and VNA vendors support it. The standard is relatively mature. There were some initial issues around the definition of the metadata that has to be submitted with the information to be exchanged, as the identifiers used to manage information within a department (e.g. Accession Numbers) and enterprise (Patient ID’s) are not sufficient to identify an image or document uniquely among different domains. Information such as specialty. and patient cross-referencing is necessary. The good news is that in the US there are modalities to start doing XDS document submissions, mainly of non-DICOM objects, such as PDF’s and JPEG’s to for example a VNA. Interestingly enough the integration of multiple non-radiology specialties creating these non-DICOM objects might drive a more widespread adoption of XDS.
9. Patient ID reconciliation – As images are being exchanged between multiple enterprises, there
10. Pathology – Digital pathology is very challenging and its implementation is trailing behind successful implementations in Europe. The main reason is that there is no FDA approval (yet) for this application requiring institutions to do dual interpretation, i.e. needing to perform a diagnosis based on the physical slide as well. There is a DICOM standard defined to encode these types of images that are created by a scanner, however, support is rare if non-existent. Even if approved, there are major implementation challenges based on the huge size of these exams and subsequent demand on infrastructure, archiving, and image display and manipulation. FDA approval is an initial and necessary step, but there are many other issues, including workflow challenges and initial resistance from the pathologists who have to get used to looking at these images on a monitor instead of through a microscope. Even though there are a few institutions starting to implement digital pathology, widespread adoption in the US is still several years down the road.
In conclusion, SIIM2016 was a good meeting. There were good discussions, and it provided a good opportunity to get up-to-date on new developments and talk with many users and vendors in a more relaxed and less crazy environment than the major big trade shows such as RSNA and HIMSS. Hopefully SIIM will proceed on their current path and next year in Pittsburg will be as good or better as this year in Portland.