[music]

David Henderson: Hey, everyone. Thank you for joining us again, this is another episode of Timeout for Anesthesia. I am quickly becoming your host, David Henderson. That wasn't the original plan, but I've kinda evolved into it. And my co-host, John Lutes. How are you doing today, John? 

John Lutes: Hello. I also wasn't planning on being a host. But hey, what the heck, especially for onboarding and Integrations.

David Henderson: Good. And that is what we're talking about. We are continuing our series on onboarding that John capped off for us. And this is our third, I think installation of this series.

John Lutes: The 34th.

David Henderson: And today, we're gonna invite back a special guest that we had on previously, Matthew Oldham. He is our VP of engineering. And again, so excited to have Matt on board. And today, John, what are we talking about? Integrations? 

John Lutes: Integration. So this will be a continuation of the initial kinda overview video. We're kinda diving deep into all the sections of the onboarding that we go through, really kinda covering in a bunch of different podcasts, everything we go throughout on that initial kickoff call. So this section is where we're circling back to the integration conversation. And this is where we loop Matt back into the conversation in a big way. Matt is our VP of engineering. So he knows everything integration. This is one of the big beating hearts of our system. And one of the wonderful things about our system and how we can really integrate with so many things and do so many amazing things. And Matt is... This is his brainchild if you will. So he knows everything there is about this.

John Lutes: So I'll bring up my screen and stop talking hopefully sooner than later. And so here we are, yeah, we're back to our sheet here. That may be familiar to you now, obviously, we've done all of our things, we've talked about your org, your naming conventions, what facilities will be onboarding, who your primary points of contact are, who we are, of course. And then this is where we are, why we're doing this kickoff call right here. So we've done the client info pack, wonderful conversation about the forums, and how important that is. And now we're going back to integration. I think we always like to call... Forums and integrations are kinda the two long poles in the tank, if you will for onboardings. These two things are the only things that really kinda make things go wrong. There could be a forums committee, that would take a while to go through a forum to make sure that everything works okay for that workflow.

John Lutes: In integration, it could be great. We can do this integration, we understand everything you need, we'll put that on the slate for next quarter. That obviously, will make an integration go long. I will tell you one thing that I'm always proud to say about our company. Onboardings go as fast as you want them to go. And we are never the one holding things up. And that's particularly true in integration. In no small part by the magic that Matt here does. So as promised, I'll stop talking here. And Matt, I'll hand it off to you. Again, we usually go through this kind of an onboarding kickoff call, this will also sometimes put out two separate meetings. Matt, yeah.

Matthew Oldham: Thanks, John. Thanks for having me back guys, this is always fun to talk about. And as John said, it's a big part of every onboarding. I mean, obviously, we need data from we as Graphium, Graphium platform, your instance in Graphium needs data from the hospital. And then the hospital needs data back from Graphium, about your anesthesia cases. And so integration is obviously the key to making that happen, and so that's a huge part of our platform. It's a really big part of our platform, it's hard to overstate the part that integration plays. It's honestly where I spend most of my time because there's so much need for integration, not just with the onboarding, but throughout the lifecycle, throughout implementation, throughout the course of anesthesia cases being captured over the course of the year, and all the activities that happen that are annual activities.

Matthew Oldham: And it's a long pole in the tent for onboarding a lot of times because there's a couple of hurdles, we're always gonna have to cross when onboarding a hospital facility. One is the need to establish secure connectivity with that facility, doing that facility's data center, or IT infrastructure and Graphium we're a cloud platform. So that, in and of itself is not the traditional... The context that hospitals have been used to working with, it's more and more common these days than it was when we started but still not 100% the way things are. And so, to establish secure connectivity, typically the traditional approaches you have a secure VPN tunnel. That's hard to manage. It requires more resources, it's more costly to set up.

