I'm in the Health IT space but we took a different approach. Early on we realized most Health IT companies are really pharmaceuticals but they don't realize it.
What I mean by this is, you need to have the budget of a pharmaceutical to play in this space: 1 - you need to spend millions to win over consumers and 2 - you need to have an existing network of connections into doctor's offices to convince them of your solution. Big Pharmas have both of those. They have reps that constantly visit doctors or hospitals to engage them and they have a well spent marketing budget to build awareness for their product. Most startups can't do either of those.
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.
This comment and the OP mirror my own experience(s).
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:
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.
What a great insight. You should really write a blog post about it because this is such a helpful perspective and needs to be understood both by entrepreneurs and investors.
Considering that the average new molecular entity requires about $1 billion dollars over 10 years (factoring in cost of refining approximately 10,000 candidates into 1 entity capable of succeeding in Phased trials and receive approval), I'm not so sure these startups are anywhere near the "pharma" level.
It's more the perspective. I.e. you can't just apply tech to healthcare and expect to become successful anymore than you can apply it to ex. the shipping industry.
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.
From what you've described, it sounds like the majority of target customers tend to be large companies? It would make sense with the longer cycles and probably less of an urgency to take a risk on new technology.
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.
Having done exactly this type of integration with legacy systems I think a point that gets glossed over is that it's the startups themselves who are full of engineers who think that the whole world has moved on to using NoSQL Node.js RESTful JSON APIs in the cloud (that buzzword soup was intentional) when the reality is that the majority of established businesses are using unsexy and what they would consider to be "legacy" technology.
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.
Heh.. you hit the nail on the head here. I've been in health integration for the past five years. By restful nosql whizbang node standards, healthcare is full of really weird old shit, and if you want to interoperate, you have to be ready to party like it's 1999, because a lot of these systems were legacy even then.
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.
They won't do it on their own because there's really no incentive to make this information easily accessible. Healthcare is like Microsoft and Oracle in the 90's. Everyone wants you locked in to their platforms and services. Add to that the fact that you're constantly dealing with incredibly sensitive information on the level of financial data (arguably even more sensitive) and it gets worse. In finance you have PCI compliance to deal with. It's tough but not as crazy as $50k fines for every instance of leaked data with HIPAA.
It may not be deliberate attempt to lock customers in, but just the first part of what you said: there is no incentive to make this any easier. It basically works, so hospitals/clinics that need to make a few simple customizations can do so with REST API calls but it isn't easy enough for third-parties to quickly and easily build large applications. There's so much going on in healthcare that it is hard for big vendors to justify cleaning up their web services over doing other things. Especially when the "interoperability" buzz fits in better with supporting FHIR, CommonWell, Healtheway, HL7, etc.
>the reality is that the majority of established businesses are using unsexy and what they would consider to be "legacy" technology.
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.
I would argue that it isn't about how old the technology is but how good the developer tools and support are. Newer technologies (not brand new, ones that have a few years of maturity) often have better support in common developer platforms, more tutorials and answers on StackOverflow, etc. They are also easier to find employees to hire who know how to use them (or who WANT to use them).
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.
The way I see MUMPS or M (because clinicians don't like hearing that word) is a string typed almost-assembly level server scripting language.
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.
Does it though? Does it do its job well? Does it have scheduled maintenance every evening for the mainframe batch job? Does it not handle non-ascii in names? Does it not have the perspective of knowing how much better it could be done, like webmail before gmail?
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).
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.
I'd say that the potential digital health startups that do their due diligence end up picking another industry. So it's only the guys who failed to do it who end up starting companies.
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.
I guess that depends on how you define it. If by "digital health" companies you mean medical industry companies, you may have a point. But part of what is wrong with American health care is that health care is a polite euphemism for medical care. Grocery stores do not get defined as being in "health care," though eating healthy is clearly a cornerstone of good health.
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.
They are largely one and the same; because as soon as you start claiming your product or service can improve a user's health, you're subject to the regulatory scope of the FDA.
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.
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:
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.)
Well that's because a grocery store isn't a health care company: it's a retailer. You can also buy very unhealthy things at the grocery store.
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.
What you describe is absolutely the wrong way to start a business
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.
Right; but that doesn't work in health care because of the regulatory environment (which in this case, is absolutely necessary). It's not like the hotel business where if you have a bad experience, Airbnb can just solve the problem with money. There is a long history of misleading health claims on products that has existed for almost all of human history; so any product you claim improves the health of the user has to be backed up by data.
"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, but migrating to another VCS would be like working on a moving car and you have to pay the mechanic to plan -> dev -> implement...and then convince everyone who's worked with the VSS thought pattern (which is pretty different from SVN, GIT, just about everything) to use this new 'better' thought pattern or create something that will mimic the workflow they're are used to and connects to the new VCS...all the while you are still try to generate revenue rather than resolve a legacy 'issue' that really just looks bad and is still in place because: it works, everyone is used to it, you don't have the time / resources to make a change until it doesn't work.
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.
True story: it took two months to explain to an IT department that XML serialization files should be flagged as binary to prevent SVN performing line auto-merges on them.
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."
I’m in the digital health space (CEO of Omada Health).
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)
This # of important stakeholders makes it difficult to “trace a dollar” and figure how who is your buyer. It's important to understand the basics of the financial, contractual, and regulatory relationships between all of these.
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.
This is a GREAT post. It is a giant puzzle, not for the faint of heart but very fun. Provider motivations vary widely based broadly on their economics and interests. There's 316 distinct U.S. markets alone! Cheers, Sherri (CEO@Medigram)
Wow. Fascinating to see so many stakeholders involved. While I'm not in the health care space, I'm going up against an industry who's fairly closed off (residential real estate) and am wondering if you have any ideas/advice on what are the key things for breaking through industries that are very tight/complex? What's key for managing all these stakeholders?
Based on this article whats killing digital health startups is they dont understand they are fundamentally in the integration business.
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.
Certainly you can make money at integration, vast amounts of money are made. But as one friend in the business really did tell me once "your job is taking one piece of crap and another piece of crap, get them to talk to each other and so turn them into a third larger piece of crap". Integration "works" but overall often makes the problem worse or at best allows you to run place. Imagine when something else has to talk to your "talks to ten things thing".
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.
If you integrate the crappy thing everyone's using with something less crappy, gradually displacing the crappiest parts, then the world has gotten better. Maybe not fast by Silicon Valley standards, but still an improvement.
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.
> 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.
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).
Well, many successful startups are just that, though.
"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).
I have been consistently surprised that Zapier hasn't taken off like a rocket. Can anyone explain this?
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.
Are their numbers public? If they are I'd love to see them; if they indeed haven't "taken off" I'd also be surprised.
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.
Zapier is great when you're dealing with REST (or even SOAP) calls.
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.
> 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.
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.
Must you really deal with the intricacies of HL7 to do this, then, or do you simply pull a few fields from the MSH and then go grepping away for ^IN1\|(something-interesting)?
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.
We use a proper HL7 parser built into our interface engine (Mirth Connect), extract the data we use and dump it into PostgreSQL. Regular expressions would be an adequate tool for parsing HL7 if you wanted to roll your own, but it made little sense to do everything from scratch.
Random thoughts from working at a marketing/software company that people occasionally build Zapier integrations for.
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.
Saying these companies could just open their APIs is probably wrong. None of the legacy EMRs has a good underlying data model and what they have tends to be customized per site. There might be some minor functionality you could get to work consistently across sites with such an open API but chances are it wouldn't cover everything your innovative startup needs.
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
What you say is true. I solved the problem by flipping it around.
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.
Better search is definitely needed and seems like something the EPICs and Cerners of the world could easily do if they just assigned a couple smart people and left them alone. Instead they'll probably form vast teams of search stakeholders.
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
Out of curiosity, what kind of data do you propose searching? Do you mean searching a patient chart? Searching for lab results? Searching doctor notes? Or do you mean more like analytics to see trends? Or for finding patients, in the vein of an national patient ID service?
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?
Perhaps my effort was informed by my prior experiences with ERP/CRM systems and the semantic web.
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.
Did you ever make it to a 510(k)? I can see Lucene making their head explode too...to say nothing of validation without checks on overwriting patient info, etc
I plead ignorance about 510(k). Scanning the wikipedia article, it might have come into play if our "patient portal" (think Microsoft HealthVault, Google Health) ever got traction. Because our brilliant notion was to store patient collected data (heart, glucose), to be shared with care providers. Another complete non-starter.
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.
Also something less talked about is how hospital administrators don't want to share their data for competitive advantages. So, they're more than happy letting the EMR vendors taking the blame for the lack of interoperability while in fact that said lack of interoperability is exactly what they're looking for when partnering up with an EMR.
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.
As any engineer knows, most software applications have APIs; it’s simply a business choice whether to publish them or not.
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.
Right, a (public) API is actually a product, just one that happens to be consumed by programmers. Starting one means implicitly committing to support the people who use it and grow it in a backwards-compatible manner even when your internal data representation goes in another direction.
In enterprise, unless it's been written in the last 5 years, the odds are good that it doesn't have APIs. Or, if it does have APIs and was written in the past 10 years, those APIs are only intended for internal (within the app itself) consumption and could never, ever be used externally.
Yeah. From my experience, public API's are only opened up when there is enough money generated from them to fund someone dedicated to managing/implementing them.
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.
The amount of data is also a huge challenge. The HL7 "standard" for patient data exchange is huge - thousands of potential data points with tens of thousands of options. The IDC-10 code set allows more than 14,400 different codes. And that's just the tip of it: https://en.wikipedia.org/wiki/ICD-10
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).
A lot of the HL7 stuff could be made a lot simpler if the hospitals embraced a simpler subset--instead, everybody picks and chooses features and fields, as do vendors, and then punt it off to integration work. It's dumb.
IHE has done good work defining conformance profiles on top of the basic HL7 standards that help to improve interoperability. Adoption is growing but still not universal.
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.
I wonder if part of the B2C difficulty is that insurance pays for most healthcare but (with a few exceptions) not for the lifestyle choices that would reduce healthcare costs.
If there was more of an emphasis on preventative measures that insurance paid for, I wonder if it would be different.
One of the biggest barriers to preventative healthcare is that it doesn't pay -- at least not quickly enough to make business sense for an insurer. There's a famous paper that looked for cost-saving interventions in preventing heart attacks and strokes, and it concluded:
"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."
The latest buzzword is precision medicine. Also if that's from 2008 then it is missing all the advancements in mobile (iPhone is 2007) and digital health monitoring like FitBit. So one of those three things could easily make an improvement over what that paper says. (Did not read the paper.)
This is difficult due to ACA regulations. For example, Pact (formerly GymPact) was trying to give people discounts on Blue Shield of CA health insurance premiums for going to the gym. A provision/update in the ACA made this illegal about a year ago; not sure if it's changed since then.
That said, it seems likely that insurance premiums will eventually be tied to real time health data, like Metromile is doing for car insurance.
What lifestyle changes would an insurer pay for--at least without very intrusive lifestyle monitoring? (Which will increasingly be possible to do whether it's done or not.) There are often discounts for gym memberships and the like. And annual physicals are typically paid for.
A friend of mine can log exercise and turn it into free money in his HSA. I don't know whether they validate it against an activity tracker or not, but this is already happening.
I'm genuinely not sure. Paying for gym memberships, FitBits, and things to get people exercising could be one option. Or maybe insurers could use extra incentives to encourage people to get flu shots or regular checkups?
One thing ACA did which at least is plausibly useful (though whether it'll move any statistics remains to be seen) is to include an annual physical plus all CDC-recommended vaccines with $0 billed-to-patient cost. So even if you otherwise have a high-deductible plan, you don't pay a copay or deductible for those services. This isn't quite an active incentive, but it's an attempt to remove the price disincentive, with the hope that'll result in higher vaccination rates (the flu vaccine is included).
I think it's interesting that this article is being written in a time when more Digital Health startups are surviving than ever before. It doesn't take being an insider to succeed in healthcare anymore; there's better options for hosting and information is no longer hidden or sold on how to integrate with EHRs and payors.
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
Lot of interesting comments about difficulty of IT integration. However, there is a much more fundamental problem with Healthcare IT. That has to with a lack of a functioning market. Thanks to HITECH subsidies, a bunch of money has flowed into EHR and related systems. It gives the impression of a customer paying for these systems, but once that fades a lot of these HIT companies are going to find that they are not in a market. People who think another 3-4 years will fix the issue are in denial.
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.
Give me a fucking break. HIPAA compliance is actually an issue. Published APIs may have benefits to businesses, but what is the benefit to the patients? He claims this hurts patients when his only evidence is his company couldn't cut it. HIPAA was written in the interest of patients who don't want the entire world to know they are HIV positive or have had 5000 sex partners because they are a sex worker or whatever. Lives can be ruined by leaving that kind of info flapping in the wind. Furthermore, federal fines for not complying can be painfully high.
If you don't want to deal with HIPAA and take it very seriously, then stay out of this space. You aren't worthy.
Just because the APIs are published doesn't mean that the data is out there for any unauthenticated client to access. Of course HIPAA is important, but it is not a serious problem for interoperability.
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.
Well thank you for those remarks. It really doesn't change my assessment of the piece. He is basically arguing that his competitors aren't graciously handing over the reins so he can make bank. How shocking. Like him, other people want to protect their income stream.
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.
BTW, while I would love to improve the healthcare industry and I wish you the best of luck, I don't think software is the primary problem. Sure, it is very expensive and always 10 years out of date. But the real problem is government and the payer model.
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.)
> (Insurance was originally for catastrophic care where the cost for a major illness or surgery would get too high.)
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,
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.)
> 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.
One way this industry may get nudged significantly (disruption is too strong a word and not exactly a great thing when dealing with peoples health) is to approach it from the outside the system and come at it from the consumer health angle. Yes, it is far more limited in many ways as you can't build a system a hospital can integrate but there is still a lot that can be done.
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.
I have used them and they are definitely on the right path but they haven't yet got past the point of just showing a lot of graphs and comparative statistics, etc. As always, it comes down to translating data to useable knowledge, which we as an industry are obviously trying to figure out across pretty much all verticals
My understanding is that PLM very much translates to useable knowledge - just for the pharma and PHM folks who mine the backend (which is how they make money). Notably, this is all quite above-board: it's not a "secretly mine people's private medical details" situation, it's "overtly mine people's private medical details in order to help find treatments for their rare disease"...
You are right about that - and I think they are doing something really good (and props to them for being really up-front about how they operate) but unless they can really do something to help patients day-to-day, is seems the participation rate will probably always be small and inconsistent, which means a smaller, less-complete data set that will yield less accurate and useful results.
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)
To think that your startup can "disrupt" an industry that has the spending equivalent to that of the GDP of an entire country is a fool's game. Most need to focus on longevity versus strategizing a quick exit.
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.
Could I talk to you about a project I'm developing? It's marketing solutions for healthcare practices, ideally connected to EMR and IT systems. Would love to hear your thoughts and advice.
The biggest issues I've seen haven't been legacy/technological challenges, but almost completely political/incentive/motivation reasons on the part of hospitals wanting to build interfaces for many practices. On the part of vendors, many systems Nextgen/Allscripts/GE etc, can often charge an exorbitant amount to build and maintain the interfaces.
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.
No discussion about APIs in health care EMRs would be complete without mentioning HL7's new FHIR protocols: REST-ful web service endpoints for HL7 health data. It makes developing applications with these standards much easier.
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.
I'm totally on board with FHIR. I just don't think we're there yet. I've talked with 3 of the Argonaut sites and real-life, production ready FHIR capabilities are lacking. There aren't many useful provider-facing applications that you can built with just GET requests. Most applications require real-time pushing and pulling of data. As sad as it is, until FHIR as implemented (not theoretically) that way, we'll still be plugging HL7v2 together. I, as an HL7v2 slinger myself, hope that goes away soon.
EM resident with an interest in EHR design and development here -- this is really cool, I didn't take a close enough look at this in Annals in August but I'm reading about the spec now. Looks promising.
Happy to hear specific issues!
https://chats.fhir.me/feeds/skype/implementers.html - best place to participate if you want to help. Even at v1.0, many people are open to changes that reflect the needs of strong cases.
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.
Instead of complaining, feel free to propose a better alternative. The HL7 standards development process is very open.
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 industry's irreducible complexity is killing people every day, and bankrupting the survivors.
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 ).
So, I could actually show you the emails where I helped move JSON from a MAY implement (with XML as a SHALL), to it being a proper first class member of the spec. The FHIR core team was and continues to be interested in feedback from experienced integrators. I read your comments here occasionally; you're smart, participate!
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?
So, specifying dateTimes (as defined here: https://www.hl7.org/fhir/datatypes.html#dateTime) is not sufficient. Remember, it isn't including the timezone (no code or anything), it's including the offset. The difference there is the usual conflation of time and timezone and location...basically, if you don't have the actual physical and political location, the offset is of only academic interest and you might as well just display UTC.
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.
Including XML and RDF doesn't bother me. A lot of people greatly prefer JSON over XML. I don't get exorcised either way. The final two look like problems. I would guess the penultimate one is because most medical systems ignore time zone so you just assume it happened in the time zone of the system of origin. It probable doesn't matter often in practice. If two different patients had a lab test done on opposite sides of the world would that knowledge ever be important? On the other hand, time is important within a patient data set. This might be a problem if a patient radically changed time zones within the course of a day.
I can see it being inconvenient for import into a better designed system. You'd have to make an assumption about time zone.
I'm a grant writer and have worked for numerous Federally Qualified Health Centers (FQHCs) and a smaller number of hospitals. From their perspective, EMR and related systems have tended to cost at least as much as they've saved. Some of them have seen the vendor jousting Sung describes and have experienced all sorts of vendor fatigue and vendor lock-in.
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....
Why doesn't the federal government build an EMR system and require its use as a condition of accepting Medicare payments?
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.
That's exactly why I'd want to tie a nationwide EHR/EMR system to Medicare reimbursements. In this case, not only must you drag the horse to water, you must force it to drink.
Having used the VA's system as a physician a few years ago, I must say it's probably my favorite. Epic, Sorian, etc add a lot of worthless gloss with minimal increases in functionality, in my experience (probably doesn't have good billing modules but those could be added). I've always thought it was a shame that this wasn't govt mandated EMR ... Im usually for competition, but in this case, we've spent millions (billions?) to reinvent the wheel. It's not at all uncommon for me to print labs off of a screen, then fax them to a different facility, where the values are then input by hand back into a (different) EMR. Completely insane, like something out of Terry Gilliam's Brazil.
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.
Exactly. Vista has pretty lousy UX, but it's implementation across most of the VA it a central part of the VA's much greater efficiency that other systems with similar populations.
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.
It's not just the lack of API's that makes it hard for digital health startups, a big hurdle is the perceived lack of security of a cloud based solution in regards to health care data.
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).
I believe this is out-of-date. Our healthcare startup has passed in-depth security reviews from multiple huge carriers, and we operate in the cloud and use tons of open source. (We're hiring Rails devs!)
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.
There are HIPAA certified cloud servers out there. I think the bigger problem is having tight security when integrating. It is considered safer to integrate behind a firewall (on an intranet) than worry about how to pass data between cloud-based software and locally hosted 3rd party databases/software
At drchrono (#1 iPad EHR on the Market, YC W'2011) we are building a very open API that has an open door policy to our customers and other digital health startups.
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
I respectfully do not agree with John's statements.
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.
Regulations, Big Pharma and Legacy Software will all take years to change, changing the behavior of an industry is usually pioneered by a few and in medicine that's pretty tough.
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.
"This kind of behavior by incumbent vendors leaves a lot of young digital health startups at risk of not being able to scale fast enough before their seed rounds dry up."
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.
EHRs are starting to open up more. EPIC (largest EHR vendor in the US by market share) just opened an API for some types of medical data. AllScripts and Athena also have open-ish APIs. 5 years ago none, and I mean literally zero, of the EHRs had APIs.
Practices on EPIC are still fundamentally non-networked, so even with an "API", you can't scale your product from one practice to all of them without some amount of non-trivial integration.
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.
That's true on the one hand. On the other hand, Athena wants a significant chunk of your profits to connect to their API. At least HL7v2 interface were one-time, scale everywhere from a cost model.
They aren't really ready for use. FHIR isn't really ready for use. While it's version 1.0.2, there's a lot of functionality lacking; for example you can't send back orders. And it seems like they have frequent breaking changes at this point. I've also yet to hear of anyone actually getting permission and using the open Epic FHIR apis in production.
Calling it a joke is probably too harsh though. It just isn't the panacea that PR makes it out to be.
"Another well-established vendor created a partner program under the guise of wanting to disrupt the EHR market (one in which they had significant market share), then later rejected our application because, they said, it was competitive with one of their modules."
Now, where have we heard that before, in the mobile device space?
Oscar Health is actually an insurer. They're trying to win by (a) better marketing and (b) using tech (like free fitness tracker) to reduce their loss ratio.
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.
Why did they start in New York? In order to do business in New York, an insurance company has to be headquartered (incorporated) there. (Edit: No other state requires this.) And New York is expensive.
They probably started in NY because most of the founding team is living in/near NYC, according to a document filed with the NY DFS (http://www.dfs.ny.gov/insurance/exam_rpt/x9475o13.pdf). It also states that
"The Company is a wholly-owned subsidiary of Mulberry Health Inc. (“Mulberry”), a Delaware Corporation."
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).
The insurance giant I once worked for also has a wholly-owned subsidiary in New York. This is probably a common tactic for coping with the ...quirky New York law concerning "No insurance company can sell insurance in our state unless you incorporate in our state."
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.
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.