PARCA gets a facelift.

Certification can provide better job
opportunities and personal growth

Remember PACS 2005? We had mostly CRT’s instead of flat panel displays, they needed a dedicated, very expensive medical video board, we used floppies to exchange information, 100 MBps was a fast network connection, which by the way was typically on a dedicated network as VLANS’s had not yet been deployed. Storage was so expensive that we used MOD or even DVD (yuck) jukeboxes for mid-term and long-term archiving of images. PACS systems did not talk to each other and we had yet to experience the many pains of migrating all those images if we were going to switch vendors. We did not know about virtualization, zero footprint viewers and VNA’s, and a cloud was still just a white fluffy thing in the sky instead of a way to outsource your data and image storage.

Looking back at those days, which were also reflected in the requirements for a PACS administrator to become certified, you can see that a lot of things have changed from a technical perspective. If you had not learned and advanced your knowledge as an imaging and informatics professional during those years, you would be hopelessly obsolete now. That is why the PACS Administrators Registry and Certification Association (PARCA) recently updated its certifications. The new requirements are posted on the PARCA website and the corresponding exams will be updated over the summer to reflect these certifications. Candidates are actually encouraged to renew their certifications to become “2014” certified.

Taking the exam again (or for the first time for that matter) is a good thing, as you can show that you are serious about staying up-to-date as an image an informatics professional. And remember, it is not about the piece of paper, it is like a race, it is all about the journey. As soon as you are at the start line of that race, you have accomplished what you are looking for, the race and in this case the exam is just a formality and confirmation of your up-to-date skills.

Top ten reasons to use IHE.

It is hard to underestimate the impact and importance of the IHE (Integrating the Healthcare Enterprise). However, there are a lot of unknowns and an under appreciation of the effect IHE has, especially on potential workflow improvements and increases in efficiency. Therefore, I’ve compiled this (limited) list of benefits. There are many more benefits than listed here, but these are the most important. This is an abstract of an IHE presentation at HIMSSME in April in Jeddah, Saudi Arabia. You can also watch a video of the presentation here.

The Interoperability Showcase was
very well attended

     1.   To increase the chance of plug and play: In general, the standards that form the foundation for the IHE have too many options, the reason being that most of them are developed as part of a semi-democratic process, which makes sure that all stakeholders (read vendors) can be facilitated, i.e. none of them are greatly benefitted and none of them severely handicapped by the choices that are made during the standardization process. However, in practice, most people go overboard with creating these standards such as DICOM and HL7. There is typically no thought given to determining what is the minimum necessary, but rather, what “might be nice” to have. The effect is that the ADT family of messages has grown to include 60 messages, each of 20 segments, with an average of 30 fields, resulting in 600 data elements. A similar feature creep has taken place with the DICOM standard, where a work list at a modality can contain up to 120 attributes according to the standard. IHE reduces these options greatly, for example, the IHE Scheduled Workflow Profile (SWF) definition limits the 600 HL7 attributes to 39 as part of 4 messages. The DICOM Worklist is also limited i.e. 42 instead of 120 attributes are specified as part of the SWF profile.

2.       To reduce on-site testing: The connectathons, where hundreds of vendor representatives get together for a week and test literally thousands of use cases is definitely reducing the integration time for these systems on-site. My guess is that the productivity for testing a system at a connectathon is at least twice, if not higher, than having to figure out the problem at a customer site. The other advantage is that these test environments provide a level playing field, i.e. small vendors have an equal opportunity to test their systems with one of the major players as the big guys in this field. Another major by-product is the widespread availability of test tools, test transactions and test images in the public domain that are created as part of this effort and are available to test against.

3.       To provide a simple selection mechanism: I always like to compare the IHE profiles with the fast food “value meal” choices, i.e. instead of having to think about the exact configuration of your hamburger and what type of sides or drink size, you can just pick a meal number. Choosing IHE profiles is similar, instead of having to specify what list of DICOM or HL7 transactions, and what attributes should be supported, one can just specify “profile x.” The Scheduled Workflow (SWF) profile for the modality actor is a good example. If a modality supports SWF, you can count on it supporting the Modality Worklist, Storage, Modality Performed Procedure Step and Storage Commitment functionality. There is only one (or at most a couple) of boxes to check off when considering purchasing a device instead of having to include pages of interface specification requirements.

