Tales of a road warrior: don’t lose your passport.

As I was getting ready to check in for my evening flight to India leaving from Chicago O’Hare,

I noticed I was missing my little pouch with my travel documents, including my passport. I must have looked somewhat frantic as a gate assistant from American Airlines came over to me and told me to take it easy, move to the side and take everything out of my bags and pockets to search for it. Apparently this was not the first time she had seen such panicky searching and, I have seen it myself in other travelers, always thinking to myself that this will never happen to me, because I am so organized, but now it was my turn.

After taking everything out of my bags and going through it a couple of times I was increasingly getting a sick feeling in my stomach as it became clear - my black travel pouch was missing. I remember distinctly that I opened it in the taxi to double-check my fight departure time, therefore, I must have lost it between that event and arriving at the airport kiosk. The most logical explanation would be that I left it in the taxi from the hotel to the airport. Fortunately I had gotten a receipt, which had the cab company phone number, so I called the company. I explained to the dispatcher that I had left my passport in the taxi and he immediately blasted a page to all his drivers asking who had dropped a passenger off at the airport in the last 10 minutes to check their cabs. He promised to call me back immediately when he heard something. I waited 15 minutes without any sign and called him back. I explained that I was stuck, could not get anywhere without my passport and if he would please page his drivers again. I waited another 15 minutes without any sign and I called him back. At that time I was getting close to the boarding time of my international flight and getting pretty anxious. I told them I would give the driver an extra $100 if he would return it ASAP. Nothing happened.

At that time I had to make a plan B. Option one was for me to fly back home to Dallas and wait until it showed up. That meant giving up the trip to India, where I was to deliver a keynote speech and a one-day training class for a healthcare technology company. If the passport did not show up, it also meant cancellation of an international training course a week later as replacing my Dutch passport with US resident card and applicable visas for the countries I was going to visit was going to take at least a month if not longer. And by the way, our upcoming mini-vacation to Belize was potentially endangered as well, something I am sure my spouse would not have been too happy about.

Option two was hanging out close to the airport and potentially going one day later assuming it would magically show up. I chose the latter, walked up to the airline counter and they were able to hold the ticket, and cancel the outgoing leg for now. I walked over to the airport hotel which could offer me a room for a mere $375 plus tax.

After checking in, and unloading my luggage, I talked with my previous hotel just in case I had left it there. I remember I had my pouch with me in the bathroom in the lobby before picking up my luggage, which was in storage. They put me on hold, sent someone to check the men’s bathroom and came up empty handed. I left my cell number just in case. I also had to notify my contact person in India to not expect me at the agreed upon time and sent an email that I was stranded because I had “trouble with my travel documents.” I walked to the airport once more backtracking all my steps and trying to find anyone who might have seen the pouch, but everyone had left by that time. There was nothing better to do than to raid the minibar in my room for cognac and chocolate (another $30), and go to sleep.

I did not sleep very well, trying to reconstruct everything in my mind over and over again. I felt that if it had been left in the taxi, the cab driver most likely would find me to return it. There was no way for me to locate the specific taxi since I had paid cash. As a matter of fact, the first thing the taxi dispatcher asked me is if I had paid with a credit card, as it apparently shows the cab number which would have made it easy. I typically pay with credit card but in this case, I did not as I felt sorry for the guy and I know that he would have to pay 5 percent of the fare for credit card charges.

The good news was that this taxi driver seemed to be a non-typical Chicago cab driver. From my experiences over the past few days being in that city, the Chicago cab drivers are the world’s second worst, after Brazil, which I will explain in a second. A typical driver seems to need to talk continuously in a very loud voice on his cell using those earpieces in unidentified languages, which may have been either Swahili or some other African language. They will never leave their seats, but do charge for extra luggage that I have to put in the trunk by myself. Of course, the first thing I do is put on my seatbelt, as their driving is kind of reckless. Incidentally, the worst cabbies are the drivers in Sao Paulo, especially during soccer matches, which seem to be going on continuously. They have tablets mounted on their front dashboards allowing them to watch games while driving. Talk about being distracted by talking on a phone; imagine being distracted looking at a TV screen while driving.

So, the first thing I noticed about my taxi driver that night was that surprisingly he was not on the phone, so I could have a decent conversation. He told me pretty much his life story, how he was originally from Palestine and was able to get out at a relatively young age. He came to the USA through Amsterdam and had subsequently gotten citizenship, settled, and had a family. He also told me about the recent unfair competition from Uber, which provides rides without needing to comply with any of the regulations he and his 10,000 or so colleagues have to deal with such as regular drug tests, car inspections, driver tests and many other rules. His base cost to make any money is about $150/day and to make a decent living, he needs to work 12 hours/day and 7 days/week. Having heard all of this, I paid him cash, but was now faced with the fact that I had to locate him among 6,000 + taxis in this city as I did not have any record of him.

