Here’s the transcript of last weeks podcast with Axolotl’s CEO Ray Scott. Essential stuff if you care about health data and information exchange–which for some reason some people seem to think is important!

Matthew Holt: It’s Matthew Holt. I’m back with The Health Care Blog doing another podcast and today, I’m talking with Ray Scott who is the CEO of Axolotl Corporation. Axolotl is a company that’s been around for about 11 years now-I may be wrong on that and Ray will correct me. Axolotl has been making a lot of noise lately in the RHIO [Regional Health Information Organization] space, and has got probably one of the oldest and most pervasive examples of this sort of fully functioning community based messaging system RHIO in the Santa Cruz area in California. But it also has got a lot of stuff on its plate. So, I thought we’d have a conversation about what Axolotl does, where RHIOs are going, and any other things that comes up.

For those of you listening to the
podcast version of this rather than reading the transcript, you’ll
figure out that you’re going to be overeducated with British accents
today because Ray is also another Brit. Perhaps it says something about
having to come over here and teach Americans about health care.
[laughs] Anyway, Ray, good morning!

Ray Scott: Good morning.

Matthew:
Before we start, give me a bit of the back story-I know we spoke and
you hinted a bit about this–about how you arrived in the US. You had a
pretty lengthy career working with Scotland Yard and some technology
companies in the UK. You seem to have done fairly well over there. And
yet, you’re over here in the US, working on health care. How did that
happen?

Ray:
Yep. Perhaps it’s a mistake. But, a friend of mine who I worked with in
Europe in building up a Pan-European software products and services
organization, got the idea to start a company in this particular
space–seeing the requirements for connecting ambulatory care
physicians to all the partners with whom they do business so that they
could do that business electronically–and called me on the phone and
said, ‘Wouldn’t you like to come and help me start this company?’ I had
no intention of moving here at that time but I helped him for the first
few months–forming the company, the company’s plan, the products’
strategy, and so on–and got tied up and seduced by the Silicon Valley
buzz at the time and ended up moving myself and my family out here.

Matthew: And this was what, some ten years ago? Longer than that now?

Ray:
Yeah, that was ’97. We moved out in ’97. The company was founded
earlier than that. I commuted from Oxford to Silicon Valley, on and
off, for about two years. It’s not a commute I’d recommend.

Matthew: Yes, I’d assume American Airlines or BA or something like that.

Ray: It was United, yeah.

Matthew:
United, sorry. That’s probably why they went bankrupt.[laughter] OK.
Tell us a bit about the core basics of what Axolotl does. I think it’s
pretty clear that for most people in health care, they understand the
concept of electronic medical records, they understand the concept of
messaging–but other than some of the Cerners and the Epics who were
doing big scale hospital system inpatient EMRs, I think it is fair to
say that there is a lot of confusion about who does what in this
market. So, could you outline clearly for us what it is that Axolotl
does? What your core services are for your customers?

Ray:
Yes, It’s health care information exchange. We connect the ambulatory
care physicians and all of their support staff to all the institutions
with whom they do business electronically. We focus on the clinical
side, and not on the billing or the payment side or reimbursement side.
So, typically we will connect ambulatory care physicians to the
hospitals where they admit their patients, to labs to whom they send
specimens for tests, to radiology centers that they do business with,
and so on. We do have some connections with payers so that we can
provide crucial information like eligibility information for patients
and provide significant help to the support staff in a physician’s
practice. So, you can think about our focus as the physician in
ambulatory care practice. But in order to make this happen, we
obviously have to deploy significant IT components at the hospital, and
at the labs, and at the radiology centers, so that we can make that
information– as soon as it’s available with our hospital-we can enable
it to flow to the physician.

If you want an analogy, think about
email. I suspect for most of your readers and listeners, that email has
become an indispensable application today. There are two reasons for
that. The first is you can communicate with almost anybody in the world
using email. The second is that when you do that communication, you do
it through one vehicle–all the messages are brought together in one
place so that you can review and you can send out all of your outgoing
emails from that one place. We do a similar thing for physicians and
their support staff. All of their clinical data comes to them in one
place–whether it’s from Hospital A, Hospital B, or Hospital C with
whom they may do business, or whether it’s from the lab or the
radiology center–it’s all brought together for them to review as a
whole, organized by patient. Then as they review it, they can respond
to it or take clinical action on it, in that one place. So, think of it
as a clinical inbox that physicians process everyday and that’s the
sort of messaging world of their own.

