HackED! Design Speaker Software Solution Acute Care Problems

- Okay, everybody, thank you for tuning in. We are so excited for the beginning of our virtual design speaker series for this year's HackED. As we mentioned in the past or prior the this year's HackED is going to be divided into two tracks of software versus hardware. We have amazing speakers, leaders in innovation, in emergency medicine and acute care who are going to be telling us or giving us very highly yield tips and important information for how to develop your concepts into the beginnings of a solution and startup, whether it's in software or hardware. A lot of these, or most of the videos that we're going to be doing, are going to be edited and then posted on our website for you to review them later during the hackathon, we're also going to have the high yield notes or bullet points that summarize the talks so that you can refer to them as you're refining your prototypes. We'll also have some contact information for our speakers if you wanna reach out to them and ask them some specific questions about things that they mentioned, or if there were parts that you want a bit more clarification on, we'll also have our contact information available for you to reach out to us. So to kick off, we have Dr. Kathy Chae. She's an emergency medicine physician, entrepreneur and is the CEO and founder of CyrenCare, a patient engagement platform designed for the emergency room. Kathy's clinical career began with training in Seoul, South Korea, where she became an assistant professor at Ajou University with a focus on postcardiac arrest care. During her time there, she led multiple initiatives to innovate within the clinical environment. These included integrating text message referrals into the hospital's EMR, so that ED physicians did not have to call specialists to make those referrals. As ED waiting room times increase around the world, and particularly in the United States during the COVID pandemic, Kathy tackled this problem head on by founding CyrenCare. CyrenCare collects data on symptoms directly from patients and translates responses into a clinical report in the EMR. This serves their approved physician workflow. She'll be speaking now on how to build a software solution for an acute care problem and her experience building CyrenCare. Thank you so much for joining Kathy today.