Matthew Oldham: And ultimately, it's less secure than the option that we make available, which I'm thankful to say that we clear this one hurdle by making available this piece of software we call the Graphium Integration Client or the GIC. You'll hear us refer to that a lot. You'll see it in the documentation for onboarding and the facility registry. So the GIC helps us kinda cross that VPN hurdle very quickly. The other thing that GIC does for us is, it helps us kinda cross the network security hurdle. And I mentioned earlier that a traditional VPN tunnel is less secure. It's not that it's insecure, it's just that there are more secure ways of establishing connectivity. And the GIC lets us do more of a socket to socket type connection with a facility as opposed to a firewall to firewall connection. So not only do you not need all the IP resources you need to set up that VPN tunnel and maintain it, we're gonna get a more secure solution in the end by using the GIC, and what the GIC is is is I think John even has our Graphium integration guide on a screen.

John Lutes: I do.

Matthew Oldham: So this is what we send you as the customer, and this is what we provide your IT team and kind of what we walk through with them. And it's a really short guide, but it kind of highlights what is the GIC? Where does it live in your IT landscape? What does it do? And really what it is, it's just a small proxy client that is comprised of a set of Windows services that runs on some Windows machine behind your firewall. That's the good news. Part one is it runs behind your firewall and it doesn't need to be sitting outside the firewall. Number two is it's really small, that's the other piece of good news, alright? Really small footprint, light weight, it can exist on a... It can be installed in an existing server or you can give it its own dedicated Windows host, whatever you want. It's low maintenance, you don't have to do anything with it once you install it, it's kind of self-updating, self-maintaining and it takes about a minute to install, so it's really, really nice in that regard.

John Lutes: I'm just scrolling around here on the GIC. This is obviously something that we'll send out ahead of time. Usually, actually at the very beginning of the onboarding if you noted, for doing integration. It's one of those things that are like, "Give this to anybody who will read it, please, it will make everybody's lives easier." And then we'll go through it on the the kick-off call and then more in-depth if we need get to the specific stakeholders like that, but you didn't say the one thing that I always love to hear you say. You always call it a headless...

Matthew Oldham: It is a headless application, John loves that.

John Lutes: And I always had this vision of [0:07:38.7] ____ running around, with like an IT use situation.

[laughter]

Matthew Oldham: Yeah, and all we mean by that is there's no UI that goes along with this piece of software, it's just you install it, it takes... We'll give you an activation code, you run the installer on the host that you wanna install it on, and it installs itself, and it kind of goes away and that's the last you see of it is a set of, I think, five Windows services that run and kind of do individual... Have individual functions. And those, I mean... For the IT audience and those who are in IT listening, or you may be dealing with this side of an anesthesia practice's interfaces, it's keeping itself updated with security updates, it's keeping itself healthy by downloading any software updates it needs to function correctly and communicate with our platform correctly. It's giving us health checks to say, "Hey, this... Not only do I still have connectivity to the internet, I can talk to Graphium, but I can also talk to the host EHR that's sending me information. And I'm able to successfully send the information back to the host EHR." So those health checks is another thing that it communicates with and then it's exchanging the information. Sending us outbound ADT. Sending back to the host EHR the anesthesia record information if necessary.

David Henderson: So Matt for our anesthesia listeners who may not be as technical, this does... This is different and a more updated way of handling an integration. Just what's a really dumb down version for people like me who are less technical of what makes this better than, for instance, a VPN tunnel version of dealing with integrations that might have happened previously? 

Matthew Oldham: Yeah. It's a great question and it's really hard to talk about it, and it's really hard to not describe it and to answer your question in a technical way. But if you think about it from the perspective of the IT administrator who has to set up this interface or interface with a... It's really broader than that, interface with a new third-party vendor in the form of Graphium Health. They may have the anesthesia practice there who is contracted instead of provides contractor services at the facility. That contracted entity, which is the anesthesia practice, has another third-party vendor that they use, called Graphium Health. And we have to integrate it to the hospital with that facility or with that vendor, Graphium Health. How are we going to do that? And how are we gonna do that securely and how are we gonna do that? How are we gonna cross all the security hurdles that we have to cross to make that happen. From their perspective, when we say, okay, this is the GIC, this is... This is what it takes, and you don't need a VPN tunnel. So number one, that means you don't need to really involve your network security team if you have a big, large network security team, we're always happy to talk to those folks and answer their questions.

