When the cost of adopting your technology is vastly higher than the price you charge, you're usually screwed.
What’s Really Killing Digital Health Startups
141–150 of 159 posts
Re: What’s Really Killing Digital Health Startups
#142I 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…
Weconnect
Re: What’s Really Killing Digital Health Startups
#143I’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) - Provide…
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)
Re: What’s Really Killing Digital Health Startups
#144Earlier quoted context omitted.
You don't think HL7 v3 being somewhat of a markup language was an improvement?
It's a massive step backwards. 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…
As someone else who works in this space, this rings incredibly true.
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.
Re: What’s Really Killing Digital Health Startups
#145Earlier quoted context omitted.
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 diagno…
Inspections and licensing of restaurants and grocery stores are typically handled by local and county health departments. (Not the FDA) 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…
> 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.
It is the same as any other fast food joint. Heck, food quality improvements were an early selling point for McDonald's.
Re: What’s Really Killing Digital Health Startups
#146Earlier quoted context omitted.
>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…
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…
Non-snarky point, but every new technology is destined to become the next old technology.
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.
Re: What’s Really Killing Digital Health Startups
#147Earlier quoted context omitted.
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)
Re: What’s Really Killing Digital Health Startups
#148Earlier quoted context omitted.
I'm sitting in the office of one right now. Their codebase is sitting in Microsoft Visual SourceSafe: https://en.wikipedia.org/wiki/Microsoft_Visual_SourceSafe 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.
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 whi…
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."
Re: What’s Really Killing Digital Health Startups
#149Earlier quoted context omitted.
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 (th…
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 anal…
The "and left them alone" is a very important point that is not being met for innovation.
Re: What’s Really Killing Digital Health Startups
#150Earlier quoted context omitted.
>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…
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…
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.