Enterprise Imaging Teams: Who, What, When and How?

I’m more and more frequently being asked ‘what does an Enterprise Imaging team look like?’  Given that the term is relatively new, and that there will be variances based on the individual organization’s needs, there are no hard-and-fast rules for creating an Enterprise Imaging (EI) team.  However, there are many components to keep in mind, and in this article, I will share with you some key considerations for EI team creation.  I believe that your EI team is a separate entity from the traditional PACS/CPACS team.  Enterprise imaging teams have a very different tempo and focus when compared to the, more organizationally static, PACS team.  Another foundational aspect of EI team creation is to understand that it is ultimately an operational team, not a project team.  There are certainly some project elements, but the majority of effort is spent maintaining operations versus discrete projects.  The size of the EI team will vary, depending on the size and complexity of the organization, but irrespective of size the ideal EI department will include the following skillsets.

Clinical workflow:  As the EI team works directly with clinical departments it is critical that there is an understanding of how things operate in the ED, Radiology, Cardiology and imaging centers.  Having a deep understanding of workflow will help to keep the EI team patient-focused and able to respond appropriately to the clinician’s needs.

Application administration:  The applications administrators keep the wheels turning and green lights blinking.  This is the hands-on monitoring of VNA queues, image viewer servers, HL7 interfaces etc.  Each system will have some amount of daily work that has to be done to keep them in good health.

Infrastructure: EI systems use a tremendous amount of infrastructure both in terms of storage and network bandwidth.  If not managed correctly this can impact other departments, to the detriment of patient care.  The EI team should have a thorough understanding of infrastructure’s technology at its most fundamental level, and then be able to translate application system requirements back to the infrastructure team.

Project Management:  Even though the team is operational, there are always projects that impact the systems.  PM experience on the team allows the EI group to effectively schedule upgrade and deployment work while interfacing with other project teams.

Training:  As systems are rolled out within the EI department the team will ideally have skilled trainers that can go onsite to instruct local PACS teams and/or physicians in the use of clinic-facing applications.  Not having to outsource all training to the vendor saves the organization substantial money, and allows for the self-service of deployments.

Troubleshooting: The EI team should be consistently working toward the ability to operate as tier 1 and tier 2 support for applications supported.  This is beyond the basics of how to navigate around on the interface, and should include a deep understanding of the back-end of each application. Vendors rarely support your system with the same passion and timeline as your internal resources will!

Data migration: A VNA is only as valuable as the data in it, which means that for the vast majority of systems connected to VNA there is a data migration to be run.  The team needs to be experts in the mechanics of data migrations, particularly in the reconciliation and verification that occurs at the end of a migration.  In general, the EI team should be running data migrations as most organizations will realize a significant cost savings keeping this task inhouse.

PACS Administration: Configuring and supporting EI systems requires a thorough understanding of the systems that they interface with, namely PACS and CPACS.  Many of the problems that EI teams face result from eccentricities of the source systems.  Knowing how each source system is deployed and how they operate is critical to configuring and troubleshooting.

Department head: Ultimately the team leader should be at an appropriate level within the organization to garner the resources needed to operate this critical set of applications.  While all the typical skills are necessary such as managing direct reports, running meeting, budgets, etc., they must also be comfortable operating as Chief Evangelization Officer of the EI team, spreading the word of EI to the rest of the organization, as more departments are included.

Depending on the size and scope of the organization, EI team members may be asked to wear multiple hats.  Delegation of duties notwithstanding, to create an efficient Enterprise Imaging team each one of the skill-sets discussed should be represented.  To go one step further and create an EI team of excellence, start with your foundation and hire the best of the best!  The more effectively your EI team does its job, the more effectively physicians can do theirs.  Great EI team = great patient care!

 

Back to Basics

5 years into my VNA experience the one thing I can say is that, the KISS principle applies.  The only way to easily maintain your system, after it is up and running, is if the build is very orderly from the beginning.  To that end, it cannot be stressed enough that sticking to the basics of system design and deployment is critical.  One way this is achieved is by utilizing well thought-out naming conventions and time-proven, standardized processes.