Matthew Oldham: This document, we intentionally included a lot of information that was specific to that audience to say, "Okay, hey, if you have concerns about let's say encryption protocol. Well, it's TLS 1.2 or above." So we're already giving them the key things they need to notice here, okay, this is a secure solution. Well, it doesn't need to live outside the firewall. Well, that means that... That's really good. That means we don't have to have any... We don't have to open any firewall ports that allow inbound traffic into our network, that's always a plus, and that makes the process much faster. And because it only...

Matthew Oldham: I know we haven't gotten into this in this particular discussion, but the way that the GIC functions is that it only talks in an outbound fashion. As I mentioned, you don't have to... The IT administrators don't have to open their firewall to allow inbound traffic from Graphium. The GIC takes care of all that, but only talking to Graphium in an outbound manner, and so that means that they don't necessarily have to have update their firewall to white list any traffic going out because it's all going out over the normal port, the 443, which is how all of SSL traffic in a secure website already goes out of the data center or out of the facility already. Now some facilities do require white listing that outbound traffic, but those are really easy changes to make. And again, it really lowers the barrier to entry to getting integrations up with Graphium, and again, the GIC makes all that possible.

David Henderson: That makes a lot of sense.

John Lutes: Very much our secret weapon. I love this thing. I love to see how much people love it when we get it going on.

Matthew Oldham: And I think the really cool thing and a big... The big... One of the biggest selling points too... And John, you've been on these calls, you've been on many of these calls, we have these all the time.

John Lutes: Oh, yeah.

Matthew Oldham: It's not uncommon for us to go from introducing ourselves to the IT administrators on an onboarding call or a kick-off call for integrations, to explaining the guide, having them download it and install it, and even set up the ADT interface all on the same call. We've had that happen within 30 minutes with not just small organizations, we're talking really big multi-facility hospital organizations. It's really possible and the GIC makes it possible, so.

John Lutes: It is our little bit of magic.

David Henderson: That's incredible.

John Lutes: Yeah, and it is great to watch people's reaction to it, that's great. Wonderful. Did we also cover... So this is obviously the GIC... So going back to our list here. Obviously, that's ADT. Did we talk about the ORU push back into systems? 

Matthew Oldham: Well, we really didn't even cover why do we need ADT, but I'm happy to talk about both of those really quickly.

John Lutes: Sure.

Matthew Oldham: ADT is probably the most important. And it's really what we need to make it possible for you to go live using Graphium at the point of care. And as I mentioned earlier, we need data from the hospital EMR for Graphium, and then the hospital EMR needs data back from Graphium. Well, this is kind of part A in that equation, because we need to be able to pre-populate the patients that the anesthesia providers are going to see at the point of care, we need to pre-populate those in Graphium. That makes that data available so that when they have an anesthesia encounter, they don't have to wait for anything, they don't have to type in a patient's name or an encounter number, or an MRN, they just scan a bar code, the patient already exists in Graphium by function of that ADT interface, and they're often charting on the case, so that makes it really easy. But we also use that demographic information for sending downstream to billing, to the billing software, or to the billing vendor, back to the practice, so that they can generate claims.

Matthew Oldham: So all the insurance and guarantor and contact information for the patient comes across that ADT interface and then enables that downstream business workflow of claim generation. And then the third thing we need that form and use that data for is for macro reporting at the end of the year. When we report data to the QCDR, there are certain demographic points or data points about a patient on a case, that are required to report that case to the QCDR, so ADT is super important. And it's really the easiest to get off the ground because, one, the hospital's got, they've got ADT interfaces already, probably scores of them running between the registration system and all the various ancillary systems. And so we make it easy, again, by saying, "We don't need a custom ADT interface, we will take your standard vanilla ADT, you just point that interface to this GIC inside of your network, and we'll take it from there," it's really quick and easy to set up, again, sometimes even on the first kick-off call, and so that's the ADT.

Matthew Oldham: The ORU is really us or Graphium getting data back to the hospital EHR, so that the anesthesia record can be posted to the patient's chart. So that helps the HIN, medical records department, but it also can be used by the PACU staff. If you have a... If maybe the facility has a PACU workflow where they're accessing the anesthesia record electronically for post anesthesia care in the recovery room, well, if we send that back in real time to the EHR, or to their scanning and archiving module or their HIN system, their imaging system, the PACU nursing staff may be trained to look there and use that for recovery room care. So that's one way, and that's another audience, I guess, that it helps. Not all customers use this interface, maybe they have a paperwork flow, meaning they print their anesthesia record to the PACU printer for the recovery room nurses to use. And that's fine too. We have plenty of customers who do that.

