David Lareau is chief operating officer of Medicomp Systems of Chantilly, VA.
Tell me about yourself and the company.
I was in Baltimore in the late 1980s and had my own practice management reselling company. One of my customers in 1990 came to me and said, “Dave, we’re real happy with your services, your billing system — we want to start looking at EMRs.” I said, “What’s that?” He said, “We think they’re going to be the thing of the future. Would you help us look at them?”
We set up a process where once a month they would come into my office and I’d bring in a vendor. After a few months, they said, “Nope. All this makes us data entry clerks. It’s all template-based. We hate it, can’t use it. Thanks. Here’s what we need you to find.”
A couple of years later, maybe ’92, I happened to see Peter Goltra and his team at Medicomp and I was intrigued. I thought, “This sounds like what those guys were talking about. Let’s bring them in.” They looked at it and said, “That’s exactly the way this stuff needs to work, but it’s just ugly as hell.” It was a Unix-based system, the old green screens and stuff dropping down. They said, “If you put a decent user interface on that and integrate it with a billing system, that would really be something.”
I talked Peter into letting my little company do that. I eventually came home to my wife one day and said, “Honey, I just found what I want to do with the rest of life. Can we move to Virginia? I really want to work with this company. I love what they’re doing. I think it’s the thing of the future.” I figured at that point, yeah, 10 years from now everybody will have an EMR. You know how it was in 1992.
I joined Medicomp. I found that they provide clinical content for documentation and patient care that thinks and works the way a physician does. It’s just simply that. We’ve been doing that ever since, with changes along the way in response to the markets, technology, etc.
You said you had to find Medicomp. I always got the feeling that both the company and Peter Goltra aren’t as widely recognized as they ought to be. Is that low-key approach intentional?
The low-key approach is somewhat intentional. We provide a really critical component to about 10 to 12 different vendors in the space. That’s growing all the time.
We leave it them to do a couple of things. Differentiate themselves from each other. And, we want to make it clear to the marketplace that if you want an EMR that uses our content, you need to go to our customers, not to us.
We’re very low-key at industry events. We really only concentrate on going to industry events like HIMSS and MGMA, where we’re there primarily to support our customers, who are EMR vendors, and educate their potential customers about the benefits of an EMR that uses MEDCIN.
The other way we stay in the background is when a new vendor decides to license our technology and put it into their product, we leave it to them to time the announcement to let their installed base know. As you know, once somebody announces a change in direction, even if it’s a good thing – which we think implementing our MEDCIN engine and Quippe is — it still tends to freeze what is then perceived as a legacy product, and these people need to maintain that revenue stream.
For readers who don’t know, describe the MEDCIN engine and how it’s used.
MEDCIN at its core is a clinical knowledge base that has about 280,000 clinical concepts in it. For the most part, they are pre-coordinated. The purpose of the engine is to present the relevant information to the physician at the point of care given a specific clinical scenario.
For example, there are 293 concepts in MEDCIN whose relevance is scored for a patient with asthma. In that case, adding more concepts to MEDCIN doesn’t do anybody good. We can focus on the relevant items given almost any clinical situation, which is what makes it valuable for a providers treating a specific patient for a specific problem or a set of problems at a specific point in time.
What’s nice is is that it thinks and works like a clinician, and then all those concepts are mapped to ICD-9, ICD-10, SNOMED, CPT, LOINC, RxNorm, and all the 44 Meaningful Use criteria. All the nonsense — from the doc’s point of view — is taken care of in the background. The engine presents to the physician the things that they would care about for a patient with that condition.
We came up with that in 33 years of working with physicians saying, “OK, here’s the presentation. What would you want to be in your note? What will you want to look at? What kind of lab results would you want? What are potential orders? What would you do for the review of systems? What history? What physical?” It presents the things that real docs who are treating patients every day tell us they would want. We’re not trying to tell them what to do – we’re presenting to them what they said they would do.
Describe where your content comes from.
We have at any point about 20 to 30 active clinical consultants. We tried in the mid-80s having medical MDs on staff and nurses on staff to do that, but we found that when we brought guest experts in — consultants to help us build the data engine — all they did was argue with each other over, “You were trained here, you were trained there. I wouldn’t do it that way, I wouldn’t do it that way.”
We ended up saying, OK, we’re going to be clinical knowledge management engineers. Let’s engineer an editing system, where we can bring these people in and we have editing facilities. Now with the Web, you don’t have to do it locally, but when we did, we had an editing facility in Martha’s Vineyard, we had one in New York, whatever’s convenient. We’d typically bring somebody in for two or three days at a time. Some of these guys come in regularly, some come in every six months, some once a year for a week or so.
We sit with them and say, you’re seeing a patient with asthma. What would you normally expect to have to think about or address? They’ll say wheezing, difficulty breathing, is the wheezing episodic. What do I see in the lungs? Auscultation. Family history. Do they have exposure to dust mites? What’s the spirometry? What’s the O2 sat? Do they have any other conditions, maybe nasal polyps?
We say, is they’re anything else that might help you differentiate asthma from something else that we should put in the asthma – we call them indices – in the asthma index that you’d need for rule-out? So there’s things in there that have both a positive and a negative correlation.
We put those in, and then we’ll go back and say, now for each one of those things, wheezing … somebody comes in wheezing, it doesn’t mean they have asthma. Means they might, but what else might it be? Let’s built out the index for those things.
You do this in an iterative process over years. We’ve ended up with about 293 items in the asthma index, one of which is wheezing, which has 260-some links of its own to diagnoses other than asthma. You can attack it from either point. This is iterative. Then we’ll have pulmonologist come in and say, we just did this recent work with somebody who was a specialist in asthma. How does this intersect with other things that you see? Does it raise the risk factors for pneumonias?
It’s iterative. It’s one of the reasons why it’s so hard to replicate this with a template system, because we’ve been at it so long. Everybody says you can’t take nine women and have a baby in a month. That’s sort of what we’re dealing with here.
Does the MEDCIN engine have competition other than templates and text-based literature look-ups?
In terms of what we do and the way we do it, no. But in terms of competition, there’s tremendous competition all throughout the marketplace for our approach and any other approach. We define competition as anything that causes somebody to say, “Hey, your stuff looks great, but I don’t really need it.”
You can fake some of this activity for a single-problem patient with loads of templates, but eventually it doesn’t scale up when you start to have multi-problem patients whose conditions progress over time with clinical sequelae, complications, comorbidities, etc. Nobody really does or is close to doing what we do, but as long as people think that there are reasonable alternatives … sure, we have competition, and now you’re hearing about Watson’s going to do this and Zynx has protocols and Wolters Kluwer is getting into the market.
One of the things that we do that those folks don’t do is we actually have the concepts for documentation linked to E&M, linked to all the other stuff designed for use at the point of care. It’s not a knowledge resource — it’s a documentation and patient care resource. In that regard, there’s really nobody else that I know of that does what we do.
Explain the advantages of Quippe and why physicians like using it.
When we first started designing this stuff, we were a little bit limited by the current technology at that time, by the state-of-the-art of user interfaces, and that kind of stuff. We made the decision in 1997 to make the knowledge engine its own component without a UI. When some of the browser-based technologies and some of the performance stuff for cloud type services came along in 2002 to 2005, that enabled us to think about a completely new way to deliver two things to the user at the point of care: deliver the content and give them control over the presentation of it.
What we’ve managed to do with Quippe is take 25 years — from 1978 to about 2003 — of clinical content development and what would now be looked on as rather primitive user interface options, and bring a bunch of docs in here and say, “We can deliver any of this content anywhere you want in millisecond time. What is it you really want, and what control over it do you want at the point of care in a user interface?
We had docs come in here over a period of about two years, probably 10 different sessions, and just say “Give me what I want to know when I need to know it. Give it to me in a format that I can control, that can learn from me as I go along, adapt to my needs, and not fix me into a template, but actually push the information to me that I want to see for any condition I treat without me having to go and find it or ask for it.”
Quippe is a note-like user interface that has all this data behind it ready to serve whatever action the clinician takes and give it to them on almost any device. Right now tablets are the hot new thing, but it doesn’t have to be that way.
How is it different selling to vendors rather than end-users? You had a significant presence at HIMSS, including sponsoring HIStalkapalooza. You have to develop interest by the user, but through their vendors.
There’s two ways to do it, and we have to do a little bit of both. Going with MEDCIN and Quippe as your platform is a major strategic and management decision. You have to get the interest of probably the busiest people at HIMSS, who are the CIOs, the CEOs, the clinical people of the vendors who are there to do business with their potential customers. They’re not there to talk to me. We have to get their attention and we have to prove to them that we can provide value.
One of the reasons we do the iPad giveaways at HIMSS that we just did at MGMA is to show these vendors that we can provide to them something that I can train their customers to use in 20 minutes on a busy show floor. They look at that and say, “Wow. That means I can scale up. I can get implementations up. The docs seem to love it. Tell me more about Medicomp and MEDCIN.”
It’s a two-pronged strategy. We’ve got to appeal to the end user, but we’ve got to also get the attention of the busiest people at HIMSS and MGMA.
I knew nothing about documenting an encounter or using an iPad, but it really was just that easy to use Quippe. What response did you get and are getting at conventions where you just sit people down cold in front of it and say, “Here you go?”
They can’t believe it. It looks so easy they think we’re faking it, which is why we have to put it in their hands.
I don’t know anybody else that puts software with the complexity underneath it and power in a user’s hand on the show floor at HIMSS and just says, “Have at it.” That’s a very powerful message and one we’ll continue to use over the next couple of years.
That all comes from those docs coming in here. Every time I had an idea for the user interface or somebody here did, the docs said, “No, no, no. Just give me what I want and get out of my way because I already know how to treat patients. I already know what a note looks like. I know how to document. Just give me the information I want and a format I’m used to looking at it.”
That’s really all that we do. There’s a tremendous layer of technology underneath that, but MEDCIN is like the wizard behind the curtain of Quippe, except there’s really something there, not just some guy pulling strings. The only way to prove that is to put it in somebody’s hands and let them do it.
Like the iPad it runs on, that’s an Apple-like strategy to replace complexity with elegance, but let the user do what they need to do efficiently.
Exactly. One of those light bulb moments for me was I went out to visit the end user of one of our customers about five or six years ago. She was not happy with how much the user interface that we had in the old VB6 days slowed her down. She was vocal about it, but she made some really good points. She gave me a lab coat and said, “You’re an intern for the day. You’re following me around. Let’s go see two patients.”
We went into see one. Lights were on, computer, etc. She did what she did using the software of one of our vendors, who will go unnamed. She went to document and do all this and do all that. At the end of that and said, “Did you see how excruciating that was? Let’s go in to the next patient.”
She pulled up the shades so that light came in. She unplugged the computer and pulled out a pad. Saw the patient, did what she did, gave the patient a prescription, walked out, and she said, “I already knew how to do everything. Without your technology, it took me 11 minutes. With your technology, it took 15. Don’t slow me down. Get out of my way.”
I came back to the guys and I said, “We’ve got to kill the idea of fixed templates. We got to kill the idea of checkboxes on forms. We got to come up with a different model for this. What do physicians know? They know medicine, they know what they’re thinking, and they know they have to produce a note. Let’s marry all that together.”
As it turns out, our engine was almost perfect to serve up that sort of solution. We brought the docs in here and said, “Help us do this.” They just kept saying simplify, simplify, simplify. That’s how we did it. That’s what makes it possible for us to teach people to document on an iPad on the show floor in 20 minutes.
That gets into the area of EHR usability, which is, along with ICD-10 and Meaningful Use, is a hot topic. What is Medicomp doing to address those?
A couple of things. Back in 1997, when the National Committee on Vital and Health Statistics decided to set up a standards committee, we were very involved in that. One of the big decisions they made in maybe 1999 or 2000 was ,”We’re going to set reference terminology standards for the exchange of information between systems. We’re not going to dictate user interface terminologies. We think those have to adapt to users and it’s not going to be the same for everybody ,so let’s establish standards.”
In July of 2003, they said that LOINC, RxNorm, and SNOMED were going to be some of the voluntary standards for this. We immediately said everything we do from now on is geared at making sure we maintain that layer of usability and map to all these standards in the background. We probably added 30% to our staff, we added consultants, and we just started cranking out those mappings, just doing them reiteratively over and over again.
When we saw that ICD-10 was going to happen eventually, we prepared for it. We’re now implementing that. We did the same thing for E&M, which is another kind set of coding mappings back in 1999, 2000. We continue to do all that mapping in the background.
We adopted Virginia Saba’s clinical care classification system for nursing and built a nursing engine and documentation index that integrates with the physician index that we’ve been talking about, so that nurses and allied health can both treat the patient based on the same information in the note, but their documentation overlaps in some cases, but is very different in other cases. That’s what’s getting us now into the enterprise market more deeply.
So you think you’ll have an inpatient clinical documentation system for nurses?
We do have it. I expect that we will make … as I said, we let other vendors make the announcements. I’m virtually certain we’ll make an announcement of a major vendor in the next six months and possibly two by the end of next year. They don’t announce until they’re almost ready to deploy. I think it’s going to stun people.
These are vendors that are committing to retool their product to have your version of the MEDCIN engine as the front end?
Yes. We found an interesting thing. We did a project in Asia about three years ago. I went to Asia and I demo of Quippe in English and they said, “Forget about that. Let’s see it in Mandarin, in simplified Chinese. When will you have that done?” We hadn’t even started and that wasn’t my intention. What would be acceptable? They said, “If you can document 95% of what you do in Chinese, that’ll be fine.”
We pulled the MEDCIN index out for the top 500 diagnoses, all the index records for those, plus 200 other areas of our clinical hierarchy that weren’t represented in the 500. We merged them all together and it came 10,104 of our 285,000 items. We got translations for those done in less than three months for positive and negative. I went back and did a demo — 98% of everything came out in Chinese.
That was pretty cool, but when we started dealing with the enterprise vendors and they said, “You know Dave, we’ve got existing content that covers most of what anybody does” – this is two different vendors independently – and I said. “How many others do you have?” They said just over 10,000.
How weird is that? It pretty much told us that even in a large population, 10,000 to 15,000 of our elements constitute 97 to 98% of total data occurrences, but the struggle that the continue to have to add items, they continue having to map them. The more items you add without some intelligent way of presenting them, the more templates you have to build and maintain over time.
The big vendors, for the most part, are coming to the conclusion that they do not want to be in the clinical content business. There’s a couple of big exceptions, one located in the Midwestern state south of Chicago.
You’ve been good at predicting the future and being ready for it. Where do you go from here looking down the road a few years?
We have to be ready for a couple of things. Whether anybody likes it or not, if you’re a clinical provider and you’re treating a patient, you have to be prepared to deal with what we think of internally as the coming data tsunami. Once these HIEs are in place and once these standards are in place and people are required to send this as LOINC or RxNorm or SNOMED or ICD-10, and I’m treating a patient and they’re under my supervision now – maybe I’m their caretaker under an ACO model — I’m responsible for that data coming in. I’ve got to be able to make some sense of it.
I might have a patient with the classic big three in America — hypertension, obesity, and diabetes — plus two other things. Maybe today I just want to deal with this. I’ve got to find the relevant information in there, because I’m probably going to be held responsible for it, and I’m probably going to be held responsible for whatever I do and making sure that patient, once I treat them, if I admit them to a hospital or I discharge them from ambulatory care; if we got to outcomes-based reimbursement, I’ve got to take that data in, treat them, and keep them from coming back.
All of our tools are built to enable that. That’s one of the reasons we got into integrating the nursing care. If somebody gets discharged or somebody comes in even to an ambulatory practice with an open wound, I’m going to be responsible if they show up with an infection coming back. I’ve got to teach them hand hygiene, I’ve got to teach them wound care, I’ve got to teach them signs of infection. I’ve got to do all that. That’s why we built that stuff and then integrated it, because whether it happens or not – and I think it will, I think it’ll take longer than people think – we’ve got to be ready for that data tsunami that’s coming.
We also have to be ready to make it possible to scale up – and I’m including implementation and training and updates of software – quickly as medical knowledge changes and get it deployed out to the places where care happens, which is why we started building our cloud-based model about six years ago. Whether or not ACOs push integrated care, information is going to increasingly be … you’re going to need to be able to integrate it quickly, absorb it, find what you want, treat the patient successfully, and manage them on an ongoing basis.
We’re building all of our tools as if we have to do that. We also know from our experience, now with about 100,000 people using MEDCIN everyday, that training consists of, “You’re new here. Let me show you how I use this.” They get about 20 minutes of training, it’s done, and they’re on they’re own. That thing had better push the information they need to them. It better be intuitive. It better be easy to use, maintain, train, deploy.
That’s what we’re focused on. It’s a lot, but it’s really one problem. Giving them the information they want when they want it so they can do what they need to do and not require massive support to do that.
Any concluding thoughts?
We think there are going two be major challenges. How do enterprises handle data and account for their outcomes? How do you get the tools to do the individual clinicians on the front lines to do their job, which is patient care, and take care of all of that other stuff in the background? That’s what we’re trying to do.