Launch YC S21: Meet the Batch, Thread #6
Welcome to another "Meet the Batch" thread for YC's S21 batch. The previous thread was https://news.ycombinator.com/item?id=28128957. The original announcement is at https://news.ycombinator.com/item?id=27877280.
There are 6 startups in this thread. The initial order is random:
Kodex (YC S21) - Easy responses to government data requests - https://news.ycombinator.com/item?id=28156465
HeyCharge (YC S21) - Low-cost EV charging in multi-user buildings - https://news.ycombinator.com/item?id=28156463
Parallel Bio (YC S21) - Improving drug discovery by replacing animal models - https://news.ycombinator.com/item?id=28156464
Secoda (YC S21) - Company data discovery tool for teams - https://news.ycombinator.com/item?id=28156461
Oneistox (YC S21) - Skill-building, cohort-based courses for designers - https://news.ycombinator.com/item?id=28156462
Zeit Medical (YC S21) - Early detection of stroke - https://news.ycombinator.com/item?id=28156466
119 comments
[ 2.6 ms ] story [ 190 ms ] threadCompanies store a growing amount of knowledge in BI tools, data warehouses, data pipelines, queries and documentation. Because these tools are not connected, it has become more difficult to manage all of this. Even with great practices, organizations still struggle to get value out of their data - up to 73% of all enterprise data goes unused. One of the big contributors to this problem is that organizations create data silos by not documenting and centralizing their data knowledge in a single place where every employee can access information about data.
Today, most data teams end up documenting all this data with Google Sheets or Confluence, which get outdated quickly. Because data documentation is outdated and hard to find, employees struggle to discover, understand and use it. This overwhelms data teams with repetitive questions about how to use and where to find company data.
In our last roles, Andrew and I had a hard time understanding context around different data resources. It was difficult to understand which table to use, what dashboard to trust, who to talk to about a particular metric or why we changed our pricing model. All of this data knowledge was in our data teams head and it made it really difficult to try to work with data. It would take around 2 weeks to get an answer to any data request because the data team was so backed up with questions. This sucked.
Secoda is unique because it's focused on helping the data team curate knowledge for the less technical employee. Data teams can use the tool to curate knowledge for specific departments or roles so that only the right people are able to see the data knowledge that they should see. We currently integrate into data warehouses, BI tools, dbt as well as Airflow and once teams connect their data to Secoda, they can get a comprehensive view of all their data knowledge in one place.
We’d love to hear your feedback or experience with the problem that we're solving and would be thrilled if you would sign up at https://secoda.co to let us know what you think!
Now to assign someone to give it a whirl and hope it works.
We're happy to help you or whoever would set it up and show you how other teams have been using the tool. Feel free to shot me an email at etai@secoda.co if you'd like any help along the way
I would love to see some case studies or customers who attest that this actually created primary value which is kind of missing. Just an opinion.
I’d also like to see comment threads over data discoveries. Like a snapshot of a report with in-context exploration would be super helpful. In my experience the default behavior is a report screenshot dropped into a slack thread, and I know there can be better. QlikView does a decent job at this but it has the trappings of enterprise software. I think that would unlock a lot of value out of reports and give a place for teams to understand opportunities and celebrate wins. Congrats on the launch!
Our most requested feature is discussion threads attached to each data resource (table, dashboard, etc) to build context around a resource. So that will be coming in the near future, and we are happy to hear you also think it would be super helpful!
[0] https://www.gartner.com/en/information-technology/glossary/m...
Additionally, we try and make Secoda easy to use for both technical and non-technical users, whereas a tool like Amundsen is more focused on the technical user.
We extract lineage in a couple of different ways. The main way is by parsing SQL queries in your data warehouse to determine which tables and dashboards are upstream/downstream. The other way we extract lineage information provided directly from dbt and BigQuery who have nice APIs for this information.
We are working releasing an API in Q4 that supports pushing information from say an Airflow DAG to Secoda to give us more lineage context. Hopefully this answers your questions.
Online learning by watching pre-recorded videos does not work for design and architecture. Learning design is an iterative process that happens through communication over drawings, sketches, screen visuals and physical prototypes. It also depends greatly on being exposed to how your peers are addressing the same problem and understanding approaches from the experienced. No LMS (Learning Management system) in the world caters to this way of communicating while learning. There is also very little quality curated content online on design, architecture and construction subjects, and no space which upskills you in these fields sufficiently for career growth. Meanwhile, demand for designers has been growing at 21% annually over the last 5 years but only 1/5th of this demand has been met.
We felt the skill gap when we were in grad school. What we were being taught was last revised 35 years ago. 80% was also by the faculty that was non-practicing in architecture—hadn’t built anything in their life. Institutes were doing nothing to address this in India. We researched deeper by talking to professionals abroad, and found that this problem came out to be global, especially in developing and under-developed nations.
We've built a new, cohort-based, project-based LMS specifically to learn design subjects for feedback over drawings, sketches, screen visuals and physical prototypes. Our learners work in groups of 2-6 on live projects and create concept designs to executable drawings from scratch. Project-based learning and peer-to-peer interaction in cohorts increases completion rates by 12x! So far we've had over 2000 learners from 27 countries upgrading their skills in subjects like Building Information Design, UI/UX, Sustainable design, Computational design, and others. We connect course graduates to industry professionals for hiring. We look forward to your feedback!
Edit: just saw your logo. That reads well on first glance.
Probably wouldn't sign up for a course at the moment, as I am focusing on honing BE and FE software engineering skills at the moment, but definitely will bookmark just in case the stars align. (meaing when I have time and see a live course that I like. As a side note, it would be a cool feature to see some upcoming courses on your site too).
Best of luck on this though! Really want to see something like this succeed.
Current indoor EV chargers are expensive to buy, install, and operate, especially because they need internet connections and cloud-based backends. They're also unreliable, because even if the charger's internet connection works, the user might not have one on their mobile device while underground.
Our chargers don’t require an internet connection, they don’t require any setup other than an electrician to wire power, and our charger and app work together, even when underground and outside of mobile network coverage. This makes them cheaper and more reliable.
We exchange cryptographically-signed, single-use tokens between the charger and our mobile app. We provide tokens proactively to users whenever they have mobile network coverage, meaning they have a supply to use when underground in front of their charger. The charger doesn't need to connect to the internet, only to the user's phone. It provides a charging session in return for a token. After charging, a token is sent in the reverse direction, where it’s eventually sent to the back end. We only provide a replacement token to the user in return for them bringing a complete charge session report. The user’s app and device is an untrusted intermediary in this design, making the system resistant to abuse.
I (Chris) got my career start at UC Davis working on EVs in a graduate research group under the inventor of the modern plug-in hybrid, Dr. Andy Frank, followed by experience at Google, Mercedes-Benz R&D, and E.ON Energy. I finally brought my first plug-in car home to a Munich city-center apartment in late 2017 and realized just how difficult and expensive installing EV chargers in these buildings was. We started HeyCharge to bring EV charging to users like me, living in apartment buildings. We are deploying hardware to our first pilot sites now. Looking forward to your thoughts, questions, and comments!
We have two models:
In a few markets, we operate a "full service" model where we're invited in by a building owner to install infrastructure at our cost, and charge a subscription fee to users to access it in addition to charging for energy consumed. Building owners love this because it's a natural way to transfer costs for the infrastructure to tenants, and -- as "full service" implies -- it takes all the administrative overhead of managing the infrastructure, billing tenants for power, etc. off their plate.
We also offer our technology as a platform for other companies to use as a part of their product or service. With a combination of our SDK and API, they can enable their own app to access HeyCharge devices. This means we can offer the low cost of hardware, low cost and high scalability of setup, and low operating costs to their product/service. We're piloting this with several energy utilities, mobility operators, and a few more that I can't talk about yet. In this case, we operate on a hardware sales + SaaS model.
I'm excited about what you folks are doing and would love to connect. We've been helping many companies in this space better integrate with electric cars.
Can you shoot me an email? sahas@smartcar.com
One side is also regulatory. At least where I was because the building feed was not up to code, and to get charging in would hit meters, the upgrade costs were too high. Hopefully solutions can show up there as well. Love not having to have network connectivity just local.
1. Eliminating the internet connection lowers both installation cost and setup complexity for the charger. The RFID card doesn't save you from having to take these (expensive) steps when setting up a site, and to pay for the connection on an ongoing basis.
2. Once you eliminate the external variable of configuring a charger to use an internet connection and a backend, the setup flow becomes virtually a plug and play. This substantially improves scalability as we don't have to train dedicated installers. Any electrician who can read a wiring diagram can bring up a site. And, of course, this translates into lower costs for the user.
Of course you could have a disconnected charger using statically-configured RFID cars that doesn't require #1 and #2 above, but then you can't bill people for what they consume or centrally manage access. This is OK for some small sites, but isn't really a scalable solution.
What prevents the user from reusing the token? Does the charger keep some state about previously seen tokens?
No phones, no apps, no access cards. The charger recognizes my car, the car has the billing info, done.
Sigh.
It was such a massive ball drop when the plug standard insisted on having the plug + car detection of the plug being inserted work in all conditions, but then failed to account for the simple fact that billing also needs to be solved.
It's like they thought of it as someone inserting a gas nozzle, or that the electricity would be free.
And now we've rolled out how many of these?
So far, only Tesla really supports this at scale (and unfortunately it's proprietary so we can't really use it).
However, the coming wave of EVs will finally support ISO15118, which is a global standard that brings this experience to any EV. We'll support it as soon as there's a meaningful population of vehicles out there with the car-side support. Come to our labs in a month or two for a preview ;)
The biggest reason why 92% of new drugs fail is that drugs are currently discovered in mice, which are not realistic models of human disease but are used due to the challenges of working in humans. We've created a human ‘immune system in a dish’ to discover drugs more likely to work in patients.
Robert has a PhD in immunology and is intimately familiar with the ways in which people are failing to recognize the importance of the immune system in diseases and the failures of trying to model it adequately. Juliana has a MSc in bioengineering and for the last 5 years has been working on developing mini-organ models in an effort to more accurately model human disease.
Both of us have always recognized a gap in the pharmaceutical industry that everyone seems to acknowledge exists, but few people are working to fill, which is using humans and human systems to treat disease. Since it is not always possible to test drugs directly in patients, there is a critical need for human systems to test drugs on that will predict downstream success in the patient.
Our immune organoid is a 3D system that has all of the features of a human secondary lymphoid organ. It contains all of the cells (B cells, T cells, NK cells, etc), structures (germinal centers, LZ/DZ, etc), and function (somatic hypermutation, antibody and cellular response, etc) that you would expect to see in a secondary lymphoid organ. It matches the genetic background of the patient from which it’s derived, meaning it also models diseases that patients have. And because it exhibits the same functions as a human immune system, you can test drugs and vaccines as if you were testing them in actual patients from the start. It's also easier to work with than mice.
People are currently using our platform as a new way to produce antibody therapies, to test vaccine candidates, and to test new treatments for diseases like multiple sclerosis.
How finicky are these organoids to maintain? It used to be true that organoids are harder to maintain than super large mouse colonies by a long shot!
What validation are you doing on your immune organoid to confirm they work correctly for the assay you’re trying to do?
How do you emulate the various ailments in these organoids? You mentioned MS, are you able to emulate MS like conditions (or even EAE) in these systems?
The organoids are incredibly finicky until you figure out a culture system they like. Then it is actually very easy to maintain them. This allows us defensibility as it's hard for others to figure out but easier for us now that we have.
We've used the organoid to test 12 immunomodulators and confirmed they matched human clinical data. We also vaccinated the organoids against 8 infectious diseases and they produced a full immune response with class switching, germinal center formation, somatic hypermutation, etc. We're also in the process of using more historical controls to show that immune reactions that were missed in mice and other animals are captured in our system (e.g. there are highly inflammatory drugs that were safe in mice but deadly in people once they got to clinical trials).
By biobanking on diverse patient backgrounds, diseases are emulated in these organoids naturally. Immune disease is typically a function of dysfunctional cells that exist in a patient. By capturing an immune niche that has those cells, we have the disease-causing cells. We can confirm they emulate a disease by demonstrating a phenotype on a tissue of interest (e.g. we can make an MS immune organoid from a patient with MS and then show that the immune cells from the organoid demyelinate neurons). This should be the same for any immune disease as we continue to generate proof of concept.
I personally don't think it is ok, but it apparently is a necessity, at the same time if this can be stopped then that would be great.
Three main Q:
* How's reception been with med chemists?
* How do you expect cost to compare with some of the individual existing immunological wet lab screens? No individual numbers, just comparative would be interesting to know.
* How granular is data collection for this kinda all-in-one system, and is throughput high enough to collect data and build predictive models alongside it?
I used to work in the earlier stages of drug discovery and advances in these assays are fascinating. Really exciting work, guys!
We haven't gotten any feedback from med chemists yet! The cost is comparable to other in vitro systems and is cheaper than using animals. *The data collection can be very granular. You can use single cell techniques like flow and RNA-seq to generate high resolution data. You can also use high resolution imaging techniques like CODEX. Moving into high throughput and building predictive models is exactly where we want to go. Currently, we can generate 7500 organoids from a single donor and screen them in the thousands. We're working on building a ML pipeline along with automation so that we can screen in the hundreds of thousands if not more. Key to this though is that we have designed a platform that is amenable to this kind of automation and scale.
And I highly recommend reaching out to a med chemist for some input. There's a lot of veteran retirees specializing in spaces adjacent to this who are open to consulting here and there. They're generally quite kind.
- Which patient/donor cell type are these immune organoids derived from?
- Are the organoids made with induced pluripotent stem cell technology?
- What is part of the workup post treatment, e.g. histology, NGS? If NGS, what kind (WGS, WES, RNASeq) and technologies (Illumina, PacBio, ONT)?
- Are you looking for mutations from the drug and vaccine treatment (e.g. comet assay, Duplex-Seq)?
- They're derived from secondary lymphoid tissue. We're trying to biobank as broadly as we can to capture sex, age, race, HLA, genetics, and other characteristics in a wide net.
- These are not iPSC-derived organoids.
- This depends on the readout but workup post treatment so far has included histology, immunofluorescence, serology (ELISA, SPR, etc.), CyTOF and other flow, broad RNA-seq, bulk and single cell repertoire sequencing for B and T cells, and MSD/Luminex.
- We haven't looked for mutations from drug and vaccine treatment. We'd love to know more about what you're thinking there.
Does your system also have epithelial lining, with all of the components of innate immunity which integrate with the adaptive immune system?
The role of the nervous system is more and more recognized as being integrated within the immune system - is there any way you can somehow include that in your system as well in the future?
Government agencies subpoena user data from thousands of companies around the world, and companies largely rely on email, fax, and spreadsheets to manage them. At a previous job, we would frequently see companies struggle to comply with legal orders, because they lacked the internal resources or expertise to automate the process of working with government agencies. Even multi-billion dollar companies had this problem. At scale, it is enormously burdensome.
Somewhat surprisingly, companies have all independently learned to comply with these requests in almost the exact same way. Regular ticketing systems don't work for this, so companies have adopted a web of Zendesk tickets, spreadsheets, and emails just to manage the intake of requests. To respond to requests, they typically send unsecured emails. The fact that this inefficient and insecure setup is so common suggests that these companies' needs can be met with one product, rather than custom solutions for each company.
Kodex automates the entire process of parsing, analyzing, and responding to subpoenas by providing companies with their own online Government Request Portal. It is similar to the Law Enforcement Portal that Facebook made for themselves, but it is a resource for every other company to use.
I think most people who haven't lived this problem assume it is only an issue for big tech, when in reality big tech are the only ones who can afford to build their own internal tools to alleviate their pain. If any of you have felt this pain, we'd love to speak with you! And your comments and questions are welcome.
What's the hardest thing you have found getting Kodex to this point?
How many government bodies are you connected to? Can you use your platform even if they do not use it?
Do you use a subscription pricing model?
We have about 60 agencies verified with us so far. What's interesting about this problem is that the company dictates how government agencies contact them. As a result, the moment our customers adopt Kodex, they automatically pull in any government agency that wants to contact them. We have new government agents signing up everyday to send our customers requests.
We do use an annual subscription pricing model.
Happy to connect offline!
What mechanism governs this? Are you standing in as their registered agent? Politely asking agencies to follow your process and finding that they tend to be willing to do so? Something else?
Agencies are willing to follow the process that a company lays out because it makes engaging with that company easier. It is not in an agency's interest to make the process difficult (i.e. demanding to use fax machines when a company already has a lawenforcment@company.com email set up).
Am I reading this right: agencies aren't reaching out to companies because it's kinda hard to because every company has their own process? Or at least, agencies are slowed down by this fact? So, couldn't adopting your product be seen as a bad thing? If a company prefers noncompliance to government agencies (legal noncompliance through explainable bureaucratic friction), and the lack of a product like yours allows for friction to slow down both the government sending, and companies responding to, for example FBI requests, that sounds like an ideal state for some companies.
Say for example if I manage a wiki, forum, library etc for protest movements, I would be motivated to make it as hard as possible for the FBI to investigate some of my users that the FBI has improperly identified with the unjust "Black Identity Extremist" [1] label. I mean, obviously I wouldn't become a customer of yours, but if other companies also don't become your customer, the FBI has less resources writ large to deal with my organization manually. Therefore, in general, it's helpful for everyone to avoid helping the FBI do their job more easily, right?
[1] https://www.aclu.org/issues/racial-justice/protectblackdisse...
I see what you're saying, but I think there is a fundamental misunderstanding - Kodex was made to make things easy for the company, not the government. Agencies are never deterred from reaching out to companies because it's "kinda hard," nor because it's different for each company. It actually doesn't even slow them down - data requests are already growing ~25% YOY. Govt agencies get more and more resources to serve subpoenas, but companies are left to fend for themselves with an ever increasing volume. The moment a company receives a subpoena, the company is now legally obligated to respond in one way or another. The nuance is that you don't necessarily have to comply and provide data - the company can push back on the legality of subpoena, but it will still need to be addressed one way or another.
Sure, you can certainly choose noncompliance through bureaucratic friction but that doesn't eliminate your problem as a company, that actually only makes it more burdensome for your company. At some point you still have to address the subpoena.
When a company does not have an intake method for these types of legal inquiries, it only makes it harder on the company...not the agency. The agency will just send the inquiry to any publicly known address, email, etc. In one way or another, if they want to send you a subpoena, they will...aka making the process hard does not prevent them from reaching out to your company, it only makes it hard on your company.
I think a perfect example is Facebook. They built their own Law Enforcement Portal because 1. there was nothing like Kodex that they could buy, and 2. They understood that making the process easier for themselves greatly helped their company with cost of compliance, protecting user privacy, and pushing back on overly broad requests. Did the Facebook LE Portal make it easier for agencies to send them subpoenas? Sure. But it's not as if agencies wouldn't still be sending just as many subpoenas to Facebook if they hadn't built their LE portal...Facebook would still be getting them, it would just be that much harder for Facebook to manage them.
In regards to your example, I understand wanting to do your part to stand up to government overreach. The government is not infallible - they've been on the wrong side of history more than once.
I think the answer to standing up for these issues, is not to create more friction, but instead to facilitate a streamlined process of engaging with government agencies - so you (as a company) can more easily push back on the legality of a subpoena that you don't agree with, and also more easily assist in the very real instances of identifying victims, or subjects, that end up saving a life.
I think this subpoena process has become so sloppy and overwhelming that it is easy to forget that there are victims at the end of this transaction.
If there are subpoenas sent to you regarding a user on your wiki, wouldn't you want to have a clear understanding of what the government is looking at, and why? What threats are on your wiki? Wouldn't you want to easily be able to prioritize a case involving child exploitation, or self-harm, and help protect those users, while also having a better avenue to push back on requests you find to be unjust?
There is a lot that can be fixed in government. This process is one of them. The goal is not to "help the government do their job more easily"... making the process easier for the company, forces the government to do their job BETTER, and helps society move forward.
Best of luck!
I think that is the most common misconception with this problem, and that is why it has gone so long without a solution. You are correct in that the biggest players (i.e. big tech) are the ones who have the resources to solve their own problems. However, this problem spreads much further and wider than just big tech. There are thousands of companies in the US alone that get these requests (from ISPs, banks, insurance, fintechs, crypto, tech, etc.). "Big tech" typically gets all the focus because of the volume they get (FB gets 300k+ per year). What goes unnoticed is that even at 100+, or 1000+ per year, these requests are very overwhelming for companies to manage. These are also the companies that don't have the internal resources to fix their pain like FB and Google.
Love to know your thoughts!
90% of strokes go untreated due to stroke recognition delays. Many patients live in fear that a stroke might happen and go unnoticed for hours, particularly if they are asleep when it starts. Stroke is currently impossible to detect based on symptoms. Unlike a heart attack, there is no distinct pain. There is a compelling need for a monitoring/alert system that will enable fast access to treatment.
Orestis has a PhD in Biotechnology and Bioengineering and has spent a decade developing wearable health-monitoring technologies. Urs is a pediatric critical care physician. Both founders have done research at Stanford. We've also both experienced the never-ending fear of another stroke in our families. We decided to do something about this problem--only 10% receiving treatment is just not cutting it!
We have a stroke detection algorithm which has been clinically proven in operating rooms. We're pairing it with commercially available brainwave sensors to create a smart headband that enables immediate stroke detection at home. The sensor pairs with our app and if a stroke is detected it alerts caregivers abs 911. This is different from other technologies that aim to improve patient transportation (once the patient is in the ambulance) or door to needle time (once the patient is in the hospital). The longest delays occur prior to calling 911, so this is the critical phase for making a difference.
The headband pairs with an app to analyze the brain’s electrical activity in real time with our stroke-detection algorithms. Brain activity metrics are already used in the clinical environment, but so far this know-how has remained siloed within the hospital. Our headband runs on AI that emulates the ability of expert neurophysiologists in digesting brain activity information to infer whether a cerebral injury is taking place.
We have recently kicked off a 15 person human factors study to assess overall system adoption and compliance. We also offer a sign up to get it first once our technology is cleared by the FDA. We look forward to your questions and comments!
We have a vision to make future versions of our technology that will be even more inconspicuous. We also have IP on implantable versions of this. For people that live with stroke risk, our current form factor is the first step towards providing some peace of mind :)
In the meantime: There are some great resources at
1) cdc : https://www.cdc.gov/stroke/facts.htm 2) aha :https://www.stroke.org/
Is there some data on the 'optimal' time from when a stroke starts where intervention would prevent serious impairment? i.e. if you detect a stroke, how many minutes/hours do you have before irreversible damage is caused?
Relatedly, what measures are done when a stroke is detected to minimize damage/impairment?
Also, what's your false positive rate?
Wish you all the best of luck! I've had family members who've had strokes and early detection might have helped them a ton.
1) There is a ton of interesting research on the topic of what happens from the onset of the stroke until permanent lesion formation.
In brief, there is usually a stroke "core" where the damage starts within seconds to minutes.
However there is a big volume surrounding the core, usually referred to as "penumbra" that is of substantial size and remains "live" longer due to access to collateral blood flow. This practically means that the small arteries which run in parallel to the main one that was blocked (causing the stroke) can sustain the surrounding tissue for a longer period of time than the core. However this blood flow is not enough to sustain those tissues in perpetuity and as a result the penumbra will also "die" if no treatment is provided promptly to re-establish flow in the "main" artery.
So there is a real race to save the penumbra!! (https://en.wikipedia.org/wiki/Penumbra_(medicine))
Summarizing the above -> Time=Brain.
The most important point to keep in mind is that for treatment to be provided there must be something "left" to save upon arrival at the hospital. This is usually not the case when people get strokes during sleep or when they are alone (it's hard to detect so there is a ton of delays pre-911)
2) The management of a stroke depends on the stroke type, location, severity, symptoms. For ischemic strokes (85% of all strokes) the strategy is to bring the patient as quickly to the hospital, complete imaging diagnosis and re-establish blood flow in the affected vessel (via thrombolysis or thrombectomy)
These options are really well explained here: https://www.nhs.uk/conditions/stroke/treatment/
3) We are optimizing our tools for zero false positives. Final product requirements will be set in communication with the FDA.
4) If you think that you family members might be interested in our technology, ping them to check out our website.
- How common are strokes generally?
Seems like a lot to wear this all the time — but also I’m not familiar with the risk factor.
- How much quicker is this at detecting a stroke versus someone simply observing it happening with a naked eye?
Like how much time does this save over simply seeing physical symptoms with your naked eye or feeling the symptoms for yourself? 1 second, 1 hour, 5 hours, days?
Great questions!
1) For the US-> There are approximately 1 million strokes every year. Stroke is the #1 cause of disability
2) Good point. We are starting with a system that can be work at night time + whenever the users feel most vulnerable. There are many patients who who through periods of increased risk (i.e. after a 1st stroke, after a transient ischemic attack).
3)Stroke recognition is one of the biggest pain points in bringing stroke victims to treatment. Strokes that happen during sleep (commonly referred to also as wake up strokes) are practically impossible to detect based on symptoms. There is not pain associated with it (like in a heart attack).
4) We have heard crazy stories from patients and caregivers about how different their outcome would have been had they been alerted a couple of hours earlier. Our vision is to help everyone go to the hospital in under 1h. Our first target is to enable everyone to go to the hospital within 4h which is currently the time window for tpa d (clot busting medication). What's the current status? -> only 4% nationwide get tpa because they arrive too late.
If you know when the stroke started and its more than 5h past that -> no tpa.
If you don't know when the stroke started -> no tpa.
Would it be useful for someone who had small lacunar strokes which provoked parkinson?
Thanks, awesome company
1) Currently focusing on clearing the FDA in the US. One of our clinical advisors is very passionate about helping bring this also to Mexico. Please sign up in our waitlist and we will make sure to keep you posted.
2) You are raising a very good point about lacunar strokes. In general these are deeper in the brain structures and not easily picked by cortical-level brain activity monitoring. However we feel confident that once our product is regulatory cleared and out there collecting data, we will be able to pick the finer effects caused by such strokes.
2) The patient will present to the ED, via medical transport or in special circumstances private transport. We will perform informative sessions with the EDs that lie within our initial rollout area. The EDs will know what to expect and will perform imaging on patients arriving with our alert. Going forward, the individual will also have information on their app they will be able to show the physician, to inform them with data about our tech.
3) Most commonly symptoms develop within minutes, after the neurons are no longer receiving oxygen. In an ideal scenario treatment could be provided in the patient’s home right after the alert, but before this can happen the tech will need to have gone through additional confirmation. We are currently relying on confirmation of the stroke in the ED with the current gold standard: CT perfusion or MRI.
Also, are you thinking you’ll try and sell into hospitals or purely D2C?
We cannot share our models but we are using brain wave analysis to detect stroke. Our algorithm is currently tuned for maximal specificity and might be tuned differently for inpatient and outpatient use. We are in conversation with several EEG vendors for inpatient use of our algorithms.
Your website also mentions seizures. Are you trying to get FDA clearance for both?
Also, why did you choose the subscription route?