Matthew:
So–if I’m to understand–there are two directions that I’d like for
you to go just a bit deeper. The first one is format. I assume, in
general, what you’re replacing here is stuff coming off the fax machine
or bits of paper going in the mail for things like labs results or
other tests–you know, bits and pieces of information that’s flowing
around.

Ray: That’s correct.

Matthew:
So, what does the typical physician using Axolotl, is it typically a
product that is used more by their office staff and they’ll print
something off and give it to the physician, or is it typically the
physicians now taking this into their computers. How is that working
out?

Ray:
It’s both. The support staff uses a different set of functions than the
application for physicians. A simple example would be that there is a
full prescription writer available within the product. Clearly, staff
can’t write prescriptions–they can prepare them but physicians have to
review and authorize prescriptions and anything that requires clinical
decisions. So, if a prescribed drug provides an interaction warning
with the drug that a patient is already taking, then a physician has to
make the decision whether to override that warning or whether to search
for a different drug that might be prescribed, and so on. So, we try to
provide a set of features and functions that help both the physician
directly and the support person, and we expect both to be users of the
system.

Matthew: So the physicians are using it on their PCs. Do they have a hand held version too?

Ray:
Yes, it’s entirely Web-based. What we do is entirely Web-based. So,
anything that will run a browser, you can essentially access that
application. It can be a phone, a PDA, or a laptop, a notebook or a
desktop PC.

Matthew:
And in actual day-to-day practice, what are you seeing in terms of
shared use? It is that basically, the physicians and the support staffs
are both using it all the time? Or is it more the support staffs using
it all the time? How does it work out?

Ray:
No, it’s pretty much even. I mean, there is somewhere between three and
four support people per physician in the US, and that’s the average
that we see in our deployments. So if a practice adopts it, then it
tends to be everybody in the practice that adopts it because that’s how
you get maximum value. You know, it’s passing responsibility for
particular issues around within the office, trying to minimize the
amounts of centralized record-keeping that might need to be done. A lot
of the practices we find still aren’t ready to give up their paper
records which they still keep for legal reasons, for malpractice
reasons. So, our product incorporates mechanisms to eventually print
copies of the information, even thought you can annotate them and react
to them interactively online, you can print or file them if you wish.
We have some practices that have gone completely paperless, but very
few. Most run a mixture.

Matthew:
And we have sort of mentioned some emails–and that’s ‘the killer app
of the Internet’–what’s the killer app, the most desired information,
if somebody signs up as an actual customer? Is it lab results? What are
they looking for?

Ray:
No, it’s a critical mass thing. Unless you’ve got the majority of the
information coming to the physician or the support person in that one
place, the app itself will not take off. So adoption is very very
dependent on achieving critical mass. Obviously lab results play an
important part in that but so do the physicians’ own progress notes.
And some physicians currently still take notes by hand, and many of
them dictate their progress notes or chart notes. So if you go in for a
patient visit you’ll find after that patient visit they dictate the
results and send it off for transcription by some external agency and
then get it back as a paper document, traditionally. One of the things
we as an organization have to do is find out where those transcriptions
are being done and try to offer an alternative service to provide that
so they get that back electronically, too. So labs, transcriptions, and
radiology together probably form the majority of the information,
adding things like prescriptions and online orderings and so on, help
enormously. Those first three are the key.

Matthew: Thats interesting. Which gets us to the second part of the point. You have taken, as a company, a regional approach.

Ray: Yes.

Matthew:
And when you talk about where you are as a company, you’re talking
about metro areas in the US, different regional areas of the US.
Getting back to that critical mass question, because obviously we’re
talking about a network you can get all into the network online. Do you
want to tell us a bit about what happened first up in Santa Cruz and
talk about some of the other places you’ve moved to? Because I think
that’s an important lesson and we as we drift into the conversation
about RHIOs there’s another California city also beginning with San,
where you had a less happy experience. [both laugh] So give us a bit of
the background, tell us what happened in Santa Cruz in the mid-90s and
let’s go from there.

