Wednesday, March 3, 2021

The Role of PACS IIP’s and Medical Physicists in Legal Disputes

Unfortunately patient safety, privacy and security violations, as well as disputes about PACS functionality and contracting might end up in arbitration cases or even in court. As a judge and/or jury is unfamiliar with the field of Imaging and Informatics, especially if it comes to understanding issues with DICOM connectivity or other details, lawyers often will call on Imaging Informatics Professionals (IIP’s) who are prepared to function as an expert witness to help settle a dispute. The same can be said regarding involvement of medical physicists, as it relates to image quality and/or radiation safety matters.

Here are some typical examples that we as authors and working in the industry for many years have been involved with as a consultant and/or expert witness that explain the role of IIP’s/medical physicists in legal (or at least potentially legal) disputes and show how you can be better prepared as a professional to anticipate potential legal proceedings.

(Herman):

1.Disputes between vendors and providers – These types of disputes are almost always caused by a mismatch of vendor capabilities and provider expectations. If there is a detailed RFP that spells out the requirements then the dispute is relatively easy to settle. In one case, a provider did not want to pay for the PACS delivery as it argued that the PACS did not meet the requirements. I did an onsite audit checking each RFP item and concluded in my final report that the vendor had complied with 95% of all items and was due full payment.

In another case, the vendor did NOT meet even 50% of the requirements, which forced them to pull out the system and pay for a replacement. If there is not a detailed RFP to go back to, it gets hard to find out what the expectations would have been, in which case there is often a settlement reached in-between.

Lesson learned; make sure you have very well defined requirements when purchasing a PACS including performance, features, functionality etc. so you are covered.

2. Technical issues – A radiation therapy vendor installed both the planning system and the therapy delivery system (linac). A programming error in the DICOM interface sent the treatment parameters to the therapy system with the ISO-center inverted, causing patients who were supposed to be treated for throat cancer to be radiated on their spine which caused them to become paraplegic. One patient became so depressed that he took his life. There was an FDA warning issued for the device and it was eventually corrected, but not after several patients were incorrectly treated.

 

Lesson learned; never trust a vendor, make sure you check all settings, parameters, etc. especially if it potentially can cause direct patient harm.

3. Misdiagnosis – “I did not see that lesion,” is unfortunately still a common event. Humans are not perfect, but some professionals are just incompetent, and the general public should be protected from those that do not deserve to be treating patients. In one case, a radiologist argued that the monitor was defective, and he could not see the lesion (even I could see the hemorrhage in the brain). The dispute required the calibration files to be pulled for that workstation. In another case a radiologist flatly denied that he saw the chest image to check the tube placement, which was refuted by showing the audit trail proof that he himself indeed (or someone with his login-password) looked at the image. In both cases the patient died, in the first case they gave blood thinner to a patient with a bleed in the brain, in the second case the patient was in the ICU and died because of incorrect tube placement.

Lesson learned; keep your calibration files for your monitors safe and also all your audit trails as they might be needed for a case.

4. QA/QC policies not being followed – A technologist selected the wrong study and the report which indicated a terminal disease was connected to the wrong patient. The good news was that the terminally ill patient already knew about the disease, but the patient who was perfectly healthy got the bad news that her days were numbered. After the discovery of the error, you can imagine the stress and agony she went through, causing her to sue the hospital.

Lessons learned; have very well defined QA policies in place that require the technologist to double check the patient demographics, defining these policies typically is the job of an IIP.

5. Privacy violations – A radiologist was fired because his “supervisor,” i.e. medical director looked at his brain CT and deemed him to be unfit for practicing radiology as he had an apparent brain cancer. The medical director argued that it was her “duty” to perform regular QA checks on all of the department studies, however, the radiologist argued that his privacy was violated and should not have been fired for that reason as he had sought medical attention and was treated accordingly.

Lesson learned; again, make sure you keep your audit trails available, in this case for proving it was indeed a privacy violation.

(Jeff)

6. Commercial grade vs. medical grade displays for diagnostic interpretation – During an evaluation of a radiologist’s home set of 5 MP displays used primarily for mammography reporting, I was asked to look at her > 5 MP Apple display as well for comparison. The question she brought to my attention was “are these satisfactory for mammography interpretation”? The AAPM TG18-QC test pattern was brought up and looked great (all details supposed to be observed were observed). However, further measurements of the luminance patches across the entire dynamic range showed that there was gross non-conformance to the GSDF curve.

Lessons learned; never make assumptions regarding the calibration status of your displays, even if an image looks acceptable for interpretation and/or review. Use of calibration software with the front sensor and/or external photometer measurements should occur on a regular basis with documentation and records retention. 

7. Phantom image retention – Routine quality control imaging of phantoms and/or other test objects can be of value, not only for compliance/accreditation requirements, but also as a form of documentation to prove that some sort of constancy evaluation of the image quality is being performed for your imaging unit. Regulatory officers/inspectors may decide to audit a facility to show that these phantom images have been retained and are consistent. Failing to adhere to imaging phantoms or retaining the images can result in fines, should an officer decide to enforce this. Furthermore, image retention can be extremely valuable in the event your facility is hit with a lawsuit and/or allegation.