John Lutes: Yeah, I like that. So there's obviously a way to go truly paperless, if that's what you want. But we'll talk about that later on. I can probably with Frank about what's... I know we have a section down here that says, "printer", and it's just like, "Wait a second, well, aren't we going digital?" Well yeah sometimes people do want to print some things. And even if you're not printing in your workflow, it could be just something clever to have like, "Oh, I'm gonna print that real quick." And you can do that from your IPad obviously, but yeah, if you wanna go truly paperless, obviously these are all the mechanisms. So very cool. Billing integration, we do have another document on this. I can bring that over.

Matthew Oldham: Yeah. Billing is one of those workflows that is unique in the sense that it seems that every customer we encounter is using some unique billing work flow. I think it speaks to the complexity of billing for anesthesia. From one perspective, you may hear somebody say, "It's really straight forward." But there are some really unique workflows in anesthesia when it comes to things like OB cases, or labor dissection conversions, that make anesthesia billing really complicated. And so, that coupled with the fact that an anesthesia practice usually has an internal billing team they're working with who's doing the coding, they have certified coders who are actually converting, doing all the coding for a case, so that they can create a claim in their software.

Matthew Oldham: And then you actually have the billing software vendor, who in many cases is doing some of those services for the practice, or they're just getting, they're kinda behind the scenes supporting their software for the practice who's really doing all the work, but either way, there are so many billing vendors out there, so many different types of software and so many different workflows being used for anesthesia billing. And we've encountered a lot of those, and as a result, we've built a lot of different unique, very custom interfaces for billing. And so what we try to do, and what we try to steer our customers to, is this kind of what we call, our standard billing interface or standard outbound billing interface. And that's what this specification here is, and it's... Because there's so much data involved that we kind of carved it out into its own document for customers who need to implement this interface, which many and most do but this is a really broad interface and that it really allows us to send you everything about an anesthesia case that you could need possibly for billing.

Matthew Oldham: And then along with the data, we send you in this kind of discrete data interface, we accompany that nightly data with the PDFs of all of your anesthesia records. So, it really gives the billing team everything they need to do claim generation. The goal of this is to make it... To kind of automate claim generation. So, if you're capturing all of the CPT codes for your diagnoses and procedures and your comorbidities, you're capturing all the codes and you're making sure your forms are complete in Graphium, you're really giving the billing team everything they need and if it's captured electronically in a discreet fashion, this interface will allow us to get it to the billing company. And hopefully with relatively low effort, they can ingest that automatically into their billing software and generate claims. The goal is automatic claim generation. It's somewhat of a panacea, but we still strive for that as much as we can to make that work easy.

John Lutes: That's great. Well, I think that pretty much concludes this section. Obviously you can see we go through this obviously quickly in the kick-off call, but you can see obviously where it can break out into separate meetings with a billing team or somebody else that wants to talk about this. But also, it's amazing what we can get done and how fast we can get it done. Can we talk about systems just real quick, before we conclude? What are some systems that we've integrated with? Start rolling them off the top of your head.

Matthew Oldham: Oh, goodness. [laughter] So I think we'll start with the most common ones we see. We see Epic, we see Cerner, we see Meditech all the time. We see McKesson, we see Allscripts, we see... Oh, goodness. You have all the kind of the surgery-centered specific ones. The HST Pathways, the Compulinks, the GMEDS and the ProVations, all of the specialty type practice software that are used for those types of practices. Just when you think you've seen them all, we'll encounter a new one but we've integrated with so many of them. And thankfully, we can... Again, that's one of the things that the GIC makes possible is that we build in support for all these various vendor platforms, so that with one piece of software we can say, "Okay, if you switch... If you're sending it to us from Allscripts or Paragon or... Again, Corepoint or specific integration servers that speak in a really unique way or handle things in a really unique way, and then you want us to send it back to you on base for medical records or some other unique system, the GIC knows how to talk to all of those systems. We build in support for all of these various products into that software, but... Yeah, there's a lot of them. I can't possibly remember them all. And John...

