If you don't have time to watch the entire digital health tech stack panel recording we've broken down the questions and answers from each panelist.

The main questions covered:

• What do you most regret building vs buying?
• Any frameworks for making the build vs buy decision?
• What does a good analytics stack look like at a virtual care company?
• How do you think about when and how to implement an EHR?
• How do you approach scheduling?
• How do you align the supply of patients with the capacity of clinical?
• Can you think of any pain points for which no good third party solution exists?
• What do you think about asynchronous communications with patients?
• Thoughts on HIPAA compliance?

Panelists Intros

We asked each panelist to introduce themselves and to tell us what their favorite burger topping is (Memorial Day grilling and all).

Alex Cohen

This is the first virtual webinar I've done in two years. I'm our director of product at Carbon Health running our consumer team. I've been with the company now for about a year and a half. Have held a bunch of different roles throughout the last year and a half, everything from building vaccine tooling to internal tools. And now, most recently, the consumer app. I’m based in Austin, Texas, and my favorite burger topping is probably bacon.

Brendan Keeler

I’m the senior product manager at Zus Health based out of Portland, Oregon. For this Memorial day, I was in Frankfurt or near Frankfurt, Germany. So I guess a sausage on top of my burger or just a sausage.

Molly McGrath

Hi, I'm Molly. I am head of product at Allara. We're an early stage startup that provides virtual specialty care for women's chronic conditions. We're based in New York, I'm also based in New York. And favorite topping on a burger or anything is pickles.

Nimish Parikh

Nimish Parikh, I'm with Redesign Health. Redesign Health is a company creation platform. We've got over, I think 300 million in assets under management and we fund ideas, promising ideas in digital health. We spend on a lot of great companies like Calibrate, MedArrive and Uplift. Part of the product team there, which is super fun because I get to bounce around a bunch of different digital startups that we've funded across B2C, B2B. And in terms of hamburgers, love a good beef hamburger. I like blue cheese on my hamburger. I have attempted to cook the blue cheese inside the hamburger meat itself, which if I can pull it off, is really fantastic, but usually epic fail.

Questions

What do you most regret building rather than buying?

What do you most regret building/developing rather than, I'll use the word buying or licensing? What capability, feature service product do you most regret having ever built in your career?

Nimish Parikh

And so my personal career, it's actually an example in diagnostic imaging, which is really niche. I was at a company previously that bought a really old school on-prem diagnostic imaging platform. Hopefully, not many of the other folks here in that example because the on-prem world went to the cloud shortly after and our whole tech stack was outdated, but the one thing I hear a redesign from other founders that we bring in is actually the number of founders that have built their own EMR systems and just the pain and anguish they went through building their own EMR platforms. So it's what I call the digital health paradox where you have so many companies that have products you could license, including EMRs, yet some of the most successful companies in our space like Oak Street, Cityblock, even One Medical have built a lot of their own product stacks and components, so interesting to see that paradox but people that have gone through that work of building an EMR, I think it's a really tough road to go.

Alex Cohen

We have, so we're right in that boat of having built our own EHR from scratch.

I don't think we regret it. I think you just don't realize that it's an entire company in and of itself until you're really in the weeds of building it and so there's a lot more that we can do now that I think we wouldn't be able to do had we had just licensed Athena or Epic or something, but it's been five years so it takes a long time to build a really good EHR.

Yeah. I mean, and we're full stack, right? So we have our own clinicians on staff and providers and they're always asking like, "Why don't you have dot phrases?" And "How come I can't do this?" And so they're used to that old paradigm and we've got our own way of doing things for better or worse.

So I haven't worked on it directly at Carbon just yet, but I would say don't try to reinvent the billing wheel, and I think there's definitely the startup mentality of, "Oh, we could do collections better, we can get billing right if we just do it ourselves." And I think that's probably the biggest thing that we probably should not have brought in-house out of everything. I think EHR, yes, but billing's one of those things where there's a lot of companies that just focus on that, recommend going down that path. And then I would agree with Brendan on analytics. We did a lot of stuff in-house early on in terms of analytics and customer data. It's a lot easier when you could just plug and play with an Amplitude or a Heap and go that way versus trying to save the 3,000 a month or whatever it is.