After little sleep, I went back to my mission to locate my passport at eight o’clock the next morning. I called the taxi company again to tell my story and ask the dispatcher to send a message to his drivers again as they might have found it by daytime. He asked me the color of the cab, upon which I said that I thought it was yellow. Ah, he said, that is not us, we are white/blue. The receipt I had in my hands was clearly from his company, but he explained that drivers swap receipts all the time and as his company does not provide free receipts to their drivers, it was almost certainly from another company. I looked on-line for taxi companies and started calling them. When I made the second call, the nice lady on the line told me that she just talked with me, as apparently taxi companies outsource their “lost and found” so she gave me the list of the companies they cover which were six. After that, I thought it might be better to go back to the airport and do more checking there.

The gate agent was nice, she checked her area and nobody had found a passport. She told me to check with the porters outside, who had not found anything either. Then she sent me to the local “lost and found,” close to the lost luggage desk. An AA agent was accompanying me to the innards of the airport, which was helpful as the lady in charge had a very difficult-to-understand east European accent (probably Russian). After discussing at length among themselves the case of the agent’s missing walking shoes, which by the way the Russian lady had not found, we finally got to the topic of my lost passport and indeed she had not gotten anything in this morning. After leaving my cell number at yet another location, I decided to try to locate the cab company again.

I situated myself inside the arrival hall where I could see the taxi line and tried to look for cars that were yellow and of the same type of the car that I remember I had used the night before. After 15 minutes or so I had become quite an expert on the different taxi companies, finding out that most companies have similar car types and that there are many more companies than I had found on-line. So, I was diligently writing down the numbers of companies that matched the car type and color as I recalled from the night before.

Then I got a call on my cell from the hotel that I stayed in prior to my loss. They had gotten a call from the driver. I asked the front desk to call him back and yes, I got to talk with him. He had found my pouch on the floor in the back of his car as he was cleaning it up for his morning runs and also found my hotel information in there. I immediately took down his number and gave him mine. My prayers were answered… I asked him to drive back to the airport and deliver it to me in the lobby.

I did not mention that Johanna, my spouse, has a good friend Diana, who is very intuitive and has the capability to see what others don’t easily see. In any case, she had texted her at night to ask for any clues and she told me that she clearly could visualize a bathroom, and something like my pocket pouch and dropping it. Based on that information, I had called the hotel, which was able to make the connection when the taxi driver called them.

So, after anxiously waiting an hour in the hotel lobby he showed up in his taxi, which by the way was not yellow but white and blue (amazing how few details you remember from the past, especially when it is dark). I gave him his cab fare and an extra $100. I took several deep breaths, called the airline which was able to reschedule the departure to that evening for a “small” fee difference of over one thousand dollars, at which point I really did not care as long as I could fulfill my commitment to my client. I left that evening, traveled for about 24 hours, arrived at the final location to check in to the hotel, get a half hour of sleep, took a shower and showed up to work. They had postponed my talk and I was just in time to deliver it 10 minutes later and do my training a day later as well. At one point in time my contact person asked what really happened and I told him some of the details, fortunately they were able to reschedule everything without much trouble.

So, what are my lessons learned from this incident, as I believe that everything happens for a reason:

• There are a lot of good and reliable people in this world, and fortunately of all the cab drivers I meet, I happened to meet one of the good ones on that trip to the airport.
• Running around like crazy is not always productive, this was a clear signal for me to slow down. Unfortunately, this was kind of a stressful situation but not having my passport was most likely the only way that the universe was able to slow me down.
• Always be prepared with a plan B in case something happens when traveling, something I learned a long time ago.
• Don’t get too stressed out or upset as you are not in control, especially when it relates to travel.
•   Look at events in a positive manner, it could have been much worse. I was able to fulfill my commitment to the customer. To reward myself, I treated myself with an upgrade using 15,000 miles to fly business class on the leg coming back from London to Dallas.
• Always pad trips, for example, when flying internationally build in an extra day to spare in your schedule.
• Travel with awareness, take down taxi numbers, and pay with credit card when possible.
• Be prepared to lose anything, leave business cards in them, make copies of important documents and/or take a picture with your phone.

So, while I am recording my experiences on this flight back home, I am getting an extra glass of wine and feel blessed to be able to do what I love and like, traveling and teaching while being able to spend a decent amount of time with my family. In the meantime, I am looking forward to my next travel adventure.

XDS Implementation Issues part 3

The previous two parts discussed how XDS fits into the IHE technical framework and also its relationship with other ITI profiles that are needed to provide the infrastructure to make XDS work.

Showing the 5 XDS actors

In this part we’ll talk about the document exchange profiles, i.e. XDS itself and its “variations” including XDR, XDM, XCA, XCPD and their imaging implementations.

The Cross Enterprise Document Sharing (XDS) profile facilitates the registration, distribution and access across healthcare enterprises of patient electronic health records. It is a standards based specification for sharing documents between healthcare enterprises. These documents could be a “view” into an electronic record, for example, specifying a certain episode of care or a summary. At a minimum, a consumer or receiver could add the received document (e.g. a pdf) to the patient record, but because of the electronic nature of the exchange, it is expected that the recipient would update its own electronic record (i.e. database records) with the relevant information from the document so it can be viewed and interpreted using the EMR user interface.