Before the first system is brought online the team should focus (obsessively so) on the naming conventions.  These naming conventions need to be easily identifiable and baked into every nook and cranny of your system; from AE titles all the way to network shares.  Typical things that one should consider including in naming conventions are: site name, the type of system and the function.  Bearing in mind that AE titles are limited to 16 characters, it is important that the names be easily and consistently identifiable.  During troubleshooting situations, the VNA team will be looking for these names in the logs, so ease of use is paramount.  An example might be HOSA_FS_R_AE standing for hospital A, Fuji Synapse, Radiology, AE title.  The last two characters could be changed to DB for database, ST for storage or any other internal component related to each particular system.  Once the naming convention is set it needs to be passionately enforced as there is often enticement to loosen the standard to fit this site or that site.   Although there might be a circumstance that truly requires it, under 99% of situations you should not give in to this temptation!  Consistency in troubleshooting and training of new VNA team members are only two, of the many, reasons as to why uniformity is key during name convention decisions.

Similar to the idea of constancy in naming conventions is the creation of standard operating procedures.  The team needs to create a checklist for regularly occurring actions, such as: adding systems to VNA, testing new VNA releases, starting and finishing data migrations and verifying during PACS upgrades.  Each of these line-item tasks needs to be simple, straight forward, and DOCUMENTED.  There are many tools available in the VNA and there may be a temptation to get fancy with tag mapping / morphing, adding in sophisticated routing rules or any one of the myriad of features and functionalities that are available.  While these features are useful, remember that customization is the antithesis of supportability.  The team should determine what features and functions to use, and site 100 should be configured similarly to site 1.  This is not to say that there are no circumstances under which customizations should be used, however, they should be build-necessary customizations and not simply because one wants to play with all the cool tools in the toolbox.

There is a myriad of things to consider when planning and architecting a VNA, of which, naming conventions and SOPs are but two.  And, while this idea of a back-to-basics approach is neither new, nor specific to VNA design, it is an intelligent and proven method to utilize when laying the foundation upon which to build your Enterprise Imaging system.

What ever happened to “deconstructed PACS”? More to the point, what would it take to achieve?

Several years ago, “deconstructed PACS” was the hot topic, also called PACS as a service, PACS 2.0, PACS 3.0, de-coupled PACS etc.  During that time many organizations made purchases based on the idea.  These were often a Vendor Neutral Archive (VNA) and a Zero Footprint Viewer (ZFV) for web and EMR viewing of radiology images.  Dictation systems have remained constant and have for the most part always been separate from the PACS.  There are several global worklist companies out in the market that have been around for a long time.   For the most part these worklist systems have been focused on the needs and requirements of teleradiology and large radiology groups.  That said they do a very good job of consolidating multiple sources of data, usually many hospitals and EMRs into a single worklist and assignment engine to get the right radiologist to read the study at the right time.  With all of this technology, why have we not seen the panacea of a deconstructed PACS come to fruition?

The answer surprisingly is that as an industry we have focused on many of the hard problems and forgotten that we still need a system to do what the PACS of yore did, and that is a departmental workflow system for the technologists.  There are several functions that need to occur before image data can be submitted into the machinery of the Enterprise Imaging Systems.  These are, while seemingly mundane extremely important:  DICOM Modality Worklist, Document Scanning, Quality Control (QC) and image management, and order validation, all tasks that are completed by the traditional PACS.  We will explore each of these in turn.

DICOM Modality Worklist (DMWL) is essential, as it ensures that images match an order, and all demographics are correct.  In my belief, a manual process is a broken process and typing in a 16 character accession number correctly is a recipe for disaster. In short something must provide DMWL and it should be used in all cases.

Document Scanning is an area I struggle with as in this day and age we should be able to remove all paper from the process.  I firmly believe that the only documents to be scanned, or electronically completed are documents that are required to be viewed by the radiologist and will alter the diagnosis.  This MUST be stored as a series with the images.  I submit that there is probably a better place for the data (the EMR) but that is another topic.

