Friday, August 10, 2018

Do I need to File a 510(k) for my PACS?


Over the past several months many of our clients have asked us questions about whether their future products need a 510(k). Initially, PACS devices were generally treated as accessories to the imaging modalities with which they were used. For example, medical image digitizers, image viewing workstation or medical image printer were considered by FDA to be accessories to stationary x-ray, MRI or CT systems. However, with the significant expansion in the functionality of medical image management products, FDA realized that the identification of many of these products as accessories to specific radiological imaging modalities was no longer appropriate.

This realization led FDA to publish the “Guidance for the Submission of Pre-market Notifications for Medical Image Management Devices” in July 2000. This guidance is applicable to medical devices that provide functions related to the management of medical images after acquisition, of which PACS (as defined by the FDA), is only one of five classifications. By the way, the guidance does not address image-processing devices that utilize artificial intelligence (AI) or other techniques to identify abnormalities in medical images or assist in diagnosis. AI is currently being addressed under the FDA Guidance; Computer-Assisted Detection Devices Applied to Radiology Images and Radiology Device Data - Premarket Notification [510(k)] Submissions Document issued on: July 3, 2012.(more on that in a later blog post).

The “Classifications for Medical Image Management Devices” are;
1)     Medical Image Storage Device (892.2010) - is a device that provides electronic storage and retrieval functions for medical images. Examples include devices employing magnetic and optical discs, magnetic tape, and digital memory. This device type is Class I and exempt from 510(k) requirements. 
2)     Medical Image Communications Device (892.2020) – is a device that provides electronic transfer of medical image data between medical devices. It may include physical communications medium, modems, interfaces, and communications protocols. This device is also Class I and exempt from 510(k) requirements.
3)     Medical Image Digitizer (892.2030) - is a device intended to convert an analog medical image into a digital format. Examples include systems employing video frame grabbers, and scanners that use lasers or charge-coupled devices. This is a Class II device and a 510(k) must be submitted to FDA.
4)     Medical Image Hardcopy Device (892.2040) - produces a visible printed record of a medical image and associated identification information. Examples include multiformat cameras and laser printers. These are Class II devices and a 510(k) must be submitted to FDA.
5)     Picture Archiving and Communications System (892.2050) - provide one or more capabilities relating to the acceptance, transfer, display, storage, and digital processing of medical images. Its hardware components may include workstations, digitizers, communications devices, computers, video monitors, magnetic, optical disk, or other digital data storage devices, and hardcopy devices. Software components may provide functions for performing operations related to image manipulation, enhancement, compression, or quantification. This is a Class II device and a 510(k) must be submitted to FDA.

Classifications 892.2010 and 892.2020 are intended to include all medical image management devices whose principal functions are communications or storage. Classification 892.2050 is intended to cover devices that have not been included in the other Medical Image Management device classifications (i.e. 892.2010-2040).

The confusion regarding the applicability of 892.2050 has occurred because the term "PACS" has commonly been used by industry to refer to all types of medical image management devices. However, the FDA classification in 892.2050 is not intended to include products whose principal function is only medical image communications and/or storage. These devices are classified Class I under 892.2010 and 892.2020.

In many cases it is not clear cut if a device should be classified as a Medical Image Communications Device, a Medical Image Storage Device, or as a Picture Archiving and Communications System. In these cases, the classification is determined by reviewing the additional functions performed by the product. Simple manipulations that do not alter the image data, such as window and level, pan and zoom, and image annotation are considered to be within the scope of the communications and storage functions and no 510(k) is required. A typical image viewing workstation falls within this classification. However, image-processing functions, which are intended to alter the image data (e.g. filtering, multiplanar reconstruction, and 3D reconstruction), are considered to be outside the scope of the storage and communications functions and fall into the PACS classification where a 510(k) must be submitted.  Also, complex quantitative functions (e.g. measurements, arterial stenosis evaluation, ventricular volume calculations, and calcium scoring) are not considered to be communications and storage functions and these types of functions are treated as PACS, requiring a 510(k).

Hopefully, I have reduced some of the confusion but if you have any questions or need assistance for product classification and/or FDA clearance, don’t hesitate to contact us.

The author of this article is Carl Alletto, OTech Senior regulatory consultant. OTech filed more than 100 PACS related 510(k)'s for both US and international based companies, see list here.

PACS System Administrator: only for “geeky” Techs?


When talking with an administrator about the best qualifications for people to support the PACS
systems in radiology, he told me that he had his best experience with hiring “geeky” techs, meaning RT’s that have a knack for computers. I tend to agree with him. It would be hard to teach someone with only an IT background the ins and outs of image quality, how to map procedure codes and series descriptions to hanging protocols, and deal with issues in workflow.

At the same time, a “geeky” tech who is not afraid of computers, can take additional training and learn quickly and get the required skills to get by. As a matter of fact, in our PACS training, students with an RT background have been the largest group represented. There has been a lot of discussion on whether a PACS system administrator (SA) should have a clinical or IT background, and the consensus seems to be that either one can do a good job, with each bringing specific expertise to the table. I would argue that the best approach is to have a team with different skills, assuming you can afford more than one PACS SA to start with.

Regardless of the background, for those professionals considering a career change, here is what a “typical” PACS SA does on a day-to-day basis:

·     Data Integrity (“fix-ups”)
Data integrity refers to the information that is typically stored in the so-called “image header.” When the information is correct, an image properly shows the corresponding patient demographics on the viewing system and allows for unambiguous storage and retrieval. When this fails to happen, and one or more elements are missing – usually some part of the patient information, it results in what most users refer to as a “broken” or “unverified” study.  A broken study is when an image or set of images is not properly identified. Broken studies must be resolved or placed in a temporary folder or holding area. It is the SA’s job to implement a process to handle broken studies, and manage problems associated with them. In many institutions, this activity is done by the technologists as it is often caused by them incorrectly entering or matching studies, so the PACS SA typically only deals with complicated cases.

