641 karma · joined July 9, 2011
If you want to work on solving this with us, check out https://picnichealth.com/careers, or shoot me an email: `${firstName}@${companyTld}`.
Yes, value is hard to calculate, but luckily market pricing mechanisms exist exactly for this purpose. There isn't a better number to use than what people are willing to pay for them.
So he's saying that on an enterprise plan, he'd be spending $2,180.16. He's not paying that much, but enterprises are.
Conceptually, I think that is the right analogy to think about. Prediction markets "want" to be a more accurate source of information, just like stock markets, so from that lens "getting" information to be more accurate is good. When government officials are placing bets on prediction markets, though, it's a massive violation of operational security, and leaking confidential information. They probably think that they are acting anonymously, but it creates so many opportunities for unfriendly state actors to get information, especially if people do it consistently.
(comment below: https://news.ycombinator.com/item?id=44804528 )
Using non-seasonally adjusted St. Louis FRED data (https://fred.stlouisfed.org/series/NA000349Q), and the AI CapEx spending for Meta, Alphabet, Microsoft, and Amazon from the WSJ article (https://www.wsj.com/tech/ai/silicon-valley-ai-infrastructure...):
-------------------------------------------------
Q4 2025 consumer spending: ~$5.2 trillion
Q4 2025 AI CapEx spending: ~$75 billion
-------------------------------------------------
Q1 2025 consumer spending: ~$5 trillion
Q1 2025 AI CapEx spending: ~$75 billion
-------------------------------------------------
Q2 2025 consumer spending: ~$5.2 trillion
Q2 2025 AI CapEx spending: ~$100 billion
-------------------------------------------------
So, non-seasonally adjusted consumer spending is flat. In that sense, yes, anything where spend increased contributed more to GDP growth than consumer spending.
If you look at seasonally-adjusted rates, consumer spending has grown ~$400 billion, which might outstrips total AI CapEx in that time period, let alone growth. (To be fair the WSJ graph only shows the spending from Meta, Google, Microsoft, and Amazon. But it also says that Apple, Nvidia, and Tesla combined "only" spent $6.7 billion in Q2 2025 vs the $96 billion from the other four. So it's hard to believe that spend coming from elsewhere is contributing a ton.)
If you click through the the tweet that is the source for the WSJ article where the original quote comes from (https://x.com/RenMacLLC/status/1950544075989377196) it's very unclear what it's showing...it only shows percentage change, and it doesn't even show anything about consumer spending.
So, at best this quote is very misleadingly worded. It also seems possible that the original source was wrong.
People in these communities are generally quite smart, and it’s seductive to reason in a purely logical, deductive way. There is real value in thinking rigorously and in making sure you’re not beholden to commonly held beliefs. But, like you said, reality is complex, and it’s really hard to pick initial premises that capture everything relevant. The insane conclusions they get to could be avoided by re-checking & revising premises, especially when the argument is going in a direction that clashes with history, real-world experience, or basic common sense.
We train on real records, and even though they are de-identified in training we still have to keep the model closed and under careful management to protect against the possibility of information leaking.
We are, though, definitely invested in this corner of research, and want to be able to work with others to push medical AI forward.
Given that, the best model for us is to collaborate on an engagement-by-engagement basis. For now we'd look to find ways to do the work directly involving LLMD within our systems.
If you research in the field and have some ideas, I'd love to chat!
Accuracy and deploying in appropriate use cases is key for real world use. Building guardrails, validation, continuous auditing, etc is a larger amount of work than model training.
We don't deploy in EHRs or sell to physicians or health systems. That is a very challenging environment, and I agree that it would be very difficult to appropriately deploy LLMs that way today. I know Epic is working on it, and they say it's live in some places, but I don't know if that's true.
Our main production use case for LLMD at PicnicHealth is to improve and replace human clinical abstraction internally. We've done extensive testing (only alluded to in the paper) comparing and calibrating LLMD performance vs trained human annotator performance, and for many structuring tasks LLMD outperforms human annotators. For our production abstraction tasks where LLMD does not outperform humans (or where regulations require human review), we use LLMD to improve the workflow of our human annotators. It is much easier to make sure that clinical abstractors, who are our employees doing well-defined tasks, understand the limitations in LLM performance than it would be to ensure that users in a hospital setting would.
When learning to program, I found typing out code samples had a similar effect to writing them out by hand, and felt more natural to the domain. But in other subjects in school, it felt like my comprehension was lower when I typed lecture notes instead of handwriting them. I was never sure whether that was something inherent to hand writing vs typing or it was just because I had more of a barrier between typing and thinking than I did with handwriting.
It always seemed clear that the value of writing something verbatim was that it forced your brain to internalize it in a way you don’t need to when reading. It takes longer to hand write than to type — maybe that is the value of hand writing vs typing? Or when typing I needed to think more about the act of typing, whether that was thinking about formatting/positioning or just being less natural than handwriting? Maybe programming is just a special case where you always think through typing?
I lean towards thinking it’s somewhat domain specific. Clearly with physics or math if you had to typeset equations with LaTeX that would get in the way, and typing would be a barrier to understanding. With programming, every idea is expressed through typing, and so typing is a natural way to imprint ideas on your brain.
Interviewing elsewhere seems like the right thing to do. I'm confident there are environments out there where other engineers would challenge you.
It's possible that could be the case at my company, PicnicHealth. If you'd be interested in chatting, reach out (email in profile)
PicnicHealth is building healthcare's missing data layer, making medical data patient-centric, computable, and complete. We collect and structure medical records for patients, empowering them to monitor and control their care. Patients can consent to share their anonymized data with life sciences researchers working to better understand disease progression and treatment.
We just announced our $25m Series B and are growing quickly. We're hiring for front-end, full-stack, data engineering, ML, data science, and product, among other roles. Join kind, focused, mission-driven team using machine learning and modern software development practices to improve health.
PicnicHealth works with patients to collect, digitize, and manage their medical records, empowering them to monitor and control their care via a personal health timeline. Through partnerships with life sciences companies, we aggregate and organize data from groups of research volunteers, which helps power some of today’s most cutting-edge medical research.
We also just announced our Series A & B funding rounds (totaling $35M) today.
We're hiring for:
* Data Engineers
* Site Reliability Engineers
* Engineering Managers
* Front-End Engineers
* Full-Stack Engineers
* Data Scientists
* Product Managers
And more. Check out a full list: https://picnichealth.com/careers
Tech Stack: Our main web service is in Node.js, and most other services are in Python (mostly machine learning services, using Keras, Tensorflow, etc). Our frontend is React + Redux, database is PostgreSQL, and services run in a Kubernetes cluster hosted on Google Cloud Platform (Google Kubernetes Engine).
PicnicHealth works with patients to collect, digitize, and manage their medical records, empowering them to monitor and control their care via a personal health timeline. Through partnerships with biotech, genomics, and pharma companies, we also aggregate and organize data from big groups of volunteers, which helps power some of today’s most cutting-edge medical research.
To learn more about who we are, our engineering culture, and whether this is the right place for you, read our Key Values profile: https://www.keyvalues.com/picnichealth
You can see all of our open roles here: https://grnh.se/3b566ba92
* Data Engineer: https://team.picnichealth.com/careerdetails?gh_jid=465624300...
* DevOps Engineer: https://team.picnichealth.com/careerdetails?gh_jid=429762800...
* Engineering Manager: https://team.picnichealth.com/careerdetails?gh_jid=437728600...
* Front-End Engineer: https://team.picnichealth.com/careerdetails?gh_jid=429755900...
* Full-Stack Engineer: https://team.picnichealth.com/careerdetails?gh_jid=429692900...
* Machine Learning Engineer: https://team.picnichealth.com/careerdetails?gh_jid=429760100...
* Data Scientist / Biostatistician: https://team.picnichealth.com/careerdetails?gh_jid=466020200...
* Product Manager, Patient Product: https://team.picnichealth.com/careerdetails?gh_jid=437728800...
Tech Stack: Our main web service is in Node.js, and most other services are in Python (mostly machine learning services, using Keras, Tensorflow, etc). Our frontend is React + Redux, database is PostgreSQL, and services run in a Kubernetes cluster hosted on Google Cloud Platform (Google Kubernetes Engine).
PicnicHealth works with patients to collect, digitize, and manage their medical records, empowering them to monitor and control their care via a personal health timeline. Through partnerships with biotech, genomics, and pharma companies, we also aggregate and organize data from big groups of volunteers, which helps power some of today’s most cutting-edge medical research.
To learn more about who we are, our engineering culture, and whether this is the right place for you, read our Key Values profile: https://www.keyvalues.com/picnichealth
You can see all of our open roles here: https://grnh.se/3b566ba92
* Engineering Manager: https://team.picnichealth.com/careerdetails?gh_jid=437728600...
* Front-End Engineer: https://team.picnichealth.com/careerdetails?gh_jid=429755900...
* Full-Stack Engineer: https://team.picnichealth.com/careerdetails?gh_jid=429692900...
* Machine Learning Engineer: https://team.picnichealth.com/careerdetails?gh_jid=429760100...
* Product Manager, Patient Product: https://team.picnichealth.com/careerdetails?gh_jid=437728800...
Tech Stack: Our main web service is in Node.js, and most other services are in Python (mostly machine learning services, using Keras, Tensorflow, etc). Our frontend is React + Redux, database is PostgreSQL, and services run in a Kubernetes cluster hosted on Google Cloud Platform (Google Kubernetes Engine).
PicnicHealth works with patients to collect, digitize, and manage their medical records, empowering them to monitor and control their care via a personal health timeline. Through partnerships with biotech, genomics, and pharma companies, we also aggregate and organize data from big groups of volunteers, which helps power some of today’s most cutting-edge medical research.
To learn more about who we are, our engineering culture, and whether this is the right place for you, read our Key Values profile: https://www.keyvalues.com/picnichealth
You can see all of our open roles here: https://grnh.se/3b566ba92
* Engineering Manager: https://team.picnichealth.com/careerdetails?gh_jid=437728600...
* Front-End Engineer: https://team.picnichealth.com/careerdetails?gh_jid=429755900...
* Full-Stack Engineer: https://team.picnichealth.com/careerdetails?gh_jid=429692900...
* Machine Learning Engineer: https://team.picnichealth.com/careerdetails?gh_jid=429760100...
* Product Designer: https://team.picnichealth.com/careerdetails?gh_jid=429763300...
* Product Manager, Patient Product: https://team.picnichealth.com/careerdetails?gh_jid=437728800...
* DevOps Engineer: https://team.picnichealth.com/careerdetails?gh_jid=429762800...
Tech Stack: Our main web service is in Node.js, and most other services are in Python (mostly machine learning services, using Keras, Tensorflow, etc). Our frontend is React + Redux, database is PostgreSQL, and services run in a Kubernetes cluster hosted on Google Cloud Platform (Google Kubernetes Engine).
PicnicHealth works with patients to collect, digitize, and manage their medical records, empowering them to monitor and control their care via a personal health timeline. Through partnerships with biotech, genomics, and pharma companies, we also aggregate and organize data from big groups of volunteers, which helps power some of today’s most cutting-edge medical research.
To learn more about who we are, our engineering culture, and whether this is the right place for you, read our Key Values profile: https://www.keyvalues.com/picnichealth
You can see all of our open roles here: https://grnh.se/3b566ba92
* Engineering Manager: https://team.picnichealth.com/careerdetails?gh_jid=437728600...
* Front-End Engineer: https://team.picnichealth.com/careerdetails?gh_jid=429755900...
* Full-Stack Engineer: https://team.picnichealth.com/careerdetails?gh_jid=429692900...
* Machine Learning Engineer: https://team.picnichealth.com/careerdetails?gh_jid=429760100...
* DevOps Engineer: https://team.picnichealth.com/careerdetails?gh_jid=429762800...
* Product Designer: https://team.picnichealth.com/careerdetails?gh_jid=429763300...
* Product Manager, Patient Product: https://team.picnichealth.com/careerdetails?gh_jid=437728800...
Tech Stack: Our main web service is in Node.js, and most other services are in Python (mostly machine learning services, using Keras, Tensorflow, etc). Our frontend is React + Redux, database is PostgreSQL, and services run in a Kubernetes cluster hosted on Google Cloud Platform (Google Kubernetes Engine).
Picnic’s mission is to structure the world’s medical data to make it useful. We work directly with patients to collect, digitize, and manage their complete medical records, giving them with control over their care. Beyond serving patients directly, we partner with biotech, genomics, and pharma companies who sponsor PicnicHealth accounts for research volunteers. Through this work we’re building the data sets that power some of today’s most cutting edge medical research. Our stack is React/Redux, Node, Python, Keras, PostgreSQL, Kubernetes.
Our product has literally saved some of our users' lives by unearthing issues in their medical records. We're growing rapidly — on pace for 4x team this year. Our team is smart, hard-working, and passionate about fixing healthcare.
The constitutional part is important too — it limits what people, and their representatives, can do even if they have a majority.
Our product has literally saved some of our users' lives by unearthing issues in their medical records. We're growing rapidly — on pace for 20x this year. Our team is smart, hard-working, and passionate about fixing healthcare.
We've chimed in a few other parts of comments, but at PicnicHealth this is exactly what we're working on. If you're interested in fixing this problem we'd love to talk.
Unfortunately, the kind of experiences described are extremely common in transfer-of-care settings. When we were starting PicnicHealth, my grandfather was in-and-out of several different ICUs. Preventable mistakes when moving between facilities and providers — inadvertently changed medication dosages, missed therapy regimens, un-transferred test results — created health emergencies that kept pushing him back further and further from recovery. He ultimately passed away. We had these problems around information management and transfer even though my dad (my grandfather's son) is a doctor, and was continuously in touch with the different care teams. Without a central, complete source of information, things will always get missed.
Patients and doctors deserve solutions to this problem today. Like the author said, you can only piece together a patient's medical history if you're willing to deal with records in any form, including faxing and scanning paper and mailing CDs. It's hard, dirty work, but it's the only way to get everything together. PicnicHealth does this so patients don't have to. And gathering the records is actually just the first part —you need to structure and normalize information in the different records so it's possible to do things like view trends and use control-find.
Full electronic interoperability is slowly coming, but it's been slowly coming for more than 20 years. I would be shocked if in 10 years faxes aren't still being sent. We need to push to make interoperability happen as quickly as possible, but in the meantime patients and their care can't wait.
Our stack is React/Redux, Node, Python, Keras, PostgreSQL, Kubernetes.
Our product has literally saved some of our users' lives by unearthing issues in their medical records. We're growing rapidly — on pace for 20x this year. Our team is smart, hard-working, and passionate about fixing healthcare.
Learn more at team.picnichealth.com/jobs?src=hn
Beyond that, a lot of the most important information is encoded in free text fields, and so isn't directly analyzable. And even when information is mapped to codes from standard medical ontologies, there's no guarantee that when that information is transferred in HL7 formats it includes the code from the ontology.
It's not at all clear what the optimal way to structure medical information should be, so it's no surprise that there's a huge amount of variance out in the world. HL7 is quite old (v2 was made in 1989), and every new variant has to support the existing variants. EHRs were originally designed around billing and administrative workflows, so it's also not surprising that the data structures aren't great for analyzing data or treating patients.
They have 12 hospitals participating right now [2], which is in line with the ~10 systems that interoperability plays typically get on board. Apple has been moving on health records for a while, with their acquisition of Gliimpse [3] a couple years ago a clear indication, and I had hoped that Apple would have been able to get more systems participating before they made an announcement. 12 systems is a far cry from the 5,500 hospitals [4] and 230,000 practices [5] in the US.
In order to make medical records really useful for people, they needs to have all of their records. That means records from whatever system they've been seen at, and all of the information in those records. Every purely electronic approach to aggregating records that I've seen doesn't get doctors notes, procedure reports, pathology reports, radiology reports or medical imaging (x-rays, MRIs, CTs, etc). Sadly, it looks like Apple's attempt also won't address those issues.
Collecting medical records is an extremely hard problem. Technical integration is not only expensive and annoying (see many other comments about the shittiness of HL7, which FHIR is the latest, least-bad iteration of), but health systems don't have strong incentives to push interoperability. Health systems have way bigger IT problems facing them than aligning with interoperability standards (e.g., update the failing, 10-year-old software in the pediatric ICU), releasing records automatically could open them up to a lot ill-defined of legal risk (is a health system liable for what happens to information it releases to third parties?), and interoperability is kinda against business incentives (more interoperability => easier to lose patients). It doesn't look like Apple is taking a fundamentally different approach than Google Health did to any of these incentive problems (if we build, it they will come).
disclosure: I'm one of the founders of PicnicHealth (YC S14), and follow these things pretty closely. If you want to chat about the space, feel free to email me: troy{at}picnichealth{dot}com
[1]: http://argonautwiki.hl7.org/index.php?title=Main_Page
[2]: https://www.apple.com/newsroom/2018/01/apple-announces-effor...
[3]: https://techcrunch.com/2016/08/22/apple-acquired-gliimpse-a-...
[4]: https://www.aha.org/statistics/fast-facts-us-hospitals
[5]: https://en.wikipedia.org/wiki/Group_medical_practice_in_the_...
Picnic’s mission is to structure the world’s medical data to make it useful. We work directly with patients to collect, digitize, and manage their complete medical records, giving them with control over their care. Beyond serving patients directly, we partner with biotech, genomics, and pharma companies who sponsor PicnicHealth accounts for research volunteers. Through this work we’re building the data sets that power some of today’s most cutting edge medical research.
Our stack is React/Redux, Node, Python, Keras, PostgreSQL, Kubernetes.
Learn more at team.picnichealth.com/jobs