Live data from Hacker News

Launch HN: Metriport (YC S22) – Open-source API for healthcare data exchange

news.ycombinator.com

91–100 of 103 posts

Re: Launch HN: Metriport (YC S22) – Open-source API for healthcare data exchange

#91
post #61

Earlier quoted context omitted.

Health optimization based on literature searches is a fool's errand. A certain niche segment of the "worried well" is constantly reading studies (often of questionable quality) and chasing marginal gains with the latest drugs, supplements, recovery modalities, or whatever. Meanwhile they still have poor sleep hygiene, insufficient exercise, and unresolved emotional problems. Major in the major, minor in the minor. Th…

Interesting yes, we've seen demand for the optimization stuff but admittedly I am in a bubble here (close with the biohacking community). It may turn out to be the case that more banal cases (I have a cold, what's the fastest way for me to get symptomatic treatment? I have X symptom, what's the fastest way to be routed to the right specialist, etc. The doctor told me XYZ, how do I remember that and what's the best wa…

No offense but the whole "biohacking" and "quantified self" community is mostly a clown show. It might be a fun hobby but there's little or no reliable evidence that any of that stuff actually leads to improved outcomes in terms of lifespan or healthspan or performance or whatever. Any business built around that community might get a few early adopters but won't cross the chasm to the mainstream market.

And I write this as someone who has personally wasted money on stuff like genetic tests for athletic performance. Interesting, but not actionable.

For common symptoms, conditions, and medications consumers mostly just rely on WebMD or similar sites.

Re: Launch HN: Metriport (YC S22) – Open-source API for healthcare data exchange

#92
post #84

Earlier quoted context omitted.

Interesting, up north the ISO 13485 certification etc. is required to even deploy an App, as your phone would be considered a medical device under the rules if used for diagnostics and or reporting. Don't get me wrong, I am sure people have no issue paying the $84k each release cycle to be cleared as compliant. Notably, our health authority legally can't buy software without these certifications, and for the past 6 y…

I'm not sure what you mean by "mystery commits". Health plans are legally required to accept transactions that conform to CMS adopted standards. They don't know or care what software is used to generate those transactions. https://www.cms.gov/priorities/key-initiatives/burden-reduct...

For regulatory reasons, the slicer.org team found out after the software was written... that it was illegal to deploy in a medical context within the US.

The reason was you can't legally use software with patchwork origins and licenses to cobble together something where the authors are not able to be found/held liable for damages if they accidentally injure someone.

If the data is not being used in _any_ way for patients diagnostics/e-record roles, than your team might get away with just clearing HIPAA rules in the US (not sure how each state would handle that exception.)

You have been warned about the historical rules, but if something changed since I was last in that Circus... than I hope the project does well.

It is always wise to talk with a local legal specialist to clear up current rules. I'd wager people had a billion reason$ to keep things as they were... =)

Re: Launch HN: Metriport (YC S22) – Open-source API for healthcare data exchange

#93
post #84

Earlier quoted context omitted.

I'm not sure what you mean by "mystery commits". Health plans are legally required to accept transactions that conform to CMS adopted standards. They don't know or care what software is used to generate those transactions. https://www.cms.gov/priorities/key-initiatives/burden-reduct...

For regulatory reasons, the slicer.org team found out after the software was written... that it was illegal to deploy in a medical context within the US. The reason was you can't legally use software with patchwork origins and licenses to cobble together something where the authors are not able to be found/held liable for damages if they accidentally injure someone. If the data is not being used in _any_ way for pati…

Wrong. Merely storing clinical data or providing it to clinicians who use it for diagnostics isn't sufficient for software to be considered an FDA regulated medical device. I have actually built such software and was careful to avoid adding any features that would make it a medical device. Open source software has being used legally by provider organizations for decades.

Instead of remaining ignorant and spreading secondhand misinformation you can literally just go read the federal regulations and supplementary guidance. Or just ask the FDA for a formal opinion letter if you're in a gray area. This is basic stuff, not hard to find or understand.

Re: Launch HN: Metriport (YC S22) – Open-source API for healthcare data exchange

