Politics aside, this article provides some numbers on the actual costs of some healthcare procedures in the U.S., comparisons to the reimbursement amounts for these, and the “horse trading” to make some procedures more affordable (performed at a loss), while others are allowed to be more expensive (higher margin to subsidize the other procedures).
Medical imaging (MRI) is mentioned on the second page.
Some humor for my friends that can relate.
One thing I have noticed (and was commented on by an esteemed panelist at the SIIM Regional meeting) is the wide disparity of the number of IT and Admin staff working on medical imaging systems among similarly sized facilities. One hospital has 10 FTE, while a peer has 2 FTE. I can’t imagine that there are productivity differences to account for such a variation. I have to think that one is simply doing more work (quality control, systems integration, user support and training, etc.).
This begs the question: how many FTE is the right amount?
I have not seen anyone come up with a ratio of the number of FTE per exam volume amount, modalities, etc.
“PACS” is used well beyond radiology; how can they still own it? It is being decomposed into discrete services, but it still has to come together and be fast and reliable (software is only valuable if it is available and responsive when needed).
Integrating patient records (different patient ID domains, order schema, different procedure codes, etc.) is critical to a patient’s imaging record interoperability, whether it is to consolidate records to a shared system (e.g. imaging studies in a VNA), or at access time (on demand cross indexing when viewing studies from different patient ID domains).
For all the pages of must have features that fill a PACS RFP, most people I talk to would trade most of them for a fast PACS that never crashes.
I am attending the SIIM regional meeting in Philadelphia. Keeping the sword sharp by listening to experts talk about challenges in radiology and informatics. Good turnout. Great to see some friends.
Noted some increasingly commonly reported trends…
Part 2 of 2 of a SIIM blog post. Enjoy.
I have been discussing what it would take to create a “check list” of sorts (a scorecard?) to assess ones facility’s capabilities and strategies along the proposed themes listed. Would be fun to work on, but would need lots of help from people with bigger brains than mine. Stay tuned for a bonus Part 3, maybe? 🙂
P.S. Part 1 is here.
Without endorsing the product represented (I have not looked at it at), I think this blog post is covering some important points (and is well written, so do have a look).
Some thoughts, though…
Pet peeve of mine: The smartphone app metaphor is a bit overused in enterprise software that manages personal healthcare information. When a physician is making a life-altering decision about my (or my loved ones’) care, I would hope that they are relying on something with a bit more vigilance around it than something that they downloaded along with a Kanye West tune. I want something that is “battled tested” and properly integrated in the enterprise (see ITIL Change and Configuration Management) before being used clinically in the hands of healthcare providers. Call me paranoid.
Look, I get it. Users like downloading and using “apps”. But, the expression of desire for “apps” is properly translated in a desire for more flexibility and responsiveness from their healthcare IT vendor(s)–people like the personal experience of the control that downloading apps provides them and speed of innovation (with a decent platform, apps can be developed with massive parallelism–think Army of Nerds) , but if Angry Birds makes a mistake, no one dies (well, a bird, I suppose–never played the game so I am only guessing).
I may get some flame mail from respected friends for this one: open source applications are also not the (complete) answer. Sure, its fun to be able to change and extend source code (and to become a hero by fixing bugs yourself instead of waiting for a fix from your vendor), but for every “coder” I have met only a small percentage that really understand the full scope of work of professional software development required to produce an application to the quality we need in healthcare. Don’t get me wrong: I love hackers. They break through barriers and solve problems with practical methods. But, their output typically needs a lot more work to make something that is production ready. Great power, great responsibility, and all that.
The reality is: we don’t need a bunch of user-downloadable apps or developer-modifiable source code. We need APIs. Good ones. REST-based Web service APIs. Documented, well-designed and tested. Supported. Unbreakable, secure ones.
When done right, APIs are contracts. Promises. They aren’t some side-door or limited set of functions added as an afterthought. They become the language by which applications speak to each other, even internal parts of an application.
Healthcare standards like DICOM and HL7 standards include APIs, just ones based on older technologies and protocols. The information model is still pretty solid, I would argue, so we don’t need completely new “words”, just some different ways to communicate.
Oh, and products with great APIs are generally higher quality because it is much easier to write automated tests to beat the crap out of them before unleashing them on to the world.
More on this topic later.
I enjoy articles like this because so much focus is on the expected benefits of healthcare IT, but as the old marketing tale goes, sometimes ‘the dogs just don’t like the dogfood’. If users won’t use the tools, the outcomes won’t be realized. As is often the case with products, the specialist is not well understood or served. The same applies for imaging consumers–the average imaging consumer using an EHR is quite different than the specialist that needs advanced visualization, navigation and measurement tools. Niche vendors will attempt to fill the gaps.
Most EHR user interfaces resemble an electronic filing cabinet, organizing information by type or service / organizational unit that created the data. Vendors could learn a lot from the design of social networking platforms, which are quite adept at coordinating activities in complex interactions among disparate users.
Have a read (may need an account).
Some thoughts…
Worth a read (note: you may have to have an account on the site, but I believe it is free). Covers a lot of history and provides a sobering perspective of state of Radiology today…
Economically, radiology experienced a classic bubble in my 30 years as a department chairman. Tailwinds from new technology increased both the demand for imaging services and reimbursement per average case. These were coupled with increased efficiency from PACS, and led to remarkable increases in departmental income and compensation for individual radiologists.
While the economic vectors were all pointing up, we were lulled into thinking this was the way things were always going to be — and should be. Wrong. As soon as imaging became the fastest-growing cost segment in healthcare, the knives came out and reimbursement cuts began, however flawed their logic. The bubble burst.
Don K Dennison 