Molly McGrath

I would say, okay. So I think overall, any company I've been at, a CMS, don't do it unless you are a content company. Everybody thinks they have a reason that's special, like you don't do it. That's probably the one that I regret building twice. And then I think a scheduling system, if you can avoid it, I would recommend not building it. I've done it once. And then we had to rebuild it. So we weren't going to swap something in and I think we could have done that. So I think scheduling anything, we're building the V2 and we're like, "Eh, let's just keep going with what we have." That usually was the wrong decision.

Brendan Keeler

Oh, analytics and data stack stuff. As soon as you start being extracting in bulk or importing in bulk, there's tools for that. And yeah, there's 100 ways to solve it but almost everything is like, let's use something off the shelf, let's use a Fivetran. Well, maybe I'm getting ahead of myself into analytics and such, but moving data within your enterprise can be done more effectively than having your engineers just code bulk stuff.

Any frameworks for making this build versus buy decision?

Now that you've gone through this a couple times, if you were to make this kind of analysis again, what would be the different things you would consider build versus buy?

Nimish Parikh

Oh, yeah. It comes up a lot. And let's start with a little bit of empathy for your startup head of product. It is one of the toughest challenges they're going to face because they're going to make build versus buy decisions. And all of their choices are extremely visible to the entire team and the user base as a startup head of product. And indeed, the success your venture can turn on how that impacts customer acquisition. The other friction point is your clinical team. Your clinical team can get very frustrated with the choices you made as head of product, because they may not understand an MVP mindset. But overall, I'd say if you're going through this process, the first question to ask yourself is what is my venture's core competency? What's our core competency? Because if you are a B2C venture, you are trying to build a compelling consumer user experience.

And that is something you may want to build to just master that yourself and then basically buy all the professional facing components. So number one is ask yourself, what's our core competency? The second is where are we in the product market fit continuum and journey? If you haven't achieved product market fit yet, then as a head of product, your seed is on fire. You are in the spotlight, you have got to achieve product market fit. And that means it's all hands on deck for whatever component of your stack addresses product market fit, everything else can be bought. Companies that are later in that journey where they've achieved product market fit and they're already scaling, you see a lot of those ventures begin to actually bring some things that they bought, they actually start to build retroactively and retrofit either for margin components or just because they want to build out their user experience.

And the last one I would say is ask yourself, where do I have an information advantage? And by that, I mean, where do you have a use case where you actually end up knowing a lot more than the rest of the market? If you are a mental health startup and you do group therapy, you may have an information advantage in building a group therapy EMR. You would know that better than maybe even Epic or Athena or anyone because it's a unique use case. You can build it. But for that same startup, a mental health provider, well, you may think you know a video conferencing software but you probably don't. You're never going to notice as well as Twilio. So you're just never going to have an information advantage over somebody with a scale of Twilio. So those are the kind of the questions. That's the framework, the way I think about it.

Molly McGrath

Yeah. So very triggering to hear all of that, because it's so true. Like I joined Allara in the back of my mind thinking like, we're going to hire a head of engineering and the build versus buy is going to be like, we're going to do it together and we still don't have one. We deprioritized it and it was immediate, making decisions like that. And they're these huge, they feel like earth-shattering. So I feel like the first thing is to make sure you think about how easy would this be to undo. Sometimes, it's not easy at all and sometimes ,it can be super easy, but knowing that is important. And then I think the first thing, it's definitely an art and a science to think through if you should build or buy. I think the first thing to find out, especially if you're zero to one build at a company and you're running product, is understand if you're a tech company or not.

I think that's something that people skip a lot and they're like, "We have to build everything. We need all this IP." And I think there's no shame in that. I'm at a service-based company, the technology enables this service. We are not building software as our core thing, we're delivering care as our really core thing. So we can do that with, like we did that with no code to start. We built, we bought everything, we got people through the process and seeing providers and gave them care and could work on our product market fit without building anything. And then I would just stress that differentiator piece, making sure it's really core to what you need to get product market fit. If it's not, don't try to build it.