#94
post #93

Earlier quoted context omitted.

For regulatory reasons, the slicer.org team found out after the software was written... that it was illegal to deploy in a medical context within the US. The reason was you can't legally use software with patchwork origins and licenses to cobble together something where the authors are not able to be found/held liable for damages if they accidentally injure someone. If the data is not being used in _any_ way for pati…

Wrong. Merely storing clinical data or providing it to clinicians who use it for diagnostics isn't sufficient for software to be considered an FDA regulated medical device. I have actually built such software and was careful to avoid adding any features that would make it a medical device. Open source software has being used legally by provider organizations for decades. Instead of remaining ignorant and spreading se…

I too have written software for both Canada and the US markets.

Don't YOLO this one kid.

(the fact you didn't mention the 2 other common ISO standards I omitted on purpose, means you have not done your work properly for "years" as you put it.)

Re: Launch HN: Metriport (YC S22) – Open-source API for healthcare data exchange

#95

Earlier quoted context omitted.

I suspect that having a hosted solution -one that is very secure, could be quite lucrative. This, on its own, is probably not something that folks could just throw onto any server, and expect reputable heath providers to use (at least, I hope not). Auditing and validation ain't cheap. I applaud the idea, and hope that it works out. Most health providers still require faxes, which is a huge pain in the butt. I have al…

> one that is very secure Another reason we're open source - better security. > Most health providers still require faxes, which is a huge pain in the butt. Yes indeed - mindblowing how such critical data still relies on faxes in 2024. > I have also heard many complaints about Epic Systems. Yeah, Epic is not perfect, but they are ubiquitous in healthcare - and Metriport provides a nice interface to pull/push data to…

I wish you great luck. I sincerely hope it works out.

> Epic is not perfect

They have managed to do great consolidation, but the people that I hear complaints from, are the end-users (doctors, nurses, and first-line medical admins). They are a tough crowd to please (most of the medical folks I know personally, are technophobes), but I have seen some of the Epic interfaces, and they could use improvement; even for a techie, like me.

It appears as if Epic is pretty good at marketing to decision-makers (high-level administrators), and maybe have been a bit less diligent on UX design. Good money-making policy, but it also means that an open API opens the field to competitors that do a better job of serving end-users. That could give Epic a reason to throw up roadblocks. Incumbents don't like upstarts.

Re: Launch HN: Metriport (YC S22) – Open-source API for healthcare data exchange

#96
post #84

Earlier quoted context omitted.

I'm not sure what you mean by "mystery commits". Health plans are legally required to accept transactions that conform to CMS adopted standards. They don't know or care what software is used to generate those transactions. https://www.cms.gov/priorities/key-initiatives/burden-reduct...

For regulatory reasons, the slicer.org team found out after the software was written... that it was illegal to deploy in a medical context within the US. The reason was you can't legally use software with patchwork origins and licenses to cobble together something where the authors are not able to be found/held liable for damages if they accidentally injure someone. If the data is not being used in _any_ way for pati…

OpenEMR is an OSS practice management system and is certified for medical use by ONC in the USA. It has been deployed in the medical context in many jurisdictions in the USA. There are some government agencies / larger organizations that require 'sole-sourcing' which I think is what you are referring to, it varies by jurisdiction, but I've never heard of anything at the federal level and widespread state level that 'requires' this. If this was the case I doubt we'd have made it through the many times we've been certified.

I will mention that the certification process is expensive. It ranges in the 100K-250K range each time we go through it in fundraising and to go through the certification process.

Re: Launch HN: Metriport (YC S22) – Open-source API for healthcare data exchange

#97

Earlier quoted context omitted.

For regulatory reasons, the slicer.org team found out after the software was written... that it was illegal to deploy in a medical context within the US. The reason was you can't legally use software with patchwork origins and licenses to cobble together something where the authors are not able to be found/held liable for damages if they accidentally injure someone. If the data is not being used in _any_ way for pati…

OpenEMR is an OSS practice management system and is certified for medical use by ONC in the USA. It has been deployed in the medical context in many jurisdictions in the USA. There are some government agencies / larger organizations that require 'sole-sourcing' which I think is what you are referring to, it varies by jurisdiction, but I've never heard of anything at the federal level and widespread state level that '…

In general, up here the 3 relevant ISO certifications (around $45k to $80k each) that apply to e-record and diagnostic systems are required, or software cannot be legally purchased by the health authority. For many reasons, the e-record system software was written in partnership between a large telecom and Microsoft.

slicer.org has their detailed story why "3D Slicer is NOT FDA approved", and its unfortunate given the transient nature of volumetric imaging data formats.

My point was this area is a mine-field of regulation. Generally, the above rules trip the instant a doctor uses something to diagnose or communicate patient data. Notably, the same software is deployed across provinces and states... but will obviously have different certification requirements in each locale.

Some people seem to get really rude over the most mundane details. =3

Re: Launch HN: Metriport (YC S22) – Open-source API for healthcare data exchange

#98
post #93

Earlier quoted context omitted.

Wrong. Merely storing clinical data or providing it to clinicians who use it for diagnostics isn't sufficient for software to be considered an FDA regulated medical device. I have actually built such software and was careful to avoid adding any features that would make it a medical device. Open source software has being used legally by provider organizations for decades. Instead of remaining ignorant and spreading se…

I too have written software for both Canada and the US markets. Don't YOLO this one kid. (the fact you didn't mention the 2 other common ISO standards I omitted on purpose, means you have not done your work properly for "years" as you put it.)

