3. Create a one size fits all EMR system

Here is another one of those statements that fly in the face of all the pundits out there who state they are experts on EMR. This also is in opposition to what the government is supporting. I understand the thinking. It goes something like this. EMR is an expensive proposition. We need to make these systems cheaper if we want adoption. How do we make t his digital conversion cheaper? One way is to have many physicians share the same system. Increase volume use can reduce prices. One method is using a SAS or ASP model. SAS stands for Software as Service (Wall Street Loves this) This is subscription based product that allows the provider to pay a monthly fee and reduces the overall entry cost to EMR by sharing hardware with others, not having to pay for on site IT support and only pays for what you need when you need it. ASP or Application Service provider is the same concept. It is a subscription based model where a provider pays monthly. The real savings for this type of service is in volume so it is important that you have many customers sharing the same data center, same applications etc. Obviously the assumption being made here is that it is possible to standardize the hardware, communications systems and the software that physicians use.

In my opinion that is where this concept breaks down. First, the most difficult EMR software to develop is primary care or internal medicine software. The reason for this is the breadth of services these professional have to offer. One patient could have ear infections and be 4 years old, the next could be a 55 y ear old with Angina and the next patient could be 80 years old with colon cancer. We worked on the knowledge base and workflow for Cardiology services for years before we got a comprehensive knowledge base and workflow tools. In my opinion that same process needs to take place for every single specialty in medicine (ie., pulmonary, Oncology, Orthopedic etc.) and then and only then will you be able to create a truly efficient EMR that reduces the physicians time to care for patients and increases their efficiency. I will also state categorically that I am biased because I sell a single specialty (Cardiology Specific) program. But I have some support for what I say. We are a small company, our product is arguably considered the premier product for Cardiology in country. We have sold more totally integrated Health information systems to Cardiologist then all our other competitors who are very very large companies with Market and selling budgets larger than our whole company. How can we do that? Our product is not cheaper then theirs? We have 1 sales person to 1000 of theirs. We can do it because our product works the best for Cardiologist. It is specialized for the Cardiologists. I dear say if I could solve the cost problem for them we could increase adoption tremendously. It is also why we don’t have large scale adoption because a general EMR does not make the physician more efficient it makes their job harder and requires the provider to customized the product to fit their knowledgebase and their workflow.

One interesting fact I discovered in two different EMR conferences was the length of time it took most practices to become fully implemented (every employee and every physician using the product). We went to two different national conferences where 4 of the top sellers in Cardiology EMR’s brought in two customers to present about how they selected their product, how they implemented their product and what kind of Return on Investment (ROI) they received. The interesting thing to note was that of 8 groups that presented only 2 (our customers) were fully implemented. Also interesting these groups all started the implementation at roughly the same time and it was three years later. It is hard to get an ROI when in less than 5 years when it takes over three to come up on the system. Why so long? There are lots of reasons. Some groups want to come up slowly because it takes internal resources, but a good deal of it is that the system is too generic and not specific enough for their workflow. Thus, they have to “build” their own version of the EMR with their language and workflow units and that takes a considerable amount of time just to get it so the practice can use it. Having a generic EMR is like saying I have a hammer and everything else must be a nail. Unfortunately it is not that simple.