Ray:
Well Santa Cruz was one of the reasons the company came about. One of
the leading physicians there recognized the need for this type of
communication in their community and Santa Cruz is a geographically
separate community in many ways, surrounded by mountains and so on, and
tends to operate a little bit as an enclave. And recognizing the need
for electronic communication, we decided as a company that we could
bring technological expertise to bear on problem, but really didn’t
have the health care expertise to know how to build the right kind of
solutions. So what we did was we armed 18 doctors in Santa Cruz with
PCs with Groupware products and PCs with Groupware products and said,
‘Look we know it’s practically impossible to get you guys to meet on a
regular schedule but what we would like to do is work with you
electronically, interactively. We would require five hours of your time
a week–you could choose when–to react to our thoughts, our ideas, our
prototypes, our proposals, and so on.’

And over a span of about
18 months, and pretty extensive dialogue, we built our first systems
and deployed them in Santa Cruz. So really the doctors in Santa Cruz
are largely responsible for the way the system is designed, and we the
technologists back in silicon valley are largely responsible for the
way it is implemented, and that’s the way that I look at it. The
roll-out in Santa Cruz was very successful. One of the hospitals got
behind it very early on. The second one decided after a short period it
wasn’t going to benefit without participating, so joined the network.
And Santa Cruz has been using the system now for over ten years, with
no real governance. That’s the interesting point about that community.
There isn’t a single entity there that we do business with. The
Independent Practice Association of which many of the physicians’
practices are members was instrumental in helping get this deployed and
in supporting it. But it doesn’t really govern it’s deployment or the
data share or the arrangements or anything.

Now this was in the
mid to late 90s that this evolved. And at the same time the rules and
regulations of privacy were evolving and being asserted through out the
nation. And that created a rather different environment. And people
began to worry a little more about what they could exchange, and under
what basis, and whether they needed patient consent to do so, etc. And
I think the subsequent RHIOs that have emerged have, I think without
exception, have done so through some form of centralization. Typically
through the creation of a new entity. There specifically to foster,
govern, and support the process of health information exchange.

And
perhaps the earliest example of that is in Cincinnati, where there was
a company called Healthbridge, a not-for-profit organization that was
actually founded by a number of hospitals in that area who had
recognized that by combining forces they could put in place a network
infrastructure that would allow the communication sharing of
information. And that has since grown to about twenty-three hospitals
today, and about 4,500 physicians. And Healthbridge runs their own data
center, it’s our technology, but they run their own data center to
provide the same capabilities for their communities. So the whole of
Cincinnati is essentially wired with Axolotl’s products. There are a
number of other situations in Tacoma and Sacramento and Texas and so on
where we’ve got deployments that are similar. Perhaps the most
recent–well now not the most recent–but one last year in Colorado,
the whole of Grand Junction of Western Slopes is now fully implemented
and operational, and are using the most advanced components of our
products. And recently we won the contract for the whole of the
Rochester area and we’re busy implementing that so the first position
should be live in June.

Matthew:
OK, let’s go back to the Santa Cruz story a little bit. Because I’m
interested in knowing two things. One is you have to get both ends of
the network set up so you have to get the hospitals on board–I don’t
know if there are any lab companies involved.

Ray: Yes, we have five labs connected.

Matthew:
And in terms of getting everyone on board, there have been a lot of
people that have set up propriety systems, and there is a lot of
concern about one hospital steering business referrals one way or
another. There is a lot of concern around that–not just on the
regulatory side but also on the pure business side-about should they be
sharing this as a network?

Ray: Sure.

Matthew:
And the other thing is physicians are very hard to change. I know Santa
Cruz is a slightly weird place-as is the whole Bay area–full of
surfers and the rest of it, but nonetheless physicians are tough to
change. They’ve been getting lab results the same way, no one was going
to pay them extra, and in fact they were going to have to pay to be on
this network. So why do you think you got an early success there when
some of the other places and some of the other areas have struggled
with this?

Ray:
Well there is an ROI [Return On Investment] for each of the
participants in the network. The ROI for the physicians’ practice tends
to be in ignoring for a moment the quality of patient care…

Matthew: Which between us physicians do …

Ray: I wouldn’t comment on that. [laughs]

Matthew: [laughs] The blogger makes a crass comment which of course he doesn’t really believe. But, anyway…