·     Project Management
Comprehensive coordination of a new PACS or upgrade installation is a big undertaking. Understanding the workflow directly impacts successful project management. Creating a map of information flow, and thoroughly understanding the interaction, as well as information storage and retrieval will help define system placement, configuration, routing, testing, and maintenance. Mapping should commence with collecting the patient information, going through the examination process, and ending with image viewing, storage, and diagnostic report generation.

Post-installation management includes software upgrades, adding new modalities, workstations, interfaces, or users to the system. Successful management of these jobs involves anticipating cause and effect relationships. For example, if a software upgrade is scheduled at noon on Sunday, will all users be trained on the new features within an acceptable timeframe?

·     Training
Training is important for the smooth daily operations and management of a PACS system. SA’s will work with vendors to train users on new releases and upgrades, as well as develop materials and curricula for the staff. They will create “cheat-sheets” to replace often bulky and unreadable manuals or on-line help. A vendor will typically “train a trainer,” which is most cases the PACS SA.

·     Support
Support follows training. Hardware and software issues, operator questions and errors, system bugs or failures, and emergency situations all require hands-on, immediate support. The SA must be available “on-call” in the event of a support need. Most support activities fall under the job description category of system maintenance; be prepared to have to be available 24/7 and get compensated for it.

·     Managing Software and Hardware Configurations
Documenting and physically mapping the system prevents potential compatibility issues whenever making a change to the system i.e. adding a new CT or upgrading ultrasound software.  Recording new installations and upgrades of software releases goes hand-in-hand with this process. It’s important to know which devices run with which software for future upgrade purposes. Lastly, hardware configuration, and changes should be documented as well.

·     Configuration Control Board
The PACS system typically interfaces with a Radiology Information System (RIS), Voice Recognition System (VR), the Electronic Health Record system (EMR) and acquisition modalities. As such, it is important that the people managing these systems and devices communicate regularly. These groups of people make up a “configuration control board,” and are responsible for planning events that will collectively affect their system(s), or device(s). They discuss the potential impact of any new addition or change to their system (or device), and how it may result in a functionality issue with another system (or device).

·     Preventive Maintenance
Preventive maintenance drastically reduces problems and issues with the PACS system. Several components comprise preventive maintenance and can be managed with a simple checklist. Monitoring image quality among modalities, workstations, and printers; checking unresolved study queues; making sure the network is up and running; and checking critical processes such as the database, are functions commonly found on a preventive maintenance checklist.

·     General System Maintenance
This task can be described as cataloguing users, and assigning them appropriate security access. It goes hand-in-hand with the Health Insurance Portability and Accountability Act (HIPAA), which deals with patient privacy and security. Hospital employees are provided with varying degrees of access based upon their authorization level, which depends on the role in the healthcare process.

·     Modality Acceptance Testing
This activity is performed with every new piece of equipment that is added to the system. The best way to execute acceptance testing is to maintain a “shadow system” that reflects the same characteristics as the main PACS system and is basically a “mini” or test PACS. Having a fully duplicated system with reduced storage capability is critical.

·     Image Quality
Proper acquisition of an image is the first step in achieving good image quality. The skill level of an RT, whether they over- or under-expose a patient, impacts how the image appears. The patient, unbeknownst to them, also affects image quality.  Movement during an exam can contribute to “fuzziness” of an image. It is critical to be able to identify whether a “noisy” image represents a bone, tissue or organ with disease, or whether it is due to a quality issue. In this specific example, a noisy image could very well be caused by under-exposing a patient, or an image processing error. When troubleshooting an image quality issue, a PACS SA must consider all of these factors.

·     Image communication
Digital images can be transferred from a hospital to a doctor’s home or from a clinic to the main hospital using compression. Common types of compression include lossy, in which the image may lose some of it’s detail, and lossless which maintains the integrity of the image. Managing image quality through this process is important, and if a problem occurs, it needs to be determined whether it lies with the compression, or the image acquisition. The ability to determine the root of the problem is essential for a PACS SA.

·     Manage Off-line storage
Short-, mid- and long-term storage solutions, e.g. to archive images that are a few months old for immediate access, or for up to more than e.g. seven years old for access within minutes, are an essential part of the PACS system. In case an institution decides to have certain studies off-line, or in the cloud, the SA typically “mounts” the specific media on a reader or makes sure the images can be fetched from the remote storage depending on whether the images have to be used as comparison for a new study.

The challenging work of a PACS System Administrator has numerous and varied tasks. A PACS SA is often someone with interdisciplinary skills, the ability to multi-task, be a forward thinker, and handle crisis management well. It requires clinical, technical, training and people skills, and can be a fun and challenging job for those who are up to it.





Monday, July 30, 2018

Help! PACS is Down!


There is no question whether your PACS will go down or not, the only question is when, how often and how do you prepare and anticipate it, in other words, how can you minimize the panic factor?

Downtime is generally understood as the period during which a system is non-functional or cannot work. Note that it does NOT include the time that a system is potentially slowing down as it is auto-repairing a failure, such as can be the case for a disk crash which is part of a redundant RAID configuration, or a server failure, which is automatically taken over by a mirrored server. It does not include scheduled downtime either, which is used for software upgrades and maintenance.

According to Mike Cannavo, aka “the PACSman,” a typical RFP for a PACS system requires an uptime of the mystical “five nine’s,” which is 99.999 percent, or 5 minutes/year. However, I have yet to see a PACS that is down only 5 minutes/year, a more realistic number according to Mike is 99.5%, which equates to about 44 hours, which includes scheduled downtime. However, it is critical to have a measure of system performance that constitutes a “downtime,” for example, I would consider retrieval time of an image slowing down to one minute a downtime, while others might not.

