[HN Gopher] Launch YC S21: Meet the Batch, Thread #6
___________________________________________________________________
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
Author : dang
Score : 78 points
Date : 2021-08-12 14:01 UTC (8 hours ago)
| Etai wrote:
| Hey HN, I'm Etai, together with Andrew a co-founder of Secoda
| (https://www.secoda.co). Secoda is a collaborative workspace for
| data teams that makes it easy to share metadata, queries, charts
| and documentation with any employee.
|
| Companies 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!
| duck wrote:
| You mention data lineage on your pricing page, but do you have
| any examples of what that looks like? Can you support custom
| lineages driven by an api?
| andrewmcewen wrote:
| An example of what lineage would look like is the following:
| You have source tables A and B that are joined to create a
| model C and then C is used in dashboard D. We are able to
| infer the lineage A->C->D and B->C->D.
|
| 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.
| sails wrote:
| Very cool. How much of this working effectively depends on a
| properly deployed dbt project?
| andrewmcewen wrote:
| Hi there, I'm the CTO of Secoda so happy to answer your
| question. Our dbt integration works with dbt cloud, and are
| working on making it compatible with dbt core as well. What
| we'll pull from dbt via their API is the metadata associated
| with the models, docs, and, jobs. We have a free version of
| the platform, so you can sign up and test it out if you'd
| like to see what that information looks like in Secoda.
| reilly3000 wrote:
| This addresses key usability issues with most data initiatives.
| Don't be dismayed that people who haven't tried to share
| reports with teams don't get it... I get it and I presume end
| users will love it. There is a particular need for metadata
| support in Google data studio that would be great if you could
| help solve: there are no folders or any real way to curate data
| outside of report sharing and leaving text boxes on the reports
| themselves. It's kind of a nightmare for an otherwise powerful
| and popular tool.
|
| 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!
| andrewmcewen wrote:
| Thanks for the positive message. We appreciate the support
| from people who understand the problem that we're trying to
| solve with Secoda. We haven't had someone request Google Data
| Studio as an integration, but if you were interested in
| discussing what that would look like please reach out to
| andrew@secoda.co. It looks like there's an API for accessing
| assets in Google Data Studio, so it's definitely possible.
|
| 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!
| jeffbarg wrote:
| Such an important problem - I really hope you become the new
| standard for companies' data. The number of times I've seen
| complex, undocumented queries...
| andrewmcewen wrote:
| Thanks, we hope so too! At Secoda, we really want to make
| data less intimidating for anyone in the organization to
| explore and use. When the whole company can use data to help
| inform their decisions it really does make a big difference.
| troelsSteegin wrote:
| Long term, do you see yourselves in the MDM space [0]?
| Informally, I think of MDM as "enterprise into analytics", and
| my first impression of Secoda is "analytics out to enterprise".
| Schemas and data dictionaries seem central to both. An MDM
| solution like Tamr looks a lot heavier weight than I think the
| experience you target.
|
| [0] https://www.gartner.com/en/information-
| technology/glossary/m...
| andrewmcewen wrote:
| You've hit the nail on the head here. Long term we want to
| bridge the gap between the data team and rest of the
| organization through a central repository of data knowledge.
| Using MDM's terms the data team = IT, the rest of the
| organization = business, and repository of data knowledge =
| master data. So it's almost a one-to-one comparison, and
| we've never heard of MDM so this is great! We are also trying
| to make the experience lightweight and user friendly so that
| everyone is interested in exploring their company's data.
| dataminded wrote:
| Take my money!
|
| Now to assign someone to give it a whirl and hope it works.
| Etai wrote:
| Thanks so much!
|
| 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
| dataminded wrote:
| Will do. Just saw that API access is gated to enterprise
| accounts so we may need your help.
| andrewmcewen wrote:
| We have pre-built integrations with many popular data
| tools (Snowflake, dbt, Tableau, etc.) that can be setup
| in less than 5 minutes. If those don't fit your needs
| then we can definitely setup some time to discuss the
| API.
| stadium wrote:
| How does the tagging feature work? Is it at the table and
| column level?
| andrewmcewen wrote:
| You can add tags to any data resource in Secoda (table,
| column, dashboard, dictionary term, etc). When you tag
| resources, you can search for them by tag. Our customers have
| found it very useful for keeping everything organized.
| achllies wrote:
| This looks really interesting. How does it differ from
| something like Amundsen : https://github.com/amundsen-
| io/amundsen
| andrewmcewen wrote:
| The catalog portion of the Secoda product is similar to
| Amundsen, but we also have a Data Dictionary for defining
| metrics, Analysis Documents for queries and charts, and
| Requests for handling data questions. We take these different
| pieces of functionality and make everything interconnected,
| so that it's one unified repository for your data knowledge.
|
| 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.
| debarshri wrote:
| How does it compare to traditional reporting tools. Lot of
| modern day BI tools like looker for instance, do have features
| like this. Where do you position yours company as compared to
| traditional tools?
| andrewmcewen wrote:
| The main way that Secoda differs from a traditional reporting
| tool is that we offer a more complete view into the data
| knowledge/context of an organization. A traditional reporting
| tool like Looker does great for reports, but it misses
| context about how certain models are created, where data is
| coming from downstream, and more general knowledge that is
| stored inside of a wiki. Secoda takes all of the context
| across a data stack and puts it in one central place. So we
| actually see ourselves as complementary to these reporting
| tools as we are a layer on top of them.
| debarshri wrote:
| This is my very naive opinion, having context of the data
| or report, I would perceive it as nice to have.
|
| 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.
| imharkunwar wrote:
| Hi HN--we're Harkunwar, Vipanchi, Chaithanya and Mehul from
| Oneistox (https://oneistox.in/). Oneistox offers online cohort-
| based courses for designers, architects and engineers to advance
| their professional growth.
|
| 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!
| aronowb14 wrote:
| This is awesome!
|
| 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.
| imharkunwar wrote:
| Thanks! :D We are launching 6 new courses in the coming
| quarter. 2 of them are around digital product design and
| UI/UX that you might be interested. We believe and see trends
| where future is going to be about every individual having
| some learning about design principles in their subjects.
| fezzez wrote:
| How do you pronounce your name?
| natemwilson wrote:
| Based on their logo it looks like: "one is to x"
| imharkunwar wrote:
| On point - Its /wan-iz-tu-ex/ - referring to scale like
| 1:100, 1:500, 1:5 etc. In design, especially tangible
| design subjects like industrial design and architecture,
| everything is prototyped at some scale or proportions that
| is friendly to understand the design development.
| kall wrote:
| If you have already considered this enough, disregard my
| comment..This name really trips me up as a german reader.
| If you like that it's a bit out there, that's cool. If
| you want most people to read it like you just explained,
| you might need to capitalize the individual words.
|
| Edit: just saw your logo. That reads well on first
| glance.
| neonate wrote:
| Looks like https://onetox.com/ is available. Maybe they
| can get big and buy it.
| ChrisCarde wrote:
| This is Chris and Robert from HeyCharge (https://heycharge.io/).
| We're developing low-cost EV charging for indoor environments
| like underground parking garages.
|
| 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!
| sahaskatta wrote:
| Hi Chris and Robert. I'm the cofounder of Smartcar.com. We're
| an API for EVs. We're backed by a16z and NEA. (I also went to
| UC Davis too!)
|
| 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
| ChrisCarde wrote:
| Will certainly drop you a line! Thanks for reaching out!
| michaelbuckbee wrote:
| The idea of using tokens is very clever and I can see how that
| could really reduce the complexity of getting a charger
| implemented. I'm curious about the overall business model here,
| do the sites hosting the chargers make money from this or is it
| more like an amenity?
| ChrisCarde wrote:
| Thanks! :) We're really excited about how our token system
| results in a nearly "plug and play" charger -- just add
| power!
|
| 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.
| saraQOA wrote:
| I love the idea! Cannot wait to have one here, as the the few
| charging stations are in the center of the small village where
| I live, so always have to park there, and pick up the charged
| car later...
| ChrisCarde wrote:
| Exactly the problem we want to solve!
| danvoell wrote:
| Great idea. Good Luck!
| slownews45 wrote:
| EV charging in shared use / multi-family housing is still one
| of the harder areas to solve. So great to see more options
| coming - I wish you the best of luck.
|
| 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.
| [deleted]
| ChrisCarde wrote:
| We aren't able to fix every wiring or capacity issue in every
| building, but we have a neat combination of low-power
| hardware options and load management. The net effect is that
| often our infrastructure will work where other options
| struggle. And thank you for the kind wordsa
| rdifazio wrote:
| Hey everyone! We're Juliana and Robert, co-founders of Parallel
| Bio. We're improving drug discovery by replacing animal models,
| in the hope of making cures for humans, not mice.
|
| 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.
| gtirloni wrote:
| Why is your website empty?
| rdifazio wrote:
| We're in the process of launching and are working on coming
| out of stealth as fast as we can. It shouldn't be empty in
| the near future!
| ramraj07 wrote:
| Exciting to hear this! Do you have any references to the type
| of work (if your own isn't published) that closely resembles
| the organoid models you use?
|
| 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?
| rdifazio wrote:
| There's been a lot of research around organoids but our human
| platform is unique. Here are two reviews discussing organoids
| that have been so far for the immune system, though these
| have almost all been done in mice
| (https://pubmed.ncbi.nlm.nih.gov/31853049/;
| https://pubmed.ncbi.nlm.nih.gov/32112908/).
|
| 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.
| dbieber wrote:
| Heads up I went to email you a congratulatory email at
| hello@parallel.bio but my email was rejected. Might want to
| double check your google groups settings.
| whymauri wrote:
| Very cool and promising. Is there any literature on this
| "immune system in a dish", or is it ,understandably,
| proprietary?
|
| 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!
| rdifazio wrote:
| There are some reviews on immune organoids that I posted
| below. This is the first human one though able to
| recapitulate these features at a commercial scale.
|
| _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.
| whymauri wrote:
| Oh wow, your upcoming plans sound great. Keep up the good
| work guys!
|
| 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.
| rdifazio wrote:
| Thank you! If you have a good recommendation, we'd love
| an introduction. Please let me know at robert at
| parallel.bio.
| jacquesm wrote:
| On behalf of all the mice, thank you very much for doing this.
| I'm all for modern medicine but the number of mice, primates
| and other mammals that we kill in the name of science every
| year does not sit right with me.
| ramraj07 wrote:
| I've always felt that if there was _any_ morally acceptable
| reason to harm and kill animals it is for the sake of
| (reasonable) medical research. In principle the ethics board
| is there to make sure this is true but in practice they
| rarely do anything about it. Perhaps the real way to solve
| that problem is hold the IrBs to a higher standard and make
| them do their job?
| jacquesm wrote:
| I always try to reverse a situation to see if it makes
| sense, and then I ask myself: what would we think if aliens
| came to earth to experiment on us with untested medicine,
| kill us afterwards and only when it is perfectly safe on us
| they would apply it to themselves. I believe a large
| fraction of humanity would say that that is unethical and
| they'd have all kinds of cognitive dissonance to deal with
| (and associated reasons why this is different) to explain
| why what we do is ok.
|
| 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.
| rdifazio wrote:
| We feel exactly the same way. Not only is it unacceptable
| that over 110 million animals a year are sacrificed for
| research, but these models do a terrible job of
| translating to humans and in most cases cannot even model
| the disease of interest but are used regardless. I used
| to work in tuberculosis where mice are predominantly used
| even though they do not get the disease and the disease
| they do get has the exact opposite pathology as a human.
| jacquesm wrote:
| If it's ok with you I will point some investors in your
| direction that are doing deals in this space.
| rdifazio wrote:
| We agree that this would be an important step. That being
| said, there is a paucity of models that would make suitable
| replacements to animal models. People are working on this
| issue, but many more people need to be working on
| developing better in vitro systems. Even with our platform,
| animal models still have to be used for certain assays
| (e.g. ADME) but we hope that one day this will not be the
| case.
| mldonahue wrote:
| We are Matt and Danny, the founders of Kodex
| (https://www.kodex.us). Kodex makes it easy for companies to
| process and respond to subpoenas from governments around the
| world.
|
| Agencies, like the FBI, subpoena user data from thousands of
| companies around the world, and companies largely rely on email,
| fax, and spreadsheets to manage them. When I (Matt) was in the
| FBI, I 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. We've got a demo video
| up at https://www.youtube.com/watch?v=Dw-hd9ZyQmk.
|
| 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.
| sergiotapia wrote:
| keeping this company in my library of saas's to use.
| mldonahue wrote:
| Great way of looking at it - good to have on deck even if you
| haven't yet gotten a data request, because you never know
| when the "flood gates" might open and bog your company down.
| anaskar wrote:
| love this! needed this at the last company I worked out. Was
| always surprised how manual and generally not secure the whole
| process seemed to me.
| mldonahue wrote:
| Thanks! So surprising how hard it is for companies to handle
| these requests. Love to learn more about your experience with
| it!
| ycorvar wrote:
| Hi there! We are Orestis and Urs from Zeit Medical
| (https://www.zeitmedical.com). We enable fast stroke detection at
| home.
|
| 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!
| gtirloni wrote:
| I know nothing about strokes and who's at risk. Perhaps the
| website could be improved in that regard because, after reading
| it, I have no idea if I should buy it for myself or family.
| ycorvar wrote:
| Thank you for pointing this out. We are working on a "educate
| yourself about stroke" page that we will add in our website.
|
| In the meantime: There are some great resources at
|
| 1) cdc : https://www.cdc.gov/stroke/facts.htm 2) aha
| :https://www.stroke.org/
| dr_ wrote:
| Congrats on your launch. Question, if the device is suggesting
| the user may be developing a stroke - what do they do? Do they
| go to the ER and show the docs that there's abnormal electrical
| activity so imaging of the brain must be done? Without physical
| symptoms, I'm not sure most ERs would be prepared to deal with
| this...or would they? Or is it assumed symptoms would develop
| by the time the patient arrives to the ER?
| [deleted]
| ycorvar wrote:
| 1) Our algos are designed to detect brain activity patterns
| that are associated with the onset of stroke. Detection of
| these patterns will send an alert to the individual, their
| caregivers, and 911 (can opt out).
|
| 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.
| dhr wrote:
| Very interesting!
|
| 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.
| ycorvar wrote:
| Thank you for the insightful comments and questions!
|
| 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.
| jranieri wrote:
| Best of luck to Orestis & co, they have been investigating this
| domain for many years and they are in a great position to find
| the product-market fit.
| ycorvar wrote:
| Thank you!
| Mizza wrote:
| Would love it if you could detect hemorrhagic vs ischemic so
| people at risk could keep tPA at home!
| jitl wrote:
| How do outcomes for stroke patients vary based on treatment?
| ycorvar wrote:
| Time to treatment is the most important factor in defining
| stroke treatment outcomes. Stroke outcomes are quantified at
| 90d post event with a metric called Modified Rankin Scale.
| The treatment strategy is defined based on the type,
| location, and severity. The two options we have for ischemic
| strokes (i.e.85% of all strokes) are TPA (clotbusting
| medication) and thrombectomy (catheter based mechanical
| removal of the clot). Each of the them has its advantages and
| disadvantages but the common denominator is that the earlier
| the patient arrives in the hospital, the more efficacious
| they are.
| jitl wrote:
| I think you should further synthesize and emphasize these
| facts in your marketing - otherwise, the impact and
| importance of your work isn't apparent to laypeople.
| ycorvar wrote:
| Thank you for this insight. Communicating accurately the
| value is a very important aspect in what we are building.
| agustif wrote:
| Could this be used outside of the US? Like in Mexico
|
| Would it be useful for someone who had small lacunar strokes
| which provoked parkinson?
|
| Thanks, awesome company
| ycorvar wrote:
| Thank you for your comments!
|
| 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.
| Rastonbury wrote:
| Is there anyway to put this technology on my wrist on into a
| t-shirt, or even implant? I like the idea I have higher risk
| factors for stroke, but I'm not too keen on wearing a headband
| nightly.
| ycorvar wrote:
| Thank you for the comment!
|
| 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 :)
| samename wrote:
| Looks amazing!
|
| Your website also mentions seizures. Are you trying to get FDA
| clearance for both?
|
| Also, why did you choose the subscription route?
| WORMS_EAT_WORMS wrote:
| Super neat...
|
| - 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?
| ycorvar wrote:
| Hi WORMS_EAT_WORMS
|
| 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.
| lharries wrote:
| This looks fantastic! I'd love to know what are the signals and
| models you're using to detect strokes? (any papers you could
| link to would be awesome) And what's the accuracy like?
|
| Also, are you thinking you'll try and sell into hospitals or
| purely D2C?
| ycorvar wrote:
| Thank you for the comment !!
|
| 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.
___________________________________________________________________
(page generated 2021-08-12 23:00 UTC)