Transcript
Brittani Luyen (00:00) Brittany, hi, Brad. How’s it going?
Bradley Eral (00:11) How are you doing?
Brittani Luyen (00:12) Good. I was chatting with you but then realized I was on mute.
Bradley Eral (00:15) No worries. Looks like Roberto’s on as well as Ross. I guess well.
Ross Martin (00:21) I’m never late.
Bradley Eral (00:24) You are very punctual. Yes, I am. We’ll see, I’ll.
Brittani Luyen (00:29) strive for that. I think you’re the model of how we should all show up to our meetings.
Bradley Eral (00:34) Absolutely… the world needs more robertos?
Ross Martin (00:41) My wife would say.
Brittani Luyen (00:42) Yes, but no.
Bradley Eral (00:47) How’s the day been so far? Roberto? Great. How about you? Good? It’s flying by. It’s been a busy morning.
Ross Martin (01:38) Bob, one of these days we’re going to make you play guitar for us while we wait. It’s waiting music.
Ross Martin (01:47) Did I just freeze Brad with my suggestion?
Brittani Luyen (01:50) Maybe Brad was like, nope, I’m out… that’s fair. Roberto, where are you based again?
Brittani Luyen (02:03) It’s your city? Oh, cool.
Bradley Eral (02:08) Excuse me?
Bradley Eral (02:17) I was just saying my wife might cut out there for a second, but Ross, I don’t know if you want me playing guitar for you. Looks like josh, Jen and Mike are on as well. Good afternoon, guys, everyone.
Ross Martin (02:32) Sorry, we were on another call.
Bradley Eral (02:34) No worries. I figured that was the case. Appreciate you joining on back to backs here, but Micah, I’ll take your lead when we have quorum and we can jump right in.
Micah Sanders (02:45) Yeah, yeah, we’re good. This is us from our side.
Bradley Eral (02:49) Amazing as from our side. So I’ll pass it to Brittany and Ross here. But really, as you guys know, the goal today is let’s scope out phase four, take a detailed look, make sure we’re aligned on what we’re all driving towards. And then the output of this will be a much more clear breakdown of what’s expected timelines for us to deliver on phase four. So with that said, I’ll pass it to Brittany and Ross and they’ll take it from here, cool.
Brittani Luyen (03:12) Thank you, Brad. I can kick us off. Yeah, proposed agenda. Like Micah, let me know what you think. We can either start off going over the diagram that we shared with you or if you’ve already had a chance to review it, we can just address the questions that you followed up with. I haven’t had a chance to respond in slack yet, but figured we can just chat on the call. And then I do want to save some time to like specifically discuss what our proposed plan is for phase four specifically. So I guess my proposed agenda would be address the questions, discuss phase four slash tasks and then hit the diagram at the end because you all can also review async and then get back to us with questions. Does that work?
Micah Sanders (03:52) Sure. Yeah. Well, the only thing is, I don’t know if Jen and josh and Roberto, if you’ve seen the diagram, probably not. It’s just like 45 minutes ago or so. Yeah. So like would it be worth taking? I don’t know, five minutes just quickly to like, look.
Brittani Luyen (04:07) Through it for sure. Yes. Let me just pull it up. Okay. All right. I always have issues sharing on zoom but I think I can manage. Okay, can you all see my screen? So we did put this together. I think this is still accurate. We put this together maybe a couple weeks ago. So some of phase zero might be a little bit different as we may have made some progress, but this is the current experience as it exists today. The user signs up in simplepractice. There’s an fstp file transfer with all the provider org data. We then create the orgs and the providers. This is what we’re working on right now, right? Like we haven’t implemented the caqh workflow quite yet the user completes the profile in medallion, they create their payer enrollment request in medallion as well. And then we then submit the application. Once it’s complete, we might get sent back to the user if there’s any follow ups and then we submit the application and then any additional follow ups from payers, and then the payer enrollment is successfully created in medallion. That’s more or less what we’re working with today. With the exception that like caqh isn’t fully implemented yet… what we want to get to for phase one, which is sort of what we are. I think this next phase that we’re all working towards is user signs up for simplepractice, they fill out their caqh profile in simplepractice. You guys collect the caqh id, the npi trigger caqh from your platform and we create the organization, we create the user, and then… trigger the data request based upon what you guys provide us. And then when the user logs in, they actually already have a caqh pre filled profile in medallion. They are still creating enrollment requests in medallion. They’re still completing the provider profile in medallion. Yeah, that’s all true. And then any follow ups are still happening in medallion, but we’re getting a little bit closer. So caqh is pre filled. So when the provider logs in, everything is already there, we’re starting to get closer to the integrated state. This is, I think what we’re working on next, let’s see… phase one point five is this plus webhooks which is what I think we can get to in the next month and a half. Webhooks is what we’re implementing right now for the payer, select the payer… service request, the payrollman service request endpoints. And so that you guys should have that in the next two months or so, the current estimate is like mid may for that to be available. So this is basically the same thing. But with webhooks end to end, intake is what we are talking about right now with the missing fields. And so this is when we would start to push all intake to simplepractice, the user would complete their profile in simplepractice. We would surface you all the endpoint that you would know, what are the missing fields, given a service request and a provider, what are the missing fields that are required? Everything else is basically the same after that. That’s really the big change that we’re all currently working towards as well. Phase three here is what we’ve been talking about is phase four which is follow up. So this is exposing the task API to you all. And so the way that we envision this working is that we would be able to expose to you all what is the object that we need. So maybe that’s a missing field. Maybe it’s a document. Maybe it’s a signature that occurs off platform. And then like what is the user action that needs to happen? Maybe it’s like completing that signature? Maybe they’ve already uploaded something and just need to re upload it because it’s blurry or is insufficient and exposing an endpoint to you. All that you all can access. That is what we are considering here. I think that’s everything Ross do you want to. Is there anything you want to specifically highlight? There’s a lot of additional detail in here about like the specific endpoints we may build. But I don’t know if that’s necessary to like really get into at this point, definitely review that async though. Yeah.
Ross Martin (08:21) I don’t have a ton like I basically just made this like a month and a half ago or so because we were having a lot of conversations and it was hard to get a clear mental map. So I mostly made this as like a model for myself. So I don’t want to be like overly prescriptive about this. I think it roughly captures where we’re going but don’t think that any of these details is like set in stone or whatever. Like I think hopefully we’ve shown that we’re pretty happy to like be flexible and, you know, change stuff as needed.
Micah Sanders (08:44) Totally. No, this is really helpful to see like this. And I think… the one thing I flagged in the thread is just that I think it makes sense for us to talk about these things as phases. But I do think there’s a possibility that some of it will just be like how the development plays out on our side, but there’s a possibility that we would go from like I think what’s represented in phase one here, which the improvement on our side is essentially like the caqh like checks. And then like not sending them into medallion until caqh is imported. And then we have some UI elements on our side. And then there’s a possibility that the next step could be like all the way to profile accessibility like push and pull and payer selection all in one kind of like delivery. Not that we would parallel like the development there. But if the timeline for like delivering those things are close enough, it doesn’t really matter or it doesn’t really make sense for us to like go live with like one piece and then wait three weeks and then like change the user experience again. So just flagging that. It makes sense from a development perspective to think about the phases. But when we think about releasing to users, we may, that may come all at once depending on how development goes for us.
Brittani Luyen (10:10) Yeah. And I don’t think we have any concerns with that. I think exposing the missing fields endpoint is not that much additional work on our end. I think the only caveat right is that we’ve mentioned that there may be some requirements that we discover later on that may be missing from our current requirements. And so we’ll continue to try to get increased coverage of those, but that might not happen perfectly on day one. But I think we’ll be at 90 to 95 percent on day one, if we can expose to you the missing fields. And that’s not like that’s a week or two of dev work. I believe Ross, right? That’s not crazy.
Ross Martin (10:46) Yeah, I don’t want to promise a timeline but something on that. Okay, cool. And I guess like not to get too far ahead of the conversation. But it seems like overall, you guys are comfortable with like something that has like the basic interface we want even if we’re not perfect on all the edge cases and get that out earlier rather than trying to get a perfect for like first release with you. So like when we like start to work on like tasks and like the post submission follow up, is that a fair like ethos to keep with?
Micah Sanders (11:13) Yeah, I think so… like there’s definitely desire on our side to think about this iteratively and not like think we have to, you know, make this work for 100 license types and 2000 payers. And like all the combos like right away. So we actually just had a conversation that is has some implications for this too is like we, because we have ways of displaying payer entities in our product that are primarily based around the transactions like claim filing and like eras or like receipts coming back. And the payer entities are slightly different in like a payer enrollment workflow. But we’re planning on like only surfacing the ability to do payer enrollment for the entities that we service on the revenue cycle side, which is not going to limit us. It’s really just like limiting some of the long tail edge cases potentially. But then we would just tie out the entity to submit payer enrollment to the same like object or like entity that we’re managing the revenue cycle with just to simplify like the user experience. So that would like allow us to kind of gate certain payers and control the user experience in that way. So that’s like one example of how we’re thinking about it iteratively as well. Like we don’t feel the need to like right now like our users can do whatever they want to in medallion which we don’t feel like they need to be able to do necessarily. And most people are going to choose from a list of a couple 100 payers at most. So that’s kind of how we’re thinking about that once.
Brittani Luyen (12:53) You have that list of like a couple 100 payers that you are specifically interested in. And then like what license types could you share those? I think that would help us narrow down on our end too, like where we should focus efforts to try to get as much coverage as possible. That matters for the phase in which we have profile intake happening in simplepractice, but also for like follow ups, right? Like they’re very related. It’s basically if we get good enough at intake and capturing the full request there and being clear to users about what they need to complete theoretically follow up might never have to happen in the perfect world. I don’t think we’ll ever quite 100 percent get there. So like we should consider follow up as like edge cases, not necessarily like a primary workflow. Yeah.
Micah Sanders (13:37) Yeah, I can do that. I know Jim has a list of payers currently, but license type is something that I can get you as well. I’ll probably need to have a few conversations just to like confirm the scope of like what from like our marketing team, like what we’re comfortable gating in terms of like, okay, this isn’t this is not for chiropractors or, you know, whatever this is for like mental health, but it shouldn’t be too hard just because transparently like our, the type of provider on simplepractice is very bent towards mental health care and we’re very much focused on that. So it shouldn’t be too hard to get that sort of like approval to like specify license types cool.
Brittani Luyen (14:21) Does market play a role or are you guys like pretty? It doesn’t matter as far as state goes and you guys are pretty late, sorry.
Micah Sanders (14:28) Say that again?
Brittani Luyen (14:28) Is state a dimension by which you prioritize as well or are you equally sort of distributed geographically and states are pretty equal as far as prioritization goes?
Micah Sanders (14:40) I would be a little more hesitant to like gate states just because it, you know, we’re pretty dispersed like in the same way that like the us population is dispersed, we’re not, there may be a little bit of a more of a bent towards states that are like that have more mental health care. Like in general, like California has, you know, probably more healthcare, more providers per population than like Alabama or something. But like other than that, like we’re not really overly bent towards a particular state. So I’d be more hesitant to gate that, yeah.
Brittani Luyen (15:17) Totally fine. I don’t think I would necessarily need to do that. Just was curious. Yeah.
Micah Sanders (15:22) We could consider gating lines of business if that was like meaningful like we would certainly want to offer commercial and probably, but, you know, I would love to be able to offer traditional medicare traditional medicaid like right off the bat because that is a really impactful one and users have a hard time getting a network… but I, you know, if there’s issues with like marketplace or whatever like we could potentially gate that just because that’s not as common. But I don’t yeah, that we can get kind of draw those lines. Maybe when we get to that. Okay… I think any other questions on our side, it’s really helpful to see like the orange green on the endpoints and I’ll go through that a little more carefully and just like maybe make notes of like areas where I have seen potential gaps and just flag those. Well, I actually that kind of maps to the document that I shared earlier this week. So some of that is already in there. But I guess the other thing to flag from my comments or questions in the thread was the provider profile, missing fields field. It’s going to be like super helpful. Like that will be extremely beneficial. The other two, the other two areas where like we will implement some sort of rules is on the payer enrollment service request itself. So, I guess my question is like, is there any way, what would be the best way that you would envision for us to block certain? Like passing of data that’s like going to like fail? Like if we tried on like united healthcare to like pass a traditional medicaid line of business like that would not work. So like, I guess my question is like, should we take that in house and like work on ways to flag those? Or is, so there’s something that we should partner on there? Yeah.
Brittani Luyen (17:22) So our expectation for how this should work is that we should send you back 400 if they’re invalid combinations of either like payr and line of business or state and payr, we aren’t there yet, but this is where we expect to get and are trying to get. So like we would expect to own some of that validation and logic for you all and expose that to you and error if you try to do submit a PSR with incorrect configurations. Yeah, I think that came up to you. Yeah.
Ross Martin (17:51) Yeah. So I think there’s like two things in my mind that’s one of them, which is just, I think we’ve been talking about it in the sense of like anything in the UI that has a certain validation or restricted rule set will be, you know, at parity in the API. The second thing I think we should do is provide at least like high level guidance of like what those validations are, so that you can program some stuff. And again, I think if we’re just like, hey, this covers 90 percent or something of the validation cases with those simple rules, you can have them. I don’t think we want to be in the business of exporting like all of our validation logic and trying to keep that up to date but, you know, basic high level kind of persistent rules plus making sure that you feel like the API contract is informative and valid, feels to me like the ideal state. Yeah.
Micah Sanders (18:38) I think that makes sense. And from what I’ve gathered of like just conversations with Vanessa and you guys et cetera. Like it’s a small, maybe a smaller subset of rules that will take care of a lot of the stuff. And then a similar question for group profiles. Like we could kind of hard code in some stuff like just based on like commercial medicare medicaid, et cetera. But I guess just curious if you guys have a perspective on what’s the best way for us to kind of limit group profile requirements when they need a group enrollment based on the type of pesr?
Ross Martin (19:18) Okay. Yeah. So in this case, you’re not talking about validation, you’re talking about actual like requirement logic?
Micah Sanders (19:24) Yeah. Like in my head, it’s like similar to the missing fields from provider, but I don’t know if you guys have a perspective on that. Yeah.
Brittani Luyen (19:34) So, I think there’s two things there there’s like missing group profile fields, right? And like that’s also something we can expose in a very similar way that we expose provider profile missing fields. Like we already think about it very similarly from that aspect that’s like that would be a new endpoint we’d have to expose. But it’s logic that we already do on our end as well. What we don’t have encoded because it’s relatively new is like prior to y’all, like 99 percent of our service requests for payer enrollment came with an associated group because individuals weren’t enrolling without groups. I think you guys have seen this play out a little bit with like the operational aspects. So that is logic we’d have to encode, but I think that like we should do that anyway, like which payers actually require groups to.
Ross Martin (20:19) Be?
Brittani Luyen (20:19) Enrolled and making sure that we codify that in our code base. Yeah, that makes.
Micah Sanders (20:25) sense. Like that would be extremely helpful. I think realistically like I think we would if we like set this loose in the while before that’s available. Like we would probably set some like really basic rules ourselves for like the top payers, just knowing that like the majority of, you know, requests are going to come through for like optum, cigna… Aetna, etc, like we would probably just like throw some rules in so that we at least reduce some pain, but that would yeah anything that we could get there is like super valuable.
Micah Sanders (21:05) So.
Ross Martin (21:06) Okay. And can we just bundle that in with our, like what we said in like the last part of the conversation, like any rules around submitting payer enrollment, service requests will just include some of this logic. Yeah, 100 percent 100 percent. Okay, great.
Micah Sanders (21:21) Yep, totally behind that. Cool. I think that’s it on my questions initially on that diagram but really appreciate that it’s very helpful to see. But do you want to move to tasks, Brittani?
Brittani Luyen (21:37) Sure. We can. Does anyone else on the team have any additional questions or questions? Okay, cool. Yeah, we can chat about tasks. So our proposal for this is that I think I sort of already mentioned this when going over the diagram that we are able to tell you what is the thing that is missing or needs updating? Like what is that object? And what should the user do with that? Are they uploading a new document? Are they updating something that’s already existing? Are they like signing something off platform? Are they simply checking a box? Like those are all different things that we could be asking user to follow up on. And I think in our previous conversations, the way you all wanted to think about it was less like here’s a task that you need to resolve and like speak to an ops team member. But like surface like all the requirements in the profile as to dos. And theoretically, if you complete all of the to dos in your profile, like you’ve then fully filled out your profile and then can submit your application, or we can submit the application on your behalf. What we will commit to is very similar to the provider profile. Like if you give us the priority payers, the priority lines of business priority license types, we can prioritize getting as much coverage as possible for those combinations that you tell us are a priority. I think we’re at 90 percent there. But the long tail can sometimes be a little bit difficult to chase down. But obviously, like the more coverage we have of the full application requirements, the easier the user experience is going to be. And the less follow up there is going to need to be as far as like how you may want to design your experience for like follow up itself. I think you had initially talked about like you would prefer not to have this like communication channel happening more or less. But we may need like a backdoor way for that communication to happen if necessary. I think that’s the piece that I haven’t fully scoped out as much like how would you all want that back and forth to sort of happen? Because ideally we can make it a requirement, a field you complete if it’s missing, go complete it. But as far as communication between our team and yours, that’s a little bit of a gray box. I would say.
Micah Sanders (23:58) Yeah, that makes sense. I think my initial take is if… we, if a medallion like payor enrollment, ops team member needs to contact the provider to like sort through missing requirements of some kind beyond the task. So like I don’t know, say that there’s like a task to upload something the provider uploads it. It’s not good. It doesn’t work. Like, I guess one solution would be like put out another task that like asks for it again that’s an option. If there’s like truly a need to contact. I guess my instinct would be like, is there, well, one is like how often would this happen? And therefore, like how robust of a solution do we build? But then my instinct is like we ideally would route that to our CS team with a link to like the provider and the payor enrollment, like specifically in a way to, so that our CS team can look into it and then reach out to the provider. That would kind of be my instinct for how we’d want to handle these cases. But then like how good of a solution again would depend on like how often does this need to occur?
Brittani Luyen (25:18) Yeah. It’s a little bit difficult to indicate how often this would occur because I think part of the goal is to reduce how often it occurs. I think it happens more today than I, than either of us would really like. So we do have service requests that go through today without there needing to be any follow up requests. I think the last time I looked, it was like slightly over half 55 percent of our service requests actually go through without needing a task created? As long as so, as long as we’re clear about the intake requirements? I think we could get there… but I don’t know if I would have a good sense today of, you know, is it going to be, if we try to make this even better? Like are we going to get to 10 percent of there needing to be communication? 20 percent? I think it’s a little bit hard to say today, but I think that makes sense as a like a backdoor workflow. And of course, the goal would be to get as few of these backdoor workflow communication channels going as possible, right? Let’s get as close to zero as possible. Yeah, the.
Micah Sanders (26:23) Other thing I think about is like, you know, in the medallion UI, in all of these cases like the full, I guess capabilities still exist. So I wonder there… could just, there could be something we could do where we, I don’t know how we would do this. But if there was a way for us to like automatically trigger a ticket to our CS team when like the ops team is like trying to communicate with the provider, that could be an option as well. I don’t know how we would do that because that wouldn’t that happen like through like a note in the task or like a comment in the task or something?
Ross Martin (27:08) Well, I think one.
Brittani Luyen (27:09) You go first. I was.
Ross Martin (27:12) going to say, yeah, like if you’re just worried about like the programmatic side of it, like we can have webhook events for all of that. So you just get notified whenever an ops agent does that.
Brittani Luyen (27:23) If.
Ross Martin (27:23) there are cases where the ops agents actually skip tasks or kind of go outside of tasks to try to do that outreach, which I think is very rare. We could also just try to figure out like a it’ll be like both an operational and a technical change where we just like have some integration to you guys where we can like trigger that kind of ticket creation. So, yeah. Okay.
Micah Sanders (27:46) I also think there’s a possibility on our side of creating… you know, again to take the iterative approach. Like we could probably create some system where… I don’t want to promise this, but I could go ask for something like this where like any pesr that has been like sitting for more than two weeks, like could just get like looked at by our customer support team, like in an initial stage, that would be a resourcing ask that we would have to make for, you know, a time until we kind of sort through how to like reduce these cases. But that is a possibility… if it means we can like get the end to end experience, you know, quicker. So can.
Ross Martin (28:36) I ask one actual like deeper question about when you say like you want your customer service to talk to the providers instead of ours and you can be like very blunt, you won’t hurt my feelings here. Is it just because like our customer service isn’t like good at talking to your customers or is there something else? And the reason I ask is because we are also trying to automate as much of this as possible. So we’re experimenting with a lot of like AI like SMS and email and phone call outreach. And so like we’re trying to like measure how good the outcomes are in terms of like time to complete profile csat, all of that kind of stuff. And so I guess my question is also like if we were able to do a good job for our own purposes, is that something that would be interesting to you or is it just like a full on, you want the control period? And to be clear, I’m not super opinionated. I just want to know, yeah, I.
Micah Sanders (29:21) Think it’s two things… in the immediate term. Like what we’ve seen like our feedback has been that people have had a hard time talking to medallion customer support. And I don’t think they differentiate between like ops and customer support, right? It’s just like a medallion person. And at times like the there’s been like language barrier concerns and then just like how the tasks are written, concerns with that, like when they’re manually written, that just being confusing that’s one piece. But honestly the larger piece is just if we’re bringing the like UX entirely into simplepractice. I think it’s confusing if there’s like another person that they would be potentially interacting with. That then is outside of our customer support. And like potentially our customer support doesn’t actually interact with themselves. I think that could just be that’s just like a bit of a disjointed experience. And so, like it’s more of a philosophical thing is just trying to like limit the amount of people that one of our customers would have to talk to.
Ross Martin (30:29) Okay. Cool. Well.
Jenn Hansen Engineering (30:34) I’m just going to add on that. I’d also be curious like if they would know when, you know, like if we made it more programmatic and they wrote the task and we sent it, would the instructions be given specific to like medallion UI? And then it would like be another hurdle because like we do have a third party we work with and I know our support always has that issue of they always think we’re doing the UI, but we’re often doing like things through an API. So.
Ross Martin (30:58) I think that is an interesting thing about the tasks like I think as we start to scope out like how we will surface tasks to you, like we will probably on our side want to encode more metadata in the tasks where possible. So that like maybe ideal state is you don’t have to care about the description at all or maybe very much again, there will be edge cases. But for anything that’s like a nudge or a reminder is like, hey, there’s this field, we already know that it exists, simplepractice and medallion share the same understanding of what that means. And we just need you to like prompt the person to fill it out. That’s like a place where metadata can carry us all the way where it starts to be these like concepts or like actions that are not encoded in the data model right now but are like kind of known actions like go get a wet signature, go do your fingerprints, whatever it happens to be that I think metadata can carry us pretty far. So, I think it’s like kind of like how much can we shove into that basket? And then maybe use like description as a last resort in your products or maybe anything where you can’t resolve it on metadata alone that goes to your csq or whatever it happens to be. Makes sense? And.
Micah Sanders (32:08) I do think I do think there will be some… of this will get naturally sorted out as we try things when like our customer support has now that our customer support has access to like the medallion platform on behalf of providers. I think that will just inherently be helpful. Any other questions, things related to tasks we need to talk through? No, we’re, I guess we have plenty of time.
Brittani Luyen (32:43) No, I don’t think so. I think those are, I think we’re aligned on the same page. Like we will try to get as structured as possible with the task data to try to reduce the need for either follow up or unstructured descriptions. We’ll prioritize a set of payers and lines of businesses and licenses based upon feedback you give us to try to get as close to like the most structured we possibly can, to try to reduce that follow up. I don’t think there’s anything else that I wanted to cover like with the shared understanding that it may not be perfect on day one, but we’ll partner together on making it as comprehensive as possible.
Micah Sanders (33:25) Awesome. And then as far as like the timeline, like I know kind of for Brad as well, like we were on site last week and then Shazad is out this week. And so I don’t know if we owe you, we may owe you some like feedback regarding your like just how we think about timelines here. But maybe just let us know what’s next, if, yeah.
Bradley Eral (33:51) Yeah. Well, we owe you, I’ll give you kind of the two scenarios, right? If we keep status quo as is, when do we expect delivery? And then, you know, if we were to expand the partnership with the early renewal, what would the timeline look like? So that’s what I owe you guys.
Bradley Eral (34:04) And then we can find some time to huddle up once you have some time to digest that and see like look is the incremental gain? Is that enough to warrant an early renewal? Yeah.
Micah Sanders (34:15) That’d be great. And then maybe my other question… just around like other, outside of the whole tasks piece like other priorities. So webhooks for the pesr is mid may and then honestly, like, and maybe Jen or josh or Berta would disagree, but I tend to think actually that like all of the rules pieces like exposing missing fields for like provider and group, and like having some basic rules we can utilize. And then the 400 for the pesrs. To me those actually are more like need to have to bring the whole thing into simple practice than like further webhooks I do think we would want eventually more webhook options but like those rules are kind of like need to have for at least like a subset, a large subset of payer license type line of business combos to feel comfortable just because, you guys do a good job of blocking certain things in the product today. So I would tend to prioritize those first beyond like further webhook development.
Brittani Luyen (35:31) Okay. That roughly aligns to how I’ve been thinking about the roadmap this quarter as well. So that sounds good. I don’t have like timelines yet for the validations or the missing fields end point, but we can potentially work to get you more details on that timeline in conjunction with the timelines that Brad’s working on as well. But that prioritization is helpful. Yeah.
Micah Sanders (35:54) And then just on our side, like we’re in dev with the milestone that we’ve shown you previously. And like then we would plan to release that toward the end of this month. And then like late this month, early next month pick up like the next pieces. So like we’re in process designing kind of like a bit of an integrated like payer selection like profile requirements, workflow. And we could probably show you that at some point in the next week or two just to get like a look at like kind of how we’re thinking about it. And we’re trying to like create like a more kind of a bit of an integrated step by step and like guide them through like the ways that we want them to take the process on. And… like we would start working on like our all of our engineering capacity as much as possible would go towards that starting like early may like late April, early may. So maybe in one of our sinks in the next week or two, we can show what josh has as far as designs there just to give some visual.
Brittani Luyen (37:06) Yeah, that’d be super helpful to sort of understand the experience as you all are working on it. Yeah, definitely.
Micah Sanders (37:17) Oh… actually one other, one other key, maybe two other mainly, yeah, two other questions that are maybe most concerning to me when we think about like where this could go wrong. One is the like agreements section of the profile like the there’s like a medallion specific agreement. And then there’s like a caqh agreement. And I’m intrigued by like how would we, how would we handle those? Like do they need to sign the same agreement? Should we like have our legal teams co, draft something else that like our providers sign? Like should we, I don’t know, I’m curious how you guys think about that cause if we, and… how we could pass that, if we need to pass it to you. That’s… one question. I don’t know if you don’t have thoughts, it’s okay. But I’ll stop there in case anyone has thoughts on that.
Brittani Luyen (38:19) Yeah. I mean, the, we should definitely get our legal teams input on that as well as whether we think that there needs to be a different version of this, Brad, maybe that’s something you could help with moving in the legal team to think through the agreements piece as far as like how you pass that to us. I mean, there’s a couple of ways we could approach this. It just, we could consider this like an off platform signature for you, all right? Where like they open, we could either work with a vendor for this or we can use our like our application where they are going off screen to sign something. I think that’s a pretty standard flow for users anyway that they’re signing through some third party and agreement. We don’t currently do this through a vendor, but we could, we have done this. There are other use cases where we’ve used a vendor for agreement signature… if you wanted to do it native in your platform and like pass us that like completed signature data. I’d check with. We should probably check with legal to see whether that’s sufficient. But I think we can approach this in multiple different ways. Okay?
Micah Sanders (39:23) I’ll start talking to our legal team about it just to get their insight. And if you guys would do the same, that’d be helpful, we have probably a couple of months before. We need to be worried about that, but it’s good to get it started and.
Ross Martin (39:37) Just for my knowledge, do you, what vendor do you use for your like signature and document stuff?
Micah Sanders (39:42) Oh, man. I honestly don’t even know Jen or josh or Roberto, do you guys know? Okay, I want to say probably like, is this something that DocuSign handles? Yeah.
Ross Martin (39:57) There’s like DocuSign and like a 1,000,000 sasspocalypse copies out there.
Jenn Hansen Engineering (40:01) Yeah. I don’t think we use DocuSign because a lot of our signatures are captured by coordinates and then we send the coordinates and I don’t think that’s a DocuSign thing.
Josh Waldman Product He Him (40:10) I think our sales team uses DocuSign, but I don’t think we have a lot of signature collection workflows right now. Yeah.
Ross Martin (40:20) It might be the, and like we want to vendorize our side of it anyway. Like we were like Brittani said, like some use cases, we have a vendor for some is like more in house kind of like what Jen was saying. Actually, we kind of want to move fully to a vendor solution anyway. So the actual like technical bit like we might actually want to do like a co, vendor like exploration so that we could do an easy thing where you can sign a document in your platform or in our platform. And we’re able to like understand that mutually. So.
Micah Sanders (40:47) Yeah. Okay. That’s a good thread for us to start on. The other thing I was going to ask about is the contract delivery from the payer. So my understanding is that happens either through email direct to the provider or it comes to medallion. And then an ops team member passes it as a task… while like while the experience is like largely in simplepractice but without tasks, that is a potential problem. I could see a world where we have an interim state where like we build in a trigger where we like based on status change, our CS team like finds a way to deliver the contract so that the user doesn’t have to like know, to jump to medallion or maybe we have some other process for that. But I just wanted to make sure. Are those the two ways that contracts do get delivered? Okay?
Brittani Luyen (41:41) Yeah. I did stick with Vanessa on this. It’s basically like the payer sends it directly to the provider for signature. We have a little bit less visibility on that, of course, like we know whether it’s been signed, but like otherwise that’s really on the provider and then, or it comes to us and then we forward it to the provider. Yeah. And so to your point, maybe that is a CS driven workflow for a little bit. I’d also be curious. I’ve never asked like, is this something we have any control over? Like is this, is it there’s any flexibility on the payer side to decide who you send it to? I don’t know whether that’s possible or not. But I can start that thread with our operations teams. Yeah, that’d be interesting. And I think the preference would be to send it to the provider, right? That would be our preference.
Micah Sanders (42:24) Theoretically. Yeah. The only concern, right? Is like from my understanding, the statusing on your pesr, wouldn’t change from like payer processing if it goes direct, but if it goes through medallion, the statusing changes and it allows us to nudge that. It’s like ready. That would be the only argument against. I think, yeah.
Brittani Luyen (42:46) Like unless we have some visibility to the fact that the contract’s been sent to the provider and could then change the status, okay, another thread for us to pull on and explore. Yeah.
Micah Sanders (42:56) Cool. And then this is, I think this is something I bugged josh about before, but there are, and it’s something that I’m exploring with our legal team. I don’t think it may not impact you guys, but I’m interested in like legally if there’s any basis for our providers to allow us access to the contract or even a part of the contract for the purpose of like automating revenue cycle setup for them. Like if we know like things like if we can like have locked in how they are structured with the payer, their contracted rates and all of that data, then we can like automate revenue cycle setup. My question has been to josh previously. Like does medallion actually have like read access to these contracts? And I don’t think that medallion does, from my understanding, it’s just like an intermediary, but if there are cases where there’s like read access, I’d be curious like the legal basis for that. And like what? Yeah, I don’t know if this is even a question that you all have thoughts on but.
Ross Martin (44:09) There.
Micah Sanders (44:09) Is some value to simple practice when we think about how do we help people understand client benefits and like claim filing, etc? So, yeah.
Brittani Luyen (44:19) Let me check on that. I do not know the answer off the top of my head if we have read access to these contracts and if we do there’s probably like things that we could do to potentially store that data and pass it to you. But… that would be continuous having read access and I don’t know the answer to that, but I’ll follow up and.
Micah Sanders (44:40) There’s also, you know, obviously the payer has written into the contracts like often like don’t share these. Basically, the question is like is I don’t know if the language from what I’ve seen has often been more aimed at like the use case of like sharing broadly to other providers and the pair being worried about like the competitiveness of rates, which this would not be that it would be actually like in house to the provider only benefiting, the provider. So anyways, it’s something that I pulled on with our legal team to see if there’s any, if we could. We could literally create like an upload feature where like optionally the provider could upload the contract or we could parse it and then help them out. But if that’s not like a must have it’s just something that we’re curious about.
Brittani Luyen (45:24) Yeah. I guess the other way to go about it if we, you don’t necessarily have the like legal access is to ask the provider to like input that and store that in your platform, which is definitely wonkier and less of a smooth user experience, but.
Micah Sanders (45:38) Yeah, we do that today. Like we, it could be, we could have better workflows for it, but, we do try to do that today. Cool. I think that’s it, anyone else have questions? I know I’ve been question asker.
Ross Martin (45:57) I just wanted to check in with Jen. Like for everything that we have delivered so far, like is that usable? Like I’ve you’ve asked a couple questions. I just want to like high level check in if that’s going okay for you? Yeah.
Jenn Hansen Engineering (46:09) We’re we’re still working kind of like on just showing the data to, our users that’s in progress. And then it seems like, yeah, what we, what you delivered with the caqh endpoint will give us exactly what we need. We kind of like have a process, we can work from for that. So that’s very helpful. Thank you. Sweet. Right? Also… I did notice on that spreadsheet, it talks about the, where we would create the organizations ourselves. That endpoint isn’t something we’re supposed to be expecting yet, right? Okay. I was like, I don’t I didn’t know that was in our radar yet. And so I was just double checking soon.
Ross Martin (46:47) That’s one of the ones where we could in theory expose that sooner, but we would like to tidy up a little bit before we expose that to outside of the house you.
Jenn Hansen Engineering (46:57) Know, what we have working right now is working just fine. And so I do think we’ll switch to that at some point, but I think for, right, for our next step, we don’t need it. So like the immediate step. So I think that’s fine. Okay, great. Yeah.
Micah Sanders (47:12) That’s actually probably a good point is, the quote unquote onboarding to medallion like flow is probably okay for us for the foreseeable future. Like like Jed said, we would like to move that to API at some point. But while we’re like kind of sprinting towards these other pieces, I’m not sure it makes sense, to move that while it’s still working. So that’s fine.
Jenn Hansen Engineering (47:37) One random note that we don’t need fix, we can work around it, but I just wanted to call out is for some reason the provider individual provider endpoint doesn’t return the group profile, only the index of providers returns the group profile, which was just a little odd, but we don’t need it fixed. We can, we’re probably only going to be calling in bulk of like all of the providers for an organization. So it’s not a big deal. I just thought I’d highlight that.
Ross Martin (48:04) That is helpful. A little interesting for sure. Going forward. Do you have preference for like whether we include related objects or just a foreign key that you can? The?
Jenn Hansen Engineering (48:17) Foreign key is fine. We can work from that. I mean, it does mean we’ll hit your API a lot more because we’re our plan right now is kind of like a nightly sync job where basically we’ll for each organization that hasn’t been updated within… refresh their providers, their groups, and their payer service requests. So we’ll basically make three calls per organization every like 48 hours. Yeah. But let’s base it out. Yeah, I’m.
Ross Martin (48:48) not worried about like that scaling factor like two verse three verse four isn’t obviously that big of a deal. I think when you start to experiment with that, maybe just give us like a little bit of a heads up. Like again, I think at the scale that we’re working, that should be like nothing for our system and it shouldn’t matter, but I just want to like make sure that someone’s watching it so that we can, you.
Jenn Hansen Engineering (49:05) Know, be sure. Yeah, for sure. Sweet.
Micah Sanders (49:12) Cool. Thank you. All. This has been really helpful. Yeah. Appreciate you guys. I will pass on like priority listed payers with lines of business and license types as soon as I can hopefully within the next week, or so… well.
Brittani Luyen (49:32) And I know we have a couple follow ups here as well. So we’re gonna look into the agreement signature piece with our legal team and sort of understand what that workflow should look like between the two of us as well as let’s see. I’m just reading through my notes, read access to pair contracts.
Brittani Luyen (49:57) And then maybe some timelines for some of the like validation work while work with Brad on getting those timelines together as well. Okay. I think that’s probably, the primary things that we said we’d follow up on great.
Micah Sanders (50:13) Thank you guys so much appreciate it absolutely.
Brittani Luyen (50:16) Thank you.