- Thank you so much for the introduction. I'm really excited to talk today because you know, emergency medicine innovation, both are things that really excite me, and I really thank you for the opportunity to share our journey with CyrenCare. So without further ado, just adjust my screens a bit. Sorry about that. So, well, first of all, congratulations on your first step towards innovation, and I'd like to talk about what you do after you have an idea. And after that, I'd like to walk you through the steps of CyrenCare. And to start, I have a huge conflict of interest that's CyrenCare, but I'm gonna mention a lot of vendors that I don't have any conflict of interest with as well. But with CyrenCare, if you come to ACEP, please stop by Booth 1010 and say hi. And I was going to touch about my background, but Zay gave me a great introduction. But just to kind of reiterate that, I'm a 1.25 Gen Korean immigrant because I have that 0.25 in my childhood growing up in the US. But I spent my adulthood in Korea and came to the US in 2022, started CyrenCare in 2023. Prior to coming and starting CyrenCare after medical school, I went into architecture and design after I became a doctor. A bit unconventional, but I think I always loved building and being creative and solving problems, et cetera. Then Lehman Brothers happened, and I came back to Korea and went into emergency medicine, became a professor. And while I was a professor, as they mentioned, I launched an internal system where we were doing consultations differently. So instead of calling other specialties, we would send out a message through the EHR that would be a text message leak to have that consultation done. And that experience really shaped the way that I was thinking about things. And really it was a rewarding experience that I think was a big factor for me to start CyrenCare. Additionally, I co-owned and invested in a Korean barbecue restaurant. That was my first taste of entrepreneurship, also shaped a lot of the ways that I thought about things. And then I went into digital health and Cyren was actually a graduate school project, and I was able to do a pilot study at Samsung Medical Center with it. And I liked the results of the study and wanted to take it further, but the Korean market was just too small. When by chance we came to the United States. So I always say the stars were aligned for it. I think in medical school and becoming a doctor, I felt, at least for me, the path was pretty straightforward. You study hard, get good grades, do well, and you're pretty well set. Whereas in the startup world and a lot of other different industries, every path is different and every process is different because every project is different. And what you want in terms of outcome is really different. So some things that you might wanna ask yourself before you decide how to build your product or how you wanna structure a company is like, do you wanna go the venture route or not? What type of business is it? Do you need FDA approval? Is it service heavy? Is it tech heavy? And kind of think about these things before the route you know, you take and build out things. And I say this because every process is different. And what I'm going to share in the contents around CyrenCare is just one startup's journey. So please take everything with a grain of salt and think about things in your own context and what you're gonna take or leave. And while every startup is different, two things are the same for most startups, you have to be profitable, so you need to make money. Second, you will have limited resources to do so, so you don't have a lot of time and money, but you have to make money. And because of that, instead of going from idea to just building, you might wanna validate your idea first before you build. So there's a saying in the startup world, like, don't make a solution and search for a problem. So you really wanna validate that this is actually a big need and people might be even willing to pay money for it before you start building out your idea. So for example, machine learning is cool. You have data, you can build an awesome algorithm, build, you might wanna step back a bit, see if there is really pressing need for this, and if people will be willing to pay money for it. And in terms of validating, there are a couple ways you can do research. You can observe where your product is going to be used with a fresh eye because you know, even if you're observing it within your workspace, you only know what you know within your role. But if your product is going to be used by patients, triage nurses, other stakeholders you might wanna observe with a fresh eye, then another way to do it is interviewing people. But when you're interviewing, be aware that you're not asking it in a biased way. So for instance, don't ask people that are close to you, show them the solution and ask what they think about it because they wanna be nice to you. You're probably not gonna get the truth. So if you have the time, if you can read up the Mom test before you start those interviews, it'll help you ask the questions better. And that's how I did my interviews as well. After I read the Mom test, I would always start with, you know, what does your shift look like? What are the pressing problems in the shift? And based on the answers that I get, I'd ask more questions to see if this is the problem that's actually the problem, and if the solution that I'm thinking it would actually be the solution for that problem. And I think there are some specific things to healthcare that makes it a lot more tougher than other industries. One thing being is that your users are going to be super busy. So couple of things that I feel are a bit different in healthcare within the startup bucket, and that makes it a bit tougher. I'm not saying this to discourage you, but if you acknowledge this and if you're having a tough time, you'll be reassured that it's just tough. Another thing when talking to users is kind of acknowledging the fact that we are in an industry that is really risk averse, conservative, slow and complex. And we probably have a lot of late laggards here. So while you're trying to collect information, even if there are a lot of naysayers, don't always turn around and be discouraged, but kind of think about why they're saying no. And think of if there's anything more to it, and try to get some information around that. And the reason why I'm saying this is based on my experience of launching that, the consultation system internally, when we were first planning for it, there are a lot of opposing stakeholders, a lot, and we had to just kind of push forward and launch it. But after a week or two and after all the bugs were fixed, it changed the way everybody worked and there was no turning back. So you kind of have to, this is a dangerous bias, but sometimes it might be the fact that they don't know what they want, but actually it's something that they really need. And some people talk about the iPhone as an analogy, like before the iPhone came out, if someone said that, do you think you need a phone with a big screen? I don't know how many people would think that they would need it, but now nobody can go back, right? So the second common thing, limited time and money. So as a startup, you will have limited time and money. And because of that, a lot of startups try to go in this bucket where they have to build cheap and quick, but sacrifice the quality of things. And the project management triangle basically says that you can't have all three, so you have to sacrifice something. But the thing with healthcare is that when you're sacrificing the quality too much, you might affect patient's safety. So we can't really move fast and break things, we'll have to kind of balance things out. So we do no harm. So that's another thing to think about, which means that, you know, compared to other industries, we might be more slower to build or we might be more expensive to build. And I'm not gonna show you this video itself, but if you don't know Y Combinator, YC, there's a lot of content. They have a startup school on it. So if you wanna read more about building your MVP, there's a lot of good resources there. So I recommend to go look in there, but you want to start with an MVP, minimum viable product, which is self descriptive. So you wanna start with something small that has the essential features for your solution to the problem and launch quickly, iterate, talk to users, iterate, and your MVP will change a lot. But the tough thing about healthcare is, so in this video they say get customers, but getting customers is going to be super tough because a lot of red tape, long sales cycle and then your users might love you, but then the decision makers might be different people. So you have to navigate all of that. But let's say you validated the idea and you have a good plan of how you wanna build your MVP. So what are your options now? You kind of wanna think if you wanna go the co-founder route or the solo founder route. And it would probably depend on like what you're building. If you're a health tech business with a big tech component to it, you would probably wanna get a tech co-founder. But if not, if it's like a service heavy business, you might be able to pull it off with by being a solopreneur. But if you don't have a co-founder, or if you're looking for one and haven't found one yet, these are the couple of options that you can take. If you can build one yourself, that's great, definitely go down that route. But if you can't like me, there are, these are some of the options. So you can prototype with some no code tools. So these are some of the vendors, I haven't used all of them, but some are good for building websites. Some are no code tools for building apps or simple like wire framing tools. I had a friend that built a no-code app with Adalo, but these are some of the resources that are out there. And Figma is also a good resource where you can kind of put together an interactive prototype. There is a bit of a learning curve. And if it's too much for you, you can always start with fig jam, which is much more easier. You can just search for a template like prototype template and you can get these templates to get you started. And also they have a lot of great templates for product management if you want to get some resources there as well. And the right reason that I recommend Figma is because it's something that you'll probably actually use down the road when you're working with your developer and designer as well. And then there's an option to buy. And this buy versus build will be a question, even if you have a co-founder, sometimes it's a better choice to just kind of buy what's out there and put it together instead of trying to build everything from ground up. And these are some of the resources on the left, you have some form builders or headless EHRs. So if you're a service oriented company, you might want to consider a headless EHR instead of trying to build an EHR from ground up yourself. And on the right it's a site called Ellion, which you can think of as a shopping mall for the options that you can buy. So under each category, they list all the vendors that are there. And this is also a good resource if you want to put together a competition deck on your pitch deck as well. Then there's the option to hire an agency or freelancers and which is a good option in some cases, but you probably want to have everything pretty much planned out and iteration is going to cost money. So probably after you have a good idea of what you wanna build, whether it's with a no-code tools or after user testing. And one thing with the freelancers, the common sites to find freelancers is Upwork and Fiverr, but there will be some variations in the talent. So if you can get any recommendations or any tech front to help validate that might be helpful as well. But I went down the co-founder route, so if you're like me, and you wanna go down to the co-founder route, you will kind of run into a chicken and egg problem where you don't have much to offer, but you wanna find great talent to join your team. Without that talent, you don't have a product. Without a product, you don't have traction. Without traction, you can't get any investment, so you don't have any money, so you don't have much to offer. And you have this chicken and egg problem that you have to kind of break free from and you have so little to offer, but you don't wanna compromise. You wanna find someone that's really proficient and perfect as a founder, but you don't have anything to offer but the dream, right? And finding a co-founder can take months. So what I recommend is try to develop your idea, you know, with the market research, the user testing, just drawing up screens as much as you can develop this and try to find a co-founder in parallel. And the better you can sell your dream, the better chance you'll find good talent. And where to find a co-founder. So there are multiple platforms, but I like Y Combinator, I use the matchmaking, the co-founder matching platforms to find my co-founders because there's a great pool of people and they put the service up together. So you basically put your information, what you're looking for on your profile and you see other founders, if you like them, they like you back, it's a match and you get to meet and you can meet a lot of people. It's like 20 meetings, 20 likes in a week. So if you're really active on it, you can go through a lot of people, a lot of profiles and meet a lot of great people. And when you're looking, again, this is so important, try to read up on it on Y Combinator, if you can, but I really believe that the person is more important than the idea itself. So if you find a great partner, the synergy will be great. So it's the most important thing to be able to have a partner and to take off with what you have. It's just super critical. So really invest your time at energy into finding the right person that you can get along with, communicate well, very proficient, and you should have a really high bar for it, so just settling won't do. So don't try to find some engineer that can just build it and give them a big chunk of equity as a co-founder, but be really, really picky in this process. And once you found the co-founder recommendations is going through the questionnaire so that you can see how your expectations meet if your core values align and have a work trial before committing to see like if the fit, the communication is going well. And you're probably going to talk about equity splits. So the norm is 50/50 with a cliff, which means that for a cliff and a vesting period, the norm is a one year cliff and four year vesting periods, although there are variations, cliff, meaning that nobody will get equity until a year passed if your cliff is one year and then four year investing period, that you'll get the rest of the equity over the remaining of the four years and it prevents anyone from taking a big chunk of equity and quitting early on. But these are the frameworks that a lot of people have in place. And Y Combinator recommends the equal split for many good reasons because you're looking for a real partner that will really contribute to the future of your company. So, bad reasons not to split equally is that I've came up with the idea, I've worked on this for six months, one year, therefore I should have 80 and you should have 20. These are bad reasons because early on what you've worked on is great, but it's very small compared to what you will do in the future. So you might wanna have that way of thinking, but this is just something that Y Combinator recommends. And while a lot of people might go with it, what I personally think is that everybody should feel that it's fair. So do what you and your co-founder agree upon. And Carta is a cap table platform. It shows that only 41% have equal split. So you don't have to be pressured to go with this framework, but do what feels fair. And then what I personally think is like when you're meeting a lot of potential co-founders, you'll come across a lot of people. Some people will be like fractional CTOs and they're on the co-founder platform, et cetera. What you don't want is an employee. So you shouldn't have to tell them what to do and they shouldn't expect for you to have everything figured out. And this is my personal thing, but you know, you're finding someone to build the company together and I personally prefer a hands-on person rather than a manager. So you'll come across some people that are like, I know a lot of great offshore engineers that I can, you know, work with and I can orchestrate things, but I personally prefer a builder hands-on person as my partner as well. And for fractional people, I am not saying that it's not an option, but if you are going to go down that route, I probably wouldn't give a whole lot of equity for someone that's not going to be around in the company a year or two later down the road. So equity is for the future is just what I wanted to say. And with that, should we answer any questions for the former part? Or should we just go through the whole thing and then entertain any questions, do you think?