What is a typical amount of downtime? I usually ask my PACS system analyst (SA) students when was the last time that their system was down, and I have found that it ranges widely, between one student whose system went down once a week (I would not want to be on call for that system) and those who can’t even remember the last time it was down as it was several years ago. Based on their feedback, it appears that once every six months seems to be the norm and/or average. The average downtime seems to be a couple of hours. Taking into account the numbers from Mike, that seems to be not far off the norm.

Which measures can you implement to take the panic out of a system going down, i.e. considering it being an unscheduled downtime?

1.      Have well-defined downtime procedures, which are visible and have all the users trained on how to use them. The procedures depend on the user, so have a little “cheat-sheet” at their desk telling them what to do. For example, for a technologist at a modality, it might say “select alt PACS” to send images to, for a radiologist it would say “select alt PACS worklist,” text PACS SA, or “Use web viewer,” etc. And as mentioned, train the users so they know what to do.
2.      Have a test system. Surprisingly enough, when I did a poll, I found out that only about two-thirds of users has a test system in place. Not only should there be a test PACS but also a test worklist provider, voice recognition system, and any other critical component. The test system is used to test updates, including patches, train users in new features, and most importantly provide a “life-support” while the system is undergoing scheduled maintenance or experiencing an unscheduled downtime.
3.      Use mirroring. This is different than having a test system, a mirrored system is a fully functional, operational duplicate of the main system, preferably at a different location. For North Texas where I am based, that means sufficiently far away that a tornado would not hit both centers, for southern Louisiana it would mean in another state not subject to the same hurricane or flooding. For California that would mean not on the same fault line subject to an earthquake.
4.      Test your downtime backup. How do you know if your backup solution works? You’ll have to test it, which is a legal requirement for the state of Texas for all government/state institutions. For example, at UT Southwestern in Dallas, they will run their orders from an external system once a year to show it can be done.
5.      Have an alternate workflow for critical areas. One of my students told me that he burns a CD for all cases in the OR and sends them up to the location every day, just in case the system goes down. The same can be done on-demand for critical cases in the ICU in case PACS (or the network) is down. Or, subsequently, one could burn CD’s in the ER for reading at a stand-alone station in radiology.
6.      Have a dual source for the information. Many hospitals used to have a separate web server that stored a copy of the images in a web-accessible format that can be viewed from any PC in case the PACS is down. Unfortunately, from a redundancy perspective, many of these web servers have gone away as PACS systems have integrated those in their main archive. The trend to have a separate VNA as an enterprise archive, however, gives back that duplication.
7.      Have more than one access point. In addition to having multiple sources of the information, having multiple access points is just as important, such as the capability to look at images on PC’s, tablets, or even a phone, not necessarily with the same quality but good enough for an emergency. This is not unheard of, I know of a surgeon who takes a picture with his phone from his view station and shares these with his surgical team on a regular basis.
8.      Reboot, re-initialize on a regular basis. In the early days of Windows implementations there were quite a few hiccups and I remember that we were able to reduce the downtime significantly by auto-rebooting each computer automatically every night at midnight. Software is sometimes funny; there can be “loose threads,” unclaimed or unreleased blocks of memory, or multiple unnecessary background processes running that could impact performance or reliability which is simply cleaned up by a reboot.
9.      Be aware of external factors. One of the most common reasons for system downtime is people cutting through cables, or sharing the wiring closets with plumbing. This is especially common when there are multiple campuses, where there could be someone digging a hole somewhere and impacting power or network availability. Even air-conditioning can bring a system down. Just last week a major brand-new facility here in the north Dallas metroplex had to shut down its server room as the A/C was down. And, for some reason, architects like to position IT in the basement, which obviously is the worst place for flooding and water breaks. Ideally it would be best to locate them on the top floor of a building, but realistically that is in many cases prime real estate.
10.   Constantly monitor your weak points and critical components. When I visited a PACS SA room not too long ago, I saw a monitor on one of the desktops that was scrolling a set of what looked like text strings. Upon asking, he told me that these are his RIS feeds containing all the orders for his PACS. He had no clue as to how to interpret the HL7 order messages, but he knew that as soon as the screen would stop he had a problem, as orders are not coming in anymore. As most of you know, in a typical size department, a one-hour RIS downtime results in a full day of fix-ups at the PACS back-end so he was very keen to monitor that data stream non-stop.

Being down does not have to result in panic. If proper procedures and methods are in place everyone knows what to do and you have time as an imaging and IT professional to fix he problem and get the system back up and running. In addition, having the right infrastructure and architecture as well as tools are essential. But system reliability is a factor, if your system is down once a week you might want to look for another vendor.

Tuesday, July 10, 2018

DICOM connectivity maturity model


The majority of the PACS installations do not use good practices. The main reason is a lack of
education and knowledge, both from the end-user (PACS administrator) side as well as from the vendor side. Service and support engineers typically want to be in-and-out and avoid any extra work and might not set up the more advanced features of your PACS. The same applies for any new modality connections; the company engineers will set up the bare minimum and not want to bother with any advanced capabilities, which will impact your workflow and operation.
Here are my recommendations for the most important good practices, organized in different steps, each representing an incremental maturity level.