Lessons learned; know your regulatory/accreditation requirements and adhere fully to these. Even if these requirements do not pertain to some modalities, routine phantom imaging and retention should still occur for the reasons mentioned previously. 

8. Dental facility being sued – I was called in by a lawyer to act as an expert consultant regarding a dental facility being sued by one of its staff members. The staff member claimed that the cause of her breast cancer (resulting in a double mastectomy) and cataracts was the result of use of the facility’s panoramic x-ray unit. I had reviewed documentation regarding past service/x-ray compliance reports, Ministry approval to install the x-ray unit, and other related documentation. Furthermore, I had conducted a comprehensive evaluation of the unit according to AAPM TG 175 (Acceptance Testing and Quality Control of Dental Imaging Equipment). Based on my evaluation, no compliance requirements evaluated or reviewed failed.

Lessons learned; no matter if the modality produces a low amount of radiation relative to others (e.g. dental panoramic to diagnostic CT), ensure that you follow all compliance requirements and retain such documentation for the required amount of time. Lawsuits are a real thing and can occur for ANY facility!

9. Accidental exposure – An x-ray technologist had apparently performed both AP and LAT views of the tibia/fibula of a two-year old child who was suspected of a fracture. During the AP view, in the midst of the child crying and the father restraining the child to remain still for the exam, the technologist had forgotten to give shielding to both the child and father. Lead protection was provided prior to the LAT view being taken, however. I was called in to perform a dose/risk analysis regarding this matter. Output measurements of the x-ray unit were taken as well as a review of the images in PACS.

Upon review of the image headers, including the attributes pertaining to exposure techniques, I asked the technologist if she was aware of what range the exposure indicator should be within (the exposure indicator being a way to quantify how much radiation the detector received). The response given to me was a blank stare. In a follow-up discussion with the diagnostic imaging manager and chief radiologist, it was explained that the increased radiation risk to the child and father from the first exposure without any lead protection was minimal. However, it was further explained that some training for at least this technologist should occur regarding how much radiation is to be administered (via the exposure indicator).

Lessons learned; accidental exposures, even overexposures, deserve due diligence and use of an expert to add value to the matter. As an incidental finding performing this review, there was a knowledge gap revealed for this particular technologist. If radiation is administered, it’s crucial to be able to know how much radiation is used. Training in best and latest trends/standards should be implemented.  

10. Investigation of high radiation badge readings – An x-ray facility had a general radiography room with a control badge directly behind a glass window. Since the start of using this room, the badge had not registered anything, but was kept to monitor the secondary radiation just in-case. However, after about one year of use, the badge was recording values, which surprised and concerned staff members, particularly some pregnant x-ray workers. I was asked to investigate this matter.

The facility had retained the documentation related to what shielding requirements they have been approved for. Upon reviewing this as well as taking various radiation measurements, I had noticed that the glass windows were half of the lead-equivalent thickness they were approved for (1.6 mm Pb vs. 3.2 mm Pb). Furthermore, the use of the room had increased by approximately three times from what they were approved for. Putting two and two together with other related evaluations, I concluded that the increase in use and inappropriate glass windows were the cause of the higher badge readings.

Lessons learned; when planning the design for approval of an x-ray room, be sure to verify and document what shielding is actually installed. One also should be proactive and plan ahead if they intend to increase the utilization of their x-ray machine, which will increase shielding requirements.   

In conclusion, there are several unfortunate events (patient injury and/or death), that might end up in a legal case. You, as an IIP/medical physicist might be asked to either assist in providing data, an opinion, or serve as an expert witness to get to the bottom of a situation so that corrective actions and/or compensation for the ones impacted can be achieved. If you have any questions, don’t hesitate to contact us:

Monday, February 8, 2021

PACS professional certification, CIIP vs PARCA.

PACS administrators or as they are also called, Imaging Informatics Professionals (IIP), have been around for about 20 years, ever since providers started to realize that it takes a dedicated support staff to manage the PACS system and be responsible for its data integrity and operation. In 2004 a certification agency, the PACS Administrators Registry and certification Association, aka PARCA, was formed to provide a proof of a certain level of proficiency witnessed by passing a certification exam. Not that long after that, the American Board of Imaging Informatics, aka ABII, was formed in a partnership between ARRT and SIIM, providing another certification called CIIP. The PARCA and CIIP certifications are quite different due to their origin and intended target group of professionals. This write up is intended to clarify the different certification paths to benefit potential candidates that are looking to become certified and for those who are trying to recruit potential IIP professionals. Here are the main differences:

1.       PARCA has four different certification exams (see figure). The basic level shown on the left-bottom, is the Certified PACS Associate (CPAS) level which requires both IT and Clinical proficiency and therefore requires both the CPAS clinical and IT certification exams to be taken. ONLY after passing this first level of certification, the candidate can continue to become certified as a Certified PACS System Administrator (CPSA). There is also a special, stand-alone certification dedicated to DICOM, i.e., the CDIP or Certified DICOM Integration Professional, which is becoming increasingly important because IIP’s are having to do their own troubleshooting in case there is a dispute between a vendor and the healthcare enterprise. CDIP teaches important skills such as how to use a DICOM sniffer to investigate performance issues and integration problems. ABII offers only one level of certification, i.e. Certified Imaging Informatic Professional (CIIP). Note that ABII requires both a certain level of experience AND minimum level of relevant imaging informatics training (i.e. semester credits) prior to CIIP certification, which is not required for the PARCA certification. The CIIP qualification requirements are explained in more detail on their website, and consists of a point system, for example, one could qualify with 2 years healthcare experience and a relevant  Masters degree, 5 years experience, 36 hours of imaging informatics experinece and an Associate degree and combinations thereof.

2.       The subject areas covered by the CIIP and PARCA PACS certifications are quite different. Because CIIP only has a single certification, there is some overlap between CIIP and PARCA certifications to cover the complete area of PACS. As a matter of fact, there is about a 10% overlap between CIIP and PARCA CPAS IT, 30% overlap between CIIP and CPAS Clinical, 30% overlap between CIIP and CPSA and 10% overlap between CIIP and CDIP, as shown in the figure by the red dashed line. 80% of the CIIP subject matter is unique and different. In order to fully appreciate the differences between the CIIP and PARCA subject areas, one would need to compare the test content outlines and/or requirments next to each other item by item, but in general, the CPAS is more technical oriented and CIIP more managerial as it covers areas such as project management, procurement, education and others. It is not uncommon for a CPAS candidate to become either CPSA and/or CIIP certified; there are several professionals who sit for all of the exams.

3.       The CPAS, i.e. basic level of PARCA, has two distinct target audiences. First, CPAS is appropriate for either non-healthcare professionals or professionals who work in a related field who are looking for a career change and want to get into the PACS profession. These are mostly Radiological Technologists or IT professionals, who either need additional training in either the IT or clinical area. The other audience is for those professionals who are already working in PACS but never had the opportunity to gain either the clinical or IT skills and would like to become trained and certified in this area. The first audience, i.e., individuals without any PACS background, is not served by the CIIP certification because CIIP requires a certain number of years of experience. This is also the case for those who were unable to complete any formal education in the form of a certain number of college credits: they would be able to take the CPAS certification but are excluded from taking the CIIP exam.

4.       PARCA and ABII took a very different approach with regard to developing their what is called certification requirements or Test Content Outline (TCO). PARCA exam requirements were developed top down, starting with outcome measurements, and learning objectives and were developed by educators in this field. The ABII requirements (TCO) were developed bottom up, based on a survey and subsequent committee of volunteers. The good news is that SIIM is in the process of “reverse engineering” the ABII requirements to make the curriculum more coherent. The same applies to the supporting materials, the PARCA textbooks are written by a single author, while the CIIP textbook is created by various authors which makes it challenging to have a consistent style and prevent gaps and overlaps.

5.       PARCA has an international focus. The majority of its board members are from outside the US. 20% of its candidates are from outside the US and it is growing in importance. Also, one should realize that in many countries, especially LMIC regions (Lower and Middle Income Countries), PACS is still in its infancy and therefore a prime target for CPAS certification, while CIIP certification, which is focused on people with experience, would not be an option.

6.       CIIP exams have to be taken at a physical testing center. In contrast, PARCA has provided on-line exams since 2005 which allows the exams to be taken “any time-anywhere”. The exams are on-line proctored, that is each student has a dedicated one-on-one proctor who is watching the candidate continuously during the examination. Any potential distraction and/or indication that a student might use any external resource or even look away from the screen will invalidate the exam. This guarantees a secure test environment. Electronic exams by telepresence instead of a physical presence at a test center has a lot of other advantages, first of all, none of the exams are identical as the questions are pulled randomly from a large test pool that is at least twice the actual test size, with the multiple choice answers being re-arranged for each test. In addition, on-line certification testing is the only way to offer international certification exams because many countries do not have access to physical testing centers. Lastly, on-line testing is much more cost effective. That is most likely one of the reasons that the PARCA certification exam cost is less than half the cost of the CIIP certification while the PARCA retake fee ($20) is less than one tenth of the CIIP retake cost ($250).

7.       The difference between PARCA and CIIP is also reflected in the training options provided by 3rd parties such as SIIM, OTech and others (note that PARCA and ABII are not offering any training themselves as they try to keep a "barrier" between trainers and examiners). PARCA CPAS training is typically a several day event going through the materials in depth because much of the content is new to the candidates. The CIIP training is typically a bootcamp to provide experienced professionals the opportunity to refresh their knowledge prior to taking the exam. The PARCA IT as well as the CDIP is also more hands-on than the CIIP, as those topics are difficult to master without any hands-on exercises.

