What’s Really Killing Digital Health Startups
techcrunch.com
techcrunch.com
Then there is the long cycles. We signed some global Big Pharma brand (can't disclose). They actually approach us and were very eager to work with us. But even with that, it took exactly 2 years before we were able to roll out our pilot partnership.
Basically you need to go into this knowing it'll take 3-4 years before you can show any traction.
Additionally, data interchange between competitors is a non-starter. Possible solutions (work-arounds) will be single payer or continued market consolidation (hospitals merging and then implementing one of the big systems like EPIC).
Not mentioned is that continued churn like HL7 v3, ICD-10, meaningful use, etc. are hugely onerous while adding zero value. A cynic might wonder if its just make work for the consultants.
---
Source: My team designed, implemented, and supported the backend of 5 exchanges. Like this one:
MedPlus to Implement Clinical Portal and Information Exchange for the Brooklyn Health Information Exchange (Jan 11, 2008) http://newsroom.questdiagnostics.com/index.php?s=30649&item=...
Bad has HL7 v2 is, it was a known evil.
With HL7 v3, there's so many more places to stuff data. And when it wasn't clear what goes where, partners created novel solutions. Just like with v2, but now with XML syntax.
We participated in an early NHIN competition (shoot out). The official WSDL only worked with one tool stack (Visual Studio?). I finally gave up and just screen scrapped the good bits. Used xpath to pull out the useful bits. Used SoupUI to create prototyped requests, manually massaged them to work, then turned them into Velocity templates.
We captured "official" requests and responses, stored them in source control. When something broke, we'd use diff to find the mutation. Turn-around was a few hours. Our two person team ran circles around our partner's teams with dozens.
I still use the fake it strategy for anything XML or web related.
I get the sense that the reality of any medical exchange format is 50% data structuring and 50% legal structuring.
Which is unfortunate... as lawyers aren't very good at commenting their code for non-legal professionals.
I hope some visionaries VCs will start thinking in those terms, and start investing in this kind of high-impact life-time ventures.
This x10MM
Some businesses are so intertwined with everything from unions, to legality to human behavior that you need to know what you are getting into before you even start.
The study on physician practice arrangements found that six in 10 doctors were in small practices of 10 or fewer physicians in 2014, a number that's unchanged since 2012.
http://www.uhc.com/bmtn-categories/bmtn-news/2015/07/14/majo...
So you have companies like one I was recently a part of integrating a Node web app and API with SOAP and SAML end points and suddenly it's everyone else's fault that things are hard when really you probably should have thought through those tech stack choices before you started.
I'm not saying the article is wrong. I agree with it wholeheartedly but there's a lot to be said for not researching the market you're about to jump into thoroughly enough before you begin.
It is rather frustrating to see some of the API designs that are finally getting shipped in healthcare now, though. Right now, I'm interfacing with a market leading EMR vendor's web services API. They advertise it as "REST" with a straight face, but it's the lake wobegon of REST APIs, where all of the responses are "HTTP/1.1 201 Created" (even the GETs) and all of the response times are horrible.
Personally, I'm rooting for startups like Redox Engine (https://www.redoxengine.com/) to bring some sanity to this world, because I don't think the EMR vendors are going to do it on their own.
I once asked a question online about a legacy technology. The only answer I got was a smug "don't use [technology], it's outdated."
I work in a "people's lives depend on this" industry, not a "move quick and break things" industry. That's why I am working with "outdated" technology.
We could have spent hundred of millions of dollar and several years to rewrite the system I was working on to use the latest technology stack. But for what? It works and does its job well.
If an older technology is so great then my preference would be to build modern tools for that old technology and then it would be like new. If you can evangelize this old-made-new platform a bit then you could find more people willing to use and learn it, which would fix the online presence and employee hiring problems too.
Note that MUMPS is one of those old technologies used in healthcare. It is basically a NoSQL database from before NoSQL was popular. Intersystems' website suggests that they've made a bunch of additions to it, but Intersystems charges a lot of money. GT.M is the open source one but as far as I know it sticks more to the ANSI M standard. That standard language is pretty old so it can get confusing to read/write it. I'm not sure if GT.M provides dev tools either. Intersystems does, but AFAIK they are not as good as tools like Visual Studio, XCode, or other newer platforms.
GTM does stick to the ANSI M standard with a few extensions for basic escape holes like calling a UNIX process or writing to a file. It doesn't have the same level of optimization, reliability, recoverability, etc. that intersystems sells.
And the future will reveal that some choices of the technology in question showed incredible foresight and some were very poorly conceived.
If we're lucky, the good choices match well with certain problem domains and the poor choices are an acceptable price to pay.
Just rewriting in new technology won't necessarily make it any better though, I'll definitely grant you that. I'm one of the crabby people who prefers technology from the early 2000s that grew out of unix technology of the 80s. But the really really old stuff can actually have meaningful limitations.
With regards to the medical industry, most of the software and systems are truly bad (in addition to being made with very very old tech). The reason IMHO is that due to all the regulation and all the money, all the power is on the political side rather than the technical side of the market, and it's a market where users don't choose what they use, administrators choose for them (and then don't have to use it).
(My mother is an MD)
Yes.
Does it do its job well?
Yes.
Does it have scheduled maintenance every evening for the mainframe batch job?
No, its used 24/7 and does not run on a mainframe.
Does it not handle non-ascii in names?
Who the hell cares? It doesn't have to.
Does it not have the perspective of knowing how much better it could be done, like webmail before gmail?
I don't even know what you mean. I think webmail before Gmail was great. Gmail is always changing its UI and confusing users. Gmail didn't bring anything to webmail except a ton of free storage.
The software is fine it doesn't have many big flaws and it operates in a space where people depend on it working right so they don't die. We still release new versions once in a while but its not too much work.
The VC startup model relies on finding white space and occupying it. Heavily regulated industries (like health care) tend not to have a lot of white space because the boundaries are rigidly defined by law. It's not a good fit for health care.
But I think it is possible to want to do something health related, conclude that the medical industry is a nightmare, and find another approach.
I mean, you can claim that things like MyFitnessPal are health apps, but it's still a fine line you have to walk where you can't give any advice, all you can do is observe and report. Try to go any further than that and you're providing diagnostic services, which makes you subject to all sorts of laws. The FDA and DHHS are very aggressive in protecting their regulatory scope.
http://www.fda.gov/AboutFDA/Transparency/Basics/ucm194244.ht...
Though, yeah, given that the FDA is the FOOD and Drug Administration, I am sure they impact grocery stores: https://foodpoisoningbulletin.com/2014/fda-proposes-rule-for...
That does not mean HIPAA impacts grocery stores, restaurants, etc.
Though if you search for "HIPAA and grocery stores" it does pull up Von's page on HIPAA related to the fact that stores can have a pharmacy window in them:
http://rss.vons.com/ShopStores/Pharmacy-HIPAA.page
So, yes, while anyone selling food will be regulated by existing food safety rules/organizations -- including the FDA -- that does not prevent someone from saying (to themselves) "I would like to make the world healthier. I don't think becoming a doctor is The Answer. I think The Answer is running an organic restaurant."
And please don't argue with me that how you conceptualize it does not matter. You cannot tell me that Chipotle, with its "Food with integrity" concept and supporting policies, is the same as any other fast food taco joint.
(I ate there consistently for a long time to get well after doctors wrote me off for dead. That did not cause Chipotle to suddenly have to comply with HIPAA.)
It is the same as any other fast food joint. Heck, food quality improvements were an early selling point for McDonald's.
What you describe is absolutely the wrong way to start a business: you should look at the type of business you want to open (in this case, a restaurant) and look for white spaces. Opening an organic restaurant is only a sensible idea if the market would respond to an organic restaurant and the category isn't already over-served. If that overlaps with your passion, then great!
Never mind there is no scientific evidence saying organic food is better for you - this is where "health" delves into pseudoscience, and the entire reason the FDA exists.
It seems to me that what I am describing is exactly what (at least some) disruptive businesses -- like AirBnB -- do: Redefine the problem in order to find a white space because the thing they are doing did not exist until they did it, so there isn't really any competition.
"Redefining the problem" is marketing speak for finding a way to trick consumers into using your business model. It's fine in the case of something like Uber where you're short-circuiting a bunch of disparate and protectionist taxi laws, but federal regulatory agencies are rarely fooled by such tactics, and aren't shy about labeling you and your company as scam artists while sending a federal prosecutor at you if you try.
Basically, if you're gonna fuck with the government, make sure you fuck with municipal and state governments. The feds don't take crap, and will steamroll you if you threaten to circumvent their jurisdiction or deceive them in any way. This happens to hundreds of companies a year (just look at Theranos and 23andme for some high-profile examples), so they're definitely not bluffing.
Yes, that's right folks - it's last release was exactly 10 years ago. You wouldn't believe some of the systems I've seen.
Not that I'm arguing for VSS, it's awful, but there are business reasons I can see trumping the desires of wanting an upgrade.
Edit: spelling
Then another month to implement the change. And this was only for one sub-group.
I think some of the problem is "People who still feel VCS is a valid technology choice probably shouldn't be trusted to make technical decisions."
Agree completely on the IT & product integration barriers highlighted in the article. This (& more) make health care a nuanced place to build a business.
There are simply more stakeholders to manage:
- Employers (Google, etc; those w/ >500 emps usually carry financial health care risk)
- Plans (United, etc; both carry risk and administer employer plans)
- Providers (Sutter, etc; deliver care, can carry some risk, contract with plans, and sometimes contract directly w/ employers)
- Benefits Consultants (Mercer, etc; guide employers, more)
- Societies (AMA, etc; build guidelines, unify provider voices, more)
- Patients (you; remain frustrated w/ system complexity)
- Consolidators (McKesson (Rx logistics & channel), Express-scripts (pharmacy benefit manager); add leverage and efficiency)
- Regulators (HHS (HIPAA), FTC, FDA, etc; define ground rules for all these players)
- Suppliers (Pharma, device, digital health; sell value into this space)
But it’s also very, very fascinating. And once you suffer through some of the learning curves can get quite fun. There are enormous financial and impact opportunities to be had. The wall can be a little high.
I'm always still learning, but if you need help on your idea and how it'd fit in, email me at sean@omadahealth.com.
I worked for a company in a total different sector that eventually ended up being acquired for a significant amount of money.
More or less the company 'succeeded' because almost everything 'product' wise was window dress. the actual value of the company was the fact that we had done the legwork to integrate with dozens and dozens of difficult legacy systems and was able to expose them in a single unified API that our 'product' used. The purchasers didnt really value the 'product' or the companies 'brand' they valued the integration and the business relationships with the integration partners that were necessary to keep these integrations working...
Seems like what the article is really saying is that in this particular market the money is in the integration not the 'product' over the integration.
Bingo. That is precisely what our backend did for healthcare data. And the front end (portal) was really good for the time.
For good or ill, The start-up ideal is generally to solve problems broadly, to disrupt an entire industry rather than build one more extension to that industry.
The problem of integration, of conforming to byzantine standards and to the mess that overall existing health IT, is itself still just a detail in the overall problem of health and technology.
The fundamental problem is the messiness and unpredictability of physical human bodies/human health.
The reason that health records are a mess is that there is no easy to way to universally classify "what is going on" with a given person in a cut-and-dried fashion. For any field of a health record, there is significant gray areas once you get to a large scale (including "basic" things like "male" and "female").
Just as much, health procedures often don't benefit from automation because what one person does to care for another person is subtle and not easily codified.
As for health records, perhaps the expectation of a neat database decomposition—data perfectionism—is itself the enemy. For just about any given application, such complete information isn't necessary to improve on the status quo.
From my perspective, too much effort is spent creating One More Standard to unlock data nirvana, and not enough on breaking down the organizational walls and misaligned incentives that brought us to this point.
The post author alluded to this, in mentioning the EHR cash incentives that tragically lacked viable interoperability requirements, and so just served to lock in the major vendors' existing systems.
But which start-up has ever done that?
Not even Google or Facebook did disrupt an entire industry – they just built one more extension to an existing industry.
Come-on, look at my context. Of course, disruption is never a fundamental up-end, just a streamlining towards a simpler and more productive approach - Uber and airBnB being the classics (whatever their social value or lack there-of).
The start-up approach (or disruption, the most archetypical part of it) is aiming for more streamlining at the end of the process - rather than aiming to be one more orifice slurping up money from one of the vast streams of money that already exist. Contrast AirBnB with a company that might "let you reserve rooms with ten of the largest hotel chains in the world" - sure, both change things, neither absolutely change the world but AirBnB is still a more fundamental change (again, in values-free terms).
"let you reserve rooms with the 1000 largest hotel chains in the world" is quite a fundamental change, as you get direct price comparison, info in which weeks it will be cheapest, etc. (And, unsurprisingly, there are dozens of startups doing exactly that).
Zapier integrates an amazingly high number of SaaS's. And aside from the annoying lag due to their frontend being done as a SPA (which doesn't effect their API at all), they seem to be well-built. I do wonder a bit at their pricing, but it's not outrageously overpriced (and underpriced compared to many competitors).
And yet the main people who are using them seem to be the "internet marketing" crowd (who is using them to great effect, by the way).
Off topic, but I've been really perplexed by this. It's not lack of promotion, since Zapier seems to do a lot of that.
Could it be that most non-programmers aren't using programming because they can't learn how to use a programming language, but because they just aren't interested in those technologies, even when they're presented to them as a super-easy web GUI.
Re: pricing; I'd argue they're vastly underpriced, when you consider the development costs of writing the integrations yourself. I could pay them $20/month indefinitely and never spend more than the development effort would cost to write and maintain 20 (heck, even 10) integrations.
Problem is, most medical applications don't use REST or SOAP. Chances are they use one of many different variants of HL7, which usually operates through an ETL/data warehousing process. HL7 is one of those data standards that's only widespread because it's barely even a standard -- you'd have to write a different parser for every product or combination of products you integrated with.
And this isn't even touching the hundreds of other proprietary data formats, for everything from medical telemetry (pulse, o2 levels, etc) to imaging (x-rays, MRIs, etc) to billing. Many of these companies don't want you to be able to use their data (because, of course, they offer their own EMR platform or require a hefty licensing fee), so it will be encrypted.
All this is on top of all the deployment problems that SaaS platforms solved in the 2000s -- most offices are still using ancient on-premesis EMR platforms built in the 90s for record keeping purposes. Younger doctors with newer practices are using SaaS systems, but very few young doctors can afford to go into practice for themselves right out of med school. So it's a problem that will eventually be solved, but the time horizon is probably closer to 5-10 years than the 3-5 years we're used to in technology.
As far as Zapier goes, I don't know that it really saves a lot of money for companies. The hardest part of integration isn't coding the integration, it's building out the business requirements -- something you still have to do with Zapier. For anything simple enough to use Zapier for, a junior developer could write the code in an hour or two of his spare time.
I beg to differ, my past six months have been in the trenches with HL7 and while it's not perfect it's nowhere near as bad as you are making it out to be.
I work for a medical billing company, and a huge initiative we have had is to start getting demographics from hospitals we bill for in real-time instead of the daily batches we have historically dealt with, all through HL7.
We spent a lot of time implementing this, we have a "standard" mapping for HL7 messages that extracts all the demographic details we need from the standard segments, along with the ability to write a per-feed override to handle edge-cases where a specific EMR does something odd.
To date, the majority of the edge-cases we have had to write are finding insurance policy ID's in weird places at the end of IN1 segments. There's been a few others, but the amount of customization we've had to do on a per-site basis has been extremely minimal.
In my limited experience various parties use HL7 messages and structures in strange ways for whatever the heck they feel like, within the loose bounds of reasonableness.
Instead of their being one point of failure Company X <--> Company Y integration, there are now two points of failure Company X <--> Zapier <--> Company Y.
So, things may break. And if they do there are more points of failure in figuring out why.
If we really want a working integration with some other software, we build it directly and support it directly.
In summary I don't think it's only lack of willingness; bad design was baked in from the beginning and piled up over the years.
As an aside, speaking as doc and programmer whose been in this field for more than a decade, I repeatedly find hilarious the hubris from developers coming from outside the field who think they are gonna fix healthcare with their amazing new perspective. Poor bastards. I feel sorry for the ones who aren't being arrogant dicks about it.
I recently reconnected with a guy who had a super high profile successful startup (like, success level=my mom even uses it) who tried to start his next company in healthcare. Fast forward a few years (i.e. a few weeks ago) and he sounds like he has PTSD
I'm going to give away the secret sauce I created for our backend.
"Traditional" EMRs imagine an idealized data model and then write ETLs to import to that model. The jargon we used was "adjudicating the single best record (SBR)" or "source of truth".
My system slurped up all data, stored mostly as-is, and then used information retrieval strategies (think Lucene) instead of querying (think SQL).
This solution was wicked fast. We showed our customers data back to them, so validation was simple. And we were super nimble when they changed their minds (what is a "visitation", how to displays scripts, updating lab results).
Sad story short: our group was acquired, my strategy made the reigning CTO's head explode, he attempted a rewrite, failed, then the execs killed the product.
But search is only one need. You say EMRs imagine an idealized model. Maybe. They certainly never develop one. And that's what you need to reach the potential of medical data analytics. The software needs to "understand" what the data means without constant human intervention
I ask because there is some amount of chart searching and organization analytics in the big EHR products so I'm curious which part you think is specifically lacking?
I'm firmly in the folksonomy (vs taxonomy) camp.
We just showed our customers data back to them. In most cases, it was the first time they'd ever seen it. Hence the churn on "what is a visit", resolving scripts, etc.
I don't know anything about medical data analytics, but if we captured the data, then its there to be mined. It was just HL7 (or whatever), as is.
We did have live data feeds to the CDC. If there was a hoop, I assume we jumped thru it.
validation without checks on overwriting patient info
Our data store was write-only. In SQL parlance, no UPDATEs, just INSERTs (and SELECTs).
One hard requirement was to be able to show what was known when about a patient. "Traditional" data store solutions have "live" tables, separate history tables (recording changes), and maybe audit logs. My solution just had the log. Queries used a date range. Made QA/test trivial.
So, when trying to sell a third-party product to a hospital, administrators forward you to the EMR vendor, while EMR vendor forwards you to the administrators :) Each of those "forwarding" takes a few months.
This makes it sound like opening an API up to the public is akin to flipping on a light switch, which as we all know is rather misleading. There are significant investments and expenditures (documentation, support, etc.) to make if you want to properly serve up a public API and no, not every company does those things as a side effect of developing a product.
And I'm not sure it is safe to say that "most" software applications have APIs in the sense the author means.
1. [B2B] Providers/enterprises aren't willing (or able) to integrate into legacy systems
2. [B2C] Consumers see their futures selves as strangers [1], and most aren't willing to put in time now to prevent something that may or may not happen in the future (e.g. sickness)
Which is sad, because this is a huge area for tech to have a meaningful impact on lives.
There are definitely some interesting companies in the space. For example, Omada Health [2] sells to companies. Companies like them because their employees' health increases (meaning more time spent working) and insurance companies like them because their loss ratio decreases.
[1] http://www.vox.com/2014/12/18/7414105/procrastination-future... [2] https://omadahealth.com/
The US ICD-10 Clinical Modification (ICD-10-CM), for instance, has some 68,000 codes. The US also has the ICD-10 Procedure Coding System (ICD-10-PCS), a coding system that contains 76,000 codes not used by other countries
The size of some data also makes exchanging it difficult. A typical MRI image is 5-10 MB with sometimes over 1,000 images in a set, and some patients will receive multiple MRIs over the course of treatment.
Scale that to millions of people, and you have some idea what larger healthcare networks are dealing with (and why the VA system has had so much trouble).
Note that this data also has to be _perfect_. Incorrect or missing data can cause real harm to real people (and serious legal trouble for the company that fucks up).
For example, IHE WCM (the waveform stuff for realtime signals) is not very good: it is overly textual for the data it represents, doesn't solve all the problems it can run into, has some weirdness with timing and how to map things into HL7, and so forth.
If there was more of an emphasis on preventative measures that insurance paid for, I wonder if it would be different.
"As they are currently delivered, almost all of the prevention activities are expensive. If applied fully, using current protocols and the reference assumptions about costs (Table 2), they would increase health care costs by $8.5 trillion over 30 years (Table 3), or $283 billion per year, or $1700 per person per year (data not shown). The only cost-saving activity is smoking cessation."
You can read the full paper here. It's from 2008, so perhaps some entrepreneur will be able to find the breakthrough that finally bends the cost curve: http://circ.ahajournals.org/content/118/5/576.short
That said, it seems likely that insurance premiums will eventually be tied to real time health data, like Metromile is doing for car insurance.
As someone who has spent the majority of my career working in Digital Health (née Health IT) and helping people get data in and out of EHRs, I think any assertions that we're about to enter a new era of magical integration efforts are usually off base. There's no magic bullet to solve digital health integrations. It takes:
- Defining the value proposition of integrations for your market (Meets regulatory concerns, reduces double documentation, saves time and money)
- Knowing what the playbook for integrations looks like for your industry. What does it mean to be an integrated telehealth vendor? An integrated cancer analytics platform?
- Having a team that know how to operate in the space. EHR and HL7 vets are hard to find, recruit and retain. I think this is particularly true in the Bay Area. Expertise here is crucial.
I know alot about this and this is what our team at Catalyze has focused on solving NOW, not whenever the magic solution arrives. Looking for help on keeping your Digital Health startup alive? Let me know. I’d love to help you out. Email me -> mark <at> catalyze.io
Look, there are lot of industries that work in IT integration. If you take manufacturing, retail, finance, telecom etc. there hundreds of systems from the '60s and integration (and all the pain) is probably 80% of the work. 100's of billions of dollars are spent on IT integration. There is no magic 'one true IT system' but lot of hard work and slog. Nothing very special about healthcare. But, there is functioning market in these industries. Consumers of these systems have a very clear idea of how IT is going to help them run their business, it is sustaining system. They pay money, IT people build systems.
Not so in healthcare IT. Healthcare consists of bunch of fragmented and tiny providers interspersed with some large players. As such very few are managed as a business (as a retailer would for ex.), instead it is managed almost like a bazaar style haggling model. Try to squeeze out as much as possible from the insurance company, reduce the cycle time of payment, negotiate some extra tests, enter the correct ICD code etc. No standard business metrics that everyone can agree upon. If the value pitch is "we will help you get paid", then you have failed. My view is that this state of affairs will continue until there is some large scale integration and verticalization. Until we have these fragmented healthcare system in place I don't see a good future of healthcare IT.
I mean sure there will always be some people doing this, but people have working on healthcare IT since the '60s. Having super clean one true data model is fanciful at best but it actually will not solve anything. The $40 Billion of HITECH subsidies have managed to create a half assed EHR ecosystem with Epic taking a chunk of the market share. It will be interesting to see how the industry will manage to get the customers to pony up the next $40 Billion and the next and the next. In a fragmented system, the only IT system that can work is some sort of Slack type system (or communication tool) for patient/providers or between providers.
If you don't want to deal with HIPAA and take it very seriously, then stay out of this space. You aren't worthy.
I work on a SOA team for a large healthcare organization, so I'm well aware of the issues. The problem comes down to the usual case of entrenched vendors working to protect and expand their turf. EHR vendors are notorious for being terrible for interop—some are better than others, but they all see integrations as competing with their own offerings. Non-trendy methods of exposing data—SOAP, custom MUMPS code, direct SQL access—are the norm. That's not a problem, except that documentation is often incorrect or nonexistent (while being restricted to direct customers, of course), and the vendors really don't care about APIs. They see interop as a necessary bullet point on a sales sheet, but they'd rather not have those APIs be used in place of their (usually crappy) complementary apps that they're trying to upsell.
Interop is a HUGE win for patients. Without it, we lose one of the main advantages of EHRs—the ability to access our own information when we need it, and allowing the information to be fluidly shared between providers. Of course, privacy is paramount—but in my experience, interop is not the attack vector I'm most concerned about.
He dismisses the presumed "cheap excuse" of HIPAA compliance given by someone who did not want to work with him. This does not give me confidence he takes HIPAA seriously. I had annual HIPAA training (as well as Gramm-Leach-Bliley) when I worked for a major insurance company for a few years. So I am not unfamiliar with HIPAA.
I'm excited to see where retail clinic initiatives like CVS's go, since that's actually a real change to how I, the patient, get care. Instead of consulting my insurer's website to find out what clinics they accept then calling up to make an appointment in a busy doctor's schedule, if I could instead just walk into the store and get what I need like I could any other product that would increase the convenience by enough that I might use it to keep healthy rather than to fix myself when I'm very sick.
We need ways for companies to compete in giving the most convenient service at the best prices. We need full price transparency. We need the prices to be things people could actually pay. (Insurance was originally for catastrophic care where the cost for a major illness or surgery would get too high.) Having prices so high that only insurers can pay them means only insurers DO pay them and since hospitals and clinics know this they can charge whatever they want.
(I once went to a dentist who advertised cheap wisdom tooth removal. I found out the way he did it was send a huge bill to the insurance and whatever the insurer declined to pay he would just forgive. Basically he is kinda willing to work for free but take as much as he can possibly get from the entity that has the deep pockets.)
Agreed 110%.
> Having prices so high that only insurers can pay them means only insurers DO pay them and since hospitals and clinics know this they can charge whatever they want.
I've explained this in more detail on another recent HN thread, but basically: prices are 'so high that only insurers can pay them' by design, but it's not for the reason most people think.
It is generally illegal for providers (hospitals/doctors/etc.) to charge different rates to different patients based on their insurance status[0]. However, it is not illegal for providers to negotiate standard rates for specific payers. Combine this with the fact that providers lose money on their publicly-insured patients[1], and it becomes clear that they have to overcharge the rest in order to end up in the black.
So what they do is set absurdly high sticker prices, knowing that the private insurers will negotiate those down (usually this is done in multiples of what Medicare pays - e.g., Aetna will say, 'We'll pay you 150% of the Medicare price for billing code 99481 this year'.
Uninsured patients are stuck with huge bills as a result, though this is basically an unintentional side-effect of the fact that hospitals can't give them lower bills initially. It's also the reason that hospitals are almost always willing to negotiate with uninsured patients. If they know to ask, they can almost always get that down to 10% of the original rate. That bill isn't meant for individuals, they don't really expect individuals to pay, and they'd much rather negotiate a discount and have it paid in full immediately than have a patient default, which has negative repercussions for their bad debt ratio.
Privately insured patients end up having higher premiums as a result, because their insurers are paying higher rates to subsidize other patients who are not paying any premiums at all (publicly insured patients)[2].
[0] There's a little nuance to this, but that's the general idea.
[1] Medicare reimburses less than the actual costs of services provided per-patient, before accounting for any overhead
[2] This subsidy happens at the claims level, so it counts towards the insurer's requisite MLR.
Hospitals don't even know what a given service costs, so this statement seems to need a little more equivocation around it.
That's not really true. We're talking about the costs of goods sold, which means it's pretty easy to place a lower bound on the marginal costs. For example, if the lab supplies for running a certain test cost $100/unit from the vendor and Medicare pays $93, you know that the hospital is losing money off of it. We're not taking into account the overhead, infrastructure, or any of that stuff, since it doesn't factor into COGS.
Anyway, this number comes straight from Medicare's own figures, astonishingly. I can't dig it up right now, but it's in the public record, somewhere within a ~100 page PDF. I have the PDF at home and have linked to it on HN before. Medicare literally acknowledges that they reimburse less than 100% of the direct costs that they incur (in 2012 it was 93%, IIRC.)
https://hn.algolia.com/?query=by:chimeracoder%20medicare&sor...
I don't think you would have linked it in a comment where you didn't mention medicare.
I'm honestly curious about it, I certainly believe that Medicaid reimbursements are not matching costs, but I think for Medicare they often are.
https://www.floridahospital.com/sites/default/files/finance_...
> In 2012, beneficiaries of Medicare and Medicaid received nearly 60% of the clinical services provided by Florida Hospital (as measured by charges)vi. However, payments from these government programs represented just 40% of Florida Hospital’s total net revenuevi . In comparison, private payers received 30% of the care provided by Florida Hospital and represented 56% of its total net revenuevi
And the next paragraph:
> hospitals such as Florida Hospital have no ability to negotiate the payments from the public payers – Medicare and Medicaid – that pay for the majority of the clinical services provided. This poses a tremendous financial challenge for hospitals because these payments do not cover costs. In order to overcome these shortfalls, hospitals negotiate higher rates from private insurance groups. For this reason, continuing cuts to Medicare and Medicaid payments create an unsustainable business environment and put undue financial pressure on private payers
(The common response to this is that we need to increase funding to Medicare. While it's true that Medicare happens to be underfunded, that doesn't actually address the structural problem. Because Medicare has the ability to change their reimbursement unilaterally[0] while it has to request additional funding from Congress, these two will always be out of sync).
[0] the word 'negotiate' is often used here, but since hospitals are essentially legally required to accept Medicare patients, it's no more a fair negotiation than the negotiation you have with Comcast over your bill. You can squeeze a few extra dollars out of them if you fight, but at the end of the day, Comcast has all the power, so they can - and do! - price-gouge.
20-30 years ago, if you had a problem, you went to a doctor and that was about it. Now, people are more likely to choose to (or forced to by cost) seek alternative practitioners or at least partially take matters into their own hands (independent research, dietary and lifestyle changes, etc). These will usually be people who are not really getting helped by the system and are probably facing issues where lifestyle is a big factor (autoimmune issues, diabetes, obesity, etc). If you can successfully help that group of people where the system has failed to, then you may start to see some real changes as most people ultimately will (eventually) gravitate to what actually works (yes, I am an optimist).
Of course, as another commenter mentioned, we tend to be terrible at doing things now to benefit our future selves, but I still believe technology could play a big role in helping with that and the current options, like wearing a fitbit, are barely scratching the surface, mainly in that they aren't yet doing much to prove their benefit to the consumer or obviously help them day-to-day. That is a really hard task when health changes occur over long timespans but at least it is just hard-hard, not EMR/politics-hard.
Again, I like the goal and I did try them but it is not a good user experience or particularly helpful on the individual level so even doing it altruistically really didn't last. To get that kind of rich dataset, you need the user to be highly engaged which means they are really getting something out of it and using it for the primarily selfish reason that it helps them.
Having now had a lot of experience dealing with the medical system as related to complex and chronic diseases, I still find myself really surprised by how little the "consumerization of x" movement has impacted it. Per point of the original article, I shouldn't be. The massive bureaucracy, the regulatory capture, and the general politics of the industry are so all-consuming that there is little time or energy left over for the patients. (disclaimer: yes, there are a ton of amazing individuals working in the industry but even they are, unfortunately, really handicapped by the system itself)
Also, I worked for one, been part of the contract negotiations and have seen at first hand the difficulty many face trying to deal with providers and payors.
Shameless plug, I'm available for HIPAA consulting in San Francisco. I'm a former InfoSec officer.
Email is in my bio.
Even if a practice/vendor is savvy and deep pocketed enough to get past the politics and expenses, then you're at the whim of the competence of the interface teams which can range from incompetent to good, with the average being on the lower end. I've often seen something that should literally take a couple hours, take a year to get completed, if ever.
There are bigger initiatives taking place to try address some of these interoperatibilty issues, namely Health Information Exchanges (HIEs), although their economics remain unproven.
It's not all gloomy, I can honestly say that in the last 5 years, anecdotally, the hurdle to building interfaces feels like it's getting less and their sophistication and capabilities are getting higher.
But that's only one piece. You need business relationships to even connect to the EMR in the first place. I think the problem with breaking into this industry is: (1) Huge incumbents with tons of cash who have shown they will spend a lot of money to smear each other, buy out smaller companies, or just implement the new feature in their own system. (2) Excessive government regulation which makes it hard to play in this area legally and makes everyone afraid to work with you.
I had a couple friends pitch me a medical-related startup idea a few years ago and I declined. They didn't last long before some bigger player came and implemented their idea thus stealing their customers.
Also, the article mentions reinventing the wheel of integration libraries. Having open APIs will not magically solve all problems. It mentions Kareo and says they are building out their own EHR. THAT is reinventing the wheel. An EHR is mega-huge. It has tons of modules and for the main vendors takes 18 months to 2 years or so to configure it to the satisfaction of all parties. It sounds like the advocated world is to have lots of small "open platform" companies re-invent the wheel by making a new EHR module-by-module but with different startups inter-operating instead of locking each other out. You realize that all the major vendors today started like that? They were all first one module and gradually added more. Why do you think hospitals tend to buy the integrated software to replace myriads of independent legacy systems? If you can't fully understand that and articulate why your "open platform" would be better then you're going to fail.
Happy to help anyone learn more about the spec @medhacker
[1] http://www.annemergmed.com/article/S0196-0644(15)00226-7/ful...
There are compromises in any API, and FHIR does a decent job of making common needs things simple, the alterative would be some RIM or graph based model that you'd have to get graduate degree in before you could say 'just GET me a Potassium result dammit'.
Please reach out if you see ways the spec could improve.
However usually the complaints about health IT complexity come from people with a lack of domain knowledge. The industry is irreducibly complex. Attempts to drastically simplify the IT systems and standards are doomed to failure since they lose the ability to cope with many common real world situations.
The fact of the matter is that the gatekeepers blocking improvement (which really only is attainable through simplification and standardization) are going to keep doing so until they die or are payed off.
We've spent 30 years building up a morass of incompatible and tailored systems and then training all the administrators that this is somehow normal and acceptable.
First, it specifies 3 different formats: JSON, XML, RDF. It should only pick one, preferably JSON, because that's the lingua-franca of the web.
Second, the datatypes are handled oddly ( https://www.hl7.org/fhir/datatypes.html ). Numbers, for example are supposed to handle arbitrary precision, but they pick the wrong datatype for it in things like JSON (should arguably be a string, or a properly-formatted Number).
Third, things like ContactPoints ( https://www.hl7.org/fhir/datatypes.html#contactpoint ) are left too open-ended. You run into things like "Well, this is not structured, some um I guess you should chase a URL to figure out how to deal with it". The point of a standard should be to standardize these fields...leave remediation to the people hired to do implementation and assume it is done correctly.
Fourth, time is still not quite handled correctly ( https://www.hl7.org/fhir/datatypes.html#period ). Period, for example, doesn't say what time zone the contents are in--a simple note "Hey, this should be in UTC" would have sufficed.
There are other issues around things like letting users bundle in embeddings of HL7 and other things, basically saying "this data can have arbitrary structure". It's a punt, and leads to things like having to infer (if you can) what a value means from it's "type" or "system" ( https://www.hl7.org/fhir/datatypes.html#codeableconcept ).
You use the phrase 'lingua franca' which provides and interesting analogy - it was implemented globally by a group of imperialists who controlled the trade transshipment points of a big chunk of the world by force of arms; is there a corollary in health care?
Actors on the web that have a profit motive to play together have adopted a set of norms (REST, JSON) to manage tasks that are usually trivial compared to medical knowledge representation. We still can't get an iCal right, for goodness' sake. Everyone else is buttoned up, and FB and GOOG don't exactly share network data with each other.
Regarding point four: if it get's specific to times, then you do have to indicate time zone, just ate the dateTime level: "If hours and minutes are specified, a time zone SHALL be populated." (https://www.hl7.org/fhir/datatypes.html#dateTime)
It's not a timezone on point 4, as explained elsewhere that's the offset (if I'm reading the spec correctly here).
As a minor history point...JSON was "discovered" by Crockford and given away as a spec, to everyone, to make life easier. REST is a (still hotly debated) style for designed HTTP API endpoints. :)
The thing about the medical knowledge representations is that every single bloody thing that might be useful to implementors or folks looking to improve the field (from the outside, because inside medicine there are significant structural and political issues preventing meaningful change) is locked behind a goddamn paywall, taxed and kept from view lest it ever actually get out there and be useful. How much does it cost to get a copy of, for example, the standards for displaying ECG signals? Do you know where you'd purchase them offhand? How about that SNOMED?
Medicine is basically the poster child for what happens when a community is allowed to horde knowledge and IP and then self-police to ensure that you can't interact with them without paying for that stuff.
Regarding #2, what do you consider the problem with representing arbitrary precision decimals as numbers? That your javascript json parser converts json numbers to 64-bit floats? I'm not sure that that is really a problem with FHIR - see e.g. https://www.npmjs.com/package/json-bigint . Or is the problem that exponents aren't allowed?
About #3, how would you standardise addresses? ISO has been at it for several years and still not produced a standard. See e.g. http://stackoverflow.com/questions/4840928/iso-standard-stre... for relevant links.
Your fourth complaint is plain invalid. A period consists of two dateTimes, both of which specify time zones.
Number one and five I can somewhat sympathise with, though.
On 3, the complaint was specifically caused by this passage:
"However, this is frequently not possible due to legacy data and/or clerical practices when recording contact details. For this reason, phone, fax, page and email addresses are not handled as formal URLs. For other kinds of contacts, the system is "other" and the value SHOULD be a URL so that its use can be determined automatically."
Addresses (post, in your case) are arguably best handled as dumb strings, of type "garbage_human_address". The problem I have is with the explicit admission of "well, support the legacy", when everyone knows that the legacy stuff needs to go. We've been killing ourselves by compromising and allowing the mistakes of the past corrupt the systems of the future in healthcare.
As for #2: if there is ever any question about the representation of numbers, especially in JSON, you store them as strings. Twitter ran into this with ids, other people have too, and it's just generally icky. If the Javascript/JSON representation of numbers is being used (and it shouldn't, because the numeric types in JS are kinda broken), then there shouldn't be the restriction on exponential notation.
I can see it being inconvenient for import into a better designed system. You'd have to make an assumption about time zone.
At the same time, FQHCs and hospitals are facing CMS requirements that dictate increasing EMR usage. This effort has had... some setbacks, let's just say. And what Executive Directors are willing to say off the record is not pretty: http://seliger.com/2015/10/25/meaningful-use-regulations-cms....
Sure, I'd expect a terrible process and result previously (such as the mess healthcare.gov was when rolled out), but I have a lot more faith with the USDS and 18F in place.
OpenVista by medsphere is based on Vista, the gov emr...
All emr companies are walled gardens.
In 2009 I built the first mobile HL7 compliant client for the iPhone which was emr agnostic and could work with any emr -across an esb... But all emr companies shunned us because they wanted to protect their walled gardens. At the time hospitals shunned us because they didn't believe the iPhone was a good enough device (big enough screen) to be usable...
We built integrations into a number of systems... But couldn't get traction at that early stage. So we open sourced it through medsphere...
Dr chrono came along and took different tack which was to make an actual emr...
After working with so many hospitals and these systems I basically gave up... The system is pretty broken and the artificial barriers to entry are pretty lame.
In my experience, there's no such thing. HL7 is a spec in only the loosest sense of the word. Half the time you had an 80-character console output dumped into the "freetext" fields. Then there's all the codes used for different drugs, tests, admission/discharge (plus differentiating when they're standardized or user-entered with appropriate typos).
Point is, all the costs were really in the integration. Getting access to the HL7 streams wasn't bad once you got far enough in the sales cycle. Once you had it, it was a one-off project to parse the specifics of the messages. And that was just for a read-only analytics system... trying to generate compatible messages to feed back to the EHR is a whole other beast.
That's the challenge getting into this space if you're a web or cloud engineer... you come in with the mindset that "oh, HL7 is a messaging standard, I'll just read the spec and use it." In practice, there's an infinite amount of variability. You really need to treat each hospital as it's own one-off integration, plus all the politics needed to get access to the messages in the first place.
I also must say that I've seen hospitals make absolutely terrible decisions when it comes to EMRs. Choice of EMR should be treated as if the hospital is constructing a new building, as its costs and lasting impact can be that massive.
Of course, being written in MUMPS (just like some of the other biggies) doesn't help, but the failure of Vista to be implemented commercially has to do with market and human reasons that could have been engineered around. Missed opportunity for the US, really.
A friend of mine works for a digital health startup, and the majority of the RFP's they receive automatically disqualify them if they have anything hosted in the "cloud", so they are forced to buy and maintain all of their own servers.
In addition to these costs (which could already be considered prohibitively expensive) they have to use enterprise versions of proven ETL and BI tools for the perceived added security benefits (i.e. they can't use open source).
It is a meaningful effort to be HIPAA-compliant, that prevent us, for example, from using lots of cool SaaS services. The bigger issue for us is that each integration still has customizations associated with it, because of a lack of agreement about what fields mean.
If anyone is working in the digital healthcare space we'd love to work with you. You can get access to and build on our JSON API in 1-2 days. Sign up here: https://drchrono.com/api
Here is a youtube video we shot with a startup that built on our API: https://www.youtube.com/watch?v=HBCIzuXEH44
1) You can do an easy light integration with the right IT shops just using for example on EPIC: Wellconnect, Oauth, and whitelisting servers on both sides. This takes three days and provides much of what most providers require.
2) Like stated at the recent Healthtech conference, no one should try to come into digital health without a decade of healthcare experience at least to understand the challenges, drivers, political, regulatory, clinical, technical, and macro financial.
Just my respectful but diverging opinion.
Best,
Sherri (CEO at Medigram)
All is not lost though, startups that make software for healthcare are slowly taking hold of the market, but all those startups that have been killed off in the process have made a change for the newer ones to get this far.
And the incumbent vendor would say ... "so what?" Why would they care that young startups can't gain traction? What's in it for them? Pretty much nothing, from what I can see.
I work at athena and we're dogfooding our API for an increasing number of products/components as it's an easy way to both decouple internal services and improve the API for our partners. From my lowly, uninformed position as a developer, we're growing the number of partners as fast as our team can support at this point.
Calling it a joke is probably too harsh though. It just isn't the panacea that PR makes it out to be.
Now, where have we heard that before, in the mobile device space?
I've heard their innovation was also in pre-paying facilities for services. The collection rate for facilities from insurers is abysmal, so Oscar can negotiate a substantial discount by paying up front. Same idea as if you go to an MRI facility and offer them cash up front - they sometimes give discounts up to 75%. (Note: not 100% sure Oscar does this, I heard from investor and don't have time to research.)
> After two years in operation, the financial trajectory is becoming clear, both in terms of the growth and the costs. In New York, the company projected a sevenfold increase in premium revenue next year to $399 million from 2014. But it also projects a loss of 12% of premiums, equivalent to $47 million, according to regulatory filings.
...
> Oscar’s losses stem from two sources: higher medical costs as a percentage of premiums than rivals, and higher administrative costs, both of which are traditionally problems of scale in the industry.
> In New York, it projected that 91.5 percent of premium revenues would be eaten up next year by medical claims costs, among the highest projected ratios in the state. That leaves little left over to pay for administrative costs, estimated to be 17 percent of premiums next year, or taxes and fees. Included in administrative costs are the company’s engineering and marketing costs.
> History says insurance companies need at least 200,000 to 300,000 members in a state to be viable, according to Ash Shehata, a partner in KPMG’s health care practice; Oscar had 38,000 members in New York and New Jersey as of June 30, with plans to expand to Texas and California this year.
...
> But Oscar believes it can succeed as a sustainable and profitable business with only 80,000 to 100,000 members per state, according to a person familiar with the company. Though scale is important to contain administrative costs, the person said, Oscar’s plan is to avoid playing the big insurance company game of using size to negotiate lower claims costs with providers. Instead, it will curb claims costs by partnering closely with select providers to exchange data.
'Partnering closely with select providers' is probably the same thing you're referring to - pre-paying facilities for services.
This sounds dumb to me.
Perhaps they thought that the administrative costs stemming from operating in NY wouldn't make/break the company - it's whether they can substantially reduce the claims costs that will really determine the outcome. And if they're from NYC, the founding team probably had preexisting contacts in the local medical institutions, which made it easier to form the partnerships that are key to making Oscar's business model work. One of the founders is Joshua Kushner (https://en.wikipedia.org/wiki/Joshua_Kushner), whose family is well-connected in NYC (for example, his brother's father-in-law is Donald Trump).
I know something about the history of the insurance giant I worked for. I know that their success has a lot to do with one of the founders having been a lawyer by trade and making strategic choices concerning things like where to found their headquarters.
I have trouble fathoming doing something less strategic while hoping to break into such a highly regulated industry, basically.
Anyway, thank you for replying. Have an upvote.