Friday, September 21, 2012

Learn about EMR’s in the Sierras!


OTech is introducing its first Enterprise Architect training for experienced healthcare imaging and IT professionals. PACS administrators and other IT professionals who are looking to advance their careers into an enterprise level position, will gain an in-depth understanding of Electronic Health Records. The training is based on the requirements for Certified Healthcare Enterprise Architects (CHEA), which is the capstone certification for those professionals who are either CIIP or PARCA certified. The certification exam fee is included in this training. For those who don’t need the training, however, there will be certification of participation, which can be credited towards continuing PARCA and/or CIIP certification.

The two-day curriculum includes EHR architecture and its components. It will focus on interface standards such as DICOM and HL7, with special emphasis on the new Version 3 standard (CDA) as well as IHE. Imaging is a major component of the training, especially on how to image-enable an EMR for multiple imaging specialties. There is also a hands-on component following orders through acquisition and results in the form of CDA documents.

The location is at the brand-new training (residential) facility and resort in Truckee, CA, in the Sierra Nevada Mountain range, which is less than one hour from Reno and/or Lake Tahoe. The dates are Oct. 17 and 18. Participation is limited to maximize the learning experience. For more information, see our on-line schedule.

Tuesday, September 18, 2012

PACS SA’s jumping ship to the vendor side?


PACS Administrator Career series (Part 2): PACS SA career opportunities with imaging vendors.
It is not uncommon for a PACS System Administrator (SA) to “jump ship” to the vendor side. Many PACS SA’s might be considering making this career move, so I interviewed John Evers, the “infamous” author of the “Day in the life of a PACS administrator,” which went viral on YouTube. John is a good example of a PACS SA who has seen both sides of the fence as he has worked in several positions on the user and vendor sides. In addition, John also has a good mix of clinical and IT education and experience and I believe he can be considered one of the relatively few truly seasoned PACS administrators. (The information below is the “short” version as the full interview that can be seen on YouTube).
I first would like to describe the various career options and list the most common positions with a vendor that a PACS SA typically is hired into. Outside the hospital setting, there are typically two options, the first is working as a PACS SA consultant either for a consulting firm, or as an independent consultant. The second option is working for a PACS vendor, which typically involves one of the following positions:
  • PACS administrator: PACS vendors sometimes provide a PACS SA for their clients as a consultant, typically for the duration of a new PACS implementation.
  • Project manager: A new installation typically gets a project manager assigned by the vendor who coordinates the installation, training and acceptance. A typical project manager would manage many projects simultaneously for several clients.
  • Technical sales support: Sales staffs typically do not have the technical skills to be able to work with a sales prospect, something that an experienced PACS SAs are able to provide.
  • Application training: This is probably the most common position. As a PACS SA is intimately familiar with a specific vendor product, he or she is very well suited to train others on the system, how to use it, configure it and provide support for it.
  • Service Support: This is for the more technical SA’s who are able to troubleshoot and resolve issues at the customer site.
Now the interview with John Evers:

Herman O.: How did you get involved in PACS?
John E.: I started out on the vendor side with Bennett X-ray, and then moved to servicing MRI’s. That  led to a career as a MRI technologist, which allowed me to learn the clinical side. PACS then became a natural fit as I have both clinical and IT background.

Herman O.: What is your opinion on whether it is better to have a clinical or IT background?
John E.: I think you definitely need both, but probably a little bit more IT than clinical skills. I know SA’s who have come from both sides of the fence that have become great at what they do.

Herman O.: Where do you think the PACS SA profession will in the next five years?
John E.: Two of the biggest changes have been the need to have a detailed knowledge about networking, and a greater understanding of the role of storage as the number of images increases. Related to that is knowledge of the role of Vendor Neutral Archiving. As an example, back-ups used to take a few hours and now might take a day.

Herman O.: What about availability of tools? For example Wireshark?
John E.: Yes, there are many open source tools now available for a SA and the vendors have built in more and better tools.

Herman O.: What is the main difference between working for a vendor or user?
John E.: One of the biggest differences is working with physicians in a hospital, as a vendor you work more with the SA’s and administrators. I believe that the PACS SA is a more challenging job as there is a larger variety of equipment, and it is definitely less boring. Although I poke fun at doctors in my video, I have been fortunate to have really great relationships with doctors.

Herman O.: Is it more of an 8 to 5 job with a vendor?
John E.: It depends on the size of the institution you are supporting, but I found the level of calls to be about the same, so that would not necessarily change when switching your career.

