New Enterprise Certification for HIT Professionals Announced

Teaching PACS at OTech

The PACS Administrators Registry and Certification Association (PARCA) announced a new certification which serves as a capstone for those health imaging and IT professionals who already have their basic PACS certification and intend to develop into a more enterprise-oriented professional. It is called the CHEA or Certified Healthcare Enterprise Architect certification and builds upon the strengths of the existing CIIP and PARCA certifications. An important part of this certification is the intimate knowledge of the standards that facilitate the exchange of imaging and related information in an enterprise. This is very relevant now that the new stage 2 Meaningful Use requirements have expanded to include imaging. The process of exchange is facilitated by existing standards such as DICOM and HL7, and addressed by the many IHE profiles which specify in detail how information is exchanged between PACS systems, EMR’s and Health Information Exchanges.

The initial discussion of whether or not health imaging and IT professionals should be certified has lost momentum as evidenced by the fact that between PARCA and CIIP there are almost 1500 professionals certified as of today. According to Dr. Chuck Willis, President of PARCA, it was time to make sure that certification adjusts to the changing environment. It is not enough to know how to move images around, but even more important to be able to facilitate the utility of images by incorporating them into the EMR and making them available through HIE’s to other facilities and physicians. Therefore, building on the strong base of CIIP and PARCA certification requirements, this new certification was defined with a strong emphasis on the implementation of EMR’s. What differentiates this from other certification programs is that it includes a major part of hands-on practical use of implementations. Candidates should be able to look at a log file that includes a transaction and retrieve DICOM and HL7 messages and image headers, and interpret these in order to troubleshoot issues that might occur.

Detailed requirements of the new certification re to be published in March on the PARCA website, but a  sneak preview based on discussions with Chuck Willis indicate that there is a big emphasis on IHE knowledge, whose implementation has proven to improve  efficiency in existing PACS/RIS and EMR deployments. This certification will allow candidates to play a pivotal role in the deployment of the EMR, its extension to include the new stage 2 and 3 requirements, and achieve the ultimate Stage 7 of the HIMSS EMR adoption model.

Launching this important new certification will be a major vehicle for healthcare professionals to gain new knowledge and build skills needed to be part of the healthcare revolution.

Introduction of the OTech security team.

Sajiv in front,
with Victoria covering his back

Let me introduce myself, my name is Sajiv, I know a weird name, but I’ll tell that story another time. I am responsible for the security of the OTech offices. My job is a real boondoggle, I inspect the grounds in the morning, keep an eye out for anyone who might come close or potentially intrude during the day, at night I do my final rounds and in between I get fed a great meal and nap most of the time. As members of the canine species we are trained and raised to perform this important task and, being of the boxer breed, we can look very threatening. In general, we do very little harm, except occasionally to other animal species, in particular squirrels, possums and in worst cases even coyotes. Sometimes we also need to deal with those small black and white animals, which get really, and I mean really smelly. For some reason, after a successful mission against those furry creatures, we are always yelled at by our master and matron and are subjected to a bath with really sticky red stuff. We also run after deer but that is more as a sport as we can’t outrun them anyway.

One of the most important jobs is to leave our scent at the perimeter to distract and confuse other species, and we do this very systematically. My partner, her name is Victoria (she is really the boss but I try to act otherwise), takes care of the surface area and I, being a male, am better equipped to take care of anything between about one half foot and one foot on any tree, mailbox, and an occasional parked car. I can assure you that it takes a lot of practice to discharge not too much and not too little so we can cover the distance we walk in the morning with our matron. (I call her matron as I am told that the word for female master has a poor connotation).

We have an excellent EWACS (Early Warning and Control System) deployed in our vicinity. We communicate very effectively among our species. We have a golden retriever positioned strategically at the entrance of our block who serves as a scout and roams the back of his premises and, upon seeing a potential intruder entering our neighborhood, immediately signals this to all of us. About halfway in between him and our property there is a pair of hush puppies who make up for their size with their signal volume. If an intruder still manages to arrive within eye sight we’ll immediately storm out of the office and go full blast to the border of our premises doing our best to look like attack dogs. So far this strategy has worked pretty well, although sometimes too well as there have been some incidents where we were unable to identify friend or foe in a timely manner (and gotten in trouble for that with our master and/or matron).