And maybe one other thing I would say is I would recommend writing out, not just like we need an EMR, we need analytics, we need this, writing out specifically every single feature you need in there so that you can one, it helps you eliminate bias similar to when you're hiring someone, you would want to write their qualifications before you just start meeting people.

And it also helps gauge the size of the build if you were to build. As you start writing those features, you'll realize how complicated things are and it might help you make a decision there. Those are some of the things I consider. And I think you can do that as an activity to make it feel more framework-y or you can just do it in your own mind, whatever the organization wants you to do.

Brendan Keeler

Yeah. Just to jump in real quick on that and to add on is what we see at Zus, as we talk to specifically virtual first care subset of digital health is a spectrum of build buy decision making. On the one end, you have Alex and Carbon and Ro, and they're just building everything. They need little bespoke things to plug out into the outside world, but they are a tech company and that's fine. At the other end of the spectrum, you have unique care models and you have unique go to markets of like, we're going to go and network and we're going to go and network in this geography. And that's our whole differentiator against other startups in this space. And they may use an EHR plugged into a Salesforce health cloud and just be like, "That's it with my six engineers." So I think the build buy, there's no right answer because it varies so dramatically depending on how you see yourself as a company for virtual first care, for business associates, if it's another beast.

Alex Cohen

Yeah. So I would say, there's a couple of dimensions that we look at that I don't think have been mentioned here just yet. I would say even through the last 18 months as I've been at Carbon and we've grown significantly, the number one most important thing is are we actually providing the care that we say we're going to the patients? And everything else can be broken besides that. And if that's working, then we can fix the duct tape afterwards. As we look at building versus buying, I think that there's an element to, are we actually building this thing custom made from the ground up or are we just using APIs to build a better experience? So I think about, we recently, back in August of last year, went through a really big project to rip out our entire customer support platform across all of our clinics, all of our call centers, all of our care pods, all of our remote workers who were doing customer support.

And we looked at building a custom experience on top of a Twilio or Amazon connect and we ended up going with Talkdesk after all was said and done because they just offered everything out of the box, and it was mentioned earlier but it's not our core competency. We're not a call center company, we're a healthcare company but there was a... One of our differentiators is providing really good customer support and having a customer experience where someone's actually picking up the phone and you're not sitting on hold for hours and hours, but we figured that we could do that with someone who had built everything out of the box versus us trying to reinvent the wheel, even though infrastructure was there. And to give you another example, like today, we use Zoom for our telehealth visits. We could use the Twilio API or that there's a bunch of other APIs for building video chat experiences, but it's just not going to move the needle on the business right now.

I think there's a lot more to do than just build a really nice web experience that you can chat with your provider. Run Zoom right now and it gets the job done. And so I think there's always that dimension. And then when you hit our scale, which is several thousand employees, they've got 120 plus locations, then we start to look at margin expansion. And that really becomes the core driver of one, do we need to fix something that's broken? And then two, how do we do it? Do we build it or do we buy it? I would say in most cases, even these days, we still buy stuff. We just probably build a wrap around those experiences. It leads to more dependencies but again, it's like tasking inside of our EHR, messaging inside of our EHR. Those are built from scratch but then things like customer support and immunization reporting, we can use APIs for doing those things.

What does a good analytics stack look like at a virtual first care company?

Brendan Keeler

Yeah. I mean, I think user tracking and CDP is typically what people think of first and that's why you come and look at Freshpaint, or you get your CDP up, your customer data platform, you pipe that over to a Mixpanel, Amplitude Pendo, whatever. And then after that, you can start to be like, "All right, let me use an ELT, like Fivetran, get more data over to a data warehouse and start to really build things up there." There's an interesting trend now with something like reverse ETL stuff. So out of your warehouse, back into applications, but I think that's of a very high maturity level in your overall analytics stack, like just getting to the point where you have those initial pieces of the CDP, your user analytics, and then warehouse plus operational data via a Fivetran, you can do a lot of fun stuff with that.

