Sunday, August 21, 2016

Deconstructed PACS: What is it, Implementation, Do’s and Don’ts (Part 1 of 4)

This is the first part of the deconstructed PACS (Picture Archiving and Communication System) series; for a full featured presentation you can look at the video. This part covers the “what” of this phenomena.

The term “deconstructed PACS” has only recently been coined and is basically referring to providing
a best-of-breed solution for the different PACS components as opposed to a single-vendor PACS. As will become clear in the discussion below, there have always been variations of deconstructed PACS systems implemented, but over the past few years, the degree to which the PACS systems have been split up and the range of components being sourced from different vendors has been increasing.

As of today, it is estimated that less than 5 percent of the installations are truly deconstructed, and there is still a lot to be learned about the support, return on investment, and what scenarios result in a good solution. Therefore, the deconstructed PACS is still relatively early in this evolution of PACS technology, and is no longer considered “hype” based on the amount of discussion and interest it gets at tradeshows and in user group discussions.

To explain what a deconstructed PACS system is, let’s start with a typical PACS system core architecture. The core has an application that manages the incoming images and related information, checks them for integrity, and sometimes, depending on the vendor, requires a technologist to “verify” them before they are added to the PACS database and archive and become available for physicians to interpret. The core also has a database/archive to allow for querying and retrieving the stored information and typically some type of Information Lifecycle Management (ILM), which implements retention rules. A radiologist can access the images to perform a diagnosis through a workflow manager, which provides a customized worklist to the radiologist, depending on the specialty, and synchronizes this list with other users who access the images. Referring physicians and specialists typically access the images for review using a web-based or some type of thin client or zero-footprint viewing interface.

One of the relatively common applications of a deconstructed PACS covers the use case whereby a radiologist needs to read for multiple institutions that have PACS systems from different vendors. Instead of having to log into different PACS systems using their proprietary workflow manager interface and dealing with multiple worklists, one can use a third party universal worklist provider that will provide a unified worklist.

A second example of a deconstructed PACS is where the database/archive is provided by a different vendor than the PACS system through a Vendor Neutral Archive (VNA). In its pure role, a VNA is a replacement for the PACS image manager/archive, which allows for a new PACS system to be deployed relatively easily as it reduces data migration issues. Note however, that it will shift the migration issue to when the VNA needs to be migrated, so this advantage could be overrated. The main benefit of a VNA is that it shifts the data ownership to the end user as several PACS vendors would store the data into a proprietary format and not even provide the database scheme to the end users.

Typically, one keeps the PACS database/image manager in place, which stores the data for 6-18 months for ready access by the radiologists. Synchronizing changes, deletions and updates of the images between the PACS and VNA is still an issue, it is addressed by implementing one of the standard IHE profiles called IOCM, but support is still lacking. An issue with VNA implementation is to decide the dataflow, i.e. are images sent first to the VNA and then to the PACS or vice versa. The same applies for physician access, should it be from the VNA or PACS? Also note that the VNA has become much more than just a simple PACS archive/image manager extension as it is also often used as an enterprise archiving solution which can potentially manage non-DICOM objects, deal with multiple Accession Numbers and patient ID’s, and perform sophisticated data clean-up using tag morphing.

A fully deconstructed PACS therefore typically has a workflow manager and image manager/archive from different vendors in addition to the diagnostic workstation and even the physician viewers. One could even argue that there is no need for a traditional PACS vendor anymore, assuming that the VNA is taking the role of the PACS image manager/archive.

Now let’s backup and look at the different PACS core and ancillary components as listed below and see how they can be deconstructed:

PACS core features to be considered for deconstructing:
  • ·         Prefetching and routing: most PACS systems provide routing capability, however, not always to the level of sophistication needed.
  • ·         Image QC: one could purchase QC workstations that provide auto merge/splitting of studies, allow for reprocessing CR/DR images and fix information in the header using a modality worklist feed.
  • ·         Reading worklist: this is the universal worklist for the radiologists that can talk to multiple PACS systems
  • ·         Diagnostic display: this is the main reader for generic radiology reading (CT, MR, CR/DR, US), but for some specialties such as digital mammography supporting breast tomosynthesis, nuclear medicine, including image fusion, and cardiology showing non-image data there might be a need for a workstation from different vendors.
  • ·         Physician display: web-server solutions from third party vendors have been available for some time; especially when looking for tablet access and zero-footprint solutions there are quite a few other options.
  • ·         3-D and other plug-ins: there has been a steady market for sophisticated 3-D applications and orthopedic templating from other vendors
  • ·         Archiving and image manager: here is where the VNA plays a role
  • ·         Audit trails and Security/privacy: this is typically done by each vendor in a proprietary manner, i.e. they provide authorization and access controls and log all accesses. Some vendors have a totally promiscuous interface, i.e. they allow anyone to access the PACS core, something that can be prevented by programming the network routers. Audit trail recording can be done using an external ATNA repository which can be shared by multiple ATNA sources.
  • ·         System administration: this addresses fixing broken or unverified studies, merging or splitting them to match orders, body parts or specialties and running database reports about storage usage, performance and availability. There are a few third party vendors that can provide some of these features, most of them are tied to the specific vendor.
  • ·         Load balancing: this is typically done by adding multiple servers that can split the load for the incoming and outgoing data
  • ·         Disaster recovery, high availability and business continuity: Many institutions have solved this by using a cloud storage solution.
  • PACS ancillary features that can be considered for deconstructing:
  • ·         Order processing: Many PACS vendors offer an integrated RIS/PACS or have the PACS worklist created by their RIS. In the majority of the cases, the RIS and PACS have been reconstructed. As a matter of fact, most of the order entry and processing is shifting to the EMR.
  • ·         Modality Worklist Provider: Most initial PACS systems were using an external modality worklist provider aka connectivity manager or broker. This takes in the HL7 orders, which are kept in a small appointment database and provide a reply to the modality worklist queries. There seems to be a trend to take this out of the PACS system as there are often limitations in the sophistication and amount of worklist filtering that can be provided.
  • ·         Dictation: even although many PACS systems are tightly connected with only one or at most two voice recognition systems, some radiologists prefer to work with a different manufacturer.
  • ·         Report storage and distribution: some vendors store reports in the PACS, some in the RIS, and some in a broker, but it appears that the trend is to store them in the EMR.
  • ·         Inter and intra image sharing: there are many solutions for this including portals, but many institutions opt to outsource the inter-facility image sharing to external companies to provide physician access.
  • ·         Critical results and discrepancy reporting: this is often built in but can also be added on.
  • ·         Clinical trials management: this can be added on by having a gateway that takes care of anonymization and adding the clinical trial identifiers.
  • ·         Teaching files: many users opt for an external solution, especially as it can be kept even after a PACS vendor has been replaced.
  • ·         Peer review: there are third party solutions for selecting random studies on a predetermined date and assigning them to a list of qualified radiologists.
  • ·         Dose and contrast management: radiation dose registration systems and in the future contrast management systems can be added on.
  • ·         Decision support: this is a new area, vendors are starting to offer data mining to provide decision support for physicians.
  • ·         Interface engine: some vendors integrate a HL7 interface engine with their product, but most of them provide an external vendor for this.

In conclusion, deconstructed PACS systems, aka “best-of-breed” have been around since PACS started, although maybe not to the degree as currently being implemented. The definition of a deconstructed PACS is vague and subject to interpretation by the vendor defining it; it can include one or many core or ancillary components. Remember that it is still a PACS, the basic functionality does not really change, both a deconstructed or reconstructed PACS does the same job. It is recommended that you look at your PACS system in case you need to have additional functionality, such as peer reviews, decision support or dose registration and consider third party vendors. If you are looking for a PACS replacement, you might even consider purchasing one of the core components from a different vendor. However, be careful, and look at the do’s and don’ts section of this series.