QC and image manipulation is simply verifying that the images are good and possibly adjusting the window/level.  There is sometimes a need for splitting, merging, deleting and moving images but this has gone down over the years and most of this is done at the modality.  The main point of this step is that this is the last opportunity for a technologist to review the study.  As soon as the image is released it becomes “ready to read” and will be picked up by a radiologist somewhere in the ether.  Given that in the new model it is unlikely that the tech can walk down the hallway and speak to the radiologist this step gains significance.  Like a bad picture on the internet, once it is out, it can’t be taken back.

The final task is order validation, with consistent use of DMWL this step should be not necessary, but in the real-world things happen.  In a distributed system where the worklist is driving reads from HL7, any study that does not match an order will not be read.  It can’t, as the dictation system needs to respond to an order with the report.  The viewer can’t launch it because the accession number does not match an order.  This last verification step is a gatekeeper step to ensure that every study has an order, as my old coach said, “no pass, no play”.

Again, PACS does all of these tasks, so what happens in a deconstructed model?  These tasks could be performed by the incumbent PACS, however most of the old guard has an inflated pricing structure and huge service maintenance contracts.  They tend to be not interested in this market, (or even the imaging center market).  Most of the smaller PACS companies are fixated on the diagnostic reading license and will not un-bundle the software at a relative price point to service this need.  We need a vendor or vendors to supply a light weight low cost departmental workflow system to feed into the enterprise imaging stack.  The only thing holding us back from deconstructing PACS is performing the simplest tasks that PACS does at the right price.  My challenge to the vendors out there is, who wants to fill this need and gain a footprint in almost every large organization?  Bear in mind that as a component of enterprise imaging this could be a foot in the door to then service one of the other components…. I would think that would be an attractive proposition, but the market has not responded thusly.

Buying and Selling Big Data, A Practical Solution for AI and Clinical Research

Every now and then someone asks me about or I read an article about someone selling massive amounts of data to one of the big companies out there.  When you have a lot of data the obvious thought is, I want some of that free money!  As a thought exercise lets look at some of the realities in moving more

than a PetaByte of image data.  A PetaByte is 1,024 TeraBytes or 1,048,576 GigaBytes.  Many, dare I say most VNA’s store data in a near DICOM format, that is close but often not a straight .dcm file.  This means that to get data out you can’t simply copy the file but have to do a DICOM transaction.  There are some that do store in straight DCM, but even so, there is still the issue of de-identification so a DICOM store is not the end of the world.

In my experience a single server tops out at somewhere around 15,000 studies per day or ~500GB.  So, doing the simple math, 10 servers dedicated to nothing but copying this data, ignoring a penalty for de-identification or additional compression will move 1 PB in 209 days.  I submit that this is not practical and there is a better way.

First, we are looking at the problem from the wrong end.  Whether clinical research or training an AI engine, it is likely that the buyer doesn’t want ALL data, they are looking for very specific use cases.  In particular what diagnosis are they trying to research or train?  Instead of dumping billions of images on them and letting the buyer figure it out, perhaps a targeted approach is better.  This begins at the report, not the images.  As I would want to have a long-term relationship and sell my data multiple times I propose that instead of answering a single question like send me all chest x-rays with lung cancer, preparing a system that can answer any question.

So, to do this we would build a database that holds all reports (not images) for the enterprise.  Start with pulling an extract from the EMR for all existing reports, and then add the HL7 or FHIR connection to get all new reports.  With the reports parsed into the dat

abase any future questions or requirements can be answered.  The output of this query would be accession number, patient ID, date of service and procedure description.  Obviously, there SHOULD be a 1-1 relationship between accession number on the report and the images in VNA, but the other data will help if Murphy happens which often does.

Armed with this export a savvy VNA team can do a targeted export of specific data that is needed.  Instead of taking a dump truck and leaving all of the data in the parking lot, one can deliver a very specific set of data needed, and setup a relationship that can be very beneficial to both sides moving forward.  Using this method, one could even prepare a sample set of data for the buyer of say 1,000 exams to which the queries can be revised and updated to get a better and better targeted data set.