Ray:
There are many of our practices who have saved staff start dealing with
their patients charts, the paper charts. If you look at the average
cost of an chart pull, that is the cost associated with getting it out
of records. Whether for a patient visit or to refer to when a new piece
of information becomes available, like a lab test for that patient, the
average cost is somewhere between three and five dollars. If you
imagine that you are no longer doing that, that your paper records–if
you still keep them–are only there as a legal receptacle–only used
maybe on a visit–but maybe when there’s a legal issue raised and
everything else done online, the savings are huge. Some of our
practices, they have reduced from seven to three medical records
personnel, and that’s significant. If you look from a hospital’s
standpoint or a lab’s standpoint, most used a combination of courier
and fax to relay their information. Many still use courier.

If
you look at the cost of providing the information on paper and then
using a courier and compare that with electronic distribution the
savings are huge. One of the hospitals in Cincinnati saved close to
600,000 dollars a year on that item alone. There’s plenty of ROI here
but it does need to be articulated–people do need to understand it
before they’ll buy in. There are significant examples that are
independent from the users to remove that barrier.

Matthew: So…

Ray: Why Santa Cruz?

Matthew: Go ahead.

Ray:
Why Santa Cruz? Partly because it’s Santa Cruz it’s a slightly odd
community. Part of it because it’s laid back California where some of
those data sharing issues were not regarded as significant enough to
get in the way of patient care. We’ve experienced the same thing in
Colorado where they were so determined to get this right that they sat
down and solved the problems that had been presented in terms of
patient privacy and found that they could comply in a variety of ways
if they focused on it. So I think there are ways around the problem and
there were a variety of ways they could comply. There’s plenty of ROI
for all organizations to benefit. That’s not to say it’s easy. We’re
still selling to multiple organizations and as I said before, you’ve
have to have critical mass for this to succeed. You’ve got to sell to
multiple organizations together, you’ve got to get a community to move.
That’s a hard thing to do.

Matthew:
What share of the community does it need to be? What point does it
become real? DO you need to get 30% of doctors and a couple of
hospitals online–do you end up with 100%? What share of Santa Cruz…

Ray:
You end up with very nearly 100% and covering 100% of the population.
Once you get to that tipping point things go very well. It’s very hard
to classify what the tipping point is because it depends on the
distribution of the practices. You often find there are one or two
dominant practices and perhaps a dominant hospitals in the community.
Getting those to play ball is obviously crucial. But they still have to
have that community spirit. We had some early customers, some hospitals
who believed they could use our product for competitive advantage and
therefore were interested in communicating with their docs, but weren’t
interested in opening it up to other members of their community. We
refused to do business with those organizations on that basis. We would
say ‘look, you’ve got the first market advantage in your community but
that’s all we’ll allow.’ We would put in place a time period where we
wouldn’t approach the other hospitals until after 12 months or whatever
it was. We don’t believe fundamentally that this can be successful
unless the doctors can deal with everybody they need to deal with
electronically.

Matthew: Which leads us to the next
question here which is–take any particular market in which you’ve got
a hospital, let’s say the hospital’s been putting in the big
information system Epic, Cerner or whatever, and it’s now starting to
provide that out to some of the physicians in the community. One of
those technologies could be a competitor to yours in some ways. How do
you start to integrate–I assume in the 24 hospitals in Cincinnati you
have a ton of different internal systems–At what point does Axolotl
start up and where does that interoperability happen

Ray: There are two components to what
we do, one is the technology and the infrastructure necessary to allow
communications from the hospital systems to whatever is may be out
there. Secondly, If there is nothing out there we have something which
the industry refers to as an EMR [Electronic Medical Record] light
which is an EMR–a very low cost EMR–that we can put a physician’s
practice and to connect up the other end. If they already have an EMR,
whether it is provided to them by a hospital of or they’ve invested in
it and purchased it separately, we have an EMR hub component to our
product range and to our underlying infrastructure that will allow us
to connect to third-party EMRs. The standard that we use throughout all
our clinical communication is HL7, and that will include newly adopted
CCR mechanism as well.

Matthew: Right, OK, so basically you’re the message in the envelope provided as necessary.

Ray:
Clinical messaging is what the company was known for years ago. We’ve
evolved a little from that. That is a term we invented and is
trademarked.

Matthew:
[laugh] I’m all for that, all for industry trademarks. That’s
interesting, your business model–someone remarked to me the other day
that it’s interesting that the term business model evolved only after
people stopped selling software and started giving it away [laughs].
Before that people just paid you money for stuff but now you have to
have a business model, but your business model is that people pay you
money for stuff.

Ray: Yes.

Matthew:
That includes-how much in a typical Axolotl implementation are the
physicians paying and the hospitals paying? Is there much cross-subsidy
there? How does that tend to work?

