Friday, December 5, 2014

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.



Monday, November 3, 2014

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.

Sunday, October 5, 2014

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!

Monday, June 30, 2014

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

Saturday, May 24, 2014

SIIM 2014 in Long Beach, CA, What’s Hot and What’s Cold:

It was definitely hot in Long Beach during the annual SIIM conference; the outside temperature
A typical view from the exhibit hall
reached over 100 degrees during the conference; a record since 1970. There were a couple of hot topics during the sessions and on the exhibit floor of the SIIM conference, although overall, much less than I expected and I have been used to. I personally think that SIIM has lost its niche and definitely not gotten its “mojo back” as one of the other writers claimed, but I’ll talk about that some more later, after listing some of the topics I found worthwhile. So, first of all, here is my “hot topic” list:

1.       Dashboards: I always like a conference when I can learn about new tools and tricks. My latest favorite tool is Splunk. I had not even heard about it prior to this conference, but this tool (which is free if you use it for a small amount of data) allows one to create an amazing dashboard in almost no time. At this particular SIIM workshop, which was amazingly lightly attended, we were using a test data set in an Excel spreadsheet format that included patient visit related events, and made an impressive dashboard in less than 30 minutes. One of the real-life issues is how to get access to the data. This software takes a simple HL7 feed from an interface engine into an open source database and indexes the data, producing an elegant solution to data access. Another advantage of indexing the data in the “middleware,” i.e. a database that functions as a data warehouse, is that it cuts down on the work and related cost that Splunk has to do, as the software license depends on the amount of data it indexes. Dashboards have been talked about for many years but I feel that now the tools are available to really implement them, I highly recommend anyone wanting to do some type of dashboarding to check this out.

2.       Decision support: There was a lot of talk about “big data,” but not a lot of talk of what to do with it, and I think that is not quite clear yet anyway.  Using the big data for the purpose of decision support was mostly considered at the conference in terms of placing the appropriate orders, which is valuable, but there are so many more opportunities than just at order placement. Interestingly enough, just sharing the data about who orders what for what condition, seems to already be making an impact on the behavior of the ordering physicians as it allows them to see how they compare with their peers. One of the main objectives for decision support has traditionally been to save money, for example, why would you order a CT, if a chest X-ray would suffice for a particular case. However, a more important reason for decision support is to increase the quality of care as it would support selecting the appropriate procedure for the specific condition of the patient. In some cases it could justify a CT scan instead of a regular chest X-ray and improve the diagnosis, and thus not necessarily save money. Decision support using big data is still in its infancy; it will be a while before mature implementations become mainstream.

3.       Analytics: One of the main challenges with doing analytics is that a lot of the data is collected and measured for the wrong reasons. For example, a commonly measured yardstick is the report turn-around time, i.e. the time between a diagnostic procedure being completed and a report being available to the physician. A typical time goal might be anywhere between 15 and 30 minutes, which is quite achievable using speech recognition and good workflow support by the PACS. However, this time as a measure is useless if you don’t put it into clinical context, i.e. what is important is that the information is available at the right point, at the right time, which in many cases is the time of the patient’s physician appointment. If the appointment is not for another two hours later, a turnaround time of 30 minutes sounds great but does not provide any additional value over a turnaround time of 90 minutes. However, if it concerns an in-patient in the ICU or someone just admitted to the ER while the physician is waiting to get the results, 15 minutes might even be too long. The problem is that a radiology department typically does not have access to appointment data, unless it has access to the EMR or hospital information system. Therefore, agreements with the corporate IT department have to be made to allow access to that information. Another lesson learned is that to do analytics, one preferably would access a copy of the data, basically building one’s own data warehouse as accessing the real-time data with additional queries could significantly impact the performance of the operational system. So, analytics in a vacuum, i.e. on a department level, is often not useful and has to be extended to the enterprise, which requires the corresponding information access.