- I think it's okay to, we'll do the questions at the end. If that's okay.

- So with that, I'm gonna just give you a walkthrough of how we built CyrenCare. So I had the idea back in Korea in graduate school and after the idea I was planning for a pilot study. The idea kind of started like this, you know, in the emergency department, we really wanna provide compassionate care, but the reality is that the circumstances aren't, you know, optimal to do that. And this is a worldwide problem. Patients can't make appointments to come. So there's a big mismatch in supply and demand. You never know how many, how severe patients are gonna come in. Limited number of healthcare providers and beds are struggling to take care of these patients and these patients are waiting for hours and hours and this is a waste of time. Whereas healthcare providers we're multitasking, we don't have enough time. So the idea was what if we use this waiting time to help lift the burden for healthcare providers in collecting and documenting information. And from that I went to the waiting room and triage with fresh eyes. This was where I trained, so I knew everything I thought, but that was only within my role. But I was observing how people were doing things, what the patients were doing, what the triage nurses were doing, and what was happening out there. I just sit there for like three hours, three times a couple of hours each and these early observations really kind of shaped what I provided answers when someone asks questions to this day and I realized, you know, the boarding problem, it's a physical problem and having a software won't solve a problem for a patient that's been waiting for eight hours for a bed. But you know, when you think of the mirror in the elevator approach, you can make an elevator so fast, but you can put a mirror in the elevator so that the rider can engage with the mirror to kind of help that time go by. And there's gonna be a lot of limitations in use, whether it be pain severity or digital literacy. So we can't mandate it for everyone. And when you think of who it will be more beneficial of and what patient population it would help the throughput with is the more or less severe patient population. So that kind of defines the goals that, we're not trying to do this for everyone, but for the patients that can, if we can shave off a couple of minutes there, the healthcare providers can better allocate their time toward the patients that need that time. Another thing was there was a bit of credibility issues from the provider side of receiving this patient provided information. And it's not because, you know, it's not because of worrying about patients lying so much, but it's more of, you know, the difference in, there's a discrepancy in the definition of terms between patients and providers. So for instance, dizziness can mean many things for patients, whereas, you know, providers, it's, you think of neurological symptoms, et cetera. So it can't be a complete alternative. So just kind of acknowledging the limitations of that and there's already a lot of information that they have to see, so can't try not to worsen the workflow or a couple of limitations and goals that I acknowledged over the observation. And we built the prototype for the pilot and initially I over-planned everything. If I knew what I knew now, I wouldn't have but later narrowed down to just abdominal symptoms. And it was barely functioning. The usability was terrible because of the limited resources that we had, but it was fine. We aimed to test the feasibility and acceptability of this new type of patient experience focusing on the patients. And we looked at if they were able to complete it, the time it took and where they got stuck. So we had a lot of insight of where we needed to improve in this process. I was basically observing them while they were using it so I would understand where they got stuck and we looked at the acceptability. So the blue is the positive and you can see in the relative advantage the patients had a lot of positive responses in terms of the relative advantage and other parts as well. And the interviews for the both side also, you know, gave us a lot of information. And what was really commonly brought up by patients was that they were almost relieved that they were able to organize their symptoms before encountering a white coat physician and it almost like preconditions them. So that was something that we heard frequently, but you know, it's good to focus on the negative responses to see how we can make it better and really confirmed what we observed in the early observations is, you know, it can't be an alternative for medical history taking. And the patient feedback really helped us shape how we asked the questions in our next version. After the pilot study, I kind of mentioned earlier, by chance I came to the United States and the market was bigger and after a couple months, I decided to take it further. So I did two things. I did the US market research and the co-founder hunt and I talked to people in my network, one being a CMO and one person that was in charge of documentation, a vice chair of documentation within the emergency department. And by talking to them, I realized that okay, this thing, I wanted to help the patients and providers, but how can I sell it? And things that came up was that the documentation was linked to the coding and billing system in 2023. There were a lot of major changes, one being that social determinants of health becoming a part of it. So we can capture social determinants of health information, screen it and put it in a way that would be really easy to document it and make improve the documents for better reimbursement. Another thing was a key KPI was left without being seen, right? So we generated an ROI calculator, this is on our website today, both are on our website today. And what I wanted to say is like even before I started my company, this market research is still like a big part of the value proposition that we have on our website today. And in parallel, I looked for a co-founder and it's very much like finding the significant other with a lot of horrible dating stories involved. And like some have commitment issues, some are two timers, some are manager types and stuff like that. So a lot of bad dates to a point that I had to take breaks in between. So altogether I think it was like a six month process, I thought I had a co-founder, but he left after the trial. A startup kind of proposed $7 million worth of stock options and I can compete with that. But anyways, eventually after six months I found a co-founder, and you can't really time box this, the co-founder kind of has to come to you, but try to enjoy it because you still meet a lot of co people. But yeah, so with the co-founder, we were starting to build and improving the Korean version that we had so that we have free text for chief complaints, expand the questionnaire, collect social determinants of health, and we had this demo to kind of display our idea of what we wanna do. So on the left we ask questions in patient language and on the right you can see how it translates to clinical context and so forth. So we had this thing where we didn't have the backend yet, we just had the front end and we had that demo and we were just talking to people, more and more people and we had to build out the provider side because we only had the patient side for the Korean prototype. So this is like, to show you how basic it all started, it was just like a PowerPoint drawing. And then we built a prototype just with just the front end based on that. And the intention was to get feedback from healthcare providers to figure out what we wanted to build out in the backend before fully building it out. And you can see here that just gonna make it a bit faster. But so we talked to a lot of providers, we had a couple of functions here on the front end, for instance, you can, after talking to a patient with the information that they provided, you can make edits to the note, you can change the ROOS and you can generate a descriptive report based on that. And we took this demo and we talked to a lot of healthcare providers to get a good idea of like what they would use more versus less and what we, you know, there are a couple ways that you can use it to have medical history taking support, documentation support. And we had a mobile version that you can kind of see while you were seeing multiple patients. And while the collecting information was generically a lot of people was going to use it, the documentation, a lot of people mentioned that they dictate their notes and it doesn't take a whole lot of time to dictate, so they probably wouldn't use it as much. And also, you know, a lot of AI scribes coming on the rise. So we deprioritized the documenting function and the mobile version. Some people mentioned that they have a mobile workstation, they don't feel comfortable looking at their phones while encountering patients, et cetera. So we deprioritized that as well. Not to put it off our backlog, but just to rearrange the priority of what we wanted to focus on first versus later. And then we visited three hospitals and looked at the workflows and three different hospitals had three different workflows, different sequences of asking questions, different roles and responsibilities. And we kind of knew, but we confirmed that we can't make this perfect generic one questionnaire and have it fit to every emergency department. And we had to make it in a way that it's scalable, but we can customize it. So we needed a no code tool to really customize everything, the questionnaire and the report that it was generating. And based on that we made the editor. So if you've ever had experience using REDCap, you know, you customize a lot of things to collect information for your research just like that with a little bit of education, anyone can generate this questionnaire and the report that it would have as an output. And by doing this we can expand the use case of if, you know someone wanted to use it for research purposes or satisfaction surveys, it would be super easy for anybody to just put together anything and make edits to the existing questionnaires as well. So after we went through all the requirements, now we were building the backend and, you know, building everything and we wanted to figure out what are the must haves and what are the nice to haves. So we kind of looked at, okay, we have a patient side, we have a provider side, what are the must haves for the patient side and what are the must have features for the provider side? And on the right you can see the purple line and above the purple line was the must haves and the under the purple line are the nice to haves so that we can prioritize among a lot of the features that we wanna build out. What do we really need for the MVP? And with our business plan, the objective and key results for the business. So what is our business for this half year or this quarter? Okay, we wanna successfully launch the MVP and what does success look like in key results? So we wanna get design partners, we want a wait list signup and one paying customer by a certain period. And based on this business objective and key results, we can put together sprints of like and time box things of when we wanna get something done by a certain date. And while we were building the backend, we also refined the contents of CyrenCare contents, meaning the clinical contents by circulating the complex symptom trees to other emergency medicine experts to validate it. It was built based on the textbooks, but you know, have other people look at the questionnaire to see if there was anything to add or take away. And the second content was around the patient language. So had we had a patient literacy expert look at the patient language, make sure it was easy, understandable, et cetera. And we had to be HIPAA compliant. And while there are a couple vendors out there, this one was a very lean, affordable one. So I recommend it if you are a very early stage startup and looking for a lean option. And we did the branding. So branding and design makes it definitely look better and much more like a product. So this was done and then we had a problem where, you know, you need to integrate for this to really work and stick to the workflow. And integration isn't so much of a technological problem, it's more of an administrative problem and no matter how well you integrate it is going to take time and heavy lifting from the IT team. And because of that, we started with, we made a widget so that any emergency department can test the proof of concept without any heavy lifting from the IT team, but test the utility before while we're doing integration because it's gonna take time and this is a good way to see, see the utility, test, the proof of concept, but also figure out what parts of the reports you want in your EMR and experience that. And it would hover above the EMR system so you wouldn't have to jump around pages, but just click it to open it up and click it to make it disappear. And I can show you a video of what I mean by that. So this was our MVP. So we would ask questions around the symptoms and past medical history. So the design and the usability was much better than our previous prototypes. As we did iterations and worked through it, we added body selectors and that this is what it would look like on the provider side. So it can either be in a mobile version or a website and it would translate the answers into clinical terminology. And this is the widget, so you can have it pop up above your EMR system, look at the contents. If you want a specific part of it within your free text, you can with one click, just have it shipped into your EMR and remember that you can customize any parts of the report so that it really mirrors how you wanna document things if you wanted to use that function. And with that, we had our de last year at ACEP, so just, the upcoming ACEP is like, we're gonna be there again. But last year was when we took our MVP to booth and we had our debut and we had people experience it and see the response and we closed our first hospital two months post-launch from someone that we met at the booth. So everything was going great, right? Then two weeks prior to our deployment, my co-founder said that he wanted to leave because healthcare was slow, complex, and conservative. And I'm not going to go into the details, but that was what he cited as his reason of departure. So I became, I had a first customer with all the agreements signed, but I was a solopreneur. So yeah, things take interesting turns very unexpectedly, but I think that's kind of the fun of it almost. And as a solopreneur, I went out there and met the staff and, you know, observed their workflow and came back with requirements that while I was looking for a new co-founder in parallel. So I really looked at the workflow, how things were being done and how I should configure the CyrenCare questionnaire to really mirror they're actually doing. And I realized that there are, I came back with some requirements too. So there are a lot of dynamics in the bottlenecks and how, you know, sometimes the way to triage is short, sometimes it's long. And so we have to kind of play with those dynamic conditions and that onboarding patients could be a challenge. But the best way to onboard it for patients it looked like was to help the register so that the patients would onboard when they're registering and to enable to help the register, we would want to help them obtain consent forms and get insurance information when needed because that would occur after intel, et cetera. So we had some requirements that would really help CyrenCare stick to the workflow with their first customer. And in parallel I looked for the next co co-founder. So this time I had more requirements, I was already picky, but now I was looking for someone with grit. And a lot of people in startup, the startup ecosystem have expectations that it should be like a rocket and grow fast, which is true to some part, but maybe not like the best for healthcare. And I was kind of looking at the background experience, not necessarily in healthcare, but B2B experience helps and maybe something similar to a culture with healthcare would help. And after going through 600 profiles on YC, having over 40 meetings over two months, I found a great person, a great communicator, but someone with great experience as well that and really helped us reinforce our team. So with that, we were able to build out the things that I came back with as requirements. So for instance, we would collect the phone number of the patients during the questionnaire and use the texting platform for the healthcare providers to ask additional questions that they needed to collect and that we can use that to not only ask additional questions, but inform them to come to the triage, help the register collect the insurance forms after triage for intella and send discharge resources to inform them about their condition. But really, you know, sending them additional questionnaires, I feel like it's, think that's really distinctive to the needs of the emergency department. So a lot of times when you come back to your computer start document but realize that you didn't ask the pharmacy information, you have to go back, look for the patient, call for them, they're in the restroom, you get interrupted three times on your way back, sit down to document and you just lose a lot of minutes there. So instead of doing that, you can generate a question, send it over, it auto translates to their language, they answer in their language, auto translates back and you get it all without leaving your workstation. So it's an asynchronous way of getting further information that you need based on the information that you have and collecting information from independent historians, which is also part of the billing and coding system, as well as to really stick to the workflow and not bombard everybody with information that they don't need. Configure the reports differently by each role so that register has information that they need for register and triage needs information for triage. So if they're using dot messages, we can customize it so that it mirrors their dot messages, but auto-populates the answers that the patients provided, et cetera. And yeah, that's our journey. I feel like that was a pretty lengthy talk, but I guess I was just really excited to share everything that I know up until this point. So if that would be useful for any of you in your journey and if you want to try out CyrenCare and experience it yourself. I'm gonna entertain questions because I feel like we don't have a whole lot of time left, but while I'm doing so feel free to try it yourself with this QR code and at the end you can, first you'll experience the patient side at the end you'll experience the provider side, but yes.