Like I mentioned, my partner Victoria is really in command, even though I am faster and can outrun her easily, if there is a real threat, I let her take the first blow as a good commander should. You see, canines are like the Israeli army; the highest number of casualties occurs among the commanders. She has the scars to show it as well. A nasty one on her side from a coyote who tried to enter the premises and one on her belly, when she was defending her matron from a nasty little dog when we were traveling. So, she is typically behind me covering my back but as I mentioned she is not afraid to take charge.

The only problem with my commander is that she suffers a nasty case of PTSD, which causes her to panic when there is a thunderstorm in the air. As soon as the clouds start to form, she gets nervous, and when it starts rumbling she is in a pretty bad shape. Her matron actually has her on drugs when this happens. I guess that happens when you have been deployed in action for too long.

Well, this is enough for now as I see my master just entering the driveway and I he does not appreciate me typing on his keyboard. I need to keep him as a friend as I don’t want to end up in the doghouse.

Signing off, Sajiv, SOIC (security officer in command), OTech Inc.

HIMSS2012: An EHR without a HIE: Useless.

View at the infamous strip

The most important message that I took away from this year’s HIMSS meeting, amid all of the meaningful use and ICD-10 clutter, was that a EMR (or EHR) without a mechanism to share this electronic information through a Health Information Exchange (HIE), which used to be called Regional Health Information Organization (RHIO), is pretty much useless.

Yes, having an electronic equivalent of a paper chart provides the potential for decision support rules, drug-drug and drug-allergy interaction alerts, and can facilitate electronic exchange with labs, but the major benefit and potential savings comes only when information is going to be freely shared between different organizations, primary care physicians and specialists, and other healthcare providers.

A provider typically knows what drugs patients are on, and has their lab results, but what about the prescription that was written a week prior by a ER physician, or a month ago by a cardiologist? Only the exchange of this information among the different healthcare providers using some type of interchange will achieve the full potential of electronic health records.

The implementation of HIE’s is still very much in its infancy. Several speakers at this year’s HIMSS reported that there are more than 400 in place in the USA, of which about 50 percent are in the private domain, but many states have not even begun implementation. One of the issues is that, yes, there are standards in places defined by HIE on how the information to be exchanged should be encoded, but there are still too many options, different encoding possibilities and a lack of agreement on what information should be structured and how.

Exchanging information is only part of the challenge, however, another problem is that we don’t want a human person involved in  interpreting this information; rather we want the appropriate data to be interpreted, imported and integrated automatically with the local EMR.

As reported at the conference, the New York e-Health cooperative has put a stake in the ground to address this issue. Their objective is to literally create a “plug and play” connection between an EHR and HIE through the definition of requirements for patient record exchanges, patient data inquiries and exchanging clinical care documents. In the meantime, the joint interoperability work group has been expanded to date to include 14 EHR vendors, 12 HIE vendors and eight states, California, Colorado, Illinois, Kentucky, Maryland, New York, Oregon, Utah and Vermont, representing 40 percent of the US population.

Important for this activity is the alignment with the Regional Extension Center (REC) program for compliance testing and to promote those vendors that support the requirements.

The intention of this working group is to work closely with the HL7 organization so that there is a place to support and maintain this profile and allow wider implementation on a global level. In the meantime, the specifications are available on the working group website at www.interopwg.org.

In conclusion, HIE connectivity is critical for EHR implementation, and this working group activity will go a long way towards achieving that.

HIMSS2012: The Blue Man’s Group or yet another IHE Showcase?

Decisions, decisions: should I go to a vendor reception, or attend a show? Should I lose a couple more quarters in a slot machine, or attend an important lecture? Should I spend a few dollars at the casino with a chance to win a brand new car, or collect some more give-aways from vendors at their booths?  There sure are plenty of distractions when a trade show is held in Vegas. One cannot get to the conference without passing through many slot machines surrounded by a lot of cigarette- and cigar- smoking gamblers. The good news is that, if you actually show up for a presentation, you automatically earn recognition for not being weak of heart and for being really motivated to be there.