4.       Quality Improvement: An important quality improvement is the avoidance of Left/Right mix-ups. The result of a mix-up can be a procedure performed on the wrong extremity (operating on the left knee instead of the right one) or on an incorrect part of the body (perform a biopsy of the wrong lung, the incorrect breast). These errors are not uncommon and can potentially be avoided by a simple Left/Right check in the report. This is implemented by scanning the report for the words “left or right,” which are subsequently highlighted in the report on the screen to provide a double-check to the radiologist. The speaker at the conference showed a plug-in of the reporting software that provides a “check PACS button” as part of the menu, upon which these words are highlighted.  A study using this feature was done over a period of 7 months when 140,000 exams were reported, 45,000 of them had the check done (for some reason, not all users used the feature). There were 32 left/right mix-ups identified in this sample. One should realize that not all errors are covered, for example, a not uncommon case whereby a procedure is performed on a different side of the body than was ordered would not be detected. The extra mouse click seems to cause some of the users to either forget or be unwilling to take the time to perform the check. However, it would not be hard for a reporting vendor to automate this as part of the regular workflow, e.g. highlight all of these as part of the sign-off. For now, during this trial there were 32 errors prevented by an amazingly simple mechanism.

5.       Ultrasound structured reporting: Ultrasound structured reporting has been around for more than 10 years. It works as follows: a technologist does measurements on the ultrasound image, which are standardized and structured, i.e. always taking same measurements for certain exams, for example, always measuring the circumference of a fetus’ head to monitor growth on a monthly basis. Instead of a radiologist having to read the measurements for his or her report from the screen, or from a piece of paper that was used by the technologist to record them and re-enter them or repeating them using speech recognition, these measurements can be exported by the ultrasound in a standard DICOM template, i.e. Structured Report (SR) that can be interpreted by the reporting software and used to automatically fill the information into the reporting template. Doing this in an automated manner provides about a 30 percent improvement in report time for certain procedures, which does not take into account the time saved for the technologist who does not have to fill out worksheets. Pretty much every ultrasound exports these SR’s today, but unfortunately, very few reporting voice recognition (VR) systems have a SR input. This seems remarkable to me, i.e. why would not every radiologist use this and be able to save 30 percent of their time, or go home early as the work is so much more efficient. I don’t know the answer to that, I do know that there is at least one vendor that sells middleware that takes the SR data and fills in the information using a proprietary interface to the most popular speech recognition system. Implementing DICOM SR is not for the faint-hearted as it is not trivial, and also there is quite a variation between the different ultrasound vendors on what they report, something that the DICOM committee is currently addressing by coming up with a more simplified template. However, these weaknesses should not keep any vendor from implementing SR. Hopefully through more user pressure, the VR vendors will start implementing it.

6.       DICOMWeb and HL7 FHIR: One of the major barriers to implementing new applications that use and exchange medical imaging and related information is the complexity of the data formats and protocols and its overhead. HL7 version 3 definitely did not help in that with its verbosity and complexity, and DICOM has traditionally been somewhat complex to understand, especially for novice users. In this day and age, developers want to build new apps using the 5-5-5 rule, i.e. 5 seconds to find the document on the computer or internet, 5 minutes to grasp what it is all about, and 5 hours to build a prototype. That is how you can build an app today, for example, for your smartphone. However that is not how you build an image enabling application in your EMR. That is why both DICOM and HL7 are working on simplifying their protocols and formats using standard web-based technologies such as REST. The HL7 FHIR specification is in the draft stage; with about 100-150 reusable objects that the committee thinks are needed, there are already 50 built and ready to be used (see more details on FHIR here). DICOM is the process of specifying the necessary new services as well, there is a DICOM pull available called WADO (Web Access to DICOM Objects), which has a new version using REST technology, there is a query available, called QIDO, and a store, that is called “post” in the form of STOW-RS. One of the issues with reporting is to coordinate different jobs using the appropriate work lists, which is being addressed by the DICOM committee with development of the Unified Procedure Step. You might ask whether this is going to change all of the installed base, for example how a CT is talking to a PACS system today. The answer is no, but if the PACS wants to post images to an EMR, communicate with any smart phones or iPads for a radiologist to share his images with a patient, or post an anonymized image on facebook for consultation, then the answer is very likely yes. This will allow DICOM and HL7 to go mainstream as developers, who have no domain knowledge because they worked on banking or manufacturing or billing software prior to the medical field, to pick up the thread very quickly and easily and start implementing these new applications. As a matter of fact, at the SIIM “hack-a-thon,” people could actually get a feel for how to build one of these apps very quickly.