As explained in the earlier part, XDS has multiple actors, i.e. in addition to the document source/repository (which could be an enterprise archive such as a Vendor Neural Archive or VNA) and the document consumer, it relies on a document registry for the registration of the documents and to allow potential consumers to query them. A Health Information Exchange typically provides this registry, which can be public or private.  The requirement for this HIE infrastructure is one of the implementation issues, i.e. what if we don’t have a HIE in place (yet)? Another problematic scenario is when the source is outside of the consumer domain, for example if it is not covered by the HIE reach. That is where the other “XDS variations” such as XDR and XCA come into play.

With regard to information sharing, one can recognize three different models, each with a specific workflow and corresponding XDS-like profile:

1. Centralized discovery and retrieval, where a community uses a common infrastructure to push and query/retrieve content. This is where we use the XDS and its imaging counterpart XDS-I. A typical use case for this profile would be publishing patient summaries upon discharge from a hospital and allowing physicians to query and retrieve these. Other examples are referrals from primary physicians to specialists with the relevant information, sharing radiology reports and images from imaging centers, communicating lab results with ordering physicians, and relaying prescription information between physicians and pharmacies.
2. Direct push, where the information is sent directly to a recipient, i.e. point-to-point. A registry is not used, and the profile to use is the Cross-Enterprise Reliable Interchange, aka XDR and XDR-I. Another option is to send a secure email, or simply use the “sneakernet” by copying the information onto a CD or flash drive and let the patient deliver it to the physician. These profiles are called XDM or Cross Enterprise Document Media Interchange. The use cases for these profiles are similar as for the centralized discovery and retrieval, for example, referral information from a physician to a specialist, or summary information from a hospital to a long-term care facility, with the difference that the information is directly sent to the recipient. This is typically only done between “trusted” partners who have a strong relationship, and established policies and procedures for information sharing using a secure semi-permanent infrastructure.
3.  The federated discovery and retrieval, which is used when the consumer and creator are not within the same domain and the information spans multiple communities. This is called the Cross Community Access (XCA and XCA-I) to documents and images. The consumer needs to know in which community the patient information is available. In case the particular community is unknown, one can use the XCPD or Cross Community Patient Discovery mechanism to find out. Typical use cases are when patients live in multiple residences, seek care in another community, move, or go on vacation.

As mentioned earlier, one of the issues with early XDS implementations is the lack of infrastructure, i.e. having either a public or private HIE available that can be used to register the information and provide query capability. Having the XDR and XDM option available should not deter a closer integration, similarly to being in another community, as we can use XCA and XCPD in those cases. Note that all of the XDS family profiles share the same transactions, therefore, to support either one or all of them should not be too big of a burden from a vendor implementation perspective. The same applies for the user community, i.e. there is no reason to NOT use any of these standard profiles instead of the many proprietary solutions that are currently used for information exchange and do little more than lock you into a single service provider. However, there are still some lingering issues with the metadata used to identify the objects (i.e. documents and images) that are exchanged, more about that in part 4 of these series.

My RSNA 2014 Top Ten

View from McCormick place to the city

I have a love-hate relationship with the annual RSNA radiology tradeshow. I don’t really care about

the long lines to wait for the shuttle bus and Starbucks, the expensive food, and of course the cold weather outside, even though it was relatively warm this year. And of course the walking, as my Fitbit® logged 7.5 miles on average going from one end to the other end of the exhibit halls. But the good things definitely make up for the bad parts, i.e. the networking with others in the industry, catching up with who is where and doing what, and last but not least, seeing what’s new from the vendor exhibits.

View at the exhibit hall

There were no spectacular new developments this year, rather more a continuation of and, in some cases, merely a slight improvement in functionality and features. Especially in the imaging IT space, the lack of significant progress has been frustrating for users who complain about workflow issues and lack of integration. Every manufacturer talks about a Vendor Neutral Archive or VNA, which is supposed to serve many specialties and an EMR, which is supposed to provide a patient-centric approach towards information presentation with a “simple” universal viewer plug-in, but in talking with users, reality is different.

An example of the criticality of proper workflow support was shown in the recent Ebola case in Dallas, where supposedly the information that the admitted patient, Thomas Duncan, had just arrived from West Africa was not communicated between the admitting nurse and the treating ER physician, resulting in the discharge and fatal result as has been widely publicized. The hospital admitted that they made significant changes in the EMR configuration (which is EPIC) to prevent this from happening again.

But let’s talk about what’s new, or noticeable, at least in my opinion that was shown on the exhibit floor:

1.       We need Vendor Neutral Video (VNV) in addition to a VNA - Many users are considering a

Multiple video sources combined

VNA, however, there are still many disparate systems without digital connections that only can be integrated by combining their video signals, which could be coined as a VNV solution. This is especially important for the OR, which has several measurements to be recorded, such as EKG’s in addition to live video feeds and DICOM image displays that all need to be available for a surgeon.

Demostrating Google glasses using a
DICOM viewer

2.       Google glass for DICOM image display - Over the past few years, vendors have shown
gesture-driven user interfaces based on commercial gaming console detectors, this year, a couple of researchers showed not only hand but also “finger” based interfaces, and the ultimate interface using Google glasses. Talking with radiologists, many suffer from wrist and arm injuries caused by the daily repetitive mouse and/or trackball movements required to go through image sets. The alternatives are not quite ready for prime time yet, but it is clear that we need a better alternative; otherwise, in another 5 or 10 years, a major part of the radiologist community is going to be on disability leave.