4.       To eliminate gaps and overlaps in functionality: In addition to the fact that no two RIS or PACS systems are equal, vendors also like to come up with very creative non-descriptive names for their system components. It is confusing for their customers who are wondering what exactly a workflow manager, connectivity manager, intelligent router, gateway. or broker does, and more importantly what it does NOT do. This also adds to the current confusion on what is exactly a VNA does. If one is very specific about which profiles are supported in what function, there is no confusion about, for example, whether or not image deletions and corrections are automatically communicated between a PACS and VNA using the IOCM (Information Object Change Management) profile. Similarly, there is no confusion on whether one can connect a univiewer to that same VNA using standard DICOM RESTful services for web access, or that information that is archived is registered to a regional repository using XDS. I understand the urge of vendors to use nice sounding names, but in my opinion it confuses users more than it actually helps.

5.       To address workflow, including exceptions: Integration profiles are defined based on real-life use cases. These use cases address real-life problems such as the performance of an exam, creation of a report, exchange of a discharge document, retrieval of a set of documents by a physician, etc. To support these workflows, the IHE committee picks the minimum necessary services and tools to do this in the most efficient manner.  As a matter of fact, I would argue that if every institution would implement these workflows and fully utilize their features, there would be a major improvement in efficiency and productivity. Knowing that real life situations do not always follow the same rules, there are also several profiles defined to address exceptions and corrections to reconcile patient information later on, or deal with unscheduled cases.

6.       To address display requirements: Communications standards such as DICOM and HL7 typically do not focus on how information is presented, but rather on the reliable exchange of the information. This causes major issues with regard to performance and functionality. For example, the capability of receiving digital mammography images at a workstation is useless unless the same workstation is able to display these in exactly the order needed for interpretation. In the case of digital mammography, the same view is presented with one mirrored and displayed against each other with the chest wand. In the case of nuclear cardiology the images are also displayed in a certain order and one should be being able to change the different windows in a specific way. Not only the presentation of the images is critical, the persistency and consistency in greyscale and color rendering is even more important. Modality specific profiles are created to address this issue.

7.       To re-enforce the standard: Some parts of the standard were so poorly implemented that a profile definition that specifically calls out these requirements is very helpful. This is the case with the  Portable Data for Imaging (PDI) profile that addresses the exchange of images on CD’s and DVD’s. This profile reiterates the requirements as stated in the DICOM standard about making sure that there are DICOM encoded images being exchanged, not some proprietary version of the images, which can only be viewed by the embedded viewer, and that there is also a DICOM DIR included providing a directory of the images stored on the media. A related profile is the IRC profile that basically takes care of reconciling the image information that is being imported in the PACS with a new or existing patient, who can be uniquely identified without jeopardizing the information integrity of the PACS.

8.       To provide a shared infrastructure platform: Many applications have similar needs with regard to patient information management: security, including access controls and audit trails, personnel management, such as the availability of provider names, unique identifiers, and many more services that can be shared, and more importantly, be implemented in a single standardized manner. For example, there is no reason that an audit trail for a physician accessing a diagnostic image should be implemented, recorded and accessed by a system administrator differently than an audit trail for someone accessing a lab result or any electronic medical record. Defining a unified set of profiles to deal with this in the form of the ITI (IT Infrastructure) domain is a great asset and will lead to efficiency because of its re-usability and economy of scale.

9.       To provide enterprise and regional exchange capabilities: Even though the information exchange mechanisms to the outside, using cross enterprise document sharing profiles, is considered part of the ITI (although for imaging it is included in the radiology domain), it is still important enough to be mentioned separately on its own merits. Registration and access of medical information is critical for the sake of patient safety, and to reduce costs due to duplicate tests and procedures. In addition, we really don’t know yet what the impact will be of having all that information available for outcome measurements and decision support, but I am sure we will find a way to use this “big data” in a way to benefit patients and improve the overall efficiency of healthcare delivery.

10.   To exchange information about images: Using DICOM, we can create a very simple object that refers to one or more other objects such as images, and tell something about these objects in a standard manner. It is encoded as a DICOM Structured Report (SR). A good application of this feature is to point back to “key images” so that a physician knows which images to review. This could be a major help during surgery, for example, to be able to pull up just a few images out of a set of potentially thousands of axial CT slices. Another application would be to exchange information between an archive and any other location where there might be a copy of its images, to determine if the image needs to be deleted, or replaced or changed in any way for synchronization purposes.

This list of the top ten advantages or reasons to use IHE could easily be larger but these are probably the most significant. Again, if you are more of a visual or auditory learner, I suggest you check out the more complete version of this write-up here. Details about the individual profiles can also be found in my blog postings, you can just search for the appropriate keywords, or at OTpedia. Enjoy!

From drinking a Corona to potentially catching the Corona virus.

Nothing tasting better than
a Corona
(except a Heineken of course)