7.       Digital Breast Tomosynthesis: the session on digital breast tomosynthesis (DBT) did not really
Vendor presentations
in the exhibit hall
reveal any new information except for the fact that it seems to be going mainstream. One of the issues noted was that there are no really good hanging protocols available yet at the vendor’s PACS systems for viewing the many thin slices being created. However, radiologists are getting better and more efficient at interpreting them and it appears that the average length of interpreting a DBT exam vs a regular mammogram is only about one-and-half to two times longer, much less than the initial times when this technology was introduced . The DBT images are supposed to detect more cancers, but one has to realize that as of now the patient gets two exams, the regular four-view and the additional DBT exam, which increases the radiation dose exposure. There is still a lot of work to be done by the vendors, for example, one user reported that their software has trouble distinguishing between the regular mammogram and DBT synthetic reconstructed images, something which is addressed in the DBT IHE profile, which is apparently not yet widely supported. This was a hot topic last year, and still is, as it is becoming mainstream, but the PACS viewers have apparently not yet caught on.

I can typically list at least 10 hot topics from every conference, but not from this one, which was an indication of SIIM2014: there were not many new things to show. It appears to me that SIIM wants to be all things to too many people, i.e. different professional groups with a different skill level, and in the process of that, it becomes too widespread and scattered. As an example, this year the program included general sessions, hot topic sessions, scientific sessions, five different learning tracks, learning labs, innovation theatre sessions, roundtable discussions, and study groups. Sounds confusing to me, I would rather have a few well-defined choices.

One of the main benefits of these types of meetings is also the opportunity for networking,
I always enjoy meeting my old students,
here with Omar who attended my training
in Cairo in 2009
however, if there is not a large enough audience, the networking opportunity is limited. Even though the attendance was a little bit more than last year, it is still less than half of what it was a few years back, and I missed many of my colleagues who did not attend.

 It was apparent that SIIM wanted to please the vendors by having sessions that consisted of vendors only. I believe that most attendees (including myself) did not really care to hear how a particular vendor has the latest and greatest solution but rather would have liked to see users giving testimonies on what works and does not work.

One of the better attended booths was
EchoPixel showing their 3-D display
next to a well visited PARCA booth


With regard to the technical exhibition, several vendors I talked with did only get a few leads, which made it very hard for them to justify this event. Potential customers do not really have to “kick the tires” anymore as pretty much any vendor today can schedule an on-line meeting and corresponding demonstration that is interactive using GoToMeeting and other similar online tools to meet most of their needs. In my opinion, if one really would like to find out how a system works, I would visit another hospital and talk with other users to find out not only the vendors strengths but even more importantly, their weaknesses.

My most memorable part of
SIIM was the 5 k run along
the bay,here with my running
partner Mohamed Shoura
From a faculty perspective, more than 30 percent of the faculty this year were the same speakers as last year, some of them giving multiple presentations. There is nothing wrong with that except that there is a lot of regurgitation of old content going on. Even many of the titles are nearly identical, with only a small twist of words. The best example of this, I saw from one of these frequent speakers showing analytics data on slides from 2007!

It is hard to look into a crystal ball and predict how SIIM is going to evolve over the next several years, but I believe that they need a new direction to get their old mojo back. The next meeting is in Washington DC, I might skip a year (or two). Hopefully the slides dating back to 2007 will be updated by then (but who knows).