Ken Willett is president, CEO, and chief technical officer of Ignis Systems of Portland, OR.
Tell me about yourself and and the company.
I’ve been in software development ever since I got out of college in 1974. I’ve worked in a number of high-tech startups, mostly in the electronic design industry. I got into healthcare IT as I started a consulting business in about 1994. Ignis Systems was incorporated in 1999.
One of my first major clients was MedicaLogic, now the Centricity products from GE since they bought MedicaLogic. That then led to EMR-Link, which is the current product that we have. Ignis is no longer a consulting company — it’s a product and services company. A number of people have joined — quite a few of them with GE Centricity background — but we’re now spreading out, bringing in people with expertise in other EMRs.
The system deals with CPOE from the ambulatory side – orders and results – and in the diagnostic area: lab orders, lab results, radiology orders and results, and so forth.
Describe briefly how the orders flow within an ambulatory EMR.
The EMR is the main cockpit of the provider these days. People who are really using EMRs well want everything to be driven out of the EMR — the decisions that they’re making, documentation they’re providing, and in particular, creating orders for outside services.
In the past, what’s typically happened is labs have provided either Web-based or application-based ordering systems to providers. Providers don’t want to switch to a different application to place a lab order, a medication order, or any other kind of order. They want that out of the EMR.
We provide the ability for them to do the ordering within the EMR. The provider generally provides some minimal information. What they’re interested in is, “What tests do I want run? What’s the justifying diagnosis for this test? When does it need to happen? Is it an urgent or a regular order?” But that’s not really sufficient information for the lab. The lab needs to know a lot more status information about the patient. They need to know about insurance. They need to know what account to bill things to.
Our application collects the information from the provider, the basics of the order. It then allows a staff person to augment that information to get it to the point where it meets all the order requirements for the lab. That helps to guarantee that when the results come back through us, they are going to meet the needs of the provider in terms of being a high-quality diagnostic report.
Many people would have assumed this problem was solved many years ago, especially since e-prescribing has settled down to universal standards. Do you think a long-term solution is coming for orders other than what you are offering, or is this as good as it will get in linking an ambulatory practice to the outside world?
I hope it will get better. When I was first involved with MedicaLogic, e-prescribing was just as much of a black hole as lab orders and lab results are now. What happened in the intervening years was there were a few large players on the prescribing side that were the pharmacy benefit managers. Once those large players got their act together and Surescripts was involved and that technology. That made it easy to essentially move that whole industry toward one set of standards and one method for communicating these orders.
The same thing hasn’t happened on the lab side. The lab industry is much more fragmented. There are two or three big players in the US, but they only account for about 20% of the total lab volume. We’re talking about hundreds or thousands of hospital labs, and now, even more in-office labs in large physician practices. It’s very, very difficult to drive a consensus there through just market activity.
What we end up having to do is have lots of different kinds of connections to different labs. They have slightly different flavors of HL7 data for orders and results and have different communications methods. We have to make sure that our hub adapts to those differences.
I think over time, particularly with a push from the federal government for information exchange, there will be some focus on standards. There’s some standards activity going on right now both at the federal level and within the HL7 community that hopefully will get adopted more widely. I think that will reduce the number of variations we have to deal with, but I don’t think it’s going to drive it down to one common standard that everybody’s going to be using.
Who is your target audience?
We sell services to the major labs and also to hospital labs as a way for them to connect the providers and their community, or the providers that they market their lab services to. The same thing with radiology. But the main user of our system is the provider. We have to make sure that what we are doing is a great solution for the doctor as they’re providing care for the patient, even though they typically pay for a small portion of our service. Most of our service is actually paid for by the lab. So it’s not simple from a marketing and sales point of view, because we have one customer who’s making the purchase decision, but we’re going to have a different customer that we have to satisfy from the usability point of view.
Let’s say LabCorp sponsors the implementation for a particular practice. Is the connection only then to LabCorp, or once it’s in place, can it be used for other lab companies?
One of the things that we think is important is to have a single ordering solution that can connect with all labs that a particular provider is going to use. The typical case is probably two to three. Because of insurance contracts, most of the people who send orders to LabCorp also send them to Quest because some insurance carriers require that. Then they may have a hospital lab that they send things to just because it’s in their community.
We have is a single application that allows ordering from any of those. From a business point of view, we have to break that apart so that LabCorp is paying for their piece of that system, Quest is paying for their piece of that system, and then there’s a subscription piece that the provider pays that’s a recurring annual usage fee.
By definition, your practices all have a large entity as a sponsor, correct? Its not really a universal system from the physician side, but rather whatever parts the sponsor wants to subsidize?
That’s true for the larger labs, but we actually have a range of different scales that we operate at. We have a lot of customers that are relatively small practices, maybe a dozen or so providers, but they have in-house lab. They want electronic ordering and electronic results. The smaller-scale LIS systems that they may be using for their in-office lab maybe don’t have that capability.
We can allow them to do electronic orders and results. Even though the lab system is in the same building that they’re in, they connect through us because it just works better and smooths out the workflow.
Then we have a lot of labs that are in the middle. They may be a single hospital or a multi-hospital organization that may have a single consolidated lab, or they might have a lab at every hospital. We provide the ability for them to connect to practices either within their organization or affiliated practices within their community.
And then of course there are the large reference labs where labs are their only business. We also have a number of hospitals who provide labs and radiology, and we can provide a single ordering and resulting solution that handles both types of orders.
What kind of user or transaction volume are you seeing?
We have about 5,000 providers using our solution at between 250 and 300 different sites. We’re handling between a half million and a million transactions a month through our system. We have unsolicited results in some cases, but they may quite often have an order with a matching result coming through.
What’s the selling point for Meaningful Use?
This goes back to the Meaningful Use criterion around structured lab results. Lab results traditionally, in a lot of cases, have been faxed to providers or they’ve been sent through a remote print engine. They print it on paper, and then maybe they’re rescanned. But the established EMRs that have been around for a number of years can handle HL7 lab results. They can do things like display the patient trend graphs or they can filter the population based on lab values.
We’re seeing a flood of new EMRs hitting the market and a lot of them don’t have that capability. A lot of them believe that lab results just means that you can present a lab report to the provider so that they read it. If a provider or an organization chooses structured lab results as one of the menu items in Meaningful Use, then they need to have a system that can present that structured data to them. In some cases, their EMR may not be able to do that.
One of the things that we provide on the result side is that we can maintain the structured data in our system. We can provide it a readable, high-quality printed report or viewable report to the provider, but we can also provide the trending and the structured data that they need. It’s also sometimes the case that we can provide viewable lab results to a provider who doesn’t have an EMR yet, or isn’t set up to handle structured lab result data yet. We can populate that EMR with the structured lab data once that provider’s ready.
It seems reasonable for EMR vendors to let a specialty company develop the integration piece while they focus on the inherent functionality needed for their own workflows.
We think that’s the right model. In most cases, with a few exceptions, the EMR vendors don’t really do a very good job of interoperability with outside systems. It tends to be an afterthought. It’s a whole different business. EMR vendors usually are as software development and database experts. They’re used to building essentially closed systems that are delivered and installed at the customer’s site.
Interoperability is a much broader game. You have to be an expert in data communications and security, error recovery, and all kinds of things which may be or not that applicable in the EMR that’s installed at a particular customer site. I think it makes sense for people to leave that to us.
We’re finding that, both with the EMR vendors and also with labs, when they start to add up they’re paying to implement lab interfaces and get them working, maintain them over time, and recertify them every two years, a lot of those companies that just don’t want to be in that business.
You mentioned use of your tools by practices with no EMR. Tell me about Orders Anywhere, which you market as a starter step.
That’s great for people that aren’t on an EMR yet. There are also many EMRs which don’t have electronic ordering at all. They don’t have the ability to generate an outbound electronic order message. A lot of them are designed just to document the orders in the chart. Some of them have an ordering capability but it’s just not very good — they don’t have the ability to configure ordering preferences to what the provider needs and they can’t split orders when they need to be split into multiple requisitions.
Orders Anywhere is a way for people to have electronic ordering, even when their EMR doesn’t provide it. It’s both for people that don’t have an EMR and people whose EMR doesn’t have good ordering capability.
Are you seeing providers who have decided that HITECH money just isn’t worth the trouble and picking and choosing just those technologies that make benefit them directly, like perhaps your electronic ordering product?
You don’t necessarily find out what the provider is intending as far as the Meaningful Use stuff. I’ve heard stories of doctors who have said, “This isn’t worth it to me right now.”
But I think what we’re seeing is that a lot of the volume growth in EMRs really is being driven by the Meaningful Use rules, so the people who’ve decided that it’s not worth it probably aren’t talking to us anyway. For somebody who has an EMR and they think EMRs are good tools to use, they’re probably going to figure out how to get their use of the EMR up to the point where they can get some Meaningful Use reimbursement.
The other thing that we’re seeing that’s sort of odd and a little scary is vendors who build their systems to the Meaningful Use requirements. They may have some technology pieces and they’re asking, “What’s the minimum we can do so that a doctor can get paid by the government?” Not what’s a good EMR or what makes sense for taking care of patients, but more, “How do we meet the letter of the Meaningful Use regulations so that if they buy our product they can get paid?“
That’s not a very far-sighted view. Those regulations are going to change over time, but that set of things that have been identified by the ONC by the Meaningful Use, they’re really pretty arbitrary. There’s a lot of other things that you really should be doing if you’re going to be a good EMR user.
You’re in a fairly niche-type technical product area. Do you see your expertise translating into other products or services beyond orders integration?
Yes. We have a couple of things in the works that I can’t really talk about them in detail, but there are a number of problems now that are of the form of having multiple back-end organizations with different standards like the labs are in our world, maybe having to have some connection on the front end to every provider, or maybe all providers in a state, or all providers in a certain geographic area.
Understanding how to put together a hub-and-spoke architecture that does the right kind of translations in moving data from one side to the other — we’ve learned a lot about doing that with labs and radiology. We believe there are similar problems that can benefit from that.
CCHIT chose your tools to test orders integration for certification. Did that raise the company’s profile?
Well, we hope it did. We have lots of experience with lab results and what works in the real world. That was a project of mine to work together with the CCHIT technical team to put together the test suite for Meaningful Use certification for lab results.
Where does the company and the industry need to go?
One of the things that we work very hard at is being really responsive as things change. One characteristic of where we are in the market is we’re hooking up new practices and new labs all the time. We have a hosted solution, a Software as a Service model, and we need to be able to turn things on very quickly, generally within the space of a few days. We can do that pretty readily as a small company. I think it might get more difficult as our organization gets bigger.
But there’s a lot of room for small companies like ours to fill in some of the gaps between these large systems, which often take 12-18 months to incorporate new capabilities. Things are moving too fast – people can’t afford to wait that long.
Any final thoughts?
I think there will be a separation between transport companies and transport technologies and content companies and technologies, sort of like what’s happened in the television industry. Communications companies deliver data from one place to another, then you have other organizations, like Facebook or HBO, that provide the content.
We’re very much in the content business. We want the information provided by the provider to be useful for the lab, and we want the results from the lab useful to the provider. We don’t necessarily want to be involved in the plumbing that makes all that happen. In the HIE world, some of the work that’s going on with Direct standards, the transport pieces are becoming more of a commodity. Those things will separate themselves out from those of us who focus more on the content.