It had been only one week since eating out in Mexico City at night and having a Corona or two, that I landed in Jeddah, Saudi Arabia during the Corona virus scare. This virus has nothing to do with the famous Mexican beer but rather is an abbreviation of Coronaviridae, the name of a family of RNA viruses. It is also known as the MERS or Middle East Respiratory Syndrome. 

Apparently when I landed in the region, a visitor had just died and the death toll was up to almost 70 people, while there are more than 200 cases reported. Unfortunately, the whole affair overshadowed the second HIMSSME conference in this city as healthcare public officials were more worried about the public unrest and concerns than paying attention to the conference. 

Interestingly enough, the advent of health care IT implementations, and especially the reporting, surveillance, and analytics of healthcare information, as shown at the IHE showcase during the conference, is exactly what would assist in the management of such outbreaks.

Talking about the IHE showcase, this year was a major improvement over last year’s first exhibit. There were two use cases shown, each with eight stations, but despite the fact that there were “only” two, it would take at least a whole hour to go through each one of them to appreciate all of the details of how these systems could communicate.

Busy booth of MOH (ministry of Health)

The good news of this show was that there was a lot of “kicking the tires,” as there are several major tenders out to be awarded in the Kingdom of Saudi Arabia, which is making a major investment in healthcare infrastructure. In contrast to the United States, where the implementation of public Health Information Exchanges (HIE’s), which will serve as the hubs to register and even be repositories for regional health care systems is still progressing very slowly, the feeling is that in Saudi Arabia there will be a very fast-paced and massive implementation in the very near term in this region. In addition to the infrastructure being put in place, the feeder hospitals and clinics will need upgrades to their PACS systems to install Vendor Neutral Archives (VNA’s) that can communicate with the infrastructure using the applicable IHE profiles (PIX/PDX, XDS).  Key to the success of this initiative is that all the Electronic Health Records need to be ready to exchange information using standard communication protocols and especially the new templates in the form of CDA (Clinical Document Architecture) so that instead of shuffling documents back and forth the data can be imported and exported electronically.

Despite the virus outbreak, the HIMSSME was very well attended, and the smaller scale made it easy to get around and spend a lot of time with the vendors that were present. Instead of relying on local dealers, many vendors are now opening their own offices, either forced by the fact that the service and support has been generally very poor by their local representatives, or because of conditions written in the outstanding tenders. I would argue that if a dealer does not perform, it is in many cases due to insufficient training and support by the parent company, but there is no question that a wholly owned operation is often managed more effectively. A potential issue is the ever-increasing requirement by the Saudi government to hire a certain percentage of Saudi nationals, which as of now is 25 percent. This may be a temporary issue as there currently is a lack of skills and training among these professionals, but with the ever increasing stream of young graduates coming back to their country after being sent abroad to study in first class universities, many of them in the USA, there should be a sufficient labor pool available, if not now, then very soon.

The virus outbreak was indeed an annoyance. The fact that many of the children were kept home from school did indirectly impact me, as many of the non-essential healthcare workers such as IT personnel, which I would have liked to visit with in Jeddah, stayed home, which was kind of a bummer. Anyway, a good reason to come back to Saudi Arabia next time, may not be Jeddah but Mecca, which is one hour away. Consequently, the plane was 90 percent filled with pilgrims, all dressed in their white loin cloths and shawls, which definitely made me feel out of place, but they were all very friendly and accommodating. This is what makes travel interesting and never boring.

IOCM, critical to synchronize a VNA with your PACS.

One of the most common complaints and challenges is how to keep the Vendor Neutral Archive (VNA) synchronized with a PACS system, particularly, with making sure that deletions and modifications made within the PACS are executed within the VNA as well. As a matter of fact, one of my PACS students recently complained and told me that her workload almost doubled because of the recent VNA implementation as she has to make all changes, updates and deletions twice, once at the main PACS and second at the VNA. One could argue that this is not a “level 5” VNA as defined here (add link), but, rather a partial and limited VNA implementation without any automated coordination between the PACS and VNA. Even if it were implemented, in what is commonly done in a proprietary manner, a standard implementation would be much better.

Implementing the IOCM, or Imaging Object Change Management profile as defined by IHE by both the VNA and PACS systems should largely address the synchronization issue and provide a standards based solution. The IOCM profile does not specifically name a VNA or PACS, but, rather addresses the need to synchronize whenever images need to be shared between a local and other systems i.e. anytime multiple copies of the same image or other DICOM objects are available. This can be the case when copies are stored on a VNA, an EMR, or any enterprise or regional repository. IOCM addresses the following use cases, i.e. when a user needs to:

·         Correct and/or update demographic information for images and other DICOM objects

·         Split or combine studies, which is mostly due to incorrect Modality Worklist item selection

·         Remove “bad” images, for example, when they are incorrectly labeled (such as an incorrect Left/Right indicator)

·         Permanently delete old imaging instances or entire studies as may be required by institutional record retention policies (typically after seven years).

The combination of needing to distribute copies of images and needing to modify them leads to copies, which are inconsistent, and in turn creates the potential for confusion, error or loss of data.

The IOCM integration profile supports the following three change management use cases:

·         Data retention expiration

·         Correction or rejection of instances for quality or patient safety reasons

·         Correction of modality work list selection

If you are interested how this works, it is important to realize how IHE profiles are defined. IHE profiles include so-called actors, which have a well-defined role and function, and the transactions between these actors. Examples of existing actors are the image manager (database) and image archive, which both provide the core of any PACS or VNA. The IOCM profile defines a new actor: Change Requester. This actor can be grouped with existing actors that manage these objects and that have the ability to apply changes to existing imaging objects, in order to support IOCM. The Change Requester would, for example, be resident at a PACS system, which can then communicate with a VNA, to communicate any updates and changes.

The information is exchanged using a DICOM Key Object Selection Document, aka a “rejection note.” This is a special case DICOM structured report (SR). SR’s are typically used when there is a need to communicate information about images such as which ones are Key Images, where and what type of measurements or CAD results are available, and other applications, hence it is a perfect template for these rejection notes as well.

In addition to the IOCM rejection note, there could also be transactions used that include any modified replacement images, and in case there was an issue with an incorrect patient selection, one could use the so-called Instance Availability Notification to communicate this information with the department scheduler.

In the case of my overworked PACS student, I only hope for her that her VNA vendor is taking notice of this new profile and starts implementing and/or upgrading its system. This assumes that the PACS vendors do this as well, otherwise the VNA does not have anyone to listen to, but I assume they will follow suit soon.

When eliminating film is not necessarily the best solution.

During my recent humanitarian trip to Nicaragua, sponsored by Rotary International, we built a library and feeding center. While there I also visited the local children’s hospital in the city of Chinandega. It was good to see the impact on patient care we had made on a previous trip by bringing in equipment, such as oximeters and other life-saving devices, to help care for these very tiny premature babies.

I typically also visit the radiology department to find out if I can learn anything. They just had received a nice refurbished CR system with an X-ray table, and with having the room newly painted, and air conditioning installed, it looked really nice.

Feeding 900 children, one at the time

However, I noticed on the table next to the CR computer an appointment book listing all of the patients that were imaged. It seems it is difficult to get people to let go of their old practices. Even though there was a mini-PACS and patient management module available, for them, there is nothing better than paper. The exams were identified as “exam1,” “exam2” etc. and the appointment book served as an index.

If patients are deemed to be in a critical condition, they travel by ambulance to the Nicaraguan capital, Managua. In the past, they would send the film with the patients. In this case, even though a film printer was provided with the system, it is unused. It seems they needed its power conditioner somewhere else, so the printer is not operational anymore. The primary image exchange from this system was intended to be paper using a small desktop printer, however, after the print cartridge ran out, this too is no longer used. While burning the image on a CD is an option, there is apparently no budget for supplies such as print cartridges and CDs.

So, the bottom line is that a year ago, before the CR system was installed, critical patients would go with the analogue film to the main hospital. Today, the analogue processor is gone, and there is no means for getting the digital images out of the PC to go with the patient. I resisted the urge to run to the local supply store and buy a stack of CD’s and/or a printer cartridge, however that would only have been good for as long as they lasted. The hospital has to learn how to implement digital technology in a sustainable manner.

This is only one example of the trial and error that takes place in aiding developing countries. That is why it is critical to travel and find out the local needs instead of throwing technology at these regions. That does not only apply to medical devices, but equally to any other areas as well. This year I visited a library that was built by another non-government organization next to a school we had started several years ago. The library was very well equipped, with books, a computer, big screen TV with a DVD, and even a copy machine. Too bad there was no electricity to use any of these new gadgets, nor has the education ministry provided anyone to staff the library.

I estimate that about 50 percent of all relief money is spent without doing the necessary homework and follow up and is thereby wasted. This is by no means meant to discourage participating or contributing to these causes, just make sure you do your homework and pick the right projects and organizations. We have been very fortunate to be able to sponsor the construction of several small clinics and classrooms in this area with a high success rate for sustainability. It takes work, visits and local follow up to make it a success.