CHRIS: That's right. And this next slide really kind of talks about some of these different systems that we integrate with. And this is really something whenever you're evaluating an integration platform that you really want to ask yourself is, as you were saying earlier, Ron, these different translations that are possible, what are these systems that the integration platform can talk to? And the way I would say it with our Clarity Connect integration platform is really anything. Anything that your team wants to integrate with. We're showing here integrations that we've commonly worked with and completed many projects with, in some cases, dozens and dozens of projects with these different platforms. But essentially, any system that does have a pretty standard kind of API basically—this can be EDI XML, SOAP, REST. Can be database. Really the list goes on, PunchOut Catalogs. Any kind of newer API framework like gRPC or FHIR, HL7v2 HL, HL7v3—we can integrate with. But whether you're looking at Clarity's platform or another platform, we do encourage you to think ahead and think about where you're going with your business and where you're going long term.
And this is the really interesting thing, Ron, that I like to ask people to think about. Does your team internally have the ability to expose the APIs with these systems? And if you don't, what's your plan? And at Clarity, we have dozens and dozens of pages in most cases for these platforms that we're showing on the screen and many others that we've written of internal documentation for how to securely and in a very high-ability performant way, expose the APIs for these different respective systems and how to work with your vendors, if you have a vendor. Or how to work directly with the companies that are shown here to get access to a sandbox, development environment, non-production first, and then be able to kind of turn that on for development and testing. And then to be able to switch to production and complete the right steps to respect the business logic and the workflows that are part of your particular implementation of these different respective platforms.
And that's really a key missing ingredient, like we were talking about earlier, right, Ron? Whenever people are looking at platforms, they myopically focus on, what does it say that it can do, you need more than that. You need a partner who can actually take the blueprints and the raw materials and turn it into a beautiful executed build. And that's really what we want to encourage you to think about looking at all these scenarios.
RON: That middle one there, it appears to be the shortest, but that's even the most important. I see that a lot where clients will come in and I'll start talking to them and they've taken a swag at these plugins, and they've done some integration. And they're integrating and exposing and breaking HIPAA compliance rules by connecting an email to an EMR, and now they're violating HIPAA, sending out protected data. Yeah, like you said, one of the most important things is make sure you've got a partner who actually knows what they're doing so that you don't put yourself in a legal position of internally going, "well, we're smart enough to figure this out. All we really need is this little tool." You grab this tool. And the next thing you know, that tool helps you literally violate some government regulations. Make sure you find a vendor that plays in that space, understands the rules and can help ensure to protect your business legally. That's a big one.
Obviously, we've done 3000 integrations over the 15 years, and I've been here 10 of them. But it used to take us, I remember, gosh! Even seven, eight years ago, it used to take us a long time to build these connectors. And it felt to me like every time I had to estimate a connector, it started from scratch, right? But it doesn't seem to be that way anymore. Aren't a lot of these now using the same basic workflows or API protocols? How does that all work?
CHRIS: Basically, you tend to see a lot of rest and you tend to see a lot of, in some of the older platforms, SOAP-based APIs. But man, whenever you get into the details with how you would customize something, most of the time, what we find with our clients is that they come to the table thinking that these different platforms that are using REST or SOAP or maybe FHIR, or they have EDI, etc, it's just as easy as mapping some fields and maybe doing some data transformations inside of the integration platform. But most of the time, what we find is to really enable self-service for customers or to enable full automation, or significantly full automation, with internal objectives for fulfillment or for other workflow processes, for example. They have to actually have the ability to customize these different respective systems because they don't actually do what needed off the shelf.
And so you really end up needing someone that you're working with for each of these particular integrations that can utilize the REST and the SOAP that's very common, but have the depth of knowledge with each respective system around how to customize them or at least point a vendor that's working with them in the right direction on how to customize these systems. Many times, Ron, in my experience with executing on these projects, the vendors who are specialists in these particular ERP, EMR-EHR, CRM systems, eCommerce systems, they don't actually have specific knowledge with customizing the way their clients need.
RON: Yeah, that's true.
CHRIS: It's pretty surprising. Yeah.
RON: Well, it is. And half of our integration jobs that come to us aren't the clients. It's the partners that come to us and they're like, "hey, we're in working on and we'll just take the one right in the middle of Epic. We're in here working on Epic at our client and now we don't know how to hook that up to a patient portal or a mobile app or online billing," like you said, they either don't know how to customize that application on the end to automate or get the benefit out of the potential automation or the other way around,they know how to customize the heck out of their application, Epic, but they don't know anything about the API.
And now, how to turn that customization that they've done inside of Epic, into real profitable processes, like putting it into a patient portal where you can allow patients to schedule their own appointments and pay their own bills and see their own lab results and invite and do their own consent forms to allow their information to be shared with another doc. All that kind of stuff can now just be easily all automated. And we do that readily. Right?