It's always disappointing to see such ignorance in HN comments like this. While there are some relevant technical standards cross listed with ISO, adherence to ISO standards isn't legally required for products like Metriport. Seriously buddy, you can just go read the FDA regulations instead of making a fool of yourself. But if you'd like to keep looking silly then feel free to have the last word.

Re: Launch HN: Metriport (YC S22) – Open-source API for healthcare data exchange

#99

Earlier quoted context omitted.

For regulatory reasons, the slicer.org team found out after the software was written... that it was illegal to deploy in a medical context within the US. The reason was you can't legally use software with patchwork origins and licenses to cobble together something where the authors are not able to be found/held liable for damages if they accidentally injure someone. If the data is not being used in _any_ way for pati…

OpenEMR is an OSS practice management system and is certified for medical use by ONC in the USA. It has been deployed in the medical context in many jurisdictions in the USA. There are some government agencies / larger organizations that require 'sole-sourcing' which I think is what you are referring to, it varies by jurisdiction, but I've never heard of anything at the federal level and widespread state level that '…

It's kind of hilarious how some people with no real industry experience aren't able to do a simple search on the CHPL. Obviously, there's nothing illegal about using OpenEMR regardless of who wrote the code. And certification isn't even necessarily required. Providers who don't participate in certain federal or state programs are free to use non-certified software as long as they're able to comply with applicable interoperability and privacy/security regulations; regulatory compliance and enforcement for that stuff is at the provider organization level, not at the product level.

Re: Launch HN: Metriport (YC S22) – Open-source API for healthcare data exchange

#100
post #99

Earlier quoted context omitted.

OpenEMR is an OSS practice management system and is certified for medical use by ONC in the USA. It has been deployed in the medical context in many jurisdictions in the USA. There are some government agencies / larger organizations that require 'sole-sourcing' which I think is what you are referring to, it varies by jurisdiction, but I've never heard of anything at the federal level and widespread state level that '…

It's kind of hilarious how some people with no real industry experience aren't able to do a simple search on the CHPL. Obviously, there's nothing illegal about using OpenEMR regardless of who wrote the code. And certification isn't even necessarily required. Providers who don't participate in certain federal or state programs are free to use non-certified software as long as they're able to comply with applicable int…

"there's nothing illegal about using OpenEMR regardless of who wrote the code"

Indeed, in your area this may be true. However, the health authority can't legally purchase or use these projects without the ISO certs, and thus it is a moot point.

I think we will have to agree to disagree, as there are two truths here. And people seem to be getting emotional about their egos. =)

Post reply on HN