3.       Monitor size and resolution is ever increasing - Extra-large size monitors (70, 84, or even 110

inches across as shown by Beacon) are useful when the user is relatively far away such as in the

12 MPixel display (note icons on bottom)

OR, but also in a conference room setting. With regard to resolution, Barco showed that last year’s 10 Megapixel is this year’s 12 Megapixel, with a different aspect ratio, optimal for displaying larger size icons, which allows for easy scrolling. An interesting application for color in mammography was to label the prior image in a different color, (e.g. yellow) vs the current study (e.g. blue), which reduces the chance of mixing up the new and old images. By implementing its own driver, Barco also showed how to create a “loupe,” which does not magnify but increases the luminance considerably, simulating a “hot light” as used for film.

4.       Cone beam CT is expanding beyond dentistry -  Cone beam CT scanners are already widely

Ever larger cores for the cone beams

used for dentistry applications, especially where high resolution is needed to simulate implants. There is a growing application field for ENT where, especially for the inner ear, high resolution is preferable. Now with ever-increasing bore sizes, it also can be a less expensive alternative for extremity imaging compared with traditional multi-slice CT scanners as shown by Claris.

5.       Breast ultrasound imaging becomes multiplanar ­- Ultrasound images are typically 2-D, or, if

Scaning a breast phantom using a
commmercial Ultrasound wth a fixed
registration

acquired as a loop, have a time component. Because of the hand-held operation, registration of these images with each other is very hard if not impossible. What if the images are acquired using a registration device that controls exactly the direction and relative distance from each other? The result are a set of images that can be used to do a multiplanar reconstruction or even a 3-D, similar to what is done in CT or MRI. The registration device as shown by Sono Cine looks conspicuously like the first-ever ultrasound unit. Regardless, this brings a completely new dimension to ultrasound, especially for breast imaging, this could be a great advantage.

Entry cautions

6.       Safety is critical - The solutions shown at RSNA range from sophisticated high-tech imaging solutions to simple devices that can have a major impact on patient and personnel safety. An example of such a pragmatic device is access control to MRI rooms as shown by Aegis. Incidents whereby people got hurt because of flying metal objects such as chairs, big oxygen cylinders and others that are attracted to the strong magnetic field are not uncommon. Proper protection could make a major improvement and satisfies the increasing scrutiny by Joint Commission inspections.

Definitely not caustrophobic

7.       Niche MRI’s are becoming available - Standing-up MRI’s have been valuable for awhile as   down or when standing up, especially when it includes the spine. A logical evolution is the sitting down MRI as provided by ParaMed, as many people spend their days sitting in a chair, and again, lying down on your back in a regular MRI might not show the cause of the back pain as a sitting down image would.

8.       True multi-modality multi-plane system - The illustration shows a

Seems kind of crowded

person that is scanned using four flexible arms, with two X-ray source and detectors using ABB robotic arm technology, called 4DDI. It is similar to a bi-plane system but with the difference that the rotation and angulation variations and combinations are virtually unlimited. It can function as a digital X-ray unit, a cone beam CT, fluoroscopy unit, all in one. This particular device was semi-experimental, apparently there has not been a single install yet, and I could not quite figure out from the sales people what the application might be for this device. So, it will be interesting to see if it makes it to next year’s RSNA.

9.        DR in a box - For veterinary and other mobile applications, such as a nursing home, the

Container with digital, wireless
plate adnd computer

Carestream DR in a box is a good solution. The plate is a wireless DR plate, with a PC used for QA and preliminary viewing. The battery life of the plates are sufficient for more than 100 exposures, which should be OK for human use; for veterinary use, it might barely cover all the views needed to image the joints for only 2 horses. In the latter case, one would require extra batteries for the plates to be available.

A true table top

10.   Tabletop CR finally arrived - Carestream introduced a follow up of their VITA CR system, which has a smaller footprint and weighs only 26 lbs. The unit’s serviceability has greatly improved as almost all of the moving parts that cause the most problems are integrated into a cartridge, which is very easy to exchange. In the case that an error occurs, the user takes out the cartridge, replaces it with an on-site spare, and the broken one is refurbished at the manufacturer to be re-used. It is even simpler than replacing a cartridge in a printer. A test plate is included with the unit which shows whether it is still in calibration. This is a great solution for small clinics and for emerging and developing countries where high serviceability is a key.

This year celebrated 100 years of RSNA. This event has grown tremendously, and even though

Having the honor to finally meeting
Dr. Wilhelm Roentgen in person

attendance and booth size has been decreasing over the past few years, it seems to have stabilized. Gone are the days where vendors would splurge, instead, cost cutting is everywhere, not only on the user but also on the vendor side, but RSNA still draws more than 50,000 attendees from around the world. I personally still enjoy it, as most attendees do. One of my friends and colleagues likes to call it a “workshop,” i.e. he does the work during the event and he takes his wife who does Christmas shopping. Not a bad idea, try it, I am sure your spouse and/or partner will like it.

IHE XDS Implementation Issues Part 2.

XDS is like an engine with several parts

