Launch HN: Metriport (YC S22) – Open-source API for healthcare data exchange
If you’ve been to doctors in the US, you may have encountered the problem: how does a healthcare provider get access to your up-to-date medical history to treat you properly? Reliance on archaic methods is still the norm: typically you, or your provider, need to call the facilities where you’ve previously received treatment (assuming you remember them all), just to have them send your records via fax (yep, fax). This can take weeks, only then to have a provider sift through hundreds of pages of unstructured docs, just to figure out basic things like your active medication list, what conditions you may have, latest lab results, etc. This not only delays treatment, it can cause improper treatment, since the medical history is critical for treatment decisions.
For example, here’s a crazy story from a customer of ours: recently a patient came to them asking for a specific medication. When the provider pulled their medical history through Metriport, they saw that the patient had had a heart attack in the last 6 months. (The patient had omitted to mention this.) In such a case, the medication they were asking for could cause death! Needless to say, the provider did not fulfill that request—but they did begin to look for medications that could actually work for that patient.
Many providers use Electronic Health Record (EHR) software to manage their patients’ data, but many EHRs don’t talk to each other, which means a patient’s data is more often than not siloed across disparate systems with incompatible data formats. More recently, Health Information Exchanges (HIEs) emerged to make the exchange of patient medical data possible between different providers. HIEs are essentially a peer-to-peer network for clinical data exchange. These networks helped push interoperability in the right direction, but their underlying technology is still based on older tech from the 90s, requiring SOAP-based protocols for transactions, using mostly C-CDAs (XML files), PDFs, and images to exchange medical data. A patient with a chronic condition may have thousands of such files across dozens of providers, and they all contain messy, likely unstructured, and duplicate information. Even if you spend lots of dev time, and money, connecting to all of these exchanges (like we did), you’re still left with the tough problem of making this medical data actually usable for providers.
We did YC in S22, starting with a quantified self personal health app (this was our Show HN: https://news.ycombinator.com/item?id=29800932 - it didn’t get very far!). Working on clinical use cases for the app ran us straight into this insane rats’ nest of 30-year-old technologies, all incompatible with each other, just to integrate medical data into our product. Vendors attempting to solve this problem wanted to lock us into $100k+ yearly contracts without even letting us try their closed-source product! Integration time would have been months, and developer docs were a whole new order of jank. It took us a while to realize there really was no good solution to this—it was hard to believe—but then we started talking to other healthcare companies and found they had the same problem. At that point it was a no-brainer to pivot to this inste...
102 comments
[ 3.2 ms ] story [ 194 ms ] thread"Access comprehensive EHR data for your patients in seconds, with FHIR R4...", I got Vietnam flashbacks from building an app to interface with the NHS Covid Vax certificate, that was my first encounter with FHIR... And honestly, all I wanted by the end of the day was to set myself on FHIR! Such a complex abstraction. Anyway, Godspeed!
Integrating with vaccine registries is another unique beast, and we haven't had the pleasure of doing that yet. Each state has actually has its own registry, they don't even use FHIR, and instead use an even older standard than C-CDAs - CAIR2 HL7v2: https://www.cdph.ca.gov/Programs/CID/DCDC/CAIR/CDPH%20Docume...
We don't support this yet - but we'll get there.
https://repository.immregistries.org/resource/hl7-version-2-...
The CDC IZ Gateway can make it somewhat easier to work with multiple state registries.
https://www.cdc.gov/vaccines/programs/iis/iz-gateway/overvie...
In practice the C-CDAs obtained from providers sometimes include immunization section entries so you can pick up some records that way as well
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 of them, as you mentioned.
> In practice the C-CDAs obtained from providers sometimes include immunization section entries
Yes for sure - we get a lot of those from C-CDAs already, these registries would be just another way to make the data even more authoritative/accurate.
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 cover a different portion of providers than CommonWell, or Carequality do.
For example, Cerner is a major EHR vendor (used by the VA and others) whose data can only be accessed through CommonWell, since they don't participate in other HIEs.
> that have many years of experience
Relatively speaking, modern HIEs are a relatively new concept (Carequality was founded in 2014) - so extra years of experience doesn't necessarily add any value, and usually just results in more legacy tech to deal with!
> charge lower costs?
This isn't necessarily true - since you brought up eHEX, see their pricing page: https://ehealthexchange.org/pricing-payers-vendors-and-for-p...
TL;DR just to get started it's going to cost you $20k + some months to integrate, $12.5k/yr as the base membership fee (up to $400k if you make a lot of money!), and they charge a per-query price.
The caveat here is per-query in eHEX, isn't what a query is in Metriport. They literally mean every single query (remember the HTTP requests to thousands of endpoints to find patient records, each one of those would be a query). So, if you want to integrate with eHEX only to get limited, messy C-CDA data, then you're looking at paying ~$0.80 per full record retrieval for a patient with 2k documents.
I congratulate you on your launch and I'm interested in your converter. I'm surprised you didn't mention the TEFCA effort and wondering if you're planning on becoming your own QHIN (Qualified Health Information Network) or if you just plan on interfacing with all of the major QHIN's?
How are you handling interstate data exchange privacy requirements. Some states have restrictions on what data can be shared across state (thinking about this in terms of things like PDMP queries). I'm also wondering how you are handling the patient data access audit trail as well as information blocking filtering requirements. Perusing your documentation, it looks like you pass along the AuditEvent, does your system create additional audit trails for those who access the patient data? Or is that all being handled upstream w/ your QHINs?
> 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 USCDI v3 (which is the ONC requirement for 2026), and are following US Core as closely as possible with our FHIR converter.
We're working on improving our FHIR documentation across the board, and have the beginnings of a FHIR-specific IG here: https://docs.metriport.com/medical-api/fhir/overview
> I didn't see listed anywhere your capability statement URL that would give insight into what your doing.
Yes good point - raised an issue for this here: https://github.com/metriport/metriport/issues/2142
Please feel free to raise more issues on our repo if you'd like to see other improvements, and it would be great to get in touch about your use case!
> you didn't mention the TEFCA effort and wondering if you're planning on becoming your own QHIN (Qualified Health Information Network) or if you just plan on interfacing with all of the major QHIN's?
Haha this post was already close to exceeding maximum length, so we had to trim it down a bit - we thought no-one would know what TEFCA/QHINs are, but cool to see that you do.
(For anyone reading this, TEFCA is the the document driving changes for different permitted purposes of use, and general governance of the networks, by the ONC. QHINs are one of the outputs of TEFCA, and are a flavor of HIEs that promise to bring more use cases, such as patient access, to the table)
Unfortunately QHINs aren't very meaningful right now, since patient access queries are not mandated to be responded to by TEFCA. One of the HIEs we connect to, CommonWell, is already a QHIN, so we'll look at leveraging that, or becoming one ourselves, as we see fit.
> How are you handling interstate data exchange privacy requirements.
We handle this on a case-by-case basis based on: (1) what state our customers' patients' are located, (2) what kind of data they can/will be sharing, and (3) state requirements as you mention. For example, there is a new bill in California that will require special care of medical info as it pertains to abortion, contraception, and etc: https://trackbill.com/bill/california-assembly-bill-352-heal...
> also wondering how you are handling the patient data access audit trail
All transactions that interface with our system have audit logs attached to them by default (as per HIPAA/SOC2 requirements).
> Or is that all being handled upstream w/ your QHINs?
Nothing is handled upstream with the HIEs we connect to (note that QHINs are a different subject, and just enable future use cases outside of Treatment) - audit logging is up to each member of the network, including us. For example, Carequality only has a directory that implementers connect to, they don't store any data, and their only service is a directory of endpoints (it's more of a framework in that sense).
How does your service differ in practice from existing networks of networks like Health Gorilla and Particle Health?
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 today requires a Treatment purpose of use under HIPAA - which means that only Covered Entities, or Business Associates who work with Covered Entities, can use Metriport."
> Authorized providers can use TEFCA through a QHIN to query for treatment purpose of use, which is supported by all participants.
Yes you can query for Treatment, but you won't get meaningful coverage. QHINs do not have nearly enough adoption to be used for Treatment. Essentially the pool of providers using QHINs is insignificant, so you need to go through existing HIEs to get meaningful coverage.
The driving force behind QHINs is to open up new use-cases for accessing patient data, not necessarily to make the Treatment purpose of use better.
> How does your service differ in practice from existing networks of networks
We're the only vendor that's open source, where you can see and trust what's going on under the hood. Ask other vendors how they do record location, patient matching, or data mapping, and they'll just tell you "trust us, we're the best!".
Additionally, we're the only vendor that is confident enough in our solution to work with companies month-to-month, to show them that our product actually brings them value (and works as advertised) in production. Other vendors will lock you into $120k+ yearly contracts before even showing you production patient data. True story: a provider came to us recently after one of the vendors you mentioned locked them into a yearly contract, and only after the lengthly implementation period did they realize the product didn't work well at all - so a bunch of time/money wasted, and they need to migrate now anyways.
We have many advantages feature-wise as well, feel free to compare our dev docs!
> distinguish yourself by providing by excellent consulting services
We actually work very closely with companies month to month during a pilot period to implement an MVP integration to show them the value of the product for both data pulls, and contribution - consultant-style.
We'd love to chat if you're up for it: https://calendly.com/colinelsinga/metriport-intro
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 tech team don't care as much, you're right, but we also support them through a no-code provider dashboard.
Glad Metriport is addressing this! I hope you will drive a new level of standardization on an open and modern data exchange protocol.
One question: at the product level, 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 Healthcare (FHIR) API (and others) as storage layers?
> 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 Healthcare (FHIR) API (and others) as storage layers?
Oh for sure - to clarify, we're open-source, but we definitely have a managed cloud solution. For our backend, we currently self-host the OSS version of HAPI FHIR on AWS: https://github.com/metriport/fhir-server. It works pretty well for our purposes, and we'd prefer to not use a managed solution like the Google FHIR storage for this. Mainly for customizability, control, and to keep things OSS.
With that being said, people using Metriport can store the FHIR data and raw docs coming from our API in whatever solution they wish - including the Google FHIR storage! Everything is standardized to FHIR R4, so syncing to another backend is straightforward.
In fact, a customer of ours recently used this OSS solution to sync Metriport data to their Google cloud: https://github.com/google/fhir-data-pipes
Great. What I was trying to say is that there may be some value for larger customers if your company were building and managing something like it (basically a Fivetran for FHIR).
Consider someone who is misdiagnosed and switching doctors because they can't get the medical staff to believe them. They would be served by a fresh set of data and if re-diagnosed, so be it.
Under HIPAA, patients do have the legal right to correct errors in their medical records.
https://www.hhs.gov/hipaa/for-individuals/medical-records/in...
Honest question, how was your experience with getting funding on an open source product within healthcare? My experience so far is that the field is, as you put it, 30 years back, also in terms of business models.
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 for, and that we have a large moat since someone could fork our code but it'd be very difficult to run the business (compliance, getting access to the different networks, understanding the niche space, etc) - open source wasn't a hinderance to raising.
One thing we learned though, is that even though every human interacts with the healthcare system in some capacity - very few people know how things actually work. So, we had to tailor our pitches to make investors understand why our product matters, since generally even people that have healthcare experience, have no idea what the hell an HIE is.
That, and our GTM allowed us to sell quickly, without needing to wait for slow moving hospital contracts, as are typical in healthcare - so some decent traction definitely helped.
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 also heard many complaints about Epic Systems.
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 their EHRs!
> 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.
We support 2 methods: (1) uploading FHIR data: https://docs.metriport.com/medical-api/api-reference/fhir/cr..., or (2) uploading documents like C-CDAs, PDFs, and images: https://docs.metriport.com/medical-api/api-reference/documen....
If you send Metriport FHIR data we'll convert it to C-CDAs under the hood when responding to providers in the HIEs, and this data is parsed and integrated as structured data directly in the EHR in the patient's chart. Same thing goes if you upload C-CDAs to Metriport yourself.
You can also share binary docs like PDFs and images, those will also be included in the patient chart in the EHR, but not parsed to discrete structured fields for display.
So concretely, by using Metriport you can pull data from EHRs connected to the HIEs we connect to (like Epic or other major EHRs like Cerner, Athena, etc), and send data back, so that the provider using the EHR can see the updated patient data directly in the chart in the UI.
A health platform I helped build was open sourced[0] (the apps built on it are closed source and deployed in NHS trusts). Feel free to dig around for any inspiration :-)
[0] https://github.com/polaris-foundation
The architecture was that that was a backend for apps, and the individual apps would host a stateless BFF service to translate the backend into what they needed, and then the web/mobile apps would talk to that. HAPI FHIR was integrated for testing reasons; it also spoke HL7v2, for our sins.
I may be in a position to open some of that up before it's lost.
I think the only other useful thing that wasn't added to the Foundation was some HL7 integration code that would sit in a customer environment and forward on requests to that backend securely. I believe that moved on with the software that it was primarily developed for, though, which is an in-hospital tablet based system for recording patient observations.
A big tricky part is understanding all the different health systems that have part of the patient's record. Typically speaking you can scrape all health system FHIR access point's and perform some geo matching to offer the ones they likely have seen. From there you do the Oauth2 dance with each health system where the patient authenticates (if they remember their login) and your app gets a token good for a certain time period after which the patient has to log in again.
The advantage of Metriport's approach is that they are getting a hook into the vendor operated HIEs. The patient doesn't have to remember/select which health care systems that have records for them since the VOHIEs have all that. The big hurdle is managing some authentication on behalf of the patient to a third party that they don't have a direct relationship to, the VOHIE. I suppose the VOHIE can pass the patient off to one of the member health systems and do the same Oauth dance but instead of just getting one health systems data, you get the whole enchilada.
The evil part of the operation is that now Metriport has proxy access to the data and eventually will get hacked and bought by private equity that will sell the data to TransEquirian Insurance Score agencies.
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 Health supports in their PHR) - and this is separate from HIEs. For reasons OP mentioned, this is impractical for treatment at scale, but is currently the best way to get your health records in your pocket, or to insurance companies, for example.
Fasten is a great OSS project that facilitates this flow for individuals, and I'd suggest you check them out: https://github.com/fastenhealth/fasten-onprem
> getting a hook into the vendor operated HIEs
This is a only part of the equation - for example, one of the biggest networks we connect with is Carequality, and this is more of a framework that's not operated by any vendors. Rather, vendors connect to a shared directory and speak the same language for medical data exchange.
> The evil part of the operation is that now Metriport has proxy access to the data and eventually will get hacked
This just speaks even more volumes to our open source approach - we're not hiding behind obscurity for security.
> and bought by private equity that will sell the data to TransEquirian Insurance Score agencies.
Only if someone wants spend a long time in prison! We can not legally do anything with the data we have proxy access to, except deliver it to the healthcare organizations we work with that are involved with treating the patient - nor would we want to. There are acquisition events with healthcare organizations all the time, and the HIPAA rules protecting the data do not change.
Hopefully you can agree that, especially with us being the only vendor in the space that's open source, there is no evil at play.
Just a minor detail here. My understanding from my attendance at some of the ONC Information Blocking seminars is that if the EHR is ONC certified, they are required to provide access to a patient using any app of the patient's choice. The rules are very different if its a provider app or an app that can provide access to data for multiple patients. Unfortunately, not all EHRs are certified (looking at you mental/behavioral health sector, and cash-only EHRs).
We continue to struggle with this in our own EMR implementation as app providers constantly complain that provider/system level access to the data requires manual human intervention, which we aren't going to change anytime soon. Things like Unified Data Access Profiles (UDAP) Dynamic Client Registration are looking to mitigate some of these problems.
What I'm intrigued about with Metriport is that app providers could connect directly to them to get the patient data as long as our EMR feeds data into the HIEs they work with.
>Additionally, using Metriport for patient data exchange today requires a Treatment purpose of use under HIPAA - which means that only Covered Entities, or Business Associates who work with Covered Entities, can use Metriport. This means that companies doing things such as clinical trials recruitment, for example, can’t use Metriport, but a primary care provider, or a clinical decision support vendor, can. This is due to current requirements set forth by HIEs, which may open up to support alternative use cases in the future, such as Individual Access Services (IAS).
Would love clarification.
Thinking is: this was a massive tar pit in the past, new interop laws and AI tooling makes it possible now.
Those other agent features could be useful, though.
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 way to do all the steps required to fulfill? )
is the better play. Still doing a lot of exploration here for sure. Appreciate the insight.
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.
Fasten Health's PHR[0] and MereMedical[1] are both great examples of this. The trade off is that patients need to remember & search for each of their health systems & then login to each of their individual patient portals. It can be a pretty high friction experience.
- [0] https://www.fastenhealth.com/ - [1] https://meremedical.co/
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 TEFCA, and QHINs, is to open up more use cases for data access, like individual access, payment/operations, and etc. We're optimistic that eventually this will become a thing, but there are a lot of politics around this, and full implementation of these use cases has been getting delayed for some time now. It's technically possible today, but responding to requests outside of Treatment is not a MUST, so essentially nobody (namely the big EHRs) will actually respond to IAS requests.
In the meantime though, we're sprinting to hook as many providers up to the networks as possible, which then can share records with their patients.
- [0] https://www.fastenhealth.com/ - [1] https://www.fastenhealth.com/connect/
As a citizen of Estonia, we pretty much have any government service available over the web, and yes, we also get to enjoy state provided health care, which makes things simpler when it comes to having a single unified system for all health care workers, which we have, have had for quite a while, probably for a decade or more. And it works, including patients who can also log into the system to check any data that is collected on their behalf.
> should be handled on state level
Many of the aforementioned HIEs in the US are actually offshoots of state, or federal, government initiatives like TEFCA. We didn't go into details in the post, but the main HIEs are definitely not privately held startups - mostly nonprofit state sponsored organizations.
> we pretty much have any government service available over the web, and yes, we also get to enjoy state provided health care
There are pros/cons of state run centralized government systems for sure - with Metriport as a communication layer, we're hoping to bring providers in the US the best of both worlds for data exchange.
1. Some governments require ISO certifications for security
2. Some standards bodies require commercial accountability (FDA), data site redundancy, and company inspection by a standards body.
3. The ecosystem for the insurance documentation is never open source. It is not only prohibitively expensive, but comes with legal strings in the EULA.
Good luck, but please read the slicer.org story before committing too much time to the project. =)
The standards bodies in the clinical interoperability space aren't accountable to the FDA (although the FDA is a registered organizational member of HL7 and contributes to standards development as a peer to other members). Services like Metriport aren't FDA regulated medical devices. The standards bodies don't inspect implementers.
There are open source libraries for dealing with the data formats used for interactions between providers and health plans (insurers), primarily ASC X12N and NCPDP. The standards documents themselves are somewhat expensive. But Metriport doesn't appear to be playing in that space so it's a moot issue.
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 years only Microsoft offers a framework through their partner for the e-records exchange systems.
There is zero "open" anything in this ecosystem, as commercial insurance won't cover mystery commits.
Best of luck, =)
It is 100% a monopoly, and thus why we left a competing firm a long time ago. =)
https://www.cms.gov/priorities/key-initiatives/burden-reduct...
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... =)
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.
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.)
I would recommend considering programs compatible with your obvious temperament:
https://www.youtube.com/watch?v=XUAsU_zQVMo
Feel free to append any additional off-topic nonsense below if it makes you feel better. I still like you. =3
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.
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
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. =)
I’m a huge fan of Metriport, Dima, and the whole team! I’m constantly impressed by the strides you are making in addressing this significant problem. I often brainstorm company ideas just to have the opportunity to use Metriport.
- Amit
There actually is a standard for converting C-CDA records to FHIR. It isn't 100% complete but serves as a useful starting point. If you find problems with it you can feed those back into the standards process.
http://hl7.org/fhir/us/ccda/
Microsoft has an open source library which works pretty well and I think implements at least part of that standard, although I haven't used it lately.
https://github.com/microsoft/FHIR-Converter
FHIR also includes unstructured narrative text so it isn't necessarily better than C-CDA in that regard. You'll find that data quality problems come down more to provider systems configuration and charting policies rather than data formats.
The problem is that most providers still work on a fee-for-service basis, billing payers (insurers) and patients for individual line items. There's no line item billing code for improving clinical data quality or sharing patient records with other authorized organizations. So they mostly do the bare minimum necessary to comply with government regulations and payer coverage rules.
For example, every doctor is supposed to have a Direct Secure Messaging address listed in NPPES by now so that they can securely email patient records to each other. Every major EHR supports this standard and it can also be used through HISP online portals. But a lot of doctors still have no clue how to do this and haven't registered their address in NPPES (or misunderstood the instructions and put in their own personal Hotmail email address or something). So, they still end up sending faxes.
The situation may eventually improve with the shift to value-based care but this will be a slow process.
I know this wouldn't fly in the US, but it is a very convenient system for people.
There's a lot of similar apps, people seem to use and like all of them, I'm just curious how it looked from the inside of this one.
Working through aggregators such as HIEs eliminates some of those issues.
- [0] https://www.fastenhealth.com/ - [1] https://www.fastenhealth.com/connect/