1.      Use common sense AE Titles and standard ports – the DICOM AE-Title is a fixed application level address of your DICOM application. Most devices have one AE-Title, some have multiple (e.g. a PACS might have four, one for its archive, one for the image manager/database, one for the print server and one for the modality worklist provider). Use only upper case characters and the control character “_” (it is case sensitive), use easy to remember mnemonics (e.g. CT_ER), and prefix it with the facility code to make cross-enterprise connectivity easy (e.g. STJGNL for St. Joseph General hospital). Remember you only have 16 characters to encode these, so be creative.
The well-known DICOM port which many use is port 104, however, this might not always be available as some systems limit access to the lower number ranges. To prevent potential conflicts, stick to the “official” DICOM port number, which is assigned by the Internet Assigned Numbers Authority (IANA) as 11112.

2.      Standardize on a preferred Transfer Syntax  – Many modalities have the option to offer Explicit VR when they negotiate transferring images and other objects. Always select this option, don’t use Implicit VR unless you absolutely have to. Explicit VR requires a sender to specify the VR (data type) for all of its header attributes, which is useful for private data. In addition, if you ever want to exchange the images on an exchange media such as a CD, implicit VR could cause issues as it is not allowed on exchange media.
Avoid using Big Endian, which has become less of an issue as most modalities today use Little Endian Byte order, however, if there is an old modality which uses the Unix operating system (and therefore the Big Endian encoding), configure either the sender to only send Little Endian, or configure the receiver to accept only the Little Endian. The reason is that some viewers might not be able to view those, and, similar to the Implicit VR encoding, it is not allowed for exchange media.
Stay away from any proprietary compression encodings, i.e. that are non-DICOM standard, and use the standard JPEG lossless and lossy for your modalities and Wavelet Lossless and Lossy for long term archiving.

3.      Avoid any proprietary and raw image objects (SOP Classes) – There are two types of proprietary objects, the first type is easy to recognize as it carries a proprietary unique identification (UID), which means that they are easy to detect. Many PACS systems will refuse to archive them, and I have incompatibility issues with these if someone puts them on a CD for image exchange, for example, it is not uncommon for private CR objects to end up on CD’s. Other applications are the 3-D private ultrasound or angio/cardio applications. The second group of proprietary objects are the ones that are “standard” on the surface, i.e. it is a standard image object such as a CT or secondary capture, but under the cover it is really another object, which became popular with the onset of the new breast tomo-synthesis modalities. The latter created a lot of incompatibility issues, one vendor would be able to recognize that the CT image was really a mammography but anyone else would get really confused and hanging protocols as well as pre-fetching algorithms would fail.
With regard to archiving raw data, I come across institutions that archive their raw data for mammography images. The raw data is only used to run a CAD algorithm, and unless you are an academic institution and want to save this raw data to test future new CAD algorithms, this would more than double your mammography image storage requirements. Only keep the image data, and don’t archive the raw data.

4.      Archive only thick slices and enhanced “anything” image types (SOP Classes) – CT scanners are increasing their number of slices, a 64-slice is becoming more or less the standard. However for cardiac applications, one might have a 320- or even up to 640-slice detector. The number of thin slices can easily run into the thousands. These thin slices are great for 3D imaging as they allow access to “orthogonal” voxels, i.e. having identical resolution in any direction to allow for lossless MPR, and 3D rendering. However, these thin slices don’t really provide additional clinical information that can’t be seen by averaging multiple thin slices into thick slices and stacking them for review by the radiologist. Therefore, keep the thin slices for let’s say a month so you can do additional 3-D views if you wish, but only permanently store these reconstructed 3D’s with the thick, averaged slices and save multiple factors of storage.
The new CT’s, MR’s and also the angio and cardio (“anything”) modalities typically support two types of image formats, the traditional format, e.g. CT or MR image storage and the “enhanced” versions. The enhanced image headers are more comprehensive, have more information, are much more standard with regard to the different series extending them to multiple “dimensions” and information in the header uses standard encoding for most clinical terms. In short, the enhanced versions are a more complete standard encoding between multiple vendors. The hanging protocols are more robust based on elaborate header information. Last but not least, these objects are multiframe, which means that the protocol overhead to transfer a study is more effective as it happens in a single transaction instead of having to use thousands of transactions back and forth to exchange one of these studies.

5.      Use the DICOM workflow services, i.e. Storage Commitment, Modality Performed Procedure Step (MPPS) and Instance Availability (IA) – Almost any modality supports Storage Commitment to provide a secure “hands-off” between a modality and PACS. Using this prevents images from falling between the cracks and getting lost. The same applies for the hands-off between a PACS and VNA, or cloud storage. It is just a matter of configuring this feature. The same applies for using MPPS, use it where you can as it provides a hands-off between the modality and PACS allowing for studies to appear on a radiologist worklist as soon as they are available, and automating any updates caused by changes in the procedures. IA is even better for identifying that processing and/or reading can be done as a next step. Also make sure your PACS and VNA support the new IHE profile IOCM (Image Object Change Management) to synchronize any changes in patient demographics, which will save your PACS administrator a lot of extra work.

6.      Use Structured Reports instead of a screen capture for CT dose and Ultrasound measurements, and switch off embedded US annotations – It is easy for a radiologist to look at the CT screen containing the dose information and record that as part of the report (which has become standard practice), however, a digital interface to the reporting system would allow this information to be automatically captured, saving time, increasing accuracy, and having much more detailed information in these reports that can be used for quality reporting and improvement.
Use Structured Reports for measurements from your ultrasound instead of re-recording all these measurements which is time consuming and prone to errors. Using the true digital interface to a reporting system is much faster and more accurate.
Switch off embedded ultrasound annotations. There is absolutely no need to have the patient name “burned-in” the image data as the DICOM header has this information. Burned-in data is very hard to get rid of in case corrections have to be made to the name, or the data has to be anonymized for whatever reason.