Now instead of providing all chest x-rays with lung cancer we can provide, Hispanic non-smoker males between the ages of 15-30 with a lung cancer diagnosis.  I am not a researcher, but I suspect that this type of targeted approach would be more beneficial to them as well as much easier to service from the VNA, in effect a win-win.

Searching for commitment between PACS and VNA

Many moons ago when most PACS was designed the archive was local.  It is the A after all in PACS.   Now that the industry is moving inexorably to a deconstructed model, or PACS as a service the archive is rarely on the same LAN as PACS.  Not only is it not on the same LAN but the fact that it is a separate application means that different rules may apply.  For example, some systems accept DIOM studies with alpha characters in the study UID, others will allow series or images to be stored in two different studies with the same SOP instance UID.  These variations in interpretation or enforcement of DICOM standards lead to problems when storing to the VNA.  There are times when a DICOM store transaction is successful, but the study is not accepted into the VNA.  There can also be a delay between the time a study is received by VNA and when it is actually stored to disk as many VNA’s have some sort of inbound cache or holding pen while processing data.  This discrepancy can create a problem where PACS believes a study to be stored but it is not actually stored, which is of course heresy for an archive.

It turns out that there is an old-school, little used solution for this very problem.  It is the arcane process called DICOM Storage Commit, and I highly recommend that every VNA owner enable this process for all sources that support it.  During the DICOM store transaction each image should be acknowledged as received and in theory any images that are not acknowledged as received would be resent by the PACS or other source system.   In practice there are a number of places where this does not occur.  The storage commit is a separate transaction that occurs after the DICOM Store.  The sending system will generate a new transaction in which it lists every image that was sent.  The response includes a list of every image with a success or failure.  If any image is listed as a failure then the source system can resend the image or the entire study, most tend to resend the entire study.

One problem with using storage commit is that many vendors have ignored this transaction for quite some time the result is that it is often less than optimally designed or configured.  Some systems have defaulted timeouts, and others batch up storage commit messages while others will not archive anything else until the commit is received.  Even with these limitations it is worth it.  The fundamental problem is that when a source believes that a study has been archived it is then available to be deleted or flushed from the cache.  If for some reason it did not successfully archive there is then there will be data loss.

Which comes first the PACS or the VNA?

 

This is a question that several years ago was philosophical and interesting but not terribly relevant.  Today as the landscape is changing the answer for your organization is vital to your overall success.  Like all good questions the answer is….. It Depends!

First what do we mean by PACS  or VNA First?  It simply means in your environment after images are acquired, are they stored to a PACS, presumably for interpretation and then archived to the VNA for storage, or are they sent to the VNA first and then routed elsewhere.  As one might expect there are pros and cons to each strategy and the determination really relates to how each is used.  I hesitate to use the term workflow because it, like “train the trainer” is one of the overused terms in the industry.

A PACS first orientation is the more classical approach to a VNA.  The study is acquired by modalities, typically reviewed by a technologist at a PACS workstation in which demographics are verified.  There may be some study manipulation such as window leveling, deleting of images and general image QA.  Often times additional information is added in the form of scanned documents which can be anything from the insurance card, to technologist notes and worksheets.  Finally, the exam is marked as ready to be viewed by the physician or radiologist.  When the study is interpreted, and a report created the study is marked complete or reported.  At some point in this flow the study is put into the archive queue and it is sent on to the VNA.  In this flow the VNA is acting primarily as the archive, and in some cases is called the deep archive or cold archive.  If the study is ever needed again as a prior and it is not in local storage PACS will retrieve it as needed.

A VNA first orientation is a different flow.  After the images are acquired they are sent to a technologist imaging system.  At this step the image manipulation occurs, this can be done in a department-based system like a PACS, it could be on a dedicated QC workstation, web system or components in the VNA itself.  Then the study is sent to the VNA, which likely maintains a local cache, but could be a cloud-based system.  After the study is in the VNA it is ready to be read.  The study is then sent from the VNA to the reading station where the interpretation takes place.