One of the best parts of HIMSS is the so-called IHE connectivity showcases. It allows one to peek a little bit into the future and see how it could potentially work, assuming all vendors start to implement these profiles defined by IHE, which are based on open standards such as DICOM and HL7. It is almost a repeat of the connectathon in early January (see ….) where hundreds of engineers test their interconnectivity with each other in a test environment. However, this demonstration puts real use cases to the test and the vendors put their best efforts forward to demonstrate their systems in a real-world environment.

One of my favorite use cases is the Transitions of Care Demonstration. Its core is a traditional scheduled workflow profile for radiology whereby an order is placed, exam is conducted and a report is generated, but then the demonstration is extended to before and after this event to show how many organizations can hand off the information in a standard manner. It spans three domains, the Patient Care Coordination, Patient Care Device and Radiology Domain, which are tied together with the transactions defined by the infrastructure domain. In the first step a patient is referred to an emergency department by a primary care physician. An HL7 version 3 CDA document, which is the standard “referral summary,” is exchanged with the hospital using a registry and patient information exchange server, typically implemented as a regional Healthcare Information Exchange (HIE). At the emergency department, the patient care device profiles are used to exchange several measurements such as vitals, which are automatically captured from the electronic devices and interfaced with the EMR to update the information. An X-ray is ordered and, following the traditional radiology scheduled workflow profile, the results and images are exchanged.

After this episode, it gets even more interesting as our virtual patient is put on an infusion pump, and is continuously monitored. A simulated alarm causes the physician to adjust the patient’s medication. Again, the alarms are exchanged using the defined profiles so that in this case this information is exchanged between and through five different vendors. After the patient condition is stabilized, he is discharged and a summary report is exchanged with his cardiologist for follow up.

demo of patient care device interopratbility at IHE show case

This demonstration seems simple, but it included interactions between 13 different vendors, and it all worked seamlessly, which is a major accomplishment. In practice, institutions barely get three or at most four systems to work together.

If you were at HIMSS, I surely hope you were able to make it to the connectathon and catch a glimpse of what hopefully is a not too distant future. It really is amazing to see what can be achieved by systems working together seamlessly as a result of open standards.

PACS 2.0 through IHE workflow implementations.



View from the deck of the MedWEB training facility



OTech delivered its first week of IHE training high in the Sierra Nevada Mountains, minutes from Lake Tahoe and major ski resorts, in the brand-new MedWeb training facility during the first week of February. Why is proper IHE implementation so critical? Based on my observations, feedback from our students, and polls from our newsletter, I estimate that the majority of the current PACS implementations in the US run at half-speed. They are based on 20^th century connectivity technology and have not made the jump to implement the many IHE profiles that have become available since the early 21^st century. They implement HL7 standards to exchange orders that result in a DICOM worklist, use DICOM to exchange images and allow modalities and third party workstations to query and retrieve the PACS archive. This is where it stops. They might have an API interface to allow a HIS or EMR to launch a window for image viewing, but require the use of their own, proprietary viewer.

Just implementing the IHE scheduled workflow profile alone could result in a significant improvement in efficiency, major reductions in potentially lost images or studies, and reduced turn-around times for procedures. Let’s look at the MPPS or Modality Performed Procedure Step. While most modality vendors have long ago implemented this DICOM service, there are still major PACS and RIS vendors that have not yet implemented MPPS.

The MPPS is an automatically issued transaction from the modality that signals when a procedure has started, completed or canceled, indicates the number of images and other objects such as presentation states or measurements that are generated, and it provides any order changes and updates to both the PACS and RIS.  When properly implemented, the modality worklist is automatically updated as soon as the study is started, and the finished procedure is immediately added to the radiologist workstation worklist and changes in the procedure are automatically updated in the RIS. Without MPPS, a technologist might have to complete or “verify” the study at the PACS and RIS, and there is a chance that a radiologist could start reporting on an incomplete procedure or wait unnecessarily to begin reporting.