In conclusion, none of these features are new, they are proven, established more than 5 years ago, available in pretty much all of the systems out there, and activating them is just a matter of configuration. If you do so, you will be able to provide a more robust and more efficient infrastructure to your medical imaging department. And, as an extra bonus, you could claim to be compliant with a certain level of DICOM connectivity maturity. 100 percent compliance might be hard, but I would argue that 80 percent compliance for each level would qualify.


Tuesday, June 5, 2018

SIIM18 meeting: Is AI reality yet?


The Artificial Intelligence (AI) hype from the RSNA meeting in Chicago definitely spilled over to the SIIM meeting held at the National Harbor in DC, May 31-June 2, 2018. There were several new upstart companies that were showing various new algorithms being applied to medical images and there were quite a few presentations about this subject.
Here are my top observations on this subject:

·        AI is nothing new – As Dr. Eliot Siegel from the VA in Baltimore said at one of the sessions. “I use AI all day, when I use my worklist, when I do image processing, or when I apply certain calculations; I have been doing that for several years before the term AI was coined.”

·        The scope of AI is continuously changing – as pointed out by the anonymous Wikipedia contributors on the definition of AI, what was considered AI technology several years ago, e.g. optical character recognition, is now considered routine; in other words, “AI is anything that hasn’t been done yet.”

·        Even the FDA realized that CAD (a form of AI) is becoming a mainstream, mature technology. The FDA has proposed reclassifying what it calls radiological medical image analyzers from class III to class II devices. The list includes CAD products for mammography for breast cancer, ultrasound for breast lesions, radiographic imaging for lung nodules, and radiograph dental caries detection devices.

·        AI can determine which studies are critical – With a certain level of confidence, AI algorithms can distinguish between studies that very likely have no finding and those that require immediate attention and sort them accordingly. Note that this requires the AI software to be tightly integrated with the workstation worklist that drives the studies to be reviewed for the radiologist, which could be challenging.

The "AI" domain name has become
popular among these early
implementers
·        There are many different AI algorithms, and none of them are all inclusive (yet) – If you would take all of the different AI implementations, one might end up with maybe ten or more different software plug-ins for your PACS, each one looking for a different type of image and disease. Even for one body part an AI application does not cover each finding, for example, looking at a vendor’s chest analysis, it listed 7 most common findings, but it did not include the detection of bone fractures.

·        What about incidental findings? – The keynote speech at the SIIM was by e-patient Dave who made a very compelling case for participative medicine, i.e. partnering with your physician, being possible by sharing information and using web resources. His story started with an incidental finding of a tumor in his lung which happened to show up in a shoulder X-ray. If this image was being interpreted by AI that was only looking for fractures, his cancer would have been missed, and he would not have been here today.

·        There is no CPT code for AI – This leads to the question of how to pay for AI. Especially for in-patients, for whom additional procedures such as processing by an AI algorithm are an additional cost. Any extra investment and/or work needs to have a positive return on investment. This would be different of course if AI can improve efficiency, accuracy, or has any other measurable impact on the ROI.
Example of Presentation State
display on image

·        Consistent presentation of AI results is a challenge – AI results are typically presented in the form of an overlay on the image and/or in combinations of key images indicating in which slices of a CT, MR or ultrasound study certain findings are shown. These overlays are either created in the form of a DICOM Presentation State (preferably color) or, if there is no support for that, as additional screen saves with the annotations “burned” into the pixel data, both appearing as separate series in the study and stored on the PACS. A couple of AI vendors noted the poor support by PACS vendors of the color presentation states as several of those apparently changed the display color upon presentation on the PACS workstation.

·        Few vendors display the accuracy – It is critical for a physician to see the accuracy or confidence level of the AI finding. However, as noted in one of the use groups, accuracy is more than just sensitivity and specificity, and there is no standard for that, i.e. how would one compare a certain number between two different vendors?

The definition of AI is being debated, some prefer to call it Augmented or Assisted Intelligence. Some argue that it is nothing new, and indeed, in practice the definition seems to be shifting towards “anything new.” Implementations are still piecemeal, covering relatively small niche applications.

As with self-driving cars, or even auto-pilots in a plane, we are far from relying on machines to perform diagnosis with a measurable and reliable accuracy. In the meantime, for routine tasks AI could provide some (limited) support. An example is for TB or mammography screening, where an AI algorithm could determine that with 99.999 % accuracy there is no finding. The question is what to do with the 0.001 % and with incidental findings, which could become more of an ethical than technical issue.

Tuesday, May 1, 2018

Does a Deconstructed PACS make sense for you?


When I was a young student in engineering school I built my own “deconstructed” sound system. By Bombardon” bass speaker and tweeter (no, nothing to do with Twitter), veneered the enclosure and using speaker cloth for the front. It was a lot of fun but in a different time frame given the fact that Radio Shack just went bankrupt as people today don’t do this kind of thing anymore.
building I mean, tracing the printed circuit and etching out the tracks according to a published schematic, buying the components (capacitors, transistors, resistors, and transformer) at what was the equivalent of Radio Shack, building a chassis from aluminum and creating a front plate and enclosure. I even built my own speakers, using at that time what was the famous Philips “

So, why would anyone build their own PACS from the ground up? As with building any sophisticated electronics system, whether it is a sound system, a gaming computer, or a PACS system, it is not for the faint of heart. But, in some cases, it does make a lot of sense. Before deciding if it makes sense for you, let’s look at the pro’s and con’s.

Arguments “for” implementing a deconstructed PACS:

1.      You get best-of-breed – For example, you go to a trade show such as RSNA or SIIM and you see this really nice workstation that does everything you need, in other words it has all the bells and whistles you would ever want. Or you really need to use this super-duper modality worklist provider that allows you to filter the worklist by location, station name, referring physician, and much more. Or, you found a workstation worklist provider that allows you to manage different worklists from several PACS systems all from different vendors. You can’t just carve out one piece at a time from your existing PACS so you will have to start building your own.