This is the second part of the IHE XDS discussion that will focus on the relationship between XDS and the other profiles in the IHE ITI technical framework domain. Note: you can watch a video of this presentation here. As mentioned in part 1 of this series, the Integrating Healthcare Enterprise (IHE) Cross Enterprise Document Sharing (XDS) profile has been widely implemented and many vendors have tested and demonstrated its functionality at the previous connectathons, however, actual deployments have been very limited. One of the reasons is that XDS by itself does not make sense, as it is merely an engine, which has several components. For example, if we continue this analogy, it has a transmission, cylinders, alternator, etc. The same is true with XDS, it consists of several actors and it is important to validate that all parts are present to make it work. As an engine needs other parts such as a chassis, wheels, steering controls, etc. to make it into a fully functioning car, truck, or motorcycle, which is where the other ITI profiles, such as security, patient information management, workflow, provider, personnel and content management play a role. 

Let’s look at each one of these profiles needed to facilitate the XDS engine:

1.       Patient Identity Management: If a document or image is exchanged between two enterprises, we better make sure that we know who it belongs to, in other words, that we have unambiguously identified the patient. There are several profiles needed to facilitate this:

a.       Patient Administration Management (PAM) - to manage patient information locally, such as with a hospital information system or ADT system

b.      Patient Identifier Cross-Referencing (PIX) - to support linking patient identifiers across multiple patient identifier domains. This allows systems to register their patient identity, e.g. with a Patient ID, with a so-called Cross Reference Manager, such as present in a Health Information Exchange or HIE, so that potential consumers, i.e. physicians can query and be notified of any changes.

c.       Patient Demographics Query (PDQ) - to allow consumers to query for patient demographics and visit information.

d.      Cross Community Patient Discovery (XCPD) - to discover patient information across communities using a gateway to talk to.

2.       Security and Privacy Management: These profiles make sure that the information is exchanged in a secure manner using the following profiles:

a.       Audit Trails and Node Authentication (ATNA) - to provide authentication and also a standard protocol and format to exchange and archive audit trails

b.      Consistent Time (CT) - to synchronize multiple applications using a single clock. This is critical as some of the applications need to be very tightly coupled.

c.       Enterprise and Cross Enterprise User Authentication (EUA and XUA)- to provide a single authentication process

d.      Basic Privacy Consent Management (BPPC) - to manage patient consents, i.e. what he or she allows to be shared

e.      Document Encryption and Digital Signatures (DEN and DSG) - to provide the information encryption and data integrity.

3.       Provider and Personnel Management: These profiles identify provider organizations and people across different enterprises:

a.       Personnel White Pages (PWP)- to provide a resource to determine exactly which provider is involved

b.      A Healthcare Provider directory (HPD) - to make sure that the right provider is selected

4.       Workflow Management: This profile defines workflows in the different enterprises. It uses the XDW or Cross-Enterprise Workflow profile to do this.

5.       Content Management: The content management profiles are not really part of the ITI domain, but rather defined in the individual specialty domains such as patient care and several others. However I want to mention it here as it is essential to have an agreement not only about the protocol to be used (e.g. a HL7 transaction) but even more about the content of these messages, otherwise the receiver will not be able to interpret it and, for example, use it to store in its medical record system. It is easy to send over documents such as a PDF that can be added as a document to a patient folder, it is much harder to agree on a template for example for a discharge or medical summary report with all of the individual fields properly encoded so that they can be decoded and interpreted by a software application.

In conclusion, XDS needs many more parts, as it is just an engine, it require several more profiles to be able to use it in an enterprise setting. The next step is discussing what the XDS itself encompasses and how it works, which will be in part 3. 

DICOM images on your smartphone: DHIR instead of FHIR?

The DICOM protocol and metadata definitions have served the health care imaging community very well. Since its early definition which dates back to 1992, the protocol has not undergone any major changes. However, with the advent of mobile devices and need to use web services to exchange images, that is about to change. Similar to the HL7 FHIR activity, (see related blog post), which intends to leverage web services and resources to provide a fast implementation platform, DICOM is following the same path and has defined a new protocol for use over the web, and it is especially geared towards mobile device connectivity. I coined this new version “DHIR” after “DICOM Healthcare Interoperability Resources.”

The need to provide a web-friendly version of the DICOM protocol was acknowledged more than 10 years ago, when WADO (Web Access to DICOM Objects) was added to the standard. This option did not really gain any traction until it became part of the XDS-I (cross document exchange for imaging) profile definition several years later. WADO compatible viewers are also relatively new, they did not appear on the market until a few years back.

WADO was the first important step towards a more web-friendly protocol, instead of the traditional DICOM negotiation that has to take place before any image communication can happen, it provides a simple http call or uri (uniform resource identifier) request that includes a pointer to a specific DICOM object using a UID while specifying the content type, for example a dicom, jpeg, or could even be a xml or rtf for reports.

In the meantime, a group of healthcare IT professionals came up with a new concept which they named MINT (Medical Imaging Network Transport), which took the web transport mechanism a step further and also changed how the metadata is being packaged while exchanging the images. There have been a few implementations of MINT, but more importantly, since then, the Working Group 27 of the DICOM standard has taken this into account and included the key concepts of MINT into the DICOM standard as “RESTful DICOM” extensions, very similar again to the HL7 FHIR concepts.

