dgoncharov

7 ms·

1.
Metriport (S22) raises $26M to give clinicians insight into any patient question(metriport.com)
9 points by dgoncharov 19d ago|0 comments
2.
Metriport (YC S22) is hiring a security engineer to harden healthcare infra(ycombinator.com)
1 points by dgoncharov 7mo ago
3.
Metriport (YC S22) is hiring a security eng to harden healthcare data infra(ycombinator.com)
1 points by dgoncharov 8mo ago
4.
Metriport (YC S22) is hiring a recruiter(ycombinator.com)
1 points by dgoncharov 11mo ago
5.
Metriport (YC S22) is hiring engineers to improve healthcare data exchange(ycombinator.com)
1 points by dgoncharov 1y ago
6.
by dgoncharov 2y ago
> 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
7.
by dgoncharov 2y ago
> Most traditional provider orgs don't care about open source Depends who you're talking to - from our experience CTOs of large provider orgs love the open source aspect (generally anyone with a tech team). Smaller orgs with no
8.
by dgoncharov 2y ago
Feel free to get in touch with us - we've migrated others of HG, and they can vouch that they get better data density, coverage, quality, and speed with Metriport. > distinguish yourself by providing by excellent consulting services
9.
by dgoncharov 2y ago
> CAIR2 is specific to California. Every state registry has some technical differences in HL7 V2 Didn't know CAIR2 was only used in CA - I guess a correct statement would be every state has an offshoot of HL7v2, with CAIR2 being one
10.
by dgoncharov 2y ago
See the bottom of the post: "We charge per full medical record retrieval for a patient (which we call a query). This starts at $1 per query (with a monthly minimum), and scales down from there based on volume. We only charge for querie
11.
by dgoncharov 2y ago
Roughly 93% of the US population, so just north of 300 million.
12.
by dgoncharov 2y ago
> Is this intended for use by providers or consumers/patients? This currently can only be used by providers, or healthcare IT vendors working with providers. Referring to the post: "using Metriport for patient data exchange tod
13.
by dgoncharov 2y ago
What're you working on in specific? Can help provide clarification if you're able to describe the use case.
14.
by dgoncharov 2y ago
Thank you!!
15.
by dgoncharov 2y ago
Thank you!
16.
by dgoncharov 2y ago
We'd love to open source it - but are too strapped for time to do so. Perhaps one day in the future.
17.
by dgoncharov 2y ago
\m/
18.
by dgoncharov 2y ago
Thank you - it's a difficult problem for sure, but that makes it all the more fun and rewarding. > should be handled on state level Many of the aforementioned HIEs in the US are actually offshoots of state, or federal, government in
19.
by dgoncharov 2y ago
> In the US, this is part of the EHR push, each EHR is supposed to accept any outside application To be explicit for readers here, outside applications can connect to some EHR systems using SMART on FHIR, but not all (this is what Apple
20.
by dgoncharov 2y ago
Thank you! That's right, we can't even request our own records using Metriport - this currently can only be done for a Treatment purpose of use (and opens up a lot gray area of what that means, as you can imagine). The promise of
21.
by dgoncharov 2y ago
Pretty much! We're essentially building a service that leverages multiple networks - from a modern healthcare engineer's perspective, and focusing on product/data usability.
22.
by dgoncharov 2y ago
Thank you! Glad to see more open-source in healthcare - was the idea here sort of like a reusable EHR backend for building digital health products? I see some mention of HAPI FHIR in the repo as well.
23.
by dgoncharov 2y ago
Europe is its own beast of healthcare data problems for sure - perhaps one day. We get asked the fundraising question a lot, especially since we're open source. Once investors understood that we still have a hosted product we charge fo
24.
by dgoncharov 2y ago
Glad you enjoyed the read - we're happy that we landed at a domain/space that we're both passionate about, and is impactful. Pretty great outcome as far as pivots go!
25.
by dgoncharov 2y ago
Yes!! A lot of folk think that the only way to get data into EHRs is by writing one-off integrations with a specific hospital IT system - but you can achieve the same thing using a single Metriport integration. We support 2 methods: (1) upl
26.
by dgoncharov 2y ago
Thank you for the detailed questions - lots to dig into: > In your FHIR implementation, what version of USCDI do you support? I'm assuming you're following US Core profile's with your implementation guides? We will support
27.
by dgoncharov 2y ago
Thank you - glad to see there are others that are aware of the mess of healthcare data! > Would it make sense to go one step further and bet on the future being the cloud - and start supporting existing cloud solution like Google Healthc
28.
by dgoncharov 2y ago
> How does this compare to ehealthexchange Good question! eHealth Exchange (eHEX) is one of 3 national HIEs that we connect to (currently through Carequality). eHEX is mainly focused on connecting to state-level regional HIEs, which cove
29.
by dgoncharov 2y ago
Hahaha definitely feel you there - also see you're a seasoned healthcare vet with the FHIR puns! Integrating with vaccine registries is another unique beast, and we haven't had the pleasure of doing that yet. Each state has actual
30.
Launch HN: Metriport (YC S22) – Open-source API for healthcare data exchange
112 points by dgoncharov 2y ago|101 comments

More ›