The author, Herman Oosterwijk is a long-time PACS trainer and consultant, published several textbooks and study guides on this subject and provides both face-to-face and on-line training on PACS, DICOM, HL7 and IHE. He can be reached at www.otechimg.com

Sunday, July 10, 2016

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.

Wednesday, July 6, 2016

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!

Monday, June 13, 2016

Structured Report for VNA synchronization (part 3 of DICOM SR series).

There is one category of Structured Reports (SR) that I really haven’t covered in the previous two
parts and that concerns “specialized” SR’s. The content of each structured report is defined by its reference to a so-called template using a DICOM defined template ID, for example, TID 5000 is used to encode an ultrasound OB/GYN procedure report. There is a complete list of those templates in part 16 of the DICOM standard.

For the so-called “generic” SR’s such as used for ultrasound measurements, the template ID is specified in the DICOM header so that the receiver knows how to interpret the information. The corresponding SR documents or DICOM objects are identified in a workstation worklist with the modality defined term of “SR”.

What I refer to as specialized SR’s encode the used template as part of the so-called SOP Class such as used for Key Images and Computer Aided Diagnosis (CAD), similar to the ones used for Dose reporting. The advantage of supporting a specialized SOP Class is that when the DICOM connection (association) is being established, the receiver can determine if it supports this particular type of data structure and if not, reject the proposed information exchange.

An example of such a specialized SR is the key image, formally called the “Key Object Selection Document,” which is used to identify what image of a study is significant or important. It is of great help for example, when the a study is quite large, let’s say a 3000 slice whole body CT scan, and the radiologist wants to identify which images contain a significant finding so that a referring physician or specialist such as a surgeon does not have to flip through all of the images, but merely selects the most important or “key” ones. This SR is identified with “KO” as the defined term for the modality, which is how it shows up in a workstation worklist.

Not only can the KO SR be used to identify a target audience such as a referring provider or surgeon, it also can be used to synchronize two image management, storage and archiving systems such as a PACS and Vendor Neutral Archive (VNA). This addresses the fact that changes and deletions are unavoidable, for example, if an image was misidentified (e.g. the incorrect orientation), has a replacement image with better quality or has patient demographic errors. 

A PACS system administrator (SA) typically updates and corrects these types of issues at the PACS “back-end,” or, if trained properly technologists might fix their own study mistakes. Imagine that the images are managed at different locations such as in the PACS and VNA or even cloud storage, the PACS SA has to do the correction work multiple times. This is one of the most common complaints I hear from the early VNA adopters, i.e. that it doubles the work load as the number of unverified or broken studies to be fixed is duplicated at the PACS and VNA.

The Integrating the Healthcare Enterprise (IHE) profile that deals with this issue, called IOCM or Imaging Object Change Management profile specifies exactly this, addressing the following scenarios:
§  Data Retention Expiration
§  Correction or Rejection of imaging instances for Quality Reasons
§  Correction or Rejection of imaging instances for Patient Safety Reasons
§  Correction of Modality Worklist Selection

A KO object will be created by the change initiator so that they can automatically be forwarded to all locations that have a copy of the image to be corrected. The work only needs to be done once. Unfortunately, support of this profile by PACS vendors is spotty at best; hopefully this will change as VNA’s and enterprise archiving solutions are becoming more mainstream. Implementation is relatively simple, but of course, it needs to be tested, verified, and requires most likely an upgrade of your PACS software. Knowing that some of the PACS installations are running 3-5 years behind their latest software upgrades, support is likely not there (yet). Your DICOM conformance statement, which you should be able to download from the web will specify it, look for the “Key Object selection Document Storage” support and make sure that the applicable codes to specify the reason for the changes are supported, or, better, look for the support of the IOCM IHE profile.


More information can be found at the DICOM website, IHE website, and OTpedia as the resource for DICOM and PACS terminology. Otech also has a PACS, DICOM and IHE Core essentials class coming up in July which is online so you can follow this from your own desk at your own location, see the OTech training schedule.