2.      It addresses a specific need that nobody else in the market is able to provide – For example, despite the fact that almost every vendor says that they provide a VNA, a true fully functional VNA with full support of the applicable IHE profiles, comprehensive tag morphing and routing as well as DICOMWeb implementation is relatively rare among the “traditional” PACS vendors. Therefore, you might be forced to look around for third party solutions, hence the start of a deconstructed PACS.

3.      It provides a major workflow advantage – A single department consisting of one specialty does not pose a lot of workflow challenges, but if a radiology group supports let’s say more than 10 hospitals each having a PACS from a different vendor, and there is also a extensive teleradiology component, you might be forced to look at solutions that support that type of workflow.

4.      It provides economy of scale – Imagine you are the CIO of a large hospital chain, which could be 15 to more than 100 hospitals. Similarly, you can imagine being in charge of IT for a VISN (Veterans Integrated Service Network) within the department of Veterans Affairs. Having to purchase and support multiple systems leads to duplication, therefore, sharing resources makes good sense from an initial cost, support and maintenance perspective. That is why the VA has some of the best examples of deconstructed PACS implementations using a single image archive/VNA solution for the whole delivery network and uses third party routers, worklist providers, and workstations.

5.      It allows for a “gradual” implementation – If you have a large monolithic system, it is often implemented in a “big-bang” kind of manner, i.e. on Monday morning 8 am everyone goes from the “old” to the “new.” Using a deconstructed PACS, you can phase implementation, which can be advantageous especially if you have a large-scale deployment. You can start by first implementing a modality worklist, making sure all your modalities are connected and working, followed by the archive, then switching the workstations, voice recognition, etc.

Arguments “against” using a deconstructed PACS:

1.      Deploying it is a lot of work – Instead of shopping for one component, you’ll be shopping for a VNA, workstation workflow manager, modality worklist provider, router(s), radiologist workstations, physician workstations, 3-D and other miscellaneous capabilities such as dose reporting, critical result reporting, peer review package, and I probably missed a few more. You’ll have to work with many different vendors for selection, contracting and implementation.

2.      It requires expertise – You need an educated purchasing team, an IT team, integration team, you need dedicated PACS administrator staff for staging, managing the migration, training, and project management. You’ll need experts in DICOM, HL7, and IHE and very likely will need to train your staff in those skills and send them back to take a seminar or training course. Most of this is not needed or needed to a much lesser degree if you purchase everything from a single vendor.

3.      It could be more expensive – I say “could” because it is not quite clear. Note the analogy of building a car from its parts, it costs about 5-6 times as much, which is the reason stolen cars are typically cut up and sold as parts. Big contracts for monolithic systems are often discounted as well, so you could be paying more for these parts. However, you can also do better shopping for some of the components. Note that “best of breed” could include “best breed for the money.”

4.      There is no single vendor contact for support – Service for these relatively complex systems is still a big differentiator, so having a single number to call might be advantageous, as you reduce the amount of finger pointing. However, one could also argue the opposite, as service is rather expensive, you could potentially save a lot of money by managing the level of in-house support. But there is no question that having a single service contact point has its advantages.

5.      It is high risk – You can design the architecture and look at the specs but there is a chance that it might not work as expected. There are safeguards you can put in, if nothing else, you should spend a lot of time testing and verifying it. I have seen good examples of that, one of the major institutions I know of used a six months trial and test phase, but the chance of failure is higher than going down the beaten path.

Most decisions are not black and white or obviously one or the other, it is often a balance, weighing multiple pro’s and con’s. I would argue that if there is not a clear advantage for a deconstructed PACS, you might be better off sitting tight for a few more years until these early installations have matured and any gaps have been filled with additional functionality or middle ware solutions. However, I remember building my own deconstructed sound system, I had a lot of fun and a learned much more than I would have learned by buying it off-the-shelf. So, if you are up to it, I’d say go for it!

Wednesday, April 18, 2018

Why you should attend SIIM


Site of the upcoming SIIM conference:
Gaylord at National Harbor
Hundreds of healthcare imaging and IT professionals gather every year at the annual SIIM meeting,
which is coming up May 31 – June 2 in Washington DC. I have attended these events since they were called “SCAR” and have seen the changes in the medical imaging informatics industry being reflected at these meetings over the many years. I am looking forward to attending this year again and would recommend it for any healthcare imaging and informatics professional for the following top ten reasons:

