Subscribe
Share
Share
Embed
this is a test
Hello everyone. Welcome to HealthTech Horizons, the newest initiative by Toplight Apps. My name is Charity and I'm the Head of Growth here at Toplight. Via HealthTech Horizons, we want to navigate the complex landscape of healthcare technology with the leaders who are shaping it. We wanna talk about AI powered diagnostics, cybersecurity channels, different regulatory compliance issues and the future of patient care.
Speaker 1:We're here to cover it all. Today in our very first episode, we're diving straight into one of the most critical aspects of modern healthcare infrastructure, EHR integrations. I'm thrilled to welcome Scott Rosignal, Head of Integrations at Toplife. Welcome Scott, thank you for being here. Tell us a little bit about yourself.
Speaker 2:Thanks, it's great to be here. So yeah, I'm Scott Rosignal. I started my career at Epic and worked there for about seven years. In the nine or so years since then, I've been really heavily focused on the integration world. So I help organizations figure out not just how to get an application data flowing, but also how to make that application work well inside of an EHR.
Speaker 2:Both of those things are really crucial and there's a lot of different nuance in today's day and age with the ways that EHR is deploy functionalities that they make their UIs available and everything else. So what I love to do is help different organizations figure out what their workflows look like and then figure out how the integrations flow from there and really make things work so that once you do something once the right the right way, you can repeat that success.
Speaker 1:Cool, thanks for sharing. Well, let's just jump into the basics. I'm sure one of the things you hear a lot is we just wanna integrate with Epic. Really, what is the reality from your side for when you hear that?
Speaker 2:Yeah. I I think a lot of of software organizations or even, you know, founders come into this space and and they see the application itself as the primary challenge to their success. Right? It's the first thing that they wanna go and build. They're right, you you need to have an application that has great functionalities that provides a useful workflow or useful data to your users.
Speaker 2:But what you often forget as part of this process is that you're actually operating inside of somebody else's application. That you're not building a standalone application in most cases. Even if you are, even if you're building something on the web, there's often some aspect of what you're doing with a healthcare application that has to be ported into the EHR. And the way that you do that is not straightforward. There are tens of different ways to integrate data with EHRs from HL seven version two, x 12.
Speaker 2:There's fire and other API based integrations. There are private APIs that EHRs deploy for certain purposes. And then there's the UI UI based aspect. You know, can you make your data your website available inside the EHR? And even if you can, is it going to be in a location that the provider actually accesses?
Speaker 2:Is it going to be accessible within the workflows that they care about? If you have an application that really revolves around ordering, how do you make that application show up when the provider is ordering something? So these questions kind of happen at the second or third level of planning after the application's already been built or you have a really good understanding of what you want to build and you're already executing on that. But what happens then is that you actually have to revisit some of your decisions early on and you have to create an EHR integrated product rather than just a standalone product. So yeah, there was a kind of a short question just integrate with Epic.
Speaker 2:Right? But like the answer is this, you're not integrating with Epic. You're integrating with your users. You have to find how your users are using that software that is not yours, and that you actually have a really hard time accessing or learning about. And then you have to figure out what capabilities that software provides to allow your software to work properly inside of those constraints.
Speaker 1:Interesting. Do you think the questions that you just mentioned are things that founders should research about and have ready when and before they're doing something or going in for an Epic integration or any kind of EHR integration? Or do you think it's something that really whoever's helping them out with it on the technical side should be bringing up?
Speaker 2:Yeah, in my experience, there aren't a lot of development organizations, technical organizations that provide software development services that really understand the EHR. And that kind of makes sense. It's not their specialty. They're not growing up in the EHR world. They don't bring EHR analysts into their organizations.
Speaker 2:It's really a focus on development work. And so as a founder, if you don't have the skills and understanding of Epic and not just the Epic workflows, but how Epic works in the background and you wanna integrate with Epic or any EHR, you really need to think about what expertise can help drive that understanding. Because like I said, if if you are a provider and you're trying to integrate with a provider workflows, you know a lot about how providers act or behave, like what things they wanna write in their note, how they wanna get data into that note, or how they wanna use the EHR. But you don't know how that EHR is exposing capabilities. You don't know how that EHR will allow a vendor to integrate.
Speaker 2:And those constraints that the EHR presents are really the harder things to to to get through. There's always a good way to do things. You know, you you can always find the best path that does work, but sometimes that means standing your use case on its head. It means thinking about it from a completely different direction in order to get the value that the providers are really looking for.
Speaker 1:Fair enough. Interesting. And do you think, obviously there's all of these different questions that need to be navigated as part of just integrating with an EHR, but do you think, or do you see a common pattern or challenge that founders are often blindsided with that just keeps on happening in all these different years that you've been in this space?
Speaker 2:Yeah, I mean, I've already touched on the fact that EHR integration is challenging from not just the data perspective, but the workflow perspective, right? So I don't need to harp on that. What I think some founders should be considering is how can you make your application valuable without EHR integration? I think a really good example in the industry right now is Open Evidence who doesn't have EHR integration and they have a very successful product. And now they're kind of actually wading into the HR integration space.
Speaker 2:You can kind of see they actually made some missteps recently where they're not really thinking about BAAs in terms of organizational BAAs. They're thinking about providers individually granting access to patients' data. And for a billion dollar company that's a big mistake. So you can see even at that level that folks can make mistakes. They can run into pitfalls and that can absolutely send your business sideways.
Speaker 2:If you don't have the right contracts in place, a lot of your work is gonna be for naught. You're gonna have to go back and redo a lot of that work. And necessarily, that's actually that's one thing we should talk about more too is integration is maybe one part work, you know, technical work for every five parts it is contracting and approvals and security reviews. Right? With especially with large health systems, when we're talking about Epic and Cerner, you're going to have committees.
Speaker 2:You're going to have a chief information security officer and a security risk assessment process. All of these things are going to require time from the health system that they're going to invest in your product before they pay any dollars to you. And before your product actually gets to do, see any pilots, any use. And so that challenge can oftentimes blindside folks. You might think, yeah, I've got a group of physicians at this organization, they're ready to go.
Speaker 2:Let me just get this IT request in and we'll be ready and good to go. No, you're actually probably six or nine months out from seeing an implementation within an Epic organization if you haven't submitted that IT request yet and you haven't gotten approval.
Speaker 1:Yeah, that's a long time. I feel like people don't really consider the contracts part of it. It's almost the same amount of time that the entire development cycle takes for new products. So keeping that in mind, do you think a good time to start on the EHR integration part of it is for people that are building a new application pretty much when you're building, starting to build the application right at the beginning?
Speaker 2:Yeah. I mean, I think as you're building an application, you're always looking for product market fit. And that means that you need users and you need to be able to show your application and and have your application actually exercised in in a production workflow. So one of the first things you should be thinking about is like, who are your users? And if your application is an EHR integrated application, if you must integrate from the outset in order to understand product market fit and really like build on top of that, then you need to start thinking about who your pilot users are right away.
Speaker 2:And I would suggest not going with a large EHR if you can. There are smaller EHRs out there that you can be up and running with much faster. And these smaller organizations might not necessarily have a security risk assessment process or other long contracting timelines. And so you might be successful working with, like, an Athena or any clinical works organization to get a little bit more understanding of how your application will work, how it will integrate, how providers will use it and iterate. Because I know that's super important to most founders.
Speaker 2:It's one of the bedrocks of most startups is to be able to pivot and to integrate or to iterate faster and faster. With EHR integration and with healthcare sales cycles, you're not gonna have that ability and you need to find ways around it.
Speaker 1:Scott, as a founder, if I wanted to figure out within a very short time, and by that I mean like thirty minutes, an hour, all right, my HR integration works, what would you recommend their go to path be? Or what would you do?
Speaker 2:I mean the first thing that we need to do is understand what data do you require. Are you pushing data? Are you writing data into the EHR? Are you getting data from the EHR? And then look at how that data can be supported by the EHR.
Speaker 2:Thirty minutes is probably a little generous here, it's a little bit more of an exercise than that, but this is a critically important thing to do and you can probably achieve it in four or six hours, where you can go and document. Yeah, need a date of birth for this patient. Yeah, I want this patient's conditions, these allergies. This is really important for your application regardless, right? Your application's going to display this information or it's gonna use this information that's core to its function.
Speaker 2:So getting that all documented and understood as like a data dictionary is one of the first things that we do when we work with organizations. The second part of that is now looking at that data and saying, okay, what healthcare standards can I use to obtain this data or to enable this workflow? Every EHR publishes how they integrate. This is difficult if you don't understand the standards already. It's not going to be a simple process to do that mapping.
Speaker 2:But what you can do is you can go on those EHR websites and you can learn about their HL7V2 interfaces or their FHIR APIs. And you can get an understanding of whether or not broadly those are gonna work for you. Things to consider is whether or not you need a kind of a triggering event or a push of data in order for your application to work. That's a really important piece of the puzzle in integration. Some applications require knowledge of a visit in advance of that visit occurring, or maybe you wanna get an order from the, when when it's placed.
Speaker 2:Those kinds of things, those pushes of data are different standards and different setup compared to pulling data in healthcare. And FHIR is not a good option if you're considering pushes of data into your application. So that's gonna move you towards these kind of older standards, the HL7 version two standard, for example, which is great. You know, it it's not a problem to use these standards, but what you're gonna be doing is you're gonna be asking for different integrations. You're gonna see different cost models from the EHRs to get that integration working, different setup timelines, different integrations on your side that you're gonna have to handle and understand and build for.
Speaker 2:So it's a it's a very good exercise to go through and really understand your data requirements and then how those data requirements can actually be met.
Speaker 1:Mhmm. Okay. I know we talked about a few things, that can derail going live with your EHR integration. We talked about the length of contracts. We talked about underestimating how long it takes for some of this risk assessments to process.
Speaker 1:And obviously, we talked about not asking the right questions right at the beginning. Are there any minor technical details that you think that can completely derail your integration or take you back to basically the drawing board again?
Speaker 2:I've seen a lot of implementations either stop or never really finish because the technologies that you've selected are not appropriate for the quantity of data that you need or, like, the type of application that you have. So I I think I already kinda talked through that. Right? We need to understand how much data you need, when you need that data, how you're gonna obtain that data, and make sure that it really aligns with the EHR. I think one thing to consider is like the amount of traffic if you're using APIs.
Speaker 2:Are you gonna be making thousands of API calls to make your application work? That's feasible, but it has to be planned for and communicated. I would say another thing is more along the lines of trying to skip ahead in the process.
Speaker 1:If
Speaker 2:your organization is integrating with a health system and, you know, you think that, oh, maybe if we have the users, you know, start using our product before we sign a BAA with the health system, that'll kind of encourage those users to bring this to their provider or their their superiors and and kind of work in a way that allows them to sell for you. Things like that are not they might work outside of health care, but health care is very specific and has a lot of rules. You know, HIPAA is a burdensome rule for good reason and you need to make sure you're compliant with it. I think the other side of HIPAA compliance is also important here is that when you get that security risk assessment questionnaire from a provider organization and they ask who your security officer is, who is your privacy officer, when was the last time you reviewed all your policies surrounding, you know, password resets or, physical access to, your premises? You know, there's so many questions in these.
Speaker 2:And not having the answers to those upfront or having software that's built in a way that's not compliant could create a huge problem for you and actually never I mean, you never get out of contracting phase. So I've seen that happen. I've definitely seen projects stall in testing also where users are trying to get the workflow running and they just don't like it. Like, the thing that you did is not what they need because we didn't think about the workflow inside the EHR before we implemented an integration that we thought would work. Right?
Speaker 2:You have to really think about all these aspects and and really take your time. There's nothing nothing happens fast in health care, and it's better to just bring that expectation to the table.
Speaker 1:I think to your point of like nothing happens fast, very true, especially in this case. When someone's obviously trying to find the right balance between, I guess the fast way or the quick way and the compliant way, just because they're dealing with brutal deadlines, which happens to be a case a lot of the times when you're spending thousands of dollars on this project you're trying to launch, but you're not able to just because of the EHR integration part. Do you think, I guess A, is there even a balance between the compliant way and the fast way? And then how does it work if there's something there?
Speaker 2:Compliance isn't that difficult to achieve as long as you're following best practices in the industry. So like from a security perspective is what I mean there. Like like if you're using AWS or Google Cloud and you're using like their identity management services, like you're a long way towards compliance with HIPAA. You know, you have to make sure that decisions you make around infrastructure are correct. And there's really no quick way to do that.
Speaker 2:You do have to make sure of your infrastructure side of things when you're building out. I think a lot of organizations kind of ignore HIPAA entirely until they're asked about it and then they have to kind of race to figure things out. It would be better to spend a little time thinking about the operational side of HIPAA which is the larger aspect of it. So there's like technical infrastructure, security is my data being exposed, are users able to access, only able to access the right information at the right times. But like most of HIPAA is actually policy and and how policy works.
Speaker 2:And so thinking about that a little bit in advance can allow you to get it done pretty quickly.
Speaker 1:Mhmm.
Speaker 2:And that means that you're gonna be set up to be compliant in the long run. One thing, you know, I'm not gonna name vendors, but like there are vendors out there that do HIPAA compliance for you almost. They provide policy templates, they give you a lot of the details that you need to just complete and say, yeah, I'm ready. So thinking about those as a starting point for HIPAA compliance could be a really great way to like be set up so that you could do things quickly and fat and compliant. Now that said, my earlier point was all about, like, the fact that nothing happens quickly in health care.
Speaker 2:And ultimately, every time you have these, like, really strict deadlines, what's gonna happen is your customer is going to find a reason to push that back. And it's all gonna be valid reasons. So you don't necessarily need to be a 100% ready with your product by the time you're entering into the contracting phase with the customer, or even by the time you're starting to pilot things with the customer. You know, think about like what your timelines really are going to be in the implementation process, and make sure that your software is working so that it can be implemented. And then build features on top of that as you understand them and as you understand the user workflows.
Speaker 2:That's a much better way to go than driving for these deadlines before you even get feedback from the health system.
Speaker 1:That's a good point. I think a lot of the times, even for us, one of the things we hear is we've already built this application but we're now beginning to consider EHR integration, which is where we're like, how do we tell you this? But this podcast is probably a good sort of opening. We'll just send this over to them. But I guess that's most of what I had, Scott.
Speaker 1:Is there anything that you wanna talk about or like just closing thoughts, final thoughts that may be useful for people that are listening in? Anything around EHR integration, integrations in general for founders that are just building out their products?
Speaker 2:Wow, there's a ton. Think two key points.
Speaker 1:I'm just kidding.
Speaker 2:Yeah. Well, one key point here is follow regulation. Regulation and interoperability go hand in hand because oftentimes CMS or, oh, ASTP, which is an office within CMS, really actually drive new use cases in healthcare by requiring or mandating certain behaviors. So founders that think they have a great idea, like go for your idea, that's great. But like, if you're searching for an idea, the first place to look for is like what new regulations are coming out and how can I help organizations achieve those regulations?
Speaker 2:Because I think those are the use cases that people are buying. Health systems have dollars to make sure they're compliant with regulation. They don't necessarily have dollars for things like provider happiness even. We see this time and again, where you're gonna spend money on the things that you have to and everything else takes a back seat. So I definitely recommend thinking about what regulations are and how those can impact your product in different ways.
Speaker 2:Again, folks that are listening to this in 2025, you probably don't wanna go build a prior authorization application unless you understand the regs coming out in 2027 about prior auth, because that's gonna disrupt the industry and it and you're not gonna find buyers that if you don't have compliance with the new regulations. So there's a ton out there. Prior auth is the tip of the iceberg, but it's a hot topic right now and one and like a very good example of that.
Speaker 1:That was a lot to you on. Thank you so much, Scott. Appreciate your time. I'm sure there's so, so much more we can talk about, so much going on in the industry, so much changing every day. We'll save it for another day, but in the meantime, thank you again for your time.
Speaker 1:Thanks everyone for listening in. Thank you.
Speaker 2:Bye.