EDI WITHOUT an EHR-S

At the December CPTT meeting, Kedren Community Mental Health Center presented their approach to an EDI solution. It was a helpful presentation, in that it pointed out that there are alternatives to an Electronic Health Record System (EHR-S) purchase. However, I found it confusing because the presentation did not spell out the steps an agency would have to take to comply with the IBHIS EDI deadline without an EHR-S and it also did not discuss the workflow and other business benefits that an EHR-S brings. I fear that a few people left the meeting thinking they could get EDI certified tomorrow, and they probably don't even have a database!

Kedren has been developing their own database system for many years now and is also in EDI production with DMH for claims. They will need to develop the new transactions for EDI submission when IBHIS is ready. I am not sure how long it took or how much it has cost Kedren to develop their database system, but it was not a simple task. Kedren's solution is a "custom database" that produces an electronic health record (EHR) or some subset of an EHR, but it is not an EHR "System" as I have defined in my seminar series.

An EHR-"S" should provide your agency with many workflow, revenue, and compliance assurance benefits in an automated way. The EHR-S products on the market today typically come with functionality such as:

• Electronic scheduling (with compliance integration)
• Tiered user access controls (some by user roles, teams etc.)
• Structured treatment planning (with libraries someday soon
• Automated claims processing, with payor rules
• Paperwork due date tracking (some with cycle date automation)
• Alerts and reminders
• An integrated, simple report writer and standard reports
• EDI Translator capability
• Automated workflow assistance, such as co-signature routing

Let's also consider the fact that the EHR-S vendor takes on the burden of maintaining the product, enhancing it, fixing it, developing the EDI transactions and certifying them, keeping up with the technology advances in the industry, certifying through standards boides like CCHIT, and in some instances doing all the change management for you.


That said, Kedren is absolutely correct.... it is not necessary to purchase an EHR-S product to comply with the DMH IBHIS EDI deadline. So, I thought I would re-iterate the steps and trade-offs of implementing only an EDI solution, rather than purchasing an EHR-S. Please see my seminar materials and your notes from the presentation I made in September 2007 at ACHSA's first in the series of four held last year.

To comply with the LACDMH IBHIS EDI deadline, you will need:

• A Database (Db) to capture… Opening data for clients/episodes, Billing/claims data , and Clinical data, e.g. outcomes
• Database programmer(s) and administrators
• A Database server(s) and associated IT infrastructure
• An EDI transaction “maker” i.e. translator (ASC.12, HL7,and XML) to create the records in the appropriate format
• A report writer application & staff to use it

Kedren wrote their own database application, and hired a consultant to develop the EDI transaction maker.

Then you need to decide if you are developing a database application that a data entry team will use to enter all the required data, or an application you will deploy to your clinicians to do the data entry. These are completely different development efforts and I would highly recommend you avoid the latter.

In my mind, this puts you in the software development business. You will need much of the staff and infrastructure that an EHR-S vendor has in place to assure the application is functional, reliable, stable, and easy to use. You will need a development team with structured design/program/test procedures in place. You will need a testing team and test cases, to be run each time a new set of enhancement are released. You may need to get it certified through some of the standards bodies, like CCHIT at some point.

You can see where this is headed. It is not a simple effort and requires staffing, skills, process, and investment to do this right.

I believe that if you cannot purchase and implement a real EHR-S before the LACDMH deadline, which seems to be 2010 now, then you should use a Clearinghouse as an interim plan. Don't invest the time and money to develop your own product when there are so many good products and vendors on the market now. The agencies that developed their own database application and EDI translator, like Kedren, started this effort in a time when we had very few options. There were no viable low cost or mid-range products in California at that time. Times have changed and you have many choices and price ranges available.

Ask your top choice EHR-S vendor if they will implement a clearinghouse solution for you until you can afford to deploy to your clinical staff. I know that at least one is offering this approach. If not, find a Clearinghouse that will agree to handle all the transactions DMH requires. Then you are simply moving from the current DMH Clearinghouse model to another Clearinghouse. This will not solve any of the problems you are having now with your workflows, audits, or revenues turns, but might be a good short term plan.

by Keely McGeehan, Sahara Management Solutions, Inc.