Submit your article of up to 500 words in length, subject to editing for clarity and brevity. Use your real or phony name (your choice). Submissions are subject to approval and become the property of HIStalk. Thanks for your thoughts!
Yes, it’s true. There is a monster in the jungle and he is devouring all that is creative and laying waste to the brilliant small companies trying to lead the way in HIT development. Only the giant dinosaurs will be left the divide up the swamp once the blood bath is over. We are doomed, the sky is falling, and the Mayan prophecies of the end of the world are coming true.
That seems to be the belief of those who rant and rave against the presence of the CCHIT.
I beg to differ. I remember all too well when there were NO STANDARDS. I remember physicians being completely at the mercy of salesmen with slick demos (now they are at least somewhat less subject to the snake oil speech). I remember the industry making minimal progress on interoperability until it became a standard. I remember when there was no forward pathway that gave any indication of where EHR development was headed.
Say what you will about the CCHIT. I have found it to be an extremely transparent organization that is helping level the playing field and make it safer for clinicians to take the plunge into electronic records. In my experience, the staff at CCHIT has been incredibly responsive and helpful providing answers and directing me to clarifying resources. They set the standard on credibility. Certainly more open, helpful, and responsive than any major EHR vendor I have every contacted for support.
So there it is. You can throw stones if you wish, but you ignore them at your own risk. The CCHIT is here and is becoming ingrained in the road that lies before us. As Dylan said, “You don’t need a weatherman to know which way the wind blows."
ICD-10 Risk Assessment
By Art Vandelay
Discussion around this topic will benefit us all.
With the changes to the ICD-10 coding scheme, I have classified our systems into four categories – highest risk, moderate risk, low risk and no-risk.
I determined the categories by considering a few areas of risk: (1) the perceived impact to their applications’ architectures; (2) perceived capability of the vendor to handle these types of changes based on past experience with HIPAA and Y2K; (3) the vendor’s ability to share a plan for ICD-10 (few have been thinking ahead); (4) the vendor’s use of ICD-9 in application and interface logic, such as order checking rules and code-to-procedure checking rules); and (5) the use of discrete ICD-9 or groups of ICD-9s to drive key reports.
After considering the areas of risk, our main ancillaries (pharmacy, surgery, pathology, radiology) and revenue cycle add-on products are in the highest-risk category. Also in the category is our EHR. This was only due to the decision rules around the EHR and the way the department-focused portions of the EHR are used. It could be much worse here if we were using more reporting or decision rules. The revenue cycle add-on products are the most troubling. These include claims scrubbing, coding rules, and charge edits.
In the moderate risk category are our revenue cycle, scheduling, medical records, and decision support products. The revenue cycle vendor has a decent plan in place.
The low-risk category includes many of the biomedical and patient education applications. These applications do not have much logic associated with a diagnosis. They also do not send interpreted data outside of the system. Some raw data without diagnoses is sent.
The no-risk category includes our enterprise resource planning (ERP) systems and document imaging system.
ICD-10 also enables the HIPAA-compliant claim attachments. We have not performed this risk analysis, but believe our EHR product will help. My fingers are crossed.
Because of this change, the independent physicians may start to approach the hospitals for some EHR-Practice Management system donations under the Stark and Anti-kickback law changes. This will place the hospitals in the unenviable position of thinking about themselves and their projects versus keeping the physicians happy. It could also impact the forms, order sets, and other data to be built in these applications because there are more possibilities to consider.
We have added ICD-10 contract language to our list of the usual items we negotiate with both our systems and medical devices. This mirrors our HIPAA and Y2K language.
By Clinton Judd
Last week, Otis Day clarified his positive comments regarding Soarian development to say he meant Soarian Clinicals, not Soarian Financials (SF). He went on to say, "I do agree that Siemens is looking to improve short-term and milk INVISION. And why should Siemens care, or the customer, for that matter? If the customer is happy (and paying their invoices), where’s the problem? Does Mr. Judd suggest this is a negative situation?"
Soarian Cynic answered this in Monday’s HIStalk by detailing how his hospital has waited six years for SF and they were recently told to wait at least two more (and asked to extend INVISION for at least five more, just in case). This is two years before SF is ready for them to start implementing. Hospitals have been hurt by the delay. They have been sold on the functionality to come in SF and, as a result, accepted that INVISION would stop being enhanced (not sunsetted, but few significant enhancements in years).
If hospitals had known in 2005 that they wouldn’t have an integrated contracted management system or an integrated EMPI until 2012, they may well have solved their revenue cycle challenges with Eclipsys’ Sunrise Financials (formerly SDK) or they might have invested in bolt-ons to INVISION to get them the process improvements they sought. Waiting for Soarian Financials has frozen some hospitals with respect to patient access and revenue cycle improvements at a time when they desperately need to improve and be efficient. CIOs (particularly ex-CIOs) have been hurt by the Soarian delays, too.
Despite still collecting high-margin INVISION fees, Siemens has been hurt, too. For example, Monday’s HIStalk mentioned Oregon Health Sciences’ (OHSU) implementation of Epic to replace A2K and LCR (A2K is OHSU’s name for INVISION). Siemens lost a very big customer there to Epic. Soarian simply wasn’t ready to compete with Epic and a number of other very large accounts nationwide have or will make the same decision to stop waiting and go with Epic. Similarly, I have heard (second-hand) that MedSeries4 has lost a number of customers to Meditech in recent years. Perhaps Soarian would have helped there too.
The difficulty with Soarian Financials isn’t because there aren’t a whole lot of good people trying hard. Siemens has invested a ton in this effort (I think SMS started the effort in 1998). The challenge is that Siemens is replacing INVISION.
INVISION certainly has its weaknesses and shortcomings, but customers have done a lot with it. It is surprisingly flexible and open to integration, if you have the skilled resources. This flexibility will make (has made) it very hard to replace. It’s the hospital’s billing system, so any replacement has to do everything INVISION does plus more. SF not only has to be a super, everything-to-everyone solution, but it effectively has to be backward-compatible too.
Oh, and it needs to keep up with the market too. Ten years ago, it didn’t need a patient portal for billing and self-scheduling, but it needs one now. Five years ago, it didn’t need registrar score cards; it needs them now. Three years ago, it didn’t need a patient payment estimator, but it needs one now. These are all bolt-ons Siemens’ customers keeping connecting to INVISION and now want in SF or require SF to integrate to.
The goal line for Soarian Financials keeps moving back. I don’t envy SMS/Siemens for having to create a replacement to INVISION.
Siemens has done much better with Soarian Clinicals, as Otis Day commented on. Soarian Scheduling is more like SF; at least one regional medical center de-installed Soarian Scheduling after just months of use for scheduling radiology.
When Soarian Financials is finally ready (however ‘ready’ is defined), the next challenge for Siemens and its customers will be the conversion process. Implementing SF is a massive, long project — a 24-month effort? It is supposed to replace the entire revenue cycle, soup to nuts. Everything. Siemens probably still has 400-500 hospitals using INVISION. How many can they convert/implement a year? If they can do 50 a year (one a week), they’ll need 8-10 years. That’s IF they could do 50 a year. If anyone has heard Siemens’ answer to this conversion/implementation effort, I’d be interested in what they think they can do.
So, Soarian Cynic, if I were your hospital’s CFO, I’d either sign up for five more years of INVISION (maybe get a better price for seven years) and beef up your bolt-ons (there are great solutions available to enhance your access/revenue cycle processes).