We're building Health Compiler, devtools and API's that fast-track digital health companies in launching their patient experience apps in days - [https://www.healthcompiler.com/LP-API]
It takes roughly 1-3 months to build an integration (depending on EHR/PMS/Wearables) and high $$ upfront. With our single unified API & simple black of code digital health companies can easily access the data they need.
We are looking for some early feedback from digital health hackers. If you are interested in testing our APIs, please fill out our form and we'll get in touch with you.
We can blame plaid all day but the banks are the ones that created a need for a third party in the first place. How banks didn’t come together and create a more secure and planned version of plaid themselves shows the technical incompetency of the leaders of those banks.
I'm perfectly happy with the existing system of verifying deposits, I don't consider disclosing passwords to be an acceptable solution to a problem that doesn't exist.
The issue with that is waiting 2-3 days for the initial funds transfer to go through, maybe more if it’s a banking holiday. We live in a world where you can get 2 day delivery of most goods. The fact that it takes 2-3 days to even initiate a bank transfer using the old method is just silly
I would love this! It could put plaid and Venmo out of business, but for some reason the banks haven’t done this. Again why I say this is the banks’ fault.
Isn't plaid the company that puts up a phishing-esque 'real looking' bank login page, then captures the login info and then makes that banking data available to whichever third party had set the thing up?
Not sure if they're still doing that. Definitely don't ever want that to happen with my medical records.
That's an interesting idea - although there would need to be a way to prove the data wasn't tampered with, since a lot of companies are using plaid to make decisions on loans and things.
What the banking industry should do is just come up with a standard format for sharing financial data, with keys to prove the data was real, and let the consumer export those files and share with anyone they want. No need for multi million dollar federated systems.
It is unforgivable that they implemented it as an iframe. Who needs EV SSL verification? never heard of it. You can't even see if there's an HTTPS lock indicator! It was bad enough that it asks for bank login credentials, but doing so with no server validation at all is a terrible flow to be teaching users to accept.
You can’t implement what you suggest in a browser. The only trusted identity that browsers have is the parent page in the URL bar — which Plaid doesn’t remove. If Plaid tried to create some kind of secondary URL bar, phishing pages could just recreate it.
I know, but that limitation should have sunk the whole idea instead of them relying on iframes. They could make a popup like PayPal (doesn't solve the picture-in-picture attack you linked to, but still better than iframe). The best way to avoid phishers would be to not collect login credentials at all. I expect some kind of token signed by your bank (and generated on your bank's site) could have created a secure way to verify your account without asking for your password. Users have been trained for years with "we will never ask for your password", and for good reason.
This token based approach is slowly arriving. Don’t know if Plaid does it yet. Yodlee and Intuit have already implemented it (OAuth and FDX) with at least and handful of banks.
Plaid does indeed support this kind of flow for quite a few banks, especially in Europe (but also in other markets). See oauth flow for details:
https://plaid.com/docs/link/#supporting-oauth
This is a really difficult space because EHR/EMR companies are not incentivized to allow data-sharing. The moment they unlock those doors they lose the vendor lock-in that allows terrible solutions like Athena/Cerner/EPIC to retain their customers. They way they technically comply with FHIR data-sharing laws without actually allowing data sharing is by requiring a $100k API-key to unlock sharing, but they only issue it per-hospital or per-clinic. As an integrator you need to contact each individual care center that you want to integrate with, a process often taking up to a year per instance.
There is no central "get all data from any EPIC instance in the US for a given patient" solution. Even after that point they often have separate APIs and technologies for read/write, and even different tech for different data fields within the same records, making efficient, seamless integration nearly impossible (intentionally). If all that wasn't enough, often these systems are very eventually consistent, meaning that to build a sync middleware between EHRs you end up with flip/flop race conditions where the lag between a write and the next read showing the update causes out-of-date data to be synced back on top of the original correct data.
Because it's such a hard problem but so badly needed, there are plenty of existing companies specifically popping up in the FHIR/HL7 EHR integration/data-sharing space to try and solve this. I spent two years building one myself for a client, but it's not public, so these are my two public favorites:
Thanks so much for your comment. As someone also working on problems in healthcare IT (and with many complaints about existing solutions), it's at least reassuring to know that other people also find it as asinine as I do. There's also a ton of solutions I haven't seen before so it's a really great reference.
On another note for people starting healthcare SaaS targeting clinics and hospitals, the situation also becomes a somewhat awkward juggling act between oneself, the clinic, and the EHR provider, since any API access offered by the EHR is meant to be given to the clinic (which often is ill-equipped to actually make use of this). Coordinating some handoff is thus non-trivial since you'll likely end up talking to people who don't know what API access is and need to get bounced around for a bit. You're also basically operating in a black box without much information about the EHR system itself, and developers with experience on multiple EHRs are a bit uncommon.
Healthcare integration from a technology perspective is a solved problem. The real problem is that health systems have zero incentive to work with your shit. Oh…someone in rev cycle management wants to use your new SaaS to do a thing with PHI? And they need FHIR? How about HL7 V1 and an IT department that won’t take your call and a VPN connection procurement that takes 7 months to work? Oh also, your tiny little SaaS company also needs to spend $100k on getting a HITRUST certification. Sound good? “It’s cool that your using health connector XYZ but we’re not working with them, k thx bye”
1. Nice idea but the TVM is tiny because its healthcare adjacent and built upon the straw foundation of healthcare startups and their backers. This functionality isn’t needed for most and is impossible to build where it’s needed — specialty medicine.
2. The true opportunity in the healthcare tech space is capturing a piece of the actual transaction either upstream like CoverMyMeds (marketing dollars) or downstream like RelayHealth, Change (Rx dispensing) which is what Plaid is actually doing. Nowadays this means capturing a piece of the specialty market which is extremely difficult due to the complexity of specialty medications.
3. New people to US healthcare don’t understand that outside of price transparency, the biggest fundamental issues in healthcare are actually time to therapy and patients remaining on therapy which is impacted by things like authorizations, lack of therapeutic support, and of course price again.
What does this mean? I as a patient have my data per HIPAA. It is easily transportable by myself or my providers however there isn’t a whole lot I can do with it for the reasons I mentioned above.
This isn’t the same problem as Plaid where theres a huge market because there’s a ton of choice and utility for the end user and also for startups looking to simply process a financial transaction.
28 comments
[ 2.9 ms ] story [ 72.2 ms ] threadIt takes roughly 1-3 months to build an integration (depending on EHR/PMS/Wearables) and high $$ upfront. With our single unified API & simple black of code digital health companies can easily access the data they need.
We are looking for some early feedback from digital health hackers. If you are interested in testing our APIs, please fill out our form and we'll get in touch with you.
Happy to answer any questions, Thx!
We are more consume the API and start getting the data
Their minimum pricing is $45K upfront which doesn't make sense for a digital health innovator
It should be downright illegal for a third party to ask for a bank password.
Sharing passwords is a universally bad practice and has been for decades.
Like https://www.healthgorilla.com/
I wish this new company luck. Healthcare is unbelievably difficult market to enter.
Not sure if they're still doing that. Definitely don't ever want that to happen with my medical records.
It's a nightmare for security as a service concept
What the banking industry should do is just come up with a standard format for sharing financial data, with keys to prove the data was real, and let the consumer export those files and share with anyone they want. No need for multi million dollar federated systems.
aka the “line of death”: https://textslashplain.com/2017/01/14/the-line-of-death/
https://www.yodlee.com/envestnet-yodlee-and-charles-schwab-e... https://developer.yodlee.com/resources/news/yodlee-and-jpmor... https://media.chase.com/news/chase-intuit-to-give-customers-...
There is no central "get all data from any EPIC instance in the US for a given patient" solution. Even after that point they often have separate APIs and technologies for read/write, and even different tech for different data fields within the same records, making efficient, seamless integration nearly impossible (intentionally). If all that wasn't enough, often these systems are very eventually consistent, meaning that to build a sync middleware between EHRs you end up with flip/flop race conditions where the lag between a write and the next read showing the update causes out-of-date data to be synced back on top of the original correct data.
Because it's such a hard problem but so badly needed, there are plenty of existing companies specifically popping up in the FHIR/HL7 EHR integration/data-sharing space to try and solve this. I spent two years building one myself for a client, but it's not public, so these are my two public favorites:
- https://www.redoxengine.com/
- https://www.healthgorilla.com/
But there is a long tail of others, each with nuanced shortcomings and benefits:
- https://www.interfaceware.com/iguana-integration-engine or https://www.interfaceware.com/iguana.html - https://www.humanapi.co/ - https://kno2.com/ - https://www.healthcompiler.com/LP-API - https://www.lyniate.com/ - https://www.clinicalpipe.com - https://tigerconnect.com/ - https://www.qvera.com/hl7-interface-engine/ - https://cliniconex.com/healthcare-collaboration/ - https://clareto.com/
IBM, Azure, and Google Cloud also offer FHIR cloud integration services.
- https://cloud.google.com/healthcare/docs - https://azure.microsoft.com/en-us/services/azure-api-for-fhi... - https://www.ibm.com/us-en/marketplace/merge-hl7-toolkit
And even more if you're interested:
- lofatdairy ↗ Thanks so much for your comment. As someone also working on problems in healthcare IT (and with many complaints about existing solutions), it's at least reassuring to know that other people also find it as asinine as I do. There's also a ton of solutions I haven't seen before so it's a really great reference.
On another note for people starting healthcare SaaS targeting clinics and hospitals, the situation also becomes a somewhat awkward juggling act between oneself, the clinic, and the EHR provider, since any API access offered by the EHR is meant to be given to the clinic (which often is ill-equipped to actually make use of this). Coordinating some handoff is thus non-trivial since you'll likely end up talking to people who don't know what API access is and need to get bounced around for a bit. You're also basically operating in a black box without much information about the EHR system itself, and developers with experience on multiple EHRs are a bit uncommon.
1. Nice idea but the TVM is tiny because its healthcare adjacent and built upon the straw foundation of healthcare startups and their backers. This functionality isn’t needed for most and is impossible to build where it’s needed — specialty medicine.
2. The true opportunity in the healthcare tech space is capturing a piece of the actual transaction either upstream like CoverMyMeds (marketing dollars) or downstream like RelayHealth, Change (Rx dispensing) which is what Plaid is actually doing. Nowadays this means capturing a piece of the specialty market which is extremely difficult due to the complexity of specialty medications.
3. New people to US healthcare don’t understand that outside of price transparency, the biggest fundamental issues in healthcare are actually time to therapy and patients remaining on therapy which is impacted by things like authorizations, lack of therapeutic support, and of course price again.
What does this mean? I as a patient have my data per HIPAA. It is easily transportable by myself or my providers however there isn’t a whole lot I can do with it for the reasons I mentioned above.
This isn’t the same problem as Plaid where theres a huge market because there’s a ton of choice and utility for the end user and also for startups looking to simply process a financial transaction.