One of the keys in the distinction between the two is how quickly the study is available in the VNA.  In a VNA first scenario the study is almost immediately available on the VNA.  This becomes important when there are multiple consumers of the image, such as an EMR integration that is serviced by the VNA not PACS.  A PACS first orientation the study is interpreted prior to archival which means the likelihood of the images changing is very low.  I would opine that the images should NOT change once they have been reported.  If they do, then an addendum is warranted.  This data flow also maintains a linear nature and is relatively simple.  There is value in simplicity and that should not be understated.   The downside of this is the time required for the image to get to the VNA and the relative inflexibility of the system.  If there is an issue with PACS or the study is “missed” it will not be available to downstream systems.

In the VNA first method there are multiple systems at play any of which could be down.  It is also a more complex workflow involving several steps.  The benefit however is near immediate access in downstream systems to the images as well as significant flexibility to integrate multiple data flows and systems.  A VNA first architecture allows for a reduced PACS footprint that can lower overall maintenance costs (often 15-20% annually of the PACS license cost).   It also supports the integration of multiple viewing systems for referring physicians, specialist viewers and outside contracted radiology groups.  I would also argue that it better supports the transition to PACS as a service or “deconstructed PACS” or PACS 3.0 whichever is your favorite term, as well as a multi facility multi PACS environment in which a single study needs to “live” in many places at once.

So back to the question, which is better?  It depends on what the current imaging needs are, in terms of access to images, how many systems are integrated and   what the future vision is for the system.  For simple systems stick with PACS first (your PACS vendor will love it!) if the intent is to implement more exotic workflows or there are multiple downstream systems it would be worth investigating a VNA first data flow.

 

Kyle Henson

Please let me know what topics you would like to discuss

Kyle@kylehenson.org

That’s not a pencil, it’s a MEDICAL DEVICE!

Three years ago, I was visiting my primary care physician for an annual exam.  My Dr, not fresh out of medical school and had been my family physician for a number of years.  Dr. L did not like computers.  He was writing on my cart in pencil (yes a for real paper chart!).  When I noticed that the pencil was worn down so far that it would only write from one angle and even so was more like a crayon.  I looked at him and said, “you might want to sharpen that pencil.”  He replied, “I can’t, this is a medical device.”  Being the highly technical Imaging person that I am I said, “forgive me Dr, but that is not a medical device, it is just a pencil.”  Slightly exasperated he took off his glasses and looked at me, replying “This is your chart, a medical record.  Obviously, you can see I am making notes and documenting your diagnosis.  You can’t do that with just any writing device, that would be illegal!  I might be audited, you can only make a diagnosis with a medical device!”  Not taking the hint I said, “well at least sharpen it, you can barely write with that.”  Now clearly ticked off Dr. L replied, “were you not listening?!  This pencil is a medical device, if I were to sharpen it, I would have to have a licensed carpenter come in, charging me $400 an hour to sharpen it!  You can’t go messing with a medial device unless you have FDA clearance!”

Sooooooo, maybe there is a hint of sarcasm in my story, but let’s talk about what a medical device is and what the FDA really says.  I was at one time a vendor, and while I was I said many of the same things about my system.  Medical device… can’t patch… blah blah, FDA certification…. I truly believed everything I said.  I had been told that by my company, and I had never read any FDA filings (at the time) so I was retelling what was for me the truth.  Like my former self, many vendors have never read nor do they understand FDA process..

 

The FDA defines a Medical Device as “”…an instrument, apparatus, implement, machine, contrivance, implant, in vitro reagent, or other similar or related article, including a component part, or accessory which is: recognized in the official National Formulary, or the United States Pharmacopoeia, or any supplement to them, intended for use in the diagnosis of disease or other conditions, or in the cure, mitigation, treatment, or prevention of disease, in man or other animals, or intended to affect the structure or any function of the body of man or other animals, and which does not achieve any of its primary intended purposes through chemical action within or on the body of man or other animals and which is not dependent upon being metabolized for the achievement of any of its primary intended purposes.” (Syring, 2018)

 