8.       There are other minor differences between PARCA and CIIP such as related to the requirement for continuing education and re-certification and when the content is made up-to-date because the PARCA requirements have been recently updated to include new technologies such as AI and cyber security and the CIIP Test Content Outline is up-to-date as of 2019.

In conclusion, both PARCA and CIIP certifications are valuable and given the fact that after 16 years, thousands of professionals have become certified, both have certainly established a new standard of professionalism which benefits the imaging and informatics community. It would be beneficial for the IIP community if PARCA and ABII would merge and work towards a more consolidated approach taking the best of both worlds. Time will tell whether this could happen.

For more details about either certification see PARCA and ABII.

About the author: Herman Oosterwijk has taught the PARCA curriculum since its inception. He created detailed study guides for both the CIIP and PARCA certifications. He is also part of the SIIM committee to create a new internship program based on the CIIP curriculum and part of the SIIM CIIP bootcamp faculty.

Tuesday, January 19, 2021

Common HL7® Order to DICOM Mapping Issues

Most PACS administrators are not that familiar with HL7® , which can be a disadvantage when trying to troubleshoot issues at the PACS backend, as many of the Attributes that are part of the DICOM header are initially created and/or mapped from a HL7 message. HL7 messages are not that hard to interpret as they are encoded in plain ASCII text. A simple browser or even notepad will show you the message allowing you to find out why a PACS system either rejects a DICOM file or decides to store it in the “lost and found” input queue and not making it available for a radiologist at its workstation.

An HL7 order message (ORM) is typically received by a PACS, RIS, or Broker which will add the order to its scheduling database and upon a query request by a digital modality, it will provide a DICOM worklist by mapping the HL7 fields into the DICOM Attributes, which are subsequently copied by the modality in the DICOM header for the images to be sent to the PACS. The most common reasons for rejection by the PACS can be traced back to couple of HL7 to DICOM mapping issues as described below:

1.       Length mismatch – Many of the HL7 fields allow for a larger field length than the DICOM Attributes. When received by the PACS, it might check its length and decide that its database record length is smaller and reject it. As an example, the Person Name data type definition in HL7 (XPN) can be a maximum of 1103 characters long and have 14 subcomponents including items such as name validity range, expiration date, etc. while the DICOM data type definition (PN) is a maximum of 64 characters long with 5 components.

2.       Formatting mismatch – Some of the HL7 fields are encoded with a different order of the components than the DICOM fields. An example would be the order of the name components in the HL7 person name (XPN), which is <last>^<first>^<middle>^<suffix>^<prefix>, for the DICOM it is <last>^<first>^<middle>^<prefix>^<suffix>, note the suffix, prefix reversal.

3.       Contents mismatch – Some of the fields in HL7 have a different set of defined terms. For example, in HL7 V2.1, the set of recommended fields for patient sex is F, M, O, U, in version 2.7 that has been expanded to F, M, O, U, A and N. In DICOM the list of defined terms is F, M, and O. All of the additional HL7 codes except for M and F should be mapped to O, If not done so, the PACS will complain.

4.       Location mismatch – The patient ID in HL7 can be in different fields depending on whether it is the internal ID, external ID, social security number, alternate patient ID or, after version 2.3.1, they could be in a single location as a list that includes the issuer of the patient ID. One needs to select the right ID to be used as its primary ID and map that into the Patient ID field (0010,0020). All others that a PACS wants to carry along in the header should be mapped into the Other Patient ID field (0010,1000). Incorrect mapping might cause issues with patient identification.

5.       Coding issues – Procedures are encoded using its CPT4 code and description as well as abbreviation. Hospitals might use internal code systems, might mix the abbreviation with the full description, etc. causing incorrect procedure selection by the technologist at a modality.

6.       Mapping the procedure to the right modality – An HL7 order does not typically include the modality type (e.g. CT, MRI, etc.). The scheduling application has to map the procedure to the modality based on the procedure code, e.g. it would know what procedure codes are to be performed at a CT, MRI, ultrasound, or other modality. The problem occurs if there are multiple modalities, e.g. an inpatient CT in radiology and an outpatient CT in the ER, as the order might be listed on both. The same applies for having an ultrasound in the delivery, radiology and cardiology departments, mapping all of these procedures to a single modality, e.g. “US”, which would cause the procedures to show up on each US modality. In this case, the scheduler has to look at additional information to determine the patient location, class, etc. and map the order to a particular Scheduled AE-Title that can be used by the modality to request the correct worklist for this device.

7.       User entry errors – These are not necessarily mapping errors, instead these are caused by user data entry input issues, for example, a data entry person might put the last name AND first name in the last name field. The information will be mapped correctly but the meaning of the data is in this case is incorrect.

In conclusion, data integrity of the image data in the PACS or enterprise imaging system is essential. Issues with incorrect, inconsistent or missing information can often be traced back to the source, i.e. the HL7 order that was used to map into a DICOM worklist for retrieval by a modality and subsequently mapped into a DICOM image header. Knowing how to interpret the HL7 transactions will go a long way to troubleshooting these issues when they occur.