Herman O.: What about the career paths and opportunities working on either side?
John E.:  I definitely think that anyone who is a good SA can move to the vendor side. However, many vendors are trying to stay away from hiring from their clients. The same is not true for the opposite side; hospitals like to hire vendor service personnel. Salary wise, you are probably better off working for a vendor. I know several PACS SA’s who are definitely not paid what they are worth. In general, I believe that the potential for earning more is with the vendor, the potential for learning more is with a hospital. There is a chance that you get pigeon-holed on the vendor side, but there are more career opportunities for sure; you have a better growth path.

Herman O.: What about travel?
John E.: As a PACS admin, I had to take a lot of classes requiring travel, and as a vendor there are installs to take care of, so there is probably a little bit more travel on the vendor side. But, there are more opportunities to work from your home on the vendor side, something that could be beneficial as well, depending on the situation, although working from home you miss the social interaction with co-workers.

Herman O.: Any final concluding remarks?
John E.: There are definitely opportunities on both sides, and if you are interested in working for a vendor, there are definitely openings, especially if you are well-rounded. However, remember it might be a little bit harder to work for the same vendor as the PACS system you are supporting.




Tuesday, September 4, 2012

Ready to throw out your RIS/PACS vendor: prevent the same mistakes.

18% of the users are ready
to throw out their system

Our newsletter poll showed that 18 percent of current PACS users are unhappy with the current vendor and another 18 percent is very frustrated, which could be a good reason to consider switching vendors. It is therefore critical to practice what we have learned during the first set of implementations, which allows us to be better prepared for the selection process and hopefully result in selecting a vendor we can embrace and be happy with. Even if you do not intend to switch your vendor, these recommendations might assist you to be better prepared for a new system from the same vendor.
Here are 12 critical items to consider during the selection and preparation process (note that his blog is a companion of the Youtube series on this subject):

1.       Collect extensive data from current users.  
Organizing a workshop is a great way to gather input. In the ones I have participated in, we would typically spend an afternoon and create groups of multi-functional teams consisting of physicians, radiologists, IT, technologists, support, service, biomed, and administration. It is important to appoint a “scribe” for each team, and have him or her list the top three items that are most annoying and, or time consuming, and list the top three items that are most valuable, and finally, list 10 functions or features that one couldn’t do without. At the end of the meeting aggregate all the lists and prioritize them with the whole group, as well as publish the results for those who couldn’t participate, and ask for comments.

2.       Re-engineer the workflow and review procedures.
It is a good idea to document the current workflow and perform a thorough analysis taking in to consideration the flow of a patient, physician, radiologist, images, reports, and any other people or systems who are involved with the process. This information would be benchmarked against current requirements for throughput, turnaround time, etc. and desired key indicators. The key indicators should be prioritized, for example, for an ER it could be efficiency, patient wait time, physician turn-around, etc. For the ICU, or main radiology it would be different. One should find out whether there are limitations in current production that dictate certain workflows, and review policies and procedures and challenge them; note that policies have a lot of details on down-time procedures, back-ups, etc. and it is a good opportunity to review those.

3.       Re-evaluate external data import and export rules.
The input and output of clinical data is often a bottleneck, such as where are CDs created, and should this activity be centralized in the file room, for example, or decentralized in each department or location. The same applies for the rules for importing data on CDs, who does it, where is it done, how is the information reconciled with potential existing patient records,  where is it going to be stored, in the archive, local cache or only the workstation to be pulled up for comparison? Another increasing issue is the electronic connection.  How do you deal with electronic data transfer from an IDN, PHR, other HIEs which are being established. Remember, never ever import any information without checking and determining potential reconciliation issues.

4.       Anticipate hardware and software changes.
There will be regular software updates and changes, how are these covered and anticipated? Such changes as higher resolution and increased data output from modalities, and new standard extensions defined by IHE and DICOM could impact performance and require upgrades. It is almost certain that new computer hardware and CPU memory requirements will have to be addressed during the life of the PACS, as well as upgraded disk capacities, new OS upgrades and database upgrades. Remember never to buy too much storage capacity as the price will drop and capacity will probably double for the same enclosure on an annual basis.

5.       Create a “sensible” RFP and write a better contract.
An RFP should neither be too long nor too short; I have seen RFPs that are 500 pages and some that were 25. I suggest RFPs should be less than 100 for a typical facility. Don’t ask a vendor to specify hardware specs for “commodity” components such as monitors, as these are pretty much all from the same manufacturer anyway, but, rather focus on application level functionality. Focus on workflow and integration requirements. Review contracts and address any disputes and, or issues that come up, and most importantly, have it reviewed by a consultant in addition to a lawyer. Include an arbitration clause, and I include a money back guarantee in case of non-performance, but make sure you state performance requirements clearly. Also, make sure you address upgrades and extensions to make sure that there are no extra charges for that.