Another major component of the scheduled workflow profile is the so-called STC or Storage Commitment, which is the hand-shake between a modality and short-term archive. It can also be used as a handshake between a short- and long-term archive, which can be hosted on-site or in a cloud. As more and more systems deploy enterprise archiving solutions and off-site storage, this is a critical transaction.

The best known IHE profile is the PDI or Portable Data for Imaging, which specifies how to store images on a CD so that they can be read by another institution and imported into their PACS. Unfortunately, there are still institutions that create proprietary CD’s, which cause unwarranted charges that “DICOM does not work,” when the real culprits are institutions and PACS vendors that simply do not follow the rules.

These are just two of the most popular profiles, there are many more that can have an impact on daily workflow, or emerge when an archive is migrated to a new version or vendor, and suddenly all of the image overlays have disappeared or when deleted images suddenly re-appear.

Why is it that these IHE services are so under-utilized and poorly implemented?  First of all, there are still PACS vendors who are lagging with the implementation of these profiles. Second, there is a still a major lack of knowledge among the user community about the “hidden” capabilities in their systems. When talking with the service engineers that install modalities, I find that they often do not install the advanced features because the user does not request them, or it is too much work to get a service representative for the PACS system to come out to configure, test and verify that it is working, or it is improperly configured. As one PACS administrator told me, “It was not worth the hassle therefore I turned it off”.



View at lake Donner,  a couple of
 miles from the training facility



With regard to training, MedWeb has taken the initiative and started to offer training on the subject of IHE in partnership with OTech in their brand new facility in the High Sierra Nevada. In this state-of-the-art training center, students can enjoy the environment, and, if they wish, even get in a ski run or two in the early morning prior to the class.



if you are interested in scheduling intensive hands-on training loaded with practical exercises using the in-house computer lab and virtual PACS environment, contact OTech at [email protected].  With more people trained in proper IHE implementation, we will achieve a better understanding of the IHE advantages and a more widespread implementation that will result in proper implementation and higher efficiency.

HL7 working group meeting San Antonio: CDA rocks!

San Antonio is fun to stroll at night

The HL7 crowd of 350+ people took over the city of San Antonio this January to find refuge from the snow, ice or cold weather that many experienced in their hometowns in order to enjoy a margarita or beer while dining outside on the river walk. The working group meetings are well attended. Many of the attendees come to get educated on the latest HL7 standard developments while others come to work on refining and expanding the standards themselves.

This is an exciting time to be involved with healthcare IT as there is a major push to implement electronic health records in the USA and many other countries around the world, which will allow the exchange of information among providers using open standards. The HL7 organization is responding to this need by promising to act swiftly, and develop new standards in record time, while at the same time consolidating and “freezing” existing standards, such as the CDA (Clinical Document Architecture), for the past 7 years  so that those implementing the new standards have enough time to incorporate them into their work flow  without having to make frequent updates. Although there is a version 3 of the CDA in the works, version 2 has been around for several years and successfully implemented by many users.

The existing version 2 of the HL7 messaging standard is very entrenched in many healthcare institutions, especially in the USA but also in many other countries. Even though there has been a more advanced version 3 available for at least 10 years, the protocol implementation has been spotty at best. Some countries, notably Norway and a few others have successfully implemented it, but others have failed for a variety of reasons. One of the “problems” with upgrading from V2 to V3 is that the protocol is much more verbose as it is encoded in XML and therefore puts a strain on existing infrastructure. In addition, V2 is quite robust, reducing the motivation to replace something that works well with another version until there is a demonstrated major return on investment and/or benefit in additional functionality. As a matter of fact, one of the gradual implementations of new CDA documents is the ability to add it as a payload in a V2 message.

