SIIM 2016: My top ten take-away’s.

The ultimate radiology workstation

The annual PACS meeting organized by SIIM and held in Portland, Oregon from June 28-July 1 was

a 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

·         Routing

·         Reading worklist

·         Diagnostic display

·         Dictation/VR integration

·         3-D integration

·         Annotations and Key images

·         Inter- and intra-enterprise communications

·         Non-diagnostic display

·         Archiving

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 

is a need to reconcile multiple ID’s that are issued by the various institutions. The US did not implement a universal patient/person identifier, which was actually part of the initial HIPAA regulations in the late 90’s due to privacy concerns. But even in countries that have a universal patient identifier, such as Canada, and many European and Asian countries, there are always cases where reconciliation is necessary because a person might not have an ID (think an illegal alien) or does not have his or her ID card when admitted to a healthcare institution. For example, in Canada, which has a so-called healthcard with a unique ID, there is still 2 percent of the admitted population that has incorrect or missing information. To reconcile a patient who has different local patient ID’s, there are two methods, i.e., deterministic and probabilistic. The first method assumes a match based on a known relationship such as a universal patient ID, the second one assigns a weight factor to each of the items in a list of demographic characteristics such as the name, birthdate, ID, gender, postal code and phone number and, if the result is higher than a certain probability threshold, declares a match or mismatch. The province of Ontario in Canada has currently four regions where information is shared and has experience with both methodologies. After matching almost 4 million patient records, it determined that .9 percent of the cases using a deterministic method resulted in an “uncertain match” and .39 percent in a mismatch. These mismatches were reported back to individual sites to allow for them to improve their match rate. Bottom line is that with both the deterministic and probabilistic method, mismatches can still occur requiring QA procedures to minimize these occurrences.

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.

Speaking the PACS language.

One of the major stumbling blocks for effective communication among PACS professionals is knowing how to speak each other’s language. Each profession has its own lingo, set of abbreviations and acronyms, and it is even be worse among the professionals who are involved with a healthcare imaging and IT system such as a Picture Archiving and Communication System (PACS): it is as of each discipline talks a different foreign language.

For example, the network engineers speak about setting up their VLAN to support the new system using DHCP to assign IP addresses to the devices, the interface specialists talk about needing an HL7 “O01” order message to map the Accession Number into the Filler order number (OBR.3), the service engineers need an AE-Title and port number to sAet up their new modality, the PACS engineer needs the specification of the SOP Class UID to add the new, enhanced breast tomo-synthesis image type to the configuration list at the PACS image manager, and the PACS administrator needs to know the DICOM attribute tags for the Ultrasound measurements in the Structured report to map into the voice recognition software. In addition, the project manager need to specify the requirements of the metadata to be stored in the VNA and review the IHE profile statements to make sure it complies with the XDS and PIX/PDQ protocol to interface with the regional Health Information Exchange to share images.

If all of this sounds familiar, you are likely speaking the right language, but if not, you might want to take a language class on how to speak and understand PACS, DICOM, HL7 and IHE so you can effectively communicate with other professionals to resolve any issues that might arise. Remember, it is much more useful to communicate with a vendor in a precise, detailed manner than just say “the PACS is down” or “the images don’t make it”.

In order to learn the PACS language, there are several options depending on the individual learning preferences. Research has identified 4 different learning types, these learning styles are found within educational theorist Neil Fleming’s VARK model of Student Learning. VARK is an acronym that refers to Visual, Auditory, Reading/Writing Preference, and Kinesthetic. In other words, some people have to “see it”, some have to “hear it”, some have to see and/or write down the words and others have “to do” it, i.e. need hands-on. In practice, I actually think that a blended learning environment is the best, i.e. to see and hear, write down a synopsis and make notes as well as do some practice.

Getting back to learning the PACS language, you can read text books on PACS, DICOM and HL7, take a core class, for example, on-line, and/or take a hands-on seminar or do extensive practice after a class, all while taking copious notes when following the training. As a matter of fact, you might want to check the schedule for the end of July as we have 4 on-line core classes on PACS, DICOM, HL7 and IHE coming up. Hope to see you in July (virtually) and allow me to improve your PACS language!