Tuesday, May 31, 2016

Modality to PACS connection: Plug and Play?

One of the common complaints from PACS administrators is that they are typically not included in the planning process to connect a new modality to the PACS system. A typical interaction might be: “Oh by the way, can you check on Labor and Delivery tomorrow as they are getting their new ultrasound unit and they want to connect it to the PACS.” One expects that these new devices are just “plug and play,” however, not only is this far from reality, but it is also poor practice to connect a new device and just “see if it works” as the integrity of the system can be jeopardized. So, what are the steps to take to prepare properly for a new modality installation to increase the chance that this will go smoothly?

Of key importance is that you need to be involved with the planning process. If you are not aware when these new connections are going to happen, you often are faced with issues that could have been prevented. Unfortunately, with regard to the planning process, it is like the chicken and egg problem. if you have not been able to demonstrate that proper planning saves time and money, they might not involve you in the planning, and if you are not involved from the start, you aren’t able to demonstrate that initial involvement pays off. I don’t have a solution for this except for diligently probing what is happening so you can get involved.

Assuming that you know when the expected delivery of the new modality will take place, for example, in four weeks, you can start the planning process, which consists of the following:

1.       Prepare the network and addressing infrastructure – If the unit is going to be at a fixed location, you need to make sure that the physical network connection is available, in the case of a wireless connection you need to work with IT to provide a reliable connection that is fast enough to facilitate querying a Worklist and sending images. Assuming that you use a VLAN in radiology, you need to work with IT to make sure that the routers are configured to allow access to the devices that it will need to communicate with. An IP address needs to be assigned, as well as an AE-Title. Good practice dictates that the new device uses a standard port number for the DICOM connection that is assigned by the IANA to be 11112. I hear from some of PACS administrators that service engineers are sometimes hesitant and initially unwilling to assign the port number and AE-Title that you are assigning to the device, but I suggest that you not give in and insist that they follow the rules and conventions of your institution.

2.       Request the DICOM conformance statement of the new device – Compare this document with those of the devices the modality needs to interface with, which is first of all the PACS and second the specifications of the Modality Worklist provider, which might be in the PACS, RIS or provided as a separate broker. This also requires a bit of persistence, as in many cases, your interface with the vendor is through their sales channel and in my experience they often provide incorrect or out-of-date documentation. Make sure that the documentation meets the exact version and model number that you are installing.

3.       Check compatibility for image and related information to be exchanged – Using the conformance statements, check if there is anything that is sent by the modality that might not be supported by the PACS. Examples are: a new, enhanced CT or MR image type, for mammography the support for the new breast tomosynthesis images, for ultrasound the support for Structured Reports containing the measurements, for a CR a DICOM Presentation state that contains shutter information, for a CT a dose Structured Report, for mammography again, the support of CAD marks, for a cardiology device support of IVUS (intravascular ultrasound) or IV-OCT (Intravascular Optical Coherence Tomography), and so on. If support at the PACS is lacking, one might consider an upgrade of the PACS software, which in many cases is unlikely to happen in the required timeframe, which means that you have to work on either a work-around or degrading the modality to send an older, well known and supported image type. Examples of workarounds for dose Structured Reports are screen shots, for enhanced objects maybe using “conventional” CT, MR objects; for breast tomosynthesis it might mean falling back to proprietary solutions and doing the diagnosis at a modality workstation. Note that some of these fallbacks have major impacts on workflow.

4.       Check the Modality Worklist interface for its filtering capability and completeness –  If the new modality is a replacement and/or addition to an existing set of modalities sharing the same workload, one can reuse the Modality Worklist settings of the old unit. Examples are adding an ultrasound to an existing department or an additional portable digital X-ray unit. However, if you are installing a modality that is new, let’s say a dental panoramic X-ray unit, a bone-density device, a new IVUS in cardiology or a new outpatient CT, you need to prepare the Worklist provider or broker so that the query for the Worklist from this modality provides only the procedures to be done at the new device.