Sunday, December 20, 2020

Using an Open Source PACS

 Using an open source PACS solution instead of a commercial PACS could be attractive to
LMIC (Low and Middle Income Countries) as it provides a good start to gain experience with managing digital medical images with a relatively low entry cost. In this paper we’ll discuss the PACS features that can be offered by open source providers, implementations strategies, and lessons learned.

Why would someone want to use an open source PACS?

 ·         The most important reason is its lower cost as it is free (kind of), i.e. there are no software and/or licensing fees. The exception is for the operating system, which can be open source as well if one uses Linux or a variant, and, if applicable, other utilities such as a commercial database, but again, they can be an open source product as well. There is a significant cost involved for the hardware, i.e. servers, PC’s, medical grade monitors for the radiologists and the network infrastructure, i.e. cabling, routers and switches. The latter assumes that there is not a reliable network in place which is often the case in LMIC’s, therefore, a dedicated network is often a requirement.

·         Open source PACS allows an organization to find out what they need as they are changing from using hardcopy films to a digital environment with which they have often no experience and/or exposure. As many open source PACS systems have a free and commercial version, it is easy to migrate at a later date to the paid version, which provides the upgrades and support as the organization feels comfortable with the vendor.

·         This is not only applicable to LMIC regions, but an open source PACS can be used to address a missing feature in your current system. For example, they can be used as a DICOM router.

·         The open source PACS can function as a free back-up in case the commercial production PACS goes down as part of an unscheduled or scheduled downtime.

·         It can be used as a “test-PACS” for troubleshooting, diagnostics and training. 

But the main reason is still the cost advantage. If a LMIC hospital has to choose between a purchasing a used CT or MRI for let’s say $350k US, which could have a major impact on patient care as it might be the only one in a large region serving a big population, and  investing in a PACS system, the choice is clear: they will first get the modality and then use maybe another $50k or so to buy the hardware servers, PC’s and monitors and string cable to get a network in place and install an open source PACS. One should also be aware that the argument of not having any vendor support for an open source PACS is grossly over-rated. I have seen some good dealers and support but also some very poor service engineers, so even if you would use a commercial PACS, the chance that you get any decent support is often slim in the LMIC region.

 Let’s now talk about the PACS architecture as there is a difference between a “bare-bones” (BB-PACS), a typical (T-PACS) and a fully featured (FF-PACS). This is important as in many cases you might only need a BBPACS to meet the immediate needs in a LMIC hospital or clinic. 

 A TPACS takes in images from different modalities, indexes them in a database, aka Image Manager, archives them in such a way that they can be returned to users, and provides a workflow manager to allow for multiple radiology users to simultaneously access the studies using different worklist criteria. For example, the workflow manager would allow the studies to be accessed using different specialties (neuro, , pediatrics) and/or body parts (extremities, breast, head) as a filter while indicating if a study is being read by someone else, its priority, and if it has been reported. The TPACS also has a tight integration with its workstations, the PACS archive, and database through the workflow manager, i.e. these workstations would typically be from the same vendor that provides the PACS archive and database.

 The FF-PACS would be a T-PACS and also have reporting capability, preferably using Voice Recognition and a Modality Worklist Provider that interfaces with the digital modalities with an ordering system to allow the technologist at the modality to pick from a list instead of having to re-enter the patient demographics and selecting the appropriate study.

 A BB-PACS would be merely a PACS database and archive. It would not have a workflow manager and one could use an open source workstation from another vendor. Almost all open source PACS systems are of the BB-PACS kind, which means that one has to select a preferable open source viewer with it as well.

 How are these open source PACS systems implemented? In the developed world, it typically happens top-down, i.e. a hospital has a Radiology Information System (RIS) that places the orders, which is replaced in most institutions by an ordering feature in the EMR. These orders are than converted from a HL7 into a DICOM worklist format by a Worklist provider. The images that are being acquired are sent to the PACS and the radiologist uses a Voice Recognition System to create the reports.

 In the LMIC regions, it typically starts bottom-up. The first step is converting the modalities from film to digital by replacing their film processors with CR reader technology or upgrading their x-ray systems to include a Direct Digital Detector. They might get a CT and/or MRI that also prints studies on a film printer. They now have digital images that need to be viewed on a viewing station, archived and managed, therefore a PACS is needed. That is when the vendors start pitching their commercial PACS products, usually a FF-PACS or T-PACS, which are typically unaffordable, hence the choice to implement an open source, BB-PACS with a couple of open source view stations.

 It is critical at this point to use a medical grade monitor for the radiologist to make a diagnosis as commercial grade monitors are not calibrated to map each image pixel value into a greyscale value that can be distinguished by a user. These monitors do not need to have the high resolution (3MP or 5MP) as is commonly used in developed countries, but a 2MP will suffice, knowing that to see the full resolution the user will have to zoom in or pan the image in a higher resolution. These 2MP monitors are at least three or more times less expensive than their high-resolution versions. The only disadvantage is that they require a little bit more time for the interpretation to be done as the user has to zoom to see the full spatial resolution.

 After having installed a BB-PACS and used it for a few years, the institution will have a better idea of what their specific requirements are for the PACS system and they can make a much better decision for what they want to do next. There are three options:

1.       Expand the current open source BB-PACS, e.g. upgrade the storage capacity, replace the server, have a more robust back-up solution and add a commercial workstation workflow manager, a Modality Worklist Provider and reporting system. This assumes there is a mechanism to enter orders, i.e. through a RIS or EMR.

2.       Keep the BB-PACS and turn it into a Vendor Neutral Archive (VNA) and purchase a commercial T-PACS which serves as a front end to the radiologist. The new PACS might store images for 3-6 months and the “old” PACS will function as the permanent archive.

3.       Replace the BB-PACS with a commercial T-PACS or even a FF-PACS assuming the funds are available and you are looking for a cost effective solution. 

Note that the advantage of option 1 and 2 is that you don’t need to migrate the images from the old to the new PACS, which can be a lengthy and potential costly endeavor.

 What are some of the open source PACS systems? The most common options are Conquest, ClearCanvas server, Orthanc, DCM4CHEE and its variant Dicoogle. Conquest and ClearCanvas are Windows based, Orthanc can be both Windows or Linux and DCM4CHEE is Linux based. Conquest is the most popular for being used as a router and for research and the easiest to install (literally a few minutes). ClearCanvas is also relatively easy to install, DCM4CHEE is the most involved but there is now a docker available that makes the process easier. DCM4CHEE is also the most scalable. For open source viewers, one can use the ClearCanvas viewer, which is the most popular, or a web-based viewer such as Oviyam with DCM4CHEE. RadiAnt is another option and Osirix is the primary choice for a MAC. There are several other options for viewers, one can do a search and try them out, but be aware that they differ greatly with regard to functionality and robustness. Another consideration is continuing support, as an example, the gold standard for the open source viewer used to be E-film, but that company was acquiredby a commercial vendor who stopped supporting the open source version which is a problem with the frequent OS upgrades especially when based on Windows.

 What are some of the lessons learned with installing the open source PACS:

·         Be prepared to assign an in-house IT and/or clinical person who is computer literate to support the PACS. This person will be responsible for day-to-day support, back-ups, managing scheduled and unscheduled downtimes, adding additional modalities and interfaces with a RIS, EMR or reporting system as they are being introduced. This staff member will also be responsible for troubleshooting any issues that might occur. They will also be the go-to person for questions about its usage and he or she will train incoming users. These so-called PACS administrators are a well-established profession in the developed world, but it will be a challenge initially to justify a designated position for these people to the department and hospital administration in the LMIC region as it is a new position.

·         How will these PACS administrators get their knowledge? There are fortunately many on-line resources, including on-line training, and organizations such as RAD-aid, which has been conducting PACS bootcamp training session in LMIC regions to educate these professionals.

·         PACS is a mission critical resource that has impact on the infrastructure (power, network, HVAC, etc.). In most cases the existing network is not secure and reliable enough and/or does not have sufficient bandwidth, which requires a dedicated network with its own switches and routers.

·         It is preferred to use locally sourced hardware for the IT components to allow for a service contract and access to parts. The only problem you might have is to get medical grade monitors in some regions as they are not as popular yet.

·         Pay attention to the reading environment for diagnostics, I had to instruct people to switch off their lightboxes that were used to look at old films and even paint some outside windows to reduce the ambient light. Use medical grade monitors for diagnostic reading.

·         Use good IT practices that includes implementing cyber security measures, reliable back-up and OS patch management.

·         Create a set of Policies and Procedures for the PACS that include access control, who can import and export data on CD’s and how that is done, unscheduled and scheduled down-time procedures, and everything else needed to manage a relatively complex healthcare imaging and IT system.

 In conclusion, open source PACS systems are a very viable, if not the only option due to cost constraints, in LMIC regions, especially for the first phase. One should be aware that these open source PACS systems are very much a bare bones solution with limited functionality, however they allow the user to get started and find out their specific requirements. If additional funds become available, one can upgrade later to enhance functionality or replace it with a commercial PACS which can become either “front-end” to the existing PACS or a replacement. 

Resources:

Conquest: https://ingenium.home.xs4all.nl/dicom.html

Dcm4chee: https://www.dcm4che.org/

Orthanc: https://www.orthanc-server.com/

ClearCanvas: http://clearcanvas.github.io/

RadiAnt: https://www.radiantviewer.com/

DiCoogle: http://www.dicoogle.com/

Oviyam: http://oviyam.raster.in/

Osirix: https://www.osirix-viewer.com/

RAD-AID: https://www.rad-aid.org/

 

Thursday, August 6, 2020

Top ten COVID-19 impact on Healthcare Imaging and IT.

