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 2
- MicroHIS mobile app — “It’s one of those low-hanging fruits.”
- CPOE — “the next big leap”
- The biggest MU 2 hurdle
- Off-the-shelf vs self-developed solutions
- “When we talk about strategy, that’s what differentiates us.”
- WebHIS call queue
- Eyeing data analytics
LISTEN NOW USING THE PLAYER BELOW OR CLICK HERE TO SUBSCRIBE TO OUR iTUNES PODCAST FEED
Podcast: Play in new window | Download (Duration: 12:18 — 11.3MB)
Subscribe: Apple Podcasts | Spotify | Android | Pandora | iHeartRadio | Podchaser | Podcast Index | Email | TuneIn | RSS
Bold Statements
If it’s one of these low-hanging fruits, we generally try to do those quickly, because they don’t really take a lot of resource, but they add value.
When you develop a system and design it, we’re the ones that decide how it’s going to work. That sometimes gets more challenging, because if you say to folks, ‘how do you want the problem list,’ you get 10 different answers.
We can provide the systems and we can encourage folks to use the systems and encourage them to implement the functionality, but we can’t make them do that. It’s the departments that have to embrace Meaningful Use.
When we talk about strategy, that’s what kind of differentiates us. It makes their function more efficient because they’re not manually dialing a telephone number. It saves time, and it documents that they did, in fact, make the call.
Gamble: What about mobile apps — is that functionality available for WebHIS?
Skvarenina: Several years ago we developed a product called MicroHIS. I don’t know if you remember the advertisement that Apple had where they had a hand and they had an iPhone in the hand; we used something similar to that advertisement when we marketed MicroHIS to our physicians. We had a hand and we had an iPhone, but we had MicroHIS running there. MicroHIS is a mobile version of WebHIS. It has some really cool features. It has a physician rounding list where physicians can read all the patients lab results, radiology results, and dictated reports. There’s a demographic section where they can see who the next of kin is, the patient’s telephone number, etc.
What’s neat about the MicroHIS is that there’s integration with the device itself. In WebHIS, when a nurse starts her shift, she assigns herself to the patients that she’s caring for that day. When she does that, she also takes a telephone and she tells the system which telephone that she has for that day — maybe her extension is 6213. So then on MicroHIS, what happens is that the physician brings up the routing list and sees the nurse who is caring for his patient that day. If he wants to speak to the nurse he can tap her extension, and that causes his phone to start a call from his phone to the nurse’s phone. It’s extremely streamlined; he doesn’t have to write down numbers and he doesn’t have to dial anything. We take care of that right in MicroHIS for him. It’s a really neat feature. For surgeons, we have the complete OR schedule there so they can see their cases for the day, and again, they can open up that mini version of the patient’s electronic medical record to review things before the surgery.
Gamble: As far as putting that app together, were there a lot of obstacles or did it require a lot of trials and testing?
Skvarenina: It took us about four months to build MicroHIS. Usually the way we develop new applications is we have an idea, so we might do a proof of concept and just put something together small. And then from that proof of concept, we show it to a group of physicians or users, depending upon the type of product that it’s going to be, and we start to collect their input and then have them help us design what they are looking for at the end of the day.
MicroHIS was derived because I knew we had to have a mobile solution. Physicians were accessing the full WebHIS right on their iPhones and their Android devices, and it’s not really formatted for that type of display. So I started thinking, what would be the minimum needed for a handheld device to be useful to a physician? That’s where MicroHIS came from.
Gamble: As far as any updates that need to happen with that, is it similar to the process for the WebHIS system?
Skvarenina: Yeah, it’s the same. If a physician came in and said, ‘hey, could you add X, Y, and Z to MicroHIS,’ the request would come through me. I would take a look at it, determine how much effort it would take, and if it’s one of these low-hanging fruits, we generally try to do those quickly, because they don’t really take a lot of resource, but they add value. If it was something complex, that would take time.
For example, we developed CPOE on WebHIS last year, and it’s a wonderful CPOE. Physicians praise it, telling us it’s much easier than at our surrounding hospitals. But a few now have started to say, ‘When can I do CPOE on the MicroHIS?’ That’s not something that’s easy to develop because CPOE is quite complex, and to make it run on a mobile device with all the capabilities that we do on WebHIS is going to take some time to put together.
Gamble: Are there any other functionalities you’re looking at with MicroHIS for the near future?
Skvarenina: Not in the near future. The user base for MicroHIS is only about 50 to 60 physicians that use it on a regular basis. We were really hoping that it was really going to take off and become heavily adopted by the physician population. Some physicians are not as tech savvy as others, and I think that we basically leveled off on the number of active users that we’re going to see for a while. They really have not been asking for anything new. I think CPOE on the MicroHIS is really the next big leap, but it’s not top on our priority list for development.
Gamble: Okay. You mentioned before that you’re looking at Meaningful Use Stage 2. Being an organization that uses the WebHIS system that was developed in-house, are there unique challenges when it comes to things like Meaningful Use 1 or 2?
Skvarenina: Probably the biggest challenge is really defining what the functionality is going to be. If you buy a vendor package, that vendor has already determined how physicians are going to enter problems and a problem list and how each functionality is going to work. When you develop a system and design it, we’re the ones that decide how it’s going to work. That sometimes gets more challenging, because if you say to folks, ‘how do you want the problem list,’ you get 10 different answers, verses someone that says ‘vendor XYZ, here’s how you do it,’ and you don’t have a choice. Sometimes having that choice it actually more complex than just getting something delivered and being told how to use it.
Gamble: As far as Meaningful Use 2, is there kind of like a task force or a group that is assigned with the specific duties of meeting Meaningful Use Stage 2 requirements, or is it not really necessarily done that way?
Skvarenina: On an IT side, I have an analyst that is really dedicated to the Meaningful Use effort. She’s been the one that has coordinated all the testing with ICSA Labs for certification. On that alone, we could talk for an hour about how complex, interesting, and challenging that really was. Even for stage 1, it was really the same thing, although back then, it was CCHIT that we did our certification with. This analyst basically goes through the test scripts line by line, comes to the developers, checks their work, and makes sure that every piece of functionality matches the test scripts. Then we do our test. She basically facilitates the test, and once that certification is really achieved, then it becomes more of a hospital project and not an IT project.
Some people view Meaningful Use as an IT project, but it’s really an entire hospital initiative, because in IT, we can provide the systems and we can encourage folks to use the systems and encourage them to implement the functionality, but we can’t make them do that. Really it’s the departments that have to embrace Meaningful Use, see what the requirements are, and actually make it happen. Sometimes that can be challenging.
Now that we’ve achieved our second certification, we have this group called the IT counsel that has been formed. The IT counsel talks about, in general, IT initiatives, priorities, helps us to decide which major projects we’re going to work on next. Meaningful Use is really at the top of the list for the counsel to take on and help us implement.
Gamble: In terms of some the other projects you’re looking at or other priorities, what else is on your plate as far as the organization’s IT strategy?
Skvarenina: We’re always looking to add additional capabilities. On our plate is reengineering the pre-admission testing process — we’re working on a project for that. We have a call center and we are working on expanding the call center functionality. We talked earlier about some of the customizations that can be done when you do your own system.
One of the neat things we have done for the call center is we’ve created a call queue. This queue gets fed from different events that happen in our systems. So if you have a surgery, we create a task for the call center to call and follow up on your surgery a day or two later. If there’s an appointment coming up for a visit, we’ll put a task into the application for the call center to call the patient to talk to them about the appointment.
What is neat about that application is that we’ve integrated with our phone switch. So you’re running WebHIS app, you’re looking at the WebHIS, and you have this task that comes up that says call this patient, and there’s a little icon next to the patient’s telephone number. When you click that telephone icon, it causes the phone at your desk to start ringing because it’s done the dialing for you.
Those little things are really value adds that normally you won’t see in the off-the-shelf commercial products. Again, when we talk about strategy, that’s what kind of differentiates us. It makes their function more efficient because they’re not manually dialing a telephone number. It saves time, and it documents that they did, in fact, make the call. It’s really neat.
Gamble: What about doing analytics, is that something that you’re looking into or planning to do soon?
Skvarenina: We have a mini data warehouse built into WebHIS, and that warehouse gives our users ability to do some data analytics. There’s a person here that is generally dedicated to doing data analytics and he is quite skilled at database models and database tools and analytical tools. So that is something that we do today, and we’re really looking to expand on that. We’ve been looking recently at some different commercial products. Companies like Tableau, for example, or Roambi — these vendors have data analytic tools that at some levels help you query your data better, and at other levels help you present it much, much better. WebHIS is web-based and it does have some nice graphical tools built in, but these commercial data analytic tools are extremely slick and have great graphical capability. So we are looking at implementing one of these more robust tools based off the WebHIS data.
Share Your Thoughts
You must be logged in to post a comment.