- Oh Kathy, that was really great. Thank you so much. Quite a few like really important points I think when you're starting out with your solution. The Mom test, incredible book, big fan, it's very surprising how you'd be leading your customers just by the way you talk to them. And being able to almost trick you to answer the questions you want is great. It also gives you, it really teaches you about self restraint, how to not talk about your idea for 45 minutes. The co-founder matching tool is great. I found my co-founder through that as well. I actually ran into your profile when I was looking for co-founders, but my, I was focusing on hardware, so that's why I didn't reach out. One thing that I really liked was the importance of flexibility. Knowing how to pivot, just being able to zero in on the social determinants of health is huge. Teaches you the importance of not thinking like, okay, I had this problem that I started with and you really need to stick to it no matter what. No, you need to understand what the market is telling you and where you can use your things to your advantage. Couple things I wanted to ask, I had a couple of questions. One thing was, I was gonna ask you to share a horror story, but I don't think it gets worse than losing your co-founder.

- A week before deployment.

- Right. Yeah. So I think we covered that. So can we mention, if you don't mind asking, if you don't mind sharing more about like how you found your first customer, I know it was at ACEP, were you targeting more, like during your, I guess spiel to customers, were you looking more for people who are academic based versus community based? Did you think like, okay, I need to go for somebody who will believe in me more, so I need somewhere where there is a bit more leeway for providers to influence decision makers? Or did you think that, you know, smaller customers might be better? How did you frame that in your mind?