Just piping over all the events allows you to see a lot of insights and just being like, "Okay, everyone's clicking on this button and they're dropping off here" and that's huge, right? You can know that there's something wrong, but the why, the exact why is why when you might use a full story to see, "Okay, let me watch exactly where they're hovering or exactly what they're doing." So you can say, "Oh, it's because it doesn't really show up", or diving into that exact person's head isn't possible with a Mixpanel or something. You have to go to that next level. And not everyone has that, not everyone needs a full story but if you're really [inaudible 00:24:50] and you're like, "Where am I losing customers?" Then that's where you might plug that in.

Nimish Parikh

Yeah. And I would say, so just to throw out a plug for analytics as a category, I think anyone that's building out a digital health experience, especially on the B2C front, do not be shocked by the amount of drop off in the apps that we build. It's just it is really difficult to get consumers to stick with these apps. So it's a huge argument for having an analytics step so you can continue to iterate and just build out your platform. So four components, I see a lot in a good analytics stack, at least across our company's, Redesign. The first is the CDP, that's the foundation. It's the invisible glue. A lot of people don't know why they would use a CDP per se, but it is the invisible glue for your entire stack. The options now are better than Google Tag Manager or Google Analytics for that matter on the analytics side. It's worth it.

And then on top of that, you're going to add in the second component, which is your aggregate marketing analytics platform. So an aggregate use Mixpanel, that's going to show you broad data and it's going to give you those compelling flows to understand where your drop off is. So Mixpanel or Amplitude or what have you, everyone's got their preference, but you're going to have an aggregate marketing platform that I think Brendan and Harry just mentioned full story, so that's a third piece is individual marketing analytics platforms that look at a session level and they have really cool techniques, understanding that end of one, as Brandon said, the why, of why people are doing it. And the fourth piece that I'm seeing more, it's really intriguing to me is A/B feature deployment. So feature flagging technology deployed through a company called, like Split.io and some of the others. And I think feature flagging is controversial in the developer community, not everybody loves it, but if you like it, it's really cool to deploy features selectively on an A/B tip basis and actually test out some of your feature functionality to see what works.

How do you think about when and how to implement an EHR?

Molly McGrath

Yeah. So there's definitely a lot of situations where I feel like you don't actually need an EHR. And again, I'm like what are the things you need to be able to do? Is it, I need all my patients or charting or ordering labs or ordering prescriptions? Individually, what are all those things that you're going to need? Are you going to take insurance? Possibly in the next five years, I would even say, maybe have that in the back of your mind? And then I feel if you're never planning to take insurance, you could start already thinking maybe on an EHR. Then if you're not, do it... I talked to somebody recently, they were like, "No insurance, no labs, no prescriptions." And I was like, "Okay, don't buy an EHR. That's like the whole thing.”

If you're just like the charting or whatever, there's really creative ways to get around that. And there's also really cool tools, like five years ago or three years ago, I used Welkin for something that worked really well for a behavioral health startup. And I think there's a lot of options out there that are more close to the use case you want, if you're not going to need the HR features because you don't really want to have to use one. There's not a super... I know we're all talking about this all the time, especially this group, but there's not an amazing headless EHR that everyone's using and it's perfect for digital health. That doesn't exist yet, to my knowledge. And so unless you're going to go back to the early aughts as soon as you open that EHR and you don't want to do that unless you absolutely have to.

Alex Cohen

Yeah. So I don't have a good frame of reference for this because I've never used another EHR. This is my first instant healthcare and so the only experience I really have, besides peeking over my doctor's shoulder when I'm at the doctor and looking at their EHR, I don't have a ton of experience with others but for example, we recently, we're in the process of switching to a regionalization model for customer support and some other supportive tangential teams. We've got a lot of work that has to go into the EHR to support that, like tasking now has to go to groups and messaging now has to go to groups, but the nice thing is we can add custom filters and we can add custom workflows and all these things in a matter of weeks instead of I guess submitting a support or feature request to Epic or someone and saying, "Hey, can you please add this thing? We need it for our workflow."

It's things like that inside of our, what we call the provider app that we've added that I think make it a bit more delightful, like every provider has their own. I don't know if other EHRs have this, but we have this feature called macros and it literally, if you have someone coming in for a chief complaint and you need to do everything from the notes all the way to the prescriptions being filled, labs, follow ups, you just press one of your preset entire care plans and it just does the entire thing for you. And so every provider can have their own, we have company ones that we've created that providers can use. And so I'm sure there's a lot of nuance things that we've built just for our own personal workflows that make things a bit more efficient.

