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.


Tuesday, March 20, 2018

DICOM Experts, Where Art Thou?


This past month alone, I got three inquiries from high tech imaging companies looking for seasoned DICOM professionals; two are wanted on the east coast (Boston), two in rural Arkansas, and if you like skiing and hiking, there is a vacancy in Boulder, Colorado.

One of these positions does not even require US residency, as they are willing to sponsor a work visa for qualified applicants. The reason these inquiries came to me is that there are literally thousands of students who went through the OTech DICOM training over the past 25 years, and therefore, I have a large base of “alumni” among my Facebook and Linked-in friends.

This poses the question, what is an expert anyway? My first source is always the (un)-official source of truth, i.e. Wikipedia:
Historically, an expert was referred to as a sage (Sophos), was a profound thinker distinguished for wisdom and sound judgment. Informally, an expert is someone widely recognized as a reliable source of technique or skill whose faculty for judging or deciding rightly, justly, or wisely is accorded authority and status by peers or the public in a specific well-distinguished domain.
The next question would then be, how to define a DICOM “expert?” To define his or her skills, I like to refer to the official DICOM certification for professionals, which is managed and administered by PARCA. The requirements for this certification include knowing:
1.     Negotiation – How DICOM connections (Associations) are being negotiated and established, i.e. the handshake and agreement on the type of images to be exchanged and encoded such as compression. Note that “images” mean any DICOM file, including dose reports, measurements, presentation states containing overlays etc.
2.     Messages and data elements ­– How DICOM metadata (literally “data about data”), aka DICOM headers that are part of the DICOM file is encoded and can be interpreted.
3.     Storage and Image management – That DICOM protocol services include the capability to query a worklist at a modality, allow for images to be exchanged, get a commitment from an archive about its permanent storage and can communicate study status and changes to the procedure using “Modality Performed Procedure Step.”
4.     Print, Query/Retrieve and compression – There are still a lot of DICOM printers, especially in emerging and developing countries, communicating with the DICOM print protocol, while Query/Retrieve is the interface to a PACS database/archive. Compression specifies what compression schemes are supported and can be negotiated such a JPEG, JPEG2000, MPEG, and others.
5.     DICOM Media – Reliable CD interchange is still a major headache and pain point for many institutions, if only everyone would follow the DICOM standard closely, it would be much easier. One should be familiar with how images are stored on a CD i.e. as so-called “part-10” files and how the DICOMDIR or directory is structured.
6.     Image quality and Structured Reports – DICOM defines a so-called pixel pipeline which specifies all the steps that the pixel data is going through prior to being displayed such as different greyscale/color schemes, annotations, Look-Up Tables, etc. Displaying the images on a monitor that is calibrated using the DICOM defined standard greyscale and color mapping is critical to ensuring that every discreet pixel value is mapped into a distinguishable greyscale or color value. Structured Reports are used for measurements, CAD marks, dose information, key images and other information related to image metrics.
7.     VR’s and conformance – A VR or Value Representation defines the data types, i.e. maximum length and encoding of the DICOM data elements. Knowing where and how to evaluate these allows for spotting errors, the most frequent being exceeding maximum length, invalid codes in the fields, invalid characters, etc. Conformance is critical as it allows checking whether two DICOM devices can communicate using the conformance statements.
8.     Networking – This includes addressing, i.e. use of IP address, port number, and AE-Title, using tools such as DICOM network sniffers as well as interpreting the communication logs and dumps.
9.     Troubleshooting – To troubleshoot DICOM connections, one would use simulators and test tools. The most basic tool is the use of the DICOM Verification, as well as using multiple test images such as those for testing the imaging pipeline and be able to change negotiation parameters
10.  New DICOM extensions – There are several DICOM extensions, such as the specifications “for processing” aka raw data, which typically is used to perform CAD, the definition of the new multi-frame enhanced CT, MR and other image types, using the Universal Worklist and the new pathology image definition. Last but not least, is DICOMWeb, which uses RESTfull services, mostly being used for mobile access and through web browsers and is the counterpart of the HL7 FHIR services.
As you can see, there is quite a bit involved with being a “DICOM expert.” If you feel like honing your skills, you might want to check out available textbooks, training or pursue certification. If you feel you would qualify for one of the “expert positions,” feel free to forward your resume and I’ll be happy to share it with those inquiring about hiring.