What’s Really Killing Digital Health Startups • Hacker News Board

Re: What’s Really Killing Digital Health Startups

#131

Post by lbhnact » Sat, Oct 31, 2015, 12:27 AM UTC

angersock wrote: post #109

gmarx wrote: post #71

Earlier quoted context omitted.

Can you be specific? I'm a skeptic but just now learning about it.

So, link is here for people playing the home game: https://www.hl7.org/fhir/ . 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 thi…

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)

Re: What’s Really Killing Digital Health Startups

#132

Post by angersock » Sat, Oct 31, 2015, 12:29 AM UTC

nradov wrote: post #114

angersock wrote: post #51

Earlier quoted context omitted.

FHIR is gross and overdesigned, like everything else in this moribund industry.

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 situatio…

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.

Re: What’s Really Killing Digital Health Startups

#133

Post by sk5t » Sat, Oct 31, 2015, 12:38 AM UTC

specialist wrote: post #112

gmarx wrote: post #105

Earlier quoted context omitted.

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…

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 min…

Honest question: who wants to read raw HL7? To whom is the ability to access HL7 on-demand a killer feature?

Re: What’s Really Killing Digital Health Startups

#134

Post by angersock » Sat, Oct 31, 2015, 12:46 AM UTC

rickard wrote: post #126

angersock wrote: post #109

Earlier quoted context omitted.

So, link is here for people playing the home game: https://www.hl7.org/fhir/ . 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 thi…

I don't quite agree with your complaints. Regarding #2, what do you consider the problem with representing arbitrary precision decimals as numbers? That your javascript json parser converts json numbers to 64-bit floats? I'm not sure that that is really a problem with FHIR - see e.g. https://www.npmjs.com/package/json-bigint . Or is the problem that exponents aren't allowed? About #3, how would you standardise addres…

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.

Re: What’s Really Killing Digital Health Startups

#135

Post by benihana » Sat, Oct 31, 2015, 12:48 AM UTC

5706906c06c wrote: post #19

salimmadjd wrote: post #17

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 solu…

> Basically you need to go into this knowing it'll take 3-4 years before you can show any traction. This x10MM

An upvote is preferable to a meaningless comment like "this" which adds very little value to the discussion.

Re: What’s Really Killing Digital Health Startups

#136

Post by sk5t » Sat, Oct 31, 2015, 12:51 AM UTC

snuxoll wrote: post #104

exelius wrote: post #62

Earlier quoted context omitted.

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 combinati…

> 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 w…

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.

Re: What’s Really Killing Digital Health Startups

#137

Post by ashearer » Sat, Oct 31, 2015, 12:58 AM UTC

joe_the_user wrote: post #55

apalmer wrote: post #38

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…

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 tal…

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.

Re: What’s Really Killing Digital Health Startups

#138

Post by angersock » Sat, Oct 31, 2015, 1:00 AM UTC

lbhnact wrote: post #131

angersock wrote: post #109

Earlier quoted context omitted.

So, link is here for people playing the home game: https://www.hl7.org/fhir/ . 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 thi…

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…

Thanks for getting JSON into a SHALL. :)

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.

Re: What’s Really Killing Digital Health Startups

#139

Post by Terr_ » Sat, Oct 31, 2015, 1:25 AM UTC

kohanz wrote: post #36

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 comp…

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.

Re: What’s Really Killing Digital Health Startups

#140

Post by ploxiln » Sat, Oct 31, 2015, 2:12 AM UTC

nommm-nommm wrote: post #93

bpatrianakos wrote: post #20

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 "l…

>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…

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).

(My mother is an MD)