Note that the Worklist information is created by converting the orders encoded in a HL7 format, which includes a procedure code and NOT the modality code (e.g. CT, MR, US, etc.), therefore, the broker decides based on the procedure code which modality is going to be performing the study, which might not always be a sufficiently enough discriminator. Examples are a dental unit and radiology unit both sharing “CR” or a radiology and cone beam CT in dentistry sharing “CT,” or an in- and out-patient CT that needs a different Worklist. In these cases, other information in the requisition such as whether it is an inpatient or outpatient, or certain procedures that identify the specialty, need to be mapped to a certain location indicator (Station Name or scheduled AE-Title), which can be used as a filter by the provider.

In addition to being able to filter the Modality Worklist so that it only displays the procedures to be done at that specific modality, one should also check the worklist contents. Depending on the modality, certain information such as pregnancy status, weight, allergic reactions, contrast allergy and others, depending on the specific workflow and practice in the institution, might need to be retrieved and displayed. If certain information is missing, one should develop a work-around, which could be as simple as mapping that information from the header in a “comment field,” or, less preferable, in a non-used field. Hopefully one can avoid the need to access the RIS, EMR or other source of the order information and all of it is provided in the Worklist, but in a worst case, that might be the only option. The key is to be prepared for these workarounds and develop them upfront instead of discovering after the fact that it is not working.

5.       Simulate the modality connection – One can use a modality simulator such as OT-DICE or DVTK that can request a Worklist that mimics the query of the new modality by using the same addressing (station AE-Title, IP address, port number) and uses the same filters for the queries. This requires scheduling dummy procedures and having the Worklist provider configured to do the correct mapping. Configure this at the PACS side as well, as most PACS systems also require that the new AE-Title be added to the list of devices that are allowed to communicate with the database, and, if applicable, pull images from the archive. In a best case scenario your institution has a test broker and test PACS that can be used to do the testing, which is the case for most institutions, but if not, the only option you have is to use the production PACS to do this. For the patients one can use test patients, and use a test pattern for the image.

6.       Simulate the PACS core and viewing capability – Get images and any other related objects that are to be generated by the new modality, such as presentation states, structured reports for measurements, dose reports, CAD marks, etc. from the vendor on a CD and import these either directly into the PACS, or even better, upload them in your modality simulator to simulate the behavior of the new modality as closely as possible. Display the images on the viewing station, and test the applicable interfaces with the reporting system for DICOM Structured Reports (SR’s) containing the measurements and a radiation dose management system for the dose SR’s. Pay particular attention to the hanging protocols, i.e. that the images are displayed in the correct presentation, which requires the interpretation of parameters such as series and study descriptions in the DICOM header. Good practice is also to run the CD data through a validator such as DVTK to find if there are any potential DICOM standard violations that might eventually cause problems.

If, for some reason, you are unable to do any, or some of these steps in advance, you use the same strategy during or after the installation in case there are issues. For example, if you cannot get the new modality to communicate, first look at the conformance statements, try a simulator and capture the communication using a DICOM sniffer to see exactly what happens between the two devices. However, when possible, I strongly recommend taking the pre-emptive route as it is less stressful and better practice. I recommend creating a “new modality pre-installation” policy and have your department and involved parties sign off on it. It would contain a checklist of the items to be reviewed prior to installation. Similarly, there would be a “new modality installation” policy that spells out what to do before you allow a service engineer from the vendor to leave, which would function as a mini-acceptance checklist to prevent a call-back because something does not quite work. Assuming that you take all these precautions, the chances for plug and play are not always guaranteed but definitely much better.



Monday, April 18, 2016

Deep learning and big data in medical imaging: buzzwords and hype? Maybe better focus on workflow and integration.

It is hard to keep up with the latest technologies, let alone, all the new buzzwords or hype introduced by smart marketers to differentiate their products. I believe that it is better to call a product by its name based on what it does. Take “deep learning,” for example, isn’t “deep learning” just another form of neural networks, which is how Wikipedia classifies it, i.e. after a four-paragraph description, it says “Deep learning has been characterized as a buzzword, or a rebranding of neural networks.