What does RESTful DICOM mean? Well it uses the http protocol, including the authorization, and encryption capabilities of the web communication protocol. The major change is that a request can get the complete metadata of a DICOM object in one request. In addition it allows for “bulk” transfer of information with a clearly defined beginning and end. It is referred to as WADO-RS.

By the way, there is also a so-called WADO-WS defined, which basically requires a message “envelope” to be exchanged in the form of a SOAP message (simple object access protocol), another intermediate step to the RESTful WADO-RS.

As part of the RESTful services, in addition to the new capabilities for bulk transport (i.e. multiple images in a single transaction) and the capability to retrieve only the metadata (DICOM headers) for a study, there are also new protocol services defined, i.e. the WADO-RS, and the capability to do a web-services store (STOW-RS) as well as a query (QIDO-RS).

Does this mean that all devices supporting the “traditional” DICOM protocol today are going to be changed? Certainly not, similar to HL7 that has a very large installed base of version 2 implementations, there is also a huge installed base of DICOM enabled devices, so as HL7 is not going to move all of them to FHIR, DICOM is not going to move them to DHIR either. However, for new applications such as small footprint viewers, plug-ins, apps on mobile devices and tablets, these new standards are a great tool. I expect that it won’t take long before we will see implementations being offered.

IHE XDS Implementation Issues Part 1.

The Integrating Healthcare Enterprise (IHE) Cross Enterprise Document Sharing (XDS) profile has been widely implemented and many vendors have tested and demonstrated its functionality at the previous connectathons, however, actual deployments have been very limited. Reasons for the very sparse implementations range from infrastructure issues, to lack of detail in the specifications, and the need to specialize and customize the metadata that is used to register and maintain the documents that are managed. The underlying issue is that XDS is not merely an interface standard but, more importantly, very much a workflow profile, which means that the differences between different institutions and even more different regions or even countries make it hard to have a one-size-fits-all implementation.

This four-part discussion will attempt to examine the issues in more detail. In part one I am going to give a high level overview of the XDS, followed by the XDS-ITI relationship discussion, the discussion of the XDS family (XDR, XDM, XCA). In part four will talk about the issues that have arisen during early implementations.

XDS is an IHE integration profile that facilitates the registration, distribution, and access of electronic health records across healthcare enterprises. It provides a framework for sharing documents, which includes images between practitioners and organizations. Some of the typical use cases are the publishing of patient care summaries by healthcare providers, the access of patient records, regardless of where they are stored in case a patient is admitted to an ER, sharing relevant information between a primary physician and specialists, sharing radiology images and reports, lab results, and exchange  pharmacy information.

If a system claims support for XDS, the first question to always ask is which of the possible actors is implemented. For example, a system such as a PACS can send information about its documents that are to be shared using XDS, a Vendor Neutral Archive or VNA can archive and manage documents and/or images and have an XDS interface to register it with a regional Health Information Exchange (HIE). A physician can access the HIE to search for relevant documents and pull them from a XDS compliant archive. The actors with corresponding functionality and transactions that are defined include the so-called Document Source, Repository, Registry, Document Consumer, and Patient Identity to provide unique patient identification. It is uncommon for a system to provide all of this information; most vendors use as one or more of these actors. To make sure that there are no gaps, one should map all of the actors using the vendor’s IHE integration profile definitions, which are available from the vendor.

The XDS-I, i.e. Cross Enterprise Document Sharing for Imaging has exactly the same structure, and number of actors. The difference is that the document source is an imaging document source instead and the same applies to the consumer. The transactions are obviously different as well, as we use DICOM transactions to exchange the image documents.

The transactions between the different actors are well defined in the IHE technical framework documents, for the XDS it is the ITI or IT Infrastructure framework and for the radiology it is the RAD or Rapid Application Development  framework. In some cases, there are different options for the transactions, for example, there is a HL7 version 2 and version 3 option for the patient identity feed, which basically translates into a traditional ADT (Admit-Discharge-Transfer) transaction (A01, A04, A05, A08, A40) for V2 or a XML encoded one for V3. Similarly, for the image retrieval one can select the traditional DICOM WADO http URI transaction or the newer SOAP based messaging WADO version.

I like to compare XDS to an engine, which has several components, for example, it has a transmission, cylinders, alternator, etc. The same is true with XDS, it consists of several actors and all are needed to make it work. It is important to validate that all parts are present to make it work. Expanding on the engine analogy, it needs other parts such as a chassis, wheels, steering controls, etc. to make it into a fully functioning device such as a car, truck, or motorcycle. That is where the other ITI profiles play a role, such as security, patient information management, workflow, provider, personnel and content management. These will be discussed in part two. For a more extended coverage of this subject see the video.

HIMSSLA in Sao Paulo: Latin America is catching up.

The exhibition floor was quite busy.

I like the international HIMSS meetings much better than the big USA-based ones. Take for example HIMSSLA, which was held on Sept.18 and 19 in Sao Paulo, Brazil. The attendance was small, probably 500 or so, but the speakers were top notch and the attendees were definitely the local top decision-makers and movers and shakers in industry and government. If nothing else, the hotels are better and less expensive compared to Chicago, for example, and the food is the best (don’t get me started on the excellent Brazilian coffee). Of course it is a little bit further than Chicago, but an eight hour direct international flight is not bad at all and priced not that much more than a domestic flight in the US.