The onslaught of the COVID-19 virus has impacted many from an emotional and financial perspective and dramatically changed the way healthcare is being delivered. From a personal emotional perspective, a few of my family members were diagnosed positive, some of my friends had their loved ones hospitalized, and I recently lost a good friend and colleague due to the virus.
However, out of a “bad thing” usually “good things” happen as there is a sense of urgency and focus to 
deliver healthcare faster and better while keeping social distance. We did not only find out what worked in this environment, but also what did not work and where are the gaps that need to be filled to be ready for the COVID-19 aftermath and for potential future pandemics. 

Here are my observations:

1.       When there is a need, there is a way to change policies – To quote Christopher Roth, Vice-Chair of Radiology at Duke, who said during one of the many excellent SIIM webinars, “this pandemic was as dramatic and life changing as the implementation of a new EMR, but with the difference that instead of taking 2-3 years, it had to be done in less than a month. Therefore there was no time for committee meetings, no time for training and planning, but instead practitioners had to learn and make changes as-you-go.”

New uses for modalities were invented, for example, instead of bringing a COVID patient to a radiology department to perform an exam, with the result that a cleanup crew has to take half an hour to clean and disinfect it again for the next patient, it might be better to take a chest X-ray with a portable unit at the bed-side in the ICU or ER or patient room. Federal guidelines for reimbursement of non-standard procedures, which under normal circumstances would not be reimbursed were quickly changed and adapted.

2.       POCUS use has sky-rocketed – The emergence of hand-held ultrasound (Point Of Care Ultrasound, or POCUS) over the last 2 years could not have come at a better time. These systems are relatively affordable as the cost ranges between $2k and $6k, and as they connect to either a standard phone or dedicated phone-size screen or tablet, a healthcare practitioner can carry one in his or her pocket and make an assessment on the spot.

Uploading the images that a physician wants to keep as part of the electronic health record has been a challenge that has been addressed by the standards community in the form of an “Encounter Based Imaging” IHE profile. As a recent JACR study showed, its usage did not impact downstream ultrasound volumes which is good news for those who feared that it would cannibalize the “standard” ultrasound procedures.

3.       Telemedicine has shown a massive increase – Telemedicine takes place in three modes: 1) Synchronous where a patient is talking real-time to a healthcare practitioner, 2) A-synchronous where the communication takes place in the form of texts, emails, uploaded documents, etc.,  and 3) Telemonitoring or Virtual Observation.

Telemonitoring does not only include monitoring a patient at home but also monitoring inpatients such as in the ICU. The less a practitioner has to interact physically with an infected patient, the lower the risk of spreading the infection and the lower the need for PPE usage.
Estimates for telemedicine business range between a 7 to 10 fold increase over the next 5 years. If you consider an individual practitioner, the increase could be dramatic from having virtually no telemedicine consults to converting more than 70% of their practices to remote consults. This increase became the ultimate test of the scalability of the platforms that are being used. It can only be expected that when the pandemic wanes there will be a certain percentage of those applications kept in place.

A positive effect also has been that tele-visits are now chargeable because of changed regulations, let’s hope that some of these “emergency rules” by CMS will stay in place as there is no reason for a patient to show up in a doctor’s office for simple things that can be dealt with remotely.

4.       The cyber security attack surface has been greatly enlarged – Many non-clinical healthcare workers have been working from home, clinical workers might be working from home as well, and last but not least, because of teleconsultations, patients are now also directly connected to providers. This is especially challenging for smaller providers who might not have the IT resources to deal with this.

5.       Patients have become users of an organization technical infrastructure – According to a survey, most of the telehealth consultations used commercial applications such as Zoom (23%), Facetime (17%) and Skype (9%) with telehealth platforms (34%) in the minority. One cannot assume that every patient is familiar with the functionality of these tools, and some of them are definitely more user-friendly than others. Who is the patient going to call if they cannot get into the tele consult application? IT support had to ramp up significantly to support patients as well as their remote employees.

6.       Telemedicine extended beyond COVID calls – The same survey showed that only 14% of visits were related to COVID symptoms. The other 86% of the calls ranged from urgent care to scheduled visits, behavioral health, chronic illness management (diabetes, cardiac, others…), and surgical follow ups. Again, the social distancing requirement showed that a significant percentage of routine visits can be done equally well remotely.

7.       Artificial Intelligence (AI) has proven not to be a panacea (yet) – As most AI algorithms are based on deep learning it requires a significant amount of training data which was certainly in the beginning not readily available. It is getting better as many institutions make their data available to researchers. Many AI vendors were “reprogramming” their algorithms from existing applications, such as pneumonia, for COVID which has proven not to work as well. In addition, it was and is still not clear what modality is the best to diagnose COVID, is it a chest X-ray, a CT, an ultrasound or other modality? The advantage of imaging is that it is almost real time, or at least has a much faster turn-around time than having to wait for a lab test result.

