Comments on: Monday Morning Update 12/3/07 http://histalk2.com/2007/12/01/monday-morning-update-12307/ Healthcare IT News and Opinion Fri, 20 Nov 2009 22:30:54 -0400 http://wordpress.org/?v=2.8.4 hourly 1 By: Martin Jensen http://histalk2.com/2007/12/01/monday-morning-update-12307/comment-page-1/#comment-479 Martin Jensen Tue, 04 Dec 2007 16:44:41 +0000 http://histalk2.com/2007/12/01/monday-morning-update-12307/#comment-479 "The challenge is understanding the “rules” as determined and sometimes published by the payers." Yeah, that's one of the principle things my little design addressed. But trying to sell it got so tiresome and time-consuming: In order to protect your IP, you have to gain an audience with the vendor without really telling them too much of what it's about, then you have to go through signing NDA's, etc, just to get a chance to present it. Then they might take awhile to decide whether it's of any interest. You still haven't talked about money, and that whole thing consumes lawyer bills and more months go by. We subsequently had a similar experience with an NPI tool. A few lookers, no takers, months went by, and the indstry proceeded in its dysfunctional way without our help. We've discussed a business model we describe as "open source think tank," whereby we would simply conjure such designs and commit them to the public domain: "This idea is free; but if you want our help making it work, it's gonna cost you." We've compromised by putting some of our best ideas into bite-sized packages (webinars, white papers) and selling them for a tiny fraction of what it would cost someone to "own" them. We'd rather the ideas themselves grow in lots of gardens anyway. We're not really looking to make a fortune. That may put us in a position to be exploited, or it may put us in a position of power. Art -- you are really a treasure. Your broad experience and incisive analysis is like plant food. Please keep publishing; we promise to keep reading. Marty “The challenge is understanding the “rules” as determined and sometimes published by the payers.”

Yeah, that’s one of the principle things my little design addressed. But trying to sell it got so tiresome and time-consuming: In order to protect your IP, you have to gain an audience with the vendor without really telling them too much of what it’s about, then you have to go through signing NDA’s, etc, just to get a chance to present it. Then they might take awhile to decide whether it’s of any interest. You still haven’t talked about money, and that whole thing consumes lawyer bills and more months go by.

We subsequently had a similar experience with an NPI tool. A few lookers, no takers, months went by, and the indstry proceeded in its dysfunctional way without our help.

We’ve discussed a business model we describe as “open source think tank,” whereby we would simply conjure such designs and commit them to the public domain: “This idea is free; but if you want our help making it work, it’s gonna cost you.” We’ve compromised by putting some of our best ideas into bite-sized packages (webinars, white papers) and selling them for a tiny fraction of what it would cost someone to “own” them. We’d rather the ideas themselves grow in lots of gardens anyway.

We’re not really looking to make a fortune. That may put us in a position to be exploited, or it may put us in a position of power.

Art — you are really a treasure. Your broad experience and incisive analysis is like plant food. Please keep publishing; we promise to keep reading.

Marty

]]> By: Art_Vandelay http://histalk2.com/2007/12/01/monday-morning-update-12307/comment-page-1/#comment-478 Art_Vandelay Tue, 04 Dec 2007 01:05:21 +0000 http://histalk2.com/2007/12/01/monday-morning-update-12307/#comment-478 Martin - actually, I read your post a few years ago and found it very accurate. In interest of being succint, I didn't post all aspects. Rules engines combining clinical and financial data will be critical. The challenge is understanding the "rules" as determined and sometimes published by the payers. Regarding ICD10 - the sheer number of codes and the nature in which codes can be combined can cause issues for user interface designers. A character based screen is not likely going to be able to deal with this well. A pure web GUI still calling traditional transactions (CICS) will likely have some issues. Martin – actually, I read your post a few years ago and found it very accurate. In interest of being succint, I didn’t post all aspects. Rules engines combining clinical and financial data will be critical. The challenge is understanding the “rules” as determined and sometimes published by the payers.

Regarding ICD10 – the sheer number of codes and the nature in which codes can be combined can cause issues for user interface designers. A character based screen is not likely going to be able to deal with this well. A pure web GUI still calling traditional transactions (CICS) will likely have some issues.

]]> By: Martin Jensen http://histalk2.com/2007/12/01/monday-morning-update-12307/comment-page-1/#comment-477 Martin Jensen Mon, 03 Dec 2007 19:10:18 +0000 http://histalk2.com/2007/12/01/monday-morning-update-12307/#comment-477 I reflected on Art's CRM update in the context of the higher-order payer claim editing systems. Not as cynical about the economics of a solution as Frank, however. And even if costs $20M, that pales in comparison to what provider stand to lose -- and what they are already losing, without being aware of it. See http://blog.hittransition.com/2007/12/denial-engines.html Marty I reflected on Art’s CRM update in the context of the higher-order payer claim editing systems. Not as cynical about the economics of a solution as Frank, however. And even if costs $20M, that pales in comparison to what provider stand to lose — and what they are already losing, without being aware of it.