- So to be honest, like, because it was our first time getting out there, I didn't know like what to expect and like, I don't think we were even targeting anyone. We just, like, we wanted feedback because we just built this thing and we wanted to see the response. We were, we weren't even sure if the response would be good or not. And that's what we wanted to test out first. And then second of all, we wanted to test out, you know, we're showing these features, are the participants going to come up with things that they wanna see or need? And if so we wanted to capture that to get a better idea of what we need to build next and reprioritize our backlog. So it was kind of a naive approach where we were kind of wanting to get feedback around our product and how to navigate with the next steps in our product rather than being super focused on sales. I do it a bit differently now, but by chance our first customer or we met our champion there, he was the CMO of a very small hospital emergency medicine physician and I think, you know, in that curve of the laggards and was a very rare like early adopter. And so after that experience, I think I realized that we did have a vague idea that okay, enterprise level hospitals are going to be really slow and have a long sales cycle, but it really confirmed that, okay, this is our ideal customer profile. We wanna target small to medium sized emergency departments with long left without being seen rates with bad left, without being seen rates and look for key decision makers there to, and that would be our sweet spot is what we figured after we got lucky and met our first champion.

- Very cool. And you mentioned the left without being seen, a lot of what startups try to do is demonstrate their value proposition and you did have that in that landing page or that page that told you you can put in your information there. Do your customers follow that up later and then by like saying, okay, how do we prove that we're actually getting the things we want? Or is it a initial proposition that they see and they like and it's more of an emotional decision where they say, yeah, you know what, I think this, this works for us.