1.      It’s a great place to network. We are working in somewhat of a niche profession. Many institutions have only a single PACS administrator for radiology, and even though you might have a colleague in cardiology and someone in pathology who is getting his or her feet wet in managing digital images, many of you might feel as if you are on a small island. You don’t have many people to talk with about your problems, issues and good practices. At SIIM you’ll find literally hundreds of people who all are in the same boat, many have the same systems you are using, and face the same challenges with their systems, vendors and users.
2.      You’ll be able to find out “what’s new” from a technology perspective. New applications for capturing dose information from your CT’s, software providing Decision Support, AI support tools, and using VNA as the core enterprise archive are all relatively new technologies you want to learn about, to find out if they make sense for your institution.
3.      You’ll be able to discover “what’s new” from a vendor perspective. Mergers, consolidations, acquisitions, new company names and branding are very common in our industry. If you are using a vendor who is not exhibiting at SIIM you might think about having a plan B i.e. replacement strategy. Sometimes it is just a matter of knowing the new name. Don’t be looking for your ACUO VNA, McKesson or Merge PACS but rather for Hyland, Change Healthcare and IBM.
4.      At SIIM you have a much better opportunity to kick the tires than at other tradeshows. Compared with large trade shows such as RSNA where you must make appointments to get a demo on a tiny monitor with three rows of people in front of you, at SIIM you can walk up to a friendly sales rep and get a one-on-one demo of the latest product features. This is important for new purchases and upgrades.
5.      You can talk with your vendor especially with large companies, and ask about specific problems, whereas it might take a while to get your messages through about certain features, issues, workflow solutions, or alternate solutions the rest of the year, at SIIM your vendors are easily accessible. Note that this works both ways, trade shows are key for vendors to collect data from customers about what features they like and don’t like, and what upgrades they would like to see prioritized in upcoming releases.
6.      Find out from other users about specific issues. Again, as an imaging professional you are somewhat on an island and you might find out that a nagging issue is not unique to your specific installation or use, even though a vendor might say “we don’t see the same problem anywhere else.” There is a strength in numbers, so knowing that your problems are not unique can give you more ammunition to get it fixed
7.      Learn a few new tools and tricks. This is my personal favorite as the learning labs are a great resource to become familiar with, for example using a DICOM sniffer to find out why a device does not want to communicate with the PACS or drops random packets, or is using a validation tool such as DVTK for validating a DICOM header so you’ll know what to fix to enable a physician to view the image. These workshops are highly recommended, and are very popular, so I recommend signing up for these as soon as you can.
8.      Understand what’s hype and what’s real. If you read the social media, radiologists will become obsolete in the next 5 years due to the increase in Artificial Intelligence (AI) applications, we’ll get reimbursed in bitcoins, and if you won’t have a VNA or deconstructed PACS you’ll be left behind by the competition. SIIM is a good meeting to not only hear from experts their opinions, but most importantly from real users, especially the early adopters, what their experiences are. This allows you to decide to jump ship and ride the next wave or wait a few more years until these fads either mature or fade away.
9.      Learn about best practices. Even though most hospitals are somewhat different regarding practices and workflow, there are a lot of best practices that can be shared among these institutions. Quality measures such as ER discrepancies and how to manage these, peer reviews, what is a reasonable number of retakes, and how to minimize these, are good KPI’s to compare against. These can be used to improve efficiency, patient care, safety and cost.
10.   Have fun. My kind of fun is participating in the early morning 5k fun run, have a beer and/or sushi with industry friends and colleagues, and sneak away for a few hours or take an extra day to visit a museum and do some sightseeing. Because of my involvement with the DICOM committee meetings, I have been to DC probably close to 100 times (imagine 6 meetings/yr for at least 15 years…) but there are still parks, museums, neighborhoods to visit or revisit.

When you visit, I suggest arriving prepared and set clear goals and objectives, such as meeting with a minimum of 5 people with the same system, looking for a at least three different replacement solutions, etc. However, have realistic expectations, don’t expect to come back an expert. There is a place for tradeshows such as SIIM, and a (different) place for fundamental, intense hands-on training. 

So don’t expect to become proficient in DICOM or HL7, different PACS architectures, or know the details of using Wireshark or Mirth. Tradeshows are a good place to enhance your training and career but view them as complementary to your other education and training options such as reading textbooks, attending in-depth training classes or seminars.

As a final caution, as you to get back to your own environment over-stimulated, but as you return to your own system with its limited versions, capabilities, budget constraints etc., be prepared for some disillusionment. But at least you can challenge your status-quo and be knowledgeable and share what you’ve learned! And last but not least know that you had fun!

Thursday, March 29, 2018

Critical measures to keep your PACS secure.


A recent article by a McAfee employee stated that more than 1100 PACS systems are currently exposed to the public internet and can be relatively easily accessed to the extent that intruders can retrieve and upload images with few problems. In doing research for his article, he did just that. The fact that certain image files were accessed is troublesome by itself. Even more troubling, medical data was changed. We wonder if someone is paying attention at those sites or if McAfee notified them.

According to HIPAA, if patient data is seen by someone who should not see it, federal law requires doctors, hospitals, and other health care providers to notify those patients of a “breach” of their health information. Patients in turn can file a complaint with the HHS office for Civil Rights (OCR). But, independent from privacy and possibly even ethical questions about this particular experiment, the fact remains that 7% of all PACS systems are completely unprotected.

What does it mean that a system is secure? According to a recent MITA white paper called “Cyber Security for Medical Imaging”:  A device can be considered secure if it defends unintended or unauthorized operation with respect to its intended environment and its intended use—as specified by its manufacturer. Therefore, providing security measures in the device and also infrastructure is a key requirement.

Security for medical devices also got the attention of the FDA. A premarket notification or 510(k) approval for PACS systems has to include a security assessment otherwise it won’t be cleared for use by the FDA. The premarket submission requires several additional documents addressing the security aspects.

Security is not only a PACS issue. At the HIMSS 2018 conference that just wrapped up in Las Vegas, the organization released its annual cybersecurity survey of its 70,000 health IT professionals showing that 75% of the respondents had experienced a recent significant security incident.

Now, back to what you can do to protect your PACS system. Below are the most important measures you can take to guard against internal and external security threats. It consists of three major phases: Identify, Mitigate, and Monitor and Review.
1.   Identify the Threats

·        Inventory your systems – Know your “surface area” for attack. Many times the weak link is an open workstation at a specialist’s office or a modality hidden in an OR that nobody checked. Remember to include your wireless systems as well. The increased connectivity within the enterprise of new specialties, POC ultrasounds and other imaging input and output devices being used by physicians create additional challenges for security.

·        Conduct a security review – Engage an outside auditor to review your systems and conduct penetration testing. Audit your systems’ compliance with the HIPAA Security Rule and PCI standards. PCI applies to payment systems, not healthcare, but they have many relevant and helpful guidelines. Even if you have a strong security team in-house, it helps to have an unbiased “outsider” to review your security plan.

