Transcript
Julie Hilton (00:00) hey, Julie, how are you? I’m good. How are you? Doing? Good, good. We’re just waiting on everybody else, and then we’ll get started. Yeah, I just went ahead and sat in there. So I knew as soon as you started the meeting, you would add me. So I’m just been working. I’ll just keep working until everybody else until they join. Thank you. Sounds good. You’re welcome.
Shannon Costine (02:53) Hey, guys. We’re waiting on a few more to join.
Jacob Moore (03:31) Hey, Sammy.
Sami Alouani (03:34) Hello? Good afternoon, everyone. I.
Shannon Costine (03:37) Just said, hey, Sammy and my Siri popped on. So apparently you’re Siri, now, Sammy?
Sami Alouani (03:42) That, you know, I would really love that if it didn’t happen six times a day, but I kid you not, it’s a, very common occurrence in my day.
Shannon Costine (03:52) Oh, I bet. Yeah, on the close knit side, who are we waiting on for this project?
Chris Diaz Cavender (04:05) I mean, the,
Shannon Costine (04:08) party’s here. There might be another person.
Chris Diaz Cavender (04:10) Joining, let me look.
Chris Diaz Cavender (04:18) Chris, did you send this?
Shannon Costine (04:19) To… I,
Chris Diaz Cavender (04:21) couldn’t even type my name, right? Oh.
Shannon Costine (04:27) There’s Tiffany. I think she was the last one we were waiting on.
Chris Diaz Cavender (04:31) I’m doing so good. Rename there’s. The button.
Shannon Costine (04:36) Guys. Thank you so much for getting together. I think we need some clarification or context for our team to understand what you’re looking to do, and Sammy’s going to be the lead here, but just wanted to get everyone together so we can kind of provide that clarification. So, Chris, I think you were going to explain and Sammy, please feel free to jump in.
Chris Diaz Cavender (04:58) Sure. I can try, yeah generally. So we’re obviously using medallion. We love medallion. We have an external platform that we also use to facilitate our scheduling that’s called administrate homegrown platform more or less from Jake who’s on the call and a couple of others as well. Eileen and Jake make up our product team. So they’d be the ones to actually figure out how much of this is doable from the conversation. Tiffany and I have the dream they do the things. But with that said, we are half of the closenet organization is a 50 state virtual care practice. So when it comes to scheduling, we have to make sure that there is a licensure match from where the patient is attesting that they’re at to where the provider has an active license that is housed in this administrate platform. Now, not always do we have a 100 percent match from what’s in medallion to what we have active, some use cases. And why we wouldn’t necessarily do that is we already have like 10 providers in Florida. For instance, I may not want patients to schedule in Florida with a new coming in provider and have them focus their panel somewhere else. But those are things that we can control and administrate. But the issue that we are seeing a lot is as medallion updates. And as we grow as an organization having to manually make those two match, is becoming a risk for us to be blunt about it, right? We’re not always 100 percent on it. Anytime there’s a manual action, human error is introduced and that is what we’ve seen crop up in a couple of places. So really want to open the conversation of what exists within medallion and how that product and platform works, and how can we potentially integrate or API in to our scheduling platform? I think we have all the right folks here. But if not, now would be the time to invite your friends to the party.
Jacob Moore (06:55) So I want to add a point of clarification. So we’ve created our homegrown portal where patients can go in and self schedule on all of this stuff for them to like see their health information. And obviously, what we’re talking about here is scheduling. The administrate platform that Chris is talking about is just the admin console for our homegrown portal.
Chris Diaz Cavender (07:18) And right.
Jacob Moore (07:20) Now, like you have to log in to administrate mark… which states they’re licensed in and which payers they accept, but you also have to do that in athena. And you also have to do that in medallion. So we want a single source of truth for state licensure and payer acceptance.
Sami Alouani (07:41) Okay. Got it. So this is an incredibly helpful context. And honestly, I think all we need to have a productive convo today. So a couple of things I want to break out. There’s really two buckets of requests, right? Like one is state licensure, that is one technical problem of its own. And then the other is payer enrollment and like the par status effectively, that’s a totally separate topic. So if you don’t mind, let’s start with licensure because that one is a much more straightforward problem to solve. And then we can tackle the par status especially because I heard athena being in the mix and that adds a whole other dimension of complexity. So starting with the administrate platform, did I hear correctly that the administrate platform primarily has state licensure? But I guess before I totally throw away or put aside rather the payer enrollment piece, does administrate have the need for the payer enrollment element or just the licensure?
Jacob Moore (08:29) Element. So our patient portal needs to know what insurances the patients accept or not the patients, the providers accept, which is the enrollment, and they also need to know which states. So when they filter the dropdowns or the right providers display, got.
Sami Alouani (08:45) It, okay, totally makes sense. So there’s an element of provider search in the patient facing version of the portal that’s powered by this administrative layer that not only confirms based on the patient’s location, that the provider is enrolled in the appropriate or licensed in the appropriate state. But then based on the patient’s input of what they’re considered a network with a match and a filter based on the provider. Okay, totally makes.
Jacob Moore (09:08) sense. And then the schedule and everything that we can is stored in athena and we’re just pulling it from athena. Got it that.
Sami Alouani (09:16) Totally makes sense. Okay. Cool. So we’re not really touching the scheduling element. On the medallion side. We’re really just… there’s some business logic that the scheduler needs to use to filter down availability for a given provider or providers. And we are the data layer that business logic is relying on to do that filtering. Is that an accurate statement?
Jacob Moore (09:36) Correct. Because right now I think somebody on Tiffany’s team opens up medallion, opens up the admin administrate platform, looks in medallion for the states and then just clicks them in the multi select.
Sami Alouani (09:50) I’m sorry for whoever has to do that. That sounds, really tedious and that’s what we’re here to solve today. So first things first, let’s start with the licenses. Like I said, a lot more straightforward. So we do have a very robust API library. I don’t know if you all have had a chance or knew about it or had a chance to look at our API documentation, but just drop the link for the first endpoint that’s going to really matter here. And that is the get licenses endpoint. So for licenses in particular, and again, I’m… going to talk about just the straight up technical approach here. And then we can figure out like do you all build it? Do we build it? We can figure those things out later. But just to kind of give you an idea here and I’ll share my screen too… first and foremost on the get licenses object, there’s a couple of ways you can approach this. First off, there’s a number of query parameters. But ultimately what I think you’re going to care about here is going to be the individual provider id. So there is a provider’s endpoint down here that’s just going to be your starting point probably for everything both for enrollment and for licenses. You would just query for the provider or providers that you care about. Once you have that provider’s id, you can pop the id in as a query parameter for the get licenses endpoint. And then in that response body, you can have everything that you need to be able to dictate like this provider is licensed in these states. And then from there, you can ultimately, then it’s a matter of writing that information back into the administrative portal. But as far as the getting the information out of medallion, which absolutely should be the source of truth in this scenario, this is the, those are the two endpoints that you’re going to need for licenses. Any questions on the getting of the info before we talk about writing it?
Jacob Moore (11:31) Yeah. Sorry. I just, I was typing it right when you asked that. So the provider endpoint, I’m assuming it has the mpi of the provider, correct? So we would be able to call the provider endpoint, get the mpi and link it to our provider that we’ve pulled from athena by the mpi?
Sami Alouani (11:48) Exactly. Yeah. There’s a number of things you can use to look up a list of providers. So there’s a, it’s a bulk provider endpoint, or if you know the specific provider, you can do that too. But generally, you’ll want to start with this bulk provider endpoint. And then, yeah, in the response body, you’ll have mpi should be one of the top ones here. But yes, it is in the response body.
Jacob Moore (12:08) There it is right here. Wait, go up. So wait.
Sami Alouani (12:09) There’s a lot of things in here. Yeah, there’s a ton.
Jacob Moore (12:12) Can you go up a little bit? Yeah, of course. No, just too far. So, sorry, I saw something on the git providers response that had the states just in the git providers call. Yes, I.
Sami Alouani (12:25) Would actually hold on. So, yeah, license states is what you care about here that’s correct? You can do that as well if that’s all you care about. Yeah, but is that an input?
Jacob Moore (12:38) No, this is a response.
Sami Alouani (12:40) This is a response. Yeah. So, sorry. Yeah, it is. Hold… on. So the way it works is you’ve got your query params here and our API docs are actually like interactive. So I can get you all a key after today’s. Call if you want to start exploring this. And then you can make API calls from within this page.
Sami Alouani (13:00) But then the response body starts and there’s a lot of values here. So it’s a little hard to read, but the response body starts here. So if you look at the 200 response and expand it, everything here is part of the response body, yeah.
Jacob Moore (13:16) So, I think this would work for the states because we have the mpi between the two systems to match on. So we would be able to make this call and then make this call, get the results, take the mpis and then match it to our provider list with, based off the mpi and set the states.
Sami Alouani (13:35) The one thing that I would need to double check here. I agree conceptually, the one thing I need to triple check here is that the license states, I’m not 100 percent sure if it takes into consideration the activity status of the license.
Sami Alouani (13:46) So we can double check that. But like for example, if a provider was licensed in this case, like in Alaska, this in its own right doesn’t tell me like when that Alaska license expires for example, so we might need to triple check that. I feel like it wouldn’t be very intuitive to have a license state object without it having some sort of validation logic. But we can double check that worst case scenario. You could grab the provider and then do you know a subsequent get licenses call based on that provider id? And then you’ll for sure have everything you need to validate. You know, you can even there’s a ton of query parameters here to say, like only give me back, you know, licenses that are active and have an expiration date after this date, et cetera. So either way the problem is solved by one or both of those endpoints.
Jacob Moore (14:30) Yeah. So ideally obviously is, if it’s one endpoint that’s better. But if you can get that answer, that would be very helpful.
Sami Alouani (14:39) Yeah. Do you also have?
Jacob Moore (14:40) A postman library or anything that we can download into postman or?
Sami Alouani (14:44) We actually can. We, no, we don’t at least not on here. I can look for that, but honestly, this is even cleaner because you literally just put in your API key and then you can make the calls directly from this webpage. It’s even easier than postman.
Jacob Moore (15:00) Yeah. I mean we use Ruby. So I’m looking at it at the language right there.
Sami Alouani (15:04) Yep. There you go. So… yeah. So Molly and, or Shannon, if y’all could keep me honest, the takeaway for me is on the get providers endpoint, there’s a licensed states object. And I just need to verify if that takes into consideration license status or if it’s just a list of states that a provider has ever been licensed in. Y’all, can keep me honest on that. I can do that. I’m not sure for the RNS that were pulling their NP license, not their RN license. Yes. So that’s the, yeah. And that’s another thing I can verify when it comes to licensed states. But I’m almost positive for that question, Chris that it does not take RN versus NP license into consideration. It’s just gonna say the thing I do think it checks is activity status. It’s not gonna discern between RN versus NP license. It’s just gonna say they have a license for whatever that’s active in this state. And so they’ll be in the licensed states. You would have to differentiate.
Jacob Moore (16:05) Yeah. We’d have to differentiate if.
Sami Alouani (16:07) You have to differentiate, then you definitely are gonna need both endpoints in that case, because then, yeah.
Jacob Moore (16:12) We really only care about the NP one to be perfectly honest in.
Sami Alouani (16:15) The licensing endpoint, can you not just call? Is there not a parameter for npi? There is not, no. You do need to grab the id? Yes. Exactly. You need to grab the id of the license or the provider rather. So you can look up individual licenses or look up all licenses associated with the provider. Okay. Yeah, you can search by state like prescription authority, obviously status here, whether it’s verified or not, if you’re doing, I can’t remember if we’re doing like license verification with you for you all? Yeah, unfortunately, no npi. So.
Jacob Moore (16:56) We would set active here. We would have the provider id, and then how would we only get it to not return the NP license if it’s an NP?
Sami Alouani (17:06) You wouldn’t filter it out. You would look in the response body and then it’ll tell you what the type of license is, and then you would only select the nested object that you care about. So you’d get back everything. And then you all would have to build in logic on your end or we can do it for you. Of course, if we end up building this, that also says like there’s a type, let’s see where is the type? Yeah, this is dummy data. But… me to do… certificate type here is going to tell you whether it’s RN or NP. And so then wherever it is in this body, you would effectively just ignore or nullify any of the nested objects that don’t match that type. Okay. Good question. So in a sense, if you’re going to have to do that discernment, then you’re going to have to use both endpoints. But frankly the really performance friendly, it shouldn’t be a meaningful difference. We’ll.
Jacob Moore (18:14) probably have like a weekly or a nightly job that runs and goes gets the states. Yeah. Because like I don’t think we need to do this real time. It’s just we need it’s not likely to change within the 24 hour.
Sami Alouani (18:29) For what it’s worth, I’ve never seen it and that’s why like we even evaluated for example, like doing web hooks to support this and we just didn’t see the need for it because to your point, it’s not going to change once a day. At most. So anyways, I think that does take care of the follow up. Actually. Now that we’ve because of, that the discernment need you’re going to, you’re, going to need to use both of these endpoints anyways. And again problem is still solvable, but just with two endpoints instead of one… valiant… I’ll drop the providers endpoint in the chat as well. And these are, these docs are open. By the way you don’t there’s no, no… login wall or anything.
Sami Alouani (19:18) All right. Any other questions about the licenses or at least getting the license info?
Sami Alouani (19:27) I don’t think so. All right. Well, then in that case, while we’re at it, let’s talk about, do we want to talk about writing? Yeah, let’s talk about the provider enrollment, like getting the data. And then we can talk about writing both sets of data back to the administrative platform. But for provider enrollment, it’s very similar. You’re going to start with your get providers and then you’re going to grab your provider id that you care about. And then we’ve got two kind of data model concepts. When it comes to enrollments. There is the, what I like to call like the pizza tracker like, you know, where’s my pizza along the journey style of the enrollment data. And then there is the, hey pizza’s here. Like how is it, right? Like what information about the enrollment that is existing? Do we care about? And so for the, in the process? Like if you care, for example, to track for whatever reason the process and this is more so for like analytical purposes and less for patient exercise enablement, like let’s say you had an internal dashboard or like a enterprise data warehouse you wanted to store like the, you know, the status of an enrollment request, that’s going to be this payr enrollment service requests model here. It’s very similar. You just there’s a bunch of query parameters for like the statuses of like, you know, hey, I want to see what was created after this date. I want to see if it was updated in the last 24 hours. What have you? And then in the response, you’re going to have a lot of information about the request itself. So, like in this case, new provider, payr, enrollment service request. It’ll tell you the state, the payr name, the entity, what the status is like, is it requested? Is it intake? Is it ready for intake? You know, is it pending the customer? Is it pending the payr, is it ready for medallion? Is it closed, whatever active? And then the status reason here is just an elaboration on the status and then honestly, a bunch of other stuff that you probably don’t care about in this case. But this is the model where if their enrollment is in flight and you want information about it, this is where you’d go for the purposes of scheduling. I highly doubt you need this information though because you wouldn’t want to schedule with a patient until the enrollment’s active would be my guess, right? Excellent. Okay. But there, if you need it and maybe, you know, Chris and team might be something for you all down the road, you know, if you wanted you know, and obviously medallion has great analytics if you log into medallion to see where your enrollments are at. But if you ever need or want, you know, like there’s another place you’re in a sharepoint or you’re in Salesforce or wherever you’re tracking things, some value there. But that said, the… other endpoint we’re looking for is going to be payer enrollments. And this payer enrollments model is going to be the completed enrollment. So this is not the request, this is enrollment is active and live number of career parameters here. You can search by group, like by tax entity, when the last update was made. Like for example, for demographic update requests, revalidations, et cetera, your line of business. So like commercial government, you know, what have you, and then you can search for specific payer entities, practices or probably what you’re going to want here is the provider level as well. So this would be the provider id that you grabbed from the provider, get providers endpoint. And then the response is going to be what you’re looking for. It is, you know, how was the, what was the method of the enrollment? Was it standard or delegated? What group or tax id was the enrollment associated with? What facility? Who is the payer? Like the internal id versus the name of the payer that we might want to display to patients or use for the matching, the state of the enrollment practice locations? Yada, yada, everything you would ever need to know about the enrollment would be in this endpoint.
Jacob Moore (23:00) So, yeah, part of we, so we already have the display name of the payer, we have all of that already configured and that’s only changed that often. So what we really just need to know is who do we, which providers do we associate? The payer that we already have configured to? So like the problem is if our name may be different than your name, so like is there, like do you have like the payer id from like a valley or RCM code or something in the response?
Sami Alouani (23:29) Yes, we do. It would be right here. So payer id would be a third party id that we would store in the enrollment record itself. So, you know, we would need to work with you all to, you know, make sure that is stored in the enrollment record or.
Jacob Moore (23:41) You know, we’ve.
Sami Alouani (23:43) also seen it such that now we don’t have, we have standardized payer names in medallion. Now, we don’t leverage custom payer names anymore. So there is, there could be value in using the standard internal id that’s always going to be populated or, we can do a one time exercise of an actual payer name mapping. I agree with you though. The external id is always the most reliable approach, but it would be, it would be work, you know, obviously to update medallion with whatever id that you care to leverage. We’re just using.
Jacob Moore (24:12) the payer list from availity?
Sami Alouani (24:15) Yeah. So yeah, your RCM RCM id would go here, but again, we would need to go back and update all of your existing enrollments and retroactively fit that availity id. So we would still need to do a mapping exercise and say, you know, here’s all the standard medallion payer names here are all of the availity ids crosswalk, those. And then we would have to do an exercise to go back in medallion and retroactively populate this based on that mapping, which is fun.
Jacob Moore (24:40) The other route would be to add a field to our administrate where we store your id. Yeah.
Sami Alouani (24:48) That would be the route that I would recommend just strictly because it accomplishes the same goal and it doesn’t require a big cleanup effort to retroactively apply an id.
Jacob Moore (24:58) Yeah. The only downside of that is we have a payer that we display called otherblue and that as, you know, has a lot of blues that have different ids and we only, we don’t store all of those ids. Sammy, why can’t we use that name? I’m just kidding.
Sami Alouani (25:17) I was about to say I had an ulcer start to form when I heard, no, I heard it.
Jacob Moore (25:21) Well, yeah, it’s because of where we’re physically located. So sure, no.
Sami Alouani (25:25) No, I kid, I completely understand why you all have that need. But from a mapping perspective, we would still need to probably use the same like systemic approach of like housing the medallion id, but then we would just need to look at what are all of the potential blues in medallion that we would need to lump into the other blues. Oh, that’d be fun, right? Right? I mean.
Jacob Moore (25:45) There’s only 41 pairs that we have configured right now, so.
Sami Alouani (25:49) Under the blues or in total, okay, good. And.
Jacob Moore (25:53) the one, the 40 first one is other blue.
Sami Alouani (25:57) Got it. Okay. And I imagine, I mean, we’re not talking dozens hopefully of potential matches there. So I.
Jacob Moore (26:04) mean, if I have another blue and I live in the DMV area, like we still probably have dozens of other blues. Yeah. Oh.
Sami Alouani (26:12) Okay. Fair enough. Then in that case, that’s probably going to be the majority of the mapping work. But like I said, we can help you with that. We’ve done it. This is not the first time we’ve seen that. I think what would worry me is if we were trying to again force fit the other blue mapping back into medallion’s existing enrollments as opposed to medallion telling you the static payer ids that we leverage and you all mapping at one time, that’s just a much as long as you all are comfortable with that approach that’s a lot cleaner and we can support you there. Yeah, I mean, what.
Jacob Moore (26:40) we probably do is we have an import spreadsheet where we would just add a column to that spreadsheet where we would put your ids in and then we would import the spreadsheet. Yep, exactly. Okay.
Sami Alouani (26:55) Cool. So, yeah, I mean that’s the long and short of the git motion is that, you know, or the egress out of medallion motion is maybe three if not four endpoints. You should be able to get everything that you need for all of your providers to serve the needs. So that’s the easy part, right? The not so easy part generally is what does ingress into that, you know, your system look like? And it sounds like the administrate platform sounds like it’s quasi home built. So, what?
Jacob Moore (27:27) Are it’s a region? I’m sorry, it’s a Ruby gym. If you’re familiar with Ruby at all. It’s one of the gyms we were able to embed into our application.
Sami Alouani (27:37) Got it. Okay. That’s helpful at least as far as like giving you all a certain level of control that you wouldn’t with a vendor administrator platform, so that’s pros, for sure. The question is what do the ingress mechanisms look like there? Do you guys have like post apis? Do you leverage? Like, yeah.
Jacob Moore (27:54) So our system is entirely home built except for the administrate piece. Obviously, we use third party gyms in places to like add on, but we would build, we have our like right now, we’re completely API integrated that we’ve written ourselves to call the athena apis, which would probably be the same thing we would do here.
Sami Alouani (28:15) Excellent. Okay.
Jacob Moore (28:16) Frankly, I think it’s a better approach to have us call your API than you write something into our portal because we already have the mechanism to call out. We do not have a mechanism for someone to call in that.
Sami Alouani (28:28) Was, I mean, I was thinking we’d need more than four minutes to answer that problem, but I think that’s answered because I very much agree with you there especially given.
Jacob Moore (28:36) Most of the time we actually call… apis, our app calls, azure and azure API management calls out. And then there’s like an in between firewall thing.
Sami Alouani (28:49) Got it. Okay. Yeah, that, yeah, and… yeah, I guess I don’t really have any other notes there that makes sense to us. We support that approach again generally like if you had readily built post endpoints that maybe you were leveraging with like a previous vendor that we would just be able to swap out payloads to match that’d. Be one thing. But if you all already need the ingress on your end, then, yeah, I agree that’s a good approach.
Jacob Moore (29:13) Yeah. Prior to moving to athena, there was only 11 providers. So it was not a hard like that’s. Why it was manual. We didn’t care well, I mean, we cared, but it wasn’t worth the development effort, but now we have 160 plus providers, it totally.
Sami Alouani (29:27) Makes sense. Okay. The last question I have for you all then is for writing back to athena, are you, or do you have interest in like are you only leveraging athena to get existing schedules or are you writing to athena’s payer table? We?
Jacob Moore (29:45) Are not touching athena’s payer table, got.
Sami Alouani (29:48) It, is that by design or just based on? Okay?
Jacob Moore (29:51) So our system treats athena as the source of truth for most things. So, I mean, it might be better for the licensure state that’s not stored in athena and they don’t care in athena, so that we probably, but for payers, I think you have to get that into athena. So frankly, our preferred mechanism for the payers would be you to update athena. And then we read from athena, yes.
Sami Alouani (30:14) And that’s what I wanted to talk touch on. So we want to do that very badly. And we’re actually working with athena right now to create a post endpoint to allow us to update athena. Because we have dozens of customers, in a similar scenario where, you know, to your point the source of truth objectively of what providers are enrolled and eligible for, what payers is medallion. So you all would benefit from it. Athena would benefit from it. My question was if you all have any mechanisms available to you to write that information into athena that you’ve explored or? Okay. So sorry, no, as in you haven’t explored it or no, we.
Jacob Moore (30:47) Haven’t explored it. No, because we weren’t it didn’t even cross my mind to us to manage the payers in our system.
Sami Alouani (30:55) Makes sense. Yeah. But, but, I think at this point, you’re still gonna have to update it in two different places unless we can update athena directly, which we want to do. So the only, I think there’s two kind of parallels here and this is probably a good place to wrap up given we have a minute left. One, one is, you know, we’ll send over these API docs as a follow up. We can get a technical solutions manager on my team assigned to you guys to help guide you in your approach to building this. I agree. It makes more sense for you all to build it against their endpoints. There’s no cost associated with that. If you guys are going to be building it. So we’ll just get you somebody that’s a dedicated point person, you can ask questions myself included. But then in parallel, what I would really love to work with you guys on is if you have, do you have a dedicated athena rep or CSM or something of that nature? Yeah. Would you all be open to getting a three way meeting on the books so that we can talk about what it would look like for medallion to write the payer statuses to athena so that you all could pull those directly from there. And instead of pulling from medallion, pulling payer status from medallion into an illustrate, and then also separately having to keep athena updated. Is that something y’all would be open to discussing? I?
Jacob Moore (32:11) Mean… I, yes, the answer is yes, I just don’t know who at athena because, we work with their digital solutions team for our apis. Yeah, we then also have an account. We also have an account rep. I don’t know who to go through. We.
Sami Alouani (32:26) Can figure that out, yeah, but.
Jacob Moore (32:28) Long long of this short of it is, yeah, we’d be willing. We just got to figure out who had athena to coordinate with.
Sami Alouani (32:35) Excellent. Yeah, that sounds good. Yeah, for generally, I’ve seen digital solutions is it takes a more… I’ll just cut to the chase personally. My two cents would be account manager. What might be, the path to getting us with the actual solutions teams that would be able to, you know, work with any product and engineering to, you know, build something?
Jacob Moore (32:59) Well, we have a continent. We have a, we have a professional services with, I think they call it the platform solutions team. Yes, we have professional services with them, like we pay them X amount a year to help with our development that’s.
Sami Alouani (33:11) the one that’s what you’re going to want to reach out to. Okay? So, we can follow up on our end with. Yeah. So if you all want to maybe start the conversation and grab some time or, you know, just position it, and let us know, when would work, Molly can help coordinate, getting something on the books. But yeah, we’re definitely eager, to work with you all to do that. So, yeah, just to wrap up, get you the API documents. Sounds like we’ve we’re in agreement you all are going to do the build. We’ll get you a dedicated point person to help with any questions you have, as you build against our endpoints, and then in parallel, you all will reach out to your professional services contact such that we can get a meeting on the books to explore options for writing par status, I know.
Jacob Moore (33:54) You said you didn’t have a postman or you’re not sure, but do you also, no other thing to check is if you have an open API specification file?
Sami Alouani (34:04) Like for the LLM, no.
Jacob Moore (34:07) It’s not open AI. It’s open API.
Sami Alouani (34:10) God. Yeah.
Jacob Moore (34:11) Yeah, it’s a, yeah, it’s a different standardized way. People are trying to start packaging apis so that we can just import that open API specification and we instantly know how to call the API. God.
Sami Alouani (34:24) Yeah. Okay. Yeah. Sorry, I heard open AI. Yeah. No, no, it’s.
Jacob Moore (34:27) fine. It’s called the open API initiative, yes.
Sami Alouani (34:30) I will, to be honest, I don’t think we do the best. The best we’re gonna have is like the ability to extract the markdown and put it into an LLM and give you like the open API spec which I’ve done personally works kind of good. But yes, I will check. But to be honest if that expectations, I don’t think we have anything out of the box for that. Okay. Well, thank you all so much this has been really productive. Looking forward to hopefully continuing the conversation with athena. And like I said, we’ll get you some follow ups sent by Molly and, or Shannon. Thank.
Jacob Moore (35:01) You guys so much appreciate you.