8.       Digital pathology is a major laggard – With tele consults and teleradiology being widely available it is definitely frustrating to see how it is currently challenging if not impossible to exchange a digitized pathology slide, especially in the US due to a lack of regulatory approvals and interoperability. Some countries, notably the Netherlands already have a nationwide digital pathology exchange set up to for this. There is no reason why this kind of implementation could not be deployed in the US, as a matter of fact this is the main topic of an upcoming seminar on this subject.

9.       How to get access to all of the records is still very challenging – Just from anecdotal experience, after one of my good friends had arranged for her scheduled in-person visit to be changed to a telehealth visit with a major institution for a second opinion, the physician did not have access to the most recent X-rays. The fact that my friend had the CD did not really help as there was no upload mechanism for them in the platform/portal they were using. Having all the information in a timely and complete manner is even more of a challenge with these telehealth consults.

10.   A major workflow redesign is needed – I was rather impressed with the new workflow when I had an in-person appointment with my specialist. I was instructed to text my arrival to the front-desk, upon which a nurse came to my car with a wireless tablet to confirm my identity, take my temperature, ask basic questions and when I “passed,” escorted me to the clinic straight into an exam room using a path that would limit any close encounters with other patients or practitioners. Similarly, hospitals now have a special dedicated entrance for suspected COVID cases. 


In conclusion, the pandemic has had a major impact on healthcare IT and accelerated some of the “dormant” applications to a degree that will very likely stay, most of it for the better. I recall the last visit of my spouse with the surgeon one week after she was discharged following a minor surgery, upon which the surgeon took a quick look at her scar and determined in a matter of seconds that all was OK. There is no reason for that type of visit to be in person as she could simply take a picture with her phone and email it or during a synchronous telehealth session point her phone to the incision to show it. Telehealth is in many cases more efficient and creates less of a burden for patients and has the potential to lower costs as well, let’s hope that the result of many of these COVID impacts will remain for the better.


Tuesday, June 23, 2020

How Workflow Bottlenecks are Choking the AI deployment Tsunami.


The introduction of AI in medical imaging could not have come at a better time with the COVID-19 pandemic, as AI applications for detection, diagnosis and acquisition support. especially when using Telemedicine. have shown to be invaluable managing these patients both at healthcare institutions as well as at home. There are a couple of caveats however, using this new technology, first the regulatory constraints limiting new AI algorithms because the FDA needs to catch up with approvals, second, as with any Deep Learning algorithm, AI for healthcare needs lots of data to train the algorithm, which is a limiting factor for COVID cases even although several hospitals are making their COVID patient data files publicly available. But, despite these limitations, institutions are ready to deploy AI for this particular use case together with other applications that have been identified and are addressed by literally hundreds of companies developing these novel applications.

However, early implementations of AI have come across a major obstacle: how to adopt it to the workflow as it has caused a true “traffic jam” of data to be routed to several algorithms, and the results from these AI applications, in the form of annotations, reports, markers, screen saves and other indications, to be routed to their destinations such as the EMR, PACS, reporting systems or viewers. This orchestration has to occur synchronized with other information flows for example, an AI result has to be available either before or at the time of the reporting of the imaging studies, and has to be available together with lab or other results, which might need delaying or queuing these other non-AI information flows to be effective.

What is needed to manage this is an AI “conductor” that orchestrates the flow of images, results, reports between all the different parties such as modalities, reporting systems, EMR, and obviously the AI applications, the latter of which could be on-premise or in the cloud. Note that the number of AI apps eventually reach hundreds if you take into account that an algorithm might be modality specific (CT, MR, US etc.), and be specialized for different body parts and/or diseases. Scalability is a key requirement of this critical device but also many other features.

A simple “DICOM router” will not be able to orchestrate this rather complex workflow. To assist users with identifying the required features, I created three levels of routers as shown in the figure.

Level 1 can do simple forwarding and multiplexing, queue management and has a simple rules engine to determine what to send where. 

The second level has additional features as it can perform “fuzzy routing” i.e. based on fuzzy logic, prefetch information using proxies (i.e. querying multiple sources while giving a single return), do conversions of data and file formats, anonymize the data and is scalable. 

The third level has all of the level 1 and 2 functionality and extends it to AI specific routing, can modify images header and split studies, perform worklist proxies (i.e. query multiple worklists while appearing as a single thread), and has secure connectivity to meet “zero-trust” requirements. It supports not only “traditional” DICOM, HL7 but also webservices such as WADO and FHIR and supports IHE. It can also perform static and dynamic routing, do data conversions, filter the data, split studies, normalize the data, anonymize it if so desired, and provide support for several different formats and support for Structured reports, annotations, to name a few. As a matter of fact, a fully featured AI conductor requires at least 25 distinctly different functions as described in detail in this white paper (link).

In conclusion, there is a serious workflow issue deploying AI, but the good news is that there are solutions available, some in the public domain with limited features and some as commercial products. Make sure you know what you need before shopping around, the link to the comprehensive white paper on this subject has a handy checklist you can use when you are shopping at your (virtual) HIMSS, SIIM or RSNA trade shows or when “Zooming” with your favorite vendor. You can download the white paper here.