·        Manage your vendor access – Vendors typically access their products as part of their service contracts, which means you could have multiple access points in your PACS. For example, one for the PACS server vendor, several for your modalities, which can be from a couple of different vendors, and you might have third party software for 3-D or other applications, as well as a speech recognition vendor, etc. Make sure that vendor access is limited to their device only and, most importantly, monitor it, i.e. check the audit trails and access logs. You want to know who accessed your devices and when, in case there are issues. It would not be the first time that a vendor made changes corrupting a database, upgrading a software release, installing patches, etc. without notifying the customer.
2. Mitigate the Threats

·        Switch off the promiscuous mode on your devices – Almost every PACS server has a “poor man’s” security mechanism, by which an unknown DICOM application, identified by a DICOM AE-Title that is not in its configuration file, is refused a connection at the Application level aka Association. However, if you have configured your PACS to be “promiscuous,” meaning that it will talk to any AE-Title, it will connect and potentially allow the upload or retrieval of data. The advantage of operating in a promiscuous mode is that every time a new device needs to be connected, you don’t have to change the configuration, however this is very poor practice.

·        Manage access configuration – PACS systems often have some granularity with regard to these privileges, for example, it might allow any device to query its database, but not allow images to be retrieved. If you look at some of the PACS user groups, this is probably one of the top-ten most asked questions: “Why can I not retrieve images from the PACS despite the fact that I can communicate with it.” The answer is that you need to add it to the access configuration file. Manage this access and configuration yourself as a PACS administrator; don’t rely on the vendor to do this for you.

·        Map any connected device to its port and IP address – As part of the access configuration file, most PACS systems will also keep track of who is connecting from what IP address and port number (hence the requirement to have fixed IP addresses using the DICOM protocol). If a device with a known AE-Title suddenly tries to access the server from another IP or to a different port, it should refuse the connection. Again, manage this configuration.

·        Use standard port numbers not port 104! – For security, DICOM applications should run in user mode without root access. Port numbers below 1024 are privileged ports that require root access by the application. The Internet Assigned Numbers Authority (IANA) has assigned a standard “registered” port number of 11112 that should be used rather than the well-known port 104.

·        Secure your perimeter – Use standard IT security best practices to harden your exposure to the outside, such as:

a.     Use a professional firewall – A Stateful Inspection Firewall can analyze packets down to the application layer. The simple packet filtering firewall you find in most routers is not effective against a determined hacker.

b.     Deny-first – Restrict access with a deny-first firewall policy, then whitelist systems and IP addresses that need access.

c.     Use intrusion detection systems (IDS) – An IDS can spot hacking attempts in real-time. An IDS can log and alert you when suspicious actions occur, like the administrative credentials logging into the EHR system at 3:00 a.m.

d.    Use Proxies and Routers – Proxy and router systems from vendors such as DICOM Systems, MedWeb, RamSoft, Osimis, Laurel Bridge and others sit between your PACS and outside systems. These proxies can automate encryption, authentication, anonymization, and more. They provide a security wrapper for DICOM devices to manage the limitations of the DICOM standard. When selecting a proxy system, it’s wise to use a professional vendor. Don’t try to roll-your-own security.

·        Use VPNs for remote access – If you must allow direct access to PACS, use a Virtual Private Network (VPN). These can be complicated to implement and require a knowledgeable IT staff to manage. Don’t be tempted to skip this and trust a password to protect your open ports. Your password will be broken or leaked.

·        Segment your network – Segment your network using Virtual LANs (VLAN) and demilitarized zones (DMZ) where appropriate. Put your public-facing servers in a DMZ. An attacker gaining control of these servers will have limited surface area to attack your internal systems. Use VLANs to segment departments where possible. There is no reason for the shipping computers on the loading dock to have direct IP access to the DICOM network systems.

·        Control access by removable devices – TechAdvisory.org has reported that 25 percent of malware is transferred through USB, therefore, you can eliminate this risk by simply not allowing unauthorized USB drives in secure networks. This protects you by restricting unauthorized data exfiltration and by cutting off a vector for malware intrusion. Disabling the USB ports is easy to do in Windows as an administrator. You can disable USB removable media across the entire domain via Active Directory Group Policy. Remember that this applies to your service providers as well, the last thing you want to have happen is allow a service engineer who just picked up a virus from a “dirty” site to use the same flash drive to infect your network (this happens!)
3. Monitor and Review
·        Check your audit trails – Audit trails for application level access are a HIPAA requirement. If you never look at them, they might as well not be implemented. Regular audits help detect both internal and external access violations of patient data. There are no “standard” guidelines on how often to check the audit trails, but most people we talk with seem to do it once a week, checking random accesses from random people. Support for standard audit trails is important, IHE defines a ATNA profile that provides this information to be recorded in a standard format. Check your IHE integration statement of your PACS system. Further transformation of your audit trails into XES event logs can facilitate process mining.

·        Rinse and Repeat – Go back to step 1. Inventory, audit and conduct reviews. This is a continuous process. You’ll never be finished, but you can be assured that you put the right practices in place.

Will these measures protect your PACS? As many security professionals will tell you, nothing is 100% secure. If someone really wants to get access to your data and/or modify it, there is likely a way. But instead of leaving the front door wide open and put your family jewels on the kitchen table, you can at least have a locked, security system and add another perimeter to secure it, so that potential hackers or intruders will go looking for an easier target.

Herman Oosterwijk is president of OTech and a PACS, DICOM, HL7 trainer/consultant, David Finster consults on security and data protection best practices. We encourage comments.