6.       Include a complete test system.
A test system should include a RIS simulator and the capability to create test transactions, a test broker/worklist provider and set it up to provide a test worklist for demos, as well as a test PACS server with a capacity of a few days to a week (poll users for what is an acceptable test capacity). Make sure the system always provides a dual path for reports and image access, e.g. from a web server independent from the PACS (in case the PACS is down). Test and simulate modalities, using test images which are available from IHE “Connectathon” activities as well as, AAPM to test imaging pipeline, calibration, and performance. Your test system should also have network sniffer capability and validation tools loaded, as well as network monitoring tools.

7.       Look at alternate service agreements.
Consider in-house support versus outsourcing, or third party service providers. Also consider an arrangement of time and or materials versus full warranty. It is important to bundle training and negotiate this line item. Going forward, clearly specify what responsibilities the various departments including IT, biomed, RIS support and PACS support, have, and clearly specify the boundaries. For example, spell out who addresses the work list being down, the RIS or PACS support person? It is important to specify and include every detail, for example, who is calibrating the monitors (automated, manual, biomed, PACS administration, etc.), who is vacuuming the computers, air filters, who is cleaning the CR cassettes, who is clearing the CR plate jams, and many more.

8.       Consider a VNA or cloud service for your archive.
Based on another recent OTech newsletter poll, we found that 50 percent of our readers are considering “Vendor Neutral” archiving. However, there is no uniform agreed upon definition of the VNA, therefore, be very specific in the specification of YOUR level of integration (see resources). Weigh costs and requirements of the VNA against the strategic importance of keeping your data “close to your chest.” Develop a roadmap for integrating the other specialties and “ologies”– work with an institution-wide task group to see whether there are economies of scale that can be achieved by incorporating more parts of the enterprise.

9.       Consider pay for service.
One might consider archiving all of the images and related information to the cloud, or only archiving externally for backup and disaster recovery. An important factor to consider is the tradeoff between the cost of capital vs operations cost. Look at the potential risk of outsourcing, even systems of giants such as Amazon and Sony have been known to go down, and closer to home, Cerner had a serious downtime period as well. There is always a risk of hackers or simply infrastructure issues caused by a construction crew cutting a fiber communication connection somewhere. Another important consideration is how the cloud fits within the IDN/RHIO/HIE and NHIN strategy. Most institutions have almost no choice as they might have an internal skill set limitation and availability issues, but if not, this could also be a consideration.

10.   Perform a risk analysis.
Look at workflow bottlenecks for physicians, radiologists, technologists, patients, PACS/RIS administrators, service, IT and determine security and privacy risks. Walk as a patient would walk, and find if there is any potential security cracks allowing access and visibility to information that should be private. Evaluate audit trails, what is their accessibility, level of detail, and security, as well as standards support, or is it a proprietary vendor-specific format that is hard to access and report from. Re-evaluate back-ups, disaster recovery, redundancy, and business continuity and determine the money the enterprise is willing to spend to prevent every additional potential minute of downtime. Remember, the more redundancy, the more expensive it is. Implement patient safety rules and checks, and establish an overall quality improvement plan including several QA steps.

11.   Create a detailed acceptance test procedure.
Make the acceptance test part of the contract and tie compliance to payment and penalties. Always modify and customize the “standard” acceptance test provided by the vendor. Preferably, let the acceptance test be performed by an independent party or consultant, or, if that is not possible, get volunteers from other departments who are not familiar with your flow and are preferably unbiased to execute them. Create detailed scenarios to include patient admission, the performance of tests, etc. Cover all exception scenarios such as, but not limited to, merging patient, exam merge, append, delete, update patients. Make sure you cover all modalities, specialties and departments.

12.   Anticipate future standards updates.
New DICOM extensions need to be planned for covering new modalities, services, and structured report templates. For example, IVUS was a not around five years ago and many PACS systems have been, and are still struggling, to facilitate that. There will be new HL7 extensions and new versions, as well as IHE extensions. New scenarios for different specialties will be covered by IHE and new and updated exchange standards such as PIX and PDQ will be introduced. There will be new document standards covered by XDS, XDS-I, and CDA. I strongly recommend that the vendor be required to support any new standards up to a specified date after a particular release date (for example three years), preferably at no charge or as part of the normal service agreement.

In conclusion, whether or not you are looking for a different vendor, or planning to stay with the same vendor, apply lessons learned as mentioned above and you’ll be guaranteed to be better prepared for the transition to a new system and end up happier with your vendor than you might be today.