Ray: It
depends very much on the relationship between the physicians and the
hospitals. In some states where the hospitals own large physician
groups they end up paying a much higher proportion of the fees because
they’re paying for their physicians. In California where that’s not
allowed, it’s a different situation.Some changes in the law have opened
that up. Some hospitals are now looking at what they might provide some
of the loosely affiliated physicians in way of an EMR or similar
product, looking at products like ours. And so we’re hopeful that that
will actually increase our deployment rather than decrease it. Even if
they choose an alternative product as I said to you earlier, we have
the ability to interface with that, we still expect to be the messaging
infrastructure to allow that to happen.

Matthew:
Right, right. Now let’s talk a bit about the other California towns
beginning with "San, " and I am referring to the reference to Santa
Barbara which had a heavily subsidized, from the California health care
foundation and others,  effort at creating a RHIO and a messaging
structure which really hasn’t gone anywhere. And in fact, it’s now
fallen, the thing being closed and they’re going to perhaps open source
the technology. But my understanding–and you probably know a lot more
about this than I do–was that they were essentially attempting to go
around again one local bidder per hospital and big smattering of
providers to create a sort of messaging system where you could go in
kind of search engine style to try and look at information that’s on
the people’s systems rather than sending a message. And you know, maybe
I’m wrong there, but give me a sense of what you think was happening
and what went wrong—if we’re doing an obituary on this.

Ray:
Well OK, all right. Well, you raise and interesting point. I’d like to
come back and talk about the query versus delivery mechanisms, push
versus pull as it’s called, because we offer both. And we haven’t
really talked about the query model, so we need to. But in terms of
Santa Barbara, I think that one of the difficult things [was] it
started at a time before the rules were clear on data sharing and
before people really understood what the impact might be. And my
understanding of the resulting solution was that the technology was
finally developed and worked, although it took far longer than was
originally anticipated. And during that time period some of the major
stakeholders decided that it wasn’t actually in their interests, in the
community, to share the information. And so they felt foul of not being
able to establish appropriate data sharing agreements and perhaps
appropriate reasons for data sharing agreements within the community. I
think that’s very sad, very sad for the industry and very sad for Santa
Barbara. I think the people that supported that financially and
technologically had the right ideas, and I think that eventually that
community will come around to putting data sharing in place again. But
it may take a while.

Matthew:
So let’s talk a bit about pull versus push. Actually I wasn’t aware
that you offer the pull variety. So tell me a bit about how you do that
and a bit more about what your take on that has been.

Ray:
OK. Well one of the problems with, the difference between push and
pull, basically push is delivery, which is what we have been discussing
so far. If a patient is admitted to a hospital by a particular
physician and a lab test occurs in that hospital, then arguably the
physician should have a copy of that. The hospital will ordinarily
deliver a copy of that lab result to the physician. We enable that
delivery to occur electronically. That’s push.

Pull is where a
patient may present to a physician for the first time and say, "I want
you to treat me now and here’s my complaint." And the physician has no
information whatsoever and might want to go out to the community and
say "OK, what is known about this patient?" And get information that is
generally available for sharing that would help inform the physician
and help him or her make a good, sound clinical decision. So that query
response mechanism is really a pull, what we refer to as pull.

And
what’s happened over the last few years, particularly with the
emergence of working health information exchanges and RHIOs, is a
mechanism that will allow institutions to control or safeguard their
information by pulling it into, if you like, databases that are still
under their control but will allow an ambulatory care physician to
query that database along with any other databases in the community and
to assemble, on the fly, information about the patient in front of the
doctor. That information typically would not be retained in one place,
so we are not talking about a centralized repository here, we’re
talking about what’s referred to in the industry as a federated or
distributed repository.

So the concept is each institution
maintains their own data. They control what is available for querying.
Physicians query multiple such repositories, pull the information
together, get it presented to them, use it. But it’s never retained in
any central store. And that seems to satisfy security and privacy
offices. It seems to satisfy the legal requirements of HIPA; and yet
seems to provide the capabilities that we need to for emergency
treatment and other treatment of patients. We think the first real
federated deployment in the U.S is ours ., and it actually is based in
Colorado. If you look at our press releases, it is described there.
It’s proven to be very successful. And we were advisors to Northrup
Grumman on one of the recent consortium projects let by the Office of
the National Coordinator. And that was a very successful deployment.
That uses similar principles.