From that definition we could assume that yes, a pencil is indeed a medical device, or could we?  Did the pencil do anything?  Did it assist in the diagnosis?  Not really, it assisted in recording it.  Similarly, we have to look at the distinction between things that are used in the diagnosis vs what is supporting.  Is a CT or Ultrasound a medical device?  Yes, no question.  What about PACS?  The software is considered a medical device, but the hardware it is running on likely is not.  Let’s examine a real 510(k) letter for a PACS.  By the way if you want to look up the certification for your vendor, which I strongly encourage you can do so on the FDA website.

https://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfpmn/pmn.cfm

Back to Vendor X……  “PACS X is medical image and information management software that is intended to receive, transmit, store, archive, retrieve, manage, display, print and process digital medical images, digital medical video and associated patient and medical information.  PACS X includes a suite of standalone, web-enabled software components, and is intended for installation and use with off-the-shelf hardware that meets or exceeds minimum specifications.” (emphasis added)

 

What this means is that the software is a medical device, and when the SOFTWARE is patched it must be tested in accordance with General Principles of Software Validation linked here (Food and Drug Administration (FDA), 2001).  The hardware that it runs on however, does not.  You can run PACS X on any hardware that meets or exceeds specs and it has no impact on the FDA certification whatsoever!  A vendor is well within their rights to provide an approved hardware list, but this is a support issue and not a FDA issue.  This distinction is very important!

 

Because the computer and operating system that run PACS software are not part of the 510(k) certification there is no requirement for the FDA to review security patches.

“Medical device manufacturers can always update a medical device for cybersecurity. In fact, the FDA does not typically need to review changes made to medical devices solely to strengthen cybersecurity.” (Food and Drug Administration, 2018)

There is a one page fact sheet that is very clearly written and I also encourage you to read here.

In summary, your PACS software IS a medical device, however what it RUNS on likely is not.   Especially given security concerns it behooves us all to read the FDA guidance and hold our vendors accountable to make sure that our devices are patched and up to date.  No one wants to report to the CEO or CIO that their system was responsible for a virus or ransomware attack on the enterprise.  Also surprising to me was that for all the secrecy and mystery surrounding medical devices and subsequent maintenance, the FDA website is surprisingly clear and easy to understand.

 

Thank you for reading, please post comments and questions !

Kyle Henson

 

 

References

Food and Drug Administration (FDA). (2001, 02 25). Information for Healthcare Organizations about FDA’s “Guidance for Industry: Cybersecurity for Networked Medical Devices Containing Off-The-Shelf (OTS) Software”. Retrieved from Food and Drug Administration Website: https://www.fda.gov/medicaldevices/deviceregulationandguidance/guidancedocuments/ucm070634.htm

Food and Drug Administration. (2018, 02 02). Information for Healthcare Organizations about FDA’s “Guidance for Industry: Cybersecurity for Networked Medical Devices Containing Off-The-Shelf (OTS) Software”. Retrieved from Food and Drug Administration: https://www.fda.gov/medicaldevices/deviceregulationandguidance/guidancedocuments/ucm070634.htm

Food and Drug Administration. (2018, 02 07). THE FDA’S ROLE IN MEDICAL DEVICE CYBERSECURITY. Retrieved from Food and Drug Administration: https://www.fda.gov/downloads/MedicalDevices/DigitalHealth/UCM544684.pdf

Syring, G. (2018, 02 25). Overview: FDA Regulation of Medical Devices. Retrieved from Quality and Regulatory Assoicats: http://www.qrasupport.com/FDA_MED_DEVICE.html

 

 

 

The DICOM is in the Details! Part 2 the Query Retrieve

 

Given the apparent interest in some of the details about DICOM store transactions, thank you to all who read it!  I thought I would add in a brief description of Query / Retrieve and then next week I will write about my favorite, Storage Commit.

A DICOM Query Retrieve transaction is a fairly simple transaction. First there is a query, and then a retrieve, luckily the standards team didn’t go crazy with the names. The first part is of course the query, which is a C-FIND transaction. In a C-FIND we again have a service class user (SCU) and a service class provider (SCP). The provider is going to be the “server” and the user the “client” or the one making the request. The query can be for a study or for a patient. However, it does not have to be only one. The query could be for “all” patients, or All studies done on a certain date, or if you get a wild hair, all dexa studies completed on Friday the 13th that have a patient who’s first name begins with the letter Q.

