Active Forum Topics | Getting Started | Interviews | EMR Forum | Medical | Billings | Press & News | Voice Recognition | The Water Cooler
Kaiser Permanente seems to be in big trouble because they chose EPIC as their EMR. EPIC seems to be ducking comment and blaming Citrix. Here are a number of items related to this.
Kaiser has asked its IT staffing vendors to reduce their rates by up to 40 percent, according to a confidential memo obtained by the Business Times. This was in July - the sign of trouble coming.
Kaiser CIO Cliff Dodd resigned amidst a thicket of finger pointing about Kaiser Permanente's 7 billion dollar financial implosion. Happened last week after the loss announcement.
A 722-page report compiled by Kaiser’s IT department details hundreds of technical problems with the system, based on technology from Epic Systems Corp — some affecting patient care.
It appears the software was written in MUMPS (Massachusetts General Hospital Utility Multi-Programming System) -- a health care programming language originally developed in the 1960s. Is the EPIC system just a rework of the VA's Vista EMR ?? Using a programming language written in the 60s and no longer actively being developed should have sent a lot of red flags!!!
Kaiser employee Justen Deal stated in an email, “Epic simply cannot scale to meet the needs of Kaiser Permanente. We’re wasting billions of dollars trying to make it. The big issues for me are the financial repercussions of trying to launch such an ineffective and inefficient and unreliable system across the organization.”
Deal also said that the Citrix scalability issue is significant. Deal argued that “using Citrix is something that defies common sense. It would be like trying to use a dial-up modem for thousands of users. It’s just not going to work. I don’t think that Citrix really appreciates what we’re trying to do with their software.”
Bottom line, EPIC may have been a big company (this may make them a small company again) but the whole premise, the underlying system architecture premise is wrong. It is based on old legacy technology ( and in this case really old) which can not possibly support a decent EMR. Some on this forum board think I am arrogant, but only because I believe the "the user is NEVER wrong, if the user has trouble - it is not more user training, or more support, or more system "tweaks", or more whatever - other than more care in understanding the user and using appropriate technology for the user.
Most EMRs (not all) are guaranteed to be a pain because they have the wrong premise - forget ASP, point and click and all the fancy certifications because they mean nothing if in the real world the user is treated like a young school boy who needs to be patted on the head and told they don't understand!
Yes I understand some have an EMR they are happy with, but we are not going to get to a national system or widespread adoption if we continue to use old technology and design. Kaiser is only 400 hospitals and just over 50,000 doctors(??) If this doesn't work how are we going to make 6,000 hospitals and 800,000 work together?? The answer is new innovation in design and technology – its the only answer.
Medscribbler Getting you there sooner!
Scriptnetics
866-350-6337
gidoc:We use Epic in our hospital. It works well for inpatient but I never liked the outpatient version.
You have "hit the nail on the head". Surveys have shown that most EMRs are under utilized, docs generally use them mainly in hospitals where maybe only a few features are used. The three that are used mainly are scheduling, lab result management and order entry. Many hospitals have an EMR with only clerical entry of lab results and scheduling. Some may not do order enrty but discharge summaries only. A few also use inventory management (especially drugs) Bottom line, medicine is very complex - not every educated person can be a doctor. So in this complex enterprise many try to write software without either understanding the limitations of software and computers or the needs of the user.
The Kaiser installation is bad from the conception using inapprobriate technology, it is also why the system at your hospital seems to be disconnected between inpatients and outpatients. Medscribbler is small, our largest install is 17 providers. We have many, many using our free version. We are waiting on the day for a large hospital or group to work with us for a complete system, because we would never do the things that are obviuosly not going to work economically.
We get calls all the time of doctors who recognize their hospital EMR is not being fully utilized or will not be able to be expanded beyond a small subset of use. If you recommend a system that costs millions and a lot of time by a lot of people to learn, it is impossible to admit it was wrong (and risk your job) and to move on. Many are in this boat now, Kaiser was and is and the longer they go without admitting the mistake the closer they come to the famous chapter in the book.
The technology paradigm changed in the last quarter of 2002, it may take time but eventually all EMRs will use embedded handwriting on Tablets running wirelessly over secure VPNs, many now are "work arounds" for lack of mobility, flexibility and security in the underlying technology. Like I tell my kids "The 60s didn't happen until the 70s" Medscribbler is a flowerchild who is starting to grow up.
sounds like an EPIC tragedy.
I liked Medtuity for KP. No Upfront costs. Vendor has to perform or you walk.
Easy Math.
How many millions of dollars would have been saved with my suggestion ? Calculator anyone ?
:)
The lesson here for the little guy is :
Avoid Upfront costs.
Monthly contracts are the way to go.
If your vendor won't do a long term contract with lower upfront costs: walk.
My EMR is: Synapse It is what we know already that often prevents us from learning. Pioneers are the ones with the arrows in their backs.
Disclaimer: I am the founder of e-MDs - highest rated EHR in 5 consecutive AAFP and ACP physician surveys
DrMurdoch:sounds like an EPIC tragedy.I liked Medtuity for KP. No Upfront costs. Vendor has to perform or you walk. Easy Math.How many millions of dollars would have been saved with my suggestion ? Calculator anyone ? :)The lesson here for the little guy is :Avoid Upfront costs.Monthly contracts are the way to go.If your vendor won't do a long term contract with lower upfront costs: walk.
Sheez. Things never change around here, do they? Y'know, Ive learned a lot in helping our group find an EMR . I come back here to find that it's the same old story. Everyone is a critic, but no one has any answers. You'll bash the big players with impunity, but when we were looking for a company to scale to our group, we saw vendor after ventor make huge promises, but fall far short of the mark.
Cyath,
I do wish that we had some techies from the biggest vendors (ie, EPIC) on this forum. It would be educational to hear the problems of such grand scalability.
In our (Medtuity's) small world of aggregating data from our largest user's 6-8 sites to a central server, I have learned some lessons.
First, as EMRs grow in power, particularly the power that users want, the SQL server must do more and more work. It's frankly, an enormous amount of work. For example, consider a small problem. A physician would like to see a pt's meds list, but simply as a list of meds that allows quick review. (To do otherwise, is too much info). Sometimes though, a physician wants to know how many times he's prescribed that Percocet, or that sleeper, or that anti-anxiety med. Instead of looking through all of the charts, wouldn't it be nice to simply hover over that last script written for Percocet, and as you hover all those details are shown. Move your cursor and the information disappears. It offers no clutter and immediate feedback. To accomplish that requires a huge amount of work by the server in that split second while hovering: examine perhaps a dozen tables, compile that info into a list, and display it in a hover window.
But the physician also wants to know if the patient suffered any side effects from that BP med that was discontinued. Again, it's very convenient to hover and see, but that's lots of work for the server.
Take that small user interface feature and multiply it x many features, then X many users X many facilities and it's hard to imagine a server farm fast enough to service all of these users. Thousands of hits per second requiring the joining of dozens of SQL tables. Worse, taking those first 20 minutes (maybe at 9:00 a.m.) when thousands of offices open simultaneously, with thousands of user automatically receiving their messages, with hundreds of thousands of health maintenance guidelines being calculated, thousands of simultaneous logins, etc, etc. Wow.
MedtuityEMR can handle 250,000 patients in our largest database. That we know. I cannot imagine providing the same response with millions of patient encounters and several hundred thousand users. It just seems obvious that you would want a local server(s) to handle the second-to-second and minute-to-minute server hits for each facility, but a mothership server where data is aggregated. There is too much work, too much data. Additionally and worse, it constrains EMR development because you must always consider the server load.
But there is no one on this forum with which we can have this to-fro argument because no one has that level of expertise. And ambulatory medicine is so different than any other database work-- you're talking scores of signs and symptoms, scripts, possible drug interactions, lab tests, imaging studies, health maintenance guidelines, followup plans, work/school excuse, ICD-9s, CPTs, E&M coding algorithms, reminders, alerts, and a host of other information flows going on concurrently. It's not as simple as a banking transaction or a bill payment over the Internet.
I know some people who recently started at EPIC (in the last month or so), but I haven't talked to them since.
I worked at a place that developed their own EMR (and lab and HMO software and payroll and ...). We had somewhere around 2,000,000 patients in the database as I remember (something like 360,000 seen per year and 1,700,000 encounters per year) and something like 700 drs. 8 or 9 am was certainly not the peak load time on our systems. The load tended to be bimodal with peaks at say 10:30 and 2:00 (or so).
It seems to me that it is not nearly as difficult as something like Amazon*. The one big thing that EMR systems have going for them is that there are few or no queries that involve multiple patients (in a complex way; showing a bunch of patients' name in the doctor's schedule doesn't count). That would say to me that it would be trivial for most systems to have two servers one with odd patient numbers and one with even (that of course decreases availability...).
* Now in realtime being able to be doing the "Customers who looked at this ended up buying..." thing for millions of customers, that requires some effort.
John
John,
Which pts are on the schedule is the least of your problems in a SQL lookup. That is a trivial query.
I think you are looking at clinical data as simple paragraphs of text that are easily queried and loaded.
When you start talking about clinical data, you might want to consider the server task of an INNER JOIN on about 30 tables having to do with clinical findings for a particular pt with particular demographics, on a half dozen meds, with a dozen problems on the problem list, 4 allergies, a couple of prior surgeries, a smoking and drinking hx (and other social items), family hx of 1/2 dozen disease, on at least ten different health maintenance guidelines (including age-related, disease-related, meds-related, and gender specific), and on and on. And then query the system so that you can have the ROS compiled in a granular fashion from the last 4 visits, and include the "auto-import" items that you flagged on all prior visits, and have your favorite templates that you use with this patient loaded too.
I'll agree with you that the query is trivial if the information is not granular (ie, stored in a big paragraphs of text), but when you offer granularity to the depth that EMRs should, these queries can become burdensome to a server.
In short, the more granular, the greater the versatility of the software, but also the greater the load on the server. That load should be distributed because (1) servers are cheap (2) the load is greater with increasing granularity leaving you little choice, and (3) synching can be done to the mothership when the encounter is complete (or some other pertinent event occurs). It seems that to do otherwise will limit the design of the software.
I wonder if you're making it too hard. Rather than doing a gazillion joins on 30 tables, it seems to me a more atomic approach may be easier to implement, and puts less load on the database servers.
Graham http://www.synapse-ehr.com/ Synapse - the EMR for the superior physicianhttp://www.onhealthtech.com/Health Tech Discussion Board
CEOMike, maybe if you had an idea of what some of our requirements were, you might understand whether or not your firm could scale to this degree.
We have a cachment area of over 200,000 patients. When one of those patients walks into one of our office, we want the EMR to know who that patient is without the staff having to create a new electronic chart. That is, the EMPI number has to flow with the demographics right into our EMR.
Every single patient has to have but one unique chart. So when little newborn "Johnson, Baby Boy" is discharged from the nursery and shows up in my office a week later as "Johnson, David", he's already got a chart. When I get labs and xrays in my inbox via the interface, I want to be able to sign and forward the results to 4 or 5 of my colleagues who might also see that patient, likewise for sign and review.
When any one of the 6000 docs in the outlying area order labs on my patient, I want those results to flow to my inbox without the ordering doc having to cc me on the order. When an outlying specialist such as a cardiologist orders labs or a cardiac diagnostic study at the hospital for one of my patients, as the primary care doc, I want the results to flow directly to my inbox for review.
When my patient is seen in the ER or is discharged from the hospital, I want the ER report and the the D/C summary to be in the patient's chart before they follow up with me.
When I go on vacation, I want to be able to proxy my email inbox and orders to my partner while I'm away so the staff doesn't have to figure out and track down who's covering for me.
When any one of the patient's from one of my 100+ partners shows up in the Urgent Care when I'm on call, I want the complete chart available. Likewise, when any on of my patients shows up in the ER, I want the ER doc to have complete access to the chart.
I don't want to have to create ANY new clinical templates for anything I might see as an FP (or Peds or IM for that matter), but I do want to be able to modify any template to just the way I like it, and then share it amongst all my partners so that they can use it or further modify it and re-post it for general consumption. I want to be able to capture data primarily through point and click, but also via HR, Dragon and keyboard- in any field, at any time.
Now, substitute "we" everywhere I said "I", and you know what we're looking for.
So, can MedScribber deliver on that RFP?
That was my point. A schedule lookup is trivial. Almost nothing else at all involves multiple patients and is therefore perfectly parallelizable by dividing patients in almost any way (terminal digit, hashing, facility). Facility seems like one of the trickier ways to do it. The system I was involved with did not do this. It was split by system. The core EMR ran on one server; the lab system ran on another; the meds and portal were on others; PACS was on others. This is probably sub-optimal, but good enough.
The main synching problem would seem to me to involve the very common situation of a patient who sees several doctors during a visit. Can the second doctor for example see the drugs prescribed by the first one if they haven't "completed the encounter"?
No, I am not thinking about text at all. I had absolutely no involvement in the text portions* of the EMR. I was largely involved with prescriptions and drug inventory, etc. This involved a number of tables and lots of joins doing drug-drug interactions, estimating cost, etc. I would bet I have typed INNER JOIN as many times as anybody here. :)
* The system's text was stored as one big text (older) or xml (newer) blob per document in a non-SQL-based database. All documents since 1992 are online. Most of the documents are generated by dictation. Much of the templates and imports and things are focused at the trasnscriptionists not the doctors. This is at least partly because the transcriptionist are in-house do a good job and many have been with a set of doctors for many years and nobody would be crazy about firing them all or anything. If the doctors are feeling extra crazy they can (and sometimes do) listen to the un-transcribed audio before it is transcribed.
cyath, "are you talking to me, are You talking to me"
Matt understands the problem and has what should be the underlying premise of any large build right. For Medscribbler with the embedded handwriting and the problems on the server load associated with this we have given much thought to this as well. Basically for an EMR, the computer and OS technology is not at a point of plug it in and it will work. This was the EPIC/Kaiser downfall. It takes extrapolating the EMR load use on the server of tens of thousands of users from what just one user does.
Johnmoe suggestion of use not by facility would break down on the lab results because of its size in relation to many of the other parts, you could keep spliting it up ie. blood work but this is really just a "tables" method that would eventually become too complex to manage on a large scale and is probably what EPIC attempted.
At Medscribbler there are two ways we might handle it.
First, we might have distributed server farms at each facility that would "report to" a data center in a push/pull. Yes this is complicated but it is the only way to handle the complexity of calls to the very large database with any speed and security. This would work as most patients use the same facility all the time. The "super" data base would only be needed for the moving of a patient from one to another facility, indexing, data mining and "super" backup.
The second way would be to do what EPIC was likely trying to do with Citrix. We would have a central DB that "indexes" the patient data on all the distributed facility systems with each sepearte system having access to the data through the index. Sort of how the Internet works.
There are other problems that have nothing to do with technology that explain some of EPICs problems. Centralization sometimes is good, but if you have to call a call center and put in a "support ticket" when you can't get the Rx history for a patient and it is responded to in 45 minutes you will "toss" the system. Medicine is not repairing a car, or having the office copy machine serviced - it is immediate and interactive. Phone calls for problems need immediate response, only computer farms in smaller chunks are capable of this on the human level. If your regional EMR system is designed for "call center" support it will fail even if the technology can handle it.
Besides being a tech guy and software guy my graduate degree is related to cultural anthropology. Many of the problems in these EMR disasters have to do with relating the technology and its limitations into the cultural perceptions of their customers. It also explains why many of the large companies fail, they become the new "tickle me elmo" (I would say holahoop) without having the basic understanding they may be a cultural phenomenon and not "whizz kids"
So, cyath, when are you going to sign up with us to build your regional system?
cyath: DrMurdoch: The lesson here for the little guy is :Avoid Upfront costs.Monthly contracts are the way to go.If your vendor won't do a long term contract with lower upfront costs: walk. Sheez. Things never change around here, do they? Y'know, Ive learned a lot in helping our group find an EMR .
DrMurdoch: The lesson here for the little guy is :Avoid Upfront costs.Monthly contracts are the way to go.If your vendor won't do a long term contract with lower upfront costs: walk.
Sheez. Things never change around here, do they? Y'know, Ive learned a lot in helping our group find an EMR .
Here is a great (? maybe the best) example how big vendors aren't necessarily the best. Cyath, you've already had one EMR failure, hopefully your last. Doctor-friendly EMR companies offer monthly EMR contracts, ie. eCW. EMRUpdate has no information to help doctor groups of your size really. So don't expect different answers. EPIC would be a terrible choice for the small doctor office, and always will be.
cyath,
Medscribbler, does most of what you ask, while we have only a solo and small clinics now, the function is built in for the kind of install you envisage.
I won't get down to features, your last request capture data through "point and click" we don't do and probably will never do because we think embedded handwriting is faster with less support and training issues, particularly training. We have fought over this before.
There are two items Medscribbler has that seems to be at the heart of your concerns.
Beacuase of the increasing simple to set-up and common use of VPNs Medscribbler has been designed to have a VPN as an underlying technology (forget ASP and Citrix - old). This means that siting on the beach in Aruba with the hotel wireless internet you can turn on your Tablet PC, use your pen and not only see the complete Medscribbler EMR system and messages from the covering doc but look up the patient's chart to decide how to respond to the covering doc. Even right a Rx and print it out at the office! You don't need to get out the keyboard or use the Tablet TIP but simply handwrite your orders or Rx.
The second item is related to the first, because of this "open" system Medscribbler has permissions built down to the grandular level. By this I mean, you can give chart permission for all of your patients to other doctors or just your partners and you can then further give individual chart parts access to individuals within the system. Ie. the receptionist can only see and modify the demographics or a nurse assistant can read the whole chart but not add chart notes. Or a partner can see all the labs, dx's,rx's etc but not your patient notes (This may be important for insurance if one of your collegues is called to testify against you - it happens)
All we need is for a large install to work with us, to help us do the tweaks neccessary for a 700 plus doctor regional install. We have the premise right with bleeding edge technology or you can take a chance on a "big" company like EPIC, or shall I remind you of threads on Alteer, Dr Notes etc. etc. which brings me back to the my first post in this thread - satisfactory EMRs are only going to happen with those who look for new technology and innovation.