RSNA has been crazy. I am in the RSNA Daily Bulletin today. My work on search in radiology has been really well recieved. I will write alot more when/if things slow down. Looking forward to the blogger event tonight.
Monthly Archives: November 2006
Here is an article comparing Microsoft and Oracle’s security. The author of the report looks at patch count over the last 3 years and shows that Oracle has issued many more patches for security issues. While in the field configuration is equally important this does say something about how seriously the SQL Server team takes security. Kudos to them. The actual article is here.
Aunt Minnie has a brief article about MyPACS.Net (a teaching file) being integrated into GE Centricity. GE is also part of the IHE TCE demo at RSNA showing how any system can be used to author a teaching file. I recommend that you stop by and check it out.I hope you will come by and see it. I was involved in the project so this is also shameless self promotion.
Medgadget has a writeup on my favorite chair, the Verte office chair from Anthro. At the Baltimore VA Medical Center we have had the oppourtunity to try many of the best/ most expensive chairs on the market. This one hands down is my favorite. The chair is both comfortable and supportive. the Ability to customize the back with sections that align to the individual vertebral bodies in your back. If you get a chance to sit in this chair by all means give it a try.
One last note on chairs. Not all expensive chairs are good. You will not like all chairs. Evaluate a chair for a few days before you buy one. I cannot stress this enough.Tags: ergonomics, radiology, chair, verte
I have been working on some tools for RSNA’s MIRC project. These tools offer different ways of creating radiology teaching files. MIRC lacks a developer API such as a web services API that would make integration easy and maintainable. Instead all integration is done via custom HTTP POSTs. For the non-developer that means that the application is programmed to fill out the forms just like you do. This is less than ideal since if the UI changes that developer may need to rewrite their code to talk to MIRC. This brings me to the saga of the last two days.
All of my authoring tools were completed and ready for testing. I tested it on my developer machine extensively and everything worked great. I distributed the tools to the testers and nothing worked for them. I sat at their machines and tried to make it work to no avail. We downloaded and reinstalled MIRC to make sure that they were using the same version that I was. The version that was listed on the web site was T30 gamma.
A quick word on software versioning. Whenever a developer pushes out a new version the version number needs to be incremented. So if my product’s version is 1.0.4, indicating that I have 4 maintenance releases after 1.0.0, when I make another change such as fix a bug the version will be 1.0.5. This is very important so that users know that this version is different than the previous version.
So I went home to my development machine to see what the problem was. I downloaded and reinstalled the version from the web site on my machine. Then it stopped working. Thinking that this was bizarre I worked on debugging for a while and did notice a couple of problems. They didn’t seem to make sense though. Finally I compared both the original MIRC installation file and the new one that I had downloaded. Would you believe that they are different? The code in the one that I originally downloaded was created on 11/4/2006 and the new one was 11/9/2006. Two different versions of the software marked with the same version. A cardinal sin in software development.
If projects like MIRC want to be taken seriously they need to employ proper software development methods. A developer cannot just push out a new version because he feels like it or he has fixed some bug and leave it as the same version. Most open source projects have many versions listed on their web site, including all minor releases for things such as bug fixes. What this issue with MIRC illustrates is a complete lack of any release controls and complete disregard for people who write software that inter operates with it.
So Agfa has launched Impax 6.0 last year as a new version of their PACS. I met with some of their architects during its development and I was very excited about some of its features, such as its use of web services. There is a lot of functionality exposed through web services that can be tapped into through custom software, or better yet through orchestration platforms like BizTalk. It used LDAP for user management which means that single sign on is a possibility. So I was excited.
The installation that I watched was a disaster. Granted things are better now. I am not sure how some of the builds got out of QA. Part of me wonders if Agfa (and Agfa is hardly alone here in the PACS industry) has a serious QA effort. Now what I am going to say I relied on about six radiologists. All of that stuff I said about Impax being good as an IT system does not matter. The system was engineered without good workflow. Most of them considered it to be at best no better than the last version of Impax and at worst a moderately sized step backwards.
Today Agfa visited him to talk about his problems. I hope something comes from it. I want Agfa to be a competitive player. More competition will give us better products.
When people get married it is often after dating for a period of time that lets them get to know each other. It is important to pick a compatible mate for the long term. Buying enterprise software like PACS is basically the same. You and the software are going to wake up everyday and spend numerous hours working together. It is important to pick software that you will be happy to see every morning.
The selection process is partially about mitigating risks that a new system brings with it. As a PACS consultant I want the user to feel happy to see the system in the morning. No matter what I think of a system I am not the one that has to get up and use it. The client is. When a client asks what PACS system they should buy I will have them pick their top three systems from the users perspective. I will rank the same systems on many other criteria and give that to the client.
As facilities migrate toward PACS one of the key decisions that must be made is the monitor configuration. Most facilities that are going to PACS now will opt for 2 high resolution monitors and 1 regular monitor for worklist. At some older facilities such as the Baltimore VA Medical Center (one of the first sites to go live with PACS) you will still find 4 monitor workstations or 4+1 monitor workstations. This is partially legacy from the first generation of PACS systems. When the PACS was installed at the Baltimore VA in 1993 it was originally supposed to have 8 monitors in 2 rows of 4 to replicate a light box. A light box used to hold the film while a radiologist read them and it could typically hold 8 sheets of film at a time. Because of budget constraints one row of monitors was eliminated, leaving 4 monitors which is what was delivered.
So in 2006 PACS software has come in to its own and does not need more than 2 high resolution monitors. Software has overcome virtually any reason to need 4 monitors. If your PACS still wants 4 monitors you should look long and hard at alternatives the next time you are considering a major upgrade or the purchase of a new system.
The bottom line: There was no workflow reason for 4 monitors.