No matter what the C-FIND attributes are (specifics of the query) the user will send the query to the SCP (provider) and the provider will then issue a C-FIND response. The response is the list of studies that meet the criteria.  Different systems have built in mechanisms to deal with large C-FIND requests, some will reject the request if it is too broad, others will limit the number of responses to and arbitrary number such as 300, while still others don’t mind at all and simply send back a very long list of matches.

The client or SCU now has a list of studies and may decide to retrieve the studies. The command to retrieve a study is typically not “send me x study” it is often a C-MOVE command. Which roughly translates to “send X study over there” with the there usually being the requester. This is mostly semantical, but interesting to me. The C-MOVE command consists of what study is to be sent and where it is to be sent. The where is an Application Entity or AE title. Once the C-MOVE provider has this information, it then begins a DICOM Store transaction with the AE title requested.  For info on the DICOM Store,

see The DICOM is in the Details!

(Yes, shameless plug for clicks)

One interesting note here, in the C-MOVE command the only destination is the AE title, it does not include the IP address or port! This gets complex because almost every PACS and modality has a standard AE title that the vendor uses for EVERY SINGLE INSTALLATION, I won’t call out a single vendor, because they all do it. This was not a problem back in the day because relatively few systems queried each other, and they were often different vendors. Now however, when you are building an enterprise system like a VNA it is not uncommon at all to have many PACS or CPACS from the same vendor. Which brings AE uniqueness into play.

Some PACS will have the ability to use multiple AE titles so you can simply add a new AE for your VNA to send back to, and not change the modalities. Other PACS will only support one AE title and you may have to reconfigure all modalities sending to it. Last tangential point on Query / Retrieve is that this process of C-FIND and C-MOVE is pretty much what all data migration companies do. They simply do a lot of transactions!

Kyle Henson

Please let me know what topics you would like to discuss

Kyle@kylehenson.org

When a picture ISN’T worth a thousand words, where do reports fit into VNA’s and Enterprise Imaging?

 

In traditional imaging systems like Radiology and Cardiology PACS the report is always with the images. In Radiology, the dictation system sends a copy of the report to PACS via HL7 which is ok since it is text. In cardiology it is either a textual report, or the cardiology system creates the report and therefore has a copy. As we get outside of the walls of those two systems, where does the report really live?

For those that don’t read to the end … the answer is DICOM SR  in your VNA but please keep reading!

In an environment where all users are logged into the EMR and launching images from there, it is not an issue as the EMR is now the system of record for the reports and will have a copy. Now, IMAGINE A WORLD (queue deep commercial voice) where images are sent for reading to various physician groups who are not logged into the EMR.  Reading the newest image is not an issue, but what about priors? In some teleradiology workflows prior reports are faxed, others copy and paste prior reports from the EMR, and still others simply read what is in front of them.

I submit that there is a better way. As we move forward with outsourcing reads, and facilities are divested and acquired regularly it makes no sense whatsoever to not keep reports with the images. The two are intrinsically linked and are important for different reasons as part of the patient record. Luckily there are several mechanisms to resolve this. Surprisingly I don’t see them often implemented.

Let’s start with the low hanging fruit, cardiology. Since most CPACS have reporting modules within the system the report is already with the images before the images are archived and / or sent elsewhere. While I am all for FHIR and emerging solutions I prefer to stick with what I can implement today, now, and yes there are options. The simplest is to do an HL7 export to the EMR. This will provide the text but no images. Often times CPACS will generate a PDF report but that ends up being imported as a separate document into the EMR and not linked. There are actually 3 options to export a content rich report besides emailing the pdf.

The first is to utilize HL7 and the encapsulated document (ED) standard. The standard does exist, and it can be done but I have not seen it nor talked to anyone who has tried. The second is to store the PDF document in the XDS, I am all about standards and a big believer in XDS. The problem is that first you have to HAVE an XDS repository which many don’t, and secondly you need a system to act as the XDS source, which many (most) imaging systems don’t do. There is a very easy answer to this problem and one that has been around for a very long time it just isn’t used.