If you follow this quote it leads to another interesting statement from IEEE Fellow Michael I. Jordan, Pehong Chen Distinguished Professor at the University of California, Berkeley:
“The overeager adoption of big data is likely to result in catastrophes of analysis comparable to a national epidemic of collapsing bridges. Hardware designers creating chips based on the human brain are engaged in a faith-based undertaking likely to prove a fool’s errand. Despite recent claims to the contrary, we are no further along with computer vision than we were with physics when Isaac Newton sat under his apple tree.”

After reading these quotes from people who are much smarter than me, I am reminded that maybe we should not get carried away by these new terms and buzzwords and instead stick to what we know and what feels right. If a new development feels like it is hype, it very likely is.

Instead of pursuing a fool’s errand, maybe we should fix what is broken, which is focusing on improving our workflow and integrating our current systems in a better manner. Implementing a VNA, deconstructed PACS, deep learning, applying big data solutions will only make the situation worse if you don’t optimize your current system first.

As an illustration, during our recent webcast on enterprise imaging, we had a poll asking the attendees for the top healthcare imaging and IT priority in their institution, and the top two issues were workflow and integration. These issues are not new as they have come up during past conferences multiple times but they still do not seem to be sufficiently resolved and addressed after all these years.

As a matter of fact, talking with other industry consultants, we seem to agree that more than 50 percent of the current healthcare imaging and IT systems could definitely use a “tune-up.” Think about a V6 in a car running only on four cylinders.  There are plenty of consultants that are busy with HIPAA audits, which is absolutely necessary, but a workflow and integration audit could be much more important.

I agree, doing a comprehensive audit of your current system is not as sexy as implementing the latest and greatest buzzword, but it can result in significant savings and efficiency and more effective patient care. Using “lessons learned” will provide a better ROI than applying “deep learning.” Remember this when next year’s buzzword is being introduced as well.


Monday, April 11, 2016

HIMSS Analytics introduces Imaging Maturity Model

Similar to the well-known EMR Adoption model, HIMSS analytics in Europe, in partnership with the European Society of Radiology (ESR), introduced at the 2016 ECR congress a digital imaging adoption model (DIAM) which promises to be a great model for institutions to benchmark their progress with regard to implementing a healthcare imaging IT strategy.  The model is quite comprehensive, it is defined using a scoring system of over 100 indicators from 10 focus areas, i.e. Software Infrastructure, Health Information Exchange, Workflow and Process Security , Quality and Safety Management, Patient Engagement, Clinical Documentation, Clinical Decision Support, Pervasiveness of Use, Advanced Analytics and Personalized Medicine. The model is currently being tested and piloted in several institutions in Europe in its initial phase. 

The different stages include the following:

Stage 0: Baseline, no electronic image management is present. Note that this does not mean that there are no digital modalities, but, rather, the information is not archived and actively managed.
Stage 1: Orders are electronically exchanged and available at the modalities. Images are exchanged and managed and reports are available and distributed electronically as well. All this is only on a departmental level, e.g. within radiology or a clinic.
Stage 2: The images are shared and available at the enterprise level for other physicians and specialties, for example through web access, or as a plugin on an EMR.
Stage 3: Workflow and process security is provided through status and change management so that the right images are available for the right patient at the right time. Quality measures are implemented such as peer reviews and critical result reporting and security and privacy controls such as audit trails are implemented.
Stage 4: Fully integrated image management at the enterprise level is provided through a Health Information Exchange, which can be private, i.e. managed by the enterprise. An enterprise can span multiple hospitals and clinics. Structured documentation is provided for measurements and other observations.
Stage 5, 6, and 7 include the following:
·         Advanced HIE functionality and Patient Engagement: A regional, typically a public HIE facilitates image exchange among practitioners, and patients are engaged such as through a portal.
·         Clinical Decision Support and Value based imaging: this provides feedback to a physician at time of ordering about the appropriateness of a procedure based on the patient preconditions, history and using practice guidelines.
·         Advanced analytics and personalized medicine: this allows for patient personalized or precision medicine based information to be used.

