Michael Skvarenina, VP & CIO, Holy Name Medical Center, Chapter 1

Michael Skvarenina, VP & CIO, Holy Name Medical Center

Michael Skvarenina, VP & CIO, Holy Name Medical Center

Every time Michael Skvarenina tells a fellow CIO about WebHIS, the homegrown HIS that has been a staple at Holy Name, the reaction is the same: shock, followed by awe. Shock that a forward-thinking organization opted away from an established solution, and awe that the staff has been able to maintain and improve the system through the years. In today’s complex, fast-moving environment, using a customized system that lacks vendor support or user groups might seem a little too out of the box, but, according to Skvarenina, that’s precisely the idea. In this interview, he talks about the benefits and pitfalls of developing in-house, the next steps for WebHIS, the problem with patient portals, and the mantra that guides his organization.

Chapter 1

  • About Holy Name
  • History of WebHIS: from green screens to web interface
  • Benefits of developing in-house
  • “IT as a strategy, not a resource”
  • Priority pyramid
  • Looking at vendor partners — “This is an interesting time.”
  • Aprima in ambulatory

LISTEN NOW USING THE PLAYER BELOW OR CLICK HERE TO SUBSCRIBE TO OUR iTUNES PODCAST FEED

Bold Statements

If there’s a new regulation, something I’ve got to do right away, I’ve got a staff developer that I can just run to and say, ‘please take a look at this, we need to get this done,’ versus submitting a ticket to a vendor.

The physician users come to us and say, ‘Why aren’t you selling this? You should be selling this.’ They talk about the surrounding hospitals and what systems are installed there, and they always have praise for WebHIS and say it’s easier. It’s more intuitive. It’s less steps.

It’s really custom built for Holy Name’s workflow. There are things that we’ve built in that specifically fit here that may not fit as well in another organization.

When you talk about the development priorities, and if you look at all the Meaningful Use requirements for an ambulatory setting, some are the same as the hospital side, some are different.

Gamble:  Hi Mike, thank you so much for taking the time to speak with us today.

Skvarenina:  My pleasure.

Gamble:  So to get things started, can you just give a little bit of background information about Holy Name Medical Center — what you have in terms of bed size, ambulatory care, things like that?

Skvarenina:  Holy Name is a hospital in Teaneck, New Jersey. We have 362 licensed beds. We have an ER department. We have a cancer center. The hospital, over the years, has been growing and adding different service lines to make us one of the premiere providers in Bergen County.

Gamble:  For those who are in different areas of the country, you are in Northern New Jersey, pretty close to New York City.

Skvarenina:  That’s right. We’re just about 10 minutes away from the George Washington Bridge. We’re easily accessible from the NJ Turnpike, Route 4 — there are lots of ways to get here.

Gamble:  And it’s a pretty densely populated area.

Skvarenina:  Extremely.

Gamble:  Now do you have physician practices that are owned or affiliated with the system?

Skvarenina:  There are a number of physician practices that we’ve been acquiring or partnering with. For the past several years, we’ve been adding these physician practices to our service line, relating to family practice, internal medicine, cardiology, all the major services. I think that’s really the trend in the industry — to have physician practices partner up with the hospital, besides the affiliated doctors. These are the practices that are owned by the hospital, and then there are general doctors that are out in the field that are on our medical staff. And you’ve got the doctor’s offices that are owned by the hospital.

Gamble:  As far as the clinical application environment, you have an HIS that was developed in-house. This is really interesting to me because as you and I have talked about, this is a rare thing now. So I wanted to talk first about the development process for WebHIS — how it was developed, who were the key players, things like that.

Skvarenina:  So back in the mid 80’s, Holy Name had been looking for a replacement for their clinical information system, and actually their entire IT system. I had worked for a small company in Wall, N.J., called Spectrum Systems Incorporated, which was selling hospital information systems. The company didn’t have a large product line. Basically all it had, at the time, was an outpatient billing system, which we had run in just one hospital here in New Jersey. It also had a small payroll application, which we had in a few hospitals.

The company came to Holy Name and I proposed an entire information system. The hospital was interested, so we signed a deal. In 1986, myself and another developer came to Holy Name and we started writing all the pieces that were missing from the base application, which is really all the inpatient pieces — ADT, inpatient billing, and coding, which were simple things back then. In the 80’s, you didn’t have all the sophistication that you have today in IT systems.

That’s really the real genesis of it. Then from 1986 on, we just continued to develop the system and add more and more functionality to it. It was in 1999 that we made the leap to the web interface. Prior to 1999, it was a green screen, text-based interface. At that time, I decided to give it a name, and we started calling it WebHIS (Web-Based Hospital Information System). From there, we started adding tremendous capability because the web interface really improved our ability to put data in and get data out. Today it’s full of incredible functionality, sometimes rivaling with what the commercial products might have to offer.

Gamble:  Why did the organization decide to go with something like this instead of one of the more established or widely used vendor products?

Skvarenina:  I think the leadership here, at the time, really liked the ability to develop applications internally. When you do that, you get more flexibility; we can easily create something that just doesn’t exist on the market. We can react much quicker to things that a vendor couldn’t react to in many ways. If there’s a new regulation, something I’ve got to do right away, I’ve got a staff developer that I can just run to and say, ‘please take a look at this, we need to get this done,’ versus submitting a ticket to a vendor and having something prioritized where you’re in line with a hundred other customers. There’s just a big advantage.