I'd have to go look. I think we've compared after hours charting time between us and other EHRs, and we're significantly less after hours charting time. And it's one of the metrics that we track with the success of the provider app, is just how often are our providers having to use it when they're done seeing a patient or when they're done with their shift and they're catching up on notes. And I'll give you another example. So we recently piloted a vending machine prescription or a prescription vending machine inside one of our clinics in Berkeley where you can literally get your prescription, walk up to the vending machine, type in your name and your, I don't know, two pieces of information. It spits out the prescription for you. That was a half day integration with our EHR to do that instead of having... I don't know what that process would've been with someone else, but I guess we don't ever have to think, can we do it? It's just, how long is it going to take?

How do you approach scheduling?

Brendan Keeler

Yeah. I mean, we see a broad cross section of virtual first care providers. And even though we're not currently pursuing scheduling at Zus, it's a big thick, thorny problem that I wrote this article about recently with Jan-Felix Schneider, because you have things with virtual care that break the assumptions of the built-in scheduling of a lot of legacy EHRs. You have multiple timezones, you have group scheduling, you have weird billing considerations, provider-patient matching, all that plus even just in the world before virtual first care, scheduling was hard. My friend who worked on [inaudible 00:35:16], he had probably the shit module of Epic because it's just painful. Every hospital thinks they're a special, unique case of visit types and scheduling rules because Dr. Smith has to golf on the third Tuesday of every month or whatever, or when the moon is waxing, whatever it might be.

So it's really hard to encode that, and a lot of it lives as tribal knowledge within the scheduler's heads.

How do you align the supply of patients with the capacity of clinical?

Molly McGrath

Yeah. It's definitely challenging, especially when you're first starting out and then all of a sudden, you start scaling faster than your scheduling is scaling. Now, I think that's been probably the most painful scale issue, is balancing scheduling, but we're still using what we used as our first no code. It was in this stack and it's still there, and we connect that through our system, to our EHR so there's a record of that appointment in EHR and that's been working pretty well. I try to keep an eye on stuff. Scheduling is a big one where I'm like, "In three months, this is going to break and we need to plan for when it breaks, what are we doing?"

So we're moving it to another platform that we use for provider management tools. We use Source Health, we love them, and they have just built scheduling and we're thrilled to be able to move over to that. But yeah, that's one downside I think of, like EHR scheduling is always terrible, not even usable. And so off the shelf, EHR scheduling was never an option, which required a second system and then you have to connect them. So there's certain things like that. Scheduling's probably the worst in terms of having to connect it back.

Alex Cohen

I can talk a bit about what we do because that's another thing that we've built end to end. So scheduling's really hard. I think we're on our second iteration, we literally call it scheduling 2.0. It's basically four products in one because you've got scheduling for a virtual primary care, scheduling for virtual urgent care, scheduling for in-clinic primary care and urgent care. And then we have chronic care conditions that those visits are longer because we are also full stack. We support everything in our urgent care clinics. We've got probably thousands of different complaints that we can treat and different conditions. And so then, you've got this weird difference between... Urgent care doesn't really matter who you go see. You want to make an appointment and go into the clinic and someone's going to see you. When you go and you want to visit a primary care doctor, you're selecting them and then you want to visit them on their schedule. And then, so we started with urgent care. We now have primary care.

Also, I don't recommend building scheduling from scratch if there is something that works for this because of all these weird cases, but we started as an urgent care scheduling system with fixed appointment slots. So if you ever went and booked an appointment with Carbon, you can literally choose which provider you're going to see and what time they're available. And then we learned a couple years later that it actually doesn't matter. You should just be able to choose a slot that you wanted. It assigns you to a provider and patients don't really care, but again, for primary care, we have to support this whole idea that you're selecting the person that you're going to see. And then there's other weird things like how do you handle walk-in appointments and know how busy a clinic is at any given point in time to support that on both the patient side to say "I'm here", but then on the provider side or the front desk person to say, "Let me add you to the walk-in schedule and we can see you in 30 minutes."