Unlike the spotty implementation of the HL7 version 3 protocol, there is no question that the CDA implementations are going to be very successful. The CCD profiles as part of the CDA, allow for automatic extraction of information from an electronic health record into an electronic document. As more of the CDA content begins to contain structured information and coded entries, it will also become easier to import this information into a record. A typical healthcare institution might handle upwards to 10,000 documents per week, as a matter of fact, for the Mayo Clinic in Rochester, this number exceeds 50,000, which is 2.5 million documents per year. Imagine the enormous amount of clinical information that will be available that could be used to improve quality of care, outcomes, efficiency, and decision support rules, when all these documents are encoded in some form or another. It is no wonder that the major institutions such as Kaiser, and the Mayo Clinic are active participants in the HL7 standard generation process.

However, one should not think that all of the documents are going to contain structured blocks of information and codes. There is a transition from totally free text, as is defined for CDA release 1, to some of the encoding, as required for CDA release 2, to more strict enforcement in CDA release 3. However, experts seem to agree that even with release 3, there will still be 10 percent of the context that requires free text. Each subsequent release will be a little bit better, but a lot also depends on the work on vocabularies and codes themselves to make sure that different contexts can be expressed well.

In addition, we need improvements in Natural Language Processing (NLP) to automate some of these tasks. One should also keep in mind that generating these structured documents also should not take much more time for a healthcare practitioner. I know from my own experience that many practitioners are holding off implementing electronic records because of the additional time and effort it takes due to unfriendly user- interfaces and limited data entry capabilities. In my own experience, when looking at many different implementations during the annual Connectathon while trying to find, let’s say a patient allergy, in some cases I could spot it immediately, in other cases, it took a while and scrolling down a window to actually find that information. Some style sheets that vendors use to display the documents are totally arbitrary and do not make intuitive sense. They mix up headings that deal with past, current history and treatment plan. A lot of work still needs to be done on usability and user friendliness.

Coming back to the HL7 working group meeting, the electronic document standardization effort in the form of the CDA in my opinion is the most significant development, and combined with the HL7 functional specifications of electronic health records will definitely impact healthcare in a major way. It is exciting to see all this activity going on firsthand and I encourage you to participate and/or join this important effort (see www.hl7.org for more information).

IHE Connectathon Chicago: More participation than ever!



view off the test "floor"



The USA IHE Connectathon has become a big operation as 453 of engineers from all over the world settle down at the downtown Chicago Hyatt to test their software and device simulators (169 this year) against each other for compliance with any of the IHE defined profiles. This year’s compliance team was comprised of 55 people serving as “monitors” to check off 4572 test requirements for these profiles. Some of these tests are relatively simple to check, such as the validation of a clinical document to make sure it contains all of the required sections and data elements, but some of them require the participation of several actors as part of the test, which makes it somewhat hard to coordinate. While participating in this event represents a major investment for the participating companies in preparation, travel, personnel and allocated resources, the benefit is clear, there is no better place to do interoperability testing than in Chicago, on neutral territory with all engineering resources right there instead of in a clinical environment.



Participating as a monitor is a gratifying job, not only because one meets many new people in this domain, but also as there is no better way to learn about the implementation of standards than to see it actually work, or fail for that matter. The participants have plenty of opportunity to test prior to submitting a test for verification by one of the monitors, and most of them do so diligently, but in my experience one out of ten participants still fail to meet the test criteria and have to go back to the drawing board. There are also participants who drop out of particular scenarios because of the problems they are having.



The certification process itself is highly automated. Participating vendors can access the test requirements from an on-line source and schedule their tests with peers. Most peer-to-peer tests require a vendor to interface with three others and they are not allowed pick their peers from their own company. A monitor will access their worklist, which shows only the tests that they are assigned to, depending on the domain, and finds the location of the vendor who submitted the test to be verified. The test is demonstrated and after successfully completed, the vendor brings up the test again from a worklist, which has a QR code that allows the monitor to pull up this test at his or her tablet PC or smart phone and change its status to pass, fail or partially completed. An example of using the partially completed status occurs when a document consumer requests a certain form from a manager, fills it in, and forwards it to a repository. At this point the test status is marked partially completed. I would then have the vendor fill in certain fields and then go on to the receiver to check to see that the modified data elements were transmitted. If correct I would then set the status of the test to “pass”.



