Friday, September 30, 2016

Deconstructed PACS part 3 of 4: Do’s and Don’ts from the PACSMan

This is part 2 of 4 of the Deconstructed PACS series, the full video and corresponding slides of the webcast can be viewed here

The first thing you need to do when considering a Deconstructed PACS (DP) is knowing your requirements. Make sure you differentiate between what you want versus what is really needed. Specifically, do you already have a solution in place that works, and especially, how does a DP solution fit in your long term strategy. Consider the integration with other clinical systems, Know that there are many components to make a DP solution work, particularly the PACS, and RIS.

You have to decide where the data is stored, for example, on-site, in the cloud or do you consider a hybrid storage solution. Then, who owns the database, how is access provided and who is managing that. Note that this is one of the major differentiators between a traditional PACS which in many cases has a locked down access to the database and the deconstructed PACS which transfers ownership of that information, including opening up the database scheme to the customer, to the client.

It is important to know the trade-offs, in particular the gains and losses. Knowing the true cost of ownership is critical, including the support cost. This takes into account the cost and solution for redundancy, which can be solved in a central versus distributed manner. Service and support can be provided either internally or externally. Internal is typically less expensive initially but requires an investment in hiring the right people and providing them with training so in the end the costs may be the same or even slightly higher.
A word of caution is that one never should buy on price alone. No vendor will ever lose a deal on price. You need to make sure that everything is included in the purchase price. Don’t buy something you don’t really need.  I have seen too many computers in a department sitting in a corner unused that were part of the deal looked good on paper, but turned out to be useless.

It is important to decide upfront who will perform the connectivity to all systems and how will it be done. You need to determine will it be a web-based interface, an HL7 or DICOM interface, or even a custom designed  API (application program interface) that is commonly used to connect to your speech recognition system, or any other interface.
It is critical to get as much in writing as you can. Know that not everything can be negotiated and there are often certain policies and contract items that are standard.

Make sure you get feedback from all stakeholders before making the purchase decision, especially from the CIO and CTO. Those two  are key. Do your due diligence to be able to justify your purchase. Look at all financing option,and  in particular if you want to finance it from the operating budget, versus capital budget or even  price per click. Regardless the term should not exceed 5 years as this technology is changing too fast to know what will be preferable at that time.

In conclusion, a deconstructed PACS is a good solution for certain applications, but not necessarily a one-size fits-all  for everyone. Do your due diligence to find out if this might be a good solution for you. It might but then again, it might not either.

Mike Cannavo, aka as “the PACSman”.

Monday, August 29, 2016

Deconstructed PACS part 2 of 4: Implementation within the VA

This is part 2 of 4 of the Deconstructed PACS series, the full video and corresponding slides of the webcast can be viewed here

The VA Midwest Health Care Network, otherwise known as VISN 23 (Veterans Integrated Service Network) implemented a deconstructed PACS between September, 2014 and August, 2015.  Our legacy PACS hardware, originally purchased as part of a Brit Systems installation was at end of life.  The leadership team in VISN 23 made the decision to proceed with a deconstructed PACS solution to replace our traditional PACS.

VISN 23 encompasses all of Minnesota, Iowa, North Dakota, South Dakota and Nebraska and small parts of additional surrounding states.  The largest facility is Minneapolis with 130,000 studies per year.  All told, the 11 facilities register 460,000 studies per year.

Prior to making the decision to proceed with a deconstructed PACS, the VISN 23 PACS and Imaging Service lines achieved successful implementations of various PACS “sub-components”.  These consisted of Corepoint Healthcare’s HL7 integration engine, PowerScribe 360®, Laurel Bridge Compass® DICOM Router, Pacsgear PACS Connect®, TeraRecon Intuition® Advanced Visualization as well as various CD burning and importing solutions across the enterprise.  Having the experience of researching, evaluating and procuring these various components encouraged the teams to move forward with a fully deconstructed PACS.

The primary three components of the deconstructed PACS in VISN 23 are Visage Imaging as the viewing solution, Lexmark Acuo as the VNA and Medicalis as the radiologists’ worklist. Due to concerns about bandwidth across the enterprise, VISN 23 chose to install a Visage server at 8 of the 11 campuses along with an Acuo local server which Acuo labels a “temporal”.  Acuo data centers are installed at both Minneapolis and Omaha with DICOM replication between these two.  The Medicalis servers are installed in Omaha.  Also installed in Omaha are the HL7, modality worklist and PowerScribe servers for the enterprise.

Prior to deconstructing the PACS, VISN 23 made extensive use of DICOM routers to ingest studies from the modality layer.  Also a third party modality worklist solution purchased from Pacsgear was implemented well ahead of the deconstructed PACS.  This allowed the biomed teams to fully configure the modalities to interact with these two systems before during and after implementing a deconstructed PACS.  This freed up time and resources during the actual implementation of the primary three components of the deconstructed PACS.

The VISN 23 team faced several challenges during implementation. First, we discovered that new internal policies prevented installation of the Visage viewer on enterprise desktops for clinical use.  Second, since the legacy PACS hardware was at end of life, implementation was begun before the legacy studies had been migrated.  Therefore, at the first site, we initiated a “just in time” or “Ad Hoc” migration meaning priors were retrieved from legacy systems for current studies as they were performed.  However, since we had to maintain the legacy PACS for the enterprise desktop viewer, we had to be cautious to avoid overburdening the legacy PACS with prior retrievals.  We managed this, but it was a delicate balancing act that went on for nearly six months.

Another challenge VISN 23 faced (and will continue to face regardless of PACS type) is that the VA’s HIS/RIS, known as VistA, will only generate an HL7 message at the time of patient registration.  This means that, essentially, there is no pre-fetch but rather a “post-fetch” or “just-in-time fetch”.  As we worked through the issues, there were times when priors were not fully available for the radiologists.  In response to this, we had a few users who innocently fetched entire jackets on multiple patients to get priors.  This caused serious system performance issues. This was easily remedied with education.

VISN 23 teams also discovered during the process of migration and priors retrieval that there were inconsistencies in some DICOM tags on these legacy studies.  We addressed this by using the evaluative tag morphing and writing capabilities of the DICOM routers mentioned earlier.

Lastly, at the request of the radiologists, support teams went back to the study description source in VistA’s RIS and improved the efficiency of the descriptions.  For example, if a CT Chest and a CT Abdomen/Pelvis were acquired together, all of the images were usually stored under the CT Chest description.  We modified the description for these studies to read “CT (CAP) Chest”.

Successes achieved during our implementation were several. The viewer and VNA were able to achieve a very tight integration for study and patient splits, edits, merges, and so on.  We found it much easier to view images from other facilities. Clinical staff easily adapted to the Visage viewer on the enterprise desktop.  The tag morphing and writing will lead to a much cleaner database.  The server side rendering of the Visage viewer allowed near instant viewing of even volumetric CT studies using minimal bandwidth. 

In summary, our vendors worked remarkably well together. VISN 23’s experience proved that a deconstructed PACS is a feasible alternative even in a challenging security environment such as the VA.

The author, Michael Ryan played a leading role in the implementation of the deconstructed PACS in the VA Midwest Health Care Network (VISN 23).  Michael has since retired from the VA and is now providing consulting services as MCR Consulting, LLC.  You can reach Mike at MCR Consulting, LLC,

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

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.