New FHIR Documentation

fhir.catalyze.io

9 points·ryanSrich··4 comments

FHIR is a bad answer to a stupid situation.

The fact that it supports extensions and embedded resources is a bad idea. Some of the later stuff is okay, like the layout of patient objects.

Honestly, a big part of the problem is that nobody seems to be pushing back and saying "Folks, we've made all of this too damned complicated...let's just identify useful subsets and make that work."

Also, good luck having any meaningful impact on the discussions if you're not with one of the vendors or can spare the time for bureaucratic bullshit.

EDIT:

A further note on the patient stuff--it looks reasonable if you look at this thing's "Show the result of `GET /patients/<whatever>`". However, the actual spec ( http://www.hl7.org/implement/standards/fhir/patient-definiti... ) kinda hints at a massive headache.

Author of that doc here. I cannot agree with you more. I have tried to be a bit more polite about that point of view. It's is complicated and very unnecessarily so at times. Lots of gaps as well. The main hope I have is that there are a lot of players involved in this (such as BIDMC) who could drive some change.

Thanks for the comment

Being polite is in good part what has allowed the situation to degrade as far as it has in our industry. Bozos and yesmen. I understand why you might be more diplomatic though! :)

We're working on an open waveform format to replace WCM, for example, and the amount of silliness there staggers the mind.

Who are you aware of that's actually interested on working on a slimmer, easier-to-use system for this stuff?

There are EHR vendors involved including some of the big players (Epic, Cerner). Ultimately adoption won't be from vendors "doing the right thing" but because their customers and/or the govt. (via $$$ incentives) create pressure.

Reply on news.ycombinator.com