And the thing that we're now somewhat getting good at is dynamic time slots, depending on the reason for the visit. And now, that's really hard because you come in for one thing, but then you're telling your provider you've got 10 other conditions when you get there that you haven't told us before when you were triage and then schedule starts to roll over. And anyway, so it creates a mess. And same thing with primary care, you're typically coming in to establish care first, but then you've got, again, 10 other things that you haven't talked about with the primary care provider in the last however many number of years.

And so I think we're a little bit unique as well as most of the, I would say the people on this call are unique in that we're all "tech companies" and so we want to give scheduling directly to the consumer, but that obviously is a much different paradigm than what people are used to of calling their primary care doctor and saying, "When can you add me to the schedule?" And they just write you down in a notepad and then you come in two weeks later. So it's hard. I think anyone that undertakes it just needs to really understand why they're bringing it in-house versus using something out of the box and how important it is to get everything right.

Molly McGrath

Oh, there's one other thing I would like throw out there just because I'm thinking about like when I built it, it was at Maven Clinic. Now Allara, we didn't build it but something to consider is also the relationship that a provider and the patient have. If it's a service, they're providing a quick prescription or if it's an ongoing one-on-one relationship, one of the hard things about scheduling, or everything's a hard thing but one of the got yous for us was like, oh, wait, this is a one-on-one relationship and this person needs to repeat schedule with this provider, which means their availability has to be different and the UI will change between their first appointment when they're just picking versus now, it's specific to one provider. And so that's another one, is that model and that relationship changing over time or not is a huge consideration. And stuff like that is really easy to gloss over the first time. And then you're coming back to it in scheduling 2.0 like Alex talked about.

Can you think of any pain points for which no good third party solution exists from what you're seeing?

Nimish Parikh

Yeah. I mean, clearly scheduling has come up in the conversation here, Brendan's written an article about it. I mean, there's acuity, there's a lot of startups going out scheduling space, but having with a lot of EMR is indeed an unmet need. The second I would say is a good headless EMR that has good specialty feature functionality built out. So I mean, there's a lot of players in the EMR PCP space, elation and others, a bevy of them but a headless one that actually has functionality built out to the point of epic would be fantastic. And I think Canvas wants to get in that direction, but right now, there's such a gap. EMRs are just, you pick your EMR vendor and then you get your clinical team on the EMR and then all the pain begins because no one's ever happy with what you found, but those are two I would point out.

Brendan Keeler

I mean, I think there's a whole host of networks to be built in healthcare that need to exist. Right? We have some nascent like data exchange and E-prescribing obviously is ubiquitous, but referrals, plug and play labs, yeah. The solutions out there are slapping tape, you know that meme of the guy slapping tape on the water gushing out, it's like that. Yeah. And when I daydream about what needs to be built, what should I go build? Those networks speak to me.

Alex Cohen

And so one of those is doing credentialing in licensing management for payers and providers are called CertifyOS. We've invested in butterfly labs, which was doing white-labeled APIs or white-labeled home test kits via APIs. We've invested in Imaging Panda, which is trying to fix referrals and sending referrals via APIs and referral management, which is actually a really... That's probably my number one answer here for things that we still struggle to manage with. And there isn't a tool for it yet, is referral management to all these different specialists with up-to-date practice data and in a way where we close the loop. So very keen on solving a lot of these really niche, plumbing problems in digital health that I think, we've just had to either use a mix of Google sheets and Airtable and no-code tools or I've had to build it in-house because it doesn't exist.

Molly McGrath

Yeah. I think I know they exist. I haven't seen one that's amazing yet, but I might not know about them, is specifically eligibility stuff. It seems like most eligibility stuff, when it's modern, like for insurance is more of a wrapper on, but I don't know anyone who's really trying to push the envelope technically on that front. But if you know any, please let me know of them. And then the other one is probably like, I love admin tools, like affordable admin tools are really hard to find, especially for healthcare, self hosting them and especially if you're seed stage is really tricky. And so I would love a more modular admin tool that would let us visualize our data and manipulate it in a cool way. Those are probably my two that I think a lot about.

What do you think about asynchronous communications?

Nimish Parikh

‍
Just having used Crossover Health's platform as a patient, absolutely love the asynchronous care experience that they had, I love this topic. I think what Memorial Health offers, if folks have seen it as really intriguing, like chat bots, intelligence linked up with an SMS functionality. So if you can link the patient with a very intelligent engine that can help triage some of that data, that's intriguing.

Alex Cohen

Yeah. I mean, again, another thing that we've built, we've got asynchronous messaging for patient, I mean, and it's real time if there's a provider inside the message thread, but I will say we've done a lot with chat bots inside the app since the beginning of Carbon. I don't recommend going the chat bot path for triaging and collecting information. Everyone wants to build a delightful lemonade experience, but we have to collect way more information than lemonade does. So it's not as fun for patients as it first seems when you're thinking about doing it but then to second the point on SMS, building as many delightful SMS-based experiences I think is something that I wish we would've done a lot earlier on. Everyone's got a phone, no one wants to download an app.

There are a lot of ways that you can get away with sending things that we used to consider PHI that only can live inside of an app that we can now do via SMS as long as we get the proper consent. Highly recommend building a really good text experience with even deep linking into records, for example, behind a couple of different patient identifiable pieces of information. So I would focus a lot on what's the lowest common denominator that every single person has, and it literally is a phone these days. It's not your app.

Nimish Parikh

Just to add on to Alex's point, I've been blown away by what people can accomplish with SMS and browser, mobile browsers with no app. People are going app-less in a super impressive way these days, with just chat you the link, SMS, it goes to your mobile browser and you get an amazing experience without downloading it.

Do you want to riff on HIPAA compliant tools, HIPAA compliance BAAs, what considerations need to be in there?

Brendan Keeler

Well, less, it was actually a Twitter thread where I just went through and ranked whether they're HIPAA compliant or not and whether they actually mentioned healthcare at all. I think [inaudible 00:51:29], they're building for a number of industries. They don't know healthcare. Maybe they start to dabble and they see HIPAA and they're like, "Oh, holy shit, should I do this?" So step one, for all these tools is to say like, "Don't send us your PHI." And it's like, "All right. Well, you're useless then" but you still see that. Full story, I think their solution is mark the elements you don't want to go through our servers and then that's their solution. I don't think they signed BAAs, but maybe someone else has used them more closely, but yeah. And then you have stage two, this reluctant relief where they realize they really want to sell them to healthcare, they need to add those features and spend some calories.

And Twilio, I think, was doing this a year ago, or maybe they're still doing it and spending $40 million to go fully HIPAA compliant or HITRUST compliant. So it's a big effort, but the more mature, generalized tooling is working their way over there and signing BAAs or building in the features. And you can look at, Freshpaint is a great example of a company that's like, "Oh, we have this cool little toggle to turn off sending HIPAA data if some of your downstream sources don't support BAAs yet, don't support HIPAA so they can help you overcome some of the limitations of more generic tooling" but still battle. People are just like, "Ah, I'll just go sell to E-commerce. It's easier."

Alex Cohen

Yeah. I mean, we do sign a BAA with everyone, although we decide what data we want to share, like very explicitly define what data... For example, I don't think anyone really needs to have individual session data for what an individual patient is doing inside of an app. I'm not really sure how that helps you. An aggregate view is definitely interesting to see where people are dropping off, but I don't really care that one person clicked into the labs page and then tapped on a lab. And if it crashes, we have Bugsnag for that. We'll determine when the app crashes in different places that way. And then on the aggregate level, you really don't need that much PHI or any PHI, and that's what we realized when we were doing instrumentation and analytics at least, was in theory, we really didn't need a BAA.

We weren't sending anything to them that if anyone, like a worst case scenario, someone hacked in the Amplitude and got access to all the stuff that we're sending, there's nothing identifiable in there, everything's anonymized. And so I think being really mindful of that, and at the end of the day, the BAA is just to protect, I think, your company in the event of litigation and if something gets breached or whatever, but if you're following best practices, I almost find that you don't need to share PHI outside of your own systems for the majority of things that you're doing.

‍