John Lutes: We have truly never met a system that we couldn't integrate with, is an accurate statement.

[laughter]

David Henderson: And John I would like...

Matthew Oldham: In some form or fashion, that's true.

David Henderson: I'd love to throw out there also, that while we've integrated with every... We also have clients where we've not done an integration before because of some kind of barrier to entry. Either the IT team can't handle it at the moment, or the cost from the host system... Our costs are relatively low, but sometimes the cost from the host system is just a huge barrier to entry, especially when we're talking about somebody in rural healthcare. They're at smaller facilities, with smaller caseloads or things like that. So, I guess my question is this...

John Lutes: I know where you're going with this. [laughter]

David Henderson: If you don't do this up front, we can do this at any time, is that...

John Lutes: Absolutely. Yeah, obviously, we can do this at any time. And we've done that before, we've gotten people started up because, "Oh, I can't do this for another three months." But in the mean time, you could do it this way, you can add your own people to the system manually, obviously. And Matt, I guess there's another thing we didn't really talk here is that we do have another way of getting patients into the system. And you can probably explain this better than I am, where we can put a file into an SFTP and then the system can scoop that up and can populate your demographics that way. Not the easiest way I suppose, 'cause somebody is doing the manual data entry at some point. But it's definitely something we can do obviously, right? 

Matthew Oldham: Yeah, for sure. And again, the GIC doesn't solve all of our problems. It's really intended for kind of that real-time data exchange with those hospital systems and ancillary systems. If you have software at your facility, a scheduling system, that doesn't support integration or it's implemented at a facility that won't allow you to integrate, but you can run a report and export all of tomorrow's patients and cases that are on the schedule, if you can do that in a format that we support and drop it onto an FTP, we can use it and treat it just like an ADT feed. We'll pick it up on a schedule and pre-create those encounters for you. From the provider's perspective, it's a real-time ADT feed. And if you have... If you're not a surgery center, maybe you're a hospital in that kind of setting and you have a bunch of add-on cases or you have changes to the schedule, you can create that report as often as you want to. Drop it onto FTP and we'll pick it up and process it and create those encounters for those add-on cases. And again, from the provider's perspective, they don't know the difference. It looks like a real-time feed because the information they need is always there.

John Lutes: Yeah I love that.

David Henderson: And Matt, that's one thing that I think that our engineering team should be the most proud... At least I am the most proud of, for our engineering team is how they've created a platform that it doesn't really matter what kind of facility you are, where you're at, what size, anything. Everyone can use our system with the same degree of success. And I just think that's huge. I think there's a lot of people in the healthcare space, especially in the rural healthcare space, who are often just overlooked and can't get some kind of software because it's not accessible for myriad reasons. And I think that speaks a volume of great things about our engineering team and our product.

Matthew Oldham: Yeah, this is a great opportunity just to highlight that. I mean I can't take credit for any of these things on my own. We have a fantastic team of engineers who have built this and architects who have built the system and made it what it is today. And every single one of the engineers on our team deserves credit for that. It's what makes my job fun, honestly, doing what I do because I have to use the tools that we build. In IT or in software engineering, that concept, they call it eating your own dog food. And we do that, we use the tools we build to help our customers. And so, yeah, we have a fantastic team and I'm thankful we are able to do what we do.

John Lutes: Well, great. I think we've more than covered the section and I think we've even come up with ideas for some other individual podcasts we can do. We may see Matt again in the future.

David Henderson: So a big thank you from me. [laughter]

Matthew Oldham: Yes. Indeed.

John Lutes: Well, great. I think that's everything I have David. Thank you everybody for listening. Any other closing remarks? 

David Henderson: Thank you very much. No, that's it from me and thank you so much Matt for being on again. We know your time's super valuable. So, taking the time out to be here means a lot.

Matthew Oldham: Yeah, thanks for having me.

John Lutes: Thanks everyone.

David Henderson: All right. You guys have a wonderful day. We'll see you next time.

[music]