Latin America is definitely catching up, during the conference, HIMSS presented two awards to hospitals that achieved stage 6 status in the HIMSS Analytics EMR adoption model. These hospitals are working on getting to stage seven already, so there is great progress being made with implementing EMR technology.

The Brazilian government in 2011 set requirements for interoperability standards such as IHE XDS, PIX/PDQ and a couple others so there is a big emphasis on interoperability. However, there is still a lot of education and learning to be done about connectivity and there are still hurdles to overcome, but the intention is clearly there and the activity at the HIMSS showed that people are serious about it.

As I mentioned, there were top notch speakers both from the US, such as the executive director of Kaiser Permanente, the CEO of the New York eHealth collaborative, and global director of health from Accenture, but also from Latin America. It is always very motivating to see how these leaders see the future of healthcare evolving and how they implemented healthcare IT to achieve major improvements in quality and patient care while also reducing cost. Of course, there is still a certain amount of crystal ball gazing when thinking about how healthcare delivery might change over the next five to 10 years, but hearing how these leaders see the impact of social media, mobile health and home health is encouraging.

One thing is clear, the care of a patient does not stop when he or she leaves a hospital, rather, it is when it continues by following up with phone calls, emails between physicians and patients, tele-consultations, uploading of personal data such as weight, blood pressure, glucose meter readers, and even pacemaker recordings into Personal Health Records often on a daily basis. That is how re-admissions can be prevented and how real, fundamental improvements can be made in the care of patients.

Several presentations showed evidence of how this clearly worked for them. Many improvements

were also made by being able to mine the data from the EMR and share it back with not only the decision- makers, but more importantly, with the people on the frontlines (physicians, nurses, care coordinators, etc.) so they can see how to make an impact.

Larry Garber from Atrius Health in Massachusetts showed that his organization typically spends $10,700 on patient healthcare costs through EMR implementation and using tools to mine and share the data, compared to the Massachusetts average of $13,000. Similarly, Accountable Care Organizations (ACO’s) in the US have saved $500 million so far, and this is just the beginning. There is still a lot of work to be done but it is clear that investing in healthcare IT pays off when done well and smartly.

In conclusion, I definitely recommend attending one or more of the international conferences, the smaller scale makes it much more effective and less tiresome, and again, the venue’s are great! I know I’ll be in Brazil next year again for sure!

PACS professional career and certification options.

Certified does not mean competency,
however it shows commitment and a
certain basic level of knowledge

Over the past several years, PACS support professionals have evolved from being “one does all” generalists into several different career paths with corresponding professional certifications[1].  Depending on the strengths and preferences, as well as ambitions, of these health care imaging and IT professionals it is now possible to select one or more career paths to meet individual and organizational goals. Note that the careers described below are equally applicable to PACS administrators as well as PACS support professionals, such as biomedical engineers, service and support technicians as well as interface and workflow analysts, working either on the provider side or the vendor side.

The different career paths have a foundation based on the basic skill set of clinical and IT knowledge, with additional specializations after that, which not coincidentally, have corresponding certifications.

The following career paths can be distinguished:

1.       The basic foundation for these health care imaging and IT professionals is provided by the PACS Associate skills with the corresponding PARCA CPAS certification (Certified PACS Associate). The core competencies include:

a.       Clinical expertise which includes familiarity with the various body parts and body systems such as the circulatory, musculoskeletal, gastro-intestinal, nervous, endocrine, pulmonary and reproductive systems. The candidate should be familiar with the most common medical terms and imaging positioning, and know the workflow and appearance of the images created by imaging modalities such as CT, MR, DR, CR, digital mammography and breast tomosynthesis, US, RF, XA and IVUS and IV-OCT, NM, PET/CT and MR/CT.

b.      IT expertise including the basic hardware components such as storage devices (RAID, SAN, NAS) and software knowledge of MSDOS, Windows, UNIX, relational databases, image and data representations and networking technology.

Here are some illustrative examples of what these PACS associate professionals are expected to do:

·         Fix “broken” or “unverified” studies at the PACS

·         Configure hanging protocols at a workstation based on body parts and view codes (e.g. PA of the chest, or MLO and CC of a breast image)

·         Configure prefetching algorithms at a PACS router based on modality type and/or series descriptions

·         Configure a new PACS workstation with its IP address and port number and be able to perform basic network troubleshooting (ping, tracert, etc.)

·         Query a PACS database using basic SQL queries to find a missing study and/or provide basic statistics such as “all CT exams added to the database during the past month”

·         Find the configuration file on a PACS server using basic UNIX commands

·         Evaluate low level log and configuration files that can be encoded in hex or binary representations

2.       The first level of specialization is to expand the competencies into other specialties, enterprise imaging, workflow and in-depth knowledge of PACS architecture corresponding with the CPSA certification. In addition, these professionals are equipped to address image quality and other QA issues and have a little knowledge of DICOM and HL7, enough to do basic troubleshooting and configuration. They also deal with security and privacy issues for the imaging and informatics systems. They might manage radiology, cardiology, dentistry and other imaging systems that are situated in various departments.