See http://blog.hittransition.com/2007/12/denial-engines.html

Marty

]]> By: rcm http://histalk2.com/2007/12/01/monday-morning-update-12307/comment-page-1/#comment-475 rcm Mon, 03 Dec 2007 15:45:58 +0000 http://histalk2.com/2007/12/01/monday-morning-update-12307/#comment-475 20 mil..+ maintainance That is where the business case is..They are thinking to install , implement and maintain the systems in future under 15 mil. So even as prices of all increase, the price of these apps will not go up. That is the basic business premise. It works well for vendors too. Imagine hiring and maintaining mumps and cache programmers in 2016. Thats not much ROI for the vendor at all. 20 mil..+ maintainance
That is where the business case is..They are thinking to install , implement and maintain the systems in future under 15 mil. So even as prices of all increase, the price of these apps will not go up.
That is the basic business premise. It works well for vendors too. Imagine hiring and maintaining mumps and cache programmers in 2016. Thats not much ROI for the vendor at all.

]]> By: frank POggio http://histalk2.com/2007/12/01/monday-morning-update-12307/comment-page-1/#comment-474 frank POggio Sun, 02 Dec 2007 22:32:22 +0000 http://histalk2.com/2007/12/01/monday-morning-update-12307/#comment-474 Re: RCMs. I had an article published in Healthcare Informatics in 2002, and did a HIMSS presentation on it that year. In summary I stated that vendors have not & will not (or very reluctantly) invest in new rev cycle systems for the following reasons: 1. It is a 100% replacement market, and the revenue and ROI on a new rev system is far less than on clinical systems. To design, develop, and test a new re cycle system is a minimum $20 mill project. I know I’ve done several in my career. 2. The maze of billing regulations across states is a software maintenance nightmare and nobody really wants to pay very high maintenance fees. 3. CFO’s are a conservative bunch and do not want to risk increasing receivables that ALWAYS happen in conversion. (Note Epic’s requirement that there is no conversion of AR, just keep the old one running even if it costs you double!) 4) Most hospitals have around 50 days in AR, so they think the old system is OK. But they will not acknowledge they have hundreds of extra back room staff filling holes in old systems. 5) The easier route for most CFO’s is bolt on and more bolt-ons. Nothing much has changed in 5 years. My suggestion to a CFO in a larger facility that really wants a state of the art RCM System to reduce staff and not have to wait another 5 years for a vendor to deliver is:…hold on…your not going to believe this…WRITE YOUR OWN for your local billing requirements. Then use a bunch of vendor bolt-ons for everything outside of the business logic of generating and printing a bill. With the tools available today for system development, such as rules engines, writing your own bill generator is not that difficult. Anyone interested? Re: RCMs.
I had an article published in Healthcare Informatics in 2002, and did a HIMSS presentation on it that year. In summary I stated that vendors have not & will not (or very reluctantly) invest in new rev cycle systems for the following reasons:
1. It is a 100% replacement market, and the revenue and ROI on a new rev system is far less than on clinical systems. To design, develop, and test a new re cycle system is a minimum $20 mill project. I know I’ve done several in my career.
2. The maze of billing regulations across states is a software maintenance nightmare and nobody really wants to pay very high maintenance fees.
3. CFO’s are a conservative bunch and do not want to risk increasing receivables that ALWAYS happen in conversion. (Note Epic’s requirement that there is no conversion of AR, just keep the old one running even if it costs you double!)
4) Most hospitals have around 50 days in AR, so they think the old system is OK. But they will not acknowledge they have hundreds of extra back room staff filling holes in old systems.
5) The easier route for most CFO’s is bolt on and more bolt-ons.

Nothing much has changed in 5 years. My suggestion to a CFO in a larger facility that really wants a state of the art RCM System to reduce staff and not have to wait another 5 years for a vendor to deliver is:…hold on…your not going to believe this…WRITE YOUR OWN for your local billing requirements. Then use a bunch of vendor bolt-ons for everything outside of the business logic of generating and printing a bill. With the tools available today for system development, such as rules engines, writing your own bill generator is not that difficult. Anyone interested?

]]>