- So it's really, really tough to sell to hospitals. So a lot of people, I guess one of their first questions is, do you have data around this? And because we are so early on, we actually don't have that in hand, although we have that, you know, agreement and upcoming deployment and stuff like that. So what, as an early, you know, early early company, what we can do is we're looking for partnerships rather than to just sell something to you. And so what, what a partnership means is that we really wanna solve this problem with you and we would set goals together and make sure that we're meeting those goals together and in exchange for that data and to really see if we can set meet those goals together, we would offer a big discount. And that's what like a design partnership would mean. So the goal is to actually find design partners rather than we do have that ROI calculator, it is based on previous evidence, but it also isn't like real world evidence. So that would be our pitch, but sometimes it might not be sufficient to kind of go through all the complexities of the decision making to purchase. So we would approach it with that design partnership approach.

- So basically the concept of like how your early adopters and your like general customer base are almost two different populations and you're targeting them early on, but then knowing that your later customers gonna be totally different.

- Yes, yes.

- Which is actually, it's like a very important lesson to learn in sort of this space. Looking out for any other questions.

- In the chat. I'm not sure if there were any questions there.

- I think a lot of that was my agreeing with a lot of the things you were saying was fanboying the comments.

- Do you have any high yield, so what would you say like the, like your top three high yield tips for someone developing a software solution would be?