So, we’re very pleased to offer
both. We think that the combination of push and pull helps speed
adoption within a community. And as I said earlier, adoption is key.
The critical mass thing occurs in two ways. Firstly, you’ve got to have
a critical mass of data supply for each user. And secondly, it’s a
communication tool, you’ve got to have a critical mass of users for a
communication tool to succeed. So there are two dimensions to that. So
having the push-pull we think is an advantage and a differentiator.

Matthew:
So the pull,  I think it’s evolving and so it’s changing. The one, I
keep going back to the report I wrote in 1994 about CHINs in which I
said basically that there is no reason for people to share this
information, and they’re likely to go away. And they did. I keep on
trying to say what is the difference between the CHIN and the RHIO? Now
there are two differences. I mean they’re obvious. One is there is some
legal structure now with HIPA. You can sue somebody if something goes
wrong with. That’s not nothing in the U.S. We’re both from a culture
where there are fewer lawyers but not that many fewer [laughter]. And
the other one is that there’s a lot more electronic data out there now
or data in a format which you can get electronic fairly easily.

And
I’m consistently coming back to the issue that the organizations, say a
big hospital system that is dealing with its business partners, and it
may have a lab as a business partner and it has a bunch of admitting
physicians. Dealing with the interoperability inside and messaging data
back and forth, clinical data, and for that matter administrative data,
to me is a no brainer because they’re already having to deal with all
these interfaces and it’s something they have to deal with already. And
that’s to my mind is actually the biggest problem in health care.
Getting one, any of these hospital systems that have got multiple
facilities dealing with hundreds or thousands of physicians. To me, I
was kind of only teasing you when we spoke in at HIMSS because I was
almost thinking, why are you guys calling yourself the RHIO company
when actually perhaps the biggest problem is dealing with the internal
side?

But it seems to me that part of the Santa Barbara issue
you brought up and it’s still an issue everywhere is that, I understand
why as a big hospital or physician I want to replace those couriers and
that mail. Because its expensive, and if I can replace that with an
electronic interface of whatever kind that works well it’s cheaper.
That’s a no brainer to me. What I don’t quite understand is the
business reason why I would want to make all of my data available to
somebody to come and look up. Because although it would help them–so I
have data in my lab, or my hospital admissions, or ER about the
admission of some patient or other that happened in the last two years
[and] that patient then shows up at some primary care doctor across
town or across the country or wherever or across the state–how does it
help me that this other primary care physician can now look up
something about my patients and why should I go to the effort of making
that data available?

Ray:
It’s a much more complicated question, because in the simple push case
you can look at a cost item and say ‘OK, I can reduce that cost item’
In the pull case you are talking about attributes of the U.S. Health
Care System. You are saying ‘OK, this can lead to better health care.’
So now if a patient survives because a doctor is able to pull
information that enables him to treat that patient differently, what
impact does that have on the hospital that made that data available?
That’s a much more difficult question to answer, and that’s why you
have to look for communities that understand that the concept of
providing better care, of reducing medical errors in their community,
will actually save the whole community cost, it will save the employers
cost, and the payers cost, as well as the hospital’s cost. So it is
more nebulous, I agree with you. I think that there is a rising tide
within the U.S., looking at the latest spend on health care, that is
begging to say ‘Look, we’ve got to attack this problem by combining
forces to attack it within our health care communities, not by
regarding each of us as a separate entity. And the communities that are
steaming ahead with that are the ones where the parties have already
gotten round the table, and recognized that fact. And they are now
looking for mechanisms, of which Health Information Exchange is one, to
try and help solve this problem and help reduce cost.

Matthew: Well every time I mention that on my blog I get accused of being this appalling English lefty socialist.

Ray: I’ll probably get accused of the same then, right?

Matthew:
You will. And I’m with you, which leads me to this sort of business
question about facts, which is half joking/full serious in that you
have an incredible business out there of hospitals and big health care
systems spending considerable amounts of money to do the internal heavy
EMR and EMR light, and then trying to figure out how to communicate
that within their own organizations and within their own core business
partners, the transactions that must be submitted to them. And that to
me would seem like the obvious place for you to be going full-tongs and
branding Axolotl as the solution to that problem. Whereas in the
marketplace you seem to be branding yourselves more as solving this
second problem, which is putting this whole community together to do
both the push and the pull, and which requires a lot more players
together, and requires a lot more community spirit or whatever the word
is.