While verifying these tests, it is almost mind boggling to contemplate the many possibilities for improving healthcare delivery once all of these standards are implemented. The ability to exchange information from one’s personal health record into your physician’s electronic health record alone will eliminate all those lengthy questionnaires every time one visits another physician, and that only scratches the surface. The exchange of drug and allergy information, submission of clinical information in standard forms to agencies that are involved with population health will allow quality measures to be implemented, and so on; the sky is the limit.



Many standards that benefit efficient and more effective patient care have been developed in the past, and implementation has been patchy, for many reasons. One reason is that there is not always enough incentives for vendors to open up their architecture and allow others to seamlessly integrate and exchange information in a standard manner. Connectivity is in many cases on the bottom of the list of improvements. Hopefully this will change with the requirements to implement electronic health records in a meaningful manner in the USA, making many of the possibilities that could be glimpsed at Connectathon will be rolled out in commercial products soon.



Connectathon 2012 was another excellent event showing the great potential and opportunity for vendors to profit by implementing these new standards and to have a positive impact on patient care. Events like this can only increase the pressure on the vendors to roll out products and releases as soon as possible as more of them compete to reap the rewards that come with successfully implementing the IHE profiles.

Tips from a road warrior (20): Have a backup for your back-up!

As travel is often unpredictable, it is important to have a back-up plan, and even a back-up back-up plan in case the first back-up does not work out. I have had several cancelations late at night, or arrived after midnight in a deserted airport where all connecting flights have departed. I have been fortunate to never have to overnight at an airport, although I have come close. If your back-up plan for being stuck at the airport is getting a hotel booked by the carrier, here is some advice; don’t.

First you have to wait in line for at least a half hour to get a voucher, then wait another half hour for a bus that has to be chartered, then stand in another half hour line to check in with a night clerk at the hotel. When you finally arrive in your hotel room at about 2 a.m., you realize that the airline has booked you on the first flight out, which leaves at 6 am. You might have 2 hours of sleep. A better back-up is to call your travel agent right away, get a room, and a cab so you’ll be taken care of in half an hour.

I have observed a couple of incidents where hospitals did not have a back-up of their back-up. I have heard first-hand stories of IT professionals who after Katrina had to go into the hospitals when the flood water receded to find the back-up in storage cabinets. A perfect example where an additional back-up somewhere in the cloud would have helped. There are also some files that typically were not backed up or had been forgotten that would have proven invaluable had there been a back-up.

As and example, radiologists often go to great length to specify how they want their images to come up on screen. They specify their preferences with regard to their window/width and level settings, and how to configure their work lists. Not backing up this information will create a lot of additional work and aggravation in case the data is lost or corrupted. Another data set that might get overlooked are “deleted” images. When discussing this with one particular PACS administrator, he mentioned that in several instances, after he was told to delete a case, he was asked to undelete it. As a result he developed a back-up plan. He basically created a special library for these deleted images, similar to the “trashcan” you find on your computer desktop and made sure he never deleted that.

Audit trails are another important set of files that should not be deleted. These files have been required by HIPAA regulations and need to be accessible in case there is a question of whether certain patient information and/or images were accessed by healthcare practitioners. Teaching files are also important to make sure that they are kept safely. In many cases, PACS systems are not geared towards creating and maintaining teaching files, as these are studies that need to be indexed based on diagnosis and/or diseases. Additional keywords need to be added that can be used to search and categorize, which is something that is clearly addressed with the IHE teaching file profile but is not widely supported. This results in institutions maintaining their own separate teaching file repositories, which become important pieces of intellectual property that can be costly to recreate should it be destroyed by unforeseen events and the back-up fails.

One last item that is often overlooked is the calibration records of the diagnostic monitors. I have talked with a PACS administrator who was asked to provide the detailed record of a particular monitor, which was used to make a diagnosis more than two years prior as the diagnosis was disputed in court as part of a malpractice suit.

In conclusion, back-ups are part of our daily lives, and just as we make sure we have alternate plans in place when traveling, we need to have back-up plans in place when the unexpected occurs. Make sure you have a back-up plan, and a plan for when the back-up does not work, and consider back-ups for areas that you might otherwise overlook.