For me, the Radiological Society of North America (RSNA) annual conference begins at the airport in Dallas. I always run into a group of folks from our industry catching Chicago-bound flights to attend the same meeting as me. Some people complain about RSNA, but I love it. It's great to catch up on who is doing what and where they're doing it, as well as reconnecting with old friends and making new ones.
Our industry is a relatively small one, with only about 700 or so companies exhibiting at RSNA each year. It's always interesting to me who is working for whom, as people tend to move around among different vendors every few years or so. I'm probably somewhat of an exception, having only worked for two firms (Philips Healthcare and Carestream-back when it was still owned by Eastman Kodak) prior to starting OTech.
Another thing I find fascinating about RSNA is the use of the latest buzz words at the meeting. For example, what exactly does cloud storage mean? What are the requirements? What are the advantages? For medical imaging, what sense does it make to have a cloud storage solution that archives images in a non-DICOM format? Or to offer a solution that does not have any real life-cycle management?
Another of the favorite buzz words being bandied about is dose reporting. Please explain what sense is there in designing a CT system with a dose report that consists of a screen-saved DICOM image? Unless, of course, you're looking forward to buying sophisticated optical character recognition software and paying someone to validate its output for every image/exam/study in order to put patient dose information into a shareable, electronic format.
My current favorite is Vendor Neutral Archive. Unfortunately, most of the offerings that use this label are not capable of archiving MPEG's, documents, or the new CDA and CCR longitudinal records.
I long ago learned to document my requirements, check out a product's specifications, and see if it met my needs. Buzz words are great for catching your attention, but that's about all they're useful for accomplishing.
And never use buzz words in an RFP. If you ask for a vendor neutral archive, or dose reporting, or cloud storage—you're going to get a Yes. Specify precisely how you want to use these devices, with exact requirements, and extensive technical detail. For example, storing dose reports should be done using DICOM Structured Reports, according to the most current radiation exposure monitoring profile.
Sifting through the hype, peering through the smoke, and looking behind the mirrors is part of the fun of attending the RSNA meeting. Make sure that when it comes time to add a new system or piece of equipment to your practice, you don't get buzz sawed by buzz words.
Wednesday, December 1, 2010
Meaningful Use or Mis-Use for Radiology?
If you scan all the marketing materials, press releases, and announcements of healthcare device and IT companies, the term Meaningful Use (MU) would be one of the most used (followed closely by cloud storage, vendor neutral archive, and dose reduction). For obvious reasons, healthcare providers are rushing to implement Electronic Health Records (EHR) that comply with MU requirements in order way to receive a share of the multibillion dollar subsidy for these products from the American Recovery and Reinvestment Act. If they don't have a system in place, procedure reimbursement will be cut—so there's a strong incentive to implement an EHR.
As would be expected, creative marketing for these products has kicked into high gear, stretching the meaning of MU. Radiology, in particular, is difficult to define in terms of MU, at least in a first pass at the recent Phase 1 Rule on Medicare and Medicare EHR incentive payments.
What is the impact of MU on radiology? As a start, the word radiology appears only once in the entire Phase 1 Rule description, which doesn't give diagnostic imaging much to go on. The emphasis is on medication interactions, errors, and public health. Even the Phase 1 Rule requirement for Computerized Physician Order Entry (CPOE) does not include radiology tests.
What is puzzling is that radiology has led the way in the development and implementation of IT in healthcare. Digital imaging, PACS, voice recognition-based reporting have been mainstream technologies for radiology the past decade. As film has been phased out, so have errors due to missing, lost, or misplaced images. Turnaround times for reports have been slashed from a day or longer to less than an hour at many facilities. And teleradiology has permitted the expertise of specialty radiologists to be available in remote areas, and allowed all-day, every-day coverage at any facility.
This is not to say that there is not still work to be done. The integration among radiology, cardiology and other ologies is still in its infancy. Most radiology images are distributed via somewhat cumbersome API's in EMR’s. The implementation of images of for anyone everywhere at any time is still a challenge.
IHE has addressed integration by offering a set of standards that makes this available, and its 2010 Connectathon has shown that vendor implementation is feasible. Unfortunately, vendors typically don’t choose to voluntarily implement standards; they tend to be biased toward using proprietary solutions that lock users into their architecture and products. And this is where the Phase 1 Rule for MU could have drawn a line in the sand by mentioning some of these efforts.
The Medical Imaging and Technology Alliance (MITA), a lobbying organization for diagnostic imaging, attempted to bring this to the attention of the Dr. Blumenthal, the Director of the Office of the National Coordinator for Healthcare Information Technology (ONC) earlier this year--without any noticeable impact on the Phase 1 Rule.
So, where and how does the MU regulation address radiology? First, it shows up in the requirement to use a CPOE; however, for radiology this is probably not to be expected until the Phase 2 Rule. Second, drug-to-drug and drug-allergy checks are required, which impacts the modalities that use contrast agents.
DICOM has defined the capability for substance administration at a modality that allows queries for verification of the supplies to be used. There is an impact on the recording of certain demographic information, such as race and ethnicity, which might impact the data that will be sent to remote readers. Problem lists and diagnosis have to be encoded.
Also, patients will have to be provided with a copy of their health information, which is a somewhat regular practice as many patients currently are requesting a copy of their images on portable media. Eventually, this data will be automatically uploaded to their Personal Health Record (PHR). There are also privacy and security requirements to protect electronic health information, which is already addressed in radiology via the widespread implementation of audit trails in PACS.
It will be interesting to see what the Phase 2 and 3 MU ruling will say; hopefully radiology will be addressed in greater detail--in particular the requirement for interconnectivity standards, which are needed to make EHR’s that include imaging a success.
As would be expected, creative marketing for these products has kicked into high gear, stretching the meaning of MU. Radiology, in particular, is difficult to define in terms of MU, at least in a first pass at the recent Phase 1 Rule on Medicare and Medicare EHR incentive payments.
What is the impact of MU on radiology? As a start, the word radiology appears only once in the entire Phase 1 Rule description, which doesn't give diagnostic imaging much to go on. The emphasis is on medication interactions, errors, and public health. Even the Phase 1 Rule requirement for Computerized Physician Order Entry (CPOE) does not include radiology tests.
What is puzzling is that radiology has led the way in the development and implementation of IT in healthcare. Digital imaging, PACS, voice recognition-based reporting have been mainstream technologies for radiology the past decade. As film has been phased out, so have errors due to missing, lost, or misplaced images. Turnaround times for reports have been slashed from a day or longer to less than an hour at many facilities. And teleradiology has permitted the expertise of specialty radiologists to be available in remote areas, and allowed all-day, every-day coverage at any facility.
This is not to say that there is not still work to be done. The integration among radiology, cardiology and other ologies is still in its infancy. Most radiology images are distributed via somewhat cumbersome API's in EMR’s. The implementation of images of for anyone everywhere at any time is still a challenge.
IHE has addressed integration by offering a set of standards that makes this available, and its 2010 Connectathon has shown that vendor implementation is feasible. Unfortunately, vendors typically don’t choose to voluntarily implement standards; they tend to be biased toward using proprietary solutions that lock users into their architecture and products. And this is where the Phase 1 Rule for MU could have drawn a line in the sand by mentioning some of these efforts.
The Medical Imaging and Technology Alliance (MITA), a lobbying organization for diagnostic imaging, attempted to bring this to the attention of the Dr. Blumenthal, the Director of the Office of the National Coordinator for Healthcare Information Technology (ONC) earlier this year--without any noticeable impact on the Phase 1 Rule.
So, where and how does the MU regulation address radiology? First, it shows up in the requirement to use a CPOE; however, for radiology this is probably not to be expected until the Phase 2 Rule. Second, drug-to-drug and drug-allergy checks are required, which impacts the modalities that use contrast agents.
DICOM has defined the capability for substance administration at a modality that allows queries for verification of the supplies to be used. There is an impact on the recording of certain demographic information, such as race and ethnicity, which might impact the data that will be sent to remote readers. Problem lists and diagnosis have to be encoded.
Also, patients will have to be provided with a copy of their health information, which is a somewhat regular practice as many patients currently are requesting a copy of their images on portable media. Eventually, this data will be automatically uploaded to their Personal Health Record (PHR). There are also privacy and security requirements to protect electronic health information, which is already addressed in radiology via the widespread implementation of audit trails in PACS.
It will be interesting to see what the Phase 2 and 3 MU ruling will say; hopefully radiology will be addressed in greater detail--in particular the requirement for interconnectivity standards, which are needed to make EHR’s that include imaging a success.
Monday, November 1, 2010
Trails and Trials in HIPAA
The implementation of HIPAA's security and privacy requirements has resulted in nearly every U.S. PACS having an audit trail capability that records who, where, and when the system was accessed. These audit trails have not only helped ensure patient privacy and security, they also provide a practice with an independent record of its radiologists' patient access.
Although organizations such as the IHE have sought to standardize the protocol and format of HIPAA audit trails, vendors are free to implement the requirement as they see fit. The result has been mostly incompatible application among different systems; however, administrators have learned to live with the issue. Manufacturers have begun to make improvements in making audit trail information available in a more user-friendly format, and grass-root efforts at data mining by IT-savvy PACS administrators have helped to improve the situation.
On average, PACS administrators check their audit trails about once or twice a month--mostly to conduct a random check for unauthorized system access. These audit trail checks have uncovered the unauthorized access of patient records in several high-profile cases (typically celebrity patients), which resulted in disciplinary action against the transgressors.
In addition to recording unauthorized access, audit trails can also be used resolve questions of authorized access. For example, I have been contacted by legal representatives of parties that needed to prove a physician saw a medical file. In one case, a patient died because a serious condition was missed by a radiologist who disputed he had accessed the image; however, the log files in the audit trail were clear about his access.
Cases such as these are good arguments to use when trying to convince physicians never to share user names and passwords. When there is legal action, the implications of password sharing can become dramatic.
The logging of audit trails required by HIPAA not only maintains patient privacy and security, it also makes a radiologist's patient access clearly visible—which can help a practice determine who did what and when they did it.
Although organizations such as the IHE have sought to standardize the protocol and format of HIPAA audit trails, vendors are free to implement the requirement as they see fit. The result has been mostly incompatible application among different systems; however, administrators have learned to live with the issue. Manufacturers have begun to make improvements in making audit trail information available in a more user-friendly format, and grass-root efforts at data mining by IT-savvy PACS administrators have helped to improve the situation.
On average, PACS administrators check their audit trails about once or twice a month--mostly to conduct a random check for unauthorized system access. These audit trail checks have uncovered the unauthorized access of patient records in several high-profile cases (typically celebrity patients), which resulted in disciplinary action against the transgressors.
In addition to recording unauthorized access, audit trails can also be used resolve questions of authorized access. For example, I have been contacted by legal representatives of parties that needed to prove a physician saw a medical file. In one case, a patient died because a serious condition was missed by a radiologist who disputed he had accessed the image; however, the log files in the audit trail were clear about his access.
Cases such as these are good arguments to use when trying to convince physicians never to share user names and passwords. When there is legal action, the implications of password sharing can become dramatic.
The logging of audit trails required by HIPAA not only maintains patient privacy and security, it also makes a radiologist's patient access clearly visible—which can help a practice determine who did what and when they did it.
Implementing Dose Recording
As low as reasonably achievable (ALARA) is a radiation dose guideline that radiologists and technologists endeavor to achieve daily. In the majority of radiologic exams, this goal is met. In addition, ongoing diagnostic imaging research, more effective post-processing algorithms, and breakthroughs in modality manufacturing are all endeavoring to lower the radiation dose delivered to the patient.
When dose delivery goes wrong—someone gets hurt. Generally, when there is a dose accident it can be traced to a combination of human and mechanical/technological issues. For example, the recent publicity surrounding the hundreds of California patients overexposed due to the selection of incorrect CT imaging protocols.
Pediatric radiologists are particularly keen on using the lowest possible diagnostic dose for their imaging protocols. The Image Gently Alliance, which advocates for greater radiation safety in pediatric imaging, has received enthusiastic support from every radiological professional society.
In addition, there have been hearings in the U.S. Congress about the issue of dose reduction, as well as new legislation adopted by California requiring that patient radiation dose be recorded—all in an effort to minimize patient overexposure.
The medical imaging industry in the U.S. was caught off-guard by the dose recording requirement. However, most of Europe has already established standard dose recording terminology and methodology, so it would not be that difficult to adopt these applications. And new extensions to the DICOM standard—in the form of Structured Reports for dose recording—have recently been added. This means that there are no practical excuses for manufacturers to not implement patient dose recording in a standard manner.
One should note that there are alternative solutions to the DICOM Structured Report for recording dose information; however, the other options are either incomplete or do not allow for the information to be stored electronically. For example, the practice of displaying the information only on a user's screen is unacceptable beyond the immediate moment—the only mechanism to access this information electronically is by saving the screen and applying some type of optical character recognition (OCR) application in order to access the data.
Alternate solutions to record dose by using information in the DICOM header are also incomplete as they do not record the complete exam (not every X-ray exposure results in a saved image). The same argument (an incomplete record of total exposure) applies to the use of the optional recording of dose in DICOM's Modality Performed Procedure Step (MPPS).
Implementing new software additions, such as adding Dose Structured Reports to existing devices, is not a trivial task. There is at least a one-year lead time—which includes proper design, documentation, implementation, verification and testing, and a well organized roll-out and upgrade of the installed base. In addition to these challenges to the modification of deployed X-ray modalities, there is also an infrastructure question as to where and how dose information should be recorded and stored. Options are in the EMR, HIS, RIS, PACS, or a separate, dedicated dose recording device or software application. Also, should patient dose recording be done in a one-off, discrete manner on a per-exam basis? Or, should dose also be recorded and presented to the ordering and examining healthcare professionals on a cumulative basis?
There is no question that dose reporting is going to be a universal requirement for X-ray modalities. The imaging industry will have to gear up quickly to implement the new DICOM additions, and also come up with solutions to record and report this vital patient safety information.
When dose delivery goes wrong—someone gets hurt. Generally, when there is a dose accident it can be traced to a combination of human and mechanical/technological issues. For example, the recent publicity surrounding the hundreds of California patients overexposed due to the selection of incorrect CT imaging protocols.
Pediatric radiologists are particularly keen on using the lowest possible diagnostic dose for their imaging protocols. The Image Gently Alliance, which advocates for greater radiation safety in pediatric imaging, has received enthusiastic support from every radiological professional society.
In addition, there have been hearings in the U.S. Congress about the issue of dose reduction, as well as new legislation adopted by California requiring that patient radiation dose be recorded—all in an effort to minimize patient overexposure.
The medical imaging industry in the U.S. was caught off-guard by the dose recording requirement. However, most of Europe has already established standard dose recording terminology and methodology, so it would not be that difficult to adopt these applications. And new extensions to the DICOM standard—in the form of Structured Reports for dose recording—have recently been added. This means that there are no practical excuses for manufacturers to not implement patient dose recording in a standard manner.
One should note that there are alternative solutions to the DICOM Structured Report for recording dose information; however, the other options are either incomplete or do not allow for the information to be stored electronically. For example, the practice of displaying the information only on a user's screen is unacceptable beyond the immediate moment—the only mechanism to access this information electronically is by saving the screen and applying some type of optical character recognition (OCR) application in order to access the data.
Alternate solutions to record dose by using information in the DICOM header are also incomplete as they do not record the complete exam (not every X-ray exposure results in a saved image). The same argument (an incomplete record of total exposure) applies to the use of the optional recording of dose in DICOM's Modality Performed Procedure Step (MPPS).
Implementing new software additions, such as adding Dose Structured Reports to existing devices, is not a trivial task. There is at least a one-year lead time—which includes proper design, documentation, implementation, verification and testing, and a well organized roll-out and upgrade of the installed base. In addition to these challenges to the modification of deployed X-ray modalities, there is also an infrastructure question as to where and how dose information should be recorded and stored. Options are in the EMR, HIS, RIS, PACS, or a separate, dedicated dose recording device or software application. Also, should patient dose recording be done in a one-off, discrete manner on a per-exam basis? Or, should dose also be recorded and presented to the ordering and examining healthcare professionals on a cumulative basis?
There is no question that dose reporting is going to be a universal requirement for X-ray modalities. The imaging industry will have to gear up quickly to implement the new DICOM additions, and also come up with solutions to record and report this vital patient safety information.
Friday, October 1, 2010
Conforming DICOM Conformance Statements
I still come across very poorly written DICOM conformance statements. For example: Conformance statements from the major modality vendors are generally over 100 pages and can be up to 400 pages in length. On the other hand, there are some mid-level and smaller modality vendors that submit only 10 page documents. Although quantity does not always mean quality, it's a good bet that there is a lot left to the imagination of the user when they only have a 10-page DICOM conformance statement from which to work.
I believe the DICOM standard should specify, in detail, what elements belong in a conformance statement. Further, the standard should include boilerplate samples of what this might look like. In this way, there would be very little wiggle room for vendors to submit less-than-adequate conformance statements with their products. They would either be compliant with the DICOM standard conformance statement or they would not.
Having a complete conformance specification is your right as a consumer. For example, would you buy a car without knowing what type of engine was powering it? It might come in handy to know if it is oil cooled or water cooled, how many cylinders it has, what type of fuel it requires and so on. You probably wouldn't rely on the smiling salesman saying, "Trust me." So, doesn't it make sense to insist on the same level of information when buying a patient-critical medical device?
Another area the DICOM standard committee should take up is the publishing format of conformance statements. By requiring that all DICOM conformance statements be encoded in the XML format, it would allow for the easy comparison of comparability elements among various documents. For example, one could easily check among various CT offerings that they implement the enhanced CT multiframe SOP Class with a receiving PACS archive and workstation.
I know that some vendors have begun to encode their documents in XML, but a uniform standard would be helpful. In any case, the absence of a publishing standard still does not justify the wide variety and lack of detail in some vendors' DICOM conformance statements. I hope they read this column and take action.
I believe the DICOM standard should specify, in detail, what elements belong in a conformance statement. Further, the standard should include boilerplate samples of what this might look like. In this way, there would be very little wiggle room for vendors to submit less-than-adequate conformance statements with their products. They would either be compliant with the DICOM standard conformance statement or they would not.
Having a complete conformance specification is your right as a consumer. For example, would you buy a car without knowing what type of engine was powering it? It might come in handy to know if it is oil cooled or water cooled, how many cylinders it has, what type of fuel it requires and so on. You probably wouldn't rely on the smiling salesman saying, "Trust me." So, doesn't it make sense to insist on the same level of information when buying a patient-critical medical device?
Another area the DICOM standard committee should take up is the publishing format of conformance statements. By requiring that all DICOM conformance statements be encoded in the XML format, it would allow for the easy comparison of comparability elements among various documents. For example, one could easily check among various CT offerings that they implement the enhanced CT multiframe SOP Class with a receiving PACS archive and workstation.
I know that some vendors have begun to encode their documents in XML, but a uniform standard would be helpful. In any case, the absence of a publishing standard still does not justify the wide variety and lack of detail in some vendors' DICOM conformance statements. I hope they read this column and take action.
Is 'Meaningful Use' Making Imaging Meaningless?
The U.S. government is set to dole out billions of dollars to promote healthcare IT solutions that meet its Meaningful Use (MU) criteria. The Phase 1 requirements were published this past July and the Phase 2 requirements are expected to be available for public comment near the end of the year.
Most professionals working in medical imaging informatics, especially the radiology and cardiology area, were very surprised to notice the absence of PACS in the MU requirements. Also conspicuous by their absence was the mention of DICOM and HL7 as well as any of their corresponding IHE profile definitions. Interestingly, radiology is only mentioned in the context of orders; there is a mention about results (not the imaging, but merely the reports) in Phase 2.
This is very puzzling to me and many of my fellow imaging informatics professionals. The implementation of digital image communication, archiving, and display over the past 30 years has been a major, but seemingly, silent revolution. Our efforts have provided health professionals in remote areas of the world with instant access to experts, during practically any time of the day or night. When it comes to an electronic health record, it's obvious that having images available to any physician at any location will eliminate duplicate procedures—increasing patient safety AND significantly decreasing the cost of providing care—and allow the physician to make a fully informed decision about the patient's course of treatment.
The Medical Imaging and Technology Alliance (MITA), the medical imaging market's lobbying organization in Washington, D.C., has written letters to the Office of the National Coordinator for Health Information Technology (ONCHIT) about these issues—apparently to no avail (yet).
So, why the silent treatment from the federal government? Not including the more than three decades of work in medical imaging informatics into the MU criteria is foolish and wasteful—both to patient safety and to our healthcare economy. On a pragmatic level, by not including PACS in the MU criteria, federal stimulus funds will be unavailable to implement these systems and related technologies. This means that the small clinics that are still using film and processor technology will still be left on the digital imaging roadside.
One would be surprised how many of these facilities there still are. I recently visited one of these clinics, which only performed about 10 or so exams each day. They rely on an old processor and then have to digitize the films so they can be read in a hospital about 45 miles away. Imagine how much more efficient and economical a digital system would be—if they only had the initial capital needed to acquire one.
I hope that our professional organizations (such as RSNA, HIMSS, SIIM, ACR, ACC, and others) make a concerted and sustained effort to ensure that medical informatics takes its rightful place in the MU requirements, as Phase 2 are about to be defined. I also urge any and all of my fellow professionals to urge these organizations to lobby for our rightful place at the healthcare informatics table.
Most professionals working in medical imaging informatics, especially the radiology and cardiology area, were very surprised to notice the absence of PACS in the MU requirements. Also conspicuous by their absence was the mention of DICOM and HL7 as well as any of their corresponding IHE profile definitions. Interestingly, radiology is only mentioned in the context of orders; there is a mention about results (not the imaging, but merely the reports) in Phase 2.
This is very puzzling to me and many of my fellow imaging informatics professionals. The implementation of digital image communication, archiving, and display over the past 30 years has been a major, but seemingly, silent revolution. Our efforts have provided health professionals in remote areas of the world with instant access to experts, during practically any time of the day or night. When it comes to an electronic health record, it's obvious that having images available to any physician at any location will eliminate duplicate procedures—increasing patient safety AND significantly decreasing the cost of providing care—and allow the physician to make a fully informed decision about the patient's course of treatment.
The Medical Imaging and Technology Alliance (MITA), the medical imaging market's lobbying organization in Washington, D.C., has written letters to the Office of the National Coordinator for Health Information Technology (ONCHIT) about these issues—apparently to no avail (yet).
So, why the silent treatment from the federal government? Not including the more than three decades of work in medical imaging informatics into the MU criteria is foolish and wasteful—both to patient safety and to our healthcare economy. On a pragmatic level, by not including PACS in the MU criteria, federal stimulus funds will be unavailable to implement these systems and related technologies. This means that the small clinics that are still using film and processor technology will still be left on the digital imaging roadside.
One would be surprised how many of these facilities there still are. I recently visited one of these clinics, which only performed about 10 or so exams each day. They rely on an old processor and then have to digitize the films so they can be read in a hospital about 45 miles away. Imagine how much more efficient and economical a digital system would be—if they only had the initial capital needed to acquire one.
I hope that our professional organizations (such as RSNA, HIMSS, SIIM, ACR, ACC, and others) make a concerted and sustained effort to ensure that medical informatics takes its rightful place in the MU requirements, as Phase 2 are about to be defined. I also urge any and all of my fellow professionals to urge these organizations to lobby for our rightful place at the healthcare informatics table.
Wednesday, September 1, 2010
Anyone Missing Their Shoes?
When you're on the road as much as I am you learn to savor humor when it finds you. For example, the airport announcement I heard this past week that urged a traveler to return to the security checkpoint to collect their shoes. You'd think you'd notice that you were in your stocking feet (or barefooted) as you scurried off to the boarding gate, but I guess this traveler was in a hurry. My guess is that they simply boarded their flight (because the announcement was repeated more than once) before they noticed their shoes were missing. If you're in a rush and preoccupied with multitasking, unless you suddenly step onto wet grass, gravel, or hot pavement, you, too, might not even notice that you've left your shoes behind.
There's an old saying that "the devil is in the details," which you might have the misfortune of experiencing if you get caught flat-footed by rushing into a PACS installation without taking the proper precautions. I've seen it happen at more than one facility: Institutions rip out their dark-room and hurry to go digital without recognizing their dependence on the new technology and its infrastructure. What if the network goes dark because someone accidentally cuts a cable? What happens if the PACS archive goes down? What's the operational plan for a software upgrade requiring the database to be down for a weekend? What if two or more RAIDs on the SAN simultaneously fail?
All these scenarios can be analyzed, their risk assessed, and mitigation procedures put in place. These procedures, which should cover scheduled as well as unscheduled downtime, modality (CR, DR, etc.) failure, a RIS being unavailable, PACS down, network failures, and so on should be thoroughly documented.
Operating procedures for technologists, radiologists, physicians, and PACS support personnel should be detailed in a step-by-step manner. Redundancy and back-up equipment and procedures have to be tested on an on-going basis so they are available when needed. This can be as simple as burning a CD at an acquisition modality for STAT cases (if, for example, a PACS or facility network is down) and walking the disc over to a radiologist for review. In fact, I worked on one RFP that that required a CD writer at each modality QA station (just remember to ensure that blank CDs are readily available).
The message is simple: Prepare for the worst and strive for the best. That way, when the unforeseen and unexpected happens—which it will—you won't find yourself shoeless and unprepared for the elements; not in an airport and not when managing and supporting a PACS.
There's an old saying that "the devil is in the details," which you might have the misfortune of experiencing if you get caught flat-footed by rushing into a PACS installation without taking the proper precautions. I've seen it happen at more than one facility: Institutions rip out their dark-room and hurry to go digital without recognizing their dependence on the new technology and its infrastructure. What if the network goes dark because someone accidentally cuts a cable? What happens if the PACS archive goes down? What's the operational plan for a software upgrade requiring the database to be down for a weekend? What if two or more RAIDs on the SAN simultaneously fail?
All these scenarios can be analyzed, their risk assessed, and mitigation procedures put in place. These procedures, which should cover scheduled as well as unscheduled downtime, modality (CR, DR, etc.) failure, a RIS being unavailable, PACS down, network failures, and so on should be thoroughly documented.
Operating procedures for technologists, radiologists, physicians, and PACS support personnel should be detailed in a step-by-step manner. Redundancy and back-up equipment and procedures have to be tested on an on-going basis so they are available when needed. This can be as simple as burning a CD at an acquisition modality for STAT cases (if, for example, a PACS or facility network is down) and walking the disc over to a radiologist for review. In fact, I worked on one RFP that that required a CD writer at each modality QA station (just remember to ensure that blank CDs are readily available).
The message is simple: Prepare for the worst and strive for the best. That way, when the unforeseen and unexpected happens—which it will—you won't find yourself shoeless and unprepared for the elements; not in an airport and not when managing and supporting a PACS.
VA Biomedical Engineers Receive PACS/EHR Training
The VA Midwest Healthcare Network (VISN 23)--covering veterans in the states of Iowa, Minnesota, Nebraska, North Dakota, South Dakota and portions of Illinois, Kansas, Missouri, Wisconsin, and Wyoming--is initiating training for its biomedical support staff on healthcare IT technologies, with a focus on Picture Archiving and Communication Systems (PACS) and Electronic Health Records (EHRs). An extensive four-phase training program will enable VA engineering staff to meet the increased demand for healthcare IT expertise in their facilities.
The VISN 23 has recognized that developing in-house expertise is more beneficial to the facilities and their patients than relying on multiple vendors' service personnel. As such, VISN 23 is devoting significant resources to training its biomedical support staff on multiple modalities as well as PACS and IT systems. IT experts concur there is no substitute for an in-house expert that can deal with problems as they occur at a facility.
A four-phase training program will take place over the course of one year. The syllabus was developed by Dallas-based Otech, in close coordination with the VA, but could be applied to any other institution or group of professionals. It uses a blended learning methodology, where students will use self-study based CDs and accompanying study guides over the course of two to three months to master each phase of training. The students will then meet at a central location to go over the materials and perform a comprehensive review prior to taking an on-line exam.
The first phase is designed to bring everyone to the same level of IT and clinical expertise--as both knowledge domains are required to deal with the support issues. The Certified PACS Clinical and Technical Associate (CPAS) certification from the PARCA organization recognizes this level of expertise, and was achieved by all of students by August 27. Most of the VISN 23 students have an IT background, and focused their energies on mastering the clinical portion of the training—particularly in regard to medical terminology, which includes radiological positioning, modality knowledge, and anatomy. Knowledge of these terms is essential when dealing with physicians, as well as when performing any type of troubleshooting.
The second training phase is similar in structure to the first: Participants self-study with CDs and study guides; meet in peer groups to review the material; and then gather for a comprehensive review prior to demonstrating mastery via an on-line exam. The second level trains students as PACS systems analysts where they will gain in-depth knowledge of the technology and its standards, such as DICOM and HL7. The students will also learn to interpret interface specifications--including conformance statements--for the purpose of preparing new installations, software changes and upgrades, and finding errors.
Phase three of the training program will start in Spring 2011. The VISN 23 biomedical support staff will become proficient in advanced troubleshooting and techniques using sniffers, and validate connections and interfaces. The emphasis will be focused on healthcare IT technologies and integration at the "back-end." Upon completion of this training phase, the support staff will also have acquired sufficient knowledge to sit for the exams to become OTech DICOM Certified Engineers.
The fourth and final phase of this round of training will focus on IT systems at the enterprise level. Students will gain mastery of many of the IT components in the healthcare enterprise, such as the EHR, as well as their related standards and will also acquire troubleshooting skills for quality related issues.
This four-phase program may set the benchmark for other VA regions in educating biomedical support staff for the next generation of healthcare IT. These new systems are more complex, issues with integration and interfacing will become more trickier, and troubleshooting will require a greater breadth of knowledge. There is no question that these skills require a new level of expertise, which will be provided by the VA biomedical staff in VISN 23!
Details about the four-phase phase, one-year training program:
Level 1: PARCA Certified Technical and Clinical PACS Associate (CPAS): Students will acquire basic clinical and technical knowledge to allow them to troubleshoot and support simple PACS connectivity issues and diagnose hardware as well as software problems. This level is intended to bring professionals with a Clinical or IT background to the same base level, allowing them to grow to level-2, -3, and -4 support levels.
The duration is 8 weeks of self study using the OTech study guides and CD's, followed by a three-day review/refresher face-to-face class. This level is equivalent to the PARCA CPAS level; an on-line exam will be taken upon completion on (www.pacsadmin.org to become CPAS certified.
Level 2: Systems Analyst: Students will be able to configure PACS components, modalities, and other connections. Students will be able to troubleshoot basic issues and interpret log files and dumps of both DICOM and HL7 transactions and relate the information back to the standard specifications. Interpreting conformance statements and interface specifications will be taught in order to anticipate and resolve potential connectivity issues. The emphasis of this training is on the interpretation of interface specifications and logs.
Duration: 8 weeks followed by a four-day review/refresher class face-to-face as well as hands-on practices.
Level 3 Support Engineer: Students will be able to support mission critical components such as the archive, and resolve complex issues regarding connectivity using advanced troubleshooting tools and techniques.
Duration: 8 weeks followed by a four day review/refresher class face-to-face and practical lab.
Level 4 Systems Enterprise Engineer: Students will be able to anticipate issues with regard to new standard implementations such as Structured Reports (such as for ultrasound and cardiology). Image quality issues diagnoses through proper use of tools and test images and issues with the pixel pipeline will be identified.
Duration: 8 weeks followed by a four-day review/refresher class face-to-face and practice lab.
For more information about this training, contact Kurt Finke at the VA ([email protected]) or Herman Oosterwijk at OTech at [email protected].
The VISN 23 has recognized that developing in-house expertise is more beneficial to the facilities and their patients than relying on multiple vendors' service personnel. As such, VISN 23 is devoting significant resources to training its biomedical support staff on multiple modalities as well as PACS and IT systems. IT experts concur there is no substitute for an in-house expert that can deal with problems as they occur at a facility.
A four-phase training program will take place over the course of one year. The syllabus was developed by Dallas-based Otech, in close coordination with the VA, but could be applied to any other institution or group of professionals. It uses a blended learning methodology, where students will use self-study based CDs and accompanying study guides over the course of two to three months to master each phase of training. The students will then meet at a central location to go over the materials and perform a comprehensive review prior to taking an on-line exam.
The first phase is designed to bring everyone to the same level of IT and clinical expertise--as both knowledge domains are required to deal with the support issues. The Certified PACS Clinical and Technical Associate (CPAS) certification from the PARCA organization recognizes this level of expertise, and was achieved by all of students by August 27. Most of the VISN 23 students have an IT background, and focused their energies on mastering the clinical portion of the training—particularly in regard to medical terminology, which includes radiological positioning, modality knowledge, and anatomy. Knowledge of these terms is essential when dealing with physicians, as well as when performing any type of troubleshooting.
The second training phase is similar in structure to the first: Participants self-study with CDs and study guides; meet in peer groups to review the material; and then gather for a comprehensive review prior to demonstrating mastery via an on-line exam. The second level trains students as PACS systems analysts where they will gain in-depth knowledge of the technology and its standards, such as DICOM and HL7. The students will also learn to interpret interface specifications--including conformance statements--for the purpose of preparing new installations, software changes and upgrades, and finding errors.
Phase three of the training program will start in Spring 2011. The VISN 23 biomedical support staff will become proficient in advanced troubleshooting and techniques using sniffers, and validate connections and interfaces. The emphasis will be focused on healthcare IT technologies and integration at the "back-end." Upon completion of this training phase, the support staff will also have acquired sufficient knowledge to sit for the exams to become OTech DICOM Certified Engineers.
The fourth and final phase of this round of training will focus on IT systems at the enterprise level. Students will gain mastery of many of the IT components in the healthcare enterprise, such as the EHR, as well as their related standards and will also acquire troubleshooting skills for quality related issues.
This four-phase program may set the benchmark for other VA regions in educating biomedical support staff for the next generation of healthcare IT. These new systems are more complex, issues with integration and interfacing will become more trickier, and troubleshooting will require a greater breadth of knowledge. There is no question that these skills require a new level of expertise, which will be provided by the VA biomedical staff in VISN 23!
Details about the four-phase phase, one-year training program:
Level 1: PARCA Certified Technical and Clinical PACS Associate (CPAS): Students will acquire basic clinical and technical knowledge to allow them to troubleshoot and support simple PACS connectivity issues and diagnose hardware as well as software problems. This level is intended to bring professionals with a Clinical or IT background to the same base level, allowing them to grow to level-2, -3, and -4 support levels.
| Technical Component: | Clinical Component: |
The duration is 8 weeks of self study using the OTech study guides and CD's, followed by a three-day review/refresher face-to-face class. This level is equivalent to the PARCA CPAS level; an on-line exam will be taken upon completion on (www.pacsadmin.org to become CPAS certified.
Level 2: Systems Analyst: Students will be able to configure PACS components, modalities, and other connections. Students will be able to troubleshoot basic issues and interpret log files and dumps of both DICOM and HL7 transactions and relate the information back to the standard specifications. Interpreting conformance statements and interface specifications will be taught in order to anticipate and resolve potential connectivity issues. The emphasis of this training is on the interpretation of interface specifications and logs.
Level 3 Support Engineer: Students will be able to support mission critical components such as the archive, and resolve complex issues regarding connectivity using advanced troubleshooting tools and techniques.
Duration: 8 weeks followed by a four day review/refresher class face-to-face and practical lab.
Level 4 Systems Enterprise Engineer: Students will be able to anticipate issues with regard to new standard implementations such as Structured Reports (such as for ultrasound and cardiology). Image quality issues diagnoses through proper use of tools and test images and issues with the pixel pipeline will be identified.
Duration: 8 weeks followed by a four-day review/refresher class face-to-face and practice lab.
For more information about this training, contact Kurt Finke at the VA ([email protected]) or Herman Oosterwijk at OTech at [email protected].
Sunday, August 1, 2010
Shift Your Archive to "Neutral"
I recently reviewed a cardiology PACS Request for Proposal (RFP) that had a section on the migration of stored data from various PACS archives to a new system, as well as a section on migration of the data when the potential vendor's PACS was replaced.
The idea of migrating the image and related data right now, in five years, than again in five years till eternity, every time one changes a vendor is not very appealing. That is where a vendor neutral archive (VNA) comes in the picture, which only requires migration once and for all into a true neutral and open format.
These data migration clauses are becoming more common in health IT RFPs—especially for second- and third-generation PACS adopters. This is because many of these users were shackled with the bill for migrating their data, which can be expensive, resource intensive, and very time consuming.
The cardiology PACS RFP author was apparently unaware of the VNA concept, and how it could help their institution avoid future migration issues. I was able to help them get the right requirements in the updated RFP, based on this checklist.
I strongly suggest that anyone who is considering the replacement of their PACS should be seriously considering implementing a VNA (a "true VNA," as defined here). If not, it better be for very good reasons—if you can come up with any, I would be interested in hearing them.
The idea of migrating the image and related data right now, in five years, than again in five years till eternity, every time one changes a vendor is not very appealing. That is where a vendor neutral archive (VNA) comes in the picture, which only requires migration once and for all into a true neutral and open format.
These data migration clauses are becoming more common in health IT RFPs—especially for second- and third-generation PACS adopters. This is because many of these users were shackled with the bill for migrating their data, which can be expensive, resource intensive, and very time consuming.
The cardiology PACS RFP author was apparently unaware of the VNA concept, and how it could help their institution avoid future migration issues. I was able to help them get the right requirements in the updated RFP, based on this checklist.
I strongly suggest that anyone who is considering the replacement of their PACS should be seriously considering implementing a VNA (a "true VNA," as defined here). If not, it better be for very good reasons—if you can come up with any, I would be interested in hearing them.
Subscribe to:
Posts (Atom)