Transcript
Bradley Eral (00:00) what’s up Ross?
Ross Martin (00:02) Hey, Brad. How’s it going? Good morning. Good.
Bradley Eral (00:04) Man. Sorry for the fire drill this morning and the lack of feedback from them?
Ross Martin (00:13) That’s how it goes. No worries at all.
Bradley Eral (00:24) Hey, Brittani. Good.
Brittani Luyen (00:26) Morning.
Bradley Eral (00:27) Good morning.
Brittani Luyen (00:31) Yeah, I can’t imagine we need a full hour. Yeah. If it’s just us and Sean talking about sso?
Bradley Eral (00:38) Agreed. Is that… am I getting a call or are you getting a call? I’m not getting a call.
Bradley Eral (01:00) here’s, Sean. So before we let him in, I’ll kick things off and just pass it to you guys. Do we think or what’s kind of the best way to lead into today’s, discussion knowing it’s just going to be Sean.
Brittani Luyen (01:14) Yeah, I think that’s fine. Ross. Do you want to drive or do you want me to drive? I’m happy with either?
Ross Martin (01:18) I think you kind of hit on mine because it’s not actually technically difficult. So I don’t.
Brittani Luyen (01:23) know what we’re doing. Yeah, I’m also, yeah, totally fine.
Bradley Eral (01:28) Awesome. I’ll let him in.
Bradley Eral (01:34) Hey, Sean. Hello. How are you doing today?
Sean Behan (01:38) All right. How are you doing?
Bradley Eral (01:40) Well, appreciate you jumping on. Yeah, I.
Sean Behan (01:43) tried to get someone from our tech side. They’ve got a leadership meeting at the same time.
Bradley Eral (01:47) No, no worries. We can use today to, or this call to talk through sso validate, we would fit the requirements to meet your needs. And then I think coming away from this discussion, we should be in a spot where we can turn around two things, the sow and then as discussed make sure that there’s protection to your team, if we don’t deliver on what is in with the sow. And then if, for whatever reason, we need follow up calls with your technical team, we can obviously coordinate that. But does that sound like a good use of your time? Sure, perfect. So with that said, I’m going to pass it to Brittany, she’s going to be driving this discussion, but again, appreciate the time and looking forward to it, well.
Brittani Luyen (02:25) Thanks, Brad. Yeah. So I think the last time we chatted, I’m not on mute, right? Yeah, I’m not, we discussed the possibility of sso and whether or not a user would be able to get into medallion without a separate set of credentials because as you mentioned, like additional set of password and username, which has caused a lot of confusion, a lot of additional admin on your work to figure out if users need to reset those. So we were able to scope this. And we do think sso is going to be possible from therapynotes. So what that experience would look like is a user would be in therapynotes, they’d either have a button or some link that they could click within your platform, and that would open a new window or a new tab into our platform. And they would not have to have a separate set of credentials. They would just be logged into their medallion account. A couple of things to note that like the account creation process will be separate from this. So this is assuming they’ve already created account through the account creation process that we’ll set up. But once they’re in therapynotes, they do not have to use a separate username and password to get into medallion. The caveat is if they go directly to medallion co, right? So instead of coming from therapynotes, if they just type medallion co into their URL bar and end up on our platform, we won’t be able to do sso in that context because we just don’t know they’re coming from therapynotes. And so we don’t have that context, but that’s not the experience you all want to drive anyway. You want users to be coming from therapynotes. And if users do want the ability to log into medallion co directly, like we will give them the ability to set up a username. And password. But as far as sso directly from therapynotes platform, yes, we can absolutely do that. I’ll pause here for questions.
Sean Behan (04:15) Yeah. I think the idea was that they wouldn’t have a username and password, right? They wouldn’t be exposed to them. They wouldn’t know there is no going to medallion directly.
Brittani Luyen (04:25) Yeah. I mean, the only thing we can’t control is if a user like types medallion co, into their URL bar, I think that’s the only scenario in which we can’t control for. But if they’re coming from therapynotes and write like theoretically, we could have them initiate like enrollment requests from therapynotes. So it all feels very therapynotes contained. And so that experience always starts with therapynotes. And from therapynotes. If they try to get to medallion, they don’t have to have a separate username and password. They don’t have to log in. That would be sso enabled.
Sean Behan (04:54) Right. Like they could go to the website, but they’d hit the login page and not be able to do anything. Yeah.
Brittani Luyen (04:59) Unless they like decided to set up their own username and password, but they don’t need to do that.
Sean Behan (05:05) Well, I guess that’s the question, right? Like if they set up their own username and password, they’d essentially be registering for a different medallion account.
Brittani Luyen (05:13) That’s not necessarily true. They could set a username and password for their medallion pass account. So cause they would use the same email theoretically. So that is something that is worth considering like if they did go directly to medallion co, they could set a username and password if they so wanted. But they don’t we can discourage that in a number of ways. Like all of the communication, it can be like login through medallion at, you know, via therapynotes, et cetera. We could also explore down the line, the ability for them to like select that they’re coming from a therapynotes as like their organization and then log in that way. But I think the experience that we both want to drive these users to is like go to therapynotes and go to medallion that way and avoid all the login hassle in the first place, and that we can definitely do.
Sean Behan (06:06) I think… from our perspective, it’s not just encourage it’s require, I think it’s more of a must rather than a shall.
Brittani Luyen (06:16) Got it. And so you’re saying like we do not want to enable an experience for them at all. Like that. I mean, if they don’t set a username and password, they won’t be able to get into medallion. And so.
Sean Behan (06:26) Right. We don’t want that to be possible, that’s the key piece, right? Like there is no workflow in which they set a username and password on your platform that’s the point of sso for us.
Brittani Luyen (06:48) And I guess like we… are comfortable with like a user experience in which like they can’t go to medallion co directly. It just wouldn’t work for them. It’d be broken basically. I mean, they.
Sean Behan (07:02) can go, they can see your website. They can log in for a separate user account. Those kind of things, obviously, right? We’re not going to stop somebody from creating their own relationship outside of that, right? But if they’re a therapynotes customer accessing medallion through therapynotes, right? And they’re using our pricing, our benefit of the account creation, all of that kind of stuff they are locked in through therapynotes. There is no, there is no ability to go in another pathway. Okay?
Brittani Luyen (07:37) Yeah, that’s a different experience than what we thought you may have wanted. I think like the thing that we were assuming is that we did want a pathway for them to be able to log in through our own platform, if they did go there instead of getting them to like a wall, but I think potentially it’s something we can explore Ross. I know you’re about to say something.
Ross Martin (07:55) Yeah, no, I think to be clear like it’s easier for us to enable what you’re talking about. Like I think it might be a confusing user experience. But if you’re okay with that, I think we could probably also become okay with that. The thing I think that we’ll introduce though is it’s kind of like an if and only if so if your users can’t sign into our platform with the username password combination, which is what you’re advocating for. That means that their email address will have to be unique, to your organization. So if they have an account through medallion for some other reason, we won’t be able to like authenticate them via sso, they’ll have to have a different email address, right? And the reason there is just like a cryptographic trust thing, we can’t like let you vouch for someone who’s going to log into a different tenant essentially.
Sean Behan (09:02) Sorry, I’m just trying to like think through a couple of like pathways real quick. So it’s.
Ross Martin (09:06) yeah. And to be clear, like we have run across this with other enterprise customers and we have like workarounds. We usually create email aliases. I don’t know if we need to get too in the weeds here, but I just want to be clear about like if we can only allow your saml authentication method for your users, then that means like we can’t have our other clients just implicitly trust you. Yeah.
Sean Behan (09:31) I guess… you get email addresses, your primary id for somebody at that point, right?
Ross Martin (09:40) Yeah, exactly. Because.
Sean Behan (09:42) I was thinking the authentication would be tied to an id rather than an email address. So, if they have a separate account, right? And their therapynotes id is one, two three four five, and then they go to medallion with the same email address and sign up for another account, that account is six seven eight nine one.
Ross Martin (10:00) Yeah. So they’re going?
Sean Behan (10:01) Into a separate account. I.
Ross Martin (10:03) Hear what you’re saying, but our user accounts are tied to email, and then each of those user accounts can have one or many authentication methods. And like we said, for you, we’re willing to do what we can to disable all but your saml connection for them. We can make that happen. But again, we can’t really impose that on the rest of our platform because most customers actually really appreciate that flexibility.
Sean Behan (10:35) So… let’s assume that I’m an admin user for a second, right?
Ross Martin (10:46) So,
Sean Behan (10:46) I have an email address, you know, admin at mybillingcompany com, right? And they provide third party billing services to a therapynotes practice and the practice wants to credential. So they come in through therapynotes, and I’m credentialing for my practice, right? But they’re a third party billing company that uses medallion as well. So that means all of our therapynotes data would be exposed on your platform when they log in for their own private billing company, because there’s no logical separation between users. At that point. It’s all based on the id. And if your third party billing company credential gets compromised in some way that would then risk therapynotes data. No.
Ross Martin (11:35) No, we only allow organization membership like one user per organization. So that’s how we maintain that data isolation. So, we explicitly don’t allow people to have multiple accounts like that.
Sean Behan (11:49) Okay.
Sean Behan (11:56) I guess now I’m lost if people can’t have multiple organization accounts.
Ross Martin (12:00) Sorry, practitioners can’t we do allow it for what we call admins, which is like the medical staff office for some of our other clients.
Sean Behan (12:14) And that’s kind of the role I was talking about, right? I’m a third party billing service. And so I have, I’m one person providing services to multiple organizations… and I offer credentialing, but I choose to do that through medallion. So I pick up customers from my website from other leads, that kind of stuff. And I have a medallion account, right? But then I have that same email address that’s with a therapynotes practice because that therapynotes customer hired me to be their billing partner. So now people that are having the therapynotes and don’t have any kind of… to their knowledge outside relationship, right? With medallion, they see it’s a therapynotes product we’re reselling like, you know, it’s powered by medallion rather than a right? But that billing credential then becomes, they… can get to the therapynotes data. They can get to that private data that’s outside of therapynotes through that one user id is?
Ross Martin (13:20) What I mean? Yeah, exactly. So the currently, our multi tenancy model is that they can log in to their account and switch tenants within that one account. But I think like we have technical workarounds there. Like I think what we can do for you and we should probably we could do this pre sale or post sale, but we can go through and do an analysis and see like how many users actually fall under that case. My suspicion Sammy would be the actual expert here is that there’s actually exceedingly few people who would meet the case that you’re talking about, but we can test that empirically. Two, we can also make sure we do that kind of validation upfront during the account provisioning process. And like do that detection and say, if you have a different account, we can send it back to you and say, hey, we need an email alias like there’s all sorts of like different technical solutions we can come up with for these like edge case users.
Sean Behan (14:08) Would one of them be a separate two factor token? So when you enter a therapynotes account, you’d have to enter your therapynotes specific two factor token or approve a push, however you do two factor.
Ross Martin (14:27) Well, I mean, typically with like saml, enterprise connections, you control the mfa on your side rather than it would be us so that’s something you could enable or disable regardless of whether we do this. We wouldn’t really have that kind of control over how you provide the security assertion now.
Sean Behan (14:45) This is where we’re getting beyond my true technical knowledge, right? Like I have the high level kind of view, but yeah, when you authenticate in a saml session, you’re authenticating the session, right? So if they’re switching tenants within yours within your platform, we don’t necessarily know that to enforce that second factor at that time of switching, yeah.
Ross Martin (15:09) And I think that’s why the lower lift on both sides of our engineering effort would be to figure out how to just provision a different email address or a different account with a different email address for this person. And so Sammy can speak to this more. But what we’ve done for other customers who hit this edge case which again is very rare is we just provision email aliases and it’s transparent to users and allows a very clean separation of data and security and all of this stuff. So again, you can kind of go back to caring about what you care about, which is, hey all therapy users only access medallion through therapynotes, sorry, therapynotes. And you can’t see therapynotes data unless you’ve been off to our standards which may or may not include mfa.
Sean Behan (15:57) Okay. We’re pushing the envelope of where I can speak to detail, right? But that sounds reasonable from a 30,000 foot view.
Ross Martin (16:12) Yeah. And I don’t mean to like blast you with the overly technical explanation. I just like… I want, yeah, I think like what’s helpful for us is for, to make sure that we can like understand exactly what you want, what you don’t want, understanding that some of the implementation details we’re both going to have to be flexible on because that’s just, you know, how these kind of integrations go. But high level, I think we both want to make the same thing happen. And I think it’s very technically doable. This isn’t very different from what we’ve done with other customers.
Sean Behan (16:46) I mean establishing an alias for that, as long as we can get communications back to the customer with their actual email address isn’t a terribly difficult thing, right? It’s not ideal, but they have no idea and it’s just an alias.
Sean Behan (17:08) So now they left.
Sean Behan (17:13) So, I guess the other question, what standard are you guys looking for? Because you had mentioned one? Now, you just mentioned saml. So I just wanted to.
Ross Martin (17:24) Yeah. If you want to use saml, that’s totally fine. We’re totally indifferent to oidc or saml, it’s really whatever’s easiest for you.
Sean Behan (17:33) Okay. I think, you know, I brought that back to the team and we had another vendor that we’re looking at maybe doing the oidc with, you know, they have a separate app service that we can do. So, yeah… if it doesn’t really matter to you which protocol that kind of helps a little bit, but.
Ross Martin (17:55) Sure. Yeah. I mean Sami doesn’t your team usually help with the provisioning of the enterprise saml connections?
Sean Behan (18:01) Yep. Yeah, that’s correct. That’s something we’ll do during the implementation process.
Sean Behan (18:15) So… I don’t know what really is… left on my side to talk through here. We’re going to get them logged in right there’s. Not going to be a way for them to establish… that email address that would have access to other tenants within the system.
Brittani Luyen (18:37) Cool. Okay. Yeah. I think we have a clear understanding of the requirements which is really what we wanted to get out of this call and make sure that you had all of your questions answered. So we want to enforce that therapynotes users can only log into medallion through therapynotes. They are not able to do that from medallion. Co, we will block that from happening. And then if you are within a therapynotes tenant, you cannot switch to another unless you’ve authenticated to therapynotes, that’s the only way you could access therapynotes data is if you’ve authenticated through therapynotes, those are the two things that I hear we have to make sure to happen. And I don’t think we see foresee any like… technical blockers that would prevent us from being able to do that. So that’s all good. Is there anything else that we can answer for you or anything else that you wanted to chat about Sean?
Sean Behan (19:26) I don’t think so. I think from our end, it’s just, it’s costs at this point that’s starting to become a concern.
Bradley Eral (19:37) Yeah, makes sense. So what we’ll do is we’ll take away, appreciate the time today. By the way Sean, we’ll memorialize this in an sow, send it your way alongside the language for protection just to get your eyes on that. I’m sure if I’m you and Brad, some questions may arise once you do get your eyes on that.
Bradley Eral (19:56) How does your schedule look tomorrow for 15 minutes should be plenty? But a quick 15 minute sync to review the updated language. Thank you.
Sean Behan (20:14) I think it looks like one 30 is my only opening tomorrow.
Bradley Eral (20:18) Perfect. One 30 that works on my side. I’ll send over an invite for one 30 and then obviously, we’ll get right on the sow. But if any questions come up between now and then, by all means, don’t hesitate to reach out.
Sean Behan (20:30) Sure. I’ve got our legal team standing by so they know they’re going to get something this afternoon.
Bradley Eral (20:35) Perfect. Appreciate you.
Sean Behan (20:36) All right. Thanks so much.
Bradley Eral (20:38) Thanks, Sean. Bye.