The easy answer is to DICOM Encapsulate the PDF report and store it with the images as another series. Many CPACS do this natively, it is as simple as clicking a button in the configuration to “archive report with images”.   Why this is not done more often is a mystery to me. This is a very good option for CPACS which commonly creates pdfs as the report product but for other systems that rely more on plain text is the PDF the way to go?

There are several options for textual reports as well. HL7 interfaces between systems is an option but HL7 tends to be more of an all or nothing proposition. Again, XDS offers several opportunities, we stored the text reports as CDA objects in XDS, however this shares some of the previously stated limitations with XDS, namely the lack of adoption so far. Still, there is an old school solution to this problem. The DICOM Structured Report (SR).  By using the DICOM SR one can store the report with the images, any time the images are viewed or sent to another location the report goes with it with no additional steps.

I did this with my VNA from the beginning and it has been a huge success as my EMR Viewer can process the SR and therefore when looking at priors for history the report is available for review without the hospitalist having to go back and forth to the EMR to view the interpretation that goes with the images. Similarly, any time images are requested by another facility or need to be shared for patient care the report is always with the images, either as a DICOM SR or an encapsulated PDF. See that was worth reading to the end wasn’t it?

Kyle Henson

Please let me know what topics you would like to discuss

Kyle@kylehenson.org

The DICOM is in the Details! but how does it work?

Most of us use DICOM every day, we smell it, we live it and we talk about it. However, often the deep dark secured is that we don’t really know how it works. What is a SOP? What is a Transfer syntax? And why do the engineers keep talking about Endians?

To begin with lets quickly review how a DICOM Store occurs, the sending system initiates a transaction. The sending system is the USER of DICOM Store (Service Class User or SCU) and the receiver is the Provider of DICOM Store or the Service Class provider (SCP). The user says I have this study that I want to store. The provider (receiver) says great, here I am. Then the user says I want to send a Breast Tomosynthesis Image.

*nerd alert- The type of image to be sent is defined by the SOP Class, the SOP stands for Service-Object Pair which is the Information Object Definition (image type) and DICOM Service Elements (DICOM Wrapper).   The SOP for Breas Tomo is 1.2.840.10008.5.1.4.1.1.13.1.3, which is in a supplement.

https://www.dicomlibrary.com/dicom/sop/

At this time the provider will reply back with yes, no problem or no, I don’t know that that is. If the answer is yes and the receiver (SCP) supports that SOP (see how you are starting to get the lingo!) it will also send back the list of languages it speaks. We are all pretty familiar by now with the 3 types of compression, uncompressed commonly called DICOM, lossless compressed which is compressed but still ok for reading and lossy compressed in which image data is lost but is much smaller. Each of these along with several others are called in DICOM Speak a transfer syntax.

Once the sender and receiver have agreed on what will be stored, the receiver sends back a list of languages it speaks, or transfer syntaxes. The sender or SCU will then select one of these to send the image. Thus, it is the sender the decides whether or not the image is sent compressed or not. Implicit VR Endian is the default DICOM transfer syntax and therefore supported by ALL vendors.  Because of this, many vendors take the easy road and simply accept the default. This is … OK… within a LAN but when the data is stored or transferred over a WAN compression becomes very important.

https://www.dicomlibrary.com/dicom/transfer-syntax/

Now that SCU and SCP have agreed on what is to be sent and how it will be sent the data transmission goes. The transmission can be at the instance level which refers to individual images or at the study level in which many images are sent on the same association. Once the association is complete the sender may initiate a Storage Commit, which I highly recommend when sending to VNA across a WAN.

Briefly in a storage commit message the sender reaches back out to the provider and sends a list of all individual images that were sent. The Provider then responds back either positively that ALL images were received or negatively in which something wasn’t. In the case of negative the entire study is considered a failure and will be resent, which takes up a lot of your bandwidth.

Please like, share and comment. I would love to know what topics are of interest to the imaging people out there!

Kyle Henson

Please let me know what topics you would like to discuss

Kyle@kylehenson.org