Our president and CEO will sometimes give a talk about IT systems, and will call IT a strategy versus a resource. So at Holy Name, we view IT as a strategy, not just a resource that you must have to run your business.

Gamble:  Now at this point, is it something where you update systems pretty often, or do you do it at certain time intervals? How does that work?

Skvarenina:  There’s a priority pyramid that I sometimes speak about, where I talk about what we do, in what order. Usually regulatory things are at the top of that pyramid. In general, we work first on anything that’s patient safety issue related.  So if we identify something that could be a patient safety issue, those types of things are at the top of our list. And then there are bug fixes — if we find a bug that could affect something, we work on that. Then we work on regulatory requirements. If there are low-hanging fruit — quick things that someone needs that can really increase productivity or patient care, whatever that may be — we work on those. And then you have revenue cycle, and then finally, operational efficiencies; things that can make the operation in general more efficient.

Recently with the ARRA Act, Meaningful Use has been one of our top priorities to achieve. And we did this twice now. We did it in 2012 by achieving 2011 criteria, and we just completed the 2014 criteria which puts us in line to start Meaningful Use stage 2 in October.

Gamble:  When you have a system like this, one of the issues I was thinking might come up with development is that balancing act between wanting to keep the users happy, but then also not driving the developers too crazy with constant tweaking. How are you able to navigate that?

Skvarenina:  In general, our users work very well with us, and they don’t usually ask for things that are unreasonable. They also know that I have a limited set of developers, so they don’t ask for little tweaks here and there that aren’t really needed. As people come and meet with me about changes that they ask for, I evaluate every request — does it make sense? What value does it add? Is it something that we have to do? There’s a whole criteria that I go through when evaluating what a request may be. Most of the time, the users really do come asking for things I think are appropriate.

Gamble:  It sounds like it’s managed well enough, but it’s certainly something that I think maybe scares off some people as far as, ‘will we constantly have to make these changes?’ But as you said, it’s a matter of having the right people.

Skvarenina:  What’s really exciting about WebHIS is that we’ve been talking for many years about marketing it and making it go commercial. We get this idea because the physician users come to us and say, ‘Why aren’t you selling this? You should be selling this.’ They talk about the surrounding hospitals and what systems are installed there, and they always have praise for WebHIS and say it’s easier. It’s more intuitive. It’s less steps. They frequently tell us how much they like our system over the competition. Recently, there’s been some activity with a consultant company that’s helping us take a look at WebHIS. They looked at the system and it definitely has marketable traits to it, and they want to help us get it to a marketable position.

Also, in looking for other modules to add to WebHIS to make it better, different vendors on the market have also come to me and asked, ‘Is it running outside of your four walls? We’re looking for a strategic partner to expand our product.’ Some big names, so it’s really quite interesting. This is an interesting time for WebHIS.

Gamble:  Is there any downside to marketing it outside of the organization?

Skvarenina:  The only downside is potentially that it would be a little bit hard to maintain because today it’s really custom built for Holy Name’s workflow. There are things that we’ve built in that specifically fit here that may not fit as well in another organization. I can’t really give an example off the top of my head, but there are some specifics that we have built in that might not be easy to implement someplace else. For us to maintain the Holy Name version and then maybe a more generic, international version could be a little bit challenging.

Gamble:  As far as the physician practices, what type of systems are they using?

Skvarenina:  The physician practices have a number of systems. I don’t know if you want me to give specific brands that are being used, but there is one large ambulatory system that we are using today, and there are a couple pockets from physicians that we’ve picked up from different vendors.

Gamble:  What’s the large vendor being used?

Skvarenina:  We’re primarily using Aprima for our ambulatory care system — that’s the practice management site. In the EMR we’ve interfaced WebHIS to work nicely with Aprima so we send to Aprima lab results, radiology results, and other data. We’ve also interfaced their EMR with the WebHIS, which is a pretty cool integration. What happens there is that there’s a button on the Aprima patient record, and when the physician clicks that button, WebHIS gets launched, Aprima passes us the credentials of the user, it passes us the patient context, and then we open up the hospital’s electronic medical record right at the physician’s desktop. So it gives the physician access to the hospitals record, with just a single click. It’s really slick.

Gamble:  So you’re not necessarily going to try to extend WebHIS to physician practices, or does it not really have that kind of scalability?

Skvarenina:  It definitely is scalable, and physicians have asked us, ‘when are you going to develop WebHIS for my office?’ We’ve been toying around with the idea of something called WebHIS Light, which could be the ambulatory side of it. Again, when you talk about the development priorities, and if you look at all the Meaningful Use requirements for an ambulatory setting, some are the same as the hospital side, some are different. It will probably take a good amount of effort to develop WebHIS enough to be used in an ambulatory setting.  So it’s definitely on our roadmap, but I don’t know really when we’re going to get to it.

Chapter 2

Share

Email Newsletter

Sign up to receive our latest updates delivered straight to your inbox.

Share Your Thoughts

To register, click here.