Ray: Right.

Matthew:
As well as the business interests. And I’m wondering wouldn’t you be
better of saying ‘This is all very well, and we can solve that problem.
But let’s go off to every big hospital system in the country which has
got problems communicating internally’

Ray:
Well, when you say ‘communicating internally’ we don’t address the
problem of information communication within the four walls of the
hospital.

Matthew:
I mean internally within their systems… If you have a hospital that
has… Lots of hospitals and lot’s of business partners internally…

Ray:
Right, and indeed we can do that. The problem we set out to solve was
really the one of how to connect the community itself. So we want
physicians to be able to talk to physicians as well as to talk to the
lab in their hospital.So when a primary care physician does a referral
to a specialist, we can send along the lab-tests and everything else,
and they don’t have to be repeated and so on and so forth. Those are
all things that cut down cost and increase efficiency and provide
better care for the patients, so that has been our focus. Now, if you
ask me if it is more difficult from a business standpoint, yes it is.
And had we addressed the EMR problem perhaps in a way that the classic
EMR vendors did, which… I shall probably get criticized for this
description, but I would describe it as capturing each position patient
and counter within the health care office, sticking it in a database,
and then believing that querying that database will provide all the
answers to outcomes, analysis, and research, and so on. When in fact,
when we looked at the problem, seventy percent of the time physicians
spend within communicating with other physicians, with labs and their
hospitals, and so on. So it seemed to me that alternating that part of
the problem is the way to get success and to have impact.And it gives
us a slightly more difficult sales problem. I think that the outcome
where we deploy is more significant than the outcome achieved by a
single EMR.

Matthew:
Right. And so with that give me a little bit of background about where
Axolotl is, in its sort of evolution as a business, how many employees
do you have, what you can tell me about where you are with revenues and
growth and what you’re plans are.

Ray:
Well, we’re a private company so we don’t discuss our revenue. We are
growing by something close to 50 percent per annum, we have about 80
employees currently, we are focused very much on the growing health
information exchange market place, which coincides fairly strongly with
the RHIO space. – RHIOs being the entities that tend to foster health
information exchange – We do have other parts of our business, and
transcription is the largest part. Which is a component that we build
up because of physician requests, and we now offer a U.S. based
transcription service to any of the physicians in our communities that
may want to have the results delivered electronically through us. And
that electronic delivering can also go through third-party EMR’s as
well as our own EMR line.So, we expect to continue that growth. We’re
bidding on a number of city initiatives and state initiatives, and are
in touch with government bodies, and I sit on the board of the eHealth
Initiative. So we want to see more of these deployments occur, and want
to see the patients, the hospitals, and the health plans benefit from
that deployment.

Matthew:
So essentially you have more or less the current solution, and you
think it’s now a horizontal distribution, that’s now the next level?

Ray:
Oh yeah, there are always product improvements and we’re always adding
additional capabilities. In Santa Cruz we are now mining the data that
we’ve collected over the years, and are starting to look at the chronic
chair populations, and giving those statistics to the physicians, about
how well or badly they may be caring for that population, allowing them
to improve their standards of care. Registry applications, chronics
care, population management, and we’ve got bio-surveillance operational
in health care. So there are a number of things that we’re doing across
the spectrum, but once you’ve got the infrastructure in place you can
do fairly easily.A good example is in Cincinnati a year ago I think,
there was a problem with a particular… I guess it was a microbe in a
swimming pool; it took them a week to discover the cause of this
problem and shut down the pool. The same problem occurred a year after,
and because our infrastructure was in place, and the bio-surveillance
mechanism was in place, they were able to communicate in eight minutes
the problem. And they had the public health authorities shutting down
the pool within eight minutes. So eight days and eight minutes is a
terrific comparison. So, you can do that. And one of the things that
putting in the infrastructure enables is a lot more than we can
provide, but it allows you to look at whether you allowing for each of
the stake holders, and public health is a very important stake holder.

Matthew:
Great. Well I’ve been speaking with Ray Scott, who is the CEO of
Axolotl. Ray, thank you very much for coming this morning, it was very
interesting finding out a bit more and having a quick discussion about
where you think RHIO’s are going.

Ray: OK, thanks Matthew.

Matthew: OK.

Ray: Thanks Matthew, I enjoyed it.