This model is a great tool for institutions as well as the user community as it will rank the level of imaging adoption. The next phase will potentially include non-European countries and include other non-radiology services. Hopefully it will be rolled out and take hold in the US and other countries soon as it can be a major differentiator between the various institutions.



Sunday, March 27, 2016

PACS Administrator training in Kuwait

OTech is teaching a series of PACS administrator training seminars for the Ministry of Health (MOH)
in Kuwait in partnership with ATC (Advanced Technology Company K.S.C.) who represents GE PACS/RIS and modalities in the region. These five day intensive and advanced training sessions teaches hands-on skills that includes DICOM and HL7 troubleshooting and advanced PACS topics to prepare these professionals for new upcoming developments such as cross-enterprise image and information exchange, and new IHE profiles to facilitate these. We go as detailed as looking at real-life interface transactions using state-of-the-art tools and simulators that represents a “virtual hospital”.
After this training, these professionals will be well equipped to support the new and upcoming healthcare imaging and IT software applications.


OTech is a well-known PACS training company that has trained literally thousands of professionals in many regions around the world both through face-to-face and on-line training and has published several textbooks and study guides on this subject for more information, see www.otechimg.com.

Monday, March 14, 2016

How many PACS SA's do you need?


The quest for the right number of support people for a PACS (Picture Archiving and Communication System)  has been asked many times, and the correct answer is: “it depends.” I have seen organizations that have a single PACS SA (System Administrator) supporting multiple campuses, and others having eight people as part of their SA staff supporting the system 24/7 using three shifts. To be precise, based on a survey, I found that 53 percent of institutions have a single PACS administrator, 23 percent of them have two, 13 percent have three and 11 percent have four or more. 

Here are my top ten criteria that influence the proper PACS SA staffing level:
1.       System size: How large is your institution, what is the number of annual procedures, the number of facilities that you are supporting, additional clinics, and number of radiologists?
2.       Imaging scope: Is your EMR image-enabled, is cardiology included in your support duties, what about surgery, dentistry, and other “ologies”?
3.       System scope: Do you support CR/DR connectivity, RIS, speech recognition?
4.       Provider expectation: Is 24/7 presence required, are you on-call, what about back-up if you go on vacation, get sick or have other personal things to take care of outside work?
5.       Level of management involvement: Are you part of the planning committee, steering committee, change control board, implementation committee, in other words, how much time do you spend in meetings?
6.       Level of organizational support: Does biomed do the modality integration, do your technologists fix their own studies, is medical physics taking care of monitor calibration and image quality verification, and is there an IT help desk to take first call?
7.       Level of vendor support: Do you rely on the vendor to provide troubleshooting, monitoring, providing reports?
8.       Educational support: Does your employer allow you time to attend professional meetings, take an on-line or face-to-face training seminar, pay for you to get certified as a PACS professional, and keep up with your peers and the industry?
9.       Experience and skill level: How much experience do you have? An experienced PACS SA takes less time to deal with an issue, such as doing a quick SQL query to the database, or to find or fix a problem, use a network sniffer to find out the reason a DICOM connection was rejected, or look at a log file of a HL7 transaction to find a missing or duplicated Accession Number.
10.   Last but not least: Budget restrictions: Unfortunately, some organizations do not allocate the proper resources which impacts effectiveness, readiness and, indirectly patient care by not making sure the PACS is properly supported.

Based on feedback from SA’s in our PACS training classes, I have found that if you are spending more than 50 percent on support and maintenance (fixing, putting out fires), you are understaffed. The ideal allocation would be 50 percent support, 35 percent on implementing projects and 15 percent on education and training. If you are too far off from these numbers, I suggest you have an honest talk with your supervisor.