These are typical activities for these professionals:

·         Review audit trails on a regular basis for any potential violations

·         Perform QC audits such as CR reject analysis

·         Run regular test plates on CR systems and test patterns at the workstations to monitor the image consistency and persistency

·         Do an extensive workflow analysis and update this to constantly improve workflow

·         Coordinate any changes and upgrades with other departments

·         Manage storage, and track performance and capacity

·         Manage the enterprise image management system (VNA) in addition to the individual PACS systems

·         Coordinate storage and image management requirements between different imaging departments and specialties

·         Manage several PACS associates who in turn are responsible for the day-to-day operations while the CPSA is more focused on the long term planning

3.       Some professionals expand into project management, coordination, and/or take on an extensive teaching role, which seems to be the area that CIIP candidates specialize in. In my opinion, CIIP by itself is not necessarily enough to do that job as it does not emphasize technical skills (for example, there is no requirement to know anything about HL7), however, it has a nice spread of generic requirements ranging from learning methods to health care delivery hazards, and creating and interpreting requests for proposals.

These are typical activities that a CIIP professional might be involved with:

·         Creating an implementation plan for a new release

·         Developing a migration strategy from one vendor to another

·         Providing a comprehensive learning plan and tools for a new release implementation

·         Being part of a multi-functional team to evaluate RFP responses

·         Managing the implementation of a new speech recognition application

·         Coordinate communication about new upgrades, changes, with an organizational control board

4.       A PACS system has many interfaces, not only to many modalities (there could be dozens of those in a typical installation), but also to a scheduling system, reporting system as well as an EMR. There could also be an enterprise solution for archiving involved, such as a VNA. An Interface analyst will manage and support these interfaces having competencies as defined by the CPIA certification. These professionals are intimately familiar with HL7 and DICOM data formats and protocols. They can use simulation tools and have access to a wide variety of test transactions and test images, and can use validation and test tools such as network sniffers to troubleshoot even the most tricky interface problems.

These are typical activities that a CPIA professional would perform:

·         Develop an acceptance test plan and perform the acceptance testing for any new releases

·         Troubleshoot random connectivity issues between modalities and a PACS system using a network sniffer

·         Map and configure HL7 messages into the DICOM worklist

·         Assist interface engine specialists with mapping HL7 messages to meet the PACS requirements

·         Assist the purchasing team by specifying interface requirements, especially with regard to required IHE profiles

·         Validate any new software and new modality interface against the hospital specific requirements for information content

·         Work with biomed and IT to make sure any new installation and device is properly evaluated by reviewing interface specifications, conformance statements and IHE profile definitions.

5.       In addition to the interface specialist as defined by the CPIA requirements, there is also a place for HL7 experts, specializing in the HL7 standards. These professionals are certified as a HL7 interface specialists and there are several types of specialists, covering version 2, version 3 and CDA. In the context of medical imaging, the version 2 certification is the most applicable. These professionals have a very detailed knowledge about the HL7 data formats.

Typical activities for these specialists would be:

·         Program interface engines to map different HL7 messages accommodating different versions and unique hospital requirements

·         Manage the hospital specific extensions of the HL7 transactions

·         Test any new interfaces and validate them against the hospital requirements

·         Manage and control the interface specifications

·         Develop hospital specific conformance profiles that can be used to test and validate changes and upgrades

6.       There is an emerging group of professionals that are called “medical informaticians.” Speaking with recruiters, these are the hottest jobs right now. Unfortunately, there is no certification (yet) that addresses this need, although the PARCA CHEA comes close. As a matter of fact there are no master’s degree programs in the US that I know of covering these specific requirements (Canada is ahead of the US in this regard). These are health care imaging and IT architects that assist an institution developing an enterprise (and beyond) imaging solution.

Typical activities for these specialists would be:

·         Negotiating with the regional Health Information Exchange (HIE) the interface, information exchange, and security and privacy policies

·         Assisting in developing the architecture for the private HIE and its interface with the VNA

·         Managing and coordinating the many imaging exchange scenarios

·         Managing the imaging components of Personal Health Records and patient portals

·         Develop and manage a comprehensive image import and export policy

·         Specify requirements for performance and throughput of any external connections to clinics, partners, third parties, for clinical trials, etc.

·         Be the interface between the EMR specialist and the imaging departments to facilitate image enabling an EMR

·         Specify and test enterprise wide IHE profiles such as PIX/PDQ and the XDS family (XDR, XCA, etc.)

In conclusion, as is obvious from the information above, there are plenty of growth opportunities for health care imaging and IT professionals. In my opinion, there is too much emphasis on how to change from existing PACS careers into other areas (witnessed by the SIIM tracks on “how to become the next CIO or COO”), while there are in my opinion plenty of opportunities to stay within this field of expertise and grow accordingly. There is definitely a need for professionals that understand the workflow and intricacies of the interface and data formats, especially now that there is so much emphasis on image exchange and image enabling of EMR’s. In short, the future is bright, especially for those who recognize the opportunities and possibilities for advanced certifications.

---

[1] The certification organizations that provide the applicable certifications are ABII, PARCA and HL7