- High yield tips?

- Somebody who's, yeah, for building out their first, I mean you mentioned a lot of them of, you know, make sure that your MVP is, you know, getting there as safely quick as possible, making sure that you spend so much time looking for your co-founder and obviously the cliff and excuse me, well the second word.

- Is the vesting period.

- The besting period is extremely important. Are there other other tips that you think would be very useful for people who are participating in on, for example, to decide on, you know, is this solution the right fit for me to pursue in a three day period?

- Yeah, I mean I think this might kind of contradict with what I mentioned earlier, but there's a lot of uncertainties. Like whether, like even if there are a lot of frameworks and a lot of content out there to a point that you have this fear of missing out that you have to know everything. You don't really have to do it because, you know, again, everything has, is you really have to think about what you wanna do, what your aim is and how to get there. So just try out a lot of things and fail a lot and fail fast without doing any harm to patients. But, you know, in a safe spot, just try, try out things and fail. Don't be embarrassed to fail and you'll figure things out on the way and you'll get better over time. So I think of my startup journey as my residency. So in my first year of being a founder, I get embarrassed. I wouldn't be the best at doing everything. You're wearing a lot of hats, figuring a lot of things out. You're doing sales marketing and whatever else that you have to do. But I look at it as my first year of residency knowing that I'll get better as the years go by and I'll progress but I won't get better if I don't go through those experience. So if I don't do enough intubations, I won't be good at intubating later down the road. So just kind of have a similar approach and forgive yourself for making mistakes and seeming stupid sometimes.

- I love that. Forgive yourself. Very important. Well, thank you so much for your time today. Thank you for walking us through your journey. For everybody that's watching this asynchronously, just remember to look for the talk bullet points so you can reference them during the competition. Thank you for everyone who attended today and in a few minutes we'll be moving on to our first hardware talk. Dr. Chae, thank you so much for being with us today.

- Thank you so much for having me. If anyone has any questions down the road, feel free to email me at kathychae@cyrencare.com or you can find something on our website where you can contact me. So when you're seeing this later, feel free to ping me for anything, any questions.

- And visit at the ACEP booth too.

- Yes.

- All right.

- We'll see you there.